Kontrola sa nespýta na smernice
Predstavte si stretnutie s audítorom kybernetickej bezpečnosti. Nesadne si k vašim smerniciam. Položí tri otázky:
„Kedy presne bol tento incident zistený a kedy nahlásený?“
„Kto schválil túto zmenu na produkčnom systéme a aký mala dopad na dostupnosť služby?“
„Ukážte mi, že zamestnancovi, ktorý odišiel v marci, boli odobraté všetky prístupy.“
Odpovede na tieto otázky existujú – v e-mailoch dvoch správcov, v Exceli starom pol roka a v adresári, ktorý nikto nevie nájsť. Dohromady to nie je dôkaz — a preukázateľnosť je presne to, na čom stojí § 29 zákona o kybernetickej bezpečnosti.
Keď už excelová tabuľka nestačí…
Väčšina organizácií, firiem a samospráv má dokumentáciu spracovanú. To je síce nevyhnutná, ale statická časť celku. Zákon tiež ukladá množstvo každodenných činností — evidenciu a klasifikáciu aktív, riadenie zmien, riešenie a hlásenie incidentov, kontrolovanie prístupov a preukázateľnosť.
Pri používaní tabuliek narazí každá firma na 3 výrazné problémy:
Zostarne rýchlejšie, než ju stihnete aktualizovať. Zariadenia v sieti mimo evidencie sú prvá vec, ktorú audit hľadá.
Nemá auditnú stopu. Vie, aká je hodnota v poli — nie kto ju tam napísal a kedy.
Nestráži termíny. Lehota 24 hodín nepočká, kým si niekto v piatok večer uvedomí, že porucha je incident.
Zákon service desk nepredpisuje. Dôkazy áno.
Povedzme to na začiatku jasne: v žiadnom ustanovení zákona o kybernetickej bezpečnosti ani vo vykonávacích vyhláškach nenájdete povinnosť nasadiť service desk. Nikto vás k tomu nenúti a nikto vám za jeho absenciu nič nevytkne.
Zákon však ukladá povinnosti, ktoré sa bez nástroja plnia veľmi ťažko — a preukazujú ešte ťažšie. Service desk je miesto, kde tieto činnosti reálne prebiehajú, a tým sa z nich automaticky stáva záznam. Nerobíte dokumentáciu k práci. Dokumentácia vzniká tým, že pracujete.
V ďalších piatich častiach ideme cez oblasti v poradí, v akom sa pri kontrole preukazujú najčastejšie ako prvé.
1 Evidencia a klasifikácia aktív (§ 19)
Čo z toho máte pri audite. Aktuálny zoznam aktív s klasifikáciou, vlastníkmi a väzbami, ktorý je zároveň hotovým vstupom do analýzy rizík. Namiesto toho, aby ste pred každou analýzou rizík dva týždne zbierali dáta, analýza sa robí nad tým, čo v systéme žije.
Ako to funguje. Základom je konfiguračná databáza (CMDB) — jedna evidencia všetkého, čo používate na poskytovanie svojich služieb. Nie len IT: servery, sieťové prvky a počítače, ale aj služby, prevádzky, lokality, technologické zariadenia, vozidlá, a ak to potrebujete, aj procesy a dáta ako primárne aktíva. Štruktúra nie je zamknutá v preddefinovanej šablóne — skupiny, typy a vlastné polia si namodelujete podľa toho, ako je organizovaná vaša organizácia, nie podľa toho, ako si to predstavil výrobca softvéru.
Nad každou položkou sú bezpečnostné atribúty, ktoré zákon vyžaduje: dôvernosť, integrita, dostupnosť a kritickosť. Pre služby k tomu RPO (maximálna prípustná strata dát) a RTO (maximálny čas obnovy) — teda parametre kontinuity prevádzky, na ktoré sa audit pýta a ktoré väčšina organizácií nemá nikde zapísané.
Podstatná je jedna vlastnosť, ktorá sa ťažko vysvetľuje a ľahko sa ukazuje: väzby s dopadom. Keď prepojíte službu s virtuálnym serverom, ten s klastrom a klaster s fyzickými servermi a rackom, klasifikácia sa prenáša po väzbách. Nemusíte pri každom z dvadsiatich serverov znova rozhodovať, aká je jeho dôvernosť — vyplýva z toho, čo na ňom beží. A pri zmene klasifikácie služby sa prepočíta na všetko závislé.
Zber dát: Toto je najčastejšia a najoprávnenejšia obava. Ručné naklikanie stoviek zariadení nikto nemá kedy urobiť. Preto sa evidencia plní automaticky. Základom je CM LAN Scan — skenovanie siete z Customer Monitor, ktoré samo nájde zariadenia a sieťové prvky, doplní ich do evidencie a zároveň ukáže, čo v sieti je, ale v evidencii chýba, teda presne tie shadow aktíva. K tomu integrujeme aj ďalšie nástroje, ktoré už prevádzkujete — monitoring, antivírusovú či EDR konzolu, MDM alebo správu siete; v praxi riešenia ako Zabbix, ESET, Microsoft Intune alebo NetBox. Čokoľvek, čo dnes o vašich zariadeniach vie, môže byť zdrojom údajov pre evidenciu. Zariadenie prichádzajúce z viacerých zdrojov sa deduplikuje, aby bolo v evidencii raz.
Poznámka o dostupnosti: jednotlivé integrácie a skener siete sa uvoľňujú postupne v priebehu rokov 2026 a 2027. Automatický import z Customer Monitor / C-Monitor je dostupný dnes. Ktoré z vašich nástrojov sa dajú prepojiť a kedy, si preto stojí za to overiť pri návrhu nasadenia — nemá zmysel stavať projekt na funkcii, ktorá ešte nie je vydaná.
2 Incidenty a lehoty 24 / 72 / mesiac (§ 24)
Čo z toho máte pri audite. Kto, čo, kedy a v akom termíne urobil. Časové stopy pre všetky tri lehoty. Žiadna úloha bez vlastníka a termínu.
Ako to funguje. Kľúčová vlastnosť nie je formulár na hlásenie incidentu. Je to schopnosť eskalovať bežnú poruchu na bezpečnostný incident bez straty histórie. Väčšina bezpečnostných incidentov totiž začína ako bežný tiket, ktorý nie je dostatočne dobre vyhodnotený. Používateľ nahlási pomalé prihlasovanie, technik to dva dni rieši ako výkonnostný problém a až na tretí deň sa ukáže, že na serveri beží niečo, čo tam nemá byť.
Ak sa po zistení problému založí nový tiket, prvé dva dni komunikácie, príloh a zistení zostávajú v pôvodnom zázname a nikto ich nespojí. Prichádzate tým o to najcennejšie — o čas prvého zistenia, od ktorého sa počítajú zákonné lehoty. Ak sa namiesto toho pôvodný tiket eskaluje, bezpečnostný tím vidí celé riešenie od vzniku poruchy a lehoty sa počítajú od správneho momentu.
Pri závažnom incidente sa zo šablóny automaticky založia pracovné príkazy s pridelenými riešiteľmi a termínmi podľa ZoKB:
| LEHOTA | ÚLOHA | OBSAH |
|---|---|---|
| do 24 hodín | Včasné varovanie | Zaslanie včasného varovania dohľadovému orgánu od prvotného zistenia incidentu |
| do 72 hodín | Oznámenie o incidente | Prvotné zhodnotenie, dopad, informácia o možnom cezhraničnom vplyve |
| do 1 mesiaca | Finálna správa | Podrobná analýza incidentu a prijaté nápravné opatrenia, kompletná auditná stopa |
Systém kontroluje plnenie termínov na úrovni hlavného incidentu aj jednotlivých úloh a eskaluje, keď sa termín blíži alebo prekročí. Formuláre sú pripravené na obsah hlásenia (rozsah a dopad, dotknuté aktíva a služby, prijaté opatrenia, cezhraničný vplyv) s exportom pre podanie dohľadovému orgánu — samotné podanie robí povinná osoba.
Druhá vec, ktorá sa v praxi ukáže ako dôležitá: incidenty často nezačínajú telefonátom, ale detekciou z monitoringu alebo z bezpečnostného nástroja. Hlásenia z týchto systémov — monitoringu, EDR/XDR konzoly, SIEM či správy koncových zariadení, teda z nástrojov typu Zabbix, ESET a podobne — sa dajú zbierať na jedno miesto a menia sa na požiadavku s prideleným riešiteľom a termínom, bez prepisovania medzi konzolami. Pretože detekcia, ktorú nikto neprevzal, nie je opatrenie.
3 Riadenie zmien (§ 17)
Čo z toho máte pri audite. Úplná auditná stopa schválení a história zmien na úrovni každého aktíva — ktoré zmenové požiadavky sa ho dotkli, kto ich schválil a kto realizoval.
Ako to funguje. Nad zmenovou požiadavkou stojí manažér zmeny, ktorý posúdi opodstatnenosť a rizikovosť a vyhodnotí bezpečnostný dopad — vplyv na dôvernosť, integritu a dostupnosť dotknutých aktív. Dopad nemusí odhadovať z hlavy: cez graf väzieb v CMDB vidí, ktoré služby a aktíva zmena zasiahne, ešte pred schválením.
Schvaľovanie môže byť viazané na konkrétne aktívy, roly či procesy – do procesu automaticky vstupujú vlastník, správca a schvaľovateľ priradení k dotknutým položkám, viacúrovňovo podľa typu a priority zmeny. Oddelenie právomocí je pritom vynútené systémom: žiadateľ, schvaľovateľ a realizátor sú rôzne roly.
Bežné zmeny sa nezdržiavajú, rizikové majú dôslednejšie kroky a k dispozícii je aj ad-hoc schválenie v priebehu realizácie, keď je zmena urgentná. Schválená zmena sa rozpadne na pracovné príkazy s riešiteľmi a termínmi — sériovo, paralelne alebo kombinovane podľa závislostí — vrátane krokov overenia po zmene a definovaného plánu návratu pri neúspechu.
Stojí za zmienku jedna vec, ktorú si organizácie pri ZoKB uvedomia až neskoro: zmena nie je len technický zásah. Nástup zamestnanca, zmena pracovného zaradenia, zastupovanie, odchod zamestnanca alebo ukončenie vzťahu s dodávateľom sú tiež zmeny s bezpečnostným dopadom. Jedna požiadavka môže vygenerovať všetky nadväzujúce úlohy naprieč IT, HR a správou majetku — oboznámenie so smernicami, pridelenie alebo odobratie prístupov, výdaj a prevzatie majetku s protokolom, prenos vlastníctva aktív. S riešiteľmi, termínmi a záznamom.
4 Prístupy a ich revízia
Čo z toho máte pri audite. Kto, kedy, prečo a ako dlho dostal aký prístup. A záznamy o vykonaných revíziách — nie len tvrdenie, že sa robia.
Ako to funguje. Menšie organizácie často nemajú a nepotrebujú samostatný IAM nástroj. Kombináciou požiadaviek a CMDB pokryjete celý cyklus: žiadosť o prístup ako štandardná požiadavka so schválením vedúceho a vlastníka systému, záznam priradenia v CMDB s väzbou na pracovníka aj na konkrétny systém, s atribútmi typ prístupu, úroveň oprávnení, platnosť a dôvod. Pre privilegované účty a prístupy dodávateľov osobitný, časovo ohraničený režim.
Pravidelná revízia sa nastaví ako opakovaná požiadavka. Pri odchode zamestnanca dostanete zoznam prístupov na odobratie — nie preto, že si niekto pamätá, kam všade mal prístup, ale preto, že je to zapísané.
Ak IAM/IDM prevádzkujete, evidencia sa dá naň naviazať.
5 Auditná stopa a reporting (§ 29)
Toto nie je samostatná funkcia, ktorú by ste zapínali. Je to dôsledok predchádzajúcich štyroch: keď činnosti prebiehajú v systéme, časové stopy, zmeny stavov, komunikácia a rozhodnutia sa zaznamenávajú automaticky. Výstup pre audit nezostavujete spätne — máte ho priebežne.
K tomu prehľady a filtre pre jednotlivé roly (vedenie, manažér kybernetickej bezpečnosti, správcovia, vlastníci aktív), exporty CSV a XLSX pre externé spracovanie a archiváciu a možnosť postaviť nad dátami Power BI vizualizácie.
Otestujte sa: viete na tieto otázky odpovedať do piatich minút?
☐ Kto je vlastníkom vášho najdôležitejšieho systému a ako je klasifikovaný?
☐ Kedy bol váš posledný bezpečnostný incident zistený a kedy nahlásený?
☐ Kedy bola naposledy vykonaná revízia prístupových práv?
☐ Aký čas obnovy má vaša najkritickejšia služba a od čoho závisí?
☐ Kto schválil poslednú zmenu na produkčnom systéme a aký mala bezpečnostný dopad?
☐ Preukážete, že zamestnancovi, ktorý odišiel pred pol rokom, boli odobraté všetky prístupy?
Ak na väčšinu z nich neviete odpovedať s dokladom, viete, kde stojíte. A viete to bez nás.
Vyskúšajte CDESK 30 dní zadarmo
Založte si skúšobnú verziu na 30 dní a presvedčte sa sami, na vlastných dátach. Ak máte ďalšie otázky, radi vám ich zodpovieme.
