Souveraineté, disponibilité, performances et scalabilité clés dans HSM managé
Les clés de chiffrement sont la racine de la confiance pour la sécurisation des systèmes informatiques modernes, que ce soit en local ou dans le cloud. Il est donc essentiel de contrôler qui a autorité sur ces clés pour créer des applications sécurisées et conformes.
Dans Azure, notre vision de la façon dont la gestion des clés doit être effectuée dans le cloud est la souveraineté clé. La souveraineté des clés signifie que l’organisation d’un client a un contrôle total et exclusif sur qui peut accéder aux clés et modifier les stratégies de gestion des clés, et sur les services Azure qui consomment ces clés. Une fois ces décisions prises par le client, le personnel Microsoft ne peut pas modifier ces décisions par des moyens techniques. Le code du service de gestion des clés exécute les décisions du client jusqu’à ce que celui-ci lui indique de faire autrement et que le personnel Microsoft ne peut pas intervenir.
En même temps, nous sommes convaincus que chaque service dans le cloud doit être entièrement géré. Le service doit fournir les promesses de disponibilité, de résilience, de sécurité et de cloud fondamentales requises, soutenues par des contrats de niveau de service (SLA). Pour fournir un service managé, Microsoft doit corriger les serveurs de gestion de clés, mettre à niveau le microprogramme du module de sécurité matérielle (HSM), réparer le matériel défaillant, effectuer des basculements et effectuer d’autres opérations à privilèges élevés. Comme la plupart des professionnels de la sécurité le savent, refuser à une personne disposant de privilèges élevés ou d’un accès physique à un système l’accès aux données au sein de ce système est un problème difficile.
Cet article explique comment nous avons résolu ce problème dans le service HSM managé Azure Key Vault, offrant aux clients une souveraineté totale des clés et des contrats SLA de service entièrement managés à l’aide d’une technologie d’informatique confidentielle associée à des HSM.
Environnement matériel HSM managé
Le pool HSM managé d’un client dans n’importe quelle région Azure se trouve dans un centre de données Azure sécurisé. Trois instances sont réparties sur plusieurs serveurs. Chaque instance est déployé dans un rack différent pour garantir la redondance. Chaque serveur a un adaptateur HSM Marvell LiquidSecurity validé FIPS 140-2 niveau 3 avec plusieurs cœurs de chiffrement. Les cœurs sont utilisés pour créer des partitions HSM entièrement isolées, y compris des informations d’identification entièrement isolées, le stockage des données et le contrôle d’accès.
La séparation physique des instances à l’intérieur du centre de données est essentielle pour garantir que la perte d’un seul composant (commutateur haut de rack, unité de gestion de l’alimentation dans un rack, etc.) ne puisse pas affecter toutes les instances d’un pool. Ces serveurs sont dédiés à l’équipe Azure Security HSM. Les serveurs ne sont pas partagés avec d’autres équipes Azure et aucune charge de travail client n’est déployée sur ces serveurs. Des contrôles d’accès physiques, y compris les racks verrouillés, sont utilisés pour empêcher l’accès non autorisé aux serveurs. Ces contrôles respectent FedRAMP-High, PCI, SOC 1/2/3, ISO 270x et d’autres normes de sécurité et de confidentialité, et sont régulièrement vérifiés indépendamment dans le cadre du programme de conformité Azure. Les HSM ont amélioré la sécurité physique, validée pour répondre aux exigences FIPS 140-2 niveau 3. L’ensemble du service HSM managé est basé sur la plateforme Azure sécurisée standard, y compris le lancement approuvé, qui protège contre les menaces persistantes avancées.
Les adaptateurs HSM peuvent prendre en charge des dizaines de partitions HSM isolées. S’exécutant sur chaque serveur est un processus de contrôle appelé Node Service. Node Service prend la propriété de chaque adaptateur et installe les informations d’identification du propriétaire de l’adaptateur, dans ce cas, Microsoft. Le HSM est conçu pour que la propriété de l’adaptateur ne donne pas à Microsoft accès aux données stockées dans les partitions client. Il permet uniquement à Microsoft de créer, de redimensionner et de supprimer des partitions client. Il prend en charge les sauvegardes aveugles de n’importe quelle partition pour le client. Dans une sauvegarde aveugle, la sauvegarde est encapsulée par une clé fournie par le client qui peut être restaurée par le code de service uniquement à l’intérieur d’un instance HSM managé appartenant au client et dont le contenu n’est pas lisible par Microsoft.
Architecture d’un pool HSM managé
La figure 1 montre l’architecture d’un pool HSM, qui se compose de trois machines virtuelles Linux, chacune s’exécutant sur un serveur HSM dans son propre rack de centre de données pour prendre en charge la disponibilité. Les composants importants sont les suivants :
- Le contrôleur de structure HSM (HFC) est le plan de contrôle du service. Le HFC pilote la mise à jour corrective et les réparations automatisées pour le pool.
- Une limite de chiffrement compatible FIPS 140-2 Niveau 3, exclusive pour chaque client, y compris trois enclaves confidentielles Intel Secure Guard Extensions (Intel SGX), chacune connectée à un HSM instance. Les clés racines de cette limite sont générées et stockées dans les trois modules HSM. Comme nous le décrivons plus loin dans cet article, aucune personne associée à Microsoft n’a accès aux données qui se trouvent dans cette limite. Seul le code de service qui s’exécute dans l’enclave Intel SGX (y compris l’agent de service de nœud), agissant pour le compte du client, a accès.
Environnement d’exécution approuvé (TEE)
Un pool HSM managé se compose de trois instances de service. Chaque instance de service est implémentée en tant qu’environnement d’exécution approuvé (TEE) qui utilise les fonctionnalités d’Intel SGX et le Kit de développement logiciel (SDK) Open Enclave. L’exécution au sein d’un TEE garantit qu’aucune personne sur la machine virtuelle qui héberge le service ou le serveur hôte de la machine virtuelle n’a accès aux secrets client, aux données ou à la partition HSM. Chaque TEE est dédié à un client spécifique et exécute la gestion TLS, la gestion des requêtes et le contrôle d’accès à la partition HSM. Il n’existe pas d’informations d’identification ou de clés de chiffrement de données spécifiques au client en texte clair en dehors de ce TEE, sauf dans le cadre du package de domaine de sécurité. Ce package est chiffré sur une clé fournie par le client et il se télécharge lors de la première création de son pool.
Les TEE communiquent entre eux à l’aide du protocole TLS attesté. TLS attesté combine les fonctionnalités d’attestation à distance de la plateforme Intel SGX avec TLS 1.2. Cela permet au code HSM managé dans le TEE de limiter sa communication à d’autres codes signés par la même clé de signature de code du service HSM managé, afin d’empêcher les attaques de l’intercepteur. La clé de signature de code du service HSM managé est stockée dans Microsoft Product Release and Security Service (qui est également utilisé pour stocker, par exemple, la clé de signature de code Windows). La clé est contrôlée par l’équipe HSM managée. Dans le cadre de nos obligations réglementaires et de conformité pour la gestion des modifications, cette clé ne peut être utilisée par aucune autre équipe Microsoft pour signer son code.
Les certificats TLS utilisés pour la communication TEE-TEE sont auto-émis par le code de service à l’intérieur du TEE. Les certificats contiennent un rapport de plateforme généré par l’enclave Intel SGX sur le serveur. Le rapport de plateforme est signé avec des clés qui sont dérivées de clés fusionnées par Intel dans le processeur lors de sa fabrication. Le rapport identifie le code chargé dans l’enclave Intel SGX par sa clé de code de signature et son hachage binaire. À partir de ce rapport de plateforme, les instances de service peuvent déterminer qu’un homologue est également signé par la clé de signature de code du service HSM managé et, avec une intrication de chiffrement via le rapport de plateforme, elles peuvent également déterminer que la clé de signature de certificat auto-émise doit également avoir été générée à l’intérieur du TEE, pour empêcher l’emprunt d’identité externe.
Offrir des contrats SLA de disponibilité avec un contrôle complet des clés gérées par le client
Pour garantir la haute disponibilité, le service HFC crée trois pools dans la région Azure sélectionnée par le client.
Création d’un pool HSM managé
Les propriétés de haute disponibilité des pools HSM managés proviennent des instances HSM triple redondantes gérées automatiquement qui sont toujours synchronisées (ou, si vous utilisez la réplication multirégion, de la synchronisation des six instances). La création de pool est gérée par le service HFC, qui alloue des pools sur le matériel disponible dans la région Azure choisie par le client.
Lorsqu’un nouveau pool est demandé, le HFC sélectionne trois serveurs sur plusieurs racks qui ont de l’espace disponible sur ses adaptateurs HSM, puis il commence à créer le pool :
Le HFC indique aux agents du service de nœud sur chacun des trois TEE de lancer une nouvelle instance du code du service à l’aide d’un ensemble de paramètres. Les paramètres identifient le locataire Microsoft Entra du client, les adresses IP de réseau virtuel interne des trois instances et d’autres configurations de service. Une partition est affectée de manière aléatoire en tant que principale.
Les trois instances démarrent. Chaque instance se connecte à une partition sur son adaptateur HSM local, puis il met à zéro et initialise la partition à l’aide de noms d’utilisateur et d’informations d’identification générés de manière aléatoire (pour s’assurer que la partition n’est pas accessible par un opérateur humain ou par un autre instance TEE).
L’instance principale crée un certificat racine de propriétaire de partition à l’aide de la clé privée générée dans le HSM. Elle établit la propriété du pool en signant un certificat au niveau de la partition pour la partition HSM à l’aide de ce certificat racine. Le serveur principal génère également une clé de chiffrement des données, qui est utilisée pour protéger toutes les données client au repos à l’intérieur du service. Pour le matériau clé, un double enveloppement est utilisé, car le HSM protège également le matériau clé lui-même.
Ensuite, ces données de propriété sont synchronisées avec les deux instances secondaires. Chaque secondaire contacte le principal à l’aide du protocole TLS attesté. Le principal partage le certificat racine du propriétaire de la partition avec la clé privée et la clé de chiffrement des données. Les instances secondaires utilisent désormais le certificat racine de partition pour émettre un certificat de partition pour leurs propres partitions HSM. Une fois cette opération effectuée, vous disposez de partitions HSM sur trois serveurs distincts appartenant au même certificat racine de partition.
Via le lien TLS attesté, la partition HSM du serveur principal partage avec les secondaires sa clé d’habillage des données générées (utilisée pour chiffrer les messages entre les trois HSM) à l’aide d’une API sécurisée fournie par le fournisseur HSM. Au cours de cet échange, les HSM confirment qu’ils disposent du même certificat de propriétaire de partition, puis utilisent un schéma de Diffie-Hellman pour chiffrer les messages afin que le code du service Microsoft ne puisse pas les lire. Tout ce que le code de service peut faire est de transporter des objets blob opaques entre les HSM.
À ce stade, les trois instances sont prêtes à être exposées en tant que pool sur le réseau virtuel du client. Ils partagent le même certificat de propriétaire de partition et la même clé privée, la même clé de chiffrement des données et une clé d’habillage de données commune. Toutefois, chaque instance possède des informations d’identification uniques pour ses partitions HSM. Les dernières étapes sont maintenant terminées.
Chaque instance génère une paire de clés RSA et une demande de signature de certificat pour son certificat TLS public. Le CSR est signé par le système d’infrastructure à clé publique (PKI) Microsoft à l’aide d’une racine publique Microsoft, et le certificat TLS résultant est retourné à l’instance.
Les trois instances obtiennent leur propre clé de scellement Intel SGX à partir de leur processeur local. La clé est générée à l’aide de la propre clé unique du processeur et de la clé de signature de code du TEE.
Le pool dérive une clé de pool unique à partir des clés de scellement Intel SGX, chiffre tous ses secrets à l’aide de cette clé de pool, puis écrit les objets blob chiffrés sur le disque. Ces objets blob ne peuvent être déchiffrés qu’en étant signés par la même clé de scellement Intel SGX qui s’exécute sur le même processeur physique. Les secrets sont liés à cette instance spécifique.
Le processus de démarrage sécurisé est maintenant terminé. Ce processus a permis à la fois la création d’un pool HSM triple redondant et la création d’une garantie de chiffrement de la souveraineté des données client.
Gestion des contrats SLA de disponibilité au moment de l’exécution à l’aide de la réparation du service confidentiel
L’histoire de création de pool décrite dans cet article peut expliquer comment le service HSM managé est en mesure de fournir ses contrats SLA à haute disponibilité en gérant de manière sécurisée les serveurs qui sous-tendent le service. Imaginez qu’un serveur, un adaptateur HSM ou même l’alimentation du rack tombe en panne. L’objectif du service HSM managé est, sans intervention du client ou la possibilité d’exposer des secrets en texte clair en dehors du TEE, de rétablir le pool à trois instances saines. Le processus de guérison des services confidentiels permet d’y arriver.
Il commence par le HFC qui détecte les pools qui avaient des instances sur le serveur défaillant. HFC recherche de nouveaux serveurs sains dans la région du pool dans laquelle déployer les instances de remplacement. Il lance de nouvelles instances, qui sont ensuite traitées exactement comme une instance secondaire lors de l’étape d’approvisionnement initiale : initialiser le HSM, rechercher son instance principale, échanger en toute sécurité des secrets par TLS attesté, signer le HSM dans la hiérarchie de propriété, puis sceller ses données de service à son nouveau processeur. Le service est maintenant guéri, de manière entièrement automatique et confidentielle.
Récupération après sinistre à l’aide du domaine de sécurité
Le domaine de sécurité est un objet blob sécurisé qui contient toutes les informations d’identification nécessaires pour reconstruire la partition HSM à partir de zéro : la clé de propriétaire de la partition, les informations d’identification de la partition, la clé d’habillage des données, ainsi qu’une sauvegarde initiale du HSM. Avant que le service ne devienne actif, le client doit télécharger le domaine de sécurité en fournissant un ensemble de clés de chiffrement RSA pour le sécuriser. Les données de domaine de sécurité proviennent des TEE et sont protégées par une clé symétrique générée et une implémentation de l’algorithme de partage de secrets de Shamir, qui fractionne les partages de clés entre les clés publiques RSA fournies par le client en fonction des paramètres de quorum sélectionnés par le client. Au cours de ce processus, aucune clé de service ou aucune information d’identification n’est jamais exposée en texte clair en dehors du code de service qui s’exécute dans les TEE. Seul le client, en présentant un quorum de ses clés RSA au TEE, peut déchiffrer le domaine de sécurité pendant un scénario de récupération.
Le domaine de sécurité n’est nécessaire que lorsque, en raison d’une catastrophe, une région Azure entière est perdue et que Microsoft perd les trois instances du pool simultanément. Si une seule instance, voire deux instances, sont perdues, la réparation du service confidentiel récupérera silencieusement à trois instances saines sans intervention du client. Si la région entière est perdue, car les clés de scellement Intel SGX sont propres à chaque processeur, Microsoft n’a aucun moyen de récupérer les informations d’identification HSM et les clés de propriétaire de partition. Elles existent uniquement dans le contexte des instances.
Dans le cas extrêmement improbable où cette catastrophe se produit, le client peut récupérer l’état et les données précédents du pool en créant un pool vide, en l’injectant dans le domaine de sécurité, puis en présentant son quorum de clé RSA pour prouver la propriété du domaine de sécurité. Si un client a activé la réplication multirégion, la catastrophe encore plus improbable que les deux régions rencontrent une défaillance complète simultanée doit se produire avant qu’une intervention du client ne soit nécessaire pour récupérer le pool à partir du domaine de sécurité.
Contrôle de l’accès au service
Comme décrit, notre code de service dans le TEE est la seule entité qui a accès au HSM lui-même, car les informations d’identification nécessaires ne sont pas fournies au client ou à quiconque. Au lieu de cela, le pool du client est lié à son instance Microsoft Entra, ce qui est utilisé pour l’authentification et l’autorisation. Lors de l’approvisionnement initial, le client peut choisir un ensemble initial d’employés pour attribuer le rôle Administrateur pour le pool. Ces personnes, ainsi que les employés du rôle Administrateur général du locataire Microsoft Entra du client, peuvent définir des stratégies de contrôle d’accès au sein du pool. Toutes les stratégies de contrôle d’accès sont stockées par le service dans la même base de données que les clés masquées, qui sont également chiffrées. Seul le code de service dans le TEE a accès à ces stratégies de contrôle d’accès.
Résumé
Le HSM managé élimine la nécessité pour les clients de faire des compromis entre la disponibilité et le contrôle des clés de chiffrement à l’aide d’une technologie d’enclave confidentielle de pointe, soutenue par le matériel. Comme décrit dans cet article, dans cette implémentation, aucun représentant ou personnel Microsoft ne peut accéder au matériel de clé géré par le client ou aux secrets associés, même avec un accès physique aux machines hôtes HSM et HSM managés. Cette sécurité a permis à nos clients des services financiers, de la fabrication, du secteur public, de la défense et d’autres secteurs verticaux d’accélérer leurs migrations vers le cloud en toute confiance.