Partage via

Transparent Data Encryption (TDE) avec des clés gérées par le client au niveau de la base de données

  • Article

S’applique à : Azure SQL Database

Cet article décrit le Transparent Data Encryption (TDE) avec des clés gérées par le client au niveau de la base de données pour Azure SQL Database.

Remarque

La CMK TDE au niveau de la base de données est disponible pour Azure SQL Database (toutes les éditions de SQL Database). Elle n’est pas disponible pour Azure SQL Managed Instance, pour SQL Server local, pour les machines virtuelles Azure et pour Azure Synapse Analytics (pools SQL dédiés (anciennement SQL DW)).

Remarque

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

Vue d’ensemble

Azure SQL offre une fonctionnalité de chiffrement au repos aux clients via Transparent Data Encryption (TDE). L’extension de TDE avec une clé gérée par le client (CMK) permet de protéger les données au repos quand le protecteur TDE (la clé de chiffrement) est stocké dans un coffre de clés Azure qui chiffre les clés de chiffrement de la base de données. Actuellement, TDE avec CMK est défini au niveau du serveur et il est hérité par toutes les bases de données chiffrées associées à ce serveur. Cette nouvelle fonctionnalité permet de définir le protecteur TDE en tant que clé gérée par le client individuellement pour chaque base de données au sein du serveur. Toute ressource Microsoft.Sql/servers/databases avec une propriété encryptionProtector valide et non vide est configurée avec des clés gérées par le client au niveau de la base de données.

Dans ce scénario, une clé asymétrique qui est stockée dans un coffre de clés Azure Key Vault (AKV) appartenant au client et géré par le client peut être utilisée individuellement pour chaque base de données au sein d’un serveur afin de chiffrer la clé de chiffrement de base de données (DEK), appelée « protecteur TDE ». Il existe une option permettant d’ajouter des clés, de supprimer des clés et de changer l’identité managée affectée par l’utilisateur pour chaque base de données. Pour plus d’informations sur les identités, consultez Types d’identités managées dans Azure.

Les fonctionnalités suivantes sont disponibles :

  • Identité managée affectée par l’utilisateur : vous pouvez affecter une seule identité managée affectée par l’utilisateur à la base de données. Cette identité peut être utilisée pour accéder au coffre de clés Azure et gérer les clés de chiffrement.
  • Gestion des clés de chiffrement : vous pouvez permettre l’ajout d’une ou plusieurs clés de chiffrement au niveau de la base de données et définir une des clés ajoutées comme protecteur TDE. Les clés de chiffrement ajoutées utilisent l’identité managée affectée par l’utilisateur déjà affectée à la base de données pour accéder à Azure Key Vault.
  • Identité client fédérée : vous pouvez aussi activer une clé gérée par le client (CMK) provenant d’Azure Key Vault dans un autre locataire Microsoft Entra à définir comme protecteur TDE au niveau de la base de données, en utilisant l’identité client fédérée définie sur l’Azure SQL Database. Ceci vous permet de gérer TDE avec des clés stockées dans le coffre de clés Azure d’un autre locataire.

Notes

L’identité managée affectée par le système n’est pas prise en charge au niveau de la base de données.

Avantages du TDE géré par le client au niveau de la base de données

Comme de plus en plus de fournisseurs de services, également appelés éditeurs de logiciels indépendants (ISV), utilisent Azure SQL Database pour créer leurs services, beaucoup se tournent vers les pools élastiques pour distribuer efficacement les ressources de calcul entre plusieurs bases de données. En plaçant les bases de données de chacun de leurs clients dans un pool élastique partagé, les éditeurs de logiciels indépendants peuvent tirer parti de la capacité du pool à optimiser l’utilisation des ressources tout en veillant à ce que chaque base de données dispose des ressources adéquates.

Il existe cependant une limitation importante à cette approche. Quand plusieurs bases de données sont hébergées sur le même Azure SQL serveur logique, elles partagent le protecteur TDE au niveau du serveur. Les éditeurs de logiciels indépendants ne peuvent pas offrir de véritables fonctionnalités de clés gérées par le client (CMK) à leurs clients. Sans la possibilité de gérer leurs propres clés de chiffrement, les clients peuvent hésiter à confier des données sensibles au service de l’éditeur de logiciels indépendant, en particulier si les réglementations de conformité les obligent à conserver un contrôle total sur leurs clés de chiffrement.

Avec la clé CMK TDE au niveau de la base de données, les éditeurs de logiciels indépendants peuvent offrir une capacité CMK à leurs clients et obtenir une isolation de sécurité, car le protecteur TDE de chaque base de données peut potentiellement appartenir au client ISV correspondant dans un coffre de clés dont il est propriétaire. L’isolation de sécurité obtenue pour les clients ISV porte à la fois sur la clé et sur l’identité utilisée pour accéder à la clé.

Le diagramme ci-dessous résume les nouvelles fonctionnalités indiquées ci-dessus. Il présente deux locataires Microsoft Entra distincts. Le locataire Best Services qui contient le serveur logique Azure SQL avec deux bases de données, DB 1 et DB 2, et le coffre Azure Key Vault 1 avec une clé Key 1 qui accède à la base de données DB 1 en utilisant UMI 1. UMI 1 et Key 1 représentent tous deux le paramètre au niveau du serveur. Par défaut, toutes les bases de données créées initialement sur ce serveur héritent de ce paramètre pour TDE avec CMK. Le locataire Contoso représente un locataire client qui contient Azure Key Vault 2 avec une clé Key 2 accédant à la base de données DB 2 sur le locataire dans le cadre de la prise en charge des clés CMK interlocataires au niveau de la base de données en utilisant la configuration de Key 2 et de UMI 2 pour cette base de données.

Configuration et fonctionnement de TDE managé par le client au niveau de la base de données

Pour plus d’informations sur la configuration de l’identité interlocataire, consultez le document sur les clés gérées par le client interlocataire avec Transparent Data Encryption au niveau du serveur.

Scénarios de gestion des clés pris en charge

Pour la section suivante, supposons qu’il existe un serveur qui se compose de trois bases de données (par exemple Database1, Database2 et Database3).

Scénario existant

Key1 est configurée en tant que clé gérée par le client au niveau du serveur logique. Toutes les bases de données sous ce serveur héritent de la même clé.

  • Serveur : Key1 définie en tant que CMK
  • Database1 : Key1 utilisée en tant que CMK
  • Database2 : Key1 utilisée en tant que CMK
  • Database3 : Key1 utilisée en tant que CMK

Nouveau scénario pris en charge : Serveur logique configuré avec une clé gérée par le client

Key1 est configurée en tant que clé gérée par le client au niveau du serveur logique. Une autre clé gérée par le client (Key2) peut être configurée au niveau de la base de données.

  • Serveur : Key1 définie en tant que CMK
  • Database1 : Key2 utilisée en tant que CMK
  • Database2 : Key1 utilisée en tant que CMK
  • Database3 : Key1 utilisée en tant que CMK

Notes

Si le serveur logique est configuré avec des clés gérées par le client pour TDE, une base de données individuelle de ce serveur logique ne peut pas être choisie pour utiliser une clé gérée par le service pour Transparent Data Encryption.

Nouveau scénario pris en charge : Serveur logique configuré avec une clé gérée par le service

Le serveur logique est configuré avec une clé gérée par le service (SMK) pour TDE. Une autre clé gérée par le client (Key2) peut être configurée au niveau de la base de données.

  • Serveur : clé gérée par le service définie comme protecteur TDE
  • Database1 : Key2 définie en tant que CMK
  • Database2 : clé gérée par le service définie en tant que protecteur TDE
  • Database3 : clé gérée par le service définie en tant que protecteur TDE

Rétablissement du chiffrement au niveau du serveur

Database1 est configuré avec une clé gérée par le client au niveau de la base de données pour TDE, tandis que le serveur logique est configuré avec une clé gérée par le service. Database1 peut être rétablie de façon à utiliser la clé gérée par le service au niveau du serveur logique.

Notes

