Jak provádět efektivní Cloud Penetration Testing

Převedli jste svou infrastrukturu do cloudu. Možná to byla postupná migrace nebo plnohodnotný "lift and shift." Na papíře to vypadá skvěle. Máte škálovatelnost, lepší dostupnost a nemusíte se starat o selhání hardwaru v zaprášené serverovně. Ale tady je realita: přechod do cloudu vás automaticky nezabezpečí. Ve skutečnosti to často jen změní způsob, jakým vás hacknou.

Zabezpečení cloudu je sdílená odpovědnost. Amazon, Google nebo Microsoft se starají o zabezpečení cloudu – fyzická datová centra a hypervisory. Ale vy jste zodpovědní za zabezpečení v cloudu. To znamená vaše konfigurace, správu identit, šifrování dat a kód aplikace. Jedna špatně umístěná značka zaškrtnutí v nastavení S3 bucketu nebo uniklý API klíč ve veřejném repozitáři GitHub může otevřít dveře do celého vašeho prostředí.

Proto se cloudový Penetration Testing liší od tradičního síťového testování. Nejde jen o skenování otevřených portů na firewallu; hledáte chybné konfigurace identit, příliš benevolentní role IAM a zranitelnosti v serverless funkcích. Pokud se ke svému cloudovému prostředí stále chováte jako k virtuálnímu datovému centru, uniká vám polovina útočné plochy.

V této příručce si projdeme, jak přesně provádět efektivní cloudový Penetration Testing. Probereme metodologii, nástroje, běžné nástrahy a jak proměnit jednorázový test v trvalé zabezpečení. Ať už jste bezpečnostní inženýr nebo IT manažer, který se snaží zjistit, zda je vaše nastavení skutečně odolné, toto je pro vás.

Pochopení útočné plochy cloudu

Než začnete spouštět nástroje, musíte pochopit, co vlastně testujete. V tradičním prostředí byl perimetr jasný: firewall byl hranice. V cloudu je perimetrem identita.

Posun od sítě k identitě

V cloudu je systém "Identity and Access Management" (IAM) nový firewall. Pokud útočník ukradne sadu přihlašovacích údajů s AdministratorAccess nebo dokonce špatně vymezenou vývojářskou roli, nemusí se "vloupávat" prostřednictvím síťové zranitelnosti. Prostě se přihlásí.

Efektivní cloudový Penetration Testing se zaměřuje silně na Privilege Escalation. Cílem není jen získat shell na serveru; je to najít způsob, jak přimět poskytovatele cloudu, aby útočníkovi udělil více oprávnění. Například, může uživatel s oprávněními "CreateRole" vytvořit novou roli s plnými administrátorskými právy a poté ji přiřadit sám sobě? To je klasický cloud-native útočný vektor.

Model sdílené odpovědnosti

Nemůžete testovat všechno. Pokud se pokusíte provést útok Denial of Service (DoS) proti spravované službě AWS, pravděpodobně vám bude účet zablokován, protože útočíte na infrastrukturu poskytovatele, nikoli na svou vlastní.

Musíte rozlišovat mezi:

Infrastrukturní vrstva: Spravovaná poskytovatelem (AWS, Azure, GCP). Obecně to nemůžete testovat pomocí Penetration Testingu.
Platformní vrstva: Spravované služby jako RDS, Lambda nebo S3. Testujete konfiguraci a přístup k nim.
Aplikační vrstva: Kód, který jste napsali a nasadili. Zde stále platí tradiční webové aplikační testování (OWASP Top 10).

Specifické cílové oblasti cloudu

Při plánování testu rozdělte své prostředí do těchto kategorií:

Úložiště: S3 buckety, Azure Blobs, Google Cloud Storage. Jsou veřejné? Jsou oprávnění příliš široká?
Výpočetní prostředky: instance EC2, Kubernetes clustery (EKS/GKE), funkce Lambda. Existují neopravené zranitelnosti OS nebo uniklé proměnné prostředí?
Identita: Uživatelé, role a zásady IAM. Existují dlouhodobé přístupové klíče? Je pro privilegované uživatele zakázáno MFA?
Síť: VPC, Security Groups, Load Balancers. Je možný "laterální pohyb" mezi veřejně přístupným webovým serverem a soukromou databází?

Fáze 1: Průzkum a sběr informací

Průzkum v cloudu je o hledání "úniků." Protože jsou cloudová prostředí tak integrovaná s DevOps pipelines, největší zranitelnosti často začínají mimo cloudovou konzoli.

OSINT a uniklé přihlašovací údaje

Nejběžnější způsob, jakým začínají narušení cloudu, je prostřednictvím uniklých tajemství. Útočníci se ne vždy "hacknou"; často jen najdou klíče.

GitHub/GitLab Scraping: Použití nástrojů jako TruffleHog nebo GitLeaks k prohledávání veřejných repozitářů pro AWS Access Keys, Azure Secret Keys nebo hesla databází.
Skenování veřejných bucketů: Hledání otevřených S3 bucketů pomocí klíčových slov souvisejících s názvem vaší společnosti. Nástroje jako s3scanner mohou pomoci identifikovat, zda jsou vaše interní dokumenty omylem veřejné.
DNS Enumeration: Hledání subdomén, které by mohly směřovat na "dev" nebo "staging" prostředí. Ty jsou často méně zabezpečené než produkční, ale sdílejí stejná oprávnění identity.

Mapování cloudové stopy

Jakmile máte opěrný bod nebo cíl, musíte zmapovat prostředí. Zde zjistíte, jaké služby skutečně běží.

Service Discovery: Používáte serverless (Lambda)? Kontejnery (ECS/Fargate)? Kombinaci obojího?
Identifikace poskytovatele: I když je to obvykle zřejmé, znalost přesné verze API cloudového poskytovatele nebo konkrétní oblasti může pomoci při přizpůsobení útoků.
Veřejně exponované koncové body: Identifikujte každý API Gateway, Load Balancer a veřejnou IP adresu. Tím se vytvoří vaše počáteční "útočná mapa."

Přístup "Zvenku dovnitř"

Začněte tím, že budete napodobovat externího útočníka. Nepředpokládejte, že nemají žádné přihlašovací údaje. Předpokládejte, že našli klíč vývojáře na fóru nebo ve veřejném repozitáři. Tato mentalita "předpokládaného narušení" je mnohem účinnější než začínat od nuly, protože testuje vaše schopnosti detekce a reakce spíše než jen váš perimetr.

Fáze 2: Analýza zranitelností a kontrola konfigurace

Nyní, když víte, co je venku, musíte najít díry. V cloudu je "zranitelnost" zřídka chyba v softwaru a častěji chyba v konfiguraci.

Auditování IAM politik

Toto je jádro cloudového Penetration Testing. Hledáte "Overprivileged Identities".

Wildcard Permissions: Hledejte politiky, které používají Resource: "*" nebo Action: "s3:*". Pokud uživatel potřebuje nahrávat soubory pouze do jedné složky, neměl by mít přístup ke každému bucketu v účtu.
Trust Relationships: Zkontrolujte, kdo smí přebírat jaké role. Pokud vývojová role může převzít produkční roli administrátora bez MFA, máte kritickou zranitelnost.
Long-Lived Keys: Identifikujte uživatele s přístupovými klíči, které nebyly otočeny za 90+ dní. Jsou to hlavní cíle pro krádež.

Nesprávně nakonfigurované úložiště a databáze

Je to klišé z dobrého důvodu: lidé nechávají buckety otevřené.

Public Read/Write: Můžete nahrát soubor do S3 bucketu bez ověření? Můžete číst citlivé konfigurační soubory?
Unencrypted Data: Zkontrolujte, zda jsou citlivá data v klidovém stavu šifrována. I když to není přímý "vstupní bod", je to zásadní selhání shody (GDPR/HIPAA) a činí exfiltraci dat mnohem škodlivější.
Database Exposure: Ujistěte se, že instance RDS nebo CosmosDB nemají přiřazené veřejné IP adresy. Vždy by měly být v soukromé podsíti.

