Fiabilité dans azure Key Vault Managed HSM

Azure Key Vault Managed HSM 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 des modules de sécurité matériel validés FIPS 140-3 de niveau 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 est résilient à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les défaillances matérielles et les pannes de région. Il décrit également comment vous pouvez utiliser des sauvegardes et le domaine de sécurité pour récupérer à partir d’autres types de problèmes, de fonctionnalités de récupération pour empêcher la suppression accidentelle et met en évidence certaines informations clés sur le contrat de niveau de service HSM managé (SLA).

Recommandations de déploiement de production pour la fiabilité

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, qui est également parfois appelée pool.

Le HSM managé est conçu pour la haute disponibilité et la durabilité grâce à son architecture :

  • Isolation à locataire unique : 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 (par exemple, l’alimentation ou le commutateur réseau d’un rack) 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. Le personnel Microsoft, y compris ceux disposant d’un accès physique aux serveurs, ne peut pas accéder à votre matériel de clé de chiffrement.

  • Réparation 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 plus d’informations sur la façon dont 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 pour la 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.

Important

Sans le domaine de sécurité, la récupération d’urgence n’est pas possible. Microsoft n’a aucun moyen de récupérer le domaine de sécurité et ne peut pas accéder à vos clés sans celui-ci.

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 de manière sécurisée : 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 gapé (par exemple, 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 à plusieurs personnes : 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 une logique de nouvelle tentative lorsqu'ils interagissent directement avec le HSM managé, notamment les politiques de réessai avec retrait exponentiel.

  • 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é. Pour les opérations de clé publique telles que le chiffrement, l’habillage et la vérification, effectuez ces opérations 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 empêche les erreurs temporaires d'interrompre ces opérations.

Si vous utilisez un HSM managé dans des scénarios à haut débit, notez que le HSM managé 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 de grandes quantités de données, utilisez une hiérarchie de clés où seule la clé de chiffrement de clé (KEK) est stockée dans le HSM managé et utilisée pour encapsuler les clés de niveau inférieur stockées dans un autre emplacement de stockage de clé sécurisée.

Pour obtenir des repères de performances détaillés et des conseils de planification de la capacité, consultez Conseils de mise à l’échelle du HSM managé Azure.

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.

Diagramme montrant les trois partitions d’un pool HSM managé, chacune sur un serveur physique distinct et dans un rack de serveur différent.

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 d’enclaves TLS et Intel SGX attestées pour protéger les secrets pendant la récupération.

Coûts

Il n’existe aucun coût supplémentaire associé à la haute disponibilité intégrée dans le HSM managé. La tarification est basée sur le nombre de pools HSM et le nombre d’opérations effectuées. 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, les requêtes sont distribuées de manière transparente entre les partitions.

  • Réplication des données : toutes les données, notamment les clés, les attributions de rôles et les stratégies de contrôle d’accès, sont répliquées de manière synchrone sur les trois partitions. Cela 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é est responsable de la détection des défaillances de partition et de leur réponse automatique. Vous n’avez pas besoin d’effectuer d’action pendant une défaillance de partition.

  • Demandes actives : lors d’un échec de partition, les demandes en cours vers 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 pendant 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 à 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é de HSM managée 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 zones 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.

Si vous devez être résilient aux pannes au niveau du centre de données ou de la zone de disponibilité, envisagez d’utiliser l’une des approches de 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

Managed HSM prend en charge la réplication multirégion facultative, ce qui vous permet d’étendre un pool HSM managé d’une région Azure (la région primaire) à une deuxième région Azure (la région étendue). Une fois configuré :

  • Les deux régions sont actives et capables de traiter les demandes.
  • Les éléments clés, les rôles et les autorisations sont répliqués automatiquement entre les régions.
  • Les demandes sont acheminées vers la région la plus proche disponible à l’aide d’Azure Traffic Manager.
  • Le SLA combiné s'améliore.

Requirements

  • Prise en charge de la région : toutes les régions HSM managées Azure sont prises en charge 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 un deuxième pool HSM est consommé dans la région étendue. Pour plus d’informations, consultez tarification des HSM gérés Azure.

Configurer la réplication multirégion

Comportement lorsque toutes les régions sont saines

Lorsque la réplication multirégion est activée 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 Private Link, 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

Lorsque la réplication multirégion est activée et qu’une région subit une panne :

  • Détection et réponse : Azure Traffic Manager détecte la région non saine et achemine les demandes 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 des 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 : il peut y avoir une perte de données pour les modifications apportées dans les six minutes avant l’échec de la région si ces modifications n’avaient pas terminé la réplication.

  • 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. Traffic Manager commence à acheminer 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. Cela nécessite :

  • 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.

Important

Le nouveau HSM a un autre nom et un URI de point de terminaison de service. Vous devez mettre à jour la configuration de votre application pour utiliser le nouvel emplacement.

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é dans un compte de stockage Azure sur lequel le stockage géoredondant (GRS) est activé.

Les sauvegardes sont chiffrées à l’aide de clés de chiffrement associées au domaine de sécurité du HSM et peuvent uniquement être restaurées 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 : lorsque vous supprimez un HSM ou une clé, il reste récupérable pour une période de rétention configurable (7 à 90 jours, 90 jours par défaut). 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 le vidage : lorsqu’elle est activée, empêche la suppression définitive de votre HSM géré et de ses clés jusqu’à ce que le délai de conservation se soit écoulé. 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 :

  • Les partitions peuvent être temporairement indisponibles pendant l’application des 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 guérison du service confidentiel assure que les secrets ne sont jamais révélés 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 géré fournit un SLA standard pour les déploiements monorégion. Lorsque vous activez la réplication multirégion, le contrat SLA combiné pour les deux régions augmente.

Contenu connexe

  • Last updated on