Mistrovské Penetration Testing pro hybridní cloudové architektury

Většina společností dnes není jen „v cloudu“ nebo „on-premise“. Jsou někde uprostřed. Možná jste přesunuli své aplikace pro styk se zákazníky do AWS nebo Azure, ale vaše klíčová finanční data stále sídlí na starším serveru v klimatizované místnosti ve vašem suterénu. Nebo možná používáte hybridní nastavení, abyste vyvážili elasticitu cloudu s přísnou kontrolou soukromé infrastruktury. Je to praktický způsob, jak růst, ale z bezpečnostního hlediska je to noční můra.

Problém je v tom, že „útočná plocha“ v hybridním cloudu je zvláštní. Nebráníte jen perimetr; bráníte most. Útočníky nezajímá, kde vaše data žijí; hledají nejslabší článek v propojení mezi vaším soukromým datovým centrem a vaším veřejným poskytovatelem cloudu. Pokud je vaše cloudová konfigurace benevolentní, útočník může přeskočit z nesprávně nakonfigurovaného S3 bucketu přímo do vaší interní podnikové sítě. Pokud je vaše on-prem VPN zastaralá, stane se z ní vstupní dveře do vašeho cloudového prostředí.

Zvládnutí Penetration Testing pro hybridní cloudové architektury znamená, že musíte přestat přemýšlet v silech. Nemůžete jen spustit skenování vašich cloudových aktiv a poté spustit samostatný audit na vašich lokálních serverech. Musíte testovat tok. Musíte přemýšlet jako útočník, který chce překročit tyto hranice.

V této příručce si rozebereme, jak k tomu přesně přistupovat. Probereme specifické zranitelnosti, které sužují hybridní nastavení, jak vytvořit testovací strategii, která skutečně něco najde, a jak přejít od „kontrol shody“ jednou za rok ke stavu trvalé bezpečnosti.

Proč jsou hybridní cloudové architektury bezpečnostním minovým polem

Když přejdete na čistý cloudový model, spoléháte se na bezpečnostní nástroje poskytovatele. Když zůstanete čistě on-premise, máte vše pod kontrolou. Ale v hybridním modelu máte „sdílenou odpovědnost“, která je často nepochopena.

Nejčastějším problémem je předpoklad, že spojení mezi cloudem a datovým centrem je ze své podstaty bezpečné. Mnoho týmů nastaví Site-to-Site VPN nebo vyhrazenou linku (jako AWS Direct Connect nebo Azure ExpressRoute) a předpokládá, že protože se jedná o „soukromý“ tunel, nemusí se starat o interní segmentaci. To je obrovská chyba. Pokud útočník získá opěrný bod ve webovém serveru založeném na cloudu a tento server má cestu k on-prem databázi přes tunel, útočník je efektivně uvnitř vašeho domu.

Pak je tu krize identity. Správa uživatelů napříč Active Directory on-premise a poskytovatelem identity (IdP) v cloudu často vede k „rozšiřování oprávnění“. Lidé získají přístup k věcem, které nepotřebují, a když opustí společnost, jejich přístup je zrušen na jednom místě, ale přetrvává na jiném.

„Mezera ve viditelnosti“

V tradičním nastavení máte firewall. Vidíte provoz. V hybridním nastavení máte „neviditelný“ provoz. Cloudové nativní služby – jako jsou funkce Lambda nebo spravované Kubernetes clustery – často komunikují způsoby, které tradiční on-prem monitorovací nástroje nevidí. To vytváří slepé místo. Můžete protokolovat každý paket, který zasáhne váš lokální server, ale nemáte tušení, že nepoctivé API volání ve vašem cloudovém prostředí vylévá data z vašeho on-prem SQL serveru.

Složitost jako zranitelnost

Složitost je nepřítelem bezpečnosti. Když máte různé sady pravidel pro vaše cloudové bezpečnostní skupiny a vaše on-prem firewallová pravidla, dochází k chybám. Vývojář může otevřít port pro testování v cloudu a zapomenout jej zavřít, aniž by si uvědomil, že tento port poskytuje přímou cestu k citlivému internímu staršímu systému.

Plánování vaší hybridní Penetration Testing strategie

S hybridním prostředím to nemůžete jen tak „odfláknout“. Pokud začnete spouštět agresivní skenování bez plánu, pravděpodobně shodíte starší server nebo spustíte automatizovaný obranný systém poskytovatele cloudu, což může způsobit označení nebo omezení vašeho účtu.

Skutečná strategie vyžaduje fázový přístup. Nejprve musíte zmapovat architekturu, poté definovat hranice a nakonec provést sérii cílených testů.

Fáze 1: Zjišťování a mapování aktiv

Nemůžete testovat to, o čem nevíte, že existuje. V hybridním prostředí je „stínové IT“ nekontrolovatelné. Někdo mohl spustit testovací prostředí v GCP, které je stále připojeno ke korporátnímu LDAP.

• Cloud Inventory: Použijte nástroje k výpisu každé instance, bucketu a serverless funkce.
• On-Prem Inventory: Auditujte své fyzické servery, VM a síťová zařízení.
• Connection Mapping: Zdokumentujte přesně, jak spolu obě prostředí komunikují. Je to VPN? Vyhrazený okruh? Které porty jsou otevřené? Které rozsahy IP adres jsou důvěryhodné?

Fáze 2: Definování rozsahu

Rozšiřování rozsahu je skutečné nebezpečí v Penetration Testing. Musíte mít jasno v tom, co je „v rozsahu“ a co je „mimo rozsah“.

Máte například povolení testovat základní infrastrukturu poskytovatele cloudu? (Nápověda: Obvykle ne. Testujete svou konfiguraci na jejich infrastruktuře). Máte povolení provádět testy Denial of Service (DoS) na hybridním spojení? Pravděpodobně ne, protože pokud toto spojení vypadne, může se zastavit celá vaše firma.

Fáze 3: Modelování hrozeb

Nespouštějte jen nástroj. Zeptejte se: „Kdo chce moje data a jak by je získal?“

• Scénář A: Útočník kompromituje cloudovou webovou aplikaci a pokusí se laterálně přesunout do on-prem mzdového systému.
• Scénář B: Domácí notebook zaměstnance je infikován, připojí se přes VPN do kanceláře a útočník použije tuto cestu k přístupu ke cloudové správní konzoli.
• Scénář C: Nesprávně nakonfigurovaný cloudový úložný bucket unikne tajný klíč, který útočníkovi umožní vytvářet nové administrativní uživatele v hybridním prostředí.

Testování spojení Cloud-to-Ground

„Most“ se nachází v místě, kde dochází k většině hybridních selhání. Toto je nejkritičtější část vašeho Penetration Testu. Chcete zjistit, zda je oddělení mezi vašimi prostředími skutečná zeď, nebo jen návrh.

Testování VPN a přímých připojení

Pokud používáte Site-to-Site VPN, první otázka zní: je správně šifrovaná? Používáte zastaralé protokoly?

Kromě šifrování se podívejte na směrování. Mnoho organizací umožňuje komunikaci „any-to-any“ přes hybridní spojení. To znamená, že jakýkoli kompromitovaný virtuální počítač v cloudu může pingovat jakýkoli server on-prem. Penetration Tester se pokusí skenovat on-prem síť z kompromitované cloudové instance. Pokud uvidí váš řadič domény nebo váš záložní server, máte problém se segmentací.

Kontrola pravidel firewallu a bezpečnostních skupin

Cloudové bezpečnostní skupiny jsou stavové, ale on-prem firewally často fungují jinak. Tato neshoda vede k „dírám“.

