Představte si, že bude váš webový server zítra kompromitován. Ke kterým dalším zařízením se dostane? Odpověď spolurozhoduje o tom, zda incident zůstane u jedné služby, nebo ohrozí další části firmy. Aktualizace chrání před známou zranitelností. Dobře navržená síť navíc omezuje možné následky.
Příkladem je fiktivní zákaznický portál: uživatelé se přihlašují, prohlížejí objednávky a stahují dokumenty. Aplikace potřebuje jasně vymezený přístup k databázi. To neznamená, že musí mít také přístup ke správě NAS, zálohovacímu serveru nebo virtualizačnímu hostiteli. Tento rozdíl je nutné technicky vynutit.
Kompromitovaná služba využívá dostupné cesty
Zranitelnost může umožnit spuštění cizího kódu s oprávněními webové aplikace. Další možnosti závisejí mimo jiné na síťových pravidlech, účtech služeb, uložených přihlašovacích údajích a dalších zranitelnostech. Dosažitelnost ještě neznamená úspěšný přístup. Kompromitovaný webový server také automaticky neovládne celou LAN.
Riziko roste, pokud se dosažitelné interní služby spojí s příliš širokými oprávněními. Útočník pak musí překonat méně hranic. Takové možné šíření k dalším systémům se označuje jako laterální pohyb. Při návrhu je proto užitečné předpokládat, že již byla některá aplikace kompromitována.
Síť A: portál je v ploché firemní síti
V prvním uspořádání sdílejí portál, databáze, souborové úložiště a rozhraní pro správu jednu síť. Perimetrový firewall sice omezuje příchozí spojení, mezi interními systémy však existují příliš široká povolení nebo nedostatečné oddělení. Webový server tak dosáhne na více cílů, než potřebuje ke své práci.
Sdílený účet správce situaci zhoršuje. Totéž platí pro připojený zálohovací adresář s právem zápisu nebo rozsáhlé přihlašovací údaje uložené v adresáři aplikace. Funkční záloha pomůže jen omezeně, pokud kompromitovaná služba může měnit také její správu nebo všechny záložní kopie.
Síť B: zóny a pravidla omezují spojení
Ve druhém uspořádání se požadavky z internetu dostanou nejprve k vymezenému frontendu nebo reverzní proxy. Ta smí oslovit potřebnou aplikaci v samostatném webovém segmentu. Aplikace získá pouze nezbytné spojení ke konkrétnímu databázovému cíli. Správa, zálohovací systémy a další interní služby jsou v oddělených zónách; nepotřebné přístupy z webového segmentu jsou blokovány.
VLAN síť logicky rozděluje. Zda toto rozdělení vytvoří účinnou bezpečnostní hranici, určuje řízení spojení. Příliš volné směrování mezi VLAN oddělené sítě z velké části znovu propojí. I uvnitř jedné VLAN může být nutné další filtrování mezi jednotlivými pracovními zátěžemi.
OPNsense nebo Sophos Firewall mohou být platformami pro odpovídající pravidla; vhodné mohou být i jiné produkty. Rozhodují konkrétní zdroje, cíle, služby, odpovědnosti a ověřené provedení. Ovládání a dostupné funkce se mezi platformami liší. Samotný název produktu nepopisuje otestovanou bezpečnostní architekturu.
Reverzní proxy a WAF zůstávají součástí ochrany
Reverzní proxy může sjednotit veřejné přístupy, zpracovávat spojení TLS a cíleně předávat požadavky backendům. HAProxy k tomu mimo jiné podporuje režimy HTTP a TCP. Neznamená to obecnou funkci proxy pro libovolný protokol. Předřazený webový aplikační firewall může rozpoznat a odmítnout určité škodlivé webové požadavky.
Tyto prvky nenahrazují bezpečné aplikace, včasné aktualizace ani omezené přístupy k backendům. Chybná pravidla nebo jiný dosažitelný vstup mohou ochranu obejít. I aplikace kompromitovaná za proxy proto v našem příkladu smí dosáhnout pouze na výslovně potřebné cíle.
Myslete na odchozí i vnitřní provoz
Rozhodující otázkou není jen to, kdo se smí připojit k webovému serveru. Kam může spojení navazovat samotný server? Dosáhne na rozhraní pro správu NAS? Musí kontaktovat libovolné internetové cíle? Které interní služby skutečně potřebují ostatní kontejnery?
Do plánování odchozího provozu, tedy egressu, patří například překlad jmen, synchronizace času, aktualizace a externí rozhraní. Potřebné cíle se povolují konkrétně. Srozumitelná pravidla vyžaduje i komunikace mezi interními systémy, často označovaná jako provoz east-west. Stejné zamýšlené oddělení musí dodržovat také IPv6 a alternativní trasy.
Plán spojení zaznamenává zdroj, cíl, potřebnou službu, účel a odpovědnou osobu. Následně se řízeně ověří povolené i blokované cesty. Logy a monitoring mají odhalit nečekaná úspěšná spojení i podezřelé blokované pokusy. Pravidlo bez ověřeného účinku ještě není spolehlivým důkazem ochrany.
VM i kontejnery potřebují odpovídající hranice
Virtuální stroj má vlastní hostovaný operační systém; kontejnery obvykle sdílejí jádro hostitele. Oba modely vyžadují vhodné nastavení sítě a oprávnění. Proxmox VE nabízí pravidla firewallu pro hostitele i hostované systémy. Které vrstvy a funkce skutečně působí, závisí také na použitém backendu firewallu a konkrétním zapnutí funkcí.
V Dockeru spolu mohou komunikovat kontejnery na stejné síti bridge. Odchozí spojení nejsou automaticky omezena jen na veřejné cíle. Publikované porty mohou vytvářet další vstupy. V režimu host kontejnery sdílejí síťový jmenný prostor hostitele; samostatná síťová izolace zde tedy neexistuje.
Dodatečná privilegia, zbytečně připojené adresáře hostitele a přístup k socketu Dockeru mohou následky incidentu výrazně rozšířit. Oddělené aplikační sítě, minimální oprávnění, vhodná pravidla firewallu hostitele a řízené cesty DNS a egressu proto patří dohromady. I zde rozhoduje skutečně účinná konfigurace.
Zvládnutelný začátek pro menší firmy
- Zmapovat služby: zdokumentovat veřejné aplikace, závislosti a odpovědné osoby.
- Vymezit zóny: oddělit veřejné zátěže, data, správu a zálohy podle potřeb ochrany.
- Zdůvodnit spojení: povolit jen určené zdroje, cíle a služby; ostatní blokovat tam, kde je to provozně vhodné.
- Zabezpečit správu: používat důvěryhodné přístupové cesty, vhodné VPN a MFA a oddělené účty.
- Zahrnout provoz: počítat s aktualizacemi, centrálními logy, upozorněními a nezávisle chráněnými zálohami s otestovanou obnovou.
- Prokázat účinek: pravidelně kontrolovat pravidla, časově omezit výjimky a po změnách testovat znovu.
Změny vyžadují přípravu, vhodné servisní okno a možnost návratu. Plošná blokace může přerušit legitimní aplikace nebo vlastní přístup ke správě. Nejprve proto zmapujte závislosti, poté proveďte řízený přechod a s odpovědnými lidmi ověřte funkčnost pro běžný provoz.
Pád aplikace nemusí znamenat pád sítě za ní
Články PHP2Shell o reakci na zranitelnosti PHP a inventarizaci s podporou AI přinášejí aktuální podnět. Doplňující kontrola NAS, Dockeru a veřejných služeb vede k trvalé architektonické otázce: která spojení a oprávnění daná služba opravdu potřebuje?
DAXS pomáhá s inventarizací, komunikačním plánem, realizací a ověřitelným provozem. Ať aplikace běží lokálně, v privátním cloudu nebo na veřejné cloudové platformě, ochranné hranice musí odpovídat skutečným potřebám. Proberme vaše konkrétní prostředí.
Zdroje: OPNsense: pravidla a stavové filtrování · Sophos Firewall: zóny, pravidla a logování · HAProxy: režimy HTTP a TCP · Docker: sítě bridge · Docker: síťový režim host · Docker: daemon, oprávnění a bezpečnostní hranice · Proxmox VE: dokumentace firewallu · NCSC: omezení šíření, ochrana správy a záloh.
