Tentokrát jsme se v CyberEdu Konzultační hodině zaměřili na Technická opatření, které se vztahují k zákonu o kybernetické bezpečnosti. Expertním hostem byl Viktor Tyúkos z EY. Níže si můžete shlédnout záznam vysílání, nebo přečíst poznámky.
Technická bezpečnostní opatření – Režim vyšších povinností
Zákon definuje 11 oblastí pro technická opatření:
1. Fyzická bezpečnost
◦ Cílem je předcházet poškození, odcizení nebo zneužití cenných aktiv.
◦ Je nutné vymezit fyzický bezpečnostní perimetr a rozdělit jej do ochranných zón podle důležitosti aktiv. (Např. recepce vs. serverovna).
◦ Opatření zahrnují: zámky, turnikety, čipové karty, biometrii (otisky prstů, skeny zornice).
◦ Dále: protipožární ochrana, automatizované hasicí systémy, záložní zdroje pro případ výpadku elektřiny.
◦ Kamerové systémy a logování vstupů (kdo, kdy, kam vstoupil).
◦ Důležité je i používat selský rozum: např. zabezpečené dveře do serverovny jsou k ničemu, když jsou stěny ze sádrokartonu nebo nevedou až ke stropu (umožňující přelézt).
2. Bezpečnost komunikačních sítí
◦ Segmentace sítě je klíčová (oddělit vývojová, testovací, administrativní a zálohová prostředí).
◦ Důležitá je dokumentace datových toků a komunikace mezi segmenty, nejen dokumentace samotných segmentů. Nedostatečná dokumentace vede k volně nastaveným firewallům a pravidlu „allow any“, což ruší efektivitu firewallu.
◦ Zabezpečené vzdálené přístupy (např. VPN) s rozumnými timeouty a vynuceným opětovným přihlášením.
3. Správa identit
◦ V době remote work je identita uživatele nejdůležitější věcí k ochraně.
◦ Implementace centrálního nástroje pro správu a ověřování identit (Identity Access Management – IAM).
◦ Multifaktorová autentizace (MFA) by měla být téměř všude.
◦ Zero trust přístup: ověřovat identitu uživatele před přístupem ke každému systému.
◦ Kde nelze použít MFA, použít kryptografické klíče, certifikáty nebo dostatečně silná hesla.
◦ Požadavky na hesla: velká/malá písmena, speciální znaky, čísla. Pozor na snadno uhodnutelné vzorce (první písmeno velké, pak čísla, speciální znak). NIST již nevyžaduje expiraci hesel a preferuje passwordless autentizaci (Face ID, otisky prstů).
◦ Osobní tip pro hesla: Diceware – generuje hesla z kombinace čtyř slov, která jsou snáze zapamatovatelná a stejně silná jako náhodně generovaná dlouhá hesla.
◦ „Break Glass“ účty (nouzové/záložní účty pro obnovu systému nebo bezpečnostní incident) musí být stejně komplikované, s 22 znaky. Hesla by měla být odrotována/změněna při podezření na kompromitaci. Přístup k nim by měl být pouze v případě potřeby (např. v obálce v trezoru).
4. Řízení přístupových práv a oprávnění
◦ Často integrováno s IAM systémy.
◦ Dodržování principů nejnižšího oprávnění a řízení na základě rolí (čtení/zápis, přístup k aktivům).
◦ Žádné konflikty zájmů v definici rolí.
◦ Pro administrátorské účty se používá „Just in Time access“ (krátkodobý přístup pro konkrétní úkon), často s nástrojem Privileged Access Management (PAM).
◦ Nepoužívat sdílené administrátorské účty; každý administrátor by měl mít svůj vlastní účet pro lepší dohledatelnost.
5. Detekce bezpečnostních událostí a incidentů
◦ Vyhláška vyžaduje kontrolovat a blokovat komunikaci nejen na perimetru sítě (internet), ale i mezi jednotlivými segmenty a uvnitř segmentů.
◦ Řídit a sledovat dění na koncových stanicích (spouštění programů, kódu, připojování externích zařízení).
◦ Používat nástroje, které dokáží vyhodnocovat události na základě chování (programů, uživatelů, síťové komunikace), nejen na základě známých virů.
6. Zaznamenávání událostí (Logování)
◦ Důležité je stanovit rozsah a detail logování na základě hodnoty aktiv a bezpečnostních potřeb.
◦ Zajistit synchronizaci času napříč všemi systémy pro korelaci událostí.
◦ Pro nové systémy a servery by měly být připraveny automatické integrace s log managementem (např. přes image), aby se předešlo manuálním chybám.
◦ Minimální rozsah logování dle vyhlášky:
- všechny detekované události a incidenty,
- síťová komunikace,
- přihlášení/odhlášení (úspěšné i neúspěšné),
- pokusy o privilegované činnosti,
- činnosti uživatelů (datum, čas, časové pásmo, typ činnosti, uživatel, účet, identita).
◦ Zajistit důvěryhodnost a integritu logů, aby útočník nemohl změnit.
◦ Mít centralizovaný nástroj pro sběr a uchovávání logů, oddělený od zbytku sítě (ochrana před ransomwarem).
◦ Uchovávat záznamy minimálně 18 měsíců.
7. Vyhodnocování bezpečnostních událostí
◦ Množství logů a dat vyžaduje automatizované systémy jako SIEM (Security Information and Event Management). Microsoft v Azure zavádí AI agenty pro korelaci dat.
◦ SIEM není „magická krabička“; vyžaduje neustálou optimalizaci, ladění a testování pravidel.
◦ Minimalizovat false positives (hlášení událostí, které se nestaly).
◦ Preferovat menší množství dobře vyladěných pravidel před tisícovkou špatně spravovaných.
8. Aplikační bezpečnost
◦ Doporučuje se používat pouze podporovaná technická aktiva; systémy po „end of life“ minimalizovat, izolovat nebo nahradit.
◦ Klasický vulnerability management: skenování zranitelností, aplikování patchů, pravidelné updatování systémů.
◦ Penetrační testování: během vývoje, po větších updatech a pravidelně alespoň jednou za dva roky. Penetrační testy nenajdou všechny zranitelnosti a mají časové omezení. Důležité je výsledky řešit a provádět retesty.
9. Šifrování
◦ Požadavek na šifrování veškeré komunikace (e-mailová, telefonní, hlasová – např. přes Teams).
◦ Pro implementaci šifer používat doporučení od NÚKIB (Národní úřad pro kybernetickou a informační bezpečnost).
◦ Správa kryptografických klíčů a certifikátů pomocí nástroje, který automatizuje jejich generování, distribuci, ukládání a případnou revokaci.
◦ Pravidelně kontrolovat a auditovat klíče a certifikáty.
◦ Udržovat šifrovací algoritmy aktuální (např. používat TLS 1.3 namísto starších verzí jako 1.0 nebo 1.1, které jsou prolomitelné).
10. Zajištění dostupnosti regulované služby
◦ Stanovení BCM (Business Continuity Management) a BCP (Business Continuity Plan) plánů.
◦ Technická podpora: zálohování, zajištění integrity záloh, testování obnovy systémů ze záloh, znalost rychlosti a času obnovy.
◦ Ideálně pravidlo 3-2-1: tři lokální zálohy, dvě off-site zálohy, jedna offline záloha (např. na páskách).
◦ Příklad ze Slovenska: měsíční nedostupnost katastru nemovitostí kvůli nedostatečnému zálohování/obnově.
11. Zabezpečení průmyslových a řídicích systémů
◦ Platí pro ně všechna výše uvedená opatření, ale s řadou specifických požadavků.
◦ Často se jedná o proprietární systémy s omezeným přístupem a fyzickou bezpečností.
◦ Mají pomalejší upgrade cyklus (životnost 15, 20, 30+ let), což znamená zastaralé systémy s menším výpočetním výkonem.
◦ Někdy samotné šifrování může být natolik náročné, že ovlivní primární funkcionalitu výrobní linky.
Technická bezpečnostní opatření – Nižší režim povinností
• Většina základních požadavků z vyššího režimu platí i pro nižší režim, ale v omezenějším rozsahu.
• Týká se šesti oblastí (oproti 11 pro vyšší režim).
• Odpadají některé „přesahující“ požadavky: např. nepotřebujete nástroj pro automatickou správu certifikátů (lze manuálně), nepotřebujete XDR/EDR pro kontrolu chování uživatelů na koncových stanicích.
• Základ jako správa identit, MFA, šifrování komunikace, segmentace zůstává.

Organizací opatření jsme probírali v tomto článku.