Penetrační testování cloudu: co reálně otestujeme ve vašem AWS

Hranici popisuje model sdílené odpovědnosti a AWS ji pojmenovává dvěma frázemi. „Security of the cloud“ drží AWS, tedy hardware, software, sítě a zařízení, na kterých služby běží. „Security in the cloud“ drží zákazník, tedy data, oprávnění, konfigurace a aplikace. Penetrační test se týká jen té druhé půlky.

Ta hranice není pevná a to je pro scoping podstatnější než samotná definice. Model sdílené odpovědnosti říká, že rozsah zákazníkovy odpovědnosti určují služby, které si zákazník vybral. U virtuálních strojů zůstává zákazníkovi aktualizace operačního systému, bezpečnost aplikace i nastavení security groups. U spravovaných služeb typu S3 provozuje AWS infrastrukturu i platformu a zákazníkovi zbývají data, šifrování a oprávnění.

AWS dělí kontroly na zděděné, sdílené a čistě zákaznické. Do prostřední skupiny patří i záplatování hostovaného operačního systému a aplikací, a to je kontrola na straně zákazníka, ne AWS. Proto scoping cloudového testu začíná soupisem služeb, ne soupisem IP adres.

V cloudu se těžiště chyb přesouvá od verzí k oprávněním. Je to naše zkušenost z testů, ne měřený fakt: u spravovaných služeb nemá zákazník co záplatovat, zato v účtu přibývá s každou aplikací a každým člověkem další role, politika a klíč.

Konkrétně testujeme role IAM a jejich skutečný rozsah, tedy co identita opravdu smí, ne co je napsané v jejím popisu. Dál přístupové klíče a tokeny aplikací, jejich uložení a platnost, a podmínky v politikách, tedy za jakých okolností smí identita danou akci provést. Cílem je zjistit, jestli se z omezené identity dá dojít k právům správce účtu.

V účtu se začíná od čtyř věcí. Kdo smí převzít jakou roli, tedy důvěryhodnostní politiky rolí (trust policies) a volání sts:AssumeRole. Oprávnění iam:PassRole, kterým jde roli přiřadit službě při jejím nastavení, aby si ji ta služba pak sama převzala. A stáří přístupových klíčů i to, kdy a proti které službě byly naposledy použité, což vyčteme z přehledu přihlašovacích údajů v IAM.

Čtvrtá je u instancí EC2 služba metadat instance (IMDS), která vydává dočasné přihlašovací údaje role, kterou instance nese. Zajímá nás, jestli je vynucená verze IMDSv2 s tokenem, protože bez ní stačí k jejich přečtení jediný požadavek z aplikace běžící na instanci.

Na eskalaci přes předané role upozorňuje sama dokumentace AWS k oprávnění PassRole: kdo smí předat roli s vyššími právy, než má sám, otevírá cestu dál. Když se takový pokus povede, hledáme k němu konkrétní volání v CloudTrailu. Co v něm bude vidět, ale závisí na vašem nastavení: běžné správcovské operace jsou v účtu dohledatelné devadesát dní i bez konfigurace, kdežto čtení dat z úložišť se loguje jen tehdy, když si to zapnete.

Externí oporu má tenhle pohled jen částečnou a je poctivé to říct. Žebříček Top Threats to Cloud Computing 2024 od Cloud Security Alliance řadí chybnou konfiguraci na první místo a správu identit a přístupů na druhé, zatímco zranitelnosti systémů až na osmé. Je to ale anketa o vnímané závažnosti mezi odborníky, ne měření četnosti incidentů, a o vývoji v čase neříká nic.

U úložišť S3 se test dívá na tři věci: kdo se k obsahu dostane, jestli je šifrovaný a co se stane, když někdo objekt smaže nebo přepíše. Kontrolujeme nastavení Block Public Access na úrovni organizace, účtu i jednotlivého bucketu, politiky bucketu proti politikám IAM, šifrování v klidu a nastavení verzování.

Samotné nastavení bucketu se ale nedá posoudit bez identit. Aplikace, která má mít právo číst jeden bucket, může držet roli, která jí dovolí vypsat všechny, a v konfiguraci úložiště to vidět není. Proto se úložiště a oprávnění testují společně, ne jako dvě oddělené kapitoly.

Jednu věc test záměrně nedělá: převzetí bucketu. AWS ho vede mezi zakázanými aktivitami, takže se takový nález doloží konfigurací a popisem dopadu, ne provedením.

AWS má jmenovitý seznam služeb, které smíte na vlastní infrastruktuře testovat bez předchozího schválení. Vypisuje je zákaznická politika AWS pro penetrační testování a u služeb mimo seznam odkazuje na AWS Support nebo na zástupce pro váš účet. Stav k 19. srpnu 2026.

Část scénářů se hlásí předem. Red team, blue team a purple team testování, volumetrické testy, simulovaný phishing a testování malwaru se podávají formulářem Simulated Events, a to nejméně dva týdny před začátkem.

Část je zakázaná úplně. Patří sem odepření služby včetně simulovaného, zahlcení portů, protokolů i požadavků, převzetí bucketu S3, převzetí subdomény a zásahy do DNS přes Route 53 včetně procházení zóny. Simulovaný DDoS má vlastní cestu mimo pravidla pro penetrační testování: smí ho provést jen předem schválený partner a cíl musí být krytý službou AWS Shield Advanced. Do běžné cloudové zakázky proto nepatří.

AWS u těchto pravidel neuvádí datum poslední aktualizace, takže je před každou zakázkou ověřujeme znovu a rozsah jim přizpůsobíme. Na cloudové testování máme v týmu certifikaci CCPenX-AWS, tedy Certified Cloud Pentesting eXpert-AWS od The SecOps Group. Je to praktická zkouška typu CTF v délce sedmi hodin.

Rozsah drží čtyři proměnné: počet účtů AWS, počet regionů, počet služeb, které v účtu opravdu běží, a počet identit, tedy uživatelů, rolí a strojových účtů. Kalendářně jsou to dva týdny od zahájení po předání reportu.

Počet serverů je u cloudu slabé vodítko. Účet se dvěma instancemi a čtyřiceti rolemi dá víc práce než účet s dvaceti instancemi a jedinou rolí, protože se testují vztahy mezi identitami, ne stroje. Rozepisujeme proto, z čeho se rozsah cloudové části počítá.

Aplikace, která v účtu běží, je samostatný předmět testu. Aplikaci běžící nad tou infrastrukturou testujeme zvlášť, protože její chyby jsou v kódu a v autorizaci uvnitř aplikace, ne v konfiguraci účtu. Do jedné zakázky se dá spojit obojí, rozsah se pak sečte.

Cloudový test chcete tehdy, když vaše data a služby běží v AWS a potřebujete vědět, co s nimi zvládne udělat někdo s ukradeným klíčem nebo s účtem dodavatele. Síť a doménové prostředí, které provozujete sami, je samostatná služba a testuje se jinými technikami.

Od cloud security auditu se test liší tím, co dělá s nálezem. Audit nebo posture review porovná konfiguraci s doporučeným stavem a vypíše odchylky, což zvládne nástroj. Test se pokusí odchylku zneužít a doloží řetěz kroků, který k tomu vedl. Obojí dává smysl vedle sebe: audit pokryje šířku účtu, test hloubku jedné cesty.

Kam cloud patří v dělení podle předmětu testu, popisuje slovníkové heslo o typech testů. Scoping, průběh a retest se u cloudové zakázky neliší od ostatních: co má každá naše zakázka společné, jsme sepsali jednou pro všechny služby. U cloudu se mění předmět, techniky a pravidla poskytovatele.