Crittografia dei dati trasparente Azure SQL con chiave gestita dal cliente

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 protezione Transparent Data Encryption (TDE), una chiave asimmetrica gestita dal cliente usata per proteggere la chiave dek (Database Encryption Key) viene archiviata in Azure Key Vault o nel modulo di protezione hardware gestito di Azure Key Vault. Si tratta di servizi di gestione delle chiavi sicuri e basati sul cloud progettati per la disponibilità elevata e la scalabilità. Azure Key Vault supporta le chiavi RSA e può essere supportato da moduli di protezione hardware convalidati FIPS 140-2 di livello 2. Per i clienti che richiedono una maggiore garanzia, il modulo di protezione hardware gestito di Azure Key Vault offre hardware convalidato FIPS 140-2 Livello 3. La chiave può essere generata nel servizio, importata o trasferita in modo sicuro da moduli di protezione hardware locali. L'accesso diretto alle chiavi è limitato: i servizi autorizzati eseguono operazioni di crittografia senza esporre il materiale della chiave.

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.

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 di Azure Key Vault può revocare le autorizzazioni di accesso alle chiavi per rendere il database crittografato inaccessibile.

• Gestione centrale delle chiavi in Azure Key Vault.

• Maggiore attendibilità dei clienti finali, poiché Azure Key Vault è progettato in modo che Microsoft non possa visualizzare né estrarre chiavi di crittografia.

Seleziona il tipo di Azure Key Vault che desideri utilizzare.

• La chiave di protezione TDE può essere solo una chiave asimmetrica, RSA o RSA HSM. Le lunghezze di chiave supportate sono 2.048 bit e 3.072 bit.

• 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 nel vault delle chiavi, assicurarsi che sia fornita in uno dei formati di file supportati: .pfx, .byok, o .backup. Per importare chiavi protette da HSM in HSM gestito di Azure, vedere Importare chiavi protette da HSM in HSM gestito (BYOK).

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

• Se la chiave viene generata nell'archivio delle chiavi, creare un backup della chiave prima di utilizzarla in Azure Key Vault per la prima volta. Il backup può essere ripristinato solo in Azure Key Vault. Altre informazioni sul comando Backup-AzKeyVaultKey. HSM gestito di Azure supporta la creazione di un backup completo dell'intero contenuto del modulo di protezione hardware, incluse tutte le chiavi, le versioni, gli attributi, i tag e le assegnazioni di ruolo. Per ulteriori informazioni, vedere Backup e ripristino completo e ripristino selettivo delle chiavi.

• 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 servizio di gestione delle chiavi o nel Modulo di Sicurezza Hardware gestito quando si ruotano le chiavi, in modo che sia possibile ripristinare i backup meno recenti del database. 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.

• Mantenere tutte le chiavi usate in precedenza in Azure Key Vault o nel modulo di protezione hardware gestito di Azure anche dopo il passaggio alle chiavi gestite dal servizio. Garantisce che i backup del database possano essere ripristinati con le protezioni TDE archiviate in Azure Key Vault o nel modulo di protezione hardware gestito di Azure. Le protezioni TDE create con Azure Key Vault o il modulo di protezione hardware gestito di Azure devono essere mantenute fino a quando non vengono creati tutti i backup archiviati rimanenti 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.

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 verificherà continuamente il Key Vault o il Managed HSM per qualsiasi nuova versione 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.

