Zabezpečte svůj serverless systém pomocí Cloud Penetration Testing

Pravděpodobně jste už slyšeli to lákání: "Serverless je budoucnost." Už žádné záplatování OS kernelů, žádné starosti s využitím CPU na konkrétním VM a žádné placení za nečinné servery. Zní to jako sen. Jen nahrajete svůj kód do AWS Lambda, Google Cloud Function nebo Azure Function a poskytovatel cloudu se postará o zbytek.

Ale tady je to, co se v marketingových materiálech často přehlíží: "Serverless" ve skutečnosti neznamená, že neexistují žádné servery. Znamená to jen, že je spravuje někdo jiný. Zatímco Amazon nebo Microsoft se starají o fyzický hardware a záplatování runtime, vy jste stále zodpovědní za kód, který píšete, za oprávnění, která udělujete, a za data, se kterými pracujete.

Mnoho týmů dělá chybu, když si myslí, že přechod na serverless architekturu automaticky zmenší jejich útočnou plochu. Ve skutečnosti se často jen změní její tvar. Vyměnili jste několik velkých, monolitických serverů za stovky malých, efemérních funkcí. Každá z těchto funkcí je potenciálním vstupním bodem. Pokud je jedna funkce nesprávně nakonfigurována nebo má zranitelnost, útočník by se mohl potenciálně dostat do celého vašeho cloudového prostředí.

Zde přichází na řadu cloudový Penetration Testing. Na serverless aplikaci nemůžete použít tradiční síťové skenery, protože neexistuje žádná trvalá IP adresa, kterou byste mohli skenovat. Potřebujete jiný přístup – takový, který rozumí logice architektur řízených událostmi a zvláštnostem cloudových oprávnění.

Proč serverless architektury vyžadují specifický bezpečnostní přístup

Po léta byla bezpečnost o budování "hrázě" kolem datového centra. Měli jste firewall, DMZ a několik silně střežených bran. Pokud se někdo dostal přes firewall, byl v síti a tam jste s ním bojovali.

Serverless tento model obrací vzhůru nohama. V serverless prostředí je váš "perimeter" nyní vaše API gateway, vaše spouštěcí události a vaše IAM (Identity and Access Management) role. Útočná plocha je fragmentovaná. Místo jedněch velkých dveří máte tisíc malých oken.

Mýtus o "zděděné bezpečnosti"

Častým mylným názorem je, že poskytovatel cloudu se stará o veškerou bezpečnost. Toto je "Shared Responsibility Model" a zde dochází k většině narušení, protože lidé nepochopí, kde končí práce poskytovatele a kde začíná ta vaše.

Poskytovatel zabezpečuje samotný cloud – virtualizační vrstvu, fyzické disky a základní OS. Vy zabezpečujete vše uvnitř cloudu. To zahrnuje:

Kód: Pokud má vaše Node.js funkce zranitelnost v knihovně třetí strany, AWS to za vás neopraví.
Konfigurace: Pokud omylem nastavíte svůj S3 bucket na "public", je to na vás.
Oprávnění: Pokud má vaše Lambda funkce AdministratorAccess namísto pouhého oprávnění zapisovat do jedné konkrétní databázové tabulky, vytvořili jste obrovskou bezpečnostní díru.

Výzva efemérních aktiv

Tradiční Penetration Testing často zahrnuje "persistence" – kdy tester získá přístup k serveru a udržuje si tento přístup, aby zjistil, co může najít. V serverless existuje "server" možná 200 milisekund a pak zmizí.

To ho nečiní bezpečnějším; jen je obtížnější ho monitorovat. Útočníci se naučili přizpůsobit. Nesnaží se na serveru "sedět"; zaměřují se na "event injection" a "permission escalation". Hledají způsoby, jak oklamat vaši funkci, aby provedla příkaz nebo vyzradila tajný klíč, který jim umožní laterální pohyb ve vašem cloudovém účtu.

Běžné zranitelnosti v serverless aplikacích

Než budete moci testovat díry, musíte vědět, kde se obvykle nacházejí. Serverless aplikace mají jedinečné režimy selhání. I když se stále zabýváte OWASP Top 10 (jako je SQL Injection), projevují se v cloud-native světě odlišně.

Event Injection: Nové SQLi

V tradiční aplikaci uživatelský vstup obvykle pochází z HTTP požadavku. V serverless může vstup pocházet odkudkoli: z nahrání S3 bucketu, streamu DynamoDB, zprávy Pub/Sub nebo e-mailu přes SES.

Pokud vaše funkce důvěřuje datům přicházejícím ze spouštěče událostí, aniž by je sanitizovala, máte problém s injekcí. Například, pokud je funkce spuštěna nahráním souboru a poté použije název souboru v systémovém příkazu ke zpracování obrázku, útočník by mohl nahrát soubor s názvem ; rm -rf /; .jpg. Pokud kód není opatrný, může tento příkaz provést.

Příliš privilegované IAM role

Toto je snad největší riziko v cloudových prostředích. Protože je "snazší" dát funkci FullAccess ke službě, než strávit hodinu zjišťováním přesných 12 oprávnění, které potřebuje, mnoho vývojářů se vydává cestou nejmenšího odporu.

Představte si funkci, která potřebuje pouze číst jeden konkrétní soubor z S3 bucketu. Pokud má oprávnění s3:*, útočník, který najde zranitelnost umožňující spuštění kódu v této funkci, může nyní vypsat všechny buckety ve vašem účtu, stáhnout data vašich zákazníků nebo dokonce smazat vaše zálohy. Cloudový Penetration Testing se silně zaměřuje na audity "least privilege", aby našel tyto mezery.

Porušená autentizace a autorizace

Protože jsou serverless funkce často oddělené, vývojáři někdy předpokládají, že pokud požadavek dosáhl funkce, musel být již autentizován API Gateway.

Ale co se stane, pokud existuje způsob, jak funkci spustit přímo, obejít gateway? Nebo co když funkce neověří, zda má uživatel oprávnění k přístupu ke konkrétnímu ID zdroje, o který žádá? To vede k Insecure Direct Object References (IDOR), kde může uživatel změnit userId v požadavku a vidět data někoho jiného.

Dependency Hell v cloudu

Serverless podporuje používání mnoha malých knihoven, aby byl balíček pro nasazení úsporný. Nicméně, každý jednotlivý npm nebo pip balíček, který zahrnete, je potenciální zadní vrátka. Protože jsou tyto funkce nasazovány často a automaticky, kompromitovaná závislost může být během několika sekund nasazena do produkce napříč tisíci funkcemi.

Základní komponenty Cloud Penetration Testing

Pokud chcete své nastavení řádně zabezpečit, nemůžete jen spustit skript a považovat to za hotové. Potřebujete vrstvený přístup, který napodobuje myšlení skutečného útočníka.

1. Revize architektury a modelování hrozeb

Začnete zmapováním toku. Odkud pocházejí data? Které funkce komunikují s kterými databázemi? Kde jsou hranice důvěry?

Dobrý model hrozeb se ptá: "Pokud by byla tato konkrétní Lambda funkce kompromitována, co nejhoršího by se mohlo stát?" Pokud je odpověď "Získají klíče od celého království," přesně víte, na co se má vaše testování zaměřit.

2. Audit konfigurace

Toto je "nízko visící ovoce". Obrovskou součástí cloudového Penetration Testing je hledání chybných konfigurací. Hledáme:

Otevřené S3 buckety nebo veřejné EBS snapshoty.
Pevně zakódované API klíče v proměnných prostředí.
Nedostatečné šifrování dat uložených i přenášených.
Výchozí přihlašovací údaje na databázových instancích.

3. Dynamická analýza (DAST) pro Serverless

Toto je aktivní část testu. Cílem je odeslat "škodlivé" události do vašich funkcí a sledovat, jak reagují.

Fuzzing API Gateways: Odesílání neočekávaných znaků nebo nadměrných payloadů, abyste zjistili, zda funkce spadne nebo odhalí stack trace.
Manipulace s událostmi: Vytváření falešných S3 událostí nebo SNS zpráv, abyste zjistili, zda je funkce zpracovává bez řádné validace.
Timing Attacks: Měření, jak dlouho trvá funkci odpovědět, abyste zjistili, zda existuje konkrétní kus dat (např. hádání uživatelských jmen).

