FAQ pour AWS Key Management Service

AWS KMS veille au respect des politiques de gestion et d'utilisation que vous établissez. Vous pouvez choisir des utilisateurs et des rôles IAM dans votre compte ou d'autres comptes pour utiliser et gérer vos clés.

AWS KMS est conçu de telle sorte que personne, pas même les employés d'AWS, ne puisse récupérer vos clés KMS en texte simple sur le service. AWS KMS utilise des modules de sécurité matériels (HSM) qui ont été validés par la norme FIPS 140-2, ou sont en cours de validation, pour protéger la confidentialité et l'intégrité de vos clés. Vos clés KMS en texte simple ne quittent jamais les modules HSM, ne sont jamais écrites sur disque et sont uniquement utilisées sur la mémoire volatile des modules HSM le temps nécessaire pour effectuer l'opération cryptographique que vous demandez. Les mises à jour des logiciels sur les hôtes du service et du micrologiciel AWS KMS HSM font l'objet d'un contrôle d'accès multipartite audité et vérifié par un groupe indépendant au sein d'Amazon et par un laboratoire certifié NIST, conformément à la norme FIPS 140-2.

Pour plus d’informations sur ces contrôles de sécurité, consultez le guide technique sur les détails cryptographiques d’AWS KMS. Vous pouvez également consulter le certificat FIPS 140-2 pour les modules HSM d’AWS KMS ainsi que la politique de sécurité associée pour obtenir plus de détails sur la manière dont les modules HSM d’AWS KMS répondent aux exigences de sécurité de la norme FIPS 140-2. Vous pouvez également télécharger une copie du rapport SOC (System and Organization Controls) disponible dans AWS Artifact pour en savoir plus sur les contrôles de sécurité que le service utilise pour protéger vos clés KMS.

Vous n'avez rien à faire. Toutes les clés AWS KMS, indépendamment de leur date de création ou de leur origine, sont automatiquement protégées à l'aide de modules HSM validés au niveau de sécurité 3 par la norme FIPS 140-2.

Les modules HSM validés au niveau de sécurité 3 par la norme FIPS 140-2 sont déployés dans toutes les Régions AWS où AWS KMS est proposé.
REMARQUE : conformément à la réglementation, AWS KMS dans les Régions Chine ne peut pas utiliser les modules HSM FIPS du NIST et utilise à la place des modules HSM certifiés par le Bureau de l'administration de la cryptographie commerciale de l'État chinois (OSCCA, Office of the State Commercial Cryptographic Administration) de la Chine.

AWS KMS est un service à deux niveaux. Les points de terminaison d'API reçoivent des requêtes de clients via des connexions HTTPS exploitant uniquement des suites cryptographiques TLS qui prennent en charge la conformité de transmission parfaite (perfect forward secrecy, PFS). Ces points de terminaison d'API authentifient et autorisent la requête avant de la transmettre aux modules HSM d'AWS KMS pour les opérations cryptographiques, ou à votre cluster AWS CloudHSM (si vous utilisez la fonctionnalité de stockage de clés personnalisé).

Vous configurez vos applications pour vous connecter aux points de terminaison HTTPS régionaux uniques validés par la norme FIPS 140-2. Les points de terminaison HTTPS validés par la norme FIPS 140-2 d'AWS KMS sont optimisés par le module d'objet FIPS d'OpenSSL. Vous pouvez consulter la politique de sécurité du module OpenSSL ici. Des points de terminaison d'API validés par la norme FIPS 140-2 sont disponibles dans toutes les régions commerciales où AWS KMS est disponible.

Oui. AWS KMS a été validé comme disposant des fonctionnalités et des contrôles de sécurité requis pour vous aider à répondre aux exigences en matière de gestion des clés et de chiffrement (principalement référencées dans les sections 3.5 et 3.6) de la norme PCI DSS 3.2.1.

Pour en savoir plus sur les services conformes à la norme PCI DSS sur AWS, vous pouvez consulter les questions fréquentes (FAQ) sur la norme PCI DSS.

Vous pouvez demander à AWS KMS de générer des clés de données que vous pouvez ensuite utiliser sur votre propre application. Les clés de données sont chiffrées sous une clé racine que vous définissez dans AWS KMS afin de stocker en toute sécurité la clé de données chiffrée, ainsi que vos données chiffrées. Votre clé de données chiffrée (et par conséquent vos données sources) peut être déchiffrée uniquement par des utilisateurs autorisés à se servir de la clé racine d'origine pour déchiffrer votre clé de données chiffrée.

Non. Les clés AWS KMS sont créées et utilisées uniquement avec le service, afin de vérifier leur sécurité, de mettre en œuvre vos politiques à appliquer de manière cohérente et de fournir un journal centralisé de leur utilisation.

Une clé KMS d'une seule région générée par AWS KMS est stockée et utilisée uniquement dans la région dans laquelle elle a été créée. Avec les clés multi-régions AWS KMS, vous pouvez choisir une clé primaire multi-région dans plusieurs régions au sein de la même partition AWS.

Les journaux d’AWS CloudTrail contiennent toutes les requêtes d’API AWS KMS, dont les requêtes de gestion (telles que la création, la rotation, la désactivation, la modification de politiques) ainsi que les requêtes cryptographiques (telles que le chiffrement ou le déchiffrement). Activez CloudTrail sur votre compte pour afficher ces journaux.

CloudHSM vous fournit un cluster HSM validé à client unique sur votre cloud privé virtuel (VPC) Amazon pour stocker et utiliser vos clés. Vous avez un contrôle exclusif sur la façon dont vos clés sont utilisées grâce à un mécanisme d'authentification indépendant d'AWS. Vous interagissez avec des clés dans votre cluster CloudHSM de la même manière qu'avec vos applications s'exécutant dans Amazon EC2. Vous pouvez utiliser CloudHSM pour prendre en charge divers cas d'utilisation, comme la gestion des droits numériques (Digital Rights Management, DRM), les infrastructures de clés publiques (PKI), la signature de documents et les fonctions cryptographiques utilisant les interfaces PKCS#11, Java JCE ou encore Microsoft CNG.
 

AWS KMS vous aide à créer et contrôler les clés de chiffrement utilisées par vos applications ainsi que les services AWS pris en charge dans plusieurs régions du monde à partir d'une seule console. Ce service utilise un module HSM FIPS validé par la norme FIPS 140-2, ou en attente de validation, pour assurer la sécurité de vos clés. La gestion centralisée de l'ensemble de vos clés dans AWS KMS vous aide à déterminer qui peut utiliser vos clés, sous quelles conditions, le moment de leur renouvellement et qui peut les gérer. L'intégration d'AWS KMS avec CloudTrail vous permet de vérifier l'utilisation de vos clés afin de faciliter vos activités de réglementation et de conformité. Vous interagissez avec AWS KMS depuis vos applications à l’aide du kit SDK AWS si vous souhaitez appeler les API de service directement, par le biais d’autres services AWS intégrés à AWS KMS, ou depuis le kitAWS Encryption SDK si vous préférez effectuer un chiffrement côté client.

Avec AWS KMS, vous ne payez que ce que vous utilisez ; il n'y a pas de frais minimum. Il n'y a pas de frais d'installation, ni aucun engagement à prendre pour commencer à utiliser le service. A la fin du mois, votre carte de crédit est automatiquement débitée en fonction de votre utilisation au cours du mois.

Toutes les clés KMS que vous avez créées vous sont facturées, de même que toutes les requêtes d'API effectués chaque mois vers le service au-delà de l'offre gratuite.
 

Pour connaître les informations de tarification actuelles, consultez la page relative à la tarification AWS KMS.

Oui. Avec l’Offre gratuite d’AWS, vous pouvez démarrer avec AWS KMS gratuitement* dans toutes les régions. Le stockage dans votre compte des clés AWS KMS gérées par AWS et créées en votre nom par les services AWS est gratuit. Il existe une offre gratuite qui permet d'effectuer un nombre illimité de requêtes vers le service chaque mois. Pour connaître les informations de tarification actuelles, notamment celles concernant l’offre gratuite, consultez la page relative à la tarification AWS KMS.

*Les requêtes API impliquant des clés KMS asymétriques et les requêtes API envoyées vers les API GenerateDataKeyPair et GenerateDataKeyPairWithoutPlaintext ne sont pas concernées par l'offre gratuite.

Sauf indication contraire, nos prix n’incluent pas les taxes et redevances applicables, y compris la TVA et les taxes sur les ventes applicables. Pour les clients dont l'adresse de facturation est située au Japon, l'utilisation de services AWS est soumise à la taxe sur la consommation applicable dans ce pays. Vous pouvez en savoir plus en cliquant ici.

Oui. Vous pouvez importer dans AWS KMS une copie d'une clé issue de votre propre infrastructure de gestion de clés afin de l'utiliser avec n'importe quel service AWS intégré ou au sein de vos propres applications.

Vous pouvez utiliser une clé importée pour avoir une meilleure maîtrise du processus de création, de la gestion du cycle de vie et de la durabilité de votre clé dans AWS KMS. Les clés importées vous permettent également de répondre à certaines exigences de conformité qui nécessitent parfois d'être en mesure de générer ou de conserver une copie sécurisée de la clé dans votre infrastructure, ainsi que de pouvoir supprimer immédiatement la copie importée de l'infrastructure AWS.

Vous pouvez importer des clés symétriques, des clés asymétriques (RSA et courbe elliptique) et des clés HMAC.

Lors de l'importation, votre clé doit être encapsulée par une clé publique fournie par AWS KMS à l'aide de l'algorithme d'encapsulage pris en charge. Cela permet de vérifier que votre clé chiffrée ne pourra être déchiffrée que par AWS KMS.

Il y a deux principales différences :
 

1. Vous devez conserver de manière sécurisée, dans votre infrastructure de gestion de clés, une copie des clés importées afin de pouvoir les réimporter à tout moment. AWS vérifie néanmoins la disponibilité, la sécurité et la durabilité des clés générées par AWS KMS jusqu'à ce que vous programmiez leur suppression.
2. Vous pouvez définir un délai d'expiration pour une clé importée. AWS KMS supprimera automatiquement les éléments de clé une fois ce délai écoulé. Vous pouvez également supprimer des éléments de clés importés à la demande. Dans les deux cas, les éléments de clé sont supprimés, mais la référence de clé KMS dans AWS KMS et les métadonnées associées sont conservées, afin que vous puissiez réimporter les éléments de clé ultérieurement. Les clés générées par AWS KMS n'ont pas de délai d'expiration et ne peuvent pas être supprimées immédiatement. Il existe un délai d'attente obligatoire de 7 à 30 jours. Toutes les clés KMS gérées par un client, qu'elles aient été importées ou non, peuvent être désactivées ou programmées pour suppression manuellement. Dans ce cas, la clé KMS elle-même est supprimée, pas seulement les éléments de clé sous-jacents.

Vous pouvez réimporter une copie des éléments de clé (avec une période d'expiration en cours de validité) dans AWS KMS sous la clé AWS KMS d'origine afin de pouvoir l'utiliser.

Oui. Une fois que vous importez votre clé dans une clé AWS KMS, une métrique CloudWatch vous est transmise à quelques minutes d'intervalle. Elle indique le compte à rebours avant l'expiration de la clé importée. Un événement CloudWatch est également généré pour vous informer une fois que la clé importée sous la clé AWS KMS arrive à expiration. Vous pouvez alors élaborer une logique basée sur ces mesures ou événements pour réimporter automatiquement la clé avec une nouvelle période d'expiration. Ainsi, vous évitez tout risque d'indisponibilité.

AWS KMS prend en charge les clés 256 bits lors de la création d'une clé KMS pour le chiffrement et le déchiffrement. Les clés de données générées qui sont renvoyées à l'appelant peuvent avoir une taille de 256 bits, de 128 bits ou une valeur arbitraire maximale de 1024 bits. Lorsqu'AWS KMS utilise une clé KMS de 256 bits pour vous pour chiffrer et déchiffrer, l'algorithme AES dans Galois Counter Mode (AES-GCM) est utilisé.

AWS KMS prend en charge les types de clés asymétriques suivants : RSA 2048, RSA 3072, RSA 4096, ECC NIST P-256, ECC NIST P-384, ECC NIST-521 et ECC SECG P-256k1. AWS KMS prend en charge les algorithmes de chiffrement RSAES_OAEP_SHA_1 et RSAES_OAEP_SHA_256 avec les types de clés RSA 2048, RSA 3072 et RSA 4096. Les algorithmes de chiffrement ne peuvent pas être utilisés avec les types de clés à courbes elliptiques (ECC NIST P-256, ECC NIST P-384, ECC NIST-521 et ECC SECG P-256k1).

Lorsque vous utilisez des types de clés à courbe elliptique, AWS KMS prend en charge les algorithmes d’accords de clés ECDH.

En cas d'utilisation des types de clés RSA, AWS KMS prend en charge les algorithmes de signature suivants : RSASSA_PSS_SHA_256, RSASSA_PSS_SHA_384, RSASSA_PSS_SHA_512, RSASSA_PKCS1_V1_5_SHA_256, RSASSA_PKCS1_V1_5_SHA_384 et RSASSA_PKCS1_V1_5_SHA_512. En cas d'utilisation des types de clés à courbe elliptique, AWS KMS prend en charge les algorithmes de signature ci-dessous : ECDSA_SHA_256, ECDSA_SHA_384 et ECDSA_SHA_512.

La portion publique d'un élément de clé asymétrique est générée dans AWS KMS et peut être utilisée pour vérifier une signature numérique (en appelant l'API « Verify ») ou pour chiffrer la clé publique (en appelant l'API « Encrypt »). La clé publique peut également être utilisée en dehors d'AWS KMS à des fins de vérification ou de chiffrement. Vous pouvez appeler l'API « GetPublicKey » pour extraire la portion publique de la clé KMS asymétrique.

La taille maximale est de 4 Ko. Si vous souhaitez signer numériquement des données supérieures à 4 Ko, vous pouvez créer une synthèse de message des données et l'envoyer à AWS KMS. La signature numérique est créée sur la synthèse des données et renvoyée. Vous devez spécifier si vous envoyez le message intégral ou une synthèse de message dans les paramètres de la requête d'API Sign. Toute donnée envoyée aux API Encrypt, Decrypt ou Re-Encrypt et nécessitant l'utilisation d'opérations asymétriques doit être inférieure à 4 Ko.

Dans la console, chaque clé possède un nouveau champ dénommé Key Type (Type de clé). Ainsi, les clés KMS que vous créez porteront la valeur Asymmetric Key (Clé asymétrique) ou Symmetric Key (Clé symétrique), pour renseigner sur le type de clé. L'API DescribeKey renvoie un champ KeyUsage pour indiquer si la clé peut être utilisée pour signer, générer des HMAC ou chiffrer.

Non. La rotation automatique des clés n'est pas prise en charge pour les clés KMS asymétriques ou HMAC. En général, la rotation des clés asymétriques ou HMAC peut perturber considérablement votre charge de travail existante, car vous devez retirer et remplacer toutes les instances de clés que vous avez partagées avec d'autres parties dans le passé. Vous pouvez effectuer leur rotation manuelle en créant une nouvelle clé KMS et en mappant un alias de clé existant depuis l'ancienne clé KMS vers la nouvelle.

Non. Lors de la création de votre clé KMS, vous devez préciser si elle servira pour les opérations de déchiffrement ou de signature. Un type de clé RSA peut être utilisé pour les opérations de signature ou de chiffrement, mais jamais les deux. Les types de clés à courbes elliptiques ne peuvent être utilisés que pour les opérations de signature.

Oui. Les limites de taux de requêtes par seconde varient selon les types de clés et les algorithmes. Pour en savoir plus, consultez la page sur les limites AWS KMS.

Non. Vous ne pouvez pas utiliser la fonctionnalité de stockage de clés personnalisé avec des clés asymétriques.

Pas directement. Le service AWS KMS ne stocke ni n'associe les certificats numériques avec les clés KMS asymétriques qu'il crée. Vous pouvez choisir de faire délivrer un certificat par une autorité de certification, par exemple AWS Private Certificate Authority, pour la portion publique de votre clé KMS asymétrique. Cela permet aux entités qui utilisent votre clé publique de vérifier que ladite clé publique vous appartient effectivement.

La fonctionnalité de magasin de clés personnalisé AWS KMS allie les contrôles fournis par CloudHSM à l’intégration et à la simplicité d’utilisation d’AWS KMS. Vous pouvez configurer votre propre cluster CloudHSM et autoriser AWS KMS à l'utiliser comme stockage de clés dédié plutôt que votre stockage de clés AWS KMS par défaut. Lorsque vous créez des clés dans AWS KMS, vous pouvez choisir de générer les éléments de clés dans votre cluster CloudHSM. Les clés KMS générées dans votre stockage de clés personnalisé ne quittent jamais les modules HSM du cluster CloudHSM en clair, et toutes les opérations d'AWS KMS qui utilisent ces clés ne s'effectuent que dans vos modules HSM. Sur tous les autres points, les clés KMS placées dans votre stockage de clés personnalisé sont cohérentes avec les autres clés AWS KMS.

Vous trouverez des conseils supplémentaires pour décider s’il est pertinent d’utiliser un magasin de clés personnalisé dans ce billet de blog.

Puisque vous contrôlez votre cluster CloudHSM, vous pouvez gérer le cycle de vie de vos clés KMS indépendamment d'AWS KMS. Un stockage de clés personnalisé peut être utile pour trois raisons. Premièrement, il est possible que certaines clés requièrent une protection explicite dans un module HSM à client unique ou dans un module HSM sur lequel vous avez un contrôle direct. Deuxièmement, vous aurez peut-être besoin de supprimer immédiatement des éléments de clés d'AWS KMS et de le prouver par des moyens indépendants. Troisièmement, vous pouvez avoir à effectuer un audit complet de l'utilisation de vos clés indépendamment d'AWS KMS ou de CloudTrail.

Il existe deux différences de gestion entre un stockage de clés personnalisé CloudHSM et le stockage de clés AWS KMS par défaut. Vous ne pouvez pas importer des éléments de clés dans un stockage de clés personnalisé, et AWS KMS ne peut pas effectuer une rotation automatique des clés. Pour le reste, notamment le type de clé qui peut être généré, la façon dont les clés utilisent les alias et les méthodes de définition des politiques, les clés stockées dans un stockage de clés personnalisé sont gérées de la même manière que toutes les autres clés KMS gérées par un client AWS KMS.

Non, seules les clés KMS gérées par le client peuvent être stockées et gérées dans un stockage de clés personnalisé AWS KMS CloudHSM. Les clés KMS gérées par AWS qui sont créées pour vous par d'autres services AWS pour chiffrer vos données sont toujours générées et stockées dans le stockage de clés par défaut d'AWS KMS.

Non, les requêtes d'API envoyées à AWS KMS afin d'utiliser une clé KMS pour chiffrer et déchiffrer les données sont traitées de la même façon. Les processus d'authentification et d'autorisation ne tiennent pas compte de l'emplacement de stockage de la clé. Toute activité impliquant une clé placée dans un stockage de clés personnalisé soutenu par CloudHSM est également consignée dans CloudTrail de la même façon. Cependant, les opérations cryptographiques proprement dites surviennent exclusivement dans le stockage de clés personnalisé ou dans le stockage de clés AWS KMS par défaut.

En plus de l'activité journalisée dans CloudTrail par AWS KMS, l'utilisation d'un stockage de clés personnalisé fournit trois mécanismes d'audit supplémentaires. Premièrement, CloudHSM consigne également toutes les activités de l'API dans CloudTrail, comme la création de clusters et l'ajout ou la suppression de HSM. Deuxièmement, chaque cluster capture aussi ses propres journaux locaux pour enregistrer les activités relatives aux utilisateurs et à la gestion des clés. Troisièmement, chaque instance CloudHSM copie les journaux d'activité d'utilisateur et de gestion de clés dans AWS CloudWatch.

L'utilisation d'un stockage de clés personnalisé AWS KMS vous aide à être responsable de la vérification de la disponibilité de vos clés pour AWS KMS. Les erreurs de configuration de CloudHSM et la suppression involontaire des éléments de clés dans un cluster CloudHSM peuvent influer sur la disponibilité. Le nombre de modules HSM utilisés et le choix des zones de disponibilité (AZ) ont également un effet sur la résilience de votre cluster. Comme dans tous les systèmes de gestion de clés, vous devez comprendre l'impact de la disponibilité des clés sur la récupération de vos données chiffrées.

Le taux d'utilisation des clés placées dans un stockage de clés personnalisé AWS KMS CloudHSM par le biais des appels d'API AWS KMS est inférieur à celui des clés placées dans le stockage de clés AWS KMS par défaut. Consultez le Guide du développeur AWS KMS pour connaître les limites de performances actuelles.

Les tarifs AWS KMS ne sont pas affectés par l'utilisation d'un stockage de clés personnalisé. Cependant, pour chaque stockage de clés personnalisé, votre cluster AWS CloudHSM doit contenir au moins deux modules HSM. Ces modules HSM sont facturés aux tarifs AWS CloudHSM standard. Il n'y a pas de frais supplémentaires pour l'utilisation d'un stockage de clés personnalisé.

Les utilisateurs AWS KMS qui souhaitent disposer d'un stockage de clés personnalisé doivent configurer un cluster AWS CloudHSM, ajouter des modules HSM, gérer les utilisateurs des modules HSM et éventuellement restaurer les modules HSM à partir d'une sauvegarde. Il s'agit de tâches de sécurité délicates pour lesquelles vous pouvez vérifier que vous disposez des ressources et des contrôles organisationnels appropriés.

Non, vous ne pouvez pas importer vos propres éléments de clés dans un stockage de clés personnalisé AWS KMS. Les clés placées dans un stockage de clés personnalisé ne peuvent être générées que dans les modules HSM qui constituent votre cluster CloudHSM.

Non, la possibilité de migrer des clés entre les différents types de stockages de clés AWS KMS n'est pas prise en charge actuellement. Toutes les clés doivent être créées dans le stockage où elles seront utilisées, sauf si vous importez vos propres éléments de clés dans le stockage de clés AWS KMS par défaut.

Non, la rotation automatique des éléments de clés dans un stockage de clés personnalisé AWS KMS n'est pas possible. La rotation des clés doit être effectuée manuellement en créant des clés et en remappant les alias de clés AWS KMS employés par votre code d'application afin d'utiliser les nouvelles clés pour de futures opérations de chiffrement.

Oui. AWS KMS ne requiert pas un accès exclusif à votre cluster CloudHSM. Si vous avez déjà un cluster, vous pouvez l'utiliser à la fois en tant que stockage de clés personnalisé et pour d'autres applications. Cependant, si votre cluster héberge de puissantes applications non-AWS KMS, le débit des opérations utilisant les clés KMS du stockage de clés personnalisé peut être réduit. De la même façon, un taux de requêtes AWS KMS élevé vers votre stockage de clés personnalisé peut avoir un impact sur vos autres applications.

Consultez le site Web AWS CloudHSM pour obtenir une présentation générale du service. Pour plus de détails sur la configuration et l’utilisation du service, consultez le Guide de l’utilisateur AWS CloudHSM.

Un stockage de clés externe est un stockage de clés personnalisé soutenu par une infrastructure de gestion de clés externe que vous possédez et gérez en dehors d'AWS. Toutes les opérations de chiffrement ou de déchiffrement qui utilisent une clé KMS dans un stockage de clés externe sont effectuées dans votre gestionnaire de clés avec des clés et opérations cryptographiques qui sont sous votre contrôle et sont physiquement inaccessibles à AWS.

Un XKS peut vous aider à vous conformer aux règles ou réglementations qui exigent que les clés de chiffrement soient stockées et utilisées en dehors d'AWS sous votre contrôle.

Les requêtes adressées à AWS KMS par les services AWS intégrés en votre nom ou par vos propres applications sont transmises à un composant de votre réseau appelé Proxy XKS. Le Proxy XKS est une spécification API open source qui vous aide, vous et votre fournisseur de gestion de clés, à créer un service qui accepte ces requêtes et les transmet à votre infrastructure de gestion de clés afin d'utiliser ses clés pour le chiffrement et le déchiffrement.

Thales, Entrust, Atos, Fortanix, DuoKey, Securonix, Utimaco, Salesforce, T-Systems et HashiCorp proposent des solutions qui s’intègrent à la spécification XKS Proxy. Pour plus d’informations sur la disponibilité, la tarification et l’utilisation des solutions de ces fournisseurs, consultez leurs documentations respectives. Nous vous encourageons, vous et votre partenaire d'infrastructure de gestion des clés, à tirer parti de la spécification open source Proxy XKS pour élaborer une solution qui réponde à vos besoins. La spécification API pour Proxy XKS est publiée ici.

Les clés externes prennent en charge les opérations de chiffrement symétrique suivantes : Encrypt, ReEncrypt, Decrypt et GenerateDataKey.

Vous pouvez utiliser les clés XKS pour chiffrer les données dans n'importe quel service AWS qui s'intègre à AWS KMS à l'aide de clés gérées par le client. Consultez la liste des services soutenus ici. Les services AWS font appel à l'API AWS KMS GenerateDataKey pour demander une clé de données unique en clair afin de chiffrer vos données. La clé de données en clair est renvoyée au service avec une copie chiffrée de la clé de données qui sera stockée avec vos données chiffrées. Pour produire la copie chiffrée de la clé de données, la clé de données en clair est d'abord chiffrée par une clé stockée dans AWS KMS unique à votre compte AWS. Cette clé de données chiffrée est ensuite transmise à votre implémentation Proxy XKS connectée à votre gestionnaire de clés externe pour être chiffrée une seconde fois sous la clé que vous définissez dans votre gestionnaire de clés externe. La clé de données doublement chiffrée qui en résulte est renvoyée dans la réponse à la requête de l'API GenerateDataKey.

La connexion réseau entre AWS KMS, votre implémentation Proxy XKS et votre gestionnaire de clés externe doit être protégée par un protocole de chiffrement point à point tel que TLS. Toutefois, afin de protéger vos données quittant AWS KMS jusqu'à ce qu'elles atteignent votre gestionnaire de clés externe, AWS KMS les chiffre d'abord avec une clé KMS gérée en interne dans votre compte spécifique à chaque clé KMS définie dans votre magasin de clés externe. Le texte chiffré résultant est transmis à votre gestionnaire de clés externe, qui le chiffre à l'aide de la clé de votre gestionnaire de clés externe. Le double chiffrement fournit le contrôle de sécurité de sorte qu'aucun texte chiffré ne peut jamais être déchiffré sans utiliser le matériel de clé dans votre gestionnaire de clé externe. Il fournit également le contrôle de sécurité avec lequel le texte chiffré quittant le réseau AWS est chiffré à l'aide des HSM AWS KMS certifiés FIPS 140. Comme votre gestionnaire de clés externe doit être utilisé pour déchiffrer les données, si vous révoquez l'accès à AWS KMS, vos données chiffrées sous-jacentes deviennent inaccessibles.

Oui. Les clés XKS peuvent également être utilisées à partir de vos propres applications lorsque vous utilisez une solution de chiffrement symétrique côté client qui utilise AWS KMS comme fournisseur de clés. Les solutions de chiffrement côté client open source d'AWS, comme le kit AWS Encryption SDK, S3 Encryption Client et DynamoDB Encryption Client, prennent en charge les clés XKS.

Toutes les clés XKS doivent être créées comme de nouvelles clés dans KMS. Vous ne pouvez pas migrer des clés KMS existantes vers des clés XKS hébergées dans votre gestionnaire de clés externe.

Vous pouvez rechiffrer des données existantes sous des clés XKS nouvellement générées, à condition que le service AWS ou votre propre application prenne en charge cette action. De nombreux services AWS vous aideront à copier une ressource chiffrée et à désigner une nouvelle clé KMS à utiliser pour chiffrer la copie. Vous pouvez configurer la clé XKS dans la commande COPIER fournie par le service AWS. Vous pouvez rechiffrer les données chiffrées côté client dans vos propres applications en utilisant l'API KMS ReEncrypt et en configurant la clé XKS.

Comme toutes les clés gérées par les clients, les clés XKS sont facturées 1 USD par mois et par clé jusqu'à leur suppression. Les demandes effectuées sous des clés XKS sont facturées au même tarif que toute autre clé symétrique AWS KMS. Pour en savoir plus sur les tarifs, consultez la page de tarification d'AWS KMS.

Oui. La rotation automatique des clés est prise en charge par la spécification XKS, et il s'agit d'une capacité fournie par la plupart des fournisseurs qui prennent en charge XKS. La rotation automatique des clés XKS s'effectue entièrement dans le gestionnaire de clés externe et fonctionne de la même manière que la rotation automatique des clés AWS KMS créées et gérées dans KMS. Lorsque vous utilisez une clé KMS XKS ayant fait l'objet d'une rotation pour chiffrer des données, votre gestionnaire de clés externe utilise le contenu de la clé actuelle. Lorsque vous utilisez la clé XKS ayant fait l'objet d'une rotation pour déchiffrer du texte chiffré, votre gestionnaire de clés externe utilise la version des éléments de clé utilisée pour le chiffrer. Tant que les clés XKS utilisées pour créer les textes chiffrés précédents sont toujours activées dans votre gestionnaire de clés externe, vous pourrez effectuer une requête d'API Decrypt avec ces versions de vos clés XKS.

Pour les services qui ne mettent pas les clés en cache, la prochaine requête d'API utilisant cette clé XKS KMS échouera. Certains services mettent en œuvre la mise en cache des clés de données ou d'autres schémas de dérivation des clés pour des raisons de performance, de latence ou de gestion des coûts de KMS. La mise en cache de ces clés peut varier de cinq minutes à 24 heures. Toute ressource protégée en cours d'utilisation (comme une base de données RDS ou une instance EC2) réagira différemment après que vous ayez refusé l'accès à la clé. Pour plus de détails, consultez la documentation du service AWS concerné.

Pour s'authentifier auprès de votre proxy de stockage de clés externe, AWS KMS signe toutes les requêtes adressées au proxy à l'aide des informations d'identification AWS SigV4 que vous configurez sur votre proxy et que vous fournissez à KMS. AWS KMS authentifie votre proxy de stockage de clés externe à l'aide de certificats TLS côté serveur. En option, votre proxy peut activer le protocole TLS mutuel pour garantir qu'il n'accepte que les requêtes provenant d'AWS KMS.

Tous les mécanismes d'autorisation habituels d'AWS KMS (politiques IAM, politiques de clés AWS KMS, cession) que vous utilisez avec d'autres clés KMS fonctionnent de la même manière pour les clés KMS dans le stockage de clés externe.

En outre, vos partenaires gestionnaires de clés externes et/ou vous-même avez la possibilité de mettre en œuvre une couche secondaire de contrôles d'autorisation basée sur les métadonnées de demande incluses dans chaque demande envoyée par AWS KMS au Proxy XKS. Ces métadonnées comprennent l'utilisateur ou le rôle AWS utilisé, la clé KMS ARN et l'API KMS spécifique qui a été demandé. Cela vous permet d'appliquer une politique d'autorisation détaillée sur l'utilisation d'une clé dans votre gestionnaire de clés externe, au-delà de la simple confiance accordée à toute demande provenant d'AWS KMS. Le choix de l'application de la politique à l'aide de ces attributs de requête est laissé à la discrétion de vos implémentations individuelles de Proxy XKS.

L'identifiant unique généré pour chaque requête arrivant à AWS KMS et impliquant des clés XKS est également transmis au proxy XKS. Vous pouvez utiliser les données du journal (si elles sont disponibles) de votre proxy XKS ou de votre gestionnaire de clés externe pour rapprocher les demandes faites à AWS KMS et celles faites à votre gestionnaire de clés externe. Cette fonctionnalité vous permet de vérifier que toutes les requêtes d'utilisation de clés dans votre gestionnaire de clés externe proviennent d'une requête que vous avez envoyée à AWS KMS, soit directement, soit par le biais d'un service AWS intégré.

Risque de disponibilité : vous êtes responsable de la disponibilité de Proxy XKS et des éléments de clé externes. Ce système doit avoir une grande disponibilité pour vérifier que, chaque fois que vous avez besoin d'une clé XKS pour déchiffrer une ressource chiffrée ou chiffrer de nouvelles données, AWS KMS peut se connecter avec succès au proxy XKS, qui lui-même peut se connecter à votre gestionnaire de clés externe pour effectuer l'opération cryptographique nécessaire en utilisant la clé. Par exemple, supposons que vous ayez chiffré un volume EBS à l'aide d'une clé XKS et que vous souhaitiez maintenant lancer une instance EC2 et joindre ce volume chiffré. Le service EC2 transmettra la clé de données chiffrée unique pour ce volume à AWS KMS pour la déchiffrer afin qu'elle puisse être provisionnée dans la mémoire volatile de la carte Nitro pour déchiffrer et chiffrer les opération de lecture ou d'écriture sur le volume. Si votre Proxy XKS ou votre gestionnaire de clés externe n'est pas disponible pour déchiffrer la clé volume, le lancement de votre instance EC2 échouera. Dans ces types d'échecs, AWS KMS renvoie une KMSInvalidStateException indiquant que le Proxy XKS n'est pas disponible. C'est maintenant à vous de déterminer pourquoi votre Proxy XKS et votre gestionnaire de clés sont indisponibles en vous basant sur les messages d'erreur envoyés par KMS.

Risque de durabilité : les clés étant sous votre contrôle dans des systèmes extérieurs à AWS, vous êtes seul responsable de la durabilité de toutes les clés externes que vous créez. Si la clé externe d'une clé XKS est définitivement perdue ou supprimée, tout le texte chiffré sous la clé XKS est irrécupérable.

Risque lié aux performances : c’est à vous de vérifier que votre infrastructure Proxy XKS et de magasin de clés externe est conçue avec des caractéristiques de performance suffisantes pour répondre à vos besoins. Étant donné que chaque demande utilisant des clés XKS nécessite une connexion avec votre stockage de clés externe, votre proxy XKS peut devenir un goulot d'étranglement si le taux de demande d'AWS KMS dépasse le taux de demande que votre Proxy XKS ou votre gestionnaire de clés externe peut supporter. De plus, si le temps écoulé d'une seule requête (y compris une tentative) entre AWS KMS et votre Proxy XKS est supérieur à 500 ms*, AWS KMS renverra une erreur 400 à son client demandeur, indiquant ainsi que votre clé XKS est indisponible et que le client demandeur ne doit pas réessayer. Ce comportement est conçu pour minimiser le risque que les services AWS en amont ou vos propres applications doivent réagir à une latence excessive sporadique causée par des problèmes de connectivité à votre infrastructure.

*AWS KMS tentera une seule relance pour toute demande qui prend 250 ms. Si la requête de relance prend également plus de 250 ms, une erreur 400 sera renvoyée au client demandeur.

Étant donné qu’AWS ne peut pas contrôler la disponibilité de bout en bout de la connexion entre AWS KMS et votre infrastructure de magasin de clés externe, nous excluons spécifiquement l’utilisation de XKS dans notre SLA de disponibilité KMS public. De plus, les clés XKS sont exclues de la disponibilité des niveaux de service pour tout service AWS dans lequel une clé XKS est configurée par vous pour chiffrer des données dans le service.