Condividi tramite

Configurare Extensible Key Management TDE di SQL Server usando Azure Key Vault

  • Articolo

Si applica a: SQL Server

In questo articolo si procederà all'installazione e alla configurazione del Connettore SQL Server per Azure Key Vault.

Nota

Microsoft Entra ID era precedentemente conosciuto come Azure Active Directory (Azure AD).

Extensible Key Management con Azure Key Vault (AKV) è disponibile per gli ambienti SQL Server in Linux, a partire dall'aggiornamento cumulativo 12 di SQL Server 2022 (16.x). Seguire le stesse istruzioni, ma ignorare i passaggi 3 e 4.

Prerequisiti

Prima di iniziare a usare Azure Key Vault con l'istanza di SQL Server, assicurarsi che siano soddisfatti i prerequisiti seguenti:

Nota

In SQL Server 2022 (16.x) l’unità di capacità 14 e versioni successive SQL Server in Linux supporta la gestione delle chiavi estendibile TDE con Azure Key Vault. I passaggi 3 e 4 di questa guida non sono necessari per SQL Server in Linux.

Passaggio 1: Configurare un'entità servizio Microsoft Entra

Per concedere all'istanza di SQL Server le autorizzazioni di accesso per Azure Key Vault, è necessario un account dell'entità servizio in Microsoft Entra ID.

  1. Accedere al portale di Azure ed eseguire una delle operazioni seguenti:

    • Selezionare il pulsante Microsoft Entra ID.

      Screenshot del riquadro dei servizi di Azure.

    • Selezionare Altri servizi e quindi nella finestra Tutti i servizi digitare Microsoft Entra ID.

  2. Registrare un'applicazione con Microsoft Entra ID seguendo le istruzioni di seguito. Per istruzioni dettagliate, vedere la sezione Ottenere un'identità per l'applicazione del post di blog di Azure Key Vault, Azure Key Vault – Procedura dettagliata.

    1. Nella sezione Gestisci della risorsa Microsoft Entra ID selezionare Registrazioni app.

      Screenshot della pagina Panoramica per Microsoft Entra ID nel portale di Azure.

    2. Nella pagina Registrazioni app seleziona Nuova registrazione.

      Screenshot della finestra delle Registrazioni app nel portale di Azure.

    3. Nel riquadro Registra un'applicazione immettere il nome dell'app visualizzato agli utenti e quindi selezionare Registra.

      Screenshot del riquadro applicazione

    4. Nel riquadro a sinistra selezionare Certificati e segreti> e quindi selezionare >Nuovo segreto client.

      Screenshot del riquadro Certificati e segreti per l’App nel portale di Azure.

    5. In Aggiungi un segreto client immettere una descrizione e una scadenza appropriata e quindi selezionare Aggiungi. Non è possibile scegliere un periodo di scadenza maggiore di 24 mesi. Per altre informazioni, vedere Aggiungere un segreto client.

      Screenshot della sezione Aggiungi un segreto client per l’App nel portale di Azure.

    6. Nel riquadro Certificati e segreti in Valore selezionare il pulsante Copia accanto al valore del segreto client da usare per la creazione di una chiave asimmetrica in SQL Server.

      Screenshot che mostra il valore segreto nel portale di Azure.

    7. Nel riquadro sinistro selezionare Panoramica e quindi nella casella ID applicazione (client) copiare il valore da usare per la creazione di una chiave asimmetrica in SQL Server.

      Screenshot del valore ID applicazione (client) nel riquadro “Panoramica”.

Passaggio 2: Creare un insieme di credenziali delle chiavi

Selezionare il metodo che si vuole usare per creare un insieme di credenziali delle chiavi.

Creare un'istanza di Key Vault usando il portale di Azure

È possibile usare il portale di Azure per creare l'insieme di credenziali delle chiavi e quindi aggiungere un'entità di sicurezza di Microsoft Entra.

  1. Creare un gruppo di risorse.

    Tutte le risorse di Azure create tramite il portale di Azure devono essere contenute in un gruppo di risorse che viene creato per ospitare l'insieme di credenziali delle chiavi. Il nome della risorsa in questo esempio è DocsSampleRG. Scegliere un nome per il gruppo di risorse e l'insieme di credenziali delle chiavi poiché tutti i nomi degli insiemi di credenziali delle chiavi devono essere univoci a livello globale.

    Nel riquadro Crea un gruppo di risorse in Dettagli del progetto immettere i valori e quindi selezionare Rivedi e crea.

    Screenshot del riquadro Crea gruppo di risorse nel portale di Azure.

  2. Nella portale di Azure, cercare o selezionare i servizi Insiemi di credenziali delle chiavi per creare un insieme di credenziali delle chiavi. Seleziona Crea.

    Nel riquadro Crea un insieme di credenziali delle chiavi, selezionare la scheda Informazioni di base, immettere i valori appropriati per la scheda. È anche consigliabile abilitare la protezione dall'eliminazione.

    Screenshot del riquadro Crea un insieme di credenziali delle chiavi nel portale di Azure.

  3. Nella scheda Configurazione di accesso è possibile selezionare il controllo degli accessi in base al ruolo di Azure o i criteri di accesso a Key Vault. Entrambe le opzioni sono disponibili, ma è consigliabile usare l'opzione di controllo degli accessi in base al ruolo di Azure. Per altre informazioni, vedere Informazioni generali sul modello di accesso.

    Screenshot del riquadro Crea insieme di credenziali delle chiavi e della scheda Configurazione di accesso nel portale di Azure.

  4. È possibile lasciare la scheda Rete come predefinita oppure configurare le impostazioni di rete per l'insieme di credenziali delle chiavi. Se si usa un firewall con l'insieme di credenziali delle chiavi, l'opzione Consenti ai servizi Microsoft attendibili di ignorare il firewall deve essere abilitata, a meno che non si usino connessioni endpoint private. Per altre informazioni, vedere Configurare i firewall e le reti virtuali di Azure Key Vault.

  5. Selezionare Rivedi e crea e creare l'insieme di credenziali delle chiavi.

Controllo dell'accesso basato sui ruoli di Azure

Il metodo consigliato consiste nell'usare il controllo degli accessi in base al ruolo di Azure per assegnare le autorizzazioni all'insieme di credenziali delle chiavi. Questo metodo consente di assegnare autorizzazioni a utenti, gruppi e applicazioni a un livello più granulare. È possibile assegnare autorizzazioni all'insieme di credenziali delle chiavi nel piano di gestione (assegnazioni di ruolo di Azure) e nel piano dati (criteri di accesso dell'insieme di credenziali delle chiavi). Se è possibile usare solo i criteri di accesso, è possibile ignorare questa sezione e passare alla sezione Politica di accesso al Key Vault. Per altre informazioni sui ruoli, sulle autorizzazioni di controllo degli accessi ad Azure Key Vault, vedere Ruoli predefiniti di Azure per le operazioni del piano dati di Key Vault.

  1. Passare alla risorsa dell'insieme di credenziali delle chiavi creata e selezionare l'impostazione Controllo di accesso (IAM).

  2. Seleziona Aggiungi>Aggiungi assegnazione ruolo.

    Screenshot del pulsante Aggiungi assegnazione di ruolo nel riquadro Controllo di accesso (IAM) nel portale di Azure.

  3. Per eseguire operazioni di wrapping e annullamento del wrapping, l'applicazione EKM richiede il ruolo Utente di crittografia del servizio di crittografia di Key Vault. Cercare Utente di crittografia del servizio di crittografia di Key Vault e selezionare il ruolo. Selezionare Avanti.

    Screenshot della selezione di un'assegnazione di ruolo nella portale di Azure.

  4. Nella scheda Membri selezionare l'opzione Seleziona membri e quindi cercare l'applicazione Microsoft Entra creata nel passaggio 1. Selezionare l'applicazione e quindi il pulsante Seleziona.

    Screenshot del riquadro Seleziona membri per l'aggiunta di un'assegnazione di ruolo nel portale di Azure.

  5. Selezionare Rivedi e assegna due volte per completare l'assegnazione di ruolo.

  6. L'utente che crea la chiave richiede il ruolo di Amministratore di Key Vault. Cercare Amministratore di Key Vault e selezionare il ruolo. Selezionare Avanti.

  7. Analogamente ai passaggi precedenti, aggiungere il membro che crea la chiave e assegnare il ruolo.

