Client-Side Encryption i Azure Key Vault for Microsoft Azure Storage

Omówienie

Biblioteka klienta platformy Azure Storage dla platformy .NET obsługuje szyfrowanie danych w aplikacjach klienckich przed przekazaniem do usługi Azure Storage i odszyfrowywaniem danych podczas pobierania do klienta. Biblioteka obsługuje również integrację z usługą Azure Key Vault na potrzeby zarządzania kluczami konta magazynu.

Aby zapoznać się z samouczkiem krok po kroku, który prowadzi do procesu szyfrowania obiektów blob przy użyciu szyfrowania po stronie klienta i usługi Azure Key Vault, zobacz Szyfrowanie i odszyfrowywanie obiektów blob w Microsoft Azure Storage przy użyciu usługi Azure Key Vault.

Aby uzyskać informacje na temat szyfrowania po stronie klienta za pomocą języka Java, zobacz Szyfrowanie po stronie klienta za pomocą języka Java dla Microsoft Azure Storage.

Szyfrowanie i odszyfrowywanie za pomocą techniki koperty

Procesy szyfrowania i odszyfrowywania są zgodne z techniką koperty.

Szyfrowanie za pośrednictwem techniki koperty

Szyfrowanie za pośrednictwem techniki koperty działa w następujący sposób:

  1. Biblioteka klienta usługi Azure Storage generuje klucz szyfrowania zawartości (CEK), który jest jednorazowym kluczem symetrycznym.

  2. Dane użytkownika są szyfrowane przy użyciu tego klucza CEK.

  3. Klucz CEK jest następnie opakowany (zaszyfrowany) przy użyciu klucza szyfrowania kluczy (KEK). Klucz KEK jest identyfikowany przez identyfikator klucza i może być parą kluczy asymetrycznych lub kluczem symetrycznym i może być zarządzany lokalnie lub przechowywany w usłudze Azure Key Vault.

    Sama biblioteka klienta magazynu nigdy nie ma dostępu do klucza KEK. Biblioteka wywołuje algorytm opakowujący klucze udostępniany przez Key Vault. Użytkownicy mogą w razie potrzeby używać dostawców niestandardowych do opakowywania kluczy/rozpakowywania.

  4. Zaszyfrowane dane są następnie przekazywane do usługi Azure Storage. Opakowany klucz wraz z dodatkowymi metadanymi szyfrowania jest przechowywany jako metadane (na obiekcie blob) lub interpolowany przy użyciu zaszyfrowanych danych (komunikaty kolejki i jednostki tabeli).

Odszyfrowywanie za pomocą techniki koperty

Odszyfrowywanie za pośrednictwem techniki koperty działa w następujący sposób:

  1. Biblioteka klienta zakłada, że użytkownik zarządza kluczem szyfrowania kluczy (KEK) lokalnie lub w usłudze Azure Key Vault. Użytkownik nie musi znać określonego klucza, który został użyty do szyfrowania. Zamiast tego można skonfigurować i użyć narzędzia rozpoznawania kluczy, który rozpoznaje różne identyfikatory kluczy kluczy.
  2. Biblioteka kliencka pobiera zaszyfrowane dane wraz z dowolnym materiałem szyfrowania przechowywanym w usłudze.
  3. Opakowany klucz szyfrowania zawartości (CEK) jest następnie odszyfrowywany (odszyfrowany) przy użyciu klucza szyfrowania kluczy (KEK). Ponownie biblioteka klienta nie ma dostępu do klucza KEK. Po prostu wywołuje niestandardowy lub Key Vault algorytm rozpasywania dostawcy.
  4. Klucz szyfrowania zawartości (CEK) jest następnie używany do odszyfrowywania zaszyfrowanych danych użytkownika.

Mechanizm szyfrowania

Biblioteka klienta magazynu używa usługi AES w celu szyfrowania danych użytkownika. W szczególności tryb łańcucha bloków szyfrowania (CBC) z AES. Każda usługa działa nieco inaczej, więc omówimy każdy z nich tutaj.

Obiekty blob

Biblioteka kliencka obsługuje obecnie tylko szyfrowanie całych obiektów blob. W przypadku pobierania obsługiwane są zarówno pełne pliki, jak i pliki do pobrania z zakresu.

Podczas szyfrowania biblioteka klienta wygeneruje losowy wektor inicjowania (IV) 16 bajtów wraz z losowym kluczem szyfrowania zawartości (CEK) 32 bajtów i wykona szyfrowanie kopert danych obiektu blob przy użyciu tych informacji. Opakowany klucz CEK i niektóre dodatkowe metadane szyfrowania są następnie przechowywane jako metadane obiektów blob wraz z zaszyfrowanym obiektem blob w usłudze.

Ostrzeżenie

Jeśli edytujesz lub przekażesz własne metadane dla obiektu blob, musisz upewnić się, że te metadane są zachowywane. Jeśli przekażesz nowe metadane bez tych metadanych, opakowany klucz CEK, IV i inne metadane zostaną utracone, a zawartość obiektu blob nigdy nie będzie można ponownie pobrać.

Podczas pobierania całego obiektu blob opakowany klucz CEK jest rozpakuwany i używany wraz z iv (przechowywanymi jako metadane obiektu blob w tym przypadku) w celu zwrócenia odszyfrowanych danych do użytkowników.

Pobranie dowolnego zakresu w zaszyfrowanym obiekcie blob obejmuje dostosowanie zakresu dostarczonego przez użytkowników w celu uzyskania niewielkiej ilości dodatkowych danych, których można użyć do pomyślnego odszyfrowywania żądanego zakresu.

Wszystkie typy obiektów blob (blokowe obiekty blob, stronicowe obiekty blob i uzupełnialne obiekty blob) można szyfrować/odszyfrowywać przy użyciu tego schematu.

Kolejki

Ponieważ komunikaty w kolejce mogą mieć dowolny format, biblioteka klienta definiuje niestandardowy format zawierający wektor inicjowania (IV) i zaszyfrowany klucz szyfrowania zawartości (CEK) w tekście wiadomości.

Podczas szyfrowania biblioteka klienta generuje losowy iv z 16 bajtów wraz z losowym kluczem CEK 32 bajtów i wykonuje szyfrowanie kopert tekstu komunikatu kolejki przy użyciu tych informacji. Opakowany klucz CEK i niektóre dodatkowe metadane szyfrowania są następnie dodawane do zaszyfrowanego komunikatu kolejki. Ten zmodyfikowany komunikat (pokazany poniżej) jest przechowywany w usłudze.

<MessageText>{"EncryptedMessageContents":"6kOu8Rq1C3+M1QO4alKLmWthWXSmHV3mEfxBAgP9QGTU++MKn2uPq3t2UjF1DO6w","EncryptionData":{…}}</MessageText>

Podczas odszyfrowywania opakowany klucz jest wyodrębniany z komunikatu kolejki i rozpakowany. Iv jest również wyodrębniany z komunikatu kolejki i używany wraz z kluczem niezapisanym w celu odszyfrowania danych komunikatów kolejki. Należy pamiętać, że metadane szyfrowania są małe (poniżej 500 bajtów), więc mimo że wlicza się do limitu 64 KB dla komunikatu w kolejce, wpływ powinien być możliwy do zarządzania. Należy pamiętać, że zaszyfrowany komunikat będzie zakodowany w formacie base64, jak pokazano w powyższym fragmencie kodu, co spowoduje również zwiększenie rozmiaru wysyłanego komunikatu.

tabelami

Uwaga

Usługa Table Service jest obsługiwana w bibliotece klienta usługi Azure Storage tylko w wersji 9.x.

