Před auditem se v mnoha IT odděleních odehrává stejný rituál. Několik lidí na pár týdnů odloží běžnou práci a skládá důkazy. Kdo schválil tuhle změnu? Proč měl tento uživatel administrátorská práva? Kdy se změnila konfigurace firewallu a kdo to udělal? Odpovědi existují, ale jsou rozeseté v e-mailech, chatech, exportech z různých nástrojů a v paměti lidí, z nichž někteří už ve firmě nepracují.
Tlak na doložitelnost přitom roste. Regulace v oblasti kybernetické bezpečnosti, například NIS2 a navazující národní legislativa, obecně kladou důraz na řízení rizik, odpovědnost vedení a schopnost prokázat, že bezpečnostní opatření skutečně fungují. Konkrétní povinnosti se liší podle typu organizace a vždy je dobré je posoudit s právníky nebo specialisty na compliance. Společný jmenovatel je ale jasný: nestačí věci dělat správně, je potřeba to umět doložit.
Proč skládání důkazů nefunguje
Problém obvykle není v tom, že by organizace neměla procesy. Problém je, že stopa po nich se netvoří automaticky.
- Schválení probíhají mimo systém. Souhlas s odstávkou přijde e-mailem, změna se pak provede jinde a vazba mezi nimi existuje jen v hlavě manažera změn.
- Historie se přepisuje. Nástroj ukazuje aktuální stav, ale ne to, jak vypadal předtím.
- Automatické akce nejsou vidět. Naplánované úlohy mění data, ale nikdo neví, kdy a co přesně udělaly.
- Odpovědnosti jsou na papíře. RACI matice existuje v dokumentu, ale nikdo nekontroluje, jestli odpovídá skutečným oprávněním.
Výsledkem je audit jako projekt, místo auditu jako běžného nahlédnutí do záznamů. A každý takový projekt stojí čas lidí, kteří by se jinak starali o provoz.
Jak k doložitelnosti přistupovat
Dobrá auditní připravenost je vedlejší produkt každodenní práce. Pokud každá akce vzniká v systému, který ji zaznamená, důkaz existuje v okamžiku, kdy se věc stane. Několik zásad:
- zaznamenávat nejen „kdo a kdy“, ale také „co přesně se změnilo“, tedy stav před a po,
- auditovat i to, co dělá stroj, nejen člověk,
- uchovávat záznamy dostatečně dlouho,
- mít odpovědnosti popsané tak, aby se daly porovnat se skutečnými oprávněními.
Jak to řeší Eywo Stratum
Eywo Stratum vede auditní stopu všech akcí s uchováním pět let. U změn konfigurace zaznamenává stav před a po, takže je vidět nejen to, že se něco změnilo, ale také co přesně. Auditují se i akce plánovače, tedy automatické úlohy, které běží bez zásahu člověka.
Položky CMDB mají vlastní historii verzí. U každé změny je vidět, kdo ji provedl, kdy, co se změnilo a odkud změna přišla, ať už z discovery API, z importu, z ruční úpravy nebo ze synchronizace s primární CMDB.
Schvalování probíhá v systému. Odstávky ve změnách, požadavky a další položky ke schválení se sbíhají do jedné fronty „Ke schválení“. Platí jedno pravidlo, kdo je vlastník, a zamítnutí je vždy se zdůvodněním. Záznam o tom, kdo s čím souhlasil, tak vzniká přímo u změny.
Odpovědnosti popisuje RACI matice a Eywo Stratum kontroluje, jestli odpovídá oprávněním. Pokud je někdo uveden jako odpovědný, ale nemá roli, která by mu umožnila danou věc schválit nebo provést, je to vidět. Role mají rozsah (vše, zákazník, tým, položka), takže je jasné nejen co kdo smí, ale také nad čím.
Závěr
Audit by neměl být projekt. Když auditní stopa vzniká automaticky, schválení jsou v systému a odpovědnosti jsou propojené s oprávněními, odpověď na otázku auditora je o pár kliknutí daleko. Tým může pracovat dál a vedení má jistotu, že odpovědnost lze doložit.
Auditní stopa, historie CMDB a RACI matice jsou součástí edice Standard.
Eywo Stratum Standard
Pro organizace, které chtějí spolehlivou CMDB a řízené ITSM procesy.