Partager via

Chiffrement transparent des données Azure SQL avec une clé gérée par le client

S’applique à :Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics (pools SQL dédiés uniquement)

Transparent Data Encryption (TDE) dans Azure SQL avec une clé gérée par le client (CMK) permet le scénario BYOK (Bring Your Own Key) pour la protection des données au repos, et permet aux organisations d’implémenter la séparation des tâches dans la gestion des clés et des données. Avec TDE managé par le client, le client est responsable et dans un contrôle total de la gestion du cycle de vie des clés (création, chargement, rotation, suppression des clés), des autorisations d’utilisation de la clé et de l’audit des opérations sur les clés.

Dans ce scénario, le protecteur TDE (Transparent Data Encryption) ( clé asymétrique gérée par le client utilisée pour sécuriser la clé de chiffrement de base de données ) est stockée dans Azure Key Vault ou Azure Key Vault Managed HSM. Il s’agit de services de gestion de clés sécurisés et basés sur le cloud conçus pour la haute disponibilité et la scalabilité. Azure Key Vault prend en charge les clés RSA et peut être sauvegardé par les modules HSM validés FIPS 140-2 de niveau 2. Pour les clients nécessitant une assurance plus élevée, Azure Key Vault Managed HSM offre du matériel validé FIPS 140-2 de niveau 3. La clé peut être générée dans le service, importée ou transférée en toute sécurité à partir de modules HSM locaux. L’accès direct aux clés est restreint : les services autorisés effectuent des opérations de chiffrement sans exposer le matériel de clé.

Pour Azure SQL Database et Azure Synapse Analytics, le protecteur TDE est défini au niveau du serveur et est hérité par toutes les bases de données chiffrées associées à ce serveur. Pour Azure SQL Managed Instance, le protecteur TDE est défini au niveau de l’instance et il est hérité par toutes les bases de données chiffrées sur cette instance. Le terme serveur fait référence à la fois à un serveur dans SQL Database et Azure Synapse et à une instance managée dans SQL Managed Instance dans cet article, sauf indication différente.

La gestion du protecteur TDE au niveau de la base de données dans Azure SQL Database est disponible. Pour plus d’informations, consultez Transparent Data Encryption (TDE) avec des clés gérées par le client au niveau de la base de données.

Remarque

Cet article s’applique à Azure SQL Database, Azure SQL Managed Instance et Azure Synapse Analytics (pools SQL dédiés (anciennement SQL DW)). Pour plus d’informations sur le chiffrement transparent des données pour les pools SQL dédiés dans les espaces de travail Synapse, consultez chiffrement Azure Synapse Analytics.

Remarque

Microsoft Entra ID s'appelait Azure Active Directory (Azure AD) jusqu'à une date récente.

Clé gérée par le client (CMK) et apportez votre propre clé (BYOK)

Dans cet article, les termes clés gérées par le client (CMK) et BYOK (Bring Your Own Key) sont utilisés de manière interchangeable, mais ils représentent certaines différences.

  • clé gérée par le client (CMK) : le client gère le cycle de vie des clés, y compris la création, la rotation et la suppression de clés. La clé est stockée dans Azure Key Vault ou Azure Managed HSM et utilisée pour le chiffrement de la clé de chiffrement de base de données (DEK) dans Azure SQL, SQL Server sur une machine virtuelle Azure et SQL Server localement.

  • Apportez votre propre clé (BYOK) : le client apporte ou importe en toute sécurité sa propre clé à partir d’un module de sécurité matériel local (HSM) dans Azure Key Vault ou Azure Managed HSM. Ces clés importées peuvent être utilisées comme toute autre clé dans Azure Key Vault, notamment en tant que clé gérée par le client pour le chiffrement de la clé DEK. Pour plus d'informations, consultez Importer des clés protégées par HSM vers un HSM managé (BYOK).

Avantages de TDE managé par le client

Le TDE managé par le client offre les avantages suivants au client :

  • Contrôle complet et précis de l’utilisation et de la gestion du protecteur TDE.

  • Transparence de l’utilisation du protecteur TDE.

  • Possibilité d’implémenter la séparation des tâches dans la gestion des clés et des données au sein de l’organisation.

  • L’administrateur Azure Key Vault peut révoquer les autorisations d’accès aux clés pour rendre la base de données chiffrée inaccessible.

  • Gestion centralisée des clés dans Azure Key Vault.

  • Une plus grande confiance de vos clients finaux, étant donné qu’Azure Key Vault est conçu de telle sorte que Microsoft ne puisse pas voir ni extraire des clés de chiffrement.

Importante

Pour ceux qui utilisent le TDE géré par le service qui souhaitent commencer à utiliser le TDE géré par le client, les données restent chiffrées pendant le processus de basculement, et il n’y a pas de temps d’arrêt ni de rechiffrement des fichiers de base de données. Le basculement d’une clé managée par le service à une clé managée par le client nécessite uniquement de rechiffrement de la clé de chiffrement (DEK), une opération rapide et en ligne.

Autorisations pour configurer le TDE géré par le client

Diagramme montrant la configuration et le fonctionnement de TDE géré par le client.

