Share via


Extensible Key Management tramite l'insieme di credenziali delle chiavi di Azure (SQL Server)

Il Connettore SQL Server per Microsoft Azure Key Vault consente alla crittografia SQL Server di sfruttare il servizio Azure Key Vault come provider EKM (Extensible Key Management) per proteggere le chiavi di crittografia.

Contenuto dell'argomento:

Utilizzi di EKM

Un'organizzazione può usare SQL Server crittografia per proteggere i dati sensibili. SQL Server crittografia include Transparent Data Encryption (TDE), Crittografia a livello di colonna (CLE) e Crittografia di backup. In tutti questi casi, i dati vengono crittografati tramite una chiave DEK simmetrica. La chiave di crittografia dei dati simmetrica è ulteriormente protetta crittografandola con una gerarchia di chiavi archiviate in SQL Server. In alternativa, l'architettura del provider EKM consente SQL Server di proteggere le chiavi di crittografia dei dati usando una chiave asimmetrica archiviata all'esterno di SQL Server in un provider di crittografia esterno. L'utilizzo dell'architettura del provider EKM aggiunge un ulteriore livello di sicurezza consentendo alle organizzazioni di separare la gestione delle chiavi e dei dati.

Il connettore SQL Server per Azure Key Vault consente di SQL Server sfruttare il servizio di insieme di credenziali delle chiavi scalabile, ad alte prestazioni e a disponibilità elevata come provider EKM per la protezione delle chiavi di crittografia. Il servizio dell'insieme di credenziali delle chiavi può essere usato con installazioni di SQL Server in Microsoft Azure Macchine virtuali e per i server locali. Il servizio dell'insieme di credenziali delle chiavi consente inoltre di usare i moduli di protezione hardware (HSM) controllati e monitorati rigorosamente per un livello di protezione maggiore per le chiavi di crittografia asimmetriche. Per altre informazioni sull'insieme di credenziali delle chiavi, vedere Insieme di credenziali delle chiavi di Azure.

L'immagine seguente illustra il flusso di processo di EKM con l'insieme di credenziali delle chiavi. I numeri dei passaggi del processo nell'immagine non sono concepiti per corrispondere ai numeri dei passaggi della configurazione riportati di seguito.

SQL Server EKM con Azure Key Vault

Passaggio 1: Configurare l'insieme di credenziali delle chiavi per essere usato da SQL Server

Usare la procedura seguente per configurare un insieme di credenziali delle chiavi da usare con il motore di database SQL Server per la protezione della chiave di crittografia. È possibile che per l'organizzazione sia già in uso un insieme di credenziali. Quando non esiste un insieme di credenziali, l'amministratore di Azure nell'organizzazione designato per gestire le chiavi di crittografia può creare un insieme di credenziali, generare una chiave asimmetrica nell'insieme di credenziali e quindi autorizzare SQL Server a usare la chiave. Per acquisire familiarità con il servizio dell'insieme di credenziali delle chiavi, consultare Introduzione all'insieme di credenziali delle chiavi di Azuree il riferimento di PowerShell Cmdlet per l'insieme di credenziali delle chiavi di Azure .

Importante

Se si dispone di più sottoscrizioni di Azure, è necessario usare la sottoscrizione che contiene SQL Server.

  1. Creare un insieme di credenziali: creare un insieme di credenziali seguendo le istruzioni presenti nella sezione Creare un insieme di credenziali delle chiavi dell'articolo Introduzione all'insieme di credenziali delle chiavi di Azure. Registrare il nome dell'insieme di credenziali. Questo argomento usa ContosoKeyVault come nome dell'insieme di credenziali delle chiavi.

  2. Generare una chiave asimmetrica nell'insieme di credenziali: La chiave asimmetrica nell'insieme di credenziali delle chiavi viene usata per proteggere SQL Server chiavi di crittografia. Solo la parte pubblica della chiave asimmetrica lascia sempre l'insieme di credenziali, la parte privata non viene mai esportata dall'insieme di credenziali. Tutte le operazioni crittografiche che usano la chiave asimmetrica vengono delegate all'insieme di credenziali delle chiavi di Azure e sono protette dalla sicurezza dell'insieme di credenziali delle chiavi.

    Esistono diversi modi per generare una chiave asimmetrica e archiviarla nell'insieme di credenziali. È possibile generare una chiave esternamente e importarla nell'insieme di credenziali come file con estensione pfx oppure creare la chiave direttamente nell'insieme di credenziali mediante le API dell'insieme di credenziali delle chiavi.

    Il connettore SQL Server richiede che le chiavi asimmetriche siano RSA a 2048 bit e il nome della chiave possa usare solo i caratteri "a-z", "A-Z", "0-9" e "-". In questo documento il nome della chiave asimmetrica viene definito ContosoMasterKey. Sostituire questo nome con il nome univoco da usare per la chiave.

    Importante

    L'importazione della chiave asimmetrica è consigliata per gli scenari di produzione in quanto consente all'amministratore di depositare la chiave in un sistema di deposito delle chiavi. Se la chiave asimmetrica viene creata nell'insieme di credenziali, non potrà essere depositata perché la chiave privata non può mai lasciare l'insieme di credenziali. È consigliabile depositare le chiavi usate per proteggere i dati critici. Se si perde una chiave asimmetrica, non sarà più possibile recuperare i dati.

    Importante

    L'insieme di credenziali delle chiavi supporta più versioni della stessa chiave denominata. Le chiavi da usare da SQL Server Connector non devono essere con controllo delle versioni o con rollback. Se l'amministratore vuole eseguire il rollback della chiave usata per la crittografia SQL Server, è necessario creare una nuova chiave con un nome diverso nell'insieme di credenziali e usare per crittografare la chiave DEK.

    Per altre informazioni su come importare una chiave nell'insieme di credenziali delle chiavi o creare una chiave nell'insieme di credenziali delle chiavi (non consigliato per un ambiente di produzione), vedere la sezione Aggiungere una chiave o un segreto nell'insieme di credenziali delle chiavi in Introduzione all'insieme di credenziali delle chiavi di Azure.

  3. Ottenere le entità servizio di Azure Active Directory da usare per SQL Server: quando l'organizzazione esegue la registrazione per un servizio cloud Microsoft, ottiene un'istanza di Azure Active Directory. Creare entità servizio in Azure Active Directory per SQL Server da usare (per eseguire l'autenticazione in Azure Active Directory) durante l'accesso all'insieme di credenziali delle chiavi.

    • Un'entità servizio sarà necessaria da un amministratore SQL Server per accedere all'insieme di credenziali durante la configurazione di SQL Server per l'uso della crittografia.

    • Un'altra entità servizio sarà necessaria dal motore di database SQL Server per accedere all'insieme di credenziali per annullare il wrapping delle chiavi usate nella crittografia SQL Server.

    Per altre informazioni su come registrare un'applicazione e generare un'entità servizio, vedere la sezione Registrare un'applicazione con Azure Active Directory in Introduzione all'insieme di credenziali delle chiavi di Azure. Il processo di registrazione restituisce un ID applicazione (noto anche come ID CLIENT) e una Chiave di autenticazione (nota anche come Segreto) per ogni entità serviziodi Azure Active Directory. Se usato nell'istruzione CREATE CREDENTIAL , il trattino deve essere rimosso dall'ID CLIENT. Registrare questi valori da usare negli script seguenti:

    • Entità servizio per un account di accesso sysadmin : CLIENTID_sysadmin_login e SECRET_sysadmin_login

    • Entità servizio per il motore di database di SQL Server: CLIENTID_DBEngine e SECRET_DBEngine.

  4. Concedere l'autorizzazione per le entità servizio per accedere al Key Vault: sia le CLIENTID_sysadmin_login che le entità di CLIENTID_DBEngineService richiedono le autorizzazioni get, list, wrapKey e unwrapKey nell'insieme di credenziali delle chiavi. Se si intende creare chiavi tramite SQL Server è necessario concedere anche l'autorizzazione di creazione nell'insieme di credenziali delle chiavi.

    Importante

    Gli utenti devono avere almeno le operazioni wrapKey e unwrapKey per l'insieme di credenziali delle chiavi.

    Per altre informazioni sulla concessione delle autorizzazioni all'insieme di credenziali, vedere la sezione Autorizzare l'applicazione a usare la chiave o il segreto in Introduzione all'insieme di credenziali delle chiavi di Azure.

    Collegamenti alla documentazione dell'insieme di credenziali delle chiavi di Azure

Passaggio 2: Installare SQL Server Connector

Il connettore SQL Server viene scaricato e installato dall'amministratore del computer SQL Server. Il connettore SQL Server è disponibile come download dall'Area download Microsoft. Cercare SQL Server Connector per l'insieme di credenziali delle chiavi di Microsoft Azure, esaminare i dettagli, i requisiti di sistema e le istruzioni di installazione e scegliere di scaricare il connettore e avviare l'installazione con il pulsante Scarica. Esaminare la licenza e accettarne le condizioni, quindi continuare.

Per impostazione predefinita, il connettore viene installato in C:\Programmi\Connettore SQL Server per Microsoft Azure Key Vault. Questo percorso può essere modificato durante l'installazione. Se si modifica il percorso, apportare la modifica negli script riportati di seguito.

Dopo aver completato l'installazione, nel computer vengono installati gli elementi seguenti:

  • Microsoft.AzureKeyVaultService.EKM.dll: si tratta della DLL del provider EKM crittografico che deve essere registrata con SQL Server tramite l'istruzione CREATE CRYPTOGRAPHIC PROVIDER.

  • SQL Server Connector per l'insieme di credenziali delle chiavi di Azure: si tratta di un servizio di Windows che consente al provider di crittografia EKM di comunicare con l'insieme di credenziali delle chiavi.

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

Passaggio 3: Configurare SQL Server per l'uso di un provider EKM per l'insieme di credenziali delle chiavi

Autorizzazioni

Per completare l'intero processo è necessaria l'autorizzazione CONTROL SERVER o l'appartenenza al ruolo predefinito del server sysadmin . Le azioni specifiche richiedono le autorizzazioni seguenti:

  • Per creare un provider di crittografia è necessaria l'autorizzazione CONTROL SERVER o l'appartenenza al ruolo predefinito del server sysadmin .

  • Per modificare un'opzione di configurazione ed eseguire l'istruzione RECONFIGURE, è necessario disporre dell'autorizzazione a livello di server ALTER SETTINGS. L'autorizzazione ALTER SETTINGS è assegnata implicitamente ai ruoli predefiniti del server sysadmin e serveradmin .

  • Per creare le credenziali, è necessaria l'autorizzazione ALTER ANY CREDENTIAL.

  • Per aggiungere le credenziali per un account di accesso, è necessaria l'autorizzazione ALTER ANY LOGIN.

  • Per creare una chiave asimmetrica, è necessaria l'autorizzazione CREATE ASYMMETRIC KEY.

Per configurare SQL Server per l'uso di un provider di crittografia

  1. Configurare il motore di database per l'uso di EKM e registrare (creare) il provider di crittografia con SQL Server.

    -- Enable advanced options.
    USE master;
    GO
    
    sp_configure 'show advanced options', 1 ;
    GO
    RECONFIGURE ;
    GO
    -- Enable EKM provider
    sp_configure 'EKM provider enabled', 1 ;
    GO
    RECONFIGURE ;
    GO
    
    -- Create a cryptographic provider, using the SQL Server Connector
    -- which is an EKM provider for the Azure Key Vault. This example uses 
    -- the name AzureKeyVault_EKM_Prov.
    
    CREATE CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM_Prov 
    FROM FILE = 'C:\Program Files\SQL Server Connector for Microsoft Azure Key Vault\Microsoft.AzureKeyVaultService.EKM.dll';
    GO
    
  2. Configurare una credenziale SQL Server per un account di accesso amministratore di SQL Server per usare l'insieme di credenziali delle chiavi per configurare e gestire scenari di crittografia SQL Server.

    Importante

    L'argomento IDENTITY di richiede il nome dell'insieme di CREATE CREDENTIAL credenziali delle chiavi. L'argomento SECRET di CREATE CREDENTIAL richiede che l'ID <>client (senza trattini) e <il segreto> vengano passati insieme senza uno spazio tra di essi.

    Nell'esempio seguente l'ID client (EF5C8E09-4D2A-4A76-9998-D93440D8115D) viene rimosso dai trattini e immessi come stringa e il segreto è rappresentato dalla stringa EF5C8E094D2A4A769998D93440D8115DSECRET_sysadmin_login.

    USE master;
    CREATE CREDENTIAL sysadmin_ekm_cred 
        WITH IDENTITY = 'ContosoKeyVault', 
        SECRET = 'EF5C8E094D2A4A769998D93440D8115DSECRET_sysadmin_login' 
    FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM_Prov ;
    
    -- Add the credential to the SQL Server administrators domain login 
    ALTER LOGIN [<domain>/<login>]
    ADD CREDENTIAL sysadmin_ekm_cred;
    

    Per un esempio di uso di variabili per gli argomenti e la rimozione a livello di codice dei CREATE CREDENTIAL trattini dall'ID client, vedere CREATE CREDENTIAL (Transact-SQL).

  3. Se è stata importata una chiave asimmetrica come descritto in precedenza nella sezione 3 del passaggio 1, aprire la chiave, fornendo il nome della chiave nell'esempio seguente.

    CREATE ASYMMETRIC KEY CONTOSO_KEY 
    FROM PROVIDER [AzureKeyVault_EKM_Prov]
    WITH PROVIDER_KEY_NAME = 'ContosoMasterKey',
    CREATION_DISPOSITION = OPEN_EXISTING;
    

    Anche se non è consigliabile per la produzione (perché la chiave non può essere esportata), è possibile creare una chiave asimmetrica direttamente nell'insieme di credenziali da SQL Server. Se in precedenza non è stata importata alcuna chiave, creare una chiave asimmetrica nell'insieme di credenziali delle chiavi ai fini del test usando lo script seguente. Eseguire lo script, usando un account di accesso di cui è stato effettuato il provisioning con le credenziali sysadmin_ekm_cred .

    CREATE ASYMMETRIC KEY CONTOSO_KEY 
    FROM PROVIDER [AzureKeyVault_EKM_Prov]
    WITH ALGORITHM = RSA_2048,
    PROVIDER_KEY_NAME = 'ContosoMasterKey';
    

Suggerimento

Gli utenti che ricevono l'errore Non è possibile esportare la chiave pubblica dal provider. Codice errore del provider: 2053. deve controllare le autorizzazioni get, list, wrappingKey e unwrapKey nell'insieme di credenziali delle chiavi.

Per altre informazioni, vedere gli argomenti seguenti:

Esempio

Esempio A: Transparent Data Encryption tramite una chiave asimmetrica dell'insieme di credenziali delle chiavi

Dopo aver completato i passaggi precedenti, creare le credenziali e un account di accesso e quindi creare una chiave di crittografia del database protetta dalla chiave asimmetrica nell'insieme di credenziali delle chiavi. Usare la chiave di crittografia del database per crittografare un database con TDE.

Per crittografare un database è necessaria l'autorizzazione CONTROL per il database.

Per abilitare TDE tramite EKM e l'insieme di credenziali delle chiavi
  1. Creare le credenziali di SQL Server per il motore di database da usare durante l'accesso a EKM con l'insieme di credenziali delle chiavi durante il caricamento del database.

    Importante

    L'argomento IDENTITY di richiede il nome dell'insieme di credenziali delle CREATE CREDENTIAL chiavi. L'argomento SECRET di CREATE CREDENTIAL richiede che l'ID <>client (senza trattini) e <il segreto> vengano passati insieme senza uno spazio tra di essi.

    Nell'esempio seguente l' ID client (EF5C8E09-4D2A-4A76-9998-D93440D8115D) viene immesso con tutti i trattini rimossi come stringa EF5C8E094D2A4A769998D93440D8115D e il Segreto è rappresentato dalla stringa SECRET_DBEngine.

    USE master;
    CREATE CREDENTIAL Azure_EKM_TDE_cred 
        WITH IDENTITY = 'ContosoKeyVault', 
        SECRET = 'EF5C8E094D2A4A769998D93440D8115DSECRET_DBEngine' 
        FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM_Prov ;
    
  2. Creare un account di accesso SQL Server da usare dal motore di database per TDE e aggiungerle. Questo esempio usa la chiave asimmetrica CONTOSO_KEY archiviata nell'insieme di credenziali delle chiavi importato o creato in precedenza per il database master, come sopra descritto nella sezione 3 del passaggio 3 .

    USE master;
    -- Create a SQL Server login associated with the asymmetric key 
    -- for the Database engine to use when it loads a database 
    -- encrypted by TDE.
    CREATE LOGIN TDE_Login 
    FROM ASYMMETRIC KEY CONTOSO_KEY;
    GO 
    
    -- Alter the TDE Login to add the credential for use by the 
    -- Database Engine to access the key vault
    ALTER LOGIN TDE_Login 
    ADD CREDENTIAL Azure_EKM_TDE_cred ;
    GO
    
  3. Creare la chiave di crittografia del database (DEK) che verrà usata per TDE. La chiave DEK può essere creata usando qualsiasi algoritmo supportato da SQL Server o la lunghezza della chiave. La chiave DEK verrà protetta dalla chiave asimmetrica nell'insieme di credenziali delle chiavi.

    Questo esempio usa la chiave asimmetrica CONTOSO_KEY archiviata nell'insieme di credenziali delle chiavi importato o creato in precedenza, come sopra descritto nella sezione 3 del passaggio 3 .

    USE ContosoDatabase;
    GO
    
    CREATE DATABASE ENCRYPTION KEY 
    WITH ALGORITHM = AES_128 
    ENCRYPTION BY SERVER ASYMMETRIC KEY CONTOSO_KEY;
    GO
    
    -- Alter the database to enable transparent data encryption.
    ALTER DATABASE ContosoDatabase 
    SET ENCRYPTION ON ;
    GO
    

    Per altre informazioni, vedere gli argomenti seguenti:

Esempio B: Crittografia dei backup tramite una chiave asimmetrica dell'insieme di credenziali delle chiavi

I backup crittografati sono supportati a partire da SQL Server 2014. L'esempio seguente crea e ripristina un backup crittografato di una chiave DEK protetta dalla chiave asimmetrica nell'insieme di credenziali delle chiavi.

USE master;
BACKUP DATABASE [DATABASE_TO_BACKUP]
TO DISK = N'[PATH TO BACKUP FILE]' 
WITH FORMAT, INIT, SKIP, NOREWIND, NOUNLOAD, 
ENCRYPTION(ALGORITHM = AES_256, SERVER ASYMMETRIC KEY = [CONTOSO_KEY]);
GO

Esempio del codice di ripristino.

RESTORE DATABASE [DATABASE_TO_BACKUP]
FROM DISK = N'[PATH TO BACKUP FILE]' WITH FILE = 1, NOUNLOAD, REPLACE;
GO

Per altre informazioni sulle opzioni di backup, vedere BACKUP (Transact-SQL).

Esempio C: Crittografia a livello di colonna tramite una chiave asimmetrica dell'insieme di credenziali delle chiavi

L'esempio seguente crea una chiave simmetrica protetta dalla chiave asimmetrica nell'insieme di credenziali delle chiavi. La chiave simmetrica viene quindi usata per crittografare i dati nel database.

Questo esempio usa la chiave asimmetrica CONTOSO_KEY archiviata nell'insieme di credenziali delle chiavi importato o creato in precedenza, come sopra descritto nella sezione 3 del passaggio 3 . Per usare questa chiave asimmetrica nel database ContosoDatabase , è necessario eseguire nuovamente l'istruzione CREATE ASYMMETRIC KEY in modo da fornire al database ContosoDatabase un riferimento alla chiave.

USE [ContosoDatabase];
GO

-- Create a reference to the key in the key vault
CREATE ASYMMETRIC KEY CONTOSO_KEY 
FROM PROVIDER [AzureKeyVault_EKM_Prov]
WITH PROVIDER_KEY_NAME = 'ContosoMasterKey',
CREATION_DISPOSITION = OPEN_EXISTING;

-- Create the data encryption key.
-- The data encryption key can be created using any SQL Server 
-- supported algorithm or key length.
-- The DEK will be protected by the asymmetric key in the key vault

CREATE SYMMETRIC KEY DATA_ENCRYPTION_KEY
    WITH ALGORITHM=AES_256
    ENCRYPTION BY ASYMMETRIC KEY CONTOSO_KEY;

DECLARE @DATA VARBINARY(MAX);

--Open the symmetric key for use in this session
OPEN SYMMETRIC KEY DATA_ENCRYPTION_KEY 
DECRYPTION BY ASYMMETRIC KEY CONTOSO_KEY;

--Encrypt syntax
SELECT @DATA = ENCRYPTBYKEY(KEY_GUID('DATA_ENCRYPTION_KEY'), CONVERT(VARBINARY,'Plain text data to encrypt'));

-- Decrypt syntax
SELECT CONVERT(VARCHAR, DECRYPTBYKEY(@DATA));

--Close the symmetric key
CLOSE SYMMETRIC KEY DATA_ENCRYPTION_KEY;

Vedere anche

CREATE CRYPTOGRAPHIC PROVIDER (Transact-SQL)CREATE CREDENTIAL (Transact-SQL)CREATE ASYMMETRIC KEY (Transact-SQL)CREATE SYMMETRICKEY (Transact-SQL)Extensible Key Management (EKM)Enable TDE using EKMBackup Encryption Create an Encrypted Backup