Crittografia dei dati trasparente Azure SQL con chiave gestita dal cliente

Si applica a:Database SQL di AzureIstanza gestita di SQL di Azure Synapse Analytics (solo pool SQL dedicate)

Azure SQL Transparent Data Encryption (TDE) con chiave gestita dal cliente abilita lo scenario Bring Your Own Key (BYOK) per la protezione dei dati inattivi e consente alle organizzazioni di separare i compiti di gestione di chiavi e dati. Con la funzionalità TDE gestita dal cliente, il cliente ha il controllo completo ed è responsabile della gestione del ciclo di vita della chiave (creazione, caricamento, rotazione, eliminazione), delle autorizzazioni di utilizzo delle chiavi e del controllo delle operazioni sulle chiavi.

In questo scenario la chiave usata per la crittografia della chiave DEK (Database Encryption Key), chiamata protezione TDE, è una chiave asimmetrica gestita dal cliente archiviata in un Azure Key Vault (AKV) di proprietà del cliente e gestito dal cliente, un sistema di gestione delle chiavi esterno basato sul cloud. Il Key Vault è un'archiviazione sicura a disponibilità elevata e scalabile per le chiavi crittografiche RSA, supportata facoltativamente da moduli di protezione hardware (HSM) con convalida di tipo FIPS 140-2 Livello 2. Non consente l'accesso diretto a una chiave archiviata, ma offre servizi di crittografia/decrittografia che usano la chiave nelle entità autorizzate. La chiave può essere generata dall'insieme di credenziali delle chiavi, importata otrasferita all'insieme di credenziali delle chiavi da un dispositivo HSM locale.

Per il database SQL di Azure e Azure Synapse Analytics, la protezione TDE è impostata a livello di server logico e viene ereditata da tutti i database crittografati associati al server. Per l'Istanza gestita di SQL di Azure, la protezione TDE è impostata a livello di istanza e viene ereditata da tutti i database crittografati nell'istanza. In questo documento il termine server fa riferimento sia al server nel database SQL e Azure Synapse che all'istanza gestita di SQL, se non diversamente specificato.

La gestione della protezione TDE a livello di database in database SQL di Azure è disponibile. Per altre informazioni, vedere Transparent Data Encryption (TDE) con chiavi gestite dal cliente a livello di database.

Nota

• Questo articolo riguarda Database SQL di Azure, Istanza gestita di SQL di Azure e Azure Synapse Analytics (pool SQL dedicati (in precedenza SQL DW)). Per la documentazione su Transparent Data Encryption per pool SQL dedicati all'interno delle aree di lavoro di Synapse, vedere Crittografia di Azure Synapse Analytics.
• Per fornire ai clienti sql di Azure due livelli di crittografia dei dati inattivi, viene implementata la crittografia dell'infrastruttura (usando l'algoritmo di crittografia AES-256) con chiavi gestite dalla piattaforma. Ciò fornisce un ulteriore livello di crittografia dei dati inattivi insieme a TDE con chiavi gestite dal cliente, che è già disponibile. Per database SQL di Azure e Istanza gestita di SQL di Azure, tutti i database, inclusi il database master e altri database di sistema, verranno crittografati quando la crittografia dell'infrastruttura è attivata. A questo punto, i clienti devono richiedere l'accesso per usare questa funzionalità. Se si è interessati a questa funzionalità, contattare AzureSQLDoubleEncryptionAtRest@service.microsoft.com.

Nota

Microsoft Entra ID era precedentemente conosciuto come Azure Active Directory (Azure AD).

Vantaggi di Transparent Data Encryption gestita dal cliente

Transparent Data Encryption gestita dal cliente offre al cliente i vantaggi seguenti:

• Controllo completo e granulare sull'utilizzo e sulla gestione della protezione TDE;

• Trasparenza dell'utilizzo della protezione TDE;

• Possibilità di implementare la separazione dei compiti nella gestione delle chiavi e dei dati all'interno dell'organizzazione;

• L'amministratore del Key Vault può revocare le autorizzazioni di accesso alle chiavi per rendere inaccessibile il database crittografato;

• Gestione centralizzata delle chiavi in AKV;

• Maggiore attendibilità per i clienti finali poiché AKV è progettato in modo che Microsoft non possa visualizzare né estrarre le chiavi di crittografia;

Importante

Per gli utenti che usano Transparent Data Encryption gestita dal servizio e vogliono iniziare a usare Transparent Data Encryption gestita dal cliente, i dati rimangono crittografati durante il passaggio e non si verifica alcun tempo di inattività o riesecuzione della crittografia dei file di database. Il passaggio da una chiave gestita dal servizio a una chiave gestita dal cliente richiede la riesecuzione della crittografia della chiave DEK, che è un'operazione online rapida.

Funzionamento di Transparent Data Encryption gestita dal cliente

Per consentire al server logico in Azure di usare la protezione TDE archiviata in AKV per la crittografia della chiave DEK, l'amministratore del Key Vault deve concedere al server i seguenti diritti di accesso usando l'identità Microsoft Entra univoca:

• get: per recuperare la parte pubblica e le proprietà della chiave nel Key Vault

• wrapKey: per proteggere (crittografare) la chiave DEK

• unwrapKey: per rimuovere la protezione (decrittografare) la chiave DEK

L'amministratore del Key Vault può anche abilitare la registrazione degli eventi di controllo del Key Vault, in modo che possano essere controllati in un secondo momento.

Quando il server è configurato per l'utilizzo della protezione TDE da AKV, il server invia la chiave DEK di ogni database abilitato per TDE al Key Vault per la crittografia. Il Key Vault restituisce la chiave DEK crittografata che viene quindi archiviata nel database utente.

Quando necessario, il server invia la chiave DEK protetta al Key Vault per la decrittografia.

Se la registrazione è abilitata, i revisori possono usare Monitoraggio di Azure per esaminare i log AuditEvent del Key Vault.

Nota

Potrebbero essere necessari circa 10 minuti per rendere effettive le modifiche alle autorizzazioni per l'insieme di credenziali delle chiavi. Ciò include la revoca delle autorizzazioni di accesso alla protezione TDE in Azure Key Vault e gli utenti entro questo intervallo di tempo potrebbero comunque avere autorizzazioni di accesso.

Requisiti per la configurazione di Transparent Data Encryption gestita dal cliente

Requisiti per la configurazione di AKV

• Le funzionalità di eliminazione temporanea e protezione dalla rimozione devono essere abilitate nell'insieme di credenziali delle chiavi per proteggere dalla perdita di dati dovuta a un'eliminazione accidentale della chiave o dell'insieme di credenziali delle chiavi.

• Concedere accesso al server o all’istanza gestita al key vault (get, wrapKey, unwrapKey) usando la rispettiva identità di Microsoft Entra. L'identità del server può essere un'identità gestita assegnata dal sistema o un'identità gestita assegnata dall'utente e assegnata al server. Quando si usa il portale di Azure, l'identità di Microsoft Entra viene creata automaticamente al momento della creazione del server. Quando si usa PowerShell o CLI di Azure, è necessario creare in modo esplicito e verificare l'identità di Microsoft Entra. Consultare Configurare TDE con BYOK e Configurare TDE con BYOK per l'istanza gestita di SQL per istruzioni dettagliate relative all'uso con PowerShell.

  • In base al modello di autorizzazione dell'insieme di credenziali delle chiavi (criterio di accesso o Controllo degli accessi in base al ruolo di Azure) è possibile concedere l'accesso all'insieme di credenziali delle chiavi creando un criterio di accesso nell'insieme di credenziali delle chiavi oppure creando una nuova assegnazione di ruolo di Controllo degli accessi in base al ruolo di Azure con il ruolo Utente di crittografia del servizio di crittografia di Key Vault.

• Quando si usa il firewall con Azure Key Vault, è necessario abilitare l'opzione Consentire ai servizi Microsoft attendibili di ignorare il firewall? Per altre informazioni, vedere Configurare i firewall e le reti virtuali di Azure Key Vault.

Abilitare l'eliminazione temporanea e la protezione dalla rimozione definitiva per Azure Key Vault

Importante

Sia l’eliminazione temporanea che la protezione dall'eliminazione devono essere abilitate nell'insieme di credenziali delle chiavi quando si configura il TDE gestito dal cliente in un server nuovo o esistente o in un'istanza gestita.

L'eliminazione temporanea e la protezione dall'eliminazione sono funzionalità importanti di Azure Key Vault che consentono il ripristino di insiemi di credenziali delle chiavi eliminati e oggetti dell'insieme di credenziali delle chiavi eliminate, riducendo il rischio che un utente elimini accidentalmente o dannosamente una chiave o un insieme di credenziali delle chiavi.

• Le risorse eliminate temporaneamente vengono conservate per 90 giorni, a meno che non vengano recuperate o rimosse definitivamente dal cliente. Alle azioni di recupero e pulizia sono associate autorizzazioni specifiche nei criteri di accesso dell'insieme di credenziali delle chiavi. La funzionalità di eliminazione temporanea è attivata per impostazione predefinita per i nuovi insiemi di credenziali delle chiavi e può essere abilitata anche usando il portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure.

• La protezione dall'eliminazione può essere attivata tramite l'interfaccia della riga di comando di Azure o PowerShell. Quando la protezione dall'eliminazione è attivata, un insieme di credenziali o un oggetto nello stato eliminato non può essere ripulito finché non è terminato il periodo di conservazione. Il periodo di conservazione predefinito è di 90 giorni, ma può essere configurato da 7 a 90 giorni tramite il portale di Azure.

• Azure SQL richiede l'abilitazione della protezione dall'eliminazione temporanea e dell'eliminazione nell'insieme di credenziali delle chiavi contenente la chiave di crittografia usata come protezione TDE per il server o l'istanza gestita. Ciò consente di evitare lo scenario di eliminazione accidentale o dannosa di chiavi che può portare allo stato Inaccessibile del database.

• Quando si configura la protezione TDE in un server esistente o durante la creazione del server, Azure SQL verifica che l'insieme di credenziali delle chiavi usato abbia la protezione dell'eliminazione temporanea e dell'eliminazione attivata. Se l'eliminazione temporanea e la protezione dall'eliminazione non sono abilitate nell'insieme di credenziali delle chiavi, l'installazione della protezione TDE ha esito negativo e viene visualizzato un errore. In questo caso, è necessario abilitare la protezione dall’eliminazione temporanea e dall’eliminazione nell'insieme di credenziali delle chiavi e quindi eseguire la configurazione della protezione TDE.

Requisiti per la configurazione della protezione TDE

• La chiave di protezione TDE può essere solo una chiave RSA o HSM RSA asimmetrica. Le lunghezze supportate per le chiavi sono di 2048 e 3072 byte.

• La data di attivazione della chiave (se impostata) deve essere una data/ora nel passato. La data di scadenza (se impostata) deve essere una data e un'ora future.

• La chiave deve avere lo stato Abilitato.

• Se si importa una chiave esistente nell'insieme di credenziali delle chiavi, assicurarsi di specificarla nei formati di file supportati (.pfx, .byok o .backup).

Nota

Azure SQL adesso supporta l'uso di una chiave RSA archiviata in un HSM gestito come protezione TDE. Il modulo di protezione hardware gestito di Azure Key Vault è un servizio cloud completamente gestito, a disponibilità elevata, a tenant singolo e conforme agli standard che consente di proteggere le chiavi crittografiche per le applicazioni cloud tramite moduli di protezione hardware convalidati in base agli standard FIPS 140-2 livello 3. Altre informazioni sul HSM gestito.

Nota

Le versioni di Thales CipherTrust Manager precedenti alla versione 2.8.0 impediscono l'uso delle chiavi appena importate in Azure Key Vault con database SQL di Azure o Istanza gestita di SQL di Azure per scenari TDE gestiti dal cliente. Qui è possibile trovare ulteriori informazioni sul problema. Per questi casi, attendere 24 ore dopo l'importazione della chiave nell'insieme di credenziali delle chiavi per iniziare a usarla come protezione TDE per il server o l'istanza gestita. Questo problema è stato risolto in Thales CipherTrust Manager v2.8.0.

Suggerimenti per la configurazione di Transparent Data Encryption gestita dal cliente

Suggerimenti per la configurazione di AKV

• Associare al massimo 500 database di utilizzo generico o 200 database business critical in totale a un Key Vault in una singola sottoscrizione per garantire la disponibilità elevata quando il server accede alla protezione TDE in Key Vault. Queste cifre sono basate sull'esperienza e documentate nei limiti del servizio Key Vault. L'obiettivo è evitare problemi dopo il failover del server poiché nel Key Vault viene attivato un numero di operazioni per le chiavi corrispondente ai database nel server.

• Impostare un blocco di risorsa nell'insieme di credenziali delle chiavi per controllare chi può eliminare questa risorsa critica e impedire l'eliminazione accidentale o non autorizzata. Altre informazioni sui blocchi delle risorse.

• Abilitare il controllo e il reporting per tutte le chiavi di crittografia: Key Vault fornisce log che si inseriscono facilmente in altri strumenti di gestione di sicurezza delle informazioni e degli eventi. Log Analytics di Operations Management Suite è un esempio di un servizio già integrato.

• Collegare ogni server a due Key Vault che risiedono in aree diverse e contengono lo stesso materiale della chiave per garantire la disponibilità elevata dei database crittografati. Contrassegnare la chiave da uno dei Key Vault nella stessa area della protezione TDE. Se si verifica un'interruzione che interessa il Key Vault nella seconda area con il medesimo materiale per le chiavi, il sistema passa automaticamente al Key Vault nell'area remota.