4. IAM Escalation Testing

Jakmile tester najde způsob, jak spustit kód ve funkci, nezastaví se tam. Pokusí se "vymanit" z omezeného rozsahu funkce. Zkontrolují aktuální IAM roli a pokusí se použít CLI poskytovatele cloudu, aby zjistili, co dalšího mohou dělat. Mohou vytvořit nového administrátorského uživatele? Mohou číst tajné klíče ze Secret Manageru? Zde spočívá skutečné nebezpečí.

Krok za krokem: Jak provést Serverless Security Assessment

Pokud máte za úkol zabezpečit serverless aplikaci, neimprovizujte. Postupujte podle strukturovaného procesu. Zde je praktický návod, jak obvykle probíhá profesionální posouzení.

Fáze 1: Průzkum

V cloudu je průzkum často o nalezení vstupních bodů.

Identifikujte koncové body: Najděte všechny API Gateway URL, Webhook koncové body a veřejně přístupné buckety.
Analyzujte veřejná data: Hledejte uniklé klíče na GitHubu nebo veřejné JS soubory, které odhalují vnitřní strukturu API.
Zmapujte spouštěče: Pochopte, které události spouštějí které funkce. Spouští nahrání do bucket-a funkci function-b?

Fáze 2: Objevování zranitelností

Nyní začnete systém zkoušet.

Testování vstupu: Vyzkoušejte klasické injekce (SQL, NoSQL, OS Command) na každém vstupním poli.
Testování logiky: Pokuste se obejít očekávaný tok. Pokud má proces být Step A -> Step B -> Step C, můžete spustit Step C přímo?
Skenování závislostí: Použijte nástroje ke kontrole známých zranitelností (CVE) v knihovnách používaných funkcemi.

Fáze 3: Exploatace ("Průlom")

Pokud najdete zranitelnost, pokusíte se prokázat její dopad.

Proof of Concept (PoC): Můžete skutečně číst soubor, který byste neměli? Můžete upravit záznam v databázi?
Doručení payloadu: Použijte payload k exfiltraci dočasných bezpečnostních přihlašovacích údajů (AWS_ACCESS_KEY_ID a AWS_SECRET_ACCESS_KEY), které poskytovatel cloudu vkládá do prostředí funkce.

Fáze 4: Post-Exploatace a laterální pohyb

Toto je nejdůležitější fáze pro pochopení obchodního rizika.

Posouzení přihlašovacích údajů: Použijte ukradené dočasné klíče, abyste zjistili, ke kterým dalším službám mají přístup.
Pivot: Zjistěte, zda můžete použít kompromitovanou funkci k útoku na jiné interní služby, které nejsou vystaveny internetu.
Exfiltrace dat: Pokuste se přesunout malý kousek citlivých dat z prostředí, abyste prokázali, že by mohlo dojít k narušení.

Srovnání tradičního Pen Testing vs. Cloud-Native Pen Testing

Je běžné, že se společnosti snaží používat své staré kontrolní seznamy pro Pen Testing pro své nové cloudové aplikace. Téměř nikdy to nefunguje. Zde je důvod, proč jsou zásadně odlišné.

Feature	Traditional Pen Testing	Cloud-Native/Serverless Pen Testing
Target	IP Addresses, Servers, Ports	APIs, Event Triggers, IAM Roles
Focus	OS Vulnerabilities, Network Flaws	Logic Errors, Misconfigurations, Permissions
Persistence	Installing a Backdoor/Rootkit	Stealing Temporary Tokens, Role Assumption
Tooling	Nmap, Metasploit, Nessus	Cloud Custodian, Burp Suite, Custom Event Scripts
Perimeter	Firewalls & VPNs	Identity is the new perimeter (IAM)
Speed	Slower, focused on "deep" access	Faster, focused on "wide" access across services

Řešení problému s "hlukem": Monitorování a protokolování v serverless

Jedním z největších problémů v serverless zabezpečení je, že protokoly jsou rozptýlené. Máte protokoly API Gateway, protokoly CloudWatch, trasování X-Ray a možná i nějaké protokoly třetích stran.

