Configurer la Gestion de clés extensible TDE de SQL Server avec Azure Key Vault
S'applique à : SQL Server
Dans cet article, vous découvrirez comment Installer et configurer le connecteur SQL Server pour Azure Key Vault.
Remarque
Microsoft Entra ID était précédemment connu sous le nom d’Azure Active Directory (Azure AD).
La gestion extensible des clés à l’aide d’Azure Key Vault (AKV) est disponible pour les environnements SQL Server sur Linux, à partir de SQL Server 2022 (16.x) Cumulative Update 12. Suivez les mêmes instructions, mais ignorez les étapes 3 et 4.
Prérequis
Avant de commencer à utiliser Azure Key Vault avec votre instance de SQL Server, assurez-vous que vous respectez les conditions préalables suivantes :
Vous devez disposer d’un abonnement Azure.
Créer un locataire Microsoft Entra.
Familiarisez-vous avec les principaux du stockage de la gestion de clés extensible à l’aide d’Azure Key Vault en consultant la rubrique Gestion de clés extensible à l’aide d’Azure Key Vault (SQL Server).
Être en mesure de modifier le Registre sur l'ordinateur SQL Server.
Installez la version de Visual Studio C++ Redistribuable basée sur la version de SQL Server que vous exécutez :
Version de SQL Server Visual C++ Version Redistributable 2008, 2008 R2, 2012, 2014 Packages redistribuables Visual C++ pour Visual Studio 2013 2016, 2017, 2019, 2022 Redistribuable Visual C++ pour Visual Studio 2015 Familiarisez-vous avec l'accès à Azure Key Vault derrière un pare-feu si vous envisagez d'utiliser le connecteur SQL Server pour Azure Key Vault derrière un pare-feu ou avec un serveur proxy.
Remarque
Dans SQL Server 2022 (16.x) CU 14 et versions ultérieures, SQL Server sur Linux prend en charge la gestion de clés extensible TDE avec Azure Key Vault. Les étapes 3 et 4 de ce guide ne sont pas requises pour SQL Server sur Linux.
Étape 1 : Configurer un principal de service Microsoft Entra
Pour accorder à votre instance SQL Server des autorisations d'accès à votre coffre de clés Azure, vous avez besoin d'un compte de principal de service dans Microsoft Entra ID.
Connectez-vous au portail Azure et effectuez l’une des actions suivantes :
Sélectionnez le bouton Microsoft Entra ID.
Sélectionnez Plus de services, puis, dans le volet Tous les services, saisissez Microsoft Entra ID.
Inscrivez une application avec Microsoft Entra ID en procédant comme suit. Pour obtenir des instructions étape par étape, consultez la section Obtenir une identité pour l’application du billet de blog Azure Key Vault, Azure Key Vault – Étape par étape.
Dans la section Gestion de votre ressource Microsoft Entra ID, sélectionnez Inscriptions d’applications.
Sur la page Inscriptions d’applications, sélectionnez Nouvelle inscription.
Dans le volet Inscrire une application, entrez le nom de l'application pour l'utilisateur, puis sélectionnez Inscrire.
Dans le volet gauche, sélectionnez Certificats et secrets > Secrets clients >Nouveau secret client.
Sous Ajoutez une clé secrète client, entrez une description et une date d’expiration appropriée, puis sélectionnez Ajouter. Vous ne pouvez pas choisir une période d'expiration supérieure à 24 mois. Pour plus d’informations, consultez Ajouter une clé secrète client.
Dans le volet Certificats et secrets, sous Valeur, sélectionnez le bouton Copier en regard de la valeur de la clé secrète client à utiliser pour créer une clé asymétrique dans SQL Server.
Dans le volet gauche, sélectionnez Vue d’ensemble puis, dans la boîte de dialogue l’ID de l’application (client), copiez la valeur à utiliser pour créer une clé asymétrique dans SQL Server.
Étape 2 : créer un coffre de clés
Sélectionnez la méthode que vous souhaitez utiliser pour créer un coffre de clés.
Créez un coffre de clés à l’aide du portail Azure
Vous pouvez utiliser le portail Azure pour créer le coffre de clés et y ajouter un principal Microsoft Entra.
Créez un groupe de ressources.
Toutes les ressources Azure que vous créez via le Portail Azure doivent être contenues dans un groupe de ressources que vous créez pour héberger votre coffre de clés. Le nom de la ressource dans cet exemple est DocsSampleRG. Choisissez vos propres noms de groupe de ressources et de coffre de clés, car tous les noms de coffre de clés doivent être uniques au monde.
Dans le volet Créer un groupe de ressources, sous Détails du projet, entrez les valeurs, puis sélectionnez Évaluer + Créer.
Dans le portail Azure, recherchez ou sélectionnez les services de coffres de clés pour créer un coffre de clés. Sélectionnez Créer.
Dans le volet Créer un coffre de clés, sélectionnez l’onglet Informations de base. Entrez les valeurs appropriées pour l’onglet. Nous vous recommandons également d’activer la protection contre la suppression définitive.
Dans l’onglet Configuration de l’accè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. Nous examinerons les deux options, mais il est recommandé d’opter pour le Contrôle d’accès en fonction du rôle Azure. Pour plus d’informations, consultez Vue d’ensemble du modèle d’accès.
Vous pouvez laisser l’onglet Mise en réseau comme valeur par défaut, ou configurer les paramètres réseau du coffre de clés. Si vous utilisez un pare-feu avec un coffre de clés, l’option Autoriser les services Microsoft approuvés à contourner le pare-feu doit être activée, à moins que vous utilisez des connexions de point de terminaison privé. Pour plus d’informations, consultez Configurer les pare-feux et réseaux virtuels d’Azure Key Vault.
Sélectionnez Vérifier + créer et créez le coffre de clés.
Contrôle d’accès en fonction du rôle Azure
La méthode recommandée consiste à utiliser le Contrôle d’accès en fonction du rôle Azure (RBAC) pour attribuer des autorisations au coffre de clés. Cette méthode vous permet d’attribuer des autorisations aux utilisateurs, aux groupes et aux applications à un niveau plus granulaire. Vous pouvez attribuer des autorisations au coffre de clés au niveau du plan de gestion (attributions de rôles Azure), et au niveau du plan de données (stratégies d’accès au coffre de clés). Si vous ne pouvez utiliser que la stratégie d’accès, vous pouvez sauter cette section et passer à la section Stratégie d’accès au coffre. Pour plus d’informations sur les autorisations RBAC d’Azure Key Vault, consultez Rôles intégrés Azure pour les opérations de plan de données du coffre de clés.
Accédez à la ressource du coffre de clés que vous avez créée, puis sélectionnez le paramètre Contrôle d’accès (IAM).
Sélectionnez Ajouter>Ajouter une attribution de rôle.
L’application EKM a besoin du rôle Utilisateur du service de chiffrement de Key Vault pour effectuer les opérations d’enveloppement et de désenveloppement. Rechercher Utilisateur du service de chiffrement Key Vault et sélectionnez le rôle. Cliquez sur Suivant.
Dans l’onglet Membres, sélectionnez l’option Sélectionner des membres, puis recherchez l’application Microsoft Entra que vous avez créée à l’étape 1. Sélectionnez cette application, puis le bouton Sélectionner.
Sélectionnez Vérifier + attribuer deux fois pour terminer l’attribution de rôle.
L’utilisateur qui crée la clé a besoin du rôle Administrateur de coffre de clés. Recherchez le rôle Administrateur de coffre de clés et sélectionnez-le. Cliquez sur Suivant.
Comme pour les étapes précédentes, ajoutez le membre qui crée la clé et attribuez-lui le rôle.
Stratégie d’accès au coffre
Remarque
Si vous utilisez l’option Contrôle d’accès en fonction du rôle Azure, vous pouvez ignorer cette section. Si vous modifiez le modèle d’autorisation, vous pouvez le faire en accédant au menu Configuration de l’accès du coffre de clés. Assurez-vous que vous disposez des autorisations correctes pour gérer le coffre de clés. Pour plus d’informations, consultez Activer les autorisations de RBAC Azure sur Key Vault.
Dans l’onglet Configuration de l’accès, sélectionnez Stratégie d’accès au coffre de clés. Si vous utilisez un coffre de clés existant, vous pouvez sélectionner le menu Stratégies d’accès à partir de la ressource du coffre de clés, puis sélectionner Créer.
Dans le volet Créer une stratégie d’accès, sélectionnez les autorisations Get et List dans les options Opérations de gestion des clés. Sélectionnez les autorisations Désenvelopper la clé et Envelopper la clé dans les options Opérations de chiffrement. Sélectionnez Suivant.
Dans l’onglet Principal, sélectionnez l’application créée à l’étape 1.
Sélectionnez Suivant, puis Créer.
Créer une clé
Dans le volet Coffre de clés, sélectionnez Clés, puis l’option Générer/Importer. Le volet Créer une clé s’ouvre. Saisissez un nom de coffre de clés. Sélectionnez l’option Générer et entrez un nom pour la clé. Le connecteur SQL Server exige que le nom de clé utilise uniquement les caractères « a-z », « A-Z », « 0-9 » et « - », avec une limite de 26 caractères.
Utilisez le type de clé RSA et la taille de clé RSA 2048. Actuellement, EKM ne prend en charge que les clés RSA. Définissez les dates d’activation et d’expiration comme il convient et définissez Activé sur Oui.
Bonnes pratiques
Pour garantir la récupération rapide de clé et être en mesure d’accéder à vos données en dehors d’Azure, nous recommandons les meilleures pratiques suivantes :
Créez votre clé de chiffrement localement sur un appareil HSM (hardware security module) local. Vérifiez qu’il s’agit d’une clé RSA 2048 ou 3072 asymétrique, donc prise en charge par SQL Server.
Importez la clé de chiffrement dans votre coffre de clés Azure. Ce processus est décrit dans les prochaines sections.
Avant d'utiliser la clé dans votre coffre de clés Azure pour la première fois, effectuez une sauvegarde de la clé du coffre de clés Azure à l'aide de la cmdlet PowerShell
Backup-AzureKeyVaultKey
.Chaque fois que vous modifiez la clé (par exemple, ajout de listes de contrôle d’accès, ajout d’étiquettes, ajout d’attributs de clé), veillez à faire une autre sauvegarde de la clé Azure Key Vault.
Remarque
La sauvegarde d’une clé est une opération de clé Azure Key Vault qui retourne un fichier que vous pouvez enregistrer à l’emplacement de votre choix.
L'utilisation du connecteur SQL Server pour Azure Key Vault derrière un pare-feu ou un serveur proxy peut affecter les performances si le trafic est retardé ou bloqué. Familiarisez-vous avec Accéder à Azure Key Vault derrière un pare-feu pour vous assurer que les règles appropriées sont en place.
Facultatif - Configurer un module de sécurité matériel (HSM) managé par Azure Key Vault
Le HSM (module de sécurité matériel) managé par Azure Key Vault est pris en charge pour SQL Server et SQL Server sur machines virtuelles Azure lors de l’utilisation de la dernière version du connecteur SQL Server, ainsi qu’Azure SQL. Le HSM managé est un service HSM complètement managé, à haut niveau de disponibilité et monolocataire en tant que service. Le HSM managé offre une base sécurisée pour les opérations de chiffrement et le stockage de clés. Le HSM managé est conçu pour répondre aux exigences de sécurité et de conformité les plus strictes.
À l’étape 2, nous avons appris à créer un coffre de clés et une clé dans Azure Key Vault. Vous pouvez éventuellement utiliser un HSM managé par Azure Key Vault pour stocker ou créer une clé à utiliser avec le connecteur SQL Server. Voici les étapes à suivre :
Créez un HSM managé par Azure Key Vault. Pour ce faire, vous pouvez utiliser le Portail Azure en recherchant le service HSM managé par Azure Key Vault et en créant la nouvelle ressource, ou en utilisant Azure CLI, PowerShell ou un modèle ARM.
Activez le HSM managé. Seuls les administrateurs désignés qui ont fait l’objet d’une attribution pendant la création du HSM managé peuvent activer le HSM. Pour ce faire, sélectionnez la ressource de HSM managé dans le Portail Azure en sélectionnant Télécharger le domaine de sécurité dans le menu Vue d’ensemble de la ressource. Suivez ensuite l’un des guides de démarrage rapide pour activer votre HSM managé.
Accorder au principal du service Microsoft Entra des autorisations d'accès au HSM managé. Le rôle Administrateur du HSM managé ne donne pas d’autorisations pour créer une clé. Comme à l’étape 2, l’application EKM a besoin du rôle Utilisateur du chiffrement du HSM managé ou Utilisateur du service de chiffrement du HSM managé pour effectuer des opérations pour envelopper et désenvelopper. Choisissez le type d’application d'entreprise lors de l’ajout du principal pour l’attribution de rôle. Pour plus d’informations, consultez Rôles RBAC locaux intégrés pour HSM managé.
Dans le menu du service HSM managé par Azure Key Vault, sous Paramètre, sélectionnez Clés. Dans la fenêtre Clés, sélectionnez Générer/Importer/Restaurer la sauvegarde pour créer une clé ou importer une clé existante.
Remarque
Lors de la création d’informations d’identification pour accéder au HSM managé, l’identité est
<name of Managed HSM>.managedhsm.azure.net
; elle se trouve dans la Vue d’ensemble du HSM managé par Azure Key Vault en tant qu’URI HSM dans le Portail Azure.La rotation automatique des clés est prise en charge dans le HSM managé par Azure Key Vault. Pour plus d’informations, consultez Configurer la rotation automatique des clés dans Azure Managed HSM.
Le connecteur SQL Server version 15.0.2000.440 ou ultérieure est nécessaire pour prendre en charge le HSM managé par Azure Key Vault.
HSM managé prend en charge les connexions de point de terminaison privé. Si vous souhaitez obtenir plus d’informations, consultez Intégrer HSM managé avec Azure Private Link. Dans cette configuration, l’option de contournement du service approuvé Microsoft doit être activée pour le paramètre Réseau HSM managé Azure Key Vault.
Étape 3 : Installer le connecteur SQL Server
Téléchargez le connecteur SQL Server à partir du Centre de téléchargement Microsoft. Ce téléchargement doit être effectué par l'administrateur de l'ordinateur SQL Server.
Remarque
- Les versions de connecteur SQL Server 1.0.0.440 et antérieures ont été remplacées et ne sont plus prises en charge dans les environnements de production et à l’aide des instructions de la page Maintenance et résolution des problèmes du connecteur SQL Server sous Mise à niveau du connecteur SQL Server.
- À partir de la version 1.0.3.0, le connecteur SQL Server signale les messages d’erreur pertinents dans les journaux des événements Windows à des fins de résolution des problèmes.
- À partir de la version 1.0.4.0, il existe une prise en charge des clouds privés Azure, y compris Azure opéré par 21Vianet, Azure Allemagne et Azure Government.
- Un changement cassant figure dans la version 1.0.5.0, lié à l’algorithme d’empreinte. Vous pourriez rencontrer un échec de restauration des bases de données après la mise à niveau vers la version 1.0.5.0. Pour plus d’informations, consultez l’article 447099 de la Base de connaissances.
- À partir de la version 1.0.5.0 (horodatage : septembre 2020), le connecteur SQL Server prend en charge le filtrage des messages et la logique de nouvelle tentative de requête réseau.
- À compter de la version 1.0.5.0 mise à jour (horodatage : novembre 2020), le connecteur SQL Server prend en charge les clés RSA 2048, RSA 3072, RSA-HSM 2048 et RSA-HSM 3072.
- À partir de la version mise à jour 1.0.5.0 (TimeStamp : novembre 2020), vous pouvez faire référence à une version de clé spécifique dans Azure Key Vault.
Par défaut, le connecteur est installé sur C:\Program Files\SQL Server Connector for Microsoft Azure Key Vault
. Cet emplacement peut être changé lors de l'installation. Si vous le modifiez, ajustez les scripts dans la section suivante.
Il n'existe aucune interface pour le connecteur, mais s'il est correctement installé, Microsoft.AzureKeyVaultService.EKM.dll
est installé sur l'ordinateur. Cet assembly est la DLL du fournisseur EKM de services chiffrement qui doit être inscrite auprès de SQL Server à l'aide de l'instruction CREATE CRYPTOGRAPHIC PROVIDER
.
L’installation du connecteur SQL Server vous permet également de télécharger des exemples de scripts pour le chiffrement SQL Server.
Pour consulter des explications des codes d’erreur, les paramètres de configuration ou les tâches de maintenance pour le connecteur SQL Server, reportez-vous à :
- A. Instructions de maintenance du Connecteur SQL Server
- C. Explications des codes d’erreur du Connecteur SQL Server
Étape 4 : Ajouter une clé de Registre pour prendre en charge le fournisseur EKM
Avertissement
La modification du Registre doit être effectuée par les utilisateurs qui savent exactement ce qu'ils font. De graves problèmes peuvent se produire si vous modifiez le Registre de façon incorrecte. Pour une protection supplémentaire, sauvegardez le Registre avant de le modifier. Ensuite, vous pouvez restaurer le Registre si un problème se produit.
Assurez-vous que le serveur SQL Server est installé et en cours d'exécution.
Exécutez regedit pour ouvrir l'éditeur du Registre.
Créez une clé de Registre
SQL Server Cryptographic Provider
surHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
. Le chemin complet estHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider
.Cliquez avec le bouton droit sur la clé de Registre
SQL Server Cryptographic Provider
, puis sélectionnez Autorisations.Octroyez les autorisations de contrôle total sur la clé de Registre
SQL Server Cryptographic Provider
au compte d'utilisateur exécutant le service SQL Server.Sélectionnez Apply (Appliquer), puis OK.
Fermez l'Éditeur du Registre et redémarrez le service SQL Server.
Remarque
Si vous utilisez TDE avec EKM ou Azure Key Vault sur une instance de cluster de basculement, vous devez effectuer une étape supplémentaire pour ajouter
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider
à la routine Point de contrôle du registre de clusters afin que le registre puisse être synchronisé entre les nœuds. La synchronisation facilite la récupération de base de données après le basculement et la rotation des clés.Pour ajouter la clé de Registre à la routine Point de contrôle du registre de clusters, dans PowerShell, exécutez la commande suivante :
Add-ClusterCheckpoint -RegistryCheckpoint "SOFTWARE\Microsoft\SQL Server Cryptographic Provider" -Resourcename "SQL Server"
Étape 5 : Configurer SQL Server
Reportez-vous à B. Forum aux questions pour lire une remarque concernant les niveaux d’autorisation minimaux nécessaires pour chaque action de cette section.
Configurer la base de données master
Exécutez sqlcmd ou ouvrez SQL Server Management Studio.
Configurez SQL Server pour utiliser EKM en exécutant le script Transact-SQL suivant :
-- Enable advanced options. USE master; GO EXEC sp_configure 'show advanced options', 1; GO RECONFIGURE; GO -- Enable EKM provider EXEC sp_configure 'EKM provider enabled', 1; GO RECONFIGURE;
Inscrivez le connecteur en tant que fournisseur EKM avec SQL Server.
Créez un fournisseur de services de chiffrement à l’aide du connecteur SQL Server, qui est un fournisseur EKM pour Azure Key Vault. Dans cet exemple, le nom du fournisseur est
AzureKeyVault_EKM
.CREATE CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM FROM FILE = 'C:\Program Files\SQL Server Connector for Microsoft Azure Key Vault\Microsoft.AzureKeyVaultService.EKM.dll'; GO
Remarque
Le chemin d’accès ne peut pas dépasser 256 caractères.
Configurez des identifiants SQL Server pour un compte de connexion SQL Server afin d'utiliser le coffre de clés.
Des informations d’identification doivent être ajoutées à chaque connexion appelée à effectuer un chiffrement à l’aide d’une clé à partir du coffre de clés. Cela peut inclure :
Une connexion administrateur SQL Server qui utilisera le coffre de clés afin de configurer et de gérer des scénarios de chiffrement SQL Server.
D'autres comptes de connexion SQL Server qui peuvent activer TDE ou d'autres fonctionnalités de chiffrement SQL Server.
Il existe un mappage un-à-un entre les identifiants et les connexions. Autrement dit, chaque connexion doit disposer de ses propres informations d’identification.
Modifiez ce script Transact-SQL de la manière suivante :
Modifiez l’argument
IDENTITY
(DocsSampleEKMKeyVault
) de sorte qu’il pointe vers votre coffre Azure Key Vault.- Si vous utilisez Azure global, remplacez l’argument
IDENTITY
par le nom de votre Azure Key Vault de l’Étape 2 : Créer un coffre de clés. - Si vous utilisez un Cloud Azure privé (par exemple, Azure Government, Microsoft Azure opéré 21Vianet ou Azure Allemagne), remplacez l'argument
IDENTITY
par l'URI du coffre renvoyé à l'étape 3 de la section Créer un coffre de clés et une clé à l'aide de PowerShell. N’incluez pashttps://
dans l’URI du coffre de clés.
- Si vous utilisez Azure global, remplacez l’argument
Remplacez la première partie de l'argument
SECRET
par l'ID client Microsoft Entra de l'Étape 1 : Configurer un principal de service Microsoft Entra. Dans cet exemple, l’ID client estd956f6b9xxxxxxx
.Important
Veillez à bien supprimer les tirets de l’ID de l’application (client).
Complétez la seconde partie de l'argument
SECRET
avec la Clé secrète client à partir de l'Étape 1 : Configurer un principal de service Microsoft Entra. Dans cet exemple, la clé secrète client estyrA8X~PldtMCvUZPxxxxxxxx
. La chaîne finale de l'argumentSECRET
sera une longue séquence de lettres et de chiffres, sans traits d'union (à l'exception de la section Clé secrète client, dans le cas où la clé secrète client contient des traits d'union).USE master; CREATE CREDENTIAL sysadmin_ekm_cred WITH IDENTITY = 'DocsSampleEKMKeyVault', -- for public Azure -- WITH IDENTITY = 'DocsSampleEKMKeyVault.vault.usgovcloudapi.net', -- for Azure Government -- WITH IDENTITY = 'DocsSampleEKMKeyVault.vault.azure.cn', -- for Microsoft Azure operated by 21Vianet -- WITH IDENTITY = 'DocsSampleEKMKeyVault.vault.microsoftazure.de', -- for Azure Germany -- WITH IDENTITY = '<name of Managed HSM>.managedhsm.azure.net', -- for Managed HSM (HSM URI in the Azure portal resource) --<----Application (Client) ID ---><--Microsoft Entra app (Client) ID secret--> SECRET = 'd956f6b9xxxxxxxyrA8X~PldtMCvUZPxxxxxxxx' FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM; -- Add the credential to the SQL Server administrator's domain login ALTER LOGIN [<domain>\<login>] ADD CREDENTIAL sysadmin_ekm_cred;
Pour obtenir un exemple d'utilisation de variables pour les arguments
CREATE CREDENTIAL
et la suppression par programmation des tirets de l'ID client, consultez CREATE CREDENTIAL.Ouvrez votre clé Azure Key Vault dans votre instance SQL Server.
Que vous ayez créé une clé ou importé une clé asymétrique, comme décrit dans l'Étape 2 : Créer un coffre de clés, vous devez ouvrir cette clé. Ouvrez la clé en spécifiant son nom dans le script Transact-SQL suivant.
Important
Veillez d'abord à remplir les conditions préalables au Registre pour cette étape.
- Remplacez
EKMSampleASYKey
par le nom souhaité pour la clé dans SQL Server. - Remplacez
ContosoRSAKey0
par le nom de votre clé dans Azure Key Vault ou votre HSM managé. Vous trouverez ci-dessous un exemple de clé sans version.
CREATE ASYMMETRIC KEY EKMSampleASYKey FROM PROVIDER [AzureKeyVault_EKM] WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0', CREATION_DISPOSITION = OPEN_EXISTING;
À compter de la version mise à jour 1.0.5.0 du connecteur SQL Server, vous pouvez vous référer à une version de clé spécifique dans Azure Key Vault :
CREATE ASYMMETRIC KEY EKMSampleASYKey FROM PROVIDER [AzureKeyVault_EKM] WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0/1a4d3b9b393c4678831ccc60def75379', CREATION_DISPOSITION = OPEN_EXISTING;
Dans l’exemple de script précédent,
1a4d3b9b393c4678831ccc60def75379
représente la version spécifique de la clé qui sera utilisée. Si vous utilisez ce script, le fait de mettre à jour la clé avec une nouvelle version n’a pas d’importance. La version de la clé (par exemple)1a4d3b9b393c4678831ccc60def75379
sera toujours utilisée pour les opérations de base de données.- Remplacez
Créez une connexion à l'aide de la clé asymétrique dans SQL Server que vous avez créée à l'étape précédente.
--Create a Login that will associate the asymmetric key to this login CREATE LOGIN TDE_Login FROM ASYMMETRIC KEY EKMSampleASYKey;
Créez une connexion à partir de la clé asymétrique dans SQL Server. Supprimez le mappage des informations d'identification de l'Étape 5 : Configurer SQL Server afin que les identifiants puissent être mappés avec la nouvelle connexion.
--Now drop the credential mapping from the original association ALTER LOGIN [<domain>\<login>] DROP CREDENTIAL sysadmin_ekm_cred;
Modifiez la nouvelle connexion et mappez les informations d’identification EKM à la nouvelle connexion.
--Now add the credential mapping to the new Login ALTER LOGIN TDE_Login ADD CREDENTIAL sysadmin_ekm_cred;
Configurer la base de données utilisateur à chiffrer
Créez une base de données de test qui sera chiffrée avec la clé Azure Key Vault.
--Create a test database that will be encrypted with the Azure Key Vault key CREATE DATABASE TestTDE;
Créer une clé de chiffrement de base de données en utilisant l'
ASYMMETRIC KEY
(EKMSampleASYKey
).USE <DB Name>; --Create an ENCRYPTION KEY using the ASYMMETRIC KEY (EKMSampleASYKey) CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER ASYMMETRIC KEY EKMSampleASYKey;
Chiffrez la base de données de test. Activez TDE en définissant
ENCRYPTION ON
.--Enable TDE by setting ENCRYPTION ON ALTER DATABASE TestTDE SET ENCRYPTION ON;
Détails du Registre
Exécutez la requête Transact-SQL suivante dans la base de données
master
pour afficher la clé asymétrique utilisée.SELECT name, algorithm_desc, thumbprint FROM sys.asymmetric_keys;
L’instruction retourne ceci :
name algorithm_desc thumbprint EKMSampleASYKey RSA_2048 <key thumbprint>
Dans la base de données utilisateur (
TestTDE
), exécutez la requête Transact-SQL suivante pour afficher la clé de chiffrement utilisée.SELECT encryptor_type, encryption_state_desc, encryptor_thumbprint FROM sys.dm_database_encryption_keys WHERE database_id = DB_ID('TestTDE');
L’instruction retourne ceci :
encryptor_type encryption_state_desc encryptor_thumbprint ASYMMETRIC KEY ENCRYPTED <key thumbprint>
Nettoyage
Nettoyez les objets de test. Supprimez tous les objets qui ont été créés dans ce script de test.
-- CLEAN UP USE master; GO ALTER DATABASE [TestTDE] SET SINGLE_USER WITH ROLLBACK IMMEDIATE; DROP DATABASE [TestTDE]; GO ALTER LOGIN [TDE_Login] DROP CREDENTIAL [sysadmin_ekm_cred]; DROP LOGIN [TDE_Login]; GO DROP CREDENTIAL [sysadmin_ekm_cred]; GO USE master; GO DROP ASYMMETRIC KEY [EKMSampleASYKey]; DROP CRYPTOGRAPHIC PROVIDER [AzureKeyVault_EKM]; GO
Pour obtenir des exemples de scripts, consultez le blog sur Chiffrement des données transparentes SQL Server et la gestion de clés extensible avec Azure Key Vault.
La clé de Registre
SQL Server Cryptographic Provider
n'est pas effacée automatiquement après la suppression d'une clé ou de toutes les clés EKM. Elle doit être effacée manuellement. L'effacement de la clé de Registre doit être effectué avec une prudence extrême, car nettoyer le Registre peut interrompre prématurément la fonctionnalité EKM. Pour effacer la clé de Registre, supprimez la clé de RegistreSQL Server Cryptographic Provider
surHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
.
Dépannage
Si la clé de Registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider
n'est pas créée ou que les autorisations requises ne sont pas accordées, l'instruction DDL suivante échoue :
CREATE ASYMMETRIC KEY EKMSampleASYKey
FROM PROVIDER [AzureKeyVault_EKM]
WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0',
CREATION_DISPOSITION = OPEN_EXISTING;
Msg 33049, Level 16, State 2, Line 65
Key with name 'ContosoRSAKey0' does not exist in the provider or access is denied. Provider error code: 2058. (Provider Error - No explanation is available, consult EKM Provider for details)
Clé secrètes clients sur le point d'expirer
Si les informations d’identification ont une clé secrète client qui va expirer, un nouveau secret peut leur être affecté.
Mettez à jour la clé secrète créée à l'Étape 1 : Configurer un principal de service Microsoft Entra.
Modifiez les identifiants en utilisant la même identité et le nouveau secret à l'aide du code suivant. Remplacez
<New Secret>
par votre nouveau secret :ALTER CREDENTIAL sysadmin_ekm_cred WITH IDENTITY = 'DocsSampleEKMKeyVault', SECRET = '<New Secret>';
Redémarrez le service SQL Server.
Remarque
Si vous utilisez EKM dans un groupe de disponibilité (AG), vous devez modifier les identifiants et redémarrer le service SQL Server sur tous les nœuds de l'AG.
Faire pivoter une clé asymétrique avec une nouvelle clé AKV ou une nouvelle version de clé AKV
Remarque
- Lors de la rotation manuelle d’une clé AKV, SQL Server prend en charge à la fois la clé AKV sans version ou la clé avec version et il n’est pas nécessaire d’utiliser une clé AKV différente.
- La clé AKV d’origine peut être pivotée pour créer une nouvelle version qui peut remplacer la clé précédente créée dans SQL Server.
- Pour la rotation manuelle des clés, une nouvelle clé asymétrique SQL Server doit être créée en se référant à la clé sans version ou à la clé avec version qui a fait l’objet d’une rotation dans AKV. Pour la nouvelle clé asymétrique SQL Server, la clé AKV sans version sera automatiquement choisie en utilisant la version de clé la plus élevée dans AKV. Pour la clé avec version, vous devez indiquer la version la plus élevée dans AKV à l’aide de la syntaxe
WITH PROVIDER_KEY_NAME = <key_name>/<version>
. Vous pouvez modifier la clé de chiffrement de la base de données pour la chiffrer à nouveau avec la nouvelle clé asymétrique. Le même nom de clé (avec ou sans version) peut être utilisé avec la stratégie de rotation AKV. Pour une clé avec version, la version actuelle doit être ajoutée. Pour une clé sans version, utilisez le même nom de clé.
SQL Server n’a pas de mécanisme pour faire pivoter automatiquement la clé asymétrique utilisée pour TDE. Les étapes de rotation manuelle d'une clé asymétrique sont les suivantes.
L’information d’identification utilisée dans notre configuration initiale (
sysadmin_ekm_cred
) peut également être réutilisée pour la rotation des clés. Vous pouvez également créer une nouvelle information d’identification pour la nouvelle clé asymétrique.CREATE CREDENTIAL <new_credential_name> WITH IDENTITY = <key vault>, SECRET = 'existing/new secret' FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM;
Ajoutez l’information d’identification au principal :
ALTER LOGIN [domain\userName]; ADD CREDENTIAL <new_credential_name>;
Créez la nouvelle clé asymétrique sur la base de la nouvelle clé (après rotation de la clé). La nouvelle clé peut être une clé sans version (
ContosoRSAKey0
dans notre exemple) ou une clé avec version (ContosoRSAKey0/1a4d3b9b393c4678831ccc60def75379
où1a4d3b9b393c4678831ccc60def75379
est la version de la clé mise à jour dans AKV) :CREATE ASYMMETRIC KEY <new_ekm_key_name> FROM PROVIDER [AzureKeyVault_EKM] WITH PROVIDER_KEY_NAME = <new_key_from_key_vault>, CREATION_DISPOSITION = OPEN_EXISTING;
Créez une connexion à partir de la nouvelle clé asymétrique :
CREATE LOGIN <new_login_name> FROM ASYMMETRIC KEY <new_ekm_key_name>;
Supprimez l’information d’identification du principal :
ALTER LOGIN [domain\username] DROP CREDENTIAL <new_credential_name>;
Mappez les identifiants AKV à la nouvelle connexion :
ALTER LOGIN <new_login_name>; ADD CREDENTIAL <new_credential_name>;
Modifiez la clé de chiffrement de base de données (DEK) pour rechiffrer avec la nouvelle clé asymétrique :
USE [databaseName]; GO ALTER DATABASE ENCRYPTION KEY ENCRYPTION BY SERVER ASYMMETRIC KEY <new_ekm_key_name>;
Vous pouvez vérifier la nouvelle clé asymétrique et la clé de chiffrement utilisée dans la base de données :
SELECT encryptor_type, encryption_state_desc, encryptor_thumbprint FROM sys.dm_database_encryption_keys WHERE database_id = DB_ID('databaseName');
Cette empreinte devrait correspondre à la clé de registre sous le chemin
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider\Azure Key Vault\<key_vault_url>\<thumbprint>
et vous donner leKeyUri
pour votre clé pivotée.
Important
La rotation du protecteur TDE logique pour un serveur désigne le passage à une nouvelle clé asymétrique qui protège la clé de chiffrement de base de données (DEK). La rotation des clés est une opération en ligne et ne doit prendre que quelques secondes, car elle ne déchiffre et ne rechiffre que la DEK, et non la base de données entière.
Ne supprimez pas les versions précédentes de la clé après une rotation. Lorsque les clés sont pivotées, certaines données sont toujours chiffrées avec les clés précédentes, comme les anciennes sauvegardes de base de données, les fichiers journaux de sauvegardes, les fichiers journaux virtuels (VLF) et les fichiers journaux de transactions. Les clés précédentes peuvent également être nécessaires pour la récupération ou la restauration d’une base de données.