Résilience interrégionale pour SQL TDE avec Azure Key Vault Managed HSM

Azure SQL Managed Instance
Azure Key Vault

Idées de solution

Cet article présente une idée de solution. Votre architecte cloud peut s’appuyer sur ces conseils pour visualiser les principaux composants d’une implémentation typique de cette architecture. Utilisez cet article comme point de départ pour concevoir une solution bien conçue qui répond aux exigences spécifiques de votre charge de travail.

Cette solution décrit un modèle de déploiement sécurisé et résilient pour Azure SQL Managed Instance. Il met en évidence la façon dont Azure Key Vault Managed HSM est utilisé pour stocker les clés de protection TDE (Transparent Data Encryption) gérées par le client.

Architecture

Diagramme montrant l’architecture SQL Managed Instance sécurisée et résiliente.

Le diagramme comporte trois sections : une région primaire, une région secondaire et une section de ressources globales. Chacune des régions contient deux sous-réseaux et les régions sont identiques. Chaque sous-réseau de chaque région est placé entre un réseau virtuel. En haut de chaque sous-réseau est une icône de groupes de ressources. Chaque sous-réseau a un groupe de sécurité réseau. Un sous-réseau de chaque région contient SQL Managed Instance déployé entre les zones de disponibilité et Azure Policy au niveau de la limite de sous-réseau. L’autre sous-réseau de chaque région contient un point de terminaison privé HSM managé, un deuxième point de terminaison privé et un équilibreur de charge et un pool HSM managé en dehors du sous-réseau. À gauche de chaque région est une icône pour une zone DNS privée pour le HSM managé. La section ressources globales contient Traffic Manager. Un espace de travail Log Analytics se trouve entre les deux régions. Les flèches pointent vers cet espace de travail à partir du pool HSM managé dans chaque région. Cinq étapes numérotées identifient le flux de travail. À l’étape 1, une flèche représentant la réplication des données interrégions connecte SQL Managed Instance dans la région primaire à SQL Managed Instance dans la région secondaire. À l’étape 2, une flèche représentant la réplication interrégion connecte le pool HSM managé dans la région primaire au pool HSM managé dans la région secondaire. L’étape 3 est étiquetée plan de données. Dans cette étape, dans chaque région, une flèche montre le trafic qui transite de SQL Managed Instance par le biais du point de terminaison privé HSM managé vers Traffic Manager. À l’étape 4, Traffic Manager redirige vers le HSM managé le plus proche : une flèche de Traffic Manager pointe vers le pool HSM managé dans chaque région. L’étape 5 est étiquetée plan de gestion. Dans cette étape, dans chaque région, une flèche indique SQL Managed Instance’envoi de demandes de plan de gestion directement à Traffic Manager.

Téléchargez un fichier Visio de cette architecture.

Flux de travail

Le workflow suivant correspond au diagramme précédent :

  1. Un groupe de basculement sur l’instance managée SQL principale réplique toutes les bases de données utilisateur vers une instance managée SQL secondaire dans une autre région pour la récupération d’urgence.

  2. Le HSM managé est configuré avec un pool interrégion. Ce pool réplique automatiquement le matériel de clé et les autorisations sur le coffre dans la région secondaire.

  3. Le trafic du plan de données à partir de SQL Managed Instance transite par le point de terminaison privé du HSM managé.

  4. Le HSM managé utilise une instance de Azure Traffic Manager gérée par Microsoft pour router le trafic vers le coffre opérationnel le plus proche.

  5. Si l’instance managée doit vérifier les autorisations sur une clé, elle envoie une demande de plan de gestion sur le réseau principal Azure.

