anonym.legal

By · Last updated 2026-06-05

Înapoi la BlogTehnic

GDPR în jurnalele de aplicații: conformitatea PII în JSON

Jurnalele de aplicații conțin adrese de email ale clienților, adrese IP și numere de cont pe care Articolul 5(1)(e) GDPR impune să fie gestionate. Iată cum să mascați PII din jurnale fără a pierde capacitatea de depanare.

June 5, 20266 min citire
API logsGDPR complianceJSON anonymizationobservabilitystorage limitation

Riscul GDPR tăcut din stiva dvs. de jurnalizare

Actualizat pentru 2026

Cele mai multe echipe verifică baza de date pentru informații personale. Mai puțini fac același lucru pentru sistemul de jurnalizare.

Articolul 5(1)(e) GDPR limitează cât timp puteți stoca informații personale. Pentru baze de date, echipele stabilesc politici și rulează sarcini de ștergere. Pentru fișierele jurnal, regula este mai simplă: păstrați totul 90 de zile pentru depanare.

Problema? Acele înregistrări conțin informații personale. Intrările de cereri conțin emailuri de utilizatori. Capturile de erori conțin valori de input brute. Intrările de acces conțin adrese IP. Fiecare dintre acestea contează ca informație personală conform GDPR. Echipa dvs. are nevoie de o bază juridică și un plan de retenție pentru fiecare.

Ce ajunge în fișierele dvs. jurnal

Jurnalizarea standard a aplicațiilor web atrage o gamă largă de PII.

Înregistrări de acces (nginx/Apache):

  • Adrese IP — informații personale conform ghidului EDPB
  • Șiruri user-agent — pot permite amprentarea dispozitivului
  • Token-uri de sesiune — dacă sunt scrise în ieșire

Înregistrări de aplicație (JSON structurat):

  • ID-uri de utilizatori și adrese de email
  • Erori de input — includ adesea valoarea invalidă brută, care poate fi informații reale de utilizator
  • Evenimente de afaceri — ID-uri de comenzi legate de conturile clienților
  • Interogări de căutare — pot conține nume sau adrese

Înregistrări de gateway API:

  • Antete de autentificare — parțial capturate în unele configurații
  • Parametri de interogare — pot conține ID-uri de utilizator, nume sau emailuri
  • Corpuri de cereri și răspunsuri — prezente în configurațiile la nivel de depanare

Intrări de audit baze de date:

  • Interogări SQL cu clauze WHERE precum email = 'user@example.com'
  • Valori personale literale în parametrii de interogare

Aceasta nu este făcută intenționat. Este un efect secundar al jurnalizării construite pentru depanare, nu pentru GDPR.

Ghidul EDPB privind adresele IP

Boardul European pentru Protecția Datelor afirmă că adresele IP sunt informații personale. ISP-urile le pot lega de abonați. În cadrul unei organizații, pot identifica utilizatori specifici.

Impactul este direct. Înregistrările de acces cu adrese IP sunt înregistrări personale. Păstrarea ieșirii nginx timp de 12 luni înseamnă păstrarea informațiilor personale timp de 12 luni. Aceasta necesită o bază juridică conform Articolului 6. Necesită, de asemenea, ca perioada de retenție să corespundă scopului declarat.

Cele mai multe echipe sar peste acest pas. „Păstrăm intrările 90 de zile pentru că securitatea o spune” este o regulă generală. Nu este o revizuire a Articolului 5(1)(e) GDPR. Consultați prezentarea noastră de conformitate juridică pentru cum se încadrează aceasta într-un program mai larg.

Cum să atingeți conformitatea

Calea practică pentru cele mai multe echipe nu este reducerea ferestrelor de retenție. Motivele operaționale și de securitate pentru ferestre mai lungi sunt reale. Calea mai bună este să mascați înregistrările înainte de stocarea pe termen lung.

Un model pe niveluri funcționează bine.

0–7 zile: Înregistrări brute complete pentru depanare activă. Șapte zile este suficient de scurt pentru cele mai multe echipe.

7–90 de zile: Înregistrări mascate pentru analiza tendințelor și revizuirea de securitate. Adresele IP sunt înlocuite. Emailurile de utilizatori devin token-uri stabile. Numerele de cont sunt mascate. Câmpurile cheie — marcaje de timp, coduri de eroare, latență, endpoint-uri — sunt păstrate intacte.

90+ zile (dacă este necesar): Numai ieșire agregată. Numărări de evenimente, rate de erori, intervale de latență. Nu rămân înregistrări la nivel de utilizator.

Informațiile personale se opresc la șapte zile. Ieșirea agregată poate fi transmisă mai departe fără a expune pe nimeni. Consultați Securitate și Conformitate pentru mai multe detalii.

Păstrați structura intactă pentru monitorizare

Mascarea bună păstrează structura JSON intactă. Înlocuiește doar conținutul. Aceasta menține ieșirea utilă pentru depanare și alerte.

Păstrate intacte:

  • Chei și imbricare JSON
  • Marcaje de timp și ordine temporală
  • Tipuri de erori și coduri de stare HTTP
  • Metode HTTP, căi și valori de latență
  • Tipuri de evenimente de afaceri

Înlocuite:

  • Adrese de email → token stabil per original (ex. user1@example.com)
  • Adrese IP → intervale RFC 5737 (192.0.2.x)
  • Numere de cont → ACCT_XXXXX
  • Numere de telefon → +XX XXX XXX XXXX
  • Nume în textul de eroare → [PERSOANA]

Token-urile stabile mențin urmele utile. O urmă pentru user1@example.com pe 40 de intrări funcționează la fel ca originalul. Metricile agregate — rate de erori, latență, throughput — nu necesită deloc informații personale. Consultați Glosarul pentru termenii pseudonimizare și anonimizare.

Trei moduri de integrare

Trei modele acoperă cele mai multe echipe de inginerie.

Opțiunea 1 — Mascare în pipeline: Fluentd sau Logstash interceptează fiecare linie înainte de a o trimite mai departe. Un pas de mascare rulează inline. Elastic sau Datadog primesc doar înregistrări curate. Nu sunt necesare modificări ale codului aplicației.

Opțiunea 2 — Lot nocturn: Înregistrările brute ajung în stocarea locală. O sarcină nocturnă maschează ieșirea zilei anterioare și șterge versiunea brută. Înregistrările mascate merg la stocarea pe termen lung. Ieșirea brută este păstrată doar șapte zile.

Opțiunea 3 — Mascare pre-partajare: Înregistrările brute rămân interne cu controale stricte de acces. Înainte de partajarea cu pen testeri sau contractori externi, rulați un pas de mascare. Părțile externe primesc întotdeauna versiuni curate.

Pentru documentele GDPR, mascarea este o „măsură tehnică” conform Articolului 32. Înregistrați instrumentul, configurația sa și politica de retenție în Registrul Activităților de Prelucrare (RoPA) conform Articolului 30. Consultați FAQ-ul nostru pentru întrebări frecvente despre RoPA.

Doriți un exemplu din lumea reală? Verificați studiile de caz pentru detalii concrete de implementare. Puteți revizui și prețurile noastre pentru a vedea ce plan include pipeline-uri de mascare integrate.

Surse

Pregătit să vă protejați datele?

Începeți să anonimizati PII cu 285+ tipuri de entități în 48 de limbi.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.