Pokud útočník zasahuje vaše funkce tisíci různými payloady, jak poznáte, že se jedná o útok, a ne jen o chybný frontend?

Důležitost centralizovaného protokolování

Nemůžete zabezpečit to, co nevidíte. Chcete-li, aby byla vaše serverless aplikace skutečně neprůstřelná, musíte odesílat protokoly do centralizovaného systému (jako je SIEM), kde můžete korelovat události.

Pokud například uvidíte náhlý nárůst chyb 403 Forbidden na vaší API Gateway, následovaný jedním 200 OK na citlivém endpointu, je to klasický příznak úspěšného útoku hrubou silou nebo injection útoku. Pokud jsou tyto protokoly na dvou různých místech, vzorec vám unikne.

Implementace "Security-as-Code"

Protože serverless je především o automatizaci, mělo by to platit i pro vaše zabezpečení. Místo provádění Penetration Testu jednou ročně se posuňte směrem k průběžnému zabezpečení.

Infrastructure as Code (IaC) Scanning: Používejte nástroje ke skenování vašich šablon Terraform nebo CloudFormation před jejich nasazením. Pokud šablona definuje S3 bucket jako veřejný, sestavení by mělo automaticky selhat.
Automatizované zábrany: Nastavte zásady, které zabraňují určitým akcím v celém účtu (např. "Nikdo nesmí vytvořit uživatele IAM s přístupem Administrator").

Jak Penetrify zjednodušuje Cloud Penetration Testing

Dělat to všechno ručně je noční můra. Buď potřebujete obrovský tým drahých bezpečnostních konzultantů, nebo vývojáře, který tráví polovinu svého času čtením bezpečnostních blogů místo psaní funkcí.

Zde se hodí Penetrify. Místo toho, abyste se snažili vybudovat si vlastní bezpečnostní laboratoř nebo hádat, kde jsou díry, Penetrify poskytuje cloud-native platformu pro identifikaci, posouzení a nápravu těchto zranitelností.

Už žádné bolesti hlavy s infrastrukturou

Tradiční testovací nástroje často vyžadují, abyste nastavili "skenovací agenty" nebo specializovaný hardware. Penetrify je cloudový. Nemusíte nic instalovat na svůj místní počítač ani spouštět samostatné virtuální počítače jen proto, abyste otestovali své prostředí. Získáte komplexní pohled na své bezpečnostní postavení bez kapitálových výdajů na specializované vybavení.

Škálování vašeho zabezpečení

Pro společnosti střední velikosti není vždy možné najmout pět penetračních testerů na plný úvazek. Penetrify vám umožňuje škálovat vaše testovací schopnosti. Ať už máte deset funkcí nebo deset tisíc, platforma vám může pomoci automatizovat proces skenování a zároveň poskytnout hloubku potřebnou pro ruční posouzení.

Překlenutí propasti mezi nalezením a opravou

Nejhorší částí Penetration Testu je obdržení 100stránkového PDF se "zranitelnostmi", které vývojáři poté ignorují, protože nevědí, jak je opravit. Penetrify se zaměřuje na pokyny k nápravě. Neříká jen "Máte nadměrně privilegovanou roli IAM"; pomáhá vám přesně pochopit, jak tuto roli zpřísnit, abyste dodržovali zásadu nejmenšího privilegia.

Průběžné monitorování vs. testy v daném okamžiku

Penetration Test je snímek. V okamžiku, kdy nasadíte novou verzi svého kódu, je tento snímek zastaralý. Penetrify pomáhá organizacím posunout se směrem k modelu průběžného monitorování. Integrací s vašimi stávajícími pracovními postupy zajišťuje, že nové zranitelnosti budou zachyceny, jakmile jsou zavedeny, spíše než o šest měsíců později během ročního auditu.

Běžné chyby při zabezpečování serverless aplikací

I zkušení vývojáři dělají tyto chyby. Pokud je vidíte ve svém kódu, měli byste okamžitě upřednostnit Penetration Test.

1. Používání jedné role IAM pro všechny funkce

