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 (pool SQL dédié uniquement)

Transparent Data Encryption (TDE) d’Azure SQL avec une clé gérée par le client 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, la clé utilisée pour le chiffrement de la Clé de chiffrement (DEK) de la base de données, appelée protecteur TDE, est une clé asymétrique managée par le client, stockée dans un système de gestion des clés externes informatique Azure Key Vault (AKV) appartenant au client et managé par le client. Key Vault fournit un stockage sécurisé hautement disponible et évolutif pour les clés de chiffrement RSA, éventuellement sauvegardé par les modules de sécurité matériels validés FIPS 140-2 niveau 2 (HSM). Il n’autorise pas l’accès direct à une clé stockée, mais fournit des services de chiffrement/déchiffrement à l’aide de la clé aux entités autorisées. La clé peut être générée par le coffre de clés, importée ou transférée vers le coffre de clés à partir d’un appareil HSM local.

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 au serveur dans SQL Database et Azure Synapse et à une instance gérée dans SQL Managed Instance tout au long de ce document, sauf indication contraire.

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.

Notes

• Cet article s’applique à Azure SQL Database, Azure SQL Managed Instance et Azure Synapse Analytics (pools SQL dédiés (anciennement SQL DW)). Pour la documentation sur le chiffrement transparent des données pour les pools SQL dédiés à l’intérieur d’espaces de travail Synapse, consultez Chiffrement Azure Synapse Analytics.
• Pour fournir aux clients Azure SQL deux couches de chiffrement des données au repos, le chiffrement de l’infrastructure (à l’aide de l’algorithme de chiffrement AES-256) avec des clés gérées par la plateforme est déployé. Cela fournit une couche supplémentaire de chiffrement au repos, ainsi que le TDE avec des clés gérées par le client, ce qui est déjà disponible. Pour Azure SQL Database et Azure SQL Managed Instance, toutes les bases de données, y compris la base de données master et les autres bases de données système, sont chiffrées quand le chiffrement de l’infrastructure est activé. À ce stade, les clients doivent demander l’accès à cette fonctionnalité. Si cette fonctionnalité vous intéresse, contactez AzureSQLDoubleEncryptionAtRest@service.microsoft.com.

Remarque

Microsoft Entra ID était précédemment connu sous le nom d’Azure Active Directory (Azure AD).

Avantages de TDE managé par le client

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

• contrôle complet et granulaire 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 Key Vault peut révoquer les autorisations d’accès à la clé pour rendre la base de données chiffrée inaccessible ;

• gestion centralisée des modèles dans Azure Key Vault ;

• confiance accrue de vos clients finaux, car AKV est conçu de telle sorte que Microsoft ne peut pas voir ni extraire les clés de chiffrement ;

Important

Pour ceux qui utilisent le TDE géré par le service et 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.

Fonctionnement de TDE managé par le client

Pour que le serveur logique dans Azure utilise le protecteur TDE stocké dans AKV pour le chiffrement de la clé de chiffrement, l’administrateur du coffre de clés doit accorder les droits d’accès suivants au serveur à l’aide de son identité Microsoft Entra unique :

• obtenir : pour récupérer la partie publique et les propriétés de la clé dans Key Vault

• wrapKey : pour pouvoir protéger (chiffrer) la clé de chiffrement

• unwrapKey : pour pouvoir ôter la protection (déchiffrer) la clé de chiffrement

L’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.

Quand le serveur est configuré pour utiliser un protecteur TDE d’AKV, le serveur envoie la clé de chiffrement de chaque base de données prenant en charge TDE au coffre de clés pour chiffrement. Le coffre de clés retourne la clé de chiffrement 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.

Notes

Les changements d’autorisation peuvent prendre environ 10 minutes avant d’être pris en compte dans le coffre de clés. Cela inclut la révocation des autorisations d’accès dans le protecteur TDE dans AKV. Du coup, les utilisateurs dans ce laps de temps peuvent toujours avoir des autorisations d’accès.

Exigences pour la configuration de TDE managé par le client

Exigences pour la configuration d’AKV

• Les fonctionnalités Suppression réversible et Protection contre le vidage doivent être activées sur le coffre de clés pour éviter une perte de données due à une suppression accidentelle d’une clé (ou d’un coffre de clés).