• Permisivní pravidla: Hledejte pravidla 0.0.0.0/0 ve svých cloudových bezpečnostních skupinách. I když je to jen pro jeden port, je to potenciální vstupní bod.
• Přílišná důvěra v hybridní spojení: Zkontrolujte, zda váš on-prem firewall považuje veškerý provoz přicházející z cloudového rozsahu IP adres za „důvěryhodný“. Pokud ano, jakékoli narušení v cloudu je automatické narušení on-prem sítě.

Testování identity bridge

Většina hybridních nastavení používá nějakou formu synchronizace identit (jako Azure AD Connect). To je vysoce hodnotný cíl.

Pokud útočník může kompromitovat účet s nízkými oprávněními v cloudu, může jej použít k eskalaci oprávnění on-prem? To se často děje prostřednictvím útoků „golden ticket“ nebo zneužitím nesprávně nakonfigurovaných vztahů důvěryhodnosti mezi cloudovým tenantem a místní doménou.

Vyzkoušejte toto během testu:

1. Kompromitujte standardní uživatelský účet v cloudu.
2. Zkontrolujte, zda v cloudovém prostředí nejsou uloženy žádné přihlašovací údaje nebo skripty, které by mohly obsahovat hesla servisních účtů on-prem.
3. Pokuste se použít tyto přihlašovací údaje pro přístup k internímu on-prem zdroji prostřednictvím hybridního spojení.

Posouzení cloudové vrstvy: Běžná slabá místa

Zatímco spojení je most, cloud sám o sobě poskytuje vstupní body. Většina „cloudových hacků“ ve skutečnosti nejsou hacky poskytovatele cloudu – jsou to hacky uživatelské konfigurace.

Nesprávně nakonfigurované úložiště (syndrom „děravého bucketu“)

Je to klišé, protože se to děje každý den. S3 buckety nebo Azure Blobs jsou ponechány veřejné.

Penetration Tester použije nástroje k nalezení veřejně přístupných bucketů. Skutečné nebezpečí v hybridním nastavení však spočívá v tom, že tyto buckety obsahují konfigurační soubory, soubory .env nebo SSH klíče, které poskytují přístup k on-prem prostředí. Nalezení souboru „backup_config.json“ ve veřejném bucketu je často „golden ticket“, který útočník potřebuje.

IAM Role Over-Permissioning

Identity and Access Management (IAM) je nový perimetr. Pokud vývojář udělí cloudové instanci AdministratorAccess jen proto, aby „to fungovalo“, vytvořil obrovské riziko.

Pokud útočník získá přístup ke cloudové instanci (prostřednictvím zranitelnosti RCE ve webové aplikaci), první věc, kterou udělá, je kontrola metadatové služby (např. 169.254.169.254). Chce zjistit, jaká role IAM je k této instanci připojena. Pokud má tato role oprávnění k úpravě nastavení sítě nebo přístupu k jiným cloudovým službám, může se útočník pohybovat laterálně prostřednictvím vašeho cloudového prostředí, než se vůbec dotkne vašich on-prem serverů.

Zranitelnosti serverless a kontejnerů

Pokud používáte funkce Lambda nebo Kubernetes (EKS/AKS/GKE), máte nová rizika.

• Container Escapes: Pokud kontejner běží jako root, útočník může „uniknout“ do hostitelského uzlu. Odtud může vidět všechny ostatní kontejnery na tomto uzlu a potenciálně získat přístup k podkladovému API poskytovatele cloudu.
• Function Injection: Serverless funkce často přijímají vstup z webových požadavků. Pokud tento vstup není sanitizován, můžete mít command injection, která útočníkovi umožní spouštět kód v cloudovém prostředí a potenciálně krást tajné klíče z proměnných prostředí.

Posouzení on-prem vrstvy: Riziko starších systémů

Obvykle je on-prem strana hybridního cloudu místem, kde žijí „staré věci“. Starší systémy jsou zřídka aktualizovány, protože „pokud to není rozbité, neopravuj to“. Ale v hybridním světě „nerozbité“ neznamená „zabezpečené“.

Selhání správy záplat

