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

Le diagramme comprend deux sections clés, la région primaire et la région secondaire. La région primaire a une sous-section qui inclut SQL Managed Instance, les zones de disponibilité et un sous-réseau avec un groupe de sécurité réseau (NSG). La région principale comporte une autre sous-section qui inclut un sous-réseau avec un groupe de sécurité réseau (NSG), un point de terminaison privé principal de la région pour un HSM managé, un autre point de terminaison privé, un équilibreur de charge et un pool HSM managé. Chaque sous-section possède un réseau virtuel et des groupes de ressources. Une zone DNS privée pour mHSM se trouve également dans la région primaire. La région secondaire réplique les ressources de la région primaire. Une flèche intitulée plan de gestion pointe de SQL Managed Instance vers Traffic Manager dans la section ressources globales externes. Une flèche étiquetée réplication de données interrégions pointe de la sous-section SQL Managed Instance dans la région primaire vers la même sous-section de la région secondaire. Flèche étiquetée "réplication interrégions" allant de la sous-section du pool HSM managé dans la région primaire vers la même sous-section dans la région secondaire. Dans chaque région, une flèche étiquetée "plan de données" pointe de l'instance gérée SQL vers le point de terminaison privé, puis vers Traffic Manager. Dans chaque région, un plan de gestion étiqueté de flèche pointe de SQL Managed Instance vers Traffic Manager. Dans chaque région, une flèche pointe de Traffic Manager vers le pool HSM managé, ce qui indique que Traffic Manager redirige vers le MHSM le plus proche.

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

Flux de travail

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

1. SQL Managed Instance est configuré avec des groupes de disponibilité dans la région secondaire non souhaitée pour répliquer les données 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 non souhaitée.

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 Azure Traffic Manager pour acheminer 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 dernier moteur de base de données SQL Server Enterprise Edition. 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 la mise à jour automatique des correctifs et des versions, les sauvegardes automatisées et la haute disponibilité. 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 des modules matériels de sécurité (HSM) validés FIPS 140-2 niveau 3. Le HSM managé est l’une des solutions de gestion de 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 sert d’interface réseau qui connecte en toute sécurité des services PaaS, tels que Stockage Azure, Azure SQL Database et Azure Key Vault à un réseau virtuel via une adresse IP privée. Cette fonctionnalité élimine la nécessité d’une exposition à Internet public, ce qui améliore la sécurité en conservant le trafic au sein du réseau principal Azure. Il utilise également le réseau virtuel client pour une protection supplémentaire. Dans cette architecture, un point de terminaison privé Azure garantit que le trafic entre les services transite par un réseau virtuel privé.

• Azure Private DNS fournit une résolution de noms transparente pour les points de terminaison privés, ce qui permet aux ressources au sein d’un réseau virtuel d’accéder aux services Azure en privé. Il leur permet d’utiliser des noms de domaine complets au lieu d’adresses IP publiques, ce qui améliore la sécurité et l’accessibilité. 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 Private DNS fournit une résilience native de résolution de noms interrégion pour le HSM managé. Dans cette architecture, les services utilisent azure Private DNS pour communiquer entre eux via leurs adresses réseau privées.

Détails du scénario

Dans cette solution, un client vise à 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 répertoriés. 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 coffre qui soutient les régions qu'ils ont choisies et répond à toutes les exigences de conformité et de sécurité. L’accès au point de terminaison privé est également appliqué pour une protection renforcée.

Cas d’usage potentiels

• Un client utilise deux régions jumelées ou non jumelé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.

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

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

• Un TDE activé par le client sur les bases de données utilisateur utilise un modèle de clé gérée par le client et stocke une clé de protection dans le HSM géré.

• Un client utilise cette conception pour fournir la résilience maximale possible.

Contributeurs

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

Auteurs principaux :

• Laura Grob | Architecte de solution cloud principal
• Armen Kaleshian | Architecte de solution cloud principal
• Michael Piskorski | Architecte de solution cloud senior

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

Étapes suivantes

• Guide complet du HSM managé pour les industries réglementées
• Rôles intégrés de contrôle d’accès en fonction du rôle local pour le HSM managé
• Activer la réplication multirégion sur un HSM managé
• Configurer un HSM managé avec des points de terminaison privés
• Vue d’ensemble de la récupération HSM managée
• Souveraineté, disponibilité, performances et scalabilité clés dans le HSM managé
• Meilleures pratiques pour la sécurisation du HSM managé
• Vue d’ensemble de la sécurité de Key Vault
• À propos des clés Key Vault
• Générer et transférer des clés protégées par HSM
• Disponibilité et redondance de 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

Le diagramme comprend deux sections clés, la région primaire et la région secondaire. La région primaire a une sous-section qui inclut SQL Managed Instance, les zones de disponibilité et un sous-réseau avec un groupe de sécurité réseau (NSG). La région principale comporte une autre sous-section qui inclut un sous-réseau avec un groupe de sécurité réseau (NSG), un point de terminaison privé principal de la région pour un HSM managé, un autre point de terminaison privé, un équilibreur de charge et un pool HSM managé. Chaque sous-section possède un réseau virtuel et des groupes de ressources. Une zone DNS privée pour mHSM se trouve également dans la région primaire. La région secondaire réplique les ressources de la région primaire. Une flèche intitulée plan de gestion pointe de SQL Managed Instance vers Traffic Manager dans la section ressources globales externes. Une flèche étiquetée réplication de données interrégions pointe de la sous-section SQL Managed Instance dans la région primaire vers la même sous-section de la région secondaire. Flèche étiquetée "réplication interrégions" allant de la sous-section du pool HSM managé dans la région primaire vers la même sous-section dans la région secondaire. Dans chaque région, une flèche étiquetée "plan de données" pointe de l'instance gérée SQL vers le point de terminaison privé, puis vers Traffic Manager. Dans chaque région, un plan de gestion étiqueté de flèche pointe de SQL Managed Instance vers Traffic Manager. Dans chaque région, une flèche pointe de Traffic Manager vers le pool HSM managé, ce qui indique que Traffic Manager redirige vers le MHSM le plus proche.

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

Flux de travail

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

1. SQL Managed Instance est configuré avec des groupes de disponibilité dans la région secondaire non souhaitée pour répliquer les données 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 non souhaitée.

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 Azure Traffic Manager pour acheminer 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 dernier moteur de base de données SQL Server Enterprise Edition. 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 la mise à jour automatique des correctifs et des versions, les sauvegardes automatisées et la haute disponibilité. 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 des modules matériels de sécurité (HSM) validés FIPS 140-2 niveau 3. Le HSM managé est l’une des solutions de gestion de 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 sert d’interface réseau qui connecte en toute sécurité des services PaaS, tels que Stockage Azure, Azure SQL Database et Azure Key Vault à un réseau virtuel via une adresse IP privée. Cette fonctionnalité élimine la nécessité d’une exposition à Internet public, ce qui améliore la sécurité en conservant le trafic au sein du réseau principal Azure. Il utilise également le réseau virtuel client pour une protection supplémentaire. Dans cette architecture, un point de terminaison privé Azure garantit que le trafic entre les services transite par un réseau virtuel privé.

• Azure Private DNS fournit une résolution de noms transparente pour les points de terminaison privés, ce qui permet aux ressources au sein d’un réseau virtuel d’accéder aux services Azure en privé. Il leur permet d’utiliser des noms de domaine complets au lieu d’adresses IP publiques, ce qui améliore la sécurité et l’accessibilité. 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 Private DNS fournit une résilience native de résolution de noms interrégion pour le HSM managé. Dans cette architecture, les services utilisent azure Private DNS pour communiquer entre eux via leurs adresses réseau privées.

Détails du scénario

Dans cette solution, un client vise à 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 répertoriés. 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 coffre qui soutient les régions qu'ils ont choisies et répond à toutes les exigences de conformité et de sécurité. L’accès au point de terminaison privé est également appliqué pour une protection renforcée.

Cas d’usage potentiels

• Un client utilise deux régions jumelées ou non jumelé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.

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

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

• Un TDE activé par le client sur les bases de données utilisateur utilise un modèle de clé gérée par le client et stocke une clé de protection dans le HSM géré.

• Un client utilise cette conception pour fournir la résilience maximale possible.

Contributeurs

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

Auteurs principaux :

• Laura Grob | Architecte de solution cloud principal
• Armen Kaleshian | Architecte de solution cloud principal
• Michael Piskorski | Architecte de solution cloud senior

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

Étapes suivantes

• Guide complet du HSM managé pour les industries réglementées
• Rôles intégrés de contrôle d’accès en fonction du rôle local pour le HSM managé
• Activer la réplication multirégion sur un HSM managé
• Configurer un HSM managé avec des points de terminaison privés
• Vue d’ensemble de la récupération HSM managée
• Souveraineté, disponibilité, performances et scalabilité clés dans le HSM managé
• Meilleures pratiques pour la sécurisation du HSM managé
• Vue d’ensemble de la sécurité de Key Vault
• À propos des clés Key Vault
• Générer et transférer des clés protégées par HSM
• Disponibilité et redondance de Key Vault