Hakirana web stranica i GDPR: što firma treba napraviti

Zamislimo webshop na WordPressu. Kupci otvaraju korisničke račune, ostavljaju imena, e-mail adrese i adrese za dostavu. Plaćanje je povezano s vanjskim pružateljem platne usluge, a pitanja stižu kroz kontakt-formu.

Jednog jutra netko iz firme primijeti da stranica dio posjetitelja preusmjerava na nepoznatu adresu. U administraciji se pojavljuje korisnički račun koji nitko iz tima nije otvorio.

Ovo nije stvaran slučaj, nego zamišljeni scenarij kroz koji je lakše pratiti što firma treba napraviti.

Prvi instinkt je razumljiv: nazvati osobu koja održava web i što prije vratiti stranicu u normalno stanje. To je važno. Preusmjeravanje treba zaustaviti, pristup ograničiti, a korisnike zaštititi od daljnje štete.

Ali ako se cijela reakcija svede na vraćanje backupa i brisanje nepoznatog računa, firma je riješila samo ono što se vidi izvana. Još ne zna kako je netko ušao, koliko je dugo imao pristup, što mu je bilo dostupno i jesu li osobni podaci kupaca mogli biti zahvaćeni.

Tu tehnički problem postaje i poslovno pitanje. A ako su u sustavu osobni podaci, otvara se i pitanje GDPR-a.

Ovaj tekst daje praktičan okvir za prvo postupanje. Ne zamjenjuje sigurnosnu istragu, procjenu konkretnog slučaja ni pravni savjet.

Prvo treba zaustaviti štetu, ali ne i izbrisati tragove

Preusmjeravanje i nepoznat administratorski račun znakovi su da nešto treba odmah provjeriti. Još nisu potpuna dijagnoza.

Netko je možda iskoristio ranjivi dodatak i promijenio samo dio sadržaja. Možda je preuzeo administratorski račun. Možda je pristupio bazi podataka ili izmijenio način na koji checkout i obrasci rade. Moguće je i da vidljivi problem uopće nije napad, nego ozbiljna tehnička greška.

Zato nije dobro naslijepo brisati datoteke, korisnike i zapise samo da bi stranica izgledala normalno. Time se mogu ukloniti tragovi koji pomažu utvrditi što se dogodilo.

U našem zamišljenom webshopu prvi koraci odvijaju se zajedno:

• bilježi se kada je problem uočen i što se točno vidjelo
• spremaju se snimke zaslona, obavijesti hostinga i dostupni zapisi
• prema potrebi se privremeno ograničava pristup stranici ili pojedinim funkcijama
• uključuje se osoba koja može stručno provjeriti kompromitaciju
• obavještavaju se odgovorne osobe unutar firme

Cilj nije da vlasnik ili zaposlenik sam provodi forenziku. Cilj je zaustaviti očitu štetu bez pretpostavke da je nestankom preusmjeravanja incident završen.

Tehnička sanacija i GDPR procjena dva su povezana zadatka

Dok sigurnosni stručnjak ili tehnički partner provjerava kako je došlo do pristupa, firma mora otvoriti drugo pitanje: jesu li osobni podaci mogli biti izgubljeni, izmijenjeni, uništeni, neovlašteno otkriveni ili dostupni neovlaštenoj osobi?

AZOP povredu osobnih podataka opisuje upravo kroz te moguće posljedice. Povreda se ne svodi samo na krađu cijele baze. Može se odnositi na povjerljivost, cjelovitost ili dostupnost podataka.

U webshopu bi mogli biti zahvaćeni:

• imena, e-mail adrese i adrese kupaca
• telefonski brojevi i povijest narudžbi
• korisnički računi i podaci za prijavu
• poruke i privici poslani kroz kontakt-formu
• podaci iz newslettera, povrata ili reklamacija
• administracijski pristupi koji vode prema drugim sustavima

Firma u ovom primjeru vjeruje da brojeve kartica ne pohranjuje jer se plaćanje odvija kod vanjskog pružatelja. To je važna informacija, ali nije dovoljan zaključak. Treba provjeriti kako je plaćanje stvarno povezano s webshopom i je li kompromitirana stranica mogla izmijeniti checkout, ubaciti zlonamjernu skriptu ili preusmjeriti kupca tijekom unosa podataka.

Vanjski sustav za plaćanje može smanjiti količinu podataka koje webshop obrađuje, ali ne dokazuje sam po sebi da podaci tijekom incidenta nisu mogli biti zahvaćeni.

Nije svako hakiranje povreda osobnih podataka

