Varnost poslovne aplikacije: kaj mora urediti izvajalec

Kaj pomeni varnost poslovne aplikacije#

Varnost poslovne aplikacije pomeni, da je pred zagonom jasno določeno, kdo lahko dostopa do katerih podatkov in funkcij, kako se beleži vsaka pomembna sprememba in kje ter kako se hranijo varnostne kopije podatkov. To niso tri ločene tehnične nastavitve, ampak sklop odločitev, ki jih mora izvajalec urediti skupaj z naročnikom še pred prvo objavo sistema v produkcijsko okolje. Če teh odločitev ni, se varnost prepusti naključju, incident pa razkrije šele, kdo je bil dejansko odgovoren za posamezen del sistema.

Poslovna aplikacija v podjetju z več oddelki redko stoji sama. Povezuje se z ERP in CRM sistemi, dokumentnimi arhivi in orodji za poročanje, zato vsaka nova povezava prek API-ja poveča površino, na kateri lahko pride do nepooblaščenega dostopa ali izgube podatkov. Odgovornost za varnost se s tem razširi na vse sisteme, ki so med seboj povezani, ne le na aplikacijo samo. Vodja IT ali direktor projekta mora zato od izvajalca zahtevati pregled celotne verige, ne le posamezne komponente.

Za odločevalca to pomeni, da varnosti ni mogoče prepustiti izvajalcu kot samoumevno storitev v ozadju. Gre za vprašanja, ki jih je treba postaviti pred podpisom pogodbe: kdo bo določil pravice dostopa, kako bo potekala sledljivost sprememb in kdo je odgovoren, če se varnostna kopija izkaže za neuporabno. Odgovori na ta vprašanja določajo, kako hitro se podjetje po morebitnem izpadu ali napaki vrne v normalno delovanje in kdo nosi odgovornost za posledice.

Upravljanje dostopov do aplikacije in podatkov#

Prva odločitev, ki jo mora urediti izvajalec, je, kdo sme videti in urejati kateri del sistema. To pomeni popis uporabniških vlog po oddelkih, ločevanje pravic branja od pravic urejanja in jasno določitev, kdo lahko dodeli ali odvzame dostop drugemu uporabniku. Brez tega popisa se v praksi zgodi, da imajo dostop do finančnih ali kadrovskih podatkov tudi zaposleni, ki ga za svoje delo ne potrebujejo.

Pri aplikaciji, ki jo uporablja več oddelkov hkrati, se tveganje poveča, ker se vloge sčasoma spreminjajo. Zaposleni zamenja oddelek, prevzame nadomeščanje ali zapusti podjetje, dostopi pa pogosto ostanejo nespremenjeni. Izvajalec mora zato predlagati način, kako se dostopi redno pregledujejo in kako se sistem poveže s kadrovsko evidenco, da se pravice samodejno prilagodijo statusu zaposlenega.

Za naročnika to pomeni, da mora pred začetkom projekta določiti lastnika posameznega sklopa podatkov - torej osebo, ki odloča, kdo sme do njih dostopati. Ta odgovornost se ne sme prenesti izključno na izvajalca, ker slednji ne pozna notranje organizacije podjetja. Skupna določitev vlog na začetku projekta prepreči kasnejše spore o tem, kdo je odobril dostop, ki se je izkazal za sporen.

• Popis uporabniških vlog po oddelkih in ravni dostopa
• Ločevanje dolžnosti med osebo, ki podatek vnese, in osebo, ki ga odobri
• Poseben nadzor nad skrbniškimi (administratorskimi) računi
• Redni pregled dodeljenih pravic in takojšen odvzem ob prenehanju zaposlitve
• Povezava dostopov z evidenco zaposlenih, da se spremembe vloge odrazijo samodejno

Revizijska sled: kdo je kaj naredil in kdaj#

Revizijska sled je zapis, ki pokaže, kdo je do sistema dostopal, kaj je spremenil in kdaj se je to zgodilo. Izvajalec mora urediti, da je ta zapis nespremenljiv - torej da ga uporabnik, tudi če ima skrbniške pravice, ne more naknadno izbrisati ali prirediti. Brez take sledi podjetje ob incidentu ali sporu nima podlage, da bi ugotovilo, kaj se je dejansko zgodilo.

