A csendes GDPR-jogsértés a megfigyelési rendszerben
A legtöbb mérnöki csapat tudja, hogy az alkalmazásadatbázisban személyes adatokat kezel. Kevesebben auditálták a naplókezelő rendszerüket ugyanolyan alapossággal.
A GDPR 5. cikk (1) bekezdés e) pontja megköveteli, hogy a személyes adatokat „nem hosszabb ideig” tárolják, „mint ami szükséges azokhoz a célokhoz, amelyekre a személyes adatokat kezelik” — a tároláskorlátozás elve. Az alkalmazásadatbázisoknál a szervezeteknek megőrzési szabályzataik, törlési feladataik és adatminimalizálási folyamataik vannak.
Az alkalmazásnaplóknál a tipikus szabályzat sokkal egyszerűbb: mindent megtartunk 90 napig (vagy 6 hónapig, vagy 1 évig) operatív és biztonsági okokból. A megőrzési időszakot a hibakeresési és auditolási igények vezérlik, nem a személyes adatok elemzése.
A probléma: ezek a naplók személyes adatokat tartalmaznak. Minden kérésnapló, amely tartalmaz egy felhasználó e-mail-címét, minden hibanapló, amely rögzít egy érvényesítési bemenetet, minden hozzáférési napló, amely rögzít egy IP-címet — ezek GDPR 4. cikk (1) bekezdése szerinti személyes adatok. A szervezetnek GDPR-jogalap kérdést kell megválaszolnia minden megőrzési időszakra.
Mi kerül valójában az alkalmazásnaplókba?
A szokásos webalkalmazás-napló formátumok felmérése feltárja a felhalmozódó személyes adatok körét:
Hozzáférési naplók (nginx/Apache):
- IP-címek (közvetlen GDPR személyes adatok az EDPB útmutatása szerint)
- Felhasználói ügynök karakterláncok (hozzájárulhatnak az ujjlenyomatvételhez)
- Munkamenet-tokenek (ha naplózzák)
Alkalmazásnaplók (strukturált JSON):
- Felhasználói azonosítók (profilokhoz kapcsolt e-mail-címek, felhasználói azonosítók)
- Beviteli érvényesítési hibák (gyakran tartalmazzák az érvénytelen bemenetet — ami lehet egy felhasználó valódi adata)
- Üzleti eseménynaplók (ügyfélfiókhoz kapcsolt rendelési azonosítók, ügyfélszolgálati jegyhivatkozások)
- Keresési lekérdezések (személyneveket, lakcímeket tartalmazhatnak)
API-átjárónaplók:
- Engedélyezési fejlécek (egyes konfigurációkban részlegesen naplózzák)
- Lekérdezési paraméterek (felhasználói azonosítókat, neveket, e-maileket tartalmazhatnak)
- Kérés-/választörzsek (hibakeresési naplózási konfigurációkban)
Adatbázis-lekérdezési naplók (lassú lekérdezési naplók, auditnaplók):
- SQL-lekérdezések beleértve a WHERE feltételeket, pl. email = 'felhasznalo@pelda.hu'
- Szó szerinti személyes adatértékek a lekérdezési paraméterekben
A felhalmozódás nem szándékos. A hibakeresésre tervezett, de nem GDPR-megfelelőséggel tervezett szokásos naplózási gyakorlatok mellékterméke.
Az EDPB álláspontja az IP-címekről a naplókban
Az Európai Adatvédelmi Testület következetesen fenntartotta, hogy az IP-címek személyes adatok a GDPR szerint — „azonosíthatók”, mert az internetszolgáltatók kapcsolatba hozhatják azokat az előfizetőkkel, és szervezeti kontextusban specifikus felhasználókat azonosíthatnak.
Ennek közvetlen következménye van a naplómegőrzésre: az IP-címeket tartalmazó hozzáférési naplók személyes adatnaplók. Az nginx hozzáférési naplók 12 hónapos megőrzése személyes adatok 12 hónapos megőrzése. A 12 hónapos megőrzés a 6. cikk szerinti jogalapot igényel, és a tároláskorlátozási elv megköveteli, hogy a megőrzési időszak szükséges legyen az adott célhoz.
A legtöbb szervezet nem elemezte explicit módon a naplómegőrzési időszakokat ezzel a kerettel szemben. „90 napig tároljuk a naplókat, mert ezt mondja a biztonsági csapat” egy operatív gyakorlatot ír le, nem GDPR 5. cikk (1) bekezdés e) pont elemzést.
Az anonimizálási út a megfelelőséghez
A naplók GDPR-megfelelőségének gyakorlati útja a legtöbb mérnöki csapat számára nem a naplómegőrzés csökkentése (amelynek operatív biztonsági indokoltsága van), hanem a naplók anonimizálása a hosszú távú megőrzés előtt.
A szintezett megőrzési modell:
0-7 nap: Teljes nyers naplók tárolva aktív hibakereséshez. Az operatív indokolás egyértelmű; a megőrzési időszak elég rövid a tároláskorlátozási problémák elkerüléséhez a legtöbb szervezetnél.
7-90 nap: Anonimizált naplók tárolva trendlelemzéshez és biztonsági megfigyeléshez. Az IP-címek anonimizált IP-ekkel helyettesítve; a felhasználói e-mailek következetes tokenekkel helyettesítve; a számlaszámok maszkolva. A technikai metaadatok (időbélyegek, hibakódok, késleltetés, végpontok) megőrizve az operatív elemzéshez.
90+ nap (ha szükséges): Csak összesített naplóadatok (eseményszámok, hibaarányok, késleltetési eloszlások) — nincs egyéni szintű rekord.
Ez a modell megőrzi az operatív hasznosságot minden megőrzési szinten, miközben teljesíti a tároláskorlátozási elvet: a személyes adatok megőrzési időszaka 7 nap; az összesített operatív adatok hosszabb ideig tárolódnak személyes adat-kitettség nélkül.
A szerkezet megőrzése a megfigyelési felhasználási esetekhez
A megfigyelési hasznosságot megőrző naplóanonimizálás alapvető műszaki követelménye a strukturális megőrzés tartalomhelyettesítéssel:
Megőrzött:
- JSON-szerkezet és kulcsnevek
- Időbélyegek és időbeli szekvenciák
- Hibatípusok és -kódok
- HTTP-metódusok, elérési utak, állapotkódok
- Késleltetési értékek és teljesítménymutatók
- Üzleti eseménytípusok (rendelés leadva, fizetés elfogadva)
Helyettesített:
- E-mail-címek → user1@example.com (az eredeti e-mailenként következetes token a naplófájlon belül)
- IP-címek → RFC 5737 dokumentációs címek (192.0.2.x, 198.51.100.x)
- Számlaszámok → ACCT_XXXXX
- Telefonszámok → +XX XXX XXX XXXX
- Nevek a hibakontextusokból → [PERSON]
Követetes token-helyettesítéssel az operatív elemzés megőrződik: a user1@example.com nyomon követése 40 naplóbejegyzésen keresztül azonosan működik hibakereséshez, mint az eredeti e-mail — mert a token a naplófájlban egységes.
Az összesített mutatók nem érintettek: végpontonkénti hibaarányok, késleltetési percentilisek, átviteli kapacitás-számítások — ezek egyike sem igényli a kérést kiváltó felhasználó tényleges e-mail-címét.
Gyakorlati integráció mérnöki csapatok számára
Egy Django- vagy Node.js-alkalmazáscsapat számára a naplóanonimizálás integrációja így néz ki:
1. lehetőség: Naplócsatorna-integráció
- A Fluentd/Logstash naplóközvetítő elfogja a naplókat
- Anonimizálási lépés fut minden naplóssoron a továbbítás előtt
- A megfigyelési platform (Elastic/Datadog) anonimizált naplókat kap
- Nincs szükség az alkalmazásnaplózási kód módosítására
2. lehetőség: Éjszakai kötegelt anonimizálás
- Nyers naplók helyi tárolóba írva
- Éjszakai cron: tegnap naplóinak anonimizálása, nyers verzió törlése
- Anonimizált naplók küldése a hosszú távú tárolóba
- Nyers naplók csak 7 napig tárolva
3. lehetőség: Megosztás előtti anonimizálás
- Nyers naplók belső megőrzése megfelelő hozzáférés-ellenőrzéssel
- Külső megosztáskor (penetrációtesztelők, alvállalkozók): anonimizálás futtatása a hozzáférés biztosítása előtt
- A külső felek mindig anonimizált verziókat kapnak
A GDPR-megfelelőségi dokumentációhoz: a naplóanonimizálás „technikai intézkedés” a GDPR 32. cikke értelmében. Az anonimizálási lépés dokumentálása — eszköz, konfiguráció, megőrzési szabályzat — a 30. cikk által előírt adatkezelési tevékenységek nyilvántartásának (ROPA) részét képezi.
Források: