Controlul accesului

Controlul accesului

Procesul de autentificare valideaza identitatea entitatilor prin intermediul retelei, bazelor de date sau aplicatiilor. Apoi, procesul de autorizare stabileste limitari asupra accesului si actiunilor acestor entitati, limitari legate de identitatea utilizatorilor si de rolurile asociate.

Asigurarea securitatii si restrictionarea accesului se poate realiza si la nivelul obiectelor accesate, acest lucru ducand la realizarea unei protectii asupra obiectelor, indiferent de entitatile si modalitatile folosite de acestea pentru a dobandi accesul si a actiona asupra respectivelor obiecte.

Protectia obiectelor se poate realiza folosind privilegii la nivel de obiect si vederi, precum si proiectand si implementand metode pentru restrictionarea accesului la anumite tabele, vederi sau linii/randuri din tabele.

Tabelele de date, adica tabelele in care este efectiv stocata informatia sunt obiectele cele mai importante ale unei baze de date si restrictionarea accesului la acestea trebuie atent realizata. Utilizatorilor ar trebui sa li se permita accesul doar la informatiile strict necesare pentru desfasurarea propriei activitati. Aceasta presupune existenta unor metode de a asigura securitatea si controlul accesului la nivel de coloana si la nivel de rand (Fine-Grained Acces Control).

In Oracle, accesul la nivel de rand, care ofera posibilitatea unui control al accesului fin granularizat (Fine-Grained Access Control) folosind contextul de aplicatie (Application Context) poarta numele de Virtual Private Database (VPD).

Un control al accesului atat de detaliat poate fi util, de exemplu, daca se doreste stocarea datelor din mai multe departamente, sau chiar mai multe organizatii in aceeasi baza de date, si aceleasi tabele, pastrandu-se totusi confidentialitatea datelor, modul de stocare fiind transparent pentru utilizatori. Modul traditional de abordare a unei astfel de situatii din versiunile mai vechi Oracle este prin folosirea vederilor (Views) , a triggerelor sau combinatii ale acestora. In general, mai ales pentru sisteme mari, aceasta ar duce la construirea de aplicatii complexe, care sa contina mult cod redundant. Pe masura ce se adauga noi grupuri de utilizatori si mai multe categorii de date, mentenanta devine din ce in ce mai dificila doar prin folosirea vederilor si triggerelor.

De asemenea sunt necesare un intreg set de roluri pentru autenitifcarea si autorizarea utilizatorilor din diverse categorii. Intreaga implementare a acestor metode s-ar afla in aplicatia client sau in aplicatia middle-tier, ceea ce ar crea o bresa de securitate in cazul in care un utilizator s-ar conecta direct la baza, ocolind aceste aplicatii. Securitatea la nivel de rand (row level security sau FGAC) rezolva acesta problema atasand unui tabel sau vedere o functie ce implementeaza politica de securitate si care este executata de fiecare data cand datele din respectivul tabel sunt interogate.

Vederile - mecanism de implementare a securitatii

O vedere reprezinta o prezentare a datelor selectate dintr-unul sau mai multe tabele, sau chiar alte vederi. O vedere nu contine efectiv date, ci deriva din datele continute in tabelele si vederile pe care se bazeaza. Poate fi vazuta ca o intergoare stocata in baza de date.

O vedere poate fi interogata si informatiile pe care le afiseaza pot fi modificate. Asupra unei vederi se pot efectua acelesi tip de operatii pentru manipularea datelor ca si in cazul tabelelor: modificari, adaugari sau stergeri de inregistrari, aceste operatii modificand tabelele aflate la baza vederii. Operatiile efectuate asupra vederii se supun acelorasi constrangeri de integritate si triggerelor din tabelele originale.

Vederile pot reprezenta o puternica metoda de secuirzare a bazei de date, prin utilizarea lor existand posibilitatea ascunderii anumitor coloane din tabel sau mascarea anumitor valori. De asemenea pot fi folosite pentru grupa informatii din mai multe tabele pentru a inlatura informatii si a pastra caracterul privat al datelor.

Accesul la aceste obiecte ale bazei de date se face prin acordarea de privilegii separate si diferite de privilegiile necesare pentru accesul tabelelor pe care se bazeaza vedere. Permiterea accesului la datele afisate de o vedere si nu la tabelele care contin efectiv respectivele date, este o tehnica eficienta de protejare a informatiei de anumiti utilizatori.

De exemplu, daca se doreste ca anumiti utilizatori sa poata afla doar o statistica privind numarul de clienti si tipul de abonament al acestora, nu este nevoie sa se acorde acestor utilizatori accesul la tabelele tbl_Clienti si tbl_Abonamente, ci pur si simplu se poate crea o vedere care sa sumarizeze aceasta informatie si apoi sa se acorde drept de acces asupra ei anumitor utilizator. Astfel, utilizatorul Felicia, folosind sintaxa de mai jos va crea o vedere in propria schema si apoi va acorda privilegiu SELECT utilizatorului Andrei

CREATE OR REPLACE VIEW v_Clienti_Ab

AS

SELECT INITCAP (a.denumire) "Tip Abonament" ,

