Segmentace sítě a zvýšení bezpečnosti v hybridní on-premise a cloudové infrastruktuře

1. Shrnutí pro vedení

Segmentace sítě zůstává jedním z nejúčinnějších opatření ke snížení kybernetického rizika v podnikových prostředích. Mnoho organizací ji přesto nedokáže účinně zavést, zejména ty, které provozují hybridní infrastrukturu zahrnující vlastní datová centra, několik cloudových platforem a sítě provozních technologií (OT).

Tento whitepaper vychází z praktických zkušeností se zaváděním programů segmentace ve farmaceutických, výrobních, automobilových, logistických a veřejných prostředích. Představuje strukturovaný přístup k segmentaci, který řeší skutečné výzvy: starší systémy, které nelze snadno přesunout, OT sítě, kde má dostupnost přednost před důvěrností, cloudová prostředí s odlišnými bezpečnostními modely a organizace s omezenými servisními okny a konkurujícími prioritami.

Hlavní argument je jednoduchý: účinná segmentace v hybridních prostředích vyžaduje zónovou architekturu, u které je hlavním návrhovým omezením hranice důvěry, nikoli topologie sítě. Pro OT prostředí poskytuje koncepční rámec model Purdue, principy Zero Trust tento přístup rozšiřují na IT a cloud. Metodika zavedení musí být postupná, bezpečná pro výrobu a sladěná s provozem firmy i s regulatorními požadavky.

2. Výzva

Moderní podnikové sítě nejsou jednotná, homogenní prostředí. Jsou to složeniny: firemní LAN s Active Directory a Microsoft 365, výrobní OT síť s PLC a systémy SCADA, jedna nebo více cloudových platforem (AWS, Azure, GCP) s provozovanými systémy a rostoucí počet SaaS aplikací dostupných odkudkoli. Každá vrstva funguje s jinými bezpečnostními předpoklady, jinými procesy řízení změn a jinými regulatorními požadavky.

Problém ploché sítě

Mnoho organizací rozvíjelo své sítě postupně. Z jednoduché kancelářské LAN vyrostla síť pro více lokalit a funkcí, ve které se z jediného kompromitovaného zařízení lze dostat k řídicím systémům výroby, finančním databázím i ke správě cloudu. Síť je „plochá“, tedy má málo vnitřních hranic, které by omezovaly laterální pohyb, nebo žádné.

Incident za incidentem, od NotPetya až po nedávné ransomwarové kampaně zaměřené na výrobu, byl hlavním zesilovačem škod laterální pohyb v plochých sítích. Útočník získá počáteční přístup přes phishingový e-mail nebo vystavenou službu a během minut se dostane z firemní IT sítě do OT systémů, zálohovací infrastruktury nebo účtů pro správu cloudu.

Komplikace hybridního prostředí

Segmentace v čistě vlastním prostředí je dobře známá: nasadit firewally, vytvořit VLAN, zavést seznamy řízení přístupu. Hybridní prostředí ale přidávají další složitost. Cloudové sítě používají softwarově definované perimetry, které se nedají jednoduše převést na tradiční segmentaci pomocí firewallů. OT sítě obsahují zařízení, na kterých nelze provozovat agenty, nepodporují moderní ověřování a mohou používat proprietární protokoly, které firewally nedokážou kontrolovat. A propojení mezi těmito prostředími (VPN tunely, okruhy ExpressRoute, API brány) vytvářejí vztahy důvěry, které bývají špatně zdokumentované a nekonzistentně monitorované.

Lidský faktor

Kromě technické složitosti narážejí projekty segmentace i na organizační tření. OT týmy se obávají o dostupnost. Vlastníci aplikací se bojí přerušení konektivity. Rady pro změny požadují důkazy, že změny jsou bezpečné. A bezpečnostním týmům často chybí provozní kontext k návrhu politik, které fungují v praxi. Programy segmentace, které selžou, téměř vždy selžou z organizačních, ne technických důvodů.

3. Principy segmentace

Účinná segmentace není primárně technologický projekt. Je to architektonická disciplína, která vyžaduje jasné principy. Ty určují každé návrhové rozhodnutí i každé pravidlo politiky.

Princip 1: Segmentujte podle důvěry, ne podle umístění

Tradiční segmentace podle fyzického umístění (budova, patro, lokalita) v hybridních prostředích nestačí. Segmentujte místo toho podle úrovně důvěry: jak citlivá jsou data? Jak kritický je systém? Jaké jsou následky kompromitace? Systémy s podobnými požadavky na důvěru patří do stejné zóny bez ohledu na fyzické nebo virtuální umístění.

Princip 2: Definujte kanály, nejen zóny

IEC 62443-3-2 zavádí pojem „kanálů“ (conduits): řízených cest mezi zónami. Právě zde většina návrhů segmentace zaostává. Nestačí umístit systémy do oddělených VLAN, musíte výslovně definovat, jaká komunikace je mezi zónami povolena, přes jaké protokoly, jakým směrem a za jakých podmínek. Každý kanál by měl mít zdokumentované obchodní zdůvodnění.

Princip 3: Výchozí zákaz, výslovné povolení

Každý firewall a každé řízení přístupu by mělo ve výchozím stavu provoz zakazovat. Povolené toky se výslovně konfigurují na základě zdokumentovaných požadavků. Zní to samozřejmě, ale v praxi mnoho organizací funguje s výchozím povolením a ke blokování známých hrozeb spoléhá na černé listiny. To je zásadně slabší zabezpečení.

Princip 4: Bezpečnost výroby na prvním místě

V OT prostředích má dostupnost a bezpečnost provozu nejvyšší prioritu. Segmentace nikdy nesmí ohrozit výrobu ani bezpečnostní systémy. To znamená důkladné testování před zavedením, postupné nasazení (nejdřív režim monitorování, pak vynucování) a jasné postupy pro návrat u každé změny.

Princip 5: Hloubková obrana napříč vrstvami

Segmentace je jednou vrstvou strategie hloubkové obrany. Má být doplněna ochranou koncových zařízení, řízením identit a přístupů, monitorováním a detekcí a schopností reagovat na incidenty. Žádné jednotlivé opatření nestačí. Hodnota segmentace je v tom, že omezí dosah škod, když ostatní opatření selžou.

4. Architektonické vzory

Model Purdue pro OT prostředí

Referenční podniková architektura Purdue (PERA) poskytuje základní model pro segmentaci OT sítí. Definuje hierarchické úrovně od úrovně 0 (fyzický proces) po úroveň 5 (podniková síť) s klíčovou demilitarizovanou zónou (DMZ) na úrovni 3.5, která odděluje IT od OT.

Klíčovým návrhovým rozhodnutím je IT/OT DMZ. Tato zóna by měla obsahovat jen systémy, které potřebují překlenout hranici IT/OT: zrcadla datových historianů (nikdy ne primární historian), servery pro správu záplat s řízenými okny aktualizací a jump servery pro ověřený vzdálený přístup. Z úrovně 5 by neměl proudit žádný přímý provoz na úroveň 2 nebo níže.

Zero Trust pro IT a cloud

Na straně IT rozšiřuje architektura Zero Trust myšlení segmentace za hranice sítě. Princip „nikdy nedůvěřuj, vždy ověřuj“ se promítá do mikrosegmentace na úrovni workloadů, řízení přístupu podle identity, průběžného ověřování stavu zařízení a šifrované komunikace mezi všemi službami.

V cloudových prostředích to odpovídá segmentaci VPC/VNET, bezpečnostním skupinám, síťovým ACL a architekturám service mesh. Nativní cloudové prvky segmentace se liší od firewallů ve vlastním prostředí, ale principy jsou totožné: definovat hranice důvěry, řídit kanály a ve výchozím stavu zakazovat.

Vrstva hybridního propojení

Architektonicky nejnáročnější částí je propojení vlastního a cloudového prostředí. VPN tunely, okruhy ExpressRoute/Direct Connect a API brány vytvářejí cesty, které mohou obejít pečlivě navrženou segmentaci ve vlastním prostředí. Každé hybridní propojení je třeba brát jako kanál: zdokumentovaný, monitorovaný a podléhající politikám řízení přístupu, které jsou nejméně tak restriktivní jako nejcitlivější zóna, které se dotýká.

