Het Stille AVG-Risico In Uw Log-Stack
Bijgewerkt voor 2026
De meeste teams controleren hun database op persoonlijke gegevens. Minder doen hetzelfde voor hun logsysteem.
AVG-artikel 5(1)(e) beperkt hoe lang u persoonsgegevens mag opslaan. Voor databases stellen teams beleid in en voeren verwijderingsjobs uit. Voor logbestanden is de regel eenvoudiger: bewaar alles 90 dagen voor debugging.
Het probleem? Die records bevatten persoonsgegevens. Aanvraagvermeldingen bevatten gebruikers-e-mails. Foutregistraties bevatten onbewerkte invoerwaarden. Toegangsvermeldingen bevatten IP-adressen. Elk hiervan telt als persoonsgegevens onder de AVG. Uw team heeft een rechtsgrond en een bewaarplan nodig voor elk hiervan.
Wat Er In Uw Logbestanden Belandt
Standaard webapplicatie-logging trekt een breed scala aan PII binnen.
Toegangsrecords (nginx/Apache):
- IP-adressen — persoonsgegevens volgens EDPB-leidraad
- User-agent-strings — kunnen apparaatfingerprinting mogelijk maken
- Sessietokens — indien naar uitvoer geschreven
App-records (gestructureerde JSON):
- Gebruikers-ID's en e-mailadressen
- Invoerfouten — bevatten vaak de onbewerkte ongeldige waarde, die echte gebruikersinformatie kan zijn
- Bedrijfsgebeurtenissen — bestel-ID's gekoppeld aan klantaccounts
- Zoekopdrachten — kunnen namen of adressen bevatten
API-gateway-records:
- Auth-headers — gedeeltelijk vastgelegd in sommige instellingen
- Queryparameters — kunnen gebruikers-ID's, namen of e-mails bevatten
- Verzoek- en antwoordlichamen — aanwezig in debug-niveau-instellingen
Database-auditregistraties:
- SQL-query's met WHERE-clausules zoals `email = 'gebruiker@voorbeeld.com'`
- Letterlijke persoonlijke waarden in queryparameters
Dit gebeurt niet opzettelijk. Het is een neveneffect van logging gebouwd voor debugging, niet voor AVG-naleving.
EDPB-Leidraad Over IP-Adressen
De Europese Gegevensbeschermingsraad stelt dat IP-adressen persoonsgegevens zijn. ISP's kunnen ze aan abonnees koppelen. Binnen een organisatie kunnen ze specifieke gebruikers identificeren.
De impact is direct. Toegangsrecords met IP-adressen zijn persoonsrecords. Nginx-uitvoer 12 maanden bewaren betekent persoonsgegevens 12 maanden bewaren. Dat vereist een rechtsgrond onder artikel 6. Het vereist ook dat de bewaarperiode overeenkomt met uw opgegeven doel.
De meeste teams slaan deze stap over. "We bewaren vermeldingen 90 dagen omdat beveiliging dat zegt" is een vuistregel. Het is geen AVG-artikel 5(1)(e)-review. Zie ons wettelijk complianceoverzicht voor hoe dit in een breder programma past.
Hoe U Compliance Bereikt
De praktische route voor de meeste teams is niet het verkorten van bewaartermijnen. Operationele en beveiligingsredenen voor langere termijnen zijn reëel. Het betere pad is het maskeren van records vóór langetermijnopslag.
Een gelaagd model werkt goed.
0–7 dagen: Volledige onbewerkte records voor actieve debugging. Zeven dagen is kort genoeg voor de meeste teams.
7–90 dagen: Gemaskeerde records voor trendanalyse en beveiligingsreview. IP-adressen worden vervangen. Gebruikers-e-mails worden stabiele tokens. Accountnummers worden gemaskeerd. Sleutelvelden — tijdstempels, foutcodes, latentie, eindpunten — blijven ongewijzigd.
90+ dagen (indien nodig): Alleen geaggregeerde uitvoer. Gebeurtenisaantallen, foutpercentages, latentieranges. Er blijven geen records op gebruikersniveau.
Persoonsgegevens stoppen na zeven dagen. Geaggregeerde uitvoer kan doorgaan zonder iemand bloot te stellen. Zie Beveiliging & Compliance voor meer detail.
Bewaar De Structuur Intact Voor Monitoring
Goed maskeren behoudt de JSON-structuur intact. Het vervangt alleen inhoud. Dit houdt uitvoer bruikbaar voor debugging en waarschuwingen.
Ongewijzigd gelaten:
- JSON-sleutels en nesting
- Tijdstempels en tijdsvolgorde
- Fouttypen en HTTP-statuscodes
- HTTP-methoden, paden en latentiewaarden
- Bedrijfsgebeurtenistypen
Vervangen:
- E-mailadressen → stabiel token per origineel (bijv. `gebruiker1@voorbeeld.com`)
- IP-adressen → RFC 5737-ranges (`192.0.2.x`)
- Accountnummers → `ACCT_XXXXX`
- Telefoonnummers → `+XX XXX XXX XXXX`
- Namen in fouttekst → `[PERSOON]`
Stabiele tokens houden traces bruikbaar. Een trace voor `gebruiker1@voorbeeld.com` over 40 vermeldingen werkt hetzelfde als het origineel. Geaggregeerde statistieken — foutpercentages, latentie, doorvoer — hebben helemaal geen persoonsgegevens nodig. Zie de Woordenlijst voor de termen pseudonimisering en anonimisering.
Drie Manieren Om Dit Te Integreren
Drie patronen dekken de meeste engineeringteams.
Optie 1 — Pipeline-maskering: Fluentd of Logstash onderschept elke regel voor het doorsturen. Een maskeringsstap wordt inline uitgevoerd. Elastic of Datadog ontvangt alleen schone records. Er zijn geen app-codewijzigingen nodig.
Optie 2 — Nachtelijke batch: Onbewerkte records komen terecht in lokale opslag. Een nachtelijkse job maskeert de uitvoer van de vorige dag en verwijdert de onbewerkte versie. Gemaskeerde records gaan naar langetermijnopslag. Onbewerkte uitvoer wordt slechts zeven dagen bewaard.
Optie 3 — Pre-deel maskering: Onbewerkte records blijven intern met strikte toegangscontroles. Voer een maskeringspass uit vóór het delen met penetratietesters of externe aannemers. Externe partijen ontvangen altijd schone versies.
Voor AVG-documentatie telt maskering als een "technische maatregel" onder artikel 32. Leg de tool, de instelling en uw bewaarbeleid vast in uw Verwerkingsactiviteiten-register (VAR) onder artikel 30. Zie onze FAQ voor veelgestelde vragen over VAR.
Wilt u een praktijkvoorbeeld? Bekijk de casestudies voor concrete implementatiedetails. U kunt ook onze prijsstellingen bekijken om te zien welk abonnement ingebouwde maskeringspipelines bevat.
Bronnen
- AVG Artikel 5: Beginselen voor gegevensverwerking — GEVERIFIEERD-EXTERN
- EDPB Opinion 5/2019 on ePrivacy Directive and GDPR — GEVERIFIEERD-EXTERN
- Sonra.io: PII Masking in JSON and XML Data — GEVERIFIEERD-EXTERN