COUNT (c.ID) "Numar clienti"

FROM tbl_Clienti c, tbl_Abonamente a 

WHERE c.tipab = a.ID

GROUP BY a.denumire;

GRANT SELECT ON v_Clienti_Ab TO Andrei;

Andrei va putea accesa aceasta vedere ca orice tabel, folosind sintaxa

SELECT * FROM Felicia.v_Clienti_Ab;

Tip abonament Numar clienti

AN 1 681

AN 2  882

AN 3  75

Securitate la nivel de campuri (Column-Level Securiy - CLS)

Vederile sunt un mijloc ideal pentru implementarea secuirtatii la nivel de camp/coloana din tabel. CLS (Column-Level Security) se poate defini in mai multe moduri:

Prevenirea accesului la datele din anumite campuri din tabel;

Mascarea valorilor din aceste coloane;

Controlul accesului la valorile din anumite coloane.

Inlaturarea coloanelor

In prima definitie, impiedicarea accesului la anumite coloane inseamna ca respectivele campuri sunt inaccesibile utilizatorilor. De exemplu, in tabelul tbl_Angajati trebuie inlaturat accesul la campul salariu, nu prin ascunderea informatiei continute, ci pur si simplu, aceasta coloana nu trebuie sa existe, pentur anumiti utilizatori.

O solutie la aceasta problema care sa presupuna utilizarea vederilor consta in crearea unui View care sa selecteze toate coloanele necesare din tabelul de angajati, mai putin coloana ce informatii despre salariu.

Aceasta solutie este mai greu de implementat daca o aplicatie exista deja si exista limitari privind utilizarea vederilor, sau pur si simplu implementarea a fost realizata folosind accesul direct la tabelul respectiv. Este un exemplu de solutie conform principiului "security by design", fiind usor de pus in practica inaine de a incepe efectiv dezvoltarea aplicatiei.

Mascarea valorilor din coloane

A doua definitie presupune ca anumite valori din respectivele coloane sa fie totusi accesibile. Acest lucru se poate realiza prin mascarea valorilor care nu se doresc a fi vizualizate de anumiti utilizatori si afisarea in loc a unei valori prestabilite, cum ar fi "ACCES NEAUTORIZAT" , 0 , NULL, etc.

De exemplu, seful unui departament nu poate avea acces la informatiile despre salariile angajatilor din alte departamente, dar poate vedea informatiile despre salariile subordonatilor sai, deci ascunderea coloanei salariu nu este o solutie.

Pentru a rezolva aceasta problema, se va folosi o vedere impreuna cu o functie pentru mascarea informatiei ce nu trebuie dezvaluita.

CREATE OR REPLACE VIEW v_angajati
AS
SELECT username, functie,departament,
DECODE (departament,20, salariu, NULL) salariu
FROM tbl_angajati;

O interogare asupra vederii SELECT * FROM v_angajati; va returna:

USERNAME  FUNCTIE DEPARTAMENT SALARIU

SMITH CLERK 10

JONES MANAGER 20 5000

SCOTT ANALYST 20 3000

ADAMS CLERK 10

UPDATE pentru vederile CLS

Vederea precedenta ofera securitate in ceea ce priveste interogarile SELECT, ramanand valabila si la folosirea functiilor agregate: SELECT SUM (salariu) FROM v_angajati;

returneaza valoarea 8000, adica doar totalul valorilor vizibile pentru utilizator.

Utilizatorul nu va putea efectua actualizari direct pe aceasta vedere.

UPDATE v_angajati SET salariu = salariu * 1.2; --- se incearcaa marirea cu 20%

Se va returna eroare ERROR ORA-01733: virtual column not allowed here

Cu toate acestea, seful departamentului trebuie sa aiba drept de a modifica salariul subordonatilor sai. Oracle ofera posibilitatea crearii unui trigger "instead-off" pentru executarea de operatii peste vederile complexe.

CREATE OR REPLACE TRIGGER v_anagajati_update INSTEAD OF UPDATE ON v_angajati
FOR EACH ROW
DECLARE
BEGIN
IF :OLD.salariu IS NOT NULL
THEN
UPDATE tbl_angajati
SET salariu = :NEW.salariu
WHERE username = :NEW.username;
END IF;
END;

Performanta vederilor cu functii CLS

Folosirea functiilor, cum a fost functia DECODE, in definirea vederii este o metoda puternica si la indemana pentru a masca valorile campurilor. Totusi, de multe ori securitatea concureaza cu performanta si de aceea orice abordare de acest fel trebuie atent analizata.

CLS pentru a controla accesul la toate inregistrarile dintr-o coloana

Baza de date Oracle furnizeaza un mecanism implicit pentru a controla dreptul de actualizare si modificare a informatiilor doar din anumite coloane ale unui tabel. Acest lucru se realizeza prin restictionarea privilegiilor anumitor utilizatori doar la unele dintre coloanele tabelului. De exemplu, un utilizator poate modifica doar valoarea nr_telefon din tabelul angajati

GRANT UPDATE (nr_telefon) ON tbl_angajati TO user1;

