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

Suite de l'article ci-dessous

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.

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.

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.

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é et le contenu à chiffrer sont protégés par une clé principale client (CMK), elle aussi stockée dans AWS KMS. Dans ce cas de figure, celle-ci est générée automatiquement au moment de chiffrer des documents au sein d’un service AWS.
Elle est gérée par le fournisseur « en votre nom », c’est-à-dire que les clés appartiennent aux clients. Les CMK peuvent alors être symétriques (AES-GCM 128, 256 et 1024 bits) ou asymétriques (RSA 2048, RSA 3072, RSA 4096, 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 10 000 par compte et par région.

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 l’avoir encapsulé avec une CMK via la méthode RSA PKCS#1.

Tarification d’AWS KMS

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 « 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

KMS peut être associé à un autre service d’AWS : 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 lequel 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.

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. À 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, ou 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.

Pour approfondir sur Sécurité du Cloud

Close