Ovo razlikovanje vrijedi sačuvati kroz cijeli postupak.

Tehnički kvar nije automatski sigurnosni incident. Sigurnosni incident nije automatski povreda osobnih podataka. Povreda osobnih podataka nije automatski razlog za obavještavanje svih kupaca ni automatska kazna.

U našem primjeru istraga može pokazati različite ishode.

Možda je napadač promijenio javni sadržaj stranice, ali nije mogao pristupiti dijelu sustava u kojem se nalaze osobni podaci. Tada se može raditi o sigurnosnom incidentu koji treba sanirati i interno evidentirati, ali ne nužno o povredi osobnih podataka.

Druga je mogućnost da je neovlaštena osoba imala pristup bazi kupaca, promijenila podatke, izvezla ih ili onemogućila pristup. Tada je riječ o povredi osobnih podataka koju treba procijeniti prema mogućim posljedicama za ljude.

Razlika se ne utvrđuje osjećajem ni rečenicom „nemamo dokaz da je nešto preuzeto”. Utvrđuje se dostupnim zapisima, tehničkom analizom, opsegom pristupa i drugim činjenicama koje se mogu prikupiti.

Kada počinje teći rok od 72 sata

Rok od 72 sata često se spominje kao da počinje čim se na stranici pojavi prvi čudan oglas. Nije baš tako. Ali nije točno ni da firma može čekati završetak potpune forenzičke istrage prije nego što počne razmišljati o prijavi.

Prema smjernicama Europskog odbora za zaštitu podataka, organizacija se smatra upoznatom s povredom kada postoji razuman stupanj sigurnosti da se dogodio sigurnosni incident koji je kompromitirao osobne podatke.

U našem webshopu prvi znak preusmjeravanja pokreće hitnu provjeru. Ako se ubrzo utvrdi da je neovlašteni administrator imao pristup podacima kupaca ili postoji razuman stupanj sigurnosti da su mu bili dostupni, firma više ne bi trebala čekati da sazna svaki detalj napada prije razmatranja prijave.

Ako je vjerojatno da će povreda prouzročiti rizik za prava i slobode pojedinaca, voditelj obrade mora bez nepotrebnog odgađanja i, ako je izvedivo, najkasnije u roku od 72 sata od saznanja za povredu izvijestiti AZOP. Ako sve informacije još nisu poznate, dostupne se informacije mogu poslati prvo, a ostale dopuniti naknadno.

Zato je važno zabilježiti ne samo kada je primijećen prvi simptom nego i kada je firma stekla razuman stupanj sigurnosti da su osobni podaci kompromitirani. Ta dva trenutka ne moraju biti ista.

Tko je za što odgovoran ako web održava vanjski partner

U našem primjeru webshop održava vanjska agencija, a hosting pruža treća firma. To ne znači da je sva odgovornost automatski prebačena na jednog od njih. Jednako tako ne znači da vanjski partneri nemaju vlastite obveze.

Za GDPR su važne stvarne uloge.

Firma koja određuje svrhe i sredstva obrade podataka kupaca u pravilu je voditelj obrade. Vanjski partner koji te podatke obrađuje prema njezinim dokumentiranim uputama može biti izvršitelj obrade. Stvarne uloge ovise o načinu rada i ugovoru, a ne samo o nazivu usluge.

Članak 33. GDPR-a propisuje da izvršitelj obrade nakon saznanja za povredu osobnih podataka mora bez nepotrebnog odgađanja obavijestiti voditelja obrade. To nije isto što i tvrdnja da svaka tehnička sumnja već predstavlja potvrđenu GDPR povredu.

U praksi je ipak korisno ugovoriti ranije upozorenje. Održavatelj bi trebao odmah prijaviti sumnjivu aktivnost kako bi firma mogla započeti procjenu, umjesto da prvi put sazna za incident tek nakon tehničke sanacije.

Firma zato prije incidenta treba znati:

• tko ima pristup domeni, hostingu, administraciji i backupima
• tko prvi obavještava koga o sumnjivoj aktivnosti
• tko može odlučiti o privremenom gašenju dijela sustava
• tko procjenjuje utjecaj na osobne podatke
• tko priprema prijavu i komunikaciju ako su potrebne

Ugovor s agencijom ili hostingom ne bi trebao biti mjesto na kojem se nakon incidenta tek pokušava pronaći odgovor na ta pitanja.

Kada se obavještava AZOP, a kada i pogođene osobe

Nakon potvrde povrede osobnih podataka slijedi procjena rizika.

