Projektiranje HMI/SCADA aplikacija s naglaskom na kibersigurnost – načela koja smanjuju rizik već u fazi projektiranja

O sigurnosti HMI/SCADA aplikacije odlučuje se mnogo ranije nego u fazi odabira zaštitnih mehanizama. Hoće li sustav biti otporan na pogrešku, zlouporabu i nekontroliranu promjenu stanja procesa, prije svega ovisi o pretpostavkama usvojenima u projektu: podjeli uloga, granicama povjerenja, opsegu funkcija dostupnih putem sučelja te načinu organizacije servisa i udaljenog pristupa. Ako se tim pitanjima pristupi kao sporednima, aplikacija će početi učvršćivati rizik umjesto da ga smanjuje. Zato projektiranje HMI/SCADA sustava s aspekta kibernetičke sigurnosti treba voditi kao inženjerski zadatak: najprije utvrditi koje su operacije kritične, kakve posljedice mogu imati i tko ih doista smije izvršavati, a tek potom oblikovati ekrane, alarme i jednostavnost rukovanja.

Cyber sigurnost počinje u projektu

U HMI/SCADA sustavima cyber sigurnost nije dodatak gotovoj vizualizaciji. Ona proizlazi iz ranije donesenih odluka: iz arhitekture aplikacije, modela ovlasti, načina komunikacije s upravljanjem i pretpostavki za servis. To je osobito važno zato što je HMI/SCADA aplikacija istodobno dodirna točka čovjeka, procesa i infrastrukture. Projektna pogreška zato se ne svodi samo na informatički rizik. Ona može istodobno utjecati na tijek reakcije operatera, funkcionalnu sigurnost, operativni rizik i kontinuitet proizvodnje.

Iz projektne perspektive temeljno pitanje zato nije koju zaštitu dodati na kraju, nego koje će odluke već na početku ograničiti površinu napada. Najveći problemi obično ne proizlaze iz izostanka pojedinog mehanizma, nego iz pretjeranog povjerenja ugrađenog u samu aplikaciju. U praksi to znači zajedničke korisničke račune, širok i stalan servisni pristup, izostanak razdvajanja uloga između operatera, održavanja i integratora te previše slobodnu komunikaciju između operaterskog sloja i upravljanja. U fazi puštanja u rad takva rješenja djeluju praktično jer ubrzavaju radove i olakšavaju dijagnostiku. Kasnije postaju trajna značajka okruženja i povećavaju rizik od zlouporabe, pogreške ili nekontrolirane promjene stanja procesa.

Zato je prije projektiranja ekrana vrijedno utvrditi ne samo što korisnik treba vidjeti, nego prije svega gdje prolaze granice povjerenja, koje su operacije kritične i na kojim mjestima sučelje može postati alat pogreške ili zaobilaženja procedure. Takav redoslijed uređuje kasnije odluke: treba li HMI biti isključivo sloj vizualizacije ili i mjesto konfiguracije, dijagnostike i promjene receptura; trebaju li servisne funkcije raditi stalno ili samo nakon svjesnog pokretanja; treba li operater imati pristup isključivo vođenju procesa ili i operacijama koje mijenjaju parametre i povijest podataka.

Praktični trošak propusta obično postaje vidljiv tek kada je aplikacija već povezana s recepturama, alarmima, izvještavanjem, arhiviranjem i procedurama održavanja. Tada čak i naizgled jednostavna korekcija, kao što je razdvajanje računa, promjena puta odobravanja kritične operacije ili ograničavanje udaljenog pristupa na povremeni način rada, prestaje biti samo promjena na ekranima. Zahtijeva preoblikovanje logike, ponovno testiranje rukovanja alarmima, utvrđivanje odgovornosti, a često i organizacijske promjene u pogonu.

U praksi je najrazumnija polazna točka radna mapa korisničkih uloga i njihovih ovlasti za kritične operacije, popis funkcija koje uzrokuju promjenu stanja procesa, konfiguracije ili receptura te pregled vanjskih veza koji obuhvaća servis, izvještavanje, nadređene sustave i udaljeni pristup. Tek se na toj osnovi može smisleno projektirati arhitektura zona i veza te pripremiti kasnija analiza rizika. Takav pristup odgovara i inženjerskoj praksi i zahtjevima za uređivanje odgovornosti, razdvajanje funkcija te nadzor komunikacije u industrijskim okruženjima.

Gdje doista rastu trošak i rizik

Najveći trošak i rizik u HMI/SCADA aplikaciji ne proizlaze isključivo iz same činjenice povezivanja sustava, nego iz toga kakve procesne i organizacijske posljedice izazivaju pojedine funkcije aplikacije. Najosjetljivija su ona mjesta koja omogućuju brzu promjenu postavki, uvođenje zaobilaženja, utišavanje alarma, promjenu recepture ili ručno upravljanje bez punog tehnološkog konteksta. Ako projekt dopušta takve operacije s razine proizvodnog ekrana u rutinskom načinu rada, rizik raste zato što jedna korisnička odluka ili jedna preuzeta sesija može izravno promijeniti stanje procesa.

To znači da katalog kritičnih operacija treba promatrati kao dio sigurnosne arhitekture, a ne samo kao pitanje ergonomije sučelja. Isti mehanizam vrijedi i za odgovornost za provedene radnje. Zajedničke prijave, računi koje dijeli cijela smjena, neodvojene ovlasti za pregled, upravljanje, konfiguraciju i administraciju te oskudno bilježenje događaja dovode do toga da je nakon incidenta teško pouzdano utvrditi je li došlo do pogreške, zaobilaženja procedure, zlouporabe servisnog pristupa ili neovlaštenog djelovanja. Problem se ne svodi samo na utvrđivanje uzroka. Bez vjerodostojnog traga korisničkih radnji nije moguće ni procijeniti učinkovitost procedura, smisleno upravljati ovlastima ni obraniti operativne odluke pred internom revizijom, zahtjevima kupca ili usvojenim sigurnosnim politikama. U praksi je ovdje riječ o odgovornosti za radnje i sljedivosti, a ne samo o samom zapisu događaja.

Vrlo skup projektantski propust jest i prenošenje opsežnih servisnih i dijagnostičkih zaslona u proizvodno okruženje, iako su izvorno pripremljeni za puštanje u rad ili podršku integratora. Takvi prikazi često omogućuju širok pristup internim varijablama, forsiranju stanja, uklanjanju blokada i izmjeni parametara, iako su u redovnom radu potrebni tek povremeno. Ako nisu obuhvaćeni dodatnim ograničenjima, postaju najkraći put za zahvat u proces izvan uobičajenog operatorskog tijeka. Razumno rješenje je odvojiti dijagnostiku potrebnu održavanju od funkcija koje omogućuju zahvat u logiku rada te zasebno odlučiti treba li dijagnostika proizvođača stroja biti dostupna lokalno, daljinski ili samo uvjetno, nakon svjesnog uključivanja i uz potpuno bilježenje sesije.

Na sličan način treba promatrati i integraciju s bazama podataka, izvještavanjem, daljinskom podrškom i uredskim sustavima. Svaka takva veza povećava udobnost rada, ali istodobno povećava i broj ovisnosti koje mogu postati ulazna točka, izvor smetnji ili uzrok gubitka jasne odgovornosti. Kvar posredničke usluge, pogrešna sinkronizacija vremena, nekontrolirana razmjena podataka s nadređenim sustavom ili ostavljen servisni kanal mogu utjecati ne samo na dostupnost izvještaja nego i na odluke koje donosi operator.

Zato već u projektu vrijedi mjeriti ne samo dostupnost zaslona, nego i jednostavnije i korisnije pokazatelje: broj kritičnih operacija mogućih s proizvodnog HMI-ja, broj aktivnih vanjskih veza, broj privilegiranih računa te opseg događaja obuhvaćenih revizijskim tragom. Takav pregled kasnije uređuje bilježenje događaja, nadzor promjena parametara i pravila daljinskog pristupa.

Poseban pristup zahtijeva alarmiranje. U tom području prividna potpunost često prikriva stvarni nedostatak nadzora. Loše projektirani alarmi i povijest događaja ne samo da preopterećuju operatora, nego mu i oduzimaju sposobnost razlikovanja kritičnih signala od tehničkog šuma. Ako se alarm može lako utišati bez obrazloženja, potvrditi bez upućivanja na uzrok ili izgubiti u masi dijagnostičkih poruka, aplikacija prestaje podupirati sigurnost procesa. Zato prioriteti alarma trebaju proizlaziti iz stvarnih posljedica za ljude, stroj i kvalitetu proizvodnje te ostati povezani s pravilima bilježenja potvrda, zaobilaženja i promjena postavki. Upravo je to trenutak u kojem analiza rizika prestaje biti formalni dokument i počinje oblikovati sučelje.

Kako projektirati da bi se ograničile posljedice pogreške i zlouporabe

Polazište je jednostavno: HMI/SCADA aplikacija ne smije pretpostavljati da svaki korisnik uvijek postupa ispravno i u odgovarajućem kontekstu procesa. Projekt treba započeti razdvajanjem funkcija, a ne crtanjem zaslona. Tim najprije treba utvrditi što operator smije samo vidjeti, što može potvrditi, što smije promijeniti u redovnom tijeku rada, a koje radnje treba prebaciti u servisni način rada, obuhvatiti dodatnom autorizacijom ili potpuno izdvojiti u zaseban alat ili stanicu.

Takva odluka uređuje cijelu arhitekturu pristupa: uloge, opseg ovlasti, način bilježenja radnji i uvjete daljinske podrške. U praksi se dobro pokazuje matrica uloga utemeljena na stvarnim odgovornostima, koja razlikuje operatora, voditelja smjene, održavanje, tehnologa, integratora i administratora. To nije formalnost. Ako servisne funkcije ostanu na istom zaslonu i pod istim računom kao i upravljanje procesom, aplikacija sama stvara put do pogreške, zaobilaženja procedure ili zlouporabe ovlasti.

Dobar HMI/SCADA ograničava mogućnost slučajnog izvođenja opasne operacije, ali bez potrebe ne usporava rutinske radnje. To zahtijeva jasan radni kontekst: korisnik treba vidjeti na kojem objektu radi, u kakvom je stanju proces, radi li lokalno ili daljinski te nalazi li se sustav u automatskom, ručnom ili servisnom načinu rada. Potvrde moraju biti razmjerne riziku, a ne jednake za sve radnje. Tamo gdje je posljedica pogreške reverzibilna i ograničena, obično je dovoljna jedna autorizacija. Kritične operacije zahtijevaju dodatnu kontrolu: drugu potvrdu, ponovnu autentifikaciju, ovisnost o stanju procesa ili fizički prijelaz na izdvojeno sučelje.

Važne su i uvjetne blokade. Ako aplikacija dopušta promjenu zadane vrijednosti, forsiranje signala ili ulazak u ručni način rada neovisno o stanju objekta, rizik se prenosi s projekta na operatera. Upravo se tu vidi da ispravno projektiranje sučelja nije samo pitanje jednostavnosti rukovanja, nego i ograničavanja posljedica pogreške ugrađenim barijerama. U mnogim slučajevima takav je način razmišljanja blizak načinu na koji funkcionira Poka-Yoke u proizvodnim linijama.

Slojevito projektiranje pristupa treba obuhvatiti i način korištenja ovlasti tijekom vremena. Pojedinačni korisnički računi nužni su svugdje gdje se očekuje sljedivost radnji. Zajednički račun onemogućuje utvrđivanje tko je stvarno donio odluku. Minimalni opseg ovlasti znači da korisnik dobiva samo one funkcije koje su mu potrebne za tekući rad, a proširenje ovlasti odvija se privremeno i u kontroliranim uvjetima. To se posebno odnosi na održavanje, integratora i udaljenu podršku proizvođača. Trajno otvoren servisni pristup samo je prividno praktičan, jer uklanja prirodnu granicu povjerenja između eksploatacije i servisa. Sigurniji model je pristup koji se aktivira na zahtjev, vremenski je ograničen, dodijeljen konkretnoj osobi i zabilježen u povijesti događaja. Takav je pristup dobro usklađen s načelom minimalnih ovlasti i segmentacijom pristupa.

