Condividi tramite

Crittografia dei dati trasparente Azure SQL con chiave gestita dal cliente

  • Articolo

Si applica a:database SQL di AzureIstanza gestita di SQL di AzureAzure Synapse Analytics (solo pool SQL dedicati)

Transparent Data Encryption (TDE) inAzure SQL 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'archivio delle chiavi, importata o trasferita all'archivio 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 si applica al database SQL di Azure, all'Istanza gestita di SQL di Azure e ad Azure Synapse Analytics (pool SQL dedicati (in precedenza SQL Data Warehouse)). Per la documentazione su Transparent Data Encryption (TDE) per pool SQL dedicati all'interno delle aree di lavoro Synapse, consultare 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

Nota

In questo articolo i termini Chiave gestita dal cliente (CMK) e Bring Your Own Key (BYOK) vengono usati in modo intercambiabile, ma rappresentano alcune differenze.

  • chiave gestita dal cliente (CMK): il cliente gestisce il ciclo di vita della chiave, inclusa la creazione, la rotazione e l'eliminazione delle chiavi. La chiave viene archiviata in azure Key Vault o del modulo di protezione hardware gestito di Azure Key Vault e usata per la crittografia della chiave di crittografia del database (DEK) in Azure SQL, SQL Server in una macchina virtuale di Azure e in SQL Server locale.
  • BYOK (Bring Your Own Key): il cliente importa o porta in modo sicuro la propria chiave da un modulo di protezione hardware locale (HSM) in Azure Key Vault o nel modulo di protezione hardware gestito di Azure Key Vault. Tali chiavi importate possono essere usate come qualsiasi altra chiave in Azure Key Vault, inclusa come chiave gestita dal cliente per la crittografia della chiave DEK. Per ulteriori informazioni, vedere Importare chiavi protette da HSM in un HSM gestito (BYOK).

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 coloro che usano TDE gestito dal servizio che vogliono iniziare a usare TDE gestito dal cliente, i dati rimangono crittografati durante il processo di passaggio e non sono previsti tempi di inattività né la ricrittografazione 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

Diagramma che mostra l’installazione e il 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 diritti di accesso usando l'identità Microsoft Entra univoca. Esistono due modelli di accesso per consentire al server di accedere al key vault.

  • Controllo degli accessi in base al ruolo di Azure: usare il controllo degli accessi in base al ruolo di Azure per concedere a un utente, a un gruppo o a un'applicazione l'accesso al Key Vault. Questo metodo è consigliato per la flessibilità e la granularità. Per consentire all'identità del server di usare la chiave per le operazioni di crittografia e decrittografia, è necessario il ruolo Utente di crittografia del servizio Key Vault.

  • Criterio di accesso al key vault - Usare il criterio di accesso al key vault per concedere al server l'accesso al key vault. Questo metodo è più semplice e più diretto, ma meno flessibile. L'identità del server deve disporre delle seguenti autorizzazioni sul deposito di chiavi:

    • 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

Nel menu del portale di Azure Configurazione di accesso dell’insieme di credenziali delle chiavi, è possibile selezionare il controllo degli accessi in base al ruolo di Azure o i criteri di accesso a Key Vault. Per istruzioni dettagliate sulla configurazione di una configurazione di accesso di Azure Key Vault per TDE, vedere Configurare la gestione delle chiavi estendibili TDE di SQL Server usando Azure Key Vault. Per altre informazioni sui modelli di accesso, vedere Sicurezza in Azure Key Vault.

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 affinché le modifiche alle autorizzazioni nel Key Vault diventino effettive. 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 cancellazione definitiva devono essere abilitate nel vault delle chiavi per proteggere dalla perdita di dati dovuta a un'eliminazione accidentale della chiave o del vault 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.

  • Quando si usa un firewall con AKV, è necessario abilitare l'opzione Consenti servizi Microsoft attendibile di ignorare il firewall, a meno che non si usino endpoint privati per AKV. Per altre informazioni, vedere Configurare i firewall e le reti virtuali di Azure Key Vault.

Abilitare il soft-delete e la protezione contro l'eliminazione per AKV

Importante

Sia l'eliminazione temporanea che la protezione dalla cancellazione permanente devono essere abilitate nella cassetta delle chiavi quando si configura il TDE gestito dal cliente su un server nuovo o esistente o su un'istanza gestita.

L'eliminazione temporanea e la protezione dalla cancellazione sono funzionalità importanti di Azure Key Vault che consentono il recupero delle casseforti eliminate e degli oggetti eliminati delle stesse, riducendo il rischio che un utente elimini accidentalmente o intenzionalmente una chiave o una cassaforte.

  • 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 in un criterio di accesso della chiave. 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 caveau o un oggetto nello stato eliminato non può essere eliminato definitivamente finché non termina 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 che la protezione dall'eliminazione temporanea e la protezione di eliminazione siano abilitate nel contenitore di credenziali delle chiavi che contiene la chiave di crittografia utilizzata come protettore 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 il protettore TDE in un server esistente o durante la creazione del server, Azure SQL verifica che l'insieme di credenziali usato abbia la protezione contro l'eliminazione temporanea e l'eliminazione completa attivata. Se soft-delete e protezione dalla cancellazione non sono abilitate nel Key Vault, la configurazione della protezione TDE fallisce con un errore. In questo caso, la protezione dall’eliminazione temporanea e definitiva deve prima essere abilitata nell'insieme di credenziali delle chiavi, e quindi si dovrebbe eseguire l'impostazione del protettore TDE.

Requisiti per la configurazione della protezione TDE

  • La chiave di protezione TDE può essere solo una chiave asimmetrica, RSA o RSA HSM. 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 importi una chiave esistente nel set di credenziali delle chiavi, assicurati di specificarla in uno dei formati di file supportati (.pfx, .byok o .backup).

Nota

Azure SQL e SQL Server in una VM Azure adesso supportano 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. Scopri di più sugli HSM gestiti e sulle autorizzazioni di configurazione o RBAC necessarie per SQL Server nell'articolo Configurare la gestione delle chiavi estendibili TDE di SQL Server usando Azure Key Vault.

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 nel key vault 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 è prevenire problemi dopo il failover del server, in quanto verranno eseguite nel Key Vault tante operazioni chiave quanti sono i database presenti in quel server.

  • Imposta un blocco di risorsa sulla cassaforte delle chiavi per gestire chi ha il permesso di eliminare questa risorsa critica e prevenire 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.

  • Usare un vault delle chiavi da un'area di Azure in grado di replicare il contenuto in un'area associata per la massima disponibilità. Per altre informazioni, vedere Procedure consigliate per l'uso di Azure Key Vault e disponibilità e ridondanza di Azure Key Vault.

Nota

Per consentire una maggiore flessibilità nella configurazione del TDE gestito dal cliente, i database SQL di Azure e le istanze gestite di SQL di Azure in una regione possono ora essere collegati a un Key Vault in qualsiasi altra regione. Non è necessario che il server e il vault 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 nel vault delle chiavi durante la rotazione delle chiavi in modo da poter ripristinare i backup del database più vecchi. 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 il protettore TDE con cui è stato criptato 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

Il cambio del protettore TDE per un server significa passare a una nuova chiave asimmetrica che protegge i database sul 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 controllerà continuamente l'archivio delle chiavi per eventuali nuove versioni della chiave utilizzata come protettore 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 senza intervento manuale per il protector TDE nel database SQL di Azure e nell'istanza gestita di SQL di Azure.

Nota

