Navrhování aplikací HMI/SCADA s ohledem na kybernetickou bezpečnost – zásady, které snižují riziko už ve fázi návrhu

O bezpečnosti aplikací HMI/SCADA se rozhoduje mnohem dříve než ve fázi volby ochranných mechanismů. To, zda bude systém odolný vůči chybě, zneužití a nekontrolované změně stavu procesu, závisí především na předpokladech přijatých v návrhu: rozdělení rolí, hranicích důvěry, rozsahu funkcí dostupných z rozhraní a způsobu organizace servisu a vzdáleného přístupu. Pokud jsou tyto otázky upozaděny, aplikace začne riziko spíše zakonzervovávat, než omezovat. Proto je třeba navrhování HMI/SCADA s ohledem na kybernetickou bezpečnost vést jako inženýrský úkol: nejprve určit, které operace jsou kritické, jaké mohou mít důsledky a kdo je skutečně smí provádět, a teprve potom vytvářet obrazovky, alarmy a uživatelsky pohodlné ovládání.

Kybernetická bezpečnost začíná v návrhu

V systémech HMI/SCADA není kybernetická bezpečnost doplňkem hotové vizualizace. Vychází z dříve přijatých rozhodnutí: z architektury aplikace, modelu oprávnění, způsobu komunikace s řízením a předpokladů pro servis. To má zvláštní význam, protože aplikace HMI/SCADA je současně styčným bodem člověka, procesu a infrastruktury. Chyba v návrhu proto nekončí jen u IT rizika. Může zároveň ovlivnit reakci operátora, funkční bezpečnost, provozní riziko i kontinuitu výroby.

Z pohledu návrhu tedy základní otázka nezní, jaké zabezpečení přidat na konci, ale která rozhodnutí už na začátku omezí plochu útoku. Největší problémy obvykle nevyplývají z absence jednoho konkrétního mechanismu, ale z nadměrné důvěry zabudované do aplikace. V praxi to znamená společné uživatelské účty, široký a trvalý servisní přístup, chybějící oddělení rolí mezi operátorem, údržbou a integrátorem a příliš volnou komunikaci mezi operátorskou vrstvou a řízením. Ve fázi uvádění do provozu se taková řešení jeví jako pohodlná, protože urychlují práci a usnadňují diagnostiku. Později se však stanou trvalou vlastností prostředí a zvyšují riziko zneužití, chyby nebo nekontrolované změny stavu procesu.

Proto je vhodné ještě před návrhem obrazovek stanovit nejen to, co má uživatel vidět, ale především kde leží hranice důvěry, které operace jsou kritické a ve kterých místech se rozhraní může stát nástrojem chyby nebo obcházení postupu. Takové pořadí zpřehledňuje další rozhodování: zda má být HMI pouze vizualizační vrstvou, nebo také místem pro konfiguraci, diagnostiku a změnu receptur; zda mají servisní funkce fungovat trvale, nebo jen po vědomém spuštění; zda má mít operátor přístup výhradně k obsluze procesu, nebo i k operacím měnícím parametry a historii dat.

Praktické náklady zanedbání se obvykle projeví až tehdy, když je aplikace už provázána s recepturami, alarmy, reportingem, archivací a postupy údržby. Pak i zdánlivě jednoduchá úprava, jako je oddělení účtů, změna postupu schvalování kritické operace nebo omezení vzdáleného přístupu na příležitostný režim, přestává být změnou obrazovek. Vyžaduje přepracování logiky, opětovné otestování obsluhy alarmů, vyjasnění odpovědností a často také organizační změny v závodě.

V praxi je nejrozumnějším výchozím bodem pracovní mapa uživatelských rolí a jejich oprávnění ke kritickým operacím, seznam funkcí způsobujících změnu stavu procesu, konfigurace nebo receptur a přehled externích spojení zahrnující servis, reporting, nadřazené systémy a vzdálený přístup. Teprve na tomto základě lze smysluplně navrhnout architekturu zón a spojení a připravit následnou analýzu rizik. Takový přístup odpovídá jak inženýrské praxi, tak požadavkům na jasné uspořádání odpovědností, oddělení funkcí a kontrolu komunikace v průmyslovém prostředí.

Kde skutečně rostou náklady a riziko

Největší náklady a riziko v aplikaci HMI/SCADA nevyplývají pouze ze samotného propojení systémů, ale z toho, jaké procesní a organizační důsledky vyvolávají jednotlivé funkce aplikace. Nejcitlivější jsou ta místa, která umožňují rychle změnit nastavení, zavést obejití, umlčet alarm, změnit recepturu nebo provést ruční řízení bez plného technologického kontextu. Pokud návrh připouští takové operace z výrobní obrazovky v rutinním režimu, riziko roste proto, že jediné rozhodnutí uživatele nebo jediné převzaté sezení může přímo změnit stav procesu.

To znamená, že katalog kritických operací je nutné chápat jako součást bezpečnostní architektury, nikoli jen jako otázku ergonomie rozhraní. Stejný princip platí i pro dohledatelnost a odpovědnost za provedené úkony. Sdílená přihlášení, účty používané celou směnou, chybějící oddělení oprávnění pro čtení, ovládání, konfiguraci a administraci a nedostatečné zaznamenávání událostí způsobují, že po incidentu je obtížné spolehlivě určit, zda šlo o omyl, obcházení postupu, zneužití servisního přístupu nebo neoprávněný zásah. Problém se netýká jen samotného zjišťování příčin. Bez věrohodné stopy uživatelských činností nelze ani vyhodnotit účinnost postupů, smysluplně spravovat oprávnění nebo obhájit provozní rozhodnutí při interním auditu, vůči požadavkům zákazníka či přijatým bezpečnostním politikám. V praxi jde o odpovědnost za provedené úkony a trasovatelnost, nikoli pouze o samotný záznam událostí.

Velmi nákladnou projekční chybou je také přenášení rozsáhlých servisních a diagnostických obrazovek do produkčního prostředí, pokud byly původně připraveny pro uvádění do provozu nebo podporu integrátora. Taková zobrazení často poskytují široký přístup k interním proměnným, vynucování stavů, rušení blokací a úpravám parametrů, přestože při běžném provozu jsou potřebná nanejvýš výjimečně. Pokud na ně nejsou uplatněna další omezení, stávají se nejkratší cestou k zásahu do procesu mimo standardní operátorskou cestu. Rozumné řešení spočívá v oddělení diagnostiky potřebné pro údržbu od funkcí umožňujících zasahovat do logiky činnosti a také v samostatném rozhodnutí, zda má být diagnostika výrobce stroje dostupná lokálně, vzdáleně, nebo jen podmíněně, po vědomém spuštění a s úplným záznamem relace.

Stejně je třeba přistupovat i k integraci s databázemi, reportingem, vzdálenou podporou a kancelářskými systémy. Každé takové propojení zvyšuje komfort práce, ale současně rozšiřuje počet závislostí, které se mohou stát vstupní cestou, zdrojem poruch nebo příčinou ztráty přehledné odpovědnosti. Výpadek zprostředkující služby, chybná synchronizace času, nekontrolovaná výměna dat s nadřazeným systémem nebo ponechaný servisní kanál mohou ovlivnit nejen dostupnost reportů, ale i rozhodnutí přijímaná operátorem.

Proto se vyplatí už ve fázi návrhu měřit nejen dostupnost obrazovek, ale i jednodušší a užitečnější ukazatele: počet kritických operací dostupných z produkčního HMI, počet aktivních externích spojení, počet privilegovaných účtů a rozsah událostí zahrnutých do auditní stopy. Takový přehled následně usnadňuje zaznamenávání událostí, kontrolu změn parametrů i pravidla vzdáleného přístupu.

Samostatnou pozornost vyžaduje alarmování. V této oblasti zdánlivá úplnost často zakrývá skutečný nedostatek kontroly. Špatně navržené alarmy a historie událostí operátora nejen přetěžují, ale zároveň mu berou schopnost rozlišit kritické signály od technického šumu. Pokud lze alarm snadno umlčet bez zdůvodnění, potvrdit bez vazby na příčinu nebo ztratit v množství diagnostických hlášení, aplikace přestává podporovat bezpečnost procesu. Proto by priority alarmů měly vycházet ze skutečných dopadů na lidi, stroj a kvalitu výroby a zároveň zůstat provázané s pravidly zaznamenávání potvrzení, obejití a změn nastavení. Právě v tomto okamžiku přestává být analýza rizik a ověření bezpečnosti průmyslového prostředí jen formálním dokumentem a začíná utvářet rozhraní.

Jak navrhovat tak, aby se omezily důsledky chyby a zneužití

Výchozí princip je jednoduchý: aplikace HMI/SCADA nesmí předpokládat, že každý uživatel jedná vždy správně a ve správném kontextu procesu. Návrh je třeba začít oddělením funkcí, ne kreslením obrazovek. Tým by si měl nejprve ujasnit, co má operátor pouze vidět, co může potvrdit, co smí měnit v běžném průběhu práce a které činnosti je nutné přesunout do servisního režimu, podmínit je dodatečnou autorizací nebo je zcela vyčlenit do samostatného nástroje či stanice.

Takové rozhodnutí uspořádá celou architekturu přístupu: role, rozsah oprávnění, způsob zaznamenávání činností i podmínky vzdálené podpory. V praxi se osvědčuje matice rolí založená na skutečných povinnostech, která rozlišuje operátora, vedoucího směny, údržbu, technologa, integrátora a administrátora. Nejde o formalitu. Pokud servisní funkce zůstávají na stejné obrazovce a pod stejným účtem jako obsluha procesu, aplikace sama vytváří cestu k omylu, obcházení postupu nebo zneužití oprávnění.

Kvalitní HMI/SCADA omezuje možnost nebezpečnou operaci provést omylem, ale zároveň zbytečně nezpomaluje rutinní činnosti. To vyžaduje přehledný pracovní kontext: uživatel musí vidět, na jakém objektu pracuje, v jakém stavu je proces, zda pracuje lokálně nebo vzdáleně a zda je systém v automatickém, ručním nebo servisním režimu. Potvrzení musí odpovídat míře rizika, nikoli být stejná pro všechny činnosti. Tam, kde je důsledek chyby vratný a omezený, obvykle postačí jednorázová autorizace. Kritické operace vyžadují dodatečnou kontrolu: druhé potvrzení, opětovné ověření identity, návaznost na stav procesu nebo fyzický přechod do odděleného rozhraní.

Důležité jsou také podmíněné blokace. Pokud aplikace umožňuje změnu nastavení, vynucení signálu nebo přechod do ručního režimu bez ohledu na stav objektu, přenáší se riziko z návrhu na obsluhu. Právě zde je vidět, že správný návrh rozhraní nespočívá jen v pohodlném ovládání, ale i v omezování následků chyb pomocí vestavěných bariér. V mnoha případech je tento způsob uvažování blízký tomu, jak funguje Poka-Yoke ve výrobních linkách.

Vrstvený návrh přístupu by měl zahrnovat také způsob používání oprávnění v čase. Individuální účty jsou nezbytné všude tam, kde se očekává dohledatelnost činností. Sdílený účet znemožňuje určit, kdo rozhodnutí skutečně provedl. Minimální rozsah oprávnění znamená, že uživatel dostane pouze ty funkce, které potřebuje pro svou aktuální práci, a zvýšení oprávnění probíhá jen dočasně a za kontrolovaných podmínek. Týká se to zejména údržby, integrátora a vzdálené podpory výrobce. Trvale otevřená servisní cesta je pohodlná jen zdánlivě, protože ruší přirozenou hranici důvěry mezi provozem a servisem. Bezpečnější model představuje přístup spouštěný na vyžádání, časově omezený, přiřazený konkrétní osobě a zaznamenaný v historii událostí. Tento přístup dobře odpovídá zásadě minimálních oprávnění a segmentaci přístupu.

Ve stejném duchu je třeba rozhodnout, zda mají být servisní funkce dostupné z pracovního HMI, nebo výhradně ze samostatné stanice, a zda povolit výměnná média a lokální import či export dat z operátorského panelu. Tato rozhodnutí nejsou okrajová. Právě na nich závisí, zda bude údržba systému probíhat řízeným způsobem, nebo prostřednictvím improvizovaných obcházek.

Z pohledu incidentu nebo provozního sporu samotné rozhraní nestačí. Aplikace musí zanechat podklady, které umožní zpětně rekonstruovat průběh rozhodování. Historie událostí, systémové protokoly a záznam změn by společně měly odpovídat nejen na otázku, co se stalo, ale také kdo, kdy, odkud a v jakém stavu procesu operaci provedl. Minimální rozsah událostí, které se obvykle vyplatí zaznamenávat, zahrnuje přihlášení, změnu oprávnění, změnu parametrů, přechod do ručního režimu, potvrzení alarmu a import konfigurace. Klíčové je propojit záznam s technologickým kontextem, protože samotná informace o změně bez stavu objektu bývá nepoužitelná.

Dobrým příkladem, typickým pro mnoho implementací, je změna prahu alarmu technologem: může být přípustná, ale pouze po přechodu do určeného režimu, se zaznamenáním uživatele, stanice, času, předchozí a nové hodnoty a s potvrzením, že objekt nebyl v kritickém stavu. Taková stopa má význam jak pro bezpečnost, tak pro řízení změn v průmyslových aplikacích.

Poslední vrstvou je udržovatelnost bez obcházení zabezpečení. Pokud aktualizace, obnova konfigurace nebo diagnostika vyžadují vypnutí řízení přístupu, použití sdíleného hesla nebo práci bez auditní stopy, problém je v návrhu, nikoli v disciplíně personálu. Aplikace by měla mít předem stanovený průběh změny: požadavek, posouzení dopadu, test, nasazení, potvrzení a plán návratu. Měla by také oddělovat provozní a servisní prostředí alespoň logicky a tam, kde je to odůvodněné, i organizačně a technicky. Zálohy konfigurace musí být možné vytvářet a obnovovat řízeným způsobem, bez operativního exportu „pro jistotu“ z panelu. Takový přístup je v souladu se zásadou minimálních oprávnění v OT i s požadavky na řízení přístupu, dohledatelnost činností a řízení změn, přičemž jejich rozsah je vždy nutné vztáhnout k architektuře systému a přijatému rozdělení odpovědností.

Praxe implementace a vztah k požadavkům

Největší přínos nepřináší doplňování dalších ochranných mechanismů na konci projektu, ale systematická revize aplikace před přejímkou nebo modernizací. To je okamžik, kdy lze ještě poměrně levně upravit způsob fungování systému, místo aby se později chybné předpoklady obestavovaly dalšími postupy. Takovou revizi by měl provádět smíšený tým: projekt, údržba, provoz, automatizační technik a osoby odpovědné za bezpečnost.

Předmětem posouzení není jen technická konfigurace, ale i to, zda aplikace skutečně odděluje role, chrání kritické operace, omezuje vzdálený přístup na odůvodněné případy, zajišťuje přehlednou obsluhu alarmů, uchovává historii změn a umožňuje provádět zálohy i havarijní postupy bez obcházení zabezpečení. Právě z takové revize by měl vzejít seznam pro FAT/SAT a také požadavky zapisované do přejímky, servisního plánu a dokumentace skutečného provedení.

Tento přístup přesouvá těžiště z debat o samotných ochranných opatřeních na projektová rozhodnutí, která následně určují chování lidí i zařízení. Pokud už ve fázi návrhu není stanoveno, kdo může měnit parametry receptur, kdo schvaluje servisní režim, jak se zaznamenává zásah integrátora a za jakých podmínek je přípustný přístup mimo závod, bude se systém po spuštění opírat o výjimky a ústní dohody.

Ze stejného důvodu je vhodné rozhodnout, zda posouzení aplikace provádět v rámci modernizace stroje nebo linky, nebo jako samostatný přezkum OT. První přístup lépe propojuje bezpečnost s funkcí procesu, druhý usnadňuje zachytit vazby mezi systémy a rozdělení odpovědnosti za účty, oprávnění a zaznamenávání činností. Je to také přirozené místo pro předběžnou analýzu rizik: identifikaci kritických operací, hranic důvěry a důsledků chyby obsluhy nebo zneužití. V praxi zde bývá užitečná také analýza rizik v projektu.

• role uživatelů a způsob jejich přihlašování,
• kritické operace a pravidla jejich potvrzování,
• vzdálený přístup a servisní funkce,
• alarmy, zaznamenávání změn a dohledatelnost činností,
• zálohy, obnova a havarijní postupy.

Dobrý výsledek v závodě jen zřídka vyplývá ze současného nasazení mnoha nástrojů. Obvykle má větší význam odstranění několika systémových rizik, která byla po léta považována za praktická. Modernizace aplikace HMI/SCADA může začít zrušením sdílených účtů, oddělením servisních funkcí od operátorských, omezením externích připojení na řízené cesty a zavedením stopy změn parametrů s přiřazením ke konkrétní osobě nebo roli. Taková změna nemusí zhoršit práci údržby ani integrátora, pokud byl od začátku předpokládán servisní režim, pravidla autorizace a reprodukovatelný průběh úprav.

V provozu má pak smysl sledovat ne abstraktní úroveň bezpečnosti, ale provozně užitečné ukazatele: počet sdílených účtů, které v systému stále zůstávají, rozsah aktivního vzdáleného přístupu, úplnost záznamů změn, dobu obnovy konfigurace a počet zásahů provedených mimo formální postup. Takové ukazatele umožňují posoudit, zda projekt skutečně omezil riziko, nebo je pouze přesunul do každodenní praxe.

V českém i unijním prostředí je stále obtížnější obhájit přístup, v němž je kybernetická bezpečnost HMI/SCADA výhradní záležitostí oddělení IT. Odpovědnost je rozložena mezi projekt, provoz, údržbu, dodavatele a integrátory a oborové i smluvní požadavky mají význam teprve tehdy, když organizace dokáže doložit konkrétní skutečnosti: jaká projektová rozhodnutí byla přijata, jak se přidělují oprávnění, jaká je stopa činností a kdo řídí změny. Samotné odkazy na normy, politiky nebo smluvní ustanovení nenahradí důkaz, že aplikace byla navržena a převzata způsobem umožňujícím bezpečný provoz.

Nejdůležitější závěr je praktický. Nejlevnějším a nejúčinnějším okamžikem pro omezování rizika zůstává návrh a přejímka aplikace. Právě tehdy lze s nejnižšími náklady stanovit hranice důvěry, role, podmínky přístupu, stopu činností a způsob řízení změn. Pokud budou tyto požadavky převedeny do ověřitelných kritérií vůči dodavateli a integrátorovi, přestane být HMI/SCADA pohodlným, ale příliš důvěřivým rozhraním a stane se nástrojem bezpečného provozu procesu.