Logy a auditní stopy: kritéria sběru, uchovávání a zabezpečení

Soukromí a bezpečnost
Eva Senková
Logy a auditné stopy: Kritériá zberu, retencie a bezpečnostná ochrana

Logy a auditní stopy: co sbírat a jak chránit

Logy a auditní stopy jsou centrálním nervovým systémem bezpečnosti, provozu i souladu s předpisy. Umožňují odhalovat incidenty, prokazovat soulad s politikami, analyzovat chyby a vytvářet metriky. Nesprávně navržené logování však vytváří právní rizika, úniky osobních údajů a náklady bez přínosu. Tento článek nabízí systematický rámec, co sbírat, jak data strukturovat a jak logy chránit, aby byly užitečné, zákonné a odolné.

Strategické cíle logování

  • Detekce a vyšetřování: rychlá identifikace anomálií, korelace událostí, časové osy incidentů.
  • Audit a průkaznost: důkazy o přístupech, změnách konfigurace, souhlasu uživatele a souladu s procesy.
  • Provoz a kvalita: měření výkonnosti, chyb a SLA/SLO.
  • Forenzní hodnota: konzistentní časové údaje, integrita, neměnnost a kontext pro pozdější analýzy.

Principy „privacy & security by design“ při logování

  • Minimalizace údajů: logujte pouze to, co potřebujete k naplnění bezpečnostních/provozních cílů; omezte granularitu a přesnost (např. zkrácené IP adresy, hodnoty rozdělené do intervalů).
  • Transparentnost: dokumentujte kategorie logů, účely, dobu uchovávání a přístupy; usnadněte odpovědi na žádosti subjektů údajů.
  • Izolace a nejnižší oprávnění: samostatná infrastruktura, RBAC, oddělení povinností (SoD) pro zápis/čtení/správu.
  • Integrita a neměnnost: zásady WORM, časová razítka, podepisování, Merkleho hashování, detekce manipulace.

Taxonomie logů: co sbírat

  • Autentizace a autorizace: pokusy o přihlášení (úspěšné/neúspěšné), toky 2FA, resetování hesla, změny rolí, delegování přístupu, tokeny (pouze metadata, nikoli tajné údaje).
  • Přístupy k datům: kdo, kdy, ke kterým entitám (tabulkám, objektům, záznamům), účel/kontext, počet dotčených položek.
  • Změny konfigurace a kódu: operace s infrastrukturou jako kódem, změny bezpečnostních politik, pravidel firewallu, šablon IAM, zásahy v CI/CD.
  • Provozní události: metriky dostupnosti, chybové kódy, timeouty, opakované pokusy, jističe (circuit-breakers), fronty a odchylky latence.
  • Síť a koncové body: toky/logy bran, proxy serverů, WAF, DNS, události EDR/antiviru, USB/médií, šifrování disků.
  • Aplikační transakce: metadata požadavků/odpovědí, identifikátory transakcí, idempotency keys, výsledky validací.
  • Logy dodavatelů a API: volání třetích stran, chybové stavy, limity, signály odvolání souhlasu.

Čemu se vyhnout: nebezpečný obsah v logách

  • PII a citlivé údaje: rodná čísla, čísla dokladů, celé IP adresy s geolokací bez důvodu, zdravotní údaje, obsah zpráv.
  • Tajné údaje: hesla, přístupové tokeny, klíče, cookies, celé hlavičky Authorization.
  • Výpisy obsahu: kompletní payloady formulářů, soubory, binární bloby, které nemají diagnostickou hodnotu.

Struktura a standardy: aby se logy daly používat

  • Strukturované logy (JSON/CBOR): klíče s jasným schématem, typy a verzemi; žádné řetězce volného textu jako jediný zdroj pravdy.
  • Identifikátory: event_id (globálně jedinečný), trace_id, span_id pro distribuované trasování, actor_id (pseudonymizovaný), resource_id, tenant_id.
  • Kontext: purpose (účel zpracování), legal_basis, consent_version, client_type (web/mobile/api), auth_method.
  • Čas: monotónní a synchronizovaný (NTP), ISO 8601 s časovou zónou, přednostně také monotónní event_seq.
  • Normalizace: kde je to možné, použijte OpenTelemetry/OTLP; u syslog/CEF/LEEF namapujte data na jednotné schéma.

Maskování, redakce a pseudonymizace v pipeline

  • Pravidla redakce před zápisem: regulární výrazy a klasifikátory pro maskování e-mailových adres, telefonních čísel a čísel karet; přísná kontrola režimů „debug“.
  • Pseudonymizace identit: stabilní, rotující pseudonymy (např. HMAC s rotovaným saltem) namísto úplných identifikátorů.
  • Hashování hodnotových polí: porovnatelné hashe pro korelace (se spravovaným saltem), nikdy ne prosté SHA bez saltu.

Integrita a neměnnost: jak zajistit důvěryhodnost logů

  • WORM/immutability: objektová úložiště s funkcí object lock, zásadami uchovávání a právním pozastavením mazání (legal hold); zákaz mazání před uplynutím doby uchovávání.
  • Podepisování a hashování: dávkové podpisy (JWS) nebo Merkleho stromy; pravidelné ukotvení u externí časové autority (např. TSA) pro zajištění průkaznosti.
  • Oddělení rolí: jiný tým/účet pro ingest, jiný pro query, žádný administrátor nesmí zpětně měnit záznamy.