Nota

Per consentire una maggiore flessibilità nella configurazione del TDE gestito dal cliente, database SQL di Azure e Istanza gestita di SQL di Azure in un'area possono ora essere collegati all'insieme di credenziali delle chiavi in qualsiasi altra area. Non è necessario che il server e l'insieme di credenziali delle chiavi si trovino nella stessa area.

Suggerimenti per la configurazione della protezione TDE

• Mantenere una copia della chiave di protezione TDE in un luogo sicuro o depositarla nel servizio di deposito.

• Se la chiave viene generata nel Key Vault, creare un backup della chiave prima di usare la chiave in AKV per la prima volta. Il backup può essere ripristinato solo in Azure Key Vault. Altre informazioni sul comando Backup-AzKeyVaultKey.

• Creare un nuovo backup ogni volta che vengono apportate modifiche alla chiave (ad esempio, ACL, tag, attributi chiave).

• Mantenere le versioni precedenti della chiave nell'insieme di credenziali delle chiavi durante la rotazione delle chiavi in modo tale da poter ripristinare i backup del database meno recenti. Quando viene modificata la protezione TDE per un database, i backup precedenti del database non vengono aggiornati per l'uso della protezione TDE più recente. In fase di ripristino ogni backup richiede la protezione TDE usata per la crittografia al momento della creazione. Le rotazioni delle chiavi possono essere eseguite seguendo le istruzioni riportate in Ruotare la protezione di Transparent Data Encryption con PowerShell.

• Conservare tutte le chiavi usate in precedenza in AKV anche dopo il passaggio alle chiavi gestite dal servizio. In questo modo è possibile ripristinare i backup dei database con protezioni TDE archiviate in AKV. È necessario conservare le protezioni TDE create con Azure Key Vault fino a quando tutti gli altri backup archiviati non sono stati creati con chiavi gestite dal servizio. Creare copie di backup recuperabili delle chiavi usando Backup-AzKeyVaultKey.

• Per rimuovere una chiave potenzialmente compromessa durante un evento di sicurezza imprevisto senza il rischio di perdita di dati, seguire la procedura descritta in Rimuovere una chiave potenzialmente compromessa.

Rotazione della protezione TDE

Ruotare una protezione TDE per un server significa passare a una nuova chiave asimmetrica che protegge i database nel server. La rotazione delle chiavi è un'operazione online e richiede solo alcuni secondi. L'operazione decrittografa e crittografa nuovamente la chiave di crittografia del database, non l'intero database.

La rotazione della protezione TDE può essere eseguita manualmente o usando la funzionalità di rotazione automatica.

La rotazione automatica della protezione TDE può essere abilitata durante la configurazione della protezione TDE per il server. La rotazione automatica è disabilitata per impostazione predefinita. Se abilitato, il server controlla continuamente l'insieme di credenziali delle chiavi per le nuove versioni della chiave usata come protezione TDE. Se viene rilevata una nuova versione della chiave, la protezione TDE nel server o nel database verrà ruotata automaticamente all’ultima versione entro 24 ore.

Se usata con rotazione automatica delle chiavi in Azure Key Vault, questa funzionalità abilita la rotazione end-to-end con zero tocco per la protezione TDE in database SQL di Azure e Istanza gestita di SQL di Azure.

Nota

L'impostazione di TDE con la chiave gestita tramite la rotazione manuale o automatica delle chiavi userà sempre l’ultima versione della chiave supportata. L'installazione non consente l'uso di una versione precedente o inferiore delle chiavi. L'uso costante dell’ultima versione della chiave è conforme ai criteri di sicurezza di Azure SQL che non consentono versioni precedenti delle chiavi che potrebbero essere compromesse. Le versioni precedenti della chiave possono essere necessarie a scopo di backup o ripristino del database, soprattutto in caso di backup di conservazione a lungo termine, in cui devono essere mantenute le versioni precedenti della chiave. Per le configurazioni della replica geografica, tutte le chiavi richieste dal server di origine devono essere presenti nel server di destinazione.

Considerazioni sulla replica geografica durante la configurazione della rotazione automatica della protezione TDE

Per evitare problemi durante la definizione o durante la replica geografica, quando la rotazione automatica della protezione TDE è abilitata nel server primario o secondario, è importante seguire queste regole durante la configurazione della replica geografica:

• Sia i server primari che secondari devono disporre delle autorizzazioni Get, wrapKey e unwrapKey per l'insieme di credenziali delle chiavi del server primario (insieme di credenziali delle chiavi che contiene la chiave di protezione TDE del server primario).

