Naplózni csak pontosan szépen

Amikor a nyolcvanas évek elején Eric Allman a Sendmail projekt keretében megalkotta a syslog protokollt, és ezzel tulajdonképp feltalálta a naplózást, valószínűleg nem sejtette, hogy pár évtized múlva a központi naplózó szerverek már napi több gigabájt logüzenetet fogadnak majd a vállalati hálózatokból. (Akkoriban a merevlemezek mérete a néhány megabájtnál tartott.)

Kezdetben a naplózás diagnosztikai célokat szolgált, főleg a fejlesztés, később pedig már az üzemeltetés számára is. A központi naplózás bevezetésével sem változott a lényeg, csupán annyi történt, hogy immár a hálózat állapotát figyeljük elsősorban szintén diagnosztikai és biztonságtechnikai célokból. A ?megfigyelésünk? tehát eddig a pontig magára az infrastruktúrára korlátozódott.

Hol tartunk ma?
A világ azonban nem áll meg a naplózásban sem. A következő lépcső bizonyos alkalmazások és adatbázisműveletek bevonása lett a központi logolási rendszerbe. Ezt ma számos informatikai szabvány és reguláció írja elő elsősorban a visszakövethetőség érdekében. (pl.: SOX, Basel II, ...)
Bár első ránézésre mindez nem tűnik nagy lépésnek, mégis alapvető változásról van szó. Ugyanis ezzel már nem csak a gépek állapotáról gyűjtünk adatokat, hanem közvetlenül az alkalmazottak tevékenységéről is. Ha nagyon filozófusan szeretnénk fogalmazni, mostantól magának a vállalatnak figyeljük a tevékenységét, az állapotát.

Bár ezeket az információkat egyelőre nem nagyon dolgozzák fel, a teljes körű központi naplózás lehetővé teszi, hogy osztályok számára riportokat készítsünk, monitorozzunk és riasztásokat állítsunk be.

A jövő: fantasztikus-tudományos
Akár félelmetes is lehet belegondolni, de hamarosan egy naplóelemző rendszer nem csak arról tud majd tájékoztatni, hogy mekkora az adatbázisszerver terheltsége, vagy melyik merevlemezt kellene hamarosan cserélni benne, hanem arról is, hogy egyes alkalmazottak mennyit dolgoztak, esetleg, ha szokatlanul nagy összegű kimenő utalásra adott megbízást egy operátor, vagy, ha a pénzügyi műveletek veszélyesen csökkentik a készpénzállományt stb...

A naplózás - elemzéssel kiegészítve - tehát a jövő vállalatainak mesterséges intelligenciájává vállhat, amely kezdetben még ?csak? akkor szól, ha például olyan valaki jelentkezik be a banki rendszerbe, aki nem lépett be a bejárati beléptetőrendszeren keresztül az épületbe, később majd akkor is riaszthat, ha felmondás alatt álló kolléga teszi meg ugyanezt szokatlanul nagy összeget utalva, végül pedig a teljes cash flow kimutatást is elkészíti minden másodpercben.

Mindez természetesen nem a jelenleg elterjedt üzemeltetési és biztonságtechnikai osztályok által használt elemző eszközökkel valósul majd meg. Inkább azt képzeljük el, hogy az összegyűjtött naplóállományokat különböző célból, különböző elemző eszközökkel fogjuk majd vizsgálni és monitorozni.

Kihívások és válaszok
Hogy mindez milyen kívánalmakat támaszt a naplózó infrastruktúrákkal szemben? Mielőtt ezt a kérdést megválaszolnánk, tekintsük át a naplózás folyamatát, hogy lássuk, milyen főbb elemekből épül fel!
Maguk a naplóállományok a szervereken keletkeznek, amelyeket az ott futó naplózó kliensek szűrnek, majd továbbítanak a központi naplózó szerver felé. A logok valamilyen protokoll segítségével érnek el a központi szerverhez, amely színtén szűri őket, majd eltárolja vagy továbbítja egy elemző rendszer felé.

A folyamatban több olyan kritikus pont is létezik, amelyen megbukhat a rendszer alkalmassága, mármint, hogy kielégítse a ma és a jövő igényeit.

Az első ilyen gyenge pont abból adódik, hogy a naplózást alapvetően nem szigorú, jogilag értelmezhető adatok előállítására tervezték. Ebből kifolyólag a legtöbb rendszer semmit nem törődik pédául azzal, ha a hálózat túlterheltsége miatt a naplózó kliens nem képes az üzeneteket elküldeni. A hálózati kiesések idején keletkezett bejegyzések ilyenkor egyszerűen elvesznek. Ez a ma vállalatainál olyan szinten probléma, hogy - tipikus, ?a befőtt teszi el a nagymamát? felállásban - a naplózás megállása esetén magát a naplózott üzleti folyamatot is megállítják. Ugyanis, biztonsági és IT megfelelőségi (compliance) megfontolásokból az események rögzítése annyira kritikus, hogy inkább álljon le a termelés, mint sem úgy történhessenek dolgok, hogy arról semmi nyom nem marad. (Például egy bankautomata akkor is üzemen kívűl van, ha minden rendben vele, de leállt a naplózás.)

A problémát két úton kezelhetjük: egyrészt szigorúan sorszámozott, esetleg időpecsételt üzenetekkel, annak érdekében, hogy a központi oldalon azonnal észlelhessük az üzenetvesztést; másrészt a kliensoldali diskbuffer bevezetésével átmeneti tárolót hozhatunk létre, amelyből a hálózati kapcsolat helyreállását követően minden bejegyzés elküldhető.

A következő probléma a központba megérkezett üzenetek megbízhatóságával van kapcsolatban. Amennyiben bizonylatként vagy hiteles bizonyítékként szeretnénk használni, biztosítani kell, hogy a naplóadatok a kliens és a szerver között megbízható, titkosított csatornán haladjanak. Ehhez az kell, hogy a naplózó infrastruktúránk támogassa az SSL/TLS titkosítást, amely garantálja az üzenetek bizalmasságát és sérthetetlenségét.

A harmadik gyenge pont a teljesítmény. Rengeteg adatot kell valós időben fogadni és feldolgozni, és a teljesítményproblémák költségként vagy kockázatként jelentkeznek majd. A feldolgozás sebességén a naplózó szerverek sokat segíthetnek, amennyiben kifinomult szűrési szolgáltatásokat nyújtanak, vagy képesek feldarabolva adatbázisba írni az üzeneteket.

Az utolsó említésreméltó gyengeség az, amivel a lehető legkevesebbet foglalkoznak a különböző naplózó eszközök fejlesztői. Ez a tárolás ? archíválás, amivel kapcsolatban számtalan kérdés merül fel. A legalapvetőbb, hogy hová lehet eltárolni napi több tíz gigabyte logot, amin sokat segíthet egy beépített tömörítő funkció, aminek segítségével a háttértár költségünket körülbelül ötödére csökkenthetjük. Nem kis probléma a bizalmasság sem, ezért jó, ha az eszközünk titkosított formátumban tárolja a naplóállományokat.

Kiss Attila marketing menedzser

Balabit Kft. - www.balabit.hu