Capacitatea bazei de date de a permite privilegii la nivel de coloana face ca utilizatorului sa i se poata acorda doar drept de actualizare a datelor din coloana nr_telefon

Privilegiile la nivel de camp permit utilizatorului sa actualizeze campul respectiv pentru toate inregistrarile din tabel, ceea ce nu este intotdeauna un lucru dorit. Ele nu asigura securitatea inregistrarilor individuale, acest lucru trebuind asigurat, in cazul folosirii vederilor, de administratorul bazei de date.

Securitate la nivel de inregistrare (Row-Level Securiy - RLS) prin vederi

Acest tip de securitate, numit si control al accesului fin granularizat (fine-grained access control) poate fi realizat prin intermediul vederilor si presupune asigurarea secuirtatii datelor nu numai la nivel de obiect (de exemplu un tabel de date), ci si la nivelul fiecarei inregistrari din cadrul obiectului respectiv.

De exemplu, un angajat isi poate modifica datele personale, dar nu si pe cele ale altor colegi. Pentru aceasta, utilizatorul are nevoie de acces la absolut toate coloanele, dar trebuie impiedicat sa modifice si datele altor angajati.

Acest lucru se poate realiza prin adaugarea unui predicat, sau clauza WHERE, la o vedere creata pornind de la tabelul ce contine informatiile necesare.

CREATE OR REPLACE VIEW v_editare
AS
SELECT * FROM angajati
WHERE nume_cont = SYS_CONTEXT ('userenv', 'session_user')
WITH CHECK OPTION;

Vederea astfel creata va afisa o singura inregistrare care va putea fi modificata sau stearsa, si nu va permite adaugari de noi interogari care sa nu corepsunda conditiei din clauza WHERE (adica numele contului sa difere de numele utilizatorului conectat). Acest lucru se ralizeaza atat din motive de securitate, dar in primul rand din considerente de integritate a datelor prin aplicarea optiunii CHECK.

Folosirea functiilor pentru realizarea RLS prin intermediul vederilor

O modalitate des intalnita pentru crearea securitatii in cadrul vederilor este folosirea unei functii PL/SQL in definitia vederii. Cand aceasta functie este plasata in lista SELECT, inainte de FROM , in sintaxa SQL, vederea indeplineste principiile securitatii CLS, iar cand functiile sunt plasate la nivelul predicatului, adica dupa clauza WHERE, functia actioneaza ca un mecanism RLS.

Acest mecanism poate insa sa scada performantele sistemului, prin apelarea repetaa a functiei din cadrul vederii. De asemenea, procesul de a crea vederi care sa implementeze securitatea CLS si RLS, sa respecte privilegiile utilizatorilor si obiectelor poate duce la o complexitate sporita a acestora.

O modalitate mai eficienta de solutionare este tehnologia Virtul Private Database (VPD), Oracle integrand incepand cu versiunea Oracle 8 securitatea la nivel de rand (Row-Level Security) .

Virtual Private Database (VPD)

Virtual Private Database este un instrument oferit de Oracle pentru construirea de aplicatii sigure in ceea ce priveste accesul granularizat la date, fiiind o combinatie a urmatoarelor doua caracteristici:

Fine-Grained Access Control (FGAC) care ofera posibilitatea asocierii politicilor de securitate cu obiectele bazei;

Contextul de aplicatie (Applicatio context) care permite definirea si accesarea anumitor atribute predefinite, relevante la nivel de aplicatie sau sesiune a bazei de date.

VPD combina aceste doua caracteristici facand posibila implementarea politicilor de securitate pentru a controla accesul la nivel de rand, control bazat pe atributele aplicatiei sau sesiunii care comunica cu baza de date, atribute ce sunt disponibile in momentul executiei.

VPD permite construirea de aplicatii care sa impuna politicile de securitate la nivel de obiect. Astfel, executarea acestora va adauga in mod dinamic predicate (clauze WHERE) cererilor SQL care interogheaza datele identificate ca necesitand a fi protejate.

Application context permite dezvoltatorilor definirea, setarea si accesarea valoarea atributelor ce caracterieaza aplicatia/sesiunea la un moment dat. Exista doua tipuri de application context:

Context de aplicatie local (bazat pe sesiune) stocat in UGA (User Global Area) si apelat de fiecare data cand un utilizator se conecteaza la baza de date;

Context de aplicatie global stocat in SGA (System Global Area) folosit pentru utilizatorii din mediile multi-tier care acceseaza baza de date prin intermediul unui connection pool.

Desi contextul de aplicatie este o parte integranta a VPD, poate fi implementat si singur, fara FGAC, in acest caz putand fi folosit pentru accesarea diverselor informatii egate de sesiune, cum ar fi identitatea utilizatorului pentru a o pastra atata timp cat userul se afla conectat in sistemul multi-tier.

Virtual Private Database (VPD) ofera posibilitatea intaririi securitatii, la un nivel fin de granularitate, si aplicarea ei direct asupra tabelelor, vederilor sau sinonimelor. Politicile de securitate fiind astfel direct atasate obiectelor bazei de date sunt automat aplicate cand se incearca accesarea datelor din respectivele obiecte, facand astfel imposibila ocolirea regulilor de securitate.

