Jak nejlépe zabezpečit cloudy?

3. 3. 2019

Sdílet

 Autor: © boscorelli - Fotolia.com
Další den a další únik dat v důsledku špatně nakonfigurovaných cloudových systémů. Nedávný incident, při kterém došlo k odhalení údajů až šesti milionů zákazníků společnosti Verizon, je dalším připomenutím, že zodpovědnost za zabezpečení cloudu musejí sdílet sama organizace i poskytovatel cloudu.

Existuje mylná představa, že za zabezpečení prostředí cloudu je zodpovědný poskytovatel cloudových služeb. To je jen polovina pravdy.

Provozovatelé cloudu, jako jsou Amazon, Microsoft či Google, se starají o zabezpečení svých fyzických datových center a serverového hardwaru, na kterém běží virtuální počítače, ale ochranu virtuálních počítačů a aplikací ponechávají na odpovědnosti jednotlivých zákazníků.

Provideři poskytují řadu bezpečnostních služeb a nástrojů k zabezpečení pracovní zátěže zákazníků, ale potřebnou ochranu musí skutečně implementovat příslušný administrátor. Ve skutečnosti nezáleží na tom, jaký druh bezpečnostní obrany poskytovatel cloudu nabízí, pokud zákazníci své vlastní sítě, uživatele a aplikace nechrání.

Nezávislý poskytovatel služeb zajišťoval Verizonu obsluhu provozu podkladové infrastruktury i centra volání a ukládal do datového úložiště S3 (Simple Storage Service) od Amazon Web Service (AWS) veškerá data o hovorech zákazníků jako jména, adresy, telefonní čísla a kódy PIN účtu každého zákazníka Verizonu, který do centra volání zavolal za posledních šest měsíců.

Tento sběr dat měl podle původních předpokladů přispět ke zlepšení fungování služby zákazníkům, ale protože byl S3 bucket nesprávně nakonfigurován a umožňoval externí přístup, mohl si tyto informace stáhnout v podstatě kdokoli, kdo byl dostatečně trpělivý, aby zjistil odpovídající webovou adresu.

Podvodníci, kteří se dostali k datům, by se mohli při volání vydávat za jakéhokoli klienta Verizonu a získat přístup k zákaznickým účtům.

Tento typ omylů je hrozivě častý. Nedávný výzkum týmu CIS (Cloud Infrastructure Security) společnosti RedLock, která se zaměřuje na zabezpečení v cloudu, zjistil, že minimálně jednu službu ve veřejném cloudu vystavilo nebezpečí v důsledku nesprávné konfigurace 40 procent organizací.

 

Následky nesprávné konfigurace

Verizon je jen jednou z mnoha organizací, jejichž data byla zpřístupněna ve veřejném cloudu v důsledku nějaké chyby.

Před několika týdny se objevily on-line osobní údaje více než tří milionů fanoušků wrestlingu, protože společnost WWE (World Wrestling Entertainment) měla instanci své databáze ve službě AWS S3 nezašifrovanou a bez řízení přístupu a bez hesla.

V polovině letošního roku potvrdil národní výbor amerických republikánů, že osobní údaje 198 milionů registrovaných voličů ve Spojených státech (přibližně 60 procent voličů) byly uložené jako běžný text na otevřeném úložném serveru ve službě Amazon S3, který vlastnila analytická firma Deep Root Analytics.

Společnost Booz Allen Hamilton působící ve vojenském průmyslu zase vyzradila 60 tisíc souborů patřících Pentagonu, včetně citlivých souborů spojených s americkým vojenským projektem a půl tuctu nezašifrovaných bezpečnostních pověření, ukládáním těchto souborů ve veřejné instanci S3.

„Problémem není, že by cloud nebyl bezpečný, ale za zabezpečení svých sítí, aplikací a dat jsou zodpovědní sami zákazníci,“ uvádí Varun Badhwar, výkonný ředitel a spoluzakladatel start-upu RedLock.

Infrastruktura veřejného cloudu, jako je AWS, podle něj může být velice bezpečná, pokud je správně nakonfigurována organizacemi, které takové služby využívají.

Společnost Threat Stack, která se zaměřuje na cloudové zabezpečení, analyzovala 200 firem využívajících AWS a zjistila, že 73 procent z nich mělo minimálně jednu kritickou chybu zabezpečení, jako jsou například ponechání možnosti přímého přístupu k datům pro neoprávněné osoby, možnost zneužití nesprávně nakonfigurovaného objektu jako součásti většího útoku a kontroly celého prostředí přihlášením do konzole AWS.

Tato narušení byla důsledkem základní bezpečnostní nedbalosti a neexistujících zásad IT, nikoliv důsledkem práce zlomyslných protivníků.

Bez ohledu na to, kdo vykonává provisioning Ѿ ať už je to správce IT, vývojář, inženýr nebo bezpečnostní tým – nakonec platí, že příliš mnoho lidí nerozumí dostatečně tomu, jak nakonfigurovat své cloudové prostředí.

Organizace by neměly přistupovat k veřejnému cloudu jako k dřívějším starým místům pro ukládání informací, ale měly by použít následující bezpečnostní opatření k zajištění ochrany svého cloudového prostředí, aplikací a dat před neoprávněným přístupem.

 

1.  Znát rozsah své zodpovědnosti

Všechny cloudové služby nejsou stejné a úroveň odpovědnosti se liší. Poskytovatelé SaaS (software jako služba) zajišťují, že jsou jejich aplikace chráněné a že se data přenášejí a ukládají bezpečně, ale u cloudové infrastruktury to není obvyklé.

Například je to organizace, kdo nese odpovědnost za své instance AWS Elastic Compute Cloud (EC2), Amazon EBS a Amazon Virtual Private Cloud (VPC) včetně konfigurací operačního systému, správy aplikací a ochrany dat.

Jako kontrast lze uvést případ, kdy Amazon udržuje operační systém a aplikace pro službu Simple Storage Service (S3) a organizace odpovídá jen za správu dat, zásady pro řízení přístupu a identity.

Amazon poskytuje nástroje pro šifrování dat pro S3, ale je na organizaci, aby tuto ochranu používala při komunikaci se serverem. Zjistěte si u poskytovatele, kdo je odpovědný za jakou část zabezpečení cloudu.

 

2. Řídit, kdo má přístup

Tým CIS společnosti RedLock zjistil, že 31 procent databází ve veřejném cloudu je otevřených pro přístup z internetu. Ve skutečnosti 93 procent zdrojů v prostředích veřejného cloudu vůbec neomezovalo odchozí přenosy.

Devět procent pracovních zatížení cloudu, které nebyly vyvažovače ani bastion hostitelé, akceptovalo přenosy z jakékoli adresy IP na libovolném portu, což je strašná představa. Internetu by měly být vystaveny jen vyvažovače zátěže a bastion hostitelé.

Únik dat společnosti Verizon nastal, protože byl S3 bucket nastaven tak, aby umožnil externí přístup. To je naneštěstí běžná chyba. Společnost Threat Stack zjistila, že 37 procent organizací v jejím výzkumu mělo S3 buckety, které dovolovaly přístup komukoli. 

Mnoho administrátorů omylem povolí globální oprávnění na svých serverech použitím 0.0.0.0/0 ve veřejných podsítích. Takové připojení je široce otevřené a může se k němu připojit jakýkoli počítač. V případě AWS by buckety S3 nikdy neměly umožňovat veřejný přístup.

Další častou chybou je ponechání otevřeného SSH, což podle analýzy Threat Stack udělalo 73 procent organizací. Threat Stack také zjistil, že 13 procent umožnilo připojení SSH přímo z internetu, což znamená, že každý, kdo by dokázal zjistit umístění serveru, by mohl obejít bránu firewall a získat přímý přístup k datům.

Všichni hlavní poskytovatelé cloudu nabízejí nástroje pro řízení přístupu a identit. Používejte je. Mějte přehled, kdo má přístup k jakým datům a kdy.

Při vytváření zásad řízení přístupu a identity poskytujte minimální rozsah oprávnění a další oprávnění poskytujte jen dočasně v případě potřeby. Nakonfigurujte skupiny zabezpečení tak, aby bylo omezení co nejpřísnější, a používejte referenční ID skupiny zabezpečení, kdekoli je to možné.

Amazon VPC umožňuje administrátorům vytvořit v rámci cloudu AWS logicky izolovanou síť a spouštět servery ve virtuálních sítích. Je to jeden ze způsobů, jak chránit a oddělit produkční prostředí od prostředí pro vývoj a od zkušebního prostředí a jak uchovávat data odděleně.

 

3. Ochrana dat

Další častou chybou je nechat data v cloudu nezašifrovaná. Tým CIS společnosti RedLock zjistil, že 82 procent databází ve veřejném cloudu není zašifrováno. Informace o voličích a citlivé soubory Pentagonu byly vyzrazené, protože data nebyla zašifrována a servery byly přístupné neoprávněným subjektům.

Ukládání citlivých dat v cloudu bez použití vhodných opatření, která by chránila přístup k serveru a data, je nezodpovědné a nebezpečné.

Pokud je to možné, udržujte si kontrolu nad šifrovacími klíči. Přestože je možné dát poskytovatelům cloudových služeb přístup ke klíčům, základem je, že odpovědnost za data nese organizace.

„Je to jako svěřit klíče od svého domu firmě, která vám tam má dělat nějaké větší úpravy,“ vysvětluje Mark Hickman, provozní ředitel společnosti WinMagic.

„Očekáváte, že vše bude v pořádku, ale nikdy si nemůžete být na 100 % jistí, jestli budou zamykat dveře, a neznáte ani charakter jejich subdodavatelů. Proč tedy podstupovat riziko tím, že jim umožníte přístup předáním všech klíčů?“