• Per un server con rotazione automatica delle chiavi abilitata, prima di avviare la replica geografica, aggiungere la chiave di crittografia usata come protezione TDE nel server primario al server secondario. Il server secondario richiede l'accesso alla chiave nello stesso insieme di credenziali delle chiavi usato con il server primario (e non un'altra chiave con lo stesso materiale della chiave). In alternativa, prima di avviare la replica geografica, assicurarsi che l'identità gestita del server secondario (assegnata dall'utente o assegnata dal sistema) disponga delle autorizzazioni necessarie per l'insieme di credenziali delle chiavi del server primario e che il sistema tenti di aggiungere la chiave al server secondario.

• Per una configurazione di replica geografica esistente, prima di abilitare la rotazione automatica delle chiavi nel server primario, aggiungere la chiave di crittografia usata come protezione TDE nel server primario al server secondario. Il server secondario richiede l'accesso alla chiave nello stesso insieme di credenziali delle chiavi usato con il server primario (e non un'altra chiave con lo stesso materiale della chiave). In alternativa, prima di abilitare la chiave automatizzata, assicurarsi che l'identità gestita del server secondario (assegnata dall'utente o assegnata dal sistema) disponga delle autorizzazioni necessarie per l'insieme di credenziali delle chiavi del server primario e che il sistema tenti di aggiungere la chiave al server secondario.

• Sono supportati scenari di replica geografica che usano chiavi gestite dal cliente (CMK) per TDE. È necessario configurare TDE con rotazione automatica delle chiavi in tutti i server se si sta configurando TDE nel portale di Azure. Per altre informazioni sulla configurazione della rotazione automatica delle chiavi per le configurazioni di replica geografica con TDE, vedere Rotazione automatica delle chiavi per le configurazioni di replica geografica.

Protezione TDE non accessibile

Quando la tecnologia TDE è configurata in modo da usare una chiave gestita dal cliente, è necessario l'accesso continuo alla protezione TDE affinché il database resti online. Se il server perde l'accesso alla protezione TDE gestita dal cliente in Azure Key Vault, dopo un massimo di 10 minuti il database inizierà a negare tutte le connessioni con il messaggio di errore corrispondente e cambierà lo stato in Inaccessibile. L'unica azione consentita in un database con stato Inaccessibile è l'eliminazione.

Nota

Se il database è inaccessibile a causa di un'interruzione di rete intermittente, non sarà necessario eseguire alcuna azione e i database torneranno online automaticamente.

Dopo il ripristino dell'accesso alla chiave, per riportare online il database sono necessari passaggi e tempo aggiuntivi, che possono variare in base al tempo trascorso senza accesso alla chiave e alle dimensioni del database:

Nota

• Se l'accesso alla chiave viene ripristinato entro 30 minuti, il database verrà riparato automaticamente entro un'ora.
• Se l'accesso alla chiave viene ripristinato dopo più di 30 minuti, l'accesso automatico del database non è possibile. Il ripristino dello stato online del database richiede dei passaggi extra nel portale di Azure e può richiedere una notevole quantità di tempo a seconda delle dimensioni del database.
• Quando il database è di nuovo online, le impostazioni a livello di server configurate in precedenza che possono includere la configurazione del gruppo di failover, i tag e le impostazioni a livello di database, ad esempio la configurazione dei pool elastici, la scalabilità in lettura, la sospensione automatica, la cronologia di ripristino temporizzato, i criteri di conservazione a lungo termine e altri andranno persi. È quindi consigliabile che i clienti implementino un sistema di notifica che identifichi la perdita di accesso alla chiave di crittografia entro 30 minuti. Una volta scaduta la finestra di 30 minuti, è consigliabile convalidare tutte le impostazioni a livello di server e database nel database ripristinato.

Di seguito è riportata una visualizzazione dei passaggi aggiuntivi necessari nel portale per riportare online un database inaccessibile.

Revoca accidentale dell'accesso alla protezione TDE

È possibile che un utente con diritti di accesso sufficienti al Key Vault disabiliti accidentalmente l'accesso del server alla chiave eseguendo le operazioni seguenti:

• revoca delle autorizzazioni get, wrapKey e unwrapKey dell’insieme di credenziali delle chiavi dal server

• eliminazione della chiave

• eliminazione del Key Vault

• modifica delle regole del firewall dell'insieme di credenziali delle chiavi

• eliminazione dell'identità gestita del server in Microsoft Entra ID

Altre informazioni sulle cause comuni per cui il database diventa inaccessibile.