5. Specifika OT/ICS

Práce se staršími protokoly

OT prostředí běžně používají protokoly, které jsou starší než moderní bezpečnostní uvažování: Modbus, DNP3, OPC Classic, PROFINET, EtherNet/IP. Mnohé z nich postrádají ověřování, šifrování nebo kontrolu integrity. Segmentace slabiny na úrovni protokolů kompenzuje tím, že omezuje, které systémy mohou pomocí těchto protokolů komunikovat, a monitoruje neobvyklé vzorce provozu.

Řízení přístupu dodavatelů

Dodavatelé OT často potřebují vzdálený přístup kvůli údržbě, řešení problémů a aktualizacím softwaru. Tento přístup musí být řízen přes jump servery v IT/OT DMZ, se záznamem relací, časově omezenými přístupovými okny a vícefaktorovým ověřováním. Přímý VPN přístup dodavatelů do výrobních OT sítí je jedním z nejčastějších a nejnebezpečnějších architektonických antivzorů.

Izolace bezpečnostních systémů

Bezpečnostní přístrojové systémy (SIS) vyžadují další izolaci nad rámec běžné segmentace. Chrání lidské životy a majetek a musí být dostupné jen pro schválenou údržbu přes fyzicky kontrolovaný přístup nebo vysoce omezené síťové cesty. Sítě SIS by nikdy neměly být dostupné z firemního IT, cloudu ani běžných OT sítí.

6. Segmentace v cloudu

Architektura VPC/VNET

Segmentace v cloudu začíná návrhem VPC (AWS) nebo VNET (Azure). Každý hlavní workload nebo prostředí (produkce, staging, vývoj) by měl mít vlastní VPC/VNET s výslovně definovaným propojením mezi nimi. Tranzitní brány nebo architektury hub-and-spoke zajišťují centralizovanou inspekci provozu a vynucování politik.

Bezpečnostní skupiny a NACL

Nativní cloudové bezpečnostní skupiny poskytují mikrosegmentaci na úrovni instancí, zatímco síťové ACL zajišťují řízení na úrovni podsítí. Obě vrstvy by měly spolupracovat: NACL zajišťují široká omezení na úrovni zón, bezpečnostní skupiny vynucují konkrétní politiky mezi službami.

Service mesh a řízení přes API brány

U kontejnerových a mikroslužbových architektur poskytují technologie service mesh (Istio, Linkerd) vzájemné TLS, politiky provozu a přehled na úrovni služeb. API brány řídí externí přístup, omezení počtu požadavků a ověřování. Představují cloudový vývoj tradiční segmentace založené na firewallech.

7. Metodika zavedení

Zavedení segmentace musí být postupné, vratné a sladěné s provozní realitou. Následující metodika byla vyladěna na řadě rozsáhlých nasazení.

Fáze 1: Zmapování a baseline (2–4 týdny)

Zmapujte všechna aktiva, komunikační toky a závislosti. Tato fáze je průzkumná, nikoli rušivá. K sestavení architektury současného stavu použijte pasivní monitorování, revizi konfigurací a rozhovory s provozními týmy. Každý komunikační tok zdokumentujte se zdrojem, cílem, protokolem, portem, směrem a obchodním zdůvodněním.

Fáze 2: Návrh zón (2–3 týdny)

Na základě zjištěných dat definujte zóny a kanály. Seskupte aktiva podle úrovně důvěry a funkce. Navrhněte cílovou architekturu včetně umístění firewallů, změn směrování a politik řízení přístupu. Než budete pokračovat, projděte návrh s provozem, IT a obchodními zainteresovanými stranami.

Fáze 3: Nasazení v režimu monitorování (2–4 týdny)

Nasaďte pravidla firewallu v režimu monitorování nebo pouze logování. Toto je klíčový krok ověření: pravidla jsou aktivní, ale nic neblokují. Veškerý provoz, který by byl zablokován, se zaloguje a zreviduje. Tato fáze zachytí komunikační toky, které při mapování unikly, a zabrání dopadu na výrobu.

Fáze 4: Postupné vynucování (4–8 týdnů)

Přecházejte z monitorování na vynucování zónu po zóně, počínaje nejméně kritickou. Každý krok vynucování má definovaný postup pro návrat a období sledování. Změny se provádějí v dohodnutých servisních oknech s provozními týmy v pohotovosti.

Fáze 5: Průběžné zlepšování

Segmentace není jednorázový projekt. Nové systémy, aplikace a obchodní požadavky průběžně přinášejí nové komunikační toky. Zaveďte proces pro revizi a schvalování změn pravidel firewallu, pravidelné audity sady pravidel a ověřování, že opatření segmentace zůstávají účinná.

8. Soulad s předpisy

Dobře navržená segmentace splňuje požadavky několika regulatorních rámců současně.

9. Případová studie

Následující případová studie je zobecněná a vychází ze souhrnných zkušeností u více výrobních klientů. Konkrétní podrobnosti byly anonymizovány.

Situace

Evropský výrobce s více lokalitami měl převážně plochou síť. Firemní IT, inženýrské stanice, výrobní PLC i VPN připojení dodavatelů sdílely stejnou síťovou infrastrukturu. Penetrační test ukázal, že útočník s přístupem k firemnímu notebooku se do výrobních systémů SCADA dostane za 8 minut.

Postup

Segmentaci podle modelu Purdue jsme zavedli během 16 týdnů. Fáze 1 odhalila přes 1 200 OT aktiv a 340 jedinečných komunikačních toků. Fáze 2 navrhla architekturu se 6 zónami a 12 definovanými kanály. Fáze 3 běžela 3 týdny v režimu pouze logování a zachytila 47 nezdokumentovaných komunikačních toků. Fáze 4 vynucovala pravidla zónu po zóně po dobu 6 týdnů, bez jakéhokoli dopadu na výrobu.

Výsledky

Penetrační testy po zavedení ukázaly, že laterální pohyb z firemního IT do výrobního OT už není možný bez průchodu dvěma body inspekce na firewallech a jump serverem s vícefaktorovým ověřováním. Metrika času do zadržení u simulovaných incidentů se změnila z 8 minut (neomezený laterální pohyb) na stav, kdy by útočník potřeboval v síti setrvat déle než 4 hodiny, což stačí k detekci a reakci.

Program segmentace současně splnil požadavky klienta na bezpečnost sítě podle NIS2, zjištění z certifikačního auditu ISO 27001 i požadavek mateřské společnosti na soulad s IEC 62443.

10. Doporučení

Pro organizace, které se segmentací začínají

Začněte zmapováním. Nemůžete segmentovat to, čemu nerozumíte. Než navrhnete jakékoli zóny nebo napíšete jakékoli pravidlo firewallu, věnujte 2–4 týdny zmapování současné architektury, komunikačních toků a závislostí. Kvalita zmapování určuje kvalitu segmentace.

Pro organizace s částečnou segmentací

Prověřte, co máte. Mnoho organizací má VLAN a firewally, ale s příliš volnými pravidly, nezdokumentovanými výjimkami nebo obchvaty. Audit sady pravidel a analýza komunikačních toků často odhalí, že stávající segmentace je méně účinná, než se předpokládalo. Než přidáte nová opatření, zaměřte se na zpřísnění stávajících.

Pro organizace s OT prostředím

Dejte přednost hranici IT/OT. Jediným krokem segmentace s největším dopadem je vytvoření správně navržené IT/OT DMZ s řízenými kanály. Odstraňte přímý VPN přístup dodavatelů do výrobních sítí, nasaďte jump servery a zajistěte, aby z firemního IT neproudil žádný provoz přímo na úroveň 2 nebo níže.

Pro všechny organizace

Berte segmentaci jako program, ne jako projekt. Sítě se neustále mění. Bez průběžné správy (revize sad pravidel, napojení na řízení změn, pravidelné přehodnocování) se segmentace časem zhoršuje. Proces správy budujte souběžně s technickým zavedením.