Si le serveur logique est configuré avec CMK pour TDE, la base de données configurée avec CMK au niveau de la base de données ne peut pas être ramenée au chiffrement au niveau du serveur.

Bien que l’opération de rétablissement soit prise en charge seulement si le serveur logique est configuré avec une clé gérée par le service lors de l’utilisation de TDE, une base de données configurée avec CMK au niveau de la base de données peut être restaurée sur un serveur configuré avec CMK, à condition que le serveur ait accès à toutes les clés utilisées par la base de données source avec une identité valide.

Exigences relatives au coffre de clés et à l’identité managée

Les mêmes exigences pour la configuration des clés Azure Key Vault (AKV) et des identités managées, y compris les paramètres de clé et les autorisations accordées à l’identité qui s’appliquent à la fonctionnalité de clé gérée par le client (CMK) au niveau du serveur, s’appliquent également à CMK au niveau de la base de données. Pour plus d’informations, consultez Transparent Data Encryption (TDE) avec CMK et Identités managées avec CMK.

Gestion des clés

La rotation du protecteur TDE pour une base de données consiste à basculer vers une nouvelle clé asymétrique qui protège la base de données. 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. Une fois qu’une identité managée affectée par l’utilisateur valide a été affectée à une base de données, la rotation de la clé au niveau de la base de données est une opération CRUD de base de données qui implique la mise à jour de la propriété du protecteur de chiffrement de la base de données. Set-AzSqlDatabase et la propriété -EncryptionProtector peuvent être utilisés pour permuter les clés. Pour créer une base de données configurée avec CMK au niveau de la base de données, New-AzSqlDatabase peut être utilisé avec les paramètres -EncryptionProtector, -AssignIdentity et -UserAssignedIdentityId.

De nouvelles clés peuvent être ajoutées et les clés existantes peuvent être supprimées de la base de données en utilisant des requêtes similaires et en modifiant la propriété keys pour la ressource de base de données. Set-AzSqlDatabase avec le paramètre -KeyList et -KeysToRemove peut être utilisée pour ces opérations. Pour récupérer le paramètre de protection de chiffrement, d’identité et de clés, vous pouvez utiliser Get-AzSqlDatabase. Par défaut, la ressource Azure Resource Manager Microsoft.Sql/servers/databases montre seulement le protecteur TDE et l’identité managée configurés sur la base de données. Pour développer la liste complète des clés, d’autres paramètres, comme -ExpandKeyList, sont nécessaires. En outre, -KeysFilter "current" et une valeur de point dans le temps (par exemple 2023-01-01) peuvent être utilisés pour récupérer les clés actuelles utilisées et les clés utilisées dans le passé à un point dans le temps spécifique.

Rotation des clés automatique

La rotation automatique des clés est disponible au niveau de la base de données et peut être utilisée avec des clés Azure Key Vault. La rotation est déclenchée lorsqu’une nouvelle version de la clé est détectée et sa rotation est automatiquement activée dans les 24 heures. Pour plus d’informations sur la configuration de la rotation automatique des clés à l’aide du Portail Azure, de PowerShell ou de l’Azure CLI, consultez Rotation automatique des clés au niveau de la base de données.

Autorisation pour la gestion des clés

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.

Modèle d’autorisation de stratégie d’accès

Pour que la base de données 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 à l’identité managée affectée par l’utilisateur de la base de données en utilisant son identité Microsoft Entra unique :

  • 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 de données.
  • unwrapKey : pour pouvoir déprotéger (déchiffrer) la clé de chiffrement de données.

Modèle d’autorisations RBAC Azure

Pour que la base de données utilise le protecteur TDE stocké dans AKV pour le chiffrement de la clé DEK, une nouvelle attribution de rôle RBAC Azure avec le rôle Utilisateur de chiffrement du service Key Vault Crypto doit être ajoutée pour l’identité managée affectée par l’utilisateur de base de données à l’aide de son identité Microsoft Entra unique.

Clés gérées par le client inter-locataires

Clés gérées par le client inter-locataires avec Transparent Data Encryption décrit comment configurer un ID de client fédéré pour CMK au niveau du serveur. Une configuration similaire doit être effectuée pour CMK au niveau de la base de données, et l’ID de client fédéré doit être ajouté dans le cadre des requêtes d’API Set-AzSqlDatabase ou New-AzSqlDatabase.

Notes

Si l’application multilocataire n’a pas été ajoutée à la stratégie d’accès du coffre de clés avec les autorisations nécessaires (Obtenir, Inclure la clé, Ne pas inclure la clé), le fait d’utiliser une application pour la fédération d’identité sur le portail Azure fait apparaître une erreur. Vérifiez que les autorisations sont correctement configurées avant de configurer l’identité cliente fédérée.

Une base de données configurée avec CMK au niveau de la base de données peut être ramenée au chiffrement au niveau du serveur si le serveur logique est configuré avec une clé gérée par le service en utilisant Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevert.

Dans le cas d’un protecteur TDE inaccessible, comme décrit dans Transparent Data Encryption (TDE) avec CMK, une fois l’accès à la clé corrigé, Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation peut être utilisé pour rendre la base de données accessible.

Notes

Gestion des identités et des clés pour TDE avec des clés gérées par le client au niveau de la base de données décrit en détails les opérations de gestion des identités et des clés pour CMK au niveau de la base de données, et donne des exemples PowerShell, Azure CLI et API REST.

Considérations supplémentaires

  • Si TDE avec CMK est déjà activé au niveau du serveur, la définition de CMK pour une base de données particulière remplace le paramètre CMK au niveau du serveur (la clé DEK de la base de données est rechiffrée avec le protecteur TDE au niveau de la base de données).
  • Les modifications ou rotations de clé au niveau du serveur logique n’affectent pas les paramètres CMK au niveau de la base de données, et la base de données continue d’utiliser son propre paramètre CMK.
  • CMK au niveau de la base de données n’est pas prise en charge via Transact-SQL (T-SQL).
  • L’identité managée affectée par l’utilisateur du serveur logique peut être utilisée au niveau de la base de données. Cependant, il est recommandé d’utiliser une identité managée affectée par l’utilisateur désignée pour CMK au niveau de la base de données.
  • Les paramètres CMK interlocataires au niveau du serveur n’affectent pas les bases de données individuelles configurées avec CMK au niveau de la base de données, et elles continuent d’utiliser leur propre configuration de locataire unique ou interlocataire.
  • Une seule identité managée affectée par l’utilisateur peut être définie au niveau de la base de données.

Remarque

Les identités managées de la base de données doivent être réaffectées si la base de données est renommée.

Migration des bases de données existantes vers CMK au niveau de la base de données

Les nouvelles bases de données peuvent être configurées avec CMK au niveau de la base de données lors de la création, et les bases de données existantes dans les serveurs configurés avec des clés gérées par le service peuvent être migrées vers CMK au niveau de la base de données en utilisant des opérations décrites dans Gestion des identités et des clés pour TDE avec des clés gérées par le client au niveau de la base de données. Pour migrer des bases de données configurées avec CMK au niveau du serveur ou la géoréplication, d’autres étapes sont nécessaires, comme décrit dans les sections suivantes.

Base de données configurée avec CMK au niveau du serveur sans géoréplication

  1. Utilisez sys.dm_db_log_info (Transact-SQL) - SQL Server pour votre base de données et recherchez les fichiers journaux virtuels actifs.
  2. Pour tous les fichiers journaux virtuels actifs, enregistrez le vlf_encryptor_thumbprint à partir du résultat de sys.dm_db_log_info.
  3. Utilisez la vue sys.dm_database_encryption_keys (Transact-SQL) - SQL Server pour votre base de données afin de rechercher encryptor_thumbprint. Enregistrez le encryptor_thumbprint.
  4. Utilisez la cmdlet Get-AzSqlServerKeyVaultKey pour obtenir toutes les clés de niveau serveur configurées sur le serveur logique. Dans les résultats, sélectionnez ceux qui ont la même empreinte numérique correspondant à votre liste dans le résultat ci-dessus.
  5. Effectuez un appel d’API de mise à jour de base de données sur la base de données que vous voulez migrer ainsi que l’identité et le protecteur de chiffrement. Passez les clés ci-dessus en tant que clés au niveau de la base de données en utilisant Set-AzSqlDatabase avec les paramètres -UserAssignedIdentityId, -AssignIdentity, -KeyList, -EncryptionProtector (et si nécessaire, -FederatedClientId).