Cand un utilizator acceseaza direct sau indrect un tabel sau vedere protejate cu politici VPD, serverul modifica dinamic instructiunea SQL a acelui utilizator creand o conditie WHERE (un predicat) returnata de o functie care implementeaza politica de securitate stabilita pentru tabelul respectiv. Modificarea este transparenta pentru utilizator si se poate aplica oricarei intructiuni SELECT, INSERT, UPDATE, INDEX sau DELETE.

O functie ce implementeaza politica de securitate (policz function), poate returna diferite predicate pentru fiecare utilizator, grup sau aplicatie. Contextul de aplicatie ofera posibilitatea accesarii sigure a atributelor pe care se bazeaza politica de securitate.

VPD la nivel de coloana

VPD la nivel de coloana ofera posibilitatea implementarii securitatii la nivel de rand/inregistrare atunci cand o coloana seminificativa pentru politica de securitate este referita in cadrul unei interogari. VPD la acest nivel se poate aplica tabelelor si vederilor, dar nu si sinonimelor.

Stabilirea coloanelor relevante pentru securitatea datelor se face folosind parametrul sec_relevant_cols al procedurii DBMS_RLS.ADD_POLICY si face ca politica de securitate sa fie aplicata de cate ori coloanele specificate de acest parametru sunt referite direct, sau indirect, intr-o interogare.

VPD cu mascarea informatiei la nivel de coloana

Uneori poate fi dorita doar ascunderea informatiei din coloanele respective, pentru inregistrarile asupra caror nu exista drept de acces si utilizare.

Parametrul sec_relevant_cols_opt a procedurii DBMS_RLS.ADD_POLICY se poate seta pentru a genera o comportare de tip mascare a valorilor si nu eliminare a acestora.

Astfel sunt afisate toate inregistrarile, dar pentru inregistrarile asupra carora nu este permis accesul, informatia din coloanele sensitive este ascunsa, afisandu-se in loc o valoare NULL.

Fine-Grained Access Control (FGAC)

FGAC ofera posibilitatea folosirii unor functii care sa implementeze politicile de securitare la un nivel de detaliere foarte fin si sa asocieze aceste politici cu tabele, vederi sau sinonime. Serverul bazei de date va aplica automat politicile astfel stabilite, indiferent de modul in care datele sunt accesate.

Folosirea FGAC presupune crearea de functii sa implementeze regulile de securitate si care sunt atasate tabeleleor,vederilor sau sinonimelor. Astfel, cand un utilizator foloseste o instructiune SELECT sau instructiuni DML asupra respectivului obiect, Oracle modifica dinamic instructiunea respectiva intr-un mod transparent pentru utilizator.

FGAC face posibila:

realizarea de politici de securitate bazate pe tabele, vederi si sinonime;

implementarea de politici de securitate multiple asupra aceluiasi obiect;

realizarea de grupuri de politici;

stabilirea unor reguli de securitate implicite;

realizarea acestor lucruri fara a scadea simtitor performantele bazei de date.

Politici de securitate pentru tabele si vederi

Implementarea unor politici de securitate la nivel de obiect si nu la nivel de aplicatie duce la o mai mare securitate, usurinta in realizare si felxibilitate

Securitate. Asocierea unei politici cu un tabel sau vedere poate ajuta la evitarea unei probleme majore de securitate existente in aplicatia client sau middle-tier. FGAC asigura aplicarea acleasi politici de securitate a datelor, indiferent de modul in care acestea sunt accesate.

Simplitatea. Adaugarea politicii de securitate la nivel de tabel, vedere sau sinonim inseamna ca acest lucru se realizeaza o singura data, spre deosebire de cazul in care aceste reguli ar fi trebuit implementate in mod redundant pentru fiecare aplicatie care acceseaza datele.

Flexibilitatea. Se pot crea politici de securitate diferite, pentru instructiuni diferite, adica un set de reguli pentru cazul unei instructiuni SELECT, altul pentru operatiile INSERT si altele pentru UPDATE sau DELETE. De exemplu, un sef de departament ar putea avea voie sa vizualizeze informatiile angajatilor intregii companii dar sa poata modifica doar date legate de angajatii din departamentul sau.

Mai multe politici pentru acelasi obiect

Exista cazuri in care diferite politici de securitate trebuie aplicate pentru diverse aplicatii. FGCA ofera posibilitatea stabilirii mai multor politici pentru acelasi obiect (tabel, vedere). Acestea sunt aplicate simultan folosindu-se sintaxa AND. Pentru a aplica politici diferite insituatii diferite (pentru accesul din aplicatii diferite) se pot defini grupuri de politici si un context de aplicatie care sa gestioneze ce politici sunt aplicate si in ce conditii.

De asemenea se pot stabili si politici default, care sa se aplice automat cand informatia este accesata.

Gruparea politicilor de securitate