Criteri di accesso insieme di credenziali delle chiavi

Nota

Se si usa l'opzione Controllo degli accessi in base al ruolo di Azure, è possibile ignorare questa sezione. Se si modifica il modello di autorizzazione, è possibile farlo passando al menu Configurazione di Accesso dell'insieme di credenziali delle chiavi. Assicurarsi di disporre delle autorizzazioni corrette per la gestione dell’insieme di credenziali delle chiavi. Per altre informazioni, vedere Abilitare le autorizzazioni di Controllo degli accessi in base al ruolo di Azure in Key Vault.

  1. Nella scheda Configurazione di accesso selezionare Criteri di accesso all'insieme di credenziali. Se si usa un insieme di credenziali delle chiavi esistente, è possibile selezionare il menu Criteri di accesso dalla risorsa insieme di credenziali delle chiavi e selezionare Crea.

  2. Nel riquadro Crea un criterio di accesso selezionare Ottieni ed Elenca le autorizzazioni nelle opzioni Operazioni di gestione delle chiavi. Selezionare le autorizzazioni Annullare il ritorno a capo della chiave e Esegui il wrapping della chiave dalle opzioni Operazioni crittografiche. Seleziona Avanti.

    Screenshot del collegamento Aggiungi un criterio di accesso nel riquadro Criteri di accesso.

  3. Nella scheda Entità di sicurezza, selezionare l'applicazione creata nel passaggio 1.

    Screenshot della casella di ricerca dell'applicazione nel riquadro Entità di protezione.

  4. Selezionare Avanti e quindi Crea.

Creazione di una chiave

  1. Nel riquadro Insieme di credenziali delle chiavi selezionare Chiavi e quindi selezionare l'opzione Genera/Importa. Verrà aperto il riquadro Crea una chiave . Immettere un nome dell'insieme di credenziali delle chiavi. Selezionare l’opzione Genera e immettere un nome per la chiave. Connettore SQL Server richiede che il nome della chiave usi solo i caratteri "a-z", "A-Z", "0-9" e "-", con un limite di 26 caratteri.

  2. Usare il tipo di chiave RSA e le dimensioni della chiave RSA pari a 2048. EKM supporta attualmente solo una chiave RSA. Impostare le date di attivazione e di scadenza in base alle esigenze e impostare Abilitato su Sì.

    Screenshot del riquadro Crea chiave.

Procedure consigliate

Per garantire un ripristino rapido della chiave e accedere ai dati all'esterno di Azure, eseguire le procedure consigliate seguenti:

  • Creare la chiave di crittografia in locale in un dispositivo del modulo di protezione hardware (HSM) locale. Assicurarsi di usare una chiave RSA 2048 o 3072 asimmetrica, in modo che sia supportata da SQL Server.

  • Importare la chiave di crittografia in Azure Key Vault. Questo processo è descritto nelle sezioni seguenti.

  • Prima di usare la chiave in Azure Key Vault per la prima volta, eseguire un backup di Azure Key Vault usando il cmdlet PowerShell.

  • Ogni volta che vengono apportate modifiche alla chiave, ad esempio aggiungendo elenchi di controllo di accesso, tag o attributi chiave, assicurarsi di eseguire un altro backup della chiave di Azure Key Vault.

    Nota

    Il backup di una chiave è un'operazione relativa alla chiave di Azure Key Vault che restituisce un file che può essere salvato in qualsiasi posizione.

    L'uso del Connettore SQL Server per Azure Key Vault dietro un firewall o un server proxy può influire sulle prestazioni se il traffico viene ritardato o bloccato. Acquisire familiarità con l’accesso ad Azure Key Vault dietro un firewall per assicurarsi che le regole presenti siano corrette.

Opzione facoltativa - Configurare un modulo HSM gestito (modulo di protezione hardware) di Azure Key Vault

Il modulo HSM gestito (modulo di protezione hardware) di Azure Key Vault è supportato per SQL Server e SQL Server nelle macchine virtuali (VM) di Azure quando si usa la versione più recente del connettore SQL Server e Azure SQL. Il modulo di protezione hardware HSM gestito è un servizio completamente gestito, a disponibilità elevata e a tenant singolo. Il modulo di protezione hardware HSM gestito offre una base sicura per le operazioni di crittografia e l'archiviazione delle chiavi. Il modulo di protezione hardware HSM gestito è progettato per soddisfare i requisiti di sicurezza e conformità più rigorosi.

Nel passaggio 2 si è appreso come creare un insieme di credenziali delle chiavi e una chiave in Azure Key Vault. Come opzione facoltativa è possibile usare un modulo di protezione hardware HSM gestito di Azure Key Vault per archiviare o creare una chiave da usare con il connettore SQL Server. Di seguito sono riportati i passaggi:

  1. Creare un modulo di protezione hardware HSM Azure Key Vault. A tale scopo, è possibile usare il portale di Azure cercando il servizio HSM gestito di Azure Key Vault e creando la nuova risorsa oppure usando l'interfaccia della riga di comando di Azure, PowerShell o un modello di ARM.

  2. Attivare l'HSM gestito. Solo gli amministratori designati assegnati durante la creazione possono attivare il modulo di protezione hardware HSM. A tale scopo, scegliere la risorsa modulo di protezione hardware HSM gestito nel portale di Azure selezionando Scarica dominio di sicurezza nel menu Panoramica della risorsa. Seguire quindi una delle guide introduttive per attivare il modulo di protezione hardware HSM gestito.

  3. Concedere le autorizzazioni per consentire all'entità servizio di Microsoft Entra di accedere al modulo di protezione hardware HSM gestito. Il ruolo amministratore del modulo di protezione hardware HSM gestito non concede le autorizzazioni per creare chiavi. Analogamente al passaggio 2, l'applicazione EKM richiede il ruolo utente Crypto del modulo HSM gestito o utente Crypto del servizio di crittografia del modulo HSM gestito per eseguire operazioni di wrapping e annullamento del wrapping. Scegliere il tipo di applicazione aziendale quando si aggiunge l'entità per l'assegnazione di ruolo. Per ulteriori informazioni, si veda ruoli predefiniti per il controllo degli accessi in base al ruolo locale per il modulo di protezione hardware HSM gestito.

  4. Nel menu del servizio HSM gestito di Azure Key Vault, in Impostazioni selezionare Chiavi. Nella finestra Chiavi selezionare Genera/Importa/Ripristina backup per creare una chiave o importare una chiave esistente.

    Nota

    Quando si creano credenziali per accedere al modulo di protezione hardware HSM gestito, l'identità è <name of Managed HSM>.managedhsm.azure.net, disponibile in Panoramica del modulo di protezione hardware HSM gestito di Azure Key Vault come URI del modulo di protezione hardware HSMnel portale di Azure.

    La rotazione automatica delle chiavi è supportata in un HSM gestito di Azure Key Vault. Per altre informazioni, si veda Configurare la rotazione automatica delle chiavi nel modulo HSM gestito di Azure.

    Per supportare il modulo di protezione hardware HSM gestito di Azure Key Vault è necessario un connettore SQL Server versione 15.0.2000.440 o successiva.

    HSM gestito supporta le connessioni endpoint privato. Per altre informazioni, vedere Integrrare HSM gestito con collegamento privato di Azure. In questa configurazione, l'opzione bypass del servizio attendibile Microsoft deve essere abilitata per l'impostazione Rete del modulo HSM gestito di Azure Key Vault.

Passaggio 3: Installare SQL Server Connector

È possibile scaricare il Connettore SQL Server dall' Area download Microsoft. Il download deve essere eseguito dall'amministratore del computer con SQL Server.

