Crittografia lato client per le code
Le librerie client di Archiviazione code di Azure per .NET e Python supportano 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. Le librerie client supportano anche l'integrazione con l'insieme di credenziali delle chiavi di Azure per la gestione delle chiavi dell'account di archiviazione.
Importante
Archiviazione di Azure 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.
Informazioni sulla crittografia lato client
La libreria client di Archiviazione code di Azure usa AES per la crittografia dei 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 code 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. Aggiornare il codice per usare la crittografia lato client v2. |
| 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. |
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 e Python che supportano le versioni della crittografia lato client:
| .NET | Python | |
|---|---|---|
| Crittografia lato client v2 e v1 | Versioni 12.11.0 e successive | Versioni 12.4.0 e successive |
| Solo crittografia lato client v1 | Versioni 12.10.0 e precedenti | Versioni 12.3.0 e precedenti |
Se l'applicazione usa la crittografia lato client con una versione precedente della libreria client .NET 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.
Funzionamento della crittografia lato client
Le librerie client di Archiviazione code 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 code 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 code di Azure. La chiave di cui è stato eseguito il wrapping insieme ad alcuni metadati di crittografia aggiuntivi viene interpolata con i dati crittografati.
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 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 dei messaggi
Poiché i messaggi in coda possono essere in qualsiasi formato, la libreria client definisce un formato personalizzato che include il vettore di inizializzazione (IV) e la chiave di crittografia del contenuto crittografato (CEK) nel testo del messaggio.
Durante la crittografia, la libreria client genera un vettore di inizializzazione casuale di 16 byte con una CEK casuale di 32 byte ed esegue la crittografia envelope del testo del messaggio in coda utilizzando queste informazioni. Al messaggio in coda crittografato vengono quindi aggiunti la CEK con wrapping e alcuni metadati di crittografia aggiuntivi. Questo messaggio modificato viene archiviato nel servizio.
<MessageText>{"EncryptedMessageContents":"6kOu8Rq1C3+M1QO4alKLmWthWXSmHV3mEfxBAgP9QGTU++MKn2uPq3t2UjF1DO6w","EncryptionData":{…}}</MessageText>
Durante la decrittografia, la chiave con wrapping viene estratta dal messaggio in coda e sottoposta a rimozione del wrapping. Anche il vettore di inizializzazione viene estratto dal messaggio in coda e utilizzato con la chiave senza wrapping per decrittografare i dati del messaggio in coda. I metadati di crittografia sono di piccole dimensioni (inferiori a 500 byte), quindi mentre vengono tenuti in considerazione per il limite di 64 KB di un messaggio in coda, l'impatto dovrebbe essere gestibile. Il messaggio crittografato è con codifica Base64, come illustrato nel frammento di codice precedente, che espande le dimensioni del messaggio inviato.
A causa della natura breve dei messaggi nella coda, la decrittografia e la re-crittografia dei messaggi della coda dopo l'aggiornamento alla crittografia lato client v2 non devono essere necessarie. Qualsiasi messaggio meno sicuro viene ruotato nel corso del normale consumo di code.
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.