Auditní logy v cloudu: kdo to byl?!
Proč poctivě uchovávat a zpracovávat auditní logy prostředí a jaké nástroje používat pro jejich analýzu?
Martin Gavanda
Ajťák 1: „Prosím tě, nevíš, proč to teď nefunguje? Včera to běželo!“
Ajťák 2: „Dohledal jsem z logu, že se tam přihlásil někdo pod admin účtem, ale nevím, co se změnilo.“
Ajťák 1: „Kdo jste tam něco měnil?“
Sbor: „Já ne.“
Obdobné situace se asi staly každému z nás. Osobně doufám, že v poslední době již jen málokdy a že všichni máme správně nastaven change management process. Poctivě uchovávat a zpracovávat auditní logy prostředí je důležité třeba také proto, že to vyžaduje vaše interní směrnice, nebo jste dokonce povinni auditní logy zpracovávat kvůli externím regulacím (například regulace ČNB, kritická infrastruktura státu nebo či rozdílné ISO standardy). Proč bychom tedy měly auditní logy ukládat a jaké nástroje použít? To si povíme v dnešním článku.
Základní rozdělení auditních logů
V principu můžeme auditní logy rozdělit do dvou základních skupin. Každá je přitom stejně důležitá a neměli bychom na jednu či druhou zapomínat.
Nezapomínejme, že auditní logy bychom měli ukládat a zpracovávat vždy, bez ohledu na použitou technologii či místo, odkud je aplikace provozována. Dále nesmíme opomenout téma retence dat. Vzhledem k faktu, že auditní logy typicky uchováváme z regulatorních důvodů, je nutné tato data uchovávat po dlouhou dobu (někdy i několik let).
- Auditní logy prostředí: typicky obsahují informace o tom, kdo a jak s prostředím jako takovým manipuloval, přistupoval k němu či jej měnil. Jedná se tedy typicky o logy, které reflektují administrativní úkony (kdo a jak měnil kterou komponentu či zdroj, ke kterým datům v databázi či ke kterým souborům přistoupil).
- Auditní logy aplikace: tyto logy mapují a popisují uživatelskou aktivitu v rámci aplikace. Může se jednat například o informace, k jaké aplikační funkcionalitě uživatel přistoupil, jaké byly uživatelské vstupy pro vygenerování nabídky nebo jaký dokument si kdo stáhnul.
V rámci našich služeb v oblasti Cloudu vám rádi pomůžeme s definicí a nastavením potřebných pravidel.
Auditní logy a cloud
Velkým benefitem cloudového prostředí je, že nástroje pro auditní logování jsou přímou součástí všech majoritních cloud platforem. V cloudu (na rozdíl od typického on-premise prostředí) jsou veškeré akce vykonávány skrze API – ať již přímým voláním těchto API nebo zprostředkovaně pomocí UI rozhraní či rozličných software development kits. Pokud tedy veškeré operace provádíme „nad jedním místem“ (ono API), je velice jednoduché veškeré tyto akce i logovat a dále zpracovávat.
Auditní logy prostředí
Jaké nástroje nám tedy jednotliví poskytovatelé cloudu nabízejí? V případě AWS se jedná o AWS CouldTrail, Azure zase nabízí Activity & Resource Logs.
Cílem těchto nástrojů je zachytit jakoukoliv aktivitu (operaci) prováděnou nad veškerými zdroji. Tyto aktivity mohou být vyvolány samotným uživatelem, nebo přímo cloudovým prostředím či jinou službou.
Zde je například zobrazena aktivita v jednom z našich interních Azure prostředí a jasně vidíme, že některé operace byly provedeny uživatelem (zde konkrétně mnou) a jiné provádí přímo cloudové prostředí (automatická záloha virtuálního serveru).
Ke každé operaci je k dispozici detailní auditní stopa, která uchovává veškeré informace o jednotlivých provedených operacích. Typicky tedy kdo (identita či role), kdy (kdy byla operace volána), kde (identifikace prostředí a regionu), odkud(IP adresa, identifikace koncového bodu) a co (jaká operace nad jakým konkrétním zdrojem) v rámci prostředí prováděl.
Zpracování a vizualizace auditních logů
První část máme za sebou – máme tedy detailní logy o všech operacích. Oba výše zmíněné nástroje (AWS CloudTrail i Azure Monitor) nabízejí základní možnosti filtrování a procházení těchto logů, ale ve vašem prostředí budete pravděpodobně chtít implementovat některé další (ať již nativní nebo 3rd party) nástroje pro vizualizaci těchto dat.
Pokud se rozhodnete využít čistě nástroje poskytovatele cloud prostředí, pravděpodobně sáhnete po nástrojích jako AWS CloudWatch, AWS QuickSight či Azure Log Analytics. Všechny mají za cíl zpracovat jakýkoliv objem zdrojových dat a na základě vašich preferencí a požadavcích je vizualizovat a nabídnout uživatelům.
Dalším krokem optimální práce s auditními logy pravděpodobně bude definice specifických notifikačních pravidel. Například by bylo zajímavé sledovat míru neúspěšných pokusů (access denied) nad jednotlivými účty, což může naznačovat, že některý z uživatelů se pokouší provádět něco, co by neměl.
Jiným příkladem může být například notifikace klíčových operací nad produkčními zdroji, nicméně představivosti se meze nekladou a jistě vymyslíte spoustu dalších zajímavých scénářů.
Externí nástroje pro zpracování auditních logů
V dnešní době existuje široké množství externích nástrojů, které můžeme využít pro analýzu auditních logů. Primární rozdíl oproti nativním cloud nástrojům je určitá vyšší míra „inteligence“, předpřipravených repotů a šablon a podpora různých prostředí, což je vhodné pro ty z vás, kteří provozují multi-cloud prostředí.
Za mě osobně bych doporučil podívat se například na následující nástroje:
Jednotlivé nástroje se mezi sebou liší, především z pohledu dalších nabízených bezpečnostních funkcí. Určitě neexistuje dokonalý nástroj, každý má své plusy i mínusy. Rozhodně doporučuji před finální implementací zvolený nástroj nasadit v rámci Proof of Concept implementace a důkladně otestovat veškeré požadované vlastnosti.
Auditní logy aplikací
Druhou oblastí, kterou byste měli pokrýt, jsou auditní logy v rámci samotné aplikace. Zde je situace o něco komplikovanější, protože každá aplikace je unikátní. V obecné rovině byste v rámci auditních logů měli být schopni identifikovat každou uživatelskou akci provedenou v samotné aplikaci, jako například:
- Vykonání business akce
- Přístup k aplikačním datům
- Volání klíčové operace
- Změna dat
Jak toho ale docílit? Zde bude rozhodnutí pravděpodobně na vývojovém týmu aplikace, jakou technologii nebo přístup využijí. Funkcionalita pro sběr aplikačních auditních logů může být implementována čistě „interně“, tedy v rámcivývoje samotné aplikace, případně můžete využít služby nabízené přímo poskytovateli cloudu.
Zde bych chtěl zmínit především nástroje AWS X-Ray a Azure AppInisghts. Tyto služby sice nejsou zaměřené na oblast aplikačního auditu (primární využití je pro aplikační monitoring), ale díky tomu, že při správné implementaci „detailně vidí“ do samotné aplikace, může být relativně jednoduché vytvořit i vlastní „auditní logiku“.
Jak tyto auditní záznamy poté zpracovávat a vyhodnocovat? Je to obdobné jako v případě auditních záznamů prostředí – můžete využít například Azure Log Analytics a data vizualizovat nebo sáhnout po standardních nástrojích pro log management, jako například Splunk či ELK Stack (Elasticsearch, Logstash a Kibana).
Co používáte vy?
Auditní logy nejsou žádná magie a v cloudu je až pozoruhodně jednoduché s nimi pracovat, protože je máte k dispozici automaticky. Nezapomínejte na ně, ukládejte a zpracovávejte je. Budou se vám hodit! A až se vás zase někdo příště zeptá: „Kdo to byl?!“, nebudete dlouze přemýšlet.
Jaké nástroje používáte vy? Vystačíte si pouze s nativními nástroji jednotlivých cloud poskytovatelů, nebo využíváte i jiné technologie a nástroje? Budu rád za jakékoliv komentáře a zejména osobní zkušenost.
A na co se můžete těšit příště? V následujícím článku se podíváme na detailní možnosti monitoringu cloudového prostředí a kolega Jakub Procházka vám do detailu představí některé z nástrojů, které jsem zmínil i v tomto dílu Encyklopedie cloudu. Všechny předchozích kapitoly seriálu najdete zde.
