Nesprávné (naivní) řešení: přímá konektivita z HMI do cloudu

Nejjednodušší řešení, které se jaksi na první pohled nabízí, vypadá tak, že Optix-Fiix knihovnu nasadíme přímo ve FT Optix aplikaci běžící na zařízení Optix Edge v OT síti, tedy na samotné vizualizační aplikaci. Vznikne tak jediná aplikace zajišťující zároveň HMI i odesílání dat do cloudového Fiix CMMS.

Protože Fiix je internetová služba, podmínkou pro funkčnost tohoto řešení je, že zařízení Optix Edge bude mít přímý odchozí přístup na veřejný internet.

Všechna zařízení jsou zapojena do jedné společné ploché sítě: oba PLC, Optix Edge i tři HMI panely sdílejí stejný síťový segment. Optix Edge komunikuje s PLC i s internetem. Neexistuje žádná ochranná vrstva ani kontrolní bod.

Přímé vystavení OT sítě internetu
Zařízení Optix Edge s aktivním odchozím připojením na internet představuje potenciální vstupní bod pro útočníka z veřejné sítě. Jakákoliv zranitelnost v Optix-Fiix knihovně, v runtime FT Optix nebo v operačním systému zařízení může být zneužita ke vzdálenému přístupu. Útočník, který kompromituje Optix Edge, se okamžitě nachází ve stejném síťovém segmentu jako oba PLC.

Jedna FT Optix aplikace s více úkoly
Jediná FT Optix aplikace zde obsluhuje zároveň vizualizaci i cloudovou komunikaci. Tak jako v předchozím článku se samozřejmě nabízí možnost rozdělit tyto funkcionality do dvou samostatných FT Optix aplikací, které by běžely na dvou různých hardwarových zařízeních Optix Edge anebo na jediném takovém zařízení s využitím kontejnerizace.

Toto rozdělení by bylo jistě správné z hlediska oddělení jednotlivých konceptů, též jistě s ohledem na budoucí správu a údržbu projektu apod., ale neodstranilo by principiální bezpečnostní problém – přímé vystavení OT sítě veřejnému internetu.

Absence segmentace a obtížnost monitoringu
Připomeňme ještě, že v ploché síti bez segmentace nelze efektivně řídit ani auditovat toky dat mezi OT zařízeními a vnějším světem. Neexistuje žádný kontrolní bod, který by umožnil detekovat anomálie, zablokovat nežádoucí spojení nebo zaznamenat, co a kam se skutečně odesílá.

Kompromisní řešení: integrační host bez stagingu

Kompromisní řešení přináší jedno zásadní zlepšení: funkci cloudové integrace přesouvá z OT sítě do samostatného hostitele umístěného v IDMZ (Industrial Demilitarized Zone). Na tomto integračním hostiteli běží FT Optix aplikace s nasazenou Fiix-Optix knihovnou a stará se výhradně o odesílání dat do Fiix CMMS.

V OT síti zůstává FT Optix aplikace pro HMI vizualizaci. Tato aplikace nevyužívá Optix-Fiix knihovnu a nijak nekomunikuje s Fiix cloudem.

Mezi OT sítí a integračním hostem je zařazen průmyslový firewall. Integrační host čte data přímo z OT a máme zde několik možností, jak tuto komunikaci nastavit, z nichž uvádím například:

• přímé čtení dat z řídicích systémů do FT Optix
• OPC komunikace mezi dvěma FT Optix aplikacemi
• MQTT komunikace mezi dvěma FT Optix aplikacemi

Nastavení pravidel na firewallu by pak odpovídalo zvolenému způsobu komunikace.

Co jsme vylepšili

• Optix Edge v OT síti již nepotřebuje přímý přístup k internetu. HMI panely ani řídicí systémy tak nejsou přímo vystaveny veřejné síti.
• Vizualizační aplikace a cloudová integrace jsou odděleny do různých zařízení, každé v jiné síti a s užším rozsahem komunikačních oprávnění.
• Firewall umožňuje omezit odchozí provoz na konkrétní cílovou adresu. Lze tedy povolit HTTPS výhradně na Fiix API server a veškerou ostatní odchozí komunikaci zablokovat. To výrazně snižuje riziko zneužití integrační aplikace k nežádoucí komunikaci s jinými servery.
• Použití průmyslového firewallu navíc nabízí možnosti monitoringu síťové komunikace a auditingu.

