Versioni delle chiavi nei cluster Big Data di SQL Server
Si applica a: 
SQL Server 2019 (15.x)
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 fornisce informazioni dettagliate su come vengono usate le versioni delle chiavi per la gestione delle chiavi dei cluster Big Data di SQL Server e la rotazione delle chiavi per HDFS e SQL Server. L'articolo include informazioni dettagliate su come le versioni possono incorporare le chiavi del cliente.
Per informazioni generali sulla protezione dei cluster Big Data di SQL Server, vedere Concetti relativi alla sicurezza per i cluster Big Data di SQL Server.
Per informazioni sulla configurazione e l'uso della funzionalità di 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
Chiavi HDFS
L'uso della crittografia dei dati inattivi in HDFS coinvolge i concetti seguenti:
- Zone di crittografia (EZ): la zona di crittografia è una cartella in HDFS che è associata a una chiave. Tutti i file in questa cartella sono crittografati. La zona di crittografia predefinita di cui viene effettuato il provisioning nei cluster Big Data di SQL Server è denominata "securelake".
- Chiavi della zona di crittografia (chiave EZ): chiave simmetrica denominata. La chiave predefinita gestita dal sistema di cui viene effettuato il provisioning nei cluster Big Data di SQL Server è "securelakekey". Le chiavi della zona di crittografia vengono gestite mediante Hadoop KMS (Key Management Server) in esecuzione all'interno dei pod del nodo dei nomi dei cluster Big Data di SQL Server. Le chiavi EZ sono ulteriormente protette da una chiave di crittografia principale archiviata in controldb (descritta nelle sezioni seguenti). Le chiavi EZ vengono crittografate in Hadoop KMS recuperando la parte pubblica della chiave di crittografia principale e le richieste di decrittografia vengono inviate al piano di controllo.
- Chiave di crittografia dei dati crittografati: ogni file nella zona di crittografia viene crittografato con una chiave DEK (Data Encryption Key) generata per il file. La chiave DEK, una volta creata, viene salvata in modo permanente con i dati. Per rendere persistente la chiave DEK, viene prima crittografata dalla chiave della zona di crittografia e quindi salvata in modo permanente con i dati. La chiave DEK viene generata in modo casuale per ogni file e la complessità della chiave DEK simmetrica è uguale a quella della chiave EZ.
L'immagine seguente illustra come i file sono protetti dalla chiave DEK e la chiave DEK è protetta dalla chiave EZ securelakekey.
Chiavi di SQL Server
La chiave di crittografia principale gestita dal sistema e le chiavi EZ di HDFS vengono archiviate all'interno del controldb, che sarà denominato controldb-<#>, ad esempio controldb-0. Per altre informazioni, vedere Risorse distribuite in un cluster Big Data.
I database SQL Server vengono crittografati da una chiave simmetrica, nota anche come chiave di crittografia del database (DEK). La chiave DEK viene salvata in modo permanente con il database in un formato crittografato. La protezione DEK può essere un certificato o una chiave asimmetrica. Per modificare la protezione DEK, usare l'istruzione ALTER DATABASE ENCRYPTION KEY. La chiave asimmetrica in SQL Server include metadati che contengono un collegamento URL alla chiave all'interno del piano di controllo. Di conseguenza, tutte le operazioni di crittografia e decrittografia della chiave DEK (Database Encryption Key) vengono eseguite all'interno del controller. SQL Server archivia la chiave pubblica, ma solo per identificare la chiave asimmetrica e non per la crittografia.
Chiave di crittografia principale dei cluster Big Data di SQL Server
Nel piano di controllo dei cluster Big Data di SQL Server, per proteggere le chiavi della zona di crittografia e per effettuare il provisioning delle chiavi asimmetriche in SQL Server, esiste il concetto di chiave di crittografia principale. Esistono due chiavi di crittografia principali, una per SQL Server e una per HDFS. Grazie a questo concetto, il piano di controllo dei cluster Big Data di SQL Server può consentire anche alla chiave di crittografia principale di risiedere all'esterno del cluster. Le proprietà della chiave di crittografia principale sono:
- Le chiavi di crittografia principali sono chiavi RSA asimmetriche.
- Viene creata una chiave di crittografia principale per l'istanza master di SQL Server e un'altra per HDFS.
- La chiave pubblica corrispondente alla chiave di crittografia principale viene sempre archiviata nel database del controller o controldb. La chiave privata viene archiviata nel database controller per la chiave di crittografia principale gestita dal sistema. Per le chiavi di crittografia da un modulo di sicurezza hardware o da qualsiasi altro provider esterno, le chiavi private non vengono archiviate all'interno del database del controller (a meno che l'applicazione per le chiavi esterne non contenga la chiave privata). Tuttavia, la chiave privata non è necessaria all'interno del controldb e i cluster Big Data di SQL Server non richiederanno il materiale della chiave privata.
- Le operazioni di crittografia che usano la chiave pubblica della chiave di crittografia principale possono essere eseguite all'interno del controller stesso oppure il controller può distribuire la chiave pubblica a Hadoop KMS in modo che Hadoop KMS possa eseguire la crittografia in locale. Le operazioni di decrittografia devono essere gestite dal provider di chiavi esterno, ad esempio il modulo di protezione hardware. Questa progettazione consente di mantenere la parte sensibile della chiave asimmetrica all'esterno del cluster e nella protezione del cliente. In questo modo, la radice di crittografia per decrittografare tutti i dati non è mai disponibile nell'ecosistema di cluster Big Data di SQL Server per le chiavi configurate dal cliente.
Protezione dell'archiviazione di chiavi diverse
Le chiavi DEK per i file HDFS e per SQL Server vengono archiviate insieme ai dati che proteggono. Le chiavi DEK vengono protette rispettivamente dalla chiave EZ di HDFS o dalla chiave asimmetrica in SQL Server.
Le chiavi asimmetriche in SQL Server contengono metadati che includono l'URL della chiave nel piano di controllo. SQL Server archivia solo la chiave pubblica della chiave asimmetrica, per la correlazione con la chiave nel piano di controllo.
L'archiviazione delle chiavi in controldb è protetta dalla chiave di crittografia della colonna in controldb. Controldb archivia informazioni sensibili sul cluster e tutte le informazioni sensibili sono protette mediante una chiave di crittografia di colonna di SQL Server in controldb, che è ulteriormente protetta da una password archiviata nei segreti Kubernetes. Per altre informazioni, vedere l'argomento relativo ai segreti nella documentazione di Kubernetes.
La protezione è riepilogata nei diagrammi seguenti. Prima di tutto, la protezione dell'archiviazione delle chiavi EZ di HDFS:
Protezione dell'archiviazione della chiave di crittografia principale:
Rotazione delle chiavi
Chiavi delle zone di crittografia HDFS
Quando il cluster Big Data di SQL Server viene distribuito con Active Directory, in HDFS viene effettuato il provisioning di una zona di crittografia predefinita denominata securelake, protetta da securelakekey. Negli esempi si useranno i valori predefiniti, ma è possibile effettuare il provisioning di nuove zone e chiavi mediante azdata. La chiave securelakekey è protetta da una chiave di crittografia principale per HDFS, archiviata nel piano di controllo. A partire da SQL 2019 CU9, è possibile usare azdata per ruotare le chiavi EZ per HDFS. La rotazione delle chiavi EZ causa la generazione di un nuovo materiale della chiave, con lo stesso nome di "securelakekey", ma con una nuova versione della chiave che punta al materiale della chiave. Per tutte le nuove operazioni di crittografia in HDFS, ad esempio scritture di file, la zona di crittografia usa sempre l'ultima versione della chiave ad essa associata. Per i file in una zona di crittografia protetta da una versione precedente delle chiavi, è possibile usare il comando azdata bdc hdfs encryption-zone reencrypt in modo che tutti i file possano essere protetti dalla versione più recente della chiave EZ.
Si prenda ad esempio un file denominato file2 situato in /securelake. Di seguito è illustrata la catena di protezione.
Per ruotare la chiave securelakekey a una nuova versione, è possibile usare azdata bdc hdfs key roll -n securelakekey. Con la rotazione non vengono crittografate nuovamente le chiavi DEK che proteggono il file. La rotazione della chiave Hadoop determina la generazione di un nuovo materiale della chiave e la protezione mediante la versione più recente della chiave principale. Il diagramma seguente mostra lo stato del sistema dopo la rotazione di securelakekey.
Per assicurarsi che i file nelle zone di crittografia siano protetti dalla securelakekey ruotata, usare azdata bdc hdfs encryption-zone -a start -p /securelake.
Il diagramma seguente illustra lo stato del sistema dopo la ripetizione della crittografia della zona di crittografia.
SQL Server
La chiave che protegge il database SQL è la chiave DEK, che può essere rigenerata. Il processo di rigenerazione causerebbe la ripetizione della crittografia dell'intero database.
Rotazione della chiave di crittografia principale
Nota
Prima di SQL Server 2019 CU10 non era possibile ruotare la chiave di crittografia principale. A partire da SQL Server 2019 CU10, è necessario esporre il comando azdata per consentire la rotazione della chiave di crittografia principale.
La chiave di crittografia principale è una chiave RSA a 2048 bit. La rotazione della chiave di crittografia principale esegue una delle operazioni seguenti a seconda dell'origine della chiave:
- Crea una nuova chiave nel caso in cui sia stata richiesta la rotazione della chiave principale a una chiave gestita dal sistema. Una chiave gestita dal sistema è una chiave asimmetrica, generata e archiviata all'interno del controller.
- Crea un riferimento a una chiave fornita esternamente, in cui la chiave privata di quella asimmetrica verrà gestita dall'applicazione del cliente. L'applicazione del cliente non ha la chiave privata, ma deve sapere come recuperarla in base alla configurazione dell'applicazione fornita.
La rotazione della chiave principale non crittografa nuovamente nulla. È quindi necessario ruotare le chiavi di SQL Server e HDFS:
- Dopo la rotazione della chiave principale, la protezione della chiave DEK del database SQL Server dovrà essere ruotata alla nuova versione della chiave principale creata.
- Concetti simili si applicano ad HDFS. Quando la chiave HDFS viene ruotata, il nuovo materiale viene crittografato dall'ultima versione della chiave principale. Le versioni precedenti delle chiavi EZ rimarranno invariate. Dopo la rotazione della chiave EZ di HDFS, è necessario ripetere la crittografia delle zone di crittografia associate alla chiave EZ, in modo che vengano crittografate nuovamente dalla versione più recente della chiave EZ.
Rotazione della chiave principale per HDFS
I diagrammi seguenti illustrano il processo di rotazione della chiave di crittografia principale per HDFS. Prima di tutto, lo stato iniziale di HDFS:
La chiave di crittografia principale verrà ruotata usando azdata bdc kms set –key-provider SystemManaged. Si noti che il comando causa la rotazione della chiave di crittografia principale sia per SQL che per HDFS, anche se sono chiavi diverse all'interno del piano di controllo. Dopo aver usato il comando azdata bdc kms:
Per usare la nuova versione della chiave di crittografia principale di HDFS, è possibile usare il comando azdata bdc hdfs key roll, che porterà il sistema nello stato seguente. Dopo la rotazione di securelakekey:
Con la rotazione di securelakekey viene creata una nuova versione di securelakekey, protetta dalla chiave di crittografia principale. Per assicurarsi che i file in securelake siano crittografati da securelakekey@2, è necessario crittografare nuovamente la zona di crittografia securelake. Dopo la ripetizione della crittografia della zona di crittografia:
Rotazione chiave principale per SQL Server
La chiave di crittografia principale di SQL Server è installata nel database master dell'istanza master di SQL Server.
I diagrammi seguenti illustrano il processo di rotazione della chiave di crittografia principale per SQL Server.
In una nuova installazione dei cluster Big Data di SQL Server non viene effettuato il provisioning di una chiave asimmetrica in SQL Server. Nello stato iniziale di SQL Server i database possono essere crittografati usando i certificati, ma questo aspetto è controllato dall'amministratore dell'istanza master di SQL Server.
La chiave di crittografia principale verrà ruotata usando azdata bdc kms set –key-provider SystemManaged. Si noti che il comando causa la rotazione della chiave di crittografia principale (o la crea, se non esiste) sia per SQL che per HDFS, anche se sono chiavi diverse all'interno del piano di controllo.
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 verrà visualizzata con la convenzione di denominazione "tde_asymmetric_key_<versione>". 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;
A questo punto, la protezione della chiave DEK viene modificata per usare la chiave asimmetrica:
Se il comando azdata bdc kms set viene eseguito nuovamente, le chiavi asimmetriche in SQL Server mostrano un'altra voce in sys.asymmetric_keys nel formato "tde_asymmetric_key_<versione>". Questo comando azdata può essere usato per modificare di nuovo la protezione della chiave DEK di un database SQL Server.
Chiave fornita dal cliente
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. Le richieste di decrittografare la chiave DEK da SQL vengono inviate anche al piano di controllo e quindi reindirizzate all'applicazione del Servizio di gestione delle chiavi.
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 o a un altro prodotto.