Partager via

Configurer la Gestion de clés extensible TDE de SQL Server avec Azure Key Vault

  • Article

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 s'appelait Azure Active Directory (Azure AD) jusqu'à une date récente.

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 :

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.

  1. Connectez-vous au portail Azure et effectuez l’une des actions suivantes :

    • Sélectionnez le bouton Microsoft Entra ID.

      Capture d'écran du volet services Azure.

    • Sélectionnez Plus de services, puis, dans le volet Tous les services, saisissez Microsoft Entra ID.

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

    1. Dans la section Gestion de votre ressource Microsoft Entra ID, sélectionnez Inscriptions d’applications.

      Capture d'écran de la page de présentation de Microsoft Entra ID dans le portail Azure.

    2. Sur la page Inscriptions d’applications, sélectionnez Nouvelle inscription.

      Capture d’écran du volet des inscriptions d’applications dans le portail Azure.

    3. Dans le volet Inscrire une application, entrez le nom de l'application pour l'utilisateur, puis sélectionnez Inscrire.

      Capture d'écran du volet « Inscrire une application ».

    4. Dans le volet gauche, sélectionnez Certificats et secrets > Secrets clients >Nouveau secret client.

      Capture d’écran du volet Certificats et secrets pour l’application dans le portail Azure.

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

      Capture d’écran de la section Ajouter une clé secrète client pour l’application dans le portail Azure.

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

      Capture d’écran de la valeur d’un secret dans le portail Azure.

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

      Capture d'écran de l'« ID de l'application (client) » dans le volet Vue d'ensemble.

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

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

    Capture d’écran du volet Créer un groupe de ressources dans le portail Azure.

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

    Capture d’écran du volet Créer un coffre de clés dans le portail Azure.

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

    Capture d’écran du volet Créer un coffre de clés et de l’onglet Configuration de l’accès dans le portail Azure.

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

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

  1. 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).

  2. Sélectionnez Ajouter>Ajouter une attribution de rôle.

    Capture d’écran du bouton Ajouter une attribution de rôle dans le volet Contrôle d’accès (IAM) du portail Azure.

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

    Capture d’écran de la sélection d’une attribution de rôle dans le portail Azure.

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

    Capture d’écran du volet Sélectionner des membres pour l’ajout d’une attribution de rôle dans le portail Azure.

  5. Sélectionnez Vérifier + attribuer deux fois pour terminer l’attribution de rôle.

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

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

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

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

    Capture d'écran du lien « Ajouter une stratégie d'accès » dans le volet « Stratégies d'accès ».

  3. Dans l’onglet Principal, sélectionnez l’application créée à l’étape 1.

    Capture d'écran de la zone de recherche d'application sur le volet principal.

  4. Sélectionnez Suivant, puis Créer.

Créer une clé

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

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

    Capture d'écran du volet « Créer une clé ».

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 la procédure à suivre :

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

  2. 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é.

  3. 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é.

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

Capture d'écran de l'Assistant Installation du Connecteur SQL Server.

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 à :

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

  1. Assurez-vous que le serveur SQL Server est installé et en cours d'exécution.

  2. Exécutez regedit pour ouvrir l'éditeur du Registre.

  3. Créez une clé de Registre SQL Server Cryptographic Provider sur HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft. Le chemin complet est HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider.

  4. Cliquez avec le bouton droit sur la clé de Registre SQL Server Cryptographic Provider, puis sélectionnez Autorisations.

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

    Capture d'écran de la clé de Registre EKM dans l'« Éditeur du Registre ».

  6. Sélectionnez Apply (Appliquer), puis OK.

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

  1. Exécutez sqlcmd ou ouvrez SQL Server Management Studio.

  2. 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;

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

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

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

      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 est yrA8X~PldtMCvUZPxxxxxxxx. La chaîne finale de l'argument SECRET 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.

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

  6. 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;

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

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

  1. 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;

  2. 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;

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

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

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

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

  2. 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 Registre SQL Server Cryptographic Provider sur HKEY_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é.

  1. Mettez à jour la clé secrète créée à l'Étape 1 : Configurer un principal de service Microsoft Entra.

  2. 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>';

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

  1. 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;

  2. Ajoutez l’information d’identification au principal :

    ALTER LOGIN [domain\userName];
ADD CREDENTIAL <new_credential_name>;

  3. 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;

  4. Créez une connexion à partir de la nouvelle clé asymétrique :

    CREATE LOGIN <new_login_name>
FROM ASYMMETRIC KEY <new_ekm_key_name>;

  5. Supprimez l’information d’identification du principal :

    ALTER LOGIN [domain\username]
DROP CREDENTIAL <new_credential_name>;

  6. Mappez les identifiants AKV à la nouvelle connexion :

    ALTER LOGIN <new_login_name>;
ADD CREDENTIAL <new_credential_name>;

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

  8. 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 le KeyUri 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.

Contenu connexe