AWS XKS (External Key Store) : Guide de mise en œuvre complet 2026

Votre RSSI vient de vous demander comment votre organisation peut utiliser les services AWS tout en conservant un contrôle cryptographique complet sur les clés de chiffrement en dehors de l'infrastructure d'Amazon. La réponse est AWS XKS (External Key Store), mais elle s'accompagne d'une réelle complexité, de coûts importants et d'un changement fondamental dans vos responsabilités opérationnelles.

Ce guide coupe le bruit. Vous comprendrez exactement ce qu'est XKS, si vous en avez réellement besoin, comment le mettre en œuvre et ce que cela vous coûtera, y compris les fournisseurs de pièces détachées qui ne se porteront pas volontaires dès le départ.

Table des matières

Qu'est-ce qu'AWS XKS ?
Fonctionnement d'AWS XKS
XKS par rapport aux autres options de gestion des clés
Quand vous avez réellement besoin de XKS
Exigences et prérequis
Guide de mise en œuvre étape par étape
Le proxy XKS : plongée profonde
Meilleures pratiques de sécurité
Défis courants et dépannage
Considérations sur la conformité et l'audit
FAQ

Qu'est-ce qu'AWS XKS ?

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.

Architecture proxy AWS XKS dans VPC

Terminologie clé

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
Cryptage double enveloppe	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 chiffrement à double enveloppe. Les données sont cryptées à l'aide du matériau de clé KMS et de votre clé externe. Cela signifie que le texte chiffré protégé par XKS est toujours au moins aussi puissant que le KMS standard : il s'agit d'un additif et non d'un remplacement.

Comment fonctionne AWS XKS

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 :

Un service AWS (S3, EBS, RDS, etc.) appelle AWS KMS pour chiffrer ou déchiffrer une clé de données
AWS KMS identifie que la clé KMS est sauvegardée par un magasin de clés externe
KMS transmet la requête cryptographique à votre proxy XKS via HTTPS
Votre proxy XKS authentifie la demande et la transmet à votre gestionnaire de clés externe
Votre gestionnaire de clés externe effectue l'opération cryptographique
Le résultat revient via le proxy vers KMS
KMS termine l'opération et renvoie les résultats au service AWS

Tout cet aller-retour se déroule de manière synchrone. Si une étape de cette chaîne échoue ou dépasse le seuil de latence (généralement 250 ms), l'opération KMS échoue — et selon le service AWS, cet échec peut se répercuter.

Le changement de responsabilité partagée

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.

XKS par rapport aux autres options de gestion des clés

Avant d'investir dans XKS, comparez-le honnêtement aux alternatives.

'Arbre de décision AWS XKS'

XKS par rapport à AWS KMS standard (clés gérées par le client)

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).

XKS contre AWS CloudHSM

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	Coût total plus élevé	~1,45 $/h par cluster HSM
Ajustement de conformité	Mandats de souveraineté stricts	La plupart des exigences FIPS 140-2 niveau 3
Complexité	Très élevé	Élevé

Choisissez CloudHSM si vous avez besoin d'une validation matérielle FIPS 140-2 niveau 3 et pouvez tolérer des clés résidant physiquement dans AWS. Choisissez XKS uniquement si votre mandat de conformité exige explicitement que les clés restent entièrement en dehors des installations appartenant à AWS.

XKS et clés gérées par le client (Résumé)

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.

Cadre décisionnel

Posez ces trois questions dans l'ordre :

Vos réglementations exigent-elles explicitement que les éléments clés résident en dehors de l'infrastructure physique de votre fournisseur de cloud ? Si non — utilisez des clés CMK ou CloudHSM.
Pouvez-vous accepter une latence plus élevée, une complexité opérationnelle et des coûts nettement plus élevés ? Si non — reconsidérez si XKS est réellement nécessaire.
Avez-vous la maturité opérationnelle nécessaire pour exécuter un service de gestion de clés hautement disponible et à faible latence ? Si non — développez cette fonctionnalité avant de mettre en œuvre XKS.

Quand vous avez réellement besoin de XKS

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.

Exigences et prérequis

Avant de commencer la mise en œuvre, validez tous ces éléments.

Exigences du gestionnaire de clés externe

Votre gestionnaire de clés externe doit :

Prendre en charge les clés symétriques AES-256
Être capable d'effectuer des opérations de cryptage et de déchiffrement AES-GCM
Exposer une API que votre proxy XKS peut traduire vers la spécification AWS XKS
Répondre aux exigences de latence : répondre aux demandes de proxy en moins de 250 ms (de bout en bout depuis KMS)

Les gestionnaires de clés externes valides avec prise en charge native du proxy XKS incluent :

Thales CipherTrust Manager (avec CipherTrust Cloud Key Manager)
Gestionnaire de sécurité des données Fortanix
HashiCorp Vault (avec implémentations de proxy communautaire XKS)
Entrust KeyControl
Atos Trustway
T-Systems (déploiements cloud souverains)
Securosys Primus HSM/CloudHSM
Tout HSM compatible PKCS#11 utilisant AWS proxy XKS de référence open source construit dans Rust

