Šifrovací klíče: kam s nimi a jak pracovat s aplikačními tajnostmi v cloudu?

 

S šifrovacími klíči, aplikačními hesly či s jinými tajnostmi je to stejné jako s klíči od domu. Nechcete je ztratit, musí být v bezpečí a čas od času je vhodné je vyměnit. Doby, kdy heslo k databázi bylo přímo součástí aplikačního kódu, jsou naštěstí pryč. Typickým trendem je hesla ukládat bezpečně mimo aplikaci. Dnes se tedy podrobně podíváme na to, jak s hesly či obecně s různými tajnostmi pracovat v cloudu a jaké nástroje můžeme použít.

 

S jakými klíči či tajnostmi se potkáme?

Práci s klíči či jinými tajnostmi můžeme rozdělit na dvě základní oblasti: správu šifrovacích klíčů a správu aplikačních tajností. Ani jednu z nich bychom neměli podcenit.

 

Šifrovací klíče

Šifrovací klíče jsou zcela zásadní komponentou pro šifrování dat. Obecně doporučovaným přístupem je šifrovat data vždy a všude, v tomto článku se nicméně zaměříme na šifrování dat v cloud prostředí. Nejprve si ho rozdělme na šifrování během přenosu (data in transit) a šifrování uložených dat (data at rest).

 

 

Šifrování dat během přenosu

Tento způsob šifrování je typicky realizován s využitím technologií SSL/TLS či IPsec. Cílem těchto technologií, respektive protokolů, je zabezpečit samotný přenos dat. Pro zjednodušení si tyto protokoly můžeme představit jako bezpečný tunel mezi jednotlivými zařízeními. Data uvnitř tohoto tunelu jsou dostupná jednotlivým koncovým zařízením, ale okolní svět (například zařízení poskytovatele internetové konektivity) do tohoto tunelu nevidí. Typickým zástupcem encryption data in transit je nám všem známí protokol https.

 

Šifrování uložených dat

V této oblasti, jež je pro nás z hlediska využití v cloudu mnohem zajímavější, se obvykle uplatňují dva základní přístupy, a to šifrování na straně klienta (client-side encryption) a šifrování na straně serveru (server-side encryption).

 

Šifrování na straně klienta

Implementace šifrování na straně klienta je vždy individuální, neboť (jak již název napovídá) za šifrování je odpovědný klient (typicky aplikace). Data jsou tedy šifrována samotnou aplikací již před uložením do cloudu.

Implementace client-side encryption je tedy vždy na vývojáři samotné aplikace. V obecné rovině poskytuje vyšší důvěru než šifrování na straně serveru (protože máme šifrování zcela pod kontrolou), na druhé straně ale přináší i některé potenciální problémy – komplikuje a prodlužuje vývoj aplikace a při nesprávné implementaci naopak může snížit úroveň bezpečnosti.

 

 

Šifrování na straně serveru

V případě šifrování na straně serveru dochází k šifrování v rámci uložiště dat (ať už se jedná například o virtuální server, databázi či jiný zdroj). Z pohledu aplikace se tedy nic nemění – aplikace pracuje s nešifrovanými daty a není nutné do ní jakkoliv zasahovat.

 

A co ty šifrovací klíče?

Ve všech případech, tedy jak při využití client-side encryption, server-side encryption, ale rovněž při šifrování během přenosu, je nutné použít šifrovací klíče (tj. hesla nebo certifikáty). Platí pro ně přitom, že musíme:

• někde ukládat s omezeným přístupem.
• řídit jejich životní cyklus.
• auditovat jejich použití.

 

 

Aplikační tajnosti

Druhou oblastí, na kterou bychom neměli zapomínat, je správa a ukládání aplikačních tajností, tedy například různých servisních hesel, connection stringů, aplikačních certifikátů a podobně.

Cílem je oddělit aplikační tajnosti od kódu aplikace. V aplikačním kódu tedy nemají být uložena žádná hesla či jiné tajnosti. Smysl je jasný: rozdělit oprávnění (segregation of duty) mezi vývojem a správcem hesel. Vývojář totiž nepotřebuje (a ani by neměl) znát heslo například k databázi. Vývojáři pouze stačí vědět, koho (respektive jaké služby) se má na heslo zeptat.