Nota

  • Le versioni 1.0.0.440 e precedenti del Connettore SQL Server sono state sostituite e non sono più supportate negli ambienti di produzione. Attenersi alle istruzioni nella pagina Manutenzione e risoluzione dei problemi del Connettore SQL Server in Aggiornamento del Connettore SQL Server.
  • A partire dalla versione 1.0.3.0, il Connettore SQL Server segnala i messaggi di errore rilevanti ai registri eventi di Windows per la risoluzione dei problemi.
  • A partire dalla versione 1.0.4.0, è disponibile il supporto per i cloud privati di Azure, tra cui Azure operato da 21Vianet, Azure Germania e Azure per enti pubblici.
  • La versione 1.0.5.0 presenta una modifica che causa un'interruzione associata all'algoritmo di identificazione personale. Dopo l'aggiornamento alla versione 1.0.5.0 può verificarsi un errore di ripristino del database. Per altre informazioni, vedere l'articolo della Knowledge Base 447099.
  • A partire dalla versione 1.0.5.0 (data e ora: settembre 2020), il Connettore SQL Server supporta il filtro dei messaggi e la logica di ripetizione dei tentativi di richiesta di rete.
  • A partire dalla versione aggiornata 1.0.5.0 (data e ora: novembre 2020), il Connettore SQL Server supporta le chiavi RSA 2048, RSA 3072, RSA-HSM 2048 e RSA-HSM 3072.
  • A partire dalla versione aggiornata 1.0.5.0 (data e ora: novembre 2020), è possibile fare riferimento a una versione specifica della chiave in Azure Key Vault.

Screenshot dell'installazione guidata del Connettore SQL Server.

Per impostazione predefinita, il Connettore viene installato in C:\Program Files\SQL Server Connector for Microsoft Azure Key Vault. Questo percorso può essere modificato durante l'installazione. Se si modifica il percorso, modificare gli script nella sezione seguente.

Non è disponibile alcuna interfaccia per il Connettore, ma se è installato correttamente, nel computer viene installato Microsoft.AzureKeyVaultService.EKM.dll: Questo assembly è la DLL del provider di crittografia EKM che deve essere registrata con SQL Server usando l'istruzione .

L'installazione del Connettore SQL Server consente anche di scaricare facoltativamente gli script di esempio per la crittografia di SQL Server.

Per la spiegazione dei codici di errore, le impostazioni di configurazione o le attività di manutenzione per il Connettore SQL Server, vedere:

Passaggio 4: Aggiungere la chiave del Registro di sistema per supportare il provider EKM

Avviso

La modifica del Registro di sistema deve essere eseguita dagli utenti che sanno esattamente cosa stanno facendo. Se le modifiche al Registro di sistema vengono apportate in modo non corretto, possono verificarsi problemi gravi. Per una maggiore protezione, eseguire il backup del Registro di sistema prima di modificarlo. E’ possibile ripristinare il Registro di sistema se si verifica un problema.

  1. Assicurarsi che SQL Server sia installato e in esecuzione.

  2. Eseguire regedit per aprire il Registro di sistema.

  3. Creare una chiave del Registro di sistema SQL Server Cryptographic Provider su HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft. Il percorso completo è HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider.

  4. Fare clic con il pulsante destro del mouse sulla chiave del Registro di sistema, quindi selezionare SQL Server Cryptographic ProviderAutorizzazioni.

  5. Concedere le autorizzazioni di controllo completo per la SQL Server Cryptographic Provider chiave del Registro di sistema all'account utente che esegue il servizio SQL Server.

    Screenshot della chiave del Registro di sistema EKM nell'editor del Registro di sistema.

  6. Selezionare Apply (Applica) e quindi OK.

  7. Chiudere l'editor del Registro di sistema e riavviare il servizio SQL Server.

    Nota

    Se si usa TDE con EKM o Azure Key Vault in un'istanza del cluster di failover, è necessario completare un passaggio aggiuntivo per aggiungere HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider alla routine checkpoint del Registro di sistema del cluster, in modo che il Registro di sistema possa eseguire la sincronizzazione tra i nodi. La sincronizzazione facilita il ripristino del database dopo il failover e la rotazione delle chiavi.

    Per aggiungere la chiave del Registro di sistema alla routine checkpoint del Registro di sistema del cluster, in PowerShell eseguire il comando seguente:

    Add-ClusterCheckpoint -RegistryCheckpoint "SOFTWARE\Microsoft\SQL Server Cryptographic Provider" -Resourcename "SQL Server"

Passaggio 5: Configurazione di SQL Server

Per visualizzare una nota sui livelli minimi di autorizzazione necessari per ogni azione in questa sezione, vedere B. Domande frequenti.

Configurare il database master.

  1. Eseguire sqlcmd o aprire SQL Server Management Studio.

  2. Configurare SQL Server per usare EKM eseguendo lo script Transact-SQL seguente:

    -- 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. Registrare il Connettore SQL Server come provider EKM con SQL Server.

    Creare un provider di crittografia usando il Connettore SQL Server che rappresenta un provider EKM per Azure Key Vault. In questo esempio il nome del provider è 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

    Nota

    La lunghezza del percorso file non può superare i 256 caratteri.

  4. Configurare le credenziali SQL Server di un account di accesso di SQL Server per l'uso dell'insieme di credenziali delle chiavi.

    È necessario aggiungere le credenziali a ogni account di accesso che esegue la crittografia usando una chiave dall'insieme di credenziali delle chiavi. Tali attività possono includere:

    • L'account di accesso dell'amministratore di SQL Server che usa l'insieme di credenziali delle chiavi per configurare e gestire gli scenari di crittografia di SQL Server.

    • Altri account di accesso di SQL Server che possono abilitare Transparent Data Encryption o altre funzionalità di crittografia di SQL Server.

    Esiste un mapping uno-a-uno tra le credenziali e gli account di accesso. In altre parole, ogni account di accesso deve avere credenziali univoche.

    Modificare lo script Transact-SQL nei modi seguenti:

    • Modificare l'argomento IDENTITY (DocsSampleEKMKeyVault) in modo che punti all'insieme di credenziali delle chiavi di Azure.

    • Sostituire la prima parte dell'argomento SECRET con l'ID client Microsoft Entra del Passaggio 1: Configurare un'entità servizio Microsoft Entra. In questo esempio l'ID client è d956f6b9xxxxxxx.

      Importante

      Assicurarsi di rimuovere i trattini dall'ID app (client).

    • Completare la seconda parte dell'argomento SECRET con segreto client del Passaggio 1: Configurare un'entità servizio Microsoft Entra. In questo esempio il segreto client è yrA8X~PldtMCvUZPxxxxxxxx. La stringa finale per l'argomento SECRET sarà una lunga sequenza di lettere e numeri, senza trattini (ad eccezione della sezione Segreto client, nel caso in cui il Segreto client contenga trattini).

      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;

    Per un esempio di utilizzo delle variabili per l'argomento CREATE CREDENTIAL e di rimozione dei trattini dall'ID client a livello di codice, si veda CREATE CREDENTIAL.

  5. Aprire la chiave di Azure Key Vault nell'istanza di SQL Server.

    Se è stata creata una nuova chiave o è stata importata una chiave asimmetrica come descritto nel Passaggio 2: Creare un insieme di credenziali delle chiavi, sarà necessario aprire la chiave. Aprire la chiave specificando il nome della chiave nello script Transact-SQL seguente.

    Importante

    Assicurarsi di completare prima i prerequisiti del Registro di sistema per questo passaggio.

    • Sostituire EKMSampleASYKey con il nome che si vuole assegnare alla chiave in SQL Server.
    • Sostituire ContosoRSAKey0 con il nome della chiave in Azure Key Vault o nel modulo HSM gestito. Di seguito è riportato un esempio di chiave senza versione.
    CREATE ASYMMETRIC KEY EKMSampleASYKey
FROM PROVIDER [AzureKeyVault_EKM]
WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0',
CREATION_DISPOSITION = OPEN_EXISTING;

    A partire dalla versione aggiornata 1.0.5.0 del Connettore SQL Server, è possibile fare riferimento a una versione della chiave specifica nell'insieme di credenziali di Azure Key Vault:

    CREATE ASYMMETRIC KEY EKMSampleASYKey
FROM PROVIDER [AzureKeyVault_EKM]
WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0/1a4d3b9b393c4678831ccc60def75379',
CREATION_DISPOSITION = OPEN_EXISTING;

    Nello script di esempio precedente, 1a4d3b9b393c4678831ccc60def75379 rappresenta la versione specifica della chiave che verrà usata. Se si usa questo script, non è importante aggiornare la chiave con una nuova versione. La versione della chiave (ad esempio) 1a4d3b9b393c4678831ccc60def75379 verrà sempre usata per le operazioni del database.

  6. Creare un nuovo account di accesso usando la chiave asimmetrica in SQL Server creata nel passaggio precedente.

    --Create a Login that will associate the asymmetric key to this login
CREATE LOGIN TDE_Login
FROM ASYMMETRIC KEY EKMSampleASYKey;

  7. Creare un nuovo account di accesso in base alla chiave asimmetrica in SQL Server. Eliminare il mapping delle credenziali del Passaggio 5: Configurare SQL Server in modo che sia possibile eseguire il mapping delle credenziali al nuovo account di accesso.

    --Now drop the credential mapping from the original association
ALTER LOGIN [<domain>\<login>]
DROP CREDENTIAL sysadmin_ekm_cred;

  8. Modificare il nuovo account di accesso ed eseguire il mapping delle credenziali EKM al nuovo account di accesso.

    --Now add the credential mapping to the new Login
ALTER LOGIN TDE_Login
ADD CREDENTIAL sysadmin_ekm_cred;

Configurare il database utente da crittografare

  1. Creare un database di test che verrà crittografato con la chiave di Azure Key Vault.

    --Create a test database that will be encrypted with the Azure Key Vault key
CREATE DATABASE TestTDE;

  2. Creare una chiave di crittografia del database usando 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. Crittografare il database di test. Abilitare TDE impostando ENCRYPTION ON.

    --Enable TDE by setting ENCRYPTION ON
ALTER DATABASE TestTDE
SET ENCRYPTION ON;

Dettagli del registro

  1. Eseguire la query Transact-SQL seguente nel database master per visualizzare la chiave asimmetrica usata.

    SELECT name, algorithm_desc, thumbprint FROM sys.asymmetric_keys;

    L'istruzione restituisce:

    name            algorithm_desc    thumbprint
EKMSampleASYKey RSA_2048          <key thumbprint>

  2. Nel database utente (TestTDE), eseguire la query Transact-SQL seguente per visualizzare la chiave di crittografia usata.

    SELECT encryptor_type, encryption_state_desc, encryptor_thumbprint
FROM sys.dm_database_encryption_keys
WHERE database_id = DB_ID('TestTDE');

    L'istruzione restituisce:

    encryptor_type encryption_state_desc encryptor_thumbprint
ASYMMETRIC KEY ENCRYPTED             <key thumbprint>

Eseguire la pulizia

  1. Pulire gli oggetti di test. Eliminare tutti gli oggetti creati in questo script di 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

    Per gli script di esempio, vedere il blog in Transparent Data Encryption e Extensible Key Management di SQL Server con Azure Key Vault.

  2. La chiave del Registro di sistema SQL Server Cryptographic Provider non viene pulita automaticamente dopo l'eliminazione di una chiave o di tutte le chiavi EKM. La pulizia deve essere eseguita manualmente. La pulizia della chiave del Registro di sistema deve essere eseguita con estrema cautela, poiché la pulizia del Registro di sistema, se eseguita prematuramente, può interrompere la funzionalità EKM. Per pulire la chiave del Registro di sistema, eliminare la chiave del Registro di sistema SQL Server Cryptographic Provider in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.

Risoluzione dei problemi

Se la chiave del Registro di sistema HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider non viene creata o le autorizzazioni necessarie non vengono concesse, l'istruzione DDL seguente avrà esito negativo:

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)

Segreti client che stanno per scadere

Se le credenziali presentano un segreto client che sta per scadere, è possibile assegnare un nuovo segreto alla credenziale.

  1. Aggiornare il segreto originariamente creato nel Passaggio 1: Configurare un'entità servizio Microsoft Entra.

  2. Modificare le credenziali usando la stessa identità e il nuovo segreto usando il codice seguente. Sostituire <New Secret> con il nuovo segreto:

    ALTER CREDENTIAL sysadmin_ekm_cred
WITH IDENTITY = 'DocsSampleEKMKeyVault',
SECRET = '<New Secret>';

  3. Riavviare il servizio SQL Server.

Nota

Se si usa EKM in un gruppo di disponibilità (AG), sarà necessario modificare le credenziali e riavviare il servizio SQL Server in tutti i nodi del gruppo di disponibilità.

