Adatbázisok biztonsági kérdései
Az adatbázisokon alapuló információs rendszerek egyik lényeges vonása, hogy
a bennük tárolt információkat védeni kell. Gondoljunk csak bele, mennyire
felháborodnánk, ha a bankokban vezetett számláinkról bárki pontos információt
kaphatna, ha minden adatunk nyilvánossá válna. Nem is szólva arról a
lehetőségről, hogy számláinkról bárki pénzt emeljen le a mi tudtunk,
hozzájárulásunk nélkül. Az információs rendszernek úgy kell működnie, hogy
mindenki csak a jogosultsági körébe eső adatokat érhesse el.
Az információ védelme nem kizárólagosan az adatbáziskezelő rendszerek
feladataihoz kapcsolódik, hiszen az informatika szinte minden területén
szükség van az ott feldolgozott információk jogosulatlan felhasználásának
megakadályozására. Az operációs rendszerek területén is nap mint nap
találkozunk a védelem legkülönbözőbb megjelenési formáival. Rögtön az
induláskor a rendszerhez való hozzáférést csak akkor kapjuk meg, ha
azonosítjuk magunkat, mint jogosult felhasználó egy azonosító név és egy
jelszó segítségével. A sikeres bejelentkezés után a többfelhasználós rendszer
nem tárulkozik ki előttünk teljes egészében, csak bizonyos részletekhez enged
hozzáférést. A leggyakoribb operációs rendszerbeli védelmek a felhasználók és
a objektumok azonosító kódrendszerén (UIC), egy hozzáférési listán (ACL),
vagy pedig egy privilégium rendszeren alapszik.
Az eddigi tapasztalataink alapján már tudjuk, hogy az adatbázis kezelő
rendszerekben is élnek ilyen védelmi funkciók, hiszen például az Oracle
RDBMS esetében is előbb azonosítani kell magunkat egy névvel és egy
jelszóval, hogy hozzáférhessünk az adatbázisban tárolt adatokhoz. A sikeres
bejelentkezés után itt is csak egy korlátozott hozzáférési jogot kapunk az
adatbázishoz, hiszen mind az elvégezhető műveletek, mind pedig az elérhető
objektumok köre csak egy szűk része az adatbázisban letárolt és biztosított
objektumok, funkciók halmazának.
A következő fejezetben az RDBMS rendszerekben megvalósított védelmi
funkciókat és védelmi módszereket tekintjük át. felmerülhet a kérdés, miért
nem elegendőek az eddig megismert, jórészt operációs rendszerhez kapcsolódó
védelmi módszerek. Miért kell ismét ezzel a területtel foglalkozni? Ennek
elsődleges oka az, hogy az azonos vagy közel álló védelmi célok és védelmi
taktikák mellett az RDBMS számos az operációs rendszerben megszokottól
eltérő egyedi védelmi sajátsággal is rendelkezik. Az operációs rendszerekben
megismert utasítások, mechanizmusok önmagukban nem elegendőek az
RDBMS hatékony védelmi mechanizmusának kiaknázására. Új utasításokat,
mechanizmusokat kell megismernünk, melyek mind finomságukban, mind
összetettségükben túlmutatnak az eddig megismert módszereken.
Az RDBMS rendszerek védelmi aspektusát vizsgálva az adatbázis
biztonságának fogalmát ez előbb említettektől tágabb értelemben is szokás
használni. A biztonság ebben a megközelítésben mindazt magába foglalja, ami
a rendeltetésszerű, elvárt működéshez szükséges. Így a RDBMS biztonsága
alatt nemcsak az adatok jogosulatlan hozzáférésének ellenőrzését értjük. Ide
szokás sorolni azon mechanizmusokat is, melyek a tárolt adatok helyessége, az
adatok integritása felett őrködnek, hiszen a téves adatok a rendszer
használhatóságát aknázzák alá. Az elvárt működéshez tartozik még emelett az
is, hogy a rendszer az igényelt időkben, körülmények között ki tuddja szolgálni
az igényeket, ne vesszenek el belőle adatok, ne kelljen rendszer összeomlások
miatt várakozni. Ez alapján tehát az RDBMS biztonsága általános szinten
tekintve három fő komponenst foglal magába:
- adatokhoz védelme (security)
- adatok megbízhatósága (integrity)
- rendelkezésre állás (avaibality)
Igy a rendszer biztonságának megitélésénél figyelembe kell venni, hogy
mennyire véd meg a jogosulatlan hozzáférésektől, másodsorban mennyire tudja
garantálni az adatok helyességét, integritását, s harmadsorban mennyire
megbízható a rendszer működése. E szempontok együttese ad igazán mérvadó
jellemzést a biztonság fokáról.
Az említett három szemponthoz az igen különböző problémakör miatt
különböző megoldási módszerek kapcsolódnak. Mi most figyelmünket a
hozzáférés védelem kérdésére fordítjuk, s a biztonság másik két szintjére nem
fogunk kitérni. E szempontokkal azonban korábban már foglalkoztunk, hiszen
szó esett a recovery és tranzakció kezelési mechanizmusról, melyek legalábbis
részben biztosítják az RDBMS rendszerek megbízható működését. Az
integritásőrzés kezelésére vonatkozó eszközökből pedig már érintettük többek
között az integritási feltételek és a triggerek mechanizmusait.
A hozzáférés védelem önmagában is egy igen széles területet ölel fel. Számos
olyan ága van, melyek mindegyike különálló ágat képvisel. A hozzáférés
védelem ugyanis sokkal több dolgot rejt magában, mint egy egyszerű
engedélyezés-tiltás mechanizmus, melyben az igénylő és az igényelt objektum
azonosító számainak függvényében vagy engedélyezzük a hozzáférést, vagy
pedig letiltjuk a hozzáférést. Ugyanis mind a hozzáférés módjainak, mind pedig
a tiltás módjainak számos árnyalata létezik, melyek teszik igazán tarkává és
igazán érdekessé a képet.
A lehetséges védelmi mechanizmusok között természetesen első rendű
fontosságot a hozzéférési jogosultság ellenőrzése (access control) áll. E
mechanizmus feladata, hogy adott igénylő és igényelt objektum esetén
eldöntse, hogy engedélyezhető-e az igényelt hozzáférési mód vagy sem. Az
engedélyezésnek számos változata, módszere lehet, melyekre e fejezetben
részletesen is ki fogunk térni. A gyakorlatban mi magunk is a bőrünkön
érezhetjük e mechanizmus működését, amikor egy másik felhasználó tábláit
szeretnénk például olvasni, s a rendszer nem hajtja végre az olvasást, ehlyett
visszautasítja ezirányú parancsunkat.
Ugyancsak lényeges és szintén közismert eleme a védelemnek a bejelentkezési
mechanizmuis, amikor is egy név és egy jelszó segítségével közöljük a
rendszerrel, hogy jogosult helhasználók vagyunk. E mechanizmus az
azonosítási mechanizmus (identification). Az RDBMS rendszerek a jelszavak
tárolására és ellenőrzésére hasonló mechanizmust használ, mint az operációs
rendszerek, azaz egy egyutas hash függvényt meghívva kódolja a megadott
jelszót. Az egyutas elnevezés arra utal, hogy a kódolt alakból már nem lehet
visszakövetekeztetni (legalábbis hatékony algoritmussal) az eredeti jelszóra. A
bejelentkezéskor a bejelentkezéskor megadott jelszót előbb kódolják, s a kapott
kódolt alakot hasonlítják össze a letárolt alakkal. Ha a két kódolt alak
megegyezik, akkor a helyesnek tekinthető a bevitt jelszó. A kódolt jelszavak
tárolása az RDBMS esetében rendszer táblában történik, melyhez azonban
normál felhasználónak még olvasási jogosultsága sem létezik.
Egy igen érdekes védelmi elem a következtetési lehetőségek kizárásának
mechanizmusa (inference control). Ez a mechanizmus azt kívánja
megakadályozni, hogy jogosult adatok alapján ne lehessen nem jogosult
adatokra következtetni. Erre a veszélyre adhatunk egy olyan példát, amelyben
az adattábla legyen a dolgozók táblája, s a felhasználó nem olvashatja az egyes
rekordokat, de feltehet aggregációs lekérdezéseket. Normál esetben összesített
adatokból nem lehet az egyedi értékekre közvetkeztetni, de ha például csak
egyetlen rekord szerepel az aggregációs alaphalmazban, akkor máris egyedi
értékekhez jutott a felhasználó. Ugyancsak fontos információk nyerhetők ki a
rendszer által küldött hibaüzenetek alakjából is, hiszen nem ugyanazt jelenti a
felhasználó számára, ha egy hivatkozás például azért nem sikerült, mert az
objektum nem létezik, mintha a védelmi korlátokra utal a hibaüzenet. Ez utóbbi
esetben már az objektum létezésére lehet következtetni.
A következtetések megnehezítésére számos megoldási javaslatot dolgoztak ki,
melyek vonatkoznak az aggregációs eredmények ellenőrzésére, így például egy
megadot egyedszám alatt nem lehet aggregációs lekérdezést hívni. Egyes
javaslatok az egyedi értékek perturbálásán, zavarásán alapulnak, így a kapott
egyedi értékek nem a valós értékeknek, hanem olyan generált értékeknek
felelnek meg, amelyek összességüket tekintve hasonlóan viselkednek az eredeti
egyedhalmazhoz. A következtetések megnehezítésének egymásik módszere a
hibaüzenetek szándékosan kétértelművé tétele (amellyel valóban találkozhatunk
is a kipróbált RDBMS rendszerekben).
A kipróbált védelmi mechanizmusok közé tartozik még a titkosítás módszere
(cryptography). Ebben az esetben nem a hozzéférést, hanem az olvasott adatok
megértését kívánják megakadályozni. A titkosításnak is számos változata van,
kezde a DES blokk-kódolástól az FSR, RSA, stb. kódolási algoritmusokig. E
területnek önmagábanis igen széles irodalma, háttere van. A titkosítás
lehetőségét gyakran alkalmazzák olyan adatrendszerek is, amlyekben az
operációs rendszer nem biztosítja a megfelelő védelmi hátteret.
Az adatáramlás ellenőrzés (data flow control) feladata az felhasználóhoz kerülő
és onnan továbbjutó adatok áramlásának ellenőrzése. Természetesen ez igen
nehezen ellenőrizhető, hiszen vannak olyan csatornák is, melyek kikerülik az
RDBMS ellenőrzési rendszerét, például szóbeli közlés formájában. A
mechanizmus inkább arra készült, hogy véletlenül, esetleg gondatlanságból az
RDBMS-t felhasználva ne tudjon egy felhasználó bizalmas információt
jogosulatlan felhaszálók felé továbbítani.
A védelemi módszerekhez sorolható még az naplózás (audit) rendszere, amely
ugyan közvetlenül nem alkalmas a hozzáférés megakadályozására, de az
utólagos ellenőrzések miatt elrettentő, s később bizonyító hatása van. A
naplózás jelentős helyigénye miatt e lehetőséget csak igen szűk felhasználói
körnek szokták engedélyezni.
A legfontosabb védelmi mechanizmusok közé tehát a
- bejelentkezés ellenőrzés, identification, login account
- hozzáférés ellenőrzés, access control
- következtetési ellenőrzés, inference control
- adatáramlás ellenőrzés, flow control
- titkosítás, cryptologhy
- naplózás, audit
elemek sorolhatók. E mechanizmusok rendszerint együtt, egymáshoz
kapcsolódóan jelennek meg az RDBMS védelmi rendszerében. A védelmi
rendszer a kiépítettségtől függően néhány vagy éppen mindegyik elemét
tartalmazza a fenti listának. E rendszerek együttesen gondoskodnak a
hozzáférési védelem biztosításáról.
A fenti elemekből kiépülő védelmi rendszerek általános felépítését mutatja be a
következő ábra.
Ezen ábra azt mutatja, hogy a védelmi rendszer a felhaszálók és az erőforrások
között helyekzedik el és szerepe a hozzáférések ellenőrzése. A védelmi
rendszeren belül különböző védelmi mechanizmusok kerülnek megvalósításra,
melyek együttesen valósítják meg az RDBMS védelmét. Az egyes
mechanizmusokhoz kapcsolódik egy algoritmus rész (védelmi módszer), amely
leírja a mechanizmus működését (mikor mit kell tenni), illetve társul hozzá egy
védelmi adatrendszer is, mely az objektumok, felhasználók jogosultási adatait
tartalmazza. A védelmi módszerek ezen jogosultsági adatok alapján döntik el,
hogy egy konkrét hozzáférési igény teljesíthető-e vagy sem.
A védelmi rendszer több, különböző funkciójú védelmi módszert is
tartalmazhat. A módszerek kiválasztásához szükséges egy irányító elv, amit
védelmi stratégiának neveznek. Ezen elv határozza meg, hogy mire kell ügyelni
a védelmi rendszernek, mi legyen a védelmi rendszer célja. A stratégia alapján
már kiválaszthatók a stratégiát megvalósító mechanizmusok.
Az RDBMS rendszerek alapvetően kétféle fő stratégiai alapirány valamelyikét
valósítják meg, illetve vannak bizonyos rendszerek, melyek mindkét
alapirányhoz tartozó mechanizmusokat megvalósítják rendszereikben védelem
maximális teljesítőképessége érdekében.
Az egyik fő irány a diszkrecionális, decentralizált védelmi stratégia (DAC,
discretionary access control). Ennek jellemzője, hogy a védelmi adatok
kezelése decentralizáltan történik. Ílyen stratégián alapul az operációs
rendszerek ismert állományvédelmi mechanizmusa is, melyben minden
objektumnak és felhasználónak egyedi azonosító kóddal kell rendelkeznie, s az
objektumhoz való hozzáférést alapvetően az objektum tulajdonosa, az
objektumot létrehozó személy határozza meg. Ebben a rendszerben az
objektum tulajdonosa adományozhat illetve vonhat meg hozzáférési jogokat
más személyektől.
E rendszer előnye, hogy nem szükséges központi nyilvántartás a védelmi
adatokról, s nincs szükség központi ellenőrzésre sem az objektumok fölött. A
tulajdonos határozhatja meg, hogy mely felhasználók férhetnek hozzá az
objektumothoz, azaz a tulajdonmos felelősége az adatok megfelelő védelmi
szinten való megőrzése. Ez a nagyfokú szabadság azonban bizonyos esetekben
már a biztonság rovására mehet, ezért kidolgoztak egy másik startégiai modellt
is a szigorúbb követelmények teljesítéséhez.
A másik alapvető stratégia a kötelező jellegű, központi irányítású védelmi
rendszerhez tartozik (MAC, mandatory access control). Ebben a stratégiában
egy központi menedzser felügyeli a kötelező jellegű védelmi kódokat. Minden
egyed és az objektum védelmi kódját egyetlen központi helyről határozzák
meg. A hozzáférés engedélyezése itt is az objektum és a kérelmező védelmi
kódjainak alapján dől el, azonban itt egy kifinomultabb védelmi adatszerkezetet
hoztak létre, melyben finomabban lehet mind a felhasználókat, mind az
objektumokat osztályozni.
A MAC rendszer előnye, hogy a központi irányításból következően sokkal
jobban ellenőrizhető az adathozzáférés, és az adatáramlás is. A MAC előnye
még a strukturáltabb védelmi kódok is. A hártányok közé viszont a valamivel
nagyobb erőforrásigény sorolható, hiszen több információt, részletesebb
információt kell tárolni az objektumokről, s személyekről. A MAC
rendszereket rendszerint a nagyobb védelmi igényű helyeken, mint a hadiipar,
kormányzás alkalmazzák.
A DAC modell
A DAC modell jellemzője, hogy minden objektumhoz külön feljegyzésre kerül,
hogy mely felhasználók férhetnek hozzá. A hozzáférésnek rendszerint több
tipusát különböztetjük meg, ami utal arra, hogy milyen tevékenységet kíván a
felhasználó az objektumon végrehajtani. A leggyakoribb hozzáférési
módozatok: olvasás (r), írás(w) és végrehajtás (x). Az objektumok és a
felhasználók kapcsolatát egy hozzáférési mátrix-szal szokás reprezentálni.
A hozzáférési mátrix (access-matrix) oszlopai az egyes objektumoknak, míg
sorai az egyes felhasználóknak felelnek meg. A mátrix cellái az engedélyezett
műveleteket tartalmazza. Így a védelmi mechanizmus csak azon hozzáférési
módor engedélyezi, amely szerepel az érintett objektum és felhasználó
pároshoz tartozó cellában.
Az egyes védelmi módszerek különbözhetnek egymástól abban, hogy hogyan
kezeli a különböző felhasználókat és milyen bejegyzések szerepelhetnek a
cellában. A legegyszerűbb esetekben, mint például az ismert UNIX operációs
rendszer állomány védelmi rendszerében is, a felhasználókat nem egyénileg
azonosítják az objektumoknál, hanem csoportokba válogatják őket, s e
csoportok minden tagjához ugyanzazt a védelmi szintet rendelik. A UNIX
esetén például a felhasználókat, objektumokat egy (csoportszám, tagszám)
párossal azonosítják, ahol az objektumok felveszik az őket létrehozó
felhasználó kódját. Az objektum és a kérelmező felhasználó kódpárosa alapján
a kérelmező az alábbi három csoport valamelyikébe sorolható:
- tulajdonos, mind a csoporszám, mind a tagszám egyforma
- csoport, a csoportszám megegyezik
- külvilág, nem egyezik meg egyik kódszám sem
Így minden objektumnál e három csoportra vonatkozó jogosultságok
szerepelnek, s nincs lehetőség egyedi felhasználókra vonatkozó jogok
megadására. Ezzel sokkal egyszerűbbé válik a jogosultságok kezelése, viszont
kevésbé rugalmas lesz a védelmi rendszer.
A rugalmasságot növeli, ha bármely objektum esetén lehetőség van az egyes
felhasználókra külön-külön is megadni és szabályozni a jogosultságokat. Ebben
az esetben az access-matrix terjedelmesebb felépítésű lesz, hiszen egy egyedhez
minden felhasználóra külön megadhatjuk az engedélyezett jogosultságokat. Egy
ilyen jellegű védelmi rendszert tapasztalhattunk meg például a VMS ACL
rendszerében is.
Az operációs rendszerek esetén az egyes cellákban az engedélyezett műveletek
felsorolása található. Bármely kérelem esetén akkor és csak akkor
engedélyezett a művelet, ha az e listában szerepel. Az engedélyezett
műveletlista meghatározása alapvetően az objektum tulajdonosának a feladata,
de az adminsztráció megkönnyítésére létezik egy alapértelmezési jogosultsági
kör is minden felhasználó esetén.
Az RDBMS rendszerek rendszerint az Access matrix alapmodellen alapuló
mechanizmust használják. Ennek fő jellemzője, hogy részletes szabályozáson
alapul, azaz minden objektum és minden felhasználó párosa esetén lehetőség
van a jogosultsági kör meghatározására. Az alapmodell másik jellemzője, hogy
a cellák nem csak egy műveletlistát tartalmaznak, hanem a műveletek mellett
egy feltétel is állhat, mely leszűkíti az engedélyezés lehetőségét. Azaz egy
adott kérelem esetén a kért művelet csak akkor engedélyezett, ha egyrészt a
művelet benne van a listában és másrészt teljesül a cellában megadott feltétel is.
Így például egy olvasási jog leszűkíthető a délelőtti órákra (azaz délután már
nem olvashatja a felhasználó az objektumot), vagy megadott terminálokra.
A normál Oracle RDBMS is DAC alapokon nyugszik. Mint már az SQL
nyelvben tapasztaltuk, az engedélyezhető műveletek köre más, mint a szokásos
írás-olvasás-végrehajtás elemek, s az elvégezhető SQL adatkezelő és
adatdefiníciós műveleteken alapulnak. Másrészt azt is figyelembe kell venni,
hogy az RDBMS egymástól igen eltérő objektumokat tartalmaz, melyekhez
eltérő műveleti lehetőségek csatlakoznak. Így például egy SEQUENCE
objektum sokkal korlátozottabb lehetőségeket adhat, mint egy TABLE
objektum, hiszen a SEQUENCE nem bővíthető, indexelhető, stb. A következő
táblázat az egyes elvégezhető, s jogosultságként megadható műveleteket
mutatja az egyes objektumtipusok esetén.
table view sequence
ALTER X X
DELETE X X
INDEX X
INSERT X X
REFERENCES X
SELECT X X X
UPDATE X X
Az egyes műveletek rövid értelmezése:
- ALTER: az objektum struktúrájának módosíthatósága
- DELETE: az objektum egyes elemeinek törlése
- INDEX: index létrehozása az obejktumhoz
- INSERT: új érték beszúrása az obejktumba
- REFERENCES: idegen kulcs hivatkozhat-e az obejktumra
- SELECT: az objektumban tárolt értékek lekérdezése
- UPDATE: az objektumban tárolt értékek módosítása
A fentebb felsorolt műveletek mellett egyes speciális objektum tipusokhoz még
más műveletek is köthetők, így például a tárolt eljárások esetén a végrehajtási
jogosultság is értelmezhető.
Az objektumoknak itt is van egy tulajdonosa, az objektumot létrehozó
felhasználó. A tulajdonos teljes hozzáférési jogkörrel rendelkezik az
objektumhoz. Más felhasználók alapesetben semmilyen hozzáférési jogot nem
kapnak. Ahhoz, hogy az obejktumhoz más felhasználó is hozzáférjen, a
tulajdonosnak engedélyeznie kell a műveletet. Az egyes jogok megadásának
utasítása:
GRANT jog ON obj. TO felh. [WITH GRANT OPTION]
ahol jog a listában felsorolt jogosultásogat (ALTER, DELETE, INDEX,...)
jelenti. A obj szimbólum az érintett obejktumra, a felh. rövidítés pedig a
felhasználóra vonatkozik. Az opcionális WITH GRANT OPTION tag
megadásakor az átadott hozzáférési jogkört az adományozott felhasználó
továbbadhatja más felhasználóknak. Ezzel mintegy ideiglenesen lemondunk az
objektum ezirányú ellenőrzéséről, hiszen tetszőleges helyekre is elkerülhet a
jogosultság. Ha felhasználó azonosítóként a PUBLIC lucsszót adjuk meg, akkor
a rendszer minden felhasználója megkapja a kijelölt hozzáférési jogot.
Az adományozott jogokat a
REVOKE jog ON obj. FROM felh.
utasítással vonhatjuk vissza, melyben a paraméterek jelentése hasonló a
GRANT utasítás paraméterezésével. Igy ha a felhasználó helyén a PUBLIC
szerepel, akkor minden felhasználótól visszavonsára kerül az adományozott
jogkör.
Ha tahát egy új KONYV táblát olvashatóvá akarjuk tenni a PETER felhasználó
számára, akkor ahhoz a
GRANT SELECT ON KONYV TO PETER;
utasítást kell kiadni.Ha később vissza kívánjuk vonni az olvasási jogot minden
felhasználótól, akkor a
REVOKE SELECT ON KONYV FROM PUBLIC;
megflelő utasítás.
Az obejktumokra vonatkozó jogosultásgok mellett az RDBMS-ben léteznek
úgynvezett rendszer privilégiumok is. A rendszerprivilégium művelet
csoportra vonatkozik, függetlenül az érintett objektumoktól. Ha egy felhasználó
rendelkezik például egy DELETE ANY TABLE privilégiummal, akkor az
illető a rendszer bármely táblájából, annak bármely rekordját törölheti. A
rendszerprivilégium tehát bármely objektumra engedélyezi a kijelölt műveletet.
Az Oracle rendszerben mintegy száz rendszer privilégium értelmezett, mint
például
CREATE SESSION: hozzáférés az adatbázishoz
CREATE TABLE: tábla létrehozásának joga a saját sémában
CREATE ANY TABLE: tábla létrehozása bármely sémában
Az rendszer jellemzője, hogy egy új felhasználó alapesetben semmilyen
jogkörrel nem rendelkezik, így például még bejelentkezéshez, egy session
létrehozásához sincs jogosultsága. A rendszergazdának külön meg kell adni
minden illeszkedő jogkört. A rendszerprivilégiumok megadásának formátuma
hasonló az objekt jogok kezeléséhez.
A rendszer privilégium adományozása a
GRANT jog ON obj. TO felh. [WITH ADMIN OPTION]
utasítással történik, ahol a WITH ADMIN OPTION azt jelenti, hogy az
adományozott továbbadhatja a kapott rendszer privilégiumot. A privilégium
visszavonása a
REVOKE jog ON obj. FROM felh.
utasítáásal lehetséges.
Az adományozott objektum jogokat és privilégiumokat az RDBMS egy
rendsertáblában tárolja, melynek egy,a felhasználót érintő részletéről bármely
felhasználó információt kaphat. A kapott jogokat tehát egy rendszer view
lekérdezésével lehet kilistáztatni. A két rendszer view azonosítója:
USER_COL_PRIVS: objektum jogok
USER_SYS_PRIVS: rendszer privilégiumok
Így a kapott privilégiumokat a
SELECT * FROM USER_SYS_PRIVS;
utasítással kérdezhetjük le.
Mint láttuk minden szükséges privilégiumot és tábla jogot külön adományozni
kell a felhasználókhoz. Ez igen időigényes és nagy körültekintést igénylő
feladat, hiszen a rendszerben mintegy száz privilégium és több tucat objektum
jogkör is létezik. Mindehez még azt is hozzá kell venni, hogy a nagyobb IS
rendszerrek több száz felhasználót is nyilvántartanak. ezáltal igen könnyen
áttekinthetetlené válna a védelmi rendszer, ha nem vezetnének be valamilyen
segédeszközt a nyilvántartást megkönnyítésére. Egy ilyen segédeszközt
mutatunk bve most, az úgynevezett szerepkör mechanizmust.
A szerepkör (role) egy átmenetet képez a felhasználók és a jogkörök,
privilégiumok között. Első közelítésben a szerepkör egy privélégium, jogkör
halmaz, együttes, amelyet a felhasnálókhoz lehet hozzárendelni. A szerepkör
adományozása után a felhasználó rendelkezni fog mindazon objektum jogokkal
és rendszer privilégiumokkal, amiket a szerepkör tartalmaz. A szerepkör
visszavonásakor a tartalmazott jogosultásgok, privilégiumok is visszavonásra
kerülnek.
A szerepkör létrehozása az arra jogosult felhasználó által kiadott
CREATE ROLE szerep;
utasítással lehetséges, ahol a szerep egy tetszőleges új szerepazonosítót jelent.
A későbbiekben a létrehozott szerep a
DROP ROLE szerep;
utasítással szüntethető meg. A szerepkörhöz, mely induláskor üres, a
GRANT jog ON obj. TO szerep;
utasítással rendelhetünk hozzá jogosultságokat és privilégiumokat. Tehát itt a
szerep formálisan mint felhasználó szerepel. Egy szerephez egymásután több
különböző privilégium és jogkör is rendelhető.
A szerephez rendelt jogosultásgokból, privilégiumokból a
REVOKE jog ON obj. FROM szerep;
utasítással lehet egyes elemeket kivenni. A létrehozott szerepeket több
különböző felhasználóhóz is hozzá lehet rendelni. A szerep adományása a
GRANT szerep TO felh.;
míg a visszavonása a
REVOKE szerep. FROM felh.
paranccsal történik.
A szerepkör mechanizmus rugalmasságát növeli, hogy a szerepkörök
egymáshoz is rendelhetők, azaz egy szerepkörhöz hozzárendelehtő egy másik
szerepkör által tartalamzott jogosultások is a a
GRANT szerep1 TO szerep2;
utasítással. Eredménykét a szerep2 szerepkörhöz hozzáadód a szerep1
szerepkör, s általa mindazon jogosultságok, melyek a szerep1 tarlamaz. Így a
szerepek mintegy egymásba is ágyazhatók.
A következő ábra egy szerep hozzárendelési példát mutat be.
Az ábrán öt privilégium (vagy obejktum jogkör) szerepel, melyeket P1, P2, P3,
P4 és P5 szimbólumokkal jelöltünk. Emellett két szerepkör (R1, R2) valamint
két felhasználó, U1 és U2 látható még a példában. Az U1 felhasználó a P1, P2,
P3, P4 privilégiumokkal, míg az U2 felhasználó a P1, P2, P3, P5
privilégiumokkal rendelkezik. A R1 szrepkör a P1, P2 és P3 privilégiumoikat
foglalja magába, s az R2 pedig az P4 valamint az R1-en keresztül a P1, P2, P3
privilégiumokat foglalja össze. A fenti szerkezetet, létező felhasználók mellet,
az alábbi utasítás sorozattal lehet előállítani:
CREATE ROLE R1;
CREATE ROLE R2;
GRANT P1 TO R1;
GRANT P2 TO R1;
GRANT P3 TO R1;
GRANT R1 TO R2;
GRANT P4 TO R2;
GRANT R2 TO U1;
GRANT R1 TO U2;
GRANT P5 TO U2;
A kapott szerepek alapesetben a bejelentkezés után közvetlenül már élnek: Van
azonban arra is lehetőség, hogy a szerepet a felhasználó ne közvetlenül kapja
meg, hanem külön, expilicte kérnie kell a szerep felvételeét. Az ilyen
szerepeket opcionális szerepeknek nevezik. Az opcionális szerep jelentősége
abban áll, hogy a szerephez egy egyedi jelszót lehet kapcsolni, így csak akkor
veheti fel a felhasználó a szerepet, ha meg tudja adni a szerephez tartozó jelszót
is. Egy opcionális szerep létrehozása három lépésben megy végbe. Elsőként a
CREATE ROLE szerep [IDENTIFIED BY jelszo];
uatsítással kiadásával új szerepet hozunk létre, melyhez jelszó is
kapcsolódhat.A jelszó megadása nem kötelező. Ezután a szerepet
hozzárendeljük a szerepet a felhasználóhoz a
GRANT szerep TO felh.;
utasítással, mely így default, vagyis a bejelentkezés után rögtön élő szereppé
válik. Az opcionális szerepet a felhasználó jogosultsági adatainak
módosításával lehet beállítani:
ALTER USER felh. DEFAULT ROLE kif.;.
A fenti utasítás a default szerepek beállítására szolgál. Minden olyan szerep,
ami nem esik bele a kif. hatáskörébe, átmegy opcionális szerepbe. A kif. helyén
több különböző módon is megadható a szerepkijelölés. Így többek között
használhatók a
ALL: minden szerep
NONE: egyik sem
ALL EXCEPT szereplista: minden szerep a lista elemeinek kivételével
kifefezések is.
Az opcionális szerepek felvételélét ezután a felhasználónak külön paranccsal
kell kérnie, melynek alakja
SET ROLE szerep [IDENTIFIED BY jelszo];
A jelszóval védett szerep esetén a jelszó megadása kötelző. A felvett szerepeket
a
SET ROLE NONE
utasítással lehet leadni. Az opcionális szerep különben a session végéig él.
A szerepek jelentősége abban áll, hogy áttekinthetőbbé teszik a védelmi jogok
adminisztrálását, könnyebb és gyorsabb velük dolgozni. Az opcionális szerepek
lehetőséget adnak ideiglenes, korlátozott idejű jogosultságok biztosítására.
Ennek egyik gyakorlati megvalósítása az, amikor egy program, amelynek egy
adott felhasználóként be kell jelentkeznie az RDBMS-hez, hogy elérje az
adatbázisban tárolt adatokat, a futás bizonyos szakaszaira vesz fel opcionális
jogokat, érzékenyebb információk elérésére. Ezen óvatosság oka az, hogy a
bejelentkezési név és jelszó viszonylag könnyen kideríthető bárki számára, de a
programban kódolt szerep jelszó feltörése már sokkal nehezebb feladatot jelent
a kiváncsiskodóknak.
A DAC fejezet végén álljon itt egy rövid összefoglalás a fontosabb RDBMS
rendszerek védelmi lehetőségeinek összehasonlítására. A táblázat első
oszlopában azon termékeknél áll X jel, amelyek saját felhasználó azonosítással
rendelkeznek, azaz a session kiépítése előtt az RDBMS felé is igazonli kell
magiűunkat. A táblázat második oszlopa azt mutatja, hogy az RDBMS fel
tudja-e használni a operációs rendszer által biztosított azonosítási
mechanizmust, azaz ha egyszer már bejelentkeztünk az operációs rendszerbe,
nincs szükség külön bejelentkezésre az RDBMS felé. A harmadik és negyedik
oszlop azt mutatja, hogy a védelmi jogkörök az adakezelő és a adatdefiníciós
uatsításookra kiterjednek-e. A utólsó előtti oszlopban ott került x a riblikába,
ameléy rendszerek támogatják a szerepkör mechanizmust, míg az utólsó
oszlopban a naplózási rendszerrel rendelkező RDBMS rendszerek kaptak X
jelet.
user OS DML DDL roles audit
pwd pwd
Ingres X X X X X
Oracle X X X X X X
Sybase X X X
Informix X X X
A MAC modell
Olyan információs rendszerekben, melyeknek szigorúbb védelmi előirásoknak
kell eleget tenniük, a DAC mechanizmus nem biztosít kellő biztonságot. A
decentralizáltság miatt az információk tetszőleges áramolhatnak, nagyobb a
veszélye annak, hogy jogosulatlan adatok olyanokhoz is lejuthatnak a RDBMS-
en keresztül, akiknek erre a rendszer alapkoncepciója szerint nem lenne
jogosultságuk. A szigorúbb feltételek kielégítésére alkották meg a MAC alapú
védelmi rendszereket.
A MAC rendszerben egységesen történik a hozzáférések szabályozása. Minden
objektum és felhasználó kap egy titkossági kódot. A titkosági kód két elemből
áll, egy terület jelző és titkossági szintből:
L = (S,A)
ahol
S: titkosság szintje (pl. Unclassified, Classified, Secret, TopSecret)
A: terület kiejölése (pl. NATO, ME)
A titkossági szintek között egy szigorúsági relációt lehet felállítani:
U (unclassified) < C (calssified) < S (secret) < TS (topsecret)
A területek között pedig egy tartalmazási reláció létesíthető, vagyis az egyik
területkód magába foglalhat egy másik területkódot. A terület jelölésére
rendserrint bevezetnek elemi területjelöléseket, mint pl. bérügy, munkaügy, stb.
S a terület kódját az oda tartozó elemi területek listájával adják meg (pl.
{bérügy, pénzügy}). Az obejktum esetén a titkossági szint azt jelzi, hogy
mennyire tekinthető titkosnak az adatot adat, míg a felhasználó esetén a
titkossági szint arra utal, hogy a felhasználó milyen titkossági szintű
információkhoz férhet hozzá.
A jogosultások eldöntésénél az objektum és a felhasználó védelmi kódjainak
viszonya a meghatározó. Mégpedig akkor olvashatunk egy objektumot, ha a mi
titkossági szintük nagyobb vagy egyenlő, mint az adat titkosáági szintje és a
területünk is kiterjed az adat vonatkozási területére. A jogosultság formális
eldöntésére beveztjük a védelmi kódok közötti dominancia fogalmát.
A definíció szerint az L1 kódot dominálja az L2 kód, ha
L1 <= L2 akkor és csak akkor, ha S1 <= S2 és A1 részhalmaza
A2-nak
teljesül, azaz a titkosséági szint legalább olyan és a terület kód magába foglalja
a másik terület kódját. Könnyen belátható, hogy nem minden kódpár
hasonlítható össze, hiszen lehet olyan kódpár, melyben a S1 nagyobb, mint S2,
és A1 kisebb mint A2. Ezért a kódok halmaza csak részben rendezett a
dominancia relációra nézve (lattice).
A MAC védelmi stratégia bemutatásánál most csak háromféle absztarkt
műveletet fogunk venni, nem térve ki a konkrét művelet tipusokra, mivel ezen
műveletcsoportok egymástól elviekben eltérő kezelést igényelnek. Az
egymástól elkülönített műveletcsoportok:
- olvasás (R), csak olvasás, módosítás nélkül
- írás (W), amikor olvassuk és módosítjuk az adatelemet
- bővítés (A), amikor csak írhatunk új adatelemet
Az A és W módok elkülönítését az indokolja, hogy lehetnek olyan információk
melyeket egy személy felvihet, mivel az például az ő adatait jelenti, de az
általa, vagy mások által felvitt és egyazon védelmi szinten tárolt adatokat már
nem kérdezheti le az illető. Ekkor az A művelet él, de a W művelet nem
engedélyezett.
A MAC rendszerek rendszerint a felhasználókat két csoportba sorolja a
megbízhatóságuk alapján: megbízható (trusted) és nem megbízható (untrusted)
csoport. A trusted felhasználóknál a megbízhatóság azt jelenti, hogy az elért
információkat nem fogja kiszolgálgatni jogosulatlan személyek felé, míg az
untrusted személyeknél gondoskodni kell arról, hogy megakadályozzuk
amennyire csak lehet az adatok jogosulatlan személyekhez történő átadaását.
Emiatt a két felhasználócsoport kezelése is eltérő lesz.
Az untrusted felhasználók esetén a működési axiómák a következőkben
foglalható össze:
- untrusted felhasználó csak olyan erőforrást olvashat, melynek
dominálja a kódját
- untrusted felhasználó csak olyan erőforrást irhat, melynek kódja
megegyezik az ő kódjával
- untrusted felhasználó olyan erőforrást bővíthet, melynek kódja
dominálja az ő kódját
Az első tétel azt mondja ki, hogy csak a nem titkosabb és az illető területébe
eső adatokat lehet olvasni. A második tétel szerint csak azon adatok olvashatók
és módosíthatók, amelyeknek a titkossági szintje és a területkódja megegyezik
a felhasználó ezirányú adataival. A harmadik tétel azt jelzi,hogy egy
felhasználó csak olyan adatokat fűzhet be, melyek legalább olyan titkossági
szinten vannak, mint a felhasználó. Ennek oka, hogy a felhasználót
megakadályozzák abban, hogy a megszerzett információt átvigyék olyan
objektumokba, melyek titkossági szintje alacsonyabb az olvasott objektum
szintjétől. A megadott aximóma ettől még egy kicsit szigorúbban is viselkedik,
hiszen a felhasználótól alacsonyabb szintű obejktumok egyáltalán nem
módosíthatók.
A trusted felhasználók esetében annyiben módosul a működési elv, hogy nincs
megtiltva az alacsonyabb védelmi szintű objektumok módosítása.
- trusted felhasználó csak olyan erőforrást írhat és olvashat, melynek
dominálja a védelmi kódját
- trusted felhasználó olyan erőforrást bővíthet, melynek kódja dominálja
az ő kódját
Az elmondottak sazemléltetésére álljon itt egy mintarendszer, melyben négy
felhasználó és öt objektum szerepel. A felhasználók között feltüntettük a
dominencia relációkat, s megadtuk az S1, S4 felhasználóhoz tartozó hozzáférési
jogokat is.
A elemek alsó sorában a védelmi kód szerepel, előbb a toitkossági szint, majd a
pontosvessző után a területkód következik. A szagatott vonal a dominanicát
jelenti, míg a folytonos élű nyilakkal a olvasási, írási és hozzáfűzési
jogosultságokat jelöljük.
Az ábrában például S2 védelmi kódja dominálja S4 kódját, mivel
TS > C, azaz S2 > S4 és
{DB,OS,NW} tartalmazza {DB} -t, azaz A2 tartalmazza A4-t
és emiatt
L2 > L4
is teljesül. Az ábrában S4 olvashatja O5-öt, hiszen
LS4 > LO5
is teljesül. Az
LO1 > LS4
teljesüléséből pedig az következi, hogy S4 csak hozzáfűzhet adatokat az O1
objektumhoz.
A MAC modellek megvalósításnak egyik példája a trusted Oracle rendszer. A
trusted Oracle RDBMS-t a nagyobb védelmi igénnyel rendelkező információs
rendszerekben használják. A trusted Oracle tipikus alkalmazási területei a
kormányzati és katonai információs rendszerek.
A trusted Oracle RDBMS védelmi rendszere a SeaView modellen alapszik. A
SeView modell elsődlegesen a MAC stratégián alapszik, de vannak be
bizonyos újabb kiegészítések is és tartalmaz DAC elemeket is.
Az egyik legfontosabb újítás a standard MAC modellhez viszonyítva, hogy a
felhasználók és az objektumok is kapnak a már ismert védelmi kód mellett egy-
egy megbízhatósági, fontossági kódot is.
Mig a védelmi kódok az adatok titkosságát jelölte, addig a megbízhatósági kód
azt jelzi, hogy az adat mennyire tekinhető végleges, biztos adatnak. Az adatok
között lehetnek ugyanis olyan adatok, melyek már biztosak és széles körben
ismertek lehetnek, míg előfordulhatnak olyan adatok is, melyek nem teljesen
tekinthetők biztosnak, illetve még nem érettek a nyilvánosság számára. Így
például a cég multévi forgalma egy biztos, megbízható ada, míg az ezévre szóló
előrejelzések még bizonytalan adatnak tekinthető, melyet esetleg nem célszerű
még a szélesebb nyilvánosság elő tárni.
A : védelmi kód mellett szereplő megbízhatósági kód is hasonló formátumban
jelenik meg, mint a védelmi kód, azaz az objektumokhoz és felhasználókhoz
egy megbízhatósági szintből és egy területjelzőből álló kódpárt rendelnek,
melyet az I szimbólummal jelölnek. Vagyis
I = (C, A)
a megbízhatósági kód, melyben
C: a megbízhatóság, fontosság szintje (C teljesen megbízható, VI igen
megbízható, I kevéssé megbízható, U nem mmegbízható)
A: terület jelző, mely több terület együttese is lehet (pl. NATO, ME)
A megbízhatósági szintek között is értelmezhető egy megbízhatósági reláció,
mely szerint:
C > VI > I > U
A területjelzők között továbbra is értelmezhető a tartalmazási reláció. Egy
felhasználó esetén a megbízhatósági szint arra utal, hogy mennyire bízunk meg
a felhasználóban, mennyire lehet a számára a még bizonytalan információkat is
kiadni. A felhasználó esetén az U szint jelenti azt, hogy bármilyen szintű
információt olvashat.
A megbízhatóság esetén a domencia értelmezése megegyezik a védelmi
kódoknál alkalmazott értelmezéssel, vagyis
I1 <= I2 akkor és csak akkor, ha C1 <= C2 és A1
részhalmaza A2-nek
A megbízhatósági és a védelmi kódok együttesen jellemzik az objektum illetve
felhasználó védelmi helyzetét, s e két kódot együttesen hozzáférési osztálynak
nevezik. A hozzáférési osztály jelölése:
C= {L, I}
A hozzáférés jogosságának ellenőrzésénél itt is fontos szerepet kap az objektum
és a felhasználó hozzáférési osztályának viszonya. Az irányelv itt abban áll,
hogy a felhasználó csak a kevéssé titkos és a jobban megbízható adatokat
olvashassa. Ennek megfelelően itt is bevezetünk egy osztályok közötti
dominancia relációt. A C1 * C2 jelenti azt, hogy C2 dominálja C1-et. A
dominencia értelmezése:
C1 <= C2 akkor és csak akkor,ha L1 <= L2 és I1 >= I2
Vagyis az L2 dominálja L1-et, míg a megbízhatóságnál az I1 dominálja I2-t. Az
irányeltérés oka, hogy stratégia alapján a felhasználó a kevesbé titkos, de
nagyobb mértékben megbízható adatokhoz férhet hozzá.
A másik lényeges eltérés a hagyományos MAC modellhez képest, hogy amíg a
MAC modellben egy adott felhasználó esetén az olvasási és a hozzáfűzési
tartomány egymással érintkezik, azaz közös a határuk, addig a SeaView
modellben e két tartomány bizonyos értelemben átfedheti egymást.
Az olvasási és írási jogok finomítására minden felhasználó kap egy Lmin, egy
Lmax , egy Imin, és egy Imax kódot. Ezen kódokból képeznek egy olvasási és
egy írási hozzáférési osztályt. A hozzáférési osztály:
CR= {Lmax, Imin}
míg az írási osztály a
CW= {Lmin, Imax}
alakban adott. A modell feltevése szerint az olvasási osztálynak dominálni kell
az írási osztályt. Ez azért szükséges, hogy ne legyen hézag a két osztáy között,
hanem legyen egy olyan szint, melyet a felhasználó úgymond magáénak
mondhat, ahol teljes jogkörrel rendelkezik.
A SeaView modell legfontosabb működési axiómái a következőkben foglalható
össze:
- Egy s felhasználó csak azon o erőforrást olvashatja, melynek elérési
osztályát a felhasználó olvasási osztálya dominálja
CR(s) * C(o)
- Egy s felhasználó csak azon o erőforrást bővítheti, melynek elérési
osztálya dominálja a felhasználó írási osztályát
CW(s) * C(o)
Az első axióma azt a már érintett elvet rögzírti, hogy a felhasználó csak olyan
adatokat olvashat, melyek kevésbé vagy olyan titkosak, mint az ő szintje, de
megbízhatóbbak vagy olyan ,megbízhatóak, mint az ő szintje.
A második axióma azt mondja ki, hogy a felhasználó csak olyan adatokat írhat,
melyek titkosabbak vagy olyan titkosak, mint az ő szintje, és nem
megbízhatóbbak, mint a felhasználó megbízhatósági szintje. Az előző
axiómákból az is következik, hogy módosítás, az adatok olvasása és írása csak
a felhasználóval azonos szintű objektumoknál lehetséges.
Az elmondottak illusztrálására vegyük az alábbi példát,melyben egy
felhasználó egy négy objektum foglal helyet. A felhasználó (S1) esetén a felső
sor az olvasási osztályt, míg az alsó sor az írási osztélyt jelöli. Az ábrában
feltüntettük, hogy a felhasználónak mely objektumokhoz milyen hozzáférési
jogai vannak.
Az S1 olvashatja és írhatja is az O1 objektumot, mivel S1 olvasási osztálya
dominálja O1 osztályát, míg az Objektum osztálya pedig dominálja S1 írási
osztályát. Az S1 az O3-at csak olvashatja, mivel S1 olvasási osztálya ugyan
dominálja O3 osztályát, de az O3 osztálya már nem dominálja S1 írási osztályát
(hiszen kisebb a titkossági szintje). Az O5 obejktumot S1 csak írni tudja, hiszen
S1 olvasási osztálya nem dominálja O5 osztályát (kisebb titkossági szint),
viszont O5 osztálya dominálja S1 írási osztályát.Az O2 objektum sem nem
olvasható, mivel O2 titkosági szintje nagyobb S2 olvasási szintjénél, sem nem
írható, mivel O2 megbízhatósági szintje nagyobb S2 szintjénél.
A SeaView modellben a fentemlített elemeken kívül még számos érdekes
vonást is tartalmaz. A SeaView alapú RDBMS rendszerekben a védelem szintje
is sokkal finomabb, mint a hagyományos RDBMS rendszerekben. Így a
védelembe bevont objektumok nemcsak a táblák lesznek, hanem az annál
kisebb egységek lesznek. Ez az egység az adatmező. Azaz a tábla minden
sorának minden mezője egy egyedi védelmi kódot kap. Az eggyszerűség végett
a továbbiakban csak a titkossági szintjelzőret fogunk hivatkozni a példákban.
A mező szintű védelem egyik következménye a többszintű, azaz multi-level
táblák megjelenése. Ez a jelenség arra utal, hogy a különböző felhasználók
másképp látják, másnak látják ugyanazt a táblát.
Ennek oka, hogy a mezőben tárolt adatok titkossági szintje más és más lehet.
Így egy adott felhasználó esetén a felhasználó védelmi kódja dönti el, hogy mit
is kap eredményül. A felhasználó csak azon mezőértékeket fogja látni, melyek
kódját a felhasználó kódja dominálja.
Vegyük például az alábbi táblát, az ábrában a mezők melletti oszlop
tartalmazza a mező védelmi szintjét, míg az utólső oszlop a rekordhoz tartozó
védelmi szintet jelöli. Az utólsó oszlop azt jelenti, hogy a teljes rekodnak mely
szinten kell elősször megjelennie. Ez megegyezik az egyes mező szintek
legnagyobb értékével.
név kor oszt fiz
-----------------------------------------------------------------
Jani C 45 S b1 S 34 C S
-----------------------------------------------------------------
Ica U 23 S b1 U 12 C S
-----------------------------------------------------------------
Tom S 24 S b3 S 56 TS TS
-----------------------------------------------------------------
A fenti táblát lekérdezve egy TS szinttel rendelkező felhasználó a tábla minden
rekodját és minden mezőjét látni fogja, hiszen a TS szint, minden más szintet
dominál. Az eredménytábla a következő lesz:
név kor oszt fiz
---------------------------
Jani 45 b1 34
---------------------------
Ica 23 b1 12
---------------------------
Tom 24 b3 56
---------------------------
Egy C védelmi kóddal rendelkező felhasználók viszont csak a C és U titkosságú
adatokat fogja látni, a többi heluyen NULL értékeket kap vissza, így a
lekérdezés eredménye az alábbi tábla lesz. Az utólső rekord nem is
látható,.mivel szintje nagyobb a felhasználó védelmi szintjétől.
név kor oszt fiz
---------------------------
Jani NULL NULL 34
---------------------------
Ica NULL b1 12
---------------------------
A különböző védelmi kódok miatt ugyanaz az objektum több különböző szinten
létezik, mindegyiken saját nézettel. E nézetek között azonabn létezik egyfajta
szabályszerűség, miszerint egy adott mezőérték valamely szint alatt NULL,
azaz üres értéket mutat, míg e szint felett a valóságos értéket mutatja
mindenkinek. E mutatott érték minden jogosult felhasználó esetén a táblában
szereplő valódi érték. Ebből azt a következtetést vonhatnánk le, hogy két
jogosult felhasználó ugyanazt az értéket fogja látni. A valóságban azonban ez
nem mindíg biztosítható, mint azt a következőkben be is fogjuk mutatni.
A jelenséghez abból a természetesnek tűnő kérdésből kell kiindulni, hogy vajon
mi dönti el, hogy egy objektum védelmi szintje milyen legyen. Az nagyon
valószínűtlennek tűnik, hogy egy központi menedzser minden mezőértékre
előír egy védelmi szintet. Ez egy átláthatatlan, reménytelen feladat lenne.
Emiatt itt is abban kell gondolkoznunk, hogy az objektum létrehozójának
védelmi szintje fog az objektumhoz kapcsolódni.
Ezen feltétel mellett vegyük egy olyan adatelemet, melynek titkossági szintje
mondjuk C. Ez az adatelem egy U szintű felhasználónál NULL értékként
jelenik meg. Az SeaView modellen alapuló RDBMS rendszernek is hasonló
képet kell mutatnia a felhasználó számára mint a hagyományos RDBMS
rendszereknek. Ezért amikor az U jogosultságú felhasználó a táblában át
kívánja írni a mező értékét, meg kell engedni neki. Ekkor tulajdonképpen a
tábla U szintű nézete változik meg, mely egyben a magasabb szintű nézetekben
is meg fog jelenni.
A problémát az okozza, hogy a magasabb C szinten már volt korábban is érték
az adatelemben. Az a megoldás, hogy a C szintű érték átíródjon nem tűnik
célszerűnek, hiszen ezáltal lentről beleavatkoznának a magasabb szinten
elvégzett tevékenységekbe. A működési axiómák pedig csak az új adatok
beszúrására vonatkoznak, s a nem a régi adatok felülírására. Emiatt a magasabb
szintű nézetekben az adatok nem átíródnak, hanem bővülnek. Ez azt is jelenti,
hogy a tábla C szintű lekérdezésénél mindkét adatértéknek szerepelni
kell,megadva, hogy melyik vonatkozik az U, s melyik a C védelmi szintre.
Ebből viszont az is látható, hogy az adatelemnek valójában több különböző
fizikai előfordulását is tárolni kell. A
Az adatok többszörös, több különböző értékkel történő előfordulását
polyinstantiation jelenségnek nevezzük. A polyinstantiation jelensége
különösen azért érdekes, mert hatására a táblában több olyan rekordelőfordulás
is szereplhet egyidejűleg, melyek azonos kulcsértéket tartalmaznak. Emiatt az
alaptáblában is módosított formában fognak csak teljesülni például az
egyediségre vonatkozó integritási feltételek. Ha meg kívánánk őrizni az
integritási feltételekt a hagyományos értelmezésben, akkor az lacsonyabb szintű
előfordulás bevitelekor például hibát jelezne a rendszer, amley hibából viszont
a felhaználó már következtethetne, hogy a tábla már tartalmaz ugyanilyen
kulcsú rekordot. Vagyis jogosulatlan információkhoz juthatna a hibajelzés által
a felhasználó.
A polyinstantiation következménye az is, hogy a felhasználó ilyen rendserben
nem lehet biztos abban, hogy a teljes igazságot kapja a lekérdezéskor. Mint a
mechanizmusból is kitűnik a felhasználó csak azt fogja megkapni, ami számára
engedélyezett,. a titkosabb, a teljesebb valóságot tartalmazó adatok rejtve
maradnak előtte.
A mechanizmus bemutatására vegyünk egy egyszerű példát, melyben az
alaptábla induláskor egyetlen egy rekordot tartalmaz.
név kor oszt fiz
------------------------------------------------------------------
Ica U 23 S b1 U 12 C S
------------------------------------------------------------------
A tábla U szintű nézete:
név kor oszt fiz
----------------------------
Ica NULL b1 NULL
A tábla S szintű nézete
név kor oszt fiz
----------------------------
Ica 23 b1 12
Ha az U szintű felhasználó módosítja a kor és a fiz mező értékeket, akkor az
alaptábla egy új rekorddal bővül, melyben a módosított személy szerepel.
név kor oszt fiz
------------------------------------------------------------------
Ica U 23 S b1 U 12 C S
------------------------------------------------------------------
Ica U 26 U b1 U 18 U U
------------------------------------------------------------------
Ekkor az U szintű nézetben a
név kor oszt fiz
---------------------------
Ica 26 b1 18
---------------------------
tábla, míg az S szintű nézetben a
név kor oszt fiz
---------------------------------
Ica 23 b1 12 S
---------------------------------
Ica 26 b1 18 U
---------------------------------
tábla fog megjelenni.
A bemutatott MAC elemek mellett a rendszer teljes védelme csak a műveletek
pontos korlátozását lehetővé tevő DAC elemekkel együtt biztosítható, így a
SeaView modell is tartalmazza korábban részletesen felvázolt DAC modellt a
MAC komponens kiegészítéseként.
A standard DAC és MAC mechanizmusok mellett még számtalan egyedi
mechanizmus is születhet az RDBMS kidolgozása során a védelem
biztosítására. E fejezet zárásaként egy olyan mechganizmust mutatunk be, mely
más környezetben is alkalmazható az adatok módosítás elleni védelmének
ellenőrzésére.
Az Integrity check mechanizmus alapelve az, hogy az adatbázisban letárolt
adategységekhez, például rekordokhoz, kiszámol egy belső egyutas
algoritmussal előállított ellenőrző összeget, úgy hogy a különböző
rekordelőfordulások nagy valószínűséggel más és más ellenőrző összeget
szolgáltassanak. A rekordhoz tartozó ellenőrző összeget a rekorddal együtt
tárolják le az adatbázisban.
Az ellenőrzés abban áll, hogy az olvasáskor ismét kiszámolásra kerül az
ellenőrző összeg, s a rendszer ellenőrzi, hogy a kiszámolt és az adatbázisban
tárolt ellenőrző összegek megegyeznek-e egymással. Ha nem akkor, valamilyen
jogosulatlan hozzáférés történhetett az adatbázisban, mivel a jogosult
hozzáférési útvonal mentén történő módosításokkor az ellenőrző összeg is
aktualizálkódik.
Az ellenőrézs mechanizmusa egy külső biztonsági komponensbe is
implementálható, mely mintegy ráépül az alkalmazott RDBMS rendszerre. Az
adatokhoz a jogosult hozzáférések mindíg e komponesen keresztül mennek
végbe. A rendszer elvi vázát mutatja a következő ábra.
A bemutatott mechanizmust az illetéktelen módosítások megakadályozására is
felhasználahtjuk olyan módon, hogy a jogosult módosításokkor az ellenőrző
öszeget a rekord egy erre kijelölt mezőjébe tesszük le, s az adatbázisban
létrehozunk egy triggert a módosításokhoz. A trigger feladata, hogy kiszámolja
az új értékkel a módosított ellenőrző összeget, s megnézze, hogy a kiszámolt
összeg megegyezik-e a rekordban megadott értékkel vagy sem. Ha nem
egyezne meg, akkor illetéktelen úton próbálják módosítani az adatbázist, ezért
ekkor a módosítás letiltható és naplózható is.
Egy igen biztonságos, de kissé merev és igen költséges megoldás az, amikor az
adatbázis adatait fizikailag particionálják nyilvános és titkos adatokra. Ekkor a
két komponens külön rendszeren, külön csomópontokon helyezkedik el.Minden
védelmi szintnek megvan a saját RDBMS rendszere és adatbázisa. Az egyes
felhasználók jogosultsági köre dönti el, hogy melyik csomóponthoz férhet
hozzá a felhasználó. A hozzáférési védelem ezáltal biztosan megvalósíthtó, e
rendszerben a nehézséget inkább az adatok szinkroniciója és a nagyobb
rendszerkarbantartásii igény okozza.