Logování (nejen) v Microsoft Azure: proč, co, kam a jak logovat?

Logování je sběr událostí (logů) z různých systémů a aplikací tak, aby bylo následně možné s nimi pracovat a vyhodnocovat je.  

Bez odpovědí na výše uvedené otázky bude podpora implementace systému logování slabá a motivace technických kolegů systém používat velice nízká. O další „krabičku“, o kterou se bude starat, ale reálně ji nevyužije, nikdo nestojí.  

Protože tlak na logování ze stran různých regulací a nařízení bude narůstat, tento článek má za cíl přiblížit technické aspekty takového systému. 

Proč je logování důležité?  

Hlavní důvody, proč logovat, jsou tři: 

1. Bezpečnost  
   Logy nám umožňují odhalit potenciální problémy a bezpečnostní mezery dříve, než dojde k jejich zneužití (a v případě zneužití nám ho odhalí hned zpočátku, než dojde k nevratným škodám). Typicky sem spadají logy z různých perimetrových systémů (FW, WAF), identitních systémů (Entra, Active Directory, …), bezpečnostních platforem (antivirus, EDR, CSPM, …) a auditní záznamy. 

2. Optimalizace a troubleshooting 
   Každý systém nebo aplikace má občas problémy s výkonem nebo jednoduše „něco nefunguje“. V takovém případě se naslepo těžko odhaluje, kde je problém, kdy se objevil a co ho způsobuje. A právě logy nám pomáhá tyto informace zjistit a problémy vyřešit. 

3. Regulatorní požadavky 
   V současnosti platí mnoho regulací, které po organizacích vyžadují logování klíčových či bezpečnostních systémů. Příkladem může být NIS2 (případně její lokální implementace – nový Zákon o kybernetické bezpečnosti), v bankovnictví DORA, pro všechny pak GDPR nebo přicházející AI Act. 

Odpověď na první otázku tedy známe: Logování potřebujeme. Nejen kvůli papírování, ale i z pohledu provozu a zabezpečení.  

Na další otázky si odpovíme dále. Zaměříme se při tom na logování v cloudovém prostředí Microsoftu, tedy na logování v Azure. 

Logování v prostředí Microsoft Azure 

Pro začátek je dobré si říci, čím se liší logování v cloudu oproti on-premise prostředí.  

V on-premise řešíme logování na úrovni syslogu (switche, firewally, servery, …) nebo pomocí agenta, který je nainstalovaný na daných serverech (ať už virtuálních nebo fyzických).  

Naproti tomu v cloudu tento scénář použít nejde. Syslog zde dostupný není a agenta lze instalovat pouze v případě, že máme k dispozici vrstvu operačního systému (IaaS). Logy z daných služeb tedy musíme tahat jinak a Microsoft pro nás má připravených několik možností. 

Azure Monitor 

Jedná se o nativní řešení Microsoftu, a zároveň unikátní místo, kde najdeme logy i nástroje pro jejich analýzu a práci s nimi. V podstatě je Azure Monitor takovým středobodem logovacího vesmíru v Azure. 

