Maskiranje i redakcija
Pri upitu ili izvozu osetljiva vrednost se menja. Originalni podaci mogu ostati u sistemu. Korisno za različite uloge, ali nije dokaz anonimizacije.
Anonimizacija i pseudonimizacija podataka: razlike u praksi
Kada je podatak anoniman, a kada samo pseudonimizovan? Primeri sa tokenizacijom, hashing metodama i kontrolom pristupa.
5. novembar 2026.
- Pseudonimizovani podaci mogu i dalje predstavljati podatke o ličnosti.
- Masking ne uklanja nužno izvorni identifikator.
- Tokenizacija zahteva odvojeno čuvanje mape i kontrolu pristupa.
Presudno je da li osoba i dalje može da se identifikuje
Kod pseudonimizacije se direktni identifikatori zamenjuju, a dodatne informacije za povezivanje sa osobom čuvaju odvojeno. Ako se identitet uz te informacije može utvrditi, podaci i dalje predstavljaju podatke o ličnosti.
Anonimizacija zahteva da se identitet ne može utvrditi razumno dostupnim sredstvima. Presudna je procena rizika u konkretnom skupu podataka, a ne naziv formata u koji su podaci izvezeni.
Zašto hashing ne znači automatsku anonimizaciju
Obrada e-mail adrese ili korisničkog broja brzom hash funkcijom često nije dovoljna. Isti ulaz daje isti rezultat, a mali skup mogućih vrednosti omogućava napade rečnikom. Stabilni identifikatori mogu povezivati zapise iz različitih baza.
Za kontrolisano povezivanje mogu biti primereni nasumični tokeni ili kriptografske metode sa zaštićenim ključevima. Ako je moguće ponovno povezivanje sa osobom, postupak ostaje pseudonimizacija.
Četiri postupka sa različitim zaštitnim svojstvima
Pseudonimizacija tokenom ili HMAC-om
Direktni identifikatori zamenjuju se vrednostima koje se mogu povezati preko zasebno čuvane mape ili tajnog ključa. Podaci i dalje mogu biti lični.
Agregacija i generalizacija
Pojedinačne vrednosti postaju grupe ili intervali. Korisnost ostaje, ali je potrebno proveriti male grupe i retke kombinacije.
Anonimizacija
Cilj je onemogućiti identifikaciju uz realno dostupne izvore i metode. To je rezultat procene rizika, ne marketinški naziv funkcije.
Model pretnji: identifikacija bez imena
Treba razlikovati tri načina napada: izdvajanje pojedinca iz skupa (*singling out*), povezivanje zapisa kroz više izvora (*linkability*) i zaključivanje osetljivih svojstava iz drugih polja (*inference*). Brisanje imena ne uklanja nužno nijedan od ovih rizika. Retka kombinacija datuma rođenja, lokacije i iznosa osiguranja može biti dovoljna da se osoba prepozna.
Važno je ko prima podatke. Interni tim možda poseduje CRM, spoljni istraživač javne podatke, a tehnički dobavljač logove ili stare eksportovane fajlove. Procena zato mora obuhvatiti svrhu, primaoca, dodatne izvore i realne pristupne puteve.
Hashing se posebno često precenjuje. Ograničen skup e-mail adresa ili brojeva polisa omogućava izračunavanje mogućih kandidata. Deterministički identifikatori mogu povezivati evidencije iz različitih sistema i kada izvorna vrednost nije direktno čitljiva.
Primer sa HMAC i nasumičnim tokenom (Python)
# Demonstracija: nije produkcioni servis za tokenizaciju
import secrets
import hmac
import hashlib
secret = secrets.token_bytes(32) # U produkciji: KMS/Vault
person_id = "synthetic-member-101"
join_key = hmac.new(
secret, person_id.encode(), hashlib.sha256
).hexdigest()
random_token = secrets.token_urlsafe(24)
print(join_key[:12], random_token)
# Mapu povezivanja i ključeve ne čuvati u analitičkom sistemu.Šta HMAC primer prikazuje, a šta ne
Primer generiše deterministički `join_key` pomoću HMAC-SHA-256 i zaseban nasumični token. Kod HMAC-a ista ulazna vrednost i isti ključ daju isti rezultat. Nasumični token nema neposrednu matematičku vezu sa izvornom vrednošću ako je mapa za povezivanje odvojeno čuvana.
Operativni zahtevi su različiti. HMAC ključ se čuva u KMS-u ili Vault-u uz kontrolu pristupa i rotaciju. Tokenizacija zahteva zaštićen servis za mapiranje, proveru prava, stabilno čuvanje i brisanje. Privremeni demo ključ nije produkcioni dizajn: promena ključa menja rezultate i može prekinuti povezivanje podataka kroz vreme.
Nijedan postupak sam po sebi ne uklanja osetljivost zdravstvenih zapisa ili finansijskih događaja. Pseudonimizacija štiti direktni identitet, ali ne znači automatski anonimizaciju istorije pojedinca.
Primer: tokenizacija sa odvojeno zaštićenom mapom
# Ilustracija; nije produkcioni servis za tokenizaciju
import secrets
identity_id = "synthetic-member-101"
token = secrets.token_urlsafe(24)
# Mapa se čuva u zasebno zaštićenom servisu.
protected_mapping = {token: identity_id}
# Analitika dobija samo minimizovani zapis.
analytics_record = {
"member_token": token,
"fund_id": "FUND-A",
"accrued_pension_eur": 128500.00,
}
assert "identity_id" not in analytics_record
# U produkciji: prava, enkripcija, trajno čuvanje,
# audit, životni ciklus i brisanje.Tehnička arhitektura toka podataka
Operativni sistem identiteta upravlja ličnim podacima. Kontrolisana transformacija priprema najmanji potrebni skup za jasno određenu analitičku svrhu. Mapa povezivanja i ključevi čuvaju se odvojeno, dok prava pristupa, brisanje, audit i izvoz moraju funkcionisati duž celog toka.
Metapodaci u alatima poput OpenMetadata mogu pomoći u dokumentaciji, ali ne zamenjuju kontrolu pristupa. Tehničke oblasti: https://valanor.co/sr/maskiranje-podataka i https://valanor.co/sr/data-governance.
Arhitektura za zdravstvene podatke
Zdravstvena platforma može povezivati administrativne evidencije, kliničke sisteme i identifikacione podatke. Pre integracije treba definisati svrhu. Analiza kapaciteta često može koristiti iskorišćenost odeljenja i vremenske intervale. Analiza toka lečenja može zahtevati postojan pseudonimni identifikator. Ta dva slučaja ne treba da imaju isti nivo pristupa.
Arhitektura odvaja izvorne sisteme, kontrolisanu transformaciju i zaštićeni servis za mapiranje identiteta. Analitičari dobijaju minimizovana polja kroz definisane uloge. Povratno povezivanje sa osobom zahteva posebnu kontrolu i odobrenje. Logovi i praćenje rada ne smeju slučajno otkriti izvorne identifikatore.
Retke dijagnoze, male ustanove i neuobičajeni datumi i dalje mogu dovesti do identifikacije. Pseudonimizacija sama po sebi ne rešava tu vrstu rizika. Više: https://valanor.co/sr/data-governance-zdravstvo.
Arhitektura za osiguranje i penzione fondove
U osiguranju i penzionim fondovima ista osoba može imati broj klijenta, polise, prijave štete, penzijskog računa i više internih ključeva. Ako svi identifikatori ostanu neizmenjeni u analitici, povezivanje je jednostavnije. Data ugovor za svaki slučaj mora odrediti dozvoljene identifikatore, nivo detalja, svrhu i rokove čuvanja.
Za pregled portfolija mogu biti dovoljni agregati. Praćenje događaja kroz vreme ponekad zahteva pseudonimni ključ, što otvara pitanja verzija ključeva, duplikata, ispravki, mape i brisanja. Odsustvo imena na dashboard-u ne znači da je podatak anoniman.
Praktični primeri: https://valanor.co/sr/data-governance-osiguranje i https://valanor.co/sr/insights/pii-maskiranje-clickhouse-penzioni-fond.
Kada sintetički podaci pomažu
Sintetički testni podaci mogu sprečiti nepotrebno kopiranje stvarnih identifikatora u razvojna okruženja. Ipak, treba proveriti generator, podatke za obuku, raspodele i mogućnost rekonstrukcije ili memorisanja izvornih podataka. Sintetičko ne znači automatski bez rizika.
Za regulisane primene u zdravstvu i osiguranju posebno se proveravaju svrha, pravni osnov, rokovi čuvanja, odgovornost i preostali rizik identifikacije.
Provere pre puštanja skupa podataka u upotrebu
Definisati svrhu i primaoca
Dokumentovati odluku koju podaci podržavaju, korisnike i dodatne informacije kojima realno raspolažu.
Popisati identifikatore
Obuhvatiti direktne i indirektne identifikatore, vreme, retke vrednosti i kombinacije svojstava.
Simulirati napade
Proveriti izdvajanje, povezivanje, razliku između agregata i povratno otkrivanje uz realne dodatne izvore.
Proveriti analitičku korisnost
Izmeriti uticaj agregacije, generalizacije ili šuma na poslovni rezultat.
Testirati pristup i životni ciklus
Proći kroz promene uloga, izvoz, backup, rotaciju ključeva i zahteve za brisanje.
Dokumentovati odobrenje
Zabeležiti preostali rizik, mere, odgovorne i kada se procena ponavlja.
Operativni rad: ključevi, brisanje i promene
Pseudonimizacija nije jednokratni ETL korak nego bezbednosni proces. Ključevi ne treba da se nalaze u repozitorijumima, notebook izlazima ili nezaštićenim promenljivama. Pristup mapi mora biti odvojen od analitike; logovi, dead-letter redovi, debug izvozi i backup zahtevaju sopstvenu kontrolu.
Promena šeme može uvesti nova polja koja olakšavaju povezivanje. Rotacija ključa može poremetiti vremensku analizu bez planske migracije. Neograničeno čuvanje starih mapa može otežati sprovođenje brisanja. Potrebni su verzionisani data ugovori, regresioni testovi i kontrolisane migracije.
Za primenu u Srbiji potrebno je proveriti važeće propise o zaštiti podataka o ličnosti i sektorska pravila sa odgovornim stručnjacima. Evropske smernice o pseudonimizaciji mogu biti korisna tehnička referenca, ali ih ne treba predstavljati kao neposredno primenljiv propis Srbije. Tehnički okvir: https://valanor.co/sr/data-governance.
Česta pitanja
Da li su hashovani podaci anonimni?
Ne nužno. Povratno otkrivanje, mali skup mogućih ulaza ili povezivanje sa drugim izvorima mogu omogućiti identifikaciju.
Da li je dinamička Masking Policy isto što i pseudonimizacija?
Ne automatski. Ona pre svega menja prikaz vrednosti u trenutku čitanja; zaštita zavisi i od korisničkih prava i drugih putanja pristupa.
Da li su sintetički podaci uvek bezbedni?
Ne. Model za generisanje može otkriti retke karakteristike, duplikate ili zapamćene detalje iz izvornog skupa.
Može li analitički tim da koristi pseudonimizovane podatke?
Samo kada postoji odgovarajući pravni osnov, dozvoljena svrha i primerene tehničke i organizacione mere.
Tehnički razgovor
Bezbedna analitika počinje od arhitekture.
Razgovarajmo o modelu pristupa, klasifikaciji i proveri vašeg konkretnog data proizvoda.
Aleksandar Basara
Managing Director
aleks@valanor.co
Bulevar Milutina Milankovića 7Đ, 11070 Beograd, Srbija
