Modelli di crittografia dei dati
Comprendere i diversi modelli di crittografia, e i relativi vantaggi e svantaggi, è fondamentale per capire come i vari provider di risorse in Azure implementano la crittografia dei dati inattivi. Queste definizioni sono condivise tra tutti i provider di risorse in Azure per garantire un linguaggio e una tassonomia comuni.
Esistono tre scenari per la crittografia sul lato server:
Crittografia sul lato server con chiavi gestite dal servizio
- I provider di risorse di Azure eseguono le operazioni di crittografia e decrittografia
- Microsoft gestisce le chiavi
- Funzionalità cloud complete
Crittografia lato server con chiavi gestite dal cliente in Azure Key Vault
- I provider di risorse di Azure eseguono le operazioni di crittografia e decrittografia
- Il cliente controlla le chiavi tramite Azure Key Vault
- Funzionalità cloud complete
Crittografia lato server con chiavi gestite dal cliente su hardware controllato dal cliente
- I provider di risorse di Azure eseguono le operazioni di crittografia e decrittografia
- Il cliente controlla le chiavi su hardware controllato dal cliente
- Funzionalità cloud complete
I modelli di crittografia lato server fanno riferimento alla crittografia eseguita dal servizio di Azure. In questo modello, le operazioni di crittografia e decrittografia sono eseguite dal provider di risorse. Ad esempio, Archiviazione di Azure potrebbe ricevere dati in operazioni di testo normale ed eseguire internamente la crittografia e la decrittografia. Il provider di risorse potrebbe usare chiavi di crittografia gestite da Microsoft o dal cliente a seconda della configurazione specificata.
Ogni modello di crittografia dei dati inattivi lato server implica caratteristiche distintive della gestione delle chiavi, tra cui dove e come vengono create e archiviate le chiavi di crittografia, nonché i modelli di accesso e le procedure di rotazione delle chiavi.
Per la crittografia lato client, prendere in considerazione:
- I servizi di Azure non possono visualizzare i dati decrittografati
- I clienti mantengono e archiviano le chiavi in locale o in altri archivi sicuri. Le chiavi non sono disponibili per i servizi di Azure
- Funzionalità cloud ridotte
Come indicato in precedenza, i modelli di crittografia supportati in Azure sono suddivisi in due gruppi principali: "Crittografia client" e "Crittografia lato server". Indipendentemente dal modello di crittografia dei dati inattivi in uso, per i servizi di Azure è sempre consigliabile usare un trasporto protetto, ad esempio TLS o HTTPS. La crittografia a livello di trasporto deve quindi essere gestita dal protocollo di trasporto e non deve rappresentare un fattore determinante per la scelta del modello di crittografia dei dati inattivi da usare.
Modello di crittografia client
Il modello di crittografia client fa riferimento alla crittografia che viene eseguita all'esterno del provider di risorse o da Azure dal servizio o dall'applicazione chiamante. La crittografia può essere eseguita dall'applicazione del servizio in Azure o da un'applicazione in esecuzione nel data center del cliente. In entrambi i casi, quando si usa questo modello di crittografia, il provider di risorse di Azure riceve un BLOB crittografato di dati senza la possibilità di decrittografare i dati in alcun modo o avere accesso alle chiavi di crittografia. In questo modello la gestione delle chiavi viene eseguita dal servizio o dall'applicazione chiamante ed è opaca al servizio di Azure.
Crittografia lato server con chiavi gestite dal servizio
Per molti clienti, il requisito essenziale consiste nel garantire che i dati siano crittografati ogni volta che sono inattivi. La crittografia lato server tramite chiavi gestite dal servizio abilita questo modello consentendo ai clienti di contrassegnare la risorsa specifica (account di archiviazione, database SQL e così via) per la crittografia e lasciando tutti gli aspetti di gestione delle chiavi, ad esempio rilascio di chiavi, rotazione e backup in Microsoft. La maggior parte dei servizi di Azure che supportano la crittografia dei dati inattivi in genere supporta questo modello di offload della gestione delle chiavi di crittografia in Azure. Il provider di risorse di Azure crea le chiavi, le inserisce in un archivio protetto e le recupera quando necessario. Il servizio ha accesso completo alle chiavi e il servizio ha il controllo completo sulla gestione del ciclo di vita delle credenziali.
La crittografia sul lato server con chiavi gestite dal servizio consente pertanto di soddisfare rapidamente l'esigenza di implementare la crittografia dei dati inattivi con un sovraccarico limitato per il cliente. Quando disponibile, un cliente apre il portale di Azure per la sottoscrizione e il provider di risorse di destinazione e seleziona una casella per indicare che vuole che i dati vengano crittografati. In alcuni Resource Manager la crittografia lato server con chiavi gestite dal servizio è attivata per impostazione predefinita.
La crittografia sul lato server con chiavi gestite da Microsoft implica che il servizio ha accesso completo all'archiviazione e gestisce le chiavi. Anche se alcuni clienti potrebbero voler gestire le chiavi perché pensano di garantire una maggiore sicurezza, durante la valutazione di questo modello è importante tenere conto del costo e del rischio associato a una soluzione personalizzata di archiviazione delle chiavi. In molti casi, un'organizzazione può stabilire che i vincoli di risorse o i rischi di una soluzione locale potrebbero essere maggiori rispetto al rischio associato alla gestione nel cloud delle chiavi di crittografia dei dati inattivi. Questo modello, tuttavia, potrebbe non essere sufficiente per le organizzazioni che hanno l'esigenza di controllare la creazione o il ciclo di vita delle chiavi di crittografia oppure per fare in modo che la gestione delle chiavi di crittografia di un servizio venga eseguita da personale diverso da quello che gestisce il servizio (ad esempio, separando la gestione delle chiavi dal modello di gestione generale per il servizio).
Accesso alle chiavi
Quando si usa la crittografia sul lato server con chiavi gestite dal servizio, la creazione delle chiavi, l'archiviazione e l'accesso al servizio sono gestiti dal servizio. In genere, i provider di risorse di Azure fondamentali archiviano le chiavi di crittografia dei dati in un archivio vicino ai dati e sono rapidamente disponibili e accessibili, mentre le chiavi di crittografia delle chiavi vengono archiviate in un archivio interno sicuro.
Vantaggi
- Impostazione semplice
- Microsoft gestisce la rotazione, il backup e la ridondanza delle chiavi
- Il cliente non deve sostenere il costo associato all'implementazione o il rischio di uno schema di gestione delle chiavi personalizzato.
Svantaggi
- Nessun controllo del cliente sulle chiavi di crittografia (specifica della chiave, ciclo di vita, revoca e così via)
- Nessuna possibilità di separare la gestione delle chiavi dal modello generale di gestione per il servizio
Crittografia lato server con chiavi gestite dal cliente in Azure Key Vault e modulo di protezione hardware gestito di Azure
Per gli scenari in cui il requisito prevede di crittografare i dati inattivi e controllare le chiavi di crittografia, i clienti possono usare la crittografia sul lato server con chiavi gestite dal cliente in Azure Key Vault. Alcuni servizi potrebbero archiviare solo la chiave KEK radice in Azure Key Vault e archiviano la chiave DEK crittografata in un percorso interno più vicino ai dati. In questo scenario, i clienti possono usare le proprie chiavi nell'insieme di credenziali delle chiavi (BYOK, Bring Your Own Key) o generare nuove chiavi e usarle per crittografare le risorse desiderate. Mentre il provider di risorse esegue le operazioni di crittografia e decrittografia, usa la chiave di crittografia della chiave configurata come chiave radice per tutte le operazioni di crittografia.
Perdita di chiavi di crittografia della chiave significa perdita di dati. Per questo motivo, le chiavi non devono essere eliminate. È consigliabile eseguire il backup delle chiavi ogni volta che vengono create o ruotate. La protezione da eliminazione definitiva ed eliminazione temporanea deve essere abilitata in qualsiasi insieme di credenziali che archivia le chiavi di crittografia delle chiavi per proteggersi da cancellazione crittografica accidentale o dannosa. Anziché eliminare una chiave, è consigliabile impostare l'abilitato su false nella chiave di crittografia della chiave. Usare i controlli di accesso per revocare l'accesso a singoli utenti o servizi in Azure Key Vault o HSM gestito.
Nota
Per un elenco dei servizi che supportano le chiavi gestite dal cliente in Azure Key Vault e il modulo di protezione hardware gestito di Azure, vedere Servizi che supportano i cmk in Azure Key Vault e il modulo di protezione hardware gestito di Azure.
Accesso alle chiavi
Il modello di crittografia sul lato server con chiavi gestite dal cliente in Azure Key Vault prevede che il servizio di accesso alle chiavi possa eseguire la crittografia e la decrittografia in base alle esigenze. Le chiavi di crittografia inattive sono rese accessibili a un servizio tramite criteri di controllo di accesso. che concede all'identità del servizio l'accesso per ricevere la chiave. Un servizio di Azure in esecuzione per conto di una sottoscrizione associata può essere configurato con un'identità all'interno della sottoscrizione. Il servizio può eseguire l'autenticazione di Microsoft Entra e ricevere un token di autenticazione che si identifica come tale servizio che agisce per conto della sottoscrizione. Tale token può quindi essere presentato all'insieme di credenziali delle chiavi per ottenere una chiave a cui è stato concesso l'accesso.
Per le operazioni con chiavi di crittografia, può essere concesso l'accesso a un'identità del servizio per qualsiasi delle operazioni seguenti: decrypt, encrypt, unwrapkey, wrapkey, verify, sign, get, list, update, create, import, delete, backup e restore.
Per ottenere una chiave da usare per la crittografia o la decrittografia dei dati inattivi, l'identità del servizio con cui verrà eseguita l'istanza del servizio Resource Manager deve disporre di UnwrapKey (per ottenere la chiave per la decrittografia) e WrapKey (per inserire una chiave nell'insieme di credenziali delle chiavi al momento della creazione di una nuova chiave).
Nota
Per altri dettagli sull'autorizzazione dell'insieme di credenziali delle chiavi, vedere la pagina Proteggere l'insieme di credenziali delle chiavi nella documentazione di Azure Key Vault.
Vantaggi
- Controllo completo delle chiavi in uso: le chiavi di crittografia vengono gestite nell'insieme di credenziali delle chiavi del cliente, sotto il controllo del cliente.
- Possibilità di crittografare più servizi in uno master
- Possibilità di separare la gestione delle chiavi dal modello generale di gestione per il servizio
- Possibilità di definire il servizio e la posizione delle chiavi tra diverse aree geografiche
Svantaggi
- Il cliente ha la piena responsabilità per la gestione dell'accesso alle chiavi
- Il cliente ha la piena responsabilità per la gestione del ciclo di vita delle chiavi
- Sovraccarico aggiuntivo per l'installazione e la configurazione
Crittografia lato server con chiavi gestite dal cliente nell'hardware controllato dal cliente
Alcuni servizi di Azure consentono il modello di gestione delle chiavi HYOK (Host Your Own Key). Questa modalità di gestione è utile negli scenari in cui è necessario crittografare i dati inattivi e gestire le chiavi presenti in un repository proprietario al di fuori del controllo di Microsoft. In questo modello, il servizio deve usare la chiave da un sito esterno per decrittografare la chiave DEK (Data Encryption Key). Le garanzie di prestazioni e disponibilità sono interessate e la configurazione è più complessa. Inoltre, poiché il servizio non ha accesso alla chiave DEK durante le operazioni di crittografia e decrittografia, le garanzie di sicurezza complessiva di questo modello sono simili allo scenario in cui le chiavi sono gestite dal cliente in Azure Key Vault. Di conseguenza, questo modello non è appropriato per la maggior parte delle organizzazioni, a meno che non siano presenti specifici requisiti di gestione delle chiavi. A causa di queste limitazioni, la maggior parte dei servizi di Azure non supporta la crittografia lato server usando chiavi gestite dal cliente nell'hardware controllato dal cliente. Una delle due chiavi in crittografia a chiave doppia segue questo modello.
Accesso alle chiavi
Quando si usa la crittografia lato server tramite chiavi gestite dal cliente nell'hardware controllato dal cliente, le chiavi di crittografia della chiave vengono mantenute in un sistema configurato dal cliente. I servizi di Azure che supportano questo modello forniscono un sistema per stabilire una connessione sicura a un archivio delle chiavi fornito dal cliente.
Vantaggi
- Controllo completo della chiave radice in uso: le chiavi di crittografia vengono gestite tramite un archivio fornito dal cliente
- Possibilità di crittografare più servizi in uno master
- Possibilità di separare la gestione delle chiavi dal modello generale di gestione per il servizio
- Possibilità di definire il servizio e la posizione delle chiavi tra diverse aree geografiche
Svantaggi
- Piena responsabilità per l'archiviazione di chiavi, sicurezza, prestazioni e disponibilità
- Piena responsabilità per la gestione dell'accesso alle chiavi
- Piena responsabilità per la gestione del ciclo di vita delle chiavi
- Significativi costi di installazione, configurazione e manutenzione
- Maggiore dipendenza dalla disponibilità della rete tra il data center del cliente e i data center di Azure.