Vaikne GDPR-risk teie logisüsteemis
Uuendatud 2026. aastaks
Enamik meeskondi kontrollib oma andmebaasi isikuandmete suhtes. Vähem teeb sama oma logisüsteemi jaoks.
GDPR artikkel 5(1)(e) piirab isikuandmete salvestamise kestust. Andmebaaside puhul seadistavad meeskonnad poliitikaid ja käivitavad kustutamistöid. Logifailide puhul on reegel lihtsam: hoidke kõik 90 päeva silumiseks.
Probleem? Need kirjed sisaldavad isikuandmeid. Päringukirjed sisaldavad kasutajate e-posti aadresse. Veakirjed sisaldavad töötlemata sisendväärtusi. Juurdepääsukirjed sisaldavad IP-aadresse. Igaüks neist loeb GDPR alusel isikuandmeteks. Teie meeskond vajab igaühe jaoks õiguslikku alust ja säilitamisplaani.
Mis satub teie logifailidesse
Standardne veebirakenduse logimine kogub laia valiku isikuandmeid.
Juurdepääsukirjed (nginx/Apache):
- IP-aadressid - isikuandmed EDPB juhendi kohaselt
- Kasutajaagendi stringid - võivad võimaldada seadme sõrmejälgede võtmist
- Seansi märgid - kui kirjutatakse väljundisse
Rakenduse kirjed (struktureeritud JSON):
- Kasutajate ID-d ja e-posti aadressid
- Sisendivead - sisaldavad sageli töötlemata kehtetut väärtust, mis võib olla reaalne kasutajateave
- Ärisündmused - tellimisnumbrid seotud klientide kontodega
- Otsingupäringud - võivad sisaldada nimesid või aadresse
API-lüüsi kirjed:
- Autentimise päised - osaliselt tabatud mõnedes seadistustes
- Päringuparameetrid - võivad kanda kasutajate ID-sid, nimesid või e-posti aadresse
- Päringu- ja vastusekehad - olemas silumistaseme seadistustes
Andmebaasi auditikirjed:
- SQL-päringud WHERE klauslitega nagu
email = 'user@example.com' - Otsesed isikuväärtused päringuparameetrites
See ei juhtu tahtlikult. See on silumiseks, mitte GDPR-i jaoks loodud logimise kõrvalmõju.
EDPB juhend IP-aadresside kohta
Euroopa Andmekaitsenõukogu ütleb, et IP-aadressid on isikuandmed. Internetiteenuse pakkujad saavad neid abonentidega seostada. Organisatsiooni sees saavad need tuvastada konkreetseid kasutajaid.
Mõju on otsene. Juurdepääsukirjed IP-aadressidega on isikukirjed. Nginx väljundi hoidmine 12 kuud tähendab isikuandmete hoidmist 12 kuud. See vajab artikkel 6 alusel õiguslikku alust. Samuti peab säilitamisperiood vastama teie nimetatud eesmärgile.
Enamik meeskondi jätab selle sammu vahele. "Hoiame kirjeid 90 päeva, sest turvalisus nõuab" on rusikareegel. See ei ole GDPR artikkel 5(1)(e) ülevaatus. Vaadake meie Juriidilise nõuetele vastavuse ülevaade selle kohta, kuidas see sobib laiemasse programmi.
Kuidas nõuetele vastavuseni jõuda
Praktiline tee enamiku meeskondade jaoks ei ole säilitamise ajavahemike lühendamine. Operatiivsed ja turvalised põhjused pikemate ajavahemike jaoks on reaalsed. Parem tee on kirjete maskimine enne pikaajalist salvestamist.
Astmeline mudel toimib hästi.
0-7 päeva: Täielikud töötlemata kirjed aktiivseks silumiseks. Seitse päeva on enamiku meeskondade jaoks piisavalt lühike.
7-90 päeva: Maskeeritud kirjed trendi analüüsiks ja turvakontrolliks. IP-aadressid vahetatakse välja. Kasutajate e-postid muutuvad stabiilseteks märkideks. Kontonumbrid maskeeritakse. Põhiväljad - ajatemplid, veakoodid, latentsus, otspunktid - hoitakse sellisena, nagu nad on.
90+ päeva (vajadusel): Ainult koondatud väljund. Sündmuste arv, vea määrad, latentsuse vahemikud. Kasutajatasemel kirjeid ei jää.
Isikuandmed peatuvad seitsme päeva juures. Koondatud väljund saab edasi kanduda ilma kellegi paljastamiseta. Vaadake Turvalisus ja nõuetele vastavus lisateabe saamiseks.
Hoidke struktuur puutumata jälgimiseks
Hea maskeerimine hoiab JSON-struktuuri puutumata. See vahetab välja ainult sisu. See hoiab väljundi kasutatavana silumiseks ja hoiatuste jaoks.
Jäetud sellisena, nagu on:
- JSON võtmed ja pesastamine
- Ajatemplid ja ajajärjestus
- Veatüübid ja HTTP-olekukoodid
- HTTP meetodid, teed ja latentsuse väärtused
- Ärisündmuste tüübid
Vahetatud välja:
- E-posti aadressid - stabiilne märk originaali kohta (nt
user1@example.com) - IP-aadressid - RFC 5737 vahemikud (
192.0.2.x) - Kontonumbrid -
ACCT_XXXXX - Telefoninumbrid -
+XX XXX XXX XXXX - Nimed veatekstis -
[ISIK]
Stabiilsed märgid hoiavad jäljed kasutatavana. Jälg user1@example.com jaoks 40 kirje ulatuses töötab sama kui algne. Koondmõõdikud - vea määrad, latentsus, läbilaskevõime - ei vaja üldse isikuandmeid. Vaadake Sõnastikku mõistete pseudonümiseerimine ja anonümiseerimine jaoks.
Kolm integreerumise viisi
Kolm mustrit katavad enamiku insenerimeeskondi.
Variant 1 - Konveieri maskeerimine: Fluentd või Logstash peatab iga rea enne edasiandmist. Maskeerimise samm töötab siseselt. Elastic või Datadog saab ainult puhastatud kirjeid. Rakenduse koodi muutused pole vajalikud.
Variant 2 - Öine partii: Töötlemata kirjed maanduvad kohalikus salvestusruumis. Öine töö maskeerib eelmise päeva väljundi ja kustutab töötlemata versiooni. Maskeeritud kirjed lähevad pikaajalisele salvestusele. Töötlemata väljundit hoitakse ainult seitse päeva.
Variant 3 - Enne jagamist maskeerimine: Töötlemata kirjed jäävad sisemiseks rangete juurdepääsukontrollidega. Enne jagamist turvatestijate või väliste töövõtjatega käivitage maskeerimise käik. Välised osalised saavad alati puhastatud versioone.
GDPR-i dokumentatsiooni jaoks on maskeerimine "tehniline meede" artikli 32 alusel. Registreerige tööriist, selle seadistus ja säilitamispoliitika töötlemistoimingute registris (RoPA) artikli 30 alusel. Vaadake meie KKK-d levinumate RoPA küsimuste jaoks.
Kas soovite reaalset näidet? Vaadake juhtumi uuringuid konkreetsete rakendamise üksikasjade saamiseks. Samuti saate vaadata meie hinnakirja, et näha, milline plaan sisaldab sisseehitatud maskeerimiskonveiereid.
Allikad
- GDPR artikkel 5: Andmete töötlemise põhimõtted - VERIFIED-EXTERNAL
- EDPB arvamus 5/2019 ePrivacy direktiivi ja GDPR kohta - VERIFIED-EXTERNAL
- Sonra.io: Isikuandmete maskeerimine JSON- ja XML-andmetes - VERIFIED-EXTERNAL