Revizijska sled postane pomembna predvsem takrat, ko pride do spora med oddelki, do inšpekcijskega nadzora ali do suma zlorabe podatkov. Če sistem beleži le zadnje stanje podatka, ne pa poti sprememb, se ne da rekonstruirati, kdo je napako povzročil in kdaj. To je še posebej pomembno pri aplikacijah, ki obdelujejo finančne, kadrovske ali osebne podatke, kjer je sledljivost pogosto tudi zakonska zahteva.

Naročnik naj od izvajalca pred podpisom pogodbe zahteva jasen opis, kaj vse sistem beleži in kako dolgo se zapisi hranijo. Enako pomembno je, da se revizijska sled hrani ločeno od produkcijske baze podatkov, tako da napaka ali napad na glavni sistem ne uniči tudi dokazov o tem, kaj se je zgodilo. To vprašanje je treba razrešiti v fazi arhitekture, ne šele po incidentu.

• Prijave in odjave uporabnikov v sistem
• Spremembe poslovno kritičnih podatkov, z zapisom stare in nove vrednosti
• Izvoz ali prenos podatkov iz sistema
• Spremembe uporabniških pravic in dodelitev skrbniških dostopov
• Brisanje zapisov ali celotnih evidenc
• Dostope administratorjev do produkcijskega okolja

Varnostne kopije in obnovitev delovanja#

Varnostna kopija ni le kopija podatkov na drugem mestu, ampak dogovorjen načrt, kako hitro in v kakšnem stanju se sistem po izgubi podatkov ali izpadu povrne v delovanje. Izvajalec mora določiti, kako pogosto se kopije izdelujejo, kje se hranijo in kdo je odgovoren za njihovo preverjanje. Brez tega dogovora se pogosto izkaže šele ob dejanski izgubi podatkov, da kopija ne obstaja ali ne deluje.

Do izgube podatkov lahko pride zaradi človeške napake, okvare infrastrukture ali napada z izsiljevalsko programsko opremo. V vseh teh primerih je ključno, da kopija ni shranjena na istem mestu kot produkcijski sistem, sicer napad ali okvara uniči tudi kopijo. Prav tako mora biti jasno, kako dolgo se stare kopije hranijo in kdaj se prepišejo z novejšimi.

Za naročnika je najpomembnejše vprašanje, ali se obnovitev iz kopije dejansko redno preizkuša, ne le izdeluje. Kopija, ki je nikoli ni bilo treba obnoviti, je lahko poškodovana, ne da bi kdo to vedel. Izvajalec naj zato v dogovoru o vzdrževanju opredeli, kako pogosto se izvede testna obnovitev in kdo o rezultatu poroča odgovorni osebi v podjetju.

• Pogostost izdelave varnostnih kopij, prilagojena kritičnosti podatkov
• Hranjenje kopij ločeno od produkcijskega okolja
• Šifriranje kopij med prenosom in med hranjenjem
• Redno testiranje dejanske obnovitve, ne le izdelave kopije
• Jasna retencijska politika - koliko časa se stare kopije hranijo
• Načrt za obnovitev delovanja ob večjem izpadu (disaster recovery)

Ločena razvojna, testna in produkcijska okolja#

Sprememba na poslovni aplikaciji se ne sme testirati neposredno na sistemu, ki ga uporabljajo zaposleni ali stranke. Izvajalec mora zagotoviti ločeno razvojno okolje, kjer nastajajo spremembe, testno okolje, kjer se preverjajo, in produkcijsko okolje, kamor gredo spremembe šele po potrditvi. Ta ločitev je osnova za to, da napaka pri razvoju ne povzroči izpada v realnem sistemu.

V testnem okolju se ne smejo uporabljati pravi osebni podatki strank ali zaposlenih. Namesto tega se uporabijo testni ali anonimizirani podatki, ki po strukturi ustrezajo pravim, ne razkrivajo pa dejanskih oseb. To je pomembno tako z vidika varstva osebnih podatkov kot z vidika tveganja, da testni podatki uidejo iz manj zavarovanega okolja.

