À quel(s) hyperscaler(s) faire confiance dans le contexte du CLOUD Act ? Cette loi fédérale promulguée par Donald Trump en mars 2018 doit faciliter l’obtention de preuves numériques dans le cadre d’enquêtes criminelles.
Le texte ouvre la voie à la signature d’accords entre gouvernements. Objectif : leur permettre de solliciter directement certains prestataires de services numériques pour qu’ils leur fournissent des données, qu’importe le lieu de stockage.
Outre le fait qu’il abolit toute restriction géographique, le mécanisme est voulu plus efficace que les autres leviers de coopération internationale, dont les traités d’assistance mutuelle (MLAT). Dans ce cadre, chacun des hyperscalers promeut, à périmètre plus ou moins large, ses solutions de chiffrement des données réceptionnées sur ses services cloud.
De manière générale, cette protection n’occasionne pas de frais supplémentaires. Elle implique une architecture à plusieurs niveaux : toute clé chiffrant des données dans une application est elle-même protégée par au moins une autre clé. Google parle de chiffrement « encapsulé » ; AWS, de chiffrement « d’enveloppe » ; Microsoft, de chiffrement « hiérarchique ».
Cette approche présente des avantages, notamment l’économie de bande passante et un gain de temps sur certaines opérations. Elle pose, néanmoins, un problème que résume Google : « Si vos données ne sont chiffrées qu’avec des clés que nous gérons, nous pourrions nous voir, avec un mandat judiciaire valable, contraints de les déchiffrer. » La réponse : un chiffrement au niveau de la couche d’application, avec l’aide d’un « magasin de secrets » dans lequel on peut stocker des données sensibles, dont les clés cryptographiques.
Au premier niveau de l’offre, l’entreprise cliente n’a pas la main sur le magasin, fourni en tant que service à locataires multiples. Mais elle s’occupe des clés : création, définition des politiques d’utilisation (sur les services cloud et en dehors), audit, alternance, désactivation temporaire, destruction, etc.
AWS, Google et Microsoft prennent en charge à peu près les mêmes types de clés : symétriques (AES 256 bits), destinées à chiffrer des données ; asymétriques RSA (2048, 3072 et 4096 bits), qui permettent aussi de signer et de vérifier des données ; asymétriques ECC (P-256, P-384, P-521 et P-256K1, à l’exception de Google pour ces deux dernières), exclusivement destinées à signer et à vérifier des données.
Le magasin héberge au minimum les clés de chiffrement principales. En fonction des hyperscalers, il est exploitable sans adaptation sur plus ou moins de services cloud, éventuellement avec une option de chiffrement côté client. Dans tous les cas, des API sont disponibles pour chiffrer sur d’autres applications. Des modules de sécurité matériels (HSM) sont mis à contribution pour protéger les clés, mais les opérations de (dé)chiffrement se font dans un logiciel que gère le fournisseur.
Considérant notamment que certains pays réservent à leurs autorités le droit d’accéder audit logiciel, les hyperscalers proposent une alternative : des HSM dédiés. Le client est seul à pouvoir y accéder, via un réseau privé. Le fournisseur ne peut que gérer la santé des clusters (mise en service, équilibrage de charge, sauvegardes, synchronisation, réplication, correctifs logiciels).
Le magasin se connecte à ces modules au sein desquels sont réalisées toutes les opérations. L’interaction se fait par l’intermédiaire d’un client logiciel qu’on installe traditionnellement sur les VM qui font tourner les applications.
Le niveau de sécurité est supérieur à celui des HSM sur lesquels le magasin repose par défaut. On monte jusqu’au niveau 3 de la certification FIPS 140-2, requis entre autres pour les systèmes de paiement et les autorités de certification SSL. Les HSM dédiés permettent de répondre à d’autres obligations de conformité.
Par exemple, la capacité à supprimer immédiatement des clés et à le prouver par des moyens indépendants. Ou pouvoir auditer leur utilisation sans s’appuyer sur le fournisseur cloud.
Une option supplémentaire consiste à créer des clés principales « vierges », puis à y importer des éléments. La proposition de valeur diffère d’un hyperscaler à l’autre : tandis qu’AWS ne prend pas en charge les clés asymétriques, Microsoft fait l’impasse sur les symétriques, quand Google refuse les clés « logicielles ». Attention à la disponibilité géographique des services. Chez AWS, le magasin n’accepte les clés asymétriques que dans cinq régions, dont une en Europe (Irlande).
Les contrats de niveau de service sont un autre point à surveiller.
Pour Azure Key Vault, Microsoft garantit un traitement des transactions dans les cinq secondes au moins 99,9 % du temps. En deçà, il octroie une compensation financière. Pour ce qui est des HSM dédiés, c’est « un service géré par le client. Par conséquent, il n’est pas financièrement garanti par un contrat de niveau de service ».
Chez AWS, on s’engage sur 99,9 % de disponibilité mensuelle pour le magasin KMS (Key Management Store) et 99,95 % pour les HSM dédiés.
Google annonce 99,5 % pour son magasin Cloud KMS comme pour les HSM dédiés. La facturation (voir ci-dessous, les prix s’entendent H. T.) s’apprécie globalement sur trois plans : le stockage des clés, leur gestion et leur utilisation.
TARIFICATION
Photo d’illustration via Shutterstock.com
Un temps pressenti pour constituer le socle d'une suite bureautique AWS, Amazon WorkDocs arrivera en…
Eviden regroupe cinq familles de serveurs sous la marque BullSequana AI. Et affiche le supercalculateur…
Le dernier Magic Quadrant du SSE (Secure Service Edge) dénote des tarifications et des modèles…
Formats de paramètres, méthodes d'apprentissage, mutualisation GPU... Voici quelques-unes des recommandations de l'ANSSI sur l'IA…
À la grogne des partenaires VMware, Broadcom répond par diverses concessions.
iPadOS a une position suffisamment influente pour être soumis au DMA, estime la Commission européenne.