Vasvári - Database Vault, Advanced Security

Üzemeltetési terv

Az alábbiakban az egyes felhasználók által végezhető/elvégzendő feladatok kerülnek felsorolásra. Mivel könnyen behatárolható feladatokat végeznek a felhasználók, kevés funkcióra van szükség a kliens-programban, ezért fontos szempontot jelent a felhasználói felület minél barátságosabb, letisztult megjelenése, így a felhasználók betanítása nem igényel majd sok időt.

 

Fő-fő adminisztrátor

Új szerv felvétele, jogosultságok kiosztása, szervek menedzselése (leíró adatbázis frissítése), törlése, valamint az adatbázis működésének felügyelete. Mindezeket a szerver-oldalon Oracle 11g alatt teheti meg.

Biztonsági mentés-szakértő

Rendszeres biztonsági mentések, esetleges visszaállítás elvégzése szerver-oldalon, Oracle 11g segítségével.

User-DBA

Kliens-program indítása után belépés saját felhasználónév+jelszó segítségével, majd az adott szerven belüli felhasználók regisztrálása, módosítása, törlése. Végül kilépés a kliens-programból.

Felhasználók

Kliens program indítása után belépés saját felhasználónév+jelszó segítségével, majd a jogosultság alapján elérhető adatok létrehozása, lekérdezése, módosítása, törlése. Végén kilépés a kliens-programból.

 

Kliens program esetleges hibaüzenetei:

·           a kliens nem tud a szerverhez kapcsolódni

·           hibás bejelentkezés (név vagy jelszó hibás begépelése, egyéb hitelesítési eszközök nem megfelelő működése)

·           tiltott művelet (jogosultság alapján nem megengedett művelet)

Az üzenethez tartozó OK gombbal a hibaüzenet eltűnik, a hibát okozó művelet megismételhető (javítható).

Tesztelési terv

 

Mivel a feladat alapvető motivációja a biztonság, ezért a legfőbb tesztelések az egyes biztonsági megoldások tesztelését veszik célba. Emellett természetesen  más működésbeli vizsgálatra is szükség van.

·                felhasználói felület működőképessége, megfelelő adatok, menü elérhetősége

·                kapcsolat létrehozás kliens-szerver között

·              hozzáférés hibamentessége (a felhasználó a megfelelő adatokat látja, a DBA megfelelő jogokkal rendelkezik)

·                nem módosítható adatok változatlansága

·                anonimizálás vizsgálata

·                lekérdezések, módosítások hibátlan működése (hibás adatok bevitele)

·                adattovábbítás során adathitelesség ellenőrzése nem megbízható csatornán

·                rendszer bővíthetősége

·                terhelésteszt (stressz teszt)

Komponensek – legkisebb, még komplex feladattal rendelkező egységek

Kliens-szerver alapú rendszer lévén az alábbi felosztás e szerint történik.

 

Szerver-oldali komponensek

Kapcsolatért felelős komponens

Klienstől érkező kapcsolatépítő, -bontó kérések, adatátvitel intézése.

Adatbázis komponens

Az adatokat tároló modul, a lekérdezések, módosítások főszereplője. A rajta végzett műveletek eredményeit szükség esetén a szerver továbbítja a kliens felé.

DB-Szerver

A szerver-oldalt vezérlő modul. Feladata az egyes modulokból érkező adatok feldolgozása, lekérdezések, módosítások elvégzése. Ő irányítja a többi szerver-oldali komponens működését.

Kliens-oldali komponensek

Kapcsolatért felelős komponens

A szerver-oldal megfelelő komponensével tart kapcsolatot, a bejelentkezést, adatátvitelt, kijelentkezést intézi.

Felhasználói komponens

adatbázis (user-DBA esetén a felhasználók) adatainak lekérdezése, módosítása, törlése egy felhasználóbarát felületen keresztül. A változtatási és lekérdezési kéréseket továbbítja a szerver irányába, valamint az onnan érkező adatokat megjeleníti. A felhasználó ezzel a modullal tart kapcsolatot.

Kliens modul

A kliens-oldal vezérlő modulja. Ő irányítja a többi, kliens-oldali komponens működését. Az érkező jeleket, adatokat ő érzékeli, és továbbítja a megfelelő modul felé.

 

Futtatási, fejlesztői környezet

Szerver-oldal esetén bármely operációs rendszer megfelelő, amelyhez elérhető a 11g megfelelő kiadása. Legkönnyebb természetesen a már meglévő rendszerre implementálni. De ez sem követelmény.

Kliens-oldali felhasználói felület esetében adta magát a Java használata. Nem csak az operációs rendszer-függetlensége lényeges tényező, de az Oracle elkötelezettsége a Java mellett saját fejlesztői környezettel döntő érvnek bizonyul. Így nem kell minden résztvevőnek alkalmazkodnia egy adott elképzeléshez, egy új szerv belépéskor maradhat saját operációs rendszerénél, csak a kliens programot kell telepítenie.

A rendszer motivációja, célja

 

Jelen rendszertervezés az önálló labor feladataként jött létre, nem célja egy valódi helyzetben történő felhasználás. Csupán egy egyszerűsített változatot mutat be (továbbfejlesztési lehetőségekkel együtt):  a nagy projektekhez hasonlóan hogyan zajlik a rendszer megtervezésének folyamata, a szereplők, eszközök meghatározása, egy nagyobb egység jobb átlátása és létrehozása. Azaz segít a mérnöki gondolkodás elsajátításában.

A feladat másik legfontosabb szempontja a fenti két Oracle termék közös felhasználása egy rendszer esetén. Az Advanced Security segítségével az adatok titkosítása, a Database Vault segítségével a hozzáférések korlátozása az alapja a feladatnak. Megfelelő működésüknek, határaiknak meghatározása, minél átfogóbb megvalósítása a kitűzött cél.

A feladatban szereplő szervek közös adatbázist használnak, mivel ez kevesebb költséggel jár mind tárhely (nem szükséges minden szervnek külön-külön az egész ország adatait tárolnia), mind módosítás időigénye szempontjából (egyik szervnél történő változást így mindenki rögtön láthatja, nincs szükség továbbítani a többi adatbázis felé). Mégis a különböző szereplők más-más adatokhoz férhetnek csak (például a rendőri szervek az összes adathoz hozzáférhetnek, de a statisztikai hivatal csupán név nélkül láthat az adatokba).

 

A rendszer szereplői

A rendszer kialakításakor a bővíthetőség fontos szempont, így lehetetlen minden, később csatlakozó szereplőt most felsorolni. Mégis, a működőképesség vizsgálatához érdemes jó pár szereplőt előre definiálni. Ők következnek most.

