Crittografia lato client per i BLOB

La libreria client Archiviazione BLOB di Azure per .NET supporta la crittografia dei dati nelle applicazioni client prima di caricare in Archiviazione di Azure e decrittografare i dati durante il download nel client. La libreria supporta anche l'integrazione con Azure Key Vault per la gestione delle chiavi dell'account di archiviazione.

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 usa la modalità CBC (Cipher Block Chaining) con AES.

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:

• È consigliabile usare le funzionalità di crittografia lato servizio anziché la 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:

Microsoft consiglia inoltre di seguire questa procedura per proteggere i dati:

• Configurare gli account di archiviazione per usare endpoint privati per proteggere tutto il traffico tra la rete virtuale (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

Nella tabella seguente vengono illustrate le versioni delle librerie client per .NET, Java e Python che supportano le versioni della crittografia lato client:

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. È quindi necessario decrittografare e crittografare nuovamente i dati con 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 busta per crittografare e decrittografare i dati sul lato client. La crittografia della busta 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 della busta funziona come indicato di seguito:

1. La libreria client di Archiviazione di Azure genera una chiave di crittografia del contenuto (CEK), che è una chiave simmetrica uni-time-use.

2. I dati utente vengono crittografati tramite CEK.

3. Viene quindi eseguito il wrapping della chiave CEK mediante la chiave di crittografia della chiave (KEK). KeK è identificato da un identificatore di chiave e può essere una coppia di chiavi asimmetrica o una chiave simmetrica. È possibile gestire kek in locale o archiviarlo in un Key Vault di Azure.

   La libreria client di Archiviazione di Azure non ha mai accesso a 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.

4. I dati crittografati vengono quindi caricati in Archiviazione BLOB di Azure. La chiave wrapped insieme ad alcuni metadati di crittografia aggiuntivi viene archiviata come metadati nel BLOB.

La decrittografia tramite la tecnica della busta funziona come segue:

1. La libreria client di Archiviazione di Azure presuppone che l'utente gestisca il kek in locale o in un Key Vault di Azure. L'utente non deve conoscere la chiave specifica usata per la crittografia. È invece possibile configurare e usare un sistema di risoluzione delle chiavi che risolve diversi identificatori di chiave per le chiavi.
2. La libreria client scarica i dati crittografati insieme a qualsiasi materiale di crittografia archiviato in Archiviazione di Azure.
3. La chiave CEK con wrapping viene quindi annullata (decrittografata) tramite KEK. La libreria client non ha accesso alla chiave KEK durante questo processo, ma richiama solo l'algoritmo di annullamento dell'applicazione dell'Key Vault di Azure o di un altro archivio chiavi.
4. La libreria client usa il codice 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 in caso di 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 un CEK casuale di 32 byte ed esegue la crittografia della busta dei dati BLOB usando queste informazioni. Il file 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, il file CEK wrapped viene decrittografato e usato insieme all'IV per restituire i dati decrittografati al client.

Il download di un intervallo arbitrario nel BLOB crittografato comporta la modifica 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.

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.

// 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(connectionString, 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);

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);

blob_client = blob_service_client.get_blob_client(container=container_name, blob=blob_name)
    blob_client.require_encryption = True
    blob_client.key_encryption_key = kek
    blob_client.encryption_version = ‘2.0’  # Use Version 2.0!

    with open("decryptedcontentfile.txt", "rb") as stream:
        blob_client.upload_blob(stream, overwrite=OVERWRITE_EXISTING)

Riprocrittografare i dati crittografati in precedenza con crittografia lato client v2

Tutti i dati crittografati in precedenza con crittografia lato client v1 devono essere decrittografati e quindi ricrittografati con crittografia lato client v2 per mitigare la vulnerabilità di sicurezza. La decrittografia richiede il download dei dati e la ricritcrittura richiede di ricaricarlo nell'archiviazione BLOB.

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 CEK e IV, crittografare il contenuto stesso, comunicare con l'archivio chiavi scelto per l'avvolgezione della chiave e il formato 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.

Passaggi successivi

• Archiviazione di Azure che aggiorna la crittografia lato client in SDK per risolvere la vulnerabilità di sicurezza
• Crittografia del servizio di archiviazione di Azure per dati inattivi
• Documentazione di Azure Key Vault