Hiljainen GDPR-riski lokipinossasi
Päivitetty vuodelle 2026
Useimmat tiimit tarkistavat tietokantansa henkilötietojen osalta. Harvemmat tekevät saman lokijärjestelmälle.
GDPR:n artikla 5(1)(e) rajoittaa, kuinka kauan voit säilyttää henkilötietoja. Tietokannoille tiimit asettavat periaatteet ja ajavat poistojobeja. Lokitiedostoille sääntö on yksinkertaisempi: pidä kaikki 90 päivää debuggausta varten.
Ongelma? Nämä tietueet sisältävät henkilötietoja. Pyyntötietueet sisältävät käyttäjien sähköposteja. Virhetietueet sisältävät raakoja syötearvoja. Käyttöoikeustietueet sisältävät IP-osoitteita. Kukin näistä lasketaan henkilötiedoksi GDPR:n alla. Tiimillesi tarvitaan oikeudellinen peruste ja säilytyssuunnitelma kullekin.
Mitä päättyy lokitiedostoihisi
Tavallinen verkkosovellusten lokitus kerää laajan valikoiman henkilötietoja.
Käyttöoikeustietueet (nginx/Apache):
- IP-osoitteet — henkilötieto EDPB:n ohjeiden mukaan
- Käyttäjäagentti-merkkijonot — voivat mahdollistaa laitteiden sormenjäljityksen
- Istuntotunnukset — jos kirjoitetaan tulosteeseen
Sovellustietueet (rakenteellinen JSON):
- Käyttäjätunnukset ja sähköpostiosoitteet
- Syötevirheet — sisältävät usein raakojen virheellisten arvojen, jotka voivat olla todellisia käyttäjätietoja
- Liiketapahtumat — tilauksen tunnukset asiakastilinumeroihin linkitettyinä
- Hakukyselyt — voivat sisältää nimiä tai osoitteita
API-gatewayn tietueet:
- Autentikointiotsikot — osittain tallennettu joissain asetuksissa
- Kyselyparametrit — voivat kantaa käyttäjätunnuksia, nimiä tai sähköposteja
- Pyyntö- ja vastausrungot — läsnä debug-tason asetuksissa
Tietokannan auditointimerkinnät:
- SQL-kyselyt WHERE-lauseilla kuten
email = 'user@example.com' - Kirjaimellisia henkilöarvoja kyselyparametreissa
Tämä ei tehdä tarkoituksella. Se on sivuvaikutus lokituksesta, joka on rakennettu debuggaukseen, ei GDPR:lle.
EDPB:n ohje IP-osoitteista
Eurooppalainen tietosuojaneuvosto sanoo, että IP-osoitteet ovat henkilötietoa. Internet-palveluntarjoajat voivat linkittää ne tilaajiin. Organisaation sisällä ne voivat tunnistaa tietyt käyttäjät.
Vaikutus on suora. Käyttöoikeustietueet, joissa on IP-osoitteita, ovat henkilötietueita. Nginx-tulosteen säilyttäminen 12 kuukautta tarkoittaa henkilötietojen säilyttämistä 12 kuukautta. Se vaatii oikeudellisen perustan artiklan 6 nojalla. Se myös vaatii, että säilytysaika vastaa ilmoitettua tarkoitusta.
Useimmat tiimit ohittavat tämän vaiheen. "Pidämme merkintöjä 90 päivää, koska tietoturva sanoo niin" on nyrkkisääntö. Se ei ole GDPR:n artiklan 5(1)(e) mukainen arviointi. Katso Oikeudellisen vaatimustenmukaisuuden yleiskatsauksemme siitä, miten tämä sopii laajempaan ohjelmaan.
Kuinka saavuttaa vaatimustenmukaisuus
Käytännöllinen reitti useimmille tiimeille ei ole lyhentää säilytysikkunoita. Operatiiviset ja tietoturvasyyt pidemmille ikkunoille ovat todellisia. Parempi polku on peittää tietueet ennen pitkäaikaista tallennusta.
Portaittainen malli toimii hyvin.
0–7 päivää: Täydet raakalokit aktiiviseen debuggaukseen. Seitsemän päivää on riittävän lyhyt useimmille tiimeille.
7–90 päivää: Peitetyt tietueet trendianalyysiin ja tietoturvatarkistukseen. IP-osoitteet vaihdetaan. Käyttäjien sähköposteista tulee vakaita tunnisteita. Tilinumerot peitetään. Avainkenttien — aikaleima, virhekoodit, viive, päätepisteet — pysyvät ennallaan.
90+ päivää (tarvittaessa): Vain aggregoitu tuloste. Tapahtumamäärät, virhetaajuudet, viivelukemat. Käyttäjätason tietueita ei jää.
Henkilötieto pysähtyy seitsemään päivään. Aggregoitu tuloste voi jatkaa ilman, että kukaan altistuu. Katso Tietoturva & Vaatimustenmukaisuus lisätietoja varten.
Pidä rakenne ehjänä monitorointia varten
Hyvä peittäminen pitää JSON-rakenteen ehjänä. Se vaihtaa vain sisällön. Tämä pitää tulosteen hyödyllisenä debuggauksessa ja hälytyksille.
Pidetään ennallaan:
- JSON-avaimet ja sisäkkäisyys
- Aikaleima ja aikajarjestys
- Virhetyypit ja HTTP-statuskoodit
- HTTP-menetelmät, polut ja viivearvot
- Liiketapahtumien tyypit
Vaihdetaan:
- Sähköpostiosoitteet → vakaa tunniste per alkuperäinen (esim.
user1@example.com) - IP-osoitteet → RFC 5737:n alueet (
192.0.2.x) - Tilinumerot →
ACCT_XXXXX - Puhelinnumerot →
+XX XXX XXX XXXX - Nimet virhetekstissä →
[PERSON]
Vakaat tunnisteet pitävät jäljitykset hyödyllisinä. Jäljitys user1@example.com:lle 40 merkinnässä toimii samoin kuin alkuperäinen. Aggregoidut mittarit — virhetaajuudet, viive, läpäisykyky — eivät tarvitse lainkaan henkilötietoa. Katso Sanasto termien pseudonymisointi ja anonymisointi selityksiä varten.
Kolme tapaa integroida tämä
Kolme mallia kattaa useimmat tekniset tiimit.
Vaihtoehto 1 — Pipeline-peittäminen: Fluentd tai Logstash sieppaa jokaisen rivin ennen edelleen lähettämistä. Peittämisvaihe ajaa inline. Elastic tai Datadog saa vain puhtaita tietueita. Sovelluskoodi ei tarvitse muutoksia.
Vaihtoehto 2 — Yöllinen erä: Raakalokit laskeutuvat paikalliseen tallennukseen. Yöllinen job peittää edellisen päivän tulosteen ja poistaa raakaversion. Peitetyt tietueet menevät pitkäaikaiseen tallennukseen. Raakalokit säilytetään vain seitsemän päivää.
Vaihtoehto 3 — Ennakkojako-peittäminen: Raakalokit pysyvät sisäisesti tiukalla pääsynhallinnalla. Ennen jakamista tietoturvatest- tai ulkopuolisten urakoitsijoiden kanssa aja peittämisajo. Ulkopuoliset osapuolet saavat aina puhtaita versioita.
GDPR-dokumentaatiota varten peittäminen on "tekninen toimenpide" artiklan 32 nojalla. Kirjaa työkalu, sen asetukset ja säilytysperiaatteesi Käsittelytoimintojen rekisteriin (RoPA) artiklan 30 nojalla. Katso FAQ-sivumme yleisistä RoPA-kysymyksistä.
Haluatko todellisen esimerkin? Katso tapaustutkimukset konkreettisia toteutustietoja varten. Voit myös tarkistaa hinnoittelumme nähdäksesi, mikä suunnitelma sisältää valmiit peittämispipelinet.