Igazgatási rendszer esetén szóba jöhetnek például az alábbi szervek: rendőrség, népesség-nyilvántartó, statisztikai hivatal, egészségügy, földhivatal, anyakönyvi hivatal, apeh.

Minden szervnek vannak saját - különböző szintű - adatbázis adminisztrátorai, felhasználói, valamint létezik egy közös biztonsági mentés-szakértő, és egy fő-fő admin. Szervenként léteznek felhasználókat menedzselő DBA-k.

A rendszer egy kliens-szerver rendszert valósít meg, ahol a felhasználók, és a user-DBA a kliens-oldalt személyesítik meg, míg a közös DBA-k a szerver-oldalhoz tartoznak.

Az előbb felsorolt szereplők kerülnek az alábbiakban kifejtésre.

Fő-fő DBA – Szervek felett álló szerver-oldali adminisztrátor

Az adatbázis szerver működéséért felelős személy. Feladata a szerver akadálymentes elérésének létrehozása, fenntartása, az újabb szervek belépésének biztosítása (régiek menedzselése, esetleg törlése).

Ha új szerv szeretne az adatbázishoz hozzáférni, ő intézkedik a megfelelő jogok, az elérhető adatok felhasználóhoz rendeléséről. Egy külön leíró adatbázist kell kezelnie, amelyben a szervek, jogkörök, felhasználóik, és a DBA-szintek szerepelnek. Azaz melyik szerv az adatbázis mely részét érheti el, mely adatokat módosíthatja.

Így tehát az ő szerepe nem igényel állandó jelenlétet, inkább folyamatos rendelkezésre állást, amennyiben bármilyen hiba lépne fel, esetleg egy szerv ügyeit kell intéznie.

Feladatköre igényli az Oracle-ben való jártasságot.

Munkaköréből látható, hogy minél kevesebb személy kap ekkora jogosultságot, annál biztonságosabb, így az ő szerepét Fiktívországban egyetlen ember tölti be. Ő az egyetlen szereplő, aki az összes adathoz hozzáférhet.

 

Biztonsági mentés-szakértő – szervek felett álló szerver-oldali adminisztrátor

Feladata, ahogy a neve is mutatja, az egész adatbázis mentésének elvégzése. Nem kell minden szervnek külön szakértő, mivel közös adatbázis esetén felesleges.

Az ő jogosultságai nem engedélyezik az adatok elérését, sem azok módosítását, azokat láthatatlanul kezeli. A biztonsági mentés-szakértőnek is el kell igazodnia az Oracle berkein belül.

Általában nem szükséges folyamatos jelenlét, elég mentéskor. Természetesen esetleges visszaállítás miatt elérhetőnek kell lennie. Erre a feladatra is elég egy ember.

 

User-DBA – felhasználókat menedzselő kliens-oldali adminisztrátor

User-DBA minden szervnél megtalálható.

Az adminisztrátor feladata a felhasználók létrehozása, menedzselése, törlése. Külön kliens-felületet kap, melynek segítségével könnyen intézheti a felhasználókkal kapcsolatos ügyeket. A kezelői felületnél a legfontosabb szempont az egyszerűség: a felhasználókat tekintheti meg, valamint az adatait módosíthatja, felvehet új felhasználót. A felület ehetőséget ad arra, hogy a user-DBA felmentést kapjon az Oracle alaposabb ismerete alól.

Nincs jogosultsága az adatokba pillantani, sem azokat módosítani, és csupán a saját igazgatási szervéhez kap hozzáférési engedélyt.

Az ő folyamatos jelenléte sem szükséges, csupán a felhasználóknál történt változások kezelésekor van rá igény.

 

Felhasználók – a különböző szervek felhasználói különböző adatokhoz férhetnek hozzá (láthatják), valamint más-más adatokat módosíthatnak. Cél, hogy egy nagy adatbázist építsenek ki azon adatok módosításával, amelyhez joguk van. Segítségükre egy egyszerű, könnyen kezelhető kliens felületet kapnak. Általánosságban elmondható, hogy mindenki a saját bevitt adatait módosíthatja, a rendőrség minden adatot elér, a többi felhasználó a neki szükséges adatokat láthatja, nem többet, és nem kevesebbet.

 

rendőrség

Használt adatai – minden adatot lát

Módosítási jogok – saját adatok

népesség-nyilvántartó

Használt adatai – név, cím, szül. dátum

Módosítási jogok – saját adatok

statisztikai hivatal

Használt adatai – anonimizálva láthatja az adatokat – nem férhet a személyazonosságot igazoló adatokhoz

Módosítási jogok – saját adatok

egészségügy

Használt adatai – személyes adatok, saját adatok

Módosítási jogok – saját adatok

földhivatal

Használt adatai – személyes adatok, saját adatok

Módosítási jogok – saját adatok

anyakönyvi hivatal

Használt adatai – személyes adatok

Módosítási jogok – személyes adatok

apeh

Használt adatai – személyes adatok, pénzügyi adatok

Módosítási jogok – pénzügyi adatok

Az idei feladatom egy fiktívország igazgatási rendszerének megtervezése. Benne az egyes szervek (pl. rendőrség, statisztikai hivatal /az adatokat csak anonimizálva látja/, népességnyilvántartó) közös adatbázist használnak. Saját adatbázis adminisztrátorral (DBA) rendelkeznek, valamint csak azokat az adatokat láthatják, amelyekhez joguk van. Különböző szintű DBA-k léteznek (pl. közös biztonsági mentés-szakértő, felhasználót rögzítő DBA).

 

1.       Az Oracle milyen alapvető funkciókkal támogatja a hozzáférés szabályozását?

A privilégiumok jogosultságok hozzáférésre, vagy futtatható parancsokra. A szerepkör a jogosultságok egy csoportja, megkönnyíti jogok felhasználókhoz rendelését. A password policy, magyarul jelszó-házirend a használandó jelszót írja körül: mekkora a minimális jelszóhossz, milyen karaktereket kell tartalmazzon, valamint meddig maradhat érvényben egy jelszó.

 

2.       Mik a privilégiumok, mire használhatók?

A felhasználói privilégiumok, vagy jogosultságok a felhasználó adatokhoz férését szabályozzák, valamint behatárolják a felhasználó által futtatható sql-parancsokat. Minden adatbázisban végzendő művelethez a megfelelő privilégiumokkal kell rendelkezni.