Ruotare la chiave asimmetrica con una nuova chiave AKV o una nuova versione della chiave AKV

Nota

  • Quando si ruota manualmente una chiave AKV, SQL Server supporta sia la chiave senza versione AKV che la chiave con controllo delle versioni e non è necessario usare una chiave AKV diversa.
  • La chiave AKV originale può essere ruotata creando una nuova versione che può sostituire la chiave precedente creata in SQL Server.
  • Per la rotazione manuale delle chiavi, è necessario creare una nuova chiave asimmetrica di SQL Server che faccia riferimento alla chiave senza versione o alla chiave con controllo delle versioni ruotata in AKV. Per la nuova chiave asimmetrica di SQL Server, la chiave AKV senza versione verrà scelta automaticamente usando la versione della chiave più alta in AKV. Per la chiave con versione, è necessario indicare la versione più recente in AKV usando la sintassi WITH PROVIDER_KEY_NAME = <key_name>/<version>. È possibile modificare la chiave di crittografia del database per crittografare nuovamente con la nuova chiave asimmetrica. Lo stesso nome della chiave (con versione o senza versione) può essere usato con i criteri di rotazione AKV. Per la chiave con versione, è necessario aggiungere la versione corrente. Per la chiave senza versione, usare lo stesso nome di chiave.

SQL Server non dispone di un meccanismo per ruotare automaticamente la chiave asimmetrica usata per TDE. I passaggi per ruotare manualmente una chiave asimmetrica sono i seguenti.

  1. Le credenziali usate nella configurazione iniziale (sysadmin_ekm_cred) possono essere riutilizzate anche per la rotazione delle chiavi. Facoltativamente, creare una nuova credenziale per la nuova chiave asimmetrica.

    CREATE CREDENTIAL <new_credential_name>
    WITH IDENTITY = <key vault>,
    SECRET = 'existing/new secret'
    FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM;

  2. Aggiungere le credenziali all'entità:

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

  3. Creare la nuova chiave asimmetrica in base alla nuova chiave (dopo la rotazione della chiave). La nuova chiave può essere una chiave senza versione (ContosoRSAKey0 in questo esempio) o una chiave con controllo delle versioni (ContosoRSAKey0/1a4d3b9b393c4678831ccc60def75379 dove 1a4d3b9b393c4678831ccc60def75379 è la versione della chiave aggiornata in 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. Creare un nuovo account di accesso in base alla nuova chiave asimmetrica:

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

  5. Eliminare le credenziali dall'entità di sicurezza:

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

  6. Eseguire il mapping delle credenziali AKV al nuovo account di accesso:

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

  7. Modificare la chiave di crittografia del database (DEK) per crittografare nuovamente con la nuova chiave asimmetrica:

    USE [databaseName];
GO
ALTER DATABASE ENCRYPTION KEY ENCRYPTION BY SERVER ASYMMETRIC KEY <new_ekm_key_name>;

  8. È possibile verificare la nuova chiave asimmetrica e la chiave di crittografia usata nel database:

    SELECT encryptor_type, encryption_state_desc, encryptor_thumbprint
FROM sys.dm_database_encryption_keys
WHERE database_id = DB_ID('databaseName');

    Questa identificazione personale deve corrispondere alla chiave del Registro di sistema nel percorso HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider\Azure Key Vault\<key_vault_url>\<thumbprint> e fornire l'oggetto KeyUri per la chiave ruotata.

Importante

Ruotare una protezione TDE logica per un server significa passare a una nuova chiave asimmetrica o certificato che protegge la chiave di crittografia del database. La rotazione delle chiavi è un'operazione online e richiede solo pochi secondi, perché si limita a decrittografare e crittografare nuovamente la chiave DEK, ma non l'intero database.

Non eliminare le versioni precedenti della chiave dopo la rotazione. Quando viene eseguito la rotazione delle chiavi, alcuni dati rimangono crittografati con le chiavi precedenti, ad esempio backup di database precedenti, file di log sottoposti a backup, file di log virtuale e file di log delle transazioni. Le chiavi precedenti potrebbero anche essere necessarie per un ripristino del database o per un ripristino del database.

Contenuto correlato