Pokud každá funkce ve vaší aplikaci sdílí stejnou roli "AppRole," máte obrovský poloměr výbuchu. Pokud je funkce "Kontaktujte nás" kompromitována, útočník má nyní oprávnění funkce "Zpracovat platby". Každá funkce by měla mít svou vlastní vyhrazenou roli.

2. Důvěra "interní" síti

Někteří lidé si myslí, že protože je funkce spouštěna jinou interní funkcí, jsou data "v bezpečí." To je chyba. Pokud útočník kompromituje první funkci, může poslat škodlivé payloady do druhé. Vždy ověřujte vstup, bez ohledu na to, odkud pochází.

3. Pevné kódování hesel v proměnných prostředí

I když jsou proměnné prostředí lepší než pevné kódování klíčů ve skriptu, jsou stále často viditelné v cloudové konzoli nebo unikají v protokolech. Použijte vyhrazeného správce hesel (jako je AWS Secrets Manager nebo HashiCorp Vault) a stáhněte klíče za běhu.

4. Ignorování nastavení "Timeout" a "Memory"

Tohle je záludné. Pokud nastavíte časový limit funkce na 15 minut a přidělíte jí 10 GB RAM, vytvořili jste ideální cíl pro útoky typu Denial of Wallet (DoW). Útočník může odeslat složité požadavky, které donutí vaše funkce běžet po maximální dobu a využívat maximální paměť, čímž se váš účet za cloud během několika hodin vyšplhá do tisíců dolarů.

Praktický kontrolní seznam pro serverless zabezpečení

Pokud dnes míříte na bezpečnostní kontrolu, použijte tento kontrolní seznam, abyste se ujistili, že jste pokryli základy.

Identity and Access Management (IAM)

Má každá funkce svou vlastní jedinečnou roli IAM?
Existují nějaké role s oprávněními * (wildcard)?
Používáme dočasné přihlašovací údaje namísto dlouhodobých klíčů uživatelů IAM?
Je pro všechny uživatele s přístupem ke cloudové konzoli povoleno MFA?

Input and Data Handling

Jsou všechny vstupy z triggerů událostí (S3, SNS, SQS) před použitím sanitizovány?
Používáme parametrizované dotazy pro všechny interakce s databází?
Jsou citlivá data šifrována jak v klidovém stavu, tak i během přenosu?
Zakázali jsme podrobné chybové zprávy (stack traces) v produkčním prostředí?

Network and Infrastructure

Jsou API Gateways chráněny Web Application Firewallem (WAF)?
Používáme VPC pro funkce, které potřebují přístup k interním zdrojům?
Jsou všechny S3 buckety ve výchozím nastavení nastaveny jako soukromé?
Implementovali jsme omezení rychlosti, abychom zabránili útokům DoS/DoW?

Observability and Governance

Jsou všechny protokoly funkcí odesílány do centrálního umístění?
Máme upozornění na neobvyklé nárůsty v provádění funkcí nebo chybách?
Je naše Infrastructure as Code (IaC) skenována na nesprávné konfigurace?
Máme zdokumentovaný proces pro opravy zranitelných závislostí?

Uvedení všeho dohromady: Scénář z reálného světa

Podívejme se na hypotetický scénář, abychom viděli, jak tyto prvky do sebe zapadají.

Aplikace: Serverless služba pro zpracování obrázků. Uživatelé nahrají fotografii do S3 bucketu, což spustí funkci Lambda, která změní velikost obrázku a uloží odkaz do tabulky DynamoDB.

Zranitelnost: Vývojář použil běžnou knihovnu pro zpracování obrázků, která měla známou zranitelnost umožňující Remote Code Execution (RCE), pokud byl nahrán speciálně vytvořený .jpg soubor. Pro usnadnění byla funkci Lambda udělena oprávnění s3:* a dynamodb:*.

Cesta útoku:

Útočník nahraje škodlivý obrazový soubor.
Spustí se funkce Lambda, knihovna se zhroutí a útočník získá shell uvnitř prostředí funkce.
Útočník spustí env a najde dočasné bezpečnostní tokeny AWS.
Protože je role nadměrně privilegovaná, útočník použije tyto tokeny k výpisu všech S3 bucketů v účtu.
Najdou bucket s názvem customer-backups-2023 a stáhnou celý obsah.

Prevence (Způsob "neprůstřelný"):

Skenování závislostí: Nástroj jako Penetrify by označil zranitelnou knihovnu obrázků během procesu sestavení.
Nejmenší privilegium: Pokud by funkce měla pouze s3:GetObject pro jeden konkrétní bucket a dynamodb:PutItem pro jednu tabulku, útočník by nemohl vypsat ostatní buckety.
WAF/Validace vstupu: WAF mohl zablokovat nahrávání souborů s podezřelými hlavičkami.
Monitorování: Upozornění by se spustilo, když funkce Lambda náhle začala provádět volání ListBuckets – akce, kterou během normálního provozu nikdy neprovádí.

FAQ: Časté dotazy ohledně Serverless Penetration Testing

Otázka: Opravdu potřebuji Penetration Test, pokud používám spravovanou službu, jako je AWS Lambda? Odpověď: Ano. AWS spravuje server, ale vy spravujete logiku. Většina serverless narušení se stane kvůli chybám na úrovni aplikace nebo nesprávným konfiguracím IAM, nikoli proto, že by byla napadena základní platforma Lambda.

Otázka: Nezruší Penetration Testing mé produkční prostředí? Odpověď: Může, pokud se provádí špatně. Proto se profesionální testování obvykle provádí v testovacím prostředí, které zrcadlí produkční prostředí. Cloudové nástroje jsou však navrženy tak, aby byly méně rušivé než staré skenery typu "kladivo na server".

Otázka: Jak často bych měl provádět cloudový Penetration Testing? Odpověď: Minimálně jednou ročně nebo po jakékoli zásadní architektonické změně. Zlatým standardem je však "Continuous Security" – integrace automatizovaného skenování do vašeho CI/CD pipeline, takže každý commit je testován.

Otázka: Nemůžu jen použít automatizovaný skener zranitelností? Odpověď: Automatizované skenery jsou skvělé pro hledání známých CVE nebo otevřených portů, ale jsou mizerné v hledání logických chyb. Neřeknou vám, že vaše funkce "Admin" může být spuštěna uživatelem "Guest". Potřebujete kombinaci automatizovaného skenování a manuální lidské odbornosti.

Otázka: Je serverless skutečně bezpečnější než tradiční VPS hosting? Odpověď: V mnoha ohledech ano. Zbavíte se celé třídy zranitelností (jako jsou nesprávné konfigurace SSH nebo exploity jádra OS). Ale zavedete nové. Není to "více" nebo "méně" bezpečné; je to jen jiný soubor rizik.

Závěrečné myšlenky a další kroky

Přechod na serverless je skvělý krok pro rychlost a škálovatelnost, ale neměl by být zkratkou pro zabezpečení. "Magie" cloudu – abstrakce, automatizace, efemérnost – je přesně to, co z něj dělá výzvu k zabezpečení.

Pokud jste se spoléhali na mentalitu „to spravuje poskytovatel“, je na čase to změnit. Začněte auditem vašich IAM rolí. Vyčistěte ty zástupné (wildcard) permise. Podívejte se na vaše závislosti. A co je nejdůležitější, přestaňte se chovat k bezpečnosti jako k poslednímu zaškrtávacímu políčku na konci projektu.

Cílem není postavit zeď kolem vaší aplikace – protože v cloudu žádné zdi nejsou. Cílem je vybudovat odolný systém, kde je každá jednotlivá komponenta zabezpečená, každé oprávnění je minimalizováno a každá událost je ověřena.

Pokud se cítíte zahlceni složitostí vašeho cloudového prostředí, nemusíte to dělat sami. Platformy jako Penetrify jsou navrženy tak, aby odstranily dohady z celého procesu. Kombinací automatizovaného skenování s cloudovou architekturou vám pomohou najít slabá místa dříve, než to udělají ti špatní.

Jste připraveni zjistit, kde jsou vaše slepá místa? Nečekejte na narušení bezpečnosti, abyste zjistili, že vaše IAM role jsou příliš benevolentní. Přejděte na Penetrify a začněte zabezpečovat svou serverless infrastrukturu ještě dnes. Vaše data – a váš spánek – vám poděkují.

Zpět na blog