Composants

  • SQL Managed Instance est une offre PaaS (Platform as a Service) qui est presque entièrement compatible avec le moteur de base de données SQL Server Êdition Entreprise le plus récent. Il fournit une implémentation de réseau virtuel native qui améliore la sécurité et fournit un modèle d’entreprise bénéfique pour les clients SQL Server existants. Vous pouvez utiliser SQL Managed Instance pour migrer vos applications locales vers le cloud avec des modifications minimales apportées aux applications et aux bases de données.

    SQL Managed Instance fournit également des fonctionnalités PaaS complètes, notamment les mises à jour correctives automatiques et les mises à jour de version, les sauvegardes automatisées et les fonctionnalités de continuité d’activité. Ces fonctionnalités réduisent considérablement la surcharge de gestion et le coût total de possession. Dans cette architecture, SQL Managed Instance est la base de données qui utilise les clés de protection TDE.

  • Le HSM managé est un service cloud entièrement managé qui fournit une haute disponibilité, une location unique et une conformité aux normes du secteur. Le HSM managé est conçu pour protéger les clés de chiffrement pour les applications cloud. Il utilise les normes de traitement des informations fédérales 140-3 niveau 3 validés par les modules HSM. Le HSM managé est l’une des solutions de gestion des clés dans Azure. Dans cette architecture, Managed HSM stocke en toute sécurité les clés de protection TDE et fournit une résilience interrégion.

  • Un point de terminaison privé Azure fournit un chemin d’accès IP privé à partir d’un réseau virtuel vers des services tels que stockage Azure, Azure SQL Database et Key Vault. Pour cette architecture, désactivez l’accès au réseau public sur le HSM managé et utilisez des points de terminaison privés dans les deux régions afin que le trafic du plan de données reste sur le réseau principal Microsoft.

  • Azure DNS privé fournit une résolution de noms pour les points de terminaison privés, ce qui permet aux ressources au sein d’un réseau virtuel d’accéder Azure services en privé. Lorsqu’un point de terminaison privé est créé, un enregistrement DNS (Domain Name System) correspondant est automatiquement inscrit dans la zone DNS privée liée. Une zone DNS privée garantit que le trafic vers le service reste dans le réseau principal Azure. Cette approche améliore la sécurité, les performances et la conformité en évitant l’exposition à l’Internet public. Si une panne de service régional se produit, Azure DNS privé fournit une résilience native de résolution de noms interrégion pour le HSM managé. Dans cette architecture, les services utilisent azure DNS privé pour communiquer entre eux via leurs adresses réseau privées.

  • Azure Policy évalue les ressources et les actions dans Azure en comparant les propriétés de ces ressources aux règles d’entreprise. Ces règles d’entreprise, décrites au format JSON, sont appelées définitions de stratégie. Pour cette solution, utilisez Azure Policy pour appliquer le TDE géré par le client lors de la création ou de la mise à jour d’une base de données Azure SQL ou d’une instance managée Azure SQL, conformément aux instructions documentées.

  • Log Analytics’espace de travail est un magasin de données dans lequel vous pouvez collecter n’importe quel type de données de journal à partir de toutes vos ressources et applications Azure et non Azure. Les options de configuration de l’espace de travail vous permettent de gérer toutes vos données de journal dans un espace de travail pour répondre aux besoins d’opérations, d’analyse et d’audit de différents personnages de votre organisation. Pour cette solution, un espace de travail Log Analytics reçoit une journalisation et des données de télémétrie complètes à partir du HSM managé.

Détails du scénario

Dans cette solution, une équipe de charge de travail souhaite respecter des seuils d’objectif de niveau de service (SLO) stricts pour son système stratégique tout en garantissant une fonctionnalité complète des services requis. Pour atteindre cet objectif, ils utilisent SQL Managed Instance avec une clé de protecteur TDE gérée par le client. La clé est stockée dans un pool HSM managé qui prend en charge les régions qu’ils utilisent et répond à toutes les exigences de conformité et de sécurité. L’accès au point de terminaison privé est également appliqué pour limiter l’exposition réseau.

Pour la récupération d’urgence inter-régions, un groupe de basculement avec une stratégie de basculement gérée par le client est généralement préféré afin que le client puisse contrôler le minutage du basculement. Le groupe de basculement réplique les bases de données utilisateur en tant qu’unité, de sorte que les objets et les paramètres au niveau de l’instance associés doivent être synchronisés séparément.

Cas d’usage potentiels

  • Une organisation utilise deux régions jumelées ou non souhaitées. L’instance managée SQL principale se trouve dans une région et les groupes de basculement sont configurés pour la connecter à l’instance managée SQL dans la région secondaire.

    Cette conception utilise des points de terminaison d’écouteur de groupe de basculement afin que les applications puissent conserver des chaînes de connexion stables pendant le basculement. Les groupes de basculement mettent à jour automatiquement l’enregistrement DNS de l’écouteur après un géo-basculement. Toutefois, l’heure de reconnexion observée sur le client dépend de la durée de vie du cache DNS du client et de la logique de nouvelle tentative d’application.

  • Une organisation utilise une instance HSM managée dans une région primaire avec un réplica interrégion dans une région secondaire. Lorsqu'un réplica interrégional est activé, une instance de Traffic Manager est créée. L’instance Traffic Manager gère le routage du trafic vers le coffre local si les deux coffres sont opérationnels ou vers le coffre opérationnel si un coffre n’est pas disponible.

    La réplication du matériel et des autorisations de clé est asynchrone et peut prendre plusieurs minutes. L’extension initiale vers une région secondaire prend du temps d’approvisionnement supplémentaire. Validez la disponibilité et la capacité du HSM managé dans les régions souhaitées avant de finaliser la conception de résilience.

  • Une organisation utilise deux zones DNS personnalisées pour prendre en charge un point de terminaison privé pour une instance HSM managée dans chaque région.

    Dans les déploiements multirégions, un point de terminaison privé et une intégration DNS privée dans chaque région permettent de conserver le trafic de résolution de noms et de plan de données dans chaque région.

  • Une organisation active TDE sur les bases de données utilisateur avec une clé gérée par le client et stocke la clé de protecteur dans le HSM managé.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteurs principaux :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes