Hold Your Own Key (HYOK) expliqué : BYOK, HYOK ou clés du fournisseur, mise en œuvre dans Microsoft 365 DKE, AWS XKS et Google CSE, et comment choisir.
Hold Your Own Key (HYOK), ou « conserver ses propres clés », est un modèle de chiffrement cloud dans lequel les clés qui protègent vos données ne quittent jamais une infrastructure que vous contrôlez. Le fournisseur cloud ne stocke que des données chiffrées et doit demander à votre service de clés d'exécuter chaque opération cryptographique : si votre service de clés refuse, ou s'il est injoignable, le fournisseur ne peut pas lire les données. La disponibilité des clés devient la disponibilité des données.
C'est cette différence qui intéresse un conseil d'administration, un régulateur ou un délégué à la protection des données. Avec des clés gérées par le fournisseur comme avec le BYOK (bring your own key), le fournisseur détient une clé utilisable : il peut donc être contraint, compromis ou mal configuré au point de déchiffrer vos données. Avec HYOK, le déchiffrement exige une étape que vous seul pouvez accomplir. Les demandes légales adressées aux fournisseurs cloud, notamment au titre du CLOUD Act américain, sont l'une des raisons pour lesquelles « qui peut déchiffrer ? » est désormais une question d'achat.
Ce guide compare HYOK au BYOK et aux clés gérées par le fournisseur, montre comment Microsoft 365, AWS, Google Workspace, Salesforce, Snowflake et Oracle le mettent en œuvre (ou non), sur la base de la documentation de chaque éditeur, et se termine par un tableau de décision.
HYOK repose sur trois propriétés :
AWS emploie directement le terme : les opérations effectuées avec une clé KMS d'un magasin de clés externe « are performed by your external key manager using your cryptographic key material, a feature known as hold your own keys (HYOKs) » (sont exécutées par votre gestionnaire de clés externe avec votre matériel de clé cryptographique, une fonctionnalité appelée hold your own keys), et « your cryptographic key material never leaves your external key manager » (votre matériel de clé cryptographique ne quitte jamais votre gestionnaire de clés externe) (AWS KMS: External key stores).
Vous rencontrerez aussi CYOK (« control your own key ») dans la documentation commerciale des éditeurs. Ce n'est pas une catégorie normalisée : certains éditeurs l'utilisent comme terme générique pour toute clé contrôlée par le client, d'autres comme synonyme de HYOK. Pour comparer des offres HYOK, BYOK et CYOK, ignorez l'étiquette et demandez qui détient la clé à l'exécution et qui peut déchiffrer sans vous le demander.
Les modèles diffèrent moins par leurs algorithmes que par la garde des clés. Pour le BYOK seul, voir ce qu'est le BYOK (bring your own key) et comment il fonctionne.
| Clés gérées par le fournisseur | BYOK (bring your own key) | HYOK (hold your own key) | |
|---|---|---|---|
| Qui génère la clé | Le fournisseur cloud | Vous, puis importée dans le KMS du fournisseur ou créée dans celui-ci selon votre politique | Vous, dans votre propre gestionnaire de clés |
| Qui détient la clé à l'exécution | Le fournisseur | Le service du fournisseur, selon votre politique | Uniquement votre gestionnaire de clés ; le fournisseur détient des données chiffrées et des références de clés |
| Qui peut déchiffrer | Les services du fournisseur, de leur propre chef | Les services du fournisseur, avec la clé que vous avez autorisée | Les services du fournisseur, uniquement après que votre service de clés a exécuté l'opération |
| Effet d'une révocation | Non disponible pour vous | Le fournisseur cesse d'utiliser la clé ; les caches et processus de purge s'appliquent selon le service | Les nouveaux déchiffrements échouent dès que votre service refuse |
| Exposition aux demandes légales adressées au fournisseur | Le fournisseur peut produire les données en clair | Le fournisseur peut généralement produire les données en clair tant que la clé est active | Le fournisseur ne peut produire que des données chiffrées |
| Coût opérationnel | Le plus faible | Modéré : cycle de vie, rotation, politique d'accès | Le plus élevé : vous exploitez un service de clés hautement disponible et à faible latence |
| Fonctionnalités conservées | Toutes | Presque toutes (recherche, indexation, fonctions d'IA) | Réduites : le fournisseur ne peut pas traiter ce qu'il ne peut pas lire |
Le BYOK est un vrai progrès : vous maîtrisez le cycle de vie et pouvez révoquer. Mais comme le fournisseur utilise la clé au sein de son service, le BYOK ne change pas qui peut déchiffrer tant que la clé est active. HYOK le change, et vous le payez en responsabilité de disponibilité et en fonctionnalités perdues.
Presque toutes les mises en œuvre reposent sur le chiffrement d'enveloppe :
Votre service de clés se trouve sur le chemin de lecture : il applique la politique, conserve la piste d'audit et, s'il est indisponible, les données le sont aussi.
AWS ajoute un double chiffrement : AWS KMS chiffre d'abord avec du matériel de clé détenu par AWS, puis votre gestionnaire de clés externe chiffre le résultat, de sorte que « neither AWS KMS nor the owner of the external key material can decrypt double-encrypted ciphertext alone » (ni AWS KMS ni le propriétaire du matériel de clé externe ne peuvent déchiffrer seuls des données doublement chiffrées) (AWS KMS). Le Chiffrement à double clé de Microsoft suit la même logique : « deux clés, toutes deux nécessaires ».
Le Chiffrement à double clé (DKE) de Microsoft Purview « uses two keys to protect data; one key in your control and a second key you store securely in Microsoft Azure » (utilise deux clés pour protéger les données : une clé sous votre contrôle et une seconde que vous stockez de manière sécurisée dans Microsoft Azure), et l'affichage des données protégées « requires access to both keys » (nécessite l'accès aux deux clés). Vous hébergez le service DKE sur site ou dans le cloud (Microsoft Learn: Double Key Encryption). D'après la même page :
Étapes de déploiement : guide de configuration du Chiffrement à double clé Microsoft 365.
La Clé client (Customer Key) est un chiffrement de service sous des clés racines que vous contrôlez, couvrant Exchange, SharePoint, OneDrive, Teams et les PC cloud Windows 365. Microsoft est explicite sur l'utilisateur de la clé : « You explicitly authorize Microsoft 365 to use your encryption keys to deliver value-added services like eDiscovery, anti-malware, anti-spam, and search indexing » (vous autorisez explicitement Microsoft 365 à utiliser vos clés de chiffrement pour fournir des services à valeur ajoutée comme eDiscovery, l'anti-malware, l'anti-spam et l'indexation de recherche) (Microsoft Learn: Customer Key overview).
C'est du BYOK. Les services Microsoft 365 déchiffrent le contenu en fonctionnement normal, ce qui explique que toutes les fonctionnalités continuent de marcher, et chaque stratégie de chiffrement des données comprend une clé de disponibilité protégée par Microsoft. Votre contrôle s'exerce à la sortie : « Revoking access to your keys triggers deletion of the availability key, resulting in cryptographic deletion of your data » (la révocation de l'accès à vos clés déclenche la suppression de la clé de disponibilité, ce qui entraîne la suppression cryptographique de vos données). De nombreux programmes utilisent la Clé client à large échelle et DKE pour une petite fraction étiquetée ; voir DKE vs Microsoft 365 Customer Key.
Chaque clé KMS d'un magasin de clés externe correspond à une « clé externe » AES 256 bits dans votre gestionnaire de clés externe, accessible via un proxy XKS que vous fournissez ; « AWS KMS cannot create, delete, or manage any external keys » (AWS KMS ne peut ni créer, ni supprimer, ni gérer aucune clé externe). Les applications utilisent les mêmes API KMS, et les services AWS qui prennent en charge les clés symétriques gérées par le client prennent en charge les clés XKS (AWS KMS). AWS documente lui-même les compromis :
Détails : guide de mise en œuvre d'AWS XKS.
Le CSE de Workspace chiffre le contenu dans le client avec une DEK, puis envoie cette DEK à votre service de clés externe (le Key Access Control List Service, KACLS) pour qu'elle soit chiffrée ; votre fournisseur d'identité authentifie d'abord les utilisateurs (Google Workspace CSE API overview). Google indique que « Google servers and third parties can't access your encryption keys and decrypt your data » (les serveurs de Google et les tiers ne peuvent pas accéder à vos clés de chiffrement ni déchiffrer vos données). La couverture comprend les fichiers Drive et des éditeurs Docs, le corps et les pièces jointes des messages Gmail, les descriptions d'événements Agenda, ainsi que l'audio, la vidéo et le chat de Meet ; les en-têtes Gmail et les titres, horaires et participants des événements Agenda ne sont pas chiffrés (Google: Protect your organization's data with CSE). Éditions : Frontline Plus, Enterprise Plus, Education Standard et Education Plus (Google: About client-side encryption).
Le Cache-Only Key Service permet de « store your key material outside of Salesforce and have the Cache-Only Key Service fetch your key on demand from a key service that you control » (stocker votre matériel de clé hors de Salesforce et laisser le Cache-Only Key Service récupérer votre clé à la demande auprès d'un service de clés que vous contrôlez), et « Salesforce doesn't retain or persist your cache-only keys in any system of record or backups » (Salesforce ne conserve ni ne persiste vos clés en cache uniquement dans aucun système d'enregistrement ni aucune sauvegarde). Les clés sont des clés AES 256 bits, encapsulées en JSON Web Encryption et récupérées via un appel sortant (callout) avec identifiants nommés (named credential) ; le cache chiffré est vidé au moins toutes les 72 heures. Le service nécessite Salesforce Shield ou Shield Platform Encryption, plus le Cache-Only Key Service (Salesforce Platform Encryption Implementation Guide).
Pour être précis : la clé est utilisée dans Salesforce tant qu'elle est en cache, ce n'est donc pas du HYOK au sens strict de XKS. Ce que vous détenez, c'est l'interrupteur : détruisez la clé et « related data isn't accessible » (les données associées ne sont plus accessibles) jusqu'à ce que vous la réactiviez.
Tri-Secret Secure « combines a Snowflake-maintained key and a customer-managed key (CMK) » (combine une clé gérée par Snowflake et une clé gérée par le client, CMK) en une clé maîtresse composite. Il nécessite l'édition Business Critical ou supérieure, et si la CMK est révoquée, Snowflake ne peut plus déchiffrer vos données (Snowflake: Tri-Secret Secure). Par défaut, la CMK réside dans le KMS de la plateforme cloud qui héberge votre compte, et vous « must release this key to decrypt data stored in your Snowflake account » (devez libérer cette clé pour déchiffrer les données stockées dans votre compte Snowflake) (Snowflake: Encryption key management).
En toute honnêteté, il s'agit de BYOK avec un bouton d'arrêt d'urgence : Snowflake utilise votre clé tant que vous l'y autorisez. Pour les comptes hébergés sur AWS, Snowflake documente un magasin de clés externe derrière la CMK, ce qui rapproche la racine du modèle HYOK ; vérifiez la liste actuelle des gestionnaires de clés testés par Snowflake. Mise en place : guide Snowflake Tri-Secret Secure.
Dans le chiffrement transparent des données (TDE) d'Oracle, « the TDE master encryption key protects the TDE table keys and tablespace encryption keys » (la clé de chiffrement maîtresse TDE protège les clés de table TDE et les clés de chiffrement des tablespaces) (Oracle: Configuring TDE). Déplacer la clé maîtresse hors de l'hôte de la base de données vous donne un contrôle de type HYOK, où que la base s'exécute. Les keystores externes pris en charge par Oracle sont Oracle Key Vault et OCI Vault. La valeur HSM de TDE_CONFIGURATION configure toujours un module de sécurité matériel, mais la documentation de référence d'Oracle indique que « Oracle does not support the use of HSMs for TDE key management » (Oracle ne prend pas en charge l'utilisation de HSM pour la gestion des clés TDE) et renvoie à la note My Oracle Support KB593570 (Oracle: TDE_CONFIGURATION). Lisez cette note avant la mise en production. Pas à pas : guide Oracle TDE avec keystore externe.
| Option de plateforme | Où opère la clé du client | Modèle |
|---|---|---|
| Microsoft 365 Chiffrement à double clé | Votre service DKE ; Microsoft détient la seconde clé | HYOK |
| Microsoft 365 Clé client | Utilisée par les services Microsoft 365 ; Microsoft protège aussi une clé de disponibilité | BYOK |
| Magasin de clés externe AWS KMS | Votre gestionnaire de clés externe, via votre proxy XKS | HYOK |
| Google Workspace CSE | Votre service de clés externe (KACLS) | HYOK |
| Salesforce Cache-Only Key Service | Hébergée par vous ; récupérée et mise en cache chiffrée par Salesforce, non persistée | Entre BYOK et HYOK |
| Snowflake Tri-Secret Secure | Votre CMK combinée à une clé Snowflake | BYOK (plus proche du HYOK avec un magasin de clés externe) |
| Oracle TDE, keystore externe | Clé maîtresse dans le keystore externe | Clé maîtresse détenue par le client (vérifier la position d'Oracle sur la prise en charge des HSM) |
Partez de la classe de données et de la menace, pas du produit. Il s'agit d'une aide à la planification, pas d'un avis juridique ; savoir si un modèle satisfait une loi ou un contrat donné relève de votre conseil juridique.
| Classe de données | Menace principale | Modèle suggéré |
|---|---|---|
| Données publiques et données métier courantes | Exposition accidentelle, vol de disques | Clés gérées par le fournisseur |
| Données personnelles ou financières réglementées nécessitant toutes les fonctionnalités de productivité | Perte de contrôle sur le cycle de vie des clés ; besoin de réversibilité et de suppression cryptographique | BYOK (p. ex. Microsoft 365 Clé client, Snowflake Tri-Secret Secure) |
| Données les plus sensibles : fusions-acquisitions, documents du conseil d'administration, secrets d'affaires | Accès par un initié du fournisseur ou compromission du fournisseur | HYOK (DKE, Google CSE, AWS XKS) |
| Données que le fournisseur ne doit pas pouvoir produire dans le cadre d'une procédure judiciaire étrangère | Demandes adressées au fournisseur, p. ex. au titre du CLOUD Act américain | HYOK, avec des clés confiées à un opérateur et sous une juridiction que vous choisissez |
| Bases de données que vous exploitez vous-même | Vol de fichiers de base de données, de sauvegardes ou d'hôtes | Clé maîtresse dans un keystore externe (p. ex. Oracle TDE) |
Pourquoi la ligne CLOUD Act compte : le Département de la Justice des États-Unis explique que la loi couvre les données « within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States » (en la possession, sous la garde ou sous le contrôle de ce fournisseur, que ces communications, enregistrements ou autres informations se trouvent aux États-Unis ou en dehors), et qualifie la loi de « encryption neutral » (neutre vis-à-vis du chiffrement) (DOJ white paper: The Purpose and Impact of the CLOUD Act). La localisation des données ne répond pas à elle seule à la question ; c'est le fait que le fournisseur détienne ou non la clé qui y répond.
DuoKey fournit le service de clés côté client pour ces options de plateforme, à partir d'une seule couche de gestion des clés. DuoKey KMS fractionne les clés grâce au calcul multipartite (MPC), de sorte qu'aucun fournisseur cloud, aucun opérateur et aucun hôte compromis ne détient une clé complète.
Pour l'emplacement de déploiement, la conception de la disponibilité ou les certifications, contactez DuoKey.
Q: Qu'est-ce que Hold Your Own Key (HYOK) ?
Hold Your Own Key est un modèle de chiffrement cloud dans lequel les clés de chiffrement restent dans un gestionnaire de clés que vous contrôlez, et le fournisseur cloud doit demander à ce gestionnaire d'exécuter chaque opération d'encapsulation ou de désencapsulation. Le fournisseur ne stocke que des données chiffrées et ne peut donc pas déchiffrer sans votre service de clés. Révoquez l'accès et les données deviennent illisibles pour le fournisseur.
Q: Quelle est la différence entre BYOK et HYOK ?
Avec le BYOK, vous êtes propriétaire de la clé, mais le service du fournisseur l'utilise pour déchiffrer vos données en fonctionnement normal. Avec HYOK, la clé ne quitte jamais votre infrastructure et le fournisseur ne peut que lui demander d'exécuter des opérations. Le BYOK donne le contrôle du cycle de vie et la révocation ; HYOK retire en plus au fournisseur la capacité de déchiffrer de son propre chef, au prix d'une responsabilité de disponibilité et de certaines fonctionnalités.
Q: Microsoft 365 prend-il en charge HYOK ?
Oui, via le Chiffrement à double clé de Microsoft Purview. DKE protège le contenu étiqueté avec deux clés, l'une dans votre service DKE et l'autre dans Microsoft Azure, et les deux sont nécessaires pour l'ouvrir. Il fonctionne dans Microsoft 365 Apps for enterprise sous Windows et est inclus dans Microsoft 365 E5 ; le contenu protégé ne peut pas être recherché, coédité sur le web ni utilisé par Copilot.
Q: La Clé client Microsoft 365 est-elle du HYOK ?
Non. La Clé client (Customer Key) est un chiffrement de service sous des clés racines que vous contrôlez, c'est-à-dire un modèle BYOK. Microsoft indique que vous autorisez Microsoft 365 à utiliser vos clés pour eDiscovery, l'anti-malware, l'anti-spam et l'indexation de recherche. Son principal levier de contrôle est la révocation, qui entraîne la suppression cryptographique de vos données.
Q: Que signifient HYOK, BYOK et CYOK ?
BYOK : vous fournissez la clé et le fournisseur l'utilise. HYOK : vous conservez la clé et le fournisseur lui demande d'exécuter des opérations. CYOK (« control your own key ») n'est pas normalisé : demandez donc qui détient la clé à l'exécution et qui peut déchiffrer sans votre accord.
Q: Que se passe-t-il si mon service de clés HYOK tombe en panne ?
Les nouveaux déchiffrements échouent, si bien que les données protégées sont indisponibles pour le service cloud jusqu'au rétablissement du service de clés. Certains services mettent brièvement en cache les clés de données. Les services de clés HYOK ont donc besoin de redondance, de supervision et d'un plan de reprise testé.
Q: HYOK protège-t-il contre le CLOUD Act ?
HYOK change ce qu'un fournisseur peut techniquement produire : sans clé utilisable, il ne peut remettre que des données chiffrées. Le Département de la Justice des États-Unis qualifie la loi de neutre vis-à-vis du chiffrement. Savoir si HYOK satisfait une exigence légale précise relève de votre conseil juridique.
Optez pour Hold Your Own Key lorsque la question n'est pas « mes données sont-elles chiffrées ? » mais « qui peut les déchiffrer ? ». Le BYOK couvre la plupart des charges de travail réglementées ; HYOK est réservé à la fraction que le fournisseur lui-même ne doit pas pouvoir lire.
Écrit par
DuoKey Team
Ressources associées
Dites-nous où le contrôle est difficile aujourd’hui. Nous vous aiderons à définir une prochaine étape concrète.
