Crittografia lato client per i BLOB
La libreria client Archiviazione BLOB di Azure per .NET supporta la crittografia dei dati all'interno delle applicazioni client prima del caricamento in Archiviazione di Azure e la decrittografia dei dati durante il download nel 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 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 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 in 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 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 della 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, quindi ricrittografarli 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, quindi ricrittografarli 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 solo a reti specifiche.
Matrice di supporto sdk per la crittografia lato client
La tabella seguente illustra le versioni delle librerie client per .NET, Java e Python che supportano le versioni 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 |
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 supporta 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 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 client Archiviazione di Azure genera una chiave di crittografia del contenuto (CEK), che è una chiave simmetrica monouso.
I dati utente vengono crittografati usando la chiave cek.
Viene quindi eseguito il wrapping della chiave CEK mediante la chiave di crittografia della chiave (KEK). La chiave kek è identificata da un identificatore di chiave e può essere una coppia di chiavi asimmetriche o una chiave simmetrica. È possibile gestire la chiave di crittografia della chiave in locale o archiviarla in un insieme di credenziali delle chiavi di Azure.
La libreria client Archiviazione di Azure non ha mai accesso alla chiave 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 in 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 gestisca la chiave di crittografia della chiave in locale o in un insieme di credenziali delle chiavi di Azure. L'utente non deve conoscere la chiave specifica usata per la crittografia. È invece possibile configurare e usare un resolver di chiavi che risolve diversi identificatori di chiave nelle chiavi.
- La libreria client scarica i dati crittografati insieme a qualsiasi 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 chiave 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/download del BLOB
La libreria client di archiviazione BLOB supporta la crittografia di interi BLOB solo al caricamento. Per i download, sono supportati sia i download completi che di intervallo.
Durante la crittografia, la libreria client genera un vettore di inizializzazione casuale (IV) di 16 byte e una chiave CEK casuale di 32 byte ed esegue la crittografia envelope dei dati BLOB usando queste informazioni. La chiave cek di cui è stato eseguito il 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 mantenuti. Se si caricano nuovi metadati senza conservare anche i metadati 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 Put BLOB e i comandi di download di interi BLOB, ad esempio Recupera BLOB. Evitare di scrivere in un BLOB crittografato usando operazioni di protocollo come Put Block, Put Block List, Put Page o Append Block. La chiamata a queste operazioni su un BLOB crittografato può danneggiarla e renderla 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 ricrittografarli 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 è necessario eseguire la migrazione dalla versione 11.x 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
IKeyEncryptionKeyinterfacce eIKeyEncryptionKeyResolver. 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. È necessario 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 non supporta la memorizzazione nella
IKeyEncryptionKeyResolvercache delle chiavi. La memorizzazione nella cache deve essere necessaria a causa della limitazione, è possibile usare l'approccio illustrato in questo esempio per inserire un livello di memorizzazione nella cache in un'istanzaAzure.Security.KeyVault.Keys.Cryptography.KeyResolverdi .
Gli sviluppatori possono fornire una chiave, un resolver di chiavi o sia una chiave che un resolver di chiavi. 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 sistema di risoluzione delle chiavi viene usato per risolvere una chiave durante il processo di decrittografia. Il sistema di risoluzione delle chiavi definisce un metodo resolve che restituisce una chiave in base a un identificatore di chiave. Il sistema di risoluzione offre agli utenti la possibilità di scegliere tra più chiavi gestite in più posizioni.
In caso di crittografia, la chiave viene usata sempre e l'assenza di una chiave genererà un errore.
In caso di decrittografia, se la chiave viene specificata e il relativo identificatore corrisponde all'identificatore di chiave richiesto, tale chiave viene usata per la decrittografia. In caso contrario, la libreria client tenta di chiamare il sistema di risoluzione. Se non è specificato alcun sistema di risoluzione, la libreria client genera un errore. Se viene specificato un resolver, viene richiamato il sistema di risoluzione delle chiavi per ottenere la chiave. Se il sistema di risoluzione viene 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 verrà gestito dalla libreria client internamente.
// 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 costruttori BlobServiceClient, BlobContainerClient o 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 creare una copia di tale oggetto con l'oggetto ClientSideEncryptionOptions specificato. Questo metodo di estensione evita il sovraccarico di costruzione di un nuovo oggetto BlobClient da zero.
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 Reencrypt precedentemente crittografati dati con crittografia lato client v2.
Ricrittografare 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 ricrittografati 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 di esempio che illustra come eseguire la migrazione dei dati dalla crittografia lato client v1 alla versione 2 e come crittografare i dati con la crittografia lato client v2 in .NET, vedere il progetto di esempio di migrazione della crittografia.
Crittografia e prestazioni lato client
Tenere presente che la crittografia dei dati di archiviazione comporta un sovraccarico delle prestazioni aggiuntivo. Quando si usa la crittografia lato client nell'applicazione, la libreria client deve generare in modo sicuro la chiave CEK e l'IV, crittografare il contenuto stesso, comunicare con l'archivio chiavi scelto per l'inserimento delle chiavi e formattare e caricare metadati aggiuntivi. Questo sovraccarico varia a seconda della quantità di dati crittografati. È consigliabile che i clienti testano sempre le proprie applicazioni per le prestazioni durante lo sviluppo.