Sécurité
Sécurité d’Oleafly Server
Oleafly Server est le serveur de collaboration auto-hébergé de l’application de bureau Oleafly. Avant que les chercheurs d’un laboratoire national ou d’une université puissent l’utiliser, leur service informatique ou leur équipe de sécurité doit généralement l’examiner. Cette page s’adresse à cette équipe. Elle décrit ce que fait le serveur aujourd’hui et ce qui est prévu pour les déploiements en environnement réglementé.
Cette page porte sur le serveur. Pour l’application de bureau seule, consultez la page de confidentialité.
Déjà en place
Ce que fait le serveur actuellement
Auto-hébergé
Votre organisation exécute le serveur sur ses propres machines ou sur son propre compte cloud, avec Docker, Coolify, Render, Railway ou comme simple service Linux. Les fichiers des projets et la base de données y restent. Les fichiers peuvent être stockés sur disque ou dans n’importe quel stockage compatible S3.
Aucun appel externe
Le serveur n’effectue aucun appel réseau vers l’extérieur, sauf vers le fournisseur d’authentification que configure votre organisation.
Votre fournisseur d’identité
Les utilisateurs se connectent avec le fournisseur d’identité OpenID Connect de votre organisation. GitHub et les liens envoyés par e-mail fonctionnent aussi, tout comme un code de connexion pour les appareils dont le navigateur ne peut pas revenir à l’application.
Les administrateurs décident qui entre
Les administrateurs contrôlent qui peut rejoindre le serveur grâce à une liste d’autorisation et à des règles de domaine, et attribuent à chaque personne un rôle : administrateur, mainteneur, membre ou invité. Les invités ne voient que les projets auxquels ils sont invités, avec l’approbation d’un administrateur si vous le souhaitez.
Clés d’appareil
Chaque appareil possède sa propre clé, et les sessions y sont liées, si bien qu’un jeton copié est inutile sans cette clé. Les jetons de rafraîchissement sont à usage unique, et le serveur détecte leur réutilisation. La déconnexion d’un appareil prend effet immédiatement, y compris sur les connexions déjà ouvertes.
Modifications signées
L’appareil qui effectue une modification la signe. Le serveur vérifie que chaque identité d’édition appartient à l’appareil qui a signé la modification, et vérifie de la même manière les auteurs des commentaires. Il construit lui-même les instantanés des projets à partir du journal des modifications signées, plutôt que de faire confiance aux données envoyées.
Journaux de sécurité et d’accès
Un journal de sécurité enregistre les connexions, les connexions refusées, les actions d’administration et les changements d’appareil, chacun avec l’adresse du client. Les propriétaires d’un projet peuvent aussi tenir un journal d’accès indiquant qui a ouvert leur projet.
Image de conteneur et SBOM
Chaque version est livrée avec une image de conteneur légère et sans shell, une nomenclature logicielle (SBOM) et la provenance de la compilation.
Évaluations indépendantes
Des évaluateurs indépendants ont examiné la sécurité, les performances et la scalabilité du serveur. Les problèmes relevés ont été corrigés, et les corrections sont couvertes par des tests.
Prévu
Prévu pour les déploiements en environnement réglementé
Certains déploiements demandent plus que ce que fait le serveur aujourd’hui. Rien dans cette section n’est encore disponible. Si votre évaluation dépend de l’un de ces points, dites-le-nous quand vous nous contactez. Cela nous aide à décider ce qu’il faut développer en premier.
Mode FIPS
En mode FIPS, TLS et les signatures utiliseront un module cryptographique validé FIPS 140.
Projets chiffrés
Le contenu des projets sera chiffré sur les appareils des membres. Le serveur relaiera des modifications scellées et ne pourra lire ni le texte, ni les commentaires, ni les fichiers. Les clés seront renouvelées chaque fois que quelqu’un sera retiré.
Contrôles renforcés pour les administrateurs
Les actions d’administration sensibles demanderont d’abord Touch ID, Windows Hello ou une nouvelle connexion. Les clés d’appareil seront conservées dans la Secure Enclave ou dans un TPM. Chaque administrateur recevra un e-mail en cas de changement de rôle ou de paramètre, et vous pourrez définir des politiques de session et d’inactivité.
Export d’audit
Les journaux de sécurité et d’accès seront transmis en continu à votre SIEM au format syslog ou JSON, avec des paramètres de rétention et la conservation légale.
Chiffrement au repos
La base de données et les fichiers stockés seront chiffrés avec des clés issues du service de gestion des clés de votre organisation.
Provisionnement SCIM
Les membres seront provisionnés depuis votre fournisseur d’identité via SCIM.
Installation sans internet
Une procédure documentée permettra d’installer le serveur sur un réseau sans accès à internet.
Documentation de sécurité
Nous publierons pour le serveur un modèle de menaces, un guide de durcissement, une matrice de responsabilité partagée et un processus de divulgation des vulnérabilités, et un tiers réalisera un test d’intrusion.
Nous contacter
Demander une évaluation de sécurité ou un projet pilote
Si votre équipe évalue Oleafly Server ou souhaite mener un projet pilote, ouvrez une discussion dans GitHub Discussions. Précisez ce dont votre évaluation a besoin, y compris tout point de la liste des éléments prévus.
Vous avez trouvé une vulnérabilité ? Ne la rendez pas publique. Signalez-la en privé sur GitHub, comme l’explique la politique de sécurité.