Šifrování front na straně klienta
Klientské knihovny Azure Queue Storage pro .NET a Python podporují šifrování dat v klientských aplikacích před nahráním do služby Azure Storage a dešifrování dat při stahování do klienta. Klientské knihovny také podporují integraci s Azure Key Vault pro správu klíčů účtu úložiště.
Důležité
Azure Storage podporuje šifrování na straně služby i na straně klienta. Pro většinu scénářů Microsoft doporučuje používat funkce šifrování na straně služby, které usnadňují ochranu vašich dat. Další informace o šifrování na straně služby najdete v tématu Šifrování neaktivních uložených dat ve službě Azure Storage.
Šifrování na straně klienta
Klientská knihovna Azure Queue Storage k šifrování uživatelských dat používá AES . V klientské knihovně jsou k dispozici dvě verze šifrování na straně klienta:
- Verze 2 používá režim Galois/Counter Mode (GCM) s AES.
- Verze 1 používá režim CBC (Cipher Block Chaining) s AES.
Upozornění
Použití šifrování na straně klienta verze 1 se už nedoporučuje kvůli ohrožení zabezpečení v implementaci režimu CBC klientské knihovny. Další informace o této chybě zabezpečení najdete v tématu Věnovaném aktualizaci šifrování na straně klienta v sadě SDK za účelem řešení ohrožení zabezpečení. Pokud aktuálně používáte verzi 1, doporučujeme aktualizovat aplikaci tak, aby používala verzi 2, a migrovat data. Další pokyny najdete v následující části Věnované zmírnění ohrožení zabezpečení ve vašich aplikacích.
Zmírnění ohrožení zabezpečení ve vašich aplikacích
Kvůli ohrožení zabezpečení zjištěnému v implementaci režimu CBC klientské knihovny Queue Storage microsoft doporučuje okamžitě provést jednu nebo více následujících akcí:
Zvažte použití funkcí šifrování na straně služby místo šifrování na straně klienta. Další informace o funkcích šifrování na straně služby najdete v tématu Šifrování neaktivních uložených dat ve službě Azure Storage.
Pokud potřebujete použít šifrování na straně klienta, proveďte migraci aplikací z šifrování na straně klienta v1 na šifrování na straně klienta v2.
Následující tabulka shrnuje kroky, které budete muset provést, pokud se rozhodnete migrovat aplikace na šifrování na straně klienta v2:
| Stav šifrování na straně klienta | Doporučené akce |
|---|---|
| Aplikace používá šifrování na straně klienta ve verzi klientské knihovny, která podporuje pouze šifrování na straně klienta v1. | Aktualizujte aplikaci tak, aby používala verzi klientské knihovny, která podporuje šifrování na straně klienta v2. Seznam podporovaných verzí najdete v matici podpory sady SDK pro šifrování na straně klienta . Aktualizujte kód tak, aby používal šifrování na straně klienta v2. |
| Aplikace používá šifrování na straně klienta s verzí klientské knihovny, která podporuje šifrování na straně klienta v2. | Aktualizujte kód tak, aby používal šifrování na straně klienta v2. |
Společnost Microsoft navíc doporučuje, abyste podnikli následující kroky, které vám pomůžou zabezpečit vaše data:
- Nakonfigurujte účty úložiště tak, aby používaly privátní koncové body k zabezpečení veškerého provozu mezi virtuální sítí (VNet) a účtem úložiště přes privátní propojení. Další informace najdete v tématu Použití privátních koncových bodů pro Azure Storage.
- Omezte síťový přístup pouze na konkrétní sítě.
Matice podpory sady SDK pro šifrování na straně klienta
Následující tabulka ukazuje, které verze klientských knihoven pro .NET a Python podporují, které verze šifrování na straně klienta:
| .NET | Python | |
|---|---|---|
| Šifrování na straně klienta v2 a v1 | Verze 12.11.0 a novější | Verze 12.4.0 a novější |
| Pouze šifrování na straně klienta v1 | Verze 12.10.0 a starší | Verze 12.3.0 a starší |
Pokud vaše aplikace používá šifrování na straně klienta se starší verzí klientské knihovny .NET nebo Pythonu, musíte nejprve upgradovat kód na verzi, která podporuje šifrování na straně klienta v2. Dále musíte data dešifrovat a znovu zašifrovat pomocí šifrování na straně klienta verze 2. V případě potřeby můžete při migraci kódu použít verzi klientské knihovny, která podporuje šifrování na straně klienta v2 se starší verzí klientské knihovny.
Jak funguje šifrování na straně klienta
Klientské knihovny Azure Queue Storage používají šifrování obálky k šifrování a dešifrování dat na straně klienta. Šifrování obálky šifruje klíč pomocí jednoho nebo více dalších klíčů.
Klientské knihovny Queue Storage se při ochraně klíčů používaných k šifrování na straně klienta spoléhají na Azure Key Vault. Další informace o azure Key Vault najdete v tématu Co je Azure Key Vault?.
Šifrování a dešifrování pomocí techniky obálky
Šifrování prostřednictvím techniky obálky funguje takto:
Klientská knihovna Azure Storage vygeneruje šifrovací klíč obsahu (CEK), což je symetrický klíč pro jednorázové použití.
Uživatelská data se šifrují pomocí CEK.
Klíč CEK se pak zabalí (zašifruje) pomocí šifrovacího klíče klíče (KEK). Klíč KEK je identifikován identifikátorem klíče a může to být asymetrický pár klíčů nebo symetrický klíč. Klíč KEK můžete spravovat místně nebo ho uložit do Key Vault Azure.
Samotná klientská knihovna Azure Storage nikdy nemá přístup ke klíči KEK. Knihovna vyvolá algoritmus obtékání klíčů, který poskytuje Key Vault. Uživatelé se můžou rozhodnout, že k zabalení nebo rozbalení klíčů použijí vlastní zprostředkovatele, pokud je to potřeba.
Šifrovaná data se pak nahrají do služby Azure Queue Storage. Zabalený klíč spolu s dalšími metadaty šifrování se interpoluje se šifrovanými daty.
Dešifrování pomocí techniky obálky funguje takto:
- Klientská knihovna Azure Storage předpokládá, že uživatel spravuje klíč KEK buď místně, nebo v azure Key Vault. Uživatel nemusí znát konkrétní klíč, který byl použit k šifrování. Místo toho je možné nastavit a použít překladač klíčů, který překládá různé identifikátory klíčů na klíče.
- Klientská knihovna stáhne šifrovaná data spolu s veškerým šifrovacím materiálem uloženým ve službě Azure Storage.
- Zabalený klíč CEK) se pak rozbalí (dešifruje) pomocí KEK. Klientská knihovna nemá během tohoto procesu přístup ke klíči KEK, ale vyvolá pouze algoritmus pro rozbalování Key Vault Azure nebo jiného úložiště klíčů.
- Klientská knihovna používá klíč CEK k dešifrování zašifrovaných uživatelských dat.
Šifrování/dešifrování zpráv
Vzhledem k tomu, že zprávy ve frontě můžou mít libovolný formát, klientská knihovna definuje vlastní formát, který obsahuje inicializační vektor (IV) a šifrovací klíč šifrovaného obsahu (CEK) v textu zprávy.
Během šifrování vygeneruje klientská knihovna náhodný kód IV o 16 bajtůch a náhodný klíč CEK 32 bajtů a pomocí těchto informací provede šifrování obálky textu zprávy fronty. Zabalený klíč CEK a některá další metadata šifrování se pak přidají do zašifrované zprávy fronty. Tato upravená zpráva (zobrazená níže) je uložená ve službě.
<MessageText>{"EncryptedMessageContents":"6kOu8Rq1C3+M1QO4alKLmWthWXSmHV3mEfxBAgP9QGTU++MKn2uPq3t2UjF1DO6w","EncryptionData":{…}}</MessageText>
Během dešifrování se zabalený klíč extrahuje ze zprávy fronty a rozbalí se. Iv se také extrahuje ze zprávy fronty a použije se spolu s nezabaleným klíčem k dešifrování dat zprávy fronty. Metadata šifrování jsou malá (méně než 500 bajtů), takže i když se započítávají do limitu 64 kB pro zprávu fronty, dopad by měl být zvládnutelný. Zašifrovaná zpráva má kódování Base64, jak je znázorněno ve výše uvedeném fragmentu kódu, což také zvětší velikost odesílané zprávy.
Vzhledem k krátkodobé povaze zpráv ve frontě by nemělo být nutné dešifrovat a znovu zašifrovat zprávy fronty po aktualizaci na šifrování na straně klienta v2. Všechny méně zabezpečené zprávy se budou obměňovat v průběhu normálního používání fronty.
Šifrování a výkon na straně klienta
Mějte na paměti, že šifrování dat úložiště má za následek další režii na výkon. Pokud ve své aplikaci používáte šifrování na straně klienta, musí klientská knihovna bezpečně generovat klíče CEK a IV, šifrovat samotný obsah, komunikovat s zvoleným úložištěm klíčů pro obálkování klíčů a formátovat a nahrávat další metadata. Tato režie se liší v závislosti na množství šifrovaných dat. Doporučujeme, aby zákazníci během vývoje vždy testovali výkon svých aplikací.