Azure Monitor (Zdroj: https://learn.microsoft.com/cs-cz/azure/azure-monitor/overview)

Které logy vlastně můžeme do Azure Monitoru posílat? 

• Aplikační logy
  Aplikační logy posíláme do Azure Monitor přímo z naší aplikace, a to buď pomocí integrace s některou Azure službou (jako app service), nebo pomocí SDK, které můžeme integrovat do vlastního kódu.  
  
  Výhodou takové app service (např. u aplikace napsané v .NET) je možnost sbírání telemetrie bez nutnosti nějaké úpravy. Tyto logy (případně metriky) nám poskytují informace o jednotlivých requestech (včetně návratových kódů), ze kterých jsme schopni odhalit výkonnostní problémy, uživatelskou zkušenost nebo chyby, které se v aplikaci vyskytují.  
  
  K tomu nám slouží komponenta Application Insights, která sbírá a analyzuje logy a nabízí škálu předdefinovaných dashboardů a workbooků (stejně jako tvorbu vlastních). 
  
• OS logy  
  OS logy pocházejí z vnitřku operačního systému. Můžeme jejich prostřednictvím sledovat Linux i Windows, případně další speciálně upravené systémy.  
  Zpravidla sem řadíme logy o přihlašování k danému systému, auditní záznamy a logy o aplikacích běžících na daném OS. K tomuto účelu slouží primárně Azure Monitor agent (jak pro Azure VM, tak pro servery mimo prostředí Azure). 
  
• Azure prostředky  
  Na Azure prostředky – což je největší rozdíl oproti on-premise světu – nelze instalovat agenta. Logy z nich můžeme sbírat nativně přímo v Azure přes nastavení diagnostics settings. V takovém případě používáme resource logy, které nám ukazují informace o daných prostředcích (přístupové logy pro WAF, logy pro PaaS databáze a mnoho dalšího). 
  
• Azure subskripce  
  Jednou z věcí, kterou určitě chceme sbírat, jsou logy z jednotlivých subskripcí, tzv. activity logy.  Jde v podstatě o auditní záznamy, které nás informují, kdo a kdy daný prostředek vytvořil, změnil nebo smazal. Přestože se sbírají již ve výchozím stavu, budeme určitě rádi, když je budeme mít k dispozici déle než 30 dní. 
  
• Tenant  
  Stejně jako sbíráme logy o přihlašování například z doménových řadičů, v cloudovém světě chceme sbírat logy o přihlašování a akcích provedených uživateli z tenantu. 

Některé součásti a vlastnosti řešení Azure Monitor jsem již nastínil. Kromě zmíněných agentů, Application Insights a nativního napojení na cloudové prostředky nástroj nabízí i další funkcionality a vlastnosti, které se s logováním neodmyslitelně pojí.

• Log Analytics workspace
  Slouží ke shromažďování a analýze logů ze všech možných zdrojů, nejen z Azure služeb. Můžete zkoumat logy pomocí dotazovacího jazyka KQL (Kusto Query Language), se kterým jde snadno procházet a analyzovat data.
  
  Cena služby závisí na objemu dat (logů) a na době, po kterou jsou logy uloženy (retence). V rámci Azure je možné si rezervovat denní přírůstek logů; minimální hranicí je však 100 GB/den, což je pro většinu (minimálně českých) firem těžko dosažitelné.
  
• Alerting a automatizace
  S platformou Azure Monitor můžeme také nastavit upozornění na základě určitých událostí nebo výskytu v logu. Pokud například dojde k překročení námi definované hranice neúspěšných pokusů o přihlášení, systém nás může okamžitě upozornit.  
  Pokud chceme jít ještě dál, můžeme využít platformu Logic Apps. Ta umožňuje řešit notifikace i integrace s různými poskytovateli. Díky tomu lze posunout alerting i celou automatizaci na zcela novou úroveň.
  
• Vizualizace
  Samotné logy jako takové jsou sice užitečné, ale často poměrně nepřehledné. Navíc exportovat je do Excelu, a poté si vytvářet vlastní filtry a dotazy není úplně nejlepší řešení.
  
  Proto máme k dispozici již zmíněný jazyk KQL, se kterým je možné vytvářet vlastní workbooky s vlastními vizualizacemi. Krom toho můžeme využít napojení na Power BI, se kterým můžeme poskytnout vizualizace v čitelnější a srozumitelnější formě například businessu.

Když už loguji, co dál?

V předchozích částech jsme si objasnili, co můžeme logovat, kam, jakým způsobem a jak to budeme platit. Stále nám však chybí asi to nejdůležitější: co s logy dál? Máme je uložené, ale umíme z logů čerpat nějakou přidanou hodnotu?

Zatím k logům přistupujeme jako k samostatným dílkům skládačky. Pomáhají nám řešit problémy, které už nastaly, ale neposkytují celkový obraz o prostředí a zabezpečení. Musíme je procházet ručně, definovat upozornění a skládat informace dohromady, což je velmi časově náročné.

Proto půjdeme ještě trochu dál, a to k systému SIEM (Security Information and Event Management), který z jednotlivých dílků skládá celkový obraz, aniž bychom museli definovat každé pravidlo nebo zkoumat a procházet logy.

SIEM (Zdroj: https://www.hbs.net/blog/benefits-of-log-consolidation-in-a-siem-environment) 

SIEM: od střípků k celkovému obrazu 

Systém SIEM pracuje s logy z různých systémů jako s celkem. Zpracovává je s využitím různých analytických pravidel, machine learningu, AI a dalších pokročilých funkcionalit. Následně vyhodnocuje důležité události a informuje nás o nich, případně rovnou vykonává konkrétní akci.

Představme si, že máme stovky různých logů z různých systémů – firewallů, serverů, aplikací. Může se v nich přitom skrývat několik souvisejících událostí, které nejsou na první pohled podezřelé, a jejichž „manuální“ odhalení by bylo velice náročné.

SIEM dokáže tyto logy analyzovat, odhalit mezi nimi anomálie, sestavit je do souvislostí a na základě předem definovaných bezpečnostních pravidel vyhodnotit, které události představují pro vaše prostředí relevantní hrozbu.

V takovém případě může rovnou spustit akce, které vaše prostředí ochrání – například zablokuje podezřelý přístup nebo izoluje napadený systém.

V případě cloudového světa Microsoft vyniká platforma Sentinel, který jde dále za hranice Azure Monitor a nabízí i mnoho dalších funkcí. Sentinel vyniká především snadnou nativní integrací nejen s cloudovým světem, která mu dává oproti jiným konkurentům výhodu a výrazně zjednodušuje napojení cloudových prostředků.

Co když…

Nechcete používat cloudovou platformu pro logování? Důvodů může být více: cena, funkcionality, závislost na daném vendorovi nebo už zkrátka máte svůj oblíbený produkt, který chcete dále používat.

Ačkoliv je Azure Monitor přirozenou a do jisté míry i nejsnazší cestou pro logování cloudových prostředků, není jedinou. Řada větších vendorů už počítá s cloudovým světem a umí tedy pracovat i s logy z podobných služeb. Navíc často přichází i s částí SIEMu, a může být tedy zajímavou alternativou i k řešení Sentinel.

Jedním z takových produktů je celosvětově populární Elastic stack (ELK), který kombinuje hned několik rolí dohromady a nabízí zajímavé alternativy i z pohledu licencování a provozu.