Fiabilité dans azure Key Vault Managed HSM

Azure Key Vault HSM managé est un service cloud entièrement géré, hautement disponible, à locataire unique et conforme aux normes, qui vous permet de protéger les clés de chiffrement pour vos applications cloud à l’aide de modules de sécurité matériels (HSM) validés au niveau FIPS 140-3. Le HSM managé fournit une gamme de fonctionnalités de fiabilité intégrées pour vous assurer que vos clés restent disponibles.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft offre une gamme de fonctionnalités permettant de prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article décrit comment Managed HSM offre une résilience face à diverses pannes et problèmes potentiels, notamment les défaillances temporaires, les défaillances de partition et les pannes régionales. Il décrit également comment utiliser des sauvegardes et le domaine de sécurité pour la récupération d’urgence, comment les fonctionnalités de récupération protègent contre la suppression accidentelle et les informations clés sur le contrat de niveau de service HSM managé (SLA).

Recommandations concernant le déploiement de production

Pour les charges de travail de production, nous vous recommandons de :

Vue d’ensemble de l’architecture de fiabilité

Lorsque vous utilisez un HSM managé, vous déployez une instance, parfois appelée pool.

L’architecture du HSM managé est conçue pour la haute disponibilité et la durabilité.

• Isolation monolocataire : Chaque instance HSM managée est dédiée à un seul client et se compose d’un cluster de plusieurs partitions HSM isolées par chiffrement.

• Partitions triples redondantes : Un pool HSM managé se compose de trois partitions HSM à charge équilibrée réparties entre des racks distincts au sein d’un centre de données. Cette distribution fournit une redondance contre les défaillances matérielles et garantit que la perte d’un composant unique, tel que l’alimentation d’un rack ou le commutateur réseau, n’affecte pas toutes les partitions.

• Informatique confidentielle : Chaque instance de service s’exécute dans un environnement d’exécution approuvé (TEE) qui utilise des enclaves Intel SGX. Microsoft personnel, y compris les personnes disposant d'un accès physique aux serveurs, ne peuvent pas accéder à votre matériel de clé de chiffrement.

• Guérison automatique : Si une défaillance matérielle ou un autre problème affecte l’une des trois partitions, le service régénère automatiquement la partition affectée sur du matériel sain sans intervention du client et sans exposer de secrets.

Pour savoir comment Managed HSM implémente ces fonctionnalités, consultez La souveraineté, la disponibilité, les performances et l’extensibilité clés dans Managed HSM.

Domaine de sécurité

Le domaine de sécurité est un composant essentiel du HSM managé à des fins de récupération d’urgence. Il s’agit d’un objet blob chiffré qui contient toutes les informations d’identification nécessaires pour reconstruire une instance HSM managée à partir de zéro, y compris la clé de propriétaire de partition, les informations d’identification de partition, la clé d’habillage des données et une sauvegarde initiale du HSM.

Les domaines de sécurité font partie intégrante de la sécurité et de la fiabilité de votre HSM managé. Nous vous recommandons de suivre ces bonnes pratiques :

• Générez des clés en toute sécurité : Pour les environnements de production, générez les paires de clés RSA qui protègent le domaine de sécurité dans un environnement air-gapped, tel qu’un HSM local ou une station de travail isolée.

• Stocker hors connexion : Stockez des clés de domaine de sécurité sur des lecteurs USB chiffrés ou un autre stockage hors connexion, avec chaque partage de clés sur un appareil distinct dans des emplacements géographiques distincts.

• Établissez un quorum multipersonn : Utilisez au moins trois titulaires de clés pour empêcher toute personne unique d’avoir accès à toutes les clés de quorum et d’éviter toute dépendance vis-à-vis d’une seule personne.

Pour plus d’informations, consultez La vue d’ensemble du domaine de sécurité dans managed HSM.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

Lorsque vous utilisez des services Azure qui s’intègrent à Managed HSM, ces services gèrent automatiquement les erreurs temporaires.

Si vous créez des applications personnalisées qui s’intègrent à Managed HSM, tenez compte des meilleures pratiques suivantes pour gérer les erreurs temporaires susceptibles de se produire :

• Utilisez les kits SDK fournis par Microsoft pour Azure Key Vault, qui incluent des mécanismes de nouvelle tentative intégrés. Les kits SDK sont disponibles pour .NET, Python et JavaScript.

• Implémentez la logique de nouvelle tentative, y compris l’interruption exponentielle, pour tout code qui interagit directement avec le HSM managé.

• Réduisez le nombre de dépendances directes sur le HSM managé. Mettre en cache les résultats des opérations cryptographiques lorsque c'est possible pour réduire les requêtes directes vers le HSM géré. Effectuez des opérations à clé publique, telles que le chiffrement, l’habillage et la vérification, localement en mettant en cache le matériel de clé publique. L’exécution des opérations localement réduit la dépendance à votre HSM managé et réduit la probabilité d’interruptions temporaires de ces opérations.

