Tichá GDPR zranitelnost ve vašem observability stacku
Většina inženýrských týmů ví, že ve své aplikační databázi zpracovávají osobní data. Méně jich audituje svůj systém správy logů se stejnou přísností.
Čl. 5 odst. 1 písm. e) GDPR vyžaduje, aby osobní data byla uchovávána „ne déle, než je nezbytné pro účely, pro které jsou osobní data zpracovávána” — princip omezení uložení. U aplikačních databází mají organizace politiky uchovávání, úlohy mazání a procesy minimalizace dat.
U aplikačních logů je typická politika mnohem jednodušší: uchovejte vše po dobu 90 dní (nebo 6 měsíců, nebo 1 roku) z provozních a bezpečnostních důvodů. Doba uchovávání je řízena potřebami ladění a auditu, nikoli analýzou osobních dat.
Problém: tyto logy obsahují osobní data. Každý log požadavku, který obsahuje e-mailovou adresu uživatele, každý chybový log, který zachycuje validační vstup, každý přístupový log, který zaznamenává IP adresu — to jsou osobní data dle čl. 4 odst. 1 GDPR. Organizace musí odpovědět na otázku právního základu GDPR pro každou dobu uchovávání.
Co se skutečně ocitá v aplikačních lozích
Přehled běžných formátů logů webových aplikací odhaluje šíři PII, která se hromadí:
Přístupové logy (nginx/Apache):
- IP adresy (přímá osobní data GDPR dle pokynů EDPB)
- Řetězce user-agent (mohou přispět k fingerprintingu)
- Tokeny relací (pokud jsou logovány)
Aplikační logy (strukturovaný JSON):
- Identifikátory uživatelů (e-mailové adresy, ID uživatelů propojená s profily)
- Chyby validace vstupu (často obsahují neplatný vstup — který může být skutečná data uživatele)
- Logy obchodních událostí (ID objednávek propojené se zákaznickými účty, reference na tikety podpory)
- Vyhledávací dotazy (mohou obsahovat osobní jména, adresy)
Logy API brány:
- Autorizační hlavičky (částečně logovány v některých konfiguracích)
- Parametry dotazů (mohou obsahovat ID uživatelů, jména, e-maily)
- Těla požadavků/odpovědí (v konfiguracích debug logování)
Logy databázových dotazů (logy pomalých dotazů, auditní logy):
- SQL dotazy včetně klauzulí WHERE s email = 'uzivatel@priklad.cz'
- Hodnoty osobních dat v parametrech dotazů
Akumulace není záměrná. Je vedlejším produktem standardních postupů logování navržených pro ladění, nikoli navržených s ohledem na soulad s GDPR.
Stanovisko EDPB k IP adresám v lozích
Evropský sbor pro ochranu osobních údajů konzistentně trvá na tom, že IP adresy jsou osobními daty dle GDPR — jsou „identifikovatelné”, protože poskytovatelé internetových služeb je mohou propojit s předplatiteli a v organizačních kontextech mohou identifikovat konkrétní uživatele.
Toto má přímé důsledky pro uchovávání logů: přístupové logy obsahující IP adresy jsou logy osobních dat. Uchovávání nginx přístupových logů po dobu 12 měsíců je uchováváním osobních dat po dobu 12 měsíců. Dvanáctiměsíční uchovávání vyžaduje právní základ dle čl. 6 a princip omezení uložení vyžaduje, aby doba uchovávání byla nezbytná pro konkrétní účel.
Většina organizací explicitně neanalyzovala své doby uchovávání logů v rámci tohoto rámce. „Logy uchováváme 90 dní, protože to říká bezpečnostní tým” je výrokem o provozní praxi, nikoli analýzou dle čl. 5 odst. 1 písm. e) GDPR.
Anonymizační cesta ke souladu
Praktická cesta ke souladu logů GDPR pro většinu inženýrských týmů není snižovat uchovávání logů (které má provozní bezpečnostní zdůvodnění), ale anonymizovat logy před dlouhodobým uchováváním.
Vrstvený model uchovávání:
0–7 dní: Plné surové logy uchovávány pro aktivní ladění. Provozní zdůvodnění je jasné; doba uchovávání je pro většinu organizací dostatečně krátká, aby se vyhnula problémům s omezením uložení.
7–90 dní: Anonymizované logy uchovávány pro analýzu trendů a bezpečnostní monitoring. IP adresy nahrazeny anonymizovanými IP; uživatelské e-maily nahrazeny konzistentními tokeny; čísla účtů maskována. Technická metadata (časová razítka, kódy chyb, latence, endpointy) zachována pro provozní analýzu.
90+ dní (pokud je potřeba): Pouze agregovaná data logů (počty událostí, míry chyb, distribuce latencí) — žádné záznamy na individuální úrovni.
Tento model zachovává provozní utilitu na každé úrovni uchovávání a zároveň splňuje princip omezení uložení: doba uchovávání osobních dat je 7 dní; agregovaná provozní data jsou uchovávána déle bez expozice osobních dat.
Zachování struktury pro případy použití observability
Klíčovým technickým požadavkem pro anonymizaci logů, která zachovává utilitu observability, je strukturální zachování s náhradou obsahu:
Zachováno:
- Struktura JSON a názvy klíčů
- Časová razítka a časové sekvence
- Typy a kódy chyb
- HTTP metody, cesty, stavové kódy
- Hodnoty latence a výkonnostní metriky
- Typy obchodních událostí (objednávka zadána, platba přijata)
Nahrazeno:
- E-mailové adresy → user1@example.com (konzistentní token na původní e-mail v souboru logů)
- IP adresy → dokumentační adresy RFC 5737 (192.0.2.x, 198.51.100.x)
- Čísla účtů → UCET_XXXXX
- Telefonní čísla → +XX XXX XXX XXXX
- Jména z chybových kontextů → [OSOBA]
S konzistentní náhradou tokenů je provozní analýza zachována: trasování požadavku sledující user1@example.com přes 40 logovacích položek funguje pro ladění identicky jako původní e-mail — protože token je konzistentní v celém souboru logů.
Agregované metriky jsou nedotčeny: míry chyb na endpoint, percentily latence, výpočty propustnosti — žádné z těchto nevyžadují znalost skutečné e-mailové adresy uživatele, který požadavek spustil.
Praktická integrace pro inženýrské týmy
Pro tým Django nebo Node.js aplikace vypadá integrace anonymizace logů takto:
Možnost 1: Integrace log pipeline
- Přepravce logů Fluentd/Logstash zachycuje logy
- Krok anonymizace běží na každém řádku logu před předáváním
- Observability platforma (Elastic/Datadog) přijímá anonymizované logy
- Nejsou potřeba žádné změny kódu aplikačního logování
Možnost 2: Noční dávková anonymizace
- Surové logy zapisovány do lokálního úložiště
- Noční cron: anonymizuje včerejší logy, odstraní surovou verzi
- Anonymizované logy odeslány do dlouhodobého úložiště
- Surové logy uchovávány pouze 7 dní
Možnost 3: Anonymizace před sdílením
- Surové logy uchovávány interně s vhodnými přístupovými kontrolami
- Při sdílení externě (testery penetrace, dodavatelé): spusťte anonymizaci před poskytnutím přístupu
- Externí strany vždy dostávají anonymizované verze
Pro compliance dokumentaci GDPR: anonymizace logů je „technickým opatřením” dle čl. 32 GDPR. Dokumentace anonymizačního kroku — nástroj, konfigurace, politika uchovávání — je součástí Záznamu o činnostech zpracování (RoPA) vyžadovaného dle čl. 30.
Zdroje: