Za posledních zhruba 3/4 roku jsem prováděl postupné nastavení standardního auditu na databázích zákazníka spolu s řešením obecné správy účtů. V následujících odstavcích se pokusím popsat, na jaká úskalí jsem za tu dobu narazil, proč jsem se rozhodl pro určitý způsob nastavení auditu a co za informace se podařilo získat.
Co stálo za auditem
V letním období 2017 bylo domluveno řešení požadavku od zákazníka na sledování aktivit na databázích zákaznických systémů a zajištění větší bezpečnosti hesel především k privilegovaným účtům.
Prvotní pokusy s nastavením auditu proběhly nejprve na našich interních databázích, přičemž pro nasimulování chování auditu na nějaké produkční databázi byla vybrána databáze interního systému pro zákaznickou administraci – (primárně z důvodu, že je nejvyužívanější a obsahuje jak účty zaměstnanců pro individuální přístupy, tak „hromadné“ aplikační účty, pod kterými přistupují aplikace). I přes určité komplikace po spuštění auditu poskytl provoz užitečný náhled na to, jak se audit chová a jak z něj zaznamenané informace číst.
Na základě získaných poznatků jsem vytvořil konkrétní konfiguraci pro první produkční databázi na zákazníka a jal jsem se nastavovat audit. Od té doby byly podobně nastaveny téměř všechny plánované databáze spolu s řešením správy auditu a omezením přístupu k určitým účtům.
Prvotní pokusy s nastavením auditu proběhly nejprve na našich interních databázích, přičemž pro nasimulování chování auditu na nějaké produkční databázi byla vybrána databáze interního systému pro zákaznickou administraci – (primárně z důvodu, že je nejvyužívanější a obsahuje jak účty zaměstnanců pro individuální přístupy, tak „hromadné“ aplikační účty, pod kterými přistupují aplikace). I přes určité komplikace po spuštění auditu poskytl provoz užitečný náhled na to, jak se audit chová a jak z něj zaznamenané informace číst.
Na základě získaných poznatků jsem vytvořil konkrétní konfiguraci pro první produkční databázi na zákazníka a jal jsem se nastavovat audit. Od té doby byly podobně nastaveny téměř všechny plánované databáze spolu s řešením správy auditu a omezením přístupu k určitým účtům.
Technické řešení auditu
Oracle nabízí poměrně dost možností, jak si audit přizpůsobit vlastním potřebám, problémem ale je, že ne všechny jsou dostupné ve starých verzích (řekněme starších než 11g2) a některé nelze použít na standardní edici produktu. Vzhledem k tomu, že pouze několik málo databází zákazníka obsahuje licenci Enterprise Edition a podstatná část z nich pak ještě běží na starých verzích, nešlo počítat s pokročilejšími možnostmi jako Fine-Grained Audit a podobně. Bylo tedy rozhodnuto využívat pouze základního standardního auditu.
Dále bylo třeba rozhodnout palčivou otázku – kam s ním? Teď není myšlen nějaký starý slamník, ale obsah auditu… Nabízejí se dvě možnosti – databázová tabulka nebo XML soubory na disku. Po určitém zvážení z hlediska pohodlnosti čtení záznamů auditu a rovněž faktu, že osoba, která bude k auditu přistupovat, bude tak jako tak používat privilegovaný účet na databázi i na OS databázového serveru, jsem se rozhodl pro ukládání do databáze. Je třeba poznamenat, že část auditu – akce účtů s rolí SYSDBA – jsou tak jako tak zapisována do souborů na specifikované místo.
Posledním problémem bylo rozhodnutí, co se bude auditovat, resp. zda auditovat z hlediska objektů na databázi (tedy příkaz provedený na specifikovaném objektu) nebo z hlediska účtů (tedy specifikovaný účet provedl příkaz). Vzhledem k tomu, že objekty mohou přibývat s každou další distribucí a i při počátečním nastavení nám může leccos uniknout, jsem vybral audit podle účtů.
Dále bylo třeba rozhodnout palčivou otázku – kam s ním? Teď není myšlen nějaký starý slamník, ale obsah auditu… Nabízejí se dvě možnosti – databázová tabulka nebo XML soubory na disku. Po určitém zvážení z hlediska pohodlnosti čtení záznamů auditu a rovněž faktu, že osoba, která bude k auditu přistupovat, bude tak jako tak používat privilegovaný účet na databázi i na OS databázového serveru, jsem se rozhodl pro ukládání do databáze. Je třeba poznamenat, že část auditu – akce účtů s rolí SYSDBA – jsou tak jako tak zapisována do souborů na specifikované místo.
Posledním problémem bylo rozhodnutí, co se bude auditovat, resp. zda auditovat z hlediska objektů na databázi (tedy příkaz provedený na specifikovaném objektu) nebo z hlediska účtů (tedy specifikovaný účet provedl příkaz). Vzhledem k tomu, že objekty mohou přibývat s každou další distribucí a i při počátečním nastavení nám může leccos uniknout, jsem vybral audit podle účtů.
Úskalí při/po nastavení auditu
Největším problémem při nastavení auditu se prokázala nejistota v tom, co bychom vlastně měli auditovat. Žádné specifické požadavky jsme v tomto ohledu zadané neměli, tudíž to bylo v zásadě na mém zvážení. Obvyklý postup spočíval v nastavení auditu všeho (kromě zjevných nesmyslů) a po nějaké době, den až týden podle databáze, zkontrolovat, které účty generují nejvíce záznamů. Tento postup se občas vymstil v situaci, kdy člověk jedno odpoledne takový audit nastavil a druhý den ráno na databázi objevil desítky milionů záznamů auditu, protože pod několika účty běžela každou minutu úloha se spoustou DML operací.
Postupným vyřazováním jsme dospěli do současného nastavení:
- DDL příkazy a příkazy GRANT se budou zaznamenávat vždy bez ohledu na účet – ty se dějí při distribucích a ručních zásazích administrátorů nebo pak při potenciálních sabotážích definice databáze – jde tedy o něco, co chceme vždy vědět.
- Příkazy DML a SELECT se v plném rozsahu auditují pouze na účtech pro individuální přihlašování – správcovské účty jako SYSTEM nebo účty zaměstnanců CCA.
- U ostatních účtů – aplikační účty a vlastníci schémat, pod kterými běží databázové joby – se audituje pouze jejich přihlašování, aby se zjistilo, zda se k databázi pokoušel pod těmito účty připojit někdo, kdo nemá příslušné povolení. Aktivita aplikací je navíc běžně logována aplikačním serverem, není potom tedy nutné logovat aktivitu na dalším místě.
Dalším problémem se do určité míry stala správa auditu a řešení jeho retence. Problém spočívá v tom, že pokud budeme v tabulce s auditem uchovávat příliš velké množství záznamů, audit se stane prakticky nepoužitelným – dotaz bude trvat třeba 30 minut. Na druhou stranu by měla být zachována možnost podívat se na záznamy třeba z minulého roku, čímž přichází na řadu nutnost záznamy z tabulky odlévat do jiných „dílčích“ tabulek, které lze pak po čase exportovat a z databáze smazat. Na základě toho se nabízí další otázka – jak tyto „dílčí“ tabulky spravovat? Brzy bylo celkem jasné, že alespoň minimální řízení ze strany administrátora bude zapotřebí, aby se záznamy s auditem nevymkly z rukou. Výsledek je takový, že retenci auditu a jeho odlévání do „dílčích“ tabulek řeší databázové procedury a případné další operace jsou v rukou správce databáze, který potřebuje provádět pravidelnou profylaxi nebo alespoň včas reagovat na varování z monitoringu. Nepochybuji, že tato část nastavení auditu se bude časem upravovat v závislosti na tom, jak se bude situace s jeho obsahem vyvíjet.
Co jsme z auditu získali
Momentální největší praktický přínos auditu se jeví v odhalení přihlášení na účty ze strany uživatelů, kteří by od něj neměli mít heslo, což vyústilo v postupné měnění hesel a zpřísnění politiky přístupů.
Dalším přínosem pak je určitá statistika provozu na databázi ze strany zaměstnanců CCA – lze si ověřit, ke kterým datům kdo přistoupil. Obecně množství informací, které lze z auditu zjistit je poměrně velké, ale momentálně není specifikována žádná metodika na to, které ukazatele by se měly sledovat. Audit je teď spíše využíván při profylaxích databáze k rychlému zjištění nějaké podezřelé aktivity.
Samozřejmě přítomnost auditu na databázích také znamená splnění určitých směrnic stanovených pro informační systémy zákazníka, ať už jeho obsah někdo sleduje nebo ne…
Přítomnost auditu má pak pochopitelně i své negativní stránky. Nutnost jeho údržby přidává určité množství práce při zakládání nebo změně účtů a při profylaxi. Dále je tu samozřejmě fakt, že audit si bere v databázi určité místo, ale to je v podstatě marginální faktor – jedná se od desítky MB až jednotky GB podle databáze. Poněkud větší vliv by audit mohl mít na výkon – čím četnější aktivita auditu, tím větší nároky na CPU a na diskové úložiště, nicméně toto lze minimalizovat vhodným nastavením auditu. Momentální nastavení se nezdá, že by audit výkon vytěžovanějších databází nějak viditelně omezoval.
Dalším přínosem pak je určitá statistika provozu na databázi ze strany zaměstnanců CCA – lze si ověřit, ke kterým datům kdo přistoupil. Obecně množství informací, které lze z auditu zjistit je poměrně velké, ale momentálně není specifikována žádná metodika na to, které ukazatele by se měly sledovat. Audit je teď spíše využíván při profylaxích databáze k rychlému zjištění nějaké podezřelé aktivity.
Samozřejmě přítomnost auditu na databázích také znamená splnění určitých směrnic stanovených pro informační systémy zákazníka, ať už jeho obsah někdo sleduje nebo ne…
Přítomnost auditu má pak pochopitelně i své negativní stránky. Nutnost jeho údržby přidává určité množství práce při zakládání nebo změně účtů a při profylaxi. Dále je tu samozřejmě fakt, že audit si bere v databázi určité místo, ale to je v podstatě marginální faktor – jedná se od desítky MB až jednotky GB podle databáze. Poněkud větší vliv by audit mohl mít na výkon – čím četnější aktivita auditu, tím větší nároky na CPU a na diskové úložiště, nicméně toto lze minimalizovat vhodným nastavením auditu. Momentální nastavení se nezdá, že by audit výkon vytěžovanějších databází nějak viditelně omezoval.
Závěr
V rámci možností se podařilo audit nastavit tak, aby mohl poskytovat potenciálně užitečné informace a zároveň příliš nezatěžoval databázi. Určitou otravností je pak údržba auditu, ale zrovna u ní počítám, že se bude časem vyvíjet podle obsahu samotného auditu a povyšování verze databází. Do budoucna je tu také potenciálně možnost využít určitých doplňků Oracle pro sjednocení správy auditu, ale zde silně záleží na zákazníkovi, jestli bude mít o takové řešení zájem (vzhledem k licencím a určité náročnosti návrhu a nastavení je zde otázka, zda se toto vyplatí). Stejně tak by šlo audit aktivně využívat v rámci monitoringu Nagiosem – např. alarm v případě, že někdo použije aplikační účet z jiného serveru než aplikačního. Možnosti tedy jsou, ale je tu nedořešená otázka, jestli o to bude zájem a jestli praktický přínos vyváží náklady.
Autor článku: Vladimír Láznička
Žádné komentáře:
Okomentovat