L'impostazione di TDE con la chiave gestita dal cliente tramite rotazione manuale o automatica delle chiavi utilizzerà 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 chiavi usato con il server primario (e non un'altra chiave con lo stesso materiale crittografico). 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 Key Vault utilizzato con il server primario (e non un'altra chiave con lo stesso materiale 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 non è accessibile a causa di un'interruzione intermittente della rete, non è necessaria alcuna azione e i database tornano online automaticamente. Per ridurre l'impatto degli errori di rete o delle interruzioni durante il tentativo di accedere alla protezione TDE in Azure Key Vault, è stato introdotto un buffer di 24 ore prima che il servizio tenti di spostare il database in uno stato inaccessibile. Se si verifica un failover prima di raggiungere lo stato inaccessibile, il database diventa non disponibile a causa della perdita della cache di crittografia.

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.

Database TDE BYOK inaccessibile.

Revoca accidentale dell'accesso alla protezione TDE

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

  • revoca delle autorizzazioni get, wrapKey e unwrapKey del key vault dal server

  • eliminazione della chiave

  • cancellazione del Key Vault

  • modifica delle regole del firewall del vault 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 SQL Istanza Gestita e Key Vault

Il blocco di connettività di rete tra un'istanza gestita di SQL e una Key Vault si verifica principalmente quando la risorsa della Key Vault esiste, ma il suo endpoint non è raggiungibile dall'istanza gestita. Tutti gli scenari in cui è possibile raggiungere l'endpoint del deposito chiavi, ma la connessione viene negata, mancano autorizzazioni, ecc., 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'archivio 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 copra l'indirizzo IP risolto sulla porta 443, soprattutto quando l'indirizzo risolto appartiene all'endpoint privato del Key Vault.
    • Controllare altre configurazioni di rete, ad esempio la tabella di percorso, l'esistenza dell'appliance virtuale e la relativa configurazione, ecc.

Monitoraggio della Transparent Data Encryption (TDE) 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à delle 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.

Database backup e restore con TDE gestito 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 proteggere la chiave DEK, ma possono essere usate durante il ripristino da un backup, se il file di backup viene 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 AKV.

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 log: i file di log di cui è stato eseguito il backup rimangono crittografati con la protezione TDE originale, anche se è stato ruotato e il database usa ora una nuova protezione TDE. In fase di ripristino, per ripristinare il database sono 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

Con L'AKV che fornisce più livelli di ridondanza, i TDE che usano una chiave gestita dal cliente possono sfruttare la disponibilità e la resilienza di AKV e affidarsi completamente alla soluzione di ridondanza AKV.

I molteplici livelli di ridondanza di AKV garantiscono l'accesso alle chiavi anche se i singoli componenti del servizio falliscono o le aree di Azure o le zone di disponibilità sono inattive. Per altre informazioni, vedere Disponibilità e ridondanza in Azure Key Vault.

AKV offre i componenti seguenti di disponibilità e resilienza forniti automaticamente senza l'intervento dell'utente:

Nota

Per tutte le aree di coppia, le chiavi AKV vengono replicate in entrambe le aree e sono presenti moduli di protezione hardware in entrambe le aree che possono operare su tali chiavi. Per altre informazioni, vedere Replica dei dati. Questo vale sia per i livelli di servizio Standard che premium di Azure Key Vault e per le chiavi software o hardware.

Ripristino di emergenza geografico e Transparent Data Encryption gestita dal cliente

Sia negli scenari di replica geografica attiva e gruppi di failover, i server primari e secondari coinvolti possono essere collegati all'Azure Key Vault situato in qualsiasi regione. Il server e l'insieme delle chiavi non devono essere collocati nella stessa regione. In questo modo, per semplicità, i server primario e secondario possono essere connessi allo stesso Key Vault (in qualsiasi regione). Ciò consente di evitare scenari in cui il materiale chiave potrebbe non essere sincronizzato se vengono utilizzati archivi delle chiavi separati per i due server. 

Azure Key Vault include più livelli di ridondanza per garantire che le chiavi e gli archivi delle chiavi rimangano disponibili in caso di guasti del servizio o della regione. La ridondanza è supportata dalle regioni abbinate e non abbinate. Per altre informazioni, vedere Disponibilità e ridondanza in Azure Key Vault.

Esistono diverse opzioni per archiviare la chiave di protezione TDE, in base ai requisiti dei clienti:

  • Sfrutta Azure Key Vault e la resilienza nativa delle aree associate o la resilienza delle aree non abbinate.

  • Sfruttare il modulo di protezione hardware del cliente e caricare le chiavi in Azure Key Vault in AKV separati in più aree.

  • Utilizzare il Managed HSM e l'opzione di replica tra regioni.

    • Questa opzione consente al cliente di selezionare l'area desiderata in cui verranno replicate le chiavi.

Il diagramma seguente rappresenta una configurazione per l'area abbinata (primaria e secondaria) per un failover incrociato AKV con la configurazione di Azure SQL per la replica geografica usando un gruppo di failover:

Diagramma che mostra il supporto al failover tra regioni di Azure Key Vault per una regione abbinata.

Osservazioni di Azure Key Vault per Geo-DR

  • Sia i server primari che secondari in Azure SQL accedono a AKV nell'area primaria.

  • Il failover AKV viene avviato dal servizio AKV e non dal cliente.

  • In caso di failover di Azure Key Vault (AKV) nell'area secondaria, il server di Azure SQL può comunque accedere allo stesso AKV. Anche se a livello interno, la connessione AKV viene reindirizzata all'AKV nella regione secondaria.

  • Le nuove creazioni, le importazioni e le rotazioni delle chiavi sono possibili solo quando l'AKV nel primario è disponibile.

  • Quando si verifica il failover, la rotazione delle chiavi non è consentita fino a quando l'AKV nell'area primaria dell'area abbinata non è nuovamente accessibile.

  • Il cliente non può connettersi manualmente all'area secondaria.

  • L'AKV è in modalità di sola lettura mentre l'AKV nell'area primaria non è disponibile.

  • Il cliente non può scegliere né controllare in quale area si trova attualmente l'AKV.

  • Per l'area non abbinata, entrambi i server Azure SQL accedono all'AKV nella prima area (come indicato nel grafico) e l'AKV utilizza un'archiviazione con ridondanza della zona per replicare i dati all'interno dell'area, attraverso zone di disponibilità indipendenti della stessa area.

Per altre informazioni, vedere disponibilità e ridondanza di Azure Key Vault, coppie di aree di Azure e aree non abbinatee contratti di servizio per Azure Key Vault.

Osservazioni di Azure SQL per Geo-DR

  • Usare l'opzione zone-redundant di Azure SQL MI e Azure SQL DB per aumentare la resilienza. Per altre informazioni, vedere Che cosa sono le zone di disponibilità di Azure?.

  • Usare i gruppi di failover per Azure SQL MI e Azure SQL DB per il disaster recovery in una regione secondaria. Per ulteriori informazioni, vedere panoramica dei gruppi di failover, & procedure consigliate,.

  • La configurazione potrebbe richiedere una zona DNS più complessa se in Azure SQL vengono usati endpoint privati, ad esempio non è possibile creare due endpoint privati per la stessa risorsa nella stessa zona DNS.

  • Assicurarsi che le applicazioni sfruttano la logica di ripetizione dei tentativi.

Esistono diversi scenari in cui i clienti potrebbero voler scegliere una soluzione HSM (Managed Hardware Security Modules) su AKV:

  • Requisito di connessione manuale al caveau secondario.

  • Requisito di accesso in lettura alla cassaforte anche in caso di errore.

  • Flessibilità per scegliere l'area in cui viene replicato il materiale chiave

    • Richiede l'abilitazione della replica tra regioni che crea il secondo pool HSM gestito nella seconda regione.

  • L'uso del modulo di protezione hardware gestito consente ai clienti di creare una replica esatta di un HSM se l'originale è smarrito o non disponibile.

  • Utilizzo di HSM gestito per soddisfare i requisiti di sicurezza o regolamentazione.

  • Possibilità di eseguire il backup dell'intero insieme di credenziali rispetto al backup di singole chiavi.

Per ulteriori informazioni, vedere Abilitare la replica in più aree nel modulo di protezione hardware gestito di Azure e ripristino di emergenza nel modulo di protezione hardware gestito.

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 ulteriori informazioni sui Criteri di Azure, vedere Cos'è Criteri di Azure e Struttura della definizione 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 crittografare i dati a riposo
  • Le istanze gestite devono usare chiavi gestite dal cliente per crittografare i dati a riposo.

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 acquisirà solo un report di controllo nei log di attività dei 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 il criterio di Azure per il TDE gestito dal cliente è impostato su Nega, la creazione del server logico SQL di Azure o dell'istanza gestita non riuscirà. I dettagli di questo errore verranno registrati nel log attività del gruppo di risorse.

Importante

Le versioni precedenti dei criteri predefiniti per TDE gestiti dal cliente contenenti gli effetti AuditIfNotExist sono stati deprecati. Le assegnazioni di criteri esistenti che usano i criteri deprecati non sono interessate e continueranno a funzionare come prima.

Contenuto correlato