U istom duhu treba odlučiti hoće li servisne funkcije biti dostupne s radnog HMI-ja ili isključivo s odvojene stanice te treba li dopustiti prijenosne medije i lokalni uvoz ili izvoz podataka s operaterskog panela. Te odluke nisu sporedne. O njima ovisi hoće li se održivost sustava provoditi na kontroliran način ili putem ad hoc zaobilaženja.

Iz perspektive incidenta ili spora u eksploataciji samo sučelje nije dovoljno. Aplikacija mora ostaviti trag koji omogućuje rekonstrukciju tijeka odlučivanja. Povijest događaja, sistemski dnevnici i bilježenje promjena zajedno trebaju odgovoriti ne samo na pitanje što se dogodilo, nego i tko je, kada, s kojeg mjesta i u kakvom stanju procesa izvršio radnju. Minimalni opseg događaja koje obično vrijedi obuhvatiti zapisivanjem uključuje prijavu, promjenu ovlasti, promjenu parametara, ulazak u ručni način rada, potvrdu alarma te uvoz konfiguracije. Ključno je povezati zapis s tehnološkim kontekstom, jer sama informacija o promjeni bez stanja objekta često nije korisna.

Dobar primjer tipičan je za mnoga uvođenja: promjena praga alarma od strane tehnologa može biti dopuštena, ali samo nakon ulaska u predviđeni način rada, uz evidentiranje korisnika, stanice, vremena, prethodne i nove vrijednosti te potvrdu da objekt nije bio u kritičnom stanju. Takav trag važan je i za sigurnost i za upravljanje promjenama u industrijskim aplikacijama.

Posljednji sloj je održivost bez zaobilaženja zaštita. Ako ažuriranje, obnova konfiguracije ili dijagnostika zahtijevaju isključivanje kontrole pristupa, korištenje zajedničke lozinke ili rad bez revizijskog traga, problem je u projektu, a ne u disciplini osoblja. Aplikacija treba imati predviđen tijek promjene: zahtjev, procjenu utjecaja, test, provedbu, potvrdu i plan povrata. Također treba odvojiti radno okruženje od servisnog barem logički, a ondje gdje je to opravdano i organizacijski te tehnički. Izradu i obnovu kopija konfiguracije mora biti moguće provesti na kontroliran način, bez ad hoc izvoza „za svaki slučaj” s panela. Takav je pristup usklađen s načelom najmanjih ovlasti u OT-u te sa zahtjevima koji se odnose na kontrolu pristupa, sljedivost radnji i upravljanje promjenama, pri čemu njihov opseg uvijek treba povezati s arhitekturom sustava i prihvaćenom podjelom odgovornosti.

Praksa provedbe i povezanost sa zahtjevima

Najviše koristi ne donosi dodavanje novih zaštitnih mehanizama na kraju projekta, nego sustavan pregled aplikacije prije preuzimanja ili modernizacije. To je trenutak u kojem se način rada sustava još može relativno jeftino korigirati, umjesto da se kasnije pogrešne pretpostavke nadograđuju dodatnim procedurama. Takav pregled treba provoditi mješoviti tim: projekt, održavanje, eksploatacija, automatika i osobe odgovorne za sigurnost.

Predmet ocjene nije samo tehnička konfiguracija, nego i to razdvaja li aplikacija doista uloge, štiti li kritične operacije, ograničava li udaljeni pristup na opravdane slučajeve, osigurava li jasno rukovanje alarmima, čuva li povijest promjena te omogućuje li izradu kopija i provedbu izvanrednih postupaka bez zaobilaženja zaštita. Upravo iz takvog pregleda treba proizaći popis za FAT/SAT te zahtjevi koji se unose u preuzimanje, plan servisa i izvedbenu dokumentaciju.