Si vous utilisez un HSM managé dans des scénarios à haut débit, managed HSM ne limite pas les opérations de chiffrement. Il utilise son matériel HSM à pleine capacité. Chaque instance HSM managée a trois partitions. Pendant les opérations de maintenance ou de réparation, une partition peut être indisponible. Pour la planification de la capacité, supposons que deux partitions sont disponibles. Si vous avez besoin d’un débit garanti, planifiez en fonction d’une partition disponible. Surveillez la métrique de disponibilité HSM managée pour comprendre l’intégrité du service.

Pour mettre à l’échelle le chiffrement pour les volumes de données volumineux, utilisez une hiérarchie de clés. Stockez uniquement la clé de chiffrement de clés (KEK) dans Managed HSM et utilisez-la pour encapsuler les clés de chiffrement de données de niveau inférieur stockées ailleurs dans un stockage de clés sécurisé.

Pour plus d’informations sur les benchmarks de performances et la planification de la capacité, consultez Azure conseils de mise à l’échelle du HSM managé.

Résilience aux échecs de partition

Le HSM managé atteint une haute disponibilité via son architecture triple redondante, où chaque pool HSM se compose de trois partitions HSM réparties entre des racks de serveur distincts au sein d’un centre de données. Cette distribution au niveau du rack fournit une redondance contre les défaillances matérielles localisées.

Lorsque des défaillances matérielles ou des pannes localisées se produisent, le HSM managé redirige automatiquement vos demandes vers des partitions saines et reconstruit les partitions affectées par le biais d’un processus appelé réparation du service confidentiel. Les partitions ayant échoué sont automatiquement reconstruites sur du matériel sain à l’aide des enclaves TLS et Intel SGX attestées pour protéger les secrets pendant la récupération.

Coûts

La haute disponibilité intégrée dans managed HSM n’ajoute aucun coût supplémentaire. La tarification est basée sur le nombre de pools HSM et le nombre d’opérations que vous effectuez. Pour plus d’informations, consultez tarification des HSM gérés Azure.

Comportement lorsque toutes les partitions sont saines

Cette section décrit ce à quoi s’attendre lorsque les pools HSM managés sont opérationnels et qu’aucune partition n’est indisponible.

• Routage du trafic : Le HSM managé gère automatiquement le routage du trafic sur ses trois partitions. Pendant les opérations normales, il distribue en toute transparence les requêtes entre les partitions.

• Réplication des données : Managed HSM réplique de manière synchrone toutes les données, notamment les clés, les attributions de rôles et les stratégies de contrôle d’accès, sur les trois partitions. Cette approche garantit la cohérence et la disponibilité même si une partition devient indisponible.

Comportement lors d’une défaillance de partition

Cette section décrit ce qu’il faut attendre quand une ou plusieurs partitions deviennent indisponibles.

• Détection et réponse : Le service HSM managé détecte les défaillances de partition et y répond automatiquement. Vous n’avez pas besoin d’effectuer d’action pendant une défaillance de partition.

• Demandes actives : Lors d’un échec de partition, les requêtes en cours d’exécution à la partition affectée peuvent échouer et exiger que les applications clientes les réessayent. Pour réduire les effets des pannes de partition, les applications clientes doivent suivre les pratiques de gestion des erreurs temporaires.

• Perte de données attendue : Aucune perte de données n’est attendue lors d’une défaillance de partition en raison de la réplication synchrone entre les partitions.

• Temps d’arrêt attendu : Pour les opérations de lecture et la plupart des opérations de chiffrement, il doit y avoir un temps d’arrêt minimal ou aucun temps d’arrêt pendant une défaillance de partition. Les partitions saines restantes continuent de répondre aux requêtes.

• Réacheminement du trafic : Le HSM managé réachemine automatiquement le trafic de la partition affectée vers des partitions saines sans nécessiter d’intervention du client.

Récupération de partition

Lorsque la partition affectée récupère, Managed HSM rétablit automatiquement les opérations par le biais du rétablissement du service confidentiel. Ce processus :

1. Crée une instance de service sur du matériel sain.
2. Établit une connexion TLS attestée avec la partition principale.
3. Échange en toute sécurité des informations d’identification et du matériel de chiffrement.
4. Scelle les données de service au nouveau processeur.

La plateforme Azure gère entièrement ce processus et ne nécessite aucune intervention du client.

Résilience aux échecs de zone de disponibilité

La haute disponibilité dans managed HSM est basée sur la distribution au niveau du rack au sein d’un centre de données, et non sur le déploiement de zone de disponibilité explicite. Chaque partition s’exécute sur un serveur distinct dans un rack différent, qui protège contre les défaillances au niveau du rack, telles que les problèmes d’alimentation ou de commutateur réseau.

