Farkas - DBVault

Elérkezett a félév vége, ez együtt elkészült a féléves beszámolom, és nagyjából befejeztem a rendszer tervet is. Most, hogy végre leadtam a házijaimat, volt időm végig olvasni a tervet, és itt közé tenni.

A rendszerterv itt el is olvasható.

Nagyjából megvan, hogy a modellben milyen táblák szerepelnek majd.

A modellbeli egységek táblái:

neptun táblái

• hallgatók
• tárgyak + eredmények

könyvtár táblái

• hallgatók
• dolgozók
• könyvek adati

gazdálkodási táblái

• dolgozók
• fizetés, járulékok
• gazdálkodási pénzek
• hallgatók
• hallgatói be-, kifizetések
• fenntartási költségek
• támogatások

karok táblái

• tanszékek
• gazdálkodási pénzek

tanszékek táblái

• tárgyak
• dolgozok
• gazdálkodási pénzek

Az egyes táblák, a tárolt adatokkal:

hallgatók tábla (közös)

• név
• kód
• pénzügyi kód
• kar
• szak

dolgozók tábla (közös)

• név
• neptun kód
• pénzügyi kód
• állás helye (tanszék..)
• beosztás

tárgyak tábla

• tárgy kód
• név
• előadó
• eredmény

fizetés, járulékok tábla

• pénzügyi kód
• bér
• járulék

hallgatói be-, kifizetések tábla

• pénzügyi kód
• kiírt tételek
• ösztöndíjak

fenntartási költségek tábla

• tanszék/kar azonosítója
• kiadás1
• kiadás2

támogatások tábla

• tanszék/kar azonosítója
• bevétel1
• bevétel2

gazdálkodási pénzek tábla

• tanszék/kar azonosítója
• összeg
• támogatások tábla
• fenntartási költségek tábla

A modelbne új tag ként még bekerül a kth, ami az olyan közösen elérhető, egyetemes adatokért lesz felelős mint a hallgatók és dolgozók adatai.

Az egész modell pusztán fikció, a valósáággal való bármilyen nemű egybeesés pusztán csak a véltlen műve. Ilyen adatbázis nincs a valóságban, és nem is lesz egyenlőre. :)

A felhasznált modell nagyvonalkban: BME

• karok
• Gazdaálkodási osztálya
  • egyetemi szintű
  • karonkénti
  • tanszéki
• Könyvtár
  • központi
  • karoké
• Neptun

Hogy ezek így miért is jönnek képbe?

Maga az egyetem felel mindenért, neki mindenbe van belelátása egy bizonyos szinten.

A Gazdálkodási osztály foglalkozik a pénzügyekkel, van egy része ami egész egyetemet érintő ügyekkel foglalkozik elosztja a pénzt, majd számon kéri a felhasználását. Az egyes tanszékek pénzügyi osztályai megkapják a pénzt és osztják szét a tanszékek között. Ők kaphatnak pénzt az egyetem mellet külső helyekről is, de ebbe már nem biztos, hogy egyetemi szinten van belelátás. A pénz végső felhasználása, elszámolása a tanszékek feladata, ők általában több külső cégtől is kapnak támogatást. A fölsőbb hierarchia szinten lévőknek, kell valamennyi belelátás az alatta lévőkbe, de csak korlátozott mértékig. Tipikusan a kivülről befolyó összegeket nem kell, h ellenőrizni tudja.

A Könyvtár esete is tipikusan ilyen hierarchikus, minden kari könyvtár felelős a sajátjáért, amit a központi könyvtár felügyel, ellenőriz. Például lehetnek közös beszerzések, de van, h karokként maguk teszik ezt.

A Neptun üzemeltetésnek kapcsolatban kell lenni a karokkal, tanszékekkel. Hiszen az oktatóknak, adminisztrátoroknak hozzá kell tudnia férni a rendszerhez, bevinni az órákat, az eredményeket, a fizetendő díjakat. De célszerű, ha csak a saját részükhöz férnek hozzá, és a többihez nem.

Még biztos rengeteg hibát és pontatlanságot tartalmaz.

Valahogy nehezen indult ez a félév, de mostmár tényleg.

A félév során tovább folytatom az DV témámat, most a feladat rendszertervezés.

A félév során azt fogom megtervezni, h egy cégnél, hogyan lehetne bevezetni az Oracle Database Vault-ot. Azt, h ehhez milyen egységeket, jogköröket, felhasználókat kell definiálni, hogy utána jól működjön a rendszer.

A feladat megvalósításához nem találok ki egy fiktív céget, hanem a műegyetemet veszem alapul, csak leegyszerűsítve. Egyrészt nem is ismerem a teljes szervezeti felépítését, másrészt ez nem is szükséges, annyit veszek figyelembe, ami mellett a feladatom értelmesen elvégezhető.