Dokonce i přestože poskytovatelé cloudu nabízejí šifrovací nástroje a služby správy, velmi mnoho společností je nepoužívá. Šifrování přináší odolnost proti selhání – i když selže konfigurace zabezpečení a data padnou do rukou neoprávněné osoby, nelze je použít.

 

4. Zabezpečení přihlašovacích údajů

Jak ukázal únik OneLogin, není neobvyklé, že dojde k vyzrazení přístupových klíčů AWS. Mohou být zjistitelné na veřejných webech, v úložištích zdrojových kódů, na nechráněných informačních panelech Kubernetes a na dalších podobných fórech.

Považujte přístupové klíče AWS za nejcennější korunovační klenoty, vzdělávejte vývojáře a zabraňte úniku takových klíčů na veřejných fórech.

Vytvářejte unikátní klíče pro každou externí službu a omezujte přístup podle principu minimálních oprávnění. Zajistěte, aby neměly klíče široké oprávnění, protože v nesprávných rukou by je bylo možné zneužít pro přístup k citlivým zdrojům a datům. Vytvářejte role IAM pro přiřazení specifických oprávnění, jako jsou například volání API.

Zajistěte pravidelnou obměnu klíčů. RedLock zjistil, že 63 procent přístupových klíčů se nezměnilo více než 90 dnů. To dává útočníkům čas na zachycení kompromitovaných klíčů a infiltrování cloudových prostředí, jako by to byli privilegovaní uživatelé.

Nepoužívejte uživatelský účet root, a to ani pro administrativní úlohy. Účet root užijte k vytvoření nového uživatele s přiřazenými oprávněními.

Účet root zamkněte (nejlépe přidáním vícefaktorového ověřování) a použijte ho jen pro velmi specifické úlohy správy účtů a služeb. Pro všechno ostatní vytvořte uživatele s odpovídajícími oprávněními.

Zkontrolujte uživatelské účty, vyhledejte ty nepoužívané a vypněte je. Pokud nikdo tyto účty nepoužívá, není důvod poskytovat útočníkům potenciální cesty ke kompromitaci.

 

5. Hygiena zabezpečení je stále důležitá

Hloubková ochrana je obzvláště důležitá při zabezpečení cloudových prostředí, protože zajišťuje, že i v případě selhání jednoho opatření existují ještě další bezpečnostní funkce, díky nimž budou aplikace, síť a data v bezpečí.

Vícefaktorová autentizace (MFA) poskytuje další vrstvu ochrany nad uživatelským jménem a heslem, takže je pro útočníky průlom těžší. MFA by se měla používat k omezení přístupu ke konzolím pro správu, k informačním a řídicím panelům a k privilegovaným účtům.

RedLock zjistil, že 58 procent účtů root nemá zapnutou vícefaktorovou autentizaci. Společnost Threat Stack navíc určila, že 62 procent organizací mělo minimálně jednoho uživatele AWS bez zapnuté vícefaktorové autentizace.

 

6. Zlepšení viditelnosti

Přední poskytovatelé cloudu nabízejí určitou úroveň nástrojů pro protokolování, takže nezapomeňte logování a monitoring zabezpečení zapnout, abyste mohli vidět neoprávněné pokusy o přístup a další problémy.

Třeba Amazon nabízí službu CloudTrail pro audit prostředí AWS, ale příliš mnoho organizací tuto službu nevyužívá. Když je služba CloudTrail zapnuta, uchovává historii všech volání rozhraní API AWS včetně totožnosti subjektu volajícího rozhraní API, času volání, zdrojové adresy IP volání, parametrů požadavku a prvků odezvy vrácených službou AWS.

Lze ji také použít pro sledování změn, správu zdrojů, bezpečnostní analýzy a audity dodržování předpisů.

 

Nedovolte, aby chyby vedly k narušení

Úniky dat nejsou vždy důsledkem nějakého externího útoku, citlivé údaje mohou být vyzrazené i lidskou chybou. Chyby typu zapomenutí něco zapnout nebo mylná představa, že se něco udělalo, ale bez ověření, ponechávají dveře dokořán pro útočníky.

Organizace musejí pravidelně kontrolovat bezpečnost svého cloudového prostředí a také to, co se týká jejich dodavatelů a partnerů. Jak ukázalo narušení u Verizonu, může to být chyba externího dodavatele, která může způsobit vážné problémy.

Model sdíleného zabezpečení existuje z nějakého důvodu. Bez ohledu na to, kdo zodpovídá za bezpečnost cloudové zátěže, je to nakonec organizace, kdo je zodpovědný za to, co se stane s jejími daty.

 

bitcoin školení listopad 24

 

Tento příspěvek vyšel v Security Worldu 4/2017. Časopis (starší čísla i předplatné těch nadcházejících) si můžete objednat na adrese našeho vydavatelství.