Raccomandazioni per la crittografia dei dati

Articolo
02/05/2024

Si applica a Well-Architected Framework Security Checklist recommendation (Elenco di controllo per la sicurezza di Well-Architected Framework):

SE:07	Crittografare i dati usando metodi moderni standard del settore per proteggere la riservatezza e l'integrità. Allineare l'ambito di crittografia alle classificazioni dei dati; assegnare priorità ai metodi di crittografia della piattaforma nativa.

Se i dati non sono protetti, possono essere modificati in modo dannoso, il che comporta la perdita di integrità e riservatezza.

Questa guida descrive le raccomandazioni per crittografare e proteggere i dati. La crittografia è il processo di utilizzo degli algoritmi di crittografia per rendere i dati illeggibili e bloccare i dati con una chiave. Nello stato crittografato non è possibile decifrare i dati. Può essere decrittografata solo usando una chiave associata alla chiave di crittografia.

Definizioni

Termini	Definizione
Certificati	File digitali che contengono le chiavi pubbliche per la crittografia o la decrittografia.
Suite di crittografia	Set di algoritmi usati per crittografare e decrittografare le informazioni per proteggere una connessione di rete tramite Transport Layer Security (TLS).
Confidential computing	Confidential Computing è la protezione dei dati in uso eseguendo il calcolo in un ambiente di esecuzione attendibile basato su hardware.
Decrittografia	Processo in cui i dati crittografati vengono sbloccati con un codice segreto.
Crittografia doppia	Processo di crittografia dei dati usando due o più livelli indipendenti di crittografia.
Crittografia	Processo in base al quale i dati vengono resi illeggibili e bloccati con un codice segreto.
Hashing	Processo di trasformazione dei dati in testo o numeri con la finalità di nascondere le informazioni.
Chiavi	Codice segreto usato per bloccare o sbloccare i dati crittografati.
Firma	Timbro crittografato dell'autenticazione sui dati.
per la firma	Processo di verifica dell'autenticità dei dati tramite una firma.
X.509	Standard che definisce il formato dei certificati a chiave pubblica.

Strategie di progettazione chiave

I obblighi dell'organizzazione o i requisiti normativi potrebbero imporre meccanismi di crittografia. Ad esempio, potrebbe essere necessario che i dati rimangano solo nell'area selezionata e che le copie dei dati vengano mantenute in tale area.

Questi requisiti sono spesso il minimo di base. Cercare un livello di protezione superiore. L'utente è responsabile della prevenzione delle perdite di riservatezza e della manomissione dei dati sensibili, indipendentemente dal fatto che si tratti di dati utente esterni o dei dipendenti.

Scenari di crittografia

È probabile che i meccanismi di crittografia debbano proteggere i dati in tre fasi:

I dati inattivi sono tutte le informazioni mantenute negli oggetti di archiviazione.

Un esempio di protezione dei dati inattivi consiste nell'usare BitLocker per crittografare i dati salvati nell'archiviazione su un disco.
I dati in transito sono informazioni trasferite tra componenti, posizioni o programmi.

Un esempio di protezione dei dati in transito è la crittografia dei dati con TLS, in modo che i pacchetti che si spostano su reti pubbliche e private siano protetti.
I dati in uso sono dati su cui si sta lavorando attivamente in memoria.

Un esempio di protezione dei dati in uso è la crittografia con confidential computing per proteggere i dati durante l'elaborazione.

Le scelte precedenti non si escludono a vicenda. Vengono spesso usati insieme nel contesto dell'intera soluzione. Una fase può fungere da controllo di compensazione. Ad esempio, potrebbe essere necessario isolare i dati per evitare manomissioni quando i dati sono letti dalla memoria.

Ambito della crittografia

Classificare i dati in base allo scopo e al livello di riservatezza per determinare quali dati è necessario crittografare. Per i dati che devono essere crittografati, determinare il livello di protezione richiesto. È necessaria la crittografia TLS end-to-end per tutti i dati in transito? Per i dati inattivi, quali funzionalità di Azure possono soddisfare i requisiti? È necessario crittografare due volte i dati in ogni punto di archiviazione? Come si implementa la protezione delle informazioni?

È importante bilanciare le decisioni di crittografia perché esistono compromessi significativi.

Compromesso: ogni hop di crittografia può introdurre latenza delle prestazioni. Le complessità operative possono verificarsi in relazione alla risoluzione dei problemi e all'osservabilità. Il ripristino può essere una sfida.