Ako je vjerojatno da će povreda prouzročiti rizik za prava i slobode pojedinaca, voditelj obrade izvješćuje AZOP. Ako je vjerojatan visok rizik, u pravilu treba bez nepotrebnog odgađanja obavijestiti i pogođene osobe jasnim i jednostavnim jezikom.

Pri procjeni se ne gleda samo broj zapisa. Važni su vrsta i osjetljivost podataka, mogućnost identifikacije ljudi, moguće posljedice, trajanje i opseg pristupa, ranjivost pogođenih osoba te mjere koje su već štitile podatke.

Primjerice, kombinacija imena, adrese, e-maila i podataka o narudžbama može pomoći napadaču sastaviti uvjerljivu phishing poruku. Rizik može biti veći ako su kompromitirane i lozinke, ako se iste lozinke koriste drugdje ili ako podaci otkrivaju osjetljive okolnosti.

Obavještavanje pogođenih osoba nije potrebno u svakoj situaciji visokog početnog rizika. Članak 34. GDPR-a predviđa iznimke, primjerice kada su na zahvaćene podatke primijenjene učinkovite mjere poput enkripcije koje ih čine nerazumljivima neovlaštenoj osobi ili kada su naknadne mjere uklonile vjerojatnost visokog rizika. Procjena tih uvjeta ovisi o konkretnom slučaju.

Prijava AZOP-u nije automatski dokaz krivnje niti sama po sebi znači kaznu. Ona je obveza kada su ispunjeni uvjeti. Odvojeno od prijave može se procjenjivati jesu li prije incidenta postojale primjerene tehničke i organizacijske mjere te kako je firma reagirala nakon saznanja.

Što treba zapisati čak i kada prijava nije potrebna

Ovdje treba razlikovati dvije situacije.

Ako je utvrđena povreda osobnih podataka, voditelj obrade mora je dokumentirati i kada procjena pokaže da prijava AZOP-u nije potrebna. Zapis treba sadržavati činjenice o povredi, njezine posljedice, poduzete mjere i obrazloženje odluke o prijavi i obavještavanju.

Ako se nakon provjere pokaže da osobni podaci uopće nisu bili zahvaćeni, možda ne postoji povreda osobnih podataka u smislu članka 33. Ipak, razumno je interno zabilježiti sigurnosni incident: što je uočeno, što je provjereno, zašto je zaključeno da podaci nisu kompromitirani i koje su mjere poduzete.

U našem zamišljenom webshopu takav zapis može sadržavati:

• datum i vrijeme prvog simptoma
• trenutak kada je potvrđen sigurnosni incident ili povreda osobnih podataka
• zahvaćene sustave i vrste podataka
• osobe i vanjske partnere uključene u odgovor
• dostupne nalaze i ograničenja istrage
• procjenu rizika i donesene odluke
• mjere sanacije i daljnje preporuke

To ne mora biti opsežan pravni dokument. Mora biti dovoljno jasan da se kasnije može razumjeti na temelju čega je donesena odluka.

Redoslijed koji firma može slijediti prvog dana

Vratimo sve dosadašnje dijelove u jedan poslovni redoslijed.

1. Zabilježite simptom i vrijeme. Sačuvajte što ste vidjeli, tko je primijetio problem i koje su obavijesti stigle.
2. Ograničite očitu štetu. Prema stručnoj procjeni privremeno onemogućite ugrožene funkcije ili pristup stranici, ali nemojte naslijepo uklanjati tragove.
3. Uključite potrebne ljude. Obavijestite održavatelja, hosting, odgovornu osobu u firmi, osobu zaduženu za zaštitu podataka ako je imate te sigurnosnog i pravnog stručnjaka prema okolnostima.
4. Napravite mapu povezanih sustava. Webshop, baza, kontakt-forma, mail, newsletter, CRM, platni sustav, backup i administratorski računi mogu biti dio istog događaja.
5. Provjerite jesu li osobni podaci mogli biti zahvaćeni. Ne tražite samo dokaz preuzimanja baze. Provjeravajte pristup, otkrivanje, izmjenu, gubitak i nedostupnost.
6. Zabilježite kada je povreda postala dovoljno izvjesna. Taj je trenutak važan za rokove i naknadno obrazloženje postupanja.
7. Procijenite rizik i donesite odluke. Utvrdite treba li prijaviti AZOP-u, obavijestiti pogođene osobe i koje mjere mogu smanjiti daljnju štetu.
8. Vratite sustav tek nakon razumne provjere. Backup treba biti čist, pristupi pregledani, a ključne funkcije poput prijave, forme i checkouta testirane.

Ovaj popis nije tehnička uputa za uklanjanje napadača. On pomaže da poslovna reakcija ne stane na rečenici „web ponovno radi”.

Nakon sanacije ostaju odluke koje ne treba odgađati

Kada je webshop ponovno stabilan, posao još nije sasvim gotov.

Treba provjeriti tko ima administratorske račune, ukloniti nepotrebne pristupe, promijeniti kompromitirane vjerodajnice i uključiti višefaktorsku autentifikaciju gdje je moguće. Treba razumjeti kako je do incidenta došlo, jesu li uklonjeni uzrok i trajni pristupi napadača te koliko je pouzdan backup iz kojeg se sustav vraća.

Povezani sustavi također zaslužuju provjeru. Ako se ista lozinka koristila na webu i drugdje, problem nije nužno ostao unutar WordPressa. Ako je administrator imao pristup mailu, hostingu ili bazi, opseg može biti širi od same naslovnice.

Na organizacijskoj strani treba dogovoriti tko ubuduće prati sigurnosne obavijesti, tko instalira zakrpe, kako partner prijavljuje sumnjivu aktivnost, koliko se dugo čuvaju zapisi i tko vodi postupak ako se incident ponovi. Za preventivni dio koristan je i vodič Cyber sigurnost: prvi koraci za sigurniji web, mail i podatke.

Neke mjere mogu biti jednostavne. Dublja istraga, sanacija ili promjena arhitekture mogu zahtijevati specijalizirano znanje i ozbiljniji zahvat. Nije korisno unaprijed obećati da se svaki incident može riješiti brzo i bez troška.

Web ponovno radi, ali odgovor završava tek kada je priča jasna

Na kraju našeg zamišljenog slučaja postoje barem dvije moguće završnice.

U prvoj tehnička analiza pokaže da je napadač izmijenio javni sadržaj, ali nije mogao pristupiti osobnim podacima. Firma evidentira sigurnosni incident, uklanja uzrok, sređuje pristupe i zapisuje zašto nije utvrđena povreda osobnih podataka.

U drugoj se potvrdi da je neovlaštena osoba imala pristup podacima kupaca. Firma procjenjuje rizik, dokumentira povredu i, ako su ispunjeni uvjeti, prijavljuje je AZOP-u te procjenjuje treba li obavijestiti pogođene osobe.

U obje završnice povratak naslovnice nije bio kraj posla.

Dobar odgovor na incident završava tek kada firma može jasno odgovoriti: što se dogodilo, koji su sustavi i podaci bili zahvaćeni, kako je smanjena šteta, na temelju čega su donesene odluke i što se mijenja da bi sljedeća reakcija bila bolja.

Najbolji trenutak za dogovor o tim odgovornostima nije jutro nakon hakiranja. Ali ako dogovor još ne postoji, incident je trenutak kada ga više ne treba odgađati.

Često postavljana pitanja

Mora li se svaka hakirana web stranica prijaviti AZOP-u?

Ne. Prvo treba utvrditi je li sigurnosni incident zahvatio osobne podatke. Ako postoji povreda osobnih podataka, procjenjuje se rizik za prava i slobode pojedinaca. Prijava AZOP-u potrebna je kada je vjerojatno da će povreda prouzročiti takav rizik.

Kada počinje rok od 72 sata?

Kada voditelj obrade stekne razuman stupanj sigurnosti da se dogodio sigurnosni incident koji je kompromitirao osobne podatke. Rok ne mora početi pri prvom neobičnom simptomu, ali se ne čeka završetak potpune istrage ako je povreda već dovoljno izvjesna.

Tko je odgovoran ako web održava vanjska agencija?

Odgovor ovisi o stvarnim ulogama i ugovoru. Firma koja određuje svrhe i način obrade najčešće je voditelj obrade, a održavatelj može biti izvršitelj. Izvršitelj mora bez nepotrebnog odgađanja obavijestiti voditelja nakon saznanja za povredu osobnih podataka, dok voditelj donosi odluke o prijavi i obavještavanju.

Izvori i granice teksta

• AZOP: Izvješćivanje o povredi osobnih podataka
• EDPB: Povrede osobnih podataka — vodič za mala i srednja poduzeća
• EDPB: Smjernice 9/2022 o izvješćivanju o povredi osobnih podataka
• GDPR — Uredba (EU) 2016/679, osobito članci 32, 33, 34 i 83

Tekst obrađuje opći odnos sigurnosnog incidenta i GDPR obveza. Pojedine organizacije mogu imati i dodatne ugovorne, sektorske ili regulatorne obveze. Za stvarni incident treba provesti tehničku i pravnu procjenu konkretnog slučaja.