Pour vous protéger contre les pannes à l’échelle du centre de données ou à l’échelle de la zone de disponibilité, utilisez l’une des approches décrites dans Résilience aux défaillances à l’échelle de la région.

Résilience aux défaillances à l’échelle de la région

Les ressources HSM managées sont déployées dans une seule région Azure. Si la région devient indisponible, votre HSM managé est également indisponible. Toutefois, il existe des approches que vous pouvez utiliser pour garantir la résilience aux pannes de région.

Réplication multirégion

Le HSM managé prend en charge la réplication multirégion facultative, que vous pouvez utiliser pour étendre un pool HSM managé d’une région Azure (la région primaire) à une deuxième région Azure (la région étendue). Lorsque vous configurez cette fonctionnalité :

• Les deux régions sont actives et peuvent traiter des demandes.
• Les éléments clés, les rôles et les autorisations sont répliqués automatiquement entre les régions.
• Azure Traffic Manager achemine les demandes vers la région disponible la plus proche.
• Le SLA combiné s'améliore.

Requirements

• Prise en charge de la région : Toutes les régions qui prennent en charge le HSM managé peuvent être utilisées en tant que régions primaires. Il n’existe aucune dépendance vis-à-vis des jumelages de régions Azure.

  Le HSM managé ne prend pas en charge toutes les régions en tant que régions étendues. Pour plus d’informations, consultez la prise en charge de la région Azure.

• Nombre maximal de régions : Vous pouvez ajouter une région étendue, pour un maximum de deux régions au total.

Coûts

La réplication multirégion entraîne une facturation supplémentaire, car la région étendue consomme un deuxième pool HSM. Pour plus d’informations, consultez tarification des HSM gérés Azure.

Configurer la réplication multirégion

• Ajoutez une région étendue : Pour plus d’informations sur l’ajout d’une région étendue à une région primaire existante, consultez Étendre un HSM principal dans une région étendue.

  L’extension d’un HSM managé vers une autre région peut prendre jusqu’à 30 minutes.

• Supprimez une région étendue : Pour plus d’informations sur la suppression d’une région étendue d’une région primaire existante, consultez Supprimer une région étendue du HSM principal.

Comportement lorsque toutes les régions sont saines

Cette section décrit ce que vous devez attendre lorsque vous configurez la réplication multirégion et que les deux régions sont opérationnelles.

• Routage du trafic : Toutes les régions peuvent traiter les demandes. Azure Traffic Manager achemine les demandes vers la région avec la proximité géographique la plus proche ou la latence la plus faible.

  Si vous utilisez Azure Private Link pour accéder au HSM managé, configurez des points de terminaison privés dans les deux régions pour un routage optimal pendant le basculement. Pour plus d’informations, consultez Le comportement de liaison privée avec la réplication multirégion.

• Réplication des données : Toutes les modifications apportées aux clés, aux définitions de rôles et aux attributions de rôles sont répliquées de manière asynchrone dans la région étendue dans les six minutes. Patientez six minutes après la création ou la mise à jour d’une clé avant de l’utiliser dans la région étendue.

Comportement lors d’une défaillance de région

Cette section décrit à quoi vous attendre lorsque vous configurez la réplication multirégion et qu’une panne survient dans l’une des régions répliquées.

• Détection et réponse : Azure Traffic Manager détecte la région non saine et achemine les requêtes futures vers la région saine. Les enregistrements DNS ont une durée de vie de cinq secondes, même si les clients mettant en cache les recherches DNS peuvent rencontrer des temps de basculement légèrement plus longs.

• Notification: Microsoft ne vous avertit pas automatiquement lorsqu’une région est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de région, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

• Demandes actives : Les demandes en cours d’exécution vers la région affectée peuvent échouer et nécessiter une nouvelle tentative.

• Perte de données attendue : Les modifications apportées au cours des six minutes précédant la défaillance de la région risquent de ne pas être répliquées dans la région étendue. Ces modifications peuvent être perdues si la région primaire n’est pas récupérable.

• Temps d’arrêt attendu : Les opérations de lecture et d’écriture restent disponibles dans la région saine pendant le basculement.

  Les applications clientes proches de la région non saine peuvent continuer à être dirigées vers cette région jusqu’à ce que les enregistrements DNS soient mis à jour, mais cette mise à jour a lieu dans un délai d’environ cinq secondes. Pour réduire le temps de basculement, les clients doivent éviter de mettre en cache les recherches DNS plus longtemps que la durée de vie de l’enregistrement DNS.

• Réacheminement: Azure Traffic Manager redirige automatiquement les requêtes vers la région saine.

Récupération de région