Druhou zásadní výhodou v případě vyčlenění hesel z aplikace do nějaké externí služby je snadný audit přístupu k těmto tajnostem a možnost automatické rotace hesel.

 

 

Jak to poté vypadá v praxi? V aplikaci se pouze implementuje Software Development Kit (SDK) některé ze služeb pro ukládání tajností, například AWS Secret Manageru. Následující (zjednodušený) příklad ukazuje, jak si může aplikace vyzvednout heslo database_password z AWS Secret Manageru:

 

 

Nástroje pro šifrovací klíče a aplikační tajnosti v cloudu

Obě klíčová public cloud prostředí, tedy Amazon Web Services a Microsoft Azure nabízejí komplexní portfolio služeb pro práci s klíči a aplikačními tajnostmi.

 

Amazon Web Services

V prostředí AWS můžeme využít dvě klíčové služby. Pro práci s šifrovacími klíčí je určena služba AWS Key Management Service (KMS), pro práci s aplikačními tajnostmi poté AWS Secret Manager.

 

AWS Key Management Service

Tato služba nabízí dvě základní rozdělení šifrovacích klíčů:

• AWS managed keys: Jedná se o klíče, které má kompletně ve správě AWS. Vy jako zákazník se nemusíte vůbec starat o jejich životní cyklus ani s nimi nějak manipulovat, pouze klíče využíváte pro šifrování vašich dat.
• Customer managed keys: Tyto klíče máte kompletně ve správě vy. Jste odpovědni za jejich generování a za celý jejich životní cyklus. Key material pro vytvoření klíče může být samotné KMS, můžete key material importovat například z vašeho vlastního HSM nebo můžete využít AWS CloudHSM.

Čím vyšší bude komplexita šifrovací infrastruktury, tím obtížnější bude samozřejmě její řízení a tím vyšší bude cena.

 

 

Na druhou stranu považuji za důležité zmínit, že i nejzákladnější customer managed key vygenerovaný přímo v KMS (v obrázku výše odpovídá Native KMS) splňuje podmínky pro PCI DSS Level 1.

Since security and quality controls in AWS KMS have been validated and certified to meet the requirements of PCI DSS Level 1 certification, you can directly encrypt Primary Account Number (PAN) data with an AWS KMS CMK. The use of a CMK to directly encrypt data removes some of the burden of managing encryption libraries. Additionally, a CMK can’t be exported from AWS KMS, which alleviates the concern about the encryption key being stored in an insecure manner. As all KMS requests are logged in CloudTrail, use of the CMK can be audited by reviewing the CloudTrail logs. 

 

Jak to poté vypadá z pohledu šifrování jednotlivých zdrojů, ať už databází, virtuálních serverů či jiných služeb? Jakmile máte vygenerovaný šifrovací klíč (ať již AWS Managed nebo Customer Managed), tak jej můžete okamžitě použít pro šifrování jednotlivých komponent – například EBS volume.

 

 

Určitě stojí za zmínku fakt, že veškeré zdroje v AWS nejsou ve výchozím stavu šifrovány a uživatel musí explicitně šifrování povolit. Naproti tomu v prostředí Microsoft Azure jsou veškeré zdroje šifrovány již ve výchozím stavu.

 

AWS Secret Manager

Jak jsem již naznačil, Secret Manager slouží k ukládání aplikačních tajností – typicky různých hesel. Standardně je podporováno několik nativních AWS služeb a samozřejmě je možné ukládat jakékoliv vlastní tajnosti (other type of secrets).

 

 

Velkou výhodou Secret Manageru je poté možnost automatické rotace jednotlivých hesel. Pro tuto funkcionalitu je nicméně vyžadována vlastní Lambda funkce, která tuto rotaci provádí. Nejedná se o out-of-the box funkcionalitu Secret Manageru.

 

 

Microsoft Azure

V prostředí Azure existuje pouze jedna služba, která je určena jak pro práci s šifrovacími klíči, tak s aplikačními tajnostmi – Azure Key Vault.

