KMS XKS : le service de chiffrement qu’AWS ne veut pas promouvoir
Plus discrètement qu’à l’accoutumée, AWS lance une nouvelle option de chiffrement pour les entreprises soumises à de fortes contraintes réglementaires. Cette solution HYOK réclame au fournisseur de faire quelques entorses aux grands principes de sa cyberphilosophie.
AWS n’en démord pas : « nous n’avons pas accès aux clés de chiffrement de nos clients ! », s’exclamait Werner Vogels, CTO d’AWS, en avril dernier auprès du MagIT. Une phrase répétée quasi au mot près par Julien Groues, directeur général d’AWS France, lors de la conférence annuelle AWS re:Invent 2022 à Las Vegas.
Une phrase entendue à de maintes reprises dans la bouche de Stephan Hadinger, Head of technologies chez AWS. Cette question de la gestion des clés de chiffrement revient régulièrement sur la table.
Comme d’autres fournisseurs américains, AWS considère que le chiffrement est la meilleure protection disponible contre les lois extraterritoriales américaines et l’espionnage industriel. Or, le doute subsiste chez certains clients quant à la possibilité pour le fournisseur, ses partenaires ou les autorités américaines d’accéder aux précieux sésames permettant de déchiffrer leurs données.
Le géant du cloud a publié un livre blanc le 18 novembre dernier pour expliquer comment son hyperviseur Nitro doit empêcher les attaquants et les opérateurs d’AWS d’accéder aux clés de chiffrement.
« Par sa conception, le système Nitro n’a pas d’accès opérateur. Il n’existe aucun mécanisme permettant à un système ou à une personne de se connecter aux hôtes EC2 Nitro, d’accéder à la mémoire des instances EC2 ou d’accéder aux données des clients stockées sur le stockage local chiffré des instances, ou sur les volumes EBS chiffrés distants », écrivent les membres de l’équipe sécurité d’AWS.
« Si un opérateur AWS, y compris ceux disposant des privilèges les plus élevés, doit effectuer des travaux de maintenance sur un serveur EC2, il ne peut utiliser qu’un ensemble limité d’API administratives authentifiées, autorisées, consignées et auditées », poursuivent-ils.
Ces API ne permettraient pas à un opérateur d’accéder aux données stockées sur les serveurs EC2. « Comme il s’agit de restrictions techniques conçues et intégrées au système Nitro lui-même, aucun opérateur AWS ne peut contourner ces contrôles et protections ».
Et pourtant, ce discours ne suffit pas à convaincre certains clients et autorités, ce qui pousse le fournisseur à faire quelques entorses à sa philosophie de cybersécurité.
External Key Store, une solution de chiffrement pour les clients très régulés
La preuve, en marge de re:Invent 2022, AWS a annoncé la disponibilité AWS Key Management Service (KMS) External Key Store. Pour rappel, KMS est le service managé de génération et gestion de clés de chiffrement compatible avec une centaine de services AWS. Habituellement, il permet de chiffrer des données ou des secrets (mots de passe, tokens, clés API, etc.). En principe, il s’agit d’encapsuler un actif et une clé publique dans une enveloppe générée par une clé maîtresse (Customer Master Key ou CMK). Cette CMK réside dans un HSM multitenant géré entièrement par AWS, l’endroit où sont générées les clés de chiffrement des données (Data Encryption Key, DEK).
Les clients peuvent également utiliser le service CloudHSM, qui fournit un HSM dédié placé derrière un VPC. Dans cette configuration, AWS s’occupe uniquement du déploiement et de la maintenance du module matériel. Une troisième option permet d’utiliser une solution tierce, fournie par un partenaire d’AWS. Dans ce cadre, la CMK réside dans le HSM externe (en dehors du périmètre AWS) géré par le fournisseur tiers (dont le HSM devient la racine de confiance), mais une copie de la clé maîtresse « existe dans la mémoire volatile d’AWS KMS » pour générer les clés depuis le KMS.
Dans ces trois modes, AWS permet d’importer des clés externes (Bring Your Own Key), mais « seulement pour chiffrer d’autres clés », générées par le KMS afin de protéger les données de l’entreprise.
Tout comme le troisième mode, External Key Store (XKS) place, lui aussi, la racine de confiance à l’extérieur du cloud AWS. Cependant, ce quatrième le laisse le choix entre l’utilisation d’un service HSM tiers ou celui du client.
Non seulement la CMK réside en dehors du périmètre AWS et le chiffrement est effectué à l’extérieur, mais avec XKS, le HSM n’entre même plus directement en contact avec AWS KMS. AWS applique ici le modèle « Hold Your Own Keys » (HYOK). Pour autant, les développeurs peuvent continuer à utiliser le service KMS afin de réclamer le chiffrement d’un secret.
Plus précisément, l’option XKR implique le déploiement d’un proxy derrière le firewall du partenaire ou du client que l’un ou l’autre devra gérer par ses propres moyens. Ce proxy joue le rôle de « médiateur » entre les requêtes d’AWS KMS et le HSM externe devant rester connecté au proxy, pour que le service fonctionne. Les métadonnées de XKS permettraient d’ajouter une couche de contrôle d’autorisation supplémentaire en sus des politiques IAM, selon AWS.
Cette couche de communication repose sur l’implémentation d’une interface PKCS #11 2.40 écrite en Rust, disponible publiquement. Elle est pour l’instant compatible avec un nombre restreint de logiciels HSM (SoftHSMv2, LunaSA 7.4.0, AWS CloudHSM) et un seul module matériel (Luna 7 Network HSM de SafeNet, une filiale de Thales), tous utilisés par AWS. Atos, Hashicorp, Fortanix, Entrust, Salesforce, Thales et T-Systems sont les premiers acteurs à supporter XKS.
XKS, un « kill switch » à utiliser avec parcimonie
Le proxy XKS, selon les dires de Sébastien Stormacq, developer advocate chez AWS, est aussi un « kill switch » : « quand vous éteignez le proxy toutes les nouvelles opérations de chiffrement et de déchiffrement utilisant XKS cessent ».
En substance, AWS dit à ses clients que même si une autorité lui réclame la clé maîtresse, il ne pourrait même pas y avoir accès.
Ce n’est pas automatique pour les DEK déjà provisionnées. « Les services AWS qui ont déjà mis en mémoire une clé de données pour l’une de vos ressources continueront à fonctionner, jusqu’à ce que vous désactiviez la ressource ou que le cache de la clé de service expire », nuance-t-il.
Il y a toutefois des contreparties importantes. AWS assurait déjà que la gestion de CloudHSM était complexe. Le fournisseur prévient que XKS est compliqué et coûteux à gérer par soi-même. Outre la gestion physique et organisationnelle du HSM, il faut que le réseau soit suffisamment robuste et performant pour prendre en charge les requêtes KMS, qui doivent être en dessous des 250 millisecondes afin d’éviter les arrêts de service.
« Nous vous recommandons d'utiliser cette fonctionnalité uniquement si vous avez un besoin réglementaire ou de conformité qui vous oblige à maintenir vos clés de chiffrement en dehors d'un centre de données AWS ».
Sébastien StormacqDeveloper Advocate, AWS
« Nous vous recommandons d’utiliser cette fonctionnalité uniquement si vous avez un besoin réglementaire ou de conformité qui vous oblige à maintenir vos clés de chiffrement en dehors d’un centre de données AWS », écrit Sébastien Stormacq.
« Activez XKS uniquement pour les clés racines qui supportent vos charges de travail les plus critiques […] et continuez à utiliser les clés gérées par le client AWS KMS (entièrement sous votre contrôle) pour le reste », poursuit-il.
En personne, le developer advocate est transparent : « nous nous attendons à ce que cette solution soit adoptée par un très petit nombre de clients », indique-t-il au MagIT. Ces clients proviendraient d’organisations très régulées – banque, assurance et secteurs publics – et plus probablement de pays européens. Les régulateurs exigeraient de ces acteurs qu’ils puissent gérer les clés maîtresses.
« Les clients américains interrogés par l’équipe en charge d’XKS ont décliné l’offre : c’est trop complexe à gérer et à maintenir ».
Si l’annonce a bien fait l’objet d’un communiqué, XKS n’a pas fait le sujet d’une présentation lors des conférences principales. Elle a été couverte lors d'une « break out session » de l'événement destinée aux utilisateurs avancés d'AWS le 1er décembre. « L’on ne va pas inciter les clients à l’adopter », admet le developer advocate.
Maj : Un porte-parole d'AWS a précisé au MagIT que le fournisseur avait présenté la fonctionnalité XKS lors d'une session secondaire de l'événement.
Pour approfondir sur Gestion des accès (MFA, FIDO, SSO, SAML, IDaaS, CIAM)
