Sécurité
Comment nous protégeons vos données
Les mesures techniques et organisationnelles en vigueur. Cette page décrit ce qui est mis en œuvre ; les limitations pertinentes sont énoncées à l'annexe II du contrat de traitement des données.
Cette traduction est fournie pour votre commodité. En cas de divergence, la version anglaise prévaut.
Dernière mise à jour:
Chiffrement
- Toutes les connexions sont chiffrées en transit avec TLS, à l'aide de certificats délivrés par une autorité de certification publique : l'application, l'API et les protocoles de messagerie (SMTP, IMAP et JMAP).
- Les fichiers dans Drive, les documents et les enregistrements de réunions sont chiffrés par nos soins, avant d'atteindre le fournisseur de stockage, avec AES-256-GCM. Le fournisseur stocke le texte chiffré et ne détient aucune clé permettant de le déchiffrer.
- Chaque organisation possède sa propre clé, conservée dans l'Union européenne et encapsulée par une clé maître qui réside uniquement dans l'environnement du service en cours d'exécution. La suppression de la clé d'une organisation rend immédiatement illisibles tous les fichiers qui lui appartiennent — une garantie plus forte que la suppression de lignes.
- Cela protège vos fichiers du fournisseur de stockage et de quiconque obtiendrait une copie du stockage. Il ne s'agit pas d'un chiffrement de bout en bout : nous détenons les clés, car le service produit des aperçus, édite des documents dans le navigateur et sert des liens partagés. Nous préférons le dire plutôt que de laisser le mot « chiffré » sous-entendre autre chose.
- La messagerie n'est pas encore couverte par cette mesure. Le contenu des messages est détenu par le serveur de messagerie, qui le lit et l'écrit directement et ne transite pas par la couche décrite ci-dessus. Il est protégé en transit par TLS et au repos par le propre chiffrement du fournisseur et par les contrôles d'accès ci-dessous. L'extension de notre propre chiffrement à la messagerie est un travail en cours, et non une fonctionnalité que nous revendiquons aujourd'hui.
- Les secrets d'authentification à deux facteurs sont chiffrés dans la base de données avec une clé détenue en dehors de celle-ci.
Contrôle d'accès
- Les mots de passe des comptes sont stockés sous forme de hachages bcrypt. Les identifiants de messagerie sont détenus par le serveur de messagerie et ne sont jamais stockés en texte clair.
- La robustesse des mots de passe est mesurée au moment du choix et les mots de passe faibles sont refusés — à la fois par nos soins et par le serveur de messagerie lui-même.
- L'authentification à deux facteurs est disponible pour tous et peut être rendue obligatoire au sein d'une organisation.
- L'accès aux données au sein du service est régi par des rôles et des autorisations par ressource. Chaque requête concernant les données d'un client est limitée à l'organisation de l'utilisateur authentifié — il s'agit d'une condition dans la requête, et non d'une vérification à l'écran.
- L'accès administratif à l'infrastructure de production est limité au personnel autorisé et protégé par une clé et un second facteur.
Sécurité de l'application
- Les cookies de session transitent uniquement via HTTPS et ne sont pas accessibles aux scripts. Les requêtes modifiant l'état nécessitent un en-tête qu'une requête cross-site ne peut pas définir.
- Les points de terminaison d'authentification sont limités en débit, afin de contrer les attaques par force brute et la réutilisation d'identifiants volés.
- Les secrets et identifiants parviennent au système via l'environnement et ne résident pas dans le code source.
- L'interface d'administration du serveur de messagerie n'est pas exposée sur Internet.
Séparation entre clients
- Le service est multi-locataire. Les données de chaque organisation sont séparées logiquement : chaque enregistrement porte l'identifiant de l'organisation propriétaire, et chaque requête y est contrainte.
- Les boîtes aux lettres sont des comptes distincts sur le serveur de messagerie, isolés les uns des autres par ses propres contrôles.
Sauvegardes
- Les bases de données de l'application et de la messagerie — cette dernière contenant les comptes, la configuration des boîtes aux lettres et les données des messages — sont sauvegardées régulièrement vers un stockage d'objets sous juridiction européenne.
- Le stockage d'objets lui-même ne fait pas l'objet d'une sauvegarde distincte. Les fichiers dans Drive, les enregistrements de réunions et l'original de chaque message électronique avec ses pièces jointes reposent sur la durabilité du fournisseur de stockage ; il n'existe pas de seconde copie sous notre contrôle. Nous le précisons plutôt que de laisser le mot « sauvegardes » tout englober.
- Les sauvegardes sont chiffrées avant de quitter le serveur, avec une clé asymétrique : le serveur ne possède que la moitié publique, il peut donc écrire de nouvelles sauvegardes et ne peut pas lire les anciennes. La moitié privée est conservée en dehors de l'infrastructure de production.
- Chaque sauvegarde est vérifiée comme étant lisible avant d'être chiffrée et stockée, et la procédure de restauration est testée à partir d'une copie chiffrée — y compris la vérification que la copie ne peut pas être lue sans la clé privée.
Supervision
- La disponibilité de chaque composant est mesurée en continu depuis l'extérieur de l'infrastructure et publiée sur status.beskos.com.
- Les accès administratifs et les opérations sensibles sont journalisés.
Développement
- Les modifications apportées au logiciel sont versionnées, revues avant publication et déployées via un pipeline automatisé ; l'historique est conservé.
- Les dépendances sont épinglées par version et les images sont construites par nos soins à partir de sources connues.
Signaler une vulnérabilité
- Écrivez à security@beskos.com. Nous accusons réception des signalements sous cinq jours ouvrés.
- Nous ne poursuivons pas les chercheurs qui agissent de bonne foi et n'accèdent pas, ne modifient pas ou ne conservent pas les données d'autrui. Nous demandons du temps pour corriger un problème avant qu'il ne soit rendu public.