Bring Your Own Key aneb přines si svůj klíč do mého zámku
Minule jsme si ukázali, že data-at-rest šifrování není všespásné, a že naopak jen mitiguje rizika, která nejsou až tak pravděpodobná.
V praxi jsem se setkal s tím, že uživatelé jsou přesvědčení, že jejich data v AWS, SalesForce, GCP,.. jsou šifrována jejich klíčem a poskytovatel tedy k datům nemá přístup, což je zásadní omyl.
Whitepapery poskytovatelů se bohužel snaží takovou domněnku vzbudit. Uživatel dostane nálož zkratek a slov jako AES256, FIPS 140-2, HSM, KMS, nondeterministic, PBKDF2, DRGB, CMK, NIST, cipher, GCM, Master Key, derivation, tenant, HBK, RFC, secret, hash, private key, TLS, cache-only a konzultant věhlasné firmy doplní SOC2, trust, shared risk, EY, KPMG, USA. Tolik odborných zkratek v prezentaci a rizikovce vypadá neprůstřelně.
Rád používám analogii z fyzické bezpečnosti. BYOK s data-at-rest šifrováním je jako supermoderní sejf se špičkovým zámkem, vyřešeným bezpečným přenášením klíčů z klíčového trezoru do velkého sejfu, ale ten zůstává stále otevřený s klíčem v zámku. Opravdu to chci? A je to tak zlé? Co se v tom cloudu tedy přesně děje?
Když data doputují (krásně zachyceno na obrázku v minulém článku) až na servery, tak jsou zpracovávány a následně ukládány. Budeme používat zažitou terminologii, takže ke zpracování dochází na aplikačních serverech. Nicméně i v cloudech platí, že aby data mohla být zpracovávána, tak samozřejmě musí být čitelná – ajťáci občas říkají v plain-textu. V operační paměti aplikačních serverů jsou tedy vždy volně.
Když je potřeba je uložit, tak je aplikační server šifruje. Často zaznívá mylná představa, že data jsou šifrována v tzv. HSM (Hardware Security Module) a že klíč nikdy neopouští HSM. Ve skutečnosti klíč nejenže opouští, ale je v zásadě trvale v operační paměti na aplikačních serverech. Aby to vypadalo lépe, whitepapery a konzultanti nemluví o aplikačních serverech, ale o service. Takže na aplikačních serverech běží service, rozuměj služba, která data šifruje/dešifruje.
Že tento bod konzultant při prezentaci zamlčel? Pochopitelně. I laik se setkal s memory dumpem, když mu počítač „spadl“, ví, že cloudové služby sází na virtualizaci (ať už klasické hypervizory, JAVA VM, kontejnery), slyšel o zranitelnostech HW, které dohromady více (Lord of the Ring(s): Side Channel Attacks on the CPU On-Chip Ring Interconnect Are Practical) nebo méně umožňují přistupovat do paměťového prostoru jiných procesů a je smířený s tím, že administrátoři můžou vše, protože je extrémně složité je omezit a audit jako 3. či případně 4. úroveň obrany přijde v tomto případě až s křížkem po funuse.
Data jsou šifrovaná klíčem, kterému různí CSP říkají různě. Někteří v souladu s NIST terminologií používají DEK (Data Encryption Key, například Salesforce Shield Platform Encrytion), AWS mluví o Data keys, které pro různé použití pojmenovává různě (Customer Data Key, Volume Key). Důležité je, že toto je ten finální klíč, kterým jsou data opravdu šifrována. Pokud se s daty pracuje (proč si jinak pořizovat cloudovou službu), tak je klíč stále v operační paměti.
Někteří CSP umožňují zákazníkovi dodat svůj vlastní DEK, tedy koncept. BYOK, jiní ho vytváří jen sami. V obou případech je tento klíč při přenosu šifrovaný a při uložení zašifrovaný v HSM poskytovale, u AWS EBS je klíč (Volume Key) zašifrovaný v metadatech volume. Šifrování je zajištěno klíči správce HSM (AWS jim říká Domain Keys, Salesforce je tvoří z kombinace různých tajemství) a tyto pravidelně rotují. Zaměstnanci s rolí Data Protection Officer a útvaru Compliance si odškrtnou požadavek na rotaci/expiraci klíčů, ale netuší (a někteří tušit nechtějí), že to nemá žádný vztah k chráněným datům. DEK je na konci v operační paměti.
Pro úplnost DEK klíčů může být více, cloud platformy to umožňují. V takovém případě jsou stará data dešifrována původním klíčem (nebo více klíči), nová jen tím jedním novým. Benefit je ale sporný, je to jako mít pod rohožkou ne jeden klíč, ale pod několika rohožkami několik klíčů.
Občas se objeví rozumný pohled, že BYOK lze alespoň použít tak, že při smazání dodaného klíče budou data poskytovateli nebo hackerům nečitelná. Naráží to ale na realitu, kdy:
- firmy využívající cloud nemají funkční exit strategii, takže službu prostě zrušit nemůžou, detailně jsme se tomuto problému věnovali zde;
- průnik je detekován v průměru po více než 200 dnech, jak píšeme zde, takže po oznámení o průniku už je stejně většinou pozdě;
- nevěříme poskytovateli, tedy nemáme důvěru v jeho opatření pro riziko s malou pravděpodobností a přitom věříme jiným jeho opatřením (především řízení přístupů), které mají zamezit pravděpodobnějším online rizikům, a zároveň věříme, že náš klíč opravdu neukládá. To je hodně schizofrenní stav.
Jinými slovy, jakmile je jednou klíč uložen v HSM poskytovatele nebo je přímo v paměti na serveru, tak si příslušná data mohou zaměstnanci poskytovatele a případní útočníci přečíst.
Výklad některých právníků k nařízení GDPR je, že firma musí udělat maximum pro ochranu dat. To je vskutku hraběcí rada umožňující značně extenzivní výklad. Každopádně v současné době je možné data chránit pomocí šifrování/tokenizace. A o tom, jak to funguje, kdo toto řešení poskytuje a jaké to má ne/výhody bude příští článek.
Zdroje pro zájemce o studium:
https://docs.aws.amazon.com/whitepapers/latest/kms-best-practices/kms-best-practices.pdf
https://docs.aws.amazon.com/kms/latest/cryptographic-details/kms-crypto-details.pdf
RUDOLF, Miroslav. Bring Your Own Key aneb přines si svůj klíč do mého zámku. Online. Clever and Smart. 2021. ISSN 2694-9830. Dostupné z: https://www.cleverandsmart.cz/bring-your-own-key-aneb-prines-si-svuj-klic-do-meho-zamku/. [cit. 2025-02-16].
Štítky: cloud computing
K článku “Bring Your Own Key aneb přines si svůj klíč do mého zámku” se zde nenachází žádný komentář - buďte první.
Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.