Nový zákon o kybernetické bezpečnosti rok poté: co mít hotové v cloudu a CI/CD

Stav rok po účinnosti

Nový zákon o kybernetické bezpečnosti, kterým Česko převzalo směrnici NIS2, nabyl účinnosti 1. listopadu 2025. Organizace, které k tomuto dni splňovaly kritéria vyhlášky č. 408/2025 Sb. o regulovaných službách, měly na ohlášení 60 dnů (§ 6 odst. 1 zákona), tedy do 31. prosince 2025.

Poslední souhrnné číslo, které NÚKIB zveřejnil, je z února: podle tiskové zprávy z 11. února 2026 se k 8. únoru ohlásilo 4 825 subjektů z přibližně 6 000 očekávaných a ohlášeným bylo zasláno rozhodnutí o registraci. Novější oficiální statistiku se při přípravě článku dohledat nepodařilo.

Doručením rozhodnutí se rozbíhají tři lhůty. Shrnuje je například přehled lhůt po doručení rozhodnutí o registraci a jejich znění lze ověřit přímo v textu zákona č. 264/2025 Sb.

Dva režimy, dvě vyhlášky a žádný „cloudový paragraf“

Zákon rozlišuje režim vyšších a nižších povinností (§ 8). Obsah opatření určují prováděcí vyhlášky: č. 409/2025 Sb. pro vyšší režim a č. 410/2025 Sb. pro nižší režim.

Rozdíl je hlavně v hloubce. Vyšší režim vyžaduje plný systém řízení bezpečnosti informací s řízením rizik, aktiv, změn, dodavatelů a s auditem (§ 3 až § 27). Nižší režim má jedenáct věcných paragrafů (§ 3 až § 13) a méně konkrétních čísel.

Vyhlášky nepracují s pojmy jako cloud, kontejner nebo pipeline. Mluví o „technických aktivech“, „administrátorech“ a „dodavatelích“. Co z toho plyne pro tenant v Azure nebo účet v AWS, je věc výkladu. Následující mapování je proto inženýrský překlad, ne závazný výklad NÚKIB, a u sporných míst se vyplatí rozhodnutí zdokumentovat.

Identity a přístup: začněte u administrátorů cloudu

Obě vyhlášky chtějí jedinečné identifikátory, oprávnění „na úroveň nezbytně nutnou“, oddělení uživatelských a administrátorských účtů a pravidelný přezkum přístupů. Nižší režim to řeší v § 7 a § 8, vyšší v § 13, § 19 a § 20.

MFA se v § 8 odst. 2 vyhlášky č. 410/2025 Sb. vztahuje na „administrátory, uživatele a technická aktiva“. Pokud MFA ještě nemáte všude, připouští odst. 3 dočasně autentizaci kryptografickými klíči nebo certifikáty. V podkladech NÚKIB k nižšímu režimu je až třetím, nouzovým stupněm silná politika hesel.

Co to znamená v praxi

• Jedna identita, federace. Přístup do AWS přes IAM Identity Center, do Azure přes Entra ID. Žádní sdílení IAM uživatelé, žádné lokální účty v clusterech.
• MFA vynucená politikou (Conditional Access, SCP), nikoli dobrovolná. Pro privilegované role ideálně FIDO2.
• Oddělené administrátorské role s aktivací na omezenou dobu (Entra PIM, časově omezené permission sety).
• Root a break-glass účty mimo běžný provoz, s alertem na každé použití. Podklady NÚKIB zmiňují pro tyto speciální účty uložení údajů v zapečetěném trezoru.
• Čtvrtletní přezkum přiřazení rolí s exportem jako důkazem. Vyhláška říká „pravidelný“, interval si určujete sami.

Sporné místo jsou „technická aktiva“, tedy strojové identity. Dlouhodobé přístupové klíče v proměnných CI/CD jsou přesně ten typ autentizačního údaje, který se špatně hlídá. Rozumný výklad je nahradit je krátkodobými tokeny přes OIDC federaci, což zároveň odpovídá cestě přes kryptografické klíče a certifikáty.

Logování, detekce a hlášení incidentů

