Architektura řešení Guardium

Řešení, se kterým se blíže seznámíme, pracuje se všemi běžně užívanými databázovými platformami, tedy Informix, DB2, Oracle, Microsoft SQL Server, Sybase, Teradata, MySQL. Implementace řešení nevyžaduje žádné změny v databázi a dokáže monitorovat veškerý provoz týkající se databázových transakcí. Plné monitorování pak nabízí buď úplný, nebo částečný sběr dat pro audit. Nad auditními daty lze pak vytvářet různé pohledy, které lze prezentovat textově formou tabulky nebo graficky. Řešení nevychází z auditních záznamů jednotlivých databázových serverů, audit na úrovni databází lze tedy vypnout a tím vrátit databázové platformě její původní výkonnost.
Základní jednotkou, která provádí monitorování, sběr a uchování dat pro audit je kolektor. Kolektor je malé zařízení připojené do síťové infrastruktury. Vlastní monitorování dat lze provádět na hardwarové úrovni síťové infrastruktury připojením na síťové zařízení TAP, případně na SPAN port switche, nebo na softwarové úrovni pomocí patentované technologie Guardium S-TAP. S-TAP je softwarová sonda instalovaná přímo na straně databázového serveru. Od monitorování prostřednictvím hardwarového TAP nebo zrcadlení portů (SPAN) se ustupuje a více se nyní spoléhá na sondu S-TAP. Důvodem je fakt, že kromě TCP/IP komunikace lze pomocí S-TAP sondy monitorovat šifrovanou komunikaci a také lokální komunikaci s databázovým serverem prostřednictvím IPC, sdílené paměti nebo pojmenovaných rour. Zrcadlení portů (SPAN) má dále tu nevýhodu, že při vysokorychlostních přenosech velkého objemu dat nelze zachytit všechna monitorovaná data.
Architektura s kolektory je plně škálovatelná. Řešení lze neomezeně rozšiřovat o další kolektory tak, aby byla zejména zajištěna plná výkonnost monitorovacího systému a také jeho vysoká dostupnost. V neposlední řadě lze více kolektory zajistit oddělení monitorovaných systémů tak, aby auditoři jednoho systému neviděli na auditní záznamy jiného systému. V případě složitější síťové infrastruktury lze pak všechny kolektory připojit k centrální jednotce pro agregaci dat (agregátor). Agregátor pak také centrálně spravuje veškeré bezpečnostní politiky a distribuuje je jednotlivým kolektorům.

Obr. 1: Základní architektura řešení Guardium

Softwarová sonda S-TAP dovoluje nejpodrobnější monitorování veškerého SQL provozu, aniž by byla jakkoliv snížena výkonnost databázového serveru. Vlastní auditní data, která jsou komprimovaně ukládána v kolektoru v relačním formátu, jsou dále interně zpracovávána, aby z nich bylo možné vytvářet co nejjednodušším způsobem reporty. Podle množství auditovaných dat může kolektor uchovat veškerá auditní data o provozu v rozmezí tří až šesti měsíců. Historická data z kolektoru lze pak transparentně odkládat na externí archivační zařízení, samozřejmě v šifrované podobě.

Omezené možnosti nativního auditu databází

Slabým místem tradičního auditu databází prostřednictvím nativních databázových prostředků je nemožnost nezávislého a spolehlivého auditu privilegovaných uživatelů. Privilegovaní uživatelé mají stále možnost mazat nebo modifikovat auditní záznamy pořízené nativním auditem, případně měnit nastavení takového auditu. Privilegovaní uživatelé mohou navíc mít plný přístup ke všem databázovým datům. To pak následně vede k potenciálnímu nebezpečí interních útoků na spravovaná data, aniž je mnohdy útočník odhalen.
Další nevýhodou tradičního auditu jsou pak zejména výkonnostní omezení, požadavky na další diskové kapacity, požadavky na změny v konfiguraci databázových systémů, různé způsoby implementace u různých typů databázových serverů, nedostatečné oddělení rolí a v neposlední řadě nutnost vytvářet uživatelské skripty nebo programy pro zpracování výsledných auditních dat. O jednoduché možnosti detekce neobvyklého chování z takto sebraných záznamů ani nemluvě.
Naopak audit prostřednictvím popisovaného řešení nemá takřka žádný vliv na výkonnost vlastního databázového serveru (diskové operace zápisu a čtení dat se provádí v kolektoru, tedy v externím zařízení), uživatelské rozhraní a pracovní prostředí je jednotné pro všechny typy databázových serverů, složitější infrastruktura poskytuje jednotnou správu, oddělení rolí je dáno architekturou řešení, schopnost odhalit neobvyklé chování je dáno již předdefinovanými pravidly, nebo lze definovat pravidla vlastní.

Základní funkce

Základem pro monitorování činnosti databázových serverů jsou auditní politiky, které se definují prostřednictvím pravidel. Pravidla se definují podle očekávaného chování systému, tedy jeho akce na určité události. Událost může být vyvolaná na základě spuštění určitého SQL příkazu či chyby SQL příkazu nebo na základě dat vrácených SQL příkazem.
Protože je monitorovaná veškerá SQL komunikace, lze v reálném čase upozornit na podezřelé operace. Například pokud konkrétní uživatel pracuje s citlivými daty, lze nastavit, kolik záznamů může za určitou dobu vybrat z pozice své činnosti. Pokud tento uživatel daný počet záznamů v určitém časovém rozmezí překročí, může jít již o neoprávněné získání celého souboru dat za účelem jejich zneužití. Pak může být takový pokus automaticky zablokován a uživatel „odstřižený“ od zdroje.
Podobně lze nastavit i počet neúspěšných přihlášení do systémů. Popisované řešení umožňuje nastavit počet neúspěšných připojení za určitý časový interval. Pokud dojde v tomto intervalu k uvedenému počtu neúspěšných přihlášení, je tento pokus detekován jako pokus neoprávněného průniku do systému. Na úrovni systému tedy nemusíme nastavovat blokování účtu po určitém počtu neúspěšných přihlášení a tím případně omezovat činnost oprávněných uživatelů, kteří zcela objektivně mohou mít problémy si heslo zapamatovat.
K základní funkcionalitě řešení patří v neposlední řadě také celkové ohodnocení systému z pohledu standardů, nastavení systému, nastavení databázových serverů a uživatelských privilegií k datům, úrovně instalace záplat nebo ohodnocení celkového chování uživatelů vůči databázovému systému (např. počet neúspěšných přihlášení, SQL chyby, počet přihlášení po pracovní době, počet přihlášení jednoho uživatele z různých IP adres a mnoho dalších). Právě provedené celkové vyhodnocení systému lze porovnat s minulým vyhodnocením a zjistit, zda došlo u parametrů, které nebyly minule splněny, ke zlepšení, nebo naopak zda u některých parametrů došlo ke zhoršení.
Pro všechny podporované databázové servery jsou všechna kritéria pro vyhodnocení zdraví systému již připravena, případně lze tato kritéria upravovat nebo doplňovat o další. Samozřejmě, že lze vytvořit také kritérium zcela nové. Tato celková vyhodnocení pak mohou sloužit jako podklad pro nezávislý audit bezpečnosti provozovaného systému.
V případě detekce incidentu má řešení vestavěný systém workflow, který dovolí tento incident systematicky řešit a jeho řešení sledovat v rámci organizační hierarchie podniku. S jednotlivými incidenty se pracuje podle toho, jak je nastavena akce pravidla v politice. Incident může být zaznamenán do interního relačního úložiště, může vygenerovat záznam do externího event management systému nebo zajistit zaslání e-mailu či SMS zprávy bezpečnostnímu správci podniku.

Závěr

Řešení Guardium je nezávislé na nativních databázových prostředcích pro audit, nesnižuje tedy výkonnost provozované databáze a je zcela nezávislé na privilegovaných uživatelích. Podporuje všechny hlavní databázové platformy. Dovoluje monitorovat veškerý databázový provoz včetně lokálních připojení k databázím, které nepoužívají TCP/IP protokol. Monitorování lze provádět v reálném čase, lze definovat i pravidla v závislosti na datech, která jsou vrácena SQL dotazem. Na této úrovni lze provádět obsahovou analýzu vracených dat. V případě, že data jsou definovaná jako citlivá, a nepřísluší tedy tomu, kdo o ně požádal, systém je zablokuje a žadateli nevydá.
Podstatou popisovaného řešení je skutečnost, že data jsou chráněna v místě, kde jsou spravována, tedy chráníme přímo zdroj dat. Tento ochranný štít nedovolí, aby se citlivá data dostala k jiným uživatelům než oprávněným nebo aby oprávnění uživatelé zneužili citlivá data, ke kterým mají přístup. I když lze celkové řešení ochrany nasazovat postupně v několika fázích a relativně rychle, může jeho realizaci zkomplikovat nedostatečný zájem o jeho nasazení. Hlavní prioritou bývá nasazení aplikací, které přímo souvisí s obchodní činností, bohužel otázkám bezpečnosti spravovaných dat není věnovaná odpovídající pozornost. Není výjimkou, že bezpečnost se stává prioritou až ve chvíli, kdy skutečně dojde k úniku dat, což je již ovšem pozdě.

Jan Musil
Autor článku působí jako certifikovaný IT specialista ve společnosti IBM.