A rendszerterv keretein belül a megvalósítandó feladatok (nem teljes):

funkcionális terv
• célja
• milyen adatok
  • itt leginkább táblák
• milyen felhasználok
  • felhasználók definiálása
  • jogkörök szétosztása

tesztelési terv

• támadásokkal szemben ellenállóság
• használhatóság

üzemeltetési terv

• hogyan lehet használni
• ki mit tud végrehajtani
• mi kell egy új egység hozzáadásához

Hát csak sikerült vmi kis életet lehelni a rossz winyoba, és ennek köszönhetőnek maratoni másolás után, meg némi telepítéssel késöbb, végre újra a birtokomba kerültek az anyagok, amin eddig dolgoztam.

És ezzel már sikerült is befejeznem a beszámoló megírásást. Illetve elkészült a tanulmány is.

Mindig is tudtam, h szeretnek a gépek. Ma is sikerült pont alólam kihalnia a winyonak. Szal éppen minden anyagom oda, annyi maradt, ami itt van a blogon.
Mégiscsak megérte ide felírni a dolgokat.
Így viszont egy kicsit nehéz tovább haladni..

Az ODV főösszetevői:

- Realms Tartományok
- Rules Szabályok
- Factors Tényezők

Az ODV-vel létre lehet hozni tartományokat, mellyel az adatbázisukat kisebb darabokra oszthatjuk fel, és ezekhez külön-külön rendelhetünk szerepköröket. Minden egyes tartománynak meg lehet a maga adminisztrátorai, felhasználói köre. A cég egy-egy osztályának el lehet különíteni e módon az adatait. Felhasználókhoz rendelhetünk tartományi korlátokat.

A kialakítható jogokkal, megmondhatjuk, hogy pontosan mely művelteket hajthatja végre az adatbázison (azon a részén amihez hozzáfér). Akár utasításról utasításra is eldönthetjük, hogy legyen-e joga az adott művelethez.

A tényezők alapján alakíthatjuk ki a szabályokat, tényező lehet szinte bármi, például, hogy mikor, és/vagy honnan férhet hozzá valaki az adatokhoz, vagy hogy milyen authentikációs folyamatot kell használni.

Példa:
Ezen főösszetevőkkel kialakitható biztonsági korlátokra. A jogosultságok korlátozása, ki, mit, mikor, honnan.

Mint ahogy az ábra is szemlélteti, a az ODV-vel tartományokra (realms) oszthatjuk fel az adatbázisunkat, és az adott tartományhoz csak az ott érintett felhasználók férhetnek hozzá.
Ahogy látszik is a HR-es DBA nem férhet hozzá a pénzügyes (Fin) tartományhoz.
Illetve bár a HR DBA hozzáfér a HR területhez, de neki viszont nincs joga (rules) új felhasználót létrehozni.
Valamint az egész adatbázis adminisztrátor bár az összes táblát látja, a konkrét adatok eléréséhez mégsincs joga. Hiába próbálja megszerezni a HR-es adatokat.

A DBA távolról kísérli meg a rendszer módosítását, amit hálózati cím alapján szűr a rendszer, mivel csak bizonyos munkaállomásokról van hozzá joga.
HE DBA dátum és idő szerint nem engedélyezett műveletet akar végrehajtani.

Azt már levontam következtetésnek, hogy az adatbázis biztonság, támadások egy elég széles témakör. Rengeteg különböző típussal. Bár számos cikk, bejegyzés, utalás található az adatbázis támadásokról, és az ellene való védekezésről, mindegyik csak egy kis részét fedi le a témának.

Hasonló módon igazán mélyen a DBVaulttal foglalkozó művet sem-igen találtam, így legfőbb információforrásom az Oracle weblapján lévő leírások, bejegyzések, helpek voltak.

Az Oracle Database Vault (ODV) a belső támadások ellen kíván védelmet nyújtani. Ezen támadások lehetőségének csökkentésért, az alábbi fő funkciókkal rendelkezik:

- Korlátozza a DBA, valamint az erős jogosultsággal rendelkező felhasználok adatbázisban tárolt értékek hozzáférési jogait
- Megakadályozza, hogy a rendszergazda jogosulatlanul férjen hozzá adatokhoz, és módosítsa azokat a rendszerben
- Irányítási jogot ad a felett, hogy ki mikor, honnan, milyen alkalmazáson keresztül éri el az adatbázist, és annak mely adataihoz milyen módon férhet hozzá

Az ODV ezen szolgáltatásit tudja úgy hozzáadni a meglévő alkalmazási környezethez, hogy nem kell megváltoztatni a már meglévő kódot.