Important

L’identité utilisée dans la requête de mise à jour de la base de données doit avoir accès à toutes les clés passées en tant qu’entrée.

Base de données configurée avec CMK au niveau du serveur avec géoréplication

  1. Suivez les étapes (1) à (4) mentionnées dans la section précédente pour récupérer la liste des clés qui seront nécessaires à la migration.
  2. Effectuez un appel d’API de mise à jour de base de données à la base de données primaire et secondaire que vous voulez migrer ainsi que l’identité et les clés ci-dessus en tant que clés au niveau de la base de données en utilisant Set-AzSqlDatabase et le paramètre -KeyList. Ne définissez pas encore le protecteur de chiffrement.
  3. La clé au niveau de la base de données que vous voulez utiliser comme protecteur principal sur les bases de données doit d’abord être ajoutée à la base de données secondaire. Utilisez Set-AzSqlDatabase avec -KeyList pour ajouter cette clé à la base de données secondaire.
  4. Une fois la clé du protecteur de chiffrement ajoutée à la base de données secondaire, utilisez Set-AzSqlDatabase pour la définir comme protecteur de chiffrement sur la base de données primaire en utilisant le paramètre -EncryptionProtector.
  5. Définissez la clé comme protecteur de chiffrement sur la base de données secondaire comme décrit dans (4) pour terminer la migration.

Important

Pour migrer des bases de données configurées avec une clé gérée par le service au niveau du serveur et avec la géoréplication, suivez les étapes (3), (4) et (5) de cette section.

Géoréplication et haute disponibilité

Dans les scénarios de géoréplication active et de groupes de basculement, les bases de données primaire et secondaire concernées peuvent être liées 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, pour que la géosecondaire 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 établir une géoréplication active pour une base de données qui a été configurée avec CMK au niveau de la base de données, un réplica secondaire doit être créé avec une identité managée affectée par l’utilisateur valide et une liste des clés actuelles utilisées par la base de données primaire. La liste des clés actuelles peut être récupérée auprès de la base de données primaire en utilisant les filtres et les paramètres de requête nécessaires, ou en utilisant PowerShell et Azure CLI. Les étapes nécessaires pour configurer un géoréplica d’une telle base de données sont les suivantes :

  1. Préremplissez la liste des clés utilisées par la base de données primaire en utilisant la commande Get-AzSqlDatabase, et les paramètres -ExpandKeyList et -KeysFilter "current". Excluez -KeysFilter si vous souhaitez récupérer toutes les clés.
  2. Sélectionnez l’identité managée affectée par l’utilisateur (et l’ID de client fédéré si vous configurez l’accès interlocataire).
  3. Créez une base de données secondaire en utilisant New-AzSqlDatabaseSecondary, et fournissez la liste préremplie des clés obtenues auprès de la base de données source et l’identité ci-dessus (et l’ID de client fédéré en cas de configuration de l’accès interlocataire) dans l’appel d’API en utilisant les paramètres -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (et si nécessaire, -FederatedClientId).
  4. Utilisez New-AzSqlDatabaseCopy pour créer une copie de la base de données avec les mêmes paramètres que dans l’étape précédente.

Important

Une base de données configurée avec CMK au niveau de la base de données doit avoir un réplica (ou une copie) configuré avec CMK au niveau de la base de données. Le réplica ne peut pas utiliser les paramètres de chiffrement au niveau du serveur.

Pour utiliser une base de données configurée avec CMK au niveau de la base de données dans un groupe de basculement, les étapes ci-dessus pour créer un réplica secondaire portant le même nom que le réplica principal doivent être utilisées sur le serveur secondaire. Une fois ce réplica secondaire configuré, les bases de données peuvent être ajoutées au groupe de basculement.

