Servery, firewally, aplikace, cloudové platformy i koncová zařízení neustále zaznamenávají, co se v nich děje. Jinými slovy, každý IT systém vytváří logy. Bez centralizovaného logování jsou rozeseté napříč různými systémy a uložené v odlišných formátech. Pokud pak dojde k problému, často se procházejí ručně, bez kontextu, což komplikuje a prodlužuje investigaci.

V tomto článku se podíváme na to, proč je centrální správa logů (central log management, centralized log management) důležitá pro kybernetickou bezpečnost, IT provoz i compliance a jak ji nastavit, aby dávala co největší smysl.

TL;DR

  • Centralizovaný log management shromažďuje logy ze serverů, aplikací, síťových zařízení, cloudových platforem, bezpečnostních nástrojů a dalších IT systémů do jedné platformy, kde je možné je vyhledávat, analyzovat a dlouhodobě uchovávat.
  • Automatická normalizace a indexace logů v log management nástrojích odstraňuje roztříštěnost dat a mění surové záznamy událostí na strukturované informace, se kterými mohou IT týmy pracovat při investici událostí a troubleshootingu.
  • Výsledkem je lepší přehled o IT prostředí, rychlejší odhalování bezpečnostních hrozeb, efektivnější řešení provozních problémů a připravenost na audity a regulatorní kontroly.
  • Centrální správa logů zároveň vytváří základ pro pokročilejší bezpečnostní workflows a technologie typu SIEM nebo SOAR.

Co je centrální správa logů?

Centrální správa logů je proces, při kterém se záznamy o událostech v IT systémech automaticky sbírají a ukládají do jednoho nástroje, a to ve strukturované, prohledávatelné a tedy prakticky využitelné podobě pro monitoring a analýzu.

Takovýchto specializovaných nástrojů existuje celá řada, od open-source řešení jako jsou ELK a Graylog, po profesionální komerční nástroje typu Logmanager, Loggly a Datadog.

Protože se tématu logů věnujeme v samostatném článku o logování, zde jen zopakujeme, že log je jednoduše záznam o nějaké aktivitě v IT systému, například:

  • uživatel se úspěšně přihlásí do systému,
  • firewall zablokuje síťový provoz,
  • administrátor změní konfiguraci síťového zařízení
  • uživatel odstraní soubor,
  • proběhne databázový dotaz.

Samostatně jde pouze o izolované informace a pokud jsou záznamy rozptýlené mezi desítkami nebo stovkami systémů, jejich sledování je složité a manuální kontrola velmi náročná

raw syslog example
Obr. 1: Příklad surového, nezpracovaného logu (syslogu) před odesláním do systému pro správu logů.
log aggregation tool hero img dashboard
Obr. 2: Příklad dashboardu v systému pro správu logů (Logmanager), který zobrazuje souhrnné informace z agregovaných logů.

Systémy pro centrální správu logů všechny tyto záznamy spojují na jednom místě, a to v normalizované podobě. Jinými slovy, namísto toho, aby administrátor musel při řešení problému přistupovat na každé zařízení/server/aplikaci, kterého se událost týká, zvlášť, má je „po ruce“ v jednom rozhraní, kde je může filtrovat, prohledávat a analyzovat.

To je možné díky tomu, že po jejich přijetí log management systém obvykle:

  • převede data do jednotné struktury,
  • vytvoří indexy pro rychlé vyhledávání,
  • uloží logy podle nastavených retenčních pravidel.

Tato automatizace je zásadní, protože moderní IT prostředí vytvářejí obrovské množství logovacích dat. Podle oborového průzkumu dnes 22 % organizací generuje alespoň 1 TB logů denně. Při takovém objemu už je manuální práce s logy nereálná a navíc vzrůstá riziko, že budou varovné signály přehlédnuty.

Je také důležité rozlišovat mezi prostým ukládáním logů a jejich skutečnou správou. Centralizovaný systém pro správu logů obvykle zahrnuje:

  • standardizaci logů pro konzistentní vyhledávání,
  • řízení přístupu,
  • automatické uplatňování retenčních pravidel,
  • automatická upozornění.

Proč organizace potřebují centrální správu logů

central log management illustration 2

Centralizace logů má přímý dopad na bezpečnosti a stabilitu IT prostředí i schopnost organizace plnit regulatorní požadavky. Podívejme se na jednotlivé oblasti podrobněji.

Lepší přehled o bezpečnosti

Kybernetický útok jen zřídka vyvolá jen jediný jednoznačný alert. Mnohem častěji po sobě zanechávají sérii událostí napříč různými systémy. Například neúspěšné přihlášení, změna oprávnění, o něco později neobvyklé odchozí síťové spojení.

