Que sont les clés gérées par le client (CMK) ?

Les clés gérées par le client (CMK) sont des clés de chiffrement que vous — et non le fournisseur de stockage ou de cloud — générez, détenez et contrôlez, et qui servent à chiffrer vos données au repos. Comme le cycle de vie de la clé vous appartient, le fournisseur conserve du texte chiffré qu'il ne peut pas lire sans une clé que vous fournissez et pouvez retirer.

La distinction essentielle est la suivante : le chiffrement au repos est quasi universel, mais qui contrôle la clé détermine qui peut réellement lire les données. « Chiffré » et « chiffré avec une clé que vous seul contrôlez » sont des garanties très différentes ; cette page traite de la seconde.

Clés gérées par le client ou par le fournisseur

Tout service de stockage chiffré utilise une clé ; la question est de savoir qui la détient.

• Les clés gérées par le fournisseur sont la valeur par défaut. Le fournisseur génère et conserve la clé et effectue le chiffrement à votre place. C'est pratique, et cela signifie qu'il peut déchiffrer vos données — et peut y être contraint.
• Les clés gérées par le client placent la clé sous votre contrôle : vous décidez de la rotation, de la politique d'accès et du moment de la révocation. Le fournisseur ne peut déchiffrer que tant que votre clé lui est accessible.

La conséquence pratique est la maîtrise de la divulgation. Avec des clés du fournisseur, une injonction adressée au fournisseur peut produire des données lisibles. Avec des clés du client, le fournisseur ne peut produire que du texte chiffré ; la copie lisible exige votre clé. Cette seule différence explique pourquoi les organisations réglementées traitent la détention des clés comme un contrôle de premier plan et non comme une case à cocher.

CMK, BYOK et HYOK

Ces sigles sont employés sans rigueur et décrivent un spectre selon le degré auquel la clé reste sous votre contrôle.

• CMK (clés gérées par le client) est le terme générique : vous gérez le cycle de vie de la clé — création, rotation, politique et révocation.
• BYOK (apportez votre propre clé) le précise : vous générez le matériel de clé dans votre propre KMS ou HSM et l'importez dans le service de clés du fournisseur, qui effectue ensuite les opérations cryptographiques au sein de son périmètre.
• HYOK (conservez votre propre clé) est le plus strict : la clé ne quitte jamais votre propre gestionnaire de clés. La plateforme du fournisseur appelle votre KMS externe pour déballer les données, de sorte que le matériel de clé demeure entièrement sous votre juridiction.

Plus de contrôle implique plus de responsabilité. HYOK offre la séparation la plus forte mais introduit une dépendance réelle : si votre gestionnaire de clés est injoignable, les données le sont aussi. Choisir entre eux est un compromis entre contrôle et résilience opérationnelle, non un simple « plus, c'est mieux ».

Comment fonctionnent les clés gérées par le client

Presque tout le chiffrement au repos utilise le chiffrement par enveloppe, et le comprendre rend le modèle CMK concret.

• Les données sont chiffrées avec une clé de chiffrement de données (DEK), générée par objet ou par volume.
• La DEK est elle-même chiffrée (« enveloppée ») par une clé de chiffrement de clés (KEK) — la clé que vous gérez.
• Pour lire les données, le système doit déballer la DEK à l'aide de la KEK ; si la KEK est dans votre KMS et indisponible, les données ne peuvent pas être déchiffrées.

Placer la KEK dans un système de gestion de clés que vous exploitez — atteint via un protocole standard tel que KMIP — vous donne trois leviers : la rotation (remplacer les clés selon un calendrier sans rechiffrer toutes les données), la politique d'accès (décider quels systèmes peuvent utiliser une clé) et la révocation. Révoquer ou détruire une clé rend définitivement illisibles les données qu'elle protégeait — ce que l'on appelle parfois le crypto-shredding — un moyen rapide et vérifiable de retirer des données ou d'isoler un système compromis.

Pourquoi les clés gérées par le client comptent