Vaše cloudové instance mohou být aktualizovány automaticky prostřednictvím CI/CD pipeline, ale váš místní souborový server pravděpodobně běží na Windows Server 2012.

Penetration Tester bude hledat neopravené zranitelnosti (jako EternalBlue nebo PrintNightmare) na vašich místních serverech. Jakmile získají opěrný bod na jednom místním serveru, mohou jej použít jako otočný bod pro útok na cloudovou správní konzoli, pokud má místní server uložené přihlašovací údaje nebo tokeny relace.

Nebezpečí plochých sítí

Mnoho on-prem sítí je „plochých“, což znamená, že jakmile jste uvnitř, můžete vidět všechno. V hybridním nastavení je to smrtelné. Pokud hybridní most přistane v ploché on-prem síti, „blast radius“ kompromisu cloudu se rozšíří na každé zařízení ve vaší kanceláři.

Řešení: Implementujte mikrosegmentaci. Hybridní spojení by mělo přistát v „DMZ“ nebo ve specifickém tranzitním VPC/VNet. Odtud by měl být provoz přísně filtrován. Mělo by být povoleno pouze těm specifickým cloudovým aplikacím, které potřebují komunikovat se specifickou on-prem databází.

Nezabezpečená rozhraní pro správu

On-prem je běžné najít staré konzole pro správu (IPMI, iDRAC, vSphere), které jsou přístupné prostřednictvím sítě. Pokud jsou tyto konzole vystaveny hybridnímu spojení, útočník z cloudu může potenciálně restartovat vaše fyzické servery nebo přeinstalovat operační systém.

Podrobný návod: Scénář laterálního pohybu

Pro pochopení, jak to všechno funguje, si projdeme hypotetický scénář útoku. Přesně takto vypadá profesionální Penetration Test při testování hybridní architektury.

Nastavení: Společnost má cloud-nativní frontend (AWS) a on-prem backend (soukromé datové centrum). Jsou propojeny pomocí Site-to-Site VPN.

Krok 1: Počáteční průnik Útočník najde zastaralou verzi CMS na webové stránce. Použije známý exploit k získání shellu s nízkými oprávněními na webovém serveru.

Krok 2: Cloudová průzkumná činnost Útočník se dotazuje na AWS Metadata Service. Zjistí, že instance má IAM roli s názvem App-Server-Role. Kontrolou oprávnění zjistí, že tato role má oprávnění ke čtení z S3 bucketu s názvem company-configs.

Krok 3: Exfiltrace tajných informací Útočník stáhne obsah bucketu a najde soubor s názvem db_connect.txt. Tento soubor obsahuje IP adresu on-prem SQL serveru a heslo servisního účtu.

Krok 4: Překročení mostu Útočník se pokusí připojit k on-prem IP adrese. Protože VPN umožňuje veškerý provoz z AWS VPC do on-prem podsítě, připojení je úspěšné.

Krok 5: On-Prem eskalace Útočník použije servisní účet k přihlášení k SQL serveru. Zjistí, že SQL server běží jako Local Administrator. Pomocí exploitu pro eskalaci oprávnění (jako je známá zranitelnost jádra) získá plný přístup SYSTEM k on-prem serveru.

Krok 6: Úplné kompromitování domény Nyní uvnitř on-prem sítě útočník použije mimikatz k výpisu paměti a nalezení přihlašovacích údajů Domain Administratora, který se k tomuto serveru přihlásil před týdnem. Útočník nyní vlastní celou firemní identifikační doménu.

Ponaučení: K "hacku" nedošlo kvůli jednomu velkému selhání. Došlo k němu kvůli řetězci malých selhání: neopravený CMS $\rightarrow$ nadměrně privilegovaná IAM role $\rightarrow$ tajné informace v S3 bucketu $\rightarrow$ nedostatečná segmentace sítě na VPN.

Jak automatizovat a škálovat hybridní testování

