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 Azure Key Vault per la gestione delle chiavi dell'account di archiviazione.

Informazioni sulla crittografia lato client

La libreria client di Archiviazione code 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.

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 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 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 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 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:

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

2. I dati utente vengono crittografati usando la chiave cek.

3. 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.

4. I dati crittografati vengono quindi caricati in 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:

1. 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.
2. La libreria client scarica i dati crittografati insieme a qualsiasi materiale di crittografia archiviato in Archiviazione di Azure.
3. 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.
4. 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 (illustrato di seguito) 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 dimensioni ridotte (inferiori a 500 byte), quindi mentre viene conteggiato per il limite di 64 KB per un messaggio di coda, l'impatto deve essere gestibile. Il messaggio crittografato è con codifica Base64, come illustrato nel frammento di codice precedente, che espanderà anche le dimensioni del messaggio inviato.

A causa della breve durata dei messaggi nella coda, non è necessario decrittografare e ricrittografare i messaggi della coda dopo l'aggiornamento alla crittografia lato client v2. Qualsiasi messaggio meno sicuro verrà ruotato nel corso del normale consumo di code.

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.

Passaggi successivi

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