Správa cloudu 2: Skenování zranitelností aneb jak předejít bezpečnostním hrozbám v public cloudu
V předchozím díle jsme porovnávali patch management v on-premise prostředí s cloudovým prostředím. V tomto článku se podíváme na bezpečnost v cloudu se zaměřením na skenování zranitelností, patchování a update softwaru i knihoven a na průběžné monitorování stavu našeho řešení.
Kybernetická bezpečnost je téma, které je aktuální a stále bude. Tak jako známe zásady bezpečnosti a ochrany zdraví při práci (BOZP) a zásady požární ochrany (PO), stejně by se naše vědomosti měly rozšířit i o zásady bezpečnosti kybernetické.
Kybernetická bezpečnost už dnes není jen o firewallu a antiviru, ale i o nastavení procesů, pravidel a o reagování na aktuální hrozby. Netýká se tedy pouze IT, ale také chování zaměstnanců a dodavatelů. Zodpovědnost za bezpečnost dat tak máme všichni, a to nejen v rámci pracovních povinností, ale i v soukromém životě. Jaké hrozby na nás číhají?
1) Nesprávně nakonfigurované prostředky
Nesprávná konfigurace cloudových služeb může vést k mnoha zranitelnostem. Příkladem je špatné nastavení přístupů ke cloudovým službám nebo nesprávná konfigurace firewallů.
Chybná konfigurace přístupových pravidel v S3 bucketu
Poměrně pravidelně se v médiích objevují informace o úniku citlivých dat kvůli špatně nakonfigurovaným přístupovým pravidlům v S3 bucketu (datové uložiště v AWS). Někdy jde o úplné šlendriánství, kdy je S3 bucket veřejně přístupný. Obvykle se však jedná o špatnou konfiguraci přístupových pravidel (např. stačí mít jakýkoli AWS účet pro přístup do daného S3 bucketu).
Příklady známých incidentů:
- Capital One (červenec 2019): Útočník ukradl osobní a finanční informace více než 100 milionů zákazníků a získal přístup k citlivým datům. Capital One totiž špatně nakonfigurovala S3 bucket a nechala jej veřejně přístupný.
- Uber (2016): Špatně nakonfigurovaný Amazon S3 bucket způsobil únik dat, který postihl více než 57 milionů zákazníků a řidičů a vedl ke zveřejnění osobních údajů.
- Verizon (červenec 2017): Špatně nakonfigurovaný S3 bucketu provozovaný třetí stranou způsobil únik osobních údajů 6 milionů zákazníků. Incident zahrnoval vystavení dat, jako jsou jména, adresy a identifikační čísla zákazníků.
- Dow Jones (červenec 2017): Kvůli špatně nakonfigurovanému S3 bucketu společnost omylem vystavila osobní údaje více než 2,2 milionu svých zákazníků.
- Accenture (září 2017): Společnost omylem nechala čtyři S3 buckety veřejně přístupné, což mělo za následek vystavení citlivých dat, včetně firemních hesel a přístupových údajů k systémům.
Na další známé případy se můžete podívat v těchto článcích.
Chybná konfigurace firewallů
Požadavky směrnice NIS2 nejsou v oblasti kybernetické bezpečnosti ničím novým. Spadala vaše organizace pod Zákon o kybernetické bezpečnosti nebo máte zavedený systém řízení bezpečnosti informací? Pak vás čeká minimum novinek.
Představuje pro vás kybernetická bezpečnost nové téma? Pak ano, budete muset vyvinout větší úsilí, abyste nové povinnosti splnili. Není ale třeba panikařit.
Přestože cloudová prostředí umožňují mikrosegmentaci sítě pomocí AWS Security Group nebo Azure Network Security Group, stává se, že firewally zůstávají úplně otevřené do celého internetu (případně „jen“ některé důležité porty jako 22 nebo 3389).
Soudruzi z ne zrovna přátelských zemí čekají jen na to, kdy se k vám na server budou moci připojit. Schválně si vytvořte veřejně přístupný server a nechejte ho běžet jednu hodinu. Poté zkontrolujte log na počet neúspěšných pokusů o připojení. Tipuji, že uvidíte tisíce pokusů o připojení. Na internetu totiž číhají boti, kteří mají za úkol cracknout jakýkoli dostupný systém.
Obecně platí, že žádný systém by neměl být veřejně dostupný (tzn. nemá mít veřejnou IP adresu), pokud to není naprosto nezbytné. A pokud to nezbytné je, tak by měl být zpřístupněný jen pro známé IP adresy.
Cloudové platformy nám (často zdarma) nabízejí nástroje a doporučení, jak naše systémy v cloudu zabezpečit. Je ale na nás, abychom o nich věděli a abychom je implementovali.
Všechny velké cloudy definují v nějaké formě sdílenou zodpovědnost za cloud (shared responsibility model), ve kterém říkají, že přejímají zodpovědnost za bezpečnost cloudu jako takového. Avšak zodpovědnost za konfiguraci cloudu a za aplikace, které v něm běží, má zákazník (viz 8 principů, se kterými zajistíte bezpečnost v cloudu).
O tom, jak ověřovat nastavení vašeho cloudového prostředí, píšeme dále v odstavci skenování konfigurace cloudového prostředí.
2) Špatně nastavená autentizace a autorizace
Jakmile útočník získá přístup k účtu uživatele, může získat přístup i k citlivým datům a zdrojům. Za tyto případy obvykle mohou slabá hesla, nedostatečná autentizace a autorizace a další faktory.
Jako úplný základ při přihlašování do cloudu má být vyžadována multifaktorová autentizace (MFA). Ke jménu a heslu (případně k přístupovým klíčům) budete tedy potřebovat ještě one-time password (OTP), které vám vygeneruje aplikace v mobilu nebo vám přijde na e-mail (či jako SMS).
Přístup do cloudu můžete také povolit jen z určitých IP adres.
3) Chyby v softwaru a knihovnách
Útočníci mohou zneužít i známé zranitelnosti v zastaralém softwaru a knihovnách. Může je způsobit špatná implementace kódu, chyby v softwarových knihovnách nebo špatná konfigurace.
Způsobům, jak přistupovat ke známým chybám v softwaru, se věnujeme v samostatné části skenování zranitelností v aplikacích.
4) Nedostatečné zabezpečení dat
Nedostatečné zabezpečení dat může vést k odcizení citlivých informací. Na vině bývá nekvalitní šifrování, neadekvátní skladování dat nebo nedostatečná kontrola přístupu.
Teoreticky bych vás měl přesvědčovat, že jediným správným konceptem zajišťujícím lepší zabezpečení uložených dat je minimalizace přístupových práv pro uživatele. Osobně ale preferuji jiný přístup: dejme uživatelům maximální možná práva, aby mohli cloud smysluplně a samostatně používat. Ovšem za předpokladu, že budou všichni uživatelé náležitě proškoleni a budou si vědomi rizik, která souvisejí s cloudovým prostředím.
Dá se to elegantně řešit vytvořením více cloudových prostředí pro jednotlivé aplikace/týmy. Každý si pak „hraje na svém písečku“ a pokud „něco rozbije“, neovlivní to ostatní.
Pokud by k některým citlivým datům neměl mít přístup ani administrátor cloudu, musíme šifrovat data na straně klienta (to znamená v aplikaci) a uchovávat šifrovací klíče mimo samotný cloud (např. externí HSM).
5) DDoS útoky
Útoky DDoS (Distributed Denial of Service) jsou časté i v public cloudu. Útočníci používají mnoho zařízení, aby poslali velké množství legitimních požadavků na cílový server, což může způsobit nedostupnost aplikace a výpadek služby.
Využití cloudu k minimalizaci dopadu DDoS útoku je přesto správnou cestou, a to hned z několika důvodů:
- Cloudové platformy mají s DDoS „bohaté“ zkušenosti a nabízejí služby, které pomáhají s ochranou (AWS Shield, Azure DDoS Protection, Google Cloud Armor).
- Cloudové platformy mají masivní konektivitu do internetu, kterou nelze tak snadno přetížit jako internetové připojení do on-premise datacentra.
- Automatické škálování aplikace (autoscaling) lze nastavit takovým způsobem, aby dokázala vstřebávat zvýšený počet požadavků, dokud útok nepřestane.
6) Špatná správa API
API (Application Programming Interface) jsou stále důležitější součástí moderních aplikací a systémů, a proto je důležité zajistit jejich bezpečnost.
Při správě API se mohou vyskytnout různé bezpečnostní problémy – např. kvůli nesprávné autentizaci a autorizaci může útočník získat přístup k funkcím API, na které nemá oprávnění. Neoprávněný přístup může vzniknout i v případě, že útočník získá přístupové údaje od oprávněného uživatele nebo najde zranitelnost v API, kterou může zneužít.
Pro vytváření API v cloudu bychom měli využívat k tomu určené služby (AWS API Gateway, Azure API Management, GCP API Gateway). Ty je vhodné integrovat s dalšími službami pro silnou autentizaci a autorizaci (AWS Cognito, Azure AD). Měli bychom nastavit správné rate limity (počet požadavků za určitou dobu, aby uživatelé nemohli bombardovat naše API). Případně můžeme použít i Web Application Firewall na ochranu proti útokům na aplikační vrstvě.
Skenování zranitelností (security scanning)
Zranitelnosti v cloudu lze rozdělit na dvě hlavní kategorie: problémy s konfigurací cloudu a zranitelnosti v softwaru, který provozujeme v cloudu. Je důležité zdůraznit, že správná ochrana cloudu vyžaduje kombinaci preventivních opatření v obou oblastech.
Skenování konfigurace cloudového prostředí
Public cloudy mají mechanizmy (AWS Service Control Policies, Azure Policy), kterými se dá zcela zakázat určitá činnost. Například neumožní uživateli vytvořit subnet přístupný z internetu, takže nebude moci vytvořit ani server, který by byl z internetu přístupný.
Existují dokonce předpřipravené sady politik, s nimiž můžete být compliant například s ISO normami, nebo security benchmarky.
Mohou se ale vyskytnou případy, kdy nechceme (nebo nemůžeme) něco explicitně zakázat, a přesto potřebujeme, aby daná konfigurace splňovala určité požadavky, např. podle PCI DSS standardu. V AWS nám k tomu slouží služba AWS Config, která umožňuje sledovat konfiguraci našeho AWS prostředí i její změny.
AWS Config & Change Analysis
Skenování zranitelností v AWS prostředí pomocí AWS Config slouží k identifikaci změn v konfiguraci, které mohou znamenat bezpečnostní riziko nebo porušení pravidel. Jsme tedy schopni rychle identifikovat problémy a reagovat na ně. AWS Config může vytvořit upozornění nebo vyvolat akce k automatické opravě daného problému.
Kromě toho může AWS Config pomoci s auditováním a historií změn. Ukládá totiž historii konfigurace vašeho prostředí. Díky tomu je dostupné zpětné zobrazení změn konfigurace a kontrola, kdo a kdy tyto změny provedl (což se může hodit při auditování).
AWS Config po integraci s dalšími službami AWS výrazně zlepší sledování vašeho AWS prostředí a identifikuje potenciální bezpečnostní rizika a problémy v konfiguraci.
Ve světě Azure funguje analogicky nástroj Change analysis, který vyhledává změny konfigurace u podporovaných prostředků.
CVE (Common Vulnerabilities and Exposures)
CVE je program pro identifikaci, popis a zaznamenání veřejně známých kybernetických zranitelností. Každá odhalená zranitelnost je klasifikována s ohledem na její závažnost (critical, high, medium, low, none) a uložena do CVE databáze (v době psaní tohoto článku měla 203 653 záznamů).
CVE databáze byla vytvořena s cílem standardizovat oznamování zranitelností a poskytnout uživatelům snadný způsob, jak identifikovat potenciální bezpečnostní hrozby a minimalizovat rizika.
V posledních letech se objevují alternativy k CVE databázi, které se snaží řešit některé její nedostatky (např. problém s rychlostí zveřejňování zranitelností). CVE databáze nicméně stále zůstává klíčovým nástrojem pro bezpečnostní experty a organizace po celém světě.
Skenování zranitelností v aplikacích
Existuje celá řada nástrojů a řešení na skenování zranitelností. Jde jen o to si nějaký vybrat a začít jej využívat (Vulnerability Scanning Tools, Orca Cloud Security, Amazon Inspector, Azure Defender for Cloud a další).
Běžně se security scanning udělá na začátku při psaní aplikačního kódu. Pak se případně oskenuje kontejner při nahrání do repozitáře, ale to je asi tak všechno. Kdo by se zabýval pravidelným security skenováním? Vždyť máme perimetr firewall, tak se k nám nikdo nedostane (navíc už teď máme plno práce).
Zde bych rád podotkl, že hackeři celosvětově vydělávají miliardy dolarů. Jsou tedy velmi motivovaní se dále zdokonalovat. My bychom na druhé straně měli být stejně motivovaní, abychom využili všech dostupných prostředků ke zmenšení prostoru pro možný útok (anglicky „attack surface“).
Nestačí update OS jednou za tři měsíce, protože to vyžaduje nějaká norma. Měli bychom průběžně vědět, v jakém stavu se náš systém nachází s ohledem na bezpečnost, na použité platformy a na naše vlastní aplikace.
Cloudová prostředí lze snadno nastavit tak, aby prováděla skenování zranitelností v pravidelných intervalech (1× denně, 1× týdně). Pokud se objeví nová zranitelnost, která splňuje námi definovanou úroveň (např. high/critical), dostaneme automatickou notifikaci e-mailem, do Slacku, případně jinak.
Závažnou zranitelnost potřebujeme co nejrychleji, co nejbezpečněji a co nejsnáze odstranit. Většinou to vyžaduje aktualizaci OS, platformy nebo aplikace a redeploy dané aplikace.
CI/CD + Infra as Code
Pokud máme správně nastavenou CI/CD pipelinu a jsme schopní nasazovat nové verze bez výpadku systému, patchování aplikace pro nás nepředstavuje žádnou výzvu.
Pokud se jedná o:
- zranitelnost v konfiguraci cloudu, tak upravíme IaC skripty,
- zranitelnost v operačním systému, stačí updatovat v IaC skriptech VM nebo Docker base image na verzi OS, ve které je daná zranitelnost vyřešena,
- zranitelnost v knihovnách aplikace, je potřeba updatovat knihovny na nové verze a rebuildnout aplikaci,
- zranitelnost v samotném kódu aplikace, je potřeba udělat adekvátní změny kódu a také celou aplikaci rebuildnout.
Po každém takovém zásahu potřebujeme mít jistotu, že naše aplikace stále funguje a že jsme nezpůsobili další chyby.
Diagram níže zobrazuje minimální počet kroků, které by měla CI/CD pipelina udělat pro úspěšné nasazení nové verze aplikace. Manuální schválení před nasazením do produkčního prostředí je volitelné. Osobně jsem však nezažil projekt, ve kterém by se nasazovalo úplně automatizovaně.
Závěrem ke skenování zranitelností
Výše popsaný proces můžeme v podstatě opakovat stále dokola. Záleží na tom, jak se objevují nové a nové zranitelnosti v našem řešení. Úsilí investované do CI/CD pipeliny se tedy dříve nebo později zaplatí.
Nemusíme tak mít strach implementovat nové bezpečnostní procesy, které by bez automatizace generovaly významně více práce pro administrátory. V našem případě se ale jedná jen o update několika skriptů a commit do Gitu – zbytek za nás vykoná CI/CD pipelina. Důležité je vědět, kdy máme tyto updaty udělat.
Skenování zranitelností je nezbytným krokem pro zajištění bezpečnosti vašich systémů a dat v public cloudu. Tento proces umožňuje identifikovat potenciální zranitelnosti v počítačových systémech a umožňuje vám přijmout opatření k jejich odstranění.