Uchovávání a kategorizace

  • Rizikové/bezpečnostní logy: 12–24 měsíců (podle regulačních požadavků a modelu hrozeb).
  • Provozní logy: 30–180 dní pro rychlé dotazy + dlouhodobé „cold storage“ pro analýzu trendů.
  • Agregované údaje s minimalizovaným PII: delší uchovávání bez identifikátorů pro reporting.
  • Legal hold: mechanismus pro pozastavení mazání během vyšetřování/sporu.

Přístupové modely a zabezpečení

  • RBAC/ABAC: role „reader“, „investigator“, „auditor“, „curator“; atributy tenanta/projektu.
  • MFA a síťové kontroly: přístup pouze přes firemní sítě/VPN, schválená zařízení, zaznamenávání relací ve vyšetřovacích konzolích.
  • Privileged Access Management: dočasná oprávnění „break-glass“ s úplnou auditní stopou.

Logovací stack a architektura

  • Edge/agent: spolehlivé agenty (např. Fluent Bit, Vector) s lokální frontou a TLS/mTLS do sběrnice.
  • Přenos: vysokokapacitní sběrnice (Kafka/PubSub) se šifrováním, kvótami a DLQ (dead letter queue).
  • Obohacování: pipeline pro geo/ASN, mapování IP→tenant (je-li nutné), korelační tabulky; pokud možno bezstavové.
  • Ukládání: horký index (SIEM/TSDB) na 30–90 dní, studené objektové úložiště pro historické dotazy.
  • Dotazy a detekce: pravidla SIEM, ML detekce anomálií (s vysvětlitelností), playbooky SOAR pro automatizovanou reakci.

Specifika podle technologií

  • Cloud (IaaS/PaaS/SaaS): zapněte logy control-plane (IAM, KMS, VPC, API), přístupy data-plane a integrujte CloudTrail/Activity logs do centrálního SIEM.
  • Kubernetes: audit API serveru (create/patch/delete), admission controllery, stdout/stderr kontejnerů, události Node a CNI.
  • Databáze: nativní audit (SELECT/UPDATE/DDL), vzorkování velkých dotazů, klíčové operace transparentního šifrování dat.
  • Web/API: HTTP přístupy (metoda, cesta, stav, latence), omezte logování těl požadavků; hlavičky trace (W3C traceparent); události WAF.
  • OS: Windows Event (Security, Sysmon), Linux auditd/eBPF; podepsané balíčky pravidel a centrální politika.

Etika a soukromí: IP, cookies a profilování

  • IP adresy jsou osobním údajem v kombinaci s dalšími signály; při analytice upřednostňujte zkrácení/odšumění.
  • Identifikátory: používejte krátkodobá, rotující ID; nezapisujte do logů trvalé cookies bez důvodu.
  • Účelové omezení: logy určené k bezpečnostním účelům nepoužívejte k marketingovému profilování.

Metriky kvality logování

  • Pokrytí: procento kritických systémů zapojených do centrálního logování.
  • Aktuálnost/latence: medián a P95 doby od události po indexaci.
  • Integrita: podíl dávek s ověřeným podpisem/Merkleho kořenem.
  • Podíl šumu: poměr bezcenných událostí; cílem je jeho trvalé snižování.
  • Míra úniku PII: počet citlivých polí zablokovaných v pipeline (trend k nule).

Runbook: incident a vyšetřování

  1. Zachování: okamžité uplatnění legal hold na relevantní oddíly logů, kontrolní bod hash/Merkle.
  2. Rozsah: časová osa, dotčené identity a zdroje, mapování trace_id napříč systémy.
  3. Omezení: změny přístupů, blokování tokenů, revize pravidel.
  4. Odstranění hrozby a obnova: opravy konfigurací, testy, návrat do normálního stavu; aktualizace detekcí.
  5. Poučení: vylepšení schématu, redakce, pravidel SIEM a playbooků.

Antivzory a časté chyby

  • „Pro jistotu logujme všechno“: vede k nákladům, riziku úniku PII a zhoršení poměru signálu k šumu.
  • Prostý text bez schématu: data nelze vyhledávat, obtížně se korelují a jsou náchylná při změnách verzí.
  • Debug v produkci: únik citlivých těl požadavků a tajných údajů.
  • Jeden administrátor na všechno: bez SoD a bez důvěryhodného auditu.
  • Nezabezpečený export: soubory CSV s logy v e-mailech nebo na discích bez šifrování.

Kontrolní seznam pro návrh logování

  • Definované účely, schéma a politika PII (maskování, hashování, pseudonymy).
  • Zapnuté WORM, podepisování a synchronizace NTP.
  • RBAC/SoD, MFA a oddělené identity pro ingest a query.
  • Doby uchovávání, legal hold, mechanismy pro export DSR.
  • Detekce SIEM, playbooky SOAR a pravidelné testy (purple team).

Implementační roadmapa (30–60–90 dní)

  • 0–30 dní: inventarizace zdrojů, společné schéma (JSON), základní maskování, centrální úložiště s TLS, NTP, rychlá vítězství v SIEM (kritické detekce).
  • 31–60 dní: WORM/object lock, podepisování dávek, RBAC/SoD, revize PII a pravidel redakce, onboarding auditních logů cloudu/k8s.
  • 61–90 dní: ukotvování Merkleho hashů, právní procesy a procesy DPO (DSR), optimalizace dob uchovávání a nákladů, detekce anomálií pomocí ML pod dohledem, runbooky a školení.

Dobře navržené logování je přesné, minimalistické, strukturované a chráněné. Kombinace jasného schématu, redakce PII, neměnného úložiště a spolehlivé analytiky vytváří prostředí, v němž jsou logy zdrojem pravdy – nikoli rizikem. Investice do kvality logů se vrací při každém vyšetřování, auditu i optimalizaci provozu.