Provider di chiavi esterne nei cluster Big Data di SQL Server

Importante

Il componente aggiuntivo per i cluster Big Data di Microsoft SQL Server 2019 verrà ritirato. Il supporto per i cluster Big Data di SQL Server 2019 terminerà il 28 febbraio 2025. Tutti gli utenti esistenti di SQL Server 2019 con Software Assurance saranno completamente supportati nella piattaforma e fino a quel momento il software continuerà a ricevere aggiornamenti cumulativi di SQL Server. Per altre informazioni, vedere il post di blog relativo all'annuncio e Opzioni per i Big Data nella piattaforma Microsoft SQL Server.

Questo articolo contiene informazioni dettagliate su come configurare i provider di chiavi esterne nei cluster Big Data di SQL Server per la gestione delle chiavi.

Per altre informazioni sul modo in cui vengono usate le versioni delle chiavi nei cluster Big Data di SQL Server, vedere Versioni delle chiavi nei cluster Big Data di SQL Server.

Per informazioni sulla configurazione e l'uso della crittografia dei dati inattivi, vedere le guide seguenti:

• Concetti sulla crittografia dei dati inattivi e guida alla configurazione
• Guida all'uso delle zone di crittografia HDFS in cluster Big Data di SQL Server
• Guida all'uso della funzione Transparent Data Encryption (TDE) di dati inattivi per i cluster Big Data di SQL Server

Prerequisiti

• Note sulla versione dei cluster Big Data di SQL Server 2019. CU11+ obbligatorio.
• Strumenti per Big Data che includono azdata 20.3.5+.
• Utente dei cluster Big Data di SQL Server con privilegi amministrativi Kubernetes, membro del ruolo clusterAdmins. Per altre informazioni, vedere Gestire l'accesso ai cluster Big Data in modalità Active Directory.
• Applicazione del modello di provider esterno. Vedere Crittografia dei dati inattivi per BDC di SQL Server.

Crittografia della chiave radice con provider esterni

Con la possibilità di inserire chiavi esterne nei cluster Big Data di SQL Server, la chiave di crittografia principale recupera la chiave pubblica usando l'applicazione distribuita dal cliente. Quando si ruotano e si usano le chiavi HDFS, le chiamate per decrittografare le chiavi HDFS vengono inviate al piano di controllo e poi reindirizzate all'applicazione usando l'identificatore chiave specificato dal cliente. Per SQL Server, le richieste di crittografia vengono inviate ed eseguite dal piano di controllo, poiché questo dispone della chiave pubblica. Anche le richieste di decrittografia della chiave DEK di SQL Server vengono inviate al piano di controllo e poi vengono reindirizzate all'applicazione che si interfaccia con il provider esterno, ad esempio un modulo di protezione hardware.

Il diagramma seguente illustra le interazioni durante la configurazione delle chiavi esterne nel piano di controllo:

Dopo aver installato la chiave, la crittografia e la decrittografia di payload diversi sono protette dalla chiave di crittografia principale. Questa protezione è simile alle chiavi gestite dal sistema, ad eccezione del fatto che le chiamate di decrittografia instradate al piano di controllo vengono poi instradate all'app plug-in del Servizio di gestione delle chiavi. L'app plug-in del Servizio di gestione delle chiavi instrada la richiesta al percorso appropriato, ad esempio un modulo di protezione hardware, Hashicorp Vault o a un altro prodotto.

Impostazione

L'applicazione modello indicata è il plug-in usato per interfacciarsi con il provider di chiavi esterne. Questa applicazione deve essere personalizzata e distribuita nei cluster Big Data per fungere da punto di integrazione con il provider di chiavi esterno scelto.

L'applicazione del modello contiene esempi su come eseguire l'integrazione con implementazioni di provider esterni usando il protocollo PKCS11 standard con SoftHSM. Ci sono anche esempi che usano Azure Key Vault e Hashicorp Vault. Le applicazioni del modello vengono rese disponibili così come sono come implementazioni di riferimento.

Le sezioni seguenti illustrano i passaggi necessari per configurare un provider di chiavi esterne da usare come chiave radice della crittografia per i database di SQL Server e le zone di crittografia HDFS.

Creare una chiave RSA 2048 nel provider di chiavi esterne

Creare un file PEM con una chiave RSA da 2048 bit e caricarlo nell'archivio dei valori della chiave nel provider di chiavi esterne.

Ad esempio, il file della chiave potrebbe essere aggiunto all'archivio KV in Hashicorp Vault nel percorso bdc-encryption-secret e il nome del segreto può essere rsa2048.

Personalizzare e distribuire l'applicazione di integrazione nei cluster Big Data

1. Nel computer locale passare alla cartella che contiene kms_plugin_app, le applicazioni del modello AppDeploy dei cluster Big Data.

2. Personalizzare l'applicazione scegliendo uno dei modelli e modificandolo in base allo scenario:

   • Il file custom_softhsm.py contiene un'implementazione di riferimento che usa SoftHSM
   • Il file custom_akv.py contiene un esempio di Azure Key Vault
   • Il file custom_akv.py contiene un esempio di HashiCorp Vault

   Attenzione

   Non modificare i contratti della funzione o le firme, ovvero i punti di integrazione. Modificare solo le implementazioni della funzione, se necessario.

3. Denominare di conseguenza il file creato dal modello precedente. Salvare, ad esempio, custom_softhsm.py come my_custom_integration_v1.py e quindi eseguire le personalizzazioni. Questo approccio è importante per il passaggio successivo.

4. app.py è il punto di ingresso che caricherà l'applicazione. In questo file è necessario modificare la riga 11 in modo che punti al nome del file personalizzato senza l'estensione PY del passaggio precedente. In base all'esempio precedente, modificare:

   ...
   import utils
   from json_objects import EncryptDecryptRequest
   import custom_softhsm as custom
   
   def handler(operation, payload, pin, key_attributes, version):
   ...
   

   impostando il valore seguente:

   ...
   import utils
   from json_objects import EncryptDecryptRequest
   import my_custom_integration_v1 as custom
   
   def handler(operation, payload, pin, key_attributes, version):
   ...
   

5. Dalla cartella che contiene spec.yaml distribuire l'applicazione nei cluster Big Data usando questo comando:

   azdata app create -s
   

6. Attendere il completamento della distribuzione dell'applicazione e verificare lo stato Pronto usando questo comando:

   azdata app list
   

Configurare i cluster Big Data per l'uso del provider di chiavi esterne

1. Impostare la variabile di ambiente AZDATA_EXTERNAL_KEY_PIN affinché generi il token che consente l'accesso al provider di chiavi esterne:

   export AZDATA_EXTERNAL_KEY_PIN=<your PIN/token here>
   

   Nota

   Il processo di distribuzione dell'applicazione di integrazione usa il token per accedere al provider di chiavi esterne. Tuttavia, la variabile AZDATA_EXTERNAL_KEY_PIN viene salvata e crittografata nel piano di controllo dei cluster Big Data in modo che possa essere interpretata dall'applicazione. È anche possibile usare un meccanismo di autenticazione diverso, ma è necessario modificare l'applicazione. Controllare l'applicazione Python custom*.py per verificare la logica di integrazione completa usata.

2. Configurare la chiave nei cluster Big Data usando la struttura del comando seguente azdata. Modificare i parametri obbligatori impostando l'implementazione specifica. Nell'esempio seguente viene usata una struttura HashiCorp Vault creata da custom2.py.

   azdata bdc kms update --app-name <YOUR-APP-NAME> --app-version <YOUR-APP-VERSION> \
   --key-attributes keypath=<YOUR-KEY-PATH>,vaulturl=http://<YOUR-IP>:<YOUR-PORT>,keyname=<YOUR-KEY-NAME> \
   --provider External
   

   Il valore del parametro --provider External configura il servizio di gestione delle chiavi dei cluster Big Data per l'uso dell'applicazione di integrazione come endpoint per le operazioni principali.

3. Verificare la chiave di crittografia della radice come chiave gestita esternamente usando il comando seguente.

   azdata bdc kms show
   

Crittografare i database e le zone di crittografia con le nuove chiavi

Dopo la configurazione, i database SQL Server e le zone di crittografia HDFS sono ancora crittografati dalla gerarchia di chiavi precedente. È necessario eseguire la crittografia in modo esplicito usando le chiavi gestite esternamente.

In SQL Server viene installata una nuova chiave asimmetrica basata sulla chiave gestita esternamente. Usarla per crittografare i database.

La chiave asimmetrica può essere visualizzata usando la query T-SQL seguente, con la vista del catalogo di sistema sys.asymmetric_keys.

USE master;
select * from sys.asymmetric_keys;

La chiave asimmetrica viene visualizzata con la convenzione di denominazione tde_asymmetric_key_<version>. L'amministratore di SQL Server può quindi modificare la protezione della chiave DEK impostando la chiave asimmetrica e usando il comando ALTER DATABASE ENCRYPTION KEY. Usare, ad esempio, il comando seguente:

USE db1;
ALTER DATABASE ENCRYPTION KEY ENCRYPTION BY SERVER ASYMMETRIC KEY tde_asymmetric_key_0;

1. Eseguire il comando seguente per controllare la chiave di crittografia corrente:

   azdata bdc hdfs key describe
   

2. Recuperare le informazioni sulla versione della chiave che protegge la chiave della zona di crittografia:

   azdata bdc hdfs key describe --name <key name>
   

3. Ruotare la chiave impostando la nuova chiave gestita esterna:

   azdata bdc hdfs key roll --name <new key name>
   

4. Avviare la crittografia usando questo comando:

   azdata bdc hdfs encryption-zone reencrypt –-path <your EZ path> --action start
   

5. Verificare la gerarchia delle chiavi usando i comandi seguenti:

   azdata bdc kms show
   azdata bdc hdfs key describe
   

Passaggi successivi

• Concetti relativi alla sicurezza per i cluster Big Data di SQL Server
• Configurare un cluster Big Data di SQL Server
• Domande frequenti sui cluster Big Data