Sélectionnez le type d’Azure Key Vault que vous souhaitez utiliser.

Pour que le serveur logique dans Azure utilise le protecteur TDE stocké dans Azure Key Vault pour le chiffrement de la clé DEK, l’administrateur Key Vault doit accorder des droits d’accès au serveur à l’aide de son identité Microsoft Entra unique. L’identité du serveur peut être une identité managée affectée par le système ou une identité managée affectée par l’utilisateur attribuée au serveur. Il existe deux modèles d’accès pour accorder au serveur l’accès au coffre de clés :

  • Contrôle d’accès en fonction du rôle Azure (RBAC) - utilisez Azure RBAC pour accorder à un utilisateur, un groupe ou un accès d’application au coffre de clés. Cette méthode est recommandée pour sa flexibilité et sa granularité. Le rôle d'utilisateur du service de chiffrement du coffre de clés est nécessaire à l'identité du serveur pour utiliser la clé dans les opérations de chiffrement et de déchiffrement.

  • Stratégie d'accès au coffre de clés : utilisez la stratégie d'accès au coffre de clés pour accorder au serveur l’accès au coffre de clés. Cette méthode est plus simple et plus directe, mais moins flexible. L’identité du serveur doit disposer des autorisations suivantes sur le coffre de clés :

    • get : pour récupérer la partie publique et les propriétés de la clé dans Azure Key Vault
    • wrapKey : pour pouvoir protéger (chiffrer) la clé de chiffrement
    • unwrapKey : pour pouvoir ôter la protection (déchiffrer) la clé de chiffrement

Dans le menu Configuration de l’accès du portail Azure du coffre de clés, vous avez la possibilité de sélectionner le Contrôle d’accès en fonction du rôle Azure ou la Stratégie d'accès au coffre. Pour obtenir des instructions pas à pas sur la configuration d’une configuration d’accès Azure Key Vault pour TDE, consultez Configurer SQL Server TDE Extensible Key Management à l’aide d’Azure Key Vault. Pour plus d'informations sur les modèles d’accès, consultez Sécurité Azure Key Vault.

Un Administrateur du coffre de clés peut également activer la journalisation des événements d’audit de coffre de clés, afin qu’ils puissent être audités ultérieurement.

Lorsqu’un serveur est configuré pour utiliser un protecteur TDE à partir d’Azure Key Vault, le serveur envoie la clé DEK de chaque base de données compatible TDE au coffre de clés pour le chiffrement. Le Key Vault retourne la clé DEK chiffrée, qui est alors stockée dans la base de données utilisateur.

Le cas échéant, le serveur envoie des clés de chiffrement protégées vers le coffre de clés pour le déchiffrement.

Les auditeurs peuvent utiliser Azure Monitor pour évaluer les journaux AuditEvent du coffre de clés, si la journalisation est activée.

Remarque

La prise en compte des changements d’autorisation dans le coffre de clés peut prendre environ 10 minutes. Cela inclut la révocation des autorisations d'accès au protecteur TDE dans AKV, et les utilisateurs pendant ce laps de temps peuvent encore disposer des autorisations d'accès.

Configuration requise pour configurer le TDE géré par le client

  • Les fonctionnalités de suppression temporaire et de protection contre la purge doivent être activées sur Azure Key Vault. Cela permet d’éviter le scénario de suppression accidentelle ou malveillante de coffre de clés ou de clés rendant une base de données Inaccessible. Lors de la configuration du protecteur TDE sur un serveur existant ou pendant la création du serveur, Azure SQL vérifie que la suppression réversible et la protection contre le vidage sont activées pour le coffre de clés utilisé. Si la suppression réversible et la protection contre la suppression définitive ne sont pas activées sur le coffre de clés, la configuration du protecteur TDE échoue avec une erreur. Dans ce cas, la suppression réversible et la protection contre la suppression définitive doivent d’abord être activées sur le coffre de clés, puis la configuration du protecteur TDE doit être effectuée.

  • Lorsque vous utilisez un pare-feu avec Azure Key Vault, vous devez activer l’option Autoriser les services Microsoft approuvés à contourner le pare-feu, sauf si vous utilisez des points de terminaison privés pour Azure Key Vault. Pour plus d’informations, consultez Configurer les pare-feux et réseaux virtuels d’Azure Key Vault.

Exigences pour la configuration du protecteur TDE

  • Le protecteur TDE peut uniquement être une clé asymétrique, RSA ou RSA HSM. Les longueurs de clé prises en charge sont 2 048 bits et 3 072 bits.

  • La date d’activation de la clé (si définie) doit être une date et une heure passées. La date d’expiration (si définie) doit être une date et une heure ultérieures.

  • La clé doit être dans l’état activé.

  • Si vous importez une clé existante dans le coffre de clés, vérifiez qu’elle est fournie dans l’un des formats de fichier pris en charge : .pfx, .byokou .backup. Pour importer des clés protégées par HSM dans Azure Managed HSM, consultez Importer des clés protégées par HSM dans managed HSM (BYOK).

Remarque