Pokud každou z těchto událostí analyzujeme na dotčeném systému izolovaně, je obtížné zrekonstruovat časovou osu útoku a dát si vše do souvislostí.

Centrální správa logů umožňuje bezpečnostním týmům dosledovat aktivitu napříč celým prostředím z jednoho místa. Vzorce chování jsou díky tomu lépe rozpoznatelné a podezřelé sekvence událostí lze rychle vyhledat a analyzovat.

Rychlejší řešení problémů

Ne každý problém je bezpečnostní incident. Řada problémů je čistě provozních. Aplikace padají. Služby přestanou odpovídat. Integrace selžou. Výkon systému klesne.

Pokud jsou logy uložené pouze lokálně na jednotlivých systémech, řešení podobného problému často znamená přeskakovat mezi servery, exportovat soubory a ručně porovnávat časové údaje. S centralizovanými logy lze naopak během několika minut vyhledávat napříč různými systémy. Týmy mohou například:

  • korelovat události podle času,
  • určit, kde problém začal,
  • zjistit, zda jde o izolovaný problém, nebo je jeho dopad širší.

To pomáhá zkrátit dobu výpadků a urychlit řešení incidentů.

Compliance a připravenost na audit

Řada regulatorních rámců, včetně nového zákona o kybernetické bezpečnosti, a standardů (typicky ISO/IEC 27001) vyžaduje, aby organizace na určených systémech uchovávaly auditní stopu uživatelských aktivit a systémových událostí (týká se bezpečnostních a relevantních provozních událostí).

Auditoři mohou požadovat například:

  • záznamy o incidentech s podklady z logů,
  • informace o politice logování s rozsahem a retencí,
  • seznam zdrojů logů namapovaný na evidenci aktiv,
  • historická data o událostech za stanovené období.

Audit ale může vyžadovat i konkrétní záznamy, ukázku vyhledání, doklad o pravidelné revizi logů a příklad řešené události. Pokud jsou logy neúplné nebo obtížně dohledatelné, může to být z pohledu compliance vážný problém.

Centralizované logování pomáhá těmto problémům předejít. 

Jak centrální správa logů funguje

Abychom pochopili přínos správy logů, je dobré podívat se na celý proces od začátku do konce.

1. Automatický sběr logů

Logy jsou ze serverů, síťových zařízení, bezpečnostních nástrojů, cloudových služeb, aplikací a dalších zdrojů automaticky odesílány do centrální platformy. K tomu mohou sloužit například log kolektory, agenti, syslog, API nebo nativní integrace jednotlivých systémů.

Po správném nastavení probíhá sběr zpravidla v reálném čase nebo s minimálním zpožděním.

2. Parsování a normalizace

Do centrální platformy přicházejí logy v celé řadě různých formátů. Jeden systém může uživatelské ID označovat jako user_id, jiný jako username. Firewall může strukturovat data úplně jinak než databáze.

Normalizace převádí tyto rozdílné formáty do jednotné struktury. Pole obsahující stejný typ informace se sjednotí, takže je možné data spolehlivě vyhledávat a porovnávat napříč systémy. Bez ní mohou být výsledky vyhledávání neúplné nebo nekonzistentní.

3. Centrální úložiště a indexace

Po zpracování a standardizaci se logy ukládají do centrálního úložiště. Indexace umožňuje platformě velmi rychle vyhledat relevantní záznamy. Místo toho, aby systém musel pokaždé procházet surové soubory řádek po řádku, může odpovídající události dohledat během několika sekund.

Retenční pravidla následně určují, jak dlouho budou jednotlivé logy uchovávány. Doba uchování se může lišit podle compliance požadavků nebo interních potřeb organizace.

4. Vyhledávání, alerty a reporting

Jakmile jsou logy centralizované a indexované, mohou s nimi týmy začít aktivně pracovat.

Administrátoři a jiní specialisté mohou například:

  • vyhledávat napříč všemi systémy,
  • filtrovat podle uživatele, IP adresy, typu události nebo časového období,
  • vytvářet dashboardy,
  • nastavovat alerty na definované podmínky,
  • generovat reporty pro audity nebo interní kontroly.

V této fázi se z logů přestávají stávat pasivní záznamy a mění se na aktivně využitelné provozní a bezpečnostní informace.

Jaké typy logů se nejčastěji zpracovávají?

Platformy pro centrální správu logů jsou užitečná jen tehdy, pokud sbírají správná data. Typy logů jsou přitom různé, ty nejběžnější shrnuje tabulka níže.

