Always Encrypted con enclave sicuri

Si applica a: SQL Server 2019 (15.x) e versioni successive - Database SQL di Azure solo Windows

Always Encrypted con enclave sicure espande le funzionalità di confidential computing di Always Encrypted abilitando la crittografia sul posto e query riservate più avanzate. Always Encrypted con enclave sicure è disponibile in SQL Server 2019 (15.x) e versioni successive, nonché in database SQL di Azure.

Introdotta in database SQL di Azure nel 2015 e in SQL Server 2016 (13.x), Always Encrypted protegge la riservatezza dei dati sensibili da malware e utenti non autorizzati con privilegi elevati: Amministratori di database (DBA), amministratori di computer, amministratori cloud o chiunque altro abbia accesso legittimo a istanze del server, hardware e così via, ma non dovrebbe avere accesso ad alcuni o a tutti i dati effettivi.

Senza i miglioramenti illustrati in questo articolo, Always Encrypted protegge i dati crittografandoli sul lato client e non consentendo mai ai dati o alle chiavi di crittografia corrispondenti di essere visualizzati come testo non crittografato all'interno del motore di database. Di conseguenza, le funzionalità per le colonne crittografate all'interno del database sono soggette a notevoli restrizioni. Le uniche operazioni che il motore di database può eseguire sui dati crittografati sono i confronti di uguaglianza (disponibili solo con la crittografia deterministica). Tutte le altre operazioni, tra cui le operazioni di crittografia (crittografia dei dati iniziale o rotazione delle chiavi) e le query più avanzate (ad esempio, i criteri di ricerca), non sono supportate all'interno del database. Gli utenti devono spostare i dati all'esterno del database per eseguire queste operazioni sul lato client.

Always Encrypted con enclave sicure supera queste limitazioni, consentendo l'esecuzione di alcuni calcoli su dati di testo non crittografato all'interno di un'enclave sicura sul lato server. Un'enclave sicura è un'area protetta della memoria all'interno del processo del motore di database. L'enclave sicura viene visualizzata come black box per il resto del motore di database e altri processi nel computer host. Non vi è alcun modo per visualizzare dati o codice all'interno dell'enclave dall'esterno, anche con un debugger. Queste proprietà rendono l'enclave sicura un ambiente di esecuzione attendibile che può accedere in modo sicuro alle chiavi crittografiche e ai dati sensibili in testo non crittografato, senza compromettere la riservatezza dei dati.

Always Encrypted usa gli enclave sicuri come illustrato nel diagramma seguente:

Durante l'analisi di un'istruzione Transact-SQL inviata da un'applicazione, il motore di database determina se l'istruzione contiene operazioni su dati crittografati che richiedono l'uso dell'enclave sicura. Per tali istruzioni:

• Il driver client invia le chiavi di crittografia della colonna necessarie per le operazioni all'enclave sicura (tramite un canale sicuro) e invia l'istruzione per l'esecuzione.

• Durante l'elaborazione dell'istruzione, il motore di database delega le operazioni di crittografia o i calcoli sulle colonne crittografate all'enclave sicura. Se necessario, l'enclave decrittografa i dati ed esegue i calcoli in testo non crittografato.

Durante l'elaborazione dell'istruzione, sia i dati che le chiavi di crittografia della colonna non vengono esposte come testo non crittografato nel motore di database al di fuori dell'enclave sicura.

Driver client supportati

Per usare Always Encrypted con enclave sicuri, un'applicazione deve usare un driver client che supporta la funzionalità. Configurare l'applicazione e il driver client per abilitare i calcoli dell'enclave e l'attestazione dell'enclave (vedere la sezione Attestazione delle enclave sicure di seguito). Per informazioni dettagliate, incluso l'elenco dei driver client supportati, vedere Sviluppare applicazioni con Always Encrypted.

Tecnologie di enclave supportate

Always Encrypted supporta le seguenti tecnologie delle enclave (o tipi di enclave):

• Le enclave di sicurezza basata su virtualizzazione (VBS), note anche come modalità protetta virtuale o enclave VSM, sono una tecnologia basata su software che si basa sull'hypervisor Windows e non richiede hardware speciale.
• Le enclave Intel Software Guard Extensions (Intel SGX) sono una tecnologia di ambiente di esecuzione attendibile basata su hardware.

Il tipo di enclave disponibile per il database dipende dal prodotto SQL che lo ospita (database SQL di Azure vs. SQL Server) e, nel caso di database SQL di Azure, dalla configurazione del database.

