Continuous cloud compliance: Aby byl váš cloud stále v bezpečí
S narůstajícím počtem provozovaných cloud prostředí a jednotlivých komponent začínají zákazníci řešit palčivé otázky jako například: Je moje prostředí nastavené stále správně? Neudělal jsem někde v konfiguraci chybu? Nejsou mé aplikace zranitelné? Na tyto všechny otázky dokáže odpovědět oblast continuous cloud compliance, potažmo produkty z rodiny cloud security posture management. V dnešním článku z Encyklopedie cloudu se tedy soustředíme na to, jak v noci klidně spát.
Martin Gavanda
Co znamená continuous cloud compliance a cloud security posture management
Nejprve si pojďme definovat dva výše uvedené klíčové termíny. Pokud se zajímáte o bezpečnost cloudu, už jste se s nimi pravděpodobně v minulosti setkali. Různí cloudoví poskytovatelé či výrobci bezpečnostních nástrojů používají jeden nebo druhý termín, ale v podstatě se jedná o totožnou věc – označují nástroje a procesy, které vám umožní mít kontinuální přehled o stavu vašeho cloud prostředí.
Já osobně spíše preferuji termín continuous cloud compliance, protože zahrnuje nejen konkrétní nástroje umožňující neustále kontrolovat dodržování nejrůznějších bezpečnostních politik, ale také samotný přístup k bezpečnosti v cloudu.
Ve klasickém on-premise prostředí se nejčastěji setkáváme s reaktivním přístupem. Bezpečnostní kontroly či nejrůznější skeny jsou prováděny (většinou již automatizovaně) v definovaných časových obdobích (typicky na týdenní či měsíční bázi) a na základě výsledků je poté případně vytvořen bezpečnostní incident, který je poté předán k řešení.
Jak jistě již tušíte, zásadní nevýhodou takového přístupu je doba, po kterou je mé prostředí v „neoptimálním“ stavu. Některé bezpečnostní aspekty přitom nejsem schopen ani detekovat.
Smyslem cloud prostředí je mít ihned k dispozici jakékoliv prostředky – ať již se jedná o databázi, Kubernetes cluster či sadu virtuálních serverů. Podobně bych měl ihned reagovat na jakékoliv bezpečnostní nedostatky či chybnou konfiguraci.
Pokud omylem vystavím obsah svého S3 bucketu veřejně do internetu, nemohu si dovolit čekat několik dní na další běh bezpečnostního skenu, tuto informaci musím mít ihned. Chci mít neustálý přehled o aktuálním zabezpečení svého cloudového prostředí, odtud tedy pojem continuous cloud compliance.
Sdílený model odpovědnosti
Kdykoliv mluvíme o bezpečnosti v cloudu, nesmíme zapomínat na sdílený model odpovědnosti (shared responsibility model) mezi námi a poskytovatelem cloudových služeb.
Tento model definuje a rozděluje odpovědnost za určité komponenty mezi nás a poskytovatele. Dělí se na dvě části:
- responsibility „of“ the cloud – za co odpovídá poskytovatel cloud služeb,
- responsibility „in“ the cloud – za co odpovídá uživatel cloud služeb
Klíčové ponaučení vyplívající ze sdíleného modelu odpovědnosti je, že za veškerou konfiguraci a zabezpečení provozovaných služeb vždy odpovídá jen a pouze uživatel.
Poskytovatel služeb nám dává nástroje a služby, se kterými můžeme komplexně zabezpečit naše cloudové prostředí. Za jejich implementaci či využití jsme však odpovědní jen a pouze my.
Krásným případem je „aféra“ z roku 2018. Dle úplně prvních článků to vypadalo na zásadní problém samotného AWS. Co se tehdy stalo? Skupina bezpečnostních expertů objevila velké množství sensitivních dat v AWS, konkrétně:
- 116,386 publicly available EBS snapshots exposed to the internet, from 3,213 different accounts,
- 373 public Relational Database Service (RDS) snapshots from 227 accounts,
- 711,598 public Amazon Machine Images (AMIs) from 20,952 accounts,
- 16,000 public IPs of exposed AWS-managed ElasticSearch clusters that could have their contents stolen or data possibly deleted.
Co obsahovala zmíněná data? Například:
- over 300,000 customer emails and encrypted passwords that belong to a Fortune 50 enterprise,
- 500,000 customer and employee records belonging to a healthcare supply chain management vendor whose clients include most major healthcare providers.
Jednalo se o nějakou chybu AWS? Nikoliv, ve výsledku se ukázalo, že za vším stojí lidská chyba či nevědomost. Pokud označím svůj EBS snapshot jako public, tak je opravdu veřejný. A nejpikantnější je, že uživatelé viděli explicitní varování, že public opravdu, ale opravdu znamená veřejné, dostupné všem.
Jaké z toho plyne ponaučení? Lidé dělají chyby. Ať už záměrně, nebo z nevědomosti. A smyslem continuous cloud compliance je těmto problémům předcházet.
Jak funguje continuous cloud compliance
Continuous cloud compliance nám poskytuje okamžitý přehled o všech komponentách v jednotlivých prostředích a neustále vyhodnocuje soulad či nesoulad těchto komponent s definovanými pravidly.
Příklady vybraných politik:
- Mají veškeré provozované komponenty přiřazeny mandatorní tagy, které jsem si definoval ve své tagging policy?
- Nemám v nějakém Firewall pravidlu povolen přístup „odkudkoliv“?
- Jsou veškeré mé provozované servery šifrovány?
- Neprovozuji někde aplikační server, ve kterém jsou známé zranitelnosti (CVEs)?
Zároveň chci mít jasný a ucelený přehled o veškerých prostředích „na jednom místě“. A v neposlední řadě potřebuji, abych byl v případě vzniku nového non-compliant stavu bezprostředně informován pomocí notifikace (nebo dokonce automaticky vytvořit security incident).
Typická funkcionalita
Jednotlivé nástroje se svou funkcionalitou liší, ale obecně by nástroje pro continuous cloud compliance měly pokrývat následující oblasti:
Assets management
Potřebuji mít jasný přehled o veškerých provozovaných komponentách napříč všemi prostředími a znát veškerá dostupná metadata těchto komponent (například jejich konfiguraci).
Event management
Potřebuji ucelený pohled na jednotlivé provozované komponenty a časovou posloupnost jednotlivých událostí (porušení pravidel). Obvykle můžeme automatizovaně vytvářet bezpečnostní incidenty na základě jednotlivých událostí.
Rules a compliance engine
Chci mít možnost definovat jednotlivé bezpečnostní politiky. Obecně je možné využít různé „industry-standard“ předdefinované politiky, například CIS Benchmark atp. Využití těchto předpřipravených pravidel usnadňuje počáteční nasazení continuous cloud compliance nástrojů, nicméně nezapomínejme, že je klíčové mít možnost tvorby vlastních pravidel.
Vulnerability management
Tato funkcionalita umožňuje provádět skenování jednotlivých provozovaných komponent na známé bezpečnostní hrozby (CVEs). Nástroj by měl podporovat minimálně skenování standardních virtuálních serverů, kontejnerů a kontejnerových obrazů.
Vizualizace síťové topologie
Především u komplexnějších aplikací bývá problém na první pohled pochopit síťovou infrastrukturu aplikace a návaznosti mezi komponentami. Některé nástroje nám pomáhají tyto závislosti automaticky vizualizovat. Například nám zobrazí, které prvky aplikace mají přiřazenou veřejnou IP adresu či jak jsou mezi sebou dále propojeny.
Příklad specifické funkcionality konkrétního nástroje
Nástroj Orca Security dokáže identifikovat a klasifikovat obsah dat v jednotlivých provozovaných serverech, například přítomnost privátního klíče či hesla v čitelné formě.
Jaké nástroje pro continuous cloud compliance mohu použít
Jednotlivá cloud prostředí nabízejí sadu nástrojů, s jejichž pomocí můžete oblast continuous cloud compliance z velké části pokrýt. Na rozdíl od hotových řešení možná budete muset jednotlivé nástroje mezi sebou propojit sami, tu si dořešit integraci na váš stávající SIEM nástroj či podobně. Ale v kontextu nákladů na hotová řešení to budou marginální částky.
Na druhou stranu je potřeba mít určité know-how a představu, čeho chcete dosáhnout. Pojďme se teď podívat na nástroje, které můžete v jednotlivých cloud prostředích okamžitě nasadit a využít. Následující seznam určitě nemá ambici pokrýt veškeré nabízené nástroje, ale představit ty z nich, které já osobně považuji za nejdůležitější.
Amazon Web Services & Continuous cloud compliance
AWS Security Hub poskytuje centrální pohled na veškeré security-related oblasti v AWS a sdružuje ostatní nástroje (například výsledky automatizovaných skenů infrastruktury nástrojem Amazon Inspector či sensitivní data identifikovaná pomocí Amazon Macie).
AWS Config je služba zajištující assets management. Umožnuje vyhodnocovat stav jednotlivých zdrojů proti definovaným bezpečnostním politikám.
AWS Inspector umožnuje provádět automatizované skenování rozdílných provozovaných komponent (virtuální servery, kontejnery, kontejnerové obrazy) proti známým zranitelnostem (CVEs).
Amazon GuardDuty umožňuje automaticky analyzovat jednotlivé logy či auditní záznamy. Na základě detekce anomálií a machine learningu vás upozorní na potencionální bezpečnostní incidenty.
Microsoft Azure & Continuous cloud compliance
Azure Policy umožnuje definovat (a případně i vynucovat) jednotlivé bezpečností politiky nad provozovanými komponentami.
Microsoft Defender for Cloud je de facto komplexní cloud security posture management nástroj (obdobně jako produkty třetích stran) pokrývající různé oblasti continuous cloud compliance.
Microsoft Defender for Identity poskytuje širokou škálu služeb v oblasti ochrany identity. Dokáže například odhalit kompromitované identity (například zneužitý servisní účet atp.).
Application Change Analysis umožnuje inventarizovat veškeré provozované prostředky a sledovat jakékoliv provedené konfigurační změny.
Produkty třetích stran
Osobně preferuji spíše využití nástrojů poskytovaných samotnými cloud poskytovateli, které si přizpůsobím přesně na míru svým potřebám. Vyžaduje to ale určité úsilí a, jak víme, čas jsou peníze. Proto je v některých případech vhodnější, když sáhnete po hotových řešeních třetích stran.
U hotových řešení vnímám určitý rozpor mezi požadovanou a poskytovanou funkcionalitou a několik dalších kladů a záporů.
Benefity hotových řešení:
- Obvykle jsou poskytována jako SaaS bez nutnosti „starosti“ o nástroj jako takový
- Bezproblémová integrace různých cloud poskytovatelů, minimálně v případě AWS a Azure
- Jednoduché a rychlé nasazení; základní onboarding prostředí je otázkou minut
- Jednotný pohled na různá cloud prostředí
- Rozsáhlá poskytovaná funkcionalita
Negativa hotových řešení:
- Poskytují funckionalitu as-is. Pokud vám něco nevyhovuje, je obtížné až nemožné to změnit.
- Cenový model je v některých případech komplikovaný (platba za různé moduly, funkční celky atp.).
- Cena se obvykle odvíjí od počtu „spravovaných“ zdrojů.
Pokud se po tomto rychlém zhodnocení kloníte spíše k využití nástrojů třetích stran, rozhodně bych doporučil se podívat minimálně na tyto produkty:
Nechtěl bych zabíhat do komplexních hodnocení jednotlivých produktů, přeci jenom vaše požadavky se mohou značně lišit od očekávání, které mám od obdobných produktů já. V obecné rovině osobně inklinuji primárně k nástroji CloudGuard, který znám ještě z dob, kdy to nebyl produkt Check Pointu, ale firmy Dome9.
Závěrem ke continuous cloud compliance
Co byste si z tohoto článku měli odnést? Hlavně a především to, že bezpečnost v cloudu je čistě vaše odpovědnost. Z toho plyne, že byste měli vždy vědět, v jakém stavu jsou jednotlivé provozované komponenty a měli byste být schopni definovat vaše individuální bezpečností politiky a požadavky.
Z mého pohledu je jedno, které nástroje pro continuous cloud compliance využijete. Ale pokud do cloud prostředí migrujete produkční aplikace, měli byste být schopni tuto oblast pokrýt.
Pokud zvažujete nasazení continuous cloud compliance a chtěli byste téma probrat do většího detailu (technické možnosti jednotlivých produktů, nutné procesní změny, ke kterým jistě bude muset dojít, apod.), klidně se na nás obraťte a zkusíme společně vymyslet to nejlepší řešení pro vaše individuální potřeby.
A to je pro dnešek vše. Díky, že jste dočetli až sem. V příštím článku Encyklopedie cloudu se s vámi Lukáš Klášterský podělí o zkušenosti, jak hodnotit vyspělost vaší organizace v kontextu možného využití cloud prostředí.
