Always Encrypted con enclave sicuri

Si applica a: sìSQL Server 2019 (15.x) - Solo Windows Sìdatabase SQL di Azure

Always Encrypted con enclave sicuri amplia le funzionalità di confidential computing Always Encrypted abilitando la crittografia sul posto e query riservate più avanzate. Always Encrypted con enclave sicuri è disponibile in SQL Server 2019 (15.x) e in database SQL di Azure.

Introdotto 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 ,amministratori di computer, amministratori del cloud o chiunque abbia accesso legittimo a istanze del server, hardware e così via, ma non deve 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 visualizzate 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 Motore di database può eseguire sui dati crittografati sono i confronti di uguaglianza (disponibili solo con la crittografia deterministica). Tutte le altre operazioni, incluse le operazioni di crittografia (crittografia iniziale dei dati o rotazione delle chiavi) e query più complesse (ad esempio, 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 di Motore di database e altri processi nel computer host. Non è possibile 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:

flusso di dati

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 esposti in testo non crittografato Motore di database all'esterno dell'enclave sicuro.

Tecnologie di enclave supportate

In SQL Server 2019 (15.x) Always Encrypted con enclave sicuri usa gli enclave di memoria sicuri di tipo sicurezza basata su virtualizzazione in Windows, noti anche come enclave in modalità protetta virtuale o VSM.

In database SQL di Azure, Always Encrypted con enclave sicure usa le enclave Intel Software Guard Extensions (Intel SGX). Intel SGX è una tecnologia ambientale di esecuzione attendibile basata su hardware supportata nei database che usano la configurazione hardware della serie DC.

Attestazione delle enclave sicure

L'enclave sicura all'interno del Motore di database può accedere ai dati sensibili e alle chiavi di crittografia della colonna in testo non crittografato. Pertanto, prima di inviare al Motore di database un'istruzione che comporta calcoli dell'enclave, il driver client all'interno dell'applicazione deve verificare che l'enclave sicura sia una vera enclave con sicurezza basata su virtualizzazione o SGX e che il codice in esecuzione nell'enclave sicura sia la libreria di Always Encrypted originale che implementa algoritmi di crittografia di Always Encrypted per la crittografia sul posto e le operazioni supportate nelle query riservate.

Il processo di verifica dell'enclave è chiamato attestazione dell'enclave e implica che un driver client all'interno dell'applicazione e Motore di database contattino un servizio di attestazione esterno. I dettagli specifici del processo di attestazione variano a seconda del tipo dell'enclave (sicurezza basata su virtualizzazione o SGX) e del servizio di attestazione.

Il processo di attestazione per le enclave sicure con sicurezza basata su virtualizzazione in SQL Server 2019 (15.x) è l'attestazione di runtime di System Guard di Windows Defender, che richiede il servizio Sorveglianza host come servizio di attestazione.

L'attestazione delle enclave di Intel SGX nel database SQL di Azure richiede l'attestazione di Microsoft Azure.

Nota

SQL Server 2019 (15.x) non supporta l'attestazione di Microsoft Azure. Il servizio Sorveglianza host è l'unica soluzione di attestazione supportata per le enclave con sicurezza basata su virtualizzazione in SQL Server 2019 (15.x).

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. Per informazioni dettagliate, incluso l'elenco dei driver client supportati, vedere Sviluppare applicazioni con Always Encrypted.

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 con la proprietà ENCLAVE_COMPUTATIONS specificata nell'oggetto metadati chiave master della colonna all'interno del database. L'oggetto metadati chiave master della 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. 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à della 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:

Operazione SQL Server 2019 (15.x) database SQL di Azure
Operatori di confronto Supportato Supportato
BETWEEN (Transact-SQL) Supportato Supportato
IN (Transact-SQL) Supportato Supportato
LIKE (Transact-SQL) Supportato Supportato
DISTINCT Supportato Supportato
Join Sono supportati solo i join annidati di cicli Supportato
Clausola SELECT - ORDER BY (Transact-SQL) Non supportato Supportato
SELECT - GROUP BY- Transact-SQL Non supportato Supportato

Nota

Le operazioni precedenti sono supportate nelle enclave sicure solo sulle colonne abilitate per le enclave che usano la crittografia casuale e non la crittografia deterministica. L'operatore per il confronto di uguaglianza rimane l'unico operatore di calcolo supportato sulle colonne che usano la crittografia deterministica e viene eseguito tramite il confronto del testo crittografato al di fuori dell'enclave, indipendentemente dal fatto che la colonna sia abilitata o meno per l'enclave. La crittografia deterministica supporta le operazioni seguenti che usano gli operatori per il confronto di uguaglianza:

In SQL Server 2019 (15.x), le query riservate che usano le enclave su una colonna di stringhe di caratteri (char, nchar) richiedono che la colonna usi regole di confronto binary2 (BIN2) per l'ordinamento. In database SQL di Azure, le query riservate sulle stringhe di caratteri richiedono regole di confronto BIN2 o UTF-8.

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'utilità di esecuzione 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 in colonne che usano la crittografia casuale e non abilitati 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.

Importante

Microsoft consiglia di abilitare il ripristino accelerato del database nel database prima di creare il primo indice su una colonna abilitata per l'enclave crittografata con la crittografia casuale. Il ripristino accelerato del database è abilitato per impostazione predefinita nel database SQL di Azure, ma non in SQL Server 2019 (15.x).

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 di annullamento che devono essere posticipate 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 ADR abilitato, SQL Server potrebbe comunque essere necessaria una chiave di crittografia della colonna per completare la pulizia delle versioni precedenti dei dati, ma ciò viene eseguito come attività in background che non influisce sulla disponibilità del database o delle transazioni utente. È possibile che nel log degli errori venga visualizzato un messaggio di errore che indica che le operazioni di pulizia non sono riuscite a causa di una chiave di crittografia della colonna mancante.

Considerazioni relative alla sicurezza

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

  • La sicurezza dei dati all'interno dell'enclave dipende da un protocollo di attestazione e un servizio di attestazione. È pertanto necessario assicurarsi che il servizio di attestazione e i criteri di attestazione applicati da tale servizio vengano gestiti da un amministratore attendibile. Inoltre, i servizi di attestazione in genere supportano diversi criteri e protocolli 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 per 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, contenente le retribuzioni dei dipendenti, ha un indice, un amministratore di database malintenzionato potrebbe analizzare l'indice per trovare il valore massimo dello stipendio crittografato e identificare una persona con lo stipendio massimo (presupponendo che il nome della persona non sia crittografato).
  • Se si usa Always Encrypted per proteggere i dati sensibili da accessi non autorizzati 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 usando 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 enclave non funzioneranno nella copia o nel database migrato.

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 Informazioni sulle funzionalità 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 chiave primaria e non è possibile farvi riferimento da vincoli di chiave esterna o vincoli di chiave univoca.
  • In SQL Server 2019 (15.x) (questa limitazione non si applica a ) solo i join a cicli annidati (che usano indici, se disponibili) sono supportati nelle colonne abilitate per l'enclave database SQL di Azureche usano la crittografia casuale. 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, crittografare nuovamente o decrittografare una colonna E modificare un tipo di dati della colonna in ALTER TABLE/ALTER COLUMN una singola istruzione Transact-SQL. 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 calcoli sulle colonne abilitate per l'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.
    • L'importazione/esportazione di database contenenti chiavi abilitate per l'enclave non è supportata.
    • Per attivare un'operazione di crittografia sul posto tramite ALTER TABLE/ALTER COLUMN, è necessario eseguire l'istruzione in una finestra di query in SSMS oppure è possibile scrivere un programma personalizzato che esegue l'istruzione. Attualmente, il cmdlet Set-SqlColumnEncryption nel modulo PowerShell SqlServer e la procedura guidata Always Encrypted in SQL Server Management Studio non supportano la crittografia sul posto, ma spostano i dati fuori dal database per le operazioni di crittografia, anche se le chiavi di crittografia di colonna usate per le operazioni sono abilitate per l'enclave.

Passaggi successivi

Vedi anche