Den tysta GDPR-risken i ditt loggstack
Uppdaterad för 2026
De flesta team kontrollerar sin databas för personuppgifter. Färre gör detsamma för sitt loggsystem.
GDPR Artikel 5(1)(e) begränsar hur länge du kan lagra personuppgifter. För databaser sätter team policyer och kör raderingsjobb. För loggfiler är regeln enklare: behåll allt i 90 dagar för felsökning.
Problemet? Dessa poster håller personuppgifter. Förfrågningsposter håller användar-e-poster. Felregistreringar håller råa indatavärden. Åtkomstposter håller IP-adresser. Var och en av dessa räknas som personuppgifter enligt GDPR. Ditt team behöver en rättslig grund och en lagringsplan för var och en.
Vad som hamnar i dina loggfiler
Standardloggning för webbapplikationer samlar in ett brett utbud av PII.
Åtkomstposter (nginx/Apache):
- IP-adresser — personuppgifter enligt EDPB-vägledning
- User-agent-strängar — kan möjliggöra enhetsfingeravtryck
- Sessionstokens — om de skrivs till utdata
Appposter (strukturerad JSON):
- Användar-ID:n och e-postadresser
- Inmatningsfel — innehåller ofta det råa ogiltiga värdet, vilket kan vara verkliga användaruppgifter
- Affärshändelser — order-ID:n kopplade till kundkonton
- Sökfrågor — kan innehålla namn eller adresser
API-gateway-poster:
- Autentiseringshuvuden — delvis fångade i vissa konfigurationer
- Frågeparametrar — kan bära användar-ID:n, namn eller e-poster
- Förfrågnings- och svarskroppar — förekommer i felsökningsnivåinställningar
Databasrevisionsposter:
- SQL-frågor med WHERE-klausuler som
email = 'användare@example.com' - Bokstavliga personvärden i frågeparametrar
Detta görs inte med avsikt. Det är en bieffekt av loggning byggd för felsökning, inte GDPR.
EDPB:s vägledning om IP-adresser
Europeiska dataskyddsstyrelsen säger att IP-adresser är personuppgifter. Internetleverantörer kan koppla dem till abonnenter. Inom en organisation kan de identifiera specifika användare.
Effekten är direkt. Åtkomstposter med IP-adresser är personposter. Att behålla nginx-utdata i 12 månader innebär att lagra personuppgifter i 12 månader. Det kräver en rättslig grund enligt Artikel 6. Det kräver också att lagringsperioden matchar ditt angivna syfte.
De flesta team hoppar över detta steg. "Vi behåller poster i 90 dagar för att säkerhet säger så" är en tumregel. Det är inte en GDPR Artikel 5(1)(e)-granskning. Se vår juridisk efterlevnadsöversikt för hur detta passar ett bredare program.
Hur du uppnår efterlevnad
Den praktiska vägen för de flesta team är inte att skära ner lagringsperioderna. Operationella och säkerhetsmässiga skäl för längre perioder är verkliga. Den bättre vägen är att maskera poster innan de lagras långsiktigt.
En nivåbaserad modell fungerar bra.
0–7 dagar: Fullständiga råposter för aktiv felsökning. Sju dagar är tillräckligt kort för de flesta team.
7–90 dagar: Maskerade poster för trendanalys och säkerhetsgranskning. IP-adresser byts ut. Användar-e-poster blir stabila tokens. Kontonummer maskeras. Nyckelfält — tidsstämplar, felkoder, latens, slutpunkter — behålls som de är.
90+ dagar (om nödvändigt): Aggregerad utdata enbart. Händelseantal, felfrekvenser, latensintervall. Inga poster på användarnivå finns kvar.
Personuppgifter stannar vid sju dagar. Aggregerad utdata kan fortsätta utan att exponera någon. Se Säkerhet & Efterlevnad för mer detaljer.
Behåll strukturen intakt för övervakning
Bra maskering håller JSON-strukturen intakt. Den byter bara ut innehåll. Detta håller utdata användbar för felsökning och larm.
Behålls som de är:
- JSON-nycklar och nästling
- Tidsstämplar och tidsordning
- Feltyper och HTTP-statuskoder
- HTTP-metoder, sökvägar och latens
- Affärshändelsetyper
Byts ut:
- E-postadresser → stabil token per original (t.ex.
user1@example.com) - IP-adresser → RFC 5737-intervall (
192.0.2.x) - Kontonummer →
KONTO_XXXXX - Telefonnummer →
+XX XXX XXX XXXX - Namn i feltext →
[PERSON]
Stabila tokens håller spår användbara. Ett spår för user1@example.com över 40 poster fungerar likadant som originalet. Aggregerade mätvärden — felfrekvenser, latens, genomströmning — behöver inga personuppgifter alls. Se ordlistan för termerna pseudonymisering och anonymisering.
Tre sätt att integrera detta
Tre mönster täcker de flesta ingenjörsteam.
Alternativ 1 — Pipeline-maskering: Fluentd eller Logstash fångar upp varje rad innan den skickas vidare. Ett maskeringssteg körs inline. Elastic eller Datadog får bara rensade poster. Inga appkodändringar behövs.
Alternativ 2 — Nattlig batch: Råposter hamnar i lokal lagring. Ett nattjobb maskerar föregående dags utdata och raderar råversionen. Maskerade poster går till långtidslagring. Råutdata behålls bara i sju dagar.
Alternativ 3 — Pre-delning maskering: Råposter stannar internt med strikta åtkomstkontroller. Innan delning med penetrationstestare eller externa konsulter kör du en maskeringsomgång. Externa parter får alltid rena versioner.
För GDPR-dokumentation är maskering en "teknisk åtgärd" enligt Artikel 32. Registrera verktyget, dess konfiguration och din lagringspolicy i dina behandlingsregister (RoPA) enligt Artikel 30. Se vår FAQ för vanliga RoPA-frågor.
Vill du ha ett verkligt exempel? Kolla fallstudierna för konkreta implementeringsdetaljer. Du kan också granska vår prissättning för att se vilken plan som inkluderar inbyggda maskeringspipelines.