Typ loguCo zaznamenáváProč jsou důležité
Logy operačních systémůPřihlášení uživatelů, aktivitu služeb, systémové chyby, změny konfiguracePomáhají odhalovat neoprávněný přístup a systémové problémy
Aplikační logyAkce uživatelů, transakce, API požadavky, chyby aplikacíPomáhají při řešení problémů a sledování chování uživatelů i systémů
Logy firewallůPovolený a blokovaný provoz, zdrojové a cílové IP adresy, portyPomáhají odhalovat podezřelá spojení a možné pokusy o průnik
Logy síťových zařízeníAktivitu routerů a switchů, stav rozhraní, změny routováníPomáhají identifikovat problémy s konektivitou a neobvyklé chování sítě
Autentizační a identity logyÚspěšná i neúspěšná přihlášení, změny oprávnění, uzamčení účtůPomáhají odhalovat brute-force útoky, zneužití přihlašovacích údajů a oprávnění
Databázové logyDotazy, změny schématu, přístup k datůmPomáhají sledovat přístup k citlivým datům a vyšetřovat možné úniky
Logy cloudových služebAdministrativní akce, vytváření zdrojů, změny konfigurace, API aktivitaPoskytují přehled o cloudové infrastruktuře a aktivitě účtů
Logy bezpečnostních nástrojů (IDS, EDR, skenery zranitelností)Bezpečnostní alerty, detekce malwaru, porušení pravidel (security policies)Přidávají bezpečnostní kontext a pomáhají při vyšetřování hrozeb
Tab. 1: Přehled různých typů logů a příklady aktivit, které zaznamenávají.

Log management vs. SIEM: jaký je mezi nimi rozdíl?

Pokud chcete spravovat logy na jednom místě, nabízí se dva druhy nástrojů: log management a SIEM (Security Information and Event Management). Oba pracují s logy, oba pomáhají organizacím spravovat a analyzovat informace o provozu IT systémů a bezpečnostních událostech.

Hlavní rozdíl spočívá v jejich použití (use casech). Zatímco log management se soustředí na sběr dat, jejich správu, bezpečné uchování (retenci), monitoring a případně analýzu, SIEM se zaměřuje na detekci, alerting a vyšetřování bezpečnostních incidentů pomocí pokročilejších metod, jako je například korelace.

Oba typy nástrojů ale nelze oddělit prostým výčtem funkcí, protože ty se často překrývají. Moderní log management „umí” i některé SIEM funkce, například posílat alerty v případě nežádoucího chování, pokud je porušeno stanovené pravidlo nebo překročen threshold. Součástí SIEMů zase bývá log management komponenta, díky níž je možné logy sbírat a dlouhodobě uchovávat.

V praxi se obě řešení kombinují a vzájemně doplňují. Log management vytváří spolehlivý datový základ, na kterém pak SIEM dále staví. V bezpečnostní architektuře je tedy log management předřazen SIEMu, kde zajišťuje sběr, uchovávání a předzpracování logů. Do SIEMu jsou pak odesílána vybraná data relevantní pro bezpečnostní monitoring a detekci hrozeb. Tento přístup pomáhá optimalizovat objem zpracovávaných dat, a tím i snížit náklady na provoz SIEM řešení, jako jsou IBM QRadar, Splunk Enterprise Security nebo Microsoft Sentinel (zejména pokud je SIEM licencován podle objemu ingestovaných dat).

Jaké funkce hledat u nástroje pro centrální správu logů

Ne všechny platformy pro centralizovanou správu logů nabízejí stejné možnosti. Rozdíly se většinou začnou výrazněji projevovat ve chvíli, kdy prostředí roste nebo přibývají compliance požadavky. V rámci rozhodování je proto dobré věnovat pozornost následujícím oblastem.

Škálovatelný sběr a ukládání dat

Objem logů rychle roste s každou novou aplikací, cloudovou službou, síťovým zařízením nebo bezpečnostním nástrojem.

Log management nástroj by tedy měl zvládnout:

  • zpracovat velké množství logů bez výrazného poklesu výkonu,
  • škálovat úložiště bez složité rekonfigurace,
  • zvládat krátkodobé špičky například během bezpečnostních incidentů.

Pokud se systém zpomalí právě ve chvíli, kdy je aktivita nejvyšší, může se zpomalit i vyšetřování incidentu.

Rychlé a flexibilní vyhledávání

Jak dobře se uživatelům se systémem pracuje je klíčovým parametrem každého systému. Rychlost vyhledávání je v tomto velmi důležitá.

