Comprendere la crittografia dei dati in Azure Storage

Azure Storage è la spina dorsale di innumerevoli applicazioni cloud-native, data lake, soluzioni di backup e carichi di lavoro aziendali. Con questo ruolo centrale viene una responsabilità innegabile: proteggere i dati ovunque risieda. La crittografia è la base di tale protezione, assicurando che le informazioni sensibili rimangano riservate anche se gli aggressori bypassano i controlli di rete o la sicurezza fisica. Microsoft Azure fornisce un framework di crittografia a strati che copre i dati sia a riposo che in transito, con le opzioni gestite da chiave completamente gestite.

Questo articolo si espande sulle funzionalità di crittografia del core all'interno di Azure Storage, tra cui Azure Blob Storage, Azure Files, Queue Storage e Table Storage.

Crittografia a Riposo

La crittografia a riposo protegge i dati quando è scritta ai media fisici all'interno dei data center Azure. Questo include tutto, dai blocchi di disco grezzi utilizzati dalle macchine virtuali ai livelli di archiviazione degli oggetti in Blob Storage. Azure implementa la crittografia a riposo utilizzando una combinazione di crittografia trasparente lato storage, crittografia a livello di infrastruttura e crittografia opzionale lato client.

Crittografia del servizio di archiviazione di Azure (SSE)

SSE è il meccanismo di crittografia predefinito per tutti i nuovi e esistenti Azure Storage account. Crittografa i dati nello strato di servizio di archiviazione prima di scrivere su disco e decifrarlo quando legge. Questo processo è completamente trasparente per le applicazioni; nessun cambiamento di codice, nessuna bandiere di configurazione e nessuna sintonia di prestazione sono necessari.

SSE copre tutti i servizi di Azure Storage: Blob Storage (blocco blobs, append blobs e page blobs), Azure Files (comprese le azioni di file), Queue Storage e Table Storage. Per Azure Managed Disks, che back virtual machine storage, la crittografia è gestita separatamente da Azure Disk Encryption o server-side crittografia (SSE + piattaforma-managed key).

Crittografia delle infrastrutture

Oltre a SSE, Azure Storage offre ] crittografia delle infrastrutture[], che aggiunge un secondo livello di crittografia a livello di infrastruttura di archiviazione. Mentre SSE protegge i dati sui dischi fisici, la crittografia delle infrastrutture crittografa nuovamente i dati prima che sia scritto sulla rete interna del cluster di archiviazione e sui livelli di cache.

La crittografia delle infrastrutture è abilitata a livello di account di archiviazione e utilizza chiavi gestite dalla piattaforma. Non richiede modifiche alle applicazioni o al codice client. Il trade-off è un piccolo overhead di scrittura (tipalmente trascurabile per la maggior parte dei carichi di lavoro) e che non può essere disabilitato una volta abilitato. La vostra organizzazione dovrebbe valutare se un secondo livello di crittografia è necessario in base a politiche interne, guida regolamentare o requisiti contrattuali.

Tasti gestite dal cliente (CMK)

Per le organizzazioni che devono controllare le proprie chiavi di crittografia–sia per soddisfare i mandati di conformità, implementare i programmi di rotazione chiave, o integrare con i sistemi di gestione chiave esistenti–Azure Storage supporta []Customer-Managed Keys (CMK)[]]] memorizzato in Azure Key Vault. Quando CMK è abilitato, la chiave di root utilizzata per avvolgere i tasti di crittografia dei dati di accesso è memorizzato per la crittografia di accesso è memorizzato.

CMK gestisce in cima a SSE. Il servizio di archiviazione crittografa ancora i dati utilizzando AES-256, ma la chiave di crittografia (KEK) che protegge le chiavi di crittografia dei dati (DEKs) è gestito da voi. È possibile scegliere tra un Key Vault-managed key]] (software-protected o HSM-backed) o un Key

Considerazioni importanti per CMK:

  • Se disattivate o eliminate la chiave in Key Vault, Azure Storage non riuscirà ad accedere ai dati, rendendo in modo efficace l'account di archiviazione inaccessibile e può portare alla perdita permanente dei dati se non accuratamente gestita.
  • CMK è disponibile per Blob Storage, Azure Files, Queue Storage, Table Storage e Azure Data Lake Storage Gen2.
  • CMK non supporta direttamente i dischi gestiti Azure; questo scenario utilizza la crittografia lato server con chiavi gestite dal cliente (SSE + CMK).
  • Monitoraggio delle operazioni chiave attraverso i registri di controllo Key Vault e Azure Monitor è essenziale per rilevare tentativi di accesso non autorizzati o la scadenza chiave.

Tasti di protezione clienti (CPK)