• Accordez au serveur ou à la Managed Instance l’accès au coffre de clés (obtenir, wrapKey, unwrapKey) à l’aide de son identité Microsoft Entra. 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. Lors de l’utilisation du portail Azure, l’identité Microsoft Entra est créée automatiquement en même temps que le serveur. En utilisant PowerShell ou Azure CLI, l’identité Microsoft Entra doit être explicitement créée et vérifiée. Consultez Configurer TDE avec BYOK et Configure TDE with BYOK for SQL Managed Instance (Configurer TDE avec BYOK pour SQL Managed Instance) pour obtenir des instructions détaillées lors de l’utilisation de PowerShell.

  • En fonction du modèle d’autorisation du coffre de clés (stratégie d’accès ou RBAC Azure), l’accès au coffre de clés peut être accordé en créant une stratégie d’accès sur le coffre de clés ou en créant une attribution de rôle Azure RBAC avec le rôle Utilisateur du chiffrement du service de chiffrement Key Vault.

• Lorsque vous utilisez le pare-feu avec AKV, vous devez activer l’option Autoriser les services Microsoft approuvés à contourner le pare-feu. Pour plus d’informations, consultez Configurer les pare-feux et réseaux virtuels d’Azure Key Vault.

Activer la suppression réversible et la protection contre le vidage pour AKV

Important

La protection par suppression réversible et la protection contre la suppression définitive doivent être activées dans le coffre de clés lors de la configuration du TDE géré par le client sur une instance gérée ou un serveur nouveau ou existant.

La suppression réversible et la protection contre la suppression définitive sont des fonctionnalités importantes d’Azure Key Vault qui permettent de récupérer des coffres supprimés et des objets de coffre supprimés, ce qui réduit les risques de suppression accidentelle ou malveillante d’une clé ou d’un coffre de clés par un utilisateur.

• Les ressources supprimées de manière réversible sont conservées pendant 90 jours, sauf si elles sont récupérées ou vidées par le client. Les actions de récupération et de vidage ont leurs propres autorisations associées dans une stratégie d’accès au coffre de clés. La fonctionnalité de suppression réversible est activée par défaut pour les nouveaux coffres de clés et peut également être activée à l’aide du portail Azure, de PowerShell ou d’Azure CLI.

• La protection contre le vidage peut être activée en utilisant Azure CLI ou PowerShell. Quand la protection contre la suppression définitive est activée, il n’est pas possible de supprimer définitivement un coffre ou un objet à l’état supprimé avant la fin de la période de conservation. La période de conservation par défaut est de 90 jours, mais elle peut être configurée entre 7 et 90 jours dans le portail Azure.

• Azure SQL exige que la suppression réversible et la protection contre le vidage soient activées sur le coffre de clés contenant la clé de chiffrement utilisée comme protecteur TDE pour le serveur ou l’instance gérée. 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 le vidage 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 le vidage doivent d’abord être activées sur le coffre de clés, puis la configuration du protecteur TDE doit être effectuée.

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 2048 bits et 3072 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, veillez à la fournir dans les formats de fichiers pris en charge (.pfx, .byok ou .backup).

Notes

Azure SQL prend désormais en charge l’utilisation d’une clé RSA stockée dans un HSM géré en tant que protecteur TDE. Azure Key Vault HSM géré est un service cloud entièrement géré, à haut niveau de disponibilité et à un seul locataire, qui vous permet de protéger les clés de chiffrement de vos applications cloud à l’aide de modules de sécurité matériels certifiés FIPS 140-2 de niveau 3. En savoir plus sur les HSM managés.

Notes

Un problème lié aux versions de Thales CipherTrust Manager antérieures à la version 2.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 le coffre de clés pour commencer à l’utiliser comme protecteur TDE pour le serveur ou l’instance managée. Ce problème a été résolu dans Thales CipherTrust Manager v2.8.0.

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

Suggestions lors de la configuration d’AKV

• Associez au maximum 500 bases de données d’usage général ou 200 bases de données critiques pour l’entreprise au total avec un coffre de clés dans un abonnement unique pour garantir une haute disponibilité lorsque le serveur accède au protecteur TDE dans le coffre de clés. Ces chiffres sont basés sur l’expérience et documentés dans les limites du service de coffre de clés. L’objectif est d’éviter les problèmes après le basculement du serveur, car il déclenchera autant d’opérations clés sur le coffre qu’il y a de bases de données dans ce serveur.

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

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

