Bring Your Own Key : contrôle du chiffrement pour l'entreprise

Note : Cet article décrit l’architecture et la conception de Mandraki. Certaines fonctionnalités évoquées sont déployées progressivement et peuvent ne pas être encore disponibles dans toutes les offres.

Pour de nombreuses équipes de sécurité d’entreprise, le chiffrement est une condition nécessaire mais pas suffisante. La question essentielle n’est pas de savoir si les données sont chiffrées, mais qui détient les clés. Si le fournisseur de la plateforme contrôle les clés de chiffrement, alors le fournisseur — ou quiconque peut le contraindre — peut déchiffrer les données. Le chiffrement existe, mais le client ne le contrôle pas vraiment.

La fonctionnalité Bring Your Own Key (BYOK) de Mandraki répond directement à cela. Elle permet aux organisations de fournir leurs propres clés de chiffrement, garantissant que le contrôle cryptographique reste à tout moment entre les mains du client.

La hiérarchie de clés à trois couches

Pour comprendre le BYOK, il est utile de comprendre l’architecture de chiffrement globale de Mandraki. Nous utilisons un modèle de chiffrement d’enveloppe à trois couches.

Au sommet se trouve la Master Key, qui protège tout ce qui se trouve en dessous. Dans un déploiement standard, Mandraki génère et gère cette clé. Dans un déploiement BYOK, le client la fournit.

La deuxième couche est composée de clés d’organisation — une par organisation. Chaque Org Key est chiffrée (encapsulée) par la Master Key et stockée dans la base de données sous sa forme encapsulée. Lorsqu’elle est nécessaire, l’Org Key est désencapsulée en mémoire, utilisée, puis supprimée. Les clés désencapsulées sont conservées dans un cache LRU en mémoire avec une durée de vie de cinq minutes pour les performances, mais ne sont jamais écrites sur disque ni stockées dans Redis.

La troisième couche est composée de Data Encryption Keys (DEK), une par finalité : messages, fichiers, enregistrements et transcriptions. Chaque DEK est encapsulée par l’Org Key de son organisation. La DEK est ce qui chiffre et déchiffre réellement les données à l’aide d’AES-256-GCM.

Cette approche en couches signifie que la rotation d’une clé à un niveau ne nécessite pas de rechiffrer toutes les données en dessous. La rotation de l’Org Key nécessite de réencapsuler les DEK, mais pas de rechiffrer chaque message. La rotation d’une DEK signifie que les nouvelles données sont chiffrées avec la nouvelle clé, tandis que les anciennes données restent lisibles avec l’ancienne DEK (qui est marquée comme tournée mais conservée).

Comment fonctionne le BYOK en pratique

Lorsqu’une organisation active BYOK, elle fournit sa Master Key via un processus d’importation sécurisé. Mandraki accepte une clé AES 256 bits fournie via un canal sécurisé. L’organisation est responsable du cycle de vie, de la sauvegarde et de la disponibilité de la clé. Pour les organisations disposant de leurs propres HSM ou infrastructure de gestion de clés, la clé peut être générée à l’extérieur et importée dans Mandraki.

Le principe est simple : Mandraki ne génère ni ne stocke jamais la racine de la hiérarchie de clés. C’est le client qui le fait. Si le client révoque ou retient sa clé, Mandraki ne peut plus déchiffrer aucune des données de cette organisation. Le texte chiffré reste dans la base de données, mais il est inerte.

Plus important encore, l’ensemble du processus de gestion des clés se déroule au sein d’une infrastructure souveraine UE. Il n’y a aucune dépendance à des services de gestion de clés non européens — aucun fournisseur de KMS cloud externe, aucun appel API vers un pays tiers. Vos clés de chiffrement restent sous votre contrôle, à l’intérieur des frontières européennes.

Les implications de la révocation de clé

C’est là que le BYOK devient un véritable contrôle de sécurité puissant, et là où les organisations doivent comprendre clairement les conséquences.

Si vous révoquez votre clé BYOK, toutes les données chiffrées de votre organisation deviennent définitivement inaccessibles. Les messages ne peuvent pas être lus. Les pièces jointes ne peuvent pas être téléchargées. Les enregistrements d’appels ne peuvent pas être lus. Les transcriptions ne peuvent pas être récupérées. C’est intentionnel — c’est tout l’intérêt du BYOK.

Cette capacité est particulièrement pertinente pour les secteurs réglementés. Une société de services financiers soumise à DORA peut démontrer aux régulateurs qu’elle conserve la capacité de rendre toutes les données de collaboration inaccessibles si nécessaire. Une organisation de soins de santé peut s’assurer que les communications adjacentes aux patients sont contrôlées de manière cryptographique. Un organisme gouvernemental peut faire respecter les politiques de cycle de vie des données par la gestion des clés plutôt qu’en faisant confiance aux processus de suppression d’un fournisseur.

BYOK et fonctionnalités IA

Les fonctionnalités IA de Mandraki — transcription, résumé, réponses intelligentes et analyse d’enregistrements — nécessitent un accès côté serveur au texte en clair. Lorsqu’une organisation BYOK utilise des fonctionnalités IA, le pipeline de traitement déchiffre les données à l’aide de la hiérarchie de clés de l’organisation, les traite via nos modèles IA (qui s’exécutent entièrement au sein de l’infrastructure de l’UE), et chiffre à nouveau les résultats avec la DEK de l’organisation.

Toutefois, les organisations BYOK sont automatiquement limitées à la conservation transitoire des données IA. Cela signifie que le texte en clair n’existe en mémoire que pendant le traitement et n’est pas persisté sur disque. Les sorties générées par l’IA (transcriptions, résumés) sont chiffrées avec les clés de l’organisation avant le stockage, ce qui garantit qu’elles relèvent de la même protection BYOK que les données sources.

Si l’organisation révoque ultérieurement sa clé BYOK, les sorties IA chiffrées deviennent inaccessibles avec tout le reste.

Rotation des clés

BYOK ne signifie pas clés statiques. Les organisations doivent faire tourner leurs clés régulièrement, et Mandraki le prend en charge via un processus simple.

Lorsqu’une Org Key est tournée, une nouvelle Org Key est générée et encapsulée avec la Master Key actuelle (ou la clé BYOK). Les DEK existantes sont réencapsulées avec la nouvelle Org Key. L’ancienne Org Key est marquée comme tournée et conservée sous forme encapsulée pour l’accès aux données historiques. Les nouvelles données utilisent de nouvelles DEK encapsulées avec la nouvelle Org Key.

Le processus de rotation est non perturbateur. Les utilisateurs ne subissent aucune interruption et les données historiques restent accessibles via la chaîne de clés conservée.

Qui devrait utiliser BYOK

BYOK ajoute une complexité opérationnelle. Le client devient responsable de la disponibilité de la clé — si la clé est perdue et qu’il n’y a pas de sauvegarde, les données sont perdues définitivement. C’est une fonctionnalité, pas un bug, mais cela nécessite des pratiques matures de gestion des clés.

Nous recommandons le BYOK pour les organisations qui disposent d’équipes de sécurité dédiées avec une expérience de la gestion des clés, qui opèrent dans des secteurs réglementés où le contrôle cryptographique est une exigence de conformité, qui ont besoin de la capacité de couper l’accès à leurs données par moyen cryptographique, ou qui disposent d’un investissement existant dans des HSM ou une infrastructure de gestion des clés.

Pour les organisations qui n’ont pas besoin de ce niveau de contrôle, le chiffrement standard de Mandraki — où nous gérons la Master Key — offre une protection solide avec une charge opérationnelle moindre. Les deux modes utilisent le même chiffrement sous-jacent AES-256-GCM et la même hiérarchie de clés à trois couches. La seule différence est qui contrôle le sommet de l’arbre.