Per Blob Storage, c'è una terza opzione chiave chiamata Customer-Provided Keys (CPK)]. CPK permette a un client di fornire una chiave di crittografia al momento di ogni richiesta, piuttosto che memorizzare la chiave in Key Vault. La chiave è utilizzata per quella singola operazione di lettura o scrittura e non è mantenuta da Azure.

Crittografia in Transit

La crittografia in transito protegge i dati mentre si muove attraverso le reti, proteggendolo dall'intercettazione, dagli attacchi di mezzo e dalla intercettazione. Azure Storage fornisce molteplici meccanismi – dall'applicazione HTTPS obbligatoria alla crittografia SMB per le azioni di file – per garantire che i dati non vengano mai trasmessi in chiarotesto.

HTTPS Enforcement

Tutti gli endpoint Azure Storage supportano HTTPS (HTTP su TLS 1.2 o versioni successive). Per impostazione predefinita, sia HTTP che HTTPS sono accettati, ma la migliore pratica è quella di enforce Secure Transfer[] a livello di account di archiviazione. Questa impostazione rifiuta qualsiasi richiesta fatta su HTTP, bloccando le connessioni da client non configurati o applicazioni legacy che non supportano TLS.

Per lo sviluppo e il test, assicurarsi che non vengano utilizzati endpoint HTTP nelle tubazioni di produzione. Gli SDK Azure applicano HTTPS per impostazione predefinita quando si utilizzano stringhe di connessione che includono il suffisso endpoint predefinito.

TLS Requisiti di versione

Azure Storage supporta TLS 1.0, 1.1 e 1.2 dal lato client. Tuttavia, Microsoft consiglia vivamente di disabilitare TLS 1.0 e 1.1 per soddisfare gli standard di sicurezza moderni. A partire dalla versione Azure Storage REST API 2021-06-08, è possibile impostare un Minimum TLS version[]] requisito a livello di account di archiviazione.

Per configurare la versione minima TLS:

  • Vai al conto di archiviazione nel portale Azure.
  • Seleziona Configurazione[] nella sezione Sicurezza + networking.
  • Impostare la versione Minimum TLS[[] a 1.2.

Questa impostazione si applica a tutti gli endpoint, inclusi Blob, File, Queue e Table storage. Audit per tutte le applicazioni legacy che possono contare su TLS 1.0 o 1.1 prima di rispettare l'aggiornamento.

Crittografia SMB per file Azure

SMB 3.0 e successivamente include la crittografia integrata che protegge i dati in transito tra il client e la condivisione di file. Quando si accede a una condivisione di file Azure da un client supportato (Windows 8/Server 2012 o versioni successive, Linux con client CIFS kernel 4.0+), la connessione viene automaticamente crittografata sulla rete.

Per i clienti che si collegano tramite VPN o ExpressRoute, la crittografia SMB garantisce che i dati che attraversano Internet pubblico (dove applicabile) rimangano riservati. Su reti interne Azure, la crittografia è ancora raccomandata per proteggere dai potenziali attacchi di movimento laterale all'interno del datacenter.

Endpoint privati e servizi

Mentre la crittografia protegge i dati in transito, i controlli di livello di rete riducono ulteriormente l'esposizione. Azure Private Endpoints[] assegnare un indirizzo IP privato all'account di archiviazione dalla rete virtuale, effettivamente portando il servizio di archiviazione all'interno del VNet. Traffico tra la rete virtuale e il conto di archiviazione viaggia sulla rete di backbone Microsoft, non su Internet pubblico.

Gli endpoint di servizio offrono un vantaggio simile a livello subnet ma senza un IP privato. Entrambe le opzioni si integrano perfettamente con le impostazioni SSE e di crittografia in-transit.

Gestione chiave e rotazione

Anche con SSE utilizzando chiavi gestite da piattaforma, la vostra organizzazione conserva la proprietà dei dati e la responsabilità legale per la sua protezione. Le chiavi devono essere ruotate periodicamente per limitare l'impatto di un potenziale compromesso chiave o per soddisfare i requisiti di conformità come PCI DSS, HIPAA, o SOC 2.

Per gli account di storage utilizzando CMK, la rotazione viene gestita tramite Azure Key Vault. È possibile configurare la rotazione automatica impostando una politica di rotazione sulla chiave, ad esempio ogni 90 giorni. Azure Storage raccoglie la nuova versione chiave e ri-critta le chiavi di crittografia dei dati con la chiave più recente. Non è necessario alcun intervento manuale o downtime. Per chiavi gestite dalla piattaforma (default SSE), Microsoft ruota le chiavi internamente senza visibilità del cliente.

L'utilizzo di chiavi di controllo è semplice con i registri diagnostici di Key Vault. Esporta i registri in uno spazio di lavoro di Log Analytics o Azure Storage e imposta avvisi per operazioni come [], , o ]. Qualsiasi modello di accesso chiave inaspettato potrebbe indicare una decisa decrittografia non autorizzata.

Porta la tua chiave (BYOK) con HSM

Per le organizzazioni in settori altamente regolamentati, Azure Key Vault Managed HSM offre un modulo di sicurezza hardware convalidato FIPS 140-2 Livello 3 (HSM) per memorizzare le chiavi di crittografia. È possibile generare la chiave on-premises e trasferirlo in modo sicuro al HSM utilizzando un processo chiamato Bring Your Own Key (BYOK).

Compliance e allineamento regolamentare

SSE soddisfa i mandati di crittografia a terra in ISO 27001, SOC 2 e FedRAMP Moderate. La crittografia a infrarossi si allinea ai requisiti per la crittografia a doppio strato visti in specifici standard federali. CMK fornisce la separazione chiave necessaria per CJIS (Criminal Justice Information Services) e IRS 1075 dati, dove il CSP non deve avere chiavi di crittografia indipendenti.

Azure fornisce la documentazione di conformità e i rapporti di audit attraverso la pagina ]Microsoft Compliance Offers[[]]. Utilizzare la politica Azure per applicare le impostazioni di crittografia in tutta la vostra organizzazione, come richiedere CMK per tutti i conti di archiviazione contenenti dati di produzione o inviare una versione minima TLS di 1.2.

