Tihi GDPR rizik u vasem log steku
Azurirano za 2026. godinu
Vecina timova proverava svoju bazu podataka zbog licnih podataka. Manje njih to rade za sistem evidencija.
GDPR clan 5(1)(e) ogranicava koliko dugo mozete cuvati licne podatke. Za baze podataka, timovi postavljaju politike i pokrecuu poslove brisanja. Za datoteke evidencija, pravilo je jednostavnije: cuvajte sve 90 dana za debagovanje.
Problemu? Ti zapisi sadrze licne podatke. Unosi zahteva sadrze korisnicke emailove. Zapisi gresaka sadrze sirove ulazne vrednosti. Unosi pristupa sadrze IP adrese. Svako od ovih se racuna kao licni podatak prema GDPR-u. Vasem timu je potrebna pravna osnova i plan retencije za svako od njih.
Sta zavrsava u vasim datotekama evidencija
Standardno logovanje web aplikacije uvlaci sirok opseg PII.
Zapisi pristupa (nginx/Apache):
- IP adrese — licni podaci prema smernicama EDPB-a
- User-agent stringovi — mogu omoguciti otisak prsta uredjaja
- Tokeni sesije — ako su upisani u izlaz
Zapisi aplikacije (strukturisani JSON):
- Korisnicki ID-ovi i email adrese
- Greske unosa — cesto ukljucuju sirovu nevazucu vrednost, koja moze biti stvarna korisnicki informacija
- Poslovni dogadjaji — ID-ovi narudzbenica povezani sa korisnickim nalozima
- Upiti za pretragu — mogu sadrzati imena ili adrese
Zapisi API gateway-a:
- Auth zaglavlja — delimicno hvacena u nekim postavkama
- Parametri upita — mogu nositi korisnicke ID-ove, imena ili emailove
- Tela zahteva i odgovora — prisutni u debug-nivovsim postavkama
Unosi revizije baze podataka:
- SQL upiti sa WHERE klauzulama poput
email = 'korisnik@example.com' - Doslovna licna vrednosti u parametrima upita
Ovo se ne radi namerno. To je nuzposledica logovanja napravljenog za debagovanje, a ne za GDPR.
EDPB smernice o IP adresama
Evropski odbor za zastitu podataka kaze da su IP adrese licni podaci. ISP-ovi ih mogu povezati sa pretplatnicima. Unutar organizacije, mogu identifikovati specificne korisnike.
Uticaj je direktan. Zapisi pristupa sa IP adresama su licni zapisi. Cuvanje nginx izlaza 12 meseci znaci cuvanje licnih podataka 12 meseci. To zahteva pravnu osnovu prema clanu 6. Takodje zahteva da period retencije odgovara vasoj navodnoj svrsi.
Vecina timova preskacu ovaj korak. "Cuvamo unose 90 dana jer bezbednost tako kaze" je pravilo palca. To nije GDPR clan 5(1)(e) pregled. Pogledajte nas pregled pravne uskladjenosti za to kako ovo uklapa u siri program.
Kako dostici uskladjenost
Prakticni put za vecinu timova nije skracivanje prozora retencije. Operativni i bezbednosni razlozi za duze prozore su stvarni. Bolji put je maskirati zapise pre dugorocnog skladistenja.
Visestepeniki model dobro funkcionise.
0–7 dana: Potpuni sirovi zapisi za aktivno debagovanje. Sedam dana je dovoljno kratko za vecinu timova.
7–90 dana: Maskirani zapisi za analizu trendova i bezbednosni pregled. IP adrese su zamenjene. Korisnicki emailovi postaju stabilni tokeni. Brojevi naloga su maskirani. Kljucna polja — vremenske oznake, kodovi gresaka, latencija, endpointi — ostaju nepromenjena.
90+ dana (ako je potrebno): Samo agregatni izlaz. Brojevi dogadjaja, stope gresaka, opsezi latencije. Nikakvi zapisi na nivou korisnika ne ostaju.
Licni podaci se zaustavljaju na sedam dana. Agregatni izlaz moze nositi napred bez izlaganja ikoga. Pogledajte Bezbednost i uskladjenost za vise detalja.
Zadrzite strukturu netaknutom za monitoring
Dobro maskiranje zadrzava JSON strukturu netaknutom. Samo zamenjuje sadrzaj. Ovo cuva izlaz korisnim za debagovanje i upozorenja.
Ostavljeno nepromenjenima:
- JSON kljucevi i ugnezdavanje
- Vremenske oznake i vremenski poredak
- Tipovi gresaka i HTTP statusni kodovi
- HTTP metode, putanje i vrednosti latencije
- Tipovi poslovnih dogadjaja
Zamenjeno:
- Email adrese → stabilan token po originalu (npr.
user1@example.com) - IP adrese → RFC 5737 opsezi (
192.0.2.x) - Brojevi naloga →
ACCT_XXXXX - Brojevi telefona →
+XX XXX XXX XXXX - Imena u tekstu gresaka →
[PERSON]
Stabilni tokeni cuvaju tragove korisnim. Trag za user1@example.com kroz 40 unosa funkcionise isto kao original. Agregatne metrike — stope gresaka, latencija, propusnost — uopste ne trebaju licne podatke. Pogledajte Recnik za termine pseudonimizacija i anonimizacija.
Tri nacina integracije
Tri obrasca pokrivaju vecinu inzenjersskih timova.
Opcija 1 — Maskiranje u kanalu: Fluentd ili Logstash presrece svaki red pre slanja dalje. Korak maskiranja se pokrenuje interno. Elastic ili Datadog dobijaju samo ociscene zapise. Nisu potrebne promene koda aplikacije.
Opcija 2 — Nocna serijska obrada: Sirovi zapisi dolaze u lokalno skladiste. Nocni posao maskira izlaz prethodnog dana i brise sirovu verziju. Maskirani zapisi idu u dugorocno skladiste. Sirovi izlaz se cuva samo sedam dana.
Opcija 3 — Maskiranje pre deljenja: Sirovi zapisi ostaju interno sa strogim kontrolama pristupa. Pre deljenja sa pen testerima ili spoljnim izvrsioce, pokrenite prolaz maskiranja. Spoljne strane uvek dobijaju ciste verzije.
Za GDPR dokumentaciju, maskiranje je "tehnicka mera" prema clanu 32. Zabeleziite alat, njegovu postavku i vasu politiku retencije u Evidencijama aktivnosti obrade (RoPA) prema clanu 30. Pogledajte nas FAQ za cesta pitanja o RoPA.
Zelite primer iz stvarnog sveta? Pogledajte studije slucaja za konkretne detalje implementacije. Takodje mozete pregledati nase cenovnik da vidite koji plan ukljucuje ugradnjene kanale maskiranja.