Les bases de données configurées avec CMK au niveau de la base de données ne prennent pas en charge la création automatisée de réplica secondaire quand elles sont ajoutées à un groupe de basculement.

Pour plus d’informations, consultez Configurer la géoréplication et la restauration de sauvegardes pour Transparent Data Encryption avec des clés gérées par le client au niveau de la base de données, qui décrit comment configurer la géoréplication et les groupes de basculement en utilisant les API REST, PowerShell et Azure CLI.

Notes

Toutes les bonnes pratiques en matière de géoréplication et de haute disponibilité mises en évidence dans Transparent Data Encryption (TDE) avec CMK pour CMK au niveau du serveur s’appliquent à CMK au niveau de la base de données.

Sauvegarde et restauration des bases de données utilisant TDE avec une clé gérée par le client au niveau de la base de données

Une fois qu’une base de données est chiffrée avec TDE en utilisant 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. Quand le protecteur TDE est changé, les anciennes sauvegardes de la base de données ne sont pas mises à jour pour utiliser le protecteur TDE le plus récent. Pour restaurer une sauvegarde chiffrée avec un protecteur TDE d’Azure Key Vault configuré au niveau de la base de données, vérifiez que la clé est fournie à la base de données cible. Nous vous recommandons de conserver toutes les anciennes versions du protecteur TDE dans un coffre de clés, afin que toutes les sauvegardes de base de données puissent être restaurées.

Important

Un seul protecteur TDE peut être défini pour une base de données. Cependant, plusieurs clés supplémentaires peuvent être passées à une base de données lors de la restauration sans les marquer comme protecteur TDE. Ces clés ne sont pas utilisées pour la protection de la clé de chiffrement de données, mais elles peuvent être utilisées lors de la restauration à partir d’une sauvegarde, si le fichier de sauvegarde est chiffré avec la clé ayant l’empreinte numérique correspondante.

Restauration dans le temps

Les étapes suivantes sont nécessaires pour une restauration à un point dans le temps d’une base de données configurée avec des clés gérées par le client au niveau de la base de données :

  1. Préremplissez la liste des clés utilisées par la base de données primaire en utilisant la commande Get-AzSqlDatabase, et les paramètres -ExpandKeyList et -KeysFilter "2023-01-01". 2023-01-01 est un exemple de point dans le temps auquel vous souhaitez restaurer la base de données. Excluez -KeysFilter si vous souhaitez récupérer toutes les clés.
  2. Sélectionnez l’identité managée affectée par l’utilisateur (et l’ID de client fédéré si vous configurez l’accès interlocataire).
  3. Utilisez Restore-AzSqlDatabase avec le paramètre -FromPointInTimeBackup, et fournissez la liste préremplie des clés obtenues à partir des étapes ci-dessus et l’identité ci-dessus (et l’ID de client fédéré si vous configurez l’accès interlocataire) dans l’appel d’API en utilisant les paramètres -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (et si nécessaire, -FederatedClientId).

Notes

La restauration d’une base de données sans la propriété -EncryptionProtector avec toutes les clés valides va la réinitialiser pour utiliser le chiffrement au niveau du serveur. Ceci peut être utile pour rétablir une configuration de clé gérée par le client au niveau de la base de données à la configuration de clé gérée par le client au niveau du serveur.

Restauration d’une base de données qui a été supprimée

Les étapes suivantes sont nécessaires pour la restauration d’une base de données supprimée configurée avec des clés gérées par le client au niveau de la base de données :

  1. Préremplissez la liste des clés utilisées par la base de données primaire en utilisant Get-AzSqlDeletedDatabaseBackup et le paramètre -ExpandKeyList. Il est recommandé de passer toutes les clés que la base de données source utilisait, mais la restauration peut également être tentée avec les clés fournies par la date/heure de suppression pour -KeysFilter.
  2. Sélectionnez l’identité managée affectée par l’utilisateur (et l’ID de client fédéré si vous configurez l’accès interlocataire).
  3. Utilisez Restore-AzSqlDatabase avec le paramètre -FromDeletedDatabaseBackup, et fournissez la liste préremplie des clés obtenues à partir des étapes ci-dessus et l’identité ci-dessus (et l’ID de client fédéré si vous configurez l’accès interlocataire) dans l’appel d’API en utilisant les paramètres -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (et si nécessaire, -FederatedClientId).

