Den stille GDPR-risiko i din logstack
Opdateret for 2026
De fleste teams kontrollerer deres database for personoplysninger. Færre gør det samme for deres logsystem.
GDPR artikel 5(1)(e) begrænser, hvor længe du kan opbevare personoplysninger. For databaser fastsætter teams politikker og kører sletningsjob. For logfiler er reglen enklere: behold alt i 90 dage til fejlsøgning.
Problemet? Disse poster indeholder personoplysninger. Anmodningsposter indeholder bruger-e-mails. Fejlfangster indeholder rå inputværdier. Adgangsposter indeholder IP-adresser. Hver af disse tæller som personoplysninger under GDPR. Dit team kræver et retsgrundlag og en opbevaringsplan for hver.
Hvad der ender i dine logfiler
Standard web-app-logning trækker en bred vifte af persondata ind.
Adgangsposter (nginx/Apache):
- IP-adresser — personoplysninger ifølge EDPB-vejledning
- User-agent-strenge — kan muliggøre enhedsfingeraftryk
- Sessionstokens — hvis skrevet til output
App-poster (struktureret JSON):
- Bruger-ID'er og e-mailadresser
- Inputfejl — inkluderer ofte den rå ugyldige værdi, som kan være reel brugerinfo
- Forretningshændelser — ordre-ID'er knyttet til kundekonti
- Søgeforespørgsler — kan indeholde navne eller adresser
API-gateway-poster:
- Auth-headers — delvist fanget i nogen opsætninger
- Forespørgselsparametre — kan bære bruger-ID'er, navne eller e-mails
- Anmodnings- og svarlegemer — til stede i debug-niveau-opsætninger
Database-revisionsposter:
- SQL-forespørgsler med WHERE-klausuler som
email = 'bruger@example.com' - Bogstavelige personværdier i forespørgselsparametre
Dette er ikke gjort med vilje. Det er en bivirkning af logning bygget til fejlsøgning, ikke GDPR.
EDPB-vejledning om IP-adresser
Det Europæiske Databeskyttelsesråd siger, at IP-adresser er personoplysninger. Internetudbydere kan linke dem til abonnenter. Inden for en organisation kan de identificere specifikke brugere.
Påvirkningen er direkte. Adgangsposter med IP-adresser er personposter. At beholde nginx-output i 12 måneder betyder at beholde personoplysninger i 12 måneder. Det kræver et retsgrundlag under artikel 6. Det kræver også, at opbevaringsperioden matcher dit erklærede formål.
De fleste teams springer dette trin over. "Vi opbevarer poster i 90 dage, fordi sikkerhed siger det" er en tommelfingerregel. Det er ikke en GDPR artikel 5(1)(e)-gennemgang. Se vores juridiske compliance-oversigt for, hvordan dette passer ind i et bredere program.
Vejen til compliance
Den praktiske vej for de fleste teams er ikke at skære opbevaringsvinduerne ned. Operationelle og sikkerhedsmæssige begrundelser for længere vinduer er reelle. Den bedre vej er at maskere poster, inden de lagres langsigtet.
En lagdelt model fungerer godt.
0–7 dage: Fulde råposter til aktiv fejlsøgning. Syv dage er kort nok til de fleste teams.
7–90 dage: Maskerede poster til trendanalyse og sikkerhedsgennemgang. IP-adresser byttes ud. Bruger-e-mails bliver stabile tokens. Kontonumre maskeres. Nøglefelter — tidsstempler, fejlkoder, latenstider, slutpunkter — beholdes uændrede.
90+ dage (om nødvendigt): Kun aggregeret output. Hændelsestal, fejlrater, latenstidsintervaller. Ingen bruger-niveau-poster forbliver.
Personoplysninger stopper ved syv dage. Aggregeret output kan videreføres uden at eksponere nogen. Se Sikkerhed & Compliance for mere detalje.
Bevar strukturen intakt til overvågning
God maskering holder JSON-strukturen intakt. Den bytter kun indholdet ud. Dette holder output nyttigt til fejlsøgning og advarsler.
Beholdt uændret:
- JSON-nøgler og indlejring
- Tidsstempler og tidsorden
- Fejltyper og HTTP-statuskoder
- HTTP-metoder, stier og latensværdier
- Forretningshændelsetyper
Byttet ud:
- E-mailadresser → stabilt token per original (f.eks.
user1@example.com) - IP-adresser → RFC 5737-intervaller (
192.0.2.x) - Kontonumre →
KONTO_XXXXX - Telefonnumre →
+XX XXX XXX XXXX - Navne i fejltekst →
[PERSON]
Stabile tokens holder traces nyttige. Et trace for user1@example.com på tværs af 40 poster fungerer det samme som originalen. Aggregerede metrikker — fejlrater, latenstider, gennemstrømning — kræver slet ikke personoplysninger. Se Ordliste for termerne pseudonymisering og anonymisering.
Tre måder at integrere dette på
Tre mønstre dækker de fleste it-teams.
Mulighed 1 — Pipeline-maskering: Fluentd eller Logstash opsnapper hver linje, inden den sendes videre. Et maskeringstrin kører inline. Elastic eller Datadog modtager kun rensede poster. Ingen ændringer i app-kode er nødvendige.
Mulighed 2 — Nightly batch: Råposter lander i lokal lagring. Et nightly job maskerer forrige dags output og sletter råversionen. Maskerede poster sendes til langsigtet lagring. Råoutput opbevares kun i syv dage.
Mulighed 3 — Pre-share maskering: Råposter forbliver interne med strenge adgangskontroller. Inden deling med penetrationstestere eller eksterne leverandører, kør et maskeringspass. Eksterne parter modtager altid rene versioner.
For GDPR-dokumentation er maskering en "teknisk foranstaltning" under artikel 32. Optegn værktøjet, dets opsætning og din opbevaringspolitik i dine Behandlingsaktivitetsregistre (RoPA) under artikel 30. Se vores FAQ for hyppige RoPA-spørgsmål.
Vil du have et virkelighedseksempel? Se casestudier for konkrete implementeringsdetaljer. Du kan også gennemgå vores priser for at se, hvilken plan der inkluderer indbyggede maskeringspipelines.
Kilder
- GDPR artikel 5: Principper for databehandling — VERIFICERET-EKSTERNT
- EDPB Udtalelse 5/2019 om ePrivacy-direktivet og GDPR — VERIFICERET-EKSTERNT
- Sonra.io: PII-maskering i JSON- og XML-data — VERIFICERET-EKSTERNT