Manapság az egy igen fontos témakör az adatbázisok védelme belső támadásokkal szemben, megfelelni a jogszabályi követelményeknek, hogy az adminisztrátorok elöl is védjük az adatokat.

Az ODV megakadályozza, hogy a széleskörű jogokkal rendelkező felhasználók hozzáférhessenek az adatbázisban tárolt adatokhoz. Hiteles biztonsági tanulmányok kimutatták, hogy az információs rendszerek adatvesztésének közel 70%-át belső támadások okozzák, olyan személyek, akik az adatokhoz valamilyen szintű hozzáféréssel rendelkeznek.

Az ODV erős és könnyen használható biztonsági megoldást nyújt az adatbázison belül. Egyrészt azzal, hogy az adatokat elrejti az adminisztrátorok elöl, mást rész azzal, hogy szétválasztja a felelősségi köröket.

A belső fenyegetettség elleni védelem jegyében minden felhasználó csak azokat az adatokat látja, melyekre ténylegesen szüksége van a feladata ellátásához. Így például az adminisztrátoroknak elég csak a táblákat és a sorokat látniuk, magukat a tényleges adatokat már nem kell. Korlátozza a hozzáférést, a hozzáférés során támasztott többszörös követelmények növelik a biztonságot.

A feladatok szétválasztása, megvédi az adatbázist a jogosulatlan változtatásoktól. Például az ODV blokkolja a DBA által egy új felhasználó megalkotását, ha ahhoz nem társul tényleges adminisztrációs szerepkör. Ráadásul az összes parancsra meghatározható, hogy ki, mikor, honnan hajthassa végre azokat.

Valamint az is meghatározható, hogy ki, mikor, honnan érhesse el az alkalmazást, ezzel is szignifikánsabban szorosabbá tehető az alkalmazás biztonsága.

Könnyű támadási lehetőséget nyújtott korábbi Oracle verziókban, a benne lévő default jelszavak. Ez nyilván könnyű támadási lehetőséget adott, ha valaki nem változtatta meg ezeket a jelszavakat. Ezt a támadási rést az Oracle a 10g bevezetésével megszüntette, ettől a verziótól kezdve már nincsenek benne default jelszavak.

A belső támadás egy lehetséges módja, mikor egy felhasználó, aki jogosan fér hozzá adatokhoz vissza él ezen jogával. Mint például kilopja az adatot a cégtől, és másoknak is hozzáférhetővé teszi, esetleg pénzért eladja. Ezen támadás ellen nehéz védekezni, de amennyiben ezt egy átlagos felhasználó teszi, akkor nem tud sok adatot kijuttatni. Amennyiben ezt egy rendszergazda, vagy hasonló erős jogokkal rendelkező felhasználó teszi, akik nagy mennyiségű adathoz férnek hozzá, már nagyobb kárt tud okozni.

A belső támadások ellen védelmet nyújt, ha odafigyelünk pár dologra. Kevesebbet figyelünk arra, hogy mely emberek férjenek be a munkakörbe, többet arra, hogy az adat forrást megvédjük. Figyelni a DBA-k, sysadminok és egyéb legitim felhasználok támadásaira. Nem csak a sebezhetőségekre kell figyelni, hanem arra is, hogy láthassuk ki, hogyan fér hozzá az alkalmazásunkhoz. Felülvizsgálatot tartani, és felelősségre vonhatóvá tenni a felhasználókat és az adminisztrátorokat is. Illetve fontos, hogy a rosszindulatú cselekedeteket azonosítani tudjuk.

A feladatom egyik része az adatbázis kezelők elleni támadások megvizsgálása.
A támadásokról:
A mai korban az információ az egyik legértékesebb dolog, így az adatbázis kezelők gyakori támadásoknak vannak kitéve, hiszen nagy mennyiségű, adott esetben kényes, titkos információt tárolnak egy helyütt. Valamint roppant elterjedtek, hiszen a dinamikus tartalmat szolgáltató webes alkalmazások alapjául is adatbázisok szolgálnak.
A támadásokat két fő csoportra oszthatjuk a szerint, hogy honnan érkeznek. Lehetnek külső illetve belső támadások. A belső támadások olyan személyektől érkeznek, akik valamilyen szinten hozzáférnek a tárolt adatokhoz. Míg a külső támadások hátterében olyan emberek állnak, akik egyébként nem férhetnének hozzá a tárolt adatokhoz.
Külső fenyegetést okozhat, ha közvetlenül kirakjuk az adatbázist az Internetre. Ilyenkor könnyű a protokoll stacket túlcsordulással megfejteni Védhetjük az adatokat a támadások ellen, ha tűzfal mögé helyezzük, de ekkor még mindig nem lesznek biztonságba. Ekkor web alkalmazásokon keresztül nyújtunk adatokat. Ilyenkor még mindig érkezhetnek támadások az alkalmazási rétegen keresztül. Illetve belülről.
Külső támadások közé tartozik például, a kártékony kódok jogosulatlan távoli futtatása. Az SQL utasítások könnyű megbabrálhatóságának sok SQL fejlesztő nincs tisztában, így ezért ezeket az utasításokat biztonságosnak feltételezik. És nem vizsgálják meg a beérkező utasítás kódot elég alaposan. Ezért az olyan alkalmazások esetében, ahol a felhasználótól származó adatokból és statikus paraméterekből állítanak össze SQL lekérdezéseket, „közvetlen SQL utasítás befecskendezés”-sel a támadó a régi SQL utasításokat módosíthatja vagy újakat adhat hozzá. Így titkos információkhoz juthat, vagy akár rendszerszintű parancsokat is futtathat az adatbázis gazdagépén.
Az SQL befecskendezéshez hasonló az Oracle shell kód kódolás-dekódolás támadás is. A shell kód valójában egy gépi utasítás, amit a hekker küld a szervernek a a puffer elárasztásával, vagy egyszerűen megszerzi a szerver irányítását. A hekker ehhez a támadáshoz talál egy helytelenül megirt kód részletet, ami lehetővé teszi számára, hogy hamis utasításokat küldhessen és ezzel átvegye a szerver felett az irányítást. A támadások közel 68%-a PL/SQL feldolgozássorán az eljárásba beépített hosszú sztringek elküldését használja ki. Ezen funkción keresztül küldenek shell kódot az adatbázis szervernek. A puffer elárasztásal a támadó megkapja a stackre mutató pointert, ahova így már maga is képes utasításokat küldeni. Így már kiadhat olyan parancsot a hekker, hogy az ő kódját futtassa a gép. Ezen támadás ellen úgy próbálnak védekezni, hogy egyre újabb és változatosabb szűröket helyeznek a hekker és az adatbázis köz, hogy kiszűrjék a lehetséges gépi kódokat. Ez főleg ott lehetséges ahol a program megengedi a hekkernek, hogy bármilyen érvényes karaktert használjon, dekódolja ls végrehajtsa.
Az adatok titkosságát az ügyfél és a kiszolgáló között mozgó adatokra védi az SSL kapcsolati protokoll. De ha az adatbázisban tárolt adatokat nem védjük, titkosítással, akkor ha a támadó egyszer hozzáférést szerez az adatbázishoz, megkerülve a webszervert, akkor az ott tárolt adatok védtelenné válnak.
Egy másik támadási módszer lehet az, amikor is a támadok a belépési neveket és jelszavakat törik fel. Az adatbázis kezelők a jelszavakat hashalt értékükkel tárolják. Ezen függvényeket könnyű számolni, de nehéz visszafejteni. Azonban léteznek szótárak, ahol több millió hash érték pár érhető el, ebből a gyakori módszerekkel előállított jelszavakhoz a szótár alapján könnyen visszafejthető a karaktersorozat.

Nos egy windows újra install útán, újra neki láttam az Oracle 11g instalállásának. És így már tisztábban láttam, hogy mi van a gépen, mit kell beállítanom, mi az amit még fel kell elötte telepítenem. Ezután már sikerült is, sikeresen feltelepítenem.

Az Oracle 11g Windows alá való feltelepítése előtt el kellet végeznem néhány frissítést. Fel kellet rakni a Windows Installer 3.1-t, a NET Framework 3.5-t és egy új hálózati loopback csatoló kellett telepíteni.

Ez után már neki kezdhettem az Oracle 11g feltelepítésének Custom módban. Mivel a DBVault alap esetben nem települ fel, így nekem kellet kijelölni és hozzáadni a feltelpítendő részegységekhez. Az installáás során a kérdésekre hagytam az alapértelmezett beállításokat. A telepítés során nem különitettem el a DBVault Owner és a DBVault Account Manager funkciókat.

Nem lehet igaz, h már többedszerre probálom feltelepiteni az oracle 11g-t windows xp-re, de egyszerűen nem megy. Ráadásul most már uninstallálni sem lehet.. Viszont legalább állandóan eszi a memóriát. :) Vaj' mit csinálok rosszul??

Ezennel elindul a blogom... Ami remélhetőleg segíteni fog az önállólaborom sikeres teljesítésében. A témám az Oracle DBVault lenne. Aminek kereteiben az adatbáziskezelőket ért támadásokat fogom tanulmányozni, hogy ezen problémák milyen típusak lehetnek. Majd pedig megnézem, hogy ezek közül a Vault miket fed le, miket nem.