• In SQL Server 2019 (15.x) e versioni successive, Always Encrypted supporta le enclave VBS. Le enclave Intel SGX non sono supportate.

• In database SQL di Azure, un database può usare un'enclave Intel SGX o un'enclave VBS a seconda dell'hardware in cui il database è configurato per l'esecuzione:

  • I database che usano la configurazione hardware della serie DC (disponibile con il modello di acquisto vCore) usano enclave Intel SGX.
  • I database che usano una configurazione diversa dalla serie DC con il modello di acquisto vCore e i database che usano il modello di acquisto DTU possono essere configurati per l'uso di enclave VBS.

  Nota

  Le enclave VBS sono attualmente disponibili in tutte le aree del database SQL di Azure tranne Jio India centrale.

Per informazioni importanti sulla protezione del livello fornita da ogni tipo di enclave, vedere la sezione Considerazioni sulla sicurezza.

Attestazione delle enclave sicure

L'attestazione dell'enclave è un meccanismo di difesa avanzata che consente di rilevare gli attacchi che comportano manomissioni con il codice dell'enclave o il relativo ambiente da parte di amministratori malintenzionati.

L'attestazione dell'enclave consente a un'applicazione client di stabilire una certa fiducia nell'enclave sicura per il database a cui l'applicazione è connessa prima che l'app usi l'enclave per l'elaborazione di dati sensibili. Il flusso di lavoro di attestazione verifica che l'enclave sia un'enclave VBS o Intel SGX originale e che il codice in esecuzione all'interno sia il catalogo originale dell'enclave firmato da Microsoft per Always Encrypted. Durante l'attestazione, sia il driver client all'interno dell'applicazione che il motore di database comunicano con un servizio di attestazione esterno usando un endpoint specificato dal client.

Always Encrypted può usare uno dei due servizi di attestazione:

• Attestazione di Azure di Microsoft: una soluzione di attestazione basata sul cloud.
• Servizio Sorveglianza host (HGS) che implementa l'attestazione di runtime di Protezione del sistema di Windows Defender.

Per abilitare Always Encrypted con enclave sicure per l'applicazione, è necessario impostare un protocollo di attestazione nella configurazione del driver client nell'applicazione. Un valore del protocollo di attestazione determina se 1) l'app client userà l'attestazione e, in tal caso, 2) specifica il tipo del servizio di attestazione da usare. La tabella seguente acquisisce i protocolli di attestazione supportati per le combinazioni valide di prodotti e tipi di enclave SQL:

Alcuni punti importanti da chiarire:

• L'attestazione di enclave VBS in SQL Server 2019 (15.x) e versioni successive richiede HGS. È anche possibile usare enclave VBS senza attestazione (sono necessari i driver client più recenti).
• Con le enclave di Intel SGX (in database della serie DC) nel database SQL di Azure, l'attestazione è obbligatoria e richiede l'attestazione di Azure di Microsoft.
• Le enclave VBS nel database SQL di Azure non supportano l'attestazione.

Per altre informazioni, vedi:

• Pianificare l'attestazione del servizio Sorveglianza host.
• Pianificare le enclave e l'attestazione di Intel SGX nel database SQL di Azure.

Terminologia

Chiavi abilitate per l'enclave

Always Encrypted con enclave sicuri introduce il concetto di chiavi abilitate per l'enclave:

• Chiave master di colonna abilitata per l'enclave - Chiave master della colonna ENCLAVE_COMPUTATIONS con la proprietà master specificata nell'oggetto metadati chiave master della colonna all'interno del database. L'oggetto metadati chiave master della master colonna deve anche contenere una firma valida delle proprietà dei metadati. Per altre informazioni, vedere CREATE COLUMN MASTER KEY (Transact-SQL).
• Chiave di crittografia di colonna abilitata per l'enclave - Chiave di crittografia di colonna crittografata con una chiave master della colonna abilitata per l'enclave master. Solo le chiavi di crittografia di colonna abilitata per l'enclave possono essere usate per i calcoli all'interno dell'enclave sicura.

Per altre informazioni, vedere Gestire le chiavi per Always Encrypted con enclave sicuri.

Colonne abilitate per l'enclave

Una colonna abilitata per l'enclave è una colonna del database crittografata con una chiave di crittografia di colonna abilitata per l'enclave.

Funzionalità di confidential computing per le colonne abilitate per l'enclave

I due principali vantaggi di Always Encrypted con le enclave sicure sono la crittografia sul posto e le query riservate avanzate.

Crittografia sul posto

