Spolehlivé logování různých událostí je jednou ze základních součástí bezpečnostního mechanizmu každé pokročilejší aplikace. [13] a [20] uvádí jako hlavní důvody pro logování:
Z logovacích souborů lze někdy odhalit právě probíhající útok na aplikaci a včas mu zabránit. Pro detekci vniknutí slouží speciální systémy, které v reálném čase analyzují a hodnotí veškeré uživatelské události a v případě ohrožení provedou příslušná protiopatření či zalarmují administrátora. Ale i po úspěšném útoku jsou logy často jediným místem, ze kterého lze provedené vniknutí vůbec odhalit.
Ze záznamů v logu lze zpětně vysledovat způsob vniknutí, průběh útoku a rozsah způsobených škod. To může administrátorovi pomoci při zpětné obnově aplikačních dat do stavu před vniknutím i při dodatečném zabezpečení proti podobným útokům v budoucnu. Také lze často vystopovat útočníka a vyvodit vůči němu příslušné důsledky.
Logovací soubory nemusí být užitečné jen v případě cíleného útoku. Analýzou záznamů lze například odhalit skryté chyby programu či hardware nebo zjistit kontext a okolnosti, za kterých k některým chybám dochází. Dokonce ani nemusí jít přímo o chyby. Zjistíme-li například, že uživatelé v aplikaci dlouho bloudí, než naleznou požadovanou stránku či funkci, můžeme podle toho vhodně upravit navigaci.
Rozborem logů můžeme také získat cenné informace o svých uživatelích, o jejich zvyklostech, typické cestě procházení aplikací, využívaných službách apod. Na základě toho lze například upravit výstup pro každého uživatele zvlášť. Zjistíme-li třeba v internetovém obchodě, že si uživatel prohlížel sekci s digitálními fotoaparáty, při jeho příští návštěvě mu hned na hlavní stránce zobrazíme jejich nabídku a přímý odkaz do dané sekce.
Logování událostí je do značné míry závislé na konkrétní aplikaci či na možnostech a architektuře používaného frameworku. Jestliže je framework postaven na centralizovaném Front Controlleru, je toto místo ideální pro zakomponování centralizovaného logovacího systému, neboť přes něj procházejí naprosto všechny klientské dotazy. Obecné PHP třídy pro logování událostí nabízí například v rámci projektu PEAR třída Log.
Každý logovací záznam musí obsahovat základní informace, jako čas události, identifikaci uživatele, IP adresu a jméno počítače, ze které přistupuje, v některých případech i session tokenu, a podrobný popis události samotné. Uchovávají se všechny důležité akce, zejména potenciálně nebezpečné, ale i některé zcela legální. [20] doporučuje v aplikaci evidovat následující typy událostí:
Pro zajištění následné použitelnosti a věrohodnosti logových záznamů je třeba je zaznamenávat na spolehlivém a bezpečném místě. Reálná možnost jejich zničení či neautorizované modifikace je činí bezcennými pro jakékoliv další analýzy. Naopak, při jejich získání neoprávněnou osobou je systém vystaven vyššímu riziku odhalení slabého místa útočníkem.
[20] uvádí jako nejbezpečnější úložiště použití samostatného a fyzicky zabezpečeného jednoúčelového počítače. Komunikace mezi ním a aplikací by měla být oboustranně šifrovaná. Systém musí pravidelně ověřovat, zda je logovací mechanizmus stále funkční.
Logovací soubory mají typicky práva pouze na přidávání záznamů na konec, nikoliv na modifikaci či smazání stávajícího obsahu. Pravidelné ořezávání nejstarších záznamů provádí jen administrátor se zvláštním přístupem. Navíc je vhodné paralelně zapisovat logy na jednorázově zapisovatelná média, jako je CD–R. Záznamy by měly být pravidelně zálohovány v intervalech závisejících na velikosti média. Maximální délka periody se stanoví tak, aby u souborů, u nichž se provádí pravidelné ořezávání, byla na záloze vždy úplná podoba souboru před ořezáním.
[13] doporučuje, aby administrátor prohlížel logy pravidelně, a to alespoň jednou denně. Pro lepší přehled lze záznamy filtrovat, nicméně by se měly skrýt jen stoprocentně známé bezpečné zprávy a vše ostatní ve výpisu ponechat. Filtrační šablony je vhodné definovat co nejkonkrétněji, předejde se tak nechtěnému skrytí potenciálně nebezpečných záznamů.
Obsah logů je třeba v každém případě brát s rezervou. Případný útočník se totiž může dostat třeba až k logům a některé záznamy změnit či smazat. Stejně tak mohou při zápisu vzniknout různé softwarové či systémové chyby. Pokud tedy není něco zaznamenáno, neznamená to ještě, že se to nestalo. A naopak, i zaznamenané události se stát nemusely, někdo mohl třeba do logu zapisovat falešné údaje, aby administrátora svedl ze stopy skutečných potíží.
Obsah stránek vyjadřuje osobní názory, postoje a zkušenosti autora. Copyright © 2004–2010 Jan Tichý.