Serverless a Container Vulnerabilities

Moderní cloudové aplikace spoléhají na Lambda, Azure Functions a Kubernetes. Tyto zavádějí nová rizika.

Environment Variables: Vývojáři často umisťují API klíče nebo DB hesla do proměnných prostředí Lambda. Pokud útočník získá práva ke spuštění (prostřednictvím code injection), může jednoduše spustit env a ukrást vše.
Container Escape: V Kubernetes, pokud pod běží jako "privileged", útočník, který kompromituje pod, může být schopen uniknout na hostitelský uzel a získat přístup k podkladové službě metadat cloudu.
Cold Start Attacking: Zkoumání, jak je stav zpracováván mezi voláními funkcí, aby se našly potenciální úniky dat mezi různými uživateli.

Fáze 3: Exploitation a Lateral Movement

Zde prokážete riziko. Nalezení "misconfiguration" ve zprávě je jedna věc; ukázat, že můžete ukrást zákaznickou databázi, je věc druhá.

Attacking the Metadata Service (IMDS)

Jedním z nejmocnějších nástrojů v arzenálu cloudového pen-testera je Instance Metadata Service. Pokud najdete Server-Side Request Forgery (SSRF) zranitelnost ve webové aplikaci běžící na instanci EC2, můžete se dotázat na http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name].

To vrací dočasné bezpečnostní přihlašovací údaje pro roli připojenou k instanci. Poté můžete tyto klíče nakonfigurovat na svém lokálním počítači a jednat jako tento server. Takto se ve skutečnosti stane většina velkých cloudových narušení.

Privilege Escalation Paths

Jakmile máte sadu přihlašovacích údajů nízké úrovně, cílem je stát se administrátorem. Mezi běžné cesty patří:

iam:CreateAccessKey: Pokud můžete vytvořit nový přístupový klíč pro jiného uživatele (například administrátora), vyhráli jste.
iam:PassRole: Pokud můžete předat roli s vysokými oprávněními nové instanci EC2 a poté se do této instance přihlásit, eskalovali jste.
lambda:UpdateFunctionCode: Pokud můžete změnit kód funkce Lambda, která je spouštěna administrátorem, můžete ji přimět, aby odeslala tokeny relace administrátora na váš vlastní server.

Lateral Movement Across Accounts

Velké společnosti používají více cloudových účtů (Dev, Stage, Prod).

Cross-Account Roles: Zkontrolujte, zda má účet Dev roli, která mu umožňuje přístup k účtu Prod.
Shared Credentials: Často se stejný SSH klíč nebo API klíč používá v několika prostředích. Najděte jej v Dev, použijte jej v Prod.
VPC Peering: Pokud jsou dvě VPC propojeny, můžete se přesunout z kompromitovaného webového serveru v jedné VPC do databáze v jiné?

Fáze 4: Post-Exploitation a Exfiltration

Cílem profesionálního Penetration Test není jen "dostat se dovnitř", ale ukázat, co by útočník mohl skutečně ukrást nebo zničit.

Data Exfiltration Techniques

Jak by útočník dostal data ven, aniž by spustil poplachy?

Snapshot Sharing: Místo stahování databáze o velikosti 1 TB (což spouští síťová upozornění) by útočník mohl vytvořit snímek svazku EBS a sdílet jej s externím účtem AWS, který ovládá.
S3 Sync: Použití aws s3 sync k zrcadlení bucketu do externího umístění.
DNS Tunneling: Odesílání malých bitů dat prostřednictvím DNS dotazů, aby se zabránilo detekci standardními firewally.

Persistence Mechanisms

Jak útočník zůstane v systému, i když otočíte heslo?

Creating Backdoor Users: Přidání nového uživatele IAM s vágním názvem, jako je cloud-support-service.
Modifying Trust Policies: Přidání ID externího účtu do vztahu důvěry, aby mohl převzít roli, kdykoli bude chtít.
Scheduling Tasks: Vytvoření úlohy Cron nebo události CloudWatch, která znovu vytvoří přístupový klíč každých 24 hodin.

Impact Assessment

V této fázi zdokumentujete, k čemu všemu bylo přistupováno.

Mohli byste získat přístup k PII (Personally Identifiable Information)?
Mohli byste odstavit celé produkční prostředí?
Mohli byste upravit zdrojový kód aplikace v rámci CI/CD pipeline?

Porovnání tradičního Pen-Testingu vs. Cloud Pen-Testingu

Je běžné, že si týmy myslí, že mohou pro cloud jednoduše použít svůj starý kontrolní seznam pro pen-testing. To je chyba. Zde je důvod proč.

Funkce	Tradiční Pen-Testing	Cloud Pen-Testing
Primární cíl	Prolomit perimetr/síť	Prolomit identitu (IAM)
Vstupní bod	Otevřené porty, neopravený software	Uniklé klíče, SSRF, Misconfigs
Pohyb	Network pivoting (SSH, SMB)	API calls, Role Assumption
Perzistence	Rootkity, Web shelly	IAM backdoors, Shadow Admins
Nástroje	Nmap, Metasploit, Burp Suite	Pacu, ScoutSuite, CloudEnum
Rozsah	Fyzické/Virtuální Servery	Managed Services & Serverless

Tradiční testování je o "rozbíjení" věcí. Cloudové testování je spíše o "zneužívání" věcí. Nebojujete s firewallem; bojujete se složitým souborem oprávnění.

Běžné chyby v Cloud Pen-Testingu

I zkušení bezpečnostní profesionálové chybují, když přecházejí do cloudu. Vyvarujte se těchto běžných nástrah.

1. Zapomínání na "lidský" element (CI/CD)

Mnoho testerů se zaměřuje pouze na spuštěné prostředí. Cloud je ale nasazován prostřednictvím kódu (Terraform, CloudFormation, Jenkins). Pokud má skript Terraform heslo pevně zakódované, "zabezpečené" prostředí, které vytváří, je ve skutečnosti kompromitováno od okamžiku, kdy je nasazeno. Vždy zahrňte CI/CD pipeline do svého rozsahu.

2. Přílišné spoléhání se na automatizované skenery

Automatizované nástroje jsou skvělé pro nalezení otevřeného S3 bucketu, ale jsou hrozné pro nalezení složitých cest eskalace IAM. Skener vám může říct, že uživatel má iam:PutUserPolicy, ale nemusí nutně vysvětlit, že to uživateli umožňuje udělit si AdministratorAccess. Manuální analýza logiky zásad je to, kde je skutečná hodnota.

3. Ignorování "tichých" služeb

Každý testuje EC2 instance a S3 buckety. Málokdo testuje Glue jobs, SQS queues nebo Secret Manager. Útočníci milují tyto "tiché" služby, protože je bezpečnostní týmy často přehlížejí a obvykle mají příliš permisivní role.

4. Selhání při testování "Blast Radius"

Běžnou chybou je zastavení po prvním úspěšném exploitu. "Dostal jsem se do dev serveru, takže systém je zranitelný." Ne. Skutečná otázka zní: "Jakmile jsem v dev serveru, mohu se dostat do produkční databáze?" Testování limitů vaší segmentace (blast radius) je to, co poskytuje skutečnou obchodní hodnotu.

5. Testování bez "Cloud-Aware" právní dohody

Testování v cloudu může být riskantní. Pokud omylem spustíte bezpečnostní alarm u AWS nebo Azure, mohou pozastavit váš účet. Vždy se ujistěte, že pracujete v rámci zásad "Permitted Services" poskytovatele a že máte jasný písemný souhlas od vlastníka účtu.

Podrobný návod: Simulace cloudového útoku

Abychom to konkretizovali, projděme si hypotetický scénář.

Cíl: Středně velká e-commerce společnost používající AWS. Cíl: Získat přístup k zákaznické databázi.

Krok 1: Zjišťování

Tester začíná s OSINT. Najdou veřejný GitHub repository patřící jednomu z vývojářů společnosti. V commitu ze šesti měsíců zpět je soubor .env obsahující AWS_ACCESS_KEY_ID a AWS_SECRET_ACCESS_KEY.

Krok 2: Počáteční přístup

Tester nakonfiguruje tyto klíče lokálně. Spustí aws sts get-caller-identity a zjistí, že klíče patří uživateli s názvem dev-automation-user. Zkontrolují oprávnění a zjistí, že uživatel má velmi omezený přístup – většinou jen čtení z několika S3 bucketů.

Krok 3: Nalezení Pivotu

Tester vypíše S3 buckety a najde jeden s názvem company-deployment-scripts. Uvnitř najdou skript používaný k nasazení Lambda funkce. Skript obsahuje pevně zakódovaný odkaz na roli: lambda-executor-role.

Krok 4: Exploitation (SSRF)

Tester najde veřejně přístupnou funkci "Image Upload" na webových stránkách společnosti. Manipulací s URL zjistí zranitelnost Server-Side Request Forgery (SSRF). Používají to k dotazování na EC2 metadata service: http://169.254.169.254/latest/meta-data/iam/security-credentials/web-server-role.

Krok 5: Eskalace

Nyní mají klíče pro web-server-role. Zkontrolují oprávnění a zjistí, že tato role má oprávnění iam:PassRole. Používají to k vytvoření nové, malé Lambda funkce, přiřadí k ní lambda-executor-role (kterou viděli v S3 bucketu) a napíší jednoduchý skript pro výpis všech secrets v AWS Secrets Manager.

Krok 6: Konečný cíl

Lambda funkce vrátí heslo k databázi. Tester znovu použije SSRF zranitelnost k tunelování do privátní VPC a připojení k databázi pomocí ukradeného hesla.

Výsledek: Kompletní únik dat. Ponaučení: K úniku nedošlo kvůli "hacku" v tradičním smyslu. Stalo se to kvůli uniklému klíči, špatně zabezpečenému S3 bucketu, SSRF chybě a nadměrně privilegované IAM roli.

Jak vybudovat program kontinuálního testování

Jednorázový Penetration Test je jen momentka. V cloudovém prostředí, kde vývojáři nahrávají kód desetkrát denně, je tato momentka v úterý zastaralá. Potřebujete kontinuální přístup.

Implementace "Security as Code"

Nejlepší způsob, jak zabránit cloudovým zranitelnostem, je zachytit je před nasazením.

Infrastructure as Code (IaC) Scanning: Používejte nástroje jako Checkov nebo Tfsec ke skenování šablon Terraform/CloudFormation. Pokud šablona definuje veřejný S3 bucket, sestavení by mělo automaticky selhat.
Policy as Code: Používejte Open Policy Agent (OPA) nebo AWS Config k vynucení pravidel v reálném čase. Například pravidlo, které říká: "Žádný IAM uživatel nesmí mít AdministratorAccess bez MFA."

Automatizace "Low Hanging Fruit"

Nepotřebujete člověka, aby vám řekl, že bucket je veřejný. Používejte automatizované nástroje Cloud Security Posture Management (CSPM) ke sledování vašeho prostředí 24/7. Tyto nástroje poskytují základní úroveň zabezpečení a upozorní vás, jakmile se konfigurace změní.

Plánovaný Red Teaming

Zatímco automatizace zvládá základy, stále potřebujete lidi, aby našli složité logické chyby a cesty eskalace. Naplánujte si "hloubkové" Penetration Testy každý čtvrtrok nebo po každé významné architektonické změně.

Integrace s vaším workflow

Největším selháním v oblasti zabezpečení je zpráva, která tři měsíce leží v PDF. Výsledky vašeho Penetration Testingu by měly být přímo v Jira nebo GitHub Issues vašeho inženýrského týmu. Zabezpečení je funkce, nikoli samostatný projekt.

Jak Penetrify zjednodušuje cloudové zabezpečení

Dělat vše výše uvedené ručně je vyčerpávající. Vyžaduje to obrovské množství specializovaných znalostí a sadu drahých nástrojů. To je přesně důvod, proč jsme vytvořili Penetrify.

Penetrify je cloudová nativní platforma pro kybernetickou bezpečnost, která je navržena tak, aby odstranila dohady z bezpečnostních hodnocení. Namísto snahy poskládat dohromady dvacet různých open-source nástrojů poskytuje Penetrify jednotné prostředí pro identifikaci, hodnocení a nápravu zranitelností.

Zde je návod, jak vám Penetrify pomůže implementovat vše, o čem jsme diskutovali:

Eliminujte infrastrukturní bariéry: Nemusíte nastavovat "attack boxes" nebo složité VPN. Cloudová nativní architektura Penetrify vám umožní spouštět hodnocení na vyžádání.
Automatizované skenování zranitelností: Postaráme se o "low hanging fruit." Penetrify automaticky skenuje nesprávné konfigurace, otevřené buckety a běžné cloudové chyby, takže se vaši lidští testeři mohou soustředit na těžké věci – jako je eskalace privilegií.
Bezproblémová integrace: Nevěříme ve statické PDF zprávy. Penetrify se integruje s vašimi stávajícími bezpečnostními workflow a SIEM systémy a vkládá výsledky přímo do vašeho kanálu nápravy.
Škálovatelnost pro rostoucí týmy: Ať už jste středně velká společnost nebo velký podnik, Penetrify se s vámi škáluje. Můžete testovat více prostředí a systémů současně, aniž byste museli najímat obrovský interní bezpečnostní tým.
Kontinuální monitoring: Posuňte se za mentalitu "momentky". Penetrify vám pomáhá udržovat silné zabezpečení tím, že poskytuje neustálý přehled o vaší cloudové odolnosti.

Kombinací automatizovaného skenování s manuálními možnostmi Penetration Testingu zajišťuje Penetrify, že pouze "neodškrtáváte políčko" pro dodržování předpisů, ale skutečně posilujete svou infrastrukturu proti reálným útokům.

Kontrolní seznam pro váš příští cloudový Pen-Test

Pokud plánujete test na zítra, použijte tento kontrolní seznam, abyste se ujistili, že jste pokryli to nejdůležitější.

$\square$ Rozsah a právní aspekty

Písemné povolení od vlastníka aktiva.
Ověření zásad Penetration Testingu poskytovatele cloudu (např. "Povolené služby" AWS).
Definované "cíle mimo rozsah" (aby nedošlo k pádu produkce).

$\square$ Průzkum

Skenování veřejných GitHub/GitLab pro uniklé klíče.
Vypsání všech veřejných DNS záznamů a subdomén.
Identifikace všech veřejně přístupných API endpointů a Load Balancerů.

$\square$ Identita a přístup (IAM)

Kontrola zástupných znaků (*) v oprávněních.
Audit vztahů důvěryhodnosti pro přístup mezi účty.
Identifikace uživatelů bez MFA na privilegovaných účtech.
Testování běžných cest eskalace privilegií (např. iam:PassRole).

$\square$ Infrastruktura a úložiště

Ověření, zda jsou všechny S3/Blob storage buckety soukromé.
Kontrola nešifrovaných citlivých dat v klidovém stavu.
Zajištění, aby byly databáze v soukromých podsítích bez veřejných IP adres.
Testování zranitelností SSRF cílených na Metadata Service (IMDS).

$\square$ Výpočetní prostředky a kontejnery

Kontrola proměnných prostředí Lambda na přítomnost tajných klíčů.
Skenování obrazů kontejnerů na známé zranitelnosti.
Pokus o únik z kontejneru v Kubernetes podech.
Kontrola VPC peeringu a pravidel Security Group pro laterální pohyb.

$\square$ Post-Exploitation a Reporting

Pokus o exfiltraci dat prostřednictvím snímků nebo synchronizace.
Kontrola mechanismů perzistence (IAM uživatelé se zadními vrátky).
Dokumentován "Blast Radius" každého úspěšného exploitu.
Poskytnuty jasné a proveditelné kroky nápravy pro každé zjištění.