La crittografia sul posto consente di eseguire operazioni crittografiche sulle colonne del database all'interno dell'enclave sicura, senza spostare i dati all'esterno del database. La crittografia sul posto migliora le prestazioni e l'affidabilità delle operazioni di crittografia. È possibile eseguire la crittografia sul posto usando l'istruzione ALTER TABLE (Transact-SQL).

Le operazioni crittografiche supportate sul posto sono:

• Crittografia di una colonna di testo non crittografato con una chiave di crittografia della colonna abilitata per l'enclave.
• Riapplicazione della crittografia a una colonna crittografata abilitata per l'enclave per:
  • Ruotare una chiave di crittografia della colonna: crittografare nuovamente la colonna con una nuova chiave di crittografia della colonna abilitata per l'enclave.
  • Cambiare il tipo di crittografia di una colonna abilitata per l'enclave, ad esempio da deterministica a casuale.
• Decrittografia dei dati archiviati in una colonna abilitata per l'enclave (conversione della colonna in colonna di testo non crittografato).

La crittografia sul posto è consentita sia con la crittografia deterministica che con quella casuale, purché le chiavi di crittografia della colonna usate in un'operazione di crittografia siano abilitate per l'enclave.

Query riservate

Le query riservate sono query DML che comportano operazioni sulle colonne abilitate per l'enclave, eseguite all'interno dell'enclave sicura.

Le operazioni supportate all'interno delle enclave sicure sono:

Per ulteriori informazioni, vedere Eseguire istruzioni Transact-SQL con enclave sicure.

Indici sulle colonne abilitate per l'enclave

È possibile creare indici non cluster sulle colonne abilitate per l'enclave tramite la crittografia casuale per velocizzare l'esecuzione delle query DML riservate che usano l'enclave sicura.

Per garantire che un indice su una colonna crittografata tramite la crittografia casuale non determini una perdita di dati sensibili, i valori di chiave nella struttura dei dati di indice (albero B) sono crittografati e ordinati in base ai relativi valori di testo non crittografato. L'ordinamento in base al valore di testo non crittografato è utile anche per l'elaborazione di query all'interno dell'enclave. Quando l'executor delle query nel motore di database usa un indice su una colonna crittografata per i calcoli all'interno dell'enclave, esegue una ricerca nell'indice dei valori specifici archiviati nella colonna. Ogni ricerca può implicare più confronti. L'utilità di esecuzione query delega ogni confronto all'enclave, che decrittografa un valore archiviato nella colonna e il valore della chiave di indice crittografata da confrontare, esegue il confronto in testo non crittografato e restituisce il risultato del confronto all'utilità di esecuzione.

La creazione di indici su colonne che usano la crittografia casuale e non sono abilitate per l'enclave non è supportata.

Un indice su una colonna con crittografia deterministica è ordinato in base al testo crittografato (non al testo non crittografato), indipendentemente dal fatto che la colonna sia abilitata per l'enclave o meno.

Per altre informazioni, vedere Creare e usare indici in colonne usando Always Encrypted con enclave sicuri. Per informazioni generali sul funzionamento dell'indicizzazione nel motore di database, vedere l'articolo Descrizione di indici cluster e non cluster.

Ripristino del database

Se si verifica un errore in un'istanza di SQL Server, i relativi database possono rimanere in uno stato in cui i file di dati possono contenere alcune modifiche da transazioni incomplete. Quando l'istanza viene avviata, viene eseguito un processo denominato ripristino del database, che implica il rollback di tutte le transazioni incomplete rilevate nel log delle transazioni per salvaguardare l'integrità del database. Se una transazione incompleta ha apportato modifiche a un indice, anche tali modifiche devono essere annullate. Ad esempio, potrebbe essere necessario rimuovere o reinserire alcuni valori di chiave nell'indice.

Con il tradizionale processo di ripristino del database (che segue il modello di ripristino ARIES), per annullare una modifica a un indice, SQL Server deve attendere che un'applicazione fornisca all'enclave la chiave di crittografia della colonna, operazione che può richiedere molto tempo. Il ripristino accelerato del database riduce notevolmente il numero di operazioni della fase di rollback che devono essere rinviate perché una chiave di crittografia della colonna non è disponibile nella cache all'interno dell'enclave. Di conseguenza, incrementa notevolmente la disponibilità del database, riducendo al minimo la possibilità che una nuova transazione resti bloccata. Con il ripristino accelerato del database abilitato, SQL Server potrebbe comunque richiedere una chiave di crittografia della colonna per completare la pulizia delle versioni precedenti dei dati, ma esegue tale operazione come un'attività in background che non influisce sulla disponibilità delle transazioni del database o degli utenti. Potrebbero essere visualizzati messaggi di errore nel log degli errori, che indicano operazioni di pulizia non riuscite a causa di una chiave di crittografia della colonna mancante.

Considerazioni sulla sicurezza

Le considerazioni sulla sicurezza seguenti si applicano ad Always Encrypted con enclave sicuri.

• Le enclave VBS consentono di proteggere i dati dagli attacchi all'interno della VM. Tuttavia, non forniscono nessuna protezione dagli attacchi che usano account di sistema con privilegi provenienti dall'host. Le enclave Intel SGX proteggono i dati dagli attacchi provenienti sia dal sistema operativo guest che dal sistema operativo host.
• L'uso dell'attestazione dell'enclave è consigliato se è disponibile per l'ambiente e se si ha l'obiettivo di proteggere i dati dagli attacchi da parte degli utenti con accesso amministratore a livello di sistema operativo al computer che ospita il database. Se si usa l'attestazione, è necessario assicurarsi che il servizio di attestazione e la relativa configurazione siano gestiti da un amministratore attendibile. Inoltre, entrambi i servizi di attestazione supportati offrono diversi criteri e modalità di attestazione, alcuni dei quali eseguono una verifica minima dell'enclave e del relativo ambiente e sono progettati per il test e lo sviluppo. Seguire attentamente le linee guida specifiche per il servizio di attestazione in uso, in modo da assicurarsi di usare le configurazioni e i criteri consigliati per le distribuzioni di produzione.
• La crittografia di una colonna tramite la crittografia casuale con una chiave di crittografia della colonna abilitata per l'enclave può comportare la divulgazione dell'ordine dei dati archiviati nella colonna, in quanto tali colonne supportano i confronti degli intervalli. Ad esempio, se una colonna crittografata che contiene gli stipendi dei dipendenti dispone di un indice, un amministratore di database malintenzionato potrebbe analizzare l'indice per trovare il valore crittografato dello stipendio massimo e identificare la persona con lo stipendio massimo (presupponendo che il nome della persona non sia crittografato).
• Se si usa Always Encrypted per proteggere i dati sensibili dall'accesso non autorizzato da parte degli amministratori di database, non condividere le chiavi master della colonna o le chiavi di crittografia della colonna con gli amministratori di database. Un amministratore di database può gestire gli indici nelle colonne crittografate senza avere accesso diretto alle chiavi, sfruttando la cache delle chiavi di crittografia della colonna all'interno dell'enclave.

Considerazioni su continuità aziendale, ripristino di emergenza e migrazione dei dati

Quando si configura una soluzione di disponibilità elevata o di ripristino di emergenza per un database che usa Always Encrypted con enclave sicure, verificare che tutte le repliche del database possano usare un'enclave sicura. Se è disponibile un'enclave per la replica primaria, ma non per la replica secondaria, eventuali istruzioni che provano a usare la funzionalità di Always Encrypted con enclave sicure avranno esito negativo dopo il failover.

Quando si esegue la copia o la migrazione di un database che usa Always Encrypted con enclave sicure, verificare che l'ambiente di destinazione supporti sempre le enclave. In caso contrario, le istruzioni che usano le enclave non funzioneranno sulla copia o sul database di cui è stata eseguita la migrazione.

Occorre tenere presenti queste considerazioni specifiche:

• SQL Server

  • Quando si configura un gruppo di disponibilità Always On, assicurarsi che ogni istanza di SQL Server che ospita un database nel gruppo di disponibilità supporti Always Encrypted con enclave sicure e che siano state configurate un'enclave e un'attestazione.
  • Quando si ripristina un file di backup di un database che usa la funzionalità Always Encrypted con enclave sicure in un'istanza di SQL Server in cui non è configurata l'enclave, l'operazione di ripristino avrà esito positivo e tutte le funzionalità che non usano l'enclave saranno disponibili. Tuttavia, tutte le istruzioni successive che usano la funzionalità dell'enclave avranno esito negativo e gli indici sulle colonne abilitate per l'enclave che usano la crittografia casuale non saranno più validi. Lo stesso vale quando si collega un database con Always Encrypted con enclave sicure nell'istanza in cui non è configurata l'enclave.
  • Se il database include indici sulle colonne abilitate per l'enclave con crittografia casuale, assicurarsi di abilitare il ripristino accelerato del database nel database prima di creare un backup del database. Il ripristino accelerato del database garantirà che il database, inclusi gli indici, sarà immediatamente disponibile dopo il ripristino del database. Per altre informazioni, vedere Ripristino del database.