• Reliez chaque serveur à deux coffres de clés résidant dans des régions différentes et détenant le même matériau clé pour garantir la haute disponibilité des bases de données chiffrées. Marquez la clé d’un des coffres de clés comme étant le protecteur TDE. Le système bascule automatiquement vers le coffre de clés situé dans la deuxième région avec le même matériel de clé en cas de panne affectant le coffre de clés situé dans la première région.

Notes

Pour bénéficier d’une plus grande souplesse dans la configuration du TDE géré par le client, une base de données et une instance managée Azure SQL d’une même région peuvent maintenant être liées au coffre de clés de 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 AKV 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.

• 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 lors de la rotation des clés, de sorte que les anciennes sauvegardes de base de données 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, le protecteur TDE doit être chiffré avec chaque sauvegarde lorsque celle-ci a été créée. Les rotations de clés peuvent être effectuées en suivant les instructions de l’article Rotation du protecteur Transparent Data Encryption à l’aide de PowerShell.

• Conservez toutes les clés précédemment utilisées dans AKV même après avoir basculé vers les clés managées par le service. Cela garantit la restauration des sauvegardes de base de données avec les protecteurs TDE stockés dans Azure Key Vault. Les protecteurs TDE créés avec Azure Key Vault doivent être conservés jusqu'à ce que toutes les sauvegardes stockées restantes aient été créées avec des clés managé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 indiquées dans Supprimer une clé potentiellement compromise.

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 le chiffrement de 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. Quand elle est activée, le serveur vérifie en permanence le coffre de clés 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 fait automatiquement l’objet d’une rotation vers la dernière version de la clé dans les 24 heures.

Utilisée avec la rotation des clés automatisée dans Azure Key Vault, cette fonctionnalité permet une rotation sans contact de bout en bout pour le protecteur TDE sur Azure SQL Database et Azure SQL Managed Instance.

Remarque

La définition de TDE avec CMK à l’aide d’une rotation des clés manuelle ou automatisée 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 en cas de 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 utilisé avec le serveur primaire (et aucune autre clé avec le même matériel de clé). Ou bien, avant de lancer la géoréplication, assurez-vous que l’identité managée du serveur secondaire (affectée par l’utilisateur ou par le système) dispose des autorisations requises sur le coffre de clés du serveur primaire et que le système tentera d’ajouter la clé au serveur secondaire.

• Pour une configuration de géoréplication existante, avant d’activer la rotation de clé automatisée sur le serveur primaire, 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 utilisé avec le serveur primaire (et aucune autre clé avec le même matériel de clé). Ou bien, avant de lancer la géoréplication, assurez-vous que l’identité managée du serveur secondaire (affectée par l’utilisateur ou par le système) dispose des autorisations requises sur le coffre de clés du serveur primaire, et que le système tentera 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 managé par le client dans AKV, dans un délai de 10 minutes, une base de données commence à refuser toutes les connexions avec le message d’erreur correspondant et passe à l’état inaccessible. La seule action autorisée sur une base de données dans un état inaccessible est de la supprimer.

Notes

Si la base de données est inaccessible en raison d’une interruption réseau intermittente, aucune action n’est requise et les bases de données sont automatiquement remises en ligne.

Une fois l’accès à la clé rétabli, la remise en ligne de la base de données nécessite un temps et des étapes supplémentaires, qui peuvent varier en fonction du temps écoulé sans accès à la clé et de la taille des données dans la base de données :

Notes

• Si l’accès à la clé est restauré dans les 30 minutes, la base de données sera automatiquement corrigée dans l’heure suivante.
• Si l’accès à la clé est restauré après plus de 30 minutes, la correction automatique de la base de données n’est pas possible. Le rétablissement de la base de données nécessite des étapes supplémentaires sur le portail Azure et peut prendre un temps considérable en fonction de la taille de la base de données.
• Une fois que la base de données est de nouveau en ligne, les paramètres précédemment configurés au niveau du serveur qui peuvent inclure la configuration du groupe de basculement, les étiquettes et les paramètres au niveau de la base de données, comme la configuration des pools élastiques, 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, etc. sont perdus. Par conséquent, il est recommandé que les clients implémentent un système de notification qui identifie 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 recommandons 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.

