Az üzleti alkalmazások az információkat adatbázisokban tárolják: adatbázisokban találhatók a személyes adatok, az üzleti partnerek adatai, a pénzügyi és üzleti tranzakciók, azaz a vállalatok szinte teljes adatvagyona. Kormányzati és önkormányzati területen is komplex adatbázisok épülnek az állampolgárok, vállalatok és intézmények adataiból (gondoljunk csak a lakcím-nyilvántartásra, az egészségügyi adatbázisokra vagy a Nemzeti Adó és Vámhivatal adatbázisaira).
A mobilitás és az információ elérhetőségének igénye miatt egyre szélesebb körben kerülnek publikálásra az adatok, és a dinamikus adattartalmat szolgáltató webes alkalmazások hátterében is szinte kivétel nélkül adatbázisok állnak. Az elérhetőség igénye napjainkban nemcsak a publikus információkra korlátozódik, hanem kiterjed az üzleti adatokra is. A korszerű többrétegű technológiákra alapozva nagy megbízhatóságú komplex rendszerek építhetők, amelyek képesek hatalmas méretű mögöttes adatbázisok kiszolgálására. Azonban a webes technológia könnyű elérhetősége mellett azt a kockázatot is jelenti, hogy jóval szélesebb kör számára válik hozzáférhetővé, ezáltal támadhatóvá a mögöttes adatbázis is.
Az adatbázis előnye, hogy nagymennyiségű adatot tartalmaz struktúrált, jól kereshető formában, potenciális támadási célpont szempontjából viszont hátrányt jelent, hiszen egy adatbázis feltörése révén egy támadó hatalmas mennyiségű információhoz jut hozzá, mint azt a hivatkozott kutatás számai is jól jelzik. Elég „néhány” rendszert feltörni ahhoz, hogy rengeteg információ hozzáférhetővé váljon.
Az adatbázisok esetében is elmondható, hogy nemcsak a külső támadók ellen kell védekezni (bár az incidensben érintett rendszerek esetében ez a tipikus), hanem az adatbázisokat a belső támadóktól is védeni kell. Ezek közé tartoznak a belső jogosult és jogosulatlan felhasználók éppúgy, mint az adatbázisok privilegizált felhasználói/üzemeltetői. Egy adatbázis elérésének több módja van:
• Hálózati elérés: az adatbázist hálózaton keresztül érik el a felhasználók közvetlenül vagy az alkalmazásokon keresztül (pl. SAP). Az adatbázisok adminisztrálása is hálózati elérésen keresztül történik (a lokális konzolon keresztüli belépést is ide értve). A hálózati elérésnek számos sérülékeny pontja van, amelyet egy támadó kihasználhat. A leggyakoribb sikeres támadások napjainkban az alkalmazásokban (adatbázis-kezelőkben) rejlő sérülékenységek, programozási vagy konfigurációs hiányosságok miatt következnek be. Legismertebb módjai az SQL injection és buffer overflow-alapú támadások, a publicitást nyert esetek szinte kivétel nélkül ebbe a kategóriába tartoznak.
• Az adatbázis-szerverek adatbázis és konfigurációs állományai a futtató operációs rendszeren keresztül is elérhetők. Ezen állományokhoz közvetlenül hozzáférve számos lehetősége van a támadónak az adatok megszerzésére/módosítására. Például egy szoftverkomponens telepítésével az adatbázis-kezelő szabadon konfigurálható, a teljes forgalom lehallgatható, de az adatállományok is másolhatók.
• Kevésbé jellemző, de az adatbázis elérhető magán az adatbázison keresztül is: a jogosultsági rendszer rossz beállítása vagy egy módosított tárolt eljárás segítségével támadható az adatbázis.
Komplex megközelítés
A fentiekből is látható, hogy az adatbázisok védelme komplex megközelítést igényel, hiszen a támadás számos ponton lehetséges. Ennek a komplex szemléletnek egyfajta megközelítését publikálta a Gartner, amelynek során három fő területre bontotta a védelmet, az egyes területeken további alábontást is megadva.
• Adminisztratív védelem: Alapvető probléma, hogy a vállalatok sokszor nincsenek tisztában azzal, hol találhatók a kritikus adatok és mi azok védelmi igénye. Ezért az első lépés az adatvagyon felmérése és a védendő adatok meghatározása. Az adminisztratív védelem körébe sorolható a telepítés során megvalósítandó hardening és a megfelelő patch menedzsment kialakítása, ahogy a rendszeres sérülékenységvizsgálat elvégzése is.
• Megelőző védelem: Ide sorolható az adatbázisban tárolt érzékeny adatok titkosított tárolása, a logikai és fizikai szegmentáció, a megfelelő hozzáférés-védelem kialakítása, de a teszt és fejlesztői környezek számára szükséges adat-anonimizálás (data masking) is.
• Detektív védelem: A legkörültekintőbben megtervezett biztonsági rendszer is csak statikus védelmet biztosít, nem képes az aktív beavatkozásra, riasztásra, illetve a „normálistól” eltérő (pl. jogosult felhasználó által lekért túl sok adat) viselkedés detektálására. Ezt a célt szolgálja az adatbázis-hozzáférések monitorozása, az adatelérések és lekérdezések kontrollja, illetve a kapcsolódó biztonsági események gyűjtése, elemzése és a megfelelő incidenskezelő rendszer kialakítása.
Az előzőekben említett problémák kezelése érdekében maguk az adatbázis-kezelő szoftverek gyártói egyre újabb és újabb biztonsági megoldásokkal vértezik fel a megoldásaikat:
• Ma már szinte mindegyik adatbázis-kezelő támogat valamilyen rejtjelezett adattárolási funkciót.
• A felhasználó menedzsment és a jogosultságok finomhangolási lehetősége is egyre szélesebb körben biztosított.
• A naplózási funkciók egyre bővebb és részletesebb nyomon követhetőséget biztosítanak.
• Az operációs rendszerekhez hasonlóan az adatbázisokhoz is rendszeresen megjelennek a gyártói biztonsági javítások.
Korlátok
Az adatbázis-kezelők által megvalósított beépített funkciók azonban nem teljes körűek, illetve számos korláttal rendelkeznek. Kérdéses, hogy mennyire bízhatunk meg egy gyári beépített sérülékenységvizsgáló-megoldás objektivitásában, de hasonló problémákat rejt a titkosítást végző kulcsok adatbázis-kezelőn „belüli” tárolása. Klasszikus problémaként említhetjük a naplózást is: a túl részletes naplózás egy tranzakció-alapú rendszerben jelentős mértékben leterhelheti a rendszer erőforrásait, és a keletkező hatalmas mennyiségű naplóeseményből a relevánsak kiválogatása és elemzése szinte lehetetlen feladat. Ezzel szemben a keletkező naplók részletessége nem biztos, hogy elegendő, mert ha a felhasználói hozzáféréshez nem kerül bejegyzésre a végfelhasználó azonosítója (adatbázis-szinten lehet, hogy csak a technikai felhasználó neve jelenik meg), akkor utólag nehezen lekövethető, hogy ki végezte az adott tevékenységet.
További problémát jelent, hogy heterogén nagyvállalati környezetben az adatbázisonként megvalósított biztonság eltérő biztonsági szintet eredményez, eltérő menedzsmenteszközökkel. Ilyen környezetben azonban jogos elvárás, hogy olyan biztonsági megoldásokat alkalmazzunk, amelyek adatbázis-szinten központi policy alapján egyenlően szilárd biztonságot valósítanak meg, függetlenül az alkalmazott technológiától.
Számos megoldás érhető el a piacon, amelyek különböző területeken és szinten valósítják meg ezt az igényt. Az idén 15 esztendős Noreg Kft. az elérhető megoldások közül a hazai piacon is alkalmazott IBM Guardium és a McAfee Database Security termékcsaládjait javasolja. Mindkét termékcsalád több, részben egymásra épülő, részben független termékből/modulból áll.
A termékek segítségével blokkolhatóak és szűrhetőek az adatbázis-hozzáférések akár SQL parancs és tábla/rekord szinten is. Gyanús események és tevékenységek esetén adatbázis-szintű IPS-ként (Intrusion Prevention System) képesek blokkolni a forgalmat, illetve a definiált szabályhalmaz alapján valamennyi releváns naplóeseményt egy központi menedzsmentkomponensnek továbbítani. Mindkét termék esetében a monitoring/hozzáférés-kontrollt megvalósító modul az adott adatbázis-szerverre kerül telepítésre. Ez az adatbázis-szintű naplógyűjtő rendszer az események alapján riasztást generálhat, riportot készíthet és/vagy az eseményeket egy központi, már meglévő naplógyűjtő rendszernek tudja továbbítani.
A termékek közötti fő megközelítésbeli különbség a szerveren futó modul működési módjában van: amíg az IBM terméke a teljes hálózati forgalom kernel-szintű figyelése mellett alkalmazás-szintű (shared memory) figyelést is használ, addig a McAfee ez utóbbira fókuszál és ezen a területen nyújt többletlehetőségeket. A Guardium előnye és egyben hátránya is ebből a kernel-szinten beépülő (szigorú operációs rendszer és adatbázis-kezelő integráció) megközelítésből ered: rendkívül finom kontrollt biztosít (akár a lekérdezések visszaadott eredményébe is képes belenyúlni/azt módosítani), ugyanakkor sokkal nehezebb egy meglévő környezeti bevezetés (operációs rendszer és az adatbázis kezelő verzió együttes támogatása kell) vagy egy esetleges platformmigráció.
A megoldások „megtaníthatóak” az adott alkalmazás felhasználói táblájára, így a szűrés és riasztási funkciók nemcsak a „technikai accountot” látják, hanem a tevékenységet végző felhasználót is azonosítani tudják.
A megoldások a „vulnerability assessment” modul segítségével nemcsak védeni tudják az adatbázisokat, hanem képesek azok sérülékeny pontjainak a feltárására is, így a sérülékenységek megszüntethetők vagy egyéb kontrollok bevezetésével a kockázatok csökkenthetők. A termékek adatbázisgyártó-függetlenek, így egységes valós képet biztosítanak a különböző adatbázis-megoldásokról (Oracle, MS SQL, MySQL, Sybase).
