Pravdepodobne ste strávili mesiace, ak nie roky, posilňovaním vlastného perimetra. Máte firewally, MFA a šifrované databázy. Ale tu je nepríjemná pravda: nedôverujete len svojmu tímu. Dôverujete každému jednému softvéru, každému API a každej cloudovej službe tretej strany, ktorá sa dotýka vášho prostredia.
Toto je váš cloudový dodávateľský reťazec. Je to zložitá sieť závislostí, ktorá vám umožňuje rýchly pohyb a škálovanie, ale je to tiež rozsiahla, neviditeľná útočná plocha. Keď si hacker uvedomí, že prelomiť dobre bránený podnik je príliš ťažké, neustále nebúši na predné dvere. Hľadá zadné vrátka – malý SaaS nástroj, ktorý používate na riadenie projektov, open-source knižnicu ukrytú vo vašom kóde alebo poskytovateľa spravovaných služieb s laxnými kontrolami prístupu.
Ak sa jeden z týchto článkov reťaze pretrhne, na vašej bezpečnosti nezáleží. Ste tak bezpečný, ako najslabší dodávateľ vo vašom stacku. Preto je tradičné "perimeter" myslenie mŕtve. Ak chcete skutočne chrániť svoje podnikanie, musíte prestať zaobchádzať s rizikom tretích strán ako s papierovačkou a začať s ním zaobchádzať ako s technickou realitou.
Tu prichádza na rad Penetration Testing. Nie ten typ testovania "odfajknúť si políčko", ale hlboké, agresívne simulácie, ktoré zaobchádzajú s celým vaším dodávateľským reťazcom ako s cieľom. V tejto príručke si rozoberieme, ako zabezpečiť váš cloudový dodávateľský reťazec a prečo je proaktívny Penetration Test jediný spôsob, ako zistiť, či vaša obrana skutočne funguje.
Čo presne je útok na cloudový dodávateľský reťazec?
Skôr ako sa dostaneme k "ako," musíme si ujasniť "čo." K útoku na cloudový dodávateľský reťazec dochádza, keď škodlivý aktér prenikne do vášho systému nie priamym útokom na vás, ale kompromitovaním prvku tretej strany, na ktorý sa spoliehate.
Predstavte si to ako vysoko zabezpečený trezor. Môžete mať desaťtonové oceľové dvere a biometrický skener, ale ak spoločnosť, ktorá vyrába zámky, nechá hlavný kľúč pod rohožkou vo svojej továrni, trezor v skutočnosti nie je bezpečný.
V cloudovom svete sa to zvyčajne deje niekoľkými konkrétnymi spôsobmi:
Softvérové závislosti a otvorený zdroj
Takmer nikto už nepíše kód od nuly. Používame balíčky, knižnice a frameworky. Ak je populárna open-source knižnica kompromitovaná – čo sme videli, že sa stalo s hlavnými balíčkami v ekosystémoch JavaScript a Python – tento škodlivý kód sa počas vášho ďalšieho buildu stiahne priamo do vášho produkčného prostredia. V podstate ste pozvali útočníka dovnútra vašich múrov.
SaaS tretích strán a API integrácie
Vaše cloudové prostredie je pravdepodobne pripojené k desiatkam SaaS platforiem. Tieto platformy majú často prístup "read/write" k vašim údajom prostredníctvom API. Ak je SaaS poskytovateľ narušený a jeho API kľúče uniknú, útočník môže použiť tieto legitímne poverenia na laterálny pohyb do vášho cloudového prostredia.
Poskytovatelia spravovaných služieb (MSP)
Mnoho spoločností outsourcuje správu cloudu MSP. Títo poskytovatelia majú často administratívny prístup na vysokej úrovni k viacerým klientom. Vďaka tomu sú "zlatou baňou" pre útočníkov. Jedno narušenie v MSP môže hackerovi udeliť prístup k stovkám rôznych podnikových sietí súčasne.
Infraštruktúra ako kód (IaC) šablóny
Ak na spustenie infraštruktúry používate vopred pripravené šablóny Terraform alebo CloudFormation z verejného úložiska, dôverujete, že šablóna je bezpečná. "Otrávená" šablóna by mohla tajne otvoriť port alebo vytvoriť backdoor používateľský účet v momente, keď ju nasadíte.
Prečo štandardná zhoda nestačí
Ak pôsobíte v regulovanom odvetví, pravdepodobne už riešite "Vendor Risk Management." To zvyčajne zahŕňa odoslanie 200-otázkového hárku vašim dodávateľom a požiadanie ich, aby podpísali zmluvu, v ktorej sa uvádza, že sú zabezpečení.
Tu je problém: správa SOC 2 alebo certifikácia ISO je snímka v čase. Hovorí vám, že dodávateľ mal zavedený proces v deň, keď ho audítor navštívil. Nehovorí vám, či majú dnes kritickú zraniteľnosť vo svojom API. Nehovorí vám, či nespokojný zamestnanec práve vložil backdoor do ich najnovšej aktualizácie.
Zhoda je o uspokojovaní audítorov; bezpečnosť je o zastavení útočníkov.
Zhoda sa zameriava na "Existuje táto politika?" Penetration Testing sa zameriava na "Môžem sa skutočne dostať dnu?" Keď používate platformu ako Penetrify, prechádzate od teoretickej bezpečnosti k preukázanej bezpečnosti. Namiesto toho, aby ste dôverovali PDF od dodávateľa, simulujete útok, ktorý presne napodobňuje, ako by hacker využil tieto pripojenia tretích strán.
Posúdenie rizika: Kde začať
Nemôžete testovať všetko naraz. Ak sa pokúsite vykonať Penetration Test každého jedného API volania a každej jednej knižnice, ktorú používate, nikdy nič nedokončíte. Potrebujete prístup založený na riziku.
Mapovanie vašich závislostí
Prvým krokom je viditeľnosť. Nemôžete chrániť to, o čom neviete, že existuje. Potrebujete komplexnú mapu vášho cloudového dodávateľského reťazca.
- Priame závislosti: Softvér, ktorý ste si kúpili, a API, ktoré ste zámerne integrovali.
- Tranzitívne závislosti: Knižnice, od ktorých sú závislé vaše knižnice. Tu sa zvyčajne skrýva skutočné nebezpečenstvo.
- Úrovne prístupu: Kto má k čomu prístup? Ktorí dodávatelia majú roly "Owner" alebo "Contributor" vo vašom prostredí Azure alebo AWS?
Kategorizácia podľa kritickosti
Nie všetci dodávatelia sú si rovní. Narušenie vášho poskytovateľa miezd je katastrofa; narušenie vašej aplikácie na objednávanie občerstvenia do kancelárie je nepríjemnosť. Zoskupte svoj dodávateľský reťazec do úrovní:
- Úroveň 1 (Kritická): Dodávatelia s prístupom k PII, finančným údajom alebo produkčnej infraštruktúre.
- Úroveň 2 (Dôležitá): Dodávatelia, ktorí poskytujú základné obchodné funkcie, ale majú obmedzený prístup k údajom.
- Úroveň 3 (Nízke riziko): Nástroje bez prístupu k citlivým údajom alebo interným systémom.
Vaše úsilie v oblasti Penetration Testing by malo byť silne zamerané na úroveň 1.
Ako Penetration Testing posilňuje cloudový dodávateľský reťazec
Penetration Testing nie je len o hľadaní chyby; je to o testovaní celého životného cyklu vášho dodávateľského reťazca. Tu je návod, ako vás profesionálny Penetration Test skutočne chráni pred hrozbami v dodávateľskom reťazci.
Testovanie "hranice dôvery"
Pentester sa zameriava na body, kde sa vaše prostredie stretáva s prostredím niekoho iného. Pýta sa: "Ak je tento dodávateľ kompromitovaný, čo môže útočník urobiť v mojej sieti?" Toto sa nazýva "analýza rozsahu dopadu". Simuláciou kompromitovaných poverení tretej strany môžete zistiť, či vaša interná segmentácia skutočne funguje, alebo či útočník môže preskočiť z menšej SaaS integrácie priamo do vašej zákazníckej databázy.
Validácia správy záplat
Mnohé útoky na dodávateľský reťazec sa spoliehajú na známe zraniteľnosti v zastaranom softvéri. Pentester preskenuje vaše prostredie na "ľahko dostupné ciele" – neopravené verzie bežných knižníc alebo zastarané cloudové konfigurácie. To vám povie, či váš automatizovaný proces záplatovania skutočne funguje, alebo či vám niečo uniká pomedzi prsty.
Vyhodnocovanie reakcie na incidenty
Jednou z najviac prehliadaných častí dodávateľského reťazca je komunikačná slučka. Ak vám dodávateľ povie, že bol narušený, viete presne, ktoré systémy izolovať? Cvičenie červeného tímu (pokročilejšia forma Penetration Testing) to môže otestovať. Testeri simulujú upozornenie na narušenie od dodávateľa a sledujú, ako rýchlo váš tím dokáže identifikovať postihnuté aktíva a vypnúť pripojenie.
Identifikácia "tieňového IT"
Pentesteri často nájdu veci, o ktorých IT oddelenie nevedelo. Možno sa marketingový manažér zaregistroval na "bezplatný" nástroj a udelil mu plný prístup do firemného Disku Google. Alebo možno vývojár nastavil dočasné testovacie prostredie, ktoré nikdy nebolo odstránené. Tieto "zabudnuté" pripojenia sú obľúbenými vstupnými bodmi pre útočníkov.
Krok za krokom: Budovanie stratégie zabezpečenia dodávateľského reťazca
Ak sa chcete posunúť z reaktívneho stavu do proaktívneho, postupujte podľa tohto rámca. Spája architektonické zmeny s aktívnym testovaním.
Krok 1: Implementujte prístup s najnižšími potrebnými oprávneniami
Prestaňte štandardne udeľovať dodávateľom prístup "Admin". Ak nástroj potrebuje iba čítať údaje z jedného konkrétneho S3 bucketu, udeľte mu prístup iba k tomuto bucketu.
- Používajte IAM roly s obmedzenými povoleniami.
- Implementujte prístup "Just-In-Time" (JIT) pre konzultantov alebo MSP.
- Pravidelne kontrolujte povolenia, aby ste odstránili prístup pre dodávateľov, ktorých už nepoužívate.
Krok 2: Vytvorte súpis softvérových komponentov (SBOM)
Predstavte si SBOM ako zoznam zložiek pre váš softvér. Je to formálny záznam obsahujúci podrobnosti a vzťahy dodávateľského reťazca rôznych komponentov použitých pri vytváraní softvéru. Keď je ohlásená nová zraniteľnosť (ako Log4j), nechcete stráviť tri dni prehľadávaním kódu. Chcete skontrolovať svoj SBOM a do niekoľkých sekúnd zistiť, či ste ovplyvnení.
Krok 3: Integrujte nepretržité testovanie zabezpečenia
Penetration Test "raz za rok" už nestačí. V cloudovom prostredí sa vaša infraštruktúra mení zakaždým, keď nahráte kód. Potrebujete nepretržitý prístup. Tu sa cloudová platforma ako Penetrify stáva prelomovou. Namiesto čakania na naplánovaný ročný audit môžete spúšťať časté, automatizované hodnotenia, ktoré vás upozornia na nové zraniteľnosti v momente, keď sa objavia. Premosťuje priepasť medzi "dnes sme zabezpečení" a "zajtra budeme zabezpečení".
Krok 4: Vynucujte prísne zabezpečenie API
API sú lepidlom cloudového dodávateľského reťazca a často sú zle chránené.
- Používajte silnú autentifikáciu (OAuth2, OpenID Connect).
- Implementujte obmedzenie rýchlosti, aby ste zabránili exfiltrácii údajov.
- Validujte všetky vstupy z API tretích strán. Nikdy nepredpokladajte, že údaje pochádzajúce od "dôveryhodného" partnera sú čisté.
Bežné chyby v zabezpečení dodávateľského reťazca
Aj skúsené tímy robia tieto chyby. Ak rozpoznáte tieto vzorce vo vašej organizácii, je čas zmeniť smer.
Pasca "Dôveruj, ale neoveruj"
Mnohé spoločnosti dôverujú dodávateľovi, pretože je to globálna značka. "Sú to spoločnosť z rebríčka Fortune 500; musia mať skvelé zabezpečenie." História dokazuje, že to nie je pravda. Niektoré z najväčších útokov na dodávateľský reťazec sa stali najväčším spoločnostiam na svete. Vaše zabezpečenie by malo byť založené na dôkazoch, nie na rozpoznávaní značky.
Ignorovanie tranzitívnych závislostí
Možno dôverujete knižnici, ktorú ste importovali, ale dôverujete 50 ďalším knižniciam, na ktorých táto knižnica závisí? Útočníci sa často zameriavajú na hlboké, nejasné závislosti, ktoré nie sú aktívne udržiavané veľkou komunitou. Preto sú potrebné hĺbkové Penetration Testing a analýza softvérovej kompozície (SCA).
Testovanie iba produkčného prostredia
Mnohé tímy testujú svoje produkčné prostredie, ale ignorujú svoj CI/CD pipeline. Ak útočník môže kompromitovať váš build server alebo vaše GitHub Actions, môže vložiť škodlivý kód priamo do vašej produkčnej aplikácie. Váš "pipeline" je súčasťou vášho dodávateľského reťazca a je potrebné ho tiež otestovať pomocou Penetration Testing.
Zaobchádzanie s Penetration Testami ako so zoznamom úloh
Najväčším plytvaním peniazmi v oblasti kybernetickej bezpečnosti je platenie za Penetration Test, získanie 50-stranového PDF so zraniteľnosťami a následné ponechanie tohto PDF v priečinku. Penetration Test je cenný iba vtedy, ak vedie k náprave. Potrebujete pracovný postup, ktorý premení "Zistenia" na "Tikety" a "Tikety" na "Záplaty".
Komparatívna analýza: Automatizované skenovanie vs. manuálny Penetration Testing
Často budete počuť ľudí tvrdiť, že automatizované skenery stačia. Nestačia. Na druhej strane, samotný manuálny Penetration Testing je príliš pomalý. Tajomstvom je hybridný prístup.
| Funkcia | Automatizované skenovanie | Manuálny Penetration Testing | Hybridný prístup (The Penetrify Way) |
|---|---|---|---|
| Rýchlosť | Takmer okamžitá | Týždne/mesiace | Rýchla a iteratívna |
| Hĺbka | Povrchová úroveň/Známe chyby | Hlboká logika/Komplexné reťazce | Široké pokrytie + hĺbkové analýzy |
| Cena | Nízka za sken | Vysoká za angažmán | Škálovateľná a predvídateľná |
| False Positives | Vysoký | Nízky | Filtrované a overené |
| Zameranie na dodávateľský reťazec | Nájde zastarané verzie | Nájde architektonické nedostatky | Komplexný prehľad |
Automatizované nástroje sú skvelé na zachytenie "základov" – zastaraných verzií, otvorených portov a nesprávne nakonfigurovaných bucketov. Ale ľudský pentester dokáže myslieť kreatívne. Človek môže povedať: "Ak použijem túto menšiu API chybu na získanie tokenu nízkej úrovne, môžem potom sfalšovať túto identitu, aby som oklamal panel správcu a získal plný prístup." Takéto "reťazenie" je spôsob, akým dochádza k skutočným narušeniam a preto potrebujete oboje.
Hlboká analýza: Hypotetický scenár útoku na dodávateľský reťazec
Aby ste pochopili, prečo je Penetration Testing taký dôležitý, prejdime si realistický scenár.
Nastavenie: Stredne veľká spoločnosť FinTech používa analytický nástroj tretej strany s názvom "MetricFlow" na sledovanie správania používateľov. Aby to fungovalo, pridelili MetricFlow API účet služby v prostredí Google Cloud Platform (GCP) s povoleniami "Editor" (pretože predajca povedal, že je to najjednoduchší spôsob nastavenia).
Útok:
- Narušenie: Vývojár v MetricFlow omylom uloží API kľúč do verejného úložiska GitHub.
- Vstup: Útočník nájde tento kľúč a uvedomí si, že udeľuje prístup k niekoľkým klientskym prostrediam, vrátane našej spoločnosti FinTech.
- Pivot: Útočník použije účet služby MetricFlow na vstup do prostredia GCP. Pretože má účet povolenia "Editor", útočník vidí všetky projekty.
- Payload: Útočník nájde zálohu zákazníckej databázy uloženú v nešifrovanom buckete. Exfiltruje dáta a potom nasadí malý kúsok ransomvéru na zašifrovanie produkčnej databázy.
Ako by Penetration Testing zabránil tomuto: Komplexný Penetration Test by označil tri kritické zlyhania:
- Účet s nadmernými oprávneniami: Tester by si všimol, že účet MetricFlow má prístup "Editor" a označil by ho ako vysoko rizikové zistenie, pričom by odporučil vlastnú rolu iba s potrebnými povoleniami.
- Únik dát: Sken by našiel nešifrovaný záložný bucket a upozornil tím, aby ho zabezpečil.
- Oblasť dopadu: Simulácia by ukázala, že narušenie jediného nástroja tretej strany by mohlo viesť k úplnému prevzatiu cloudu.
V čase, keď skutočný útočník nájde tieto diery, je už príliš neskoro. Penetration Test ich nájde, keď sú to ešte len "zistenia" v správe, a nie "katastrofy" na titulnej strane správ.
Integrácia Penetration Testing do životného cyklu DevOps (DevSecOps)
Ak chcete skutočne chrániť svoj cloudový dodávateľský reťazec, zabezpečenie nemôže byť "posledným krokom" pred vydaním. Musí byť votkané do procesu vývoja. Toto je jadro DevSecOps.
Posun doľava (Shifting Left)
"Posun doľava" znamená presunúť bezpečnostné testovanie skôr v cykle vývoja. Namiesto testovania aplikácie, keď je už v produkcii, ju testujete počas jej vytvárania.
- IDE pluginy: Používajte nástroje, ktoré upozorňujú vývojárov na nezabezpečené knižnice počas písania kódu.
- Pre-commit Hooks: Zabráňte odovzdaniu kódu, ak obsahuje natvrdo zakódované tajné kľúče alebo známe zraniteľnosti.
- CI/CD Integrácia: Zakaždým, keď sa zlúči požiadavka na stiahnutie (pull request), malo by sa spustiť automatizované bezpečnostné skenovanie.
Slučka spätnej väzby
Najdôležitejšou súčasťou tohto procesu je slučka spätnej väzby. Keď Penetration Test identifikuje zraniteľnosť dodávateľského reťazca, informácie by nemali ísť iba do CISO. Mali by ísť priamo k vývojárom.
Keď vývojári presne vidia, ako sa zraniteľnosť využíva – prostredníctvom dôkazu konceptu (PoC) poskytnutého pentesterom – je oveľa pravdepodobnejšie, že uprednostnia opravu. Premení to abstraktnú "požiadavku na zabezpečenie" na konkrétny technický problém, ktorý treba vyriešiť.
Správa ľudského prvku: Dodávateľský reťazec "insiderov"
Často hovoríme o dodávateľoch, ale vaši zamestnanci a dodávatelia sú tiež súčasťou vášho dodávateľského reťazca. Dodávateľ s pretrvávajúcim prístupom do vášho prostredia AWS predstavuje riziko pre dodávateľský reťazec.
Kontroly prístupu dodávateľov
Nenastavujte iba dátum vypršania platnosti účtu dodávateľa a dúfajte v najlepšie. Implementujte prísny proces kontroly. Každých 30 dní by mal manažér potvrdiť, že dodávateľ stále potrebuje konkrétne povolenia, ktoré má.
Školenie pre "ľudský firewall"
Vaši vývojári musia poznať nebezpečenstvá "kopírovania a vkladania" kódu zo Stack Overflow alebo používania neoverených balíkov NPM. Školenie o zvyšovaní povedomia o bezpečnosti by nemalo byť nudné ročné video; mala by to byť praktická diskusia o najnovších útokoch na dodávateľský reťazec a o tom, ako sa im vyhnúť.
FAQ: Časté otázky o cloudovom Penetration Testing dodávateľského reťazca
Otázka: Už máme skener zraniteľností. Prečo potrebujeme Penetration Testing? Odpoveď: Skenery nájdu "známe-známe" – veci s CVE číslom. Pentesteri nájdu "neznáme-neznáme." Skener vám povie, či je váš softvér stará verzia; pentester vám povie, že vaša špecifická kombinácia softvéru a konfigurácie vytvára jedinečné zadné vrátka, ktoré by žiadny skener nikdy nenašiel.
Otázka: Nie je Penetration Testing príliš rušivý pre produkčné prostredie? Odpoveď: Nie, ak sa to robí správne. Profesionálni pentesteri používajú "bezpečné" payloady a starostlivo koordinované plány, aby zabezpečili nulový výpadok. Mnohé organizácie tiež vytvárajú "stagingové" prostredie, ktoré je presným zrkadlom produkčného prostredia pre najagresívnejšie testy.
Otázka: Moji dodávatelia mi nedovolia robiť Penetration Test ich platforiem. Čo mám robiť? Odpoveď: Zvyčajne nemôžete priamo robiť Penetration Test poskytovateľa SaaS tretej strany – to by bolo nezákonné. Avšak, môžete robiť Penetration Test vášho pripojenia k nim. Testujete vaše API integrácie, vaše IAM roly a vaše interné spracovanie ich dát. Zameriavate sa na tú časť reťazca, ktorú skutočne kontrolujete.
Otázka: Ako často by sme mali vykonávať tieto testy? Odpoveď: Závisí to od vašej miery zmien. Ak posielate kód každý deň, ročný test je zbytočný. Odporúčame hybridný prístup: nepretržité automatizované skenovanie a štvrťročné hĺbkové manuálne testy pre kritické systémy.
Otázka: Čo by som mal hľadať u partnera pre Penetration Testing? Odpoveď: Vyhnite sa "cert-mills", ktoré len spustia nástroj a pošlú generickú správu. Hľadajte partnerov, ktorí poskytujú podrobnú metodológiu, jasný proof-of-concept pre každé zistenie a záväzok pomôcť vám pri riešení problémov.
Kontrolný zoznam: Váš audit zabezpečenia cloudového dodávateľského reťazca
Ak chcete začať ešte dnes, použite tento kontrolný zoznam, aby ste zistili, ako na tom ste.
Viditeľnosť a mapovanie
- Máme úplný zoznam všetkých SaaS a API integrácií tretích strán?
- Máme SBOM (Software Bill of Materials) pre naše primárne aplikácie?
- Vieme, ktorí dodávatelia majú administratívny prístup do nášho cloudového prostredia?
Riadenie prístupu
- Odstránili sme roly "Owner" alebo "Admin" z účtov služieb tretích strán?
- Je MFA vynútená pre každého jedného používateľa a dodávateľa s prístupom do cloudu?
- Máme proces na okamžité zrušenie prístupu po skončení zmluvy?
Technické obrany
- Používame nástroj na správu tajných kľúčov (ako HashiCorp Vault alebo AWS Secrets Manager) namiesto env súborov?
- Máme automatizované skenovanie integrované do nášho CI/CD pipeline?
- Sú naše produkčné dáta šifrované v pokoji a pri prenose?
Validácia a testovanie
- Vykonali sme simuláciu "blast radius" pre nášho najkritickejšieho dodávateľa?
- Máme overený proces na riešenie oznámenia o narušení bezpečnosti dodávateľa?
- Sú naše pentestové zistenia sledované v systéme tiketov s pridelenými vlastníkmi a termínmi?
Ďalší krok s Penetrify
Zabezpečenie cloudového dodávateľského reťazca je náročná úloha, pretože nikdy nie je "dokončená." Každý deň sa vydávajú nové knižnice, integrujú sa nové API a objavujú sa nové zraniteľnosti. Pokúšať sa to spravovať pomocou tabuliek a ročných auditov je recept na neúspech.
Presne preto sme vytvorili Penetrify. Veríme, že profesionálne zabezpečenie testovania by nemalo byť luxusom vyhradeným pre top 1 % technologických gigantov. Naša cloudová platforma je navrhnutá tak, aby bol Penetration Testing prístupný, škálovateľný a nepretržitý.
Namiesto tradičného, ťažkopádneho pentestového procesu, Penetrify poskytuje:
- Testovanie na požiadanie: Nemusíte čakať na naplánované okno. Môžete posúdiť svoje bezpečnostné postavenie, ako sa vaše prostredie vyvíja.
- Cloudová architektúra: Nie je potrebné inštalovať komplexný hardvér alebo spravovať vlastnú testovaciu infraštruktúru. Všetko sa rieši v cloude.
- Akčná inteligencia: Nedávame vám len zoznam chýb; poskytujeme vám usmernenie na nápravu, ktoré potrebujete na skutočné vyriešenie problému.
- Škálovateľnosť: Či už máte jedno prostredie alebo sto, Penetrify sa škáluje s vami, čím zabezpečuje, že žiadna časť vášho dodávateľského reťazca nezostane nesledovaná.
Riziko útokov na cloudový dodávateľský reťazec nezmizne. V skutočnosti rastie len preto, že sa viac spoliehame na prepojené služby. Otázka neznie, či bude prepojenie vo vašom reťazci testované – ide o to, či nájdete slabinu skôr, ako to urobí útočník.
Prestaňte hádať a začnite vedieť. Navštívte Penetrify ešte dnes a urobte prvý krok k skutočne odolnej cloudovej infraštruktúre. Váš dodávateľský reťazec je len taký silný, ako váš posledný test. Uistime sa, že je dostatočne silný.