Asmens duomenys slepiasi programų žurnaluose
Programų žurnalai yra vienas labiausiai nepastebimų BDAR paviršių inžinerijoje. Ne todėl, kad inžinieriai ignoruoja įstatymą. Todėl, kad naudotojų detalės atsitiktinai patenka į žurnalų failus.
Vienas JSON užklausų žurnalas gali turėti keturis asmens duomenų laukus:
{
"timestamp": "2025-11-14T09:22:13Z",
"level": "ERROR",
"endpoint": "/api/users/profile",
"user_email": "sarah.johnson@company.com",
"client_ip": "82.123.45.67",
"user_agent": "Mozilla/5.0",
"error": "ValidationError: phone format",
"input_value": "+49 176 1234 5678"
}
Tas vienas įrašas turi el. paštą, IP ir telefono numerį. Padauginkite tai iš milijonų kasdieninių API iškvietimų. Rezultatas yra didelė asmens duomenų veikla. Jai reikalingas teisinis pagrindas, apribojimai ir kontrolė.
Trečiųjų šalių žurnalų dalijimasis kelia BDAR riziką
Komandos nuolat dalinasi žurnalų failais su išorinėmis šalimis:
- Saugumo testavimo firmos gauna įrašus programos elgseną atvaizduoti
- Išorės konsultantai naudoja žurnalų pavyzdžius lėtoms vietoms rasti
- Žurnalų platformos (Elastic, Datadog, Splunk) gauna pilnus išvesties srautus
- SRE rangovai pasiekia įrašus incidentų metu
- Kūrimo komandos kitose teisiniuose subjektuose gauna failus derinimui
Kiekvienas dalijimasis kelia BDAR 28 straipsnio klausimus. Ar gavėjas yra tvarkytojas? Ar yra duomenų tvarkymo sutartis? Ar jie turi teisinį pagrindą matyti naudotojų detales tuose failuose?
Žurnalų platformos yra dažna spraga. Išvesties su tikraisiais naudotojų el. paštais ir IP siuntimas į Elastic Cloud ar Datadog sukuria tvarkymo ryšį. Tas ryšys reikalauja DTS, standartinių sąlygų ir perdavimo priemonės, jei platforma yra už ES ribų. Kiekvienas iš jų reikalauja laiko ir teisinio patikrinimo.
Paprastesnis kelias: pašalinkite naudotojų detales prieš failams paliekant jūsų sistemą. Skaitykite mūsų atitikties apžvalgą dėl visų 28 straipsnio taisyklių.
Kodėl JSON struktūra apsunkina aptikimą
JSON žurnalų failai keičiasi struktūroje. Bendras teksto nuskaitymas nepakanka.
Įnelgtimo gylis: Naudotojų detalės pasirodo bet kokiame gylyje. Laukas request.headers.x-forwarded-for laiko IP adresus. Laukas response.body.errors[0].field_value gali laikyti naudotojo įvestį. Plokščias teksto nuskaitymas praleidžia laukus, palaidotus įnelgtuose keliuose.
Nenuoseklios schemos: Kiekvienas API galinis taškas gamina savo išvesties formą. Autentifikavimo failai atrodo kitaip nei mokėjimų failai. Profilio atnaujinimo failai atrodo kitaip nei abu. Fiksuoto kelio metodas praleidžia naudotojų detales, atsirandančias neįprastais keliais klaidų kontekstuose.
Techninės reikšmės sumaišytos su asmens duomenimis: Klaidos sekos, klaidų kodai ir laiko žymos turi likti nepakeistu. Bendras šalinimas ištrina reikalingus laukus ir padaro failą nenaudingą.
Tinkamas metodas yra turinio pagrindu pagrįstas aptikimas. Raskite naudotojų detales pagal tai, kas jos yra - el. pašto šablonas, IP formatas, įvardintas objektas - o ne pagal tai, kur jos yra struktūroje. Tai tvarko kintamas schemas be kiekvieno galinio taško sąrankos.
Nuoseklus pakeitimas išlaiko žurnalus naudingus
Pagrindinė reikalavimas yra nuorodinė vientisumas. Jei sarah.johnson@company.com pasirodo 47 įrašuose per užklausų grandinę, visi 47 turi atitikti tą pačią reikšmę.
Atitikimo taisyklės:
sarah.johnson@company.com-user1@example.com(ta pati reikšmė per visą failą)82.123.45.67-192.0.2.1(RFC 5737 dokumentacijos IP - aiškiai ne tikras)+49 176 1234 5678-+49 XXX XXX XXXX(užmaskuotas)
Su tuo atitikimu kūrėjas gali atsekti user1@example.com per 47 įrašus, atkurti užklausų grandinę ir ištaisyti klaidą - nematydamas jokių tikrų naudotojų detalių.
Šie metaduomenų laukai lieka nepakeistu:
- Laiko žymos (ne naudotojo duomenys)
- Klaidų kodai ir tipai (ne naudotojo duomenys)
- Klaidos sekos (gali turėti technikos ID, ne naudotojo duomenys)
- HTTP metodai, keliai, būsenos kodai (ne naudotojo duomenys)
- Metrikos reikšmės ir delsos skaičiai (ne naudotojo duomenys)
Rezultatas yra failas, veikiantis derinimo darbui. Jame nėra jokių tikrų naudotojų detalių. Žiūrėkite mūsų žodyną dėl skirtumo tarp anonimizavimo ir pseudonimizavimo pagal BDAR.
Naudojimo atvejis: saugumo testavimo žurnalų dalijimasis
SaaS firma vykdė ketvirtinį saugumo patikrinimą su išorine saugumo testavimo komanda. Apimtis reikalavo 90 dienų gamybos API išvesties autentifikavimo srautams atvaizduoti ir klaidų šablonams analizuoti.
Nedorinis kiekis: 180 MB JSON failų. Asmens duomenų skaičius: 4 200 unikalių naudotojų el. paštų, 1 800 unikalių IP, 340 dalinių sąskaitų numerių klaidų kontekstuose.
Be naudotojų detalių pašalinimo pirmiausia, tų failų dalijimasis reikalautų:
- DTS su saugumo testavimo firma
- BDAR 46 straipsnio perdavimo priemonę (firma buvo už ES ribų)
- Duomenų subjektų pranešimų peržiūrą
Kiekvienas iš jų prideda teisinį darbą ir laiką.
Pritaikius asmens duomenų šalinimą:
- Apdorojimo laikas: 25 minutės 180 MB
- Išvestis: 180 MB struktūriškai identiškų failų, visi el. paštai ir IP pakeisti saugiomis reikšmėmis
- Rezultatas: saugumo testavimo komanda gavo pilną kontekstą; jokios tikros naudotojų detalės jų nepasiekė
- BDAR rezultatas: DTS nereikalinga - išvalyti duomenys nėra naudotojų duomenys pagal BDAR
Žiūrėkite mūsų DUK dėl dažnų klausimų apie tai, kas laikoma anoniminiu pagal BDAR.
Asmens duomenų šalinimo integravimas į CI/CD
Komandoms, reguliariai dalinančioms išvestimi, šis žingsnis gali veikti esamuose konveijeriuose.
Žurnalų rotacija:
- Rotacijos scenarijus veikia naktimis
- Šalinimo žingsnis veikia prieš archyvavimą ar siuntimą į bet kurią žurnalų platformą
- Išvalyti failai eina į išorines sistemas
- Originalūs failai lieka viduje su pilnu saugojimu
Scenarijus prieš dalijimąsi:
- Inžinierius turi pasidalinti pavyzdžiu su rangovu
- Paleidžia scenarijų:
input=raw-logs/ output=clean-logs/ - Dalinasi
clean-logs/aplanku - Jokio rankinio asmens duomenų patikrinimo nereikia
Šoninio automobilio metodas:
- Šoninis automobilis išvalo išvesties srautą prieš perduodant toliau
- Realaus laiko šalinimas išlaiko naudingumą žurnalų analizei
- Platforma gauna nulinį tikrų naudotojų detalių kiekį
Saugojimo politikos integracija
BDAR 5 straipsnio 1 dalies e punktas reikalauja saugojimo apribojimo. Asmens duomenų šalinimas tinka į bet kurią saugojimo politiką.
- Neapdorota išvestis saugoma 7 dienas (kasdieniam derinimui)
- Išvalytos versijos saugomos 90 dienų (tendencijų analizei ir incidentų peržiūrai)
- Šalinimo žingsnis veikia 7 dieną
Tai atitinka saugojimo apribojimą. Tai pašalina neapdorotos išvesties ilgalaikio saugojimo riziką.