Adatbázisok védelme

1. Adatbázisok védelme Jogosultság és szerepkör kezelés Oracle 11gR2 alatt

2. Rendszer jogosultság és szerepek kiosztása • A GRANT SQL utasítás segítségével adhatunk rendszer jogosultságot és szerepkört amennyiben: • Van ADMIN OPTION vagy ANY PRIVILEGE rendszer jogosultságunk van • Egy szerep kiosztásához ADMIN OPTION vagy ANY ROLE szerepkörre van szükségünk • Pl.: GRANT CREATE SESSION, accts_pay TO jward;

3. ADMIN OPTION jogosultság • Ha megadjuk a WITH ADMIN OPTION záradékot akkor a jogosultság a következőkkel bővül: • A kezdeményezett adhat vagy visszavonhat rendszer jogosultságot vagy szerepkört az adatbázisban. A felhasználók önmaguktól nem vonhatják meg a jogosultságot • A kezdeményezett kiadhatja a rendszer szintű jogosultságot vagy szerepet az ADMIN OPTION segítségével • A kezdeményezett módosíthatja vagy eldobhatja a szerepkört • Pl.: GRANT new_dba TO michael WITH ADMIN OPTION; • Használjuk óvatosan!

4. Új felhasználó létrehozása a GRANT segítségével • Ha GRANT-tel hivatkozunk egy felhasználóra, aki nem létezik az adatbázisban, és használjuk az IDENTIFIED BY záradékot, akkor automatikusan létrejön a felhasználó az záradék segítségével megadott jelszóval • Pl.:GRANT CREATE SESSION TO psmith IDENTIFIED BY password;

5. Objektum jogosultságok • A GRANT segítségével objektum jogosultságokat rendelhetünk a felhasználókhoz és szerepkörökhöz • Hogy ezt megtehessük az alábbiaknak kell igaznak lennie ránk: • A szóban forgó objektumnak sajátnak kell lennie • Rendelkezni kell a GRANT ANY OBJECT PRIVILEGE jogosultsággal • Amikor megkaptuk az objektum feletti jogosultságunkat, akkor azt a WITH GRANT OPTION záradékkal kaptuk meg • Pl.: - GRANT SELECT, INSERT, DELETE ON emp TO jfee, tsmith;- GRANT ALL ON salary TO jfee;

6. A GRANT OPTION záradék • Ha ezt a záradékot megadjuk, akkor az objektumra jogosult továbbadhatja ezt a jogosultságot más felhasználók számára. • A felhasználó, akinek a sémájában az objektum van, automatikusan megkapja a GRANT OPTION záradékot • A záradék a következőkre jogosítja fel a kezdeményezettet: • A kezdeményezett bármelyik felhasználónak és szerepnek adhat jogosultságot a GRANT OPTION záradékkal vagy a nélkül • Ha az alábbiak teljesülnek, akkor a felhasználó létrehozhat nézeteket, és hozzá tartozó jogosultságokat oszthat ki a felhasználókra illetve szerepekre nézve: • A kezdeményezett rendelkezik a GRANT OPTION jogosultsággal • Rendelkezik továbbá a CREATE VIEW vagy CREATE ANY VIEW rendszer jogosultsággal

7. Objektum jogosultság megadása az objektum tulajdonosának nevében • A GRANT ANY OBJECT PRIVILEGE rendszer jogosultság lehetővé teszi a felhasználóknak, hogy jogosultságot osszanak ki vagy vonjanak vissza az objektum tulajdonosai számára. • Ez a jogosultság része a DBA szerepnek, így minden AS SYSDBA-ként csatlakozó felhasználó megkapja. Mint minden rendszer jogosultságot, a GRANT ANY OBJECT PRIVILEGE-tis csak az ADMIN OPTION-nelrendelkezők adhatják. • A rögzítésre kerülő ‘felhatalmazó’ lehet az objektum tulajdonosa, vagy az a személy, aki rendelkezik a GRANT ANY OBJECT PRIVILEGE-gel. Ha a felhatalmazónak van GRANT ANY OBJECT PRIVILEGE jogosultsága, de nincs GRANT OPTION jogosultsága az objektumhoz, akkor az objektum tulajdonosa lesz a felhatalmazó, különben pedig a jogosultságot adó felhasználó.

8. Objektum jogosultság megadása az objektum tulajdonosának nevében • adams – GRANT ANY OBJECT PRIVILEGE • GRANT SELECT ON HR.EMPLOYEES TO blake WITH GRANT OPTION; • A DBA_TAB_PRIVS nézetben látható, hogy a hr van megjelölve felhatalmazóként • Ha blake-nek van GRANT ANY OBJECT PRIVILEGE jogosultsága is: • GRANT SELECT ON HR.EMPLOYEES TO clark; • A DBA_TAB_PRIVS nézetben már blake a jogosultság kiosztója clark esetében

9. Jogosultság kezelése oszlopokon • INSERT, UPDATE, REFERENCES jogosultságok rendelhetők oszlopokhoz • INSERT jogosultság esetén vigyázni kell, hogy van –e a táblán NOT NULL megszorítás. Lehet, hogy a felhasználó nem fog tudni beszúrni értékeket a táblába. Hogy elkerüljük ezt a szituációt, tegyük lehetővé, hogy minden NOT NULL oszlop beszúrható legyen, vagy legyen egy nem NULL alapértelmezett értéke. • Pl.:GRANT INSERT (acct_no) ON accounts TO psmith; GRANT INSERT(ename, job) ON emp TO jfee, tsmith;

10. Sor szintű hozzáférés-kezelés • Sor szintű hozzáférés-kezelésre is lehetőség van • Virtual Private Database (VPD) vagy Oracle Label Security (OLS) segítségével

11. Jogosultság és szerep megvonása felhasználótól • A rendszer jogosultságokat és szerepeket a REVOKE SQL utasítás segítségével lehet visszavonni • Bármely ADMIN OPTION rendszer jogosultsággal vagy szerepkörrel rendelkező felhasználó visszavonhat jogosultságot vagy szerepet bármelyik másik adatbázis felhasználójától vagy szerepkörétől. Nem feltétlenül az a felhasználó vonja vissza a jogosultságot aki kiadta. A GRANT ANY ROLE jogosultságú felhasználók bármilyen szerepkört visszavonhatnak. • Pl.: REVOKE CREATE TABLE, accts_rec FROM psmith;

12. Objektum jogosultságok visszavonása • Egy objektum jogosultságának visszavonásához a következő feltételek közül az egyiknek meg kell megfelelni: • A jogosultságot vagy szerepkört mi ruháztuk az objektumra • Rendelkezünk a GRANT ANY OBJECT PRIVILEGE rendszer jogosultsággal ami lehetővé teszi hogy jogosultságot adjunk, vagy vonjunk vissza az objektum tulajdonosától • Csak olyan jogosultságokat vonhatunk vissza, amiket közvetlenül mi adtunk vissza. Nem vonhatunk vissza olyat, amit olyan adott ki, akiknek mi adtunk jogosultságot • Pl.:REVOKE SELECT, INSERT ON emp FROM jfee, psmith;REVOKE ALL ON dept FROM human_resources; • Megjegyzés: A GRANT OPTION objektum jogosultságot nem vonhatjuk vissza külön. Vonjuk vissza az objektum jogosultságot, és adjuk meg újra GRANT OPTION nélkül

13. Objektum jogosultság visszavonása valaki nevében • A GRANT ANY OBJECT PRIVILEGE rendszer jogosultság lehetővé teszi, hogy bármilyen olyan objektum jogosultságot visszavonjunk, amit az objektum tulajdonosa adott meg. • Abban az esetben, ha a jogosultságot az objektum tulajdonosa is kérte, és a felhasználó kiadja a REVOKE utasítást, az Oracle csak a felhasználó által megadott jogosultságot vonja vissza • Blake SELECT jogosultságot adott a HR.EMPLOYEES –onclark-nak. Még ha blake rendelkezik is a GRANT ANY PRIVILAGE rendszer jogosultsággal, ő birtokolja az adott objektum jogosultságot, tehát ez a ‘felhatalmazás’ hozzá tartozik. • A HR felhasználó SELECT jogosultságot adott clark-nak a HR.EMPLOYEES táblán.

14. Objektum jogosultság visszavonása valaki nevében • DBA_TAB_PRIVS nézet:GRANTEE GRANTOR PRIVILEGE GRANTABLE-------- ------- ----------- ----------BLAKE HR SELECT YES CLARK BLAKE SELECT NO CLARK HR SELECT NO • blakekiadja az alábbi utasítást:REVOKE SELECT ON HR.EMPLOYEES FROM clark; • Csak a blake által kiadott jogosultság lesz visszavonva, a tulajdonos (HR) által kiadott megmaradGRANTEE GRANTOR PRIVILEGE GRANTABLE-------- ------- ----------- ----------BLAKE HR SELECT YES CLARK HR SELECT NO • Ha blake újra kiadja a REVOKE utasítást, akkor már az adams által elhelyezett jogosultságot vonja vissza, mivel rendelkezik a GRANT ANY OBJECT PRIVILEGES rendszer jogosultsággal

15. Oszlopra helyezett jogosultság visszavonása • Oszlopokra helyezett jogosultságot nem tudunk külön-külön visszavonni egy egyszerű REVOKE utasítással • Megoldás: Mindet visszavonni, és egyesével visszahelyezni ami szükséges

16. A REFERENCES objektum jogosultság visszavonása • Ha egy objektumra REFERENCES jogosultságot helyeztünk külső kulcs megszorítás létrehozása érdekében, akkor ennek visszavonása csak a CASCADE CONSTRAINTS opció segítségével lehetséges • Pl.:REVOKE REFERENCES ON dept FROM jward CASCADE CONSTRAINTS; • (Ekkor minden olyan külső kulcs megszorítás amit a REFERENCES-zel hoztunk létre el lesz dobva.)

17. Kaszkádolás a jogosultság visszavonása esetén • A jogosultság típusától függően többféle kaszkádolás váltódhat ki annak visszavonásakor

18. Kaszkádolás rendszer jogosultságok visszavonása esetén • Nincsen kaszkádolás az olyan rendszer jogosultságok visszavonása esetén, amik DDL-hez kapcsolódnak, akkor sem ha ADMIN OPTION-nel lettek megadva • Pl. • A biztonsági adminjfee-t felruházza a CREATE TABLE rendszer jogosultsággal (ADMIN OPTION) • jfee csinál egy táblát • jfee CREATE TABLE rendszer jogosultságot ad tsmith-nek • tsmith csinál egy táblát • A biztonsági admin visszavonja a CREATE TABLE jogosultságot jfee-től • A jfee által létrehozott tábla továbbra is létezni fog, tsmith-nek pedig meglesz a táblája, és a CREATE TABLE jogosultsága

19. Kaszkádolás rendszer jogosultságok visszavonása esetén • DML utasításhoz kapcsolódó jogosultság esetén már előfordulhat a kaszkádolás effektus • Ha a SELECT ANY TABLE jogosultságot megvonjuk egy felhasználótól, akkor minden eljárás ami a felhasználó sémájában használná ezt a jogosultságot, nem fog tudni lefutni, amíg a jogosultságot vissza nem kapja

20. Kaszkádolás effektus objektum jogosultság visszavonása esetén • Az objektum jogosultság visszavonása esetén előfordulhat kaszkádolás effektus: • Az olyan objektum definíciókra, amik egy DML objektum jogosultságtól függenek, hatással lehet a jogosultság visszavonása. Pl.:Ha egy eljárás törzse adatokat olvas az emp táblából, és megvonjuk a SELECT jogosultságot az emp táblától, akkor az eljárás nem tud sikeresen lefutni.

21. Kaszkádolás effektus objektum jogosultság visszavonása esetén • Ha egy táblához tartozó REFERENCES jogosultságot visszavonunk a felhasználótól, minden külső kulcs megszorítás, ami a felhasználó által definiálva lett és ezen a táblán alapul, az automatikusan el lesz dobva • Az objektum jogosultságok amik a GRANTOPTION használatával lettek kiadva visszavonásra kerülnek ha egy grantor objektum jogosultsága visszavonásra kerül

22. Kaszkádolás effektus objektum jogosultság visszavonása esetén • Azok az objektum definíciók amiknek szüksége van az ALTER és INDEX DDL objektum jogosultságokra, nem érintettek abba, ha az ALTER vagy INDEX objektum jogosultság visszavonásra kerül. Pl ha egy felhasználó csinál egy táblát amiben egy index egy másik felhasználóhoz tartozik, és az INDEX jogosultságot visszavonjuk, az index továbbra is létezik.

23. A PUBLIC UserGroup-hoz tartozó jogosultságok hozzáadása és visszavonása • Minden jogosultság és szerepkör amit a PUBLIC-nak megadunk elérhető minden felhasználó számára. • A biztonsági adminisztrátorok és adatbázis felhasználóknak oda kell figyelni, hogy csak azok a jogosultságok és szerepkörök legyenek érvényesek a PUBLIC-ra, amikre szükség van • Egy jogosultság visszavonása a PUBLIC-tól jelentős kaszkádolási hatásokkal járhat

24. Szerepkörök kiosztása operációs rendszer vagy hálózat segítségével • Operációs rendszer segítségével is le lehet vezényelni a szerepkörökhöz való hozzáadást, vagy visszavonást. • A szerepköröket egy hálózati szolgáltatáson keresztül is kioszthatjuk • Ez utóbbi hasznos lehet ha biztonsági szempontból központosítani szeretnénk a rendszerünket, pl. a következő módokon: • MVS Oracle adminok RACF csoporotokkal szeretnék azonosítani a szerepköröket • UNIX OraadminokUNIX csoportokkal szeretnék • VMS Oraadminok jogosultsági azonosítókkal szeretnék

25. Szerepkörök kiosztása operációs rendszer vagy hálózat segítségével • OS hátrányai: • A jogosultság kezelése csak szerepkör szintjén megvalósítható (egyedi jogosultság kiadására nincs lehetőség, csak a GRANT utasítással az adatbázison belülről) • Alapértelmezetten a felhasználók nem csatlakozhatnak az adatbázishoz megosztott szerveren, vagy bármilyen más hálózati kapcsolaton keresztül (ez az alapértelmezés megváltoztatható)

26. Szerepkör azonosítás operációs rendszer seegítségével • OS_ROLES – TRUE –ra állítása • Ha egy felhasználó létrehoz egy új session-t az adatbázisban, akkor az Oracle inicializálja a felhasználó szerepkörét az OS segítségével • Ahhoz hogy az adatbázis azonosítani tudja a felhasználókhoz tartozó szerepkört, minden felhasználónak lennie kell egy egyedi azonosítónak az OS-ben (bárhogy is nevezzük ezt), ami megmutatja, hogy a felhasználó számára mely adatbázis szerepkörök érhetők el. • Megadható az alapértelmezett szerepkör jelentése és az ADMIN OPTION-é is

27. Szerepkör azonosítás operációs rendszer segítségével • A szerepkör specifikációja OS-től függetlenül a következő:ora_ID_ROLE[[_d][_a][_da]] • ID: minden OS-nél más. • ROLE: az adatbázis szerepkör neve • d: opcionális karakter, ami az alapértelmezett szerepkört jelöli • a: opcionális karakter, azt jelöli, hogy a szerepkör egy olyan felhasználóhoz fog tartozni, aki ADMIN OPTION-nel rendelkezik. Ez lehetőséget ad a felhasználónak, hogy átadja a szerepköröket más szerepköröknek. A szerepkörök nem adhatók át felhasználóknak, ha az OS kezeli őket

28. Szerepkör azonosítás operációs rendszer segítségével • Pl.:ora_PAYROLL_ROLE1ora_PAYROLL_ROLE2_aora_PAYROLL_ROLE3_dora_PAYROLL_ROLE4_da

29. OS szerepkör menedzselés használata • Minden adatbázis felhasználót azonosítani kell tudni az operációs rendszer oldaláról, ezért minden felhasználóhoz használni kell az IDENTIFIED EXTERNALLY-t

30. Szerepkör hozzárendelése és visszavonása OS_ROLES TRUE esetén • OS kezel minden szerepkört • Az előzőleg megadott hozzárendelések nem lesznek érvényben. Az OS csak a szerepköröket kezeli, a felhasználók továbbra is adhatnak jogosultságokat szerepköröknek és felhasználóknak

31. Szerepkörök engedélyezése és tiltása OS_ROLES TRUE esetén • SET ROLE utasítás segítségével • Max. 148 szerepkör definiálható a felhasználó által

32. Hálózati kapcsolatok használata OS szerepkör menedzselés mellett • Alapértelmezetten megosztott szerveren keresztül nem kommunikálhatnak a felhasználók az adatbázissal, mert biztonsági rést okoz • REMOTE_OS_ROLES - TRUE

33. Mikor lesz hatása a jogosultság hozzáadásának és visszavonásának? • Attól függ hogy mit szeretnénk hozzáadni vagy visszavonni: • Minden rendszer és objektum jogosultság hozzáadása és visszavonása azonnal megtörténik • A szerepkörök hozzárendelése és visszavonása akkor történik meg, amikor a felhasználó aktuális session-je kap egy SET ROLE utasítást • Az aktuálisan engedélyezett szerepkörök tanulmányozásához a SESSION_ROLES adatkönyvtárat érdemes vizsgálni

34. Hogyan befolyásolja a SET ROLE utasítás a GRANT és REVOKE utasításokat • A felhasználó akárhányszor módosíthatja az aktuálisan engedélyezett szerepköröket a SET ROLE utasítással • Pl.:SET ROLE clerk IDENTIFIED BY password;SET ROLE NONE;

35. Alapértelmezett szerepkörök definiálása • Amikor egy felhasználó bejelentkezik, akkor minden explicit módon megadott jogosultság, és az alapértelmezett szerepkörben lévő minden jogosultság automatikusan engedélyezve lesz • Az alapértelmezett szerepkör megadására az ALTER USER SQL utasítás használható • Pl.:ALTER USER jane DEFAULT ROLE payclerk, pettycash; • CREATE USER esetén nem adhatunk meg alapértelmezett szerepkört. (Ilyenkor ALL)

36. Finom szemcsézettségű elérés PL/SQL Network UtilityPackages • A felhasználói felügyelethez beállíthatók külső hálózati eszközök segítségével a következőkön keresztül: • Pl/SQL csomagok: • UTL_TCP • UTL_SMTP • UTL_HTTP • UTL_INADDR • HttpUriType típus

37. Finom szemcsézettségű elérés PL/SQL Network UtilityPackages • Finom szemcsézetsségű felhasználói felügyelet és szerepkör kezelés külső hálózati szolgáltatásokon keresztül az adatbázisból: • Különböző csoportok tudnak csatlakozni a kiszolgálógépekhez, melyeket jogosultságkezelését elvégezhetjük • Finom szemcsézettségű felhasználói felület Oracle wallets-en keresztül olyan HTTP kérések küldésére, melyek jelszavas authentikációt kívánnak

38. Finom szemcsézettségű hozzáférés felügyelet egy külső hálózati szolgáltatáshoz • Access Control List (ACL) létrehozása • XML DB-ben tároljuk • XML DB használata, vagy DBMS_NETWORK_ACL_ADMIN és DBMS_NETWORK_ACL_UTILITY PL/SQL csomagok segítségével • XML DB -> Oracle XML DB Developer's Guide

39. Finom szemcsézettségű hozzáférés felügyelet egy külső hálózati szolgáltatáshoz • Nagyobb biztonság a külső hálózati host-ok korlátozásával • Ha egy behatoló bejut az adatbázisba, kárt tehet a hálózatban mivel az EXECUTE jogosultság a PUBLIC felhasználókhoz tartozik • IP4 és IP6 támogatás

40. A Wallets-hez való hozzáférés szabályozása • Weboldalon keresztüli hozzáférés esetén lehetőség van jelszóval történő authentikációra • Egy wallet-hez való hozzáféré szabályozásához a következő komponensekre van szükség: • Oracle wallet: mkstoreutilityvagy OacleWallet Manager segítségével hozható létre • Egy ACL a wallet-hez tartozó jogosultságok kezeléséhez. • Valamilyen módon össze kell rendelni az ACL-t az Oracle wallet-tel: DBMS_NETWORK_ACL_ADMIN

41. PL/SQL Network UtilityPackages alapú alkalmazások frissítése • ORA-24247: network access denied by access control list (ACL) • Újra kell konfigurálni az alkalmazás hálózathoz való csatlakozását

42. ACL létrehozása külső hálózati szolgáltalásokhoz • Ne csináljunk túl sok csoportot • DBMS_NETWORK_ACL_ADMIN • Az ACL létrehozása és a jogosultságok definiálása • Név • Leírás • Jogosultság egy felhasználónak vagy egy szerepkörnek

43. ACL létrehozása külső hálózati szolgáltalásokhoz - példa BEGIN DBMS_NETWORK_ACL_ADMIN.CREATE_ACL ( acl => 'file_name.xml', description => 'file description', principal => 'user_or_role', is_grant => TRUE|FALSE, privilege => 'connect|resolve', start_date => null|timestamp_with_time_zone, end_date => null|timestamp_with_time_zone); END;

44. ACL létrehozása külső hálózati szolgáltalásokhoz - példa • acl: Adjunk meg egy nevet az ACL XML-nek. /sys/acls könyvtárba kerülacl => 'us-example-com-permissions.xml', • Description: Egy leírás a fájlhozdescription => 'Network connection permission for ACCT_MGR role', • principal: Az felhasználói fiók vagy szerepkörre vonatkozó engedélyeket vagy tiltásokat adunk meg ittprincipal => 'ACCT_MGR‘Fontos a kis és nagybetűk közti különbség • is_grant: TRUE vagy FALSE, attól függően hogy tiltjuk vagy engedélyezzük a jogosultságotis_grant => TRUE, • privilege: connectvagyresolveprivilege => 'connect‘UTL_TCP, UTL_HTTP, UTL_SMTP, és UTL_MAIL esetén van rá szükség

45. ACL létrehozása külső hálózati szolgáltalásokhoz - példa • start_date: opcionális. Mikortól legyen érvényes a hozzáférés szabályozásstart_date => '2008-02-28 06:30:00.00 US/Pacific', • end_date: később kell lennie, mint a start_dateend_date => '2008-12-10 23:59:00.00 US/Pacific');

46. ACL létrehozása külső hálózati szolgáltalásokhoz - példa • DBMS_NETWORK_ACL.ADD_PRIVILEGE eljárás: BEGIN DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE ( acl => 'file_name.xml', principal => 'user_or_role', is_grant => TRUE|FALSE, privilege => 'connect|resolve', position => null|value, start_date => null|timestamp_with_time_zone, end_date => null|timestamp_with_time_zone); END; • Nincsdescription • Vanposition:a szerepek hozzáadásának precedenciáját adja meg

47. Egyéb ACL műveletek • DELETE_PRIVILEGE • DROP_ACL

48. Az ACL Hálózati kiszolgálókhoz való hozzárendelése • DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL eljárás: BEGIN DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL ( acl => 'file_name.xml', host => 'network_host', lower_port => null|port_number, upper_port => null|port_number); END;

49. Az ACL Hálózati kiszolgálókhoz való hozzárendelése • acl: ACL XML fájl neveacl => 'us-example-com-permissions.xml', • host: hálózati kiszolgáló, amihez hozzárendeljük az ACL-t.host => 'us.example.com', • lower_port: (Opcionális) TCP kapcsolatokhoz. A port tartomány alsó korlátja.lower_port => 80, • upper_port: (Opcionális) TCP kapcsolatokhoz. upper_port => 3999);Ha megadtunk egy alsó korlátot, de nem adunk meg felsőt, akkor automatikusan az alsó egyben felső korlát is lesz.

50. Az ACL Hálózati kiszolgálókhoz való hozzárendelése • Egy host géphez, egy ACL tartozik • DROP_ACL: ACL törlése • UNASSIGN_ACL: ACL hozzárendelés megszüntetése