Database Security Assessment je proces zkoumání rizik hrozeb v databázích .
Chybou zabezpečení může být nepřesnost v konfiguraci systému, jako je absence zásady hesla databáze , softwarová chyba, jako je přetečení vyrovnávací paměti v proceduře nebo chyba v řízení přístupu , jako je přítomnost veřejných přístupových práv k tabulka obsahující důvěrné informace [1] . Po identifikaci zranitelnosti se vyhodnotí její priorita – nízká, střední, vysoká, kritická atd.
Nakonec je vytvořena zpráva shrnující výsledky studie. Typickým příkladem výstupu analýzy je celkový počet nalezených zranitelností seřazených podle důležitosti. Toto shrnutí je v podstatě snímek rizika, který může správce použít k určení priority kroků potřebných ke zlepšení zabezpečení databáze . Specifikuje, které databáze a které zranitelnosti by měly být zváženy jako první.
Základní část osvědčeného postupu analýzy zabezpečení databáze se skládá z následujících čtyř částí:
Mnoho analytických metod se snaží identifikovat zranitelnosti simulací akcí vetřelce. Například během procesu analýzy může systém využít vyrovnávací paměť, která je náchylná k přetečení, nebo použít metodu hrubé síly k získání nezbytných přístupových klíčů. Takové hackerské techniky často používají automatizované webové servery nebo nástroje pro analýzu sítě, často projekty s otevřeným zdrojovým kódem . Hlavním problémem tohoto přístupu je, že pokud je úspěšný, může způsobit výpadky nebo dokonce poškodit databázi. Například přetečení vyrovnávací paměti nevyhnutelně zhroutí databázi [2] .
Jakákoli šance na selhání je v produkčním prostředí nepřijatelná. Díky tomu jsou tyto metody použitelné pouze v laboratorních testovacích podmínkách. [3] Na druhou stranu jsou výsledky testů provedených v laboratoři špatně aplikovatelné na databáze používané ve výrobě. Nalezené, nebo co je důležitější, zranitelnosti mohou, ale nemusí existovat ve výrobě. Analýza zabezpečení databáze by proto měla být prováděna bez zneužití zranitelností.
Mnoho metod výzkumu zranitelnosti nevyužívá dostupné informace dostatečně hluboko k tomu, aby přesně určily stav nalezené zranitelnosti. Jako příklad zvažte přetečení vyrovnávací paměti procedury xp_sprintf v Microsoft SQL Server . Tento postup může zneužít útočník k získání oprávnění správce nebo ke zhroucení serveru. [4] Existují dva hrubé přístupy k vyšetřování takové zranitelnosti, které vedou k nesprávnému závěru.
Operativní přístupV tomto přístupu se analytický systém navzdory riziku pokusí odeslat data a přetečit vyrovnávací paměť procedury. Na základě výsledku zneužití bude vygenerováno odpočítávání, zda je server zranitelný či nikoli. [5] Přesnost této metody však závisí na tom, zda uživatel používaný analytickým nástrojem má práva k provedení procedury. Uživatel VEŘEJNÝ tato práva nemusí mít. Systém proto nebude moci zneužít zranitelnost a existující zranitelnost nebude započítána. Ale jeden z uživatelů nebo webová aplikace může mít práva ke spuštění procedury, v takovém případě má databáze závažnou zranitelnost, kterou analýza nezjistila.
Přístup založený na verziDruhý přístup je založen na kontrole verze softwaru za účelem posouzení přítomnosti zranitelnosti. V tomto případě mají zmíněnou chybu zabezpečení servery SQL s verzemi 6.5 SP4 a staršími. Proto bude každý server s verzí níže označen jako zranitelný. V tomto případě je však existence takového postupu na serveru ignorována. Postup by mohl být například odstraněn jako osvědčený postup [6] a pak takový server ve skutečnosti nemá uvedenou zranitelnost.
Jako součást osvědčených postupů by analýza zabezpečení databáze měla zahrnovat širokou škálu testů, které kontrolují každou z oblastí:
Open Vulnerability Databases sledují tisíce známých softwarových zranitelností, včetně databází a operačních systémů , díky kterým fungují. Proces analýzy zabezpečení databáze by měl vyhodnotit citlivost databáze a operačního systému, na kterém je založena, vůči všem známým zranitelnostem, které je ovlivňují.
Příklad bezpečnostního výzkumu a stanovení priorit zranitelnosti bez předstírání útokuExistuje záznam Bugtrack s ID 2041, který opravuje zranitelnost v Microsoft SQL Server 2000, ve které je rozšířená uložená procedura xp_printstatements náchylná k přetečení vyrovnávací paměti, což může způsobit zhroucení systému nebo umožnit spuštění externího kódu [7] . Zvažme kroky výzkumu zranitelnosti, aniž bychom ji zneužili.
Zabezpečení databáze je extrémně citlivé na problémy s nastavením systému a jako takové je většina z nich pokryta vzory osvědčených postupů. Položky konfigurace by měly být vyhodnoceny podle typu a zamýšleného použití. [9] Je zřejmé, že databáze, která podporuje webové aplikace, vyžaduje jinou konfiguraci než ta, která podporuje skupinu interních uživatelů.
Jednoduchým příkladem je frekvence změn hesla. Podle osvědčeného postupu by měl uživatel často měnit heslo, systém analýzy zabezpečení by měl správci umožnit konfigurovat politiku frekvence změny hesla a automaticky ji aplikovat na skutečné stáří hesel. Poté musí poskytovat statistiky o vypršených účtech a upřednostňovat hrozbu.
Správa privilegiíJe také nutné prošetřit organizaci vydávání databázových oprávnění. Obecně platí, že vlastník databáze se řídí zásadou nejmenšího oprávnění . Příkladem je řízení přístupu na základě rolí. Přímo udělená práva mohou vyvolat situaci, kdy uživatel po změně pozice v organizaci bude mít nadměrná oprávnění v systému. Přímé udělení práv také znamená nedokumentovaný autorizační proces, který znemožňuje dodržení předpisů, jako je Sarbanes-Oxley Act .
Externí objektyNěkteré objekty, které jsou vně databáze, lze použít (pokud nejsou správně nakonfigurovány) k útoku na databázi. [10] Tyto externí objekty jsou většinou objekty operačního systému, jako jsou soubory, služby, klíče registru a tak dále. Například DB2 obsahuje spustitelný soubor db2job, který lze standardně použít k tomu, aby místní uživatelé mohli spouštět kód s oprávněními správce. Vystavení této chybě zabezpečení lze určit kontrolou oprávnění operačního systému v souboru db2job. [jedenáct]
Dodržování předpisůPři hodnocení databáze by měla být věnována zvláštní pozornost bezpečnostním požadavkům, které se týkají souladu s předpisy. Například zákon Sarbanes-Oxley Act vyžaduje, aby všechny nové uživatelské účty byly sledovány v databázích, které uchovávají informace z finančního výkaznictví. Proto je nutné během procesu analýzy zkontrolovat datový slovník pro účty, jejichž datum vytvoření je v konfigurovatelném časovém období. Jakékoli nové účty mohou být uvedeny v závěrečných zprávách o skóre.
Navzdory výhodám úplné analýzy databáze je pro mnoho organizací obtížné ji organizovat.
Velký počet organizací vyžaduje písemné potvrzení o nutnosti alokovat další finanční prostředky pro IT oddělení. Nástroje pro analýzu zabezpečení databáze mohou poskytnout zprávu odůvodňující potřebu zlepšit bezpečnostní systémy a podle toho přidělit rozpočet. Ne vždy je však možné prokázat potřebu vylepšení samotného analyzačního systému. [12]
Správci systému mají nespočet dalších každodenních povinností a často nemají čas věnovat dostatečnou pozornost otázkám zabezpečení databází. I když takové problémy nakonec povedou k negativním důsledkům, správce je zanedbává ve prospěch naléhavějších úkolů.
Zaměstnanci zabezpečení dat ve společnosti mají jen zřídka požadovanou úroveň odborných znalostí v databázové infrastruktuře a nepokrývají celý rozsah testů analýzy zranitelnosti.