Curenje podataka: što napraviti u prva 72 sata i kako to spriječiti

Ponedjeljak ujutro. Netko iz podrške javi da se u sustavu događa nešto čudno: zahtjevi s nepoznatih adresa, računi koje nitko ne prepoznaje, promet u tri ujutro. Za nekoliko sati jasno je da netko ima pristup koji ne bi smio imati.

U tom trenutku nitko ne pita tko je to bio. Svi pitaju isto: što je vidio?

Sat otkucava od prvog trenutka

Ako su u igri osobni podaci kupaca ili korisnika, GDPR traži da povredu prijavite nadzornom tijelu, u Hrvatskoj AZOP-u, bez odgađanja i najkasnije 72 sata od trenutka kad ste za nju saznali. Ako je rizik za ljude visok, morate obavijestiti i njih.

Da biste to mogli, morate znati odgovor na tri pitanja: do kojih je podataka napadač mogao doći, do kojih je stvarno došao i je li još unutra. Ako ne znate, jedino pošteno je pretpostaviti najgore, da je vidio sve. A “sve” znači pisati svim kupcima.

Razlika između “vidio je deset zapisa” i “morali smo obavijestiti sve kupce” ne odlučuje se na dan napada. Odlučuje se mjesecima prije, u načinu na koji je aplikacija napravljena.

Rupe koje napadači stvarno koriste

Napadi na poslovne aplikacije rijetko izgledaju kao u filmu. Najčešće ne treba nikakva genijalnost, nego ulazak kroz vrata koja je netko ostavio otvorena:

• Lozinke spremljene kao običan tekst. Tko dođe do baze, ima sve lozinke. A korisnici iste lozinke koriste za e-mail i banku, pa curenje ne završava kod vas. Lozinke se nikad ne spremaju, sprema se samo njihov otisak iz kojeg se lozinka ne može vratiti.
• Aplikacija šalje više nego što ekran pokazuje. Ekran prikazuje ime i e-mail, a u pozadini aplikacija pošalje cijeli zapis, s poljima koja nitko ne vidi osim onoga tko pogleda. Napadač uvijek pogleda.
• Tuđi podaci na promjenu broja. Promijenite broj narudžbe u adresi i vidite tuđu narudžbu. Zvuči previše jednostavno da bi bilo istina, a upravo neispravna kontrola pristupa stoji na vrhu OWASP-ove liste najčešćih sigurnosnih rizika web aplikacija.
• Neograničen broj pokušaja. Bez ograničenja napadač može isprobavati lozinke ili brojeve tisuće puta u minuti, sve dok nešto ne upali.
• Otvorena samoregistracija. Ako se svatko može registrirati, napadač ne mora provaljivati. Otvori račun i gleda što sve korisnik iznutra može dohvatiti.
• Administracija dostupna s cijelog interneta. Sučelje koje treba petorici ljudi iz firme, a do kojeg može doći bilo tko na svijetu.
• Logovi iz kojih se ništa ne vidi. Aplikacija bilježi greške, ali ne i tko je što dohvatio. Na dan incidenta to je razlika između odgovora i nagađanja.

Kad se dogodi: redoslijed

1. Zatvori vrataPrekinuti pristup, promijeniti ključeve
2. Utvrdi što je viđenoIz logova, a ne nagađanjem
3. ObavijestiNadzorno tijelo i, po potrebi, ljude
4. Popravi uzrokeDa se isto ne ponovi

1. Zatvorite vrata. Prekinite pristup koji ne bi smio postojati: ugasite sporne račune, promijenite lozinke, ključeve i tokene koje je napadač mogao vidjeti. Brzo, ali bez brisanja tragova.
2. Utvrdite što je viđeno. Iz logova složite što je napadač radio, do kojih je podataka došao i od kada. Ovaj korak odlučuje o svemu ostalom.
3. Obavijestite. Nadzorno tijelo u roku, a ljude kojih se to tiče kad je rizik visok. Jasno i iskreno: što se dogodilo, koji podaci su pogođeni i što poduzimate.
4. Popravite uzroke. Ne samo rupu kroz koju je ušao, nego i sve slične. Napadač koji je našao jedna otvorena vrata sigurno je probao i ostala.

10 pitanja koja danas možete postaviti svom timu

Ne morate znati programirati da biste ih postavili. Morate samo inzistirati na jasnom odgovoru:

1. Kako spremamo lozinke korisnika? Dobar odgovor je: kao otisak (hash), nikad kao tekst.
2. Vraća li aplikacija samo podatke koje ekran stvarno treba?
3. Provjerava li aplikacija kod svakog zahtjeva smije li ovaj korisnik vidjeti baš ovaj zapis?
4. Koliko pokušaja prijave dopuštamo prije blokade?
5. Može li se bilo tko registrirati, i što vidi nakon toga?
6. Tko može doći do administracije, i odakle?
7. Imaju li administratori prijavu u dva koraka?
8. Kad bi sutra netko ušao, bismo li iz logova znali što je vidio? Koliko dugo čuvamo logove?
9. Kad smo zadnji put nadogradili biblioteke s poznatim ranjivostima?
10. Tko je odgovoran ako se incident dogodi u tri ujutro, i zna li što treba napraviti?

Ako na više od dva pitanja dobijete “ne znam” ili “trebalo bi biti u redu”, znate gdje početi.

Kako mi radimo

ProCoding je .NET studio iz Splita. Radimo sigurnosne preglede poslovnih aplikacija na .NET-u, ASP.NET Coreu, Blazoru i SQL Serveru. Prolazimo kod, API-je, prijavu i ovlasti, logove i postavke, a vi dobivate popis rupa poredanih po riziku, s prijedlogom popravka za svaku.

A kad se incident već dogodi, pomažemo u onome najhitnijem: zatvoriti vrata, iz logova utvrditi što je napadač vidio i popraviti uzroke. Prvi korak je besplatni razgovor od 30 minuta.

Izvori

• Opća uredba o zaštiti podataka (GDPR), članci 33. i 34., EUR-Lex
• OWASP Top 10:2025, OWASP Foundation