By · Last updated 2026-06-05

Torna al BlogTecnico

GDPR nei Log delle Applicazioni: Conformità PII in JSON

I log delle applicazioni contengono indirizzi email dei clienti, IP e numeri di account che l'Articolo 5(1)(e) del GDPR richiede di gestire con policy di conservazione definite.

June 5, 20266 min di lettura
API logsGDPR complianceJSON anonymizationobservabilitystorage limitation

Il Rischio GDPR Silenzioso nel Tuo Stack di Log

Aggiornato per il 2026

La maggior parte dei team verifica la presenza di dati personali nel proprio database. Meno team fanno lo stesso per il sistema di log.

L'Articolo 5(1)(e) del GDPR limita la durata della conservazione dei dati personali. Per i database, i team definiscono policy ed eseguono job di cancellazione. Per i file di log, la regola sembra più semplice: conservare tutto per 90 giorni per il debug.

Il problema? Quei record contengono dati personali. Le voci delle richieste contengono email degli utenti. Le acquisizioni degli errori contengono i valori di input grezzi. Le voci di accesso contengono indirizzi IP. Ciascuno di questi conta come dato personale ai sensi del GDPR. Il tuo team ha bisogno di una base giuridica e di un piano di conservazione per ciascuno.

Cosa Finisce nei Tuoi File di Log

Il logging standard delle applicazioni web cattura un'ampia gamma di PII.

Record di accesso (nginx/Apache):

  • Indirizzi IP — dati personali secondo le linee guida EDPB
  • Stringhe user-agent — possono consentire il fingerprinting del dispositivo
  • Token di sessione — se scritti nell'output

Record delle applicazioni (JSON strutturato):

  • ID utente e indirizzi email
  • Errori di input — spesso includono il valore grezzo non valido, che può essere informazione reale dell'utente
  • Eventi di business — ID ordine collegati agli account clienti
  • Query di ricerca — possono contenere nomi o indirizzi

Record del gateway API:

  • Header di autenticazione — parzialmente acquisiti in alcune configurazioni
  • Parametri di query — possono contenere ID utente, nomi o email
  • Corpo delle richieste e delle risposte — presenti nelle configurazioni di debug

Voci di audit del database:

  • Query SQL con clausole WHERE come email = 'utente@esempio.it'
  • Valori personali letterali nei parametri delle query

Non si tratta di scelte intenzionali. È un effetto collaterale di un logging costruito per il debug, non per il GDPR.

Le Linee Guida EDPB sugli Indirizzi IP

Il Comitato Europeo per la Protezione dei Dati afferma che gli indirizzi IP sono dati personali. I provider di rete possono collegarli agli abbonati. All'interno di un'organizzazione, possono identificare utenti specifici.

L'impatto è diretto. I record di accesso con indirizzi IP sono record personali. Conservare l'output nginx per 12 mesi significa conservare dati personali per 12 mesi. Questo richiede una base giuridica ai sensi dell'Articolo 6 e un periodo di conservazione coerente con il tuo scopo dichiarato.

La maggior parte dei team salta questo passaggio. «Conserviamo le voci per 90 giorni perché lo dice la sicurezza» è una regola empirica. Non è una revisione ai sensi dell'Articolo 5(1)(e) del GDPR. Consulta la nostra panoramica sulla Conformità Legale per come questo si inserisce in un programma più ampio.

Come Raggiungere la Conformità

Per la maggior parte dei team, la soluzione pratica non è ridurre le finestre di conservazione. Le ragioni operative e di sicurezza per finestre più lunghe sono reali. La strada migliore è mascherare i record prima dello storage a lungo termine.

Un modello a livelli funziona bene.

0-7 giorni: Record grezzi completi per il debug attivo. Sette giorni è sufficientemente breve per la maggior parte dei team.

7-90 giorni: Record mascherati per l'analisi dei trend e la revisione della sicurezza. Gli indirizzi IP vengono sostituiti. Le email degli utenti diventano token stabili. I numeri di account vengono mascherati. I campi chiave — timestamp, codici di errore, latenza, endpoint — vengono mantenuti invariati.

90+ giorni (se necessario): Solo output aggregato. Conteggi degli eventi, tassi di errore, intervalli di latenza. Nessun record a livello utente rimane.

I dati personali si fermano a sette giorni. L'output aggregato può proseguire senza esporre nessuno. Consulta Sicurezza e Conformità per maggiori dettagli.

Preservare la Struttura per il Monitoraggio

Un buon mascheramento mantiene intatta la struttura JSON e sostituisce solo il contenuto. Questo mantiene l'output utile per il debug e gli alert.

Mantenuti invariati:

  • Chiavi JSON e struttura di annidamento
  • Timestamp e ordine temporale
  • Tipi di errore e codici di stato HTTP
  • Metodi HTTP, percorsi e valori di latenza
  • Tipi di eventi di business

Sostituiti:

  • Indirizzi email → token stabile per originale (es. user1@example.com)
  • Indirizzi IP → intervalli RFC 5737 (192.0.2.x)
  • Numeri di account → ACCT_XXXXX
  • Numeri di telefono → +XX XXX XXX XXXX
  • Nomi nel testo degli errori → [PERSONA]

I token stabili mantengono le tracce utili. Una traccia per user1@example.com su 40 voci funziona esattamente come l'originale. Le metriche aggregate — tassi di errore, latenza, throughput — non richiedono alcun dato personale. Consulta il Glossario per i termini pseudonimizzazione e anonimizzazione.

Tre Modi per Integrare Questa Soluzione

Tre pattern coprono la maggior parte dei team di sviluppo.

Opzione 1 — Mascheramento nella pipeline: Fluentd o Logstash intercetta ogni riga prima di inoltrarla. Una fase di mascheramento viene eseguita in linea. Elastic o Datadog ricevono solo record ripuliti. Non sono necessarie modifiche al codice dell'applicazione.

Opzione 2 — Batch notturno: I record grezzi arrivano nello storage locale. Un job notturno maschera l'output del giorno precedente ed elimina la versione grezza. I record mascherati vengono inviati allo storage a lungo termine. L'output grezzo viene conservato solo per sette giorni.

Opzione 3 — Mascheramento pre-condivisione: I record grezzi rimangono interni con controlli di accesso rigidi. Prima di condividerli con pen tester o contractor esterni, si esegue un passaggio di mascheramento. Le parti esterne ricevono sempre versioni ripulite.

Per la documentazione GDPR, il mascheramento è una «misura tecnica» ai sensi dell'Articolo 32. Registra lo strumento, la sua configurazione e la tua policy di conservazione nel Registro delle Attività di Trattamento (RAT) ai sensi dell'Articolo 30. Consulta le nostre FAQ per le domande frequenti sul RAT.

Vuoi un esempio concreto? Consulta i casi studio per dettagli di implementazione reali. Puoi anche esaminare i nostri prezzi per vedere quale piano include pipeline di mascheramento integrate.

Fonti

Pronto a proteggere i tuoi dati?

Inizia ad anonimizzare i PII con oltre 285 tipi di entità in 48 lingue.

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.