Oracle 11g new features 3. rész
Security
A biztonság terén is sok újítás készült:
Lehetőségünk van egy új nézet (DBA_USERS_WITH_DEFPWD) segítségével ellenőrizni, hogy a felhasználók default jelszavakat használnak-e.
Végre kis-nagybetű érzékenyek lettek a jelszavak. Viszont továbbra is használható a régi érzéketlen mód, arra az esetre ha gondunk akadna, valamelyik alkalmazással.
A jelszavak minőségének kikényszerítését megvalósító függvény (verify_fnction_11g) új, fejlettebb logikával rendelkezik. Ezt a fv-t a utlpwdmg.sql script generálja.
Az auditálás az alábbi objektumokra alapértelmezetten be van állítva:
- ALTER SYSTEM
- SYSTEM AUDIT
- CREATE SESSION
- CREATE USER
- ALTER USER
- DROP USER
- ROLE
- CREATE ANY TABLE
- ALTER ANY TABLE
- DROP ANY TABLE
- CREATE PUBLIC DATABASE LINK
- GRANT ANY ROLE
- ALTER DATABASE
- CREATE ANY PROCEDURE
- ALTER ANY PROCEDURE
- DROP ANY PROCEDURE
- ALTER PROFILE
- DROP PROFILE
- GRANT ANY PRIVILEGE
- CREATE ANY LIBRARY
- EXEMPT ACCESS POLICY
- GRANT ANY OBJECT PRIVILEGE
- CREATE ANY JOB
- CREATE EXTERNAL JOB
Ez az auditálás a DB-be a SYSTEM táblatér AUD$ táblájába történik, így figyelni kell, hogy nehogy megteljen ez a táblatér, mert ez komoly problémákhoz vezet. A felsorolt műveletek, egy átlagos adatbázisban azonban nem okoznak nagy terhelést, illetve sok adat generálást.
A 10g-ben bevezetett transparent tablespace encryption-t is tovább fejlesztették. Most már tudja alkalmazni az Oracle az indexeket a kódolt adatokra. Ugyanis a memóriában a kikódolás után tudja alkalmazni az index scan-t. A kódolás nem jelent nagy extra terhelést a porcesszornak. A kódoló kulcsokat az Oracle wallet-ben tárolja, melyet külön kulccsal lehet kinyitni.
A Data Pump Dump fájlok esetében is alkalmazható a titkosítás, így az archívumaink is biztonságban lehetnek.
Acces Controll List-ekkel korlátozhatjuk az adatbázisból kimenő kapcsolatokat, melyeket az UTL_TCP, UTL_HTTP és UTL_SMTP csomaggal hozhatnak létre a fejlesztők. Meghatározhatjuk a cél szervert, illetve a portot ahova a kimenő csatlakozás irányul.
(dbms_network_acl_admin.create_acl, dbms_network_acl_admin.add_privilege, dbms_network_acl_admin.assign_acl)
Adat maszkolást már az adatok exportálása közben megvalósíthatjuk az új Data Pump funkcióval: remap_data=[<SchemaName>.]<TableName>.<ColumnName>:[<SchemaName>.]<PackageName>.<FunctionName>
Így egy keverő plsql fv-t alkalmazhatunk a kiexportálandó oszlopra.
Ezentúl az Enterprise Manager-ből intézhetjük a security beállításokat, és nem kell az Oracle Security Managert használnunk.
Az audit adatok törlésére eddig csak úgy volt lehetőségünk, hogy ha leállítjuk az auditálást és törlünk. A 11g-ben immár rendelkezésre áll a dbms_audit_mgmt csomag melynek eljárásaival ezt menet közben is megtehetjük. (init_cleanup, clean_audit_trail, create_purge_job, set_audit_trail_property)
Új funkció az is, hogy az audit adatokat átmozgathatjuk, az előbb említett csomag segítségével (set_audit_trail_location).
Több RAC instance-on keresztül is használhatók már a globális alkalmazás context-ek. Ezekben változó értékeket tárolhatunk és több session-on/alkalmazáson/instance-on keresztül biztonságosan érhetjük el. (create context, dbms_session.set_context, select sys_context).
A listener jelszó beállítási funkciója többé nem használatos, felesleges funkcióvá vállt.
Új privilégiumot hoztak létre: execute -directory objektumokra. Melynek segítségével az adatbázison kívüli alkalmazások futtatásának jogát állíthatjuk. Ez azért is fontos, mert a 11g-ben például megtehetjük azt, hogy egy becsatolt külső tábla selectálása előtt elindítsunk külső programot mely pl.: kitömöríti az adatokat, mielőtt az adatbázis olvassa őket. Ezt a külső program futtatást, külön auditálhatjuk is természetesen.
Új audit funkció továbbá az audit all statements is, mely lekorlátozza az auditált parancsok körét a felhasználó által direkt hívott/kiadott parancsokra, és nem jeleníti meg az indirekt parancsokat. Például ha a felhasználó egy funkciót hívott, akkor nincs az audit trailben részletezve a függvény által hívott további parancsok listája. Így könnyebben kezelhető audit log keletkezik.
Beállítható a saját session teljes auditja is (audit all in session current) mely csak az adott session-t figyeli, és nem az összest. Így könnyebb megkeresni egy hibát, mely egy hívási lánc mélyén történt, és nincs róla egyébb információnk, csupán annyi hogy valahol a programban hibás tábla hivatkozás volt.
A Transparent Data Encryption (TDE) terén is finomítottak a 11g R2-ben. Csak 1 mester kulcsot kell használnunk, mind oszlop, mind táblatér szintű kódolás esetén (unified master encryption key). Amúgy a táblatér szintű TDE a 11g R1-ben jelent meg. A mester kulcs ahogy korábban említettem, wallet-ben van tárolva amit külön ki kell nyitni. Ezt RAC esetén, nem kell minden instance-on külön megtennünk. Habár a táblateret/táblákat kódoló kulcsot nem de a mester kulcsot - mely a többi kulcsot kódolja - megváltoztathatjuk.
A by session audit, mely idáig csak egy audit rekordot generált egy táblahozzáférés/session esetén most már ugyanúgy viselkedik mint a by access audit. Annyi rekordot generál ahányszor az adott táblához hozzáfértek.
A cikk forrása az Oracle hivatalos oldala.
http://www.oracle.com/technetwork/articles/sql/index-099021.html