Pravdepodobne ste už počuli túto frázu: "Serverless je budúcnosť." Už žiadne záplatovanie OS jadier, žiadne starosti s využitím CPU na konkrétnom VM a žiadne platenie za nečinné servery. Znie to ako sen. Jednoducho nahráte svoj kód do AWS Lambda, Google Cloud Function alebo Azure Function a poskytovateľ cloudových služieb sa postará o zvyšok.
Ale tu je vec, ktorá sa v marketingových prezentáciách často prehliada: "Serverless" v skutočnosti neznamená, že neexistujú žiadne servery. Znamená to len, že ich spravuje niekto iný. Zatiaľ čo Amazon alebo Microsoft sa starajú o fyzický hardvér a záplatovanie runtime, vy ste stále zodpovední za kód, ktorý píšete, povolenia, ktoré udeľujete, a dáta, s ktorými manipulujete.
Mnohé tímy robia chybu, keď si myslia, že prechod na serverless architektúru automaticky zmenší ich útočnú plochu. V skutočnosti to často len zmení jej tvar. Vymenili ste niekoľko veľkých, monolitických serverov za stovky malých, efemérnych funkcií. Každá z týchto funkcií je potenciálny vstupný bod. Ak je jedna funkcia nesprávne nakonfigurovaná alebo má zraniteľnosť, útočník by sa mohol potenciálne dostať cez celé vaše cloudové prostredie.
Tu prichádza na rad cloudový Penetration Testing. Nemôžete použiť tradičné sieťové skenery na serverless aplikáciu, pretože neexistuje žiadna trvalá IP adresa na skenovanie. Potrebujete iný prístup – taký, ktorý rozumie logike architektúr riadených udalosťami a zvláštnostiam cloudových povolení.
Prečo Serverless Architektúry Vyžadujú Špecifický Bezpečnostný Prístup
Počas rokov bola bezpečnosť o budovaní "priekopy" okolo dátového centra. Mali ste firewall, DMZ a niekoľko prísne strážených brán. Ak sa niekto dostal cez firewall, bol v sieti a tam ste s ním bojovali.
Serverless tento model obracia hore nohami. V serverless prostredí je váš "perimeter" teraz vaša API gateway, vaše spúšťacie udalosti a vaše IAM (Identity and Access Management) roly. Útočná plocha je fragmentovaná. Namiesto jedných veľkých dverí máte tisíc malých okien.
Mýtus o "Zdedenej Bezpečnosti"
Bežná mylná predstava je, že poskytovateľ cloudových služieb rieši všetku bezpečnosť. Toto je "Model Zdieľanej Zodpovednosti" a práve tu dochádza k väčšine narušení, pretože ľudia nerozumejú tomu, kde sa končí práca poskytovateľa a začína tá vaša.
Poskytovateľ zabezpečuje samotný cloud – virtualizačnú vrstvu, fyzické disky a základný OS. Vy zabezpečujete všetko vnútri cloudu. To zahŕňa:
- Kód: Ak má vaša Node.js funkcia zraniteľnosť v knižnici tretej strany, AWS to za vás neopraví.
- Konfigurácia: Ak omylom nastavíte svoj S3 bucket na "public", je to na vás.
- Povolenia: Ak má vaša Lambda funkcia
AdministratorAccessnamiesto iba povolenia na zápis do jednej konkrétnej databázovej tabuľky, vytvorili ste obrovskú bezpečnostnú dieru.
Výzva Efemérnych Aktív
Tradičný Penetration Testing často zahŕňa "perzistenciu" – kde tester získa prístup k serveru a udržiava si tento prístup, aby zistil, čo môže nájsť. V serverless prostredí "server" existuje možno 200 milisekúnd a potom zmizne.
Nerobí to bezpečnejším; len to sťažuje monitorovanie. Útočníci sa naučili prispôsobiť. Nesnažia sa "sedieť" na serveri; zameriavajú sa na "event injection" a "permission escalation." Hľadajú spôsoby, ako oklamať vašu funkciu, aby vykonala príkaz alebo prezradila tajný kľúč, ktorý im umožní laterálny pohyb cez váš cloudový účet.
Bežné Zraniteľnosti v Serverless Aplikáciách
Skôr ako môžete testovať diery, musíte vedieť, kde sa zvyčajne nachádzajú. Serverless aplikácie majú jedinečné režimy zlyhania. Aj keď sa stále zaoberáte OWASP Top 10 (ako SQL Injection), prejavujú sa odlišne v cloud-native svete.
Event Injection: Nové SQLi
V tradičnej aplikácii používateľský vstup zvyčajne pochádza z HTTP požiadavky. V serverless prostredí môže vstup pochádzať odkiaľkoľvek: z nahrávania S3 bucketu, DynamoDB streamu, Pub/Sub správy alebo e-mailu cez SES.
Ak vaša funkcia dôveruje dátam prichádzajúcim zo spúšťača udalostí bez toho, aby ich sanitizovala, máte problém s injection. Napríklad, ak je funkcia spustená nahrávaním súboru a potom použije názov súboru v systémovom príkaze na spracovanie obrázka, útočník by mohol nahrať súbor s názvom ; rm -rf /; .jpg. Ak kód nie je opatrný, môže tento príkaz vykonať.
Príliš Rozsiahle IAM Roly
Toto je pravdepodobne najväčšie riziko v cloudových prostrediach. Pretože je "jednoduchšie" dať funkcii FullAccess k službe, ako stráviť hodinu zisťovaním presných 12 povolení, ktoré potrebuje, mnohí vývojári sa vydávajú cestou najmenšieho odporu.
Predstavte si funkciu, ktorá potrebuje iba prečítať jeden konkrétny súbor z S3 bucketu. Ak má pridelené povolenia s3:*, útočník, ktorý nájde zraniteľnosť v spustení kódu v tejto funkcii, môže teraz vypísať každý bucket vo vašom účte, stiahnuť údaje o vašich zákazníkoch alebo dokonca vymazať vaše zálohy. Cloudový Penetration Testing sa silne zameriava na audity "least privilege" na nájdenie týchto medzier.
Narušená Autentifikácia a Autorizácia
Pretože serverless funkcie sú často oddelené, vývojári niekedy predpokladajú, že ak požiadavka dosiahla funkciu, musela byť už autentifikovaná API Gateway.
Čo sa však stane, ak existuje spôsob, ako spustiť funkciu priamo, obídením gateway? Alebo čo ak funkcia neoverí, či má používateľ povolenie na prístup ku konkrétnemu ID zdroja, o ktorý žiada? To vedie k Insecure Direct Object References (IDOR), kde používateľ môže zmeniť userId v požiadavke a vidieť údaje niekoho iného.
Dependency Hell v Cloude
Serverless podporuje používanie mnohých malých knižníc, aby bol balík nasadenia štíhly. Avšak, každý jeden npm alebo pip balík, ktorý zahrniete, je potenciálny backdoor. Keďže sú tieto funkcie nasadzované často a automaticky, kompromitovaná závislosť môže byť v priebehu sekúnd nasadená do produkcie naprieč tisíckami funkcií.
Základné komponenty Cloud Penetration Testing
Ak chcete svoju konfiguráciu správne zabezpečiť, nemôžete len spustiť skript a považovať to za hotové. Potrebujete vrstvený prístup, ktorý napodobňuje myslenie skutočného útočníka.
1. Revízia architektúry a modelovanie hrozieb
Začnete zmapovaním toku. Odkiaľ pochádzajú dáta? Ktoré funkcie komunikujú s ktorými databázami? Kde sú hranice dôvery?
Dobrý model hrozieb sa pýta: "Ak by bola táto konkrétna Lambda funkcia kompromitovaná, čo najhoršie by sa mohlo stať?" Ak je odpoveď "Získajú kľúče od celého kráľovstva," presne viete, na čo sa má vaše testovanie zamerať.
2. Audit konfigurácie
Toto je "ľahko dostupná korisť". Obrovská časť cloudového Penetration Testing je hľadanie nesprávnych konfigurácií. Hľadáme:
- Otvorené S3 buckety alebo verejné EBS snapshoty.
- Pevne zakódované API kľúče v premenných prostredia.
- Nedostatok šifrovania dát pri uložení alebo prenose.
- Predvolené prihlasovacie údaje na databázových inštanciách.
3. Dynamická analýza (DAST) pre Serverless
Toto je aktívna časť testu. Cieľom je posielať "škodlivé" udalosti do vašich funkcií a sledovať, ako reagujú.
- Fuzzing API Gateways: Posielanie neočakávaných znakov alebo nadrozmerných payloadov, aby sa zistilo, či funkcia spadne alebo odhalí stack trace.
- Manipulácia s udalosťami: Vytváranie falošných S3 udalostí alebo SNS správ, aby sa zistilo, či ich funkcia spracováva bez riadnej validácie.
- Timing Attacks: Meranie, ako dlho trvá funkcii odpovedať, aby sa zistilo, či existuje konkrétny údaj (napr. hádanie používateľských mien).
4. IAM Escalation Testing
Keď tester nájde spôsob, ako spustiť kód vo funkcii, nekončí tam. Pokúša sa "vymanévrovať" z obmedzeného rozsahu funkcie. Skontroluje aktuálnu IAM rolu a pokúsi sa použiť CLI cloudového poskytovateľa, aby zistil, čo ešte môže urobiť. Môže vytvoriť nového admin používateľa? Môže čítať tajomstvá zo Secret Manager? Tu spočíva skutočné nebezpečenstvo.
Krok za krokom: Ako vykonať Serverless Security Assessment
Ak máte za úlohu zabezpečiť serverless aplikáciu, nerobte to len tak náhodne. Postupujte podľa štruktúrovaného procesu. Tu je praktický návod, ako zvyčajne prebieha profesionálne hodnotenie.
Fáza 1: Prieskum
V cloude je prieskum často o hľadaní vstupných bodov.
- Identifikácia Endpointov: Nájdite všetky API Gateway URL, Webhook endpointy a verejne prístupné buckety.
- Analýza verejných dát: Hľadajte uniknuté kľúče na GitHub alebo verejné JS súbory, ktoré odhaľujú vnútornú štruktúru API.
- Zmapovanie Triggerov: Pochopte, ktoré udalosti spúšťajú ktoré funkcie. Spúšťa nahrávanie do
bucket-afunkciufunction-b?
Fáza 2: Objavovanie zraniteľností
Teraz začnete systém skúšať.
- Input Testing: Vyskúšajte klasické injekcie (SQL, NoSQL, OS Command) na každom vstupnom poli.
- Logic Testing: Pokúste sa obísť očakávaný tok. Ak má proces byť
Step A -> Step B -> Step C, môžete spustiťStep Cpriamo? - Dependency Scanning: Použite nástroje na kontrolu známych zraniteľností (CVEs) v knižniciach používaných funkciami.
Fáza 3: Exploitation (The "Break-In")
Ak nájdete zraniteľnosť, pokúsite sa dokázať jej dopad.
- Proof of Concept (PoC): Môžete skutočne čítať súbor, ktorý by ste nemali? Môžete upraviť záznam v databáze?
- Payload Delivery: Použite payload na exfiltráciu dočasných bezpečnostných prihlasovacích údajov (
AWS_ACCESS_KEY_IDaAWS_SECRET_ACCESS_KEY), ktoré cloudový poskytovateľ vkladá do prostredia funkcie.
Fáza 4: Post-Exploitation a Lateral Movement
Toto je najkritickejšia fáza pre pochopenie obchodného rizika.
- Credential Assessment: Použite ukradnuté dočasné kľúče na zistenie, ku ktorým ďalším službám majú prístup.
- Pivot: Zistite, či môžete použiť kompromitovanú funkciu na útok na iné interné služby, ktoré nie sú vystavené internetu.
- Data Exfiltration: Pokúste sa presunúť malý kúsok citlivých údajov z prostredia, aby ste dokázali, že by mohlo dôjsť k narušeniu.
Porovnanie tradičného Pen Testing vs. Cloud-Native Pen Testing
Je bežné, že sa spoločnosti pokúšajú použiť svoje staré kontrolné zoznamy Pen Testing pre svoje nové cloudové aplikácie. Takmer nikdy to nefunguje. Tu je dôvod, prečo sú zásadne 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 |
Riešenie problému s "hlukom": Monitorovanie a protokolovanie v Serverless
Jedným z najväčších problémov v oblasti serverless bezpečnosti je, že protokoly sú roztrúsené. Máte protokoly API Gateway, protokoly CloudWatch, X-Ray traces a možno aj nejaké protokoly tretích strán.
Ak útočník zasiahne vaše funkcie tisíckami rôznych payloadov, ako zistíte, či ide o útok a nie len o chybný frontend?
Dôležitosť centralizovaného protokolovania
Nemôžete zabezpečiť to, čo nevidíte. Ak chcete, aby bola vaša serverless aplikácia skutočne nepriestrelná, musíte odosielať svoje protokoly do centralizovaného systému (ako je SIEM), kde môžete korelovať udalosti.
Napríklad, ak vidíte náhly nárast chýb 403 Forbidden na vašej API Gateway, po ktorom nasleduje jediný 200 OK na citlivom koncovom bode, je to klasický znak úspešného útoku hrubou silou alebo injection útoku. Ak sú tieto protokoly na dvoch rôznych miestach, vzor vám unikne.
Implementácia "Security-as-Code"
Keďže serverless je o automatizácii, aj vaša bezpečnosť by mala byť. Namiesto toho, aby ste raz ročne robili Penetration Test, prejdite na nepretržitú bezpečnosť.
- Skenovanie Infrastructure as Code (IaC): Používajte nástroje na skenovanie vašich šablón Terraform alebo CloudFormation predtým, ako sú nasadené. Ak šablóna definuje S3 bucket ako verejný, zostava by mala automaticky zlyhať.
- Automatizované zábrany: Nastavte politiky, ktoré zabránia určitým akciám v celom účte (napr. "Nikto nesmie vytvoriť používateľa IAM s prístupom správcu").
Ako Penetrify zjednodušuje Cloud Penetration Testing
Robiť toto všetko manuálne je nočná mora. Potrebujete buď rozsiahly tím drahých bezpečnostných konzultantov, alebo vývojára, ktorý trávi polovicu svojho času čítaním bezpečnostných blogov namiesto písania funkcií.
Tu prichádza na rad Penetrify. Namiesto toho, aby ste sa pokúšali vybudovať si vlastné bezpečnostné laboratórium alebo hádali, kde sú diery, Penetrify poskytuje cloud-natívnu platformu na identifikáciu, posúdenie a nápravu týchto zraniteľností.
Už žiadne bolesti hlavy s infraštruktúrou
Tradičné testovacie nástroje často vyžadujú, aby ste nastavili "skenovacie agenty" alebo špecializovaný hardvér. Penetrify je cloudový. Nemusíte nič inštalovať na svojom lokálnom počítači ani spúšťať samostatné virtuálne počítače len na testovanie svojho prostredia. Získate komplexný pohľad na svoje bezpečnostné postavenie bez kapitálových výdavkov na špecializované vybavenie.
Škálovanie vašej bezpečnosti
Pre spoločnosti strednej triedy nie je vždy možné najať päť penetračných testerov na plný úväzok. Penetrify vám umožňuje škálovať vaše testovacie schopnosti. Či už máte desať funkcií alebo desaťtisíc, platforma vám môže pomôcť automatizovať proces skenovania a zároveň poskytnúť hĺbku potrebnú na manuálne posúdenie.
Prepojte medzeru medzi hľadaním a opravou
Najhoršia časť Penetration Testu je prijatie 100-stranového PDF súboru so "zraniteľnosťami", ktoré vývojári potom ignorujú, pretože nevedia, ako ich opraviť. Penetrify sa zameriava na usmernenie pri náprave. Nehovorí len "Máte nadmerne privilegovanú rolu IAM"; pomáha vám presne pochopiť, ako sprísniť túto rolu, aby ste dodržiavali zásadu najmenších privilégií.
Neustále monitorovanie vs. testy v danom čase
Penetration Test je snímka. V momente, keď nasadíte novú verziu svojho kódu, je táto snímka zastaraná. Penetrify pomáha organizáciám prejsť na model nepretržitého monitorovania. Integráciou s vašimi existujúcimi pracovnými postupmi zabezpečuje, že nové zraniteľnosti sú zachytené hneď, ako sú zavedené, a nie o šesť mesiacov neskôr počas ročného auditu.
Bežné chyby pri zabezpečovaní Serverless aplikácií
Tieto chyby robia aj skúsení vývojári. Ak ich vidíte vo svojej kódovej základni, mali by ste okamžite uprednostniť Penetration Test.
1. Používanie jednej roly IAM pre všetky funkcie
Ak každá funkcia vo vašej aplikácii zdieľa rovnakú "AppRole", máte rozsiahly polomer výbuchu. Ak je funkcia "Kontaktujte nás" ohrozená, útočník má teraz povolenia funkcie "Spracovať platby". Každá funkcia by mala mať svoju vlastnú vyhradenú rolu.
2. Dôverovanie "internej" sieti
Niektorí ľudia si myslia, že pretože funkciu spúšťa iná interná funkcia, dáta sú "v bezpečí". To je chyba. Ak útočník ohrozí prvú funkciu, môže posielať škodlivé payloady do druhej funkcie. Vždy overujte vstup, bez ohľadu na to, odkiaľ pochádza.
3. Pevné kódovanie tajných kľúčov v premenných prostredia
Hoci sú premenné prostredia lepšie ako pevné kódovanie kľúčov v skripte, stále sú často viditeľné v cloudovej konzole alebo unikajú v protokoloch. Používajte vyhradeného správcu tajných kľúčov (ako je AWS Secrets Manager alebo HashiCorp Vault) a načítajte kľúče za behu.
4. Ignorovanie nastavení "Timeout" a "Memory"
Toto je záludné. Ak nastavíte časový limit pre vašu funkciu na 15 minút a pridelíte jej 10 GB RAM, vytvorili ste ideálny cieľ pre útoky typu Denial of Wallet (DoW). Útočník môže posielať komplexné požiadavky, ktoré prinútia vaše funkcie bežať maximálny čas a využívať maximálnu pamäť, čím sa váš účet za cloud vyšplhá do tisícov dolárov v priebehu niekoľkých hodín.
Praktický kontrolný zoznam pre serverless bezpečnosť
Ak dnes idete na bezpečnostnú kontrolu, použite tento kontrolný zoznam, aby ste sa uistili, že ste pokryli základy.
Identity and Access Management (IAM)
- Má každá funkcia svoju vlastnú jedinečnú IAM rolu?
- Existujú nejaké roly s povoleniami
*(wildcard)? - Používame dočasné poverenia namiesto dlhodobých kľúčov používateľa IAM?
- Je pre všetkých používateľov s prístupom ku cloudovej konzole povolené MFA?
Input and Data Handling
- Sú všetky vstupy zo spúšťačov udalostí (S3, SNS, SQS) pred použitím sanitizované?
- Používame parametrizované dotazy pre všetky interakcie s databázou?
- Sú citlivé údaje šifrované v pokoji aj počas prenosu?
- Zakázali sme podrobné chybové hlásenia (stack traces) v produkcii?
Network and Infrastructure
- Sú API Gateways chránené Web Application Firewall (WAF)?
- Používame VPC pre funkcie, ktoré potrebujú prístup k interným zdrojom?
- Sú všetky S3 buckety predvolene nastavené ako súkromné?
- Implementovali sme obmedzenie rýchlosti na zabránenie útokom DoS/DoW?
Observability and Governance
- Sú všetky protokoly funkcií odosielané do centrálneho umiestnenia?
- Máme upozornenia na abnormálne nárasty v spúšťaní funkcií alebo chybách?
- Je naša Infrastructure as Code (IaC) skenovaná na miskonfigurácie?
- Máme zdokumentovaný proces pre opravu zraniteľných závislostí?
Spojenie všetkého dohromady: Scenár z reálneho sveta
Pozrime sa na hypotetický scenár, aby sme videli, ako tieto časti do seba zapadajú.
Aplikácia: Serverless služba na spracovanie obrázkov. Používatelia nahrávajú fotografiu do S3 bucketu, čo spustí funkciu Lambda na zmenu veľkosti obrázka a uloženie odkazu do tabuľky DynamoDB.
Zraniteľnosť: Vývojár použil bežnú knižnicu na spracovanie obrázkov, ktorá mala známu zraniteľnosť umožňujúcu Remote Code Execution (RCE), ak bol nahraný špeciálne vytvorený súbor .jpg. Pre uľahčenie bola funkcii Lambda pridelené povolenia s3:* a dynamodb:*.
Cesta útoku:
- Útočník nahrá škodlivý obrazový súbor.
- Spustí sa funkcia Lambda, knižnica zlyhá a útočník získa shell v prostredí funkcie.
- Útočník spustí
enva nájde dočasné bezpečnostné tokeny AWS. - Pretože je rola predimenzovaná, útočník použije tieto tokeny na zoznam všetkých S3 bucketov v účte.
- Nájdete bucket s názvom
customer-backups-2023a stiahnete si celú vec.
Prevencia (The "Bulletproof" Way):
- Skenovanie závislostí: Nástroj ako Penetrify by označil zraniteľnú knižnicu obrázkov počas procesu zostavovania.
- Najnižšie privilégiá: Ak by funkcia mala iba
s3:GetObjectpre jeden konkrétny bucket adynamodb:PutItempre jednu tabuľku, útočník by nemohol vypísať ostatné buckety. - WAF/Validácia vstupu: WAF mohol zablokovať nahrávanie súborov s podozrivými hlavičkami.
- Monitorovanie: Upozornenie by sa spustilo, keď funkcia Lambda zrazu začala uskutočňovať volania
ListBuckets– akcia, ktorú nikdy nevykonáva počas normálnej prevádzky.
FAQ: Časté otázky o Serverless Penetration Testing
Otázka: Naozaj potrebujem Penetration Test, ak používam spravovanú službu ako AWS Lambda? Odpoveď: Áno. AWS spravuje server, ale vy spravujete logiku. Väčšina serverless narušení sa stane kvôli chybám na úrovni aplikácie alebo miskonfiguráciám IAM, nie preto, že by bola hacknutá základná platforma Lambda.
Otázka: Nespôsobí Penetration Testing zlyhanie môjho produkčného prostredia? Odpoveď: Môže, ak sa to robí zle. Preto sa profesionálne testovanie zvyčajne vykonáva v testovacom prostredí, ktoré zrkadlí produkciu. Nástroje natívne pre cloud sú však navrhnuté tak, aby boli menej rušivé ako staré skenery typu "kladivo na server".
Otázka: Ako často by som mal vykonávať cloudový Penetration Testing? Odpoveď: Minimálne raz ročne alebo po akejkoľvek významnej architektonickej zmene. Zlatým štandardom je však "Continuous Security" – integrácia automatizovaného skenovania do vášho CI/CD pipeline, takže každý commit je testovaný.
Otázka: Nemôžem jednoducho použiť automatizovaný skener zraniteľností? Odpoveď: Automatizované skenery sú skvelé na hľadanie známych CVE alebo otvorených portov, ale sú na nič pri hľadaní logických chýb. Nepovedia vám, že vaša funkcia "Admin" môže byť spustená používateľom "Guest". Potrebujete kombináciu automatizovaného skenovania a manuálnych ľudských odborných znalostí.
Otázka: Je serverless skutočne bezpečnejší ako tradičný VPS hosting? Odpoveď: V mnohých ohľadoch áno. Zbavíte sa celej triedy zraniteľností (ako sú miskonfigurácie SSH alebo exploity OS jadra). Ale zavádzate nové. Nie je to "viac" alebo "menej" bezpečné; je to len iný súbor rizík.
Záverečné myšlienky a ďalšie kroky
Prechod na serverless je skvelý krok pre rýchlosť a škálovateľnosť, ale nemal by to byť skratka pre bezpečnosť. "Mágia" cloudu – abstrakcia, automatizácia, efemérnosť – je presne to, čo sťažuje jeho zabezpečenie.
Ak ste sa spoliehali na mentalitu "je to spravované poskytovateľom", teraz je čas to zmeniť. Začnite auditom svojich IAM rolí. Vyčistite tie wildcard povolenia. Pozrite sa na svoje závislosti. A čo je najdôležitejšie, prestaňte považovať bezpečnosť za posledný zaškrtávací bod na konci projektu.
Cieľom nie je postaviť múr okolo vašej aplikácie – pretože v cloude žiadne múry nie sú. Cieľom je vybudovať odolný systém, v ktorom je každý jeden komponent zabezpečený, každé povolenie je minimalizované a každá udalosť je validovaná.
Ak sa cítite zahltení zložitosťou vášho cloudového prostredia, nemusíte to robiť sami. Platformy ako Penetrify sú navrhnuté tak, aby odstránili dohady z tohto procesu. Kombináciou automatizovaného skenovania s cloudovou architektúrou vám pomôžu nájsť diery skôr, ako to urobia tí zlí.
Ste pripravení zistiť, kde sú vaše slabé miesta? Nečakajte na narušenie bezpečnosti, aby ste zistili, že vaše IAM roly sú príliš povoľujúce. Prejdite na Penetrify a začnite zabezpečovať svoju serverless infraštruktúru ešte dnes. Vaše dáta – a váš spánok – sa vám poďakujú.