Fonctionnement d'AWS KMS External Key Store (XKS) : proxy, étapes CLI, limites de 250 ms et 35 ms, codes d'erreur, et quand préférer XKS à CloudHSM.
AWS External Key Store (XKS) est un magasin de clés personnalisé d'AWS KMS, adossé à un gestionnaire de clés que vous exploitez hors d'AWS. Les services AWS continuent d'appeler AWS KMS comme d'habitude, mais chaque chiffrement et déchiffrement sous une clé XKS nécessite aussi votre clé externe, atteinte via un proxy XKS que vous opérez. AWS KMS ne peut ni créer, ni voir, ni supprimer cette clé, et si vous déconnectez le proxy, AWS ne peut plus déchiffrer les données (AWS KMS Developer Guide).
Ce contrôle a un prix : de la complexité et un transfert de responsabilité opérationnelle. Ce guide explique ce qu'est le magasin de clés externe AWS, si vous en avez besoin, comment configurer pas à pas le proxy XKS et le magasin de clés, les limites de latence et de disponibilité fixées par AWS, les codes d'erreur que vous rencontrerez et ce que cela coûte au-delà de la facture KMS.
AWS External Key Store (XKS) est une fonctionnalité d'AWS Key Management Service (KMS) qui vous permet d'utiliser des clés de chiffrement générées, stockées et gérées entièrement en dehors de l'infrastructure AWS -- dans le matériel ou les logiciels que vous possédez et contrôlez.
Annoncé lors de re:Invent 2022 et désormais une fonctionnalité mature, XKS comble une lacune spécifique : les organisations qui ont besoin de l'étendue des services AWS mais ne peuvent pas, par réglementation ou politique, autoriser leurs clés racine cryptographiques à résider sur l'infrastructure AWS.
Sous AWS KMS standard, Amazon gère les éléments clés au sein de sa propre infrastructure sécurisée. Vous contrôlez l'accès aux clés, mais les clés elles-mêmes résident dans AWS. XKS inverse cela : vos clés résident dans votre infrastructure et AWS les appelle lorsqu'il doit effectuer des opérations cryptographiques.
| Terme | Définition |
|---|---|
| Magasin de clés externe (XKS) | Un magasin de clés personnalisé soutenu par votre gestionnaire de clés externe |
| Proxy XKS | Middleware géré par le client qui traduit les appels d'API KMS en protocole de votre gestionnaire de clés |
| Gestionnaire de clés externe | Votre HSM, logiciel KMS ou plateforme de gestion de clés en dehors d'AWS |
| XksKeyId | L'identifiant de votre clé externe, lié à une clé KMS |
| Double chiffrement | Les données sont d'abord chiffrées par AWS KMS, puis à nouveau par votre gestionnaire de clés externe |
Une précision qui surprend de nombreux architectes : XKS utilise le double chiffrement. Chaque clé KMS adossée à XKS a deux clés sous-jacentes : un matériel de clé AWS KMS généré dans les HSM d'AWS KMS, et votre clé externe. Les données sont chiffrées avec la première, puis le résultat est chiffré avec la seconde. Un texte chiffré protégé par XKS est donc toujours au moins aussi robuste qu'un texte chiffré KMS standard, et ni AWS KMS ni le détenteur de la clé externe ne peuvent le déchiffrer seuls (AWS : double chiffrement).
(AWS KMS Developer Guide : External key stores)
Comprendre le flux de requêtes est essentiel avant de vous engager dans XKS. Chaque opération de chiffrement ou de déchiffrement suit ce chemin :
Tout cet aller-retour se déroule de manière synchrone. La spécification de l'API du proxy indique que si KMS ne reçoit pas de réponse du proxy XKS en 250 ms, l'appel expire, et elle demande une latence ping de 35 ms au plus entre la Région AWS et votre gestionnaire de clés (XKS Proxy API Specification). Si une étape de la chaîne échoue, l'opération KMS échoue, et selon le service AWS, cet échec peut se répercuter.
La clé de données en clair n'est jamais envoyée au proxy : AWS KMS envoie le texte chiffré produit avec son propre matériel de clé, et c'est ce texte que votre gestionnaire de clés chiffre.
C'est là que de nombreuses organisations sous-estiment XKS. Sous KMS standard, AWS gère la disponibilité, l'application de correctifs, la mise à l'échelle et la reprise après sinistre de l'infrastructure clé. Sous XKS, vous prenez en charge tout cela pour votre proxy et votre gestionnaire de clés externe, y compris les couches physiques, d'alimentation, de refroidissement, de réseau, de système d'exploitation et d'application.
Si votre gestionnaire de clés externe tombe en panne, les services AWS reposant sur des clés XKS ne peuvent ni chiffrer ni déchiffrer. Il ne s'agit pas d'un mode de défaillance hypothétique : il s'agit du comportement attendu, et il est de votre responsabilité de concevoir des solutions en conséquence.
Avant d'investir dans XKS, comparez-le honnêtement aux alternatives.
Avec les clés CMK (Customer-Managed Keys) standard, vous contrôlez les politiques et les accès des clés : qui peut utiliser la clé, dans quelles conditions, avec une journalisation d'audit complète. AWS détient toujours les éléments clés dans sa propre infrastructure KMS.
Utilisez les clés CMK lorsque : vous avez besoin d'un contrôle d'accès et d'une auditabilité forts, mais vos exigences de conformité n'exigent pas que les éléments clés résident en dehors d'AWS.
Utilisez XKS lorsque : les réglementations ou les politiques organisationnelles exigent explicitement que les clés cryptographiques ne résident jamais sur une infrastructure tierce (c'est-à-dire AWS).
CloudHSM vous propose des modules de sécurité matérielle dédiés et à locataire unique dans les centres de données AWS. Vous contrôlez le HSM, ses utilisateurs et ses clés : AWS n'a pas accès aux clés. Cependant, les HSM eux-mêmes se trouvent physiquement dans des installations appartenant à AWS.
| XKS | CloudHSM | |
|---|---|---|
| Emplacement clé | Votre infrastructure | Centre de données AWS (HSM dédié) |
| Accès physique AWS | Aucun | Pas d'accès au contenu HSM, mais le matériel se trouve dans les locaux d'AWS |
| Latence | Supérieur (aller-retour externe) | Inférieur (au sein du réseau AWS) |
| Responsabilité de disponibilité | Entièrement vôtre | Partagé (AWS gère le matériel ; vous gérez le logiciel HSM) |
| Coût | Tarif des clés KMS, plus votre gestionnaire de clés, le proxy et le réseau | Facturé par HSM et par heure, plus le tarif des clés KMS |
| Adéquation conformité | Exigences de souveraineté strictes | Exigences de HSM dédiés et validés |
| Complexité | Très élevé | Élevé |
Choisissez CloudHSM si vous avez besoin de HSM dédiés et mono-locataires et pouvez tolérer des clés résidant physiquement dans AWS. Choisissez XKS uniquement si votre exigence de conformité impose explicitement que les clés restent entièrement en dehors des installations appartenant à AWS. Pour comparer les deux types de magasins de clés personnalisés, voir AWS KMS custom key store : CloudHSM vs XKS.
Pour la majorité des charges de travail, y compris la plupart des exigences HIPAA, PCI-DSS et SOC 2, les clés KMS standard gérées par le client sont suffisantes. XKS est spécialement conçu pour l'ensemble restreint de réglementations (certaines exigences de souveraineté des données de l'UE, règles spécifiques du secteur financier, mandats du gouvernement américain) qui exigent explicitement qu'aucun fournisseur de cloud n'ait accès aux éléments clés en aucune circonstance.
Posez ces trois questions dans l'ordre :
XKS existe pour un scénario de conformité spécifique, et non pour une amélioration générale de la sécurité. Voici les cas d'utilisation légitimes :
Souveraineté des données réglementaires, Des réglementations telles que le RGPD (complétées par l'arrêt Schrems II) exigent que les organisations de l'UE soient en mesure de prouver que les clés de chiffrement ne quittent jamais leur juridiction contrôlée et de révoquer l'accès du fournisseur de cloud à tout moment. XKS répond à cet objectif en plaçant les clés dans une infrastructure basée dans l'UE en dehors d'AWS.
Atténuation de l'exposition au CLOUD Act, Les organisations préoccupées par le US CLOUD Act (qui permet aux forces de l'ordre américaines d'obliger les fournisseurs de cloud américains à produire des données) utilisent XKS pour garantir qu'AWS ne puisse pas accéder aux éléments clés sous la contrainte. Votre gestionnaire de clés externe, dans une juridiction distincte, en détient la seule copie.
Mandats de services financiers, Certaines réglementations des banques centrales et cadres de surveillance du secteur financier exigent des dispositions de « résilience opérationnelle » qui incluent le maintien du contrôle du matériel cryptographique externe au fournisseur de cloud principal.
Charges de travail du gouvernement et de la défense, Les agences fédérales américaines traitant des CUI (Controlled Unclassified Information) ou des données classifiées dans le cadre des cadres FedRAMP High ou DoD IL peuvent avoir des exigences explicites en matière de conservation des clés.
Architecture de clé zéro confiance : organisations mettant en œuvre des modèles stricts de confiance zéro dans lesquels aucun fournisseur unique n'a un accès complet aux données et aux clés.
À quoi XKS n'est-il pas destiné : renforcement général de la sécurité, mise en conformité HIPAA (le KMS standard est suffisant), réduction de la dépendance vis-à-vis du fournisseur AWS pour des raisons non cryptographiques ou économie d'argent. C'est plus cher et plus complexe que toutes les alternatives.
Avant de commencer la mise en œuvre, validez tous ces éléments.
Votre gestionnaire de clés externe doit :
Le gestionnaire de clés externe peut être un HSM physique, un HSM virtuel ou un gestionnaire de clés logiciel avec ou sans composant HSM, sur site ou dans n'importe quel cloud (AWS). Les options pour le proxy placé devant lui sont comparées dans Options de proxy XKS.
XKS prend en charge deux modèles de connectivité :
Connectivité des points de terminaison publics : AWS KMS atteint votre proxy sur Internet via HTTPS. Plus simple à configurer, mais expose votre point de terminaison proxy à l'Internet public. Acceptable uniquement avec une authentification mTLS robuste.
Connectivité du service de point de terminaison VPC : AWS KMS se connecte via un service de point de terminaison VPC AWS PrivateLink que vous créez et gérez. Cela maintient le trafic hors de l'Internet public et constitue l'approche recommandée pour les charges de travail de production.
Votre mandataire doit être joignable avec :
/kms/xks/v1 (ou un préfixe se terminant par ce chemin)Configurez le gestionnaire de clés de votre choix pour générer et stocker les clés AES-256. Notez l'ID de clé externe (XksKeyId) pour chaque clé que vous prévoyez d'utiliser : vous y ferez référence lors de la création de clés KMS.
Assurez-vous que votre gestionnaire de clés est déployé avec une haute disponibilité. Au minimum : basculement actif-passif. Pour la production : actif-actif sur deux ou plusieurs nœuds indépendants.
Votre proxy est l'élément essentiel. Options de déploiement :
Connexion d'un proxy sur site via un point de terminaison public : Le proxy s'exécute dans votre centre de données, exposé via un point de terminaison HTTPS public. À utiliser uniquement si la connectivité VPC n'est pas viable.
Proxy sur EC2 au sein d'un VPC (recommandé) : Déployez le proxy sur une instance EC2 dans un sous-réseau privé. Créez un service de point de terminaison VPC pointé sur un Network Load Balancer devant votre proxy. AWS KMS se connecte via PrivateLink.
Connexion d'un proxy sur site via VPC : Exécutez le proxy sur site, mais connectez-le à un service de point de terminaison d'un VPC via un VPN site à site ou une connexion directe. Sécurité maximale, complexité maximale.
Pour une haute disponibilité, déployez des instances proxy sur plusieurs zones de disponibilité derrière un équilibreur de charge réseau.
L'authentification entre KMS et votre proxy utilise un identifiant d'authentification de proxy SigV4 : un ID de clé d'accès et une clé d'accès secrète que vous configurez à la fois sur le proxy et dans KMS. Ne réutilisez jamais d'identifiants IAM pour cela. AWS recommande que le proxy accepte au moins deux identifiants valides, pour pouvoir les renouveler sans interruption, et publie la métrique CloudWatch XksProxyCredentialAge pour suivre leur âge (AWS).
Créez le magasin de clés externe à l'aide de l'AWS CLI :
# Create external key store with VPC endpoint service connectivity
aws kms create-custom-key-store \
--custom-key-store-name "MyExternalKeyStore" \
--custom-key-store-type EXTERNAL_KEY_STORE \
--xks-proxy-connectivity "VPC_ENDPOINT_SERVICE" \
--xks-proxy-uri-endpoint "https://myproxy-private.xks.example.com" \
--xks-proxy-uri-path "/kms/xks/v1" \
--xks-proxy-vpc-endpoint-service-name "com.amazonaws.vpce.us-east-1.vpce-svc-0example" \
--xks-proxy-authentication-credential \
AccessKeyId=ABCDE12345670EXAMPLE,RawSecretAccessKey=supersecretkeyvalue
Connectez le magasin de clés :
aws kms connect-custom-key-store \
--custom-key-store-id cks-1234567890abcdef0
Vérifiez l'état de la connexion :
aws kms describe-custom-key-stores \
--custom-key-store-id cks-1234567890abcdef0
Une réponse saine affiche "ConnectionState": "CONNECTED".
aws kms create-key \
--custom-key-store-id cks-1234567890abcdef0 \
--xks-key-id "your-external-key-id" \
--description "XKS-backed key for S3 bucket encryption" \
--key-usage ENCRYPT_DECRYPT
Attachez une stratégie de clé qui accorde l'accès aux services et aux mandataires qui doivent utiliser la clé :
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Enable KMS key administration",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/KeyAdminRole"
},
"Action": [
"kms:Create*",
"kms:Describe*",
"kms:Enable*",
"kms:List*",
"kms:Put*",
"kms:Update*",
"kms:Revoke*",
"kms:Disable*",
"kms:Get*",
"kms:Delete*"
],
"Resource": "*"
},
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/AppRole"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
}
]
}
Testez explicitement la connexion avant d'utiliser le magasin de clés en production :
# Test encrypt/decrypt round-trip
aws kms generate-data-key \
--key-id "arn:aws:kms:us-east-1:123456789012:key/your-key-id" \
--key-spec AES_256
Testez les scénarios de basculement : mettez votre proxy hors ligne et confirmez que les services AWS gèrent l'échec correctement et récupèrent au retour du proxy. Ne sautez jamais ce test lors de la mise en scène.
Le proxy mérite une attention particulière car il constitue la source la plus courante de problèmes de mise en œuvre.
Le proxy implémente la AWS KMS External Key Store Proxy API Specification, une API REST sur HTTPS avec quatre opérations :
| API du proxy | Ce que demande AWS KMS | Déclenchée par |
|---|---|---|
GetKeyMetadata | Type (AES_256), usage et état de la clé externe | CreateKey |
Encrypt | Chiffrer avec la clé externe (AES-GCM) | Encrypt, GenerateDataKey, ReEncrypt |
Decrypt | Déchiffrer avec la clé externe (AES-GCM) | Decrypt, ReEncrypt |
GetHealthStatus | État du proxy et du gestionnaire de clés : Active, Degraded ou Unavailable | Création ou connexion du magasin de clés |
requestMetadata valide contenant l'ARN principal AWS et l'ARN de la clé KMS, cela vous permet d'implémenter une autorisation supplémentaire au niveau de la couche proxy au-delà d'IAM.AWS fournit une implémentation de référence open source dans Rust, exécutable en tant que conteneur, compatible avec n'importe quel HSM PKCS#11. Il s'agit d'un point de départ raisonnable pour les organisations utilisant des gestionnaires de clés non pris en charge par le fournisseur.
Pour une utilisation en production, ajoutez :
Chaque appel KMS pour une clé sauvegardée par XKS implique un aller-retour sur le réseau externe. Pour les charges de travail générant des milliers de requêtes KMS par seconde, cela s'additionne. AWS met en cache les clés de données au niveau du service (par exemple, S3 met en cache les clés de données pendant quelques minutes lorsque les clés de compartiment sont activées), ce qui réduit le volume de requêtes brutes adressées à votre proxy, mais vous devez toujours planifier la capacité en cas de charge de pointe.
Testez votre proxy sous une charge réaliste avant la mise en production. Les erreurs XKS_PROXY_TIMED_OUT indiquent que votre proxy est trop lent ; XKS_PROXY_INVALID_RESPONSE indique un problème de protocole. AWS publie aussi un client de test qui vérifie la conformité d'un proxy à la spécification.
Chaque magasin de clés externe AWS a besoin d'exactement un proxy XKS. AWS permet de le développer à partir de la spécification ouverte ou de l'acheter à un fournisseur, et le proxy peut faire partie du gestionnaire de clés lui-même (AWS).
| Option | Ce que vous obtenez | Ce que vous exploitez |
|---|---|---|
| Proxy d'exemple AWS (aws-kms-xks-proxy) | Implémentation de référence open source en Rust, qui parle PKCS#11 à un HSM | Le proxy, sa haute disponibilité, TLS, les identifiants, la journalisation et le HSM derrière |
| Proxy d'un fournisseur de HSM ou de gestion de clés | Un proxy intégré à l'appliance ou au service du fournisseur. Thales (CipherTrust), Fortanix, Entrust et Securosys publient des intégrations XKS | L'appliance ou le cluster du fournisseur, ou son service hébergé |
| DuoKey XKS Proxy | Intégré à DuoKey Cockpit ; chaque point de terminaison est lié à un coffre et à une clé AES-256 | Rien à installer ; voir ci-dessous |
Questions à poser à tout fournisseur avant de choisir :
requestMetadata (principal appelant, ARN de la clé KMS), en plus d'IAM ?DuoKey pour AWS XKS implémente la spécification du proxy XKS comme une fonction intégrée de DuoKey Cockpit. Il n'y a pas de proxy séparé à installer : vous déployez un point de terminaison XKS depuis la même interface Cockpit que vos autres applications et clés, et chaque point de terminaison est lié au coffre et à la clé que vous choisissez (DuoKey docs : AWS XKS).
Pour choisir entre détenir la clé vous-même et laisser le fournisseur la détenir, voir Hold Your Own Key (HYOK).
Utilisez la connectivité du service de point de terminaison d'un VPC : n'exposez jamais votre point de terminaison proxy publiquement, sauf en cas d'absolue nécessité. La configuration supplémentaire de PrivateLink vaut la surface d'attaque réduite.
Implémenter l'autorisation au niveau du proxy, les requestMetadata dans chaque requête KMS incluent l'ARN du principal appelant. Utilisez-le pour appliquer des politiques granulaires au niveau de la couche proxy : des rôles IAM spécifiques ne peuvent utiliser que des clés externes spécifiques, certaines opérations sont bloquées en dehors des heures de bureau, etc.
Faites pivoter les informations d'authentification du proxy selon un calendrier défini. Utilisez AWS Secrets Manager pour stocker et faire pivoter automatiquement la clé d'accès secrète utilisée pour l'authentification KMS vers proxy.
Surveillez et alertez sur toutes les erreurs de proxy, surveillez spécifiquement les erreurs XKS_PROXY_TIMED_OUT, XKS_PROXY_NOT_REACHABLE et INVALID_KEY_USAGE dans CloudTrail. Tout taux d'erreur soutenu devrait déclencher une réponse à l'incident.
Gestion du cycle de vie des clés : documentez les procédures explicites pour la rotation des clés (votre gestionnaire de clés externe peut faire pivoter le matériau de clé derrière le même XksKeyId), la suppression de clé (coordonnée entre la suppression de clé KMS et la suppression de clé externe - un ordre erroné entraîne une perte permanente de données) et la révocation de clé d'urgence (votre proxy est le kill switch : mettez-le hors ligne et toutes les opérations XKS cessent).
Reprise après sinistre : maintenez un runbook de récupération testé. Si votre gestionnaire de clés externe subit une panne catastrophique, vous devez le restaurer et vous reconnecter avant que les données chiffrées avec les clés XKS ne deviennent définitivement inaccessibles. Sauvegardez vos clés externes à l'aide des mécanismes de sauvegarde natifs de votre gestionnaire de clés.
XKS_PROXY_NOT_REACHABLE, KMS ne peut pas atteindre le point de terminaison du proxy. Vérifiez : le routage réseau, les règles du groupe de sécurité, les vérifications de l'état NLB, l'état du processus proxy.
XKS_PROXY_TIMED_OUT, Proxy accessible mais ne répondant pas dans le délai imparti. Vérifiez : les journaux des applications proxy, la latence du gestionnaire de clés externe, le processeur/la mémoire de l'instance proxy, la latence du réseau entre le proxy et le gestionnaire de clés. Si le temps aller-retour entre la Région et votre gestionnaire de clés dépasse 35 ms, AWS suggère de créer le magasin dans une Région plus proche ou de rapprocher le gestionnaire de clés d'AWS.
XKS_PROXY_INVALID_RESPONSE, Le proxy a répondu mais la réponse n'est pas conforme à la spécification de l'API XKS. Vérifiez l'implémentation du proxy pour déceler les incompatibilités de version de l'API ou les bogues de sérialisation.
XKS_PROXY_ACCESS_DENIED, Incompatibilité d'informations d'identification entre la configuration KMS et proxy. Vérifiez que AccessKeyId et RawSecretAccessKey correspondent exactement des deux côtés. Les informations d'identification sont sensibles à la casse.
XksKeyNotFoundException, Le XksKeyId transmis à CreateKey n'existe pas dans votre gestionnaire de clés externe, ou le proxy ne le trouve pas. Vérifiez qu'il s'agit bien de l'identifiant que le proxy utilise pour cette clé.
XksKeyInvalidConfigurationException, GetKeyMetadata a renvoyé une clé qui n'est pas AES_256, pas utilisable pour [ENCRYPT, DECRYPT], ou DISABLED dans le gestionnaire de clés externe. Ceci est indépendant de l'état de la clé KMS. Corrigez à la source.
KMSInvalidStateException au chiffrement ou au déchiffrement, Les opérations cryptographiques d'AWS KMS renvoient cette exception pour toute défaillance liée à la configuration ou à la connexion du magasin de clés externe. Lisez le texte du message d'erreur pour trouver la cause (AWS : Troubleshooting external key stores).
# Check connection state and error codes
aws kms describe-custom-key-stores \
--custom-key-store-id cks-1234567890abcdef0
# CloudTrail -- filter for XKS-related errors
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventSource,AttributeValue=kms.amazonaws.com \
--start-time 2026-01-01T00:00:00Z
Activez la journalisation des accès au niveau du proxy et corrèlez les journaux du proxy avec les événements CloudTrail à l'aide du champ requestId présent dans les deux.
XKS crée une piste d'audit plus complexe que KMS standard, mais plus complète, si vous l'instrumentez correctement.
CloudTrail enregistre chaque appel d'API KMS impliquant des clés XKS, y compris le principal appelant, l'ARN de la clé et le résultat de l'opération. Il s'agit de votre principal artefact d'audit pour démontrer le contrôle de l'utilisation des clés aux régulateurs.
Les journaux au niveau du proxy capturent chaque demande transmise de KMS à votre gestionnaire de clés externe. Lorsqu'il est configuré pour enregistrer les requestMetadata (qui incluent l'ARN principal AWS d'origine), vous disposez d'une piste d'audit de bout en bout depuis l'appel du service AWS jusqu'à l'opération cryptographique.
Les journaux d'audit du gestionnaire de clés externe fournissent un enregistrement faisant autorité indiquant quelles clés ont été utilisées, quand et par quelle identité de proxy.
Pour la conformité RGPD / Schrems II, documentez :
Pour PCI-DSS, assurez-vous que le gestionnaire de clés externe répond aux exigences de gestion des clés selon l'exigence 3.7 de PCI-DSS v4.0, y compris les procédures de double contrôle et de partage des connaissances pour les dépositaires de clés.
Q : Qu'est-ce qu'AWS XKS ?
AWS XKS (External Key Store) est une fonctionnalité d'AWS KMS qui vous permet d'utiliser des clés de chiffrement stockées et gérées entièrement en dehors de l'infrastructure AWS. Vos clés résident dans votre gestionnaire de clés externe ; AWS appelle votre proxy XKS chaque fois qu'il doit effectuer des opérations cryptographiques.
Q : Quand ai-je besoin de XKS au lieu de KMS standard ?
Lorsque les réglementations ou les politiques organisationnelles exigent explicitement que les clés cryptographiques ne résident jamais sur une infrastructure tierce (y compris le fournisseur de cloud). Les facteurs courants incluent le RGPD + Schrems II pour la souveraineté des données de l'UE, l'atténuation du CLOUD Act et certains mandats du secteur financier. Pour la plupart des exigences HIPAA, PCI-DSS et SOC 2, les clés CMK standard sont suffisantes.
Q : Qu'est-ce qu'un proxy XKS ?
Le proxy XKS est un middleware que vous possédez et exploitez. Il se situe entre AWS KMS et votre gestionnaire de clés externe, traduisant les requêtes API AWS XKS dans le protocole natif de votre gestionnaire de clés. Il fournit également une couche d'autorisation supplémentaire et agit comme un kill switch : désactivez le proxy et toutes les opérations de chiffrement/déchiffrement XKS s'arrêtent.
Q : Que se passe-t-il si mon gestionnaire de clés externe tombe en panne ?
Les services AWS qui s'appuient sur des clés sauvegardées par XKS ne pourront pas effectuer de nouvelles opérations de chiffrement ou de déchiffrement. Certains services (comme S3 avec les clés de compartiment activées) mettent en cache les clés de données pendant quelques minutes, offrant une brève résilience. Mais une panne prolongée signifie que vos charges de travail AWS ne peuvent pas traiter les données chiffrées. La haute disponibilité n'est pas négociable.
Q : Puis-je utiliser XKS avec tous les services AWS ?
AWS indique que les services qui prennent en charge les clés gérées par le client pour le chiffrement symétrique prennent aussi en charge les clés KMS d'un magasin de clés externe, dont S3, EBS et RDS. Vérifiez toujours votre service et votre Région AWS dans la documentation actuelle avant de vous engager.
Q : XKS coûte-t-il plus cher qu'une clé KMS standard ?
Pas sur la facture AWS : AWS KMS facture les clés d'un magasin de clés externe comme des clés KMS standard. Le surcoût, c'est tout ce que vous exploitez vous-même : le gestionnaire de clés externe, le proxy XKS, l'équilibrage de charge, les liens réseau et les équipes qui les opèrent.
Q : Quelle latence exige un magasin de clés externe AWS ?
Le proxy XKS doit répondre à chaque appel en 250 ms, sinon AWS KMS expire, et la spécification demande une latence ping de 35 ms au plus entre la Région AWS et votre gestionnaire de clés. Placez le magasin de clés dans la Région la plus proche de votre gestionnaire de clés.
Q : Quels fournisseurs proposent un proxy XKS ?
Vous pouvez en développer un à partir de la spécification ouverte d'AWS et de son exemple en Rust, ou utiliser un proxy de fournisseur. Thales, Fortanix, Entrust et Securosys publient des intégrations XKS, et DuoKey livre un proxy XKS intégré à DuoKey Cockpit, avec un coffre MPC parmi ses backends. Voir Options de proxy XKS.
Q : XKS est-il identique à CloudHSM ?
Non. CloudHSM fournit des HSM matériels dédiés physiquement situés dans les centres de données AWS, mais sous votre contrôle exclusif. XKS va plus loin : votre matériau clé réside dans l'infrastructure que vous exploitez, entièrement en dehors des installations appartenant à AWS. XKS a une complexité opérationnelle plus élevée, un coût total plus élevé et une latence plus élevée que CloudHSM.
Q : XKS est-il la même chose que BYOK avec du matériel de clé importé ?
Non. Avec le matériel de clé importé, vous générez la clé et l'importez, puis AWS KMS la détient et l'utilise dans ses propres HSM : c'est du BYOK. Avec XKS, le matériel de clé ne quitte jamais votre gestionnaire de clés externe et chaque opération passe par votre proxy : c'est le modèle Hold Your Own Key. Voir qu'est-ce que BYOK et le guide HYOK.
Q : Comment fonctionne la rotation des clés avec XKS ?
La rotation est plus complexe que le KMS standard. Vous ne pouvez pas utiliser la rotation automatique des clés KMS pour les clés XKS, ni changer le XksKeyId associé à une clé KMS. Au lieu de cela, votre gestionnaire de clés externe renouvelle le matériel de clé associé au même XksKeyId : AWS KMS continue de référencer le même ID de clé et votre gestionnaire de clés utilise de manière transparente le nouveau matériel de clé. Coordonnez soigneusement les procédures de rotation entre l'équipe qui exploite votre gestionnaire de clés et votre équipe AWS.
Q : Puis-je migrer les données chiffrées KMS existantes vers XKS ?
Pas directement. Il n'existe aucun chemin de rechiffrement qui déplace les données chiffrées CMK existantes vers XKS sans déchiffrer et rechiffrer chaque objet. Pour S3, cela signifie parcourir tous les objets ; pour les volumes EBS, vous auriez besoin de flux de travail de capture et de restauration. Planifiez soigneusement la migration et prévoyez du temps et des coûts importants pour les grands ensembles de données.
XKS est spécialement conçu pour un scénario de conformité restreint et spécifique. Il tient sa promesse : le matériau de clé cryptographique sous votre contrôle exclusif, en dehors de l'infrastructure AWS, mais au prix d'une complexité opérationnelle importante, d'une latence plus élevée et de coûts considérablement plus élevés.
Utilisez cette liste de contrôle avant de vous engager :
Si vous pouvez vérifier tous ces éléments, XKS est une solution bien conçue à un problème difficile. Si vous en vérifiez moins de quatre, jetez un autre regard sur CloudHSM ou sur des CMK bien gouvernées : ils peuvent satisfaire vos besoins réels avec une charge opérationnelle bien moindre.
Écrit par
Nagib Aouini
Ressources associées
Dites-nous où le contrôle est difficile aujourd’hui. Nous vous aiderons à définir une prochaine étape concrète.
