Azure SQL la crittografia dei dati trasparente con chiave gestita dal cliente

Si applica a: Database SQL di Azure Istanza gestita di SQL di Azure Azure Synapse Analytics

Azure SQL la crittografia dei dati trasparente (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 implementare la separazione dei compiti nella gestione delle chiavi e dei dati. Con TDE gestito dal cliente, il cliente è responsabile e in un controllo completo di una gestione del ciclo di vita delle chiavi (creazione, caricamento, rotazione, eliminazione), autorizzazioni di utilizzo delle chiavi e 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 o trasferita all'insieme di credenziali delle chiavi da un dispositivo HSM locale.

Per Azure SQL Database e analisi Azure Synapse, la protezione TDE è impostata a livello di server e viene ereditata da tutti i database crittografati associati a tale 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. Il termine server fa riferimento a un server in database SQL e Azure Synapse e a un'istanza gestita in Istanza gestita di SQL in tutto questo documento, a meno che non sia indicato diversamente.

Nota

Questo articolo si applica a database Azure SQL, Istanza gestita di SQL di Azure e Azure Synapse Analytics (pool SQL dedicati (in precedenza SQL DW)). Per la documentazione sulla crittografia dei dati trasparente per i pool SQL dedicati all'interno delle aree di lavoro di Synapse, vedere crittografia Azure Synapse Analytics.

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.

Nota

Per fornire Azure SQL clienti con due livelli di crittografia dei dati inattivi, la crittografia dell'infrastruttura (usando l'algoritmo di crittografia AES-256) con chiavi gestite dalla piattaforma viene implementata. In questo modo viene fornito un livello di crittografia aggiuntivo inattivo insieme a TDE con chiavi gestite dal cliente, già disponibili. Per Azure SQL Database e Istanza gestita, tutti i database, inclusi il database master e altri database di sistema, verranno crittografati quando viene attivata la crittografia dell'infrastruttura. In questo momento, i clienti devono richiedere l'accesso a questa funzionalità. Se si è interessati a questa funzionalità, contattare AzureSQLDoubleEncryptionAtRest@service.microsoft.com.

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à dei clienti finali, poiché AKV è progettato in modo che Microsoft non possa visualizzare né estrarre chiavi di crittografia;

Funzionamento di Transparent Data Encryption gestita dal cliente

Installazione e funzionamento di Transparent Data Encryption gestita dal cliente

Per consentire al server di Azure SQL di usare la protezione TDE archiviata in AKV per la crittografia del codice DEK, l'amministratore dell'insieme di credenziali delle chiavi deve concedere i diritti di accesso seguenti al server usando l'identità univoca di Azure Active Directory (Azure AD):

  • 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 eventuali modifiche alle autorizzazioni da apportare per l'insieme di credenziali delle chiavi. Ciò include la revoca delle autorizzazioni di accesso alla protezione TDE in AKV 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

  • Il Key Vault e il database SQL o l'istanza gestita devono appartenere allo stesso tenant di Azure Active Directory. Le interazioni tra insiemi di credenziali delle chiavi e server in diversi tenant non sono supportate. Per spostare le risorse in un secondo momento, è necessario riconfigurare Transparent Data Encryption con AKV. Altre informazioni sullo spostamento di risorse.

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

  • Concedere al server o all'istanza gestita l'accesso all'insieme di credenziali delle chiavi (get, wrappingKey, unwrapKey) usando l'identità di Azure Active Directory. L'identità del server può essere un'identità gestita assegnata dal sistema o un'identità gestita assegnata dall'utente assegnata al server. Quando si usa il portale di Azure, l'identità di Azure AD viene creata automaticamente al momento della creazione del server. Quando si usa PowerShell o l'interfaccia della riga di comando di Azure, è necessario creare in modo esplicito e verificare l'identità di Azure AD. Vedere Configurare TDE con BYOK e Configurare TDE con BYOKper Istanza gestita di SQL per istruzioni dettagliate dettagliate quando si usa 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 AKV, è necessario abilitare l'opzione Consentire ai servizi Microsoft attendibili di ignorare il firewall?

Abilitare la protezione di eliminazione temporanea ed eliminazione per AKV

Importante

Sia l'eliminazione temporanea che la protezione dell'eliminazione devono essere abilitate nell'insieme di credenziali delle chiavi durante la configurazione del TDE gestito dal cliente in un server nuovo o esistente o in un'istanza gestita.

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

  • Le risorse eliminate in modo temporaneo vengono mantenute per 90 giorni, a meno che non vengano ripristinate o eliminate 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 è attiva per impostazione predefinita per i nuovi insiemi di credenziali delle chiavi e può anche essere abilitata usando l'portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure.

  • La protezione di 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 è configurabile da 7 a 90 giorni attraverso la portale di Azure.

  • Azure SQL richiede l'abilitazione della protezione dell'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 impedire lo scenario dell'insieme di credenziali delle chiavi accidentali o dannose o dell'eliminazione delle chiavi che può causare l'accesso al database in stato inaccessibile .

  • Quando si configura la protezione TDE in un server esistente o durante la creazione del server, Azure SQL convalida che l'insieme di credenziali delle chiavi usato abbia la protezione di eliminazione temporanea ed eliminazione attivata. Se la protezione di eliminazione temporanea e eliminazione non è abilitata nell'insieme di credenziali delle chiavi, l'installazione della protezione TDE ha esito negativo con un errore. In questo caso, è necessario abilitare la protezione di eliminazione temporanea e 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 della chiave supportate sono 2048 byte e 3072 byte.

  • La data di attivazione della chiave (se impostata) deve essere una data e un'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 la chiave esistente nell'insieme di credenziali delle chiavi, assicurarsi di specificarlo nei formati di file supportati (.pfx, o .byok.backup).

Nota

Azure SQL ora supporta l'uso di una chiave RSA archiviata in una protezione HSM gestita come protezione TDE. Azure Key Vault Managed HSM è un servizio cloud conforme agli standard, completamente gestito, a disponibilità elevata e a disponibilità elevata che consente di proteggere le chiavi crittografiche per le applicazioni cloud usando FIPS 140-2 Livello 3 convalidato. Altre informazioni sulle macchine virtuali gestite.

Nota

Un problema con le versioni di Thales CipherTrust Manager precedenti alla versione 2.8.0 impedisce che le chiavi appena importate in Azure Key Vault vengano usate con Azure SQL Database o Istanza gestita di SQL di Azure per scenari TDE gestiti dal cliente. Altre informazioni su questo problema sono disponibili qui. Per questi casi, attendere 24 ore dopo l'importazione della chiave nell'insieme di credenziali delle chiavi per iniziare a usarlo 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 nel Key Vault 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 la creazione di report per tutte le chiavi di crittografia: Il Key Vault offre log che possono essere facilmente inclusi in altri strumenti di gestione delle informazioni di sicurezza e di gestione 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 degli insiemi di credenziali delle chiavi come protezione TDE. Il sistema passerà automaticamente all'insieme di credenziali delle chiavi nella seconda area con lo stesso materiale della chiave, se si verifica un'interruzione che influisce sull'insieme di credenziali delle chiavi nella prima area.

Nota

Per consentire una maggiore flessibilità nella configurazione del TDE gestito dal cliente, Azure SQL server di database e Istanza gestita 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 attributi chiave, tag, ACL.

  • 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 Transparent Data Encryption tramite 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

La rotazione della 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 richiederà 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.

È possibile abilitare la rotazione automatica della protezione TDE durante la configurazione della protezione TDE per il server. La rotazione automatica è disabilitata per impostazione predefinita. Se abilitata, il server controlla continuamente l'insieme di credenziali delle chiavi per le nuove versioni della chiave usate come protezione TDE. Se viene rilevata una nuova versione della chiave, la protezione TDE nel server verrà ruotata automaticamente alla versione più recente della chiave entro 60 minuti.

Se usato con rotazione automatica delle chiavi in Azure Key Vault, questa funzionalità consente la rotazione end-to-end zero-touch per la protezione TDE in Azure SQL Database e Istanza gestita di SQL di Azure.

Nota

La rotazione automatica della funzionalità di protezione TDE è attualmente disponibile in anteprima pubblica per database SQL e Istanza gestita.

Considerazioni sulla replica geografica durante la configurazione della rotazione automatizzata 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.

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 aver ripristinato l'accesso alla chiave, il ripristino online del database richiede tempo e passaggi aggiuntivi, che possono variare in base al tempo trascorso senza accedere alla chiave e alle dimensioni dei dati nel database:

  • Se l'accesso alla chiave viene ripristinato entro 30 minuti, il database verrà eseguito automaticamente entro l'ora successiva.

  • Se l'accesso alla chiave viene ripristinato dopo più di 30 minuti, l'esecuzione automatica non è possibile e il ripristino del database richiede passaggi aggiuntivi nel portale e può richiedere una quantità significativa di tempo a seconda delle dimensioni del database. Quando il database è di nuovo online, le impostazioni a livello di server configurate in precedenza, ad esempio la configurazione del gruppo di failover, la cronologia dei ripristini temporizzati e i tag, andranno persi. È quindi consigliabile implementare un sistema di notifica che consente di identificare e risolvere i problemi di accesso alla chiave sottostante entro 30 minuti.

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

Database inaccessibile TDE BYOK

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, unwrapKey del server dell'insieme di credenziali delle chiavi

  • 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 Azure Active Directory

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

Connettività bloccata tra Istanza gestita di SQL e Key Vault

In Istanza gestita di SQL, gli errori di rete durante il tentativo di accedere 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 non è possibile raggiungere l'endpoint dall'istanza gestita. Tutti gli scenari in cui è possibile raggiungere l'endpoint dell'insieme di credenziali delle chiavi, ma la connessione viene negata, le 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.
  • Risoluzione DNS non valida, ad esempio quando l'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 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 il https://). - La porta da testare è 443. - Il risultato di RemoteAddress deve esistere e deve essere l'indirizzo IP corretto. Il risultato del test TCP deve essere TcpTestSucceeded: True.

Nel caso in cui il test restituisca TcpTestSucceeded: False, esaminare la configurazione di rete: - Controllare l'indirizzo IP risolto, verificare che sia valied. 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 copre 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 route, l'esistenza dell'appliance virtuale e la relativa configurazione e così via.

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.
  • I gruppi di azioni possono essere definiti per inviare notifiche e avvisi in base alle preferenze, ad esempio Email/SMS/Push/Voice, App per la logica, Webhook, ITSM 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 AKV creati tra <Timestamp #1> e <Timestamp #2>. Ripetere l'operazione dopo il ripristino di tutti gli URI AKV."

Per attenuarlo, eseguire il cmdlet Get-AzSqlServerKeyVaultKey per il server di destinazione o Get-AzSqlInstanceKeyVaultKey per l'istanza gestita di destinazione per restituire l'elenco delle chiavi disponibili e identificare quelli 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 di backup per database SQL, vedere Ripristinare un database in database SQL. Per altre informazioni sul ripristino di backup per i pool SQL dedicati in Azure Synapse Analytics, vedere Ripristinare un pool SQL dedicato. Per il backup o il ripristino nativo di SQL Server con Istanza gestita di SQL, vedere Guida introduttiva: Ripristinare un database in Istanza gestita di SQL.

Un'altra considerazione per i file di log: i file di log 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 la ridondanza geografica per il server, è consigliabile configurare il server per usare due insiemi di credenziali delle chiavi diverse in due aree diverse con lo stesso materiale della chiave. La chiave nell'insieme di credenziali delle chiavi secondarie nell'altra area non deve essere contrassegnata come protezione TDE e non è nemmeno consentita. Se si verifica un'interruzione che influisce sull'insieme di credenziali delle chiavi primarie e quindi, il sistema passa automaticamente all'altra chiave collegata con la stessa identificazione personale nell'insieme di credenziali delle chiavi secondarie, se presente. Si noti anche se l'opzione non si verifica se la protezione TDE è inaccessibile a causa dei diritti di accesso revocati o perché la chiave o l'insieme di credenziali delle chiavi viene eliminata, in quanto può indicare che il cliente vuole intenzionalmente limitare l'accesso al server dalla chiave. Fornire lo stesso materiale chiave a due insiemi di credenziali delle chiavi in aree diverse può essere eseguito creando la chiave all'esterno dell'insieme di credenziali delle chiavi e importandoli in entrambi gli insiemi di credenziali delle chiavi.

In alternativa, può essere eseguita generando la chiave usando l'insieme di credenziali delle chiavi primarie in un'area e clonando la chiave in un insieme di credenziali delle chiavi in un'area di Azure diversa. Usare il cmdlet Backup-AzKeyVaultKey per recuperare la chiave in formato crittografato dall'insieme di credenziali delle chiavi primarie e quindi usare il cmdlet Restore-AzKeyVaultKeyKey e specificare un insieme di credenziali delle chiavi nella seconda area per clonare la chiave. In alternativa, usare il portale di Azure per eseguire il backup e ripristinare la chiave. L'operazione di backup/ripristino delle chiavi è consentita solo tra gli insiemi di credenziali delle chiavi all'interno della stessa sottoscrizione di Azure e l'area geografica di Azure.

Disponibilità elevata con server singolo

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 per separare gli insiemi di credenziali delle chiavi. Se gli insiemi di credenziali delle chiavi separati sono collegati ai server primari e secondari, il cliente è responsabile del mantenimento coerente del materiale della chiave negli insiemi di credenziali delle chiavi, in modo che il database geo-secondario sia sincronizzato e possa assumere la stessa chiave dall'insieme di credenziali delle chiavi collegato se la chiave primaria diventa inaccessibile a causa di un'interruzione nell'area e viene attivato un failover. È possibile configurare fino a quattro secondarie e la concatenazione (secondarie di secondarie) non è supportata.

Per evitare problemi durante la definizione o durante la replica geografica a causa di materiale chiave incompleto, è importante seguire queste regole durante la configurazione del TDE gestito dal cliente (se vengono usati insiemi di credenziali delle chiavi separate 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.

Gruppi di failover e ripristino di emergenza geografico

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 database SQL abbia mantenuto l'autorizzazione di accesso a entrambi gli insiemi di credenziali delle chiavi.

Azure SQL server di database e Istanza gestita in un'area può ora essere collegato all'insieme di credenziali delle chiavi in qualsiasi altra area. Il server e l'insieme di credenziali delle chiavi non devono essere inclusi 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 dell'insieme di credenziali delle chiavi di Azure

Criteri di Azure per TDE gestito dal cliente

Criteri di Azure può essere usato per applicare il TDE gestito dal cliente durante la creazione o l'aggiornamento di un server di database Azure SQL o Istanza gestita di SQL di Azure. Con questo criterio, eventuali tentativi di creare o aggiornare un server logico in Azure o nell'istanza gestita avranno esito negativo se non è configurato con una chiave gestita dal cliente. Il Criteri di Azure può essere applicato all'intera sottoscrizione di Azure o solo all'interno di un gruppo di risorse.

Per altre informazioni su Criteri di Azure, vedere Informazioni Criteri di Azure eCriteri di Azure struttura di definizione.

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

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

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

Per questi criteri sono disponibili tre effetti:

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

Se il Criteri di Azure per TDE gestito dal cliente è impostato su Deny, Azure SQL server logico o creazione di istanze gestite 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 il TDE gestito dal cliente contenenti l'effetto AuditIfNotExist sono state deprecate. 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:

Inoltre, abilitare Microsoft Defender per SQL per proteggere i database e i relativi dati, con funzionalità per individuare e mitigare potenziali vulnerabilità del database e rilevare attività anomale che potrebbero indicare una minaccia ai database.