Za vodjo IT ali projekta to pomeni, da mora pred začetkom sodelovanja preveriti, ali izvajalec dejansko loči okolja ali gre le za deklarativno zavezo v ponudbi. Vprašanje, kdo ima dostop do testnega okolja in kateri podatki se v njem nahajajo, je smiselno postaviti že na prvem sestanku, ne šele ob prvem incidentu.

Testiranje pred objavo v produkcijo#

Vsaka sprememba na poslovni aplikaciji mora pred objavo v produkcijsko okolje skozi pregled in testiranje. To pomeni, da izvajalec preveri, ali sprememba deluje, kot je bilo dogovorjeno, in ali ni poškodovala delovanja drugih delov sistema. Brez tega koraka se poveča tveganje, da manjši popravek povzroči izpad na povsem drugem, na videz nepovezanem delu aplikacije.

Testiranje obsega ročno preverjanje kritičnih funkcij, avtomatizirano testiranje uporabniškega vmesnika, na primer z orodji, kot sta Playwright in Cypress, ter testiranje API-jev in regresijsko testiranje, ki preveri, da stara funkcionalnost še vedno deluje po novi spremembi. Te vrste testiranja se lahko izvajajo tudi znotraj samodejnega postopka objave (CI/CD), da se preverjanje ne pozabi ali izpusti pod časovnim pritiskom.

Pri poslovno kritičnih sistemih je smiselno dodati prevzemno testiranje po vnaprej dogovorjenih merilih, kjer naročnik potrdi, da sprememba izpolnjuje dogovorjene zahteve, preden gre v uporabo. Pri večjih ali bolj tveganih projektih je priporočljivo, da testiranje izvaja neodvisna ekipa, ločena od razvojne, saj razvijalec redkeje najde lastno napako.

• Ročno preverjanje kritičnih poslovnih funkcij
• Avtomatizirano testiranje uporabniškega vmesnika (na primer Playwright, Cypress)
• Testiranje API-jev in povezav z drugimi sistemi
• Regresijsko testiranje po vsaki večji spremembi
• Testiranje znotraj CI/CD postopka objave
• Prevzemno testiranje po vnaprej dogovorjenih merilih
• Neodvisen QA, ločen od razvojne ekipe, pri bolj tveganih projektih

Vzdrževanje po uvedbi in odzivnost (SLA)#

Ko je aplikacija v uporabi, varnost ni zaključena naloga, ampak se nadaljuje skozi vzdrževanje. Izvajalec lahko po uvedbi prevzame nadzor delovanja, odpravo napak ter tehnične in varnostne posodobitve. Ključno je, da je to dogovorjeno vnaprej, z jasno določenimi razredi napak in prednostjo obravnave, ne šele takrat, ko pride do dejanske motnje v delovanju.

Napake se običajno razvrstijo v razrede glede na resnost. Izpad pomeni, da sistem ali ključni del ne deluje in ima najvišjo prednost obravnave. Motnja pomeni, da sistem deluje, a posamezna funkcija ne, kar se obravnava po dogovorjeni prednosti. Manjša napaka brez vpliva na poslovanje se uvrsti v naslednjo redno objavo, zahteva za spremembo ali nadgradnjo pa se oceni in uskladi ločeno.

Za naročnika je pomembno, da so ti razredi in način obravnave zapisani v pogodbi o vzdrževanju, ne dogovorjeni ustno. Konkretni odzivni časi se določijo glede na kritičnost sistema in dogovor med naročnikom in izvajalcem, saj se razlikujejo glede na to, ali gre za sistem, ki ga uporablja nekaj zaposlenih, ali za sistem, od katerega je odvisno celotno poslovanje.

• Razred 1 - izpad: sistem ali ključni del ne deluje, obravnava ima najvišjo prednost
• Razred 2 - motnja: sistem deluje, posamezna funkcija ne
• Razred 3 - napaka: manjša napaka brez vpliva na poslovanje, uvrsti se v naslednjo objavo
• Razred 4 - zahteva: sprememba ali nadgradnja, obseg se oceni posebej

Lastništvo kode, podatkov in dokumentacije#

Izvorna koda in podatki poslovne aplikacije so last naročnika, ne izvajalca. To mora biti zapisano v pogodbi, saj določa, kaj se zgodi, če se podjetje odloči zamenjati izvajalca ali projekt prevzeti v lastno vzdrževanje. Brez tega določila se lahko zgodi, da je podjetje odvisno od enega izvajalca, ne glede na kakovost njegovega dela.

Poleg kode je enako pomembna dokumentacija: opis arhitekture, seznam dostopov in gesel ter opis, kako sistem deluje. Vse to je del primopredaje in mora biti naročniku na voljo, ne glede na to, ali se sodelovanje z izvajalcem nadaljuje ali konča. Dokumentacija, ki obstaja le v glavi enega razvijalca, je tveganje samo po sebi.

Kadar podjetje prevzema obstoječ ali nedokončan sistem od drugega izvajalca, je prvi korak pregled izvorne kode, arhitekture, infrastrukture in podatkov. Šele na podlagi tega pregleda je mogoče oceniti, ali je sistem varen, dokumentiran in pripravljen na nadaljnji razvoj, ali pa je treba posamezne dele najprej urediti, preden se nadgradnja sploh začne.

Kako izbrati izvajalca za varnost poslovne aplikacije#

Pri izbiri izvajalca je smiselno preveriti, ali ima izkušnje z varnostno arhitekturo, upravljanjem dostopov (IAM), testiranjem ranljivosti in odzivom na varnostne incidente. Gre za področja, ki jih je težko presoditi zgolj iz predstavitve, zato je vredno vprašati po konkretnem primeru, kako je izvajalec tovrstno nalogo rešil pri drugem projektu podobne velikosti.

Epix pri tovrstnih projektih sodeluje s specialistično partnersko mrežo, znotraj katere so na voljo strokovnjaki za varnostno arhitekturo, penetracijsko testiranje, upravljanje ranljivosti, digitalno forenziko in odziv na incidente. Znotraj te mreže so prisotni tudi nosilci certifikatov s področja oblačne varnosti, upravljanja identitet in projektnega vodenja, standardi upravljanja kakovosti in varnosti informacij pa so del delovne strukture, po kateri se projekti izvajajo.

Za naročnika to pomeni, da se pri večjem projektu ne zanaša na enega samega razvijalca, ampak na sestavljeno ekipo, kjer ima vsak član jasno vlogo. Pri izbiri velja preveriti tudi, ali izvajalec pozna zahteve panoge, v kateri podjetje deluje - na primer javni sektor, bančništvo ali zdravstvo, kjer so zahteve po sledljivosti in varnosti pogosto strožje kot drugod.

• Izkušnje z varnostno arhitekturo in upravljanjem dostopov (IAM)
• Izkušnje s testiranjem ranljivosti in odzivom na incidente
• Dostop do strokovnjakov za digitalno forenziko znotraj partnerske mreže
• Standardi upravljanja kakovosti in varnosti informacij v delovni strukturi
• Izkušnje v regulirani panogi, kot so javni sektor, bančništvo ali zdravstvo
• Jasna pogodba o vzdrževanju z opredeljenimi razredi napak

Cena in obseg dela#

Cene za ureditev varnosti poslovne aplikacije se ne da podati brez pregleda konkretnega sistema, zato je ne objavljamo v splošni obliki. Namesto tega je smiselno vprašanje obrniti v to, kateri dejavniki obseg dela dejansko določajo, saj ti dejavniki povedo več kot poljubna okvirna številka.

Na obseg dela vplivajo zahteve glede varnosti, revizijske sledi in skladnosti, ki so pri javnem sektorju ali regulirani panogi strožje kot drugod, količina in stanje podatkov, ki jih je treba zaščititi ali prenesti, ter to, ali gre za nov sistem ali za prevzem in nadgradnjo obstoječega. Pomemben dejavnik je tudi raven podpore po uvedbi in dogovorjeni razredi odzivnosti.

Epix pred pripravo ponudbe predlaga krajšo analizo, ki obseg razčleni na posamezne sklope - dostope, revizijsko sled, varnostne kopije, testiranje in vzdrževanje - tako da je vsak sklop mogoče oceniti in izvesti ločeno. To naročniku omogoči, da vidi, kje nastaja največ dela, in se odloči, kateri del prevzame takoj in kateri kasneje.