Vous trouverez ci-dessous une vue des étapes supplémentaires requises sur le portail pour remettre en ligne une base de données inaccessible.

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 désactive accidentellement l’accès du serveur à la clé en :

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

• supprimant la clé

• supprimant le coffre de clés

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

• 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 Key Vault

Sur SQL Managed Instance, les erreurs réseau qui surviennent lors de tentatives d’accès au protecteur TDE dans Azure Key Vault n’entraînent pas forcément le changement de l’état des bases de données en Inaccessible, mais elles rendront l’instance indisponible par la suite. Ce phénomène se produit principalement lorsque la ressource Key Vault existe, mais que son point de terminaison n’est pas accessible à partir de l’instance managée. Tous les scénarios où le point de terminaison Key Vault est accessible, mais où la connexion est refusée, les autorisations sont manquantes, etc., provoquent un changement d’état des bases de données enInaccessible.

Les causes les plus courantes de l’absence de connectivité réseau à Key Vault sont les suivantes :

• Key Vault est exposé par le biais d’un point de terminaison privé, et l’adresse IP privée du service AKV n’est pas autorisée dans les règles de trafic sortant du groupe de sécurité réseau (NSG, Network Security Group) associé au sous-réseau de l’instance managée.
• La résolution DNS est incorrecte, comme lorsque le nom de domaine complet du coffre de clés n’est pas résolu ou aboutit à une adresse IP non valide.

Testez la connectivité entre SQL Managed Instance et le coffre de clés 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.
  • Vérifiez les autres configurations réseau telles que la table de routage, l’existence de l’appliance virtuelle et sa configuration, etc.

Surveillance de TDE managé 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 apparaît comme « Non disponible » après le refus de la première connexion à la base de données.
• 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.

Sauvegarde et restauration de la base de données avec TDE managé par le client

Une fois qu’une base de données est chiffrée avec TDE à l’aide d’une clé du coffre de clés, 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 de Key Vault, assurez-vous que le matériel de clé est toujours 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, afin que toutes les sauvegardes de base de données puissent être restaurées.

Important

À tout moment, il ne peut pas y avoir plus d’un protecteur TDE défini pour un serveur. C’est la clé marquée avec « Faire de la clé le protecteur TDE par défaut » dans le volet du Portail Azure. Toutefois, plusieurs clés supplémentaires peuvent être liées à un serveur sans les marquer comme protecteur TDE. Ces clés ne sont pas utilisées pour la protection de la clé de chiffrement, mais elles 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.

Afin d’en savoir plus sur la récupération d’une sauvegarde pour SQL Database, consultez Récupérer une base de données dans 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 SQL Server avec SQL d’instance gérée, consultez Démarrage rapide : Restaurer une base de données dans SQL Managed Instance.

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 seront nécessaires pour restaurer la base de données. Si le fichier journal utilise un protecteur TDE stocké dans Azure Key Vault, cette clé sera nécessaire lors de la restauration, même si entretemps la base de données est passée à un TDE managé par le service.

Haute disponibilité avec TDE managé par le client

Même dans les cas où aucune géoredondance n’est configurée pour le serveur, il est fortement recommandé de configurer le serveur pour utiliser deux coffres de clés différents dans deux régions différentes, avec le même matériel de clé. La clé du coffre de clés secondaire dans l’autre région ne doit pas être marquée comme protecteur TDE et n’est même pas autorisée. En cas de panne affectant le coffre de clés principal, et uniquement dans ce cas, le système bascule automatiquement vers l’autre clé liée avec la même empreinte numérique dans le coffre de clés secondaire, le cas échéant. Notez cependant que ce commutateur ne se produira pas si le protecteur TDE est inaccessible en raison de droits d’accès révoqués ou parce que la clé ou le coffre de clés est supprimé, car il peut indiquer que le client voulait intentionnellement empêcher le serveur d’accéder à la clé. Il est possible de fournir une même clé à deux coffres de clés situés dans des régions différentes en créant la clé en dehors du coffre de clés et en l’important dans les deux coffres de clés.

Vous pouvez également le faire en générant une clé à l’aide du coffre de clés primaire situé dans une région et en clonant la clé dans un coffre de clés situé dans une autre région Azure. Utilisez la cmdlet Backup-AzKeyVaultKey pour récupérer la clé au format chiffré depuis le coffre de clés primaire, puis utilisez la cmdlet Restore-AzKeyVaultKey et spécifiez un coffre de clés dans la deuxième région pour cloner la clé. Vous pouvez également utiliser le portail Azure pour sauvegarder et restaurer la clé. L’opération de sauvegarde/restauration de clé est autorisée uniquement entre des coffres de clés au sein du même abonnement Azure et de la même zone géographique Azure.

Fonctionnement de TDE managé 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 principal et secondaire concernés peuvent être liés au même coffre de clés (dans n’importe quelle région) ou à des coffres de clés distincts. Si des coffres de clés distincts sont liés aux serveurs primaire et secondaire, le client est responsable du maintien de la cohérence du matériel de clé dans les coffres de clés, afin que la géo-secondaire soit synchronisée et puisse prendre le relais à l’aide de la même clé de son coffre de clés lié si la base de données primaire devient inaccessible en raison d’une panne dans la région et qu’un basculement est déclenché. Jusqu’à quatre bases de données secondaires peuvent être configurées et le chaînage (bases de données secondaires de secondaires) n’est pas pris en charge.

Pour éviter tout problème lors de l’établissement ou de la géoréplication en raison d’un matériel de clé incomplet, il est important de suivre les règles suivantes lors de la configuration des TDE managés par le client (si des coffres de clés distincts sont utilisés pour les serveurs primaire et secondaire) :

• Tous les coffres de clés impliqués doivent avoir les mêmes propriétés, ainsi que les mêmes droits d’accès pour les serveurs respectifs.

• Tous les coffres de clés impliqués doivent contenir un matériau de clé identique. Il s’applique non seulement au protecteur TDE actuel, mais aussi à tous les protecteurs TDE précédents qui peuvent être utilisés dans les fichiers de sauvegarde.

• La configuration initiale et la rotation du protecteur TDE doivent d’abord être effectuées sur la base de données secondaire, puis sur la primaire.

Pour tester un basculement, suivez les étapes décrites dans Aperçu de la géo-réplication active. Le test de basculement doit être effectué régulièrement pour confirmer que SQL Database a conservé l’autorisation d’accès aux deux coffres de clés.

Le serveur Azure SQL Database et SQL Managed Instance d’une même région peuvent maintenant être liés au coffre de clés de 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. Pour faire simple, les serveurs principaux et secondaires peuvent être connectés au même coffre de clés (de n’importe quelle région). Les scénarios où le matériel de clé peut être désynchronisé si des coffres de clés distincts sont utilisés pour les deux serveurs peuvent ainsi être évités. Azure Key Vault a mis en place plusieurs couches de redondance pour s’assurer que vos clés et coffres de clés restent disponibles en cas de panne du service ou de la région. Disponibilité et redondance d’Azure Key Vault

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. Une fois cette stratégie en place, toute tentative de création ou de mise à jour d’un serveur logique dans Azure ou d’une instance managée échoue s’il ou 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 Présentation d’Azure Policy et Structure de définition 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, qui 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 n’empêche pas les utilisateurs de créer ou de mettre à jour un serveur logique ou une instance managée sans que le TDE géré par le client soit activé

Si la stratégie Azure pour le TDE géré par le client est définie sur Refuser, la création du serveur logique Azure SQL ou de l’instance managée échoue. Les détails de cet échec sont enregistrés dans le Journal d’activité du groupe de ressources.

Important

Les versions antérieures des stratégies intégrées pour le TDE géré par le client contenant l’effet AuditIfNotExist ont été dépréciées. Les affectations de stratégies existantes qui utilisent les stratégies dépréciées ne sont pas impactées et continuent de fonctionner comme avant.

Étapes suivantes

Vous pouvez également vérifier les exemples de scripts PowerShell suivants pour les opérations courantes avec TDE managé par le client :

• Opérer la rotation du protecteur TDE pour SQL Database

• Supprimer un protecteur de chiffrement transparent des données (TDE) pour SQL Database

• Gérer le chiffrement transparent des données dans SQL Managed Instance avec votre propre clé à l’aide de PowerShell

En outre, activez Microsoft Defender pour SQL pour sécuriser vos bases de données et leurs données, avec des fonctionnalités permettant de détecter et d’atténuer les vulnérabilités potentielles des bases de données, ainsi que de détecter les activités anormales susceptibles d’indiquer une menace pour vos bases de données.