AWS External Key Store (XKS) : Atteindre une véritable souveraineté cloud
Table des matières
- Qu'est-ce qu'AWS External Key Store et pourquoi l'utiliser
- AWS KMS vs XKS : contrôle et souveraineté comparés
- Exigences d'architecture pour le déploiement XKS
- Guide de configuration XKS étape par étape
- Intégration de XKS avec le chiffrement S3, EBS et RDS
- Surveillance et audit de votre magasin de clés externe
- Avantages pour la conformité : RGPD, DORA et souveraineté
- Conclusion
- Références et lectures complémentaires
Pour les entreprises opérant dans des secteurs réglementés, la question de savoir qui contrôle les clés de chiffrement est devenue une préoccupation de niveau conseil d'administration. AWS External Key Store (XKS) répond directement à ce besoin en permettant aux organisations de maintenir leurs clés cryptographiques entièrement en dehors de l'infrastructure AWS — une capacité qui change fondamentalement l'équation de la souveraineté des données pour les déploiements cloud.
Annoncé fin 2022 et désormais mature en déploiements prêts pour la production dans les services financiers, la santé et les secteurs gouvernementaux, XKS représente la reconnaissance par AWS que certaines organisations ne peuvent pas céder la garde des clés à un fournisseur cloud, quelles que soient les assurances contractuelles. Ce guide technique accompagne les architectes de sécurité d'entreprise à travers l'architecture, le déploiement et les implications de conformité de la mise en œuvre d'AWS XKS avec des solutions de gestion de clés externes.
Qu'est-ce qu'AWS External Key Store et pourquoi l'utiliser
AWS External Key Store est un type de magasin de clés personnalisé au sein d'AWS Key Management Service (KMS) qui vous permet de stocker et d'utiliser des clés de chiffrement dans un gestionnaire de clés externe que vous possédez et contrôlez. Contrairement aux clés AWS KMS standard — qui sont générées, stockées et gérées dans des modules de sécurité matérielle (HSM) contrôlés par AWS — les clés XKS n'existent jamais dans l'infrastructure AWS.
Les fondements techniques
Lorsque vous créez une clé KMS adossée à XKS, AWS KMS communique avec votre gestionnaire de clés externe via un proxy API sécurisé. Chaque opération cryptographique — chiffrement, déchiffrement, signature, vérification — nécessite un appel en temps réel à votre gestionnaire de clés externe. AWS ne met jamais en cache ni ne stocke le matériau de clé ; il sert uniquement de couche d'orchestration.
Cette architecture implique :
- Le matériau de clé reste exclusivement en votre possession à tout moment
- AWS ne peut pas accéder à vos données même avec un mandat valide ou une demande gouvernementale
- Vous conservez la capacité de révoquer l'accès instantanément en déconnectant le magasin de clés externe
- Les opérations cryptographiques maintiennent des pistes d'audit complètes dans votre gestionnaire de clés externe
Quand XKS devient essentiel
Les organisations adoptent généralement AWS External Key Store lorsque l'AWS KMS standard ne répond pas à leurs exigences :
| Exigence | KMS standard | XKS |
|---|---|---|
| Clés stockées en dehors d'AWS | Non | Oui |
| Le fournisseur cloud ne peut pas accéder aux clés | Non | Oui |
| Capacité de révocation instantanée | Limitée | Complète |
| Gestion des clés à double contrôle | Non | Oui |
| Résidence géographique des clés | Contrôlée par AWS | Contrôlée par le client |
| Approbation réglementaire pour les charges de travail sensibles | Souvent insuffisante | Répond aux exigences les plus strictes |
Les institutions financières soumises à DORA (Digital Operational Resilience Act), les organisations de santé traitant des données de santé protégées selon des interprétations strictes d'HIPAA, et les contractants gouvernementaux ayant des mandats de souveraineté trouvent de plus en plus que XKS est la seule architecture qui satisfait l'examen des auditeurs et des régulateurs.
AWS KMS vs XKS : contrôle et souveraineté comparés
Comprendre la distinction entre AWS KMS standard et XKS nécessite d'examiner où le contrôle réside réellement tout au long du cycle de vie des clés.
AWS KMS standard : garde partagée
Avec AWS KMS standard, Amazon génère des clés dans du matériel CloudHSM exploité par AWS. Ces HSM sont certifiés FIPS 140-2 Niveau 3, et AWS met en œuvre des contrôles opérationnels rigoureux. Cependant, plusieurs lacunes en matière de souveraineté subsistent :
- AWS conserve une capacité technique d'accès au matériau de clé (même si la politique l'interdit)
- Les opérations sur les clés se produisent sur l'infrastructure AWS, laissant des métadonnées dans les journaux AWS
- La révocation dépend de l'application des politiques AWS, pas du contrôle physique
- La résidence géographique est limitée à la disponibilité des régions AWS
Pour de nombreuses charges de travail, ces compromis sont acceptables. Pour les industries réglementées traitant des données de citoyens européens, des transactions financières ou des informations classifiées, ils ne le sont souvent pas.
XKS : véritable souveraineté des clés
L'architecture de clé externe AWS KMS via XKS inverse ce modèle :
Point de contrôle : Génération des clés
- KMS standard : AWS génère le matériau de clé dans les HSM AWS
- XKS : Vous générez les clés dans votre propre HSM ou système de gestion des clés
Point de contrôle : Stockage des clés
- KMS standard : Matériau de clé chiffré et stocké dans l'infrastructure AWS
- XKS : Le matériau de clé ne quitte jamais votre gestionnaire de clés externe
Point de contrôle : Opérations cryptographiques
- KMS standard : Les opérations s'exécutent dans les HSM AWS
- XKS : Les opérations s'exécutent dans votre gestionnaire de clés externe via des appels API
Point de contrôle : Audit et journalisation
- KMS standard : Journaux CloudTrail (contrôlés par AWS)
- XKS : Journaux de votre gestionnaire de clés + CloudTrail (double visibilité)
Point de contrôle : Révocation d'accès
- KMS standard : Nécessite la propagation d'un changement de politique AWS
- XKS : Déconnecter le proxy XKS = révocation immédiate et complète
Ce modèle de souveraineté des données AWS répond à la préoccupation fondamentale : aucune partie — y compris AWS — ne peut accéder à vos données sans votre coopération continue et active.
La réalité de la frontière de confiance
Considérez un scénario où une autorité gouvernementale signifie à AWS une demande d'accès légal aux données pour des objets S3 chiffrés. Avec KMS standard, AWS peut techniquement se conformer en utilisant la clé KMS du client pour déchiffrer les données. Avec XKS, AWS ne peut fournir que du texte chiffré — inutile sans accès à votre gestionnaire de clés externe, que vous contrôlez.
Ce n'est pas une distinction théorique. Les régulateurs européens dans le cadre des implications Schrems II du RGPD, les exigences suisses de la FINMA, et les mandats NIS2 émergents exigent de plus en plus que les organisations démontrent que les fournisseurs cloud ne peuvent pas accéder de manière unilatérale aux données protégées.
Exigences d'architecture pour le déploiement XKS
Le déploiement de XKS nécessite une planification architecturale minutieuse à travers les composantes réseau, calcul et cryptographiques. Le système doit répondre à des exigences strictes de disponibilité et de latence tout en maintenant les frontières de sécurité.
Composantes d'infrastructure principales
Un déploiement XKS en production nécessite quatre composantes principales :
1. Gestionnaire de clés externe Votre HSM ou système de gestion des clés logiciel qui génère, stocke et effectue des opérations cryptographiques sur le matériau de clé. Cela doit prendre en charge la spécification de l'API proxy XKS.
Les gestionnaires de clés externes compatibles comprennent :
- La plateforme de gestion des clés basée sur MPC de DuoKey
- Thales CipherTrust Manager
- Fortanix SDKMS
- HashiCorp Vault Enterprise (avec plugin XKS)
- nCipher nShield HSMs
2. Proxy XKS Un composant intermédiaire qui traduit les appels d'API AWS KMS en API native de votre gestionnaire de clés externe. Le proxy gère l'authentification, le routage des requêtes et le formatage des réponses.
3. Connectivité réseau Connectivité privée à faible latence entre AWS et votre gestionnaire de clés externe. Les options incluent :
- AWS PrivateLink (recommandé pour la plupart des déploiements)
- VPN via AWS Direct Connect
- Point de terminaison public avec mTLS (latence plus élevée, moins recommandé)
4. Authentification et autorisation Certificats mTLS, signature de requêtes SigV4, et politiques de contrôle d'accès de votre gestionnaire de clés travaillant ensemble pour autoriser chaque opération cryptographique.
Exigences de latence et de disponibilité
XKS impose des exigences de performance strictes car chaque opération de chiffrement AWS dépend des réponses en temps réel du gestionnaire de clés externe :
| Métrique | Exigence | Recommandation |
|---|---|---|
| Latence API (P99) | < 250ms | < 100ms pour la production |
| Disponibilité | 99,99 % | Déployer sur plusieurs zones de disponibilité |
| Délai d'expiration des requêtes | 250ms | S'assurer que le chemin réseau supporte un RTT < 100ms |
| Connexions simultanées | Variable selon la charge | Tester en charge avant la mise en production |
Le non-respect de ces exigences entraîne des échecs d'opérations de chiffrement/déchiffrement, qui se propagent en erreurs d'application. Concevoir pour une disponibilité d'au moins 99,99 % avec basculement automatique entre les instances du gestionnaire de clés externe.
Considérations sur les frontières de sécurité
Lors de la conception d'une architecture XKS, définir des frontières de sécurité claires :
- Segmentation réseau : Le proxy XKS doit résider dans un segment réseau dédié avec des règles de pare-feu strictes autorisant uniquement les points de terminaison AWS KMS et votre gestionnaire de clés externe
- Gestion des certificats : Les certificats mTLS doivent être renouvelés régulièrement et stockés dans des magasins de clés protégés par HSM
- Journalisation des accès : Chaque appel d'API XKS doit générer des journaux d'audit dans AWS CloudTrail et dans votre gestionnaire de clés externe
- Stratégie de basculement : Définir des procédures explicites pour les scénarios de panne du proxy XKS
Guide de configuration XKS étape par étape
Ce guide de configuration aws xks parcourt le processus de configuration technique, des prérequis aux tests de validation.
Liste de vérification des prérequis
Avant de commencer la configuration, vérifiez :
- Gestionnaire de clés externe déployé et opérationnel
- Composant proxy XKS installé et configuré
- Connectivité réseau établie entre AWS et le proxy XKS
- Certificats mTLS générés et déployés
- Permissions IAM pour les opérations de magasin de clés personnalisé KMS
- AWS CLI v2 ou AWS SDK configuré
Étape 1 : Configurer votre gestionnaire de clés externe
Commencez par créer le matériau de clé qui soutiendra vos clés XKS. Dans votre gestionnaire de clés externe :
- Générer une clé AES 256 bits (pour le chiffrement symétrique) ou une paire de clés RSA/ECC (pour les opérations asymétriques)
- Attribuer un identifiant de clé unique que AWS KMS référencera
- Configurer les politiques d'accès autorisant les identifiants d'authentification du proxy XKS
- Activer la journalisation d'audit pour toutes les opérations sur cette clé
Intégration de XKS avec le chiffrement S3, EBS et RDS
Une fois votre magasin XKS opérationnel, vous pouvez l'utiliser pour chiffrer des données sur les principaux services de stockage AWS.
Surveillance et audit de votre magasin de clés externe
Une visibilité complète est essentielle pour maintenir la sécurité et la conformité dans les déploiements XKS.
Métriques CloudWatch pour XKS
Configurez des alarmes CloudWatch sur les métriques KMS pertinentes :
| Métrique | Seuil suggéré | Action |
|---|---|---|
CustomKeyStoreConnectionErrors | > 0 sur 5 minutes | Alerte critique |
XksProxyErrors | > 1 % des requêtes | Alerte d'avertissement |
XksProxyLatency | > 200ms (P95) | Alerte de performance |
Journalisation du gestionnaire de clés externe
Votre gestionnaire de clés externe doit journaliser tous les accès aux clés avec :
- Horodatage de chaque requête
- Identité du demandeur (ARN AWS, adresse IP)
- Identifiant de clé accédé
- Type d'opération (chiffrement, déchiffrement)
- Résultat (succès, refus, erreur)
Ces journaux constituent votre preuve d'audit principale pour la conformité et l'investigation d'incidents.
Avantages pour la conformité : RGPD, DORA et souveraineté
XKS transforme la posture de conformité des organisations opérant dans des environnements cloud réglementés.
Conformité RGPD
XKS répond directement aux préoccupations soulevées par la décision Schrems II. En maintenant les clés de chiffrement en dehors de l'infrastructure d'AWS, vous pouvez démontrer que :
- Les transferts de données vers AWS ne constituent pas un transfert de données accessibles
- Aucune autorité judiciaire américaine (via le CLOUD Act) ne peut contraindre AWS à déchiffrer vos données
- Vous maintenez un contrôle technique effectif sur les données personnelles européennes
Conformité DORA
Pour les entités financières, DORA exige une démonstration du contrôle des risques ICT de tiers. XKS permet de :
- Documenter la souveraineté des clés comme mesure de réduction des risques
- Fournir une preuve de révocation instantanée en cas d'incident fournisseur
- Répondre aux exigences d'audit Article 28 sur la gestion des risques tiers ICT
Conformité NIS2
NIS2 Article 21(2)(h) exige des politiques et procédures pour l'utilisation de la cryptographie. XKS soutient la conformité en :
- Éliminant la dépendance au magasin de clés AWS pour les données critiques
- Fournissant des pistes d'audit de toutes les opérations cryptographiques
- Permettant une révocation immédiate des accès en cas de compromission
Conclusion
AWS External Key Store représente une avancée significative dans la capacité des organisations à maintenir une véritable souveraineté des données tout en bénéficiant des services cloud AWS. Pour les entreprises dans les secteurs réglementés — finance, santé, secteur public — XKS n'est plus une option mais une nécessité pour satisfaire aux exigences croissantes des régulateurs européens.
La clé du succès avec XKS réside dans une planification architecturale rigoureuse : une connectivité réseau à faible latence, une haute disponibilité du gestionnaire de clés externe, et une surveillance proactive des métriques opérationnelles. Les organisations qui investissent dans cette infrastructure gagnent non seulement en conformité, mais aussi en confiance — la certitude que leurs données restent sous leur contrôle exclusif, quelles que soient les circonstances.
DuoKey propose une plateforme de gestion des clés compatible XKS conçue spécifiquement pour les exigences de souveraineté des entreprises européennes, avec des opérations MPC distribuées qui éliminent tout point de compromission unique.