Uživatelé by měli mít možnost:

  • vyhledávat jedním dotazem napříč všemi připojenými systémy,
  • filtrovat podle uživatele, IP adresy, typu události, času, nebo tagů
  • rychle dohledat související události, například další aktivitu stejného uživatele nebo zařízení.

Pokud každý dotaz trvá několik minut místo několika sekund, celé vyšetřování se výrazně zpomalí.

Granulární řízení přístupu

Ne každý uživatel by měl mít přístup ke všem logům. Role-based access control (RBAC) umožňuje nastavit například to, aby:

  • bezpečnostní tým mohl vyšetřovat incidenty,
  • IT tým mohl řešit technické problémy,
  • auditoři měli přístup k potřebným záznamům,
  • citlivá data zůstala omezená pouze na oprávněné osoby.

Chrání se tím jak soukromí a citlivost dat, tak integrita provozu.

Retence a archivace

Požadavky na délku uchovávání logů se liší podle odvětví, legislativy i interních pravidel organizace.

Kvalitní řešení by mělo umožňovat:

  • nastavovat dobu uchování podle typu logu,
  • starší logy ekonomicky archivovat,
  • historické záznamy v případě potřeby dohledat.

Organizace nemusí uchovávat všechny logy donekonečna, ale zároveň by měla být připravená na audit nebo zpětné vyšetřování incidentu.

Alerty a integrace

Jak už jsme uvedli, moderní log management platformy běžně nabízejí také funkce alertingu. Umožňují tedy:

  • nastavit automatická upozornění na základě definovaných pravidel, prahových hodnot nebo výskytu konkrétních událostí. 
  • integraci s dalšími bezpečnostními nástroji,
  • API pro automatizaci.

Logy se díky tomu stávají součástí širších bezpečnostních a provozních procesů. Některé pokročilejší log management nástroje podporují také detekci anomálií a neobvyklých vzorců chování.

Nejčastější problémy spojené centrální správou logů

Centralizace logů výrazně zlepšuje přehled o IT prostředí, ale přináší také několik praktických výzev. Pokud s nimi organizace počítá už ve fázi proof of concept (PoC) a následné implementaci, může si později ušetřit řadu komplikací.

Růst objemu logů

Objem logů roste pokaždé, když přidáte nové systémy nebo zvýšíte úroveň detailu zaznamenávaných událostí. S růstem prostředí proto začínají být kapacita úložiště a výkon vyhledávání zásadními parametry celého řešení.

Pokud příjem dat roste rychleji než kapacita infrastruktury, systém se může začít zpomalovat. A pokud nejsou jasně nastavené retenční politiky, mohou zbytečně růst i náklady.

Organizace proto potřebují promyšlenou strategii, která vyvažuje okamžitý přístup k aktuálním datům s ekonomickým dlouhodobým ukládáním.

Neúplné pokrytí zdrojů logů

Ne všechny systémy musí nutně odesílat veškeré dostupné logy. To se většinou ani neděje z nákladových důvodů. Důležité je ale zajistit pokrytí relevantních zdrojů a typů událostí podle provozních a bezpečnostních potřeb organizace. V praxi jsou ale mezery ve viditelnosti běžné. Například není aktivováno auditní logování v cloudu, nová aplikace není zapojena do centrálního sběru logů nebo logy z identity management systémů zůstávají izolované v samostatné konzoli.

Část prostředí se pak během vyšetřování nebo auditu stává neviditelnou. Je proto třeba pravidelně kontrolovat, které systémy logy odesílají, zda je logování správně zapnuté a nakonfigurované a zda sběr dat skutečně funguje i po změnách infrastruktury.

Špatně nastavená retence

Uchovávat všechno navždy nedává smysl. Zbytečně rostou náklady na úložiště i provozní složitost. Na druhou stranu, pokud jsou logy uchovávány příliš krátce, může to při auditu nebo zpětném vyšetřování incidentů znamenat problém.

Většina regulací a standardů neuvádí konkrétní vyžadovanou dobu pro uchovávání záznamů a prokazatelnou auditní stopu. Vystačí si s požadavkem logy centralizovat a v případě potřeby prokázat, že se tak děje v souladu s nastavenými vnitřními politikami a retenčními pravidly. Existují ale i výjimky, jako například nový zákon o kybernetické bezpečnosti (18 měsíců pro organizace v režimu vyšších povinností), EU AI Act (6 měsíců pro vysoce rizikové AI systémy) nebo PCI-DSS (nejméně 12 měsíců). 

Pokud organizace nedokáže historické logy na požádání získat, může být obtížné prokázat, že její bezpečnostní a kontrolní mechanismy fungují správně a tedy naplnit compliance (soulad) s daným standardem nebo legislativou. Retenční politiky by proto měly být jasně definované, technicky vynucované a pravidelně revidované podle změn interních požadavků a změn legislativy.

Nekonzistentní parsování a mapování polí

Normalizace má přímý dopad na přesnost vyhledávání v lozích i na kvalitu následného vyšetřování.

Jestliže různé systémy označují stejná data různými názvy nebo používají odlišné formáty, může být vyhledávání napříč platformami nespolehlivé.

Typickým příkladem jsou nekonzistentní identifikátory uživatelů nebo různé formáty časových značek, které mohou komplikovat správnou korelaci událostí.

Pravidla parsování a mapování polí je proto vhodné pravidelně kontrolovat, zejména při přidávání nových zdrojů logů.

Jak zavést centralizovaný systém logování

central log management illustration 3

Zavedení centralizovaného logování vyžaduje systematický přístup. Následující kroky mohou posloužit jako praktický rámec.

1. Zmapujte všechny zdroje logů

Vytvořte kompletní přehled systémů, které generují logy. U každého systému ověřte, že je logování zapnuté a správně nakonfigurované.

Typicky mezi ně patří:

  • servery a operační systémy,
  • aplikace,
  • firewally a síťová zařízení,
  • cloudové platformy,
  • poskytovatelé identit,
  • bezpečnostní nástroje,
  • a prakticky všechny další důležité součásti IT prostředí.

2. Definujte požadavky na monitoring a compliance

Ujasněte si, co má platforma podporovat. Tato rozhodnutí ovlivní konfiguraci úložiště, parsování, retence i oprávnění.

Určete například:

  • které události mají spouštět alert,
  • která data je nutné uchovávat kvůli compliance,
  • jak dlouho mají být jednotlivé logy uložené,
  • kdo k nim má mít přístup.

3. Nastavte odesílání a příjem logů

Nasaďte kolektory, agenty nebo nastavte nativní integrace, které budou logy automaticky odesílat do centrální log management platformy.

Už v této fázi ověřte, že příjem dat skutečně funguje. Předejdete tak nepříjemnému zjištění během budoucího incidentu, že některé důležité záznamy vůbec nemáte.

Zkontrolujte, že:

  • data přicházejí pravidelně,
  • časové údaje jsou správné,
  • pole jsou správně parsovaná.

4. Nastavte normalizaci a retenční pravidla

Zajistěte, aby se logy převáděly do konzistentní struktury a používaly jednotná pole. Současně nastavte a technicky vynuťte retenční pravidla podle regulatorních i provozních požadavků. Tím zajistíte přesnější vyhledávání a spolehlivější dlouhodobé uchovávání dat.

5. Vytvořte vyhledávání, dashboardy a alerty

Připravte dotazy a dashboardy podle skutečných scénářů, které budou vaše týmy používat. Může jít například o sledování neúspěšných přihlášení, monitoring administrátorských aktivit, detekci neobvyklého síťového chování a podobně.

Pravidla pro alerty následně otestujte, abyste měli jistotu, že se při odpovídající situaci skutečně aktivují.

6. Pravidelně vše testujte a kontrolujte

Centralizované logávní není jednorázový projekt, je to průběžný proces. Provádějte proto simulovaná vyšetřování incidentů a ověřujte, zda máte dostatečné pokrytí logů a zda vyhledávání vrací očekávané výsledky.

S každou změnou infrastruktury aktualizujte zdroje logů, integrační nastavení i pravidla parsování.

Jak proměnit logy v prakticky využitelné informace

Automatický sběr logů, sjednocování jejich formátu a možnost rychle vyhledávat relevantní data dávají organizacím výrazně lepší přehled o celé infrastruktuře. Pomáhá zrychlit vyšetřování bezpečnostních incidentů, zkrátit dobu potřebnou k řešení provozních problémů a zjednodušit compliance reporting.

Centralizované logování je zároveň základem pro pokročilejší bezpečnostní funkce, jako jsou detekce hrozeb, korelace událostí nebo automatizovaná reakce na incidenty.

Na trhu dnes existuje řada nástrojů pro centralizované logování, od open-source řešení (ELK, Graylog) po komerční produkty (Logmanager, Loggly, Datadog). Nabídka zahrnuje jak nástroje určené pro menší IT týmy, tak komplexní řešení pro velké podniky, jak čistě cloudová, tak on-premise řešení.

Pokud se o dostupných možnostech chcete dozvědět více, přečtěte si náš článek na téma log management nástroje.