Kada se govori o razvoju softvera, zaštiti podataka i praćenju aktivnosti korisnika, jedna od najvažnijih tema je audit. U praksi se pod tim najčešće misli na audit trail, odnosno evidenciju ko je šta uradio u sistemu, kada je to uradio, sa kog naloga, nad kojim podacima i sa kakvim rezultatom. Takva evidencija je važna i za bezbednost i za usklađenost sa propisima, jer pomaže da firma dokaže zakonitost obrade, otkrije zloupotrebe, rekonstruiše incidente i uspostavi odgovornost. GDPR zahteva odgovarajuće tehničke i organizacione mere bezbednosti i zasniva se na principima integriteta, poverljivosti i odgovornosti rukovaoca, dok srpski Zakon o zaštiti podataka o ličnosti sadrži praktično ista načela i obaveze bezbednosti obrade.
Šta je zapravo audit u softveru
Audit u softverskom sistemu nije običan “history” prikaz niti puka lista izmena. Pravi audit beleži kritične radnje u sistemu: prijavu i odjavu korisnika, neuspele pokušaje pristupa, unos i izmenu podataka, brisanje, odobravanje, izvoz, promene privilegija, pristup osetljivim zapisima, rad administratorskih naloga i događaje vezane za integritete dokumenata i procesa. U srpskom ZZPL je za nadležne organe u posebnim svrhama izričito propisano beleženje unosa, menjanja, uvida, otkrivanja, prenosa, upoređivanja i brisanja, baš zato što takav zapis omogućava ocenu zakonitosti obrade, interni nadzor i bezbednost podataka.
Drugim rečima, audit trail odgovara na ključna pitanja: ko, šta, kada, gde, nad čim i, po mogućnosti, zašto. Kada sistem nema takvu evidenciju, veoma je teško dokazati ko je napravio izmenu, ko je pristupio podacima, da li je neko prekoračio ovlašćenja ili kako je došlo do incidenta. Zato audit nije luksuz niti dodatna funkcija, već osnovni mehanizam kontrole u ozbiljnim softverskim rešenjima. To je posebno važno u okruženjima gde se obrađuju lični podaci, finansijski zapisi, službeni dokumenti, ugovori, medicinski ili HR podaci.
Zašto je audit važan u razvoju softvera
Audit je važan već u fazi projektovanja sistema, a ne tek kada softver krene u produkciju. Srpska Uredba o bližem uređenju mera zaštite IKT sistema od posebnog značaja izričito traži da se zahtevi informacione bezbednosti ispune u svim fazama životnog ciklusa sistema, uključujući projektovanje, uvođenje novog sistema i izmene postojećeg sistema. То znači da audit mora biti deo arhitekture, modela prava pristupa, baze podataka i administrativnih tokova, a ne naknadna zakrpa.
U praksi, audit doprinosi kvalitetu softvera na više nivoa. On pomaže timu da otkrije greške u logici dozvola, da vidi da li korisnici rade ono što je očekivano, da prati izmene u produkciji, da kontroliše administratorske radnje i da analizira bezbednosne incidente. Ako korisnik tvrdi da “nije ništa obrisao”, audit može pokazati da li je zaista njegov nalog izvršio brisanje, u kom trenutku i sa kog okruženja. Ako se javi sumnja da je neko izneo podatke, audit pomaže da se vidi da li je postojao uvid, izvoz ili neobičan pristup. GDPR i srpski ZZPL traže da rukovalac i obrađivač sprovode mere koje obezbeđuju trajnu poverljivost, integritet, raspoloživost i otpornost sistema, a audit trail je jedan od najvažnijih praktičnih alata za ostvarivanje tih ciljeva.
Zašto je audit važan za praćenje korisnika
Praćenje korisnika ne znači samo marketing analitiku. U pravnom i bezbednosnom smislu, mnogo je važnije praćenje pristupa i radnji unutar sistema. To obuhvata pitanje ko je pristupio podacima, da li je pristup bio ovlašćen, da li je neko menjao sadržaj bez ovlašćenja i da li postoji trag koji to potvrđuje. GDPR u članu 29 propisuje da lice koje ima pristup podacima o ličnosti ne sme te podatke obrađivati osim po nalogu rukovaoca, osim ako drugačije zahteva pravo Unije ili države članice. Srpski ZZPL sadrži praktično istu logiku kroz obaveze rukovaoca i obrađivača da ograniče i zaštite obradu.
To je razlog zašto ozbiljan sistem ne sme da ima “slepe zone”. Ako više zaposlenih koristi iste administratorske naloge, ako nema evidencije uvida u osetljive zapise ili ako nije moguće razlikovati ko je izvršio koju radnju, firma ostaje bez realne kontrole. Audit omogućava i interni nadzor i kasniju proveru zakonitosti, a kod javnog sektora i nadležnih organa ZZPL to eksplicitno prepoznaje kao svrhu logovanja.
Ko sme da ima pristup audit podacima
Pristup audit zapisima ne treba da ima “svako iz IT-a”. Naprotiv, on mora biti strogo ograničen. Pristup bi trebalo da imaju samo lica koja za to imaju jasnu poslovnu i pravnu potrebu: na primer bezbednosni administrator, ovlašćeno lice za informacionu bezbednost, interni revizor, DPO kada je to relevantno za zaštitu podataka, rukovodilac sistema ili eksterni revizor kada postoji ugovoreni i legitimni osnov. GDPR i ZZPL polaze od principa da pristup podacima imaju samo lica koja postupaju po instrukcijama rukovaoca i u meri koja je nužna za svrhu obrade.
Važno je i da audit logovi sami po sebi često sadrže lične podatke: korisnički ID, IP adresu, vreme aktivnosti, identitet zaposlenog, detalje pristupa određenim zapisima. Zato i audit evidencije podležu pravilima zaštite podataka. To znači da moraju imati definisanu svrhu, rok čuvanja, mere zaštite i ograničen pristup. Ako logovi otkrivaju više nego što je potrebno ili su dostupni širokom krugu ljudi, i sami postaju bezbednosni i pravni rizik. GDPR princip minimizacije i bezbednosti obrade, kao i srpski ZZPL, ovde su direktno relevantni.
Kako se audit rešava u praksi
U praksi se audit rešava tako što se na nivou softvera unapred definišu događaji koji se moraju beležiti. To su obično: login, logout, failed login, create, update, delete, export, approve, revoke, change role, reset password, pristup poverljivim zapisima i administrativne akcije. Za svaku stavku treba čuvati najmanje identitet korisnika ili servisa, datum i vreme, tip radnje, objekat nad kojim je radnja izvršena i tehnički kontekst. Kod osetljivijih sistema dodaju se IP adresa, korisnički agent, razlog izmene, pre/posle vrednosti i identifikator sesije. Ovakav pristup je u skladu sa srpskim pravilima za posebne IKT sisteme, koja traže praćenje aktivnosti, reviziju i nadzor, kao i sprečavanje pristupa, izmene ili korišćenja sredstava bez ovlašćenja i bez evidencije o tome.
Dobar audit sistem ima još nekoliko važnih osobina. Prvo, zapisi ne smeju biti lako izmenjivi ili brisivi od strane običnih administratora. Drugo, vreme mora biti pouzdano sinhronizovano. Treće, rok čuvanja mora biti definisan internim aktom, procenom rizika i eventualnim sektorskim propisima. Četvrto, mora postojati procedura kako se logovi pregledaju, kako se izdvajaju za istragu i kako se štite od manipulacije. U ozbiljnijim sistemima se zbog toga koriste odvojena skladišta logova, write-once pristup, hash kontrola integriteta i vremenski žigovi. EU eIDAS propisuje da elektronskom vremenskom žigu ne može biti osporena dokazna snaga samo zato što je elektronski, a kvalifikovani elektronski vremenski žig uživa pretpostavku tačnosti datuma i vremena i integriteta podataka na koje je vezan; isto načelo postoji i u srpskom zakonu o elektronskom dokumentu.
Da li je audit validan dokaz pred institucijama
Da, audit može biti veoma važan dokaz, ali ne automatski i ne uvek sam za sebe. Njegova dokazna vrednost zavisi od toga kako je sistem projektovan, da li su logovi pouzdani, da li je moguće dokazati integritet zapisa, da li postoji kontrola pristupa tim zapisima, da li je vreme tačno i da li je lanac čuvanja evidencije uredan. Srpski Zakon o elektronskom dokumentu propisuje da se elektronskom dokumentu ne može osporiti punovažnost i dokazna snaga samo zato što je u elektronskom obliku, a isto načelo važi i za elektronski vremenski žig. Kod kvalifikovanog vremenskog žiga postoji zakonska pretpostavka tačnosti datuma i vremena i očuvanosti integriteta tih podataka.
Zato je najtačnije reći: audit log je validan elektronski dokazni materijal, ali njegova snaga raste ako je tehnički i proceduralno dobro obezbeđen. Ako imate log koji može menjati isti administrator čiji se rad proverava, taj log je mnogo slabiji. Ako imate centralizovane zapise, kontrolu integriteta, ograničen pristup, kvalifikovane vremenske žigove ili druge mehanizme dokazivanja neizmenjenosti, njegova vrednost je znatno veća. U sudskim, upravnim i internim postupcima upravo ti elementi često prave razliku između “indikacije” i ozbiljnog dokaza.
Da li je audit obavezan po EU i srpskim pravilima
Za sve privatne firme ne postoji jedna jedina opšta norma koja kaže da “svaki softver mora imati audit trail” u identičnom obliku. Međutim, u praksi do istog zaključka dolaziš kroz više propisa. GDPR i srpski ZZPL traže odgovarajuće tehničke i organizacione mere, integritet, poverljivost, kontrolu pristupa i sposobnost dokazivanja usklađenosti. Za određene sisteme i sektore logovanje je mnogo bliže stvarnoj obavezi nego opciji, jer bez njega ne možeš razumno dokazati zakonitost obrade ni bezbednost sistema. Za nadležne organe u posebnim svrhama srpski ZZPL eksplicitno propisuje beleženje radnji obrade. Za operatore IKT sistema od posebnog značaja srpska uredba traži praćenje aktivnosti, reviziju i nadzor. U EU kibernetičkom okviru, NIS2 i prateća pravila traže upravljanje rizicima, detekciju, odgovor i proveru efektivnosti mera, što u praksi gotovo nezamislivo funkcioniše bez kvalitetnih audit i security logova.
To znači da za firme koje razvijaju ili koriste ozbiljan poslovni softver audit najčešće nije pitanje “da li”, već “koliko detaljno i na kojim mestima”.
Ko može da napravi audit izveštaj u firmi
Audit izveštaj u firmi može praviti više različitih aktera, ali nije svaki izveštaj jednak po svrsi i težini. Interni audit izveštaj može pripremiti interni revizor, lice zaduženo za informacionu bezbednost, compliance tim, DPO kada je reč o zaštiti podataka ili odgovorno tehničko lice, pod uslovom da postoji odgovarajuće ovlašćenje, procedura i stručnost. Za dnevni operativni nadzor to je sasvim uobičajeno. Srpska uredba o merama zaštite IKT sistema posebno insistira na utvrđenim poslovima i odgovornostima zaposlenih i na procedurama za praćenje aktivnosti, reviziju i nadzor.
Ako firma želi izveštaj za regulatorne, ugovorne ili sporne situacije, često je bolje da audit izveštaj radi nezavisno interno odeljenje ili eksterni stručnjak / revizor. Kod ocene bezbednosti, usklađenosti ili dokaza pred trećim stranama nezavisnost izveštaja povećava njegovu težinu. Ipak, ni EU ni srpski propisi ne kažu da samo jedna određena profesija sme da napiše takav izveštaj u svim slučajevima. Presudni su stručnost, ovlašćenje, metodologija i pouzdanost izvora podataka na kojima je izveštaj zasnovan. Tamo gde propis traži formalno ocenjivanje usaglašenosti, sertifikaciju ili veštačenje, naravno važe posebna pravila za tačan tip postupka i ovlašćeno lice.
Šta bi jedan dobar audit izveštaj trebalo da sadrži
Dobar audit izveštaj ne bi trebalo da bude samo izvoz logova u Excel. On bi trebalo da sadrži opis sistema, svrhu provere, vremenski period, izvor i integritet evidencije, metodologiju pregleda, spisak relevantnih događaja, nalaze, ocenu rizika i preporuke. Ako se izveštaj koristi kao dokaz ili za institucije, korisno je navesti i kako su logovi prikupljeni, ko im je pristupao, da li su vremenski žigosani, da li su hashirani i gde su čuvani. Bez tih elemenata audit izveštaj može biti informativan, ali slabiji kao formalni dokaz. Načela integriteta, bezbednosti i odgovornosti iz GDPR-a i srpskog ZZPL upravo podržavaju ovakav pristup dokumentovanju.
Audit u softveru je jedan od temelja bezbednosti, usklađenosti i odgovornosti. On omogućava da firma zna ko je šta radio u sistemu, da zaštiti podatke, da prati ponašanje korisnika, da istraži incidente i da pripremi pouzdan izveštaj kada je to potrebno. Po EU i srpskim pravilima, audit nije samo tehnička preporuka, već veoma često praktično nužna mera za dokazivanje integriteta, zakonitosti i kontrole pristupa. Elektronski zapisi, elektronski dokumenti i vremenski žigovi mogu imati dokaznu snagu, ali njihova vrednost zavisi od toga koliko su dobro projektovani, zaštićeni i proceduralno uređeni.
