Co obsahuje bezpečnostní audit a jak probíhá?

Jak se určuje rozsah a cíle auditu

Prvním krokem je dohoda na tom, co přesně se audituje a podle kterých kritérií. Rozsah (scope) může pokrývat celou IT infrastrukturu, konkrétní informační systém (např. ERP v cloudu), procesy řízení přístupů nebo dodržování normy ISO 27001 a legislativy jako NIS2. Zákazník a auditor společně definují cíle: ověření compliance, hledání technických děr, hodnocení maturity procesů nebo přípravu na certifikaci. Jasný scope brání nedorozuměním o tom, zda se testuje i fyzická bezpečnost serverovny, domovské kanceláře zaměstnanců či dodavatelský řetězec. V praxi se často stává, že firma chce audit „všeho“, ale nemá přehled o všech aktivech · v takovém případě první fází se stává inventarizace.

Sběr informací a mapování prostředí

Auditoři shromažďují důkazy bez zásahu do chodu systémů. Žádají o politiky bezpečnosti, diagramy sítě, seznamy uživatelů a práv, logy z SIEM, zálohovací politiku a smlouvy s dodavateli. Následují rozhovory s klíčovými rolemi: CISO, správci Active Directory, vývojáři aplikací, majiteli dat. Cílem je pochopit realitu, ne jen dokumentaci. Typický český příklad: firma má v politice povinnou dvoufaktorovou autentizaci, ale v rozhovoru se zjistí, že vývojové servery ji nemají, protože „to komplikuje CI/CD pipeline“. Takové odchylky se zaznamenávají jako nálezy již v této fázi, ještě než spustí jakýkoli automatizovaný skener.

Technické testy a ověření kontrol

Tato fáze kombinuje automatizované a manuální metody. Vulnerability scanning mapuje známá zranitelnosti v operačních systémech, databázích a webových aplikacích. Konfigurační audity ověřují nastavení firewallů, switchů, cloudových tenantů (Microsoft 365, Azure, AWS) podle hardening benchmarků (např. CIS Benchmarks). Testy penetračního charakteru (pentest) mohou být součástí auditu, ale nejsou jeho synonymem: pentest simuluje útočníka a hledá cestu dovnitř, audit ověřuje, zda kontrolní mechanismy fungují podle očekávání. Příklad: auditor ověří, zda proces patch managementu skutečně nasadil kritické aktualizace do 14 dnů, jak vyžaduje interní směrnice, a zda existuje evidence schválení výjimek.

Zpráva, rizika a plán nápravy

Výstupem je strukturovaná zpráva pro management i technické týmy. Každý nález obsahuje popis, důkaz, hodnocení rizika (kritické, vysoké, střední, nízké) dle CVSS a kontextu firmy, a konkrétní doporučení k nápravě. Managementový shrnutí ukazuje trendu a priority: např. „absence segmentace sítě umožňuje laterální pohyb · riziko vysoké“. Technická příloha dává správcům kroky k opravě: nastavení GPO, aktualizace šablon ARM/CloudFormation, úpravaRBAC v Kubernetes. Důležité je rozlišit rychlé opravy (quick wins) od systémových změn vyžadujících rozpočet a čas. V auditech CIAD se ukazuje, že firmy často podceňují čas na testování oprav v předprodukčním prostředí.

Náprava, opětovné ověření a kontinuita

Po doručení zprávy následuje fáze remediace. Zákazník implementuje opatření, auditor provede retest (opětovné ověření) vybraných kritických nálezů. Retest není plnohodnotný nový audit, zaměřuje se pouze na potvrzení, že konkrétní díra je uzavřená a nezaváděla novou. Doporučuje se nastavit sledování metrik: počet otevřených kritických nálezů starších než 30 dnů, pokrytí assetů správou zranitelností, čas od detekce k opravě. Audit by neměl být jednorázová akce před certifikací, ale součást průběžného cyklu · např. roční interní audit, poloroční vulnerability assessment, ad-hoc audit po velké změně (migrace do cloudu, splýv firem).

Co to znamená: Bezpečnostní audit dává vedení fakta pro rozhodování: kde jsme náchylní, co splňujeme, co ne, a kolik to bude stát opravit. Není to technický test prolomení, ale hodnocení řídicích mechanismů a jejich efektivity v reálném provozu.