La détention des clés est le point où convergent plusieurs objectifs de sécurité et de conformité.

• Maîtrise de la divulgation. Si le fournisseur ne peut pas déchiffrer, une injonction ne produit que du texte chiffré, non des informations lisibles — le moment où le chiffrement prend son sens pour la souveraineté des données.
• Séparation des tâches. Aucune partie ne détient à la fois les données et le moyen de les lire, ce qui s'aligne sur les principes de confiance zéro et satisfait les auditeurs qui recherchent cette séparation.
• Risque interne et de chaîne d'approvisionnement. Un compte ou un administrateur du fournisseur compromis ne peut pas lire des données dont la clé se trouve dans votre KMS.
• Retrait vérifiable. Détruire la clé est un moyen net et démontrable de rendre les données irrécupérables sans traquer chaque copie.

Ce sont les raisons pour lesquelles les cadres de la finance, de la santé et du secteur public demandent de plus en plus non pas seulement si les données sont chiffrées, mais qui détient les clés.

Les clés gérées par le client et ARTESCA

Scality ARTESCA est conçu pour que la plateforme de stockage ne détienne jamais à la fois vos données et les clés pour les lire.

• AES-256 au repos. Les données sont chiffrées en AES-256, et le chiffrement peut être activé au niveau du bucket, de sorte que chaque objet du bucket est couvert.
• Clés hors du système. Les clés de chiffrement sont conservées dans un système externe de gestion de clés compatible KMIP, et non sur ARTESCA lui-même : aucune donnée d'authentification de chiffrement ne côtoie les données.
• Large prise en charge des KMS. Parce qu'ARTESCA parle le protocole standard KMIP, il fonctionne avec un large éventail de gestionnaires de clés tiers que vous exploitez déjà.
• Confiance zéro par conception. Séparer les clés du stockage signifie qu'aucun système ne détient les deux, renforçant la séparation des tâches décrite plus haut.

Le résultat est un chiffrement géré par le client que vous maîtrisez réellement : vous exploitez le gestionnaire de clés, vous définissez la rotation et la révocation, et les mêmes données peuvent être rendues immuables via S3 Object Lock, afin d'être à la fois confidentielles et protégées contre les rançongiciels.

FAQ sur les clés gérées par le client

Quelle est la différence entre les clés gérées par le client et par le fournisseur ?

Les clés du fournisseur sont générées et détenues par le fournisseur, qui peut donc déchiffrer vos données. Les clés du client sont contrôlées par vous — vous définissez la rotation, l'accès et la révocation — de sorte que le fournisseur ne peut déchiffrer que tant que votre clé lui est accessible.

CMK est-il la même chose que BYOK ?

Pas exactement. CMK est l'idée générale du client qui contrôle le cycle de vie de la clé. BYOK est un schéma précis où vous générez le matériel de clé et l'importez dans le service de clés du fournisseur. HYOK va plus loin en conservant la clé entièrement dans votre propre KMS.

Qu'est-ce que le chiffrement par enveloppe ?

Un schéma à deux niveaux où les données sont chiffrées avec une clé de chiffrement de données (DEK), et la DEK est chiffrée par une clé de chiffrement de clés (KEK) que vous gérez. Lire les données suppose de déballer la DEK avec la KEK : contrôler la KEK, c'est contrôler l'accès.

Que se passe-t-il si je perds ou révoque ma clé ?

Les données protégées par cette clé deviennent illisibles. C'est un risque à gérer par des sauvegardes et une discipline de rotation, mais c'est aussi une fonctionnalité : détruire une clé est un moyen rapide et vérifiable de rendre les données irrécupérables, ce que l'on appelle le crypto-shredding.

Le KMIP a-t-il de l'importance pour les clés gérées par le client ?

Oui. KMIP est un protocole standard de dialogue avec les gestionnaires de clés : un système de stockage qui le prend en charge peut utiliser le KMS que vous exploitez déjà plutôt que de vous enfermer dans le service de clés d'un seul fournisseur.