Logy a auditní stopy: kritéria pro sběr, zabezpečení a ochranu integrity dat

Proč logy a auditní stopy rozhodují

Logy a auditní stopy jsou základní infrastrukturou důvěry: umožňují detekci incidentů, forenzní rekonstrukci, prokázání souladu a nepopiratelnost klíčových úkonů. Bez nich je reakce na incidenty pomalá, kontroly jsou formalitou a riziko eskaluje. Zároveň však platí, že neuvážený sběr vytváří rizika pro soukromí a právní rizika. Cílem je sbírat jen to, co potřebujeme, ve strukturované podobě, s řízenou dobou uchovávání a technickou integritou.

Terminologie a rámec

Log: strukturovaný záznam o události systému nebo aplikace.
Auditní stopa: konzistentní sled událostí navázaný na identitu, systém nebo proces, který slouží k prokazatelnosti.
Telemetrie: metriky, trasování (traces) a logy používané k observabilitě.
Nepopiratelnost (non-repudiation): vlastnost, díky níž lze prokázat původ a integritu záznamu (podpisy, časová razítka, úložiště WORM).

Princip minimalismu: co skutečně sbírat

Každá kategorie logů musí mít účel, schéma a dobu uchovávání. Pokud je nemá, nesbírejte ji. Užitečné jsou zejména:

Identita a přístup: přihlášení, neúspěšné pokusy, změny hesel/2FA, přidělení/odebrání rolí, zvýšení oprávnění (JIT/JEA).
Správa konfigurace: změny zásad (GPO/MDM), firewallu/ACL, zásad IAM, rozdíly v infrastruktuře jako kódu, nasazení (CI/CD).
Citlivé operace: čtení/export dat, změny limitů, finanční transakce, schválení, deaktivace ochranných mechanismů.
Síť a perimetr: události VPN/ZTNA, souhrny proxy/HTTP, IDS/IPS, dotazy DNS (agregované), e-mailové brány.
Endpoint/EDR: spouštění procesů, změny registru, karantény, zjištěné indikátory kompromitace.
Aplikační logy: chyby (error/exception), přístup k API (kdo/kdy/endpoint/výsledek), limity a anomálie.
Integrita a verzování: kontroly integrity konfigurací, kontrolní součty artefaktů, podpisy.

Co nesbírat nebo důsledně redigovat

Osobní obsah (těla e-mailů, zprávy, dokumenty) – pokud to není nezbytné; upřednostněte metadata a řízené vzorkování.
PII v nezpracované podobě (rodná čísla, adresy, celá čísla platebních karet) – podle účelu použijte maskování nebo hashování se „saltem“.
Úplné IP adresy/UA pro dlouhodobé uchovávání – pro analytiku stačí zkrácené IP adresy nebo kategorie.
Tajemství (tokeny, klíče, hesla) – nikdy je nelogujte; ověřujte to pomocí linterů a filtrů za běhu.

Strukturované logování a schéma

JSON s pevným schématem (verze schématu, povinná pole, výčtové hodnoty, časová pásma UTC).
Identifikace: korelační ID (trace/span), ID požadavku, ID souhlasu/zdroje.
Kontext: účel zpracování, citlivost (štítek „confidential“), výsledek (allow/deny), důvod zamítnutí.
Čas: RFC3339, synchronizovaný pomocí NTP/PTP; zaznamenejte odchylku a stav synchronizace.

Integrita a nepopiratelnost

Digitální podepisování dávek logů (JWS) nebo jednotlivých záznamů; klíče v HSM/KMS, rotace a audit přístupů.
Řetězení Merkleovým stromem (hash chain) jako důkaz neměnnosti v rámci časových oken.
Úložiště WORM (object lock) se zásadami uchovávání a právním pozastavením mazání; zásadní pro forenzní analýzu.
Časová razítka (TSA) pro klíčové události – podpisy, změny zásad, schválení.

Datový řetězec: příjem, obohacení, ukládání

Ingest: spolehlivý přenos (TLS/mTLS, backpressure, opakování), ochrana před log injection (escapování, validace).
Enrichment: normalizace polí, mapování IP→ASN (agregované), geografické kategorie, štítky citlivosti, mapování identit.
Filtrování a redakce: pravidla drop/mask na straně serveru (regex, pole), firewall PII.
Storage: horká vrstva (SIEM/search), teplá (objektová), studená (archiv s WORM); definujte TTL a rozdělení do vrstev.

Přístupy a oddělení rolí

Princip nejnižších oprávnění pro přístup k logům; analytik nevidí PII, pouze pseudonymy/štítky; DPO/DPA má řízený přístup k depseudonymizaci.
Oddělení povinností: kdo mění zásady uchovávání, nesmí mazat logy incidentů; změny vyžadují kontrolu čtyř očí.
Přístupy Just-in-time s časovým omezením a auditem; zákaz trvalých administrátorských tokenů.

Doba uchovávání a právní soulad

Doby uchovávání vycházejí z účelu, regulace a rizika. Příklady:

Bezpečnostní logy (IAM, EDR, síť): 6–24 měsíců podle rizika; horká vrstva 30–90 dní.
Finanční transakce a schválení: podle místních účetních/finančních předpisů (často 5–10 let) – s přísným omezením přístupu.
Logy obsahující velké množství PII: minimalizujte je, zkraťte dobu uchovávání, po skončení účelu je anonymizujte; zdokumentujte právní základ (oprávněný zájem, právní povinnost).

GDPR a práva subjektů údajů v logách

Informování o kategoriích logování a dobách uchovávání v zásadách ochrany soukromí.
Přístup a výmaz: pro PII v logách definujte proveditelný postup (pseudonymizace, „selektivní výmaz“), který nenaruší forenzní analýzu.
Minimalizace a účel: nepřenášejte logy do BI bez posouzení účelu; oddělte observabilitu od marketingu.

