Un dump de base de données ne révèle rien.
Les données personnelles de chaque utilisateur sont chiffrées au repos avec des clés propres à chaque tenant, qui ne transitent jamais par la base de données. Un identifiant de stockage compromis ou une sauvegarde volée ne livrent que du texte chiffré — ni e-mails, ni noms, ni numéros de téléphone.
Comment ça fonctionne
- Le chiffrement s'effectue en dehors de la base de données. Les valeurs sont chiffrées et déchiffrées via HashiCorp Vault Transit — l'application ne détient jamais le matériel de clé, et la base de données ne voit jamais de clé.
- Chaque tenant possède sa propre clé. Supprimer un tenant détruit sa clé par crypto-broyage, rendant toutes ses données définitivement irrécupérables — aucun effacement ligne par ligne n'est nécessaire.
- Le chiffrement AES-256-GCM randomisé protège chaque valeur, de sorte que des entrées identiques ne produisent jamais le même texte chiffré.
Chiffrées, et pourtant consultables
Le chiffrement implique généralement de renoncer à la recherche. Pas ici. En plus de chaque valeur chiffrée, nous stockons des jetons d'« index aveugle » par HMAC à clé — de sorte que la connexion par e-mail, la recherche par nom côté administration, et « tous les utilisateurs de acme.com » fonctionnent tous par correspondance exacte ou par préfixe sur des données qui ne sont jamais stockées en clair. Les clés d'index sont elles aussi des HMAC : un dump des tables d'index ne révèle rien non plus.
Ce qui est protégé
Adresses e-mail, noms et prénoms, numéros de téléphone, noms d'entreprise, et tout attribut personnalisé que vous stockez — tout est chiffré au repos. Les mots de passe n'ont jamais été stockés de façon réversible (ils sont hachés à sens unique avec une KDF moderne). Les attributions de rôles, les identifiants opaques et les horodatages ne sont pas des données personnelles et restent en clair afin que le système reste exploitable.
La menace contre laquelle nous nous protégeons
Le scénario visé est un identifiant de stockage compromis ou une sauvegarde exposée — quelqu'un obtient une copie brute des tables. Le chiffrement transparent au niveau du disque (avec clés gérées par le client) n'aide pas dans ce cas : il déchiffre automatiquement pour tout ce qui peut lire le stockage, si bien qu'un dump ressort en clair. Le chiffrement au niveau applicatif, lui, protège réellement — les clés résident dans Vault, isolées des données, de sorte qu'une copie des tables n'est qu'une copie de texte chiffré.
En transit aussi
Les données sont chiffrées en transit (TLS 1.2+) comme au repos. Nous serons heureux de présenter en détail nos contrôles de sécurité aux clients entreprise sous accord de confidentialité (NDA).
Signaler une vulnérabilité
Vous avez trouvé quelque chose ? Écrivez à [email protected]. Notre contact lisible par machine est publié à l'adresse /.well-known/security.txt.