Tichý problém akumulace PII v aplikačních lozích
Aplikační logy jsou jedním z nejvíce přehlížených compliance povrchů GDPR v inženýrských organizacích. Ne proto, že by inženýři o GDPR nevěděli — ale protože logy hromadí PII incidentálně, způsoby, které nejsou vždy viditelné, dokud je compliance audit neodhalí.
Zvažte, co se objevuje v typickém JSON logu požadavku/odpovědi:
{
"timestamp": "2025-11-14T09:22:13Z",
"level": "ERROR",
"endpoint": "/api/users/profile",
"user_email": "jana.novakova@firma.cz",
"client_ip": "82.123.45.67",
"user_agent": "Mozilla/5.0...",
"error": "ValidationError: phone field requires format...",
"input_value": "+420 776 123 456"
}
Tato jediná logovací položka obsahuje čtyři entity PII: e-mailovou adresu, IP adresu a telefonní číslo (v kontextu chyby). Vynásobeno miliony denních API volání, objem logů představuje podstatnou činnost zpracování osobních dat, která vyžaduje právní základ GDPR, limity uchovávání a vhodná technická opatření.
Proč sdílení logů se třetími stranami vytváří expozici GDPR
Organizace sdílejí aplikační logy se třetími stranami neustále:
- Firmy provádějící penetrační testy dostávají produkční logy, aby porozuměly chování aplikace
- Externí konzultanti odstraňují problémy s výkonem pomocí vzorků logů
- Observability platformy (Elastic, Datadog, Splunk) přijímají celé streamy logů
- SRE dodavatelé přistupují k logům při řešení incidentů
- Vývojové týmy v různých právních entitách dostávají logy pro ladění
Každý z těchto scénářů sdílení vyvolává otázky podle čl. 28 GDPR: je příjemce zpracovatelem dat? Existuje Smlouva o zpracování dat? Má třetí strana právní základ pro přijetí osobních dat obsažených v lozích?
U observability platforem je analýza GDPR zvláště komplexní. Odesílání produkčních logů obsahujících skutečné e-mailové adresy a IP adresy uživatelů na Elastic Cloud nebo Datadog vytváří zpracovatelský vztah, který vyžaduje DPA, vhodné standardní smluvní doložky a mechanismus přenosu, pokud platforma působí mimo EU.
Jednodušší compliance cesta: anonymizujte logy předtím, než opustí vaše kontrolované prostředí.
Výzvy struktury JSON logů
JSON logy jsou strukturálně variabilní způsoby, díky nimž je obecné skenování textu nedostatečné:
Hloubka vnoření: PII se může vyskytovat v libovolné hloubce vnořeného JSON. request.headers.x-forwarded-for obsahuje IP adresy; response.body.errors[0].field_value může obsahovat uživatelem zadané PII z chyb validace. Plošné skenování JSON souboru jako textového dokumentu jej považuje za textový dokument a může přehlédnout entity na vnořených cestách.
Nekonzistentní schémata: Různé API endpointy produkují různá schémata logů. Logy autentizace uživatelů vypadají jinak než logy zpracování plateb, které vypadají jinak než logy aktualizace profilu uživatele. Přístup s pevnou cestou (‚vždy anonymizovat $.user.email') přehlédne PII, které se objevuje na neočekávaných cestách v kontextu chyb.
Technické hodnoty smíchané s PII: Stack traces, kódy chyb, technická ID, časová razítka a metrické hodnoty musí být pro ladění zachovány. Plošná anonymizace, která dezinfikuje vše technické, učiní log pro jeho primární účel nepoužitelným.
Řešením je detekce na základě obsahu: identifikujte PII podle toho, čím je (vzor e-mailové adresy, formát IP adresy, pojmenovaná entita), nikoli podle toho, kde se v JSON struktuře nachází. Detekce na základě obsahu automaticky zvládá variabilní schémata.
Zachování utility pro ladění prostřednictvím konzistentní pseudonymizace
Klíčovým požadavkem pro anonymizaci logů zachovávající utilitu pro ladění je referenční integrita: pokud se jana.novakova@firma.cz vyskytuje v 47 různých logovacích položkách týkajících se jediného řetězce požadavků, všech 47 výskytů musí být nahrazeno stejnou pseudonymní hodnotou.
Přístup k náhradě:
- jana.novakova@firma.cz → user1@example.com (konzistentní v souboru logů)
- 82.123.45.67 → 192.0.2.1 (dokumentační IP dle RFC 5737 — jednoznačně neskutečná)
- +420 776 123 456 → +420 XXX XXX XXX (maskováno)
S konzistentní pseudonymizací může vývojář sledovat user1@example.com přes 47 logovacích položek, rekonstruovat sekvenci požadavků a odladit problém — aniž by kdy viděl skutečnou e-mailovou adresu uživatele.
Technická metadata jsou zachována beze změny:
- Časová razítka (nikoli PII)
- Kódy chyb a typy (nikoli PII)
- Stack traces (nikoli PII — mohou obsahovat technická ID, ale nikoli osobní data)
- HTTP metody, cesty, stavové kódy (nikoli PII)
- Metrické hodnoty, měření latence (nikoli PII)
Anonymizovaný soubor logů je plně funkční pro ladění; neobsahuje žádná skutečná osobní data uživatelů.
Případ použití: SaaS společnost sdílí logy pro penetrační test
SaaS společnost angažovala externí firmu provádějící penetrační testy pro čtvrtletní bezpečnostní posouzení. Rozsah penetračního testu vyžadoval přístup k 90 denním produkčním API logům k pochopení chování aplikace, identifikaci autentizačních toků a analýze chybových vzorů.
Objem surových logů: 180 MB JSON logů. Počet entit: 4 200 unikátních e-mailových adres uživatelů, 1 800 unikátních IP adres, 340 částečných čísel účtů v kontextech chyb.
Bez anonymizace by sdílení těchto logů s externí firmou vyžadovalo DPA, mechanismus přenosu GDPR dle čl. 46 (firma sídlí mimo EU) a analýzu oznamovací povinnosti vůči subjektům dat.
S anonymizací:
- Čas zpracování: 25 minut pro 180 MB
- Výstup: 180 MB strukturálně identických logů s nahrazenými konzistentními pseudonymními hodnotami pro všechny e-mailové adresy, IP adresy a čísla účtů
- Výsledek: firma provádějící penetrační test obdrží plný kontext logů pro bezpečnostní analýzu; v jejich držení nejsou žádná skutečná data uživatelů
- Požadavek GDPR: DPA není potřeba (anonymizovaná data nejsou osobními daty dle GDPR)
Integrace anonymizace logů do CI/CD pipeline
Pro organizace pravidelně provozující kontinuální bezpečnostní testování nebo sdílející logy s externími stranami lze dávkovou anonymizaci logů integrovat do automatizovaných pipeline:
Integrace rotace logů:
- Skript rotace logů běží v noci
- Před archivací nebo odesláním na observability platformu: krok anonymizace
- Anonymizované logy odeslány do externích systémů
- Původní logy uchovávány interně s plnou dobou uchovávání
Skript před sdílením:
- Inženýr potřebuje sdílet vzorek logů s externím dodavatelem
- Spustí anonymizační skript: vstup=surové-logy/, výstup=anonymizované-logy/
- Sdílí anonymizované-logy/ s dodavatelem
- Není vyžadován ruční přezkum PII
Integrace observability platformy:
- Postranní proces anonymizuje stream logů před předáním Elastic/Datadog
- Anonymizace v reálném čase zachovává utilitu logů pro observability
- Observability platforma nepřijímá žádné skutečné PII uživatelů
Pro soulad s principem omezení uložení podle čl. 5 odst. 1 písm. e) GDPR může být anonymizace logů také součástí politiky uchovávání logů: surové logy uchovávány 7 dní (provozní ladění), anonymizované verze uchovávány 90 dní (analýza trendů), přičemž krok anonymizace běží automaticky 7. den.
Zdroje: