Šifrování na straně klienta pro fronty
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ím dat při stahování do klienta. Klientské knihovny také podporují integraci se službou 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.
Informace o šifrování na straně klienta
Klientská knihovna Azure Queue Storage používá AES k šifrování uživatelských dat. 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.
Upozorňující
Použití verze 1 šifrování na straně klienta se už nedoporučuje kvůli ohrožení zabezpečení v implementaci režimu CBC klientské knihovny. Další informace o tomto ohrožení zabezpečení najdete v tématu Aktualizace šifrování na straně klienta v sadě SDK, aby se vyřešilo ohrožení zabezpečení. Pokud aktuálně používáte verzi 1, doporučujeme aktualizovat aplikaci tak, aby používala verzi 2 a migrovala data. Další pokyny najdete v následující části: Zmírnění ohrožení zabezpečení v aplikacích.
Zmírnění ohrožení zabezpečení v aplikacích
Vzhledem k ohrožení zabezpečení zjištěnému v implementaci režimu CBC klientské knihovny Queue Storage společnost Microsoft doporučuje provést jednu nebo více následujících akcí okamžitě:
Místo šifrování na straně klienta zvažte použití funkcí šifrování na straně služby. 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, migrujte aplikace z šifrování na straně klienta v1 na šifrování na straně klienta v2.
Následující tabulka shrnuje kroky, které je potřeba 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 verzi klientské knihovny, která podporuje pouze šifrování na straně klienta verze 1. | Aktualizujte aplikaci tak, aby používala verzi klientské knihovny, která podporuje šifrování na straně klienta verze 2. 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 přístup k síti jenom na konkrétní sítě.
Matice podpory sady SDK pro šifrování na straně klienta
Následující tabulka uvádí, které verze klientských knihoven pro .NET a Python podporují 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 v2. V případě potřeby můžete při migraci kódu použít verzi klientské knihovny, která podporuje šifrování na straně klienta verze 2 vedle starší verze klientské knihovny.
Jak funguje šifrování na straně klienta
Klientské knihovny Azure Queue Storage používají šifrování obálek k šifrování a dešifrování dat na straně klienta. Šifrování obálek šifruje klíč jedním nebo více dalšími klíči.
Klientské knihovny Queue Storage spoléhají na službu Azure Key Vault k ochraně klíčů, které se používají k šifrování na straně klienta. Další informace o službě Azure Key Vault najdete v tématu Co je Azure Key Vault?
Šifrování a dešifrování prostřednictvím techniky obálky
Šifrování prostřednictvím techniky obálky funguje takto:
Klientská knihovna Azure Storage generuje šifrovací klíč obsahu (CEK), což je jednorázový symetrický klíč.
Uživatelská data se šifrují pomocí klíče 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 být buď asymetrickým párem klíče, nebo symetrickým klíčem. Klíč KEK můžete spravovat místně nebo ho uložit ve službě Azure Key Vault.
Samotná klientská knihovna Azure Storage nemá přístup k klíči KEK. Knihovna vyvolá algoritmus obtékání klíčů, který poskytuje služba Key Vault. V případě potřeby se uživatelé můžou rozhodnout použít vlastní zprostředkovatele pro zabalení nebo rozbalení klíčů.
Šifrovaná data se pak nahrají do azure Queue Storage. Zabalený klíč spolu s některými dalšími metadaty šifrování se interpoluje se zašifrovanými daty.
Dešifrování prostřednictvím techniky obálky funguje takto:
- Klientská knihovna Azure Storage předpokládá, že uživatel spravuje klíč KEK místně nebo ve službě Azure Key Vault. Uživatel nemusí znát konkrétní klíč, který se použil 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í klíče KEK. Klientská knihovna nemá během tohoto procesu přístup k klíči KEK, ale vyvolá pouze algoritmus rozbalení služby Azure Key Vault nebo jiného úložiště klíčů.
- Klientská knihovna používá CEK k dešifrování šifrovaných uživatelských dat.
Šifrování a dešifrování zpráv
Vzhledem k tomu, že zprávy fronty můžou být libovolného formátu, 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í klientská knihovna generuje náhodnou IV ze 16 bajtů spolu s náhodným kódem CEK 32 bajtů a pomocí těchto informací provádí šifrování obálek textu zprávy fronty. Zabalené CEK a další metadata šifrování se pak přidají do zprávy šifrované fronty. Tato upravená zpráva je uložena 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žívá se spolu s nezapsaným klíčem k dešifrování dat zpráv fronty. Metadata šifrování jsou malá (pod 500 bajtů), takže i když se počítá do limitu 64 kB zprávy fronty, dopad by měl být spravovatelný. Zašifrovaná zpráva je zakódovaná ve formátu Base64, jak je znázorněno ve výše uvedeném fragmentu kódu, což rozšiřuje velikost odesílané zprávy.
Z důvodu krátkodobé povahy zpráv ve frontě by dešifrování a opětovné šifrování zpráv fronty po aktualizaci na šifrování na straně klienta v2 nemělo být nutné. Méně zabezpečené zprávy se v průběhu normální spotřeby fronty obměňují.
Šifrování a výkon na straně klienta
Mějte na paměti, že šifrování dat úložiště vede k dalším režijním nákladům na výkon. Pokud ve své aplikaci používáte šifrování na straně klienta, musí klientská knihovna bezpečně vygenerovat klíče CEK a IV, šifrovat samotný obsah, komunikovat s vybraným úložištěm klíčů pro vytváření klíčů a formátovat a nahrávat další metadata. Tato režie se liší v závislosti na množství šifrovaných dat. Zákazníkům doporučujeme, aby během vývoje vždy testovali své aplikace na výkon.