Kryptering på klientsidan för blobar
Azure Blob Storage-klientbiblioteket för .NET stöder kryptering av data i klientprogram innan de laddas upp till Azure Storage och dekrypterar data vid nedladdning till klienten. Biblioteket stöder även integrering med Azure Key Vault för nyckelhantering av lagringskonton.
Viktigt!
Blob Storage stöder både kryptering på tjänstsidan och på klientsidan. I de flesta scenarier rekommenderar Microsoft att du använder krypteringsfunktioner på tjänstsidan för enkel användning för att skydda dina data. Mer information om kryptering på tjänstsidan finns i Azure Storage-kryptering för vilande data.
En stegvis självstudiekurs som leder dig genom processen att kryptera blobar med kryptering på klientsidan och Azure Key Vault finns i Kryptera och dekryptera blobar i Microsoft Azure Storage med hjälp av Azure Key Vault.
Om kryptering på klientsidan
Azure Blob Storage-klientbiblioteket använder Advanced Encryption Standard (AES) för att kryptera användardata. Det finns två versioner av kryptering på klientsidan i klientbiblioteket:
- Version 2 använder GCM-läge (Galois/Counter Mode) med AES.
- Version 1 använder CBC-läge (Cipher Block Chaining) med AES.
Varning
Användning av version 1 av kryptering på klientsidan rekommenderas inte längre på grund av en säkerhetsrisk i klientbibliotekets implementering av CBC-läge. Mer information om den här säkerhetsrisken finns i Azure Storage som uppdaterar kryptering på klientsidan i SDK för att åtgärda säkerhetsrisker. Om du använder version 1 rekommenderar vi att du uppdaterar programmet så att det använder version 2 och migrerar dina data. Mer information finns i följande avsnitt: Åtgärda säkerhetsrisken i dina program.
Minska säkerhetsrisken i dina program
På grund av en säkerhetsrisk som identifieras i Blob Storage-klientbibliotekets implementering av CBC-läget rekommenderar Microsoft att du vidtar en eller flera av följande åtgärder omedelbart:
Överväg att använda krypteringsfunktioner på tjänstsidan i stället för kryptering på klientsidan. Mer information om krypteringsfunktioner på tjänstsidan finns i Azure Storage-kryptering för vilande data.
Om du behöver använda kryptering på klientsidan migrerar du dina program från kryptering på klientsidan v1 till kryptering på klientsidan v2.
I följande tabell sammanfattas de steg som ska utföras om du väljer att migrera dina program till kryptering på klientsidan v2:
| Krypteringsstatus på klientsidan | Rekommenderade åtgärder |
|---|---|
| Programmet använder kryptering på klientsidan en version av klientbiblioteket som endast stöder kryptering på klientsidan v1. | Uppdatera programmet så att det använder en version av klientbiblioteket som stöder kryptering på klientsidan v2. En lista över versioner som stöds finns i SDK-stödmatrisen för kryptering på klientsidan. Läs mer ... Uppdatera koden så att den använder kryptering på klientsidan v2. Läs mer ... Ladda ned krypterade data för att dekryptera dem och kryptera sedan om dem med kryptering på klientsidan v2. Läs mer ... |
| Programmet använder kryptering på klientsidan med en version av klientbiblioteket som stöder kryptering på klientsidan v2. | Uppdatera koden så att den använder kryptering på klientsidan v2. Läs mer ... Ladda ned krypterade data för att dekryptera dem och kryptera sedan om dem med kryptering på klientsidan v2. Läs mer ... |
Dessutom rekommenderar Microsoft att du vidtar följande steg för att skydda dina data:
- Konfigurera dina lagringskonton så att de använder privata slutpunkter för att skydda all trafik mellan ditt virtuella nätverk (VNet) och ditt lagringskonto via en privat länk. Mer information finns i Använda privata slutpunkter för Azure Storage.
- Begränsa endast nätverksåtkomst till specifika nätverk.
SDK-stödmatris för kryptering på klientsidan
I följande tabell visas vilka versioner av klientbiblioteken för .NET, Java och Python som stöder olika versioner av kryptering på klientsidan:
| .NET | Java | Python | |
|---|---|---|---|
| Kryptering på klientsidan v2 och v1 | Version 12.13.0 och senare | Version 12.18.0 och senare | Version 12.13.0 och senare |
| Endast kryptering på klientsidan v1 | Versioner 12.12.0 och tidigare | Version 12.17.0 och tidigare | Versioner 12.12.0 och tidigare |
Kommentar
Kryptering på klientsidan v2.1 är tillgängligt i Java SDK för version 12.27.0 och senare. Med den här versionen kan du konfigurera regionlängden för autentiserad kryptering, från 16 byte till 1 GiB. Mer information finns i Java-exemplet i Exempel: Kryptera och dekryptera en blob med kryptering på klientsidan v2.
Om ditt program använder kryptering på klientsidan med en tidigare version av .NET-, Java- eller Python-klientbiblioteket måste du först uppgradera koden till en version som stöder kryptering på klientsidan v2. Därefter måste du dekryptera och kryptera om dina data med kryptering på klientsidan v2. Om det behövs kan du använda en version av klientbiblioteket som stöder kryptering på klientsidan v2 sida vid sida med en tidigare version av klientbiblioteket medan du migrerar koden. Kodexempel finns i Exempel: Kryptera och dekryptera en blob med kryptering på klientsidan v2.
Så här fungerar kryptering på klientsidan
Azure Blob Storage-klientbiblioteken använder kuvertkryptering för att kryptera och dekryptera dina data på klientsidan. Kuvertkryptering krypterar en nyckel med en eller flera ytterligare nycklar.
Blob Storage-klientbiblioteken förlitar sig på Azure Key Vault för att skydda de nycklar som används för kryptering på klientsidan. Mer information om Azure Key Vault finns i Vad är Azure Key Vault?.
Kryptering och dekryptering via kuverttekniken
Kryptering via kuverttekniken fungerar på följande sätt:
Azure Storage-klientbiblioteket genererar en innehållskrypteringsnyckel (CEK), som är en symmetrisk nyckel för engångsanvändning.
Användardata krypteras med hjälp av CEK.
CEK omsluts sedan (krypteras) med nyckelkrypteringsnyckeln (KEK). KEK identifieras av en nyckelidentifierare och kan vara antingen ett asymmetriskt nyckelpar eller en symmetrisk nyckel. Du kan hantera KEK lokalt eller lagra den i ett Azure Key Vault.
Själva Azure Storage-klientbiblioteket har aldrig åtkomst till KEK. Biblioteket anropar nyckelomslutningsalgoritmen som tillhandahålls av Key Vault. Användare kan välja att använda anpassade providers för nyckelomslutning/avskrivning om så önskas.
Krypterade data laddas sedan upp till Azure Blob Storage. Den omslutna nyckeln tillsammans med ytterligare krypteringsmetadata lagras som metadata på bloben.
Dekryptering via kuverttekniken fungerar på följande sätt:
- Azure Storage-klientbiblioteket förutsätter att användaren hanterar KEK antingen lokalt eller i ett Azure Key Vault. Användaren behöver inte känna till den specifika nyckel som användes för kryptering. I stället kan en nyckellösare som löser olika nyckelidentifierare till nycklar konfigureras och användas.
- Klientbiblioteket laddar ned krypterade data tillsammans med krypteringsmaterial som lagras i Azure Storage.
- Den omslutna CEK:en packas sedan upp (dekrypteras) med hjälp av KEK. Klientbiblioteket har inte åtkomst till KEK under den här processen, men anropar bara algoritmen för att packa upp i Azure Key Vault eller något annat nyckelarkiv.
- Klientbiblioteket använder CEK för att dekryptera krypterade användardata.
Kryptering/dekryptering vid blobuppladdning/nedladdning
Blob Storage-klientbiblioteket stöder endast kryptering av hela blobar vid uppladdning. För nedladdningar stöds både fullständiga nedladdningar och intervallnedladdningar. Kryptering på klientsidan v2 delar upp data i 4 MiB-buffrade autentiserade krypteringsblock som bara kan omvandlas helt. Om du vill justera segmentstorleken kontrollerar du att du använder den senaste versionen av SDK som stöder kryptering på klientsidan v2.1. Regionlängden kan konfigureras från 16 byte upp till 1 GiB.
Under krypteringen genererar klientbiblioteket en slumpmässig initieringsvektor (IV) på 16 byte och en slumpmässig CEK på 32 byte och utför kuvertkryptering av blobdata med hjälp av den här informationen. Den omslutna CEK:en och några ytterligare krypteringsmetadata lagras sedan som blobmetadata tillsammans med den krypterade bloben.
När en klient laddar ned en hel blob packas den omslutna CEK:en upp och används tillsammans med IV för att returnera de dekrypterade data till klienten.
Att ladda ned ett godtyckligt intervall i den krypterade bloben innebär att justera det intervall som tillhandahålls av användare för att få en liten mängd ytterligare data som kan användas för att dekryptera det begärda intervallet.
Alla blobtyper (blockblobar, sidblobar och tilläggsblobar) kan krypteras/dekrypteras med det här schemat.
Varning
Om du redigerar eller laddar upp dina egna metadata för bloben måste du se till att krypteringsmetadata bevaras. Om du laddar upp nya metadata utan att också bevara krypteringsmetadata kommer den omslutna CEK, IV och andra metadata att gå förlorade och du kommer inte att kunna hämta innehållet i bloben. Om du anropar åtgärden Ange blobmetadata ersätts alltid alla blobmetadata.
När du läser från eller skriver till en krypterad blob använder du hela blobuppladdningskommandon, till exempel Placera blob och intervall eller hela blobnedladdningskommandon, till exempel Hämta blob. Undvik att skriva till en krypterad blob med protokollåtgärder som Put Block, Put Block List, Put Page eller Addd Block. Att anropa dessa åtgärder på en krypterad blob kan skada den och göra den oläslig.
Exempel: Kryptera och dekryptera en blob med kryptering på klientsidan v2
Kodexemplet i det här avsnittet visar hur du använder kryptering på klientsidan v2 för att kryptera och dekryptera en blob.
Viktigt!
Om du har data som tidigare har krypterats med kryptering på klientsidan v1 måste du dekryptera dessa data och kryptera dem igen med kryptering på klientsidan v2. Se vägledningen och exemplet för klientbiblioteket nedan.
Om du vill använda kryptering på klientsidan från .NET-koden refererar du till Blob Storage-klientbiblioteket. Kontrollera att du använder version 12.13.0 eller senare. Om du behöver migrera från version 11.x till version 12.13.0 läser du migreringsguiden.
Två ytterligare paket krävs för Azure Key Vault-integrering för kryptering på klientsidan:
Azure.Core-paketet innehåller gränssnitten
IKeyEncryptionKeyochIKeyEncryptionKeyResolver. Blob Storage-klientbiblioteket för .NET definierar redan den här sammansättningen som ett beroende.Paketet Azure.Security.KeyVault.Keys (version 4.x och senare) tillhandahåller Key Vault REST-klienten och de kryptografiska klienter som används med kryptering på klientsidan. Kontrollera att det här paketet refereras till i projektet om du använder Azure Key Vault som nyckelarkiv.
Azure Key Vault är utformat för huvudnycklar med högt värde, och begränsningsgränser per nyckelvalv återspeglar den här designen. Från och med version 4.1.0 av Azure.Security.KeyVault.Keys
IKeyEncryptionKeyResolverstöder gränssnittet inte cachelagring av nycklar. Om cachelagring krävs på grund av begränsning kan du använda den metod som visas i det här exemplet för att mata in ett cachelagringslager i enAzure.Security.KeyVault.Keys.Cryptography.KeyResolverinstans.
Utvecklare kan tillhandahålla en nyckel, en nyckellösare eller både en nyckel och en nyckellösare. Nycklar identifieras med hjälp av en nyckelidentifierare som tillhandahåller logiken för omslutning och avskrivning av CEK. En nyckellösare används för att lösa en nyckel under dekrypteringsprocessen. Nyckellösaren definierar en lösningsmetod som returnerar en nyckel med en nyckelidentifierare. Med lösaren kan användarna välja mellan flera nycklar som hanteras på flera platser.
Vid kryptering används alltid nyckeln och avsaknaden av en nyckel resulterar i ett fel.
Vid dekryptering, om nyckeln har angetts och dess identifierare matchar den nödvändiga nyckelidentifieraren, används den nyckeln för dekryptering. Annars försöker klientbiblioteket anropa matcharen. Om ingen lösning har angetts utlöser klientbiblioteket ett fel. Om en lösning har angetts anropas nyckellösaren för att hämta nyckeln. Om matcharen har angetts men inte har någon mappning för nyckelidentifieraren utlöser klientbiblioteket ett fel.
Om du vill använda kryptering på klientsidan skapar du ett ClientSideEncryptionOptions-objekt och ställer in det när klienten skapas med SpecializedBlobClientOptions. Du kan inte ange krypteringsalternativ per API. Allt annat hanteras av klientbiblioteket internt.
// 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);
Du kan använda krypteringsalternativ för en BlobServiceClient-, BlobContainerClient- eller BlobClient-konstruktor som accepterar BlobClientOptions-objekt .
Om det redan finns ett BlobClient-objekt i koden men saknar krypteringsalternativ på klientsidan kan du använda en tilläggsmetod för att skapa en kopia av objektet med angivna ClientSideEncryptionOptions. Den här tilläggsmetoden undviker att skapa ett nytt BlobClient-objekt från grunden.
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);
När du har uppdaterat koden för att använda kryptering på klientsidan v2 kontrollerar du att du dekrypterar och krypterar om befintliga krypterade data enligt beskrivningen i Kryptera om tidigare krypterade data med kryptering på klientsidan v2.
Kryptera om tidigare krypterade data med kryptering på klientsidan v2
Alla data som tidigare krypterats med kryptering på klientsidan v1 måste dekrypteras och sedan krypteras igen med kryptering på klientsidan v2 för att minska säkerhetsrisken. Dekryptering kräver nedladdning av data och omkryptering kräver att den laddas upp på nytt till Blob Storage.
Ett exempelprojekt som visar hur du migrerar data från kryptering på klientsidan v1 till v2 och hur du krypterar data med kryptering på klientsidan v2 i .NET finns i exempelprojektet krypteringsmigrering.
Kryptering och prestanda på klientsidan
Tänk på att kryptering av lagringsdata resulterar i ytterligare prestandakostnader. När du använder kryptering på klientsidan i ditt program måste klientbiblioteket på ett säkert sätt generera CEK och IV, kryptera själva innehållet, kommunicera med det valda nyckelarkivet för nyckel-omslutning och formatera och ladda upp ytterligare metadata. Den här kostnaden varierar beroende på hur mycket data som krypteras. Vi rekommenderar att kunderna alltid testar sina program för prestanda under utvecklingen.