Securitatea Bazelor de Date In Oracle
1. SECURITATEA DATELOR
Securitatea este o preocupare constanta in proiectarea si dezvoltarea bazelor de date. In mod uzual, nu se pun probleme legate de existenta securitatii, ci mai de graba de cat de mare va fi aceasta. Un SGBD are in mod caracteristic mai multe nivele de securitate, pe langa cele oferite de sistemul de operare sau de retea. De obicei, un SGBD detine conturi pentru utilizatori, care necesita o parola de conectare ce trebuie autentificata pentru a accesa datele.
Un SGBD ofera de asemenea si alte mecanisme cum ar fi grupurile, rolurile, privilegiile si profilurile care dau securitatii mai mult rafinament. Aceste nivele de securitate nu prevad numai constrangeri, ci si stabilirea politicii de securitate. De exemplu, intr-un sistem de electornic banking o companie isi poate deschide un cont la o banca, iar accesul persoanelor din cadrul companiei pentru consultarea contului va fi autorizat printr-un nume si cel putin o parola. In plus, accesul poate fi diferentiat intre diferiti membri ai companiei, numai unora dintre ei fiindu-le permis sa faca si tranzactii asupra contului. Pe de alta parte, personalul bancii poate avea acces la informatii despre toate conturile din banca.
In Oracle, securitatea datelor este asigurata in primul rand prin intermediul utilizatorului de data (in sensul folosit de Oracle, un utilizator al bazei de date este de fapt un cont si nu se identifica cu o persoana care acceseaza baza de date ; in general, mai multe persoane pot folosi acelasi cont de acces). Orice obiect al bazei de date este proprietatea unui utilizator, schema unui utilizator cuprinzand toate obiectele pe care acesta le detine. Pentru a accesa un obiect, un utilizator trebuie fie sa fie proprietarul acelui obiect, fie sa aiba privilegiile necesare pentru aceasta operatie. Privilegiile pot fi acordate direct unui utilizator sau pot fi grupate in roluri, care la randul lor pot fi acordate utilizatorului.
Baza de date Oracle contine propriul ei sistem de securitate care previne accesul neautorizat la baza de date. Sistemul de securitate al bazei de date Oracle este realizat prin intremediul utilizatorilor bazei de date. Serverul bazei de date solicita numele utilizatorului si parola pentru fiecare accesare a bazei de date ; indiferent de utilitarul folosit pentru interfata, serverul bazei de date nu permite accesul la baza de date daca nu este utilizat un nume si o parola corecta.
Nota : Asa cum s-a mai mentiona, in contextul bazei de date Oracle, un utilizator inseamna de fapt un cont de utilizator si nu o persoana care acceseaza baza de date. Evident, o persoana poate accesa baza de date folosind unul sau mai multi utilizatori Oracle, iar mai multe persoane pot accesa baza de date folosind acelasi utilizator Oracle (acesta este cazul cel mai intalnit).
O schema este o colectie de obiecte disponibile unui utilizator. Obiectele schemei sunt structuri logice ce se refera efectiv la datele unei baze de date precum tabele, vederi, secvente, indecsi, sinonime, etc.
Fiecarui utilizator al bazei de date ii sunt acordate anumite drepturi cunoscute sub numele de privilegii. Un privilegiu este permisiunea de a executa o actiune sau de a accesa un obiect apartinand unui alt utilizator. In Oracle, un utilizator nu poate executa nici un fel de actiune fara a avea privilegiul sa o faca. In acest sens unui utilizator ii pot fi acordate sau revocate privilegii.
Accesul unui utilizator la baza de date este administrat printr-un numar de drepturi numite privilegii de sistem, sau privilegii la nivelul bazei de date, care permit utilizatorului sa efectueze operatii precum conectarea la baza de date si crearea de obiecte. Odata ce utilizatorul a creat obiecte ale bazei de date, el este apoi responsabil de a acorda drepturi altor utilizatori pentru obiectele care sunt proprietatea lui. Aceste drepturi sunt numite privilegii la nivel de obiect.
Rolurile sunt utilizate pentru a simplifica administrarea privilegiilor. Astfel, in loc de a acorda un anumit privilegiu direct unui utilizator, privilegiile sunt acordate unui rol, iar un rol este acordat la randul lui unui utilizator. Cu alte cuvinte, rolurile reprezinta un grup de privilegii.
Securiatea datelor este o functie importanta a unui sistem de baze de date, care protejeaza datele impotriva accesului neautorizat. Securitatea datelor are doua componente: protejarea datelor si controlul accesului autorizat.
Protejarea datelor este necesara pentru a nu permite utilizatorilor neautorizati sa inteleaga continutul fizic al datelor. Aceasta functie este oferita, de obicei, de sistemele de operare, centralizate sau distribuite. Principala abordare a protejarii datelor este criptarea lor, lucru util atat in cazul in care informatia este stocata pe disc, cat si cand informatia este transmisa intr-o retea. Datele criptate pot fi decriptate numai de utilizatorii autorizati, care “stiu” codul.
Controlul accesului autorizat trebuie sa se asigure ca numai utilizatorii autorizati efectueaza operatii care le sunt permise asupra bazei de date. Multi utilizatori diferiti pot avea acces la un volum larg de date sub controlul unui singur sistem centralizat sau distribuit. SGBD-ul, centralizat sau distribuit, trebuie sa fie capabil sa restrictioneze accesul unei parti din utilizatori la o parte din date. Controlul accesului autorizat a fost oferit mult timp de catre sistemul de operare, si mai de curand de sisteme de operare distribuite, ca serviciu al sistemului de fisiere. In acest context, este oferit un control centralizat.
Controlul accesului autorizat in sistemele de baze de date difera in anumite privinte de cel din sistemele traditionale de fisiere. Autorizarile trebuie sa ofere unor utilizatori diferiti drepturi diferite pe aceleasi obiecte ale bazei de date. Aceasta necesitate implica specificarea obiectelor mai precis decat dupa nume si diferentierea intre grupurile de utilizatori. Deasemenea, controlul descentralizat al accesului autorizat este important intr-un context distribuit.
Din solutiile pentru controlul autorizat in sistemele centralizate, le putem deduce pe cele din SGBD-uri distribuite. Totusi, exista o complexitate aditionala care provine din faptul ca obiectele si utilizatorii pot fi distribuiti.
Securitatea datelor este o functie importanta a unui sistem de baze de date, care protejeaza datele impotriva accesului neautorizat. Securitatea datelor are doua componente: protejarea datelor si controlul accesului autorizat.
Securiatea unei baze de date presupune monitorizarea actiunilor realizate de utilizatori asupra acesteia sau a obiectelor sale. In acest sens, sistemul foloseste scheme de obiecte pe domenii de securitate.
Un utilizator este un nume definit in baza de date care poate accesa obiectele acesteia. Obiectele bazei de date sunt continute in scheme. Definirea utilizatorilor si a schemelor de obiecte ajuta administratorii sa asigure securitatea bazei de date.
Accesul tuturor utilizatorilor la anumite obiecte este reglementat prin acordarea de privilegii si role-uri. Un privilegiu este permisiunea de a accesa un obiect intr-o maniera predefinita. Un role este un grup de privilegii care poate fi acordat utilizatorilor bazei de date sau altor role-uri.
Atunci cand este creat un utilizator, administratorul bazei de date trebuie sa defineasca un domeniu de securitate pentru acesta. In cadrul domeniului de securitate sunt specificate metodele de autentificare, spatiile tabel implicite si cele temporare, profilul pentru restrictionarea folosirii resurselor bazei, privilegiile si role-urile acordate utilizatorului respectiv.
1.1 Securitate la nivel de sistem
Securitatea la nivel de sistem presupune administrarea adecvata a utilizatorilor, alegerea metodelor de autentificare a acestora si stabilirea securitatii sistemului de operare gazda. Fiecare baza de date are unul sau mai multi administratori care sunt responsabili pentru asigurarea politicilor de securitate (administratori pentru securitate). Daca baza de date are dimensiuni reduse, administratorul bazei poate avea si responsabilitati de securitate.
Utilizatorii sunt cei care acceseaza informatiile din baza de date si de aceea, este deosebit de important modul de administrare al acestora. In general, administratorul pentru securitate este singurul utilizator al bazei de date care are dreptul de administrare al celorlalti utilizatori (creare, modificare, eliminare).
Sistemul furnizeaza mai multe metode de autentificare a utilizatorilor bazei de date, folosind parole, sistemul de operare gazda, servicii de retea sau protocolul SSL (Secure Sockets Layer), autentificare si autorizare de tip proxy.
La nivelul sistemului de operare pe care rezida server-ul si aplicatiile de baze de date trebuie ca:
Administratorii bazei de date sa aiba privilegii de creare, respectiv de stergere a fisierelor;
Utilizatorii obisnuiti ai bazei sa nu detina privilegii de creare sau de stergere a fisierelor utile functionarii bazei de date;
Administratorii pentru securitate sa detina privilegii de modificare a domeniului de securitate pentru conturile disponibile in sistemul de operare (daca identificarea role-urilor pentru utilizatorii bazei de date Oracle se realizeaza prin sistemul de operare)
1.2 Securitate la nivel date
Securitatea la nivel de dateinclude mecanisme de control al accesuluila date si al gradului de utilizare a obiectelor bazei. Se stabilesc utilizatorii care au acces la un anumit obiect si tipurile de actiuni permise asupra sa. In acest sens, se acorda utilizatorilor bazei de date anumite privilegii de sistem si obiect, cate pot fi grupate in role-uri. De asemenea, pentru fiecare obiect al unei scheme sunt definite actiunile care vor fi auditate.
O alta modalitate de stabilire a securitatii la acest nivel este folosirea vizualizarilor. Acestea pot restrictiona accesul la datele unui tabel, prin excluderea unor coloane sau linii. Sistemul permite implementarea politicilor de securitate prin folosirea unor functii si asocierea acestora la tabele sau vizualizari (fine-grained acces control). O astfel de functie genereaza automat o conditie WHERE intr-o instructiune SQL, si astfel se restrictioneaza accesul la anumite linii de date.
1.3 Securitate la nivel de utilizator
Exista doua modalitati generale de stabilire a securitatii la nivel de utilizatori, prin intermediul parolelor si prin acordarea privilegiilor.
Daca autentificarea utilizatorilor este administrata de baza de date, atunci administratorii trebuie sa dezvolte politici de securitate pentru parole. De exemplu, sa impuna utilizatorilor bazei de date sa-si schimbe parolele la anumite intervale de timp, lungimea parolelor sa fie suficient de mare, iar in componenta acestora sa intre atat litere, cat si cifre.
Problema administrarii privilegiilor pentru diferite tipuri de utilizatori este de o deosebita importanta. Pentru baze de date cu multi utilizatori, administrarea privilegiilor este mai eficienta daca se folosesc role-uri. In schimb, atunci cand numarul de utilizatori este scazut, se recomanda sa se acorde privilegii explicite pentru fiecare utilizator si sa se evite folosirea role-urilor.
Administratorul trebuie sa decida care sunt categoriile de grupuri de utilizatori si sa atribuie role-uri fiecarui grup in parte. De asemenea, acesta trebuie sa decida ce privilegii trebuie acordate nominal utilizatorilor.
Administratorii pentru securitate trebuie sa dezvolte politici de securitate inclusiv pentru administratorii bazei de date. Pentru baze foarte mari, care necesita mai multi administratori, administratorul pentru securitate trebuie sa decida care sunt grupurile de privilegii de administrare si sa le includa in role-uri de administrare. Pentru baze de date mici este suficienta crearea unui singur role specific si acordarea acestuia tuturor administratorilor bazei.
De asemenea, administratorii pentru securitate trebuie sa creeze politici de securitate pentru dezvoltatorii pentru securitate sa detina privilegii de modificare a domeniului de securitate pentru conturile disponibile in sistemul de operare (daca identificarea role-urilor pentru utilizatorii bazei de date Oracle se realizeaza prin sistemul de operare)
1.2 Securitate la nivel date
Securitatea la nivel de dateinclude mecanisme de control al accesuluila date si al gradului de utilizare a obiectelor bazei. Se stabilesc utilizatorii care au acces la un anumit obiect si tipurile de actiuni permise asupra sa. In acest sens, se acorda utilizatorilor bazei de date anumite privilegii de sistem si obiect, cate pot fi grupate in role-uri. De asemenea, pentru fiecare obiect al unei scheme sunt definite actiunile care vor fi auditate.
O alta modalitate de stabilire a securitatii la acest nivel este folosirea vizualizarilor. Acestea pot restrictiona accesul la datele unui tabel, prin excluderea unor coloane sau linii. Sistemul permite implementarea politicilor de securitate prin folosirea unor functii si asocierea acestora la tabele sau vizualizari (fine-grained acces control). O astfel de functie genereaza automat o conditie WHERE intr-o instructiune SQL, si astfel se restrictioneaza accesul la anumite linii de date.
1.3 Securitate la nivel de utilizator
Exista doua modalitati generale de stabilire a securitatii la nivel de utilizatori, prin intermediul parolelor si prin acordarea privilegiilor.
Daca autentificarea utilizatorilor este administrata de baza de date, atunci administratorii trebuie sa dezvolte politici de securitate pentru parole. De exemplu, sa impuna utilizatorilor bazei de date sa-si schimbe parolele la anumite intervale de timp, lungimea parolelor sa fie suficient de mare, iar in componenta acestora sa intre atat litere, cat si cifre.
Problema administrarii privilegiilor pentru diferite tipuri de utilizatori este de o deosebita importanta. Pentru baze de date cu multi utilizatori, administrarea privilegiilor este mai eficienta daca se folosesc role-uri. In schimb, atunci cand numarul de utilizatori este scazut, se recomanda sa se acorde privilegii explicite pentru fiecare utilizator si sa se evite folosirea role-urilor.
Administratorul trebuie sa decida care sunt categoriile de grupuri de utilizatori si sa atribuie role-uri fiecarui grup in parte. De asemenea, acesta trebuie sa decida ce privilegii trebuie acordate nominal utilizatorilor.
Administratorii pentru securitate trebuie sa dezvolte politici de securitate inclusiv pentru administratorii bazei de date. Pentru baze foarte mari, care necesita mai multi administratori, administratorul pentru securitate trebuie sa decida care sunt grupurile de privilegii de administrare si sa le includa in role-uri de administrare. Pentru baze de date mici este suficienta crearea unui singur role specific si acordarea acestuia tuturor administratorilor bazei.
De asemenea, administratorii pentru securitate trebuie sa creeze politici de securitate pentru dezvoltatorii de aplicatii care se conecteaza la baza de date. Pentru crearea obiectelor, se pot acorda privilegii direct dezvoltatorilor sau numai administratorilor bazei, care sa defineasca obiectele la cererea acestora.
Dezvoltatorii de aplicatii sunt singurii utilizatori ai bazei de date care necesita grupuri speciale de privilegii. Spre deosebire de utilizatorii finali, acestia au nevoie de privilegii sistem specifice activitatii lor. Privilegiul sistem CREATE este acordat dezvoltatorilor, pentru ca acestia sa poata crea obiectele necesare in aplicatii. Daca dezvoltatorii de aplicatii au privilegii pentru crearea obiectelor, administratorul pentru securitate trebuie sa controleze limitele de folosire a spatiului bazei de date pentur fiecare dezvoltator in parte.
Administratorii pentru securitate trebuie sa defineasca proceduri de verificare (audit) pentru baza de date. Se poate impune ca aceste proceduri sa fie active doar pentru anumite actiuni sau se pot face verificari prin selectie aleatoare. Administratorul trebuie sa decida care este nivelul minimal la care se fac aceste verificari.
In cazul sistemelor mari de baze de date, pe care ruleaza multe aplicatii, trebuie sa existe administratori pentru aplicatii. Acestia sunt responsabili pentru:
Crearea si administrarea obiectelor folosite de aplicatiile bazei;
Crearea role-urilor corespunzatoare aplicatiilor si gestiunea privilegiilor asociate fiecarui astfel de role;
Mentinerea si modificarea codului aplicatiilor, procedurilor si pachetelor Oracle, daca acest lucru este necesar;
De cele mai multe ori, administratorul pentru aplicatii este unul din dezvoltatorii care analizeaza si proiecteaza aplicatia.
Protejarea datelor este necesara pentru a nu permite utilizatorilor neautorizati sa inteleaga continutul fizic al datelor. Aceasta functie este oferita, de obicei, de sistemele de operare, centralizate sau distribuite. Principala abordare a protejarii datelor este criptarea lor, lucru util atat in cazul in care informatia este stocata pe disc, cat si cand informatia este transmisa intr-o retea. Datele criptate pot fi decriptate numai de utilizatorii autorizati, care “stiu” codul.
Controlul accesului autorizat trebuie sa se asigure ca numai utilizatorii autorizati efectueaza operatii care le sunt permise asupra bazei de date. Multi utilizatori diferiti pot avea acces la un volum larg de date sub controlul unui singur sistem centralizat sau distribuit. SGBD-ul, centralizat sau distribuit, trebuie sa fie capabil sa restrictioneze accesul unei parti din utilizatori la o parte din date. Controlul accesului autorizat a fost oferit mult timp de catre sistemul de operare, si mai de curand de sisteme de operare distribuite, ca serviciu al sistemului de fisiere. In acest context, este oferit un control centralizat.
Controlul accesului autorizat in sistemele de baze de date difera in anumite privinte de cel din sistemele traditionale de fisiere. Autorizarile trebuie sa ofere unor utilizatori diferiti drepturi diferite pe aceleasi obiecte ale bazei de date. Aceasta necesitate implica specificarea obiectelor mai precis decat dupa nume si diferentierea intre grupurile de utilizatori. Deasemenea, controlul descentralizat al accesului autorizat este important intr-un context distribuit.
Din solutiile pentru controlul autorizat in sistemele centralizate, le putem deduce pe cele din SGBD-uri distribuite. Totusi, exista o complexitate aditionala care provine din faptul ca obiectele si utilizatorii pot fi distribuiti.
1.4 Controlul accesului autorizat in sistemele centralizate
Trei actori principali sunt implicati in controlul accesului autorizat: utilizatorii, care declanseaza executia aplicatiilor; operatiile, care sunt incluse in aplicatii; obiectele bazei de date asupra carora se efectueaza operatiile. Controlul accesului autorizat consta in validarea unui triplet: (utilizator, operatie, obiect). O autorizare poate fi vazut ca un triplet (utilizator, tipul operatiei, definitia obiectului) care specifica daca acel utilizator are dreptul de a efectua o operatie de acel tip asurpa obiectului. Pentru a controla autorizarile corect, un SGBD necesita definirea utilizatorilor, a obiectelor si a drepturilor.
Introducerea unui utilizator (o persoana sau un grup de persoane) in sistem se face de obicei printr-o pereche (nume utilizator, parola). Numele utilizatorului identifica in mod unic utilizatorul, in timp ce parola, stiuta numai de acel utilizator, autentifica utilizatorul. Amandoua sunt cerute la conectarea la sistem.
Obiectele care trebuie protejate sunt submultimi ale bazei de date. Intr-un sistem relational obiectele poti fi definite dupa tipul lor (vederi, relatii, tupluri, atribute) cat si dupa continutul lor, folosind predicate de selectie. Deasemenea, mecanismul vizualizarilor permite protejarea obiectelor prin simpla ascundere a unor submultimi ale relatiilor (atribute sau tupluri).
Un drept exprima o relatie intre un utilizator si un obiect pentru un anumit set de operatii. Controlul accesului autorizat poate fi caracterizat prin cine anume acorda drepturile. In cea mai simpla forma a sa, controlul este centralizat: un singur utilizator, sau o clasa de utilizatori, respectiv administratorul bazei de date are toate privilegiile asupra obiectelor. El este singurul care are acces la instructiunile GRANT (acordare) si REVOKE (revocare).
Un privilegiu este dreptul de a executa anumite comenzi SQL. Privilegiile pot include dreptul de: conectare la baza de date, creare de tabele, selectare a liniilor din tabelul altui utilizator, executie a procedurilor stocate create de alt utilizator etc. Privilegiile trebuie sa fie acordate utilizatorilor numai daca sunt absolut necesare in activitatea acestora. Acordarea excesiva de privilegii poate compromite securitatea bazei de date. Privilegiile pot fi de tip sistem sau obiect.
Un role este un grup de privilegii inrudite care pot fi acordate sau revocate simultan utilizatorilor sau altor role-uri. Folosirea role-urilor permite:
simplificarea administrarii privilegiilor (in loc sa se acorde mai multe privilegii intr-un mod explicit unui grup de utilizatori inruditi, se poate crea un role care sa contina toate privilegiile necesare si apoi sa se acorde acest role fiecarui membru al grupului);
administrarea dinamicaa privilegiilor (daca privilegiile unui grup de utilizatori trebuie schimbate, modificarea lor se va face la nivelul role-ului care le contine si aceasta se propaga automat pentru fiecare utilizator care are asociat role-ul respectiv);
activarea selectiva a privilegilor (role-urile pot fi activate sau dezactivate selectiv, astfel incat se permite un control ridicat al privilegiilor acordate utilizatorilor);
1.5 Administrarea utilizatorilor si resurselor
In functie de licentele primate pentru sistemul Oracle, trebuie limitat numarul de sesiuni concurente si de utilizatori conectati la baza de date. Aceasta se realizeaza prin setarea parametrilor de initializare de tip LICENSE.
Licentele pentru folosirea concurenta limiteaza numarul de sesiuni care pot fi conectate simultan la baza de date. Numarul maxim de sesiuni concurente (LICENSE _MAX_SESSIONS) poate fi precizat inainte de a porni instanta si modificat in timp ce baza de date este pronita. Atunci cand aceasta limita este atinsa, sistemul va trimite utilizatorilor un mesaj prin care ii anunta acest lucru. In acest caz, se pot conecta la baza de date numai utilizatorii care au privilegiul RESTRICTED SESSION.
Limitarea numarului de utilizatori restrictioneaza numarul autorizarilor individuale de folosire a sistemului. Precizarea numarului maxim de utilizatori care pot fi creati in baza se face inainte de pornirea unei instante (LICENSE_MAX_USERS). Aceasta limita poate fi modificata in timpul functionarii instantei, prin folosirea comenzii ALTER SYSTEM. Dupa depasirea ei, nu mai pot fi creati noi utilizatori. In acest caz, sistemul va trimite un mesaj prin care anunta ca numarul maxim de utilizatori permisi a fost atins.
Vizualizarea V$LICENSE din dictionarul datelor permite identificarea setarilor curente privind limitarile impuse, numarul curent de sesiuni utilizatorilor si numarul maxim de sesiuni concurente atins de la momentul pornirii instantei.
1.6 Metode de autentificare a utilizatorilor
Pentru a preveni folosirea neautorizata a unui cont de utilizator (username), sistemul Oracle realizeaza validarea utilizatorilor prin diferite metode, intainte ca acestia sa initieze o sesiune de lucru cu baza de date :
autentificare prin baza de date, folosind parole ;
autentificare externa, prin sistemul de operare sau servicii de retea
autentificare globala, prin protocolul de securitate SSL
autentificare proxy, daca utilizatorii se conecteaza la baza de date printr-un server de aplicatii
In general, este folosita aceiasi metoda pentru autentificarea tuturor utilizatorilor bazei de date. Totusi, sistemul Oracle permite abordarea tuturor metodelor de autentificare, in cadrul aceleiasi instante a bazei.
Sistemul necesita proceduri speciale de autentificare, in cadrul aceleiasi instante a bazei.
Sistemul necesita proceduri speciale de autentificare pentru administratorii bazei de date, deoarece ei pot executa operatii importante asupra acesteia.
In cazul autentificarii prin baza de date, administrarea conturilor, respectiv a parolelor si validarea utilizatorilor sunt realizate in intregime de catre sistem. Pentru fiecare utilizator se definesc parole de acces. Din motive de securitate acestea pot fi stocate in format criptat.
Daca se foloseste autentificarea externa, atunci conturile utilizatorilor sunt intretinute de sistem, iar administrarea parolelor si autentificarea utilizatorilor se fac printr-un serviciu extern (sistemul de operare sau un serviciu retea, de exemplu Oracle Net). Conturile utilizatorilor bazei de date vor fi formate dintr-un prefix urmat de numele conturilor acestora din sistemul de operare. Prefixul este setat prin parametrul de initializare OS_AUTHENT_PREFIX. Daca valoarea acestuia este modificata, conturile care folosesc vechiul prefix sunt invalide. Valorarea implicita a parametrului este OPS$.
Un utilizator care incearca sa se conecteze la baza de date Oracle, va fi autentificat de sistemul de operare. Daca in acest sistem utilizatorul are contul nume, atunci conectarea la baza de date este permisa doar daca sistemul Oracle contine contul corespondent al utilizatorului la nivelul bazei de date (OPS$nume).
Beneficiile autentificarii prin sistemele de operare sunt :
utilizatorii se pot conecta la sistemul Oracle in mod conventional, fara sa foloseasca un cont si o parola (de exemplu, un utilizator poate sa invoce utilitarul SQL*Plus, lasand direct comanda SQLPLUS/) ;
controlul autorizarii utilizatorilor este centralizat in sistemul de operare (in baza de date nu trebuie stocate si administrate parolele utilizatorilor).
Sistemul Oracle poate utiliza un serviciu de retea (DCE, Kerberos, SESAME etc.) pentru autentificarea utilizatorilor. Pentru aceasta trebuie folosit Oracle9i Enterprise Edition cu optiunea Oracle Advanced Security.
Serviciul de autentificare externa prin retea foloseste infrastructuri cu chei publice (PKI). Elementele fundamentale ale acestora sunt certificatele digitale, autoritatile de certificare si facilitatile de administrare a certificatelor. In functionarea sistemelor cu chei publice este necesar un sistem de generare, circulatie si autentificare a cheilor folosite de utilizatori. Autoritatile de certificare distribuie certificate de chei autentificate. Certificatul reprezinta o asociere imposibil de falsificat dintre o cheie publica si un anumit atribut al posesorului sau. El poarta semnatura digitala a unei autoritai de certificare, care, in acest fel, confirma identitatea subiectului.
Sistemele de autentificare care folosesc infrastructuri cu chei publice elibereaza utilizatorilor certificate digitale, pentru autentificarea directa la server.
Infrastructura cu chei publice folosita de Oracle are componentele :
protocolul SSL (indepdendent de platforma si de aplicatie, care furnizeaza servicii de autentificare, compresie de date, criptare si intergritate a datelor pentru o serie de protocoale Internet la nivel aplicatie), pentru autentificarea si gestiunea sigura a cheilor ;
utilitarul Oracle Call Interface si functii Pl/SQL pentru folosirea semnaturii digitale si verificarea acesteia utilizand certificatul asociat ;
certificate pentru utilizatori, eliberate de autoritate de certificare care ofera un nivel ridicat de incredere ;
portofele virtuale, care contin cheia private a utilizatorului, certificatul de autentificare si lista certificatelor de baza prin care utilizatorul obtine un nivel ridicat de incredere
Oracle Wallet Manager, o aplicatie Java folosita pentru gestiunea si editarea scrisorilor de acreditare din portofelele virtuale (protejeaza cheile utilizatorilor, gestioneaza C.509v3) pe server-ele Oracle, genereaza perechi de chei publice si private, creeaza cereri de certificare catre autoritatea de certificare, instaleaza certificate, configureaza coertificate de incredere, deschise un portofel Oracle pentru a accesa un PKI, creeaza portofele care pot fi deschise folosind Oracle Enterprise Login Assistant) ;
Certificate de tip X.509v3, obtinute de la autoritati de certificare externe sistemului Oracle ;
instrumentul Oracle Enterprise Security Manager, pentru gestiunea centralizata a privilegiilor ;
serviciul Oracle Internet Directory, care permite configurarea si administrarea centralizata a utilizatorilor, incluzand privilegii si atribute de securitate pentru autentificarea acestora cu certificate X.509.
utilitarul Oracle Enterprise Login Assistant, pentru deschiderea sau inchiderea portofelului virtual al unui utilizator si activarea sau dezactivarea comunicatiilor unei aplicatii securizate prin SSL.
Prin autentificarea globala, utilizatorii sunt identificati in baza de date ca utilizatori globali, folosind protocolul SSL. Administrarea utilizatorilo se face in afara bazei de date, prin centralizarea acestora intr-un director, numit director de servicii (directory service). Role-urile globale sunt definite in baza de date, dar autorizatiile pentru acestea se acorda prin directorul de servicii. Avantajul gestionarii centralizate consta in posibilitatea definirii de utilizatori si role-uri la directorul de servicii, pentru fiecare baza de date la care trebuie sa aiba acces. Solutia este crearea de utilizatori independenti de schema, ceea ce le permite acestora sa foloseasca o schema in comun.
Procesul de creare a unui utilizator independent de schema presupune :
crearea unei schmeme partajate la nivelul bazei de date, folosind comanda CREATE USER nume_schema INDENTIFIED GLOBALLY AS ‘specificatie_identificare’;
crearea utilizatorilor globali in directorul de servicii si asocierea lor la aceasta schema.
In cazul configurarii multitier, autentificarea proxy presupune verificarea dreptului de acces al server-ului de aplicatii la baza de date, protejand identitatea si privilegiile client-ilor de-a lungul tuturor nivelurilor si verificand doar actiunile realizate in favoarea acestora. De asemenea, sunt controlate actiunile pe care server-ul de aplicatii le initiaza in nume propriu.
Sistemul Oracle ofera doua forme de autentificare proxy :
daca client-ul este o aplicatie sau un utilizator global, atunci el va fi autentificat de catre severul-ul de aplicatii ;
daca client-ul este un utilizator al bazei de date, atunci el nu va fi autentificat de catre server-ul de aplicatii (identitatea client-ilor si parolele trec prin server-ul de aplicatii catre server-ul de baze de date unde are loc autentificarea) ;
Pentru a putea sa actioneze in favoarea client-ului, server-ul de aplicatii este autorizat de catre adiministrator.
Principalul avantaj al arhitecturii multitier este acela ca permite mai multor client-i sa aiba acces la server-ul de date, printr-un server de aplicatii, fara sa fie necesare conexiuni separate.
Intr-un mediu multitier autentificarea se realizeaza in trei etape :
aplicatia client trimite dovada autenticitatii catre server-ul de aplicatii (parola sau certificat) ;
server-ul de baze de date verifica autenticitatea client-ului si apoi se autentifica si el la server-ul de baze de date ;
server-ul de daze de date verifica autenticitatea server-ului de aplicatii, existenta client-ului si faptul ca server-ul de aplicatii are dreptul de conectare pentru client-ul respectiv
1.7 Administrarea utilizatorilor
Fiecare baza de date Oracle contine o lista de utilizatori. Pentru a accesa baza de date, un utilizator trebuie sa execute o aplicatie a bazei si sa se conecteze o instanta a acesteia, folosind un cont valid definit in baza.
Crearea unui utilizator se realizeaza prin comanda CREATE USER. Pentru a avea dreptul de folosire a acestei comenzi este necesar privilegiul sistem CREATE USER. In general, administratorul pentru securitate este singurlui care are acest privilegiu. Crearea unui utilizator consta in definirea identitatii sale (nume si parola), specificarea profilului, a spatiului table implicit, a cotei de folosire a spatiului table si a spatiului table temporar in care sunt create segmentele temporare.
Forma simplificata a comenzii CREATE USER este urmatoarea:
CREATE USER nume_utilizator
IDENTIFIED
{ BY parola l EXTERNALLY
l GLOBALLY AS’CN=nume_user, alte_atribute_de_identificare’}
[DEFAULT TABLESPACE nume_spatiu_tabel]
[TEMPORARY TABLESPACE nume_spatiu_tabel]
[QUOTA {intreg [{K l M}] l UNLIMITED} ON nume_spatiu_tabel]
[PROFILE nume_profil]
[PASSWORD EXPIRE]
[ACCOUNT { LOCK l UNLOCK}]};
Numele unui utilizator trebuie sa fie unic. Un utilizator si un role nu pot avea acelasi nume. Modul de autentificare poate fi realizat prin baza de date (IDENTIFIED BY parola), extern (IDENTIFIED EXTERNALLY) sau prin protocolul SSL (IDENTIFIED GLOBALLY AS ‘specificatie_identificare’). Sirul specificatie_identificare furnizeaza un mod de identificare la nivelul directorului de servicii.
Fiecare utilizator trebuie sa aiba asociat un spatiu tabel implicit (DEFAULT TABLESPACE) in care sistemul stocheaza obiectele create de utilizator, daca nu se specifica un alt spatiu tabel pentru acestea. Spatiul tabel implicit este SYSTEM.
Pentru fiecare utilizator se poate specifica un spatiu tabel temporar. Acest spatiu tabel este folosit pentru stocarea segmentelor temporare care sunt necesare comenzilor SQL initiate de cate utilizator. Daca nu este specificat un spatiu table temporar, sistemul aloca in mod implicit utilizatorului spatiul tabel temporar care a fost definit la crearea bazei de date. Daca nici acesta nu a fost specificat, spatiul table temporar implicit este SYSTEM.
Cu scopul de a preveni consumul excesiv al spatiului bazei de date se pot preciza limite de folosire (cote) pentru spatiile tabel la care are acces utilizatorul. Aceste limite sunt specificate prin clauza QUOTA. Daca limita spatiului tabel este 0, atunci utilizatorul nu mai poate crea obiecte noi, iar pentru obiectele noi, iar pentru obiectele existente in spatiul tabel respectiv acesta nu ami poate aloca spatiu suplimentar. Optiunea UNLIMITED presupune folosirea nelimitata a spatiului tabel respectiv.
Privilegiul sistem UNLIMITED TABLESPACE premite utilizatorilor sa detina spatiu tabel nelimitat. Acest privilegiu are prioritate fata de toate limitele specificate pentru spatiile tabel alocate utilizatorului respectiv.
De asemenea, la crearea unui utilizator se poate specifica profilul acestuia. Profilurile faciliteaza administrarea parolelor si a limitelor de folosire a resurselor. Daca nu este specificat nici un profil, se asociaza unul implicit.
Clauza PASSWORD EXPIRE presupune ca parola utilizatorului trebuie schimbata la prima conectare la baza de date.
Pentru blocarea sau deblocarea contului unui utilizator este folosita clauza ACCOUNT, cu optiunile LOCK, respectiv UNLOCK.
Exemplu:
Sa se creeze utilizatorul liviana, identificat prin parola liviana. Utilizatorului I se asociaza spatiu tabel users cu posibilitatea de a folosi maxim 5MB din acesta. Limitarea folosirii resurselor bazei de date este definita de profilul user_p.
CREATE USER liviana
IDENTIFIED BY liviana
DEFAULT TABLESPACE users
QUOTA 5M ON users
PROFILE user_p;
Sa se creeze utilizatorul angajat cu optiunea de autentificare externa.
CREATE USER angajat
IDENTIFIED EXTERNALLY
DEFAULT TABLESPACE users
QUOTA 15M ON users
PROFILE user_p;
Pentru a modifica o optiune a domeniului de securitate al unui utilizator (modul de autentificare, limitele unui spatiu table, revocarea unui spatiu tabel, profilul) este necesar privilegiul sistem ALTER USER. De obicei, acesta este detinut doar de administratorul de securitate. Comanda folosita este ALTER USER, iar modificarile specificate prin aceasta nu afecteaza sesiunea curenta a utilizatorului.
Singura optiune pe care fiecare utilizator o poate modifica pentru propriul cont este parola. Pentru aceasta nu este necesar un privilegiu de sistem special, altul decat cel de conectare la baza de date. Comanda folosita are urmatoarea sintaxa:
ALTER USER nume_utilizator IDENTIFIED BY parola;
Stergerea unui utilizator implica eliminarea acestuia si a schemei asociate, din dictionarul datelor, ceea ce determina stergerea imediata a tuturor obiectelor continute in schema. Daca se doreste pastrarea schemei unui utilizator, iar acesta trebuie sa piarda dreptul de a accesa baza de date, i se va revoca utilizatorului respectiv privilegiul CREATE SESSION.
Nu se poate elimina un utilizator care este conectat la baza de date. Pentru a putea elimina un utilizator este necesar privilegiul sistem DROP USER. Daca schema utilizatorului contine obiecte, trebuie folosita optiunea CASCADE pentru a sterge atat utilizatorul, cat si toate obiectele asociate, inclusiv cheile externe care refera tabelele detinute de utilizator. Daca utilizatorul are obiecte asociate si nu este utilizata aceasta clauza, atunci sistemul returneaza un mesaj de eroare, utilizatorul nefiind eliminat. Sintaxa comenzii folosite pentru stergerea unui utilizator este:
DROP USER nume_utilizator [CASCADE];
Fiecare baza de date contine un grup de utilizatori numit PUBLIC. Deoarece orice utilizator al bazei de date face parte in mod automat din grupul PUBLIC, privilegiile si role-urile acordate acestui grup sunt accesibile tutror utilizatorilor. Ca membru al acestui grup utilizatorul poate consulta toate tablele din dictionarul datelor prefixate de USER sau ALL.
Se pot acorda sau revoca grupului PUBLIC orice privilegii sistem, privilegii obiect sau role-uri. Din motive de securitate, este recomandabil sa se acorde doar privilegiile sau role-urile care ii intereseaza pe toti membrii grupului. Acordarea sau revocarea unor privilegii sistem sau obiect grupului PUBLIC poate conduce la recompilarea vizualizarilor, procedurilor, functiilor, pachetelor si declansatorilor.
Grupul PUBLIC are urmatoarele restrectii:
nu se pot asocia cote spatiilor tabel detinute de grup, insa se poate acorda acestuia privilegiul sistem UNLIMITED TABLESPACE;
se pot crea legaturi de baze de date sau sinonime publice (prin comanda CREATE PUBLIC {DATABASE LINK l SYNONYM}), acestea fiind singurele obiecte detinute de grupul PUBLIC.
1.8 Administrarea parolelor si a resurselor utilizand profiluri
Un profil este un set de limitari de resurse care poate fi atribui nui utilizator al bazei de date. Fiecare baza Oracle permite definirea unui numar nelimitate de profiluri. Acestea trebuie create si administrate doar daca politica de securitate a bazei de date cere ca utilizarea resurselor sa fie limitata. Pentru a putea folosi profilurile, mai intai se creeaza categorii de grupuri de utilizatori similari.
Profilurile pot fi atribuite fiecarui utilizator in parte (folosind comanda CREATE USER sau ALTER USER) sau se pot defini profiluri implicite care sunt asociate tuturor utilizatorilor care nu au un profil specific.
Pentru a crea un profil este necesar privilegiul sistem CREATE PROFILE. In momentul crearii se pot explicita limitele folosirii unor resurse particulare sau parametrii pentru parole.
Comanda prin care se creaza un profil este urmatoarea:
CREATE PROFILE nume LIMIT
[SESSIONS_PER_USER valoare]
[CPU_PER_SESSION valoare]
[CPU_PER_CALL valoare]
[CONNECT_TIME valoare]
[IDLE_TIME valoare]
[LOGICAL_READS_PER_SESSION valoare]
[LOGICAL_READS_PER_CALL valoare]
[PRIVATE_SGA valoare]
[COMPOSITE_LIMIT valoare]
[FAILED_LOGIN_ATTEMPTS valoare]
[PASSWORD_LIFE_TIME valoare]
[PASSWORD_REUSE_TIME valoare]
[PASSWORD_REUSE_MAX valoare]
[PASSWORD_LOCK_TIME valoare]
[PASSWORD_GRACE_TIME valoare]
[PASSWORD_VERIFY_FUNCTION {funtie l NULL l DEFAULT} ];
Pentru fiecare parametru care apare in comanda se poate preciza o valoare intreaga sau optiunea UNLIMITED, respectiv DEFAULT. Optiunea UNLIMITED indica posiblitatea de folosire nelimitata a resursei respective. Daca se foloseste DEFAULT, atunci limita de folosire a resursei va fi preluata din profilul implicit.
Fiecare baza de date are un profil implicit. Toate limitarile de resurse nespecificate pentru profilurile particulare vor fi setate automat la valorile implicite. La carearea bazei de date server-ul Oracle defineste profilul implicit DEFAULT.
Sistemul Oracle poate autentifica utilizatorii folosind informatii stocate in baza de date. Cea mai importanta informatie de autentificare o reprezinta parola asociata unui utilizator. Aceasta este cripatata si stocata in dictionarul datelor. Utilizatorul poate oricand sa-si schimbe propria parola.
Pentru a asigura confidentialitatea parolelor, sistemul permite criptarea acestora in timpul conexiunilor din retea (client/server sau server/server). Daca este activata aceasta functionalitate atat pe masina client, cat si pe server, sistemul codifica parolele inainte de a le trimite in retea, folosind o versiunde modificata a algoritmului de criptare DES (Data Encryption Standard).
Daca utilizatorul introduce parola gresit de un numar specificat de ori, sistemul blocheaza contul asociat acestuia. In functie de modul de configurare, contul poate fi deblocat automat, dupa un interval specificat de timp, sau manual, de adiministratorul bazei de date. Prin parametrul FAILED_LOGIN_ATTEMPTS se precizeaza numarul de conectari care pot esua inainte de blocarea contului, iar prin parametrul PASSWORD_LOCK_TIME numarul de zile in care acesta va fi blocat.
Administratorul bazei de date poate bloca manual un cont, folosind comanda ALTER USER. In acest caz, contul nu mai poate fi deblocat automat, administratorul trebuind sa-l blocheze explicit.
Prin parametrul PASSWORD_LIFE_TIME se poate specificat durata de viata a unei parole. Dupa aceasta perioada, parola expira si trebuie schimbata. La prima incercare de conectare dupa expirare apare, apare un mesaj prin care utilizatorul este atentionat ca trebuie sa-ti schimbe parola intr-un anumit numar de zile (perioada in care are inca dreptul de conectare). Aceasta perioada este precizata prin parametrul PASSWORD_GRACE_TIME. Daca parola nu este schimbata pana la terminarea perioadei de gratie , atunci contul se blocheaza automat.
Se recomanda ca schimbarea parolelor sa nu se faca folosind comanda ALTER USER, deoarece aceasta nu realizeaza verificarea completa a complexitatii parolei. Este preferabil ca pentru schimbarea unei parole sa se utilizeze functia OCIPasswordChange().
Pentru a verifica daca o parola nou specificata nu a mai fost utilizata anterior este mentinuta o istorie a parolelor. Prin parametrul PASSWORD_REUSE_TIME se poate preciza intrevalul de timp (exprimat in numar de zile) in timpul executiei script-ului utlpwdmg.sql, server-ul Oracle creeaza in schema SYS functia implicita VERIFY_FUNCTION care asigura verificarea complexitatii unei parole. Aceasta verifica daca parola indeplineste urmatoarele conditii:
are lungimea de cel putin 4 caractere
nu coincide cu username-ul
include cel putin o litera, o cifra si un caracter special
nu este un cuvand simplu din lista de notiuni interne (de exemplu, numele contului, al bazei de date sau al utilizatorului etc.)
difera de parola anterioara cu cel putin 3 caractere
Rutina de verificare a complexitatii parolelor poate fi modificata sau se paote crea o rutina nou, in schma SYS. Comanda CREATE PROFILE permite, prin intermediul parametrului PASSWORD_VERIFY_FUNCTION, precizarea unei functii PL/SQL pentru verificarea complexitatii prolelor.
Pentru fiecare utilizator, sistemul permite specificarea unei limite de folosire a resurselor disponibile, in cadrul domeniului sau de securitate. Astfel, se controleaza consumul resurselor importante ale sistemului. Limitarea resurslor este o metoda deoseit de utila in cazul sistemelor multiuser, unde acestea sunt costisitoare. Consumul excesiv al resurselor, de catre unul sau mai multi utilizatori, poate fi in detrimentul celorlalti utilizatori ai bazei de date.
Sistemul poate controla utilizarea resurselor la nivel de sesiune (session level), la nivel de apel (call level) sau la ambele niveluri.
In momentul conexiunii unui utilizator la o baza de date se creeaza o sesiune. Fiecare sesiune consuma timp CPU (timp de incarcare al procesorului) si memorie. Daca utilizatorul depaseste limita de consum a resurselor, sistemul anuleaza comanda curenta si returneaza un mesaj prin care indica depasirea limitei si sunt permise doar operatii de tip COMMIT. ROLLBACK sau deconectare. Toate celelalte operatii produc erori.
Sistemul permite si limitarea altor resurse la nivel de sesiune: numarul de sesiuni concurente pentru fiecare utilizator, timp in care o sesiune poate ramane inactiva, timpul de conectare consumat pentru fiecare sesiune, spatiul SGA (folosit de zonele private SQL) al unei sesiuni etc.
Pentru procesarea comenzilor SQL sau a altor tipuri de apeluri catre sistem este necesar un timp CPU. In medie, apelurile nu sunt mari consumatoare de timp CPU. In schimb, o comanda SQL poate implica multe interogari care pot fi mari consumatoare ale acestei resurse. Pentru a preveni folosirea inadecvata a timpului CPU, se pot fixa limite pentru fiecare apel in parte sau pentru apelurile din cadrul unei anumite sesiuni.
Operatiile I/O sunt unele dintre cele mai costisitoare operatii intr-un sistem de baze de date. De aceea, sistemul permite limitarea citirilor blocurilor logice de date, la nivel de apel sau de sesiune. Citirea blocurilor logice de date include citirea blocurilor de date din memorie si de pe disc. Limitarile presupun numararea blocurilor citite in timpul unui apel sau pe parcursul unei sesiuni.
Optiunile de limitare a resurselor care intervin in comanda CREATE PROFILE sunt urmatoarele:
SESSION_PER_USER (numarul maxim de sesiuni concurente);
CPU_PER_SESSION (timpul de incarcare al procesorului pentru o sesiune, exprimat in secunde);
CPU_PER_CALL (timpul de incarcare al procesorului pentru un apel, exprimat in secunde);
CONNECT_TIME (timpul total al unei sesiuni, exprimat in minute);
IDLE_TIME (timpul de inactivitate continua pe parcursul unei sesiuni, exprimat in minute);
LOGICAL_READS_PER_SESSION (numarul de blocuri de date citite intr-o sesine, inclusiv blocurile citite din memorie sau de pe disc);
LOGICAL_READS_PER_CALL (numarul de blocuri de date citite pe parcursul unui apel pentru a procesa a comanda SQL);
PRIVATE_SGA (dimensiunea spatiului SGA alocat unei sesiuni);
COMPOSITE_LIMIT (costul total al resurselor pentru o sesiune).
Inainte de crearea profilurilor si specificarea limitelor de folosire a resurselor asociate lor, trebuie sa se determine valorile estimative pentru fiecare limita de resurse. Estimarea acestor limite se poate face evaluand tipul de operaii pe caer le executa o categorie de utilizator. De exemplu, daca o categorie de utilizatori, in mod normal, nu face un numar mare de citiri din blocurile logice de date, atunci valorile parametrilor referitori la acest tip de resursa pot fi mari. De obicei, cea mai buna cale de a determina valoarea aproximativa a limitei de folosire a resurselor pentru un profil al unui utilizator dat, este consultarea informatiilor istorice cu privire la ocuparea fiecarui tip de resurse. Pentru a obtine statistici referitoare la folosirea resurselor se poate utiliza componenta de monitorizare a utilitarului OEM sau SQL*Plus. De exemplu, administratorul pentru securitate poate folosi clauza AUDIT SESSION pentru a obtine informatii despre limitele CONNECT_TIME, LOGICAL_READS_PER_SESSION si LOGICAL_READS_PER_CALL.
Pentru ca profilurile sa aiba efect trebuie sa fie pornita optiunea de limitare a resurselor pentru baza de date. Activarea sau dezactivarea acestei optiuni se poate face inaintea pronirii bazei de date sau in timp ce aceasta este deschisa. In acest sens, este folosit parametrul de initializare RESOURCE_LMIT (TRUE pentru activare, FALSE pentru dezactivare).
Exemplu:
Sa se activeze optiunea de limitare a resurselor presupunand ca baza de date este deschisa.
ALTER SYSTEM SET RESOURCE_LIMIT = TRUE;
Dupa cum se observa, comanda CREATE PROFILE permite limitarea costului total al resurselor. Astfel, utilizatorul poate folosi orice resurser doreste, dar suma cantitatilor resurselor consumate nu poate depasi aceasta limita. Un profil poate folosi limitari explicite de resurse, concomitent cu limitarea costului total al resurselor. Atingerea uneia dintre limite determina oprirea activitatii utilizatorului in sesiune. Folosirea limitarilor compuse permite mai multa flexibilitate. Valoarea corecta a unei limite compuse de resurse depinde de cantitatea totala de resurse folosita in medie de un utilizator.
Limitarile de resurse la nivel de apel (LOGICAL_READS_PER_CALL, CPU_PER_CALL) sunt impuse fiecarui apel initiat in timpul executiei unei comenzi SQL. Depasirea uneia dintre aceste limite determina intreruperea procesarii comenzii si anularea acesteia, sesiunea utilizatorului fiind mentinuta.
Dupa ce profilul a fost creat, el poate fi asociat utilizatorilor bazei de date. Nu este posibil ca un utilizator sa aiba concomitent mai multe profiluri. Daca un profil este atribuit unui utilizator care are deja unul, noul profil il va inlocui pe cel vechi. Asocierea profilurilor nu afecteaza sesiunea curenta. Profilurile pot fi atribuite numai utilizatorilor, si nu unui role sau unui alt profil.
Exemplu:
Sa se creeze profilul u_profil, specificand parametrii in mod corespunzator.
CREATE PROFILE u_profil LIMIT
SESSION_PER_USER UNLIMITED
CPU_PER_USER UNLIMITED
CPU_PER_CALL 1000
CONNECT_TIME 50
LOGICAL_READS_PER_SESSION DEFAULT
LOGICAL_READS_PER_CALL DEFAULT
PRIVATE_SGA 25K
COMPOSITE_LIMIT DEFAULT
FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LIFE_TIME 50
PASSWORD_REUSE_TIME 50
PASSWORD_REUSE_MAX DEFAULT
PASSWORD_VERIFY_FUNCTION DEFAULT
PASSWORD_LOCK_TIME 1/24
PASSWORD_GRACE_TIME 15;
Folosind comanda ALTER PROFILE se pot modifica limitarile de resurse ale unui profil. Pentru aceasta este necesar privilegiul sistem ALTER PROFILE. Orice utilizator care detine acest privilegiu poate modifica limitarile profilului implicit. Initial, nu exista limitari de resurse in profilul implicit (sunt UNLIMITED). Pentru a preveni consumul nelimitat de resurse, administratorul pentru securitatea sistemului va trebui sa modifice acest profil.
Modificarile facute asurpa unui profil nu vor afecta sesiunea curenta. Acestea vor deveni active pentru sesiunile ulterioare.
Exemplu:
Sa se modifice profilul creat anterior, astfel incat dupa doua incercai de conectare esuate contul utilizatorului sa se blocheze, paola sa expire dupa 25 de zile si sa nu poata reutiliza aceeasi parola pentru cel putin 60 de zile.
ALTER PROFILE u_profil LIMIT
FAILED_LOGIN_ATTEMPTS 2
PASSWORD_LIFE_TIME 30
PASSWORD_REUSE_TIME 60
PASSWORD_REUSE_MAX UNLIMITED;
Stergerea unui profil necesita privilegiul sistem DROP PROFILE. Comanda SQL folosita are urmatoarea sintaxa:
DROP PROFILE nume_profil [CASCADE];
Optiunea CASCADE se foloseste daca profilul este asociat mai multor utilizatori. Aceasta determina disocierea profilului respectiv de toti utilizatorii care il aveau alocat. In mod automat, sistemul va atribui acestora profilul implicit.
1.9 Informatii despre utilizatori si profiluri
Sistemul mentine o serie de vizualizari in dictionarul datelor care contin informatii despre utilizatorii bazei de date si despre profiluri:
DBA_TS_QUOTAS (descrie cotele spatiilor tabel pentru utilizatori);
USER_PASSWORD_LIMITS (descrie valorile parametrilor referitori la parole, setati prin comanda CREATE PROFILE);
DBA_PROFILES (listeaza toate profilurile impreuna cu limitele lor);
USER_RESOURCE_LIMITS (afiseaza limitarile de resurse pentru utilizatorul curent);
RESOURCE_COST (afiseaza costul fiecarei resurse);
V$SESSTAT (listeaza statistici despre sesiunile utilizatorilor);
V$STATNAM (afiseaza numele statisticilor listate prin vizulaizarea anterioare);
PROXY_USERS (descrie utilizatorii bazei de date care isi pot asuma identitatea altor utilizatori)etc.
1.10 Administrarea privilegiilor si a role-urilor
Un privilegiu este dreptul de a executa anumite comenzi SQL. Privilegiile pot include dreptul de: conectare la baza de date, creare de tabele, selctare a liniilor din tabelul altui utilizator, executie a procedurilor stocate create de alt utilizator etc. Privilegiile trebuie sa fie acordate utilizatorilor numai daca sunt absolute necesare in activitatea acestor. Acordarea excesiva de privilegii poate compromite securitatea bazei de data. Privilegiile pot fi de tip sistem sau obiect.
Un privilegiu sistem reprezinta dreptul de a executa anumite actiuni asupra bazei de date sau de a grupa aceste actiuni. De exemplu, privilegiul de a crea spatii tabel sau a sterge linii din orice tabel al bazei sunt privilegii de sistem. Exista peste 100 de privilegii sistem distincte.
Actiunile pe care un utilizator le poate efectua asupra bazei de date sunt administrate prin privilegiile de sistem acordate acestuia. Ele variaza de la permisiunea de a se conecta la o baza de date (CREATE SESSION) la dreptul de a creea un tabel (CREATE ANY TABLE) sau index (CREATE ANY INDEX) sau de a distruge un tabel (DROP ANY TABLE) sau index (DROP ANY INDEX) din schema oricarui utilizator. O lista a privilegiilor de sistem este prezentata mai jos :
Privilegiile sistem pot fi clasificate astfel:
privilegii specifice sistemului (de exemplu, CREATE SESSION, DROP TABLESPACE, ALTER TABLESPACE);
privilegii pentu gestiunea obiectelor din orice schema (de exemplu, CREATE ANY TABLE, DROP ANY INDEX).
Deoarece privilegiile sistem sunt puternice, se recomanda sa nu se acorde utilizatorilor obisnuiti privilegii de tip ANY asupra tabelelor dictionarului datelor (de exemplu, UPDATE ANY TABLE). Pentru a securiza accesul la dictionarul datelor, parametrul de initializare O7_DICTIONARY_ACCESIBILITY trebuie sa fie FALSE. In acest caz, accesul la obiectele schemei SYS este permis doar utilizatorului care detine schema SYS sau care se conecteaza ca administrator. Privilegiile sitem acordate utilizatorilor vor permite accesul la obiectele din alte scheme, dar nu la cele din schema SYS.
Pentru administrarea bazei de date exista doua privilegii sistem speciale, SYSOPER si SYSDBA. Aceste privilegii permit accesul la instanta bazei de date, chiar daca baza nu este deschisa. Atunci cand un utilizator avand privilegiul SYSOPER sau SYSDBA se conecteaza la baza de date ii este asociata o schema obiectuala implicita, nu cea corespunzatoare username-ului sau. Pentu SYSDBA aceasta sechema este SYS, iar pentru SYSOPER este PUBLIC. Privilegiul SYSOPER permite folosirea comenzilor de baza, dar fara posibilitatea de a vizualiza datele utilizatorilor (STARTUP, SHUTDOWN, ALTER DATABASE, CREATE SPFILE etc.). Privilegiul SYSDBA permite utilizatorului sa execute orice tip de operatie asupra bazei de date si a obiectelor sale.
Privilegiile obiect sunt drepturi de a executa anumite actiuni asupra unui obiect specific al schemei: tabel, vizualizare, secventa, procedura, functie, pachet. De exemplu, ALTER TABLE, DELETE TABLE, SELECT TABLE si UPDATE TABLE sunt privilegii obiect. Unele obiecte, ca de exemplu gruparile, indecsii, declansatorii, legaturile de baze de date, nu au asociate privilegii obiect. Folosirea lor este controlata de privilegiile de sistem. De exemplu, pentru a modifica o grupare utilizatorul trebuie sa fie proprietarul gruparii sau sa detina privilegiul de sistem ALTER ANY CLUSTER.
In ceea ce priveste respectarea privilegiilor, obiectul schemei este echivalent cu sinonimul sau. Daca se acorda un privilegiu pentru un obiect, acesta este valabil si pentru sinonimul sau si reciproc. Daca sinonimul este eliminat, toate privilegiile obiectului au in continuare efect, chiar daca privilegiile au fost acordate doar pentru sinonimul sau.
Un role este un grup de privilegii inrudite care pot fi acordate sau revocate simultan utilizatorilor sau altor role-uri. Folosirea role-urilor permite:
simplificarea administrarii privilegiilor (in loc sa se acorde mai multe privilegii in mod explicit unui grup de utilizatori inruditi, se poate crea un role care sa contina toate privilegiile necesare si apoi sa se acorde acest role fiecarui membru al grupului);
administrarea dinamica a privilegiilor (daca privilegiile unui grup de utilizatori trebuie schimbate, modificarea lor se va face la nivelul role-ului care le contine si aceasta se propaga automat pentru fiecare utilizator care are asociat role-ul respectiv);
activarea selectiva a privilegiilor (role-urile pot fi activate sau dezactivate selectiv, astfel incat se permite un control ridicat al privilegiilor acordate utilizatorilor);
Se pot crea aplicatii care sa interogheze dictionarul datelor si sa activeze/dezactiveze automat unele role-uri, in functie de utilizatorul care incearca sa execute aplicatia respectiva.
Role-urile au urmatoarele caracteristici:
pot fi acordate sau revocate utilizatorilor folosin aceleasi comenzi ca si in cazul privilegiilor sistem;
pot cuprinde atat privilegii sistem, cat si privilegii obiect;
pot fi protejate prin folosirea parolelor;
trebuie sa aiba un nume unic, diferit de conturile utilizatorilor si de celelalte role-uri din baza de date;
nu sunt continute in schema nici unui utilizator;
caracteristicile lor pot fi regasite in dictionarul datelor.
La crearea bazei de date Oracle se definesc automat role-uri predefinite. Acestora li se pot acorda sau revoca alte privilegii sau role-uri. Un exemplu de role predefinit este CONNECT care include privilegiile sistem CREATE SESSION, ALTER SESSION, CREATE DATABASE LINK, CREATE SEQUENCE, CREATE TABLE, CREATE SYNONIM, CREATE VIEW, CREATE CLUSTER.
Pentru a permite utilizatorilor care nu detin un role DBA accesul la vizualizarile dictionarului datelor, sistemul ofera role-urile DELETE_CATALOG_ROLE, EXECUTE_CATALOG_ROLE si SELECT_CATALOG_ROLE.
Crearea unui role necesista privilegiul sistem CREATE ROLE si se realizeaza prin comanda cu acelasi nume. Dupa creare, role-ul nu are privilegii sau role-uri asociate, acestea putand fi acordate ulterior.
Comanda prin care se creeaza un role are urmatoarea sintaxa:
CREATE ROLE nume_role
{NOT IDENTIFIED l INDENTIFIED tip_autorizare};
Daca este folosita clauza NOT IDENTIFIED atunci nu se cere nici o autorizare pentru role-ul respectiv. Aceasta optiune este implicita.
Clauza tip_autorizare specifica urmatoarelor categorii de autorizari:
prin baza de date (IDENTIFIED BY parola);
prin intermediul unei aplicatii care utilizeaza pachete specifica (IDENTIFIED USING [schema.]nume_pachet);
externa, realizandu-se prin sistemul de operare, retea sau alte surse externe (IDENTIFIED EXTERNALLY);
globala (IDENTIFIED GLOBALLY).
Daca autorizarea role-ului se face prin sistemul de operare, atunci informatiile pentru fiecare utilizator trebuie configurate la acest nivel. In cazul autorizarii prin retea, daca utilizatoriise conecteaza la baza de date prin Oracle Net, atunci role-urile nu pot fi autorizate de sistemul de operare.
Autorizarea globala presupune existenta role-uilor globale. Un role global se definieste in baza de date, dar nu poate fi acordat de la acest nivel altui utilizator sau role. Atunci cand un utilizator global incearca sa se conecteze la baza este interogat directorul de servicii pentru a se obtine role-urile globale asociate.
Schimbarea modului de autorizare a unui role se face folosing comanda ALTER ROLE. Pentru aceasta este necesar privilegiul sistem ALTER ANY ROLE sau un role cu optiuni de administrare.
Unui utilizator ii pot fi acordate mai multe role-uri. La fiecare conectare a utilizatorului este activat in mod automat un role implicit, chiar daca acsta nu are asociat explicit nici un role. Un role implicit este specificat folosind clauza DEFAULT ROLE din comanda ALTER USER:
ALTER USER nume_utilizator DEFAULT ROLE
{role[,role] l ALL[EXCEPT role[, role …] ] l NONE}.
Folosind optiunea ALL, toate role-urile acordate utilizatorului devin implicite. In acest caz, la conectare utilizatorul va beneficia doar de privilegiile care i-au fost acordate in mod explicit.
Clauza DEFAUL ROLE nu poate fi folosita pentru role-uri:
care nu au fost acordate utilizatorului;
acordate prin intermediul altor role-uri;
administrate prin servicii externe.
Deoarce role-urile trebuie initial acordate unui utilizator si apoi declarate implicite, nu pot seta role-uri implicite folosind comanda CREATE USER.
Atunci cand un role este activ, utilizatorul poate folosi privilegiile acordate prin intermediul acestuia. Daca role-ul este inactiv, atunci utilizatorul poate folosi doar privilegiile care i-au fost acordate in mod explicit sau care fac parte din alte role-uri detinute de acesta. Activarea sau dezactivarea role-urilor persista doar pentru sesiunea curenta. In sesiunile urmatoare, utilizatorul va avea activate din nou role-urile implicite.
Pentru activarea sau dezactivarea role-urilor este utilizata comanda SET ROLE. Aceasta are urmatoarea sintaxa:
SET ROLE {role [IDENTFIED BY parola]
[,role [IDENTIFIED BY parola]…]
l ALL [ EXCEPT role [, role …]] l NONE};
Clauza IDENTIFIED BY precizeaza parola necesara pentru autorizarea role-ului. Folosind optiunea ALL sunt activate toate role-urile acordate utilizatorului curent, cu exceptia celor care apar in clauza EXCEPT. Optiunea NONE asigura dezactivarea tuturor role-urilor care erau acordate utilizatorului respectiv.
In unele cazuri este necesara suprimarea unui role din baza de date. Stergerea acestuia implica suprimarea sa din toate role-urile carora le-a fost acordat. Deoarece crearea obiectelor nu este dependenta de privilegiile primite prin role-uri, tabelele si celelalte obiecte nu vor fi sterse in momentul suprimarii role-ului. Comanda SQL de stergere a unui role este DROP ROLE. Pentru folosirea acestei comenzi este necesar privilegiul sistem DROP ANY ROLE sau un role cu optiuni de administrare.
1.11 Acordarea privilegiilor si a role-urilor
Privilegiile si role-urile pot fi acordate utilizatorilor sau altor role-uri folosind comanda GRANT sau utilitarul Oracle Enterprise Manager.
Nu pot acorda privilegii system sau role-uri decat utilizatorii carora le-au fost acordate acestea cu optiunea WITH ADMIN OPTION a comenzii GRANT sau cei care detin privilegiul system GRANT ANY ROLE.
Utilizatorii nu pot acorda role-uri autorizate global. Acordarea, respective revocarea unui astfel de role este controlata in intregime prin directorul de servicii.
Comanda SQL prin care se acorda privilegii sistem sau role-uri unui utilizator are urmatoarea sintaxa:
GRANT {privilegiu_sistem l role} [, {privilegiu_sistem l role} …]
TO {nume_utilizator l role l PUBLIC}
[,{nume_utilizator l role l PUBLIC} … ]
[WITH ADMIN OPTION];
Optiunea PUBLIC permite acordarea privilegiilor sistem tuturor utilizatorilor bazei de date. Clauza WITH ADMIN OPTION permite utilizatorilor sa acorde mai departe privilegiile sistem si role-urile respective altor utilizatori sau role-uri.
Privilegiile obiect nu pot fi acordate impreuna cu privilegii sistem sau cu role-uri, in cardrul aceleiasi comenzi GRANT. Acordarea de privilegii obiect utilizatorilo sau role-urilor poate fi facuta de proprietarul obiectului sau de un utilizator caruia I s-a acordat privilegiul obiect respectiv, cu optiunea WITH GRANT OPTION. Comanda folosita pentru acordarea unui privilegiu obiect este:
GRANT {privilegi_obiect [(lista_coloane)]
[, privilegiu_obiect [(lista_coloane)…]
l ALL [PRIVILEGES] }
ON [nume_schema.] obiect
TO {nume_utilizator l role l PUBLIC}
[, {nume_utilizator l role l PUBLIC} …]
[WITH GRANT OPTION];
Prin optiunea lista_coloane se precizeaza coloanele unui tabel sau ale unei vizualizari pentru care se acorda privilegiul. Aceasta optiune poate fi folosita atunci cand sunt acordate privilegii obiect de tip INSERT, REFERENCES sau UPDATE. Optiunea ALL permite acordarea tuturor privilegilor obiect pentru care utilizatorul ce initiaza comanda GRANT are optiunea WITH GRANT OPTION.
Clauza ON [nume_schema.]obiect precizeaza obiectul relativ la care este acordat privilegiul. Optiunea PUBLIC permite acordarea privilegiilor obiect tuturor utilizatorilor bazei de date.
Clauza WITH GRANT OPTION permite utilizatorilor sa acorde privilegii obiect altor utilizatori sau role-uri. Aceasta clauza nu poate fi utilizata atunci cand privilegiul obiect este acordat unui role.
In ceea ce priveste privilegiile referitoare la comenzile LMD, acestea sunt acordate pentru operatiile DELETE, INSERT, SELECT si UPDATE asupra unui tabel sau unei vizualizari, doar utilizatorilor sau role-urilor care trebuie sa interogheza sau sa prelucreze datele respective.
Privilegiile INSERT si UPDATE se pot restrictiona pentru anumite coloane ale tabelului. In cazul unui privilegiu INSERT restrictionat pentru anumite coloane, inserarea unei linii permite inserarea de valori doar pentru coloanele accesibile. Coloanele restrictionate primesc valori implicite sau null. In cazul unui privilegiu UPDATE restrictionat, vor putea fi modificate doar coloanele pentru care utilizatorul are acest drept.
Privilegiile ALTER, INDEX si REFERENCES permit executarea de operatii LDD asupra unui tabel. Un utilizator care incearca sa execute o comanda LDD trebuie sa aiba anumite privilegii sistem sau obiect. De exemplu, pentru a crea un declansator asupra unui tabel, utilizatorul trebuie sa detina privilegiul obiect ALTER TABLE si privilegiul sistem CREATE TIGGER. Privilegiul REFERENCES poate fi acordat unei anumite coloane a unui tabel. Astfel, tabelul respectiv este folosit ca tabel “parinte” pentru orice cheie externa care trebuie creata.
Exemplu:
Sa se acorde utilizatorului liviana dreptul de a porni si opri baza de date, fara a i se permite crearea unei baze de date.
GRANT SYSOPER TO liviana;
Sa se acorde utilizatorului angajat privilegiul obiect SELECT asupra colanelor tabelului oferte.
GRANT SELECT ON oferte TO angajat;
Exemplu:
Sa se creeze un role numit u_role, care sa permita utilizatorilo sa creeze tabele si vizualizari.
CREATE ROLE u_role;
GRANT CREATE TABLE, CREATE VIEW TO u_role;
Sa se atribuie role-ul creat anterior si role-ul predefinit RESOURCE, utilizatorul u5. Role-ul RESOURCE trebuie sa fie activat in mod automat atunci cand utilizatorul se conecteaza.
GRANT user_role, RESOURCE TO u5;
ALTER USER u1
DEFAULT ROLE RESOURCE;
Sa se permita utilizatorului u5 sa consulte vizualizarile dictionarului.
GRANT SELECT_CATALOG_ROLE TO u5;
Sa se afiseze segmentele undo care sunt utilizate de instanta curenta (se presupune ca utilizatorul curent este u5).
SET ROLE SELECT_CATALOG_ROLE;
SELECT SEGMENT_NAME
FROM DBA_ROLLBACK_SEGS
WHERE STATUS = ‘ONLINE’;
1.12 Revocare privilegiilor si a role-urilor
Pentru a revoca privilegii sau role-uri se poate folosi comanda REVOKE sau utilitarul Oracle Enterprise Manager. Un utilizator care are optiunea de administrare, de acordare a unui privilegiu sau role, le poate revoca pe acestea oricarui role sau utilizator al bazei de date. Un utilizator care detine privilegiul GRANT ANY ROLE poate revoca orice role.
Sintaxa generala a comenzii de revocare a unui privilegiu sistem sau role este urmatoarea:
REVOKE <privilegiu_sistem | role> [<privilegiu_sistem | role> … ]
FROM <nume_utilizator | role | PUBLIC> ;
Optiunea PUBLIC permite revocarea privilegiilor sistem sau a role-urilor tuturor utilizatorilor bazei de date.
Sintaxa generala a comenzii de revocare a unui privilegiu obiect este:
REVOKE <privilegiu_obiect [, privilegiu_obiect …]
| ALL [PRIVILEGES] >
ON [nume_schema.]obiect
FROM <nume_utilizator | role | PUBLIC>
[,<nume_utilizator | role | PUBLIC>…]
[CASCADE CONSTRAINTS];
Oprtiunea ALL permite revocarea tuturor privilegiilor obiect acordate utilizatorului. Prin clauza ON se identifica obiectul la care se refera privilegiul ce trebuie revocat. Clauza FROM identifica utilizatorii sau role-urile pentru care este revocat privilegiul obiect. Optiunea PUBLIC determina revocarea unor privilegii obiect tuturor utilizatorilor bazei de date.
Clauza CASCADE CONSTRAINTS permite suprimarea constrangerilor de integritate referentiala definite folosindu-se privilegiile REFERENCES sau ALL.
Definitiile obiectelor care depind de privilegiile LMD sistem sau obiect pot fi afectate daca privilegiile respective sunt revocate. De exemplu, daca privilegiul sistem SELECT ANY TABLE a fost acordat unui utilizator care apoi a creat proceduri sau vizualizari ce folosesc un tabel din alta schema, atunci revocarea acestui privilegiu determina invalidarea procedurilor sau vizualizarilor respective. De asemenea, daca o procedura include comenzi SQL prin care sunt selectate datele unui tabel si este revocat privlegiul obiect SELECT asupra tabelului respectiv, atunci procedura nu se mai executa cu succes.
Definitiile obiectelor pentru care sunt necesare privilegiile obiect ALTER si INDEX nu sunt afectate daca aceste privilegii sunt revocate. DE exemplu, daca privilegiul INDEX, este revocat unui utilizator care a creat un index asupra unui tabel al altui utilizator, indexul respectiv va continua sa existe si dupa revocare.
Revocarea unui privilegiu obiect poate determina efectul de revocare in cascada a acestuia. De exemplu, daca utilizatorului u1 i se acorda privilegiul obiect SELECT asupra unui tabel, cu optiunea WITH GRANT OPTION, iar acesta il acorda utilizatorului u2, atunci revocarea privilegiului utilizatorului u1 va determina automat revocarea acestui privilegiului si pentru utilizatorul u2.
Privilegiile utilizatorilor asupra obiectelor sunt memorate in dictionarul datelor ca reguli de autorizare. Aceste autorizari pot fi stocate in mai multe feluri. Cea mai convenabila modalitate este de a considera privilegiile ca elemente ale unei matrici in care liniile sunt utilizatori, coloanele sunt obiecte, iar elementele matricei corespunzatoare unei perechi (utilizator, obiect) sunt operatiile autorizate.
Exemplu de matricea autorizarilor
Matricea autorizarilor poate fi stocata in trei moduri: dupa linie, dupa coloana, sau dupa element.
1.13 Controlul accesului autorizat in sistemele distribuite
Problemele aditionale care apar intr-un mediu distribuit provin din faptul ca obiectele si utilizatorii sunt distribuiti. Aceste probleme sunt: autentificarea utilizatorilor de la distanta, gestionarea regulilor de autorizare distribuite, ca si manipularea vizualizarilor si grupurilor de utilizatori.
Autentificarea utilizatorilor la distanta este necesara deoarece orice locatie a unui SGBD distribuit poate accepta programe initiate si autorizate la alte locatii, aflate la distanta. Pentru a preveni accesul de la distanta al utilizatorilor neautorizati (de exemplu, dintr-o locatie care nu face parte din SGBD-ul distribuit) este necesara o identificare si autentificare a utilizatorilor la locatia care este accesata. Sunt posibile doua solutii:
Informatia de autentificare (nume utilizator si parola) este replicata la toate locatiile. Programele locale, initiate de la o locatie aflata la distanta trebuie deasemenea sa indice numele utilizatorului si parola.
Toate locatiile din SGBD-ul distribuit se identifica si autentifica ele insesi, intr-un mod similar utilizatorilor. Comunicarea intre locatii este astfel protejata de parola fiecarei locatii. Odata autentificata locatia de unde se initiaza un proces, nu mai este necesara autentificarea utilizatorilor.
Prima solutie este mai costisitoare avand in vedere faptul ca introducerea unui utilizator devine o operatiune distribuita. Avantajul consta in faptul ca utilizatorii pot accesa baza de date distriuita de la orice locatie. A doua solutie este necesara daca informatia utilizatorului nu este replicata. Ea poate fi implementata insa si daca aceasta informatie este replicata. Daca aceste informatii nu sunt replicate, ele trebuie stocate la locatia de unde respectivul utilizator acceseaza sistemul. Ultima solutie se bazeaza pe presupunerea realista ca utilizatorii sunt mai statici, ca ei acceseaza intotdeauna baza de date de la aceeasi locatie.
Vizualizarile pot fi considerate ca fiind obiecte de catre mecanismul de autorizare. Ele sunt de fapt compuse din obiecte. Astfel, acordarea accesului la o vizualizare se traduce in acordarea accesului la obiectele care o compun. Daca definitia vederii si regulile de autorizare a obiectelor sunt replicate aceasta traducere este simpla si poate fi facuta local. Traducerea este mai dificila atunci cand definitia vizualizarii si obiectele care o alcatuiesc sunt stocate separat. In acest caz, traducerea este o operatiune distribuita. Autorizarile acordate pe vedere depind de drepturile de acces catre obiecte pe care cel care a creat vederea le-a acordat.
Gestionarea grupurilor de utilizatori pentru autentificare simplifica administrarea bazelor de date distribuite. Intr-un SGBD distribuit, toti utilizatorii pot fi referiti prin cuvantul public. Si in SGBD-urile exista aceeasi notiune, dar aici exista si un nivel intermediar, care specifica toti utilizatorii de la o anumita locatie. PUBLIC este un grup de utilizatori particular. Se pot defini grupuri mai precise prin comanda
DEFINE GROUP <group_id> AS <lista codurilor utilizatorilor>
Gestionarea grupurilor in mediul distribuit implica cateva probleme deoarece membrii unui grup pot fi la locatii diferite si accesul la un obiect poate fi acordat mai multor grupuri care sunt, la randul lor, distribuite. O solutie pentru aceste probleme poate fi replicarea definitiei grupului la fiecare nod care contine un obiect care poate fi accesat de unul din membrii grupului. Aceasta solutie tinde sa micsoreze autonomia locatiei.
In concluzie, replicarea totala a informatiei de autorizare are doua avantaje puternice: controlul accesului autorizat este mult mai simplu si poate fi facut chiar la momentul compilarii. Totusi, costul total al gestionarii catalogului ditribuit poate fi semnificativ.
1.14 Informatii despre privilegii si role-uri
Sistemul mentine o serie de vizualizari in dictionarul datelor, care contin informatii despre privilegii si role-uri:
DBA_SYS_PRIVS (privilegiile sstem si obiect acordate utilizatorilor sau altor role-uri);
SESSION_PRIVS (privilegiile sistem si obiect disponibile utilizatorului in sesiunea curenta);
DBA_TAB_PRIVS (privilegiile acordate asupra obiectelor bazei);
DBA_COL_PRIVS (coloanele obiectelor care sunt referite in privilegii);
DBA_ROLES (role-urile definite in baza de date);
DBA_ROLES_PRIVS (role-urile acordate utilizatorilor sau altor role-uri);
ROLE_ROL_PRIVS (role-urile acordate altor roleuri);
SESSION_ROLES (role-urile active pentru utilizator in sesiunea curenta);
ROLE_SYS_PRIVS (pivilegiile sistem acordate role-urilor);
ROLE_TAB_PRIVS (privilegiile obiect acordate role-urilor); etc.
2. AUDITAREA
Auditarea presupune monitorizarea si inregistrarea selectiva a actiunilor utilizatorilor unei baze de date. Auditarea este un proces folosit pentru:
investigarea activitatilor suspecte (de exemplu, daca un utilizator neautorizat sterge din tabele, administratorul pentru securitate trebuie sa verifice toate conexiunile la baza si operatiile de stergere a liniilor din tabelele bazei de date pentru a-l identifica);
monitorizarea si gruparea datelor pe categorii de activitati specifice in cadrul bazei de date (de exemplu, administratorul bazei trebuie sa colecteze statistici despre tabelele care au fost modificate, numarul de operatii I/O executate, durata medie a unei sesiuni, privilegiile sistem folosite, numarul de utilizatori care s-au conectat simultan la diferite intervale de timp etc.)
2.1 Optiuni de audit
Controlul actiunilor intreprinse asupra elementelor unei baze de date este realizat prin comanda AUDIT, iar rezultatele verificarilor sunt inregistrate intr-un table (AUD$) al dictionarului datelor, cunoscut sub denumirea de audit trail. Pentru a preveni completarea totala a spatiului tabel asociat, periodic se sterg inregistrari din tabelul AUD$. Se recomanda ca tabelul AUD$ sa nu apartina spatiului tabel SYSTEM. De asemenea, aceasta trebuie protejat impotriva accesului neautorizat.
Sintaxa simplificata a comenzii AUDIT este urmatoarea:
AUDIT {comanda_SQL [, comanda SQL …]
l privilegiu_sistem, [, privilegiu_sistem…]
[BY utilizator]
l ON [nume_schema.]obiect }
[BY {SESSION l ACCESS} ]
[WHENEVER [NOT]SUCCESFUL];
Sistemul Oracle suporta trei tipuri generale de audit, la nivel de comanda, privilegiu sau obiect ale unei scheme. Operatiile de audit pot fi definite la nivel de sesiune sau acces. Pentru a dezactiva optiunile de audit initiate printr-o comanda AUDIT se utilizeaza comanda NOAUDIT asupra acelor optiuni.
Auditul la nivel de comanda se refera la verificari selective asupra comenzilor SQL, care se gasesc in una dintre urmatoarele doua categorii:
comenzi LDD relative la un anumit obiect al schemei (de exemplu, AUDIT TABLE verifica toate comenzile CREATE si DROP TABLE);
comenzi LMD referitoare la anumite obiecte ale schemei, dar fara sa se specifice numele acestora (de exemplu, AUDIT SELECT TABLE controleaza toate operatiile SELECT asupra tabelelor si vizualizarilor).
Sistemul Oracle permite verificarea selective a executiilor comenzilor SQL. Executiile esuate se pot verifica doar daca structura SQL este valida, iar esuarea s-a produs din cazua referirii unui obiect inexistent sau a lipsei unei autorizari adecvate. Comenzile care esueaza pentru ca nu au fost valide, nu pot fi verificate.
Pentru verificarea exclusiva a executiilor cu success se utilizeaza clauza WHENEVER SUCCESSFUL a comenzii AUDIT, iar pentru verificarea doar a executiilor esuate clauza WHENEVER NOT SUCCESSFUL a aceleiasi comenzi. Daca nu este folosita nici una dintre clauzele mentionate mai sus, verificarea se realizeaza in ambele cazuri.
Auditul la nivel de privilegii asigura verificarea selective a comenzilor care necesita privilegii sistem. De exemplu, verificarea privilegiului sistem SELECT ANY TABLE permite monitorizarea comenzilor care se executa folosind acest privilegiu.
Privilegiile obiect sunt verificate inaintea privilegiilor sistem. Daca sunt setate optiuni de audit pentru comenzi si privilegii similare, atunci este generata o singura inregistrare pentru audit. De exemplu, daca comanda CREATE TABLE si privilegiul sistem CREATE TABLE sunt ambele verificate, atunci se genereaza o singura inregistrare de audit, de fiecare data cand este creat un tabel.
Auditul la nivel de obiect al schemei consta in verificarea comenzilor LMD specifice si a comenzilor GRANT sau REVOKE pentru obiectele schemei.
Se pot verifica acele comenzi care refera tabele, vizualizari, secvente, proceduri stocate, funcii, pachete. Procedurile din pachete nu pot fi verificate individual. De asemenea, comenzile care refera grupari, indecsi sau sinonime, nu pot fi verificate direct. Totusi, se poate verifica accesul la aceste obiecte in mod indirect, prin verficarea operatiilor care afecteaza tabelul de baza.
Exemplu:
Se considera urmatoarea secventa SQL:
AUDIT SELECT ON oferte;
CREATE VIEW oferte_cereri AS
SELECT id_oferta, adresa, zona
FROM oferte, cereri
WHERE oferta.tip_oferta = cereri.tip_oferta;
AUDIT SELECT ON oferte
SELECT * FROM oferte_cereri;
Ca urmare a interogarii vizualizarii oferte_cereri sunt generate doua inregistrari de auditare, corespunzatoare interogarii vizualizarii oferte_cereri, respectiv tabelului de baza oferte. Interogarea tabelului de baza oferte nu genereaza inregistrari de verificare, deoarece optiunea de AUDIT SELECT pentru acest table nu este activata.
Optiunile de audit pot fi specificate la nivel de sesiune sau acces, folosind clauzele BY SESSION, respectiv BY ACCESS ale comenzii AUDIT.
Auditarea la nivel de sesiune are ca rezultat inserarea unei singure inregistrari in tabelul AUD$ pentru fiecare utilizator si obiect al schemei, in timpul sesiunii care include o actiune auditata.
Actiunea de audit la nivel de acces presupune inserarea unei inregistrari in tabelul AUD$ pentru fiecare executie a unei operatii care este monitorizata. Operatiile de audit la nivel de comenzi sau de privilegii, aplicate pentru comenzi LDD nu pot fi precizate decat la nivel de acces.
Optiunile de audit la nivel de comenzi sau privilegii permit ca monitorizarea sa se realizeze pentru un anumit utilizator sau pentru un grup de utilizatori. Prin utilizarea operatiei de audit asupra unui grup de utilizatori se poate minimiza numarul de inregistrari din tableul AUD$.
Exemplu:
Sa se dispuna auditarea comenzii SELECT TABLE folosite de utilizatorii liviana si angajat.
AUDIT SELECT TABLE
BY liviana, angajat;
Se presupune ca:
auditarea se realizeaza la nivel de sesiune pentru toate comenzile SELECT TABLE;
utilizatorul liviana se conecteaza la baza de date, executa trei comenzi SELECT asupra tabelului opera si apoi se deconecteaza;
utilizatorul angajat se conecteaza la baza de date, executa doua comenzi SELECT asupra tabelului artist si apoi se deconecteaza.
In tabelul AUD$ se vor insera doua inregistrari, cate una pentru fiecare sesiune ce contine comenzi auditate.
Daca acelasi utilizator executa interogari asupra unor tabele distincte, atunci in tabelul AUD$ se vor insera mai multe inregistrari, cate una pentru fiecare tabel.
Se presupune ca:
auditarea se realizeaza la nivel de acces pentru toate comenzile SELECT TABLE;
utilizatorul liviana se conecteaza la baza de date, executa trei comenzi SELECT asupra tabelului opera si apoi se deconecteaza;
utilizatorul angajat se conecteaza la baza de date, executa patru comenzi SELECT asupra tabelului opera si apoi se deconecteaza.
In tableul AUD$ se vor insera sapte inregistrari, cate una pentru fiecare comanda SELECT.
2.2 Mecanisme pentru audit
Inregistrarea informatiilor pentru audit poate fi activata sau dezactivata. Daca optiunea de auditare este activa, atunci se permite oricarui utilizator autorizat sa specifice optiuni pentru audit, rezervand administratorului pentru securitate dreptul de control asupra inregistrarii informatiilor de audit.
Informatiile de audit contin numele contului, identificatorul sesiunii, identificatorul masinii client, numele schemei de obiecte care a fost accesata, operatiile executate sau initiate, codul rezultate in urma compilarii operatiei, privilegiile de sistem folosite etc.
Activarea sau dezactivarea operatiilor de audit pentru o instanta se realizeaza prin parametrul de initializare AUDIT_TRAIL. Acest parametru poate avea una din urmatoarele valori:
TRUE sau DB (se activeaza operatiile de audit si informatiile despre acestea sunt inregistrate in tabelul AUD$ al bazei de date);
OS (se activeaza operatiile de audit si informatiile despre acestea sunt inregistrate in tabelul audit trail al sistemului de operare);
FALSE sau NONE (se dezactiveaza operatiile de audit).
Atunci cand optiunea de audit devine activa se genereaza verificari asupra inregistrarilor pe durata derularii fazelor de executie a comenzilor. Comenzile SQL din interiorul unitatilor de program PL/SQL sunt verificate individual.
Chiar daca auditul bazei de date nu este activat, sistemul Oracle inregistreaza intotdeauna in tableul audit trail al sistemului de operare, informatii despre urmatoarele actiuni care au loc asupra bazei:
pornirea instantei (utilizatorul care a pornit instanta, identificatorul masinii client, data si momentul de timp etc.);
oprirea instantei (utilizatorul care a inchis instanta, identificatorul masinii client, data si momentul de timp etc.);
sesiunile utilizatorilor cu privilegii de administrare.
Optiunile de audit la nivel de comenzi SQL sau privilegii au efect pe timpul conexiunii unui utilizator la baza de date (pe toate durata sesiunii). Schimbarile optiunilor de audit la nivel de comenzi si privilegii nu afecteaza sesiunea curenta. Modificarile au efect numai asupra noilor sesiuni initiate. In schimb, modificarile optiunile de audit la nivel de obiecte ale schemei au efect imediat, inclusiv pentru sesiunea curenta.
Operatia de audit a bazei de date nu permite monitorizari la nivel de coloana. Daca acest lucru este necesar, atunci se pot folosi rutine speciale pentru auditare (de exemplu, proceduri stocate, declansatori). Baza de date permite mecanisme de audit integrate, astfel incat monitorizarile pot fi realizate automat, fara interventia utilizatorilor.
Sistemul Oracle9i ofera procedee de auditare granulara (fine-grained auditing) prin care se permite monitorizarea accesului la date. Administratorul pentru securitate poate utiliza pachetul DBMS_FGA cu scopul de a crea politici de audit pentru un anumit tabel.
Daca fiecare linie returnata de o interogare indeplineste conditiile de audit, atunci se inregistreaza in tabelul AUD$ un eveniment de audit care include username-ul, codul SQL, variabilele de legatura, identificatorul sesiunii, momentul de timp etc.
Optional administratorii pot defini modalitati de prelucrare si procesare a evenimentelor de audit. De exemplu, la prelucrarea unui eveniment de audit se pot trimite mesaje de avertizare administratorului. Toate informatiile relevante sunt livrate printr-un mecanism asemanator declansatorilor.
2.3 Informatii despre audit
Informatii despre optiunile de audit si evenimentele de audit inregistrate se pot optine consultand dictionarul datelor. Dintre cele mai importante vizualizarii referitoare la auditul bazei de date remarca:
ALL_DEF_AUDIT_OPTS (optiunile implicite pentru audit);
DBA_STMT_AUDIT_OPTS (optiunile de audit la nivel de comanda);
DBA_PRIV_AUDIT_OPTS (optiunile de audit la nivel de privilegiu);
DBA_OBJ_AUDIT_OPTS (optiunile de audit la nivel de obiect);
DBA_AUDIT_TRAIL (toate inregistrarile de audit trail)
DBA_AUDIT_OBJECT (inregistrarile de audit trail referitoare la obiectele schemei);
DBA_AUDIT_SESSION (inregistrarile din audit trail pentru operatiile de audit la nivel de sesiune);
DBA_AUDIT_STATEMENT (inregistarile de audit tail referitoare la comenzi) etc.
3. ORACLE’S MIDDLEWARE SECURITY
Arhitecturile de tip multi-tier au inlocuit aplicatiile de tip client-server in ceea ce priveste canalul preferat pentru accesul la aplicatii cat si la datele procesate. Exista multe motive intemeiate pentru aceasta, incluzand o scalabilitate mai mare, costuri reduse si oportunitati mai multe. Riscurile care apar in momentul deployment-ului aplicatiilor pe internet nu trebuie trecut cu vederea. Astfel de riscuri includ:
cunoasterea limitata a identitatii utilizatorilor
control minim asupra comportamentului utilizatorilor
expunerea marita a sistemelor si a datelor catre utilizatori rauvoitori
atacuri care exploateaza caracteristici deschise specifice internetului, cum ar fi “worms”, scripturi de tip “cross-site”, etc.
Dezvoltatorii de aplicatii web au fost nevoiti sa gaseasca solutii pentru astfel de riscuri. Despre aceste solutii de securizare a aplicatiilor din middleware vom discuta in urmatoarele randuri. Tendintele recente care multiplica posibilele riscuri ce apar in cazul aplicatiilor web includ: deployment-ul mai multor aplicatii printr-un portal unic de infromatii, cresterea ponderii tehnologiei Java pentru dezvoltarea aplicatiilor web si complexitatea si nevoia de scalabilitate pentru aplicatiile rulate.
Prin Oracle Application Server 10g, Oracle asigura un cadru de securitate atat pentru componentele interne ale lui OracleAS cat si pentru aplicatii terte sau custom care ruleaza pe OracleAS. OracleAS introduce termenul de Identity management prin care se asigura suport pentru procesul de definire si administrare a identitatii utilizatorilor aplicatiilor. Termenul de “Identity management” descrie procesele prin care:
Se provizioneaza si se coordoneaza identitatile utilizatorilor
Se automatizeaza provizionarea conturilor de utilizatori
Se administreaza roluri, privilegii si credentiale pentru utilizatori
Administratorii deleaga responsabilitati
Administratorii realizeaza un deploy al aplicatiilor facil si sigur
Utilizatorii isi administreaza singuri setarile si parolele
Utilizatorii dispun de acces de tip “single sign-on”
O astfel de infrastructura integrata pentru identity management permite ca aceste operatii de mai sus sa se execute intr-un mod eficient, reducandu-se costurile de administrare in timp ce securitatea este sporita. Oracle Identity Management reprezinta o infrastructura distribuita de securitate, oferita de Oracle pentru intreaga platforma.
Componentele din Oracle Identity Management sunt urmatoarele:
Oracle Identity Management: un director compatibil LDAP V3, scalabil si robust, implementat in Oracle9i Database Server
Oracle Directory Integration and Provisioning: componenta a lui Oracle Identity Management, ce permite:
sincronizarea intre OID si alte directoare
transmiterea de notificari catre aplicatii interesate privind modificari aduse starii sau informatiilor despre un anumit utilizator
dezvoltarea si deployment-ul propriilor agenti de conectare
Oracle Delegated Administration Services: componenta a lui OID care ofera administrarea sigura de tip proxy pentru informatiile din director direct de catre administratorii de utilizatori sau aplicatii
Oracle Application Server Single Sign-On (OracleAS Single Sign-On): ofera acces “single sign-on” la aplicatii web Oracle si la aplicatii web terte
Oracle Application Server Certificate Authority (OCA): emite, revoca, reinnoieste si publica certificate X.509v3 ca suport pentru metode de autentificare puternice bazate pe PKI
Aplicatii diverse, incluzand aplicatiile Oracle si celelalte aplicatii web utilizate, pot beneficia de infrastructura oferita de OID dupa cum se observa in imaginea urmatoare.
Aplicatiile care au la baza o astfel de infrastructura pentru identity management interactioneaza cu aceasta in urmatoarele moduri:
Autentificarea utilizatorilor: La accesul aplicatiei de catre un utilizator, sunt validate credentialele utilizatorului de catre infrastructura. De exemplu, in cazul infrastructurii OID aceasta validare se face printr-un cookie de browser criptat, de catre OracleAS Single Sign-On.
Autorizarea utilizatorilor: Odata autentificat, aplicatia trebuie sa verifice ca utilizatorul are suficiente privilegii asupra resurselor protejate de catre aplicatie. De exemplu, o aplicatie J2EE va utiliza Oracle Application Server Java Authentication and Authorization Service (OracleAS JAAS Provider) pentru a accesa informatiile despre roluri si utilizatori stocate in infrastructura OID, imediat dupa autentificare.
3.1 Single Sign-On
O componenta de securitate importanta a lui OracleAS il reprezinta suportul pentru “single sign-on” (SSO) pentru aplicatiile web. Motivele pentru care o astfel de solutie se dovedeste utila sunt multiple. Printre acestea se afla si utilizarea crescuta a aplicatiilor web folosite de catre angajati, parteneri sau clienti. Fara SSO, fiecare utilizator ar fi trebuit sa aiba identitati si parole diferite pentru fiecare aplicatie pe care o acceseaza. Intretinerea mai multor conturi si parole pentru fiecare utilizator este atat nesigura cat si costisitoare.
Intretinerea mai multor conturi si parole este nesigura
Majoritatea utilizatorilor nu pot retine decat cateva parole. Utilizatorii care trebuie sa retina mai multe conturi deseori aleg parole usor de retinut, parole identice pentru conturi diferite, reutilizeaza parolele atunci cand trebuie sa le modifice, sau isi scriu parolele. Toate aceste practici reduc securitatea. Daca un utilizator se alatura sau paraseste organizatia, sau i se modifica rolul in cadrul organizatiei, privilegiile asociate aplicatiilor sunt modificate la randul lor. Conturi multiple, independente inseamna de cele mai multe ori ca sistemele nu vor fi rapid sincronizate cu modificarile organizationale. Astfel, sistemul poate fi vulnerabil in fata unui potential atac.
Intretinerea mai multor parole este costisitoare
Administrarea mai multor conturi si parole per utilizator este costisitoare. In multe medii organizationale, o parte semnificativa din timpul administratorilor de sistem este ocupat cu probleme legate de conturi si parole, incluzand crearea initiala a conturilor, modificarea conturilor si resetarea parolelor. Printre problemele intalnite de administratori putem aminti si pe aceea ca acestia vor trebui sa acceseze mai multe sisteme, cu interfete de administrare posibil diferite.
3.2 Suport pentru PKI
Autentificarea PKI se pare ca va inlocui tot mai mult utilizarea parolelor pentru aplicatii. In aplicatiile web, autentificarea PKI este realizata in mod tipic prin schimbul de certificate X509, printr-o sesiune Secure Sockets Layer (SSL). In OracleAS, utilizatorii se pot autentifica la OracleAS SSO Server prin PKI. Aceasta ofera suport SSO atat pentru aplicatiile web suportate de OracleAS SSO Server cat si pentru alte aplicatii compatibile PKI.
Alte caracteristic de securitate aduse de OracleAS sunt:
“Single Sign-Off “: permite terminarea sesiunilor SSO cat si terminarea sesiunilor cu aplicatiile partenere. Aceasta caracteristica este importanta deoarece perioadele de timeout ale aplicatiilor partenere pot fi mai lungi decat sesiunea SSO, astfel incat este posibil ca un utilizator sa nu mai aiba o sesiune SSO valida (SSO session cookie este inactiv) dar sa continue sa aiba o sesiune valida in cadrul aplicatiei partenere.
Suport pentru aplicatii de tip “paranoid”: permite aplicatiilor partenere sa forteze serverul de SSO sa re-autentifice un utilizator chiar daca cookie-ul SSO este inca valid.
Detectare globala a inactivitatii: in OracleAS este posibila configurarea acestei caracteristici pentru a se implementa politici de securitate ce necesita re-autentificarea utilizatorilor daca utilizatorul a fost inactiv pentru o anumita perioada stabilita.
3.3 Securitatea serviciilor oferite de Oracle HTTP Server
Oracle HTTP Server extinde Apache cu o varietate de optimizari standard sau specifice Oracle (prin “module” adaugate la serverul Apache). Aceste optimizari includ si posibilitatea de a permite/restrictiona accesul la fisiere si servicii pe baza identitatii utilizatorului stabilita prin operatii standard de autentificare, prin certificate X.509 si prin adresa IP sau nume de host.
O alta caracteristica importanta a lui Oracle HTTP Server o reprezinta protectia datelor schimbate intre clienti si server. Aceasta este oferita prin protocolul SSL, care asigura integritatea datelor si autentificarea atat a utilizatorilor cat si a serverelor HTTP.
Desi Oracle HTTP Server este bazat pe serverul web open source Apache, acesta contine cateva imbunatatiri ale controlului accesului care cresc securitatea. De exemplu, Apache Server restrictioneaza accesul la directoare prin fisiere cu extensia .htaccess. Procesarea acestor fisiere este dezactivata implicit in Oracle HTTP Server, deoarece procesarea fisierelor .htaccess presupune o probleme legate atat de securitate cat si de scaderea performantelor. Oracle HTTP Server implementeaza acest tip de control al accesului prin module/plug-ins care ofera o securitate sporita si performante mai bune pentru autorizarea utilizatorilor la resursele accesate.
3.4 Securitatea Java in OracleAS
Java, si in particular Java 2 Enterprise Edition a devenit mediul de dezvoltare preferat pentru multe aplicatii web. J2EE defineste un model de securitate de tip Java2 Security Model si un framework de securitate cunoscut sub numele de Java Authentication and Authorization Service (JAAS). OracleAS implementeaza acest framework printr-un provider JAAS compatibil J2EE. Provider-ul JAAS asigura accesibilitatea la serviciile de autentificare, autorizare si de delegare pentru dezvoltatorii de aplicatii, si permite integrarea in medii de aplicatii J2EE.
Implementarea OracleAS pentru JAAS ofera suport atat pentru informatiile de autorizare stocate in OID cat si pentru o implementare mai simpla a API-ului de autorizare folosind XML ca si mecanism de codificare. Acest API permite aplicatiilor Java sa obtina informatii despre utilizatori si roluri printr-un mecanism sigur, din fisierele sistemului de operare.
3.5 OracleAS Portal – elemente de securitate
Oracle 9iAS Portal este o componenta cheie a ofertei de produse Oracle din categoria “enterprise portal”. Produsele web din aceasta clasa nou formata permit accesul catre informatii legate de business din retele interne ale organizatiilor. Desi initial a fost destinat pietei de portaluri pentru corporatii, OracleAS poate fi configurat pentru a permite accesul la comunitati mult mai mari, de genul celor internet.
Acest portal permite utilizatorilor sa-si organizeze aplicatiile si continutul publicat pe web, si sa structureze informatiile logic. De asemenea, contine numeroase instrumente pentru a crea utilizatori si pentru a tine evidenta celor deja existenti, precum si a accesului acestora la Portalul OracleAS.
Portalurile, ca si consolidare si extensie a spatiilor de piata existente, pot folosi trei componente foarte importante:
tehnologia de management al informatiei, integrata in baza de date Oracle
numeroase aplicatii ce tin evidenta informatiilor importante, precum ERP (Enterprise Resourse Planning), CRM (Customer Relationship Management) si BI (Business Intelligence)
o interfata adecvata (OracleAS Portal) ce exploateaza aceasta tehnologie, astfel incat sa imbine aceste informatii cu altele deja existente intr-o retea locala
Functionalitatea incorporata in OracleAS furnizeaza o interfata comuna pentru mai multe aplicatii si produse Oracle sau third-party.
In aceasta sectiune sunt cuprinse informatii legate de elementele de securitate ale acestui produs, precum si de arhitectura sa. In primul rand, cele legate de utilizatori si grupuri, si de relatia dintre utilizatori si baza de date. Apoi, informatiile legate de autentificare, sesiunile de management si autorizare si diferitele elemente de arhitectura.
Portalul OracleAS ofera o platforma sigura pentru a integra diferite aplicatii intr-un singur portal, precum si instrumentele de administrare eficienta a acestui mediu.
Portalul OracleAS ofera un model consistent de autorizari, bazat pe privilegii individuale si de grup, pentru a oferi acces utilizatorilor la aplicatiile si continutul portalului. Ofera de asemenea un model flexibil de integrare a aplicatiilor in interfata de autentificare a portalului, permitand acestora sa fie clasificate ca portlets, aplicatii partener sau aplicatii externe. Portalul OracleAS ofera de asemenea suport de tip audit pentru evenimente legate de securitate, prin intermediul serviciului de inregistrare a evenimentelor.
Pe langa monitorizarea activitatilor care ar putea indica utilizarea neautorizata a sistemului, auditul evenimentelor de securitate este deseori cel mai eficient mijloc de asigurare a faptului ca utilizatorii autorizati respecta politicile de utilizare.
3.6 Utilizatorii Portalului
Intr-o aplicatie internet, posibil accesata de un numar mare de utilizatori, este foarte important sa se tina a buna evidenta a acestora. Pentru a face fata unui numar mare de utilizatori si unui volum urias de date, intr-o maniera sigura, masurabila si in anumite limite permisiva, OracleAS Portal beneficiaza de securitatea si de tehnologia administrarii datelor continuta in baza de date Oracle.
Portalul OracleAS isi defineste proprii utilizatori, care sunt denumiti lightweight deoarece nu beneficiaza fiecare de o schema unica in baze de date, dupa care ar putea fi identificati in baza de date Oracle. In schimb, fiecarui cont de inregistrare ii corespunde un cont unic din OracleAS SSO. Evidenta acestor utilizatori este realizata cu ajutorul unui mecanism dezvoltat in portalul OracleAS.
3.7 Concluzie
Securitatea reprezinta o problema critica in cazul aplicatiilor de tip multi-tier. Middleware-ul Oracle ofera un framework solid pentru acest tip de aplicatii folosind serverul de web Oracle HTTP Server avand la baza Apache, framework-ul Oracle pentru J2EE si OracleAS Portal. Securitatea serverului de aplicatii OracleAS porneste de la serviciile de baza, bine testate si usor configurabile oferite de Apache, adauga optimizari de tipul single sign-on, autorizare bazata pe OID si administrare a utilizatorilor, servicii de securitate Java2 si ajunge pana la securitatea Portalului si a mecanismelor de integrare a aplicatiilor. De asemenea, OracleAS ofera suport pentru un acces sigur la baza de date Oracle folosind Oracle Advanced Security. Aceste caracteristici asigura faptul ca OracleAS reprezinta o alegere inteligenta pentru infrastructura de dezvoltare si deployment al aplicatiilor multi-tier intr-un mediu sigur.
4. APLICATIA
Mediul de programare in care a fost realizata aplicatia este C#. Serverul de baze de date este Oracle9i. Legatura dintre baza de date si aplicatie se realizeaza folosind tehnologia ADO.net.
Baza de date poate fi accesata prin intermediul a doi useri: Liviana si angajat, care semnifica doua grupe separate de utilizatori. Pe de o parte, userul Liviana face parte din categoria administrator, avand drepturi de citire si scriere. Pe de alta parte, userul angajat beneficiaza de drepturi de citire, reprezentand categoria generica a utilizatorilor care consulta baza de date fara drepturi de modificare.
Una dintre utilitatile practice ale aplicatiei poate fi aceea de intranet pentru o agentie imobiliara. Meniul principal este alcatuit din Aplicatie, Baza de Date, Rapoarte Clienti si Rapoarte Firma, cum se poate vedea din figura de mai jos:
Meniul aplicatie permite logarea la baza de date si parasirea acesteia prin intermediul optiunilor loginul si iesire. In Baza de Date exista 3 cateogrii: Clienti, Oferte si Cereri. In Rapoarte Clienti se afiseaza oferta pentru client care nu contine numele proprietarului, adresa completa si numarul de telefon al proprietarului. In Rapoarte Firma se fiseaza oferta clientului cu numele proprietarului, adresa completa si numarul de telefon al proprietarului. Userul cu drepturi de modificare a bazei de date poate introduce inregistrari in limita a 5 MB.
5. BIBLIOGRAFIE:
1. Florentin Eugen Ipate si Monica Popescu, Dezvoltarea aplicatiilor de baze de date in Oracle 8 si Forms 6, Editura ALL, 2000
2. Ileana Popescu, Alexandra Alecu, Letitia Velcescu, Gabriela Florea – Programare avansata in Oracle9i, Editura Tehnica, 2004
3. O. Basca, Baze de date, Editura ALL, 1997
4. Suzanne Van Cleve & Mike Britton, Discover Intranets, IDG Books Worldwide, INC, 1997.
5. Oracle Romania, White Paper.
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Securitatea Bazelor de Date In Oracle (ID: 149183)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.