Napadený server je jen zřídka koncem útoku. Pokud může tento server komunikovat se všemi ostatními zařízeními v síti, může jej útočník využít jako výchozí bod ke krádeži přihlašovacích údajů, nasazení ransomwaru, změně aplikací nebo napadení zálohovacích systémů. Segmentace sítě zmenšuje rozsah dopadu tím, že řídí, které systémy spolu mohou komunikovat a z jakého důvodu.
Segmentace není jeden produkt ani jedno nastavení. Jde o disciplínu návrhu, která kombinuje VLAN, podsítě, bezpečnostní zóny, směrování, pravidla firewallu, řízení identity a monitorování. Cíl je jednoduchý: webový server by neměl být schopen zahajovat libovolná spojení s notebooky zaměstnanců, databáze by neměla být dostupná z veřejného internetu a produkční server by neměl automaticky získat administrátorský přístup k zálohovací infrastruktuře.
Pro agentury a malé firmy nemusí být rozumný návrh složitý. Musí však odpovídat tomu, jak systémy skutečně fungují, všude, kde je to praktické, používat přístup s výchozím zákazem a být pravidelně testován. Segmentace by měla doplňovat izolovanou a obnovitelnou strategii zálohování. Nemůže zaručit, že útok bude zcela omezen, ani obnovit data, která útočník zašifroval nebo smazal.
Před čím segmentace sítě chrání
Segmentace sítě rozděluje infrastrukturu do samostatných oblastí a vytváří mezi nimi řízené hranice. Ty mohou být implementovány pomocí fyzických sítí, VLAN, směrovaných podsítí, virtuálních firewallů, firewallů na hostitelích nebo kombinací těchto opatření.
Hlavním bezpečnostním přínosem je omezení laterálního pohybu. Laterální pohyb je proces, při kterém se útočník přesouvá z původně napadeného systému na další systémy uvnitř prostředí. Veřejně dostupný webový server může být napaden prostřednictvím neaktualizovaného frameworku. Útočník následně hledá přihlašovací údaje k databázím, rozhraní pro správu, sdílené složky, doménové služby, hypervizory a zálohovací konzole. Každá dostupná služba představuje další příležitost.
Plochá síť tento proces usnadňuje. V plochém návrhu mohou servery, pracovní stanice, tiskárny, hypervizory a nástroje pro správu používat jeden rozsáhlý rozsah IP adres. Dostupnost v síti se často považuje za oprávnění. Jakmile je útočník uvnitř, může prohledávat prostředí, připojovat se ke službám, které nikdy neměly být veřejně dostupné, a využívat slabá interní opatření.
Segmentace tento výchozí předpoklad mění. Systémy jsou podle své role a míry vystavení umístěny do zón a provoz mezi zónami je explicitně řízen. Napadený webový server může být stále nebezpečný, měl by však mít pouze spojení potřebná k poskytování aplikace. Neměl by být schopen prohledávat síť správy ani se připojovat ke každému serveru přes vzdálenou plochu a SSH.
Týmy, které hledají informace o segmentaci sítě a zabezpečení serverů proti laterálnímu pohybu, najdou mnoho možných architektur. Důležité není slepě kopírovat nějaký diagram. Návrh musí vycházet ze skutečných závislostí aplikací, administrativních postupů a požadavků na obnovu.
VLAN, podsítě a bezpečnostní zóny spolu souvisejí, ale liší se
VLAN zajišťují logické oddělení
Virtuální LAN neboli VLAN odděluje zařízení na 2. vrstvě, i když používají stejné fyzické přepínače. Firma může například umístit kancelářské pracovní stanice do jedné VLAN, produkční servery do jiné a rozhraní pro správu do třetí. VLAN zmenšují rozsah broadcastu a vytvářejí jasná místa, v nichž musí být provoz směrován.
Samotné VLAN nejsou bezpečnostní hranicí. Pokud směrovač, přepínač 3. vrstvy nebo firewall povoluje mezi VLAN veškerý provoz, je oddělení převážně administrativní. Bezpečnostní hodnota vzniká kontrolou a kontrolou provozu při překračování této hranice.
Podsítě definují směrované sítě
Každá VLAN má obvykle vlastní IP podsíť. Podsíť serverů může používat jeden rozsah privátních adres, zatímco podsíť správy jiný. Podsítě usnadňují pochopení tras a pravidel firewallu, ale oddělené rozsahy IP automaticky nebrání komunikaci. O tom, co je povoleno, stále rozhoduje směrování a seznamy řízení přístupu.
Bezpečnostní zóny popisují důvěru a vystavení
Bezpečnostní zóna je koncept založený na pravidlech. Sdružuje systémy s podobnou mírou vystavení nebo podobným bezpečnostním účelem. Typické malé prostředí může zahrnovat:
- Internetová nebo okrajová zóna: firewally, reverzní proxy, nástroje pro vyvažování zátěže a další systémy přímo vystavené externím sítím.
- Webová zóna: veřejně dostupné webové servery, které přijímají požadavky z internetu nebo od okrajové proxy.
- Aplikační zóna: aplikační služby, které by měly přijímat požadavky pouze od schválených webových nebo integračních systémů.
- Databázová zóna: databázové servery, které by měly být dostupné pouze konkrétním aplikačním službám a schváleným administrativním cestám.
- Zóna správy: přístupové servery, monitorovací konzole, konfigurační systémy, správa hypervizorů a další administrativní rozhraní.
- Zálohovací zóna: zálohovací agenti, úložiště, systémy správy a infrastruktura pro obnovu oddělená od produkčních úloh.
- Uživatelská zóna: zařízení zaměstnanců, tiskárny a další kancelářská technika, která obvykle vyžaduje jiná pravidla přístupu než servery.
Tyto zóny mohou být fyzické, virtuální nebo hostované poskytovatelem. Podstatné je, aby provoz mezi nimi procházel bodem vynucujícím pravidla a aby byl dostatečně zaznamenáván pro vyšetření neočekávaného chování.
Navrhujte podle požadavků na komunikaci
Nejlepším výchozím bodem není seznam čísel VLAN. Je jím inventář služeb a jejich komunikačních požadavků. U každého serveru zaznamenejte, co poskytuje, kdo jej používá, které porty jsou potřebné, zda je komunikace zahajována jedním směrem nebo obousměrně a co se stane, když závislá služba nebude dostupná.
Ptejte se například:
- Potřebuje webová vrstva přístup k aplikační vrstvě, nebo tuto funkci může zajišťovat interní reverzní proxy?
- Potřebuje aplikační server přímý přístup k databázi a na kterém databázovém portu?
- Které systémy potřebují DNS, synchronizaci času, služby identity nebo certifikační služby?
- Dotazuje se monitorovací systém serverů, nebo agenti odesílají data do monitorovacího kolektoru?
- Kteří administrátoři potřebují přístup přes SSH, vzdálenou plochu, konzoli nebo hypervizor?
- Potřebuje server vůbec odchozí přístup k internetu, a pokud ano, ke kterým cílům?
- Která zálohovací spojení zahajuje produkční server, zálohovací server nebo oba?
Odpovědi zdokumentujte v komunikační matici. Jednoduchá matice může uvádět zdrojovou zónu, cílovou zónu, protokol, port, účel, směr, vlastníka a datum kontroly. Předejdete tak časté chybě: povolení celé podsítě jen proto, že jedna aplikace potřebuje jedno spojení.
Závislosti aplikací ověřujte, nepředpokládejte je. Dokumentace dodavatele může uvádět, že služba používá jeden port, zatímco skutečné nasazení závisí také na DNS, poskytovateli identity, licenční službě, SMTP relayi nebo cloudovém API. Začněte obezřetnými pravidly, sledujte legitimní provoz a přidávejte úzce definovaná pravidla s odpovědným vlastníkem.
Praktický vícevrstvý návrh pro agentury a malé firmy
Malá agentura může hostovat weby klientů, interní aplikace, databáze a nástroje pro správu na omezeném počtu fyzických nebo virtuálních serverů. Nemusí mít vlastní tým síťové bezpečnosti. Užitečný návrh přesto může oddělit hlavní rizika, aniž by vytvořil neudržovatelný labyrint.
Webová vrstva
Webová vrstva obsahuje systémy zpracovávající nedůvěryhodné požadavky. Tyto servery by měly být považovány za rizikovější, protože vystavují služby internetu. Povolte příchozí provoz pouze pro potřebné webové protokoly, obvykle prostřednictvím firewallu, reverzní proxy nebo vrstvy pro vyvažování zátěže. Administrativní přístup by měl přicházet cestou správy, nikoli z veřejného rozhraní.
Webový server obvykle potřebuje zahajovat spojení s aplikační vrstvou, získávat schválené aktualizace nebo kontaktovat vybrané externí služby. Neměl by mít neomezený přístup k databázové síti, interním sdíleným složkám, zařízením zaměstnanců ani rozhraním hypervizorů. Pokud server poskytuje pouze statický obsah, mohou být povolené cíle ještě omezenější.
Aplikační vrstva
Aplikační vrstva provozuje obchodní logiku, API, úlohy na pozadí a integrační služby. Měla by přijímat provoz pouze od definovaných webových serverů, důvěryhodných integrací nebo v případě potřeby od interních uživatelů. Odchozí přístup by měl být omezen na databáze, fronty, služby identity a externí API, které aplikace skutečně používá.
Nepředpokládejte, že umístění aplikačních a databázových serverů do samostatných VLAN stačí. Firewall by měl povolit pouze databázový protokol a port potřebný aplikací, a to z konkrétních adres aplikace. Administrativní přístup k databázi by měl využívat samostatnou trasu správy a silnější ověřování.
Databázová vrstva
Databáze obsahují koncentrovanou hodnotu a měly by mít co nejužší praktické síťové vystavení. Neměly by přijímat spojení z internetu ani z běžných uživatelských sítí. V mnoha prostředích by se k databázové službě měla moci připojit pouze malá skupina aplikačních serverů.
Databázové servery mohou potřebovat DNS, synchronizaci času, monitorování a připojení k zálohám. Tyto požadavky řešte samostatnými pravidly, nikoli širokým pravidlem povolení. Pokud databázový engine podporuje šifrování přenosu a silné ověřování, používejte tyto kontroly jako další vrstvu. Segmentace sítě omezuje dostupnost; sama o sobě z povoleného spojení nedělá důvěryhodné spojení.
Vrstva monitorování a protokolování
Monitorovací systémy potřebují přehled, ale přehled neznamená neomezený přístup. Pokud agenti monitorování odesílají data do kolektoru, povolte odchozí spojení agentů k tomuto kolektoru. Pokud kolektor systémy dotazuje, povolte z monitorovací podsítě pouze potřebné protokoly dotazování.
Protokoly by měly být odesílány na místo, které útočník po napadení produkčního serveru nemůže snadno změnit. Omezte, kdo může monitorovací platformu spravovat, chraňte její přihlašovací údaje odděleně a upozorňujte na změny pravidel firewallu, privilegovaných účtů a konfigurace záloh. Monitorování by mělo pomáhat odhalit útoky i selhání segmentace.
Vrstva správy
Vrstva správy patří k nejcitlivějším oblastem prostředí. Může obsahovat přístupové servery, nástroje vzdálené správy, konzole hypervizorů, správu konfigurace, adresářové služby, správu síťových zařízení a bezpečnostní platformy.
Rozhraní pro správu by neměla být přímo vystavena internetu. Administrátoři by se měli připojovat prostřednictvím řízené služby vzdáleného přístupu a podle potřeby přes zabezpečený přístupový server. Ten by měl mít omezenou množinu povolených cílů a neměl by být používán k běžnému procházení webu nebo práci s e-mailem.
Používejte pravidla firewallu s výchozím zákazem
Výchozí zákaz znamená, že provoz je blokován, pokud jej nepovolí konkrétní pravidlo. Je to bezpečnější než povolit široký interní přístup a později se pokoušet odstraňovat nebezpečné výjimky. Zároveň zviditelňuje zamýšlenou architekturu v sadě pravidel.
Užitečné pravidlo firewallu by mělo odpovídat na pět otázek:
- Které zdrojové adresy, identity nebo zóna jsou zapojeny?
- Který cílový systém nebo služba je potřebná?
- Který protokol a port jsou povoleny?
- Je spojení příchozí, odchozí nebo obousměrné?
- Kdo je vlastníkem pravidla, proč existuje a kdy má být zkontrolováno?
Dávejte přednost konkrétním adresám serverů nebo úzce vymezeným skupinám adres před celými podsítěmi. Používejte pojmenované objekty služeb místo širokých rozsahů portů. Vyhýbejte se pravidlům typu „libovolný zdroj na libovolný cíl“, pokud k tomu neexistuje jasně zdokumentovaný a dočasný důvod s datem ukončení.
Na pořadí pravidel záleží. Široké pravidlo povolení umístěné před omezujícím pravidlem může záměrný návrh tiše zmařit. Tam, kde to zlepší přehled, používejte explicitní pravidla zákazu a zamítnutý provoz zaznamenávejte selektivně. Zaznamenávání každého paketu může malý tým zahltit, opakované pokusy o přístup mezi citlivými zónami však mohou odhalit skenování, malware nebo nefunkční závislost aplikace.
Pravidla firewallu spravujte jako infrastrukturu, nikoli neformálními úpravami pod tlakem. Veďte záznamy změn, u citlivých zásad používejte kontrolu druhou osobou a po dokončení práce dočasný přístup odstraňte. Pokud to platforma podporuje, propojte změny pravidel se správou konfigurace a uchovávejte předchozí verze pro případ návratu zpět.
Kontrolujte provoz mezi interními systémy, nejen internetový provoz
Provoz sever–jih proudí mezi interním prostředím a internetem. Provoz východ–západ proudí mezi interními systémy. Tradiční obvodová bezpečnost se často soustředí na provoz sever–jih a předpokládá, že interní síť je důvěryhodná. Tento předpoklad selže, když útočník napadne server, ukradne přihlašovací údaje správce nebo připojí infikované zařízení do kancelářské sítě.
Kontroly provozu východ–západ by měly pokrývat provoz mezi:
- webovými a aplikačními servery,
- aplikačními servery a databázemi,
- produkčními servery a rozhraními pro správu,
- servery a uživatelskými pracovními stanicemi,
- virtuálními počítači na stejném hostiteli nebo v clusteru,
- produkčními systémy a zálohovacími úložišti,
- monitorovacími kolektory a monitorovanými zařízeními.
Další vrstvu představují firewally na hostitelích. Jsou obzvlášť užitečné, když úlohy sdílejí virtuální přepínač nebo když provoz neprochází centrálním fyzickým firewallem. Firewall hostitele může omezit lokální služby a blokovat spojení, která by nikdy neměla být nutná, i když je síťová politika omylem příliš široká.
Mikrosegmentace může tento přístup dále rozšířit uplatněním pravidel na jednotlivé úlohy nebo identity, nikoli pouze na VLAN. Malé organizace nepotřebují vždy specializovanou platformu pro mikrosegmentaci. Pečlivě spravované firewally hostitelů, bezpečnostní skupiny, identity služeb a lokální zásady mohou poskytnout významné oddělení, pokud jsou zdokumentované a udržované.
Oddělte správu od produkčního provozu
Administrativní přístup si zaslouží vlastní cestu, protože přihlašovací údaje správce mohou odemknout mnoho systémů najednou. Kombinace uživatelského, aplikačního a správního provozu v jedné síti ztěžuje rozlišení legitimní správy od činnosti útočníka.
Bezpečnější model spočívá v tom, že se administrátoři připojí k bráně vzdáleného přístupu nebo VPN, ověří se pomocí individuálních účtů a pokud možno použijí vícefaktorové ověřování. Odtud se dostanou k zabezpečenému přístupovému serveru nebo do zóny správy. Přístupový server se následně připojuje ke schváleným rozhraním serverů. Přímému přístupu z nespravovaného notebooku ke všem serverům je třeba se vyhnout.
Administrativní kontroly by měly zahrnovat:
- samostatné pojmenované účty správců namísto sdílených privilegovaných údajů,
- vícefaktorové ověřování pro vzdálený přístup a privilegované systémy,
- oprávnění s nejnižšími potřebnými právy podle pracovní role,
- časově omezený nebo just-in-time přístup pro citlivé úkoly, pokud je podporován,
- omezení zdrojových sítí, které mohou přistupovat k SSH, vzdálené ploše a administračním API,
- centrální protokolování ověřování a privilegované činnosti,
- bezpečné ukládání a pravidelnou změnu přihlašovacích údajů služeb.
Nezapomínejte na mimopásmovou správu. Správa hypervizorů, řadiče vzdálených konzolí, úložné systémy a síťová zařízení by měly být v zóně správy, nikoli ve stejném segmentu jako běžné úlohy. Pokud je produkční server napaden, útočník by neměl automaticky získat cestu k platformě, která řídí všechny virtuální počítače.
Udržujte zálohovací síť nezávislou
Zálohy jsou často cílem útoku poté, co útočník pronikne do produkce. Pokud zálohovací konzole, úložiště a produkční servery sdílejí stejné přihlašovací údaje a neomezený síťový přístup, ransomware může před zašifrováním živých systémů smazat body obnovy.
Všude, kde to architektura umožňuje, oddělte zálohovací provoz a správu od běžného produkčního provozu. Zálohovací síť může zahrnovat vyhrazené VLAN, pravidla firewallu, omezené trasy, samostatné účty služeb a přístup k úložišti, který není dostupný z uživatelských ani webových zón.
Segmentace musí odpovědět na dvě různé otázky. Za prvé: může zálohovací systém shromáždit nebo přijmout data, která potřebuje? Za druhé: může napadený produkční server uložené body obnovy měnit, mazat nebo spravovat? První spojení může být nezbytné; druhé musí být přísně omezeno.
Síťová opatření jsou jen jednou částí odolnosti záloh. Zálohy by měly být zašifrovány před opuštěním prostředí kontrolovaného zákazníkem, přičemž šifrovací klíč by měl držet zákazník, nikoli poskytovatel záloh. Měly by být uloženy mimo produkci a chráněny před smazáním nebo změnou po celou dobu retenční lhůty.
Pokud napadený server dosáhne na produkční systémy a pokusí se zničit možnosti obnovy, poskytuje izolovaná, šifrovaná a neměnná služba, jako je off-site zálohování Safenix pro firemní servery, další hranici obnovy. Safenix chrání servery kontrolované zákazníkem; nejde o zálohovací plán pro weby provozované na sdíleném hostingu.
VPS a hostovanou webovou infrastrukturu zvažujte pečlivě
Segmentace je složitější, když infrastrukturu hostuje poskytovatel, protože zákazník nemusí mít kontrolu nad fyzickými přepínači ani nad sítí poskytovatele. Návrh by měl rozlišovat mezi opatřeními, která může zákazník nastavit uvnitř VPS nebo cloudového prostředí, a opatřeními, která musí poskytovat hostingová platforma.
Na úrovni zákazníka používejte samostatné virtuální sítě, bezpečnostní skupiny, firewally hostitelů a podle dostupnosti také privátní rozhraní. Veřejná rozhraní omezte pouze na potřebné služby. Databáze a koncové body správy umístěte do privátních sítí a nevystavujte je veřejnými IP adresami jen kvůli pohodlí.
Zeptejte se poskytovatele, jak funguje izolace sítě, zda je privátní provoz filtrován, jak se uplatňují pravidla firewallu a zda je přístup pro správu oddělen od zákaznických úloh. Prověřte také, jak poskytovatel zpracovává snapshoty, obrazy a zálohy. Snapshot dostupný přes stejnou napadenou řídicí rovinu nemusí být nezávislou kopií pro obnovu.
Pro organizace používající VPS a hostovanou webovou infrastrukturu s oddělenými bezpečnostními zónami platí stejné praktické otázky jako v serverovně: který systém může zahájit spojení, která služba je vystavena, kdo ji může spravovat a jak by byl přístup během incidentu odvolán? Hostované umístění neodstraňuje potřebu segmentace. Mění pouze to, která opatření jsou dostupná a kdo je provozuje.
U sdíleného hostingu je třeba zvlášť pečlivě popsat odpovědnosti. Zákazník může být schopen konfigurovat nastavení aplikace nebo firewall na úrovni účtu, to však neznamená, že má kontrolu nad serverovou sítí poskytovatele nebo nad okolními účty. Safenix chrání firemní servery kontrolované zákazníkem a neměl by být prezentován jako zálohovací služba pro web na sdíleném hostingu.
Časté chyby při segmentaci
Vytvoření VLAN bez vynucování pravidel
Samostatné VLAN s neomezeným směrováním mezi VLAN vytvářejí dojem segmentace bez zamýšlené ochrany. Prověřte skutečnou cestu předávání provozu a pravidla firewallu. Ověřte, že provoz nemůže obejít kontrolní bod přes alternativní rozhraní, bridge nebo nespravovaný přepínač.
Povolení celé podsítě kvůli pohodlí
Pokud aplikace potřebuje přístup k jedné databázi, je rychlejší povolit celou webovou podsíť než určit přesný zdroj. Zároveň to umožní každému napadenému nebo chybně nakonfigurovanému hostiteli v podsíti přístup k databázi. Místo toho používejte skupiny adres a pravidla pro konkrétní služby.
Ponechání dočasných výjimek
Nouzový přístup se často stane trvalým. Každé dočasné pravidlo by mělo mít vlastníka, důvod, datum vytvoření a datum ukončení. Prošlá pravidla kontrolujte v rámci běžného provozu, nejen po incidentu.
Používání sdílených přihlašovacích údajů
Sdílené účty správců a služeb ztěžují přiřazení aktivity konkrétní osobě a usnadňují útočníkovi pohyb mezi systémy. Používejte individuální účty pro lidi, samostatné identity služeb pro aplikace a jedinečné přihlašovací údaje pro zálohovací a správní systémy.
Umístění rozhraní správy do produkčních sítí
Porty pro správu serverů, konzole hypervizorů a správa úložišť by neměly být dostupné z běžných zařízení uživatelů ani z veřejně dostupných úloh. Síť správy je užitečná pouze tehdy, pokud je omezen i přístup do ní.
Zapomenutí na zařízení, která nejsou servery
Tiskárny, kamery, systémy budov a levná síťová zařízení bývají udržovány hůře než servery. Neměla by mít neomezený přístup k citlivé infrastruktuře. Umístěte je do vhodné zóny zařízení a povolte pouze služby, které potřebují.
Nedostatečná dokumentace výjimek
Nezdokumentovaná pravidla se stávají trvalými předpoklady. Když technik odejde nebo se aplikace změní, nikdo neví, proč spojení existuje ani zda je možné je odstranit. Dokumentace je součástí kontroly, nikoli administrativní ozdobou.
Jak ověřit, že segmentace funguje
Návrh není prokázán síťovým diagramem. Kontrolní body testujte ze stejných míst, která by mohl využít útočník. Udržujte schválený testovací plán, aby skenování a pokusy o spojení nenarušily produkci.
Testujte povolené cesty
Z každé zdrojové zóny ověřte dostupnost potřebných služeb. Testujte přesný protokol a port, nejen to, zda cíl odpovídá na ping. Potvrďte, že transakce aplikací, monitorování, správa a zálohovací úlohy fungují zamýšlenými cestami.
Testujte zakázané cesty
Pokoušejte se o spojení z webových serverů k rozhraním správy, z uživatelských sítí k databázím, z aplikačních serverů k nesouvisejícím produkčním systémům a z běžných serverů k portům správy záloh. Tyto testy musí selhat. Úspěšné spojení vyžaduje prošetření, i když služba neodhalí žádná data.
Testujte z pohledu napadeného hostitele
Pomocí kontrolovaného testovacího účtu nebo schváleného bezpečnostního hodnocení simulujte útočníka, který získal přístup k jednomu serveru. Ověřte, zda z této pozice lze provádět síťové zjišťování, přistupovat ke službám přihlašovacích údajů, vzdáleně spravovat systémy, sdílet soubory nebo přistupovat do jiných zón. Hledejte cesty, které byly přehlédnuty, protože původní dokumentace popisovala zamýšlený, nikoli skutečný provoz.
Kontrolujte protokoly a upozornění
Ověřte, že zamítnutá spojení jsou viditelná s užitečnou mírou podrobnosti. Upozornění by měla identifikovat neobvyklé skenování, opakované pokusy o přístup k citlivým zónám a změny bezpečnostních zásad. Zajistěte, aby byly protokoly uchovávány na místě, kde je napadený server nemůže smazat.
Testujte selhání a obnovu
Firewally, přepínače a VPN brány mohou selhat nebo být chybně nakonfigurovány. Ověřte chování prostředí při selhání zařízení, nasazení pravidel nebo ztrátě primární cesty správy. Potvrďte, že nouzový přístup je řízený a zdokumentovaný, místo abyste spoléhali na nezdokumentovanou obchvatnou cestu.
Po významných změnách test opakujte: nové aplikace, migrace serverů, redesign VLAN, změny poskytovatele a aktualizace firewallu mohou změnit dostupnost. Automatizované ověřování zásad a plánované skenování zranitelností mohou pomoci, měly by však podporovat lidskou kontrolu obchodních závislostí, nikoli ji nahrazovat.
Segmentace a reakce na incidenty
Během incidentu by měla segmentace týmu pomoci rychle izolovat server, aniž by odpojil celý podnik. Připravte předem definované kroky omezení pro běžné situace. Mohou zahrnovat deaktivaci portu přepínače hostitele, odstranění serveru z produkční VLAN, zablokování účtu služby, omezení odchozího přístupu zóny nebo přesun správy na nouzovou cestu.
Udržujte přesný inventář zařízení a závislostí. Pokud zasahující pracovníci nevědí, které služby na serveru závisí, mohou jej izolovat příliš pomalu nebo způsobit zbytečné přerušení. U důležitých systémů zaznamenejte obchodního vlastníka, technického vlastníka, zónu, kritické závislosti, pravidla zálohování a prioritu obnovy.
Havarijní postupy by měly uvádět, kdo může schválit nouzové změny firewallu, jak se změny zaznamenávají a jak se po incidentu obnoví běžná politika. Postupy testujte. Kontrola, která existuje pouze v dokumentu, ale nelze ji pod tlakem použít, poskytuje omezenou ochranu.
Proč segmentace nemůže nahradit izolované zálohy
Segmentace omezuje dostupnost; z napadeného systému však nedělá bezpečný systém. Útočník může zneužít povolené aplikační spojení, napadnout pracovní stanici správce, ukrást přihlašovací údaje, zneužít výjimku ve firewallu nebo napadnout zálohovací systém legitimními cestami správy. Malware může také poškodit data ještě před spuštěním zálohovací úlohy.
Obnovitelnost znamená více než mít někde kopii. Kopie musí být dostupná po napadení produkce, chráněná před neoprávněným smazáním, vhodně zašifrovaná, uchovávaná po požadovanou dobu a obnovitelná v rámci cílů obnovy firmy.
Safenix poskytuje off-site zálohování firemních serverů kontrolovaných zákazníkem. Data jsou šifrována klíčem, který Safenix nikdy nedrží, uložena v Německu a po celou dobu retenční lhůty uchovávána v neměnné podobě. Tento model doplňuje segmentaci: síťová opatření snižují pravděpodobnost šíření incidentu, zatímco nezávislá kopie pro obnovu pomáhá firmě vrátit se do známého funkčního stavu, pokud jsou systémy nebo lokální zálohy poškozeny.
Zálohovací spojení plánujte jako součást architektury. Omezte, které hostitele mohou odesílat zálohovaná data, držte správu záloh mimo běžné produkční účty a testujte obnovu, nikoli pouze to, zda úlohy hlásí úspěch. Úspěšná zálohovací úloha dokládá, že data byla zkopírována; úspěšná obnova ukazuje, že data skutečně podporují zotavení.
Plán zvládnutelné implementace
Malé týmy mohou segmentaci zlepšovat postupně. Začněte systémy, které představují největší riziko a hodnotu, místo abyste se pokoušeli najednou o dokonalý redesign.
- Zmapujte prostředí. Identifikujte servery, virtuální počítače, uživatele, síťová zařízení, rozhraní správy, databáze, zálohovací systémy a externí závislosti.
- Klasifikujte vystavení. Označte internetové, interní, citlivé, administrativní a obnovovací systémy. Určete, kde by jeden kompromitovaný systém způsobil největší dopad.
- Definujte zóny. Začněte praktickými skupinami, jako jsou okrajová, webová, aplikační, databázová, správní, uživatelská a zálohovací zóna. Zóny dále rozdělujte pouze tehdy, když rozdíl v pravidlech ospravedlňuje provozní náklady.
- Vytvořte komunikační matici. Zaznamenejte potřebný zdroj, cíl, protokol, port, směr, vlastníka a účel.
- Nejprve vynucujte nejcennější hranice. Oddělte veřejně dostupné servery od databází, uživatele od systémů správy a produkci od správy záloh.
- Použijte pravidla s výchozím zákazem. Přidejte konkrétní výjimky pro ověřené závislosti a zaznamenávejte důležité zamítnuté pokusy.
- Zabezpečte identity. Odstraňte sdílené přihlašovací údaje, zapněte vícefaktorové ověřování pro vzdálenou správu a omezte privilegovaný přístup na cestu správy.
- Testujte a dokumentujte. Ověřte povolené i blokované cesty, zaznamenejte výsledky a aktualizujte inventář zařízení a pravidel.
- Průběžně kontrolujte. Po změnách aplikací, personálu, migracích k poskytovatelům a bezpečnostních incidentech zásady znovu prověřte.
Cílem není vytvořit prostředí, v němž spolu nemůže nic komunikovat. Cílem je zajistit, aby každé důležité spojení bylo záměrné, omezené a obhajitelné. Když je server napaden, právě tato rozhodnutí určují, zda incident zůstane pod kontrolou, nebo se promění ve výpadek celé infrastruktury.