Provádět manuální Penetration Test jednou ročně je jako chodit na fyzickou prohlídku jednou ročně a předpokládat, že jste zdraví každý den mezi tím. V hybridním cloudu se věci mění každou hodinu. Někdo přidá pravidlo do bezpečnostní skupiny; někdo spustí nový virtuální stroj; někdo aktualizuje část kódu.

Potřebujete způsob, jak tento proces učinit kontinuálním.

Kontinuální skenování zranitelností

Nemůžete jen skenovat své IP adresy. Potřebujete skener, který "rozumí aktivům". To znamená nástroj, který ví, kdy je ve vašem cloudu vytvořena nová instance, a automaticky ji přidá do seznamu skenování. Měl by být také schopen dosáhnout přes hybridní spojení a zkontrolovat stav vašich on-prem aktiv.

Role Breach and Attack Simulation (BAS)

Nástroje BAS vám umožňují spouštět "playbooky" útoků. Můžete simulovat scénář útoku "Cloud-to-Ground" popsaný výše každý týden. Pokud změna konfigurace náhle otevře díru ve vašem firewallu, nástroj BAS ji zachytí při příštím spuštění, místo aby čekal, až ji lidský tester najde o šest měsíců později.

Integrace s vaším workflow

Největší problém s bezpečnostními testy je "PDF Report." Stostránkové PDF se zranitelnostmi je místo, kde bezpečnost umírá.

Potřebujete, aby se výsledky testování dostávaly přímo do vašeho systému pro správu úkolů (Jira, ServiceNow atd.). Pokud je v hybridním spojení nalezena zranitelnost s vysokou závažností, měla by automaticky spustit ticket pro síťový tým.

Využití Penetrify pro hybridní zabezpečení

Zde se platforma jako Penetrify stává zásadní změnou. Pokusit se spravovat to všechno ručně – skenování, manuální testování, mapování a nápravu – je práce na plný úvazek pro velký tým.

Penetrify poskytuje cloud-nativní architekturu, která řeší infrastrukturní bolesti hlavy. Místo abyste si museli nastavovat vlastní "attack boxes" on-prem a v cloudu, Penetrify vám umožňuje nasazovat bezpečnostní hodnocení na vyžádání. Překlenuje mezeru tím, že poskytuje jak automatizované skenování, tak manuální odbornost, což znamená, že získáte rychlost nástroje s kritickým myšlením člověka. Ať už jste společnost střední velikosti, která se snaží škálovat své zabezpečení bez najímání pěti nových inženýrů, nebo podnik spravující složitý hybridní web, Penetrify vám pomůže identifikovat tyto "bridge" zranitelnosti dříve, než to udělá skutečný útočník.

Běžné chyby v hybridním Penetration Testing

Viděl jsem mnoho týmů, které "dělají" Penetration Testing, ale dělají to způsobem, který poskytuje falešný pocit bezpečí. Zde jsou nejčastější pasti:

1. Testování v "čistém" prostředí

Některé společnosti vytvářejí "staging" prostředí, které vypadá jako jejich hybridní nastavení, ale je "čistší" než produkční. To je zbytečné. Produkce je místo, kde je "nepořádek". Produkce je místo, kde žijí stará legacy pravidla. Pokud netestujete skutečné prostředí, kde data sedí, nenacházíte skutečná rizika.

2. Ignorování cesty "Ground-to-Cloud"

Všichni se obávají, že cloud bude vstupním bodem. Ale co opačná cesta? Útočník se dostane do lokální pracovní stanice prostřednictvím phishingu a poté použije hybridní spojení pro přístup ke cloudové správní konzoli. Pokud je vaše cloudová správní konzole přístupná z interní firemní sítě bez Multi-Factor Authentication (MFA), jste dokořán otevření.

3. Spoléhání se pouze na automatizované nástroje

Automatizované skenery jsou skvělé pro nalezení chybějících záplat, ale jsou hrozné pro nalezení logických chyb. Skener vám neřekne: "Hej, tato IAM role je pro tuto konkrétní aplikaci příliš silná." Jen vám řekne, že server je opravený. Potřebujete manuální průzkum k nalezení cest laterálního pohybu.

4. Přeskočení kroku "Remediation Verify"

Běžný vzor:

1. Test najde zranitelnost.
2. Vývojový tým říká: "Opraveno!"
3. Bezpečnostní tým to označí jako "Uzavřeno."

Nikdy to nedělejte. Vždy proveďte opakovaný test. Často "oprava" pouze přesune zranitelnost někam jinam, nebo ve skutečnosti nevyřeší hlavní příčinu.

Kontrolní seznam zabezpečení hybridního cloudu

Pokud se připravujete na Penetration Test nebo provádíte vlastní audit, použijte tento kontrolní seznam, abyste se ujistili, že jste pokryli všechny základy.

Síť a konektivita

• Auditujte všechny konfigurace Site-to-Site VPN a Direct Connect.
• Ověřte, že hybridní spojení ústí do omezené podsítě (nikoli do hlavního on-prem prostředí).
• Zkontrolujte přítomnost 0.0.0.0/0 nebo příliš širokých bloků CIDR v cloudových bezpečnostních skupinách.
• Potvrďte, že on-prem firewally filtrují provoz přicházející z cloudu.
• Zmapujte všechny porty a protokoly povolené přes hybridní most.

Identita a přístup

• Zkontrolujte role IAM z hlediska "Principu nejmenšího privilegia."
• Auditujte synchronizaci identit (např. AD Connect) z hlediska cest eskalace oprávnění.
• Zajistěte, aby bylo MFA vyžadováno pro veškerý přístup ke cloudové správní konzoli, a to i z interní sítě.
• Zkontrolujte přítomnost napevno zakódovaných přihlašovacích údajů/tajných klíčů v cloudovém úložišti nebo proměnných prostředí.
• Ověřte, že "osiřelé" účty (bývalí zaměstnanci) jsou odstraněny z cloudových i on-prem systémů.

Infrastruktura a aplikace

• Naskenujte všechny veřejně přístupné cloudové úložné prostory z hlediska otevřených oprávnění.
• Auditujte on-prem starší servery z hlediska kritických neopravených zranitelností.
• Otestujte izolaci kontejnerů, abyste zajistili, že kompromitovaný pod nebude mít přístup k hostitelskému uzlu.
• Ověřte, že serverless funkce mají omezený přístup k interním zdrojům.
• Zajistěte, aby centralizované protokolování zaznamenávalo provoz v cloudu i on-prem.

Srovnání: Tradiční Pentesting vs. Hybrid Cloud Pentesting

Funkce	Tradiční Pentesting	Hybrid Cloud Pentesting
Perimetr	Jasně definovaný (Firewall)	Fluidní (IAM, API, VPN, VPC)
Zaměření	Externí $\rightarrow$ Interní	Cloud $\leftrightarrow$ On-Prem $\leftrightarrow$ Cloud
Nástroje	Síťové skenery, Metasploit	Cloud-native nástroje, auditoři IAM, BAS
Rychlost	Periodická (Roční/Čtvrtletní)	Kontinuální/Na vyžádání
Riziková oblast	Softwarové chyby, Otevřené porty	Nesprávné konfigurace, Vztahy důvěry
Odpovědnost	Zcela interní	Sdílená (Vy + Poskytovatel cloudu)

FAQ: Zvládnutí zabezpečení hybridního cloudu

Otázka: Musím informovat svého poskytovatele cloudu před provedením Penetration Testu? Odpověď: V minulosti jste museli žádat o povolení téměř ke všemu. V současné době mají AWS, Azure a GCP seznamy "Povolených služeb". Pro většinu standardních testů (skenování vlastních instancí, útok na vlastní aplikace) je nemusíte informovat. Pokud však děláte něco agresivního, jako je DDoS test nebo testování základní struktury, musíte si absolutně ověřit zásady poskytovatele, abyste se vyhnuli pozastavení účtu.