Deoarece mai multe aplicatii cu aceleasi politici de securitate pot folosi in comun aceleasi tabele sau vederi este important sa se identifice acele politici de securitate care ar trebui sa fie activate atunci cind respectivele obiecte sunt accesate. De exemplu, daca tabelul angajati contine informatii despre angajatii intregii companii, relevante atat pentru departamentul financiar, cat si pentru departamentul de resurse umane, accesul la date se va face conform a doua politici de securitate diferite, si anume dep. Financiar acceseaza datele in functie de departamente, in timp ce dep. HR acceseaza datele in functie de nivelul ierarhic pe care se afa utilizatorul. Imbinarea regulilor fiecarei aplicatii si realizarea unor politici de securitate comune, ar fi destul de dificila.

FGCA ofera posibilitatea organizarii politicilor de securitate in grupuri. Serverul bazei de date Oracle va folosi contextul de aplicatie va determina care grup de politici sa il aplice la un moment dat, la run-time.

Cresterea performantei

Cu FGCA, fiecare functie ce implementeaza politicile de securitate este evaluata o singura data, in momentul analizarii instructiunii/solicitarii SQL. De asemenea, intrega instructiune modificata dinamic este optimizata si odata analizata poate apoi fi refolosita.

Stabilirea politicilor implicite

Desi este utila impartirea politicilor de securitate intre diverse aplicatii, este de asemenea util sa existe politici de securitate care sa fie mereu aplicate. Astfel, se pot stabili reguli care sa fie valabile indiferent de aplicatia folosita pentru accesarea datelor, si apoi, folosindu-se grupurile de politici sa se aplice, deasupra acestora, reguli specifice securitatii necesare diverselor aplicatii.

Pentru implementarea unei politici de securitate default, aceasta trebuie sa fie adaugata in grupul de politici SYS_DEFAULT

Pasii pentru realizarea FGAC

Controlul accesului granularizat (FGAC) se bazeaza pe instructiuni SQL modificate dinamic. Realizarea acestui control se face urmand pasii de mai jos:

se creaza o functie care implementeaza politica de securitate si care va adauga un predicat unei instructiuni DML emisa de utilizator;

functia este asociata unui tabel ;

utilizatorul executa o intructiune pe tabelul in cauza;

serverul Oracle apeleaza functia creata;

functia modifica in mod dinamic instructiunea initiala adaugand conditi in clauza WHERE;

serverul Oracle executa intructiunea modificata dinamic si returneaza doar informatia permisa.

Application context

Application context permite dezvoltatorilor definirea, setarea si accesarea valoarea atributelor ce caracterieaza aplicatia/sesiunea la un moment dat.

Exista doua tipuri de application context:

Context de aplicatie local (bazat pe sesiune) stocat in UGA (User Global Area) si apelat de fiecare data cand un utilizator se conecteaza la baza de date. Poate fi de doua feluri

Securizat

Bazat pe client

Context de aplicatie global stocat in SGA (System Global Area) folosit pentru utilizatorii din mediile multi-tier care acceseaza baza de date prin intermediul unui connection pool.

Cele mai multe aplicatii contin informatii care pot fi folosite pentru controlul accesului la date, ca de exemplu identitatea utilizatorului poate determina afisarea doar a datelor adaugate de acesta, sau doar a informatiilor legate de departamentul in care acesta lucreaza.

Configurarea unui context de aplicatie se face folosind functia SQL:

