Raccomandazioni per la crittografia dei dati

Articolo
02/05/2024

Si applica alla raccomandazione dell'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, che causano 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.
Pacchetto di crittografia	Set di algoritmi usati per crittografare e decrittografare le informazioni per proteggere una connessione di rete tramite TLS (Transport Layer Security).
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 lo scopo 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 usando una firma.
X.509	Standard che definisce il formato dei certificati di chiave pubblica.

Strategie di progettazione chiave

I requisiti normativi o obbligatori dell'organizzazione potrebbero applicare 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, sia che si tratti di dati utente esterni o dei dipendenti.

È 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 consiste nella 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.

Determinare i requisiti di 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 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 dovrebbero essere l'unica forma di difesa. Implementare processi di prevenzione del furto di dati, metodi di test appropriati e rilevamento anomalie.

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

Usare meccanismi di crittografia nativi

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 svantaggi e usare algoritmi di crittografia standard del settore.

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

Scegliere un approccio alle 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 le 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 chiavi separate dai dati crittografati. Questo disaccoppiamento garantisce 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.Store highly sensitive data in a managed hardware security module (HSM).

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

Usare algoritmi di crittografia standard

Usare algoritmi di crittografia ben consolidati e seguire gli standard del settore anziché creare implementazioni personalizzate.

Gli standard di settore per gli algoritmi richiedono che gli schemi di crittografia abbiano un determinato livello di entropia. Le origini di entropia vengono inserite durante la crittografia. L'entropia rende l'algoritmo forte e rende difficile per un utente malintenzionato estrarre informazioni. 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 spesi per la crittografia, rispetto agli obiettivi di prestazioni complessivi della richiesta di calcolo.

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

Usare 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 causate da manomissioni. Le funzioni hash sono basate sulla crittografia, ma non usano chiavi. Le funzioni hash usano algoritmi per produrre checksum. I checksum possono confrontare i dati per verificarne l'integrità.

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

Crittografare i dati inattivi

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

Crittografare i dati usando opzioni native disponibili per i servizi di archiviazione, gli archivi dati e altre risorse usate per rendere persistenti i dati. Crittografare questi dati anche se si archiviano i 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 viene 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 due 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 della chiave (KEK) per proteggere la chiave DEK (Data Encryption Key).
Usare i controlli di accesso basati sull'identità per controllare l'accesso ai dati. Aggiungere firewall di rete per fornire un ulteriore livello 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 controllo di accesso con privilegi minimi. Separare i dati dalle chiavi ai dati.
Archiviare quantità limitata di dati in modo da crittografare solo ciò che è necessario. I dati non devono durare più a lungo del ciclo di crittografia. Quando i dati non sono più necessari, eliminare i dati crittografati senza i cicli di decrittografia di spesa.

Crittografare i dati in movimento

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

Non usare versioni precedenti a TLS 1.2. Eseguire la migrazione di 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 client-server, negoziare l'uso dei criteri HTTP Strict Transport Security (HSTS) in modo che il trasporto HTTPS venga mantenuto e non venga scaricato su 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, database SQL di Azure 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 crittografie assicurano che lo scambio sia crittografato e autenticato. La scelta delle crittografie dipende dalla versione TLS usata dal server. Per alcuni servizi, ad esempio app Azure lication Gateway, è possibile scegliere la versione di TLS e le suite di crittografia che si desidera supportare. Implementare pacchetti 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 conservare certificati di lunga durata e non lasciare che scadano 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 di certificati, 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 le 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 invalidati prima della scadenza. Il controllo di convalida deve tenere conto dei CRL.

Compromesso: il processo di convalida della certificazione può essere complesso e in genere comporta una CA. Determinare i dati da 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 reciproco (mTLS). Stabilisce l'attendibilità in entrambe le direzioni tra il client e il server. Sia il client che il server hanno i propri certificati 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.
Se necessario, crittografare due connessioni VPN. Eseguire la doppia crittografia per aggiungere difesa avanzata 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, anche 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'INDIRIZZO IP di origine, la porta e il protocollo. Usare queste informazioni per rilevare le anomalie.

Crittografare i dati in uso

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 sono 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 entro tali limiti di isolamento.

I requisiti normativi o di sicurezza più rigorosi possono richiedere anche prove con firma crittografica basate su hardware che i dati vengono crittografati durante l'uso, che possono essere ottenuti tramite attestazione. Il confidential computing è una di queste tecnologie che supportano il requisito. Servizi specifici in Azure offrono la possibilità di proteggere i dati durante il calcolo. Per altre informazioni, vedere Facilitazione di Azure: Confidential Compute 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 componenti di una soluzione possano fornire i livelli di protezione necessari o garantire che la strategia di gestione dei dati fornisca una segmentazione o una 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 modulo di protezione hardware gestito da Key Vault.

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

Per altre informazioni, vedere Fornire l'accesso a chiavi, certificati e segreti di Key Vault usando il controllo degli accessi in base al ruolo.

Azure Key Vault Premium e Managed-HSM migliorano ulteriormente l'offerta includendo funzionalità di confidential computing e Secure Key Release che supportano un criterio per garantire che una chiave venga rilasciata solo a un carico di lavoro in grado di dimostrare crittograficamente che viene eseguita all'interno di un ambiente di esecuzione attendibile (TEE).

Protezione dei dati inattivi

Archiviazione di Azure crittografa automaticamente i dati con crittografie a blocchi quando i dati vengono salvati in modo permanente in un account di archiviazione. Per Archiviazione BLOB di Azure e Archiviazione code di Azure, Archiviazione fornisce anche la crittografia lato client tramite librerie.

Per altre informazioni, vedere Crittografia dell'archiviazione.
Azure Macchine virtuali include file su disco che fungono da volumi di archiviazione virtuale. È possibile crittografare i file del disco virtuale in modo che non sia possibile accedere al contenuto.

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 del disco gestito.
database SQL offre una funzionalità transparent data encryption 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 SSL (Secure Sockets Layer) pubblici e privati. È possibile usare i certificati con Azure e con le risorse connesse interne.

Protezione dei dati in uso

Servizi specifici in Azure offrono la possibilità di proteggere i dati durante il calcolo all'interno della CPU fisica e della memoria di un host usando il confidential computing di Azure.

I Macchine virtuali riservati offrono un'intera macchina virtuale in esecuzione all'interno di un ambiente tee, la memoria e l'esecuzione del contenuto della CPU della macchina virtuale sono crittografate offrendo un semplice approccio "lift &shift" per lo spostamento di applicazioni non modificate con requisiti di sicurezza elevati in Azure. Ogni macchina virtuale riservata di Azure ha un proprio 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 offrono la possibilità di eseguire e gestire contenitori non modificati all'interno di un ambiente tee che consente ai clienti di trarre vantaggio dalla protezione in uso. Le offerte di contenitori sono basate su Confidential Macchine virtuali e traggono vantaggio dalle stesse protezioni.
Le soluzioni dell'enclave delle applicazioni sono applicazioni appositamente create sfruttando specifiche estensioni cpu offerte dagli SKU di macchine virtuali che supportano le estensioni di Intel Software Guard (SGX), che offrono una base TCB (Trusted Compute Base) molto granulare, ma richiedono che le applicazioni vengano codificate specificamente per sfruttare le funzionalità.
Secure Key Release può essere combinato con queste tecnologie per garantire che i dati crittografati vengano decrittografati solo all'interno di un tee 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 a token, password, certificati, chiavi API e altri segreti. Usare Key Vault come soluzione di gestione delle chiavi e dei certificati. Lo SKU Premium supporta i moduli di protezione hardware.

Esempio

L'esempio seguente illustra 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 relativo alla sicurezza

Condividi tramite

Raccomandazioni per la crittografia dei dati