Navrhovanie aplikácií HMI/SCADA s dôrazom na kybernetickú bezpečnosť – zásady, ktoré znižujú riziko už vo fáze návrhu

O bezpečnosti aplikácie HMI/SCADA sa rozhoduje výrazne skôr než vo fáze výberu ochranných mechanizmov. To, či bude systém odolný voči omylu, zneužitiu a nekontrolovanej zmene stavu procesu, závisí predovšetkým od predpokladov prijatých v návrhu: od rozdelenia rolí, hraníc dôvery, rozsahu funkcií dostupných cez rozhranie a od spôsobu organizácie servisu a vzdialeného prístupu. Ak sa tieto otázky odsúvajú na vedľajšiu koľaj, aplikácia začne riziko skôr upevňovať, než ho obmedzovať. Preto treba HMI/SCADA navrhovať s ohľadom na kybernetickú bezpečnosť ako inžiniersku úlohu: najprv určiť, ktoré operácie sú kritické, aké môžu mať dôsledky a kto má byť skutočne oprávnený ich vykonať, a až potom vytvárať obrazovky, alarmy a komfort obsluhy.

Kybernetická bezpečnosť sa začína v návrhu

V systémoch HMI/SCADA nie je kybernetická bezpečnosť doplnkom k hotovej vizualizácii. Vyplýva z rozhodnutí prijatých skôr: z architektúry aplikácie, modelu oprávnení, spôsobu komunikácie s riadením a z predpokladov pre servis. Má to osobitný význam, pretože aplikácia HMI/SCADA je zároveň styčným bodom človeka, procesu a infraštruktúry. Chyba v návrhu sa preto nekončí pri IT riziku. Môže súčasne ovplyvniť priebeh reakcie operátora, funkčnú bezpečnosť, prevádzkové riziko a kontinuitu výroby.

Z pohľadu návrhu teda základná otázka neznie, aké zabezpečenie doplniť na konci, ale ktoré rozhodnutia už na začiatku obmedzia plochu útoku. Najväčšie problémy zvyčajne nevyplývajú z absencie jedného konkrétneho mechanizmu, ale z nadmernej dôvery zabudovanej do aplikácie. V praxi to znamená spoločné používateľské účty, široký a trvalý servisný prístup, chýbajúce oddelenie rolí medzi operátorom, údržbou a integrátorom a príliš voľnú komunikáciu medzi operátorskou vrstvou a riadením. Vo fáze uvádzania do prevádzky sa takéto riešenia javia ako pohodlné, pretože urýchľujú práce a uľahčujú diagnostiku. Neskôr sa však stanú trvalou vlastnosťou prostredia a zvyšujú riziko zneužitia, omylu alebo nekontrolovanej zmeny stavu procesu.

Preto sa pred návrhom obrazoviek oplatí určiť nielen to, čo má používateľ vidieť, ale predovšetkým kde sú hranice dôvery, ktoré operácie sú kritické a na ktorých miestach sa rozhranie môže stať nástrojom chyby alebo obídenia postupu. Takéto poradie vnáša poriadok do ďalších rozhodnutí: či má byť HMI iba vizualizačnou vrstvou, alebo aj miestom konfigurácie, diagnostiky a zmeny receptúr; či majú servisné funkcie fungovať trvalo, alebo len po vedomej aktivácii; či má mať operátor prístup výlučne k obsluhe procesu, alebo aj k operáciám meniacim parametre a históriu údajov.

Praktické náklady zanedbaní sa zvyčajne prejavia až vtedy, keď je aplikácia už prepojená s receptúrami, alarmami, reportovaním, archiváciou a postupmi údržby. Vtedy aj zdanlivo jednoduchá úprava, ako je oddelenie účtov, zmena postupu schvaľovania kritickej operácie alebo obmedzenie vzdialeného prístupu na príležitostný režim, prestáva byť len zmenou na obrazovkách. Vyžaduje si prepracovanie logiky, opätovné otestovanie obsluhy alarmov, určenie zodpovedností a často aj organizačné zmeny v závode.

V praxi je najrozumnejším východiskom pracovná mapa používateľských rolí a ich oprávnení ku kritickým operáciám, zoznam funkcií spôsobujúcich zmenu stavu procesu, konfigurácie alebo receptúr a prehľad externých pripojení zahŕňajúci servis, reportovanie, nadradené systémy a vzdialený prístup. Až na tomto základe možno zmysluplne navrhovať architektúru zón a prepojení a pripraviť následnú analýzu rizika. Takýto prístup zodpovedá inžinierskej praxi aj požiadavkám na usporiadanie zodpovedností, oddelenie funkcií a kontrolu komunikácie v priemyselných prostrediach.

Kde v skutočnosti rastú náklady a riziko

Najväčšie náklady a riziko v aplikácii HMI/SCADA nevyplývajú len zo samotného prepojenia systémov, ale z toho, aké procesné a organizačné dôsledky vyvolávajú jednotlivé funkcie aplikácie. Najcitlivejšie sú tie miesta, ktoré umožňujú rýchlo zmeniť nastavenia, zaviesť obídenie, stlmiť alarm, zmeniť receptúru alebo vykonať ručné riadenie bez úplného technologického kontextu. Ak návrh pripúšťa takéto operácie z úrovne výrobnej obrazovky v rutinnom režime, riziko rastie preto, že jedno rozhodnutie používateľa alebo jedno prevzatie relácie môže priamo zmeniť stav procesu.

To znamená, že katalóg kritických operácií treba vnímať ako súčasť bezpečnostnej architektúry, nielen ako otázku ergonómie rozhrania. Rovnaký princíp platí aj pre vyvoditeľnosť zodpovednosti za vykonané úkony. Spoločné prihlasovacie údaje, účty zdieľané v rámci zmeny, chýbajúce oddelenie oprávnení na čítanie, riadenie, konfiguráciu a administráciu, ako aj nedostatočné zaznamenávanie udalostí spôsobujú, že po incidente je ťažké spoľahlivo určiť, či išlo o omyl, obídenie postupu, zneužitie servisného prístupu alebo neoprávnený zásah. Problém sa netýka iba samotného zisťovania príčin. Bez dôveryhodnej stopy používateľských činností sa nedá ani vyhodnotiť účinnosť postupov, rozumne spravovať oprávnenia či obhájiť prevádzkové rozhodnutia pri internom audite, voči požiadavkám zákazníka alebo prijatým bezpečnostným politikám. V praxi tu ide o vyvoditeľnosť zodpovednosti za činnosti a trasovateľnosť, nielen o samotný záznam udalostí.

Veľmi nákladnou projektovou chybou je aj prenášanie rozsiahlych servisných a diagnostických obrazoviek do výrobného prostredia, ak boli pôvodne pripravené na účely uvádzania do prevádzky alebo podpory integrátora. Takéto zobrazenia často poskytujú široký prístup k interným premenným, vynucovaniu stavov, rušeniu blokovaní a úpravám parametrov, hoci pri bežnej prevádzke sú potrebné nanajvýš výnimočne. Ak na ne nie sú uplatnené dodatočné obmedzenia, stávajú sa najkratšou cestou k zásahu do procesu mimo štandardnej operátorskej cesty. Rozumné riešenie spočíva v oddelení diagnostiky potrebnej pre údržbu od funkcií, ktoré umožňujú zasahovať do logiky činnosti, a tiež v samostatnom rozhodnutí, či má byť diagnostika výrobcu stroja dostupná lokálne, vzdialene alebo len podmienečne, po vedomej aktivácii a s úplným záznamom relácie.

Rovnako treba pristupovať aj k integrácii s databázami, reportingom, vzdialenou podporou a kancelárskymi systémami. Každé takéto prepojenie zvyšuje komfort práce, no zároveň rozširuje počet závislostí, ktoré sa môžu stať vstupnou cestou, zdrojom porúch alebo príčinou straty prehľadnosti zodpovednosti. Výpadok sprostredkujúcej služby, chybná synchronizácia času, nekontrolovaná výmena dát s nadradeným systémom alebo ponechaný servisný kanál môžu ovplyvniť nielen dostupnosť reportov, ale aj rozhodnutia prijímané operátorom.

Preto sa už pri návrhu oplatí sledovať nielen dostupnosť obrazoviek, ale aj jednoduchšie a praktickejšie ukazovatele: počet kritických operácií dostupných z výrobného HMI, počet aktívnych externých spojení, počet privilegovaných účtov a rozsah udalostí zahrnutých do auditnej stopy. Takýto prehľad následne prináša poriadok do zaznamenávania udalostí, kontroly zmien parametrov a pravidiel vzdialeného prístupu.

Osobitný prístup si vyžaduje alarmovanie. V tejto oblasti zdanlivá úplnosť často zakrýva skutočný nedostatok kontroly. Zle navrhnuté alarmy a história udalostí operátora nielen preťažujú, ale zároveň mu berú schopnosť rozlíšiť kritické signály od technického šumu. Ak sa alarm dá ľahko stlmiť bez odôvodnenia, potvrdiť bez väzby na príčinu alebo sa stratí v množstve diagnostických hlásení, aplikácia prestáva podporovať bezpečnosť procesu. Preto by priority alarmov mali vychádzať zo skutočných dôsledkov pre ľudí, stroj a kvalitu výroby a zároveň zostať prepojené s pravidlami zaznamenávania potvrdení, obídení a zmien nastavení. Práve v tomto momente prestáva byť analýza rizík formálnym dokumentom a začína formovať rozhranie.

Ako navrhovať tak, aby sa obmedzili dôsledky chyby a zneužitia

Východisko je jednoduché: aplikácia HMI/SCADA nemôže vychádzať z predpokladu, že každý používateľ vždy koná správne a v správnom kontexte procesu. Návrh treba začať oddelením funkcií, nie kreslením obrazoviek. Tím by si mal najprv určiť, čo má operátor iba vidieť, čo môže potvrdiť, čo smie meniť v bežnom priebehu práce a ktoré činnosti treba presunúť do servisného režimu, podmieniť dodatočnou autorizáciou alebo úplne vyčleniť do samostatného nástroja či stanice.

Takéto rozhodnutie usporadúva celú architektúru prístupu: roly, rozsah oprávnení, spôsob zaznamenávania činností aj podmienky vzdialenej podpory. V praxi dobre funguje matica rolí založená na skutočných povinnostiach, ktorá rozlišuje operátora, majstra, údržbu, technológa, integrátora a administrátora. Nie je to formalita. Ak servisné funkcie zostávajú na tej istej obrazovke a pod tým istým účtom ako obsluha procesu, aplikácia sama vytvára cestu k omylu, obídeniu postupu alebo zneužitiu oprávnení.

Dobre navrhnuté HMI/SCADA obmedzuje možnosť náhodného vykonania nebezpečnej operácie, no zároveň zbytočne nespomaľuje rutinné činnosti. Vyžaduje si to jasný pracovný kontext: používateľ musí vidieť, na akom objekte pracuje, v akom stave je proces, či pracuje lokálne alebo vzdialene a či je systém v automatickom, ručnom alebo servisnom režime. Potvrdenia musia zodpovedať miere rizika, nie byť rovnaké pre všetky činnosti. Tam, kde je dôsledok chyby vratný a obmedzený, zvyčajne postačuje jedno potvrdenie. Kritické operácie si vyžadujú dodatočnú kontrolu: druhé potvrdenie, opätovné overenie totožnosti, väzbu na stav procesu alebo fyzický prechod do oddeleného rozhrania.

Dôležité sú aj podmienené blokovania. Ak aplikácia umožňuje zmenu nastavenia, vynútenie signálu alebo prepnutie do ručného režimu bez ohľadu na stav objektu, riziko sa prenáša z návrhu na operátora. Práve tu je vidieť, že správny návrh rozhrania nespočíva iba v pohodlí obsluhy, ale aj v obmedzovaní dôsledkov chyby pomocou zabudovaných bariér. V mnohých prípadoch je takýto spôsob uvažovania blízky tomu, ako funguje Poka-Yoke vo výrobných linkách.

Vrstvený návrh prístupu by mal zahŕňať aj spôsob používania oprávnení v čase. Individuálne účty sú nevyhnutné všade tam, kde sa vyžaduje identifikovateľnosť činností. Spoločný účet znemožňuje určiť, kto rozhodnutie skutočne prijal. Minimálny rozsah oprávnení znamená, že používateľ dostane iba tie funkcie, ktoré potrebuje na svoju aktuálnu prácu, a zvýšenie oprávnení prebieha len dočasne a za kontrolovaných podmienok. Týka sa to najmä údržby, integrátora a vzdialenej podpory výrobcu. Trvalo otvorená servisná cesta je pohodlná iba zdanlivo, pretože ruší prirodzenú hranicu dôvery medzi prevádzkou a servisom. Bezpečnejší model predstavuje prístup aktivovaný na požiadanie, časovo obmedzený, priradený ku konkrétnej osobe a zaznamenaný v histórii udalostí. Tento prístup dobre zodpovedá zásade minimálnych oprávnení a segmentácii prístupu.

V rovnakom duchu treba rozhodnúť, či majú byť servisné funkcie dostupné z pracovného HMI, alebo výlučne zo samostatnej stanice, a či povoliť vymeniteľné médiá a lokálny import alebo export údajov z operátorského panela. Tieto rozhodnutia nie sú vedľajšie. Práve od nich závisí, či bude udržiavateľnosť systému zabezpečená riadeným spôsobom, alebo prostredníctvom improvizovaných obchádzok.

Z pohľadu incidentu alebo prevádzkového sporu samotné rozhranie nestačí. Aplikácia musí zanechať podklady, ktoré umožnia zrekonštruovať priebeh rozhodovania. História udalostí, systémové denníky a zaznamenávanie zmien by mali spoločne odpovedať nielen na otázku, čo sa stalo, ale aj kto, kedy, z akého miesta a v akom stave procesu vykonal danú operáciu. Minimálny rozsah udalostí, ktoré sa zvyčajne oplatí zaznamenávať, zahŕňa prihlásenie, zmenu oprávnení, zmenu parametrov, prepnutie do ručného režimu, potvrdenie alarmu a import konfigurácie. Kľúčové je prepojenie záznamu s technologickým kontextom, pretože samotná informácia o zmene bez stavu objektu býva nepoužiteľná.

Dobrým príkladom je situácia typická pre mnohé implementácie: zmena prahu alarmu zo strany technológa môže byť prípustná, ale iba po vstupe do predpokladaného režimu, so zaznamenaním používateľa, stanice, času, predchádzajúcej a novej hodnoty a s potvrdením, že objekt nebol v kritickom stave. Takáto stopa má význam tak pre bezpečnosť, ako aj pre riadenie zmien v priemyselných aplikáciách.

Poslednou vrstvou je udržiavateľnosť bez obchádzania zabezpečení. Ak aktualizácia, obnova konfigurácie alebo diagnostika vyžadujú vypnutie kontroly prístupu, použitie spoločného hesla alebo prácu bez auditnej stopy, problém je v návrhu, nie v disciplíne personálu. Aplikácia by mala mať definovaný priebeh zmeny: žiadosť, posúdenie vplyvu, test, nasadenie, potvrdenie a plán návratu. Mala by tiež oddeľovať pracovné prostredie od servisného aspoň logicky a tam, kde je to opodstatnené, aj organizačne a technicky. Zálohy konfigurácie musia byť vyhotoviteľné a obnoviteľné kontrolovaným spôsobom, bez operatívneho exportu „pre istotu“ z panela. Takýto prístup je v súlade so zásadou najmenších oprávnení v OT aj s požiadavkami na kontrolu prístupu, identifikovateľnosť činností a riadenie zmien, pričom ich rozsah treba vždy vzťahovať na architektúru systému a prijaté rozdelenie zodpovedností.

Prax implementácie a vzťah k požiadavkám

Najväčší prínos neprináša dopĺňanie ďalších ochranných mechanizmov na konci projektu, ale systematické preskúmanie aplikácie pred prevzatím alebo modernizáciou. To je chvíľa, keď sa ešte dá pomerne lacno upraviť spôsob fungovania systému, namiesto toho, aby sa neskôr chybné východiská obostavali ďalšími postupmi. Takéto preskúmanie by mal vykonávať zmiešaný tím: projekt, údržba, prevádzka, automatizér a osoby zodpovedné za bezpečnosť.

Predmetom posúdenia nie je iba technická konfigurácia, ale aj to, či aplikácia skutočne oddeľuje roly, chráni kritické operácie, obmedzuje vzdialený prístup na odôvodnené prípady, zabezpečuje prehľadnú obsluhu alarmov, uchováva históriu zmien a umožňuje vykonávať zálohy a havarijné postupy bez obchádzania zabezpečení. Práve z takéhoto preskúmania by mal vyplynúť zoznam pre FAT/SAT a tiež požiadavky zapisované do prevzatia, servisného plánu a dokumentácie skutočného vyhotovenia.

Tento prístup presúva ťažisko z diskusie o samotných ochranných opatreniach na projektové rozhodnutia, ktoré následne určujú správanie ľudí aj zariadení. Ak sa už vo fáze návrhu neurčí, kto môže meniť parametre receptúr, kto schvaľuje servisný režim, ako sa zaznamenáva zásah integrátora a za akých podmienok je prípustný prístup mimo závodu, systém sa po uvedení do prevádzky bude opierať o výnimky a ústne dohody.

Z rovnakého dôvodu sa oplatí rozhodnúť, či hodnotenie aplikácie vykonať v rámci modernizácie stroja alebo linky, alebo ako samostatné preskúmanie OT. Prvý prístup lepšie prepája bezpečnosť s funkciou procesu, druhý uľahčuje zachytiť väzby medzi systémami a rozdelenie zodpovednosti za účty, oprávnenia a zaznamenávanie činností. Je to aj prirodzené miesto na predbežnú analýzu rizika: identifikáciu kritických operácií, hraníc dôvery a dôsledkov chyby operátora alebo zneužitia. V praxi tu býva užitočná aj analýza rizík v projekte.

• roly používateľov a spôsob ich prihlasovania,
• kritické operácie a pravidlá ich potvrdzovania,
• vzdialený prístup a servisné funkcie,
• alarmy, zaznamenávanie zmien a dohľadateľnosť činností,
• zálohy, obnova a havarijné postupy.

Dobrý výsledok v závode len zriedka vyplýva zo súčasného nasadenia mnohých nástrojov. Zvyčajne má väčší význam odstránenie niekoľkých systémových rizík, ktoré sa roky považovali za praktické riešenie. Modernizácia aplikácie HMI/SCADA sa môže začať zrušením spoločných účtov, oddelením servisných funkcií od operátorských, obmedzením externých pripojení na kontrolované cesty a spustením záznamu zmien parametrov s priradením ku konkrétnej osobe alebo roli. Takáto zmena nemusí zhoršiť prácu údržby ani integrátora, ak sa od začiatku počítalo so servisným režimom, pravidlami autorizácie a reprodukovateľným priebehom úprav.

Počas prevádzky sa potom oplatí sledovať nie abstraktnú úroveň bezpečnosti, ale prevádzkovo užitočné ukazovatele: počet spoločných účtov, ktoré v systéme ešte zostali, rozsah aktívneho vzdialeného prístupu, úplnosť záznamov o zmenách, čas obnovy konfigurácie a počet zásahov vykonaných mimo formálneho postupu. Takéto ukazovatele umožňujú posúdiť, či projekt skutočne znížil riziko, alebo ho iba presunul do každodennej praxe.

V slovenských aj únijných podmienkach je čoraz ťažšie obhájiť prístup, podľa ktorého je kybernetická bezpečnosť HMI/SCADA výlučne záležitosťou oddelenia IT. Zodpovednosť je rozdelená medzi projekt, prevádzku, údržbu, dodávateľov a integrátorov a odvetvové aj zmluvné požiadavky nadobúdajú význam až vtedy, keď organizácia dokáže preukázať konkrétne skutočnosti: aké projektové rozhodnutia boli prijaté, ako sa prideľujú oprávnenia, aká je stopa vykonaných činností a kto riadi zmeny. Samotné odkazy na normy, politiky alebo zmluvné ustanovenia nenahradia dôkaz, že aplikácia bola navrhnutá a prevzatá spôsobom, ktorý umožňuje bezpečnú prevádzku.

Najdôležitejší záver je praktický. Najlacnejším a najúčinnejším momentom na znižovanie rizika zostáva návrh a prevzatie aplikácie. Práve vtedy sa s najnižšími nákladmi určujú hranice dôvery, roly, podmienky prístupu, stopa činností a spôsob riadenia zmien. Ak sa tieto požiadavky premietnu do overiteľných kritérií voči dodávateľovi a integrátorovi, HMI/SCADA prestáva byť pohodlným, ale príliš dôverčivým rozhraním a stáva sa nástrojom bezpečnej prevádzky procesu.