Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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
Téléchargez un fichier Visio de cette architecture.
Flux de travail
Le workflow suivant correspond au diagramme précédent :
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.
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.
Le trafic du plan de données à partir de SQL Managed Instance transite par le point de terminaison privé du HSM managé.
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.
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 :
- Laura Grob | Responsable du programme 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
- Contrôler vos données dans le cloud à l’aide du 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
- Générer et transférer des clés protégées par HSM
- Disponibilité et redondance de Key Vault
- Chiffrement transparent des données Azure SQL avec une clé gérée par le client
- Présentation des groupes de basculement et meilleures pratiques - Azure SQL Managed Instance