Un problème avec les versions de Thales CipherTrust Manager avant la version v2.8.0 empêche les clés nouvellement importées dans Azure Key Vault d’être utilisées avec Azure SQL Database ou Azure SQL Managed Instance pour les scénarios TDE gérés par le client. Pour plus d’informations sur ce problème, cliquez ici. Dans ce cas, attendez 24 heures après l’importation de la clé dans Azure Key Vault pour commencer à l’utiliser comme protecteur TDE pour le serveur ou l’instance managée. Ce problème est résolu dans Thales CipherTrust Manager v2.8.0.

Suggestions lors de la configuration de TDE managé par le client

  • Pour garantir des performances et une fiabilité optimales, il est fortement recommandé d’utiliser un coffre de clés Azure dédié pour Azure SQL. Ce coffre de clés ne doit pas être partagé avec d’autres services. Si le coffre de clés est soumis à une charge importante, en raison d’une utilisation partagée ou d’opérations de clé excessives, il peut affecter négativement les performances de la base de données, en particulier pendant l’accès à la clé de chiffrement. Azure Key Vault applique des limites de limitation. Lorsque ces limites sont dépassées, les opérations peuvent être retardées ou défaillantes. Cela est essentiel lors des basculements de serveur, qui déclenchent des opérations essentielles pour chaque base de données sur le serveur.

    Pour plus d'informations sur le comportement de régulation, consultez les recommandations sur la régulation d’Azure Key Vault.

    Pour maintenir la haute disponibilité et éviter les problèmes de limitation, suivez ces instructions par abonnement :

    • Utilisez un coffre de clés Azure dédié pour les ressources Azure SQL.

    • Associez pas plus de 500 bases de données à usage général à un seul coffre de clés Azure.

    • Associez pas plus de 200 bases de données critiques pour l’entreprise à un seul coffre de clés Azure.

    • Le nombre de bases de données Hyperscale qui peuvent être associées à un seul coffre de clés Azure est déterminé par le nombre de serveurs de pages. Chaque serveur de pages est lié à un fichier de données logique. Pour rechercher le nombre de serveurs de pages, exécutez la requête suivante.

      -- # of page servers (primary copies) for this database
SELECT COUNT(*) AS page_server_count
FROM sys.database_files
WHERE type_desc = 'ROWS';

      N’associez pas plus de 500 serveurs de pages à un seul coffre de clés Azure. À mesure que la base de données augmente, le nombre de serveurs de pages augmente automatiquement. Il est donc important de surveiller régulièrement la taille de la base de données. Si le nombre de serveurs de pages dépasse 500, utilisez un coffre de clés Azure dédié pour chaque base de données Hyperscale qui n’est pas partagée avec d’autres ressources Azure SQL.

    • Surveillez et configurezles alertes Azure Key Vault. Pour plus d’informations sur la surveillance et les alertes, consultez Surveiller Azure Key Vault et configurer des alertes Azure Key Vault.

  • Définissez un verrou de ressource sur le coffre de clés pour contrôler les utilisateurs pouvant supprimer cette ressource critique et pour empêcher toute suppression accidentelle ou non autorisée. En savoir plus sur les verrous de ressource.

  • Activez l’audit et la création de rapports sur toutes les clés de chiffrement : Azure Key Vault fournit des journaux faciles à injecter dans d’autres outils de gestion des événements et des informations de sécurité. Operations Management Suite Log Analytics est un exemple de service déjà intégré.

  • Utilisez un coffre de clés à partir d’une région Azure qui peut répliquer son contenu vers une région jumelée pour une disponibilité maximale. Pour plus d’informations, consultez Meilleures pratiques pour l’utilisation d’Azure Key Vault et disponibilité et redondance d’Azure Key Vault.

Remarque

Pour permettre une plus grande flexibilité dans la configuration du TDE géré par le client, Azure SQL Database et Azure SQL Managed Instance dans une région peuvent désormais être liés à Azure Key Vault dans n’importe quelle autre région. Le serveur et le coffre de clés n’ont pas besoin d’être colocalisés dans la même région.