Considerazioni sulle prestazioni

La crittografia in Azure Storage introduce un minimo di sovraccarico. SSE opera al livello del nodo di archiviazione ed è ottimizzata per il throughput. Nella maggior parte dei benchmark, il costo della CPU della crittografia AES-256 è molto inferiore alla latenza della rete I/O. La crittografia delle infrastrutture aggiunge un piccolo costo di amplificazione di scrittura, ma per i carichi di lavoro tipici (conti di archiviazione GPv2, blocchi di uso generale), l'impatto è ben inferiore al 5% per gli oggetti di sequenti.

CMK aggiunge latenza di rete per operazioni di swrapping chiave perché il servizio di archiviazione deve chiamare Key Vault per decifrare il DEK su ogni supporto o fetch. Questa latenza è tipicamente sotto 10 ms per chiamata, e il risultato è memorizzato nella cache, quindi le richieste successive all'interno della stessa sessione non incorrere in overhead. Per la maggior parte delle applicazioni, questo è impercettibile.

L'implementazione della crittografia in Azure Storage richiede pianificazione ma non complessità. Le seguenti pratiche ti aiuteranno a costruire una postura di crittografia robusta:

  • Verify SSE è abilitato. È su per impostazione predefinita, ma controlla i conti esistenti creati con le versioni precedenti di Azure Storage API o strumenti di gestione per garantire che nessun account abbia la crittografia disabilitata.
  • Abilita l'applicazione di trasferimento sicuro[[] su ogni account di archiviazione per garantire la comunicazione HTTPS-solo.
  • Impostare la versione TLS minima a 1.2 in tutti i conti di storage di produzione.
  • Utilizzare le chiavi gestite dal cliente[[] per i carichi di lavoro soggetti ai requisiti di conformità che richiedono il controllo chiave o la separazione dei compiti.
  • Implementare la crittografia delle infrastrutture[[]] se il vostro framework di conformità richiede esplicitamente la crittografia a doppio strato.
  • I tasti di rotazione regolarmente[]]–la rotazione automatica utilizzando le politiche di Key Vault per evitare errori manuali.
  • Le operazioni di crittografia del motorino[[] attraverso la diagnostica Azure Monitor e Key Vault.
  • Usa Azure Policy[[]]] per far rispettare i requisiti di crittografia, come ad esempio la richiesta di CMK per alcuni gruppi di risorse o il blocco dell'accesso HTTP.
  • Creazione lato client [[]] per i dati ultrasensibili che devono essere crittografati prima di raggiungere Azure Storage. Le librerie client Azure Storage supportano questo, ma aggiunge complessità e devono essere riservate per scenari eccezionali.
  • Test il vostro piano di recupero di emergenza[[]] con chiavi CMK. Se il vostro Key Vault è in una regione diversa e non riesce, può il vostro account di archiviazione ancora essere accessibile?

Grazie alla crittografia a riposo, alla crittografia in transito e alla gestione delle chiavi, è possibile ottenere una postura di sicurezza che soddisfi le esigenze della moderna conformità aziendale senza sacrificare le prestazioni o la semplicità operativa. Per ulteriori dettagli, fare riferimento alla Azanzana Storage Service Encryption documentazione[] e alla ]] Guida di trasferimento di Microsoft Learn]].