Szyfrowanie po stronie klienta dla kolejek
Biblioteki klienta usługi Azure Queue Storage dla platformy .NET i języka Python obsługują szyfrowanie danych w aplikacjach klienckich przed przekazaniem do usługi Azure Storage i odszyfrowywaniem danych podczas pobierania do klienta. Biblioteki klienckie obsługują również integrację z usługą Azure Key Vault na potrzeby zarządzania kluczami konta magazynu.
Ważne
Usługa Azure Storage obsługuje zarówno szyfrowanie po stronie usługi, jak i po stronie klienta. W przypadku większości scenariuszy firma Microsoft zaleca korzystanie z funkcji szyfrowania po stronie usługi w celu ułatwienia korzystania z danych. Aby dowiedzieć się więcej na temat szyfrowania po stronie usługi, zobacz Szyfrowanie usługi Azure Storage dla danych magazynowanych.
Informacje o szyfrowaniu po stronie klienta
Biblioteka klienta usługi Azure Queue Storage używa algorytmu AES do szyfrowania danych użytkownika. W bibliotece klienta są dostępne dwie wersje szyfrowania po stronie klienta:
- Wersja 2 używa trybu Galois/Counter Mode (GCM) z AES.
- Wersja 1 używa trybu łańcucha bloków szyfrowania (CBC) z AES.
Ostrzeżenie
Korzystanie z szyfrowania po stronie klienta w wersji 1 nie jest już zalecane z powodu luki w zabezpieczeniach w implementacji trybu CBC biblioteki klienta. Aby uzyskać więcej informacji na temat tej luki w zabezpieczeniach, zobacz Aktualizowanie szyfrowania po stronie klienta w zestawie SDK w usłudze Azure Storage w celu rozwiązania luk w zabezpieczeniach. Jeśli obecnie używasz wersji 1, zalecamy zaktualizowanie aplikacji do korzystania z wersji 2 i przeprowadzenie migracji danych. Aby uzyskać więcej wskazówek, zobacz następującą sekcję : Ograniczanie luk w zabezpieczeniach w aplikacjach.
Eliminowanie luk w zabezpieczeniach w aplikacjach
Ze względu na lukę w zabezpieczeniach wykrytą w implementacji trybu CBC biblioteki klienta usługi Queue Storage firma Microsoft zaleca natychmiastowe wykonanie co najmniej jednej z następujących czynności:
Rozważ użycie funkcji szyfrowania po stronie usługi zamiast szyfrowania po stronie klienta. Aby uzyskać więcej informacji na temat funkcji szyfrowania po stronie usługi, zobacz Szyfrowanie usługi Azure Storage dla danych magazynowanych.
Jeśli musisz użyć szyfrowania po stronie klienta, przeprowadź migrację aplikacji z szyfrowania po stronie klienta w wersji 1 do szyfrowania po stronie klienta w wersji 2.
Poniższa tabela zawiera podsumowanie czynności, które należy wykonać, jeśli zdecydujesz się przeprowadzić migrację aplikacji do szyfrowania po stronie klienta w wersji 2:
| Stan szyfrowania po stronie klienta | Zalecane akcje |
|---|---|
| Aplikacja używa szyfrowania po stronie klienta wersji biblioteki klienta, która obsługuje tylko szyfrowanie po stronie klienta w wersji 1. | Zaktualizuj aplikację, aby korzystała z wersji biblioteki klienta obsługującej szyfrowanie po stronie klienta w wersji 2. Zobacz Macierz obsługi zestawu SDK dla szyfrowania po stronie klienta , aby zapoznać się z listą obsługiwanych wersji. Zaktualizuj kod, aby używał szyfrowania po stronie klienta w wersji 2. |
| Aplikacja korzysta z szyfrowania po stronie klienta z wersją biblioteki klienta, która obsługuje szyfrowanie po stronie klienta w wersji 2. | Zaktualizuj kod, aby używał szyfrowania po stronie klienta w wersji 2. |
Ponadto firma Microsoft zaleca wykonanie następujących kroków w celu zabezpieczenia danych:
- Skonfiguruj konta magazynu tak, aby używały prywatnych punktów końcowych do zabezpieczania całego ruchu między siecią wirtualną a kontem magazynu za pośrednictwem łącza prywatnego. Aby uzyskać więcej informacji, zobacz Używanie prywatnych punktów końcowych dla usługi Azure Storage.
- Ogranicz dostęp sieciowy tylko do określonych sieci.
Macierz obsługi zestawu SDK dla szyfrowania po stronie klienta
W poniższej tabeli przedstawiono wersje bibliotek klienckich dla platformy .NET i języka Python, które obsługują wersje szyfrowania po stronie klienta:
| .NET | Python | |
|---|---|---|
| Szyfrowanie po stronie klienta w wersji 2 i 1 | Wersje 12.11.0 i nowsze | Wersje 12.4.0 i nowsze |
| Tylko szyfrowanie po stronie klienta w wersji 1 | Wersje 12.10.0 i starsze | Wersje 12.3.0 i starsze |
Jeśli aplikacja używa szyfrowania po stronie klienta z wcześniejszą wersją biblioteki klienta .NET lub Python, należy najpierw uaktualnić kod do wersji obsługującej szyfrowanie po stronie klienta w wersji 2. Następnie należy odszyfrować i ponownie zaszyfrować dane przy użyciu szyfrowania po stronie klienta w wersji 2. W razie potrzeby można użyć wersji biblioteki klienta obsługującej szyfrowanie po stronie klienta w wersji 2 obok wcześniejszej wersji biblioteki klienta podczas migrowania kodu.
Jak działa szyfrowanie po stronie klienta
Biblioteki klienta usługi Azure Queue Storage używają szyfrowania kopert do szyfrowania i odszyfrowywania danych po stronie klienta. Szyfrowanie koperty szyfruje klucz za pomocą co najmniej jednego dodatkowego klucza.
Biblioteki klienta usługi Queue Storage korzystają z usługi Azure Key Vault w celu ochrony kluczy używanych do szyfrowania po stronie klienta. Aby uzyskać więcej informacji na temat usługi Azure Key Vault, zobacz Co to jest usługa Azure Key Vault?.
Szyfrowanie i odszyfrowywanie za pośrednictwem techniki koperty
Szyfrowanie za pomocą techniki koperty działa w następujący sposób:
Biblioteka klienta usługi Azure Storage generuje klucz szyfrowania zawartości (CEK), który jest jednorazowym kluczem symetrycznym.
Dane użytkownika są szyfrowane przy użyciu klucza CEK.
Klucz CEK jest następnie opakowany (zaszyfrowany) przy użyciu klucza szyfrowania klucza (KEK). Klucz KEK jest identyfikowany przez identyfikator klucza i może być parą kluczy asymetrycznych lub kluczem symetrycznym. Klucz szyfrowania kluczy można zarządzać lokalnie lub przechowywać go w usłudze Azure Key Vault.
Sama biblioteka klienta usługi Azure Storage 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/rozpakowywania kluczy.
Zaszyfrowane dane są następnie przekazywane do usługi Azure Queue Storage. Opakowany klucz wraz z dodatkowymi metadanymi szyfrowania jest interpolowany przy użyciu zaszyfrowanych danych.
Odszyfrowywanie za pośrednictwem techniki koperty działa w następujący sposób:
- Biblioteka klienta usługi Azure Storage zakłada, że użytkownik zarządza kluczem 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żywać narzędzia rozpoznawania kluczy, który rozpoznaje różne identyfikatory kluczy dla kluczy.
- Biblioteka klienta pobiera zaszyfrowane dane wraz z dowolnym materiałem szyfrowania przechowywanym w usłudze Azure Storage.
- Opakowany klucz CEK) jest następnie odszyfrowywany (odszyfrowywany) przy użyciu klucza KEK. Biblioteka klienta nie ma dostępu do klucza KEK podczas tego procesu, ale wywołuje tylko algorytm rozpasywania usługi Azure Key Vault lub innego magazynu kluczy.
- Biblioteka klienta używa klucza CEK do odszyfrowania zaszyfrowanych danych użytkownika.
Szyfrowanie/odszyfrowywanie komunikatów
Ponieważ komunikaty w kolejce mogą mieć dowolny format, biblioteka klienta definiuje niestandardowy format zawierający wektor inicjalizacji (IV) i zaszyfrowany klucz szyfrowania zawartości (CEK) w tekście komunikatu.
Podczas szyfrowania biblioteka klienta generuje losowy IV z 16 bajtów wraz z losowym kluczem CEK 32 bajtów i wykonuje szyfrowanie koperty 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 niezapisany. Iv jest również wyodrębniany z komunikatu kolejki i używany wraz z kluczem niezapisanym do odszyfrowania danych komunikatu kolejki. Metadane szyfrowania są małe (poniżej 500 bajtów), więc chociaż wlicza się do limitu 64 KB dla komunikatu w kolejce, wpływ powinien być możliwy do zarządzania. Zaszyfrowany komunikat jest zakodowany w formacie Base64, jak pokazano w powyższym fragmencie kodu, co spowoduje również rozszerzenie rozmiaru wysyłanego komunikatu.
Ze względu na krótkotrwały charakter komunikatów w kolejce, odszyfrowywanie i ponowne odszyfrowywanie komunikatów kolejek po aktualizacji do szyfrowania po stronie klienta w wersji 2 nie powinno być konieczne. Mniej bezpieczne komunikaty będą obracane w trakcie normalnego użycia kolejki.
Szyfrowanie i wydajność po stronie klienta
Należy pamiętać, że szyfrowanie danych magazynu powoduje dodatkowe obciążenie wydajności. W przypadku korzystania z szyfrowania po stronie klienta w aplikacji biblioteka klienta musi bezpiecznie wygenerować klucz CEK i IV, zaszyfrować samą zawartość, komunikować się z wybranym magazynem kluczy na potrzeby otaczania klucza oraz formatować i przekazywać dodatkowe metadane. To obciążenie zależy od ilości zaszyfrowanych danych. Zalecamy, aby klienci zawsze testowali swoje aplikacje pod kątem wydajności podczas opracowywania.