Biblioteka kliencka obsługuje szyfrowanie właściwości jednostki na potrzeby operacji wstawiania i zastępowania.

Uwaga

Scalanie nie jest obecnie obsługiwane. Ponieważ podzbiór właściwości mógł zostać wcześniej zaszyfrowany przy użyciu innego klucza, po prostu scalanie nowych właściwości i aktualizowanie metadanych spowoduje utratę danych. Scalanie wymaga wykonania dodatkowych wywołań usługi w celu odczytania wstępnie istniejącej jednostki z usługi lub użycia nowego klucza na właściwość, z których oba nie są odpowiednie ze względów wydajności.

Szyfrowanie danych tabeli działa w następujący sposób:

  1. Użytkownicy określają właściwości, które mają być szyfrowane.
  2. Biblioteka klienta generuje losowy wektor inicjowania (IV) 16 bajtów wraz z losowym kluczem szyfrowania zawartości (CEK) 32 bajtów dla każdej jednostki i wykonuje szyfrowanie koperty dla poszczególnych właściwości, które mają być szyfrowane przez wyprowadzenie nowej właściwości IV na właściwość. Zaszyfrowana właściwość jest przechowywana jako dane binarne.
  3. Opakowany klucz CEK i niektóre dodatkowe metadane szyfrowania są następnie przechowywane jako dwie dodatkowe właściwości zarezerwowane. Pierwsza właściwość zarezerwowana (_ClientEncryptionMetadata1) to właściwość ciągu, która przechowuje informacje o iv, wersji i opakowanym kluczu. Druga właściwość zarezerwowana (_ClientEncryptionMetadata2) to właściwość binarna, która przechowuje informacje o zaszyfrowanych właściwościach. Informacje w tej drugiej właściwości (_ClientEncryptionMetadata2) są szyfrowane.
  4. Ze względu na te dodatkowe właściwości zarezerwowane wymagane do szyfrowania użytkownicy mogą teraz mieć tylko 250 właściwości niestandardowych zamiast 252. Całkowity rozmiar jednostki musi być mniejszy niż 1 MB.

Należy pamiętać, że można zaszyfrować tylko właściwości ciągu. Jeśli inne typy właściwości mają być szyfrowane, należy je przekonwertować na ciągi. Zaszyfrowane ciągi są przechowywane w usłudze jako właściwości binarne i są konwertowane z powrotem na ciągi po odszyfrowaniu.

W przypadku tabel oprócz zasad szyfrowania użytkownicy muszą określić właściwości, które mają być szyfrowane. Można to zrobić, określając atrybut [EncryptProperty] (dla jednostek POCO, które pochodzą z tabeli TableEntity) lub rozpoznawania szyfrowania w opcjach żądania. Rozpoznawanie szyfrowania to delegat, który przyjmuje klucz partycji, klucz wiersza i nazwę właściwości oraz zwraca wartość logiczną wskazującą, czy ta właściwość ma być zaszyfrowana. Podczas szyfrowania biblioteka kliencka użyje tych informacji, aby zdecydować, czy właściwość powinna być szyfrowana podczas zapisywania w sieci. Delegat zapewnia również możliwość logiki dotyczącej sposobu szyfrowania właściwości. (Jeśli na przykład X, szyfruj właściwość A; w przeciwnym razie szyfruj właściwości A i B). Należy pamiętać, że nie jest konieczne podanie tych informacji podczas odczytywania ani wykonywania zapytań dotyczących jednostek.

Operacje wsadowe

W operacjach wsadowych ten sam klucz KEK będzie używany we wszystkich wierszach w tej operacji wsadowej, ponieważ biblioteka kliencka zezwala tylko na jeden obiekt opcji (a tym samym jeden klucz zasad/KEK) na operację wsadową. Jednak biblioteka klienta wewnętrznie wygeneruje nowy losowy klucz IV i losowy klucz CEK na wiersz w partii. Użytkownicy mogą również wybrać szyfrowanie różnych właściwości dla każdej operacji w partii, definiując to zachowanie w narzędziu rozpoznawania szyfrowania.

Zapytania

Uwaga

Ponieważ jednostki są szyfrowane, nie można uruchamiać zapytań filtrujących dla zaszyfrowanej właściwości. Jeśli spróbujesz, wyniki będą niepoprawne, ponieważ usługa próbuje porównać zaszyfrowane dane z niezaszyfrowanymi danymi.

Aby wykonać operacje zapytań, należy określić klucz rozpoznawania, który może rozpoznać wszystkie klucze w zestawie wyników. Jeśli nie można rozpoznać jednostki zawartej w wyniku zapytania dla dostawcy, biblioteka klienta zgłosi błąd. W przypadku każdego zapytania, które wykonuje projekcje po stronie serwera, biblioteka klienta doda specjalne właściwości metadanych szyfrowania (_ClientEncryptionMetadata1 i _ClientEncryptionMetadata2) domyślnie do wybranych kolumn.

Azure Key Vault

Usługa Azure Key Vault ułatwia ochronę kluczy kryptograficznych i kluczy tajnych używanych przez aplikacje i usługi w chmurze. Za pomocą usługi Azure Key Vault użytkownicy mogą szyfrować klucze i wpisy tajne (takie jak klucze uwierzytelniania, klucze konta magazynu, klucze szyfrowania danych, . Pliki PFX i hasła) przy użyciu kluczy chronionych przez sprzętowe moduły zabezpieczeń (HSM). Aby uzyskać więcej informacji, zobacz Co to jest usługa Azure Key Vault?.

Biblioteka klienta magazynu używa interfejsów Key Vault w podstawowej bibliotece, aby zapewnić wspólną strukturę na platformie Azure na potrzeby zarządzania kluczami. Użytkownicy mogą korzystać z bibliotek Key Vault dla wszystkich dodatkowych korzyści, które zapewniają, takich jak przydatne funkcje dotyczące prostych i bezproblemowych dostawców kluczy lokalnych/RSA/ Symmetric/RSA, a także pomoc w agregacji i buforowaniu.

Interfejs i zależności

Istnieją dwa niezbędne pakiety do integracji Key Vault:

  • Azure.Core zawiera IKeyEncryptionKey interfejsy i IKeyEncryptionKeyResolver . Biblioteka klienta magazynu dla platformy .NET już definiuje ją jako zależność.
  • Azure.Security.KeyVault.Keys (wersja 4.x) zawiera klienta REST Key Vault, a także klientów kryptograficznych używanych z szyfrowaniem po stronie klienta.

Key Vault jest przeznaczony dla kluczy głównych o wysokiej wartości, a limity ograniczania przepustowości na Key Vault są zaprojektowane z myślą o tym. Od wersji Azure.Security.KeyVault.Keys 4.1.0 nie IKeyEncryptionKeyResolver ma implementacji obsługującej buforowanie kluczy. Jeśli buforowanie jest konieczne ze względu na ograniczanie przepustowości, można wykonać czynności opisane w tym przykładzieAzure.Security.KeyVault.Keys.Cryptography.KeyResolver w celu wstrzyknięcia warstwy buforowania do wystąpienia.

Najlepsze rozwiązania

Obsługa szyfrowania jest dostępna tylko w bibliotece klienta magazynu dla platformy .NET. Windows Phone i środowisko wykonawcze systemu Windows nie obsługują obecnie szyfrowania.

Ważne

Należy pamiętać o tych ważnych kwestiach podczas korzystania z szyfrowania po stronie klienta:

  • Podczas odczytywania lub zapisywania w zaszyfrowanym obiekcie blob użyj całych poleceń przekazywania obiektów blob i poleceń pobierania zakresu/całego obiektu blob. Unikaj zapisywania w zaszyfrowanym obiekcie blob przy użyciu operacji protokołu, takich jak Put Block, Put Block List, Write Pages, Clear Pages lub Append Block; w przeciwnym razie możesz uszkodzić zaszyfrowany obiekt blob i uczynić go nieczytelnym.
  • W przypadku tabel istnieje podobne ograniczenie. Należy zachować ostrożność, aby nie aktualizować zaszyfrowanych właściwości bez aktualizowania metadanych szyfrowania.
  • Jeśli ustawisz metadane zaszyfrowanego obiektu blob, możesz zastąpić metadane związane z szyfrowaniem wymagane do odszyfrowywania, ponieważ ustawienie metadanych nie jest dodawane. Dotyczy to również migawek; unikaj określania metadanych podczas tworzenia migawki zaszyfrowanego obiektu blob. Jeśli należy ustawić metadane, najpierw wywołaj metodę FetchAttributes , aby uzyskać bieżące metadane szyfrowania i uniknąć współbieżnych zapisów podczas ustawiania metadanych.
  • Włącz właściwość RequireEncryption w domyślnych opcjach żądania dla użytkowników, którzy powinni pracować tylko z zaszyfrowanymi danymi. Aby uzyskać więcej informacji, zobacz poniżej.

Interfejs API/interfejs klienta

Użytkownicy mogą podać tylko klucz, tylko program rozpoznawania lub oba te elementy. Klucze są identyfikowane przy użyciu identyfikatora klucza i zapewniają logikę opakowywania/rozpakowywania. Narzędzia rozpoznawania są używane do rozpoznawania klucza podczas procesu odszyfrowywania. Definiuje metodę rozpoznawania, która zwraca klucz przy użyciu identyfikatora klucza. Zapewnia to użytkownikom możliwość wyboru między wieloma kluczami zarządzanymi w wielu lokalizacjach.

  • W przypadku szyfrowania klucz jest zawsze używany, a brak klucza spowoduje wystąpienie błędu.
  • W przypadku odszyfrowywania:
    • Jeśli klucz jest określony i jego identyfikator jest zgodny z wymaganym identyfikatorem klucza, ten klucz jest używany do odszyfrowywania. W przeciwnym razie podjęto próbę rozwiązania. Jeśli nie ma narzędzia rozpoznawania dla tej próby, zostanie zgłoszony błąd.
    • Rozpoznawanie kluczy jest wywoływane, jeśli zostanie określony w celu pobrania klucza. Jeśli program rozpoznawania jest określony, ale nie ma mapowania identyfikatora klucza, zgłaszany jest błąd.

RequireEncryption mode (tylko wersja 11)

Użytkownicy mogą opcjonalnie włączyć tryb działania, w którym wszystkie operacje przekazywania i pobierania muszą być szyfrowane. W tym trybie próba przekazania danych bez zasad szyfrowania lub pobranie danych, które nie są zaszyfrowane w usłudze, zakończy się niepowodzeniem na kliencie. Właściwość RequireEncryption obiektu opcji żądania kontroluje to zachowanie. Jeśli aplikacja zaszyfruje wszystkie obiekty przechowywane w usłudze Azure Storage, możesz ustawić właściwość RequireEncryption w domyślnych opcjach żądania dla obiektu klienta usługi. Na przykład ustaw parametr CloudBlobClient.DefaultRequestOptions.RequireEncryption na wartość true , aby wymagać szyfrowania dla wszystkich operacji obiektów blob wykonywanych za pośrednictwem tego obiektu klienta.

Szyfrowanie usługi Blob Service

Utwórz obiekt ClientSideEncryptionOptions i ustaw go podczas tworzenia klienta za pomocą polecenia SpecializedBlobClientOptions. Nie można ustawić opcji szyfrowania dla poszczególnych interfejsów API. Wszystkie inne elementy będą obsługiwane wewnętrznie przez bibliotekę klienta.

// Your key and key resolver instances, either through KeyVault 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.V1_0)
{
   KeyEncryptionKey = key,
   KeyResolver = keyResolver,
   // string the storage client will use when calling IKeyEncryptionKey.WrapKey()
   KeyWrapAlgorithm = "some algorithm name"
};

// Set the encryption options on the client options
BlobClientOptions options = new SpecializedBlobClientOptions() { ClientSideEncryption = encryptionOptions };

// Get your blob client with client-side encryption enabled.
// Client-side encryption options are passed from service to container clients, and container 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);

Obiekt BlobServiceClient nie jest niezbędny do zastosowania opcji szyfrowania. Można je również przekazać do konstruktorów BlobContainerClientBlobClient/, które akceptują obiekty BlobClientOptions.

Jeśli żądany obiekt BlobClient już istnieje, ale bez opcji szyfrowania po stronie klienta, istnieje metoda rozszerzenia, aby utworzyć kopię tego obiektu przy użyciu danego obiektu ClientSideEncryptionOptions. Ta metoda rozszerzenia pozwala uniknąć nakładu pracy nad konstruowaniem nowego obiektu BlobClient od podstaw.

using Azure.Storage.Blobs.Specialized;

// Your existing BlobClient instance and encryption options
BlobClient plaintextBlob;
ClientSideEncryptionOptions encryptionOptions;

// Get a copy of plaintextBlob that uses client-side encryption
BlobClient clientSideEncryptionBlob = plaintextBlob.WithClientSideEncryptionOptions(encryptionOptions);

Szyfrowanie usługi kolejki

Utwórz obiekt ClientSideEncryptionOptions i ustaw go podczas tworzenia klienta za pomocą polecenia SpecializedQueueClientOptions. Nie można ustawić opcji szyfrowania dla poszczególnych interfejsów API. Wszystkie inne elementy będą obsługiwane wewnętrznie przez bibliotekę klienta.

// Your key and key resolver instances, either through KeyVault 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.V1_0)
{
   KeyEncryptionKey = key,
   KeyResolver = keyResolver,
   // string the storage client will use when calling IKeyEncryptionKey.WrapKey()
   KeyWrapAlgorithm = "some algorithm name"
};

// Set the encryption options on the client options
QueueClientOptions options = new SpecializedQueueClientOptions() { ClientSideEncryption = encryptionOptions };

// Get your queue client with client-side encryption enabled.
// Client-side encryption options are passed from service to queue clients.
QueueClient queue = new QueueServiceClient(connectionString, options).GetQueueClient("myQueue");

// Send an encrypted queue message.
queue.SendMessage("Hello, World!");

// Download queue messages, decrypting ones that are detected to be encrypted
QueueMessage[] queue.ReceiveMessages(); 

Element QueueServiceClient nie jest niezbędny do zastosowania opcji szyfrowania. Można je również przekazać do konstruktorów QueueClient , które akceptują obiekty QueueClientOptions .

Jeśli żądany obiekt QueueClient już istnieje, ale bez opcji szyfrowania po stronie klienta, istnieje metoda rozszerzenia, aby utworzyć kopię tego obiektu przy użyciu danego obiektu ClientSideEncryptionOptions. Ta metoda rozszerzenia pozwala uniknąć narzutów związanych z konstruowaniem nowego obiektu QueueClient od podstaw.

using Azure.Storage.Queues.Specialized;

// Your existing QueueClient instance and encryption options
QueueClient plaintextQueue;
ClientSideEncryptionOptions encryptionOptions;

// Get a copy of plaintextQueue that uses client-side encryption
QueueClient clientSideEncryptionQueue = plaintextQueue.WithClientSideEncryptionOptions(encryptionOptions);

Niektórzy użytkownicy mogą mieć kolejki, w których nie wszystkie odebrane komunikaty można pomyślnie odszyfrować, a klucz lub narzędzie rozpoznawania musi zgłaszać. Ostatni wiersz powyższego przykładu będzie zgłaszany w tym przypadku, a żaden z odebranych komunikatów nie będzie dostępny. W tych scenariuszach podrzędna klasa QueueClientSideEncryptionOptions może służyć do udostępniania opcji szyfrowania klientom. Uwidacznia zdarzenie DecryptionFailed , które zostanie wyzwolone za każdym razem, gdy komunikat kolejki nie zostanie odszyfrowany, o ile do zdarzenia dodano co najmniej jedną wywołanie. W ten sposób można obsłużyć indywidualnie nieudane komunikaty i zostaną one odfiltrowane z końcowej funkcji QueueMessage[] zwróconej przez komunikaty ReceiveMessages.

// Create your encryption options using the sub-class.
QueueClientSideEncryptionOptions encryptionOptions = new QueueClientSideEncryptionOptions(ClientSideEncryptionVersion.V1_0)
{
   KeyEncryptionKey = key,
   KeyResolver = keyResolver,
   // string the storage client will use when calling IKeyEncryptionKey.WrapKey()
   KeyWrapAlgorithm = "some algorithm name"
};

// Add a handler to the DecryptionFailed event.
encryptionOptions.DecryptionFailed += (source, args) => {
   QueueMessage failedMessage = (QueueMessage)source;
   Exception exceptionThrown = args.Exception;
   // do something
};

// Use these options with your client objects.
QueueClient queue = new QueueClient(connectionString, queueName, new SpecializedQueueClientOptions()
{
   ClientSideEncryption = encryptionOptions
});

// Retrieve 5 messages from the queue.
// Assume 5 messages come back and one throws during decryption.
QueueMessage[] messages = queue.ReceiveMessages(maxMessages: 5).Value;
Debug.Assert(messages.Length == 4)

Szyfrowanie usługi Table Service (tylko wersja 11)

Oprócz tworzenia zasad szyfrowania i ustawiania ich w opcjach żądania należy określić atrybut EncryptionResolver w tabeli TableRequestOptions lub ustawić atrybut [EncryptProperty] w jednostce.

Korzystanie z narzędzia rozpoznawania

// Create the IKey used for encryption.
 RsaKey key = new RsaKey("private:key1" /* key identifier */);

 // Create the encryption policy to be used for upload and download.
 TableEncryptionPolicy policy = new TableEncryptionPolicy(key, null);

 TableRequestOptions options = new TableRequestOptions()
 {
    EncryptionResolver = (pk, rk, propName) =>
     {
        if (propName == "foo")
         {
            return true;
         }
         return false;
     },
     EncryptionPolicy = policy
 };

 // Insert Entity
 currentTable.Execute(TableOperation.Insert(ent), options, null);

 // Retrieve Entity
 // No need to specify an encryption resolver for retrieve
 TableRequestOptions retrieveOptions = new TableRequestOptions()
 {
    EncryptionPolicy = policy
 };

 TableOperation operation = TableOperation.Retrieve(ent.PartitionKey, ent.RowKey);
 TableResult result = currentTable.Execute(operation, retrieveOptions, null);

Używanie atrybutów

Jak wspomniano powyżej, jeśli jednostka implementuje wartość TableEntity, właściwości można ozdobić atrybutem [EncryptProperty] zamiast określania właściwości EncryptionResolver.

[EncryptProperty]
 public string EncryptedProperty1 { get; set; }

Szyfrowanie i wydajność

Należy pamiętać, że szyfrowanie danych magazynu powoduje dodatkowe obciążenie wydajności. Klucz zawartości i iv muszą być generowane, sama zawartość musi być zaszyfrowana, a dodatkowe metadane muszą być sformatowane i przekazane. To obciążenie będzie się różnić w zależności od ilości zaszyfrowanych danych. Zalecamy, aby klienci zawsze testowali swoje aplikacje pod kątem wydajności podczas opracowywania.

Następne kroki