Crittografia lato client per i BLOB
La libreria client di Archiviazione BLOB di Azure per .NET supporta la crittografia dei dati all'interno delle applicazioni client prima del caricamento nell'Archiviazione di Azure, nonché la decrittografia dei dati durante il download al client. La libreria inoltre supporta l'integrazione con l' insieme di credenziali chiave di Azure per la gestione delle chiavi dell'account di archiviazione.
Importante
Archiviazione BLOB supporta sia la crittografia lato servizio che quella lato client. Per la maggior parte degli scenari, Microsoft consiglia di usare le funzionalità di crittografia lato servizio per semplificare l'uso nella protezione dei dati. Per altre informazioni sulla crittografia lato servizio, vedere Crittografia di Archiviazione di Azure per i dati inattivi.
Per un'esercitazione dettagliata che guidi l'utente attraverso il processo di crittografia dei BLOB mediante la crittografia lato client e l'insieme di credenziali delle chiavi di Azure, vedere Crittografare e decrittografare i BLOB in Archiviazione di Microsoft Azure tramite l'insieme di credenziali chiave di Azure.
Informazioni sulla crittografia lato client
La libreria client Archiviazione BLOB di Azure usa Advanced Encryption Standard (AES) per crittografare i dati utente. Nella libreria client sono disponibili due versioni della crittografia lato client:
- La versione 2 usa la modalità Galois/Counter Mode (GCM) con AES.
- La versione 1 si avvale della modalità Cipher Block Chaining (CBC) con AES.
Avviso
L'uso della versione 1 della crittografia lato client non è più consigliato a causa di una vulnerabilità di sicurezza nell'implementazione della libreria client in modalità CBC. Per altre informazioni su questa vulnerabilità di sicurezza, vedere Archiviazione di Azure che aggiorna la crittografia lato client in SDK per risolvere la vulnerabilità di sicurezza. Se si usa attualmente la versione 1, è consigliabile aggiornare l'applicazione per usare la versione 2 ed eseguire la migrazione dei dati. Per altre indicazioni, vedere la sezione seguente Attenuare la vulnerabilità di sicurezza nelle applicazioni.
Attenuare la vulnerabilità di sicurezza nelle applicazioni
A causa di una vulnerabilità di sicurezza individuata nell'implementazione della libreria client di Archiviazione BLOB della modalità CBC, Microsoft consiglia di eseguire immediatamente una o più delle azioni seguenti:
Prendere in considerazione l'uso delle funzionalità di crittografia lato servizio anziché della crittografia lato client. Per altre informazioni sulle funzionalità di crittografia lato servizio, vedere Crittografia di Archiviazione di Azure per i dati inattivi.
Se è necessario usare la crittografia lato client, eseguire la migrazione delle applicazioni dalla crittografia lato client v1 alla crittografia lato client v2.
La tabella seguente riepiloga i passaggi da eseguire se si sceglie di eseguire la migrazione delle applicazioni alla crittografia lato client v2:
| Stato crittografia lato client | Azioni consigliate |
|---|---|
| L'applicazione usa la crittografia lato client una versione della libreria client che supporta solo la crittografia lato client v1. | Aggiornare l'applicazione per usare una versione della libreria client che supporta la crittografia lato client v2. Per un elenco delle versioni supportate, vedere Matrice di supporto SDK per la crittografia lato client. Altre informazioni Aggiornare il codice per usare la crittografia lato client v2. Altre informazioni Scaricare tutti i dati crittografati per decrittografarli e quindi crittografarlo nuovamente con la crittografia lato client v2. Altre informazioni |
| L'applicazione usa la crittografia lato client con una versione della libreria client che supporta la crittografia lato client v2. | Aggiornare il codice per usare la crittografia lato client v2. Altre informazioni Scaricare tutti i dati crittografati per decrittografarli e quindi crittografarlo nuovamente con la crittografia lato client v2. Altre informazioni |
Microsoft consiglia inoltre di seguire questa procedura per proteggere i dati:
- Configurare gli account di archiviazione per usare gli endpoint privati per proteggere tutto il traffico tra la rete virtuale e l'account di archiviazione tramite un collegamento privato. Per altre informazioni, vedere Usare endpoint privati per Archiviazione di Azure.
- Limitare l'accesso alla rete esclusivamente alle reti specifiche.
Matrice di supporto di SDK per la crittografia lato client
La tabella seguente illustra le versioni delle librerie client per .NET, Java e Python che supportano versioni diverse della crittografia lato client:
| .NET | Java | Python | |
|---|---|---|---|
| Crittografia lato client v2 e v1 | Versioni 12.13.0 e successive | Versioni 12.18.0 e successive | Versioni 12.13.0 e successive |
| Solo crittografia lato client v1 | Versioni 12.12.0 e precedenti | Versioni 12.17.0 e precedenti | Versioni 12.12.0 e precedenti |
Nota
La crittografia lato client v2.1 è disponibile in Java SDK per le versioni 12.27.0 e successive. Questa versione consente di configurare la lunghezza dell'area per la crittografia autenticata, da 16 byte a 1 GiB. Per altre informazioni, vedere l'esempio Java in Esempio: Crittografia e decrittografia di un BLOB con crittografia lato client v2.
Se l'applicazione usa la crittografia lato client con una versione precedente della libreria client .NET, Java o Python, è prima necessario aggiornare il codice a una versione che supporti la crittografia lato client v2. Successivamente, è necessario decrittografare e crittografare nuovamente i dati con la crittografia lato client v2. Se necessario, è possibile usare una versione della libreria client che supporta la crittografia lato client v2 side-by-side con una versione precedente della libreria client durante la migrazione del codice. Per esempi di codice, vedere Esempio: Crittografia e decrittografia di un BLOB con crittografia lato client v2.
Funzionamento della crittografia lato client
Le librerie client di Archiviazione BLOB di Azure usano la crittografia envelope per crittografare e decrittografare i dati sul lato client. La crittografia envelope crittografa una chiave con una o più chiavi aggiuntive.
Le librerie client di Archiviazione BLOB si basano su Azure Key Vault per proteggere le chiavi usate per la crittografia lato client. Per altre informazioni su Azure Key Vault, vedere Informazioni su Azure Key Vault.
Crittografia e decrittografia tramite la tecnica basata su envelope
La crittografia tramite la tecnica envelope funziona come segue:
La libreria di Azure Storage Client genera una chiave di crittografia del contenuto (CEK) che funziona come chiave simmetrica monouso.
I dati utente vengono crittografati con CEK.
Viene quindi eseguito il wrapping della chiave CEK mediante la chiave di crittografia della chiave (KEK). La KEK è identificata con un identificatore di chiave e può essere costituita da una coppia di chiavi asimmetriche o da una chiave simmetrica. È possibile gestire la KEK in locale o archiviarla in un insieme di credenziali delle chiavi di Azure.
La libreria del client Archiviazione di Azure non ha mai accesso alla KEK. Richiama solo l'algoritmo di wrapping della chiave fornito dall'insieme di credenziali chiave. Gli utenti possono scegliere di usare provider personalizzati per il wrapping o la rimozione del wrapping delle chiavi, se lo desiderano.
I dati crittografati vengono quindi caricati nel servizio Archiviazione BLOB di Azure. La chiave di cui è stato eseguito il wrapping insieme ad alcuni metadati di crittografia aggiuntivi viene archiviata come metadati nel BLOB.
La decrittografia tramite la tecnica envelope funziona come segue:
- La libreria client Archiviazione di Azure presuppone che l'utente gestisce la KEK in locale o in un insieme di credenziali Azure. L'utente non deve necessariamente conoscere la chiave specifica utilizzata per la crittografia. Al contrario, è possibile impostare e utilizzare un resolver di chiavi che risolve diversi identificatori di chiave per le chiavi.
- La libreria client scarica i dati crittografati insieme al materiale di crittografia archiviato in Archiviazione di Azure.
- La chiave CEK di cui è stato eseguito il wrapping viene quindi decrittografata (decrittografata) usando la chiave kek. La libreria client non ha accesso alla KEK durante questo processo, ma richiama solo l'algoritmo di annullamento del wrapping dell'insieme di credenziali delle chiavi di Azure o di un altro archivio chiavi.
- La libreria client usa la chiave CEK per decrittografare i dati utente crittografati.
Crittografia/decrittografia nel caricamento/scaricamento del BLOB
La libreria client di Archiviazione BLOB supporta la crittografia di interi BLOB solo durante il caricamento. Per i download, sono supportati sia i download completi che di intervallo. La crittografia lato client v2 suddivide i dati in 4 blocchi di crittografia autenticati memorizzati nel buffer miB che possono essere trasformati solo interi. Per modificare le dimensioni del blocco, assicurarsi di usare la versione più recente dell'SDK che supporta la crittografia lato client v2.1. La lunghezza dell'area è configurabile da 16 byte fino a 1 GiB.
Durante la crittografia, la libreria client genera un vettore di inizializzazione casuale (IV) di 16 byte e una chiave CEK casuale di 32 byte, quindi esegue la crittografia envelope dei dati BLOB usando queste informazioni. La CEK con wrapping e alcuni metadati di crittografia aggiuntivi vengono quindi archiviati come metadati BLOB insieme al BLOB crittografato.
Quando un client scarica un intero BLOB, la chiave CEK di cui è stato eseguito il wrapping viene annullata e usata insieme all'IV per restituire i dati decrittografati al client.
Il download di un intervallo arbitrario nel BLOB crittografato comporta la regolazione dell'intervallo fornito dagli utenti per ottenere una piccola quantità di dati aggiuntivi che possono essere usati per decrittografare correttamente l'intervallo richiesto.
Tutti i tipi di BLOB (BLOB in blocchi, BLOB di pagine e BLOB di accodamento) possono essere crittografati/decrittografati con questo schema.
Avviso
Se si stanno modificando o caricando i propri metadati per il BLOB, è necessario assicurarsi che i metadati di crittografia vengano conservati. Se si caricano nuovi metadati senza conservare quelli di crittografia, la chiave CEK di cui è stato eseguito il wrapping, l'IV e altri metadati andranno persi e non sarà possibile recuperare il contenuto del BLOB. La chiamata all'operazione Imposta metadati BLOB sostituisce sempre tutti i metadati del BLOB.
Quando si esegue la lettura o la scrittura in un BLOB crittografato, usare i comandi di caricamento di BLOB interi, (ad esempio, Inserisci BLOB) e i comandi di scaricamento di BLOB interi, (ad esempio, Ottieni BLOB). Evitare di scrivere in un BLOB crittografato usando operazioni di protocollo come Inserisci blocco, Inserisci lista blocchi, Inserisci paginao Accoda blocco. La chiamata a queste operazioni su un BLOB crittografato può danneggiarlo e renderlo illeggibile.
Esempio: crittografia e decrittografia di un BLOB con crittografia lato client v2
L'esempio di codice in questa sezione illustra come usare la crittografia lato client v2 per crittografare e decrittografare un BLOB.
Importante
Se si dispone di dati precedentemente crittografati con la crittografia lato client v1, sarà necessario decrittografare i dati e crittografarlo nuovamente con la crittografia lato client v2. Vedere le indicazioni e l'esempio per la libreria client di seguito.
Per usare la crittografia lato client dal codice .NET, fare riferimento alla libreria client di Archiviazione BLOB. Assicurarsi di usare la versione 12.13.0 o successiva. Se si necessita di eseguire la migrazione dalla versione 11x alla versione 12.13.0, vedere la guida alla migrazione.
Per l'integrazione di Azure Key Vault per la crittografia lato client sono necessari due pacchetti aggiuntivi:
Il pacchetto Azure.Core fornisce le interfacce
IKeyEncryptionKeyeIKeyEncryptionKeyResolver. La libreria client di archiviazione BLOB per .NET definisce già questo assembly come dipendenza.Il pacchetto Azure.Security.KeyVault.Keys (versione 4.x e successive) fornisce il client REST di Key Vault e i client crittografici usati con la crittografia lato client. Assicurarsi che questo pacchetto venga fatto riferimento nel progetto se si usa Azure Key Vault come archivio chiavi.
Azure Key Vault è progettato per le chiavi master ad alto valore, e i limiti di limitazione per ogni insieme di credenziali delle chiavi riflettono questa progettazione. A partire dalla versione 4.1.0 di Azure.Security.KeyVault.Keys, l'interfaccia
IKeyEncryptionKeyResolvernon supporta la memorizzazione nella cache delle chiavi. Se la memorizzazione nella cache dovesse risultare necessaria a causa della limitazione, è possibile usare l'approccio illustrato in questo campione per inserire un livello di memorizzazione nella cache in un'istanzaAzure.Security.KeyVault.Keys.Cryptography.KeyResolver.
Gli sviluppatori possono fornire una chiave, un resolver di chiavi o entrambi. Le chiavi vengono identificate usando un identificatore di chiave che fornisce la logica per il wrapping e l'annullamento del wrapping della chiave CEK. Un resolver delle chiavi viene usato per risolvere una chiave durante il processo di decrittografia. Il resolver delle chiavi definisce un metodo di risoluzione che restituisce una chiave in base a un identificatore di chiave. Il resolver offre agli utenti la possibilità di scegliere tra più chiavi gestite in più posizioni.
In caso di crittografia, la chiave viene sempre usata e l'assenza di una chiave genera un errore.
Per la decrittografia, se la chiave viene specificata e il relativo identificatore corrisponde all'identificatore di chiave richiesto, la chiave viene usata per la decrittografia. In caso contrario, la libreria client tenta di chiamare il resolver. Se non è specificato alcun resolver, la libreria client genera un errore. Se un resolver è specificato, il resolver delle chiavi viene chiamato per ottenere la chiave. Se il resolver è specificato ma non ha un mapping per l'identificatore di chiave, la libreria client genera un errore.
Per usare la crittografia lato client, creare un oggetto ClientSideEncryptionOptions e impostarlo alla creazione del client con SpecializedBlobClientOptions. Non è possibile impostare le opzioni di crittografia per ogni API. Tutto il resto viene gestito internamente dalla libreria client.
// Your key and key resolver instances, either through Azure Key Vault SDK or an external implementation.
IKeyEncryptionKey key;
IKeyEncryptionKeyResolver keyResolver;
// Create the encryption options to be used for upload and download.
ClientSideEncryptionOptions encryptionOptions = new ClientSideEncryptionOptions(ClientSideEncryptionVersion.V2_0)
{
KeyEncryptionKey = key,
KeyResolver = keyResolver,
// String value that the client library will use when calling IKeyEncryptionKey.WrapKey()
KeyWrapAlgorithm = "some algorithm name"
};
// Set the encryption options on the client options.
BlobClientOptions options = new SpecializedBlobClientOptions() { ClientSideEncryption = encryptionOptions };
// Create blob client with client-side encryption enabled.
// Client-side encryption options are passed from service clients to container clients,
// and from container clients to blob clients.
// Attempting to construct a BlockBlobClient, PageBlobClient, or AppendBlobClient from a BlobContainerClient
// with client-side encryption options present will throw, as this functionality is only supported with BlobClient.
BlobClient blob = new BlobServiceClient
(new Uri($"https://{accountName}.blob.core.windows.net"), new DefaultAzureCredential(), options).GetBlobContainerClient("my-container").GetBlobClient("myBlob");
// Upload the encrypted contents to the blob.
blob.Upload(stream);
// Download and decrypt the encrypted contents from the blob.
MemoryStream outputStream = new MemoryStream();
blob.DownloadTo(outputStream);
È possibile applicare opzioni di crittografia a BlobServiceClient, BlobContainerClient o costruttori BlobClient che accettano oggetti BlobClientOptions.
Se un oggetto BlobClient esiste già nel codice ma non dispone di opzioni di crittografia lato client, è possibile usare un metodo di estensione per crearne una copia con l'oggetto ClientSideEncryptionOptions specificato. Questo metodo di estensione evita il sovraccarico causato dalla costruzione di un nuovo oggetto BlobClient.
using Azure.Storage.Blobs.Specialized;
// An existing BlobClient instance and encryption options.
BlobClient plaintextBlob;
ClientSideEncryptionOptions encryptionOptions;
// Get a copy of the blob that uses client-side encryption.
BlobClient clientSideEncryptionBlob = plaintextBlob.WithClientSideEncryptionOptions(encryptionOptions);
Dopo aver aggiornato il codice per usare la crittografia lato client v2, assicurarsi di decrittografare e crittografare nuovamente i dati crittografati esistenti, come descritto in Crittografare nuovamente i dati crittografati in precedenza con la crittografia lato client v2.
Crittografare nuovamente i dati crittografati in precedenza con la crittografia lato client v2
Tutti i dati precedentemente crittografati con la crittografia lato client v1 devono essere decrittografati e quindi crittografati nuovamente con la crittografia lato client v2 per attenuare la vulnerabilità di sicurezza. La decrittografia richiede il download dei dati e la ricrittografia richiede il ricaricamento nell'archiviazione BLOB.
Per un progetto campione che illustra come eseguire la migrazione di dati dalla crittografia lato client v1 a v2 e come crittografare dati con la crittografia lato client v2 in .NET, vedere il progetto campione di migrazione della crittografia.
Crittografia e prestazioni lato client
Tenere a mente che la crittografia dei dati di archiviazione restituisce un overhead delle prestazioni aggiuntivo. Quando si usa la crittografia lato client nell'applicazione, la libreria client deve generare in modo sicuro la chiave CEK e IV, crittografare il contenuto stesso, comunicare con l'archivio chiavi scelto per l'inserimento delle chiavi e formattare e caricare metadati aggiuntivi. Questo overhead varia a seconda della quantità di dati da crittografare. È consigliabile che i clienti testano sempre le proprie applicazioni per le prestazioni durante lo sviluppo.