Customer-managed TDE for Azure Synapse Analytics

Si applica a: pool SQL dedicati di Azure Synapse Analytics (in precedenza SQL Data Warehouse)

Tip

Microsoft Fabric Data Warehouse è un data warehouse relazionale su scala aziendale su una base data lake, con un'architettura futura, un'intelligenza artificiale predefinita e nuove funzionalità. Se non si ha familiarità con il data warehousing, iniziare con Fabric Data Warehouse. I carichi di lavoro esistenti del pool SQL dedicated possono eseguire l'aggiornamento a Fabric per accedere a nuove funzionalità tra data science, analisi in tempo reale e creazione di report.

La crittografia trasparente dei dati (TDE) con chiave gestita dal cliente (CMK) consente lo scenario Bring Your Own Key (BYOK) per la protezione dei dati a riposo e consente alle organizzazioni di implementare la separazione dei compiti nella gestione di chiavi e dati. Utilizzando il TDE gestito dal cliente, ti assumi la responsabilità e hai il pieno controllo della gestione del ciclo di vita delle chiavi (creazione, caricamento, rotazione, cancellazione delle chiavi), dei permessi di utilizzo delle chiavi e dell'audit delle operazioni sulle chiavi.

In questo scenario, il protettore Transparent Data Encryption (TDE) è una chiave gestita dal cliente che protegge la Chiave di Cifratura del Database (DEK). Memorizzi il protettore TDE in Azure Key Vault o Azure Key Vault Managed HSM, che sono servizi di gestione delle chiavi sicuri basati su cloud progettati per alta disponibilità e scalabilità. Entrambi i servizi supportano chiavi crittografiche protette da hardware validato FIPS 140-2: Azure Key Vault supporta FIPS 140-2 Livello 2, e Azure Key Vault Managed HSM supporta FIPS 140-2 Livello 3. Entrambi i servizi supportano anche tipi di chiavi asimmetriche e simmetriche, e gli algoritmi supportati e l'uso dipendono dal modello di distribuzione TDE. Puoi generare la chiave nel servizio, importarla o trasferirla in modo sicuro dagli HSM on-premise. L'accesso diretto alle chiavi è limitato, quindi i servizi autorizzati eseguono operazioni crittografiche senza esporre il materiale delle chiavi.

Note

Questo articolo tratta i pool SQL dedicati standalone (precedentemente SQL DW).

  • Per i pool SQL dedicati di Azure Synapse Analytics (precedentemente SQL DW), imposta la protezione TDE a livello di server. Tutti i database criptati associati a quel server ereditano il protettore TDE.
  • Crittografa i dati in pool SQL dedicati e pool SQL serverless in uno spazio di lavoro Synapse utilizzando la chiave gestita dal cliente configurata a livello di workspace. Per ulteriori informazioni sulla crittografia dei dati trasparente per i pool SQL dedicati all'interno delle aree di lavoro di Synapse, consulta Crittografia di Azure Synapse Analytics.

Chiave gestita dal cliente (CMK) e Bring Your Own Key (BYOK)

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, inclusi la creazione, la rotazione e l'eliminazione della chiave. Memorizza la chiave in Azure Key Vault o Azure Managed HSM e usala per la crittografia della Chiave di Crittografia del Database (DEK).

  • Porta la tua chiave (BYOK) - Puoi portare o importare in modo sicuro la tua chiave da un modulo di sicurezza hardware (HSM) on-premises in 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).

Vantaggi di Transparent Data Encryption gestita dal cliente

Il TDE gestito dal cliente offre i seguenti vantaggi:

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

Importante

Per chi utilizza il TDE gestito dal servizio e vuole iniziare a usare il TDE gestito dal cliente, i dati rimangono criptati durante il processo di passaggio e non ci sono tempi di inattività o ri-crittografia dei file del 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.

Permessi per configurare il TDE gestito dal cliente in Azure Key Vault

Seleziona il tipo di Azure Key Vault che desideri utilizzare.

Affinché il server logico SQL in Azure possa utilizzare il protettore TDE memorizzato in Azure Key Vault per la crittografia del DEK, l'Amministratore Key Vault deve concedere diritti di accesso al server utilizzando la sua identità unica 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. 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à. L'identità del server richiede il ruolo Key Vault Crypto Service Encryption User per utilizzare la chiave nelle operazioni di crittografia e decrittazione.

  • 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 richiede i seguenti permessi sul vault delle chiavi:

    • get : per recuperare la parte pubblica e le proprietà della chiave in Azure Key Vault
    • wrapKey: per proteggere (crittografare) la chiave DEK
    • unwrapKey - per rimuovere la protezione (decrittografare) DEK

Nel menu del portale di Azure Configurazione di accesso dell’insieme delle chiavi, è possibile selezionare il controllo degli accessi in base al ruolo di Azure o i criteri di accesso all'insieme delle chiavi. Per istruzioni passo dopo passo su come configurare una configurazione di accesso Azure Key Vault per TDE, consulta Configura SQL Server TDE Extensible Key Management utilizzando 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 configuri un server per usare un protettore TDE di Azure Key Vault, il server invia il DEK di ogni database abilitato TDE al key vault per la crittografia. Il vault delle chiavi restituisce il DEK criptato, che il server memorizza nel database utente.

Quando necessario, il server invia il DEK protetto al vault delle chiavi per la decrittazione.

Gli auditor possono utilizzare Monitoraggio di Azure per esaminare i log di AuditEvent del key vault se il logging è abilitato.

Note

Potrebbero volerci circa 10 minuti perché eventuali modifiche ai permessi entrino in vigore per il Key Vault. Questo periodo include la revoca dei permessi di accesso al protettore TDE in AKV, e gli utenti potrebbero comunque avere i permessi di accesso.

Requisiti per configurare il TDE gestito dal cliente in Azure Key Vault

  • Abilita le funzionalità di soft-delete e protezione dall’eliminazione definitiva in Azure Key Vault. Questa configurazione aiuta a prevenire l'eliminazione accidentale o dolosa dell'insieme di credenziali delle chiavi o della chiave che possono portare il database a uno stato Inaccessible. Quando configuri il protettore TDE su un server esistente o durante la creazione del server, Azure SQL verifica che il Key Vault che stai usando abbia attivate l'eliminazione temporanea e la protezione dall'eliminazione definitiva. 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, abilita l'eliminazione temporanea e la protezione da eliminazione definitiva nell'insieme di credenziali delle chiavi, quindi esegui la configurazione del protettore TDE.

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

Requisiti principali per la configurazione della protezione TDE

Transparent Data Encryption con chiavi gestite dal cliente utilizza una chiave esterna, chiamata TDE protector, memorizzata in Azure Key Vault per proteggere la chiave di crittografia del database (DEK).

Si applicano i requisiti seguenti.

Tipi di chiavi e dimensioni supportati

La protezione TDE può essere protetta da chiavi asimmetriche memorizzate in Azure Key Vault. Le dimensioni delle chiavi supportate sono 2.048 bit e 3.072 bit.

Stato della chiave e requisiti di validità

  • Se specifichi una data di attivazione della chiave, impostala a una data e un'ora passate.
  • Se specifichi una data di scadenza della chiave, impostala a una data e un orario futuro.
  • La chiave deve avere lo stato Abilitato.

Requisiti di importazione delle chiavi

Se importi una chiave esistente in Azure Key Vault, fornisci la chiave in uno dei seguenti formati supportati:

  • .pfx
  • .byok
  • .backup

Raccomandazioni per configurare il TDE gestito dal cliente in Azure Key Vault

Per garantire un'elevata disponibilità ed evitare problemi di limitazione, seguire queste linee guida per ogni abbonamento:

  • Per garantire prestazioni e affidabilità ottimali, utilizza un Azure Key Vault dedicato per Azure SQL. Non condividere questo insieme di credenziali con altri servizi. Se il vault delle chiavi è sotto forte carico a causa dell'uso condiviso o di operazioni eccessive con le chiavi, può influire negativamente sulle prestazioni del database, specialmente durante l'accesso alle chiavi di crittografia. Azure Key Vault applica limiti di limitazione. Quando questi limiti vengono superati, le operazioni potrebbero essere posticipate o non superate. Questo rischio è più alto durante i failover del server, che attivano operazioni di chiave per ogni database presente nel server.

    Per maggiori informazioni sul comportamento del throttling, consulta la guida Azure Key Vault per il throttling.

    • Il numero di database Hyperscale che puoi associare a un singolo Azure Key Vault dipende dal numero di server di pagina. Ogni server di pagine è collegato a un file di dati logico. Per trovare il numero di server di pagina, esegui la seguente interrogazione.

      -- # of page servers (primary copies) for this database
SELECT COUNT(*) AS page_server_count
FROM sys.database_files
WHERE type_desc = 'ROWS';

      Non associare server di più di 500 pagine a un singolo Azure Key Vault. Man mano che il database aumenta, il numero di server di pagine aumenta automaticamente, quindi è importante monitorare regolarmente le dimensioni del database. Se il numero di server di pagine supera 500, usa un Azure Key Vault dedicato per ogni database Hyperscale e non condividere quel vault con altre risorse Azure SQL.

    • Monitorare e configurare gli avvisi di Azure Key Vault. Per maggiori informazioni su monitoraggio e allerta, consulta Monitora Azure Key Vault e Configura gli avvisi di Azure Key Vault.

  • 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. Per saperne di più sui blocchi di risorsa.

  • Abilitare il controllo e la creazione di report su tutte le chiavi di crittografia: Azure Key Vault fornisce log facili da inserire in altri strumenti di gestione degli eventi e informazioni di sicurezza. 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.

Suggerimenti per la configurazione della protezione TDE

  • Conserva una copia della chiave di protezione TDE in un luogo sicuro oppure depositala presso un servizio di deposito a garanzia.

  • Se generi la chiave in Key Vault, esegui un backup della chiave prima di usarla per la prima volta in Azure Key Vault. Puoi ripristinare il backup solo in un Azure Key Vault. Per saperne di più, consulta il comando Backup-AzKeyVaultKey . Azure Managed HSM supporta la creazione di un backup completo dell'intero contenuto dell'HSM, inclusi tutte le chiavi, versioni, attributi, tag e assegnazioni di ruoli. Per ulteriori informazioni, vedere Backup e ripristino completo e ripristino selettivo delle chiavi.

  • Crea un nuovo backup ogni volta che apporti modifiche alla chiave (ad esempio, attributi della chiave, tag, ACL).

  • Conserva le versioni precedenti della chiave nel vault o nell'HSM gestito quando ruoti le chiavi, così puoi ripristinare i backup del database più vecchi. Quando il protettore TDE cambia per un database, i vecchi backup del database non vengono aggiornati per usare l'ultimo protettore TDE. Al momento del ripristino, ogni backup richiede l'elemento di protezione TDE con cui è stato crittografato al momento della sua creazione. Per ruotare le chiavi, segui le istruzioni nell'articolo Ruota il protettore per la crittografia trasparente dei dati (TDE).

  • Conserva tutte le chiavi usate in precedenza in Azure Key Vault anche dopo il passaggio alle chiavi gestite dal servizio. Garantisce che i backup del database possano essere ripristinati con i protettori TDE memorizzati in Azure Key Vault. I protettori TDE creati con Azure Key Vault devono essere mantenuti finché tutti i backup memorizzati rimanenti non sono stati creati con chiavi gestite dal servizio. Realizza copie di backup recuperabili di queste chiavi utilizzando Backup-AzKeyVaultKey.

  • Per rimuovere una chiave potenzialmente compromessa durante un evento imprevisto di sicurezza senza il rischio di perdita di dati, seguire la procedura descritta nell'articolo Rimuovere una protezione TDE (Transparent Data Encryption) con PowerShell. Ruotare sempre verso una nuova protezione TDE e verificare che tutti i database usino la nuova chiave prima di eliminare o disabilitare la chiave compromessa. Eliminare o disabilitare la chiave senza prima ruotare rende inaccessibili tutti i database criptati e non invalida le copie della chiave precedentemente salvate e ripristinate in un altro vault.

Rotazione della protezione TDE

Quando ruoti il protettore TDE, sostituisci la chiave che protegge la chiave di crittografia del database (DEK). La rotazione delle chiavi è un'operazione online e richiede solo pochi secondi. Questa operazione decripta e ri-cripta solo la chiave di cifratura del database, non l'intero database.

Puoi ruotare la protezione TDE cambiando la configurazione per usare una nuova chiave memorizzata in Azure Key Vault. A seconda dell'offerta e della configurazione supportata, questa chiave può essere:

  • Passaggio a una nuova versione della stessa chiave
  • Passare a un'altra chiave

La rotazione del protettore TDE può essere effettuata manualmente o utilizzando la funzione di rotazione automatica.

Puoi abilitare la rotazione automatica del protettore TDE quando configuri il protettore TDE per il server. La rotazione automatica è disabilitata per impostazione predefinita. Quando è abilitato, il server controlla continuamente il Key Vault per verificare la presenza di nuove versioni della chiave usata come strumento di protezione TDE. Se il server rileva una nuova versione della chiave, ruota automaticamente il TDE protector sul server o database all'ultima versione della chiave entro 24 ore.

Note

Quando imposti TDE utilizzando una CMK mediante la rotazione manuale o automatizzata delle chiavi, usi sempre la versione più recente della chiave supportata dal sistema. 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.

Protezione TDE non accessibile

Quando configuri il TDE per utilizzare una chiave gestita dal cliente, il database necessita di un accesso continuo al protettore TDE per rimanere online. Se il server perde l'accesso al protettore TDE gestito dal cliente in Azure Key Vault, il database inizia a negare tutte le connessioni entro 10 minuti, mostra un messaggio di errore e cambia stato in Inaccessibile. L'unica azione consentita in un database con stato Inaccessibile è l'eliminazione.

Stato inaccessibile

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'effetto di errori di rete o interruzioni durante l'accesso al protettore TDE in Azure Key Vault, il servizio introduce un buffer di 24 ore prima di tentare 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 al protettore TDE gestito dal cliente in Azure Key Vault a causa di un errore di Azure Key Vault (come un errore 4XX), il database passa a uno stato inaccessibile dopo 30 minuti.

Ripristina l'accesso al database dopo un errore di Azure Key Vault

Dopo aver ripristinato l'accesso alla chiave, il ripristino online del database richiede tempi 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 viene 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 dei gruppi 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 vengono 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.

Revoca accidentale dell'accesso alla protezione TDE

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.

Connettività bloccata tra Istanza gestita di SQL e Azure Key Vault

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 l'insieme di credenziali delle chiavi o l'endpoint del modulo di protezione hardware gestito, 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 con Azure Key Vault sono:

  • Azure Key Vault viene esposto tramite endpoint privato e l'indirizzo IP privato del servizio Azure Key Vault non è consentito nelle regole in uscita del Network Security Group (NSG) associato alla subnet di 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.

Verifica la connettività da Istanza gestita di SQL a Azure Key Vault che ospita il protettore TDE.

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

Monitorare il TDE gestito 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 inaccessibile che ha perso l'accesso al protettore TDE appare come "Non disponibile" dopo che la prima connessione al database è stata negata.

  • Log attività quando si verifica un errore nell'accesso al protettore TDE nel Key Vault gestito dal cliente, vengono aggiunte voci al log attività. Creando avvisi per questi eventi, puoi ripristinare l'accesso il prima possibile.

  • I Gruppi d'Azione possono essere definiti per inviarti notifiche e avvisi in base alle tue preferenze, ad esempio Email, SMS, Push, Voice, Logic App, Webhook, ITSM o Automation Runbook.

Backup e ripristino del database con TDE gestito dal cliente

Una volta che un database è criptato con TDE utilizzando una chiave di Azure Key Vault, eventuali backup generati vengono anch'essi criptati con lo stesso protettore 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 criptato con un protettore TDE di Azure Key Vault, assicurati che il materiale della chiave sia disponibile per il server target. Pertanto, conserva tutte le vecchie versioni del protettore TDE in un key vault o in un HSM gestito, così i backup del database possono essere ripristinati.

Importante

Non è possibile impostare più protezioni TDE per un server in qualsiasi momento. La chiave contrassegnata con Rendi la chiave la protezione TDE predefinita nel riquadro del portale di Azure è la protezione TDE. Tuttavia, è possibile collegare più chiavi a un server senza contrassegnarle come protezione TDE. Queste chiavi non sono usate per proteggere il DEK, ma possono essere usate durante il ripristino da un backup se il file di backup è criptato con la chiave con la corrispondente impronta digitale.

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 aver ripristinato 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 pool dedicato di SQL in Azure Synapse Analytics, vedere Recuperare un pool dedicato 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 utilizza un protettore TDE memorizzato in Azure Key Vault, questa chiave è necessaria al momento del ripristino, anche se nel frattempo il database è stato modificato per utilizzare il TDE gestito dal servizio.

Disponibilità elevata con Transparent Data Management gestita dal cliente

Utilizzando i molteplici livelli di ridondanza di Azure Key Vault, i TDE che utilizzano una chiave gestita dal cliente possono beneficiare della disponibilità e della resilienza di Azure Key Vault. Possono fare pienamente affidamento sulla soluzione di ridondanza di Azure Key Vault.

I molteplici livelli di ridondanza di Azure Key Vault garantiscono l'accesso alle chiavi anche se i singoli componenti del servizio falliscono o se le regioni o le zone di disponibilità di Azure sono fuori uso. Per ulteriori informazioni, vedere Disponibilità e ridondanza di Azure Key Vault.

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

Contenuti correlati

  • Ultimo aggiornamento: