SIEM a log management v kontextu IAM

SIEM v praxi
11. 02. 2026
Audit nebo incident rychle ukáží, že nestačí „nastavit přístupy“ — je potřeba umět doložit, co se reálně dělo a kdy. V článku vysvětlujeme, proč má SIEM / log management v kontextu IAM smysl, kde to nejčastěji drhne a co si zkontrolovat, abyste měli přístupy „audit-ready“. Součástí je záznam webináře s rychlým rozcestníkem na nejdůležitější kapitoly a praktické demo.

Ve firmách se běžně řeší, kdo má k čemu přístup. Audit nebo incident ale rychle prověří, jestli je to i průkazné: umíte doložit, co se reálně dělo (kdo se přihlásil, odkud, co změnil a jaké privilegované akce proběhly)?

Právě o tom je záznam webináře se Smitio: SIEM / log management v kontextu řízení identit a přístupů (IAM).

 

Co ve webináři uvidíte:

  • 03:22 rozdíl mezi SIEM / SIM / SEM a log managementem
  • 06:10 co připravit před zavedením SIEMu a jaké logy sledovat
  • 12:06 proč jsme v Cleverbee zvolili Wazuh (a rozdíly vs Splunk / Microsoft Sentinel)
  • 39:10 praktická ukázka: simulace brute-force + detekce malwaru + práce s dashboardy

Záznam webináře: https://youtu.be/I3Nl3efEC2o?si=nI4p486whrXgS3o5
 

 

Pro koho je webinář

Hodí se hlavně pro firmy, kde se řeší auditní stopa a provozní dohled nad přístupy, typicky:

  • regulované organizace (BFSI, energetika, průmysl) a firmy pod tlakem auditu / interních kontrol
  • firmy v transformaci nebo po akvizici, kde se sjednocují identity, přístupy a přihlašování do systémů
  • organizace s interním IT, které potřebují zrychlit reakci na incidenty a mít jasnou dohledatelnost událostí

 

Proč má SIEM / log management u IAM smysl

V praxi nejde o to „sbírat logy“. Dává to smysl tehdy, když logy pomáhají:

  • zrychlit reakci na incident (rychle poskládat časovou osu událostí)
  • zvládnout audit bez ruční „detektivky“ (dohledat kdo / co / kdy)
  • vidět vzorce a anomálie (opakované pokusy, eskalace oprávnění, nové privilegované účty)

 

Kde to typicky drhne

Nejčastější problém nebývá absence logů, ale jejich použitelnost:

  • události jsou roztroušené v různých systémech a formátech
  • chybí jednotný čas a struktura (korelace pak nefunguje)
  • sbírá se „příliš mnoho“ bez priorit a bez scénářů využití (vzniká šum)
  • nejsou jasně definované základní detekční scénáře (alerty)

 

Mini-checklist: 10 bodů pro „audit-ready“ přístupy

Níže je rychlá kontrola, kterou si můžete projít během 10 minut. Pokud máte více odpovědí „ne / nevím“, je to signál, že logování a monitoring u přístupů stojí za cílené doladění.

A) Co logovat (aby to mělo hodnotu)

  1. Máme logované přihlášení (úspěch / neúspěch) včetně kontextu (zdroj, IP, zařízení)?
  2. Logujeme MFA události (vyžádáno / splněno / odmítnuto / bypass)?
  3. Logujeme změny rolí a oprávnění (kdo změnil, komu, kdy – ideálně i proč)?
  4. Logujeme privilegované akce (admin operace, zásahy do konfigurace, změny politik)?

B) Kvalita a dohledatelnost

  1. Jsou logy sjednocené do použitelného formátu a máme jednotný čas (NTP)?
  2. Máme definovanou retenci a víme, kde je „zdroj pravdy“ pro dohledání?
  3. Umíme do 15 minut dohledat „kdo se přihlásil / co změnil / jaké oprávnění použil“?

C) Detekce (aby to nebyl jen archiv)

  1. Máme alerty na opakované neúspěšné pokusy a podezřelé přihlašování?
  2. Máme alerty na skokové navýšení oprávnění nebo vznik nových privilegovaných účtů?
  3. Máme alespoň základní korelaci (IAM události + VPN/síť + AD/endpoint + kritické aplikace)?

 

Kam dál

Chcete to posunout z teorie do praxe? Tady jsou rychlé další kroky: