Les services de chiffrement d’AWS : KMS et CloudHSM
AWS KMS et CloudHSM sont deux services proposés par le géant du cloud pour aider ses clients à chiffrer les données. Découvrez leurs spécificités, leurs qualités et leurs limites.
Mettre ses données d’entreprises sur un cloud public peut créer une forme de tension. Pour rassurer les utilisateurs et encourager les bonnes pratiques, les fournisseurs proposent des services de chiffrement appelés Key Management Service (KMS).
Le principal intérêt de tels services est d’offrir une gestion centralisée des clés de chiffrement. AWS KMS est l’un d’entre eux. Celui-ci sert principalement à chiffrer les données hébergées depuis les différents services du fournisseur de cloud et les données en transit via certificats SSL/TLS. AWS KMS dispose de l’ensemble des fonctionnalités décrites ci-dessus et ajoute une option de signature numérique associée à des paires de clés asymétriques.
AWS KMS est utilisé pour chiffrer, déchiffrer et re-chiffrer des données. L’outil permet de signer et de vérifier les messages signés. Il gère également les clés exportables ainsi que les nombres aléatoires pouvant servir à sécuriser des applications.
Dans un livre blanc, l’opérateur explique le fonctionnement de son service. « AWS KMS fournit une interface web via la console de gestion, une interface de ligne de commande AWS CLI et des API Restful pour appeler des opérations cryptographiques depuis une flotte distribuée de HSM validés par la norme FIPS 140-2 », peut-on lire dans le document.
L’API permet de créer et de gérer des clés KMS et des fonctions spéciales, notamment des magasins de clés personnalisés, ainsi que d’utiliser les clés KMS dans des opérations cryptographiques. Tous les appels à l’API AWS KMS doivent être signés et transmis à l’aide du protocole TLS (Transport Layer Security). AWS recommande d’utiliser les SDK AWS (disponibles pour .NET, C++, Go, Java et d’autres langages) pour effectuer des appels API programmatiques à AWS KMS.
Qu’est-ce qu’une clé dans AWS KMS ?
Une clé AWS KMS est une représentation logique d’une clé de chiffrement. Il s’agit d’une ressource primaire dans AWS KMS. Pour utiliser ou gérer les clés KMS, il est obligatoire de déployer AWS KMS. Les trois types de clés KMS suivants peuvent être créés dans AWS KMS :
Clé gérée par le client. Créée par l’organisation.
Clé gérée par AWS. Créée par les services AWS qui utilisent les clés KMS pour chiffrer les ressources de service de l’organisation.
Clé appartenant à AWS. Clés KMS créées par les services AWS dans un compte de services.
Une clé KMS contient les éléments suivants :
des métadonnées (ID de la clé, spécification de la clé, utilisation de la clé, date de création, description et état de la clé) ;
et une référence au support de clé utilisé lorsque des opérations cryptographiques sont effectuées avec la clé KMS.
L’avantage d’AWS KMS, c’est son intégration « transparente » à une grande majorité des services AWS. Ces intégrations reposent sur un chiffrement d’enveloppe (ou encapsulage). La clé du client et le contenu à chiffrer sont protégés par une clé gérée par AWS et/ou appartenant à AWS. Celle-ci est générée automatiquement au moment de chiffrer des documents au sein d’un service AWS. Dans le premier cas de figure, elle est gérée par le fournisseur « en votre nom », c’est-à-dire que les clés appartiennent in fine aux clients et sont payantes. Les clients ont accès à une piste d’audit. Dans le deuxième cas, AWS crée et gère les clés, donc sans garantie d’audit et de contrôle par l’utilisateur, mais l’utilisation des clés est gratuite.
Pour surveiller les accès aux clés, ce KMS s’intègre avec AWS CloudTrail. Cet outil doit donner accès aux fonctionnalités d’audit afin de savoir quelles clés sont utilisées pour quelles ressources, par qui, et quand.
Les clés KMS peuvent être symétriques (AES-GCM 128, 256 et 1 024 bits) ou asymétriques (RSA 2048, RSA 3072, RSA 4 096, ECC NIST P-256, ECC NIST P-384, ECC NIST-521 et ECC SECG P-256k1). AWS assure qu’il est possible d’en gérer 100 000 par compte et par région.
Un diagramme illustrant comment le chiffrement symétrique utilise la même clé pour chiffrer et déchiffrer les données, tandis que le chiffrement asymétrique s'appuie sur une clé privée et une autre public pour protéger un secret.
Le client peut importer ses clés symétriques (AES GCM 256 bits) en provenance de sa propre infrastructure de gestion de clés publiques pour faciliter leur gestion dans AWS KMS, après les avoir encapsulées avec une clé AWS KMS via la méthode RSA PKCS#1.
Les clés KMS peuvent également être créées et utilisées pour générer et vérifier des balises HMAC (Hash-Based Message Authentication Code). Elle représente une clé symétrique de longueur variable.
Depuis 2021, les utilisateurs ont la possibilité de créer des clés KMS HMAC multirégions, qui fonctionnent comme des copies de la même clé KMS dans différentes régions AWS (les données peuvent être chiffrées dans une région AWS et déchiffrées dans une autre région). En 2022, le fournisseur a continué à améliorer la prise en charge des clés HMAC.
Focus sur XKS
Par défaut, avec AWS KMS, les clés sont stockées par AWS dans des HSM mutualisés et multitenant. Le fournisseur assure qu’il ne peut avoir accès aux clés des clients de cette manière. Le service n’offre qu’une abstraction de ce qui se produit au sein du HSM sous-jacent.
AWS KMS propose bien un mécanisme BYOK (Bring Your Own Key), mais certains clients ne pouvaient pas laisser – par obligation – les clés dans des modules matériels de sécurité mutualisés. À la fin du mois de novembre 2022, le fournisseur introduit External Key Store (XKS), un mécanisme permettant d’utiliser KMS comme interface de chiffrement pour des clés générées et stockées par un HSM distant, géré par une organisation utilisatrice. Dans ce mode HYOK (Hold Your Own Key), AWS KMS n’est plus directement connecté avec le HSM. Les organisations installent un proxy dont le rôle est de transmettre les demandes de création et d’utilisation de clés dans les services AWS. Si le proxy est éteint, tous les services et applications utilisant les clés ne sont plus accessibles.
AWS assure qu’il veut garantir l’accès à ce service au plus grand nombre de ses clients. Pour cela, il inclut 20 000 requêtes AWS KMS gratuites par mois (les tarifs sont identiques pour toutes les régions disponibles) et de 0,03 à 12 dollars pour 10 000 demandes suivant le type de chiffrement (RSA 2048, ECC Generate DataKeyPair, asymétrique, RSA GenerateDataKeyPair). Ce service KMS est disponible dans l’ensemble des régions cloud AWS, hormis les régions Chine et Chine Continentale, opérées par Sinnet et NWCD qui n’ont pas obtenu la validation FIPS 140-2.
Le coût de stockage des clés principales est fixé à 1 dollar par clé par mois. Si la rotation annuelle de clés est activée, il faut ajouter un dollar par mois pour chacune d’entre elles. Selon les calculs d’AWS, le service coûterait moins de 7 dollars « pour chiffrer 10 000 fichiers uniques qui sont collectivement déchiffrés pour un accès 2 000 000 fois par mois ». Le SLA d’AWS KMS atteint dans le meilleur des cas 99,9 %.
CloudHSM : plus sécurisé, mais moins pratique
Avant la disponibilité de XKS, AWS supportait déjà un moyen de gérer des HSM dans le cloud. Son nom ? CloudHSM. « Utilisez AWS CloudHSM quand vous avez besoin de gérer le HSM qui génère et stocke les clés de chiffrement », précise la documentation d’AWS. Les clés symétriques et asymétriques préalablement encapsulées seront stockées dans un cluster CloudHSM dédié, installé dans l’Amazon Virtual Private Cloud (VPC) du client. Les modules matériels, gérés physiquement par AWS (qui n’a pas non plus accès aux clés dans cette configuration), respectent les normes FIPS 140-2 de niveau 3 et SP800-90B pour le générateur déterministe de bits aléatoires (20 Mo/s d’entropie par HSM). AWS utilise SafeNet Luna pour les instances déployées avant le premier trimestre 2019. Depuis, le géant du cloud utilise les produits de la gamme Liquid Security de Marvell.
De son côté, le client a la charge de gérer les clés. Dans ce cas de figure, il est possible de conserver et gérer les clés principales depuis son HSM sur site et de les communiquer via les méthodes RSA. Il n’y a toutefois pas de communication directe entre CloudHSM et un HSM sur site. Les données en transit sont protégées par les protocoles SSL et TLS, comme avec KMS.
Ce service permet également aux clients de gérer eux-mêmes des DRM, leur PKI (Public Key Infrastructure), des traitements de transactions et des signatures numériques. Les entreprises peuvent également protéger des bases de données Oracle, puisque CloudHSM supporte la technologie Transparent Data Encryption (TDE), également utilisée par Microsoft pour SQL Server ou IBM pour DB2.
Pour chiffrer les données dans leurs applications hébergées sur Amazon EC2, les développeurs peuvent utiliser le SDK Encryption fournie par AWS : il est compatible avec la boîte à outils OpenSSL, plusieurs API (PKCS# 11 et Java JCA/JCE – Java Cryptography Architecture/Java Cryptography Extensions) et les langages de programmation C et Java. Pour gérer les autres opérations comme la rotation des clés et l’accès aux utilisateurs, le service comprend lui aussi un CLI.
CloudHSM permet de gérer les clés de chiffrement pour les applications et espaces de stockage de données situés dans la même zone de disponibilité sur laquelle il est installé. Un cluster peut comprendre jusqu’à 28 HSM et contenir jusqu’à 3 300 clés. À la création d’un HSM, le service crée une interface réseau Elastic (ENI) dans le compte AWS d’un client, plus spécifiquement dans une instance qui contient ses applications, protégée par un autre VPC. L’ENI permet de synchroniser les clés utilisées pour chiffrer les données dans l’instance EC2 (généralement) avec CloudHSM.
Depuis septembre 2022, CloudHSM prend en charge un algorithme de chiffrement CMAC (Cipher-base MAC). Plus rapide que la fonction algorithmique HMAC, la méthode CMAC s’avère plus sensible aux attaques par collision. Par ailleurs, AWS a renforcé la compatibilité de son service avec Java et plus particulièrement avec l’API JCE (Java Cryptography Extension).
Le fournisseur a revu le logiciel de son service pour supporter Amazon Linux 2 et les architectures ARM, ainsi qu’Ubuntu 20.04.
Dans la mise à jour 5.08, disponible depuis le 16 mars 2023, CloudHSM dispose d’un mécanise de quorum pour gérer les authentifications des administrateurs. Avec ce mode, au moins deux officiers de chiffrement doivent être consultés pour créer et effacer un compte utilisateur ou changer son mot de passe.
La subtilité des intégrations SaaS
Pour gérer le chiffrement des données issues d’un produit SaaS en dehors du VPC du client, il existe deux méthodes. La première permet de faire de l’appairage de VPC et ne requiert pas de souscrire à KMS. Toutefois, il existe des risques si l’adressage IP CIDR est mal configuré. L’éditeur SaaS pourrait par inadvertance supprimer les identifiants d’un HSM si des plages CIDR se chevauchent. Pour éviter ce problème, AWS recommande de créer un cluster CloudHSM à la gestion des clés des applications SaaS. Autre défaut de cette configuration, il n’est pas possible de collecter des logs concernant l’utilisation des clés par l’éditeur de logiciels.
Avec la deuxième méthode, il convient de combiner KMS et CloudHSM. Les clés maîtresses CMK générées via KMS (à l’aide du SDK associé) sont stockées dans un cluster CloudHSM. Dans cette configuration, l’éditeur SaaS peut manipuler les CMK avec sa propre instance KMS. C’est KMS qui crée automatiquement l’infrastructure réseau nécessaire à la connexion avec l’environnement SaaS. L’éditeur n’a cependant pas accès au cluster CloudHSM du client, ce qui limite les opérations de chiffrement. En clair, elles sont réalisées à partir de KMS et il n’est pas possible d’utiliser les techniques de cryptologie plus avancées offertes par CloudHSM.
Plusieurs services tiers utilisent cette forme d’intégration dont Hashicorp Vault, Thycotic, P6R, Primekey EJBCA, Box Keysafe, Gemalto KeySecure, Vormetric Data Security Platform, Insyde Software, F5 Big IP LTM et Cloudera Navigator Key HSM.
À noter que CloudHSM n’est pas compatible avec les architectures réseau NAT, les répartiteurs de charge et AWS Privatelink qui permettent de relier plus directement le VPC du client et celui de l’éditeur SaaS.
Tarification de CloudHSM
CloudHSM est disponible dans 20 régions cloud AWS. Le service est bien plus cher qu’AWS KMS : un module HSM vous coûtera 2,18 dollars de l’heure dans la région Europe (Paris), soit 1 591,40 dollars pour 730 heures de fonctionnement en un mois. Selon Stephan Hadinger, Head of Technology, chez AWS France, il faut au minimum deux CloudHSM « pour des questions de résilience », ce qui fait grimper le prix à 3 182 dollars par mois.
De fait, CloudHSM est organisé en cluster automatiquement synchronisé entre zones de disponibilité (AZ). Ce mécanisme de redondance, présenté comme une fonctionnalité, est une nécessité. Il permet d’assurer la redondance et la haute disponibilité des clés et donc des services s’appuyant sur ces clés.
À cela, il faut ajouter le prix d’Amazon VPC, tout de même bien plus abordable (0,05 à 0,18 dollar de l’heure). Le SLA de CloudHSM atteint au maximum 99,95 % et AWS se charge de la sauvegarde automatique des clés.
Enfin, les clients peuvent faire appel à des partenaires tiers. Ces derniers proposent soit un surchiffrement sur certains services, comme les bases de données, soit de gérer les clés de chiffrement depuis leurs propres infrastructures. Thales, lui, propose une solution pour centraliser le chiffrement de services issus de différents clouds.
« Faire constamment appel à KMS n’est pas un bon usage. »
Stephan HadingerHead of technology, France
Notons que pour certains services, le client ne peut pas générer et gérer ses propres clés. Soit le service dispose de son propre système de chiffrement, soit il ne prend en charge que les clés KMS gérées par AWS. C’est le cas pour Lightsail, Cloud9 ou encore CodeCommit. Pour les entreprises ayant des exigences de sécurité importantes, AWS conseille d’utiliser ces services incompatibles avec CloudHSM à partir de comptes séparés.
Par ailleurs, du fait du chiffrement, KMS et CloudHSM peuvent avoir un effet sur les performances s’ils sont mal gérés. AWS ne recommande pas de tout protéger avec KMS pour cette raison. « Faire constamment appel à KMS n’est pas un bon usage », considère Stephan Hadinger. L’utilisation à bon escient de ces services serait sans conséquence sur les performances, selon AWS. Enfin CloudHSM a l’inconvénient d’être moins bien intégré aux services AWS que l’est KMS.