Minimální obsah záznamu je v obou režimech podobný: datum a čas včetně časového pásma, typ činnosti, jednoznačná identifikace aktiva a účtu původce a úspěšnost nebo neúspěšnost činnosti (§ 9 odst. 2 vyhlášky č. 410/2025 Sb.). Auditní logy cloudových control plane (CloudTrail, Azure Activity Log, přihlašovací a auditní logy Entra ID, audit log Kubernetes API) tyto položky obsahují. Problém bývá jinde: nejsou zapnuté ve všech účtech a regionech, nikdo je nevyhodnocuje a výchozí retence je krátká.

Vyšší režim požaduje uchování alespoň 18 měsíců a synchronizaci jednotného času. V AWS CloudWatch Logs to má praktický háček: retence se zadává z pevného výčtu hodnot a podle dokumentace API po 400 dnech následuje 545 a pak 731 dní. Hodnota 545 dní je o pár dní kratší než 18 kalendářních měsíců, bezpečná volba je tedy 731.

resource "aws_cloudwatch_log_group" "audit" {
  name              = "/org/audit/cloudtrail"
  retention_in_days = 731   # 545 dni je mene nez 18 mesicu
  kms_key_id        = aws_kms_key.logs.arn
}

V nižším režimu žádné číslo není. Podklady NÚKIB uvádějí 12 měsíců jako doporučenou dobu. Zvolenou retenci si zapište i se zdůvodněním, protože vyhláška ji váže na vaše „bezpečnostní potřeby“.

Hlášení incidentů

Podle § 16 zákona se prvotní hlášení podává nejpozději do 24 hodin po zjištění incidentu. U incidentů s významným dopadem následuje oznámení do 72 hodin po zjištění a závěrečná zpráva do 30 dnů od oznámení. Režim vyšších povinností hlásí NÚKIB incidenty ve stanoveném rozsahu, které mají původ v kybernetickém prostoru a u nichž nelze vyloučit úmyslné zavinění; režim nižších povinností hlásí Národnímu CERT jen ty z nich, které mají významný dopad na poskytování regulované služby (§ 15).

Technický důsledek: do 24 hodin musíte být schopni říct, co se stalo. To předpokládá centrální sběr logů mimo postižený účet, alerty směrované na konkrétní osoby a runbook, kdo hlášení podává. Podrobněji o stavbě takového řetězce píše článek o bezpečnostním monitoringu a logování.

Zálohy a obnova: bod, kde cloud svádí k falešnému klidu

Vyhlášky nechtějí jen zálohy dat, ale i „konfigurací a nastavení technických aktiv“. V cloudu to znamená, že součástí zálohy je i infrastruktura jako kód, stav Terraformu, manifesty clusteru, konfigurace identity providera a DNS. Snapshot databáze bez možnosti znovu postavit prostředí kolem ní obnovu neřeší.

Nižší režim navíc vyžaduje stanovit prioritu a pořadí obnovy aktiv a určit odpovědné osoby (§ 6). Vyšší režim přidává pravidelné testování integrity, dostupnosti a obnovitelnosti záloh a jejich ochranu (§ 26) a oddělení provozního, zálohovacího, vývojového, testovacího a administrátorského prostředí (§ 12).

Zranitelnosti, změny a pipeline

Nižší režim v § 12 požaduje „bezodkladné aplikování schválených bezpečnostních aktualizací“, evidenci nepodporovaných technických aktiv s kompenzačními opatřeními a pravidelné skenování zranitelností. Vyšší režim stanoví četnost: skenování alespoň jednou ročně z vnitřní i vnější sítě a penetrační test alespoň jednou za dva roky, mimo jiné před uvedením do provozu a při významných změnách (§ 24).

Roční sken je zákonné minimum, ne rozumná praxe pro prostředí, které se nasazuje několikrát denně. V pipeline dává smysl skenovat při každém buildu a běžící prostředí průběžně.