Observabilita bez úniků: bezpečný návrh

Strukturované logování + OpenTelemetry pro traces/metrics; jednotný kontext a korelace.
Vzorkování pro velké objemy (tail-based pro chyby a anomálie); selektivní rozšíření při incidentu.
Redakce na okraji (edge redaction): citlivá pole se maskují ještě před opuštěním zóny aplikace.
Datové kontrakty pro logy: verzovaná schémata testovaná v CI; nasazení se zablokuje, pokud se bez schválení přidá PII.

Detekce a reakce: od pravidel po ML

Případy použití: útoky hrubou silou na IAM, exfiltrace (velké exporty), změna zásad mimo úřední hodiny, nové administrátorské role, deaktivace EDR.
Korelační pravidla a behaviorální modely: anomálie z více zdrojů (změna SIM + nové zařízení + změna 2FA).
Playbooky SOAR: při události s vysokým rizikem automatické zablokování tokenu, zvýšené ověření (step-up autentizace), vytvoření ticketu a upozornění DPO.

Testování a kvalita logů

Testování odolnosti logování: simulace výpadků ingestu, vynechávání polí, poruch časové synchronizace.
Canary events: syntetické události pro ověření cesty od začátku do konce (aplikace → SIEM → upozornění).
KPI kvality dat: procento záznamů se schématem v1/v2, podíl polí s hodnotou „unknown“, latence ingestu, procento podepsaných dávek.

Bezpečnostní zásady při práci s logy

Šifrování při přenosu (mTLS) i v klidovém stavu (AES-256/KMS), oddělené klíče pro prostředí (dev/test/prod).
Privátní propojení (VPC peering/PrivateLink) mezi aplikacemi a SIEM; žádné veřejné endpointy bez důvodu.
Kontrola exportů: povoleny jsou pouze kurátorované exporty; rozsáhlé výpisy vyžadují schválení a časová razítka.
Monitorování přístupu k samotným logům (meta-audit) – kdo a proč četl citlivé stopy.

Specifika: cloud, mobilní zařízení, zdravotnictví a bankovnictví

Cloud: využívejte nativní auditní logy (control plane/data plane), proudy podobné CloudTrail ukládejte do vlastního účtu se zámkem.
Mobilní zařízení: diagnostika bez osobního obsahu; hlášení o pádech bez PII, anonymizovaná zařízení, opt-in pro rozšířenou telemetrii.
Zdravotnictví/finance: přísnější režimy uchovávání a přístupu; zobrazení podle rolí s deidentifikací.

Procesy: governance a odpovědnosti

Vlastníci dat (data stewards) pro datové proudy logů; odpovídají za schéma, účel, dobu uchovávání a pravidla DLP.
Řízení změn: změny schémat a zásad uchovávání procházejí bezpečnostní radou (bezpečnostní revize + DPO).
Pravidelné audity: ověřování podpisů a zámků WORM, náhodné kontroly přístupů a spisů incidentů.

Kontrolní seznam pro architekty a vývojáře

Loguji strukturovaně, podle schématu a bez tajemství.
Mám maskování/redakci na okraji a testy, které selžou při úniku PII do logu.
Každý požadavek má trace ID; korelační ID předávám napříč službami.
Citlivé operace vyvolávají explicitní auditní událost s identitou a důvodem.

Kontrolní seznam pro provoz a bezpečnost

Synchronizace NTP/PTP je monitorována a odchylka je v mezích tolerance.
Logy jsou podepsané, uložené v WORM a přístupy jsou auditovány.
Zásady uchovávání jsou automatizované (TTL, rozdělení do vrstev) a testované.
Existují playbooky SOAR pro hlavní scénáře (exfiltrace, zneužití účtu, změna zásad).

KPI a metriky řízení rizik

Pokrytí logováním: procento klíčových systémů s aktivním ingestem a schématem.
Integrita: podíl dávek s platným podpisem/položkou Merkleova řetězce; počet neúspěšných ověření.
Latence detekce: průměrná doba od události k upozornění; cíl < 5 min pro vysoké riziko.
Skóre ochrany soukromí: podíl záznamů obsahujících PII mimo povolená pole; cíl → 0.

Reakce na incident: práce s logy během incidentu a po něm

Stabilizovat ingest (ukládání do vyrovnávací paměti), zmrazit dobu uchovávání (právní pozastavení mazání) a zabránit přepsání.
Forenzní analýza: vytvořit neměnné kopie, ověřit podpisy, vypočítat hashovací otisky; pracovat pouze s klony.
Rekonstrukce: korelovat identitu, síť, endpoint a aplikaci; sestavit časovou osu.
Analýza po incidentu: upravit pravidla, doplnit události chybějící kvůli „slepým místům“, aktualizovat playbooky.

90denní plán zavedení nebo zlepšení

Dny 1–30: inventarizace datových proudů logů, definice schémat a účelů, audit NTP, nasazení redakce PII na okraji, základní pravidla SIEM.
Dny 31–60: podepisování dávek, WORM pro kritické proudy, canary events, playbooky SOAR pro 5 hlavních scénářů, první dashboardy KPI.
Dny 61–90: vzorkování a optimalizace nákladů, rozšíření korelací, právní revize zásad uchovávání, cvičný forenzní test.

Méně šumu, více důkazů

Silný program logování a auditních stop je kombinací minimalismu, struktury, integrity a řízení přístupu. Sbírejte to, co má z hlediska bezpečnosti a souladu smysl, chraňte to jako citlivá data a zachovejte schopnost kdykoli prokázat, kdo co udělal – aniž byste z logů vytvořili novou plochu útoku nebo riziko pro soukromí.