Suggestions lors de la configuration du protecteur TDE

  • Conservez une copie du protecteur TDE à un emplacement sécurisé ou déposez-le au service de dépôt.

  • Si la clé est générée dans le coffre de clés, créez une sauvegarde de clé avant d’utiliser la clé dans Azure Key Vault pour la première fois. La sauvegarde peut être restaurée sur un Azure Key Vault uniquement. En savoir plus sur la commande Backup-AzKeyVaultKey. Azure Managed HSM prend en charge la création d’une sauvegarde complète de l’ensemble du contenu du module HSM, y compris toutes les clés, versions, attributs, balises et attributions de rôles. Pour plus d’informations, consultez Sauvegarde complète et restauration et restauration de clés sélectives.

  • Créez une nouvelle sauvegarde à chaque modification de la clé (par exemple, attributs de clé, balises, listes de contrôle d’accès).

  • Conservez les versions précédentes de la clé dans le coffre de clés ou le HSM managé lors de la rotation des clés, afin que les sauvegardes de base de données plus anciennes puissent être restaurées. Lorsque le protecteur TDE est modifié pour une base de données, les anciennes sauvegardes de la base de données ne sont pas mises à jour pour utiliser le dernier protecteur TDE. Au moment de la restauration, chaque sauvegarde nécessite le protecteur TDE avec lequel elle a été chiffrée au moment de sa création. Les rotations de clé peuvent être effectuées en suivant les instructions de l’article Faire pivoter le protecteur TDE (Transparent Data Encryption).

  • Conservez toutes les clés précédemment utilisées dans Azure Key Vault ou Azure Managed HSM, même après avoir basculé vers des clés gérées par le service. Il garantit que les sauvegardes de base de données peuvent être restaurées avec les protecteurs TDE stockés dans Azure Key Vault ou azure Managed HSM. Les protecteurs TDE créés avec Azure Key Vault ou Azure Managed HSM doivent être conservés jusqu’à ce que toutes les sauvegardes stockées restantes aient été créées avec des clés gérées par le service. Effectuez des copies de sauvegarde récupérables de ces clés à l’aide de Backup-AzKeyVaultKey.

  • Pour supprimer une clé potentiellement compromise pendant un incident de sécurité sans risque de perte de données, suivez les étapes de l’article Supprimer un protecteur TDE (Transparent Data Encryption) à l’aide de PowerShell.

Rotation du protecteur TDE

La rotation du protecteur TDE pour un serveur consiste à basculer vers une nouvelle clé asymétrique qui protège les bases de données sur le serveur. La rotation de clé est une opération en ligne qui ne devrait prendre que quelques secondes. L’opération ne fait que déchiffrer et re-chiffrer la clé de chiffrement de la base de données, pas la base de données entière.

La Rotation du protecteur TDE peut être effectuée manuellement ou à l’aide de la fonctionnalité de rotation automatisée.

La rotation automatisée du protecteur TDE peut être activée lors de la configuration du protecteur TDE pour le serveur. La rotation automatisée est désactivée par défaut. Lorsqu'il est activé, le serveur vérifie continuellement le coffre de clés ou le HSM géré pour toute nouvelle version de la clé utilisée comme protecteur TDE. Si une nouvelle version de la clé est détectée, le protecteur TDE sur le serveur ou la base de données est automatiquement pivoté vers la dernière version de la clé dans les 24 heures.

Lorsqu’elle est utilisée avec la rotation automatisée des clés dans Azure Key Vault ou l’autorotation dans Azure Managed HSM, cette fonctionnalité active la rotation sans contact de bout en bout pour le protecteur TDE sur Azure SQL Database et Azure SQL Managed Instance.

Remarque

La configuration de TDE avec CMK à l’aide d’une rotation manuelle ou automatisée de clés utilise toujours la dernière version de la clé prise en charge. La configuration n’autorise pas l’utilisation d’une version antérieure ou inférieure des clés. Toujours utiliser la dernière version de la clé est conforme à la stratégie de sécurité Azure SQL qui interdit les versions précédentes de clés qui peuvent être compromises. Les versions précédentes de la clé peuvent être nécessaires à des fins de sauvegarde ou de restauration de base de données, en particulier pour les sauvegardes à conservation à long terme, où les versions antérieures de clé doivent être conservées. Pour les configurations de géoréplication, toutes les clés requises par le serveur source doivent être présentes sur le serveur cible.

Considérations relatives à la géoréplication lors de la configuration de la rotation automatisée du protecteur TDE

Pour éviter les problèmes d’établissement ou de géoréplication, lorsque la rotation automatique du protecteur TDE est activée sur le serveur primaire ou secondaire, il est important de suivre ces règles pour la configuration de la géoréplication :

  • Les serveurs primaire et secondaire doivent disposer d’autorisations Get, wrapKey et unwrapKey sur le coffre de clés du serveur primaire (coffre de clés contenant la clé du protecteur TDE du serveur primaire).

  • Pour un serveur avec la rotation de clé automatisée activée, avant de lancer la géoréplication, ajoutez la clé de chiffrement utilisée comme protecteur TDE sur le serveur primaire au serveur secondaire. Le serveur secondaire requiert l'accès à la clé dans le coffre de clés ou le HSM managé utilisé avec le serveur primaire (et aucune autre clé avec le même matériel de clé). Sinon, avant de lancer la géoréplication, assurez-vous que l’identité managée du serveur secondaire (affectée par l’utilisateur ou affectée par le système) dispose des autorisations requises sur le coffre de clés du serveur principal ou le HSM managé, et que le système tente d’ajouter la clé au serveur secondaire.

  • Pour une configuration de géoréplication existante, avant d’activer la rotation automatisée des clés sur le serveur principal, ajoutez la clé de chiffrement utilisée comme protecteur TDE sur le serveur principal au serveur secondaire. Le serveur secondaire requiert l'accès à la clé dans le coffre de clés ou le HSM managé utilisé avec le serveur primaire (et aucune autre clé avec le même matériel de clé). Avant d’activer la clé automatisée, assurez-vous que l’identité managée du serveur secondaire (affectée par l’utilisateur ou affectée par le système) dispose des autorisations requises sur le coffre de clés du serveur principal et que le système tente d’ajouter la clé au serveur secondaire.

  • Les scénarios de géoréplication utilisant des clés gérées par le client (CMK) pour TDE sont pris en charge. TDE avec rotation automatique des clés doit être configuré sur tous les serveurs si vous configurez TDE dans le portail Azure. Pour plus d’informations sur la configuration de la rotation automatique des clés pour les configurations de géoréplication avec TDE, consultez Rotation automatique des clés pour les configurations de géoréplication.

Protecteur TDE inaccessible

Quand le TDE est configuré pour utiliser une clé managée par le client, un accès continu au protecteur TDE est requis pour que la base de données reste en ligne. Si le serveur perd l’accès au protecteur TDE géré par le client dans Azure Key Vault ou Azure Managed HSM, jusqu’à 10 minutes, une base de données commence à refuser toutes les connexions avec le message d’erreur correspondant et à changer son état sur Inaccessible. La seule action autorisée sur une base de données dans un état inaccessible est de la supprimer.

État Inaccessible

Si la base de données est inaccessible en raison d’une panne réseau intermittente (par exemple, une erreur 5XX), aucune action n’est requise, car les bases de données reviennent automatiquement en ligne. Pour réduire l’effet des erreurs réseau ou des pannes lors de l’accès au protecteur TDE dans Azure Key Vault ou Azure Managed HSM, une mémoire tampon de 24 heures est introduite avant que le service tente de déplacer la base de données vers un état inaccessible. Si un basculement se produit avant d’atteindre l’état inaccessible, la base de données devient indisponible en raison de la perte du cache de chiffrement.

Si le serveur perd l’accès au protecteur TDE géré par le client dans Azure Key Vault ou Azure Managed HSM en raison d’une erreur Azure Key Vault (par exemple, une erreur 4XX), la base de données est déplacée vers un état inaccessible après 30 minutes.

Restaurer l’accès à la base de données après une erreur Azure Key Vault ou Azure Managed HSM

Une fois l’accès à la clé restauré, le retour en ligne de la base de données nécessite un temps et des étapes supplémentaires, qui peuvent varier en fonction de la durée d’indisponibilité de clé et de la taille des données dans la base de données.

Si l’accès à la clé est restauré dans les 30 minutes, la base de données guérit automatiquement au cours de l’heure suivante. Toutefois, si l’accès à la clé est restauré après plus de 30 minutes, la réparation automatique de la base de données n’est pas possible. Dans ce cas, la restauration de la base de données implique des procédures supplémentaires via le portail Azure et peut prendre du temps, en fonction de la taille de la base de données.

Une fois la base de données de nouveau en ligne, les paramètres au niveau du serveur précédemment configurés, y compris les configurations de groupe de basculement, les balises, et les paramètres au niveau de la base de données tels que les configurations de pool élastique, la mise à l'échelle de lecture, la pause automatique, l'historique de restauration à un point dans le temps, la stratégie de rétention à long terme, et d'autres, sont perdus. Par conséquent, il est recommandé aux clients d’implémenter un système de notification pour détecter la perte d’accès à la clé de chiffrement dans les 30 minutes. Une fois la fenêtre de 30 minutes expirée, nous vous conseillons de valider tous les paramètres au niveau du serveur et de la base de données sur la base de données récupérée.

Voici une vue des étapes supplémentaires requises sur le portail pour ramener une base de données inaccessible en ligne.

Capture d’écran d’une base de données inaccessible TDE BYOK.

Révocation accidentelle de l’accès au protecteur TDE

Il peut arriver qu’une personne disposant de droits d’accès suffisants au coffre de clés ou au module HSM géré désactive accidentellement l'accès à la clé via le serveur :

  • révoquant les autorisations get, wrapKey, unwrapKey du coffre de clés ou du HSM managé à partir du serveur

  • Suppression de la clé

  • supprimant le coffre de clés ou le HSM managé

  • modifiant les règles de pare-feu du coffre de clés ou du HSM managé

  • suppression de l’identité managée du serveur dans Microsoft Entra ID

En savoir plus sur les causes courantes pour que la base de données devienne inaccessible.

Connectivité bloquée entre SQL Managed Instance et Azure Key Vault ou Azure Managed HSM

Le bloc de connectivité réseau entre SQL Managed Instance et coffre de clés ou HSM managé se produit principalement lorsque le coffre de clés ou la ressource HSM managée existe, mais que son point de terminaison ne peut pas être atteint à partir de l’instance managée. Tous les scénarios où le coffre de clés ou le point de terminaison HSM managé sont accessibles, mais la connexion est refusée en raison d'autorisations manquantes, etc., entraînent les bases de données à passer à l'état Inaccessible.

Les causes les plus courantes de l’absence de connectivité réseau à Azure Key Vault ou azure Managed HSM sont les suivantes :

  • Azure Key Vault ou Azure Managed HSM est exposé via un point de terminaison privé et l’adresse IP privée du service Azure Key Vault ou Azure Managed HSM n’est pas autorisée dans les règles de trafic sortant du groupe de sécurité réseau (NSG) associé au sous-réseau d’instance managée.

  • La résolution DNS est incorrecte, comme lorsque le nom de domaine complet du coffre de clés ou du HSM managé n'est pas résolu ou aboutit à une adresse IP non valide.

Testez la connectivité entre SQL Managed Instance et Azure Key Vault ou Azure Managed HSM hébergeant le protecteur TDE.

  • Le point de terminaison est votre nom de domaine complet de coffre, comme <nom_coffre>.vault.azure.net (sans la mention https://).
  • Le port à tester est le port 443.
  • Le résultat de RemoteAddress devrait exister et être la bonne adresse IP
  • Le résultat du test TCP doit être TcpTestSucceeded: True.

Si le test retourne TcpTestSucceeded: False, vérifiez la configuration réseau :

  • Vérifiez la validité de l’adresse IP résolue. Une valeur manquante est le signe de problèmes de résolution DNS.

    • Vérifiez que le groupe de sécurité réseau sur l’instance managée a une règle de trafic sortant qui couvre l’adresse IP résolue sur le port 443, en particulier lorsque l’adresse résolue appartient au point de terminaison privé du coffre de clés ou du HSM privé managé.

    • Vérifiez les autres configurations réseau telles que la table de routage, l’existence de l’appliance virtuelle et sa configuration, etc.

Surveiller le TDE géré par le client

Pour surveiller l’état de la base de données et activer l’alerte pour la perte d’accès au protecteur TDE, configurez les fonctionnalités Azure suivantes :

  • Azure Resource Health. Une base de données inaccessible qui a perdu l’accès au protecteur TDE s’affiche comme « Indisponible » une fois la première connexion à la base de données refusée.

  • Journal d’activité : lorsque l’accès au protecteur TDE dans le coffre de clés géré par le client échoue, des entrées sont ajoutées au Journal d’activité. La création d’alertes pour ces événements vous permet de rétablir l’accès dès que possible.

  • Des groupes d’actions peuvent être définis de manière à vous envoyer des notifications et des alertes en fonction de vos préférences, par exemple par e-mail/SMS/push/voix, application logique, webhook, ITSM ou Runbook Automation.

Les bases de données backup et restore avec TDE géré par le client

Une fois qu’une base de données est chiffrée avec TDE à l’aide d’une clé à partir d’Azure Key Vault ou d’Azure Managed HSM, toutes les sauvegardes nouvellement générées sont également chiffrées avec le même protecteur TDE. Lorsque le protecteur TDE est modifié, les anciennes sauvegardes de la base de données ne sont pas mises à jour pour l’utiliser le dernier protecteur TDE.

Pour restaurer une sauvegarde chiffrée avec un protecteur TDE à partir d’Azure Key Vault ou d’Azure Managed HSM, assurez-vous que le matériel de clé est disponible pour le serveur cible. Par conséquent, nous vous recommandons de conserver toutes les anciennes versions du protecteur TDE dans le coffre de clés ou le HSM managé, afin que les sauvegardes de base de données puissent être restaurées.

Importante

À tout moment, il ne peut pas y avoir plus d’un protecteur TDE défini pour un serveur. La clé marquée avec Faire de la clé le protecteur TDE par défaut dans le volet du portail Microsoft Azure est le protecteur TDE. Toutefois, plusieurs clés peuvent être liées à un serveur sans les marquer comme protecteur TDE. Ces clés ne sont pas utilisées pour protéger la clé DEK, mais peuvent être utilisées lors de la restauration à partir d’une sauvegarde, si le fichier de sauvegarde est chiffré avec la clé avec l’empreinte numérique correspondante.

Si la clé nécessaire pour la restauration d’une sauvegarde n’est plus disponible dans le serveur cible, le message d’erreur suivant est retourné lors de la tentative de restauration : « Le serveur cible <Servername> n’a pas accès à tous les URI AKV créés entre <Timestamp #1> et <Timestamp #2>. Réessayez l’opération après avoir restauré tous les URI AKV. »

Pour l’atténuer, exécutez la cmdlet Get-AzSqlServerKeyVaultKey pour le serveur cible ou Get-AzSqlInstanceKeyVaultKey pour l’instance gérée cible afin de retourner la liste des clés disponibles et d’identifier celles qui sont manquantes. Pour garantir la restauration possible de toutes les sauvegardes, vérifiez que le serveur cible pour la sauvegarde dispose d’un accès à toutes les clés nécessaires. Ces clés n’ont pas besoin d’être marquées comme protecteur TDE.

Pour en savoir plus sur la récupération de sauvegarde pour SQL Database, consultez Restaurer une base de données à partir d’une sauvegarde dans Azure SQL Database. Pour en savoir plus sur la récupération de sauvegarde pour des pools SQL dédiés dans Azure Synapse Analytics, consultez Récupérer un pool SQL dédié. Pour la sauvegarde/restauration native de SQL Server avec SQL Managed Instance, consultez démarrage rapide : Restaurer une base de données dans Azure SQL Managed Instance avec SSMS.

Attention particulière pour les fichiers journaux : les fichiers journaux sauvegardés restent chiffrés avec le protecteur TDE d’origine, même en cas de permutation et si la base de données utilise maintenant un nouveau protecteur TDE. Lors d’une restauration, les deux clés sont nécessaires pour restaurer la base de données. Si le fichier journal utilise un protecteur TDE stocké dans Azure Key Vault ou Azure Managed HSM, cette clé est nécessaire au moment de la restauration, même si la base de données a été modifiée pour utiliser TDE géré par le service en attendant.

Haute disponibilité avec TDE managé par le client

Avec Azure Key Vault ou Azure Managed HSM fournissant plusieurs couches de redondance, les processus TDE utilisant une clé gérée par le client peuvent tirer parti de la disponibilité et de la résilience d’Azure Key Vault ou azure Managed HSM, et s’appuyer entièrement sur la solution de redondance Azure Key Vault ou Azure Managed HSM.

Plusieurs couches de redondance Azure Key Vault garantissent l’accès aux clés, même si les composants de service individuels échouent ou si des régions Azure ou des zones de disponibilité sont en panne. Pour plus d’informations, consultez Disponibilité et redondance d’Azure Key Vault.

Azure Key Vault offre les composants suivants de disponibilité et de résilience qui sont fournis automatiquement sans intervention de l’utilisateur :

Remarque

Pour toutes les régions jumelées, les clés Azure Key Vault sont répliquées dans les deux régions et il existe des modules de sécurité matériels (HSM) dans les deux régions qui peuvent fonctionner sur ces clés. Pour plus d'informations, consultez Réplication des données. Cela s’applique aux niveaux de service Azure Key Vault Standard et Premium, ainsi qu’aux clés logicielles ou matérielles.

La réplication multirégion HSM managée Azure vous permet d’étendre un pool Azure Managed HSM d’une région Azure (appelée région primaire) à une autre région Azure (appelée région étendue). Une fois configurées, les deux régions sont actives, capables de traiter les requêtes et, avec la réplication automatisée, de partager les mêmes éléments clés, rôles et autorisations. Pour plus d’informations, consultez Activer la réplication multirégion sur Azure Managed HSM.

Fonctionnement de TDE géré par le client et à récupération d’urgence de géoréplication

Dans les scénarios de géoréplication active et de groupes de basculement, les serveurs principaux et secondaires impliqués peuvent être liés à Azure Key Vault ou à Azure Managed HSM, situés dans n'importe quelle région. Le serveur et le coffre de clés ou le HSM managé n’ont pas besoin d’être colocalisés dans la même région. Ainsi, par souci de simplicité, les serveurs principaux et secondaires peuvent être connectés au même coffre de clés ou au même HSM managé (dans n’importe quelle région). Cela permet d’éviter les scénarios où le matériel de clé peut être désynchronisé si des coffres de clés distincts ou des HSM gérés sont utilisés pour les serveurs.

Azure Key Vault et Azure Managed HSM ont plusieurs couches de redondance en place pour s’assurer que les clés et les coffres de clés restent disponibles en cas d’échecs de service ou de région. La redondance est prise en charge par les régions non souhaitées et jumelées. Pour plus d’informations, consultez Disponibilité et redondance d’Azure Key Vault.

Il existe plusieurs options pour stocker la clé de protection TDE, en fonction des exigences des clients :

  • Utilisez Azure Key Vault et la résilience de région jumelée native ou la résilience de région non souhaitée.

  • Utilisez HSM client et chargez des clés dans Azure Key Vault dans des coffres de clés Azure distincts dans plusieurs régions.

  • Utilisez azure Managed HSM et l’option de réplication inter-régions.

    • Cette option permet au client de sélectionner la région souhaitée dans laquelle les clés sont répliquées.

Le schéma suivant représente une configuration en région jumelée (principale et secondaire) pour un basculement croisé d'Azure Key Vault avec Azure SQL configuré pour la géoréplication à l'aide d'un groupe de basculement :

Diagramme montrant la prise en charge du basculement entre régions Azure Key Vault pour une région jumelée.

Remarques d’Azure Key Vault pour Geo-DR

  • Les serveurs principaux et secondaires dans Azure SQL accèdent à Azure Key Vault dans la région primaire.

  • Le basculement d'Azure Key Vault est déclenché par le service Azure Key Vault et non par le client.

  • Si Azure Key Vault bascule vers la région secondaire, le serveur dans Azure SQL peut toujours accéder au même coffre de clés Azure. Toutefois, en interne, la connexion à Azure Key Vault est redirigée vers l'Azure Key Vault situé dans la région secondaire.

  • Les nouvelles créations de clés, les importations et les rotations de clés ne sont possibles que lorsque l'Azure Key Vault dans le principal est disponible.

  • Une fois le basculement effectué, la rotation de la clé n'est plus autorisée tant que l'Azure Key Vault dans la région principale de la paire n'est pas à nouveau accessible.

  • Le client ne peut pas se connecter manuellement à la région secondaire.

  • Azure Key Vault est en mode lecture seule tant que le coffre de la région principale est indisponible.

  • Le client ne peut pas choisir ou vérifier la région dans laquelle Azure Key Vault se trouve actuellement.

  • Pour la région non souhaitée, les deux serveurs Azure SQL accèdent à Azure Key Vault dans la première région (comme indiqué sur le graphique) et Azure Key Vault utilise un stockage redondant interzone pour répliquer les données au sein de la région, entre les zones de disponibilité indépendantes de la même région.

Pour plus d’informations, consultez disponibilité et redondance d’Azure Key Vault, paires de régions Azure et régions non appariées, et accords de niveau de service pour Azure Key Vault.

Remarques Azure SQL pour Geo-DR

  • Utilisez l’option redondante interzone d’Azure SQL Managed Instance et d’Azure SQL Database pour augmenter la résilience. Pour plus d’informations, consultez Qu’est-ce que les zones de disponibilité Azure ?.

  • Utilisez des groupes de basculement pour Azure SQL Managed Instance et Azure SQL Database afin de permettre la reprise après sinistre vers une région secondaire. Pour plus d’informations, consultez Vue d'ensemble des groupes de basculement et pratiques exemplaires.

  • Lorsqu’une base de données fait partie des groupes de géoréplication ou de basculement actifs et devient inaccessible, le plan de contrôle SQL interrompt le lien et convertit la base de données en base de données autonome. Après avoir corrigé les autorisations de clé, la base de données primaire peut généralement être remise en ligne. La base de données secondaire ne peut pas être remise en ligne, car Azure SQL n’effectue pas de sauvegardes complètes pour les bases de données secondaires par conception. La recommandation consiste à supprimer les bases de données secondaires et à rétablir le lien.

  • La configuration peut nécessiter une zone DNS plus complexe si des points de terminaison privés sont utilisés dans Azure SQL (par exemple, il ne peut pas créer deux points de terminaison privés sur la même ressource dans la même zone DNS).

  • Vérifiez que les applications utilisent la logique de nouvelle tentative.

Il existe plusieurs scénarios où les clients peuvent choisir une solution HSM managée Azure sur Azure Key Vault :

  • Exigences concernant la connexion manuelle au coffre secondaire.

  • Exigence d’accès en lecture au coffre, même en cas de défaillance.

  • Possibilité de choisir la région dans laquelle leur matériel clé est répliqué

    • Nécessite l’activation de la réplication interrégion, qui crée le deuxième pool Azure Managed HSM dans la deuxième région.

  • L’utilisation du HSM managé Azure permet aux clients de créer un réplica exact pour HSM si l’original est perdu ou indisponible.

  • Utilisation d’Azure Managed HSM pour la sécurité ou les exigences réglementaires.

  • Disposer de la capacité à sauvegarder l’intégralité du coffre au lieu de sauvegarder des clés individuelles.

Pour plus d’informations, consultez Activer la réplication multirégion sur Azure Managed HSM et Récupération d’urgence des HSM managés.

Azure Policy pour le TDE géré par le client

Azure Policy peut être utilisé pour appliquer un TDE géré par le client lors de la création ou de la mise à jour d’un serveur Azure SQL Database ou d’une instance managée Azure SQL. Avec cette stratégie en place, toutes les tentatives de création ou de mise à jour d’un serveur logique dans Azure ou managed instance échouent si elle n’est pas configurée avec une clé gérée par le client. La stratégie Azure peut être appliqué à l’ensemble de l’abonnement Azure, ou uniquement au sein d’un groupe de ressources.

Pour plus d'informations sur Azure Policy, consultez Qu’est-ce qu’Azure Policy et la structure de définition d'Azure Policy.

Les deux stratégies intégrées suivantes sont prises en charge pour le TDE géré par le client dans Azure Policy :

  • Les serveurs SQL doivent utiliser des clés gérées par le client pour chiffrer les données au repos
  • Les instances managées doivent utiliser des clés gérées par le client pour chiffrer les données au repos

Vous pouvez gérer la stratégie du TDE géré par le client en accédant au portail Azure et en recherchant le service Policy. Sous Définitions, recherchez la clé gérée par le client.

Il existe trois effets pour ces stratégies :

  • Audit : paramètre par défaut et capture uniquement un rapport d’audit dans les journaux d’activité Azure Policy

  • Refuser : empêche la création ou la mise à jour d’instances managées ou de serveurs logiques sans clé gérée par le client configurée

  • Désactivé : désactive la stratégie et ne empêche pas les utilisateurs de créer ou de mettre à jour un serveur logique ou une instance managée sans TDE géré par le client

Si Azure Policy pour le TDE géré par le client est défini sur Refuser, la création d’un serveur logique Azure SQL ou d’une instance gérée échoue. Les détails de cet échec sont enregistrés dans le journal d’activité du groupe de ressources.

Importante

Les versions antérieures des stratégies intégrées pour le TDE géré par le client contenant l’effet AuditIfNotExists sont déconseillées. Les attributions de stratégie existantes utilisant les stratégies déconseillées ne sont pas affectées et continuent à fonctionner comme avant.

Contenu connexe

  • Last updated on