Küberturvalisust silmas pidades HMI/SCADA rakenduste projekteerimine – põhimõtted, mis vähendavad riski juba projekteerimisetapis

HMI/SCADA-rakenduse ohutus otsustatakse ära märksa varem kui kaitsemehhanismide valiku etapis. See, kas süsteem peab vastu eksimustele, väärkasutusele ja protsessi oleku kontrollimatule muutumisele, sõltub eelkõige projektis tehtud lähteotsustest: rollide jaotusest, usalduspiiridest, liidese kaudu kättesaadavate funktsioonide ulatusest ning hoolduse ja kaugjuurdepääsu korraldusest. Kui neid küsimusi käsitletakse teisejärgulisena, hakkab rakendus riski vähendamise asemel seda kinnistama. Seetõttu tuleb HMI/SCADA küberturvalisust silmas pidades projekteerida inseneriülesandena: kõigepealt tuleb määrata, millised toimingud on kriitilised, millised võivad olla nende tagajärjed ja kellel peab tegelikult olema õigus neid teha, ning alles seejärel kujundada ekraanid, häired ja kasutusmugavus.

Küberturvalisus algab projektist

HMI/SCADA-süsteemides ei ole küberturvalisus valmis visualiseeringule hiljem lisatav täiendus. See tuleneb varem tehtud otsustest: rakenduse arhitektuurist, õiguste mudelist, juhtimissüsteemiga suhtlemise viisist ja hoolduse lähte-eeldustest. See on eriti oluline, sest HMI/SCADA-rakendus on ühtaegu inimese, protsessi ja taristu kokkupuutepunkt. Seetõttu ei piirdu projekteerimisviga ainult IT-riskiga. See võib samal ajal mõjutada operaatori reaktsiooni kulgu, funktsionaalset ohutust, operatsiooniriski ja tootmise järjepidevust.

Projekti vaates ei ole põhiküsimus seega mitte see, milline kaitse lõpus juurde lisada, vaid millised otsused vähendavad ründepinda juba alguses. Suurimad probleemid ei tulene tavaliselt üksiku mehhanismi puudumisest, vaid rakendusse sisse ehitatud liigsest usaldusest. Praktikas tähendab see ühiseid kasutajakontosid, laiaulatuslikku ja püsivat hooldusjuurdepääsu, rollide eristamise puudumist operaatori, hoolduse ja integraatori vahel ning liiga vaba suhtlust operaatorikihi ja juhtimissüsteemi vahel. Käikulaskmise etapis tunduvad sellised lahendused mugavad, sest need kiirendavad tööd ja lihtsustavad diagnostikat. Hiljem muutuvad need keskkonna püsivaks omaduseks ning suurendavad väärkasutuse, eksimuse või protsessi oleku kontrollimatu muutumise riski.

Seetõttu tasub enne ekraanide projekteerimist kindlaks määrata mitte ainult see, mida kasutaja peab nägema, vaid eelkõige see, kus kulgevad usalduspiirid, millised toimingud on kriitilised ja millistes kohtades võib liides muutuda vea või protseduurist möödahiilimise vahendiks. Selline järjekord korrastab hilisemaid otsuseid: kas HMI peab olema üksnes visualiseerimiskiht või ka konfiguratsiooni, diagnostika ja retseptide muutmise koht; kas hooldusfunktsioonid peavad olema pidevalt aktiivsed või ainult teadliku käivitamise järel; kas operaatoril peab olema juurdepääs üksnes protsessi käitamisele või ka toimingutele, mis muudavad parameetreid ja andmeajalugu.

Puudujääkide praktiline hind ilmneb tavaliselt alles siis, kui rakendus on juba seotud retseptide, häirete, aruandluse, arhiveerimise ja hooldusprotseduuridega. Siis lakkab isegi näiliselt lihtne parandus, nagu kontode eraldamine, kriitilise toimingu kinnitamise tee muutmine või kaugjuurdepääsu piiramine juhupõhise kasutusega, olemast pelgalt ekraanide muudatus. See nõuab loogika ümbertegemist, häirekäsitluse uuesti testimist, vastutuse määratlemist ja sageli ka organisatsioonilisi muudatusi ettevõttes.