Otázka: Co je nebezpečnější: cloudová strana nebo on-prem strana? Odpověď: Žádná z nich není ze své podstaty "více" nebezpečná; mají jen různé režimy selhání. Cloudová strana selhává kvůli nesprávné konfiguraci (např. otevřený S3 bucket). On-prem strana selhává kvůli zanedbání (např. neopravený server z roku 2016). Skutečné nebezpečí spočívá v interakci mezi nimi.

Otázka: Jak často bych měl testovat svou hybridní architekturu? Odpověď: Pokud jste regulované odvětví (HIPAA, PCI DSS, SOC 2), pravděpodobně máte požadavek na roční nebo pololetní testy. Ale upřímně? Měli byste provádět automatizované skenování týdně a hloubkové manuální Penetration Testing pokaždé, když provedete významnou změnu ve své architektuře (např. změna poskytovatele VPN nebo migrace nové základní aplikace do cloudu).

Otázka: Mohu používat open-source nástroje pro hybridní testování? Odpověď: Ano, nástroje jako Nmap, Burp Suite a Metasploit jsou stále zásadní. Pro cloudovou stranu jsou nástroje jako Prowler nebo Scout Suite skvělé pro auditování konfigurací. Problémem však nejsou nástroje – je to korelace dat. Proto je platforma jako Penetrify užitečná; organizuje zjištění do uceleného obrazu vašeho skutečného rizika.

Otázka: Co je nejdůležitější věc, kterou mohu udělat pro zabezpečení svého hybridního spojení? Odpověď: Přestaňte důvěřovat "soukromé" povaze spojení. Chovejte se ke spojení mezi vaším cloudem a vaším datovým centrem, jako by to byl veřejný internet. Vyžadujte ověření při každém kroku, šifrujte vše a používejte přístup "Zero Trust". Pokud cloudová aplikace potřebuje komunikovat s on-prem databází, měla by to být jediná věc, které je to povoleno, na jednom konkrétním portu a pouze poté, co se ověřila.

Realizovatelné další kroky

Pokud se cítíte zahlceni složitostí vašeho hybridního nastavení, nesnažte se opravit vše najednou. Začněte těmito třemi kroky:

1. Zmapujte most: Věnujte jedno odpoledne zdokumentování všech způsobů, jakým vaše cloudové prostředí komunikuje s vaším on-prem prostředím. Pokud najdete spojení, které nepoznáváte, okamžitě ho vypněte nebo prošetřete.
2. Zpřísněte IAM: Projděte si své nejpoužívanější cloudové role. Pokud má role AdministratorAccess nebo FullS3Access, ale potřebuje pouze číst jeden konkrétní bucket, změňte to. Toto je nejrychlejší způsob, jak snížit váš poloměr výbuchu.
3. Spusťte cílený test: Nečekejte na svůj roční audit. Vyberte si jedno cenné aktivum on-prem a zkuste zjistit, zda se k němu můžete dostat z cloudové instance s nízkými oprávněními. Pokud ano, právě jste našli svou první hlavní prioritu pro nápravu.

Zabezpečení není cíl; je to proces neustálého zdokonalování. Čím více testujete, tím více si uvědomíte, že "zdi", o kterých jste si mysleli, že je máte, jsou často jen závěsy. Přijetím strategie Penetration Testing s ohledem na hybridní prostředí se posunete od hádání, že jste v bezpečí, k vědění, kde přesně máte mezery.

Pokud chcete přestat hádat a začít ověřovat své zabezpečení, Penetrify vám může pomoci automatizovat nudné části tohoto procesu a zároveň vám poskytne odborné poznatky potřebné k zabezpečení vaší hybridní architektury. Navštivte penetrify.cloud a zjistěte, jak můžete začít identifikovat a opravovat zranitelnosti dříve, než se stanou titulky.