Conditions requises pour le compte AWS

AWS KMS activé dans vos régions cibles
Autorisations IAM pour créer et gérer des magasins de clés personnalisés
VPC configuré si vous utilisez la connectivité du service de point de terminaison VPC (recommandé)

Configuration réseau requise

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 :

TLS 1.2 ou supérieur avec un certificat valide
Le chemin de l'URI du proxy doit être /kms/xks/v1 (ou un préfixe se terminant par ce chemin)
Port 443 (HTTPS)
Temps de réponse constamment inférieur à 250 ms

Guide de mise en œuvre étape par étape

Étape 1 : Configurez votre gestionnaire de clés externe

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.

Étape 2 : Déployer le proxy XKS

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 système d'informations d'identification de type 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. Faites régulièrement pivoter ces informations d'identification.

Étape 3 : Configurer AWS KMS

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".

Étape 4 : Créer des clés KMS soutenues par XKS

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

Étape 5 : Configuration de la stratégie IAM

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": "*"
    }
  ]
}

Étape 6 : Tests et validation

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 XKS : analyse approfondie

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 spécification de l'API du proxy AWS XKS, une API REST sur HTTPS qui définit cinq opérations : GetHealthStatus, GetKeyMetadata, Encrypt, Decrypt et GetXksProxyConfiguration.

'DuoKey AWS XKS'

Exigences de sécurité du proxy

Authentification mTLS ou SigV4 pour toutes les requêtes KMS vers proxy
Le proxy doit valider que les demandes incluent un champ 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.
Toutes les communications chiffrées en transit ; aucune exception
Le proxy ne doit pas stocker les clés : il traduit les requêtes, il ne met pas en cache les secrets.

Créer un proxy personnalisé

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 :

Journalisation des demandes/réponses (sans journalisation des éléments clés)
Limitation de débit et disjoncteurs
Points de terminaison de contrôle de santé pour l'intégration de l'équilibreur de charge
Exportation de métriques vers CloudWatch ou votre pile d'observabilité

Considérations sur les performances du proxy

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.

Comparez votre proxy sous une charge réaliste avant la mise en ligne. Les erreurs XKS_PROXY_TIMED_OUT indiquent que votre proxy est trop lent ; XKS_PROXY_INVALID_RESPONSE indique un problème de protocole.

Bonnes pratiques de sécurité

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.

Défis courants et dépannage

Erreurs de connexion

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.

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.

Échecs d'authentification

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.

Problèmes clés

XKS_KEY_NOT_FOUND — Le XksKeyId référencé dans KMS n'existe pas dans votre gestionnaire de clés externe, ou le proxy ne peut pas le trouver. Vérifiez que l'ID de clé est correct et que la clé est activée dans votre gestionnaire de clés externe.

XKS_KEY_DISABLED_IN_EXTERNAL_KEY_MANAGER — La clé est désactivée au niveau du gestionnaire de clés externe. Ceci est indépendant de l'état activé de la clé KMS. Réactivez à la source.

Outils de débogage

# 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.

Considérations relatives à la conformité et à l'audit

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 :

Localisation physique du gestionnaire de clés externe
Politiques de contrôle d'accès sur le gestionnaire de clés externe
Chemin réseau d'AWS au proxy (le service de point de terminaison VPC est idéal)
Procédures de sauvegarde et de récupération clés qui maintiennent les restrictions géographiques
Procédures de réponse aux incidents en cas de compromission clé

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.

FAQ

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 ?

XKS fonctionne avec la plupart des services AWS qui prennent en charge les clés KMS gérées par le client, notamment S3, EBS, RDS, DynamoDB, Lambda et autres. AWS valide et documente progressivement la prise en charge par service. Vérifiez toujours votre service spécifique et votre région AWS par rapport à la documentation actuelle avant de vous engager dans la conception.

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 : 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. Au lieu de cela, votre gestionnaire de clés externe alterne les éléments de clé associés 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 les nouveaux éléments de clé. Coordonnez soigneusement les procédures de rotation entre votre équipe de gestionnaires clés des opérations 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.

Conclusion : XKS est-il fait pour vous ?

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 :

Votre équipe juridique ou de conformité a explicitement confirmé que les réglementations exigent que les éléments clés résident en dehors de l'infrastructure du fournisseur de cloud (et pas seulement un « contrôle fort des clés » en général)
Vous avez identifié un gestionnaire de clés externe compatible et un déploiement de proxy XKS viable
Vous pouvez maintenir une latence aller-retour inférieure à 250 ms depuis votre proxy vers un gestionnaire de clés externe.
Vous avez la capacité opérationnelle d'exécuter un service de gestion de clés hautement disponible
Vous avez prévu un budget de 7 000 $ à 20 000 $+/mois en coûts opérationnels totaux
Vous disposez d'un plan de reprise après sinistre testé pour les pannes du gestionnaire clé
Vous avez audité les services AWS que vous utilisez et confirmé la prise en charge XKS pour chacun

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.

Références

Ressources associées