Šifrování je řešeno obdobným způsobem jako v případě AWS – máte tedy možnost využít buď takzvané platform-managed keys (obdoba AWS Managed Keys), tedy klíče kompletně ve správě Azure, nebo customer-managed keys, či jejich kombinaci.

 

 

Druhou částí Azure Key Vault jsou samotné tajnosti (obdoba Secret Manageru), nicméně zde neexistuje podpora pro automatickou rotaci hesel.

 

 

Kdo jsem, jsem jen já, aneb základem je identita

Když víme, jak ukládat jednotlivé aplikační tajnosti, zbývá poslední krok: jakým způsobem vlastně aplikace získá přístup ke konkrétním tajnostem? Přeci na základě své identity!

V aplikaci nikdy není uveden nějaký „přístupový token“ do AWS Secret Manageru či Azure Key Vaultu (neřeším klíče zamčené v trezoru dalším klíčem), ale aplikace (respektive komponenta, kde aplikace běží) má přiřazenou svou identitu.

Jak tedy pracovat s identitou aplikace?

 

Identita aplikace & Amazon Web Services

V prostředí AWS se využívají Identity and Access Management (IAM) role. Každá komponenta, ať už je to virtuální server, Lambda funkce či kubernetes Pod, má přiřazenou svou roli. V rámci této role jsou poté definovány konkrétní IAM politiky, v rámci kterých jsou specifikována jednotlivá oprávnění.

Následující příklad ukazuje IAM policy, která umožňuje číst dvě položky uložené v Secret Manageru – MySecret1 a MySecret2:

 

 

Poté již jen zbývá přiřadit specifickou IAM roli konkrétnímu zdroji.

 

 

V prostředí AWS je tedy identita aplikace definována IAM rolí přiřazené aplikaci.

 

Identita aplikace & Microsoft Azure

Zde je situace obdobná. Jediný rozdíl spočívá v tom, že pro správu identit se používá Azure Active Directory. Každá komponenta (virtuální server, App Service, Azure Function) má svou identitu – buď system nebo user assigned.

Nejdříve tedy vytvoříme managed identity pro naši aplikaci:

 

 

Jakmile je managed identita vytvořena, můžeme ji přiřadit naší aplikaci (respektive zdroji, v rámci kterého aplikace běží) – v tomto případě tedy například virtuálnímu serveru:

 

 

Poté již jen zbývá nastavit standardně práva (access control) v požadovaném Key Vaultu:

 

 

A to je vše. Aplikace má vytvořenu svou managed identitu, ta je přiřazena zdroji a access control této identitě povoluje určité akce. V prostředí Azure je tedy identita aplikace definována její managed identitou.

 

Co si z toho odnést?

Dnes jsme si popsali základní principy práce se šifrovacími klíči v jednotlivých cloud prostředích a ukázali jsme si, jak vyčlenit hesla z našich aplikací a bezpečně je ukládat v jednotlivých externích službách.

Prosím, nezapomínejme, že šifrování dat patří k základním bezpečnostním pilířům práce s daty v cloud prostředí. Zároveň si troufám říci, že aplikační tajnosti (ať už přímo hesla či jiná senzitivní data) rozhodně nepatří do aplikačního kódu či konfiguračních souborů a měly by být ukládány mimo samotnou aplikaci.

A ještě jednou připomínám, že v prostředí AWS nejsou data (na rozdíl od Azure) nijak šifrována!

 

Pokud byste v této oblasti potřebovali jakkoliv pomoci, rádi s vámi v rámci našich služeb Migrace aplikací do cloudu projdeme veškeré aspekty týkající se správného šifrování dat v cloudu.

A pokud již máte tuto oblast vyřešenou, budu rád za jakékoliv komentáře k tématu. Využíváte služby jako Azure Key Vault či Secret Manager nebo jste se rozhodli jít cestou jiných řešení, například Vault by Hashicorp? Importujete vlastní klíče z vašeho HSM, nebo si vystačíte s klíči generovanými samotným cloud prostředím?

Jestli vás naše články baví a přijdou vám zajímavé, určitě mrkněte i na předchozí díly Encyklopedie cloudu – stručný průvodce cloudovým prostředím.