Connettività bloccata tra Istanza gestita di SQL e l’insieme di credenziali delle chiavi

In Istanza gestita di SQL, gli errori di rete durante il tentativo di accesso alla protezione TDE in Azure Key Vault potrebbero non causare la modifica dello stato dei database in Inaccessibile, ma renderanno l'istanza non disponibile in seguito. Ciò si verifica principalmente quando la risorsa dell'insieme di credenziali delle chiavi esiste, ma l’istanza gestita non riesce a raggiungere l'endpoint. Tutti gli scenari in cui è possibile raggiungere l'endpoint dell'insieme di credenziali delle chiavi, ma la connessione viene negata, vi sono alcune autorizzazioni mancanti e così via, causano la modifica dello stato dei database in Inaccessibile.

Le cause più comuni della mancanza di connettività di rete a Key Vault sono:

• Key Vault viene esposto tramite endpoint privato e l'indirizzo IP privato del servizio AKV non è consentito nelle regole in uscita del gruppo di sicurezza di rete (NSG) associato alla subnet dell'istanza gestita.
• Problema di risoluzione DNS, come quando il nome di dominio completo (FQDN) dell'insieme di credenziali delle chiavi non viene risolto o viene risolto in un indirizzo IP non valido.

Testare la connettività da Istanza gestita di SQL al Key Vault che ospita la protezione TDE.

