Crittografia per le aree di lavoro di Azure Synapse Analytics
In questo articolo verrà illustrato quanto segue:
- Crittografia dei dati inattivi nelle aree di lavoro di Synapse Analytics.
- Configurazione delle aree di lavoro di Synapse per abilitare la crittografia con una chiave gestita dal cliente.
- Gestione delle chiavi usate per crittografare i dati nelle aree di lavoro.
Crittografia dei dati inattivi
Una soluzione completa di crittografia dei dati inattivi assicura che i dati non vengano mai salvati non crittografati in modo permanente. La doppia crittografia dei dati inattivi riduce le minacce con due livelli separati di crittografia, per proteggerli da compromissioni di qualsiasi livello singolo. Azure Synapse Analytics offre un secondo livello di crittografia per i dati presenti nell'area di lavoro, grazie a una chiave gestita dal cliente. Questa chiave viene protetta in Azure Key Vault, pertanto è possibile acquisire la proprietà della gestione e della rotazione delle chiavi.
Il primo livello di crittografia per i servizi di Azure è abilitato con chiavi gestite dalla piattaforma. Per impostazione predefinita, i dischi di Azure e i dati negli account di archiviazione di Azure vengono crittografati automaticamente se inattivi. Altre informazioni sull'uso della crittografia in Microsoft Azure sono disponibili nella Panoramica della crittografia di Azure.
Nota
Alcuni elementi considerati contenuto dei clienti, ad esempio nomi di tabella, nomi di oggetti e nomi di indice, potrebbero essere trasmessi nei file di resoconto per il supporto e la risoluzione dei problemi da parte di Microsoft.
Crittografia di Azure Synapse
In questa sezione si spiega in maggior dettaglio il modo in cui la crittografia della chiave gestita dal cliente viene abilitata e applicata nelle aree di lavoro di Synapse. Questa crittografia si avvale di chiavi esistenti o nuove generate in Azure Key Vault. Una singola chiave viene utilizzata per crittografare tutti i dati all'interno di un'area di lavoro. Le aree di lavoro di Synapse supportano le chiavi RSA da 2048 e 3072 byte, oltre che le chiavi RSA-HSM.
Nota
Le aree di lavoro di Synapse non supportano l'uso di chiavi EC, EC-HSM e oct-HSM per la crittografia.
I dati nei componenti di Synapse seguenti vengono crittografati con la chiave gestita dal cliente, configurata a livello di area di lavoro:
- Pool SQL
- Pool SQL dedicati
- Pool SQL serverless
- Pool di Esplora dati
- Pool di Apache Spark
- Runtime di integrazione, pipeline e set di dati di Azure Data Factory.
Configurazione della crittografia dell'area di lavoro
Le aree di lavoro possono essere configurate per abilitare la doppia crittografia con una chiave gestita dal cliente, al momento della creazione dell'area di lavoro. Abilitare la doppia crittografia tramite una chiave gestita dal cliente nella scheda "Sicurezza", al momento della creazione della nuova area di lavoro. È possibile scegliere di immettere un URI dell'identificatore della chiave, o selezionalo da un elenco di insiemi di credenziali delle chiavi nella stessa area dell'area di lavoro. L'insieme di credenziali delle chiavi deve avere la protezione dalla rimozione definitiva abilitata.
Importante
Dopo la creazione dell'area di lavoro, non è possibile modificare l’impostazione doppia crittografia della configurazione.
Accesso con chiave e attivazione dell'area di lavoro
Il modello di crittografia con chiavi gestite dal cliente in Azure Synapse, prevede che l'area di lavoro che accede alle chiavi in Azure Key Vault possa crittografare e la decrittografare in base alle esigenze. Le chiavi vengono rese accessibili per l'area di lavoro tramite i criteri di accesso o Controllo degli accessi in base al ruolo di Azure Key Vault. Quando si concedono le autorizzazioni tramite i criteri di accesso di Azure Key Vault, scegliere l'opzione "Solo applicazione" durante la creazione dei criteri (selezionare l'identità gestita dell'area di lavoro e non aggiungerla come applicazione autorizzata).
Per poter attivare l'area di lavoro, è necessario concedere all'identità gestita dell'area di lavoro le autorizzazioni necessarie per l'insieme di credenziali delle chiavi. Questo approccio a più fasi dell'attivazione dell'area di lavoro garantisce che i dati al suo interno vengano crittografati con la chiave gestita dal cliente. La crittografia può essere abilitata o disabilitata per singoli pool SQL dedicati. Per impostazione predefinita, il singolo pool dedicato non è abilitato per la crittografia.
Usare un'identità gestita assegnata dall'utente
Le aree di lavoro possono essere configurate per usare un'identità gestita assegnata dall'utente per accedere alla chiave gestita dal cliente archiviata in Azure Key Vault. Configurare un'identità gestita assegnata dall'utente per evitare l'attivazione a più fasi dell'area di lavoro di Azure Synapse se si utilizza la doppia crittografia con chiavi gestite dal cliente. Il ruolo predefinito di Collaboratore identità gestita è necessario per assegnare un'identità gestita assegnata dall'utente a un'area di lavoro di Azure Synapse.
Nota
Un'identità gestita assegnata dall'utente non può essere configurata per l'accesso alla chiave gestita dal cliente se Azure Key Vault è dietro a un firewall.
Autorizzazioni
Per crittografare o decrittografare i dati inattivi, l'identità gestita deve disporre delle autorizzazioni riportate di seguito. Analogamente, se si usa un modello di Resource Manager per creare una nuova chiave, il parametro 'keyOps' del modello deve avere le autorizzazioni seguenti:
- WrapKey (per inserire una chiave in Key Vault durante la creazione di una nuova chiave).
- UnwrapKey (per ottenere la chiave per decrittografia).
- Get (per leggere la parte pubblica di una chiave)
Attivazione dell'area di lavoro
Se non si configura un'identità gestita assegnata dall'utente per accedere alle chiavi gestite dal cliente, durante la creazione dell'area di lavoro, l'area di lavoro rimarrà nello stato "In sospeso" fino ad attivazione riuscita. L'area di lavoro deve essere attivata prima di poter utilizzare completamente tutte le funzionalità. Ad esempio, è possibile creare un nuovo pool SQL dedicato solo dopo aver completato l'attivazione. Concedere all'identità gestita dell'area di lavoro l'accesso all'insieme di credenziali delle chiavi e selezionare il collegamento di attivazione nel banner del portale di Azure dell'area di lavoro. Una volta completata l'attivazione, l'area di lavoro è pronta per l'uso e garantisce che tutti i dati al suo interno siano protetti con la chiave gestita dal cliente. Come indicato in precedenza, l'insieme di credenziali delle chiavi deve avere la protezione di ripulitura abilitata affinché l'attivazione venga completata.
Gestire la chiave gestita dal cliente dell'area di lavoro
È possibile modificare la chiave gestita dal cliente usata per crittografare i dati dalla pagina Crittografia nel portale di Azure. Anche in questo caso, è possibile scegliere una nuova chiave usando un identificatore chiave o selezionarla dall'insieme di credenziali delle chiavi al quale si può accedere nella stessa area dell'area di lavoro. Se si sceglie una chiave in un insieme di credenziali delle chiavi diverso da quelli usati in precedenza, concedere all'identità gestita dall'area di lavoro le autorizzazioni "Get", "Wrap" e "Unwrap" per il nuovo insieme di credenziali delle chiavi. L'area di lavoro convaliderà l'accesso al nuovo insieme di credenziali delle chiavi e tutti i dati presenti nell'area di lavoro verranno crittografati di nuovo con la nuova chiave.
Importante
Quando si modifica la chiave di crittografia di un'area di lavoro, mantenere la chiave precedente fino a sostituirla nell'area di lavoro con una nuova chiave. Ciò consente la decrittografia dei dati con la chiave precedente prima che venga crittografata nuovamente con la nuova chiave. Lo stato del pool SQL (online/offline) non influisce sul processo di rotazione della chiave gestita dal cliente dell'area di lavoro.
I pool SQL offline durante la rotazione della chiave cmk rimarranno crittografati con la chiave o la versione precedente della chiave. Se la chiave o la versione della chiave precedente è disabilitata o scaduta, i pool non riprenderanno perché la decrittografia non è possibile. Al momento della ripresa di questi pool, la chiave o la versione precedente della chiave deve essere 1) essere abilitata e 2) avere una data di scadenza impostata in futuro per consentire la decrittografia e la successiva ricrittografia con la nuova chiave o versione della chiave.
Per garantire una rotazione uniforme della chiave cmk, se alcuni pool SQL sono offline durante il processo, la versione precedente della chiave o della chiave deve rimanere abilitata e impostare la data di scadenza in futuro. Questo è fondamentale fino a quando i pool offline non vengono ripresi e crittografati nuovamente con la nuova chiave o la nuova versione della chiave.
È consigliabile non eliminare chiavi o versioni chiave precedenti, perché potrebbero essere ancora necessarie per decrittografare i backup. Al contrario, dopo che tutti i pool SQL sono stati ricrittografati con la nuova chiave o versione della chiave, disabilitare la versione precedente della chiave o della chiave. In questo modo, la versione precedente della chiave o della chiave rimane disponibile per decrittografare i backup meno recenti, se necessario.
I criteri di Azure Key Vault per la rotazione automatica, periodica delle chiavi o delle azioni sulle chiavi, possono comportare la creazione di nuove versioni delle chiavi. È possibile scegliere di crittografare di nuovo tutti i dati nell'area di lavoro con la versione più recente della chiave attiva. Per crittografare di nuovo, modificare la chiave nel portale di Azure in una chiave temporanea e quindi tornare alla chiave che si vuole usare per la crittografia. Ad esempio, per aggiornare la crittografia dei dati con la versione più recente della chiave attiva Key1, modificare la chiave gestita dal cliente dell'area di lavoro come chiave temporanea, Key2. Attendere il completamento della crittografia con Key2. Quindi, commutare la chiave gestita dal cliente dell'area di lavoro di nuovo su Key1-data nell'area di lavoro e verrà crittografata di nuovo con la versione più recente di Key1.
Nota
Azure Synapse Analytics non crittografa automaticamente i dati quando vengono create nuove versioni delle chiavi. Per garantire coerenza nell'area di lavoro, forzare la nuova crittografia dei dati mediante il processo descritto in precedenza.
SQL Transparent Data Encryption con chiavi gestite dal servizio
TDE (Transparent Data Encryption) SQL è disponibile per i pool SQL dedicati nelle aree di lavoro non abilitate per la doppia crittografia. In questo tipo di area di lavoro viene usata una chiave gestita dal servizio per eseguire la doppia crittografia dei dati nei pool SQL dedicati. TDE con la chiave gestita dal servizio può essere abilitato o disabilitato per i singoli pool SQL dedicati.
Cmdlet per il database SQL di Azure e Azure Synapse
Per configurare TDE tramite PowerShell è necessario essere connessi come proprietario, collaboratore o Gestore Sicurezza SQL di Azure.
Usare i cmdlet seguenti per l'area di lavoro di Azure Synapse.
| Cmdlet | Descrizione |
|---|---|
| Set-AzSynapseSqlPoolTransparentDataEncryption | Abilita o disabilita TDE per un pool SQL. |
| Get-AzSynapseSqlPoolTransparentDataEncryption | Ottiene lo stato TDE per un pool SQL. |
| New-AzSynapseWorkspaceKey | Aggiunge una chiave di Key Vault a un'area di lavoro. |
| Get-AzSynapseWorkspaceKey | Ottiene le chiavi dell'insieme di credenziali delle chiavi per un'area di lavoro |
| Update-AzSynapseWorkspace | Imposta la protezione Transparent Data Encryption per un'area di lavoro. |
| Get-AzSynapseWorkspace | Ottiene la protezione TDE |
| Remove-AzSynapseWorkspaceKey | Rimuove una chiave di Key Vault da un'area di lavoro. |