Často Kladené Otázky

Musím informovat AWS, Azure nebo GCP před zahájením Penetration Testing?

V minulosti jste museli odeslat formulář žádosti téměř pro všechno. V současné době má většina hlavních poskytovatelů seznam "Permitted Services". Pokud testujete své vlastní zdroje a neprovádíte útoky typu DoS nebo neútočíte na základní infrastrukturu poskytovatele, obecně nepotřebujete formální žádost. Vždy si však ověřte nejnovější zásady pro svého konkrétního poskytovatele cloudu, abyste se vyhnuli označení svého účtu.

Jak často bych měl provádět cloudový Penetration Testing?

Protože se cloudová prostředí tak rychle mění, roční test nestačí. Lepší přístup je hybridní model:

Continuous Scanning: Používejte nástroj jako Penetrify denně pro odhalení chybných konfigurací.
Čtvrtletní hloubkové analýzy: Provádějte manuální Penetration Testy každé 3 měsíce.
Testování řízené událostmi: Spusťte cílený test, kdykoli provedete zásadní změnu rolí IAM nebo migrujete základní službu.

Jaký je rozdíl mezi Vulnerability Scan a Pen-Testem?

Vulnerability Scan je jako domácí bezpečnostní systém, který vám řekne, že jsou odemčené přední dveře. Najde známou chybu a nahlásí ji. Penetration Test je jako profesionální zloděj, který vidí odemčené dveře, vejde dovnitř, najde klíč od trezoru v kuchyni a poté ukradne šperky. Jeden najde díru; druhý dokazuje, kolik škody lze touto dírou způsobit.

Nemůžu místo Penetrace Testing použít jen nástroj CSPM?

Nástroje CSPM (Cloud Security Posture Management) jsou skvělé pro hledání konfigurací "known-bad" (např. "Tento bucket je veřejný"). Ale nemohou najít "logické" chyby. Například CSPM vám neřekne, že kombinace tří různých rolí s nízkými oprávněními umožňuje uživateli nakonec se stát administrátorem. To vyžaduje kreativní, nepřátelské myšlení lidského pen-testera.

Mám provádět testování "White Box" nebo "Black Box"?

Pro cloudová prostředí téměř vždy doporučuji testování "Gray Box" nebo "White Box". Black box testing (nulová znalost) tráví příliš mnoho času fází "hádání". Pokud dáte testerovi seznam svých aktiv a uživatele IAM s nízkou úrovní oprávnění, může trávit čas hledáním hlubokých, strukturálních chyb, na kterých skutečně záleží, místo toho, aby trávil tři dny snahou najít IP adresu vašeho vývojového serveru.

Závěrečné Myšlenky: Bezpečnost je Proces, Ne Projekt

Pokud si z této příručky odnesete jednu věc, ať je to tato: Cloudová bezpečnost je pohyblivý cíl.

V okamžiku, kdy dokončíte Penetrace Test a opravíte zranitelnosti, vývojář odešle novou aktualizaci, bude aktivována nová cloudová služba nebo bude objeven nový Zero Day. Nemůžete "vyřešit" bezpečnost; můžete pouze řídit riziko.

Cílem efektivního cloudového Penetration Testing není dosáhnout stavu "dokonalé bezpečnosti" (který neexistuje). Cílem je vybudovat systém, který je odolný – kde jedna chyba v konfiguračním souboru nevede k úniku dat, který se dostane na titulní stránky.

Tím, že se zaměříte na identitu, omezíte svůj Blast Radius a posunete se směrem k modelu kontinuálního testování, dostanete se před většinu útočníků. A pokud chcete přestat spravovat tucet různých bezpečnostních nástrojů a začít získávat jasný obraz o svém riziku, podívejte se na Penetrify. Vybudovali jsme platformu, která zvládne náročné úkoly cloudových hodnocení, abyste se mohli soustředit na bezpečné budování svého podnikání.

Přestaňte hádat, jestli jste v bezpečí. Začněte to testovat.

Zpět na blog