• L'endpoint è il nome di dominio completo dell'insieme di credenziali, ad esempio <vault_name>.vault.azure.net (senza https://).
• La porta da testare è la 443.
• Il risultato per RemoteAddress deve esistere e essere l'indirizzo IP corretto
• Il risultato per il test TCP deve essere TcpTestSucceeded : True.

Nel caso in cui il test riporti TcpTestSucceeded: False, esaminare la configurazione di rete:

• Controllare l'indirizzo IP risolto e confermarne la validità. Un valore mancante indica che si verificano problemi con la risoluzione DNS.
  • Verificare che il gruppo di sicurezza di rete nell'istanza gestita disponga di una regola in uscita che comprende l'indirizzo IP risolto sulla porta 443, soprattutto quando l'indirizzo risolto appartiene all'endpoint privato dell'insieme di credenziali delle chiavi.
  • Controllare altre configurazioni di rete, ad esempio la tabella di percorso, l'esistenza dell'appliance virtuale e la relativa configurazione, ecc.

Monitoraggio di Transparent Data Encryption gestita dal cliente

Per monitorare lo stato del database e abilitare gli avvisi per la perdita dell'accesso alla protezione TDE, configurare le funzionalità di Azure seguenti:

• Integrità risorse di Azure. Un database non accessibile che ha perso l'accesso alla protezione TDE viene visualizzato come "Non disponibile" dopo che è stata negata la prima connessione al database.
• Log attività. Quando si verifica un errore durante l'accesso alla protezione TDE nel Key Vault gestito dal cliente, vengono aggiunte voci al log attività. La creazione di avvisi per questi eventi consente di ripristinare l'accesso appena possibile.
• Gruppi di azioni. È possibile definire gruppi di azioni per inviare notifiche e avvisi in base alle preferenze, ad esempio Posta elettronica/SMS/Push/Messaggio vocale, App per la logica, Webhook, Gestione dei servizi IT o Runbook di Automazione.

Backup e ripristino di database con Transparent Data Encryption gestita dal cliente

Quando un database viene crittografato con TDE usando una chiave del Key Vault, vengono crittografati anche eventuali nuovi backup generati con la stessa protezione TDE. Quando la protezione TDE viene modificata, i backup precedenti del database non vengono aggiornati per l'uso della protezione TDE più recente.

Per ripristinare un backup crittografato con la protezione TDE del Key Vault, assicurarsi che il materiale della chiave sia disponibile per il server di destinazione. Per questa ragione, è consigliabile conservare tutte le versioni precedenti della protezione TDE nel Key Vault in modo che i backup dei database possano essere ripristinati.

Importante

In qualsiasi momento potrebbe non essere presente più di una protezione TDE impostata per un server. Si tratta della chiave contrassegnata con "Imposta la chiave predefinita come protezione TDE predefinita" nel pannello del portale di Azure. È possibile tuttavia collegare più chiavi aggiuntive a un server senza contrassegnarle come protezione TDE. Queste chiavi non vengono usate per la protezione della chiave DEK, ma possono essere usate durante il ripristino da un backup, se il file di backup è crittografato con la chiave con l'identificazione personale corrispondente.

Se la chiave necessaria per il ripristino di un backup non è più disponibile per il server di destinazione, viene restituito il messaggio di errore seguente nel tentativo di ripristino: "Il server <Servername> di destinazione non ha accesso a tutti gli URI di Azure Key Vault creati tra <Timestamp n. 1> e <Timestamp 2>. Ripetere l'operazione dopo il ripristino di tutti gli URI di Azure Key Vault".

Per risolvere il problema, eseguire il cmdlet Get-AzSqlServerKeyVaultKey per il server di destinazione oppure il cmdlet Get-AzSqlInstanceKeyVaultKey per l'istanza gestita di destinazione per restituire l'elenco delle chiavi disponibili e identificare le chiavi mancanti. Per garantire che tutti i backup possano essere ripristinati, verificare che il server di destinazione per il ripristino abbia accesso a tutte le chiavi necessarie. Le chiavi non devono essere contrassegnate come protezione TDE.

Per altre informazioni sul ripristino dei backup per il database SQL, vedere Recuperare un database nel database SQL. Per altre informazioni sul ripristino dei backup per il pool dedicato di SQL in Azure Synapse Analytics, vedere Recuperare un pool dedicato di SQL. Per il backup/ripristino nativo di SQL Server con un'istanza gestita, vedere Avvio rapido: ripristinare un database nell’Istanza gestita di SQL.

Un’altra considerazione per i file di resoconto: i file di resoconto di cui è stato eseguito il backup rimangono crittografati con la protezione TDE originale, anche se è stata ruotata e il database usa ora una nuova protezione TDE. In fase di ripristino, per ripristinare il database saranno necessarie entrambe le chiavi. Se il file di log usa una protezione TDE archiviata in Azure Key Vault, questa chiave sarà necessaria in fase di ripristino, anche se nel frattempo il database è stato modificato per usare TDE gestita dal servizio.

Disponibilità elevata con Transparent Data Management gestita dal cliente

Anche nei casi in cui non è stata configurata alcuna ridondanza geografica per il server, si consiglia di configurare il server per l'uso di due diversi Key Vault in due aree diverse con lo stesso materiale della chiave. La chiave nel Key Vault secondario in un'altra area non deve essere contrassegnata come protezione TDE e non è consentito. Solo se si verifica un'interruzione che interessa il Key Vault primario, il sistema passa automaticamente all'altra chiave collegata con la stessa identificazione personale nel Key Vault secondario, se esistente. Si noti che il passaggio non si verifica se la protezione TDE non è accessibile a causa di diritti di accesso revocati o perché la chiave o il Key Vault è stato eliminato. Ciò potrebbe indicare che il cliente ha intenzionalmente voluto limitare l'accesso alla chiave da parte del server. È possibile fornire lo stesso materiale della chiave a due insiemi di credenziali delle chiavi in aree diverse creando la chiave all'esterno dell'insieme di credenziali delle chiavi e importandole in entrambi gli insiemi di credenziali delle chiavi.

In alternativa, è possibile generare la chiave usando l'insieme di credenziali delle chiavi primaria in un'area e clonando la chiave in un insieme di credenziali delle chiavi in un'area di Azure diversa. Usare il cmdlet Backup-AzureKeyVaultKey per recuperare la chiave in formato crittografato dal Key Vault primario e quindi usare il cmdlet Restore-AzureKeyVaultKey e specificare un Key Vault nella seconda area per clonare la chiave. In alternativa, usare portale di Azure per eseguire il backup e il ripristino della chiave. L'operazione di backup/ripristino delle chiavi è consentita solo tra gli insiemi di credenziali delle chiavi nella stessa sottoscrizione di Azure e nella stessa area geografica di Azure.

Ripristino di emergenza geografico e Transparent Data Encryption gestita dal cliente

In entrambi gli scenari di replica geografica attiva e gruppi di failover, i server primari e secondari coinvolti possono essere collegati allo stesso insieme di credenziali delle chiavi (in qualsiasi area) o a insiemi di credenziali delle chiavi separati. Se ai server primari e secondari sono collegati insiemi di credenziali delle chiavi separati, il cliente è responsabile di mantenere la coerenza del materiale delle chiavi negli insiemi di credenziali delle chiavi, affinché la replica geografica secondaria sia sincronizzata e possa sostituire quella primaria usando la stessa chiave dell'insieme di credenziali collegato se il server primario diventa inaccessibile a causa di un'interruzione di servizio nell'area e viene attivato il failover. È possibile configurare fino a quattro repliche secondarie e il concatenamento (database secondari di database secondari) non è supportato.

Per evitare problemi durante la creazione o durante la replica geografica a causa di un materiale della chiave incompleto, è importante attenersi alle regole seguenti durante la configurazione di TDE gestita dal cliente (se si utilizzano insieme di credenziali delle chiavi separati per i server primari e secondari):

• Tutti i Key Vault interessati devono avere le stesse proprietà e gli stessi diritti di accesso per i rispettivi server.

• Tutti i Key Vault interessati devono contenere lo stesso materiale della chiave. Ciò si applica alla protezione TDE corrente e a tutte le protezioni TDE precedenti che possono essere state usate nei file di backup.

• Sia la configurazione iniziale che la rotazione della protezione TDE devono essere eseguite prima nel database secondario e successivamente nel database primario.

Per testare un failover, seguire la procedura descritta in Panoramica della replica geografica attiva. Il failover di test deve essere eseguito regolarmente per verificare che il database SQL abbia mantenuto l'autorizzazione di accesso a entrambi gli insiemi di credenziali delle chiavi.

Il server di database SQL e l’istanza gestita di SQL di Azure in un'area ora possono essere collegati all'insieme di credenziali delle chiavi in qualsiasi altra area. Non è necessario che il server e l'insieme di credenziali delle chiavi si trovino nella stessa area. In questo modo, per semplicità, i server primario e secondario possono essere connessi allo stesso insieme di credenziali delle chiavi (in qualsiasi area). Ciò consente di evitare scenari in cui il materiale delle chiavi potrebbe non essere sincronizzato se vengono usati insiemi di credenziali delle chiavi separati per entrambi i server. Azure Key Vault dispone di più livelli di ridondanza per assicurarsi che le chiavi e gli insiemi di credenziali delle chiavi rimangano disponibili in caso di errori del servizio o dell'area. Disponibilità e ridondanza in Azure Key Vault

Criteri di Azure per TDE gestito dal cliente

È possibile utilizzare i Criteri di Azure per applicare TDE gestito dal cliente durante la creazione o l'aggiornamento di un server database SQL di Azure o Istanza gestita di SQL di Azure. Con questo criterio, qualsiasi tentativo di creare o aggiornare un server logico in Azure o un'istanza gestita avrà esito negativo se non è configurato con una chiave gestita dal cliente. È possibile applicare i Criteri di Azure all'intera sottoscrizione di Azure o solo all'interno di un gruppo di risorse.

Per altre informazioni sui Criteri di Azure, vedere Che cosa sono i Criteri di Azure? e Definizione della struttura dei Criteri di Azure.

I due criteri predefiniti seguenti sono supportati per TDE gestito dal cliente nei Criteri di Azure:

• I server SQL devono usare chiavi gestite dal cliente per la crittografia dei dati inattivi
• Le istanze gestite devono usare chiavi gestite dal cliente per la crittografia dei dati inattivi

I criteri TDE gestiti dal cliente possono essere gestiti passando al portale di Azure e cercando il servizio Criteri. In Definizioni cercare la chiave gestita dal cliente.

Esistono tre effetti per questi criteri:

• Audit: l'impostazione predefinita e acquisisce solo un report di controllo nei log attività Criteri di Azure
• Nega: impedisce la creazione o l'aggiornamento di un server logico o di un'istanza gestita dal cliente senza una chiave gestita dal cliente configurata
• Disabilitato: disabilita il criterio e non impedisce agli utenti di creare o aggiornare un server logico o un'istanza gestita senza TDE gestito dal cliente abilitato

Se Criteri di Azure per TDE gestito dal cliente è impostato su Nega, la creazione del server logico SQL di Azure o dell'istanza gestita avrà esito negativo. I dettagli di questo errore verranno registrati nel log attività del gruppo di risorse.

Importante

Le versioni precedenti dei criteri predefiniti per TDE gestito dal cliente contenenti l'effetto AuditIfNotExist sono state deprecato. Le assegnazioni di criteri esistenti che usano i criteri deprecati non sono interessate e continueranno a funzionare come prima.

Passaggi successivi

È anche possibile controllare gli script di esempio di PowerShell seguenti per le operazioni comuni con Transparent Data Encryption gestita dal cliente:

• Ruotare la transparent data encryption per il database SQL tramite PowerShell

• Rimuovere una protezione TDE (Transparent Data Encryption) per il database SQL

• Gestire Transparent Data Encryption in un'istanza gestita di SQL con una chiave personalizzata usando PowerShell

Inoltre, abilitare Microsoft Defender per SQL per proteggere il database e i dati in esso contenuti, con funzionalità per il rilevamento e l'attenuazione di potenziali vulnerabilità dei database e il rilevamento di attività anomale che potrebbero indicare una minaccia per il database.