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 che viene eseguita dal servizio di Azure. In questo modello, le operazioni di crittografia e decrittografia sono eseguite dal provider di risorse. Archiviazione di Azure può ad esempio ricevere i dati in operazioni di testo normale ed esegue internamente la crittografia e la decrittografia. Il provider di risorse può usare chiavi di crittografia gestite da Microsoft o dal cliente, a seconda della configurazione specificata.

Server

Ognuno dei modelli di crittografia dei dati inattivi lato server implica caratteristiche distintive per la gestione delle chiavi. Questo include le posizioni e le modalità di creazione e archiviazione delle chiavi di crittografia, nonché i modelli di accesso e le procedure di rotazione delle chiavi.

Per la crittografia lato client, considerare quanto segue:

  • 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

I modelli di crittografia supportati in Azure sono suddivisi in due gruppi principali: "Crittografia client" e "Crittografia lato server", come indicato in precedenza. 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 di dati crittografato senza alcuna possibilità di decrittografare i dati 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.

Client

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 con chiavi gestite dal servizio abilita questo modello consentendo ai clienti di contrassegnare la risorsa specifica (account Archiviazione, SQL db e così via) per la crittografia e lasciare tutti gli aspetti della gestione delle chiavi, ad esempio il rilascio delle chiavi, la rotazione e il backup in Microsoft. La maggior parte dei servizi di Azure che supportano la crittografia dei dati in pausa supporta in genere 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 sicuro e le recupera quando necessario. Questo significa che il servizio ha l'accesso completo alle chiavi e il pieno controllo della gestione del ciclo di vita delle credenziali.

managed

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 manager delle risorse la crittografia lato server con chiavi gestite dal servizio è attiva 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. Tuttavia, questo modello potrebbe non essere sufficiente per le organizzazioni che hanno requisiti per controllare la creazione o il ciclo di vita delle chiavi di crittografia o per fare in modo che personale diverso gestisse le chiavi di crittografia di un servizio rispetto a quelle che gestiscono il servizio(ovvero, separazione della 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 principali provider di risorse di Azure archiviano le chiavi DEK in un archivio vicino ai dati e rapidamente disponibile e accessibile, mentre le chiavi KEK sono archiviate in un archivio interno protetto.

Vantaggi

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

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

La perdita di chiavi di crittografia delle chiavi comporta la 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 dall'eliminazione temporanea e dall'eliminazione deve essere abilitata in qualsiasi insieme di credenziali in cui sono archiviate le chiavi di crittografia delle chiavi per proteggersi da cancellazioni crittografiche accidentali o dannose. Invece di eliminare una chiave, è consigliabile impostare enabled su false per la chiave di crittografia della chiave.

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 per la crittografia dei dati inattivi vengono rese accessibili a un servizio tramite un criterio 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 Azure Active Directory e ricevere un token di autenticazione che lo identifica come un servizio che opera per conto della sottoscrizione. Il token può quindi essere presentato all'insieme di credenziali delle chiavi per ottenere una chiave a cui è stato consentito 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 sulle chiavi usate: le chiavi di crittografia vengono gestite nell'Key Vault 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 di configurazione & dell'installazione aggiuntivo

Crittografia lato server con chiavi gestite dal cliente in 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 in pausa e gestire le chiavi in un repository proprietario al di fuori del controllo di Microsoft. In questo modello il servizio deve recuperare la chiave da un sito esterno. Ciò ha effetto sulle garanzie di prestazioni e disponibilità e la configurazione risulta 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 server nell'hardware controllato dal cliente.

Accesso alle chiavi

Quando si usa la crittografia lato server con chiavi gestite dal servizio nell'hardware controllato dal cliente, le chiavi 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.

Servizi di supporto

I servizi di Azure che supportano ogni modello di crittografia:

Prodotto, funzionalità o servizio Lato server con chiave gestita dal servizio Server-Side tramite Customer-Managed chiave Client-Side tramite Client-Managed chiave
Intelligenza artificiale e Machine Learning
Ricerca cognitiva di Azure -
Servizi cognitivi di Azure -
Azure Machine Learning -
Content Moderator -
Viso -
Language Understanding -
Personalizza esperienze -
QnA Maker -
Servizi Voce -
Traduzione testuale -
Power BI Sì, RSA a 4096 bit -
Analisi
Analisi di flusso di Azure Sì** -
Hub eventi -
Funzioni -
Azure Analysis Services - -
Azure Data Catalog - -
Azure HDInsight Tutti -
Application Insights di Monitoraggio di Azure -
Monitoraggio di Azure Log Analytics -
Esplora dati di Azure -
Azure Data Factory -
Archivio Azure Data Lake Sì, RSA a 2048 bit -
Contenitori
Servizio Azure Kubernetes -
Istanze di Container -
Registro Container -
Compute
Macchine virtuali -
Set di scalabilità di macchine virtuali -
SAP HANA -
Servizio app Sì** -
Automazione Sì** -
Funzioni di Azure Sì** -
Portale di Azure Sì** -
App per la logica -
Applicazioni gestite da Azure Sì** -
Bus di servizio -
Site Recovery -
Database
SQL Server in macchine virtuali
database SQL di Azure Sì, RSA a 3072 bit
database SQL di Azure per MariaDB - -
database SQL di Azure per MySQL -
database SQL di Azure per PostgreSQL -
Azure Synapse Analytics Sì, RSA a 3072 bit -
SQL Server Stretch Database Sì, RSA a 3072 bit
Archiviazione tabelle
Azure Cosmos DB (altre informazioni) (altre informazioni) -
Azure Databricks -
Servizio Migrazione del database di Azure N/D* -
Identità
Azure Active Directory - -
Servizi di dominio Azure Active Directory -
Integrazione
Bus di servizio
Griglia di eventi - -
Gestione API - -
Servizi IoT
Hub IoT
Provisioning di dispositivi dell'hub IoT -
Gestione e governance
Azure Site Recovery - -
Azure Migrate -
Supporti
Servizi multimediali
Sicurezza
Microsoft Defender per IoT -
Microsoft Sentinel -
Storage
Archiviazione BLOB
Premium BLOB Archiviazione
Archiviazione su disco -
Archiviazione su disco Ultra -
Managed Disk Archiviazione -
Archiviazione file -
File Premium Archiviazione -
Sincronizzazione file -
Archiviazione code
Avere vFXT - -
Cache Redis di Azure N/D* -
Azure NetApp Files -
Spazio di archiviazione -
StorSimple
Backup di Azure
Data Box -
Data Box Edge -

* Questo servizio non rende persistenti i dati. Le eventuali cache temporanee vengono crittografate con una chiave Microsoft.

** Questo servizio supporta l'archiviazione di dati nel proprio Key Vault, nell'account Archiviazione o in un altro servizio di persistenza dei dati che supporta già Server-Side Encryption con Customer-Managed Key.

Passaggi successivi