Provozní logy mohou obsahovat osobní údaje i tehdy, když v nich není jméno. Uživatelský identifikátor, IP adresa, konkrétní událost a čas mohou společně umožnit určit člověka. Pravidla protokolování proto musí vysvětlit, proč se údaje zaznamenávají, jaký rozsah je potřebný a kdo smí záznamy používat. Bezpečnostní účel neznamená oprávnění ukládat neomezeně celý obsah komunikace.
GDPR spojuje omezení účelu a uložení s přiměřeným zabezpečením podle článku 32. ÚOOÚ uvádí logování mezi opatřeními, která mohou pomáhat ochraně údajů. Konkrétní nastavení však musí odpovídat riziku a potřebě. Tento pracovní vzor nepředepisuje univerzální počet dnů ani technický standard pro každý systém.
Nejprve oddělte účely logů
Rozlišujte bezpečnostní dohled, diagnostiku chyb, provozní měření a audit důležitých změn. Každý účel může potřebovat jinou podrobnost a dobu uchování. Pokud tým používá stejné záznamy k hodnocení pracovníků, nejde automaticky o pokračování původního bezpečnostního účelu. Takové použití vyžaduje samostatné posouzení a odpovídající informování.
Sepište otázky, na které mají logy odpovědět. Kdo změnil platební kontakt? Který účet hromadně exportoval záznamy? Proč se žádost nezpracovala? Teprve z těchto otázek odvoďte potřebná pole. Nastavení zaznamenávat všechno pro jistotu vytváří další rozsáhlou databázi, která může být sama cílem útoku.
Matice událostí a polí
| Typ události | Užitečná pole podle konkrétní potřeby | Co obvykle vyžaduje omezení |
|---|---|---|
| Přihlášení | Čas, účet, výsledek a přiměřený kontext | Heslo, celý token nebo obnovovací tajemství |
| Změna oprávnění | Aktér, dotčená role, změna a schválení | Kopie osobního spisu uživatele |
| Export | Aktér, typ exportu, rozsah a výsledek | Celý export vložený jako obsah logu |
| Změna údajů | Identifikátor objektu, operace a čas | Neomezené uchování starých citlivých hodnot |
| Chyba aplikace | Kód chyby, kontext a identifikátor požadavku | Celé tělo formuláře nebo přílohy |
| Administrace | Účet správce, zásah a odpovědný případ | Soukromý obsah nesouvisející s operací |
Tabulku vyplňujte společně s bezpečnostním i aplikačním týmem. Technický pracovník vysvětlí, zda pole skutečně potřebuje pro diagnostiku. Odpovědná osoba posoudí zásah do soukromí a dobu. U každého typu události uveďte, kdo jej čte a jaké rozhodnutí na jeho základě dělá. Nepoužívaná pole jsou kandidátem k odstranění.
Zabraňte ukládání tajemství
Před odesláním do centrálního systému filtrujte přístupové tokeny, hesla, autorizační hlavičky a další tajné hodnoty. Kontrolujte i adresy URL, které mohou obsahovat identifikátory nebo přihlašovací odkazy. Maskování ve výsledném rozhraní nestačí, pokud se plný obsah již uložil do základního úložiště a je dostupný administrátorům nebo exportům.
Zvlášť prohlédněte chybové hlášky a režim podrobné diagnostiky. Při řešení chyby se někdy dočasně zapne výpis celého požadavku a nikdo jej později nevypne. Dočasná zvýšená podrobnost má mít schválený rozsah, konec a kontrolu odstranění podkladů. Pro běžnou diagnostiku používejte zkušební údaje, kde to jde.
Hypotetický případ zákaznického portálu
Smyšlený portál zaznamenává chyby formuláře včetně celé zprávy zákazníka. Při kontrole tým zjistí, že zákazníci do volného pole občas píší informace o zdravotním stavu. Centrální logovací služba tak obsahuje citlivější údaje, než odpovídá účelu diagnostiky. Správce nezvolí pouhé rozšíření zásad soukromí na všechno, co systém náhodou zachytil.
Tým nahradí obsah zprávy identifikátorem požadavku, chybovým kódem a nezbytnými technickými parametry. Potřebný detail lze v odůvodněném případě dohledat v chráněném zdrojovém systému s omezeným přístupem. Historické logy posoudí podle rozsahu, účelu a potřeby odstranění. Pokud byly neoprávněně zpřístupněny, otevře také posouzení porušení zabezpečení.
Při další kontrole správce vybere zkušební formulář se syntetickými údaji a ověří výsledný záznam v celé cestě. Prohlédne aplikaci, přenos i centrální úložiště. Samotná úprava jedné obrazovky by totiž nemusela odstranit kopii v navazujícím nástroji. Výsledek uloží jako omezený důkaz, nikoli jako plný export produkčních zpráv.
Doba uchování podle potřeby
Určete, jak dlouho je záznam potřebný pro konkrétní účel, a od jaké události dobu počítáte. Bezpečnostní vyšetřování může potřebovat jiný horizont než ladění běžné chyby. Použijte doloženou potřebu detekce, incidentní zkušenost a případné konkrétní povinnosti. GDPR nestanoví jednu společnou lhůtu pro všechny provozní logy.
Oddělte běžný cyklus od důkazů konkrétního incidentu. Pokud vyjmete potřebný úsek z automatického mazání, uveďte důvod, rozsah, přístup a událost dalšího přezkoumání. Nezastavujte uchování celého systému na neurčito kvůli jednomu případu. Zálohy a repliky zahrňte do celkového pravidla a ověřte jeho technické provedení.
Přístup a integrita záznamů
Přidělte přístup podle potřeby: provozní tým může číst diagnostiku, bezpečnostní tým citlivější auditní události a jiná role spravovat nastavení. Zvažte oddělení osoby provádějící významné změny od možnosti bez stopy upravit související logy. Ochrana integrity musí odpovídat riziku a možnostem systému, ne jen deklaraci v dokumentu.
Synchronizace času pomáhá spojit události z více zdrojů. Zaznamenejte časové pásmo a vysvětlete případné rozdíly. Pokud se logy z různých aplikací časově rozcházejí, může vyšetřovatel nesprávně určit pořadí událostí. Spolehlivost důkazu závisí na kontextu a původu, nikoli pouze na jeho existenci.
Vyhledávání při incidentu nebo žádosti
Určete, kdo může zahájit cílené hledání, na základě jakého případu a v jakém rozsahu. Hromadné prohlížení aktivit zaměstnance bez odůvodnění není totéž co vyšetřování konkrétního bezpečnostního signálu. Uchovejte záznam provedeného vyhledání a přiměřeně omezte export výsledků. Výstup nemá automaticky putovat do běžné týmové konverzace.
Při žádosti o přístup zvažte, které logové údaje se týkají žadatele a jak je srozumitelně poskytnout při ochraně ostatních osob a bezpečnosti. Automatické odmítnutí všech logů jako technických není dostatečné. Stejně není správné vydat celou interní bezpečnostní databázi. Posuzujte konkrétní informace a vhodný způsob jejich zpřístupnění.
Dodavatel logovací služby
Ověřte roli dodavatele, uložené kategorie, další zpracovatele, přístupy a případná předání. Centralizací logů může vzniknout nový významný datový tok, který nebyl v registru činností popsán. Smlouva musí odpovídat skutečnému rozsahu a potřebné součinnosti. Zkontrolujte také, zda se diagnostické údaje nepoužívají pro jiné vlastní účely dodavatele.
Při změně služby řešte export potřebných záznamů, zachování čitelnosti a odstranění starého prostředí. Přístupové klíče a integrační účty musí být odvolány. Nakonec ověřte novou konfiguraci sběru a retenčního cyklu. Úspěšná migrace dashboardu sama neprokazuje, že staré osobní údaje přestaly být dostupné.
Kontrola kvality událostí na zkušebním případu
Vytvořte omezenou syntetickou událost, například změnu oprávnění zkušebního účtu, a sledujte ji od aplikace do centrálního úložiště. Ověřte identitu aktéra, čas, výsledek a vazbu na schválený požadavek. Chybějící pole může znemožnit rozlišení úspěšného zásahu od zamítnutého pokusu. Naopak celé tělo požadavku může přidávat údaje, které k této otázce vůbec nepotřebujete.
Zkontrolujte i situaci, kdy centrální systém není dostupný. Určete, zda se události dočasně ukládají, ztrácejí nebo znovu odesílají, a jak se projeví chyba. Provozní tým musí vědět, že výpadek sběru může omezit schopnost zjistit incident. Není správné tvrdit, že všechny důležité události jsou dohledatelné, pokud nebyla tato cesta ověřena.
Při změně formátu logu zachovejte potřebnou čitelnost starších záznamů. Nový název pole nebo jiná časová jednotka mohou způsobit chybné vyhledání. Do dokumentace napište význam změny a ověřte běžné dotazy používané při incidentu nebo žádosti. Technická migrace je dokončena až tehdy, když odpovědný pracovník dokáže údaje správně najít a vyložit v rámci povoleného účelu.
Při předání role novému správci logů ověřte, že rozumí významu událostí i povolenému účelu jejich čtení. Technické oprávnění samo není pokynem sledovat libovolnou osobu. Předejte současně otevřené incidenty, retenční výjimky a kontakty odpovědných vlastníků.
Navazující pracovní podklady
- Doba uchování osobních údajů: pracovní tabulka a výmaz: pro každý účel logování určete potřebný interval a ověřený výmaz.
- Politika hesel a přístupů podle GDPR: pracovní pravidla: chraňte přístupové prostředky a nikdy neukládejte hesla do provozních událostí.
- Evidence porušení zabezpečení: vzor registru incidentů: při incidentu zachovejte potřebné důkazy a jejich časový kontext.
- Balanční test oprávněného zájmu: pracovní vzor: posuďte nezbytnost a dopady monitorování založeného na oprávněném zájmu.
- Informace pro zaměstnance podle GDPR: vzor pro HR: zaměstnancům srozumitelně vysvětlete přiměřené sledování pracovních systémů.
Právní východiska: české znění GDPR na EUR-Lex a tematické informace Úřadu pro ochranu osobních údajů. Odkazy ověřeny 8. září 2026. Popsané pracovní postupy jsou návrhem pro přizpůsobení konkrétnímu zpracování; příklady nepředstavují rozhodnutí dozorového úřadu.