Zapisi o procjeni rizika, revizijski dokazi, ugovori, zdravstveni podaci, financijska izvješća i administrativni pristupni podaci često se nalaze u istim poslovnim sustavima. Jedan pogrešno dodijeljen pristup, kompromitirani korisnički račun ili izgubljena sigurnosna kopija mogu taj skup podataka pretvoriti u regulatorni, operativni i reputacijski problem. Enkripcija osjetljivih poslovnih podataka zato nije samo tehnička stavka na sigurnosnoj listi, nego kontrola koja odlučuje može li neovlaštena osoba pročitati podatke do kojih je došla.
Za upravu, CISO-a i odgovorne osobe za usklađenost ključno pitanje nije koristi li organizacija enkripciju negdje u svojoj infrastrukturi. Pitanje je jesu li točno određeni podaci zaštićeni odgovarajućom metodom, jesu li ključevi pod kontrolom organizacije te može li se ta zaštita dokazati tijekom nadzora ili nakon incidenta.
Što enkripcija stvarno štiti
Enkripcija pretvara čitljiv podatak u šifrirani oblik koji bez odgovarajućeg ključa nije razumljiv. Time se smanjuje posljedica neovlaštenog pristupa mediju, bazi podataka, datoteci ili mrežnom prometu. Važno je razlikovati enkripciju od kontrole pristupa: kontrola pristupa određuje tko smije otvoriti podatak, a enkripcija štiti podatak i kada netko zaobiđe ili kompromitira dio tog mehanizma.
Primjerice, višefaktorska autentifikacija može spriječiti prijavu napadača u korisnički račun, ali ne štiti nezaštićenu bazu koja je pogrešno izvezena u datoteku. Sigurnosna kopija može omogućiti oporavak nakon ransomwarea, ali postaje dodatni izvor rizika ako nije šifrirana. Učinkovita zaštita povezuje identitete, prava pristupa, enkripciju, nadzor i postupke odgovora na incidente.
Za regulirane organizacije enkripcija ima i dokaznu vrijednost. Nakon sigurnosnog događaja treba moći utvrditi jesu li izloženi podaci bili čitljivi, tko je imao pristup ključevima te jesu li evidentirani pokušaji dešifriranja. Ta razlika izravno utječe na procjenu rizika, opseg istrage i obveze izvješćivanja.
Enkripcija osjetljivih poslovnih podataka u tri sloja
Podaci nisu izloženi samo kada se nalaze u glavnoj aplikaciji. Kreću se između korisnika, aplikacija, lokacija za pohranu i vanjskih pružatelja usluga. Zato zaštitu treba planirati prema stanju podatka, a ne prema jednom proizvodu ili poslužitelju.
Podaci u prijenosu
Podaci u prijenosu putuju mrežom: između preglednika i poslovne aplikacije, između integriranih sustava, prema udaljenim korisnicima ili prema vanjskim servisima. Zaštita transportnim enkripcijskim protokolima sprječava presretanje i izmjenu prometa, pod uvjetom da su certifikati, konfiguracija i verzije protokola pravilno upravljani.
Česta pogreška je pretpostaviti da HTTPS rješava cijeli problem. On štiti komunikaciju do aplikacije, ali ne rješava preširoke ovlasti unutar aplikacije, nezaštićene izvoze ni nešifriranu pohranu nakon primitka podatka. Jednako vrijedi za integracije: API pristup mora koristiti snažnu autentifikaciju, ograničene ovlasti i evidentiranje aktivnosti.
Podaci u mirovanju
Podaci u mirovanju uključuju baze podataka, datotečne sustave, dokumentne repozitorije, prijenosna računala, mobilne uređaje i sigurnosne kopije. Enkripcija na razini diska korisna je zaštita od krađe fizičkog uređaja, ali nije uvijek dovoljna za zaštitu posebno osjetljivih polja unutar poslovne aplikacije.
Ako korisnik ili administrator ima pristup aktivnom sustavu, enkripcija cijelog diska najčešće neće ograničiti njegov uvid u podatke koje aplikacija već može pročitati. Zato za podatke poput identifikacijskih brojeva, zdravstvenih nalaza, bankovnih podataka, tajni ugovora ili revizijskih priloga treba razmotriti enkripciju na razini baze, tablice, zapisa ili pojedinog polja.
Takav pristup smanjuje izloženost kada dođe do neovlaštenog izvoza baze, pogrešno dodijeljenih administrativnih prava ili kompromitiranog skladišta podataka. Istodobno zahtijeva pažljivo projektiranje jer može utjecati na pretraživanje, izvještavanje i integracije.
Podaci tijekom obrade
Podatak je tijekom obrade najteže zaštititi jer ga aplikacija mora moći koristiti u čitljivom obliku. Tu najveću ulogu imaju segmentacija sustava, najmanje potrebne ovlasti, upravljanje privilegiranim računima, izolacija radnih okruženja i detaljni zapisi aktivnosti.
Nije realno očekivati da enkripcija sama ukloni svaki rizik. Ako napadač preuzme ovlasti korisnika koji legitimno smije čitati podatke, sadržaj će mu često biti dostupan. Zato enkripciju treba povezati s otkrivanjem anomalija, ograničenjem masovnih izvoza, periodičnim pregledom prava i jasnim postupkom opoziva pristupa.
Ključevi su važniji od algoritma
Organizacije često raspravljaju o nazivima algoritama, a zanemaruju pitanje tko upravlja ključevima. Bez sigurnog stvaranja, pohrane, korištenja, rotacije i opoziva ključeva, enkripcija ostaje samo djelomična zaštita.
Ključevi ne bi smjeli biti pohranjeni zajedno s nešifriranim kopijama podataka niti ugrađeni u programski kôd, skripte ili konfiguracijske datoteke. Pristup ključevima mora biti strogo ograničen, evidentiran i odvojen od svakodnevnih korisničkih ovlasti. Posebno je važno unaprijed definirati postupak za gubitak ključa, promjenu pružatelja usluge, odlazak administratora i oporavak nakon incidenta.
Kod korištenja usluga u oblaku treba provjeriti tko operativno kontrolira ključeve, u kojoj se jurisdikciji pohranjuju podaci, postoje li zapisi o korištenju ključeva i može li organizacija dokazati vlastite sigurnosne zahtjeve. Odgovor nije uvijek isti. Manja organizacija može opravdano koristiti upravljanu uslugu uz dobro ugovorene kontrole, dok subjekt s visokim rizikom može zahtijevati vlastitu kontrolu ključeva, EU hosting ili implementaciju u vlastitom okruženju.
Kako povezati enkripciju s NIS2 i nacionalnim obvezama
NIS2 i hrvatski propisi o kibernetičkoj sigurnosti ne svode upravljanje rizicima na jednu kontrolu. Od organizacija se očekuju primjerene i proporcionalne mjere koje štite mrežne i informacijske sustave, upravljaju rizicima u lancu opskrbe, osiguravaju kontinuitet te omogućuju pravodobno otkrivanje i prijavu incidenata.
Enkripcija se u tom okviru procjenjuje prema kontekstu. Potrebno je pokazati koje kategorije podataka postoje, gdje se obrađuju, kako je procijenjen njihov rizik i koje su mjere odabrane. Za osjetljive podatke nije dovoljno napisati da je sustav šifriran. Dokumentacija treba obuhvatiti opseg zaštite, odgovornosti, upravljanje ključevima, iznimke, periodične provjere i dokaz da su kontrole stvarno aktivne.
Takav pristup smanjuje administrativni teret tijekom revizije. Umjesto naknadnog prikupljanja snimki zaslona, procedura i zapisa iz više timova, organizacija održava strukturiran skup dokaza povezan s procjenom rizika i konkretnim mjerama. Ako se utvrdi neusklađenost, mora postojati vlasnik aktivnosti, rok i provjerljiv zapis provedbe.
Praktičan redoslijed uvođenja
Prvi korak nije kupnja novog alata, nego popis podataka i tokova. Organizacija treba utvrditi koje podatke smatra osjetljivima, gdje se nalaze, tko im pristupa, prenose li se izvan organizacije i postoje li njihove kopije u testnim okruženjima ili sigurnosnim kopijama.
Nakon toga slijedi klasifikacija prema poslovnoj šteti i regulatornim obvezama. Nisu svi podaci jednako vrijedni niti je svaku datoteku potrebno štititi istom razinom kontrole. Prestroga primjena može otežati rad i potaknuti zaposlenike da traže neslužbene načine razmjene podataka. Preslaba primjena ostavlja najvrjedniju imovinu izloženu. Cilj je razmjerna zaštita koja je provediva u svakodnevnom radu.
Treći korak je odabir kontrola: enkripcija prijenosa, pohrane, sigurnosnih kopija i, gdje rizik opravdava, pojedinačnih polja. Zatim treba imenovati odgovorne osobe za ključeve i administraciju, postaviti pravila rotacije te uključiti nadzor nad neuspjelim i neuobičajenim pokušajima pristupa.
Na kraju, organizacija treba redovito testirati može li oporaviti šifrirane podatke i može li dokazati djelovanje kontrola. Test oporavka nije formalnost. Neupotrebljiva sigurnosna kopija ili nedostupan ključ u kriznom trenutku mogu zaustaviti poslovanje jednako učinkovito kao i sam napad.
Platforme za upravljanje usklađenošću mogu taj proces učiniti preglednim povezivanjem procjene rizika, dokaza, nesukladnosti i plana aktivnosti. ITrevizija.hr pritom koristi EU hosting, interne AI modele i enkripciju na razini polja za zaštitu osjetljivih sadržaja koji ulaze u proces usklađivanja i revizijskog dokazivanja.
Enkripcija donosi stvarnu vrijednost tek kada je dio svakodnevne upravljačke discipline: kada su podaci klasificirani, ključevi pod nadzorom, iznimke odobrene, a dokazi spremni prije nego što ih zatraži regulator ili ih nametne incident.