Praktikas on kõige mõistlikum lähtekoht kasutajarollide ja nende kriitiliste toimingute õiguste töökaart, protsessi olekut, konfiguratsiooni või retsepte muutvate funktsioonide loetelu ning välisühenduste nimekiri, mis hõlmab hooldust, aruandlust, ülemisi süsteeme ja kaugjuurdepääsu. Alles selle põhjal saab sisukalt projekteerida tsoonide ja ühenduste arhitektuuri ning valmistada ette hilisema riskianalüüsi. Selline lähenemine vastab nii inseneripraktikale kui ka vajadusele korrastada vastutust, eraldada funktsioone ja kontrollida sidet tööstuskeskkondades.

Kus kulu ja risk tegelikult kasvavad

HMI/SCADA-rakenduse suurim kulu ja risk ei tulene üksnes süsteemide ühendamisest endast, vaid sellest, milliseid protsessi- ja organisatsioonilisi tagajärgi rakenduse üksikud funktsioonid kaasa toovad. Kõige tundlikumad on need kohad, mis võimaldavad kiiresti muuta seadeid, rakendada möödaviiku, vaigistada häiret, muuta retsepti või teostada käsijuhtimist ilma täieliku tehnoloogilise kontekstita. Kui projekt lubab selliseid toiminguid tootmisekraani kaudu tavapärases töörežiimis, kasvab risk seetõttu, et üks kasutaja otsus või üks ülevõetud seanss võib protsessi olekut otseselt muuta.

See tähendab, et kriitiliste toimingute loetelu tuleb käsitleda turbearhitektuuri osana, mitte ainult kasutajaliidese ergonoomika küsimusena. Sama põhimõte kehtib ka tegevuste vastutuse jälgitavuse puhul. Ühised sisselogimised, vahetuse peale jagatud kontod, lugemis-, juhtimis-, seadistus- ja haldusõiguste eristamise puudumine ning napp sündmuste logimine muudavad pärast intsidenti keeruliseks usaldusväärselt kindlaks teha, kas tegemist oli eksimuse, protseduuri eiramise, hooldusjuurdepääsu kuritarvitamise või volitamata tegevusega. Probleem ei piirdu ainult põhjuste uurimisega. Ilma kasutaja tegevuste usaldusväärse jäljeta ei ole võimalik hinnata protseduuride tõhusust, mõistlikult hallata õigusi ega põhjendada käitamisotsuseid siseauditi, kliendi nõuete või kehtestatud turbepoliitikate ees. Praktikas on siin küsimus tegevuste vastutuse jälgitavuses ja jälgitavuse ahelas, mitte ainult sündmuste salvestamises.

Väga kulukas projekteerimisviga on ka see, kui tootmiskeskkonda viiakse üle mahukad hooldus- ja diagnostikaekraanid, mis olid algselt loodud kasutuselevõtu või integraatori toe jaoks. Sellised vaated annavad sageli laia juurdepääsu sisemistele muutujatele, olekute sundseadmisele, blokeeringute tühistamisele ja parameetrite muutmisele, kuigi tavapärases käitamises on neid vaja vaid üksikjuhtudel. Kui neile ei rakendata täiendavaid piiranguid, muutuvad need lühimaks teeks protsessi mõjutamiseks väljaspool tavapärast operaatori töövoogu. Mõistlik lahendus on eraldada hoolduseks vajalik diagnostika funktsioonidest, mis võimaldavad sekkuda tööloogikasse, ning otsustada eraldi, kas masina tootja diagnostika peab olema kättesaadav kohapeal, kaugühenduse kaudu või ainult tingimuslikult, teadliku aktiveerimise järel ja kogu seansi täieliku salvestamisega.

Sarnaselt tuleb käsitleda integratsiooni andmebaaside, aruandluse, kaugtugi ja kontorisüsteemidega. Iga selline ühendus parandab töö mugavust, kuid samal ajal suurendab sõltuvuste hulka, mis võivad kujuneda sisenemisteeks, häirete allikaks või vastutuse selguse kadumise põhjuseks. Vahendusteenuse rike, vale ajasünkroonimine, kontrollimatu andmevahetus ülemise taseme süsteemiga või alles jäetud hoolduskanal võivad mõjutada mitte ainult aruannete kättesaadavust, vaid ka operaatori tehtavaid otsuseid.

Seetõttu tasub juba projekteerimisel mõõta mitte ainult ekraanide kättesaadavust, vaid ka lihtsamaid ja praktilisemaid näitajaid: kui palju kriitilisi toiminguid on võimalik teha tootmis-HMI tasemelt, kui palju on aktiivseid välisühendusi, kui palju on privilegeeritud kontosid ning milline on auditeerimisjäljega kaetud sündmuste ulatus. Selline ülevaade korrastab hiljem sündmuste logimist, parameetrimuudatuste kontrolli ja kaugjuurdepääsu reegleid.

Alarmihaldus vajab eraldi käsitlemist. Selles valdkonnas varjab näiline täielikkus sageli tegelikku kontrolli puudumist. Halvasti projekteeritud alarmid ja sündmuste ajalugu ei koorma operaatorit mitte ainult üle, vaid võtavad talt ka võime eristada kriitilisi signaale tehnilisest mürast. Kui alarmi saab põhjenduseta lihtsalt vaigistada, kinnitada ilma põhjusega seostamata või kaotada diagnostiliste teadete massi sisse, lakkab rakendus protsessi ohutust toetamast. Seetõttu peavad alarmide prioriteedid lähtuma tegelikust mõjust inimestele, masinale ja tootmise kvaliteedile ning olema seotud kinnituste, möödaviikude ja seadistuste muudatuste logimise põhimõtetega. Just siin lakkab riskianalüüs olemast formaalne dokument ja hakkab kujundama kasutajaliidest.

Kuidas projekteerida nii, et vea ja kuritarvituse mõju oleks piiratud

Lähtekoht on lihtne: HMI/SCADA rakendus ei tohi eeldada, et iga kasutaja tegutseb alati õigesti ja protsessi jaoks õiges kontekstis. Projekti tuleb alustada funktsioonide eristamisest, mitte ekraanide joonistamisest. Meeskond peaks esmalt kindlaks määrama, mida operaator tohib ainult näha, mida ta võib kinnitada, mida tal on lubatud tavapärase töö käigus muuta ning millised tegevused tuleb viia hooldusrežiimi, katta täiendava autoriseerimisega või eraldada täielikult eraldi tööriista või jaama alla.

Selline otsus korrastab kogu juurdepääsu arhitektuuri: rollid, õiguste ulatuse, tegevuste logimise viisi ja kaugtugi tingimused. Praktikas toimib hästi rollimaatriks, mis põhineb tegelikel tööülesannetel ja eristab operaatorit, vahetusevanemat, hooldust, tehnoloogi, integraatorit ja administraatorit. See ei ole formaalsus. Kui hooldusfunktsioonid jäävad protsessi juhtimisega samale ekraanile ja sama konto alla, loob rakendus ise tee eksimuseks, protseduuri eiramiseks või õiguste kuritarvitamiseks.

Hea HMI/SCADA piirab ohtliku toimingu juhusliku tegemise võimalust, kuid ei aeglusta tarbetult rutiinseid tegevusi. See eeldab selget töökonteksti: kasutaja peab nägema, millise objekti kallal ta töötab, millises olekus on protsess, kas ta tegutseb kohapeal või kaugühenduse kaudu ning kas süsteem on automaat-, käsitsi- või hooldusrežiimis. Kinnitused peavad olema riskiga proportsionaalsed, mitte kõigi tegevuste puhul ühesugused. Seal, kus vea tagajärg on pöörduv ja piiratud, piisab tavaliselt ühest autoriseerimisest. Kriitilised toimingud nõuavad täiendavat kontrolli: teist kinnitust, uuesti autentimist, sõltuvust protsessi olekust või füüsilist üleminekut eraldatud liidesele.

Olulised on ka tingimuslikud lukustused. Kui rakendus lubab muuta seadistust, sundida signaali või minna käsirežiimi sõltumata objekti olekust, kandub risk lahenduselt operaatorile. Just siin ilmneb, et liidese korrektne projekteerimine ei tähenda ainult kasutusmugavust, vaid ka vea tagajärgede piiramist sisseehitatud tõkete abil. Paljudel juhtudel on selline mõtteviis lähedane sellele, kuidas toimib Poka-Yoke tootmisliinidel.

Juurdepääsu kihiline kavandamine peab hõlmama ka seda, kuidas õigusi ajas kasutatakse. Isiklikud kontod on vajalikud kõikjal, kus eeldatakse tegevuste jälgitavust. Ühine konto võtab ära võimaluse kindlaks teha, kes otsuse tegelikult tegi. Minimaalsete õiguste põhimõte tähendab, et kasutaja saab ainult need funktsioonid, mida ta vajab oma jooksva töö tegemiseks, ning õiguste laiendamine toimub ajutiselt ja kontrollitud tingimustel. See puudutab eelkõige hooldust, integraatorit ja tootja kaugtoe kasutamist. Püsivalt avatud teeninduskanal on mugav vaid näiliselt, sest kaotab loomuliku usalduspiiri käituse ja hoolduse vahel. Turvalisem mudel on nõudmisel aktiveeritav juurdepääs, mis on ajaliselt piiratud, seotud konkreetse isikuga ja talletatud sündmuste ajaloos. See lähenemine sobitub hästi minimaalsete õiguste põhimõtte ja juurdepääsu segmenteerimisega.