Lorsque la région affectée récupère, managed HSM reprend automatiquement les opérations. Azure Traffic Manager commence à acheminer à nouveau les demandes vers les deux régions en fonction de la proximité.

Tester les défaillances régionales

HSM géré de manière entièrement autonome s'occupe du routage du trafic, de la redondance et de la restauration automatique en cas de défaillances régionales. Vous n’avez donc pas besoin de valider les processus liés aux défaillances régionales ou d’apporter d'autres informations.

Solutions multirégions personnalisées pour la résilience

Si la réplication multirégion n’est pas adaptée à vos besoins, vous pouvez implémenter une récupération d’urgence manuelle. Cette approche nécessite les éléments suivants :

• Domaine de sécurité du HSM source.
• Clés privées (au moins le numéro de quorum) qui chiffrent le domaine de sécurité.
• Une sauvegarde HSM complète récente provenant du HSM source.

Pour effectuer une récupération d’urgence :

1. Créez une instance HSM managée dans une autre région.
2. Activez le mode de récupération du domaine de sécurité et chargez le domaine de sécurité.
3. Effectuez une sauvegarde du nouveau HSM (requis avant la restauration).
4. Restaurez la sauvegarde à partir du HSM source.

Pour obtenir des procédures détaillées de récupération d’urgence, consultez La récupération d’urgence HSM managée.

Sauvegarde et restauration

Le module HSM managé prend en charge la sauvegarde et la restauration complètes de toutes les clés, versions, attributs, balises et attributions de rôles. Les sauvegardes sont stockées dans un compte de stockage Azure. Si votre région la prend en charge, nous vous recommandons de sauvegarder votre HSM managé sur un compte stockage Azure sur lequel le stockage géoredondant (GRS) est activé.

Le module HSM chiffre les sauvegardes à l’aide de clés de chiffrement associées au domaine de sécurité du HSM. Vous pouvez uniquement restaurer des sauvegardes sur un HSM avec le même domaine de sécurité.

Le HSM managé ne prend pas en charge la planification des sauvegardes, mais vous pouvez créer votre propre planificateur à l’aide d’un service tel qu’Azure Functions ou Azure Automation.

Bien qu’une sauvegarde soit en cours, le HSM peut ne pas fonctionner à plein débit, car certaines partitions sont occupées à effectuer l’opération de sauvegarde.

Pour obtenir des procédures détaillées de sauvegarde et de restauration, consultez Sauvegarde et restauration complètes.

Résilience à la suppression accidentelle

Le HSM managé fournit deux fonctionnalités de récupération clés pour empêcher la suppression accidentelle ou malveillante.

• Suppression réversible : Les modules HSM et clés supprimés ne sont pas immédiatement vidés. Ils restent récupérables pendant une période de rétention configurable de 7 à 90 jours (valeur par défaut : 90 jours). La suppression réversible est toujours activée et ne peut pas être désactivée.

  Note

  Les ressources HSM managées supprimées temporairement continuent de générer des frais jusqu’à ce qu’elles soient purgées.

• Protection contre la purge : Lorsqu’elle est activée, elle empêche la suppression définitive de votre module HSM managé et de ses clés jusqu’à l’expiration de la période de rétention. La protection contre le vidage ne peut pas être désactivée ou remplacée par n’importe qui, y compris Microsoft.

Nous vous recommandons vivement d’activer la protection contre la purge pour les environnements de production. Pour plus d’informations, consultez Suppression réversible et protection contre la purge des HSM managés.

Résilience à la maintenance du service

Le HSM managé gère la maintenance du service, notamment les mises à jour du microprogramme, la mise à jour corrective et la réparation matérielle, sans intervention du client. Pendant la maintenance :

• Le service peut temporairement rendre les partitions indisponibles pendant qu’elle applique les mises à jour.
• Au moins deux de trois partitions restent disponibles pendant la maintenance courante.
• Vos applications clientes doivent implémenter une logique de nouvelle tentative pour gérer de brèves interruptions.

Le processus de réparation du service confidentiel garantit que le service n’expose jamais les secrets pendant les opérations de maintenance.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les SLA pour les services en ligne.

Le HSM managé fournit un contrat SLA de disponibilité standard pour les déploiements à une seule région. L’activation de la réplication multirégion augmente la disponibilité globale attendue, car les requêtes peuvent être traitées par l’une ou l’autre des régions si l’une d’elles devient indisponible.

Contenu connexe

• Qu’est-ce qu’Azure Key Vault Managed HSM ?
• Activer la réplication multirégion
• Récupération d’urgence pour HSM managé
• Sauvegarde et restauration complètes
• Vue d’ensemble du domaine de sécurité dans managed HSM
• Suppression douce et protection contre la purge des HSM managés
• Guide de mise à l'échelle du HSM managé Azure
• Qu’est-ce que la documentation sur la fiabilité d’Azure ?