SYS_CONTEXT ('namespace', 'parametru'[,dimensiune]

Aceasta functie primeste ca parametrii numele namespace-ului de care apartine atributul a carui valoare se solicita si numele atributului si returneaza valoarea resepctivului atribut. Optional se mai poate furniza un parametru numeric care truncheaza valoarea returnata de functie la dimensiunea specificata de acest parametru.

Un context de aplicatie este un set de perechi nume-valoare, pastrate in memorie, care pot fi definitte, setate si accesate de catre utilizatori si aplicatii. Valorile legate de acelasi domeniu pot fi grupate intre ele, un astfel de grup fiind definit si accesat prin intermediul numelui sau (namespace-ul). In cadrul unui namespace, atributele individuale si valorile lor asociate sunt stocate in memoria privata sau partajata, iar valorile lor sunt accesate prin folosirea uneor functii de apel SQL. Accesul la aceste valori, datorita pastrarii lor in memorie, se realizeaza foarte rapid.

De obicei, un context de aplicatie pastreaza cateva atribute generale, cum ar fi numele unei aplicatii sau a unui utilizator, organizatie, rol sau functie. Politica de securitate poate referi aceste atribute/valori pentru a controla accesul la datele din baza de date.

Fiecare aplicatie poate avea propriul sau contex de aplicatie, cu propriile sale atribute, adaptat nevoior de securitate ale fiecarei aplicatii.

Namespace-ul predefinit USERENV

Oracle furnizeaza un context de aplicatie implicit, pentru fiecare sesiune a bazei de date. Acesta are namespace-ul USERENV. Cele mai multe atribute continute de acesta sunt predefinite de catre baza de date si ofera informatii despre mediul in care se afla utilizatorul. Aceste atribute ofera multe detalii importante desprea sesiunea la baza de date, cum ar fi adresa IP a clientului, identificatorul sesiunii, numele de utilizator al proxy-ului daca se foloseste autenitifcarea prin proxy, protocolul folosit pentru conectarea la baza de date si chiar modul de autentificare al utilizatorului. Multe dintre atributele USERENV pot fi folosite pentru stabilirea datelor care pot fi accesate de utilizatorul respectiv, dar nu pot fi modificate. Atributul Client Identifier (identificatorul clientului) poate fi initializat decatre aplicatie, fiind singura valoare a contextului de aplicatie care poate fi auditata.

Informatiile despre sesiunea curenta, pastrate in USERENV pot fi accesate prin sintaxa:

SYS_CONTEXT (`userenv`, `nume_atribut`)

O lista cu parametrii folositi la apelarea functiei SYS_CONTEXT este prezentata mai jos:

Parametru	Explicatie
AUDITED_CURSORID	Returneaza ID-ul cursorului care a declansat auditarea
AUTHENTICATION_DATA	Data autentificarii
AUTHENTICATION_METHOD	Modul in care s-a autentificat utilizatorul:la nivel de baza de date, sistem de operare, retea sau proxy
CLIENT_IDENTIFIER	Identificatorul utilizatorului, la nivel global
CLIENT_INFO	Informatii despre utilizatorul sesiunii curente
CURRENT_SCHEMA	Schema implicita folosita de sesiunea curenta
CURRENT_SCHEMAID	Identificatorul schemei implicite
CURRENT_SQL	Intructiunea SQL care a generat apelarea functiei ce implementeaza securitatea row-level sau auditarea granularizata.
DB_NAME	Numele bazei de date asa cum este specificat in parametrul de initializare DB_NAME
GLOBAL_CONTEXT_MEMORY	Cantitatea de memorie partajata, in octeti, folosita de contextul de aplicatie global
HOST	Numele masinii de la care se conecteaza clientul
INSTANCE	Numarul de identificare al instantei curente
IP_ADDRESS	Adresa IP a masinii de la care se conecteaza clientul
ISDBA	Returneza TRUE daca utilizatorul are privilegii DBA, sau FALSE in caz contrar.
NETWORK_PROTOCOL	Protocolul de retea folosit
NLS_CALENDAR	Calendarul folosit pentru exprimarea datelor in sesiunea curenta
NLS_CURRENCY	Simbolul de moneda folosit in sesiunea curenta
NLS_DATE_FORMAT	Formatul de data folosit in sesiuea curenta
NLS_SORT	Indica daca sortarile se fac binar sau lingvistic
OS_USER	Numele de utilizator la nivel de sistem de operare pentru utilizatorul conectat
PROXY_USER	Numele utilizatorului care a deschis sesiunea curenta in numele utilizatorului reprezentat de SESSION_USER
PROXY_USERID	Identificatorul utilizatorului care a deschis sesiunea curenta in numele utilizatorului reprezentat de SESSION_USER
SESSION_USER	Numele de utilizator din cadrul bazei de date al utilizatorului conectat
SESSION_USERID	Identificatorul de utilizator din cadrul bazei de date al utilizatorului conectat
SESSIONID	Identificatorul sesiunii de auditare
TERMINAL	Identificatorul sistemului de operare al clientului ce foloseste sesiunea curenta

Se poate crea o vedere pentru afisarea atributelor care vor fi cel mai des folosite, astfel:

CREATE OR REPLACE VIEW v_userenv
AS
SELECT SYS_CONTEXT ('userenv', 'session_user') session_user,
SYS_CONTEXT ('userenv', 'current_user') CURRENT_USER,
SYS_CONTEXT ('userenv', 'current_schema') current_schema,
NVL (SYS_CONTEXT ('userenv', 'external_name'), 'NULL') external_name,
NVL (SYS_CONTEXT ('userenv', 'client_identifier'), 'NULL')
client_identifier,
NVL (SYS_CONTEXT ('userenv', 'client_info'), 'NULL') client_info,
NVL (SYS_CONTEXT ('userenv', 'proxy_user'), 'NULL') proxy_user,
SYS_CONTEXT ('userenv', 'audited_cursorid') audited_cursorid,
SYS_CONTEXT ('userenv', 'entryid') entryid,
NVL (SYS_CONTEXT ('userenv', 'sessionid'), 'NULL') sessionid,
SYS_CONTEXT ('userenv', 'isdba') isdba,
NVL (SYS_CONTEXT ('userenv', 'ip_address'), 'NULL') ip_address,
SYS_CONTEXT ('userenv', 'db_name') db_name,
SYS_CONTEXT ('userenv', 'host') HOST,
NVL (SYS_CONTEXT ('userenv', 'network_protocol'), 'NULL')
network_protocol,
NVL (SYS_CONTEXT ('userenv', 'authentication_type'),
SYS_CONTEXT ('userenv', 'policy_invoker')policy_invoker,
NVL (SYS_CONTEXT ('userenv', 'current_sql'), 'NULL') current_sql
FROM DUAL;

Folosind comanda DESC se pot vedea atributele care sunt disponibile prin aceasta vedere:

DESC v_userenv

Rezultatul va fi:

Name  Null? Type

SESSION_USER  VARCHAR2(256)

CURRENT_USER  VARCHAR2(256)

CURRENT_SCHEMA  VARCHAR2(256)

EXTERNAL_NAME  VARCHAR2(256)

CLIENT_IDENTIFIER  VARCHAR2(256)

CLIENT_INFO  VARCHAR2(256)

PROXY_USER  VARCHAR2(256)

AUDITED_CURSORID  VARCHAR2(256)

ENTRYID  VARCHAR2(256)

SESSIONID  VARCHAR2(256)

ISDBA  VARCHAR2(256)

IP_ADDRESS  VARCHAR2(256)

DB_NAME  VARCHAR2(256)

HOST VARCHAR2(256)

NETWORK_PROTOCOL  VARCHAR2(256)

AUTHENTICATION_TYPE  VARCHAR2(256)

POLICY_INVOKER  VARCHAR2(256)

CURRENT_SQL  VARCHAR2(256)

Pentru a afla valoarea atributelor dorite se efectueaza un SELECT pe aceasta vedere:

SELECT session_user, authentication_type, ip_address FROM v_userenv;

SESSION_US AUTHENTICATION_TYPE IP_ADDRESS

SEC_MGR DATABASE 192.168.0.100

Context de aplicatie local (bazat pe sesiune)

Este un context de aplicatie pentru care informatiile sunt stocate in sesiunea bazei de date creata de utilizator.

Exista doua tipuri de astfel de contexte:

Context de aplicatie securizat, in care informatiile sunt pastrate intr-un namespace specificat prin comanda CREATE CONTEXT. Informatia nu va putea fi modificata decat prin intermediul pachetului specificat de aceasta comanda:

CREATE CONTEXT test USING felicia.package1;

Ca urmare a acestei instructiuni, se stabileste ca singurul program autorizat sa initializeze si sa stearga informatiile din contextul de aplicatie este programul package1 considerat "sigur". Citirea informtiilor se poate face insa prin apelul functiei publice SYS_CONTEXT .

Namespace-urile create in acest mod sunt initializate apeland din cadrul managerului de namespace-uri, o procedura aflata in pachetul DBMS_SESSION, si anume DBMS_SESSION.SET_CONTEXT.

Cel mai utilizat mod de a folosi contextul de aplicatie este pastrarea valorilor rezultate in urma apelarii unei functii sau executarii unei interogari interne sau externe. Executarea functiei/interogarii o singura data si pastrarea informatiilor in contextul de aplicatie va face ca implementarile ce tin de securitate sa fie mult mai rapide in executie, nemaifiind nevoie sa se apeleze respectivele functii/interogari. Acest lucru este foarte util atunci cand valoarea stocata este folosita an cadrul unui predicat SQL sau intr-o clauza WHERE .

De asemenea, initializarea se poate face si extern sau global, caz in care informatiile sunt completate automat, pentru utilizator. In ambele cazuri informatia fiind pastrata la nivelul sesiunii curente a utilizatorului.

Initializarea externa inseamna ca valorile contextului de aplicatie sunt preluate din surse ecxterne cum ar fi un proces al operatiilor in asteptare(job queue process) , o legatura la baza de date, sau un program ce foloseste o interfata OCI (Oracle Call Interface).

Initializarea globala foloseste atribute si valori dintr-o locatie centralizata, cum ar fi un director LDAP(Lightweight Directory Access Protocol

Context de aplicatie client

Acest tip de context foloseste doar namespace-ul CLIENTCONTEXT, updatabil de catre orice client OCI sau prin API-ul existent in pachetul DBMS_SESSION pentru contextul de aplicatie. Namespace-ul CLIENTCONTEXT permite o singura tranzactie din partea aplicatiei care sa modifice informatiile de context ale utilizatorului si sa foloseasca acelasi handle pentru sesiune curenta pentru a indeplini solicitarea noului utilizator.

Contextul de aplicatie global

Acest tip de application context pastreaza informatia in zona de memorie partajata (SGA - System Global Area) astfel incat aceasta poate fi folosita de aplicatii care nu utlizeaza sesiuni, cum ar fi aplicatiile middle-tier intr-o arhitectura pe 3 nivele(three-tier). In aceste cazuri, nu se paote folosi contextul de aplicatie la nivel de sesiune deoarece utilizatorii se autentifica la nivelul aplicatiei si apoi sunt conectati la baza de date ca o singura entitate.

Un context de aplicatie global foloseste atributul CLIENT_IDENTIFIER al namespace-ului USERENV, setat prin interfata oferita de pachetul DBMS_SESSION pentru a asocia o sesiune a bazei de date cu un anumit utilizator sau grup.

Interfata oferita de DBMS_SESSION pentru manipularea contextelor de aplicatie, are un identificator de client pentru fiecare context de aplicatie. Astfel, contextul de aplicatie poate fi administrat global, totusi fiecare client sa nu poata vedea decat contextele de aplicatii asociate.

Urmatoarele interfete din cadrul pachetului DBMS_SESSION permit administratorului sa organizeze aplicatiile de context in sesiuni client:

SET_CONTEXT;

CLEAR_CONTEXT;

CLEAR_ALL_CONTEXT;

SET_IDENTIFIER;

CLEAR_IDENTIFIER

Serverul de aplicatii de la nivelul middle-tier poate folosi SET_CONTEXT pentru a seta contextul de aplicatie pentru un anumit ID de client. Apoi, cand se asociaza o conexiune la baza pentru a procesa cerea clientului, serverul de aplicatii trebuie sa foloseasca SET_IDENTIFIER pentru a stabili identificatorul sesiunii aplicatiei. Ulterior, de fiecare data cand clientul va apela SYS_CONTEXT, doar contextul asociat cu acest identificator va fi returnat

Crearea unei politici VPD folosind Oracle Policy Manager

O alternativa la implementarea policilor VPD, folosind pachetul DBMS_RLS pentru a aplica politicile tabelelor si vederilor, si comanda CREATE_CONTEXT pentru creare contextelor de aplicatii, este folosirea interfatei grafice Oracle Policy Manager, care poate fi accesata din Oracle Enterprise Manager.

Pentru a crea poltici VPD, utilizatorii trebuie sa specifice numele schemei, tabelului sau vederii , numele politicii ce va fi implementata, numele functiei care genereaza predicatul dinamic si tipurile de instructiuni pentru care se aplica politica (adica SELECT, INSERT, UPDATE, DELETE)..

Apoi, Oracle Policy Manager va executa functia DBMS_RLS.ADD_POLICY.

De asemenea, se poate crea si un context de aplicatie furnizand utilitarului numele contextului si pachetul care il implementeaza.

Oracle Policy Manager este de asemenea si utilitarul folosit pentru administrarea Oracle Label Security. OLS permite implementarea politicilor de securitate si control al accesului la nivel de rand, fara a necesita cunoasterea unui limbaj de programare, prin punerea la dispozitie a unui framework pentru implementarea FGAC prin specificarea de etichete pentru utilizatori si date.

Fig. 3.1. - Oracle Policy Manager

Oracle Label Security

OLS (Oracle Label Security este o facilitate a bazleor de date Oracle introdusa incepand cu versiunea 9i. Ea ofera optiuni puternice de control asupra accesului la nivel de rand, fiind foarte utila in cazul bazelor de date de mari dimensiuni.

Practic OLS preia responsabilitatile pe care in trecut apartineau aplicatiilor care accesau bazele de date, si le implementeaza, mai rapid si mai sigur, direct in baza de date. OLS este capabil sa implementeze atat reguli simple, precum capacitatea de a vizualiza date dar de a nu le modifica, precum si orice combinatie de reguli. Validarea regulilor si aplicarea lor se face complet automat, ducand astfel la eficienta si stabilitate pentru aplicatie.

Pentru aceasta, se genereaza automat interogari SQL.

De exemplu, presupunand ca utlizatorul Ana are drepturi limitate la o anumita categorie de randuri dintr-un tabel, desemnata de ID-ul ei (presupunem 123), de fiecare data cand aceasta va utiliza aplicatia se aplica in interogarile SQL conditia

WHERE Nume_Tabel. ID_Utilizator = 123

Mecanismul de functionare al OLS este urmatorul:

Identifica datele care trebuiesc securizate si stabileste politici de securitate.

Fiecarui utilizator i se desemneaza o eticheta unica. Aceste etichete vor permite identificarea drepturilor fiecarui utilizator la nivel de rand.

Pentru fiecare tabel pentru care este necesara securitatea la nivel de rand se genereaza o coloana speciala, care este populata cu etichete.

Se stabileste pentru fiecare rand care permisiuni sunt necesare pentru accesarea sa, si ce actiuni se pot aplic randului respectiv.

Pentru a defini drepturile si permisiunile, se utilizeaza trei seturi de criterii niveluri, compartimente si grupuri

Nivelurile sunt folosite pentru a defini senzitivitatea datelor. Implicit, acestea se impart in: date publice, clasificate, secrete si ultra-secrete;

Compartimentele definesc domeniul de interes al datelor. In mod tipic, aceste compartimente corespund departamentelor fiecarei companii precum contabilitate, vanzari, HR)

Grupurile definesc ariile de interes ale datelor. De exemplu, aceste arii pot sa fie la nivel ierarhic (executiv, management, operational), la nivel geografic (pentru departametul de marketing al unei firme nationale grupurile pot sa fie impartite inTransilvania, Muntenia, Moldova, Banat, Dobrogea)

Combinarea conditiilor este detul de mare. Pentru fiecare rand se pot aloca pana la 10.000 de conditii. In cazul in care nu este nici o conditie specificata unui anumit rand, coloana de etichete va avea valoarea echivalenta conditiei "unrestricted".

Sistemul de lucru este urmatorul

coloana suplimentara de etichete pastreaza campuri de tip numeric;

fiecarui numar ii este atribuita o combinatie unica de drepturi pentru useri.

De fiecare data cand se acceseaza un rand, se verifica setul de conditii asociate randului respectiv prin eticheta atasata. Acest proces se numeste medierea accesului la date.

Pentru stabilirea conditiilor de acces, a nivelurilor, compartimentelor si grupurilor se poate utiliza atat programarea directa prin editarea de scripturi cat si o interfata grafica pusa la dispozitie de catre Oracle Policy Manager.