• Nepodporovaná aktiva: do evidence patří i Kubernetes verze po konci podpory, staré base image a runtime bez záplat. Přehled termínů je na stránce Kubernetes EOL.
• Skenování: image a závislosti v CI, registry scan pro už nasazené image, kontrola konfigurace cloudu (Defender for Cloud, AWS Security Hub nebo open-source alternativa).
• „Schválené“ aktualizace: slovo naznačuje řízený proces. Pull request s review a automatické testy jsou dobře doložitelný způsob schválení.
• Řízení změn (vyšší režim, § 11): chráněné větve, povinné review, záznam o tom, kdo co nasadil. Historie v Gitu a v pipeline je důkaz, pokud ji neumí přepsat ten, kdo změnu dělá.
• Pipeline jako privilegované aktivum: runner s právem nasazovat do produkce má fakticky administrátorská oprávnění. Platí pro něj nejmenší oprávnění, oddělení prostředí i logování. Konkrétní opatření shrnuje článek o bezpečnosti CI/CD.

Vyhláška č. 410/2025 Sb. v § 3 odst. 5 výslovně zmiňuje „postupy bezpečného vývoje“ dodavatele. Pokud software dodáváte regulovaným subjektům, čekejte, že se na váš vývojový proces začnou ptát ve smlouvách a dotaznících, i když sami regulovanou službu neposkytujete.

Dodavatelé, cloud provider a vedení firmy

Poskytovatel cloudu je dodavatel. V nižším režimu musí smlouvy s dodavateli v rozsahu podle § 12 zákona obsahovat relevantní požadavky z přílohy č. 2. Ve vyšším režimu se evidují významní dodavatelé a příloha č. 5 mezi náležitostmi smlouvy uvádí i podmínky při ukončení, tedy exit strategii s přechodným obdobím a migrací dat.

U hyperscalerů individuální smlouvu nevyjednáte. Reálně jde o to doložit, že jste standardní podmínky, auditní zprávy a certifikace poskytovatele posoudili proti požadavkům vyhlášky a zbylé riziko vědomě přijali. Jak přísně bude NÚKIB tento postup při kontrolách hodnotit, zatím z veřejně dostupných zdrojů neplyne.

Exit strategie má i technickou stránku: infrastruktura popsaná kódem, data exportovatelná ve standardních formátech a zálohy čitelné mimo původní platformu. Plán, který nikdo nezkusil, je pouze dokument.

Vedení

Požadavky na vrcholné vedení jsou samostatným bezpečnostním opatřením. V nižším režimu (§ 4) vedení určuje osobu pověřenou kybernetickou bezpečností, prokazatelně absolvuje školení, zajišťuje zdroje, seznamuje se se stavem opatření a stanoví prioritu obnovy primárních aktiv. Sankce podle NÚKIB dosahují až 250 milionů korun nebo 2 % čistého celosvětového ročního obratu a zákon v § 58 upravuje i zákaz výkonu funkce.

Co udělat v pondělí

Hranice přiměřenosti: firma v nižším režimu s jednou aplikací a jedním cloudovým účtem nepotřebuje SIEM ani tým pro detekci. Potřebuje zapnuté auditní logy, MFA, oddělené zálohy a sepsané odpovědnosti. Naopak splněná vyhláška neznamená bezpečné prostředí. Roční sken zranitelností vyhoví paragrafu, útočníka nezastaví.

Klíčové poznatky

• Lhůta běží od doručení rozhodnutí. Na opatření i na hlášení incidentů je nejvýše jeden rok (§ 13 odst. 4 a § 15 odst. 4 zákona č. 264/2025 Sb.).
• Vyhlášky jsou technologicky neutrální. Převod do cloudových nastavení je výklad, který je potřeba zdokumentovat.
• Vyšší režim má tvrdá čísla. Logy alespoň 18 měsíců, sken zranitelností alespoň ročně, penetrační test alespoň jednou za dva roky.
• Nižší režim nechává víc na vás. Retenci logů i četnost skenů si určujete sami, ale musíte je umět zdůvodnit.
• Záloha zahrnuje konfiguraci. Bez IaC, stavu a testu obnovy požadavek na kontinuitu nesplníte.
• Pipeline je privilegované aktivum. Platí pro ni řízení přístupu, logování i řízení změn stejně jako pro produkci.
• Soulad není bezpečnost. Vyhláška stanoví minimum, nikoli cílový stav.