Definire l'ambito di questi compromessi. Prevedere i compromessi per i dati classificati come sensibili. I requisiti possono anche determinare i compromessi, ad esempio se un determinato tipo di dati deve essere crittografato e archiviato entro determinate soglie.

Esistono casi in cui la crittografia non è possibile a causa di limitazioni tecniche, investimenti o altri motivi. Assicurarsi che questi motivi siano chiari, validi e documentati.

I meccanismi di crittografia avanzata non devono essere l'unica forma di difesa. Implementare processi di prevenzione del furto dei dati, metodi di test appropriati e rilevamento anomalie.

Per informazioni sulla classificazione, vedere Raccomandazioni sulla classificazione dei dati.

Meccanismi di crittografia nativa

La maggior parte dei servizi di Azure offre un livello di crittografia di base. Esplorare le opzioni di crittografia fornite dalla piattaforma.

È consigliabile non disabilitare le funzionalità della piattaforma per sviluppare funzionalità personalizzate. Le funzionalità di crittografia della piattaforma usano standard di settore moderni, sono sviluppate da esperti e sono altamente testate.

Per rari casi, se è necessario sostituire la crittografia fornita dalla piattaforma, valutare i vantaggi e i contro e usare algoritmi di crittografia standard del settore.

Gli sviluppatori devono usare le API di crittografia integrate nel sistema operativo anziché librerie di crittografia nonpiattaforma. Per .NET, seguire il modello di crittografia .NET.

Chiavi di crittografia

Per impostazione predefinita, i servizi di Azure usano chiavi di crittografia gestite da Microsoft per crittografare e decrittografare i dati. Azure è responsabile della gestione delle chiavi.

È possibile scegliere chiavi gestite dal cliente. Azure usa ancora le chiavi, ma è possibile tenere conto delle operazioni chiave. È possibile modificare le chiavi quando si desidera. La decrittografia è un motivo interessante per usare chiavi gestite dal cliente.

È consigliabile associare la crittografia avanzata con la decrittografia avanzata. Dal punto di vista della sicurezza, la protezione di una chiave di decrittografia è importante perché la rotazione è un modo comune per controllare il raggio dell'esplosione se una chiave viene compromessa. Monitorare l'accesso per rilevare l'accesso anomalo e le attività.

Archiviare le chiavi separate dai dati crittografati. Questo disaccoppiamento consente di garantire che la compromissione di un'entità non influisca sull'altra. Se si usano chiavi gestite dal cliente, archiviarle in un archivio chiavi. Archiviare dati altamente sensibili in un modulo di protezione hardware gestito.

Entrambi gli archivi sono protetti con accesso basato sull'identità. Questa funzionalità consente di negare l'accesso, anche alla piattaforma.

Algoritmi di crittografia standard

Usare algoritmi di crittografia ben definiti e conformi agli standard di settore anziché creare implementazioni personalizzate.

Gli standard del settore per gli algoritmi richiedono schemi di crittografia per avere un determinato livello di entropia. Le origini entropia vengono inserite durante la crittografia. Entropy rende l'algoritmo sicuro e rende difficile l'estrazione di informazioni da parte di un utente malintenzionato. Determinare le soglie tollerabili dell'entropia. Le procedure di crittografia sono a elevato utilizzo del processore. Trovare il giusto equilibrio in modo da ottimizzare i cicli di calcolo che vengono impiegato per la crittografia, rispetto alle destinazioni di prestazioni complessive della richiesta di calcolo.

Compromesso: se si sceglie un algoritmo che è altamente complesso o inserisce più di una quantità ragionevole di entropia, riduce le prestazioni del sistema.

Hash e checksum

In genere, l'hashing è una tecnica di rilevamento degli errori. È anche possibile usare l'hashing per la sicurezza perché rileva le modifiche ai dati che potrebbero essere causati da manomissione. Le funzioni hash si basano sulla crittografia, ma non usano chiavi. Le funzioni hash usano algoritmi per produrre checksum. I checksum possono confrontare i dati per verificare l'integrità.

Le applicazioni devono usare la famiglia SHA-2 di algoritmi hash, ad esempio SHA-256, SHA-384 o SHA-512.

Dati inattivi

Classificare e proteggere gli oggetti di archiviazione delle informazioni in conformità ai requisiti di conformità interni ed esterni. Vedere i consigli seguenti:

Crittografare i dati usando le opzioni native fornite per i servizi di archiviazione, gli archivi dati e altre risorse usate per rendere persistenti i dati. Crittografare questi dati anche se si archiviano dati in questi servizi di archiviazione o risorse solo temporaneamente. Crittografare anche i dati di backup per mantenere lo stesso livello di sicurezza dell'origine originale.

Per altre informazioni, vedere Protezione dei dati inattivi.
Usare la doppia crittografia. Se i requisiti aziendali richiedono una maggiore garanzia, è possibile eseguire la doppia crittografia. Crittografare i dati in due o più livelli usando chiavi gestite dal cliente indipendenti. Archiviare i dati in un modulo di protezione hardware gestito. Per leggere i dati, è necessario accedere a entrambe le chiavi. Se una chiave è compromessa, l'altra chiave protegge comunque i dati. Questa tecnica mira ad aumentare i costi degli utenti malintenzionati.

È anche possibile usare la crittografia fornita dalla piattaforma per crittografare doppiamente i dati. La crittografia fornita dalla piattaforma protegge i supporti di archiviazione a livello di infrastruttura e si applica un altro livello di crittografia a livello di dati. Ad esempio, un servizio message broker ha la crittografia fornita dalla piattaforma tramite chiavi gestite da Microsoft che protegge la pipe dei messaggi. Questo metodo consente di crittografare i messaggi con chiavi gestite dal cliente.

Usare più di una chiave di crittografia. Usare una chiave di crittografia delle chiavi (KEK) per proteggere la chiave di crittografia dei dati (DEK).
Usare i controlli di accesso basati su identità per controllare l'accesso ai dati. Aggiungere firewall di rete per fornire un livello aggiuntivo di sicurezza che blocca l'accesso imprevisto e non sicuro.

Per altre informazioni, vedere Raccomandazioni per la gestione delle identità e degli accessi.
Archiviare le chiavi in un modulo di protezione hardware gestito con il controllo di accesso con privilegi minimi. Separare i dati dalle chiavi ai dati.
Archiviare una quantità limitata di dati in modo che si crittografi solo ciò che è necessario. I dati non devono vivere più a lungo del ciclo di crittografia. Quando i dati non sono più necessari, eliminare i dati crittografati senza decrittografare i cicli di decrittografia.

Dati in transito

Usare protocolli sicuri per la comunicazione client-server. I protocolli di trasporto hanno un livello predefinito di sicurezza. TLS è lo standard del settore per lo scambio di dati tra endpoint client e server.

Non usare versioni inferiori a TLS 1.2. Eseguire la migrazione delle soluzioni per supportare TLS 1.2 e usare questa versione per impostazione predefinita. Tutti i servizi di Azure supportano TLS 1.2 sugli endpoint HTTPS pubblici.

Rischio: i client meno recenti che non supportano TLS 1.2 potrebbero non funzionare correttamente se la compatibilità con le versioni precedenti non è supportata.

Tutte le comunicazioni del sito Web devono usare HTTPS, indipendentemente dalla riservatezza dei dati trasferiti. Durante un handshake del server client, negoziare l'uso dei criteri HSTS (HTTP Strict Transport Security) in modo che il trasporto HTTPS venga mantenuto e non venga abbandonato a HTTP durante la comunicazione. Questo criterio protegge dagli attacchi man-in-the-middle.

Il supporto per HSTS è per le versioni più recenti. È possibile interrompere la compatibilità con le versioni precedenti con i browser meno recenti.

Nota

È anche possibile crittografare i protocolli per stabilire connessioni sicure per i database. Ad esempio, Azure SQL Database supporta il protocollo TDS (Tabular Data Stream), che integra un handshake TLS.

Una suite di crittografia è un set di algoritmi usati per standardizzare l'handshake tra il client e il server. Le crittografia garantiscono che lo scambio sia crittografato ed autenticato. La scelta di crittografia dipende dalla versione TLS usata dal server. Per alcuni servizi, ad esempio gateway applicazione di Azure, è possibile scegliere la versione di TLS e le suite di crittografia che si desidera supportare. Implementare suite di crittografia che usano Advanced Encryption Standard (AES) come crittografia a blocchi simmetrici. AES-128, AES-192 e AES-256 sono accettabili.
Gestire il ciclo di vita dei certificati. I certificati hanno una durata predeterminata. Non mantenere certificati di lunga durata e non lasciarli scadere autonomamente. Implementare un processo che rinnova i certificati a una frequenza accettabile. È possibile automatizzare il processo per i rinnovi che si verificano a intervalli brevi.

Nota

Se si usa l'aggiunta del certificato, acquisire familiarità con le limitazioni di agilità e gestione dei certificati.

Il flusso di lavoro non deve consentire l'accettazione di certificati non validi nell'ambiente. Il processo di aggiunta del certificato deve convalidare i certificati e applicare tale controllo di convalida. È necessario monitorare i log di accesso per assicurarsi che la chiave di firma venga usata con autorizzazioni appropriate.

Se una chiave viene compromessa, il certificato deve essere revocato immediatamente. Un'autorità di certificazione (CA) fornisce un elenco di revoche di certificati (CRL) che indica i certificati non validi prima della scadenza. Il controllo di convalida deve essere accountato per gli elenchi di controllo dei certificati.

Compromesso: il processo di convalida della certificazione può essere complesso e in genere comporta una CA. Determinare i dati che è necessario crittografare con i certificati. Per altri tipi di comunicazione, determinare se è possibile implementare controlli di compensazione localizzati per aggiungere sicurezza.

Un modo per localizzare i controlli è con TLS reciproca (mTLS). Stabilisce l'attendibilità in entrambe le direzioni tra il client e il server. Sia il client che il server hanno certificati personalizzati e ogni certificato viene autenticato con la coppia di chiavi pubblica o privata. Con mTLS non si dipende dalla CA esterna. Il compromesso è la complessità aggiunta della gestione di due certificati.
Crittografare doppiamente le connessioni VPN se necessario. Eseguire la doppia crittografia per aggiungere la difesa in profondità al tunnel VPN. Quando si usano due server VPN, è possibile nascondere l'indirizzo IP tra i server e nascondere anche l'indirizzo IP tra il server e la destinazione. Durante questo processo, i dati in transito vengono crittografati due volte.

Compromesso: rispetto alle singole configurazioni VPN, le configurazioni VPN doppie sono spesso più costose e le connessioni sono spesso più lente.
Implementare processi di registrazione e monitoraggio. Tenere traccia delle risorse di accesso che archiviano informazioni sui client, ad esempio l'IP di origine, la porta e il protocollo. Usare queste informazioni per rilevare anomalie.

Utilizzo dei dati

Per carichi di lavoro con sicurezza elevata, segmentazione, isolamento e privilegi minimi sono i modelli di progettazione consigliati.

Nel contesto della protezione in uso, i limiti hardware possono richiedere la crittografia dei dati mentre è in uso nella CPU fisica e nella memoria per garantire l'isolamento delle macchine virtuali, il codice di gestione host e altri componenti.

La crittografia e la decrittografia dei dati devono essere eseguite solo all'interno di tali limiti di isolamento.

I requisiti di sicurezza o normative più rigorosi possono richiedere anche prove basate su hardware, con firma crittografica che i dati vengono crittografati durante l'uso, questo può essere ottenuto tramite attestazione.

L'uso di misure di sicurezza e privacy moderne è un requisito comune per i carichi di lavoro normativi. Il calcolo riservato è una tecnologia di questo tipo che supporta il requisito. Servizi specifici in Azure offrono la possibilità di proteggere i dati durante il calcolo. Per altre informazioni, vedere Facilitazione di Azure: Calcolo riservato di Azure.

Prendere in considerazione il ciclo di vita end-end dei dati che si stanno proteggendo spesso attraverso più sistemi nella sua durata, prestare attenzione a garantire che tutte le parti dei componenti di una soluzione possano fornire i livelli di protezione necessari o assicurarsi che la strategia di gestione dei dati fornisca segmentazione o maschera appropriata.

Facilitazione di Azure

Le sezioni seguenti descrivono i servizi e le funzionalità di Azure che è possibile usare per crittografare i dati.

Chiavi gestite dal cliente

Archiviare le chiavi gestite dal cliente in Azure Key Vault o in un HSM gestito da Key Vault.

Key Vault tratta le chiavi come qualsiasi altro segreto. I controlli di accesso in base al ruolo di Azure accedono alle chiavi tramite un modello di autorizzazione. Questo controllo basato su identità deve essere usato con i criteri di accesso Key Vault.

Per altre informazioni, vedere Fornire l'accesso alle chiavi, ai certificati e ai segreti Key Vault tramite controllo degli accessi in base al ruolo.

Azure Key Vault Premium e Managed-HSM migliora ulteriormente l'offerta includendo funzionalità di calcolo riservate e versione della chiave sicura che supporta un criterio per garantire che una chiave venga mai rilasciata a un carico di lavoro che possa dimostrare in modo crittografico che è in esecuzione all'interno di un ambiente di esecuzione attendibile (TEE).

Protezione dei dati inattivi

Archiviazione di Azure crittografa automaticamente i dati con crittografia a blocchi quando i dati vengono mantenuti in un account di archiviazione. Per Archiviazione BLOB di Azure e Archiviazione code di Azure, l'archiviazione offre anche la crittografia lato client tramite librerie.

Per altre informazioni, vedere Crittografia dell'archiviazione.
Azure Macchine virtuali dispone di file di disco che fungono da volumi di archiviazione virtuale. È possibile crittografare i file del disco virtuale in modo che il contenuto non possa essere accessibile.

I dischi gestiti possono essere esportati dal portale. La crittografia e la crittografia lato server nell'host possono proteggere i dati solo dopo l'esportazione. Tuttavia, è necessario proteggere i dati durante il processo di esportazione. È possibile usare Crittografia dischi di Azure per proteggere e proteggere i dati durante il processo di esportazione.

Azure offre diverse opzioni di crittografia per i dischi gestiti. Per altre informazioni, vedere Panoramica delle opzioni di crittografia dei dischi gestiti.
database SQL offre una funzionalità di crittografia dei dati trasparente usata per crittografare un file di database a livello di pagina.

Protezione dei dati in transito

Con Key Vault è possibile effettuare il provisioning, gestire e distribuire certificati SECURE Sockets Layer (SSL) pubblici e privati. È possibile usare i certificati con Azure e con le risorse connesse interne.

Protezione in uso dei dati

Servizi specifici in Azure offrono la possibilità di proteggere i dati mentre vengono calcolati all'interno della CPU fisica e della memoria di un host usando il calcolo riservato di Azure.

Riservato Macchine virtuali offrire un'intera macchina virtuale in esecuzione all'interno di un tee, la memoria e l'esecuzione del contenuto della CPU della macchina virtuale sono crittografate offrendo un semplice approccio "lift & shift" per spostare applicazioni non modificate con requisiti di sicurezza elevati in Azure. Ogni macchina virtuale riservata di Azure dispone di un modulo TPM (Virtual Trust Platform Module) dedicato. La crittografia viene eseguita durante l'avvio sicuro dei componenti del sistema operativo.
I nodi di lavoro del servizio Azure Kubernetes riservati, i contenitori riservati nel servizio Azure Kubernetes o i contenitori riservati in Istanze di Azure Container (ACI) offrono la possibilità di eseguire e gestire contenitori non modificati all'interno di un'operatore tee che consente ai clienti di trarre vantaggio dalla protezione in uso. Le offerte di contenitori sono basate su Confidential Macchine virtuali e offrono vantaggi alle stesse protezioni.
Le soluzioni Application Enclave sono applicazioni appositamente create sfruttando specifiche estensioni cpu offerte dagli SKU della macchina virtuale che supportano le estensioni di Intel Software Guard (SGX), che offrono una base di calcolo attendibile molto granulare (TCB), ma richiedono che le applicazioni vengano codificate in modo specifico per sfruttare le funzionalità.
La versione sicura della chiave può essere combinata con queste tecnologie per garantire che i dati crittografati vengano decrittografati solo all'interno di un tee che dimostra che fornisce il livello di protezione richiesto tramite un processo noto come attestazione.

Gestione dei segreti

È possibile usare Key Vault per archiviare e controllare in modo sicuro l'accesso ai token, alle password, ai certificati, alle chiavi API e ad altri segreti. Usare Key Vault come soluzione di gestione delle chiavi e dei certificati. Lo SKU Premium supporta le macchine virtuali.

Esempio

Nell'esempio seguente vengono illustrate le soluzioni di crittografia che è possibile usare per gestire chiavi, certificati e segreti.

Collegamenti della community

Panoramica di Key Vault

Elenco di controllo relativo alla sicurezza

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo della sicurezza

Raccomandazioni per la crittografia dei dati