Jedna z nejpraktičtějších otázek kolem NIS2 zní jednoduše: co konkrétně máme logovat? Mnoho organizací na ni odpovídá dvěma špatnými způsoby. Buď začnou sbírat téměř všechno bez priorit, nebo naopak nechají logování v lokálních výchozích nastaveních a doufají, že to při auditu nebo incidentu nějak postačí. Ani jedna cesta není dobrá.
Smyslem není mít co nejvíc dat. Smyslem je mít dostatečně kvalitní a dostupné záznamy z míst, která opravdu rozhodují o auditní dohledatelnosti, incidentní časové ose a schopnosti obhájit, co se v prostředí stalo. Právě proto je důležitější priorita než objem.
Tento materiál nepředstavuje právní poradenství ani závazný výčet povinností. Slouží jako praktický rámec pro určení logovacího minima u menších a středních organizací.
Pro koho je tato stránka
Text je určený pro:
- IT manažery a správce infrastruktury,
- externí administrátory a MSP,
- vedení, které potřebuje pochopit, proč je priorita logů důležitá,
- bezpečnostní role, které skládají minimální auditní a incidentní základ.
Co si z ní odnesete
Po přečtení by vám mělo být jasné:
- proč dává větší smysl logovat prioritní zdroje než „všechno“,
- které vrstvy infrastruktury mají nejvyšší hodnotu pro audit a incidenty,
- jak odlišit rozumné minimum od rozšířené vrstvy,
- jak postupovat při omezeném rozpočtu a kapacitě,
- proč musí klíčové logy odcházet mimo zdrojové systémy.
Proč nestačí sbírat všechno bez priorit
Když organizace začne logovat bez priorit, často narazí na tři problémy:
- utopí se v objemu a ztratí přehled,
- utratí rozpočet za data s malou hodnotou,
- stejně jí chybí klíčové důkazy z identit, administrátorských zásahů nebo síťových přístupů.
U menších a středních firem je mnohem rozumnější začít otázkou: které systémy a události budou nejdůležitější, až budeme řešit audit, incident nebo interní šetření?
Jak přemýšlet o kritických systémech
Nejdůležitější nejsou vždy systémy s největším objemem logů. Důležité jsou ty, které rozhodují o:
- identitě a přístupech,
- administrátorských změnách,
- vzdáleném přístupu,
- síťové komunikaci,
- provozu klíčových služeb,
- správě virtualizace a úložišť,
- přístupech do cloudových a SaaS platforem.
Z praktického hlediska pomůže rozdělit logování do dvou vrstev:
- minimum, bez kterého je auditní a incidentní obraz slabý,
- rozšířená vrstva, která přidává širší kontext a analytickou hodnotu.
Užitečné je také dívat se na systémy podle toho, zda odpovídají na některou z těchto otázek:
- kdo udělal změnu,
- kdo získal nebo ztratil privilegovaný přístup,
- odkud přišel vzdálený přístup,
- co se stalo těsně před výpadkem nebo podezřelou aktivitou,
- které systémy pomohou potvrdit nebo vyvrátit incidentní hypotézu.
Pokud zdroj nepomáhá ani s jednou z nich, je často vhodnější až ve druhé fázi než v logovacím minimu.
Minimum: identita a Active Directory
Pokud organizace provozuje Active Directory nebo jinou centrální identitu, je to téměř vždy priorita číslo jedna. Z identity se skládá velká část důkazní stopy.
Prioritní jsou zejména:
- úspěšná a neúspěšná přihlášení,
- změny hesel a reset účtů,
- zakládání a mazání účtů,
- změny skupin a privilegií,
- změny v administrátorských účtech,
- události kolem MFA a podmíněného přístupu, pokud existují.
Proč je to důležité:
- identita ukazuje, kdo co dělal,
- z identity se často odvíjí pohyb útočníka,
- bez identity nelze dobře rekonstruovat změny oprávnění ani eskalaci privilegií.
Minimum: Windows servery a vybrané endpointy
Ne všechny koncové stanice musí být první den součástí minima. Ale určité systémy ano:
- doménové řadiče,
- jump hosty,
- administrátorské stanice,
- klíčové aplikační servery,
- servery s citlivými daty nebo kritickou rolí.
Zajímají vás hlavně:
- přihlášení,
- spuštění privilegovaných akcí,
- změny služeb a plánovaných úloh,
- vypínání bezpečnostních funkcí,
- chyby a události související s provozní anomálií.
Právě z těchto systémů se často skládá incidentní časová osa.
Minimum: firewally, VPN a síťové prvky
Síťová vrstva bývá pro audit i incidenty zásadní, protože ukazuje:
- odkud někdo přišel,
- kam se připojoval,
- jak probíhala vzdálená správa,
- jaké byly neobvyklé směry komunikace,
- kdy došlo ke změně pravidel nebo konfigurace.
Prioritní zdroje bývají:
- firewally,
- VPN koncentrátory,
- reverzní proxy a gateway,
- vybrané switche a routery,
- zařízení segmentující kritickou infrastrukturu.
Bez této vrstvy bývá těžké pochopit šíření incidentu a hranice dopadu.
Minimum: hypervisory, NAS a appliance
Virtualizační platformy, storage a různé appliance se často logují pozdě nebo vůbec. Přitom právě tam dochází k událostem, které jsou při incidentu nebo kontrole velmi důležité.
Dává smysl sbírat:
- přihlášení správců,
- změny konfigurace,
- vytvoření, smazání a přesuny virtuálních strojů,
- změny snapshotů, datastore a storage politik,
- bezpečnostní a systémové události zařízení.
To je zvlášť důležité tam, kde na virtualizaci a storage stojí kritické služby firmy.
Minimum: cloud a SaaS systémy
Mnoho organizací už dnes neprovozuje kritické procesy jen lokálně. Bez cloudových a SaaS logů tak vzniká slepé místo.
Typicky dává smysl řešit:
- identity a přihlášení do M365 nebo Google Workspace,
- administrátorské změny v tenantovi,
- bezpečnostní alerty a audit logy cloudové platformy,
- aktivity v business kritických SaaS systémech,
- privilegované zásahy v IaaS a PaaS službách.
Bez této vrstvy je auditní a incidentní obraz neúplný, i když on-premise část logujete dobře.
Co bývá nejčastěji podceněné
V praxi se často podcení zdroje, které nejsou „hlavní server“, ale nesou velmi silný důkazní význam:
- management rozhraní firewallů a appliance,
- administrátorské účty v cloudových tenantech,
- změny ve VPN konfiguraci,
- hypervisor a storage události,
- logy z nástrojů, přes které správci dělají vzdálené zásahy.
Právě tyto vrstvy často vysvětlují, jak se útok nebo chyba skutečně šířily. Když chybí, organizace sice může mít spoustu provozních logů, ale stále jí chybí rozhodující důkazní spojnice.
Rozšířená vrstva: kde dává smysl přidat víc
Jakmile funguje minimum, dává smysl rozšiřovat pokrytí podle rizika a kapacity. Typicky sem patří:
- širší pokrytí endpointů,
- aplikační logy důležitých interních systémů,
- detailnější síťové telemetrie,
- specializované bezpečnostní appliance,
- dlouhodobější korelační a analytické vrstvy.
Rozšířená vrstva by měla navazovat na reálná rizika, ne na snahu „mít všechno pro jistotu“.
Jak prioritizovat při omezeném rozpočtu a kapacitě
Pokud je rozpočet omezený, použijte jednoduchý filtr:
1. Pomůže tento zdroj vysvětlit, kdo co udělal?
Pokud ano, má vysokou prioritu.
2. Pomůže tento zdroj složit incidentní časovou osu?
Pokud ano, má vysokou prioritu.
3. Pomůže tento zdroj obhájit auditní tvrzení?
Pokud ano, má vysokou prioritu.
4. Je tento zdroj dnes ohrožený tím, že logy zůstávají jen lokálně?
Pokud ano, vyplatí se ho přesunout mezi první kandidáty na centralizaci.
Tento přístup obvykle vede k tomu, že první jsou identity, firewally, VPN, klíčové servery a cloudové identity.
Dobrá priorizace ale znamená i něco vynechat. Pro menší a střední organizace bývá častou chybou, že se snaží v první fázi sbírat rozsáhlou endpoint telemetrii, detailní aplikační debug logy nebo velmi široké síťové toky, aniž by měly pokrytý základ identity a administrátorských změn. Výsledkem je hodně dat, ale slabá auditní a incidentní použitelnost.
Proč logy musí být centralizované mimo zdrojové systémy
I správně vybrané logy jsou málo platné, pokud zůstávají jen lokálně. Při kompromitaci se útočník často snaží lokální záznamy měnit, mazat nebo znepřístupnit. Proto je zásadní, aby klíčové záznamy odcházely mimo zdrojové systémy do centrální vrstvy.
Centralizovaný sběr a uchování mimo zdrojové systémy významně snižuje riziko:
- ztráty klíčových záznamů,
- manipulace s historií,
- přepsání důležitých událostí,
- nedostupnosti důkazní stopy při incidentu.
Téma auditní obhajitelnosti detailně rozebírá stránka Audit, dohledatelnost a důkazní stopa.
Jak vypadá praktické minimum pro SMB a střední firmy
Pokud chcete začít pragmaticky, minimum často znamená:
- centrálně sbírat identitu, firewally, VPN a klíčové servery,
- přidat cloudové identity a hlavní SaaS administrátorské logy,
- ověřit, že logy opravdu dorážejí a nejsou jen „nastavené“,
- držet retenci mimo zdrojové systémy,
- být schopní rychle vyhledat událost podle času, systému a identity.
To je často mnohem hodnotnější než rozsáhlý projekt bez jasných priorit.
Stejně důležité je ověřit, že minimum skutečně funguje. Nestačí mít zdroj „přidaný do konfigurace“. Potřebujete vědět:
- že logy dorážejí konzistentně,
- že jsou čitelné a dávají smysl i po čase,
- že umíte dohledat konkrétní změnu nebo přihlášení,
- že výpadek sběru nezůstane týdny bez povšimnutí,
- že klíčová důkazní stopa neleží jen v jednom lokálním souboru na napadeném systému.
Právě toto provozní ověření odlišuje připravenost od formálního zaškrtnutí položky.
Dobře zvolené minimum navíc usnadňuje další růst. Když organizace zvládne první vrstvu správně, může ji postupně rozšiřovat bez chaosu, duplicit a zbytečného sběru dat s nízkou hodnotou.
Praktická doporučení
Pokud chcete rychle udělat pořádek:
- Sepište si kritické služby a systémy.
- Ke každé vrstvě určete, jaké logy mají nejvyšší auditní a incidentní hodnotu.
- Vyberte minimum pro první fázi.
- Zajistěte centrální uchování mimo zdrojové systémy.
- Ověřte, že z logů umíte složit konkrétní scénář, ne jen že „někam tečou“.
Pokud teprve řešíte širší kontext, navazuje hlavní přehled NIS2 a uchování logů.
FAQ
Máme sbírat všechny Windows eventy?
Obvykle ne. Začněte u událostí s vysokou hodnotou pro identitu, privilegia, změny a bezpečnostní anomálie.
Co je první priorita, když máme omezený rozpočet?
U většiny organizací identita, firewally, VPN a klíčové servery. Tyto zdroje nejčastěji rozhodují o kvalitě auditní i incidentní dohledatelnosti.
Nestačí, že logy umíme při potřebě vytáhnout z jednotlivých zařízení?
Je to slabé řešení. Při kompromitaci nebo výpadku se k nim nemusíte dostat včas a mohou být neúplné nebo změněné.
Interní odkazy
- Zpět na hlavní přehled NIS2
- Spadá vaše organizace pod NIS2?
- NIS2 pro vedení firmy
- Audit, dohledatelnost a důkazní stopa
Další krok
- Získat minimální logovací standard pro SMB a střední firmy.
- Nechat si posoudit připravenost prioritních zdrojů logů a retence.
- Požádat o orientační konzultaci k mapování logovacího minima pro audit a incidenty.