• Database SQL di Azure

  • Quando si configura la replica geografica attiva, verificare che un database secondario supporti le enclave sicure, se il database primario le supporta.

Sia in SQL Server che nel database SQL di Azure, quando si esegue la migrazione del database tramite un file con estensione bacpac, è necessario accertarsi di eliminare tutti gli indici per le colonne abilitate per l'enclave con crittografia casuale prima di creare il file con estensione bacpac.

Limitazioni note

Always Encrypted con enclave sicure risolve alcune limitazioni di Always Encrypted supportando la crittografia sul posto e query riservate più avanzate con indici, come illustrato in Funzionalità di confidential computing per le colonne abilitate per l'enclave.

Tutte le altre limitazioni per Always Encrypted elencate in Limitazioni si applicano anche ad Always Encrypted con enclave sicure.

Le limitazioni seguenti sono specifiche per Always Encrypted con enclave sicuri:

• Non è possibile creare indici cluster sulle colonne abilitate per l'enclave che usano la crittografia casuale.
• Le colonne abilitate per l'enclave che usano la crittografia casuale non possono essere colonne della chiave primaria e non è possibile farvi riferimento da vincoli di chiave esterna o vincoli di chiave univoca.
• In SQL Server 2019 (15.x) solo i join a cicli annidati (usando indici, se disponibili) sono supportati nelle colonne abilitate per l'enclave usando la crittografia casuale. Questa limitazione non si applica a database SQL di Azure o SQL Server 2022 (16.x). Per informazioni su altre differenze tra i diversi prodotti, vedere Query riservate.
• Non è possibile combinare le operazioni di crittografia sul posto con qualsiasi altra modifica dei metadati di colonna, ad eccezione della modifica delle regole di confronto all'interno della stessa tabella codici e del supporto dei valori Null. Ad esempio, non è possibile crittografare, ricrittografare e decriptare una colonna E modificare un tipo di dati della colonna in un'unica istruzione Transact-SQL ALTER TABLE/ALTER COLUMN. Usare due istruzioni separate.
• L'uso di chiavi abilitate per l'enclave per le colonne in tabelle in memoria non è supportato.
• Le espressioni che definiscono le colonne calcolate non possono eseguire alcun calcolo sulle colonne abilitate per le enclave usando la crittografia casuale (anche se i calcoli sono tra le operazioni supportate elencate in Query riservate).
• I caratteri di escape non sono supportati nei parametri dell'operatore LIKE nelle colonne abilitate per l'enclave che usano la crittografia casuale.
• Le query con l'operatore LIKE o un operatore di confronto con un parametro di query che usa uno dei seguenti tipi di dati (che dopo la crittografia, diventano oggetti di grandi dimensioni) ignorano gli indici ed eseguono scansioni di tabella.
  • nchar[n] e nvarchar[n], se n è maggiore di 3967.
  • char[n], varchar[n], binary[n], varbinary[n], se n è maggiore di 7935.
• Limitazioni degli strumenti:
  • Gli unici archivi di chiavi supportati per l'archiviazione di chiavi master della colonna abilitate per l'enclave sono Archivio certificati Windows e Azure Key Vault.
  • Per attivare un'operazione di crittografia sul posto tramite ALTER TABLE/ALTER COLUMN, è necessario eseguire l'istruzione in un intervallo di query in SSMS o in Azure Data Studio, oppure è possibile scrivere un programma personalizzato che esegue l'istruzione. Attualmente, il cmdlet Set-SqlColumnEncryption nel modulo SqlServer di PowerShell e la procedura guidata di Always Encrypted in SQL Server Management Studio non supportano la crittografia sul posto. Spostare i dati dal database per le operazioni di crittografia, anche se le chiavi di crittografia della colonna usate per le operazioni sono abilitate per l'enclave.
• Quando si ripristina un database abilitato per l'enclave VBS, è essenziale riconfigurare nuovamente l'impostazione dell'enclave VBS.

Contenuto correlato

• Documentazione di Always Encrypted con enclave sicure
• Azure SQL Database Always Encrypted, SIGMOD '20: Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data
• Esercitazione: Introduzione ad Always Encrypted con enclave sicure
• Configurare e usare Always Encrypted con enclavi sicure
• Always Encrypted con enclave sicuri
• Esempi di SQL Server
• Azure confidential computing (Confidential computing di Azure)