Ovakav pristup težište premješta s rasprave o samim zaštitama na projektne odluke koje kasnije određuju ponašanje ljudi i opreme. Ako se već u fazi projektiranja ne odredi tko smije mijenjati parametre receptura, tko odobrava servisni način rada, kako se evidentira intervencija integratora i pod kojim je uvjetima dopušten pristup izvan pogona, sustav će se nakon puštanja u rad oslanjati na iznimke i usmene dogovore.

Iz istog je razloga važno odlučiti treba li ocjenu aplikacije provoditi u sklopu modernizacije stroja ili linije, ili kao zasebnu reviziju OT-a. Prvi pristup bolje povezuje sigurnost s funkcijom procesa, a drugi olakšava uočavanje međuovisnosti između sustava i podjelu odgovornosti za račune, ovlasti i evidentiranje aktivnosti. To je ujedno i prirodno mjesto za početnu analizu rizika: identifikaciju kritičnih operacija, granica povjerenja te posljedica pogreške operatera ili zlouporabe. U praksi ovdje može biti korisna i analiza rizika u projektu.

• uloge korisnika i način prijave,
• kritične operacije i pravila njihove potvrde,
• udaljeni pristup i servisne funkcije,
• alarmi, evidentiranje promjena i sljedivost aktivnosti,
• sigurnosne kopije, obnova i postupci u izvanrednim situacijama.

Dobar rezultat u pogonu rijetko proizlazi iz istodobne primjene velikog broja alata. Obično je važnije ukloniti nekoliko sustavnih rizika koji su se godinama smatrali praktičnima. Modernizacija HMI/SCADA aplikacije može započeti ukidanjem zajedničkih računa, odvajanjem servisnih funkcija od operaterskih, ograničavanjem vanjskih veza na kontrolirane putove te uvođenjem traga promjena parametara s pripisivanjem konkretnoj osobi ili ulozi. Takva promjena ne mora otežati rad održavanja ni integratora, pod uvjetom da su od početka predviđeni servisni način rada, pravila autorizacije i ponovljiv tijek izmjena.

U eksploataciji potom vrijedi pratiti ne apstraktnu razinu sigurnosti, nego operativno korisne pokazatelje: broj zajedničkih računa koji su još prisutni u sustavu, opseg aktivnog udaljenog pristupa, potpunost zapisa o promjenama, vrijeme obnove konfiguracije te broj intervencija provedenih izvan formalnog postupka. Takvi pokazatelji omogućuju procjenu je li projekt doista smanjio rizik ili ga je samo prebacio u svakodnevnu praksu.

U poljskim i europskim okolnostima sve je teže braniti pristup prema kojem je kibernetička sigurnost HMI/SCADA sustava isključivo stvar IT odjela. Odgovornost je raspodijeljena između projektiranja, eksploatacije, održavanja, dobavljača i integratora, a zahtjevi struke i ugovora imaju stvarnu težinu tek kada organizacija može pokazati konkretne činjenice: koje su projektne odluke donesene, kako se dodjeljuju ovlasti, kakav trag aktivnosti postoji i tko nadzire promjene. Samo pozivanje na norme, politike ili ugovorne odredbe ne može zamijeniti dokaz da je aplikacija projektirana i preuzeta na način koji omogućuje sigurnu eksploataciju.

Najvažniji zaključak je praktičan. Projektiranje i preuzimanje aplikacije i dalje su najjeftiniji i najučinkovitiji trenutak za smanjenje rizika. Tada se uz najmanji trošak određuju granice povjerenja, uloge, uvjeti pristupa, trag aktivnosti i način provedbe promjena. Ako se ti zahtjevi pretoče u provjerljive kriterije prema dobavljaču i integratoru, HMI/SCADA prestaje biti praktično, ali previše povjerljivo sučelje i postaje alat za sigurnu eksploataciju procesa.