Samas vaimus tuleb otsustada, kas teenindusfunktsioonid peavad olema kättesaadavad töö-HMI kaudu või ainult eraldi jaamast, ning kas lubada eemaldatavaid andmekandjaid ja lokaalset andmete importi või eksporti operaatoripaneelilt. Need otsused ei ole teisejärgulised. Nendest sõltub, kas süsteemi hooldatavus tagatakse kontrollitult või ajutiste möödaviikude kaudu.

Intsidendi või käitlusvaidluse vaates ei piisa ainult liidesest. Rakendus peab jätma alles materjali, mille põhjal saab otsustuste käigu taastada. Sündmuste ajalugu, süsteemilogid ja muudatuste registreerimine peavad koos vastama mitte ainult küsimusele, mis juhtus, vaid ka sellele, kes, millal, millisest kohast ja millises protsessi olekus toimingu tegi. Minimaalne sündmuste ulatus, mida tavaliselt tasub logida, hõlmab sisselogimist, õiguste muutmist, parameetrite muutmist, käsirežiimi sisenemist, alarmi kinnitamist ning konfiguratsiooni importi. Võtmetähtsusega on siduda kirje tehnoloogilise kontekstiga, sest pelk teave muudatuse kohta ilma objekti olekuta võib osutuda kasutuks.

Hea näide on paljudele juurutustele tüüpiline: tehnoloogi tehtud alarmiläve muutmine võib olla lubatav, kuid ainult pärast ettenähtud režiimi sisenemist, koos kasutaja, jaama, aja, eelmise ja uue väärtuse registreerimisega ning kinnitusega, et objekt ei olnud kriitilises olekus. Selline jälg on oluline nii ohutuse kui ka tööstusrakenduste muudatuste haldamise seisukohalt.

Viimane kiht on hooldatavus ilma kaitsemeetmetest mööda minemata. Kui uuendamine, konfiguratsiooni taastamine või diagnostika nõuavad juurdepääsukontrolli väljalülitamist, ühise parooli kasutamist või töötamist ilma auditijäljeta, on probleem lahenduses, mitte personali distsipliinis. Rakendusel peab olema ette nähtud muudatuse käik: taotlus, mõju hindamine, test, juurutamine, kinnitamine ja tagasipöördumise plaan. Samuti peab see eristama töökeskkonda teeninduskeskkonnast vähemalt loogiliselt ning seal, kus see on põhjendatud, ka organisatsiooniliselt ja tehniliselt. Konfiguratsioonikoopiate tegemine ja taastamine peab olema võimalik kontrollitud viisil, ilma ajutise „igaks juhuks” ekspordita paneelilt. Selline lähenemine on kooskõlas OT minimaalse õiguste põhimõttega ning nõuetega, mis puudutavad juurdepääsukontrolli, tegevuste jälgitavust ja muudatuste haldamist, kusjuures nende ulatus tuleb alati siduda süsteemi arhitektuuri ja vastutuse jaotusega.

Juurutamise praktika ja seos nõuetega

Kõige rohkem annab mitte uute kaitsemehhanismide lisamine projekti lõpus, vaid rakenduse korrastatud ülevaatus enne vastuvõttu või moderniseerimist. See on hetk, mil süsteemi tööviisi saab veel suhteliselt väikese kuluga korrigeerida, selle asemel et hiljem valede eelduste ümber täiendavaid protseduure ehitada. Sellist ülevaatust peaks tegema segameeskond: projekteerimine, hooldus, käitus, automaatik ja ohutuse eest vastutavad isikud.

Hindamise objekt ei ole ainult tehniline konfiguratsioon, vaid ka see, kas rakendus tegelikult eristab rolle, kaitseb kriitilisi toiminguid, piirab kaugjuurdepääsu põhjendatud juhtudega, tagab alarmide selge käsitlemise, säilitab muudatuste ajaloo ning võimaldab teha varukoopiaid ja avariiprotseduure ilma kaitsemeetmetest mööda minemata. Just sellisest ülevaatusest peaks tulenema nimekiri FAT/SAT jaoks ning nõuded, mis kantakse vastuvõtu tingimustesse, hooldusplaani ja teostusdokumentatsiooni.