Restauration géographique

Les étapes suivantes sont nécessaires pour une géorestauration d’une base de données configurée avec des clés gérées par le client au niveau de la base de données :

  • Préremplissez la liste des clés utilisées par la base de données primaire en utilisant Get-AzSqlDatabaseGeoBackup et -ExpandKeyList pour récupérer toutes les clés.
  • Sélectionnez l’identité managée affectée par l’utilisateur (et l’ID de client fédéré si vous configurez l’accès interlocataire).
  • Utilisez Restore-AzSqlDatabase avec le paramètre -FromGeoBackup, et fournissez la liste préremplie des clés obtenues à partir des étapes ci-dessus et l’identité ci-dessus (et l’ID de client fédéré si vous configurez l’accès interlocataire) dans l’appel d’API en utilisant les paramètres -KeyList, -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (et si nécessaire, -FederatedClientId).

Important

Il est recommandé de conserver toutes les clés utilisées par la base de données pour la restaurer. Il est également recommandé de passer toutes ces clés à la cible de restauration.

Notes

Les sauvegardes avec conservation à long terme (LTR, Long Term Retention) ne fournissent pas la liste des clés utilisées par la sauvegarde. Pour restaurer une sauvegarde LTR, toutes les clés utilisées par la base de données source doivent être passées à la cible de restauration LTR.

Pour en savoir plus sur la récupération des sauvegardes pour SQL Database avec CMK au niveau de la base de données avec des exemples d’utilisation de PowerShell, d’Azure CLI et des API REST, consultez Configurer la géoréplication et la restauration des sauvegardes pour Transparent Data Encryption avec des clés gérées par le client au niveau de la base de données.

Limites

La fonctionnalité de clés gérées par le client au niveau de la base de données ne prend pas en charge les rotations de clés quand les fichiers journaux virtuels de base de données sont chiffrés avec une ancienne clé différente du protecteur principal actuel de la base de données. L’erreur levée dans ce cas est :

PerDatabaseCMKKeyRotationAttemptedWhileOldThumbprintInUse : la rotation des clés pour le protecteur TDE au niveau de la base de données est bloquée quand des transactions actives bloquent le journal chiffré avec d’anciennes clés.

Pour mieux comprendre ce scénario, considérons la chronologie suivante :

Un exemple de chronologie de rotations de clés sur une base de données configurée avec des clés gérées par le client au niveau de la base de données.

  • Heure t0 = Une base de données est créée sans chiffrement
  • Heure t1 = Cette base de données est protégée par Thumbprint A, qui est une clé gérée par le client au niveau de la base de données.
  • Heure t2 = Le protecteur de la base de données fait l’objet d’une rotation vers une nouvelle clé gérée par le client au niveau de la base de données, Thumbprint B.
  • Heure t3 = Un changement du protecteur vers Thumbprint C est demandé.
  • Si les fichiers journaux virtuels actifs utilisent Thumbprint A, la rotation n’est pas autorisée.
  • Si les fichiers journaux virtuels actifs n’utilisent pas Thumbprint A, la rotation est autorisée.

Vous pouvez utiliser la vue sys.dm_db_log_info (Transact-SQL) - SQL Server pour votre base de données et rechercher les fichiers journaux virtuels actifs. Vous devez voir un fichier journal virtuel actif chiffré avec la première clé (par exemple Thumbprint A). Une fois qu’un journal suffisant a été généré par l’insertion de données, cet ancien fichier journal virtuel est vidé et vous devez être en mesure d’effectuer une autre rotation de clé.

Si vous pensez que quelque chose bloque votre journal plus longtemps qu’attendu, reportez-vous à la documentation suivante pour plus d’informations sur la résolution des problèmes :

Étapes suivantes

Consultez la documentation suivante sur les différentes opérations de CMK au niveau de la base de données :