Představte si následující situaci. Útočník získá přístup k jediné sadě uniklých přihlašovacích údajů AWS nebo Azure. Možná to byl inženýr, který omylem nahrál soubor .env do veřejného repozitáře GitHub, nebo možná phishingový e-mail zafungoval na mladšího vývojáře. Na první pohled to nevypadá jako katastrofa. Přihlašovací údaje patří pouze uživateli s nízkou úrovní oprávnění "Pouze pro čtení" nebo omezenému servisnímu účtu s přístupem k jednomu malému S3 bucketu. Můžete si myslet: Dobře, to je nepříjemnost, ale ve skutečnosti nemohou nic dělat.
Ale v tom se mýlíte. V cloudovém prostředí je "nízkoúrovňový" vstupní bod často jen prvním krokem v řetězci událostí zvaném privilege escalation. Během několika minut se útočník nedívá jen na jeden bucket; našel způsob, jak převzít silnější roli, unést administrativní token a nyní má plnou kontrolu nad celým vaším produkčním prostředím. Může smazat vaše zálohy, ukrást vaši zákaznickou databázi nebo nasadit crypto-minery, které během víkendu vygenerují šestimístný účet.
Cloud privilege escalation se liší od tradičního on-premise escalation. Nehledáte jen chybný kernel nebo špatně nakonfigurovaný soubor sudoers. Zabýváte se složitými zásadami Identity and Access Management (IAM), rolemi propojenými se službami a závratným množstvím cloud-native oprávnění, které je téměř nemožné sledovat ručně.
Jediný způsob, jak zjistit, zda je váš "uzamčený" cloud skutečně bezpečný, je pokusit se do něj proniknout. A tady přichází na řadu Penetration Testing. Simulací těchto přesných útočných cest můžete najít díry dříve, než to udělá někdo se špatnými úmysly.
Co přesně je Cloud Privilege Escalation?
Než se dostaneme k tomu, jak to zastavit, musíme si ujasnit, proti čemu bojujeme. Privilege escalation je akt získání vyšší úrovně oprávnění, než bylo původně zamýšleno. V cloudu se to obvykle děje dvěma způsoby: vertikální escalation a horizontální escalation.
Vertikální Privilege Escalation
Toto je klasický scénář "šplhání po žebříku". Útočník začíná jako standardní uživatel a najde cestu, jak se stát administrátorem. Například může zjistit, že má oprávnění iam:CreatePolicyVersion. Na první pohled se to zdá specifické. Ale ve skutečnosti mu toto oprávnění umožňuje změnit si vlastní zásady a udělit si AdministratorAccess. Stejně tak přeskočil z omezeného uživatele na krále kopce.
Horizontální Privilege Escalation
Toto je spíše "úkrok stranou". Zde útočník nemusí nutně získat více moci, ale získá jinou moc. Může se přesunout z jednoho uživatelského účtu na jiný uživatelský účet, který má stejnou úroveň oprávnění, ale přístup k různým datům. Pokud se nachází v multi-tenant prostředí nebo ve společnosti s mnoha oddělenými složkami projektů, horizontální pohyb mu umožňuje shromažďovat data z celé organizace, dokud nenajde "šťavnatý" účet, který umožňuje vertikální escalation.
Proč Cloud Usnadňuje Tento Proces
V tradičním datovém centru je pohyb často omezen segmentací sítě (VLAN, firewally). V cloudu není primárním perimetrem síť – je to identita. Pokud jsou vaše zásady IAM příliš široké, "síť" je v podstatě otevřená. Jedna špatně nakonfigurovaná role může fungovat jako most, který útočníkovi umožní přeskočit z veřejně přístupného webového serveru přímo do vašeho správce hesel.
Běžné Cesty, Které Útočníci Používají k Eskalaci Oprávnění
Útočníci obvykle nehádají cestu na vrchol; sledují známé vzorce. Pokud těmto vzorcům rozumíte, můžete proti nim vybudovat obranu.
1. Nadměrně Oprávněné Servisní Účty
Toto je nejčastější viník. Vývojáři často dávají virtuálnímu stroji (jako je instance EC2 nebo Azure VM) "Managed Identity" nebo "IAM Role", aby aplikace mohla komunikovat s databází. Aby ušetřili čas během vývoje, často dávají této roli přístup Contributor nebo PowerUser.
Pokud útočník najde Server-Side Request Forgery (SSRF) zranitelnost ve webové aplikaci, může se dotazovat na cloudovou službu metadat (IMDS). Tato služba doslova předá dočasné bezpečnostní přihlašovací údaje pro roli připojenou k danému stroji. Nyní útočník operuje s těmito oprávněními na vysoké úrovni ze svého vlastního notebooku.
2. Past "PassRole"
V AWS je oprávnění iam:PassRole častým zdrojem escalation. Umožňuje uživateli přiřadit roli zdroji. Pokud má uživatel iam:PassRole a oprávnění k vytvoření nové funkce Lambda, může jednoduše vytvořit funkci Lambda, přiřadit jí roli AdministratorAccess a poté spustit tuto funkci k vytvoření nového administrátorského uživatele pro sebe. Neměl administrátorská práva, ale měl právo dát administrátorská práva nástroji, který ovládal.
3. Špatně Nakonfigurované Vztahy Důvěryhodnosti
Cloudové role mají často "zásady důvěryhodnosti", které definují, kdo je může převzít. Pokud je zásada důvěryhodnosti příliš benevolentní – například umožňuje jakémukoli ověřenému uživateli v organizaci převzít specializovanou roli "Backup" – útočník, který kompromituje jakýkoli jednotlivý zaměstnanecký účet, může nyní přeskočit do této role Backup, která má pravděpodobně široký přístup pro čtení ke každému jednotlivému kusu dat v cloudu.
4. Krádež Tokenů a Únos Relace
Cloudové konzole používají session tokeny. Pokud útočník může ukrást soubor cookie relace prostřednictvím XSS nebo najít soubor .aws/credentials vývojáře ve veřejném snímku, nemusí prolomit heslo. Jednoduše se "stane" tímto uživatelem. Pokud je tento uživatel náhodou DevOps inženýr s vysokými oprávněními, hra je u konce.
Proč Automatizované Skenování Nestačí
Pravděpodobně jste použili nástroj pro správu stavu zabezpečení cloudu (CSPM). Ty jsou skvělé pro nalezení "nízko visícího ovoce", jako jsou otevřené S3 buckety nebo zakázané MFA. Ale CSPM jsou obecně "statické". Podívají se na konfiguraci a řeknou: "Tohle vypadá špatně."
Eskalace oprávnění je „dynamická“. Jde o vztah mezi různými oprávněními. CSPM vám může říct, že Uživatel A má iam:CreatePolicyVersion, a nemusí to ani označit jako vysoké riziko, protože je to běžné oprávnění pro některé administrátory. Nicméně, Penetration Tester se podívá na Uživatele A a zeptá se: "Může tento uživatel použít toto konkrétní oprávnění ke změně své vlastní role a stát se administrátorem?"
Odpověď na tuto otázku vyžaduje řetězec logiky:
- Zkontrolujte aktuální oprávnění $\rightarrow$ 2. Identifikujte "nebezpečná" oprávnění $\rightarrow$ 3. Otestujte, zda lze tato oprávnění použít k úpravě aktuální identity $\rightarrow$ 4. Proveďte eskalaci.
Automatizované nástroje s tímto řetězcem bojují. Vidí jednotlivé cihly, ale nevidí most, který útočník staví. Proto je manuální a poloautomatizovaný Penetration Testing – ten, který nabízejí platformy jako Penetrify – pro seriózní zabezpečení nezbytný.
Jak Penetration Testing zastaví eskalaci
Pentesting nenachází jen chyby; validuje celý váš bezpečnostní model. Zde je návod, jak strukturovaný pentestingový přístup specificky likviduje cesty eskalace oprávnění.
Mapování prostoru útoku
Pentester začíná mapováním každého vstupního bodu. To zahrnuje veřejné API, zapomenutá vývojová prostředí a integrace třetích stran. Nalezením "nejslabšího" vstupního bodu mohou simulovat, jak by skutečný útočník vstoupil do vašeho systému.
Testování "Blast Radius"
Jakmile je nalezen vstupní bod, tester se pokusí určit blast radius. Pokud kompromitují malou mikroslužbu, mohou se dostat do databáze? Mohou upravit konfiguraci sítě? Dokumentováním toho, jak daleko se mohou dostat, vám ukáží skutečný dopad vašich nastavení IAM.
Identifikace oprávnění "Shadow Admin"
Ve vašem systému existují uživatelé, kteří nejsou označeni jako "Administrátoři", ale efektivně jimi jsou. Tito se nazývají "Shadow Admins". Mohou mít možnost resetovat hesla nebo upravovat členství ve skupinách. Pentester bude hledat tyto skryté cesty, které vaše auditní protokoly mohou ignorovat.
Validace monitoringu a upozorňování
Nejnebezpečnější částí eskalace oprávnění je, že je často tichá. Mnoho společností si uvědomí, že byly prolomeny, až když se jejich data objeví na únikové stránce. Pentest testuje vaše SOC (Security Operations Center). Spustila se vaše upozornění, když uživatel s nízkou úrovní oprávnění najednou začal volat CreateUser nebo AttachUserPolicy? Pokud ne, máte problém s viditelností, který je stejně nebezpečný jako problém s oprávněními.
Podrobný návod k posílení vašich cloudových oprávnění
Zatímco pentesting nachází díry, potřebujete strategii, jak je zacelit. Nemůžete jen odstranit každé oprávnění – vaši vývojáři přestanou být schopni pracovat. Místo toho se zaměřte na tyto konkrétní kroky posílení.
1. Implementujte striktní model "Least Privilege"
Přestaňte používat spravované zásady, jako je AdministratorAccess nebo PowerUserAccess pro lidské uživatele. Vytvořte vlastní zásady, které udělují pouze konkrétní akce požadované pro danou práci.
- Špatně: Udělení přístupu
s3:*vývojáři. - Dobře: Udělení přístupu
s3:GetObjectas3:PutObjectvývojáři pouze pro konkrétní buckety, které potřebují pro svůj projekt.
2. Používejte hranice oprávnění (příklad AWS)
Hranice oprávnění jsou účinný způsob, jak zastavit eskalaci. Hranice je zásada, která nastavuje maximální oprávnění, která identita může mít. I když má uživatel zásadu, která mu uděluje AdministratorAccess, pokud jeho hranice oprávnění říká, že se nemůže dotknout nastavení IAM, je zablokován. To efektivně likviduje útočné vektory iam:PassRole a iam:CreatePolicyVersion.
3. Vynucujte Just-In-Time (JIT) přístup
Proč inženýr potřebuje přístup Admin 24/7? Nepotřebuje. Implementujte systém, kde uživatelé nemají žádná trvalá oprávnění. Když potřebují provést konkrétní úkol, požádají o zvýšený přístup, který je udělen na omezené časové období (např. 2 hodiny) a poté automaticky zrušen. To zmenšuje okno příležitosti pro útočníka, který ukradne přihlašovací údaje.
4. Auditujte své servisní role
Projděte si každý jednotlivý VM, Lambda funkci a kontejner. Zeptejte se: Potřebuje to roli? A pokud ano, má příliš velkou moc? Použijte nástroje k analýze oprávnění "naposledy použitých". Pokud má servisní role 50 oprávnění, ale za posledních 90 dní použila pouze 5 z nich, odstraňte zbývajících 45.
5. Uzamkněte službu Metadata
Pokud používáte AWS, přejděte na IMDSv2. Na rozdíl od IMDSv1 vyžaduje token orientovaný na relaci, což útočníkovi výrazně ztěžuje použití zranitelnosti SSRF ke krádeži cloudových přihlašovacích údajů.
Srovnání: Statická analýza vs. Penetration Testing
Pro lepší pochopení, proč potřebujete kombinovaný přístup, se podívejme, jak tyto dvě metody řeší typický scénář eskalace oprávnění.
| Feature | Static Analysis (CSPM) | Penetration Testing (např. Penetrify) |
|---|---|---|
| Detection Method | Kontroluje konfiguraci podle kontrolního seznamu. | Aktivně se snaží zneužít konfiguraci. |
| Context | Nízký. Vidí "pravidlo". | Vysoký. Vidí "cestu k administrátorovi". |
| False Positives | Vysoké. Označuje věci, které nejsou skutečně zneužitelné. | Nízké. Pokud se tester dostal k administrátorovi, je to skutečné riziko. |
| Speed | Rychlá, kontinuální. | Pomalejší, bodová nebo periodická. |
| Outcome | Seznam "nevyhovujících" nastavení. | Prokázaný útočný řetězec s nápravnými kroky. |
| Focus | Hygiena a Compliance. | Odolnost proti útokům. |
Scénář z reálného světa: "DevOps" skok
Dovolte mi uvést konkrétní příklad toho, jak ve skutečnosti dochází ke zvýšení oprávnění a jak by to Penetration Test odhalil.
Nastavení:
Společnost má roli "DevOps", která se používá v CI/CD pipeline (jako je Jenkins nebo GitHub Actions). Tato role má možnost aktualizovat kód na sadě produkčních serverů. Protože se jedná o roli "DevOps", má oprávnění iam:PassRole, aby mohla připojit správné role k novým instancím EC2, které spouští.
Útok:
- Útočník najde zranitelnost v pluginu třetí strany, který používá CI/CD pipeline.
- Získají práva ke spuštění v prostředí CI/CD.
- Všimnou si, že role pipeline má
iam:PassRoleaec2:RunInstances. - Útočník vytvoří novou "stínovou" instanci EC2. Přiřadí této nové instanci
OrganizationAccountAccessRole(což je role plného administrátora). - Útočník se pomocí SSH připojí k nové instanci, dotazuje se na službu metadat a získá token administrátora.
- Výsledek: Úplné převzetí účtu.
Jak Pentesting zastaví tento útok: Penetration Tester by se nepodíval jen na to, že "role CI/CD má PassRole" a nezaškrtl políčko. Skutečně by tento postup provedl. Ukázali by bezpečnostnímu týmu: "Podívejte, začal jsem v pluginu třetí strany a skončil jsem jako váš Root Administrator za 15 minut."
To ve firmě vyvolá "aha moment". Najednou iam:PassRole není jen technický detail v pravidle – je to obrovská díra v jejich zabezpečení.
Role Penetrify ve vaší bezpečnostní strategii
Správa cloudových oprávnění je noční můra. Mezi tisíci možných akcí v AWS/Azure/GCP a neustálými změnami ve vaší infrastruktuře je nemožné udržet vše perfektní. Potřebujete způsob, jak otestovat svou obranu, aniž byste museli budovat masivní interní "Red Team".
Zde přichází na řadu Penetrify.
Penetrify je cloudová platforma, která překlenuje propast mezi "zaškrtnutím políčka pro Compliance" a "skutečným zabezpečením". Namísto spoléhání se na statický skener, který vám poskytne 200stránkový PDF dokument s "potenciálními" problémy, Penetrify poskytuje způsob, jak identifikovat, posoudit a napravit skutečné zranitelnosti prostřednictvím kombinace automatizovaného a manuálního testování.
Proč Penetrify funguje pro tento problém:
- Cloud-Native Architecture: Nemusíte instalovat nemotorný hardware ani otevírat nebezpečné porty firewallu, abyste se nechali otestovat. Vše je doručováno prostřednictvím cloudu.
- Simulace skutečných útoků: Penetrify nehledá jen nesprávné konfigurace; simuluje, jak by se útočník skutečně pohyboval ve vašem prostředí, aby zvýšil oprávnění.
- Škálovatelnost: Ať už máte jeden účet AWS nebo padesát, platforma vám umožňuje škálovat testování napříč více prostředími současně.
- Praktická náprava: Nalezení díry je jen polovina bitvy. Penetrify vám poskytne pokyny potřebné k tomu, abyste skutečně opravili zásady IAM nebo vztah důvěryhodnosti, aby díra zůstala uzavřená.
- Průběžné hodnocení: Zabezpečení není jednorázová událost. Jak nasazujete nový kód a měníte svou infrastrukturu, objevují se nové cesty ke zvýšení oprávnění. Penetrify vám pomáhá udržovat trvalé zabezpečení.
Běžné chyby, kterých se společnosti dopouštějí při boji proti eskalaci
I když společnosti vědí o eskalaci oprávnění, často implementují "opravy", které ve skutečnosti nefungují. Vyvarujte se těchto běžných úskalí.
1. Spoléhání se pouze na MFA
Multi-Factor Authentication (MFA) je skvělá pro zastavení útočníka v přihlášení do konzole. MFA ale nijak nezabrání eskalaci oprávnění, jakmile je ukraden token relace nebo je unesená role služby. Pokud útočník používá ukradený access_key a secret_key prostřednictvím CLI, nezobrazí se mu výzva MFA.
2. Kultura "Admin pro všechny"
V mnoha rychle rostoucích startupech má každý přístup administrátora, protože "to prostě urychluje věci". Logika je: věříme našim zaměstnancům. Zabezpečení ale není o důvěře; je to o omezení škod, které může kompromitovaný účet způsobit. Pokud váš vedoucí vývojář podlehne phishingu a má přístup administrátora, má útočník přístup administrátora. Tečka.
3. Ignorování rolí "Pouze pro čtení"
Mnoho týmů ignoruje účty s ReadOnlyAccess, protože si myslí, že "nemohou nic změnit". To je obrovská chyba. Přístup pouze pro čtení umožňuje útočníkovi zmapovat celou vaši síť, najít tajné klíče uložené v proměnných prostředí, objevit další zranitelné role a identifikovat přesnou cestu, kterou musí podniknout k eskalaci. Přístup pouze pro čtení je průzkumná fáze útoku.
4. Oprava Symptomu, Ne Příčiny
Pokud pentester najde cestu k eskalaci, neblokujte pouze jednu konkrétní akci. Podívejte se na to, proč tam to oprávnění vůbec bylo. Pokud měl uživatel příliš mnoho pravomocí, je to obvykle proto, že váš proces vytváření rolí je chybný. Opravte proces, ne pouze zásadu.
Kontrolní seznam pro vaši příští Cloud Security Review
Pokud se chystáte na bezpečnostní audit nebo plánujete Penetration Test, použijte tento kontrolní seznam k identifikaci míst, kde jsou vaše rizika eskalace oprávnění nejvyšší.
Identity & Access Management (IAM)
- Mají všichni lidští uživatelé jedinečnou identitu (žádné sdílené účty)?
- Existují nějací uživatelé se zásadami
AdministratorAccessneboFullAccess? - Auditovali jste všechny role s
iam:PassRoleneboiam:CreatePolicyVersion? - Existují nějací "Shadow Admins" (uživatelé, kteří mohou upravovat role, ale nejsou administrátory)?
- Je MFA vynuceno pro všechny uživatele konzole?
Compute & Service Roles
- Používají vaše instance EC2/VM nejvíce omezené role?
- Přešli jste na IMDSv2, abyste zabránili krádeži tokenů založené na SSRF?
- Jsou funkce Lambda omezeny pouze na konkrétní zdroje, které potřebují?
- Zkontrolovali jste "příliš privilegované" integrace třetích stran (SaaS nástroje)?
Monitoring & Visibility
- Máte upozornění pro vysoce riziková volání IAM (např.
CreateUser,AttachUserPolicy)? - Jsou vaše cloudové auditní protokoly (CloudTrail, Activity Logs) uloženy v samostatném, neměnném účtu?
- Kontrolujete data "Last Accessed" pro pročištění nepoužívaných oprávnění?
- Může váš SOC detekovat horizontální pohyb mezi účty?
Často Kladené Otázky (FAQ)
Jak často bych měl provádět Penetration Testing pro eskalaci cloudových oprávnění?
Záleží na vaší míře změn. Pokud denně nasazujete novou infrastrukturu nebo týdně měníte své role IAM, měli byste provádět průběžné nebo měsíční hodnocení. Minimálně by měl hloubkový Penetration Test proběhnout čtvrtletně nebo po jakékoli zásadní architektonické změně.
Nemohu jen použít nástroj jako Prowler nebo ScoutSuite?
To jsou vynikající nástroje pro auditování a hledání chybných konfigurací. Ale pamatujte, jsou to skenery. Řeknou vám, že dveře jsou odemčené. Penetration Test vám řekne, že pokud útočník projde těmito dveřmi, může najít klíče od trezoru v další místnosti. Potřebujete obojí: skenery pro každodenní hygienu a Penetration Testing pro ověření v reálném světě.
Může Penetration Test narušit mé produkční prostředí?
Profesionální Penetration Test, zejména ten spravovaný prostřednictvím platformy jako Penetrify, je navržen tak, aby byl bezpečný. Testeři používají kontrolované metody k prokázání existence zranitelnosti bez způsobení výpadku. Nicméně, vždy je nejlepší provádět nejagresivnější testy ve stagingovém prostředí, které zrcadlí produkci.
Co je to "blast radius" a proč na tom záleží?
Blast radius je celkové množství škod, které může útočník způsobit, jakmile kompromituje jeden bod ve vašem systému. Pokud jedna kompromitovaná funkce Lambda umožní útočníkovi smazat celou vaši databázi, máte masivní blast radius. Cílem zastavení eskalace oprávnění je zmenšit tento blast radius co nejblíže nule.
Je eskalace oprávnění běžná v Azure a GCP, nebo jen v AWS?
Je to univerzální. Zatímco názvy oprávnění se liší (např. "Role-Based Access Control" v Azure vs. "IAM" v AWS), základní logika je stejná. Nesprávně nakonfigurované role, příliš privilegované servisní účty a krádeže tokenů se dějí u všech hlavních poskytovatelů cloudu.
Akční Závěry: Kde Začít Dnes
Pokud se cítíte zahlceni složitostí cloudového IAM, nesnažte se opravit všechno najednou. Začněte těmito třemi vysoce účinnými kroky:
- Auditujte svá oprávnění "PassRole". Vyhledejte ve svých zásadách IAM
iam:PassRolenebo podobná oprávnění v Azure/GCP. Pokud je vidíte přiřazené uživatelům, kteří nejsou administrátory, považujte to za vysoce prioritní riziko. - Povolte IMDSv2. Pokud jste na AWS, je to jeden z nejrychlejších způsobů, jak zabránit tomu, aby se velmi běžný vektor útoku (SSRF) proměnil v rozsáhlé narušení.
- Naplánujte si profesionální posouzení. Přestaňte hádat, zda jsou vaše oprávnění správná. Použijte službu jako Penetrify, abyste získali reálný pohled na vaše bezpečnostní postavení. Je mnohem levnější zaplatit za Penetration Test nyní, než platit za obnovu po ransomwaru později.
Cloud nabízí neuvěřitelnou agilitu, ale tato agilita má svou cenu: složitost. Když se vaše vrstva identit stane příliš složitou na pochopení, stane se hřištěm pro útočníky. Proaktivním hledáním cest eskalace oprávnění obrátíte situaci a donutíte útočníka, aby se vypořádal s posíleným prostředím, kde je každý krok monitorován a každé oprávnění je zasloužené.
Nečekejte na narušení, abyste zjistili, kde jsou vaše díry. Zabezpečte svůj cloud, omezte svůj blast radius a získejte profesionální pohled na svou infrastrukturu ještě dnes.
Jste připraveni zjistit, zda je vaše cloudové prostředí skutečně zabezpečené? Navštivte Penetrify a začněte identifikovat a opravovat rizika eskalace oprávnění dříve, než je objeví někdo jiný.