See lähenemine nihutab fookuse pelgalt kaitsemeetmete arutelult projekteerimisotsustele, mis hakkavad hiljem määrama inimeste ja seadmete käitumist. Kui juba projekteerimisetapis ei ole kokku lepitud, kes tohib muuta retseptiparameetreid, kes kinnitab hooldusrežiimi, kuidas dokumenteeritakse integraatori sekkumine ja millistel tingimustel on lubatud juurdepääs väljastpoolt tehast, siis pärast süsteemi kasutuselevõttu hakkab see tuginema eranditele ja suulistele kokkulepetele.

Samal põhjusel tasub otsustada, kas rakenduse hindamine teha masina või liini moderniseerimise osana või eraldi OT ülevaatusena. Esimene lähenemine seob ohutuse paremini protsessi funktsiooniga, teine aitab hõlpsamini märgata süsteemidevahelisi sõltuvusi ning vastutuse jaotust kontode, õiguste ja tegevuste logimise eest. See on ka loomulik koht esialgseks riskianalüüsiks: kriitiliste toimingute, usalduspiiride ning operaatori vea või kuritarvituse tagajärgede tuvastamiseks. Praktikas on siin abiks ka projekti riskianalüüs.

• kasutajarollid ja sisselogimise viis,
• kriitilised toimingud ja nende kinnitamise põhimõtted,
• kaugjuurdepääs ja hooldusfunktsioonid,
• häired, muudatuste logimine ja tegevuste jälgitavus,
• varukoopiad, taastamine ja avariiprotseduurid.

Hea tulemus tehases sünnib harva paljude tööriistade samaaegsest kasutuselevõtust. Tavaliselt on suurema mõjuga mõne süsteemse riski kõrvaldamine, mida on aastaid peetud praktiliseks lahenduseks. HMI/SCADA rakenduse ajakohastamine võib alata ühiskontode kaotamisest, hooldusfunktsioonide eraldamisest operaatorifunktsioonidest, välisühenduste piiramisest kontrollitud kanalitega ning parameetrimuudatuste jälje käivitamisest nii, et see on seotud konkreetse isiku või rolliga. Selline muudatus ei pea halvendama tootmise hoolduse ega integraatori tööd, kui juba algusest peale on ette nähtud hooldusrežiim, autoriseerimise põhimõtted ja muudatuste korratav kulg.

Käitamise ajal tasub seejärel mõõta mitte abstraktset turvalisuse taset, vaid töö seisukohalt kasulikke näitajaid: süsteemi alles jäänud ühiskontode arvu, aktiivse kaugjuurdepääsu ulatust, muudatuslogide täielikkust, konfiguratsiooni taastamise aega ning väljaspool ametlikku protseduuri tehtud sekkumiste arvu. Sellised mõõdikud võimaldavad hinnata, kas projekt vähendas riski tegelikult või kandis selle lihtsalt üle igapäevasesse praktikasse.

Poola ja Euroopa Liidu tingimustes on üha raskem kaitsta lähenemist, mille järgi HMI/SCADA küberturvalisus on ainult IT-osakonna asi. Vastutus jaguneb projekteerimise, käitamise, tootmise hoolduse, tarnijate ja integraatorite vahel ning valdkondlikud ja lepingulised nõuded omandavad tähenduse alles siis, kui organisatsioon suudab näidata konkreetseid asjaolusid: millised projekteerimisotsused tehti, kuidas õigusi antakse, milline on tegevuste jälg ja kes muudatusi kontrollib. Pelgalt viited standarditele, poliitikatele või lepingusätetele ei asenda tõendit, et rakendus on projekteeritud ja vastu võetud viisil, mis võimaldab protsessi ohutut käitamist.

Kõige olulisem järeldus on praktiline. Kõige odavam ja tõhusam hetk riski vähendamiseks on endiselt rakenduse projekteerimine ja vastuvõtt. Just siis saab kõige väiksema kuluga määrata usalduspiirid, rollid, juurdepääsutingimused, tegevuste jälje ja muudatuste haldamise viisi. Kui need nõuded tõlgitakse tarnija ja integraatori jaoks kontrollitavateks kriteeriumideks, lakkab HMI/SCADA olemast mugav, kuid liialt usaldav liides ning sellest saab turvalist käitamist toetav tööriist.