À 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
Le voile est levé sur Oracle Code Assist. Présenté comme spécialisé en Java et SQL,…
EPEI, la société d'investissement de Daniel Kretinsky, a déposé une offre de reprise d'Atos. En…
Onepoint, l'actionnaire principal d'Atos, a déposé une offre de reprise du groupe. En voici quelques…
Broadcom a repris seul la main sur la vente de l'offre VMware d'AWS... qui, dans…
Microsoft expérimente, sous la marque ZTDNS, une implémentation des principes zero trust pour le trafic…
Accord de principe entre créanciers, propositions de reprise, discussions avec l'État... Le point sur le…