Quando utilizzato con la rotazione automatica delle chiavi in Azure Key Vault o con la rotazione automatica nel modulo di sicurezza hardware gestito di Azure, questa funzionalità consente una rotazione automatica completa senza intervento per il protettore TDE nel database SQL Azure e nell'istanza gestita SQL Azure.

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 o HSM gestito utilizzato 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 (sia essa assegnata dall'utente o dal sistema) possieda le autorizzazioni necessarie per il Vault delle chiavi del server primario o l'HSM gestito. Successivamente, il sistema proverà ad 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 di chiavi o modulo di protezione hardware gestito utilizzato con il server primario (e non un'altra chiave con lo stesso materiale di 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.

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 o nel modulo di protezione hardware gestito di Azure, fino a 10 minuti un database inizia a negare tutte le connessioni con il messaggio di errore corrispondente e modificarne lo stato in Inaccessibile. L'unica azione consentita in un database con stato Inaccessibile è l'eliminazione.

Se il database non è accessibile a causa di un'interruzione intermittente della rete (ad esempio un errore 5XX), non è necessaria alcuna azione, perché i database tornano online automaticamente. Per ridurre l'impatto degli errori di rete o delle interruzioni quando si accede alla protezione TDE in Azure Key Vault o nel modulo di protezione hardware gestito di Azure, è 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.

Se il server perde l'accesso alla protezione TDE gestita dal cliente in Azure Key Vault o nel modulo di protezione hardware gestito di Azure a causa di un errore di Azure Key Vault (ad esempio un errore 4XX), il database verrà spostato in uno stato inaccessibile dopo 30 minuti.

Dopo aver ripristinato l'accesso alla chiave, il ripristino online del database richiede tempo e passaggi aggiuntivi, che possono variare in base alla durata dell'indisponibilità della chiave e alle dimensioni dei dati all'interno del database.

Se l'accesso alla chiave viene ripristinato entro 30 minuti, il database verrà ripristinato automaticamente entro l'ora successiva. Tuttavia, se l'accesso alla chiave viene ripristinato dopo più di 30 minuti, la correzione automatica del database non è possibile. In questi casi, il ripristino del database comporta procedure aggiuntive tramite il portale di Azure e può richiedere molto tempo, a seconda delle dimensioni del database.

Quando il database è di nuovo online, le impostazioni a livello di server configurate in precedenza, incluse le configurazioni del gruppo di failover, i tag e le impostazioni a livello di database, ad esempio configurazioni del pool elastico, scalabilità in lettura, sospensione automatica, cronologia di ripristino temporizzato, criteri di conservazione a lungo termine e altri andranno persi. È quindi consigliabile che i clienti implementino un sistema di notifica per rilevare la perdita di accesso alla chiave di crittografia entro 30 minuti. Dopo la scadenza della 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.

Potrebbe verificarsi che un utente con diritti di accesso sufficienti per l'insieme delle credenziali della chiave o un modulo di protezione hardware gestito possa disabilitare accidentalmente l'accesso del server alla chiave tramite:

• revoca delle autorizzazioni get, wrapKey, unwrapKey dall'insieme di credenziali delle chiavi o dal modulo di protezione hardware gestito sul server

• eliminazione della chiave

• eliminazione dell'insieme di credenziali o dell'HSM gestito

• modifica delle regole del firewall dell'HSM gestito o dell'insieme di credenziali

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

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

Il blocco di connettività di rete tra l'Istanza di SQL gestita e il Key Vault o il modulo di protezione hardware (HSM) gestito si verifica principalmente quando esiste il Key Vault o la risorsa HSM gestita, ma non è possibile raggiungere il relativo endpoint dall'istanza gestita. Tutti gli scenari in cui è possibile raggiungere il servizio di gestione delle chiavi o l'endpoint HSM gestito, ma la connessione è negata o mancano le autorizzazioni, causeranno la modifica dello stato dei database a Inaccessibile.

Le cause più comuni della mancanza di connettività di rete ad Azure Key Vault o al modulo di protezione hardware gestito di Azure sono:

• Azure Key Vault o Azure Managed HSM viene esposto tramite endpoint privato e l'indirizzo IP privato del servizio Azure Key Vault o Azure Managed HSM non viene consentito nelle regole di uscita del gruppo di sicurezza di rete (NSG) associato alla subnet dell'istanza gestita.
• Risoluzione DNS non valida, ad esempio quando il key vault o il nome di dominio completo dell'HSM gestito non viene risolto o restituisce un indirizzo IP non valido.

Testare la connettività da SQL Managed Instance a Azure Key Vault o Azure Managed HSM che ospita il TDE protector.

• L'endpoint è il FQDN della tua vault, 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 outbound che copre l'indirizzo IP risolto sulla porta 443, soprattutto quando l'indirizzo risolto appartiene all'endpoint privato dell'insieme di credenziali delle chiavi o del managed HSM.
  • Controllare altre configurazioni di rete, ad esempio la tabella di percorso, l'esistenza dell'appliance virtuale e la relativa configurazione, ecc.

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 nell'accesso al protettore 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.

Dopo che un database viene crittografato con TDE usando una chiave di Azure Key Vault o HSM gestito di Azure, tutti i backup appena generati vengono crittografati 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 un protettore TDE tramite Azure Key Vault o Azure Managed HSM, assicurarsi che il materiale della chiave sia disponibile per il server di destinazione. È pertanto consigliabile mantenere tutte le versioni precedenti del protezione TDE nel Key Vault o nel modulo di protezione hardware gestito, in modo che sia possibile ripristinare i backup del database.

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 o nel modulo di protezione hardware gestito di Azure, questa chiave è necessaria in fase di ripristino, anche se il database è stato modificato per usare TDE gestito dal servizio nel frattempo.

Con Azure Key Vault o Azure Managed HSM che forniscono più livelli di ridondanza, i TDE che utilizzano una chiave gestita dal cliente possono avvantaggiarsi della disponibilità e della resilienza di Azure Key Vault o Azure Managed HSM, e fare completo affidamento sulla soluzione di ridondanza di Azure Key Vault o Azure Managed HSM.

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

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

• Replica dei dati
• Failover all'interno di un'area
• Failover tra regioni

La replica multiarea del modulo di protezione hardware gestito di Azure consente di estendere un pool di moduli di protezione hardware gestito di Azure da un'area di Azure (denominata area primaria) a un'altra area di Azure (denominata area estesa). Una volta configurate, entrambe le aree sono attive, in grado di gestire le richieste e, con la replica automatizzata, condividere lo stesso materiale chiave, ruoli e autorizzazioni. Per altre informazioni, vedere Abilitare la replica in più aree nel modulo di protezione hardware gestito di Azure.

In entrambi gli scenari di replica geografica attiva e gruppi di failover , i server primari e secondari coinvolti possono essere collegati all'insieme di credenziali delle chiavi di Azure o al modulo di protezione hardware gestito di Azure che si trova in qualsiasi area. Il server e l'archivio chiavi o l'HSM gestito non devono necessariamente essere collocati nella stessa regione. In questo modo, per semplicità, i server primari e secondari possono essere connessi allo stesso Key Vault o HSM gestito (in qualsiasi regione). Ciò consente di evitare scenari in cui il materiale criptografico potrebbe non essere sincronizzato se vengono usati insiemi di credenziali delle chiavi separati o gli HSM gestiti per entrambi i server. 

Azure Key Vault e Azure Managed HSM hanno più livelli di ridondanza per garantire che le chiavi e i Key Vault rimangano disponibili in caso di errori del servizio o dell'area. 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 insiemi di credenziali delle chiavi di Azure separati in più aree.

• Sfruttare il modulo di protezione hardware gestito di Azure e l'opzione di replica tra aree.

  • 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 di Azure Key Vault con la configurazione di Azure SQL per la replica geografica usando un gruppo di failover:

• Sia i server primari che secondari in Azure SQL accedono ad Azure Key Vault nell'area primaria.

• Il failover di Azure Key Vault viene avviato dal servizio Azure Key Vault e non dal cliente.

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

• Le creazioni di nuove chiavi, le importazioni e le rotazioni delle chiavi sono possibili solo quando l'Azure Key Vault primario è disponibile.

• Quando si verifica il failover, la rotazione delle chiavi non è consentita fino a quando l'Azure Key Vault nella regione primaria della regione associata non è nuovamente accessibile.

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

• L'Azure Key Vault è in modalità di sola lettura mentre Azure Key Vault nell'area primaria non è disponibile.

• Il cliente non può scegliere o controllare l'area in cui si trova il Key Vault di Azure.

• Per l'area non abbinata, entrambi i server SQL di Azure accedono ad Azure Key Vault nella prima area (come indicato nel grafico) e Azure Key Vault usa l'archiviazione con ridondanza della zona per replicare i dati all'interno dell'area, tra 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.

• 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,.

• Quando un database fa parte di gruppi di replica geografica o failover attivi e diventa inaccessibile, il piano di controllo SQL interrompe il collegamento e converte il database in un database autonomo. Dopo aver corretto le autorizzazioni della chiave, il database primario può in genere essere riportato online. Non è possibile riportare online il database secondario perché SQL di Azure non esegue backup completi per i database secondari in base alla progettazione. È consigliabile eliminare i database secondari e ristabilire il collegamento.

• 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 gestita di Azure su Azure Key Vault:

• 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 replicazione tra regioni, che crea il secondo pool HSM gestito di Azure nella seconda regione.

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

• Uso del modulo di protezione hardware gestito di Azure per i requisiti di sicurezza o normativi.

• 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.

È 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.

• Ruotare la protezione della cifratura dati trasparente per il database SQL
• 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
• Microsoft Defender per SQL