A jogok két fő típusát különböztetjük meg, a rendszer-(system) valamint az objektumprivilégiumot (object privileges). A SYSDBA, SYSOPER hatáskörébe tartoznak bizonyos típusú sémákon végzett műveletek végrehajtása (például tábla, user létrehozása). Hozzáférhetnek a zárt adatbázishoz is, tehát az adatbázis indításához rendszerjogosultságra van szükségünk. Ebből is következik, hogy a rendszerprivilégiumok szabályozása az adatbázison kívülről történik.

Az objektum jogosultságok esetében adott sémán végezhető műveletek végrehajtását értjük (például lekérdezés, törlés adott táblából).

 

3.       Mit takar az erős hitelesítés kifejezés?

Külső szoftver használatával történő azonosítás (például Kerberos) Net service számára, amelyeket saját klienseivel támogat. Segítségükkel az adatbázis webes felületről, vagy kliens-szerver alapú alkalmazásokon keresztül távolról is elérhető. Ebben az esetben mindkét félnél be kell állítani a választott hitelesítési eljárást (sqlnet.ora fájl)

 

4.       Melyek a támogatott erős hitelesítési módok?

Kerberos, Remote Authentication Dial-In User Service (távoli betárcsázós hitelesítési rendszer, vagy RADIUS) kliens-szerver biztonsági protokoll Smart kártya, Token kártya hitelesítési mechanizmusokkal, Secure Sockets Layer digitális aláírással, Entrust/PKI.

 

5.       Mi a központosított hitelesítés?

Központosított hitelesítés esetén egy jelszóval akár több alkalmazás is igénybe vehető.

 

6.       Mi a hitelesítési eljárások nagy számának oka?

Sok hálózat több hitelesítést is engedélyez egy biztonsági szerveren. Ezért engedi az Advanced Security, hogy a kliensek speciális hitelesítést használhassanak, és az adatbázis szerverek elfogadhassanak bármilyen eljárást. Beállításukhoz Netmanager, vagy szövegszerkesztő használható. Szövegszerkesztő esetén az sqlnet.ora fájlt módosítjuk. Netmanager segítségével a metódusokat használatuk ajánlott sorrendjében adhatjuk meg.

 

7.       Hogyan történik a hitelesítési és adatintegritási algoritmusok kiválasztása kliens-szerver alapú alkalmazásoknál?

Ha létrejött a kliens-szerver kapcsolat, szerver választása a titkosító, és az integritási algoritmus. A szerver megkeresi azokat az algoritmusokat, amelyek elérhetők mindkettejük számára, és kiválasztja az első szóba jövőt. Ha az egyik oldalon nincs létrehozott, és sorrendbe állított algoritmus-lista, akkor az összes telepített algoritmus elfogadhatónak tekintendő. A titkosítási és integrációs paraméterek az sqlnet.ora fájlban megtalálhatók kliens és szerveroldalon.

Egy kapcsolati szakaszban egy titkosítási és egy integrációs algoritmust használhatunk.

Oracle tanácsa, hogy tegyük sorrendbe az algoritmusokat, saját döntésünk alapján, kiválasztva első helyre a legerősebb kulcshosszt.

 

8.       Mire használható a Diffie-Hellman kulcscsere algoritmus?

A titkosítás minősége függ a kommunikáló felek között megosztott titkos kulcs létezésétől. Key Management a kulcsok cseréjét, és fenntartását jelenti. Több-felhasználós környezetben a kulcsok megosztására a Diffie-Hellman kulcscsere algoritmust használja az Advanced Security. A kulcsokat sűrűn kell váltani a védett adatok megóvása érdekében. Az Advanced Security Key Management minden szakaszban lecseréli a kulcsokat. A Fold-in hitelesítési kulcs célja, hogy meghiúsítsa a lehetséges harmadik fél által okozott támadást Diffie-tárgyalás közben. Kliens-szerver kommunikáció kezdetén Diffie-szakaszkulcsot használnak a felek.

 

9.       Mire használhatók a tartományok Database Vault esetén?

Database Vault újításai segítségével rugalmasan alakítható bármely vállalat igényeihez. A hozzáférések szabályozásához a védett objektumok köré tartományt (Realm) jelölhetünk ki, és megalkothatjuk a hozzá kapcsolódó szabályokat (Rules). Így elérhető, hogy a jogosulatlan felhasználó ne változtathasson a tartományon belüli adatokon, szigorúbb esetben akár ne is láthassa azokat.

 

10.   Miért előnyös a fenti két Oracle termék használata?

Mindkettő fontos biztonsági intézkedéseket tesz adataink védelmében, fontos szempont továbbá, hogy csatasorba állításukhoz nincs szükség alkalmazásszintű módosításokra.

 

1.       Mi a HSM, és mire használható?

Hardware Security Module (HSM) fizikai eszköz, mely a titkosító kulcsok tárolásáról gondoskodik. Biztonsági memóriája segítségével hajtja végre a kódolást, dekódolást. Az Oracle Wallet biztonságosabb megoldása. A kulcs védett az illetéktelen hozzáférési kísérletektől, mivel nem egy operációs rendszerfájl, hanem fizikai berendezés. Minden művelet, ami a kulcsot használja, a HSM-en belül történik. A kulcs így nem kerül át veszélyes memóriába. A HSM-et újra aktiválni kell, ahányszor az adatbázis újraindul. Menedzselése a biztonsági adminisztrátor felelőssége. Ha az adatbázis nyilvános kulccsal titkosított oszlopot tartalmaz, az oszlopot visszaállítja, majd újrakódolja HSM-alapú, AES szimmetrikus kulcsú titkosítással.

 

2.       Wallet elhelyezésére és karbantartására milyen lehetőségek állnak rendelkezésre?

A wallet lehet egy előre megadott helyen megosztva más adatbázis komponensekkel, vagy elkülönítve tároljuk külön modulban a mesterkulcsot (ezt ajánlja az Oracle). A második esetben lehetőség van automatikus elérésre (auto-login), amikor a tárca folyamatosan nyitva van. Akkor használatos, ha nincs szükség erős biztonsági intézkedésekre (például csak akkor legyen nyitva, ha a megfelelő személy használja), kényelmes hozzáférést jelent a titkosított adatokhoz adatbázis újraindulása esetén is. A külön modul használata elszeparálja az alap adatbázis-kezelő programokat a titkosítási műveletektől, lehetővé téve az adatbázis adminisztrátor és a biztonsági adminisztrátor feladatainak szétválasztását. A biztonság fokozódik, mivel a wallet jelszava az adatbázis admin előtt ismeretlen, megkövetelve, hogy a biztonsági admin feladata legyen a tárca kezelése.

 

3.       Windows környezetben milyen lehetőségek vannak tárcák tárolására?

Windows rendszerben lehetőség van többszörös wallet tárolására a registryben, előnyei

·       könnyebb hozzáférés felügyelet: a wallet a felhasználó profil területén tárolva csak a felhasználónak engedélyezi a hozzáférést, kilépésével a wallethez férést is meggátolja

·       könnyebb adminisztráció: nincs szükség engedélyek kérésére, a wallet automatikusan törlődik a profil törlésével. Az Oracle Wallet Manager létrehozható, és kezelhető a registryn belül.

támogatott lehetőségek:

·       registryben létrehozott, registrybe mentett, registryből törölt wallet

·       elmentés másik registry területre

·       fájlrendszerben megnyitott wallet mentése registrybe, és fordítva

 

4.       Milyen feladatokat lát el az Oracle Wallet Manager?

A wallet gondoskodik a szükséges tároló helyről, ahol biztonságban tudhatók az igazolások, valamint megbízhatósági pont, ahol a partner hitelessége ellenőrizhető (tanúsítvány - aláírt adatstruktúra, ami összeköti a hálózati személyazonosságot a megfelelő nyilvános kulccsal). A tárca erős jelszóval védett (min 8 karakter, nincs max hossz, kevert betű, szám vagy egyéb karakterek). A kulcsok tárolása X.509-es szabvánnyal karöltve, 3DES titkosítással történik. Ezen adatok kezelését, szerkesztését végzi az Oracle Wallet Manager:

·           wallet létrehozása

·           igazolás-kérés létrehozása

·           PKI-alapú szolgáltatások eléréséhez a wallet megnyitása

·           wallet kihelyezése külső környezetbe (harmadik fél)

·           PKCS #12 formátumú wallet behozatala külső helyről

·           wallet fel- és letöltése

·           igazoló iratok biztonságos hardver modulba mentése API-k segítségével, amely eleget tesz a 11-es számú nyilvános kulcsú titkosítási szabványnak (PKCS #11 – Public-Key Cryptography Standards #11)

 

5.       Mit jelent az auto-login, mikor használható?

Auto-login az automatikus wallet-hozzáférést jelent, ha a wallet-et külön modulban tároljuk. PKI-alapú hozzáférést jelent  a szolgáltatásokhoz mellőzve az emberi beavatkozást. Használata létrehoz egy elhomályosított wallet-másolatot, amelyet addig használ automatikusan, amíg az auto-login módot ki nem kapcsoljuk. Auto-login wallet-eket fájlrendszeri engedélyek védik. Auto-login módban csak az operációs rendszer felhasználója, aki a wallet-et létrehozta, tudja kezelni Oracle Wallet Manager-en keresztül.
Engedélyezni kell az auto-logint, ha egyszeri belépési hozzáférést (Single Sign-on) szeretnénk összetett Oracle adatbázisokhoz.

 

11.       Mesterkulcs létrehozására és karbantartására milyen lehetőségek vannak?

Mesterkulcs alap esetben egy random érték, de lehet egy PKI-tanúsítvány (Public Key Infrastructure – Nyilvános Kulcsú Infrastruktúra) által kijelölt aszimmetrikus kulcspár.

A jelenlegi kulcstároló vagy visszaállító rendszerek, a kulcshitelesítők a titkos kulcs egy verzióját tárolják, vagy információt, ami segít visszaállítani azt. Ha a privát kulcs elveszett, akkor a felhasználó az eredeti kulcsot, és a tanúsítvány visszaállítását a tanúsítvány hitelesítőtől kérheti. Általában ez a visszaállítás automatizált, és a felhasználónak csak bizonyos hitelesítési adatokat kell megadnia a tanúsítvány kiadója felé. TDE egyetlen feltételt szab, a kulcsnak és a tanúsítványnak meg kell felelnie a PKCS#12 szabványnak.

Egyik kulcstípus sem ad nagyobb biztonságot, ám a PKI-szolgáltatás lényegesen több rendszerben alapkövetelmény, mint a szimmetrikus titkosítás. Viszont a PKI kulcspár használata nagyobb teljesítménycsökkenést okozhat, ha a titkosított oszlopokhoz hozzáférnek.

 

12.       Külső táblák használatakor fellépő problémákra milyen megoldások adhatók?

Külső helyen levő tábla oszlopai titkosíthatók random kulcs segítségével. Amennyiben a külső tábla új helyre kerülhet, a random módszer nem használható, mivel a random kulcs az új helyen nem feltétlen érhető el. Ezért érdemes jelszót létrehozni a titkosítás idejére, majd az adatok mozgatása után ugyanazzal a jelszóval újra generálható a kulcs, amivel az adatok elérhetők.

 

13.       Táblahely titkosítására milyen lehetőségek vannak?

Táblahely titkosítása után a rajta létrehozott táblák automatikus titkosításra kerülnek. Előnyös, ha több oszlop tartalmaz titkosítani való adatot, vagy egy egész táblát titkosítani szeretnénk, nem csupán egy oszlopot. Titkosított táblahely összes adata a titkosított táblahelyen található, még óriás objektumok esetén is (pl. BLOB, CLOB). Azokat az adatokat, amelyeket máshol tárolnak, nem titkosítja, ezek kódolás nélkül maradnak (pl. BFILE). A kódolt adatok átlátszóak, a jogosult felhasználó úgy dolgozhat rajtuk, mint a nem titkosított adatokon.

Táblahely titkosításakor a mesterkulcs segítségével kódoljuk a táblahelyek kulcsait, amelyek a táblahelyek adatait védik.

Az adatok védettek maradnak pl. JOIN, SORT műveletekre, amikor az ideiglenes táblahelyen vannak, továbbá az undo, redo műveletek sem ártanak a biztonságuknak. Az index szerinti keresés során sem kerülnek ki a biztonságos zónából, ami nem mondható el az oszlopok titkosítása esetén. Táblahely titkosításához 10.0.0+ Oracle adatbázisra van szükség. Már létező táblahelyet nem titkosíthatunk, ehhez a táblák átmozgatására van szükség egy védett táblahelyre.

 

14.       Milyen veszélyeket rejtenek a szellemmásolatok (ghost copies)?

Átlátszóan titkosított adatokat titkosított formában egy adatfájlban tároljuk. De ezek a fájlok tartalmazhatnak néhány tiszta adatot (szellemmásolatok, ghost copies, amit egy korábbi adatművelet hagyott a táblában).

Régi törölt szövegrészek valamennyi ideig jelen vannak, amíg az adatbázis felül nem írja. Ha jogosult felhasználók átlépik az adatbázis biztonsági ellenőrzését, közvetlenül hozzáférhetnek ezen adatokhoz.

 

15.       Mi történik a titkosított adatokkal export-import művelet közben?

titkosított oszlopokat tartalmazó táblák mozgatásakor fontos szempontok:

·           érzékeny adatok megfejthetetlenek maradjanak szállítás közben

·           jogosult személyek dekódolhassák az adatot célba érkezés után

Oracle Data Pump használható export-import műveletekhez. Export előtt titkosítani kell egy új jelszó segítségével. Import esetén ugyanazt a jelszót kell megadni, ezzel az oszlop visszaállítható, és a cél adatbázis titkosítja a saját kulcsaival (ehhez az ottani tárca is nyitva kell legyen).

Oracle Data Pump ezen verzióban továbbfejlesztésre került, a teljes mentési fájlt (dump set) titkosíthatjuk. Lehetséges akár dupla titkosítás is, amikor nem csak mesterkulccsal, hanem jelszóval is titkosítunk. Importáláskor a jelszós, vagy a mesterkulcsos visszaállításra van lehetőség. Jelszó nélkül a wallet mesterkulcsát használja dekódolásra.

 

16.       Hogyan valósítható meg az adatok hálózaton történő biztonságos továbbítása?

Kétféle támadás ellen nyújt védelmet az Advanced Security hálózaton történő adattovábbítás esetén: adatmódosítás, adatduplikáció. Megoldást a hash-algoritmusok jelentenek, melyek ellenőrző összegei jelzi az adatforgalomban történt változást. Kétféle hash algoritmus, a Message Digest 5 (MD5) és Secure Hash Algorithm (SHA-1) akár adattitkosítás nélkül is használható.

 

 

1.       Hogyan valósítható meg az adatok biztonságos tárolása?

Védett adatok tárolására az Advanced Security az átlátszó adattitkosítást (Transparent Data Encryption) használja. Segítségével az adatokat tárolás előtt titkosítjuk, így mentésre a más titkosított adat kerül. Átlátszó adattitkosításnak nevezzük, mert a felhasználó elől rejtve történik a kódolás, a dekódolásról is maga gondoskodik. A felhasználónak nem kell tudnia, mely oszlopok kerültek kódolásra.

 

2.       Mik az átlátszó adattitkosítás (Transparent Data Encryption) előnyei?

·         Nem szükséges alkalmazásokba beavatkozni, elég hálózati beállítások módosítása.

·         A titkosítás az adatbázis-kezelőben történik, a felhasználók elől rejtve.

·         Maga gondoskodik a titkosításhoz szükséges kulcsok generálásáról, és karbantartásáról.

·         Védelmet nyújt az adathordozó eltulajdonítása esetén is, mivel a visszafejtéshez szükséges kulcsokat külön hardveren tároljuk.

 

3.       Mi az átlátszó adattitkosítás hátránya?

A titkosítás során pluszköltségek jelennek meg mind a teljesítmény, mind a tárolt titkos adat méretét tekintve. Az előbbinél a titkosítás körülbelül 5%-os teljesítménycsökkenést jelent, az adatok tárigénye általánosságban 32-48B-tal növekszik oszloponként.

 

4.       Milyen részekből épül fel az átlátszó adattitkosítás?

A titkosításra váró oszlopok kódolásához szükség van táblakulcsokra, ezek segítségével a titkosítás elvégezhető. A táblákhoz tartozó kulcsok titkosításához pedig a mesterkulcs vagy más néven főkulcs (Master-Key) áll rendelkezésre. Ezt a kulcsot külön tároljuk az adatbázistól, külső hardveren, amit tárcának (wallet) nevezünk. Nehezítésként a wallet elérése jelszóval történik. A táblákhoz tartozó kulcsokat az adatbázis Dictionary táblájában tárolja.

 

5.       Melyek az átlátszó adattitkosítás előkészítő lépései?

A titkosításhoz először wallet létrehozására van szükség (ALTER SYSTEM jogosultsággal rendelkezve), amelyhez jelszót kell megadni. Ezt követően megnyitjuk a walletet, és létrehozzuk a mesterkulcsot. A wallet használatához a tárcát létrehozás után meg kell nyitni, anélkül nem érhető el a benne tárolt mesterkulcs. A mesterkulcs segítségével pedig a táblákhoz tartozó kulcsokat titkosíthatjuk.

 

6.       Milyen titkosító algoritmusokat támogat az Advanced Security?

11.1-es Advanced Security támogatja a ma elérhető titkosító algoritmusokat, és kulcshosszakat (Korábbi verziók használata esetén  „Domestic” kiadásra van szükség, amely ezeket tartalmazza):

·           Az alap titkosító eljárás az AES (Advanced Encryption Standard), ezt használják az amerikai kormányszervek és cégek a hálózati adatforgalom biztonságához. Használt kulcshosszok 128, 192, 256 bit. Mindegyik CBC (Visszacsatolt blokk-kódolás) módban működik.

·           DES (Data Encryption Standard) AES előtti standard volt sok évig.

·           Triple-DES a DES eljárásai 3-szor egymás után. A magas fokú üzenetbiztonság ára a teljesítmény csökkenése. Ez a processzorok sebességén mérhető le, ami lecsökken a titkosítás miatt. Elérhető 2- vagy 3-kulcsos verziója, kulcshosszakra 112 vagy 168 bit a választható érték.

·           RSA RC4 algoritmus nagy sebességű kódolás nemzetközi szabványa. Változó kulcshosszakat használ folyamkódoláshoz. Nagy adatátvitel minimális sebességingadozással. RC4 kivitelezés kulcshosszai 40, 56, 128, 256, hátra kompatibilis, erős titkosítás lényegi teljesítményváltozás nélkül.

 

7.       Mikor nem használható az átlátszó adattitkosítás?

Nem használható külső kulcsot tartalmazó oszlop esetén, mivel minden tábla egyedi oszlop-kódoló kulccsal rendelkezik. Valamint a titkosítás folyamata az SQL rétegében történik, így azok a programok, melyek elkerülik ezt a réteget, nem alkalmazhatók az adattitkosítással együtt:

·           B-fától eltérő indextípusok

·           láncolt pásztázás indexek alapján

·           külső nagy objektumok (BFILE) (Megj.: az Oracle 11g már támogatja a belső nagy objektumokat – BLOB, CLOB)

·           megvalósított nézetnaplók

·           egyidejű adatváltoztatás elfogása

·           szállítandó táblahelyek

·           eredeti ex-import programok

 

8.       Mely Oracle verzióban használható az átlátszó adattitkosítás?

Az átlátszó adattitkosítás már a 10g-ben elérhető volt, a használatához a 10.2-es verziószám az alapkövetelmény. A 11.1-es verzió magasabb biztonságot jelent az átmeneti táblahelyeken végzett műveleteknél, mint pl. SORT, JOIN. Ekkor az adatok titkosítva maradnak. A 10.2-ről frissített 11.1 esetén a használatban tartott titkosítás esetén az ORACLE felajánlja az adatbázis 11.0.0 kompatibilitását, és a mesterkulcs visszaállítását.

 

9.       Mit jelent a Salt, és mikor használható?

Salt használatakor az adathoz egy random karaktersorozatot adunk, majd a kapott karaktersorozatot titkosítjuk. Használata csak azon oszlopoknál engedélyezett, amelyeket nem látunk el indexeléssel. Ha titkosított oszlopot indexszel látunk el, a korábbi titkosítás többé nem alkalmazható.

Használata tovább erősíti az adatok biztonságát, mivel az azonos karaktersorozatok más kódszót kapnak, így lehetetlenné teszi a minta alapján történő visszafejtést.

10.   Mesterkulcs létrehozására és karbantartására milyen lehetőségek vannak?

Mesterkulcs alap esetben egy random érték, de lehet egy PKI-tanúsítvány (Public Key Infrastructure – Nyilvános Kulcsú Infrastruktúra) által kijelölt aszimmetrikus kulcspár.

A jelenlegi kulcstároló vagy visszaállító rendszerek, a kulcshitelesítők a titkos kulcs egy verzióját tárolják, vagy információt, ami segít visszaállítani azt. Ha a privát kulcs elveszett, akkor a felhasználó az eredeti kulcsot, és a tanúsítvány visszaállítását a tanúsítvány hitelesítőtől kérheti. Általában ez a visszaállítás automatizált, és a felhasználónak csak bizonyos hitelesítési adatokat kell megadnia a tanúsítvány kiadója felé. TDE egyetlen feltételt szab, a kulcsnak és a tanúsítványnak meg kell felelnie a PKCS#12 szabványnak.

Egyik kulcstípus sem ad nagyobb biztonságot, ám a PKI-szolgáltatás lényegesen több rendszerben alapkövetelmény, mint a szimmetrikus titkosítás. Viszont a PKI kulcspár használata nagyobb teljesítménycsökkenést okozhat, ha a titkosított oszlopokhoz hozzáférnek.

Több cég használhat közös adatbázist adatainak tárolására. Ám ilyenkor közelebbi veszélyekkel is számolni kell, mint egy kívülről érkező támadó esetén. Közös információik birtokában akár kis utánajárással a másik fél adataihoz férhetnek. Így tehát a legfontosabb kérdés a szeparálhatóság. A következőkben a szétválasztási lehetőségeket vizsgálva kerülnek elő, majd megválaszolásra a kérdések. A válaszokat az Oracle 11g korábbról hozott bevált eszközei és újításai adják.

 

1.       Mik a legfontosabb célok az adatbázis felosztásakor?

                                I.            A cégek egymás adatait ne láthassák

·   Az adatok biztonságos tárolása

·   Az archív fájlokhoz ne férhessenek illetéktelenek

·   A biztonsági mentések se legyenek jogosulatlanok számára hozzáférhetők

                              II.            Jelszavak, kulcsok külön tárolása (akár több helyre szétosztva)

                            III.            Adminisztrátorok jogainak szétválasztása, hozzáférések szabályozása (cégeknek saját biztonsági adminisztrátor)

                            IV.            Terheléselosztás

 

2.       Mely Oracle termékek segédkeznek az előbbi célok megvalósításában?

Flashback Data Archive segítheti az archiválást, az Automatic Workload Management pedig hozzájárul a terhelésmegosztás javításához. Róluk jelen dokumentumban a későbbiekben nem lesz szó.

A megelőzésben az Oracle alap biztonsági funkciói mellett az Oracle Database Vault, valamint az Oracle Advanced Security nyújt segítő kezet. A továbbiakban csak ezek tulajdonságai kerülnek górcső alá.

3.       Database Vault mely opcióit alkalmazhatjuk közös adatbázis használata esetén?

Az Oracle Database funkciói mind a védettséget fokozzák:

·           Kiváltságos felhasználók jogainak erős korlátozása (adminisztrátor, fejlesztő, alkalmazás felhasználó), nem módosíthatják, vagy akár nem is láthatják az adatokat.

·           Tartományok, és a köréjük létrehozható szabályok segítségével az egyes adatbázis-részletek külön is védhetők a jogosulatlan felhasználóktól.

·           Többtényezős hozzáférési szabály segítségével a behatolás még nehezebbé tehető (megadható, ki+mikor+honnan érheti el az adatbázist).

·           Védelmet jelent a jogosulatlan módosítások ellen, valamint parancsszintű szabályokat róhatunk ki SQL parancsokhoz.

4.       Az Advanced Security mely funkcióit alkalmazhatjuk közös adatbázis használata esetén?

Az Oracle Advanced Security biztonsági megoldásai:

1)      Erős hitelesítés

2)      Hálózati titkosítás

3)      Átlátszó adattitkosítás

 

 

3. Behatolás elleni védelem

3.1 Password policy (jelszó házirend)

Behatolás elleni védelem erőssége a jelszó bonyolultságától is függ. A meghatározott jelszóhosszon kívül a tartalmazott karakterek széles skálája mind a nehezebb megfejtést teszik lehetővé. Megadhatunk határidőt, meddig lehet érvényben egy karaktersorozat, lejártakor a jelszót változtatni kell. Ennek elhanyagolásakor, vagy a jelszó többszöri sikertelen próbálgatása esetén a password zárolásra kerül (lock). Minden felhasználói fiókhoz egy profile objektumot rendelünk, amelynek attribútumai együtt adják a házirendet.

(Léteznek az adatbázisban default jelszavak. Ez esetben a verzió frissítésekor (upgrade) a régi jelszavak megmaradnak, így könnyű célpontot jelenthetnek támadáskor, ezért ezeket előbb meg kell változtatni. Default password a data dictionary view-ban megkereshető.)

 

Az adatbázis felhasználók információi SYS userként a jelszavakkal együtt látható. A biztonság érdekében ezeket az oszlopokat az ORACLE titkosítja.

A jelszavak védelmére ajánlott Advanced Security használata, vagy egyéb, erős autentikációval, nehezen másolható belépési móddal támogató szolgáltatások (például token, Kerberos, smart kártyák).

3.2 Transparent Data encryption (átlátszó adattitkosítás)

Az adatok védelmében játszik fontos szerepet a transparent data encryption. Az adatot csak a címzett képes elolvasni (fordítani). A Masterkey a kulcs, amivel a fordítás elvégezhető. A kulcsot úgynevezett wallet-ben (tárca) tároljuk. Ha egy user adatot visz titkosított cellába, akkor az adatbázis a köv lépéseket teszi: walletből kiveszi a masterkey-t, a kulccsal a táblához tartozó titkosító kulcsot visszafejti az adatszótárból (data dictionary). Ezzel a kulccsal az adatot titkosítja, majd tárolja a titkos formában. Transparent data encryption segítségével igazolható, hogy egy adatbázis megfelel valamely biztonsági előírásnak. Lényeges momentuma, hogy a titkosítást az adatbázis maga elvégzi. Nem kell programozni, a kódolás a háttérben történik. Előnye, hogy a fontos adat biztonságban van akkor is, ha a tároló médiát, vagy az adatfájlt ellopják. Hátránya, hogy 32-48B-tal több helyet igényel cellánként.

 
3.3 Óvintézkedések

A teljesség igénye nélkül néhány fontos feladat, amelyekkel az adatbázis biztonsága garantálható. Ha megbizonyosodtunk arról, hogy a telepítés, valamint a konfigurálás biztonságos, a telepítés után megbízható házirendet alkothatunk, és a felhasználói hozzáférést szabályozhatjuk. A default biztonsági beállításokat engedélyeznünk kell (auditálási beállítások, erősebb jelszó-házirend, és így tovább). Lényeges a hálózati kapcsolat biztonságának feltérképezése, és az érzékeny adatok megfelelő titkosítása. A hálózati kapcsolat esetén is segítséget nyújt az Advanced Security.

2. Felhasználók jogkörének behatárolása

 

2.1 Privileges (privilégiumok)

A felhasználói jogosultságok alapvető fontossággal bírnak a biztonság területén. Bevezetésük célja, hogy a felhasználó adatokhoz férését szabályozzák, valamint behatárolják a felhasználó által futtatható sql-parancsokat. Minden adatbázisban végzendő művelethez a megfelelő privilégiumokkal kell rendelkezni.

A jogok két fő típusát különböztetjük meg, a rendszer-(system) valamint az objektum-privilégiumot (object privileges). A rendszer jogosultságok hatáskörébe tartoznak bizonyos típusú sémákon végzett műveletek végrehajtása (például tábla, user létrehozása). Az objektum jogosultságok esetében adott sémán végezhető adott műveletek végzését értjük (például lekérdezés, törlés adott táblából).

 

Rendszerprivilégiumok

SYSDBA a legmagasabb szintű hozzáférési jogosultság (SYS user SYSDBA jogosultsággal rendelkezik), a SYSOPER-re jogosult alapvető feladatok elvégzére kap engedélyt anélkül, hogy a felhasználók adataiba belelátna. Mindkettővel hozzáférhetünk az adatbázishoz, akkor is, ha az nincs nyitott állapotban, ezért szabályozásuk az adatbázison kívülről történik. Rajtuk keresztül kapcsolódhatunk tehát az adatbázishoz, ha indítani akarjuk.

2.2 Roles (szerepkörök)

Privilégiumok könnyebb kezelhetősége érdekében hozták létre a szerepköröket. Egy szerepkör adott rendszer- és objektum-privilégium csoportot tartalmaz, ezeket rendeljük az egyes felhasználókhoz. Magunk is létrehozhatjuk őket, de az adatbázis néhány előre definiált szerepet tartalmaz, amelyeket a jogosultságok kiosztásakor felhasználhatunk. A connect role a kapcsolódás engedélyezésére szolgál. A resource role a felhasználóhoz rendelt sémákon végzett műveletek jogát adja, korlátlan tárhelyet biztosít, csupán nézetet nem hozhat létre (CREATE VIEW), minden más jogosultságot rendelkezésre bocsát, amire a sémákat létrehozó felhasználónak szüksége van. A dba role a legtöbb adminisztrációs funkciót eléri. Felhasználókat hozhat létre, szerepeket, jogokat oszthat, séma műveleteket végezhet. Minden rendszer-jogosultságot megkap, kivéve az adatbázis indítása és leállítása. A dba a SYS valamint a SYSTEM felhasználó alapértelmezett szerepköre. Szerep törlésekor (SYSTEM) minden user elveszti a szerepben rejlő képességét.

Adatbázis biztonság

 

Az alábbi felsorolás az adatbázisok biztonságát növelő elemeket és a fontosabb óvintézkedéseket tartalmazza. Feladatomban a több cég által közösen használt adatbázis korlátairól, előnyeiről és lehetőségeiről adok összefoglalót. Ehhez a legfontosabb szempontot a biztonság jelenti. Közös adatbázis használatában nagy segítséget nyújt a Database Vault, valamint az Advanced Security. Ezen termékek plusz szolgáltatásai átláthatók, ha ismerjük az ORACLE alapvető biztonsági intézkedéseit.

 

1. Felhasználói fiók

1.1 user account (felhasználói fiók)

ORACLE-ben a felhasználói fiók többek között hitelesítési eljárást tartalmaz, amelyhez minden felhasználónak jelszóra van szüksége. A fiók státuszokkal is rendelkezik; lehet zárolt (nem hozzáférhető - locked), valamint a jelszó státusza lejártat jelezhet (expired), például adott idő után frissítésre ítélt jelszó nem kerül módosításra, de léteznek eleve lejárt jelszavak, ilyet találunk a minta sémáknál (sample schema).

Account létrehozásakor felhasználónevet, jelszót, alapértelmezett táblahelyet jelölünk ki, valamint rendszer- és objektum jogokat, és szerepkört adunk hozzá.

Létrehozhatunk alkalmazások által használt fiókot is. Az alkalmazások ezen keresztül kapcsolódnak az adatbázishoz, de felhasználó nem tud bejelentkezni vele, megelőzve az illetéktelen közvetlen hozzáférést és a (nem szándékos) károkozást.

 

Az adatbázis installálásakor automatikusan létrejönnek adminisztratív fiókok (SYS, SYSTEM, SYSMAN, DBSNMP), amelyek nem törölhetők, és magasszintű hozzáférést jelentenek, úgymint adatbázis leállítása, indítása, tárhelyek menedzselése, felhasználók létrehozása.

Az adatbázisok belső fiókokat is tartalmaznak, amelyet a user nem használhat fel, és nem is törölhet.

 

Az adminisztratív usereket az adatbázis telepítéskor automatikusan létrehozza. Magasszintű feladataik között szerepel az adatbázis és felhasználóinak menedzselése. Két fajtája van, SYS és SYSTEM. SYS user több funkciót tartalmaz: SYS-ként felhatalmazást kaphatunk biztonsági mentésre (backup), állapot-visszaállításra vagy adat visszanyerésre (recover) és verziófrissítésre (upgrade). Továbbá a SYS séma tárolja a data dictionary (adatszótár) alaptábláit, amelyek kritikusak az egész adatbázis futtatásához, nem szabad megváltoztatni. Sőt, a SYS sémában nem szabad más táblát létrehozni.

Az ORACLE javaslata, hogy minden felhasználónak pont a kellő jogokat biztosítsuk, ami a feladat ellátásához szükséges, és nem többet!

 

1.2 Schema (séma)

Felhasználó létrehozásakor értelemszerűen sémát is létrehozunk. A séma logikai gyűjtőnév, a felhasználó adatbázis-objektumait tartalmazza (ilyenek például a táblák, nézetek, triggerek). Lehetőség van minta sémák (sample schema) létrehozására is, amely alkalmas a tapasztalatszerzésre, anélkül, hogy a fontos adatokat veszélyeztetnénk.

Mivel a cégek használta adatbázis legfontosabb tényezője a biztonság, így első közelítésben az Oracle alapvető biztonsági kérdéseivel foglalkozom. Majd ezt követően kerül sor a biztonságot növelő termékek megismerésére. Végül a kérdések összeállítása, és megválaszolása lesz terítéken.

Az alaptémám továbbra is a Database Vault, ám most kicsit konkrétabb feladat következik.
A feladat: "Különböző cégek közös adatbázis használatának korlátai, lehetőségei".
Ebben a félévben a DBVault mellett szerepet kap az Oracle Advanced Security is.

Némi töprengés után eljutottam arra a felismerésre, hogy nem custom módban indítottam a telepítést, így nem csoda, hogy a DBVaultnak nyomát sem találtam. Két-három rá- és újratelepítés, néhány, a registryből kézzel eltávolított ORACLE-höz tartozó service-kulcs, valamint újraindítás után újabb telepítést mértem a gépemre, hogy immáron a számomra fontos funkciók is elérhetővé váljanak.

Részletesebben:
Kézzel távolítottam el a fájlokat, mivel a telepítő valamilyen hiba miatt nem adott segítséget a már felrakott fájlok eltűntetésében. Az oci.dll-t nem lehetett eltávolítani. A neten való keresgélés segített a megoldáshoz, így ha átnevezem a fájlt, és restartolok, az állomány törölhetővé válik.

A telepítés:
Custom módban indítva minden lehetséges funkciót bejelöltem a telepítéshez. A service-ek indítása közben nem tudta elindítani a MS Transaction Serverrel együttműködő service-t (ennek, gondolom, egy előkövetelmény hiánya volt az oka: nincs MS Transaction Serverem telepítve), de a hibát "ignorálhattam". Ezek után még egy 05.jpg hiba jött elő, de az Enterprise Manager elindult.

A hosszas Linux huzavona után visszatértem a jó öreg Windows-hoz. Örömmel tapasztaltam, hogy minden gond nélkül, azonnal (=elsőre) feltelepült a 11g! Ezt nem gondoltam volna, főleg a korábbi telepítési problémák miatt, amit persze legfőképp én magam okoztam Debian erőltetésével.

Most már nincs más hátra, mint előre!

A telepítési dokumentációt  (http://download.oracle.com/docs/cd/B28359_01/install.111/b32281/toc.htm) követve az Oracle 11g for Linux a telepítést követően hibamentesen elindult, erről meggyőződhettem a webes Enterprise Managerbe való belépés után.
Láthatóan jól működött, képes voltam új adatbázist létrehozni, az adatbázismotor tulajdonságait megnézni, biztonsági beállításokat ellenőrizni. A többszintes modulok között nézelődtem.
De komolyabb munkát akkor még nem kezdtem, mivel arról akartam meggyőződni, hogy a linux újraindítása után a kívánt szolgáltatások (pl. Oracle Listener, Consol) automatikusan, a kívánt módon elindulnak, és ugyanezen futó állapotba kerülnek (sajnos elkövettem egy szarvashibát: nem mentettem le a működö 11g-ről screenshot-ot, ami az éppen működő Oracle-t mutatja a böngészőben).

Legközelebbi újraindítás után azt tapasztaltam, hogy a Linuxon kívül más nem indult el.
Újra dokumentációolvasás következett, amiből kiderült, hogy a telepítő nem is hozza létre a megfelelő szolgáltatás-indító bejegyzéseket egyik futási szinten sem (runlevel), azt kézzel kell megvalósítani.
Az ide vonatkozó dokumentációk (http://www.pythian.com/blogs/549/installing-oracle-11g-on-ubuntu-linux-704 - Ubuntuhoz, http://linux.togaware.com/survivor/Starting_Stopping.html)
olvasásába kezdtem, megpróbáltam a lehetőségekhez (Debian) mérten a lehető legkompatibilisebben eljárni a megfelelő init script létrehozásában. Ez részben működött is, de az adatbázismotor indulásakor a logokból visszakövetve olyan nem várt (és nem is dokumentált) hibát kaptam, amely után érdemben nem tudtam továbblépni.

Ezért nem vettem részt az DBVault konzultáción, hiszen el sem jutottam az adatbázisokig.

Örömmel tapasztaltam viszont, hogy Windows platformra is megjelent az Oracle 11g! A Windows XP SP2 image-emet visszatöltöttem a gépre, most indul a második roham az Oracle ellen, immáron Windows környezetben.

Röpke 4 óra alatt a Windows XP-t felváltotta a Debian Etch, Gnome. Az Oracle 11g letöltése még javában tart.

A letöltéshez a www.otn.oracle.com oldalról indultam, majd bejelentkezés után az alábbi címről töltöm:
http://www.oracle.com/technology/software/products/database/oracle11g/111060_linuxsoft.html.
A fenti oldalon kiválasztott Oracle Database 11g Release 1 (11.1.0.6.0) for Linux x86 programhoz a linux_11gR1_database.zip (1,844,533,232 bytes) (cksum - 4231932775) adatok tartoznak.

Megkezdi pályafutását a blog, megkésve bár...
Eddigi sikertelen próbálkozásaim után arra a döntésre jutottam, Linuxot rakok a gépre. Úgy talán minden egyszerűbb lesz.
Amíg ez meg nem történik, Sárecz Lajos ajánlására telepítem a 10g-t windowsra, és jöhet a Database Vault.

Talán túl optimista munkatervemben a telepítés, és 11g-hez, valamint DB Vaulthoz tartozó alap irodalmak feldolgozása a 4-7. hétre került. E szerint október 20-a környékén a kezdeti ismerkedés megtörténik.

Most pedig irány a 10g!