Kde zůstává riziko
Integrační host má přímý přístup do OT sítě pro čtení dat a zároveň přímý přístup na internet pro odesílání dat do Fiix cloudu. Je to tedy jakýsi most mezi dvěma světy, které by od sebe měly být důsledně odděleny. Oproti předcházejícímu řešení je propojení s okolním světem o něco více vzdáleno řídicím systémům, most však stále existuje. Pokud útočník integrační host ovládne, přímá cesta do OT sítě mu zůstává otevřená.

Bezpečnost tohoto řešení je přímo závislá na tom, jak důkladně je integrační host konfigurován, aktualizován a monitorován. Pro méně kritické projekty může být tato varianta dostačující, ale jako dlouhodobé řešení pro průmyslový provoz s vysokými bezpečnostními nároky ji nelze doporučit.

Zabezpečené řešení: architektura se staging SQL

Plně zabezpečená architektura vychází podobně jako v předchozím článku z Purdue modelu a principu hloubkové obrany (defense-in-depth).

Síť je rozdělena do tří zón oddělených průmyslovými firewally: OT síť (Purdue L1–L2), IDMZ (Purdue L3.5) a IT síť (Purdue L4).

OT síť
Konfigurace zařízení v OT síti je vlastně totožná s tou, kterou jsme použili v předchozím článku pro data logging. Funkcionalita je rozdělena do dvou aplikací FT Optix, které běží na dvou samostatných Optix Edge zařízeních nebo na jediném s použitím Docker kontejneru. Jedna aplikace ovládá HMI terminály, které jsou odděleny ve zvláštní síti. Druhá FT Optix aplikace pak zajišťuje sběr dat, která jsou potřebná pro údržbu, tedy těch dat, která máme v úmyslu finálně odesílat do Fiix API.

IDMZ a staging SQL server
FT Optix aplikace běžící na Optix Edge v OT síti průběžně zapisuje vybrané tagy do stagingového SQL serveru umístěného v IDMZ. Tento zápis probíhá přes první firewall (ve schématu označený jako Firewall 1), a to jednosměrně – povolený je pouze směr z OT do IDMZ. Komunikace v opačném směru je zakázána.

IT síť
Integrační aplikace FT Optix je umístěna právě zde, v IT síti, tedy za druhým firewallem. Jejím úkolem je načítat periodicky data ze stagingového SQL serveru. Tato komunikace probíhá opět na pull principu – komunikaci iniciuje vždy načítající aplikace, tedy IT síť. Načtená data se ukládají do vnitřních proměnných FT Optix aplikace.

Tato integrační aplikace již plně využívá Optix-Fiix knihovnu. Pomocí jejích objektů zajišťuje přenos dat https protokolem do Fiix API.

Na tomto místě se nabízí úvaha, zda jako integrační aplikaci je nutné použít FT Optix. Nutné to samozřejmě není. Podobnou aplikaci, která bude periodicky načítat data z SQL databáze a rovněž periodicky je odesílat pomocí https requestu do určeného API rozhraní, je možné nakódovat v mnoha programovacích jazycích. FT Optix spolu s Optix-Fiix knihovnou však nabízí možnost vytvořit integrační aplikaci pohodlně v Optix Studiu s využitím předpřipravených objektů zcela bez potřeby jakéhokoliv programování.

Pravidla firewallů

• Firewall 1 oddělující OT síť od IDMZ povoluje jediný datový tok: zápis tagů z Optix Edge na stagingový SQL server (TCP 1433). Veškerá komunikace v opačném směru je blokována.
• Firewall 2 oddělující IDMZ od IT sítě povoluje pouze komunikaci z IT do IDMZ pro čtení dat ze staging databáze. Ostatní provoz je zablokován.
• Perimetr IT sítě povoluje odchozí https komunikaci z integrační aplikace do Fiix API (TCP 443).

Výsledek
Navržená architektura důsledně odděluje OT a IT vrstvy pomocí zóny IDMZ. PLC a HMI systémy v OT síti zapisují data do staging databáze umístěné v IDMZ. Integrační aplikace běžící v IT síti přistupuje k této databázi pouze čtecím způsobem (pull princip) a následně odesílá zpracovaná data do cloudového API systému Fiix prostřednictvím zabezpečené komunikace https (TCP 443). Tímto způsobem je zajištěno, že:

• OT zařízení nejsou nikdy přímo vystavena IT síti ani internetu,
• IDMZ slouží jako bezpečný mezistupeň pro výměnu dat,
• integrační aplikace v IT síti nekomunikuje přímo s PLC zařízeními,
• veškerá komunikace směrem do cloudu probíhá výhradně z IT zóny.