Logování průmyslových dat z pohledu kybernetické bezpečnosti - od ploché sítě k segmentované architektuře
Zadání problému
Představme si typickou průmyslovou aplikaci: výrobní linka řízená dvěma řídicími systémy ControlLogix od Rockwell Automation. Operátoři potřebují sledovat a řídit stav výroby v reálném čase na třech HMI panelech (mohou být použity například grafické panely Optix) a zároveň je požadováno periodické ukládání vybraných PLC tagů do SQL databáze, která má být dále přístupná IT aplikacím pro účely reportingu a analýzy dat. Pro řešení vizualizace zde můžeme například navrhnout jedno zařízení Optix Edge, které bude hostovat aplikaci FactoryTalk Optix a tu bude distribuovat do HMI panelů jako do webových klientů pomocí WebPresentationEngine objektu.
Hardwarová základna je tedy následující:
- dva ControlLogix PLC jako zdroje dat
- jedno zařízení Optix Edge jako runtime pro běh FT Optix aplikace
- tři Optix panely jako HMI terminály / weboví klienti
- SQL server jako cílové úložiště historických dat
Požadavky jsou zdánlivě jednoduché — distribuovat vizualizační aplikaci do panelů a pravidelně odesílat data do databáze. Způsob, jakým tyto funkcionality technicky realizujeme, má ale zásadní vliv na bezpečnost celého OT prostředí.
Nesprávné (naivní) řešení: plochá síť
Nejjednodušší a bohužel v praxi stále ještě poměrně rozšířené řešení vypadá tak, že všechna zařízení zapojíme do jedné společné sítě bez jakékoli segmentace. Oba řídicí systémy jsou připojeny přes switch ke stejnému síťovému segmentu, ve kterém se nachází Optix Edge, všechny tři HMI panely a dokonce i samotný SQL server. Na Optix Edge běží jediná FT Optix aplikace, která zajišťuje jak vizualizaci pro panely prostřednictvím WebPresentationEngine, tak i logování dat do SQL serveru.
SQL server přitom není izolován — přistupují k němu i uživatelé z firemní IT sítě, například za účelem generování reportů nebo exportu dat do podnikového informačního systému. Vzniká tak přímé propojení OT sítě s IT světem, pravděpodobně i s veřejným internetem, a to bez jakékoli ochranné vrstvy.
Tuto architekturu nazýváme „plochá síť“ a nese s sebou několik závažných bezpečnostních rizik.
Absence síťové segmentace
V ploché síti má každé zařízení přímý přístup ke každému jinému zařízení. Kompromitace jakéhokoli uzlu — ať už HMI panelu, SQL serveru nebo libovolného IT počítače s přístupem do databáze — otevírá útočníkovi přímou cestu k řídicím systémům. V průmyslovém prostředí to znamená potenciální možnost zasáhnout do řízení technologického procesu, běh tohoto procesu narušit či destruovat, zneužít citlivá data apod.
Monolitická aplikace
Jediná FT Optix aplikace obsluhuje zároveň vizualizaci i data logging, což znamená, že má přístup jak ke komunikaci s PLC, tak k databázovému serveru. Jakákoli zranitelnost v aplikační logice nebo v konfiguraci spojení může být zneužita k průniku do obou systémů současně.
Vystavení SQL serveru
Server, který přijímá data přímo z OT sítě, je zároveň dostupný z IT prostředí bez firewallu. Útočník, který získá přístup k SQL serveru z IT strany, se nachází ve stejném síťovém segmentu jako PLC.
Správné řešení: segmentovaná architektura s IDMZ
Bezpečná architektura vychází z Purdue modelu a principu hloubkové obrany (defense-in-depth). Purdue model (často označovaný jako Purdue Enterprise Reference Architecture – PERA) je referenční architektura používaná v průmyslové automatizaci a kybernetické bezpečnosti pro strukturování výrobních systémů a jejich oddělení od IT sítí. Je zásadní zejména v kontextu OT (Operational Technology) a standardů jako ISA-95 nebo IEC 62443.
Ve správně zabezpečeném řešení našeho zadání rozdělíme síť je rozdělena do tří zón, které od sebe oddělíme firewally:
- OT síť (Purdue L1-L2),
- průmyslová DMZ neboli IDMZ (Purdue L3.5)
- IT síť (Purdue L4).
Dvě oddělené Optix aplikace
Vedle toho provedeme ještě jednu změnu oproti naivnímu řešení – rozdělíme funkcionality do dvou samostatných FT Optix aplikací. Pro běh těchto aplikací můžeme nasadit dvě Optix Edge zařízení anebo může jedna ze dvou aplikací běžet v Docker kontejneru. Použijeme-li kontejnerizaci, snížíme hardwarové nároky a budeme potřebovat pouze jediné Optix Edge zařízení. Pro zjednodušení v dalším textu píšeme o dvou Optix Edge zařízeních.
Na prvním Optix Edge běží aplikace určená výhradně pro vizualizaci — distribuuje HMI obrazovky do panelů prostřednictvím WebPresentationEngine a nemá žádný přímý přístup k databázovému serveru.
Na druhém Optix Edge běží aplikace určená výhradně pro data logging — čte vybrané tagy z obou PLC a odesílá je přes firewall do stagingového SQL serveru v IDMZ (viz dále). Každá aplikace má přesně definovanou a omezenou množinu komunikačních oprávnění, žádná z nich nepotřebuje přístup k oběma systémům zároveň.
OT síť a VLAN segmentace
OT síť je dále interně segmentována pomocí VLAN. První VLAN sdružuje oba řídicí systémy ControlLogix a dvě zařízení Optix Edge — tato VLAN obsahuje výhradně zařízení přímo komunikující s technologickým procesem. Druhá VLAN je vyhrazena pro tři HMI panely.
IDMZ
IDMZ je zkratka pro Industrial Demilitarized Zone. Jde tedy o oddělenou zónu, která slouží jako bezpečnostní vrstva mezi OT a IT prostředím. Stagingový SQL server v IDMZ přijímá data z OT sítě přes první firewall, ale sám o sobě není dostupný z IT prostředí pro zápis. IT systémy si data ze stagingu aktivně stahují přes druhý firewall pomocí mechanismu pull — iniciátorem komunikace je vždy IT strana, nikdy IDMZ.
Využití IDMZ zajišťuje, že případný incident v IT prostředí nemůže přímo ohrozit dostupnost ani integritu OT systémů.
Návrh IP adresace
| Zóna | Podsíť | Zařízení a adresy |
|---|---|---|
| VLAN 1 (PLC + Edge) | 10.0.1.0/24 | ControlLogix 1: 10.0.1.10, ControlLogix 2: 10.0.1.11, Optix Edge 1: 10.0.1.20, Optix Edge 2: 10.0.1.21 |
| VLAN 2 (HMI panely) | 10.0.2.0/24 | Panel 1: 10.0.2.10, Panel 2: 10.0.2.11, Panel 3: 10.0.2.12 |
| IDMZ | 10.0.3.0/24 | SQL staging: 10.0.3.10 |
| IT síť | 10.0.4.0/24 | SQL finální: 10.0.4.10 |
Pravidla Firewall 1 (OT → IDMZ)
Firewall 1 odděluje OT síť od IDMZ. Jediný povolený datový tok je odesílání logovaných tagů z Optix Edge 2 na stagingový SQL server. Komunikace z IDMZ směrem do OT sítě je zakázána. Optix Edge 1 nemá žádné pravidlo pro průchod přes FW1, protože s IDMZ ani IT sítí vůbec nekomunikuje.
| Pravidlo | Zdroj | Cíl | Port | Akce |
|---|---|---|---|---|
| 1 | 10.0.1.21 | 10.0.3.10 | TCP 1433 | PERMIT |
| 2 | any | any | any | DENY |
Pravidla Firewall 2 (IDMZ → IT)
Firewall 2 odděluje IDMZ od IT sítě. Jediný povolený tok je iniciovaný z IT strany — finální SQL server si aktivně stahuje data ze stagingu. Klíčový princip je, že komunikaci iniciuje vždy IT strana (pull), nikoli IDMZ směrem do IT. Tím je zajištěno, že i při kompromitaci IT sítě nemůže útočník aktivně tlačit data nebo příkazy směrem do IDMZ a dál do OT prostředí.
| Pravidlo | Zdroj | Cíl | Port | Akce |
|---|---|---|---|---|
| 1 | 10.0.4.10 | 10.0.3.10 | TCP 1433 | PERMIT |
| 2 | any | any | any | DENY |
Závěr
Návrh síťové architektury pro průmyslový data logging představuje rozhodnutí s přímým dopadem na bezpečnost celého výrobního provozu. Jak ukazuje srovnání obou řešení, funkčně ekvivalentní systém může mít zásadně odlišnou úroveň odolnosti vůči kybernetickým hrozbám.
Plochá síť bez segmentace je lákavá svou jednoduchostí a nízkými pořizovacími náklady. Propojení všech zařízení do jednoho segmentu a jedna monolitická aplikace zajišťující vizualizaci i data logging skutečně fungují — dokud se neobjeví problém. SQL server vystavený IT prostředí bez jakékoli ochranné vrstvy představuje přímý most mezi firemní sítí a průmyslovými řídícími systémy. V době, kdy jsou OT sítě stále častějším cílem kybernetických útoků, je taková architektura nepřijatelným rizikem.
Segmentované řešení s IDMZ přináší několik vrstev ochrany, které se navzájem doplňují. Rozdělení OT sítě do dvou VLAN odděluje HMI panely od řídicích systémů. Dva samostatné Optix Edge s oddělenými aplikacemi uplatňují princip nejmenšího oprávnění na aplikační úrovni. IDMZ se stagingovým SQL serverem fyzicky přerušuje přímé spojení mezi IT a OT světem. Dva průmyslové firewally s explicitně definovanými pravidly zajišťují, že veškerá komunikace mezi zónami je předem schválená a auditovatelná. Pull princip na hranici IDMZ a IT sítě pak zajišťuje, že iniciátorem každého datového toku je vždy IT strana — útočník z IT prostředí tedy nemá možnost aktivně pronikat do nižších vrstev architektury.
Je třeba doplnit, že přidané náklady na hardware – průmyslové firewally, stagingový server, případně druhé Optix Edge zařízení jsou ve srovnání s potenciálními důsledky bezpečnostního incidentu v OT prostředí zanedbatelné.
Poznámka: Tento článek se zabývá pouze aplikačním návrhem a návrhem síťové infrastruktury. Pro komplexní řešení kybernetické bezpečnosti daného projektu je jistě potřebné věnovat pozornost i dalším bezpečnostním otázkám (analýza rizik, bezpečnost na aplikační úrovni a na úrovní zařízení, řízení přístupů, monitoring atd.), stejně tak jako zabezpečení samotného finálního SQL serveru (autentizace, šifrování, hardening atd.).
