Aspecte opionale ale securitii n bazele de date Primele versiuni ale bazelor de date comerciale au furnizat acest tip de securitate (discretionary).

Politici de securitate Politicile de securitate constituie un set de reguli care asigur securitatea sistemului. Aceste politici includ 2 categorii :

- politicile obligatorii (mandatory) prezentate anterior ; - politicile opionale (discretionary).

Reamintim c politicile de tip mandatory sunt cele care sunt obligatorii prin natura lor i care sunt independente de aplicaie.

Politicile de tip discretionary sunt cele care sunt specificate de ctre administrator sau de ctre o persoan responsabil pentru mediul n care va opera sistemul respectiv.

Cea mai popular politic de securitate opional este cea referitoare

la controlul accesului. Aceste politici au fost studiate pentru sistemele de operare nc din anii 60, iar pentru bazele de date nc din anii 70. Cele mai reprezentative sisteme de baze de date, System R i INGRES au fost printre primele care au investigat controlul accesului pentru sistemele de baze de date. De atunci, au avut loc anumite modificri ale acestor politici.

O alt clas de politici opionale de securitate include politicile de administrare.

De asemenea, vom discuta identificarea i autentificarea n cadrul politicilor opionale.

Ca i n prezentarea politicilor obligatorii, introducerea politicilor opionale se concentreaz asupra sistemelor relaionale, ns majoritatea principiilor sunt aplicabile i altor sisteme, cum ar fi sistemele de baze de date orientate pe obiecte i bazele de date distribuite.

1. Politici de control al accesului Aa cum am menionat anterior, aceste politici au fost investigate mai

nti pentru sistemele de operare. Problema esenial n acest cadru este dac unui proces i se poate acorda accesul la un fiier. Accesul poate fi de citire sau de scriere, iar acesta din urm poate include accesul pentru modificare, adugare sau tergere. Ulterior, aceste principii au fost transferate asupra sistemelor de baze de date, cum ar fi INGRES i System R. De atunci, au fost studiate diferite forme ale controlului accesului. Printre acestea, se pot meniona politicile bazate pe role-uri implementate n prezent n mai multe sisteme comerciale.

Politicile de control al accesului includ i politici obligatorii, discutate anterior. Diferitele tipuri de control al accesului sunt prezentate n figura 1 i vor fi descrise n continuare.

Politici de securitate

referitoare la controlul accesului

Politici de autorizare pozitiv i negativ

Politici de control al

accesului i utilizare bazate

pe role-uri

Politici pentru integritate,

confidenialitate, partajare de date i colaborare

Figura 1 Politici de autorizare Majoritatea politicilor de control al accesului se bazeaz pe politici de autorizare. Acestea presupun faptul c utilizatorilor le este acordat accesul la date pe baza regulilor de autorizare. n continuare, vom introduce tipurile de reguli.

Autorizrile pozitive. Primele sisteme s-au concentrat asupra regulilor care acum sunt denumite reguli de autorizare pozitiv. De exemplu, utilizatorului John i este acordat accesul la relaia EMP sau utilizatorului Jane i este acordat accesul la relaia DEPT. Acestea sunt reguli de control al accesului asupra relaiilor. De asemenea, se poate acorda acces asupra atributelor i tuplurilor. De exemplu, John are acces pentru citirea atributului salary i acces pentru scrierea atributului name din relaia EMP.

Autorizrile negative. Dac accesul lui John asupra unui obiect nu este specificat, aceasta nseamn c John nu are acces la acel obiect? n anumite sisteme, nespecificarea unei reguli de autorizare presupune implicit autorizarea negativ, n timp ce n alte sisteme autorizrile negative sunt specificate n mod explicit. De exemplu, putem impune reguli astfel nct John s nu aib acces la relaia EMP sau Jane s nu aib acces la relaia DEPT.

Rezolvarea conflictelor. Atunci cnd avem reguli n conflict, cum se

rezolv acesta? De exemplu, putem avea o regul care acord accesul lui John pentru citire la relaia EMP. De asemenea, putem avea i o regul care nu i acord lui John accesul la citire asupra atributului salary din EMP. Acesta este un conflict. De obicei, sistemul aplic regula celui mai mic privilegiu, adic John are acces la EMP mai puin valorile atributului salary.

Autorizare tare i slab. n cazul autorizrii tari regula este valabil

indiferent de conflicte, iar n cazul celei slabe regula nu se aplic dac exist un conflict. De exemplu, dac John primete acces la EMP i aceasta este o regul tare de autorizare, iar regula prin care John nu primete acces la atributul salary este o regul slab, avem o situaie conflictual. Aceasta nseamn c rmne valabil autorizarea tare.

Propagarea regulilor de autorizare. De exemplu, dac John are acces

pentru citire asupra relaiei EMP, aceasta nseman c John are acces la fiecare element din EMP? De obicei, acest lucru are loc cu excepia cazului n care exist reguli care interzic propagarea automat a unei reguli de autorizare. Dac o astfel de regul exist, trebuie s stabilim explicit reguli de autorizare care specific obiectele asupra crora are acces John.

Reguli speciale. Constrngerile bazate pe coninut i context sunt

reguli prin care accesul este acordat n funcie de coninutul datelor sau de contextul n care acestea sunt afiate. Aceste reguli constituie extensii ale politicilor obligatorii, ns pot fi aplicate i n cadrul securitii opionale. De exemplu, n cazul constrngerilor bazate pe coninut, John are acces pentru citire doar asupra tuplurilor din departamentul 100. n cazul constrngerilor bazate pe context sau asociere, John nu are acces pentru citire la nume i salarii luate mpreun, dar poate avea acces individual la acestea. n cazul constrngerilor bazate pe evenimente, dup alegere, John are acces la toate elementele din relaia EMP.

Consistena i completitudinea regulilor. Una dintre probleme este

asigurarea consistenei i completitudinii constrngerilor. Aceasta nseamn c, dac regulile sau constrngerile sunt inconsistente, avem reguli de rezolvare a conflictelor care s trateze situaia? Cum putem asigura c toate entitile (atribute, relaii, elemente etc.) sunt cuprinse n cadrul regulilor de control al accesului pentru un utilizator? Cu alte cuvinte, sunt regulile complete? Dac nu, ce presupuneri trebuie s facem despre entitile care nu au nici autorizri pozitive, nici negative specificate asupra lor pentru un anumit utilizator sau pentru o clas de utilizatori.

Controlul accesului bazat pe role-uri Role-Based Access Control (RBAC) a devenit una dintre cele mai populare metode de control al accesului. Metoda a fost implementat n sisteme comerciale, inclusiv Oracle. Ideea este aceea de a acorda acces utilizatorilor pe baza role-urilor i funciilor lor. Utilizatorii au nevoie de acces la date n funcie de role-urile lor. De exemplu, un preedinte de corporaie poate avea acces la informaiile despre vicepreedinii si i despre membrii consiliului, iar directorul financiar poate avea acces la informaiile financiare i la cele referitoare la angajaii din subordinea sa. Un director de departament poate avea acces la datele despre cei care lucreaz n departamentul respectiv iar directorul de resurse umane poate obine informaii asupra datelor personale ale angajailor din corporaie.

Controlul accesului pe baz de role-uri este un tip de politic de autorizare care depinde de rolul utilizatorului i activitile corespunztoare acestuia. Literatura conine direciile de cercetare asupra ierarhiilor de role-uri . Unele dintre problemele care apar n acest domeniu se refer la modul n care este propagat accesul sau la posibilitatea ca un role s conin pe altul.

Managerul de departament are

toate drepturile de acces pe care le are

un manager de grup

Manager de grup

Manager-ul de divizie are toate

drepturile de acces ale unui manager de

departament

Figura 2

Considerm ierarhia de role-uri din figura 2. Dac acordm acces unui nod din ierarhie, aceasta nseamn c accesul este propagat n sus? (Dac un manager de departament are acces la anumite informaii despre proiecte, accesul este propagat n nodul printe, care corespunde unui director? Dac un conductor de secie are acces la informaiile angajailor din secia sa, accesul se propag ctre managerul de departament (parintele din ierarhia de role-uri)? Ce se ntmpl cu nodurile copil? Accesul se propag n jos? (de exemplu, dac un manager de departament are acces la anumite informaii, au i subordonaii si acces la informaiile respective? Exist cazuri n care subordonaii au acces la date la care managerul de departament nu are acces? Ce se ntmpl dac un angajat trebuie s raporteze la 2 supervizori

(managerul de departament i eful su de proiect)? Ce se ntmpl cnd managerul de departament lucreaz pe un proiect i trebuie sa raporteze efului su de proiect, care este condus de el? Prinii multiplii sunt ilustrai n figura 3 iar un ciclu este reprezentat n figura 4. Accesul pe baz de role-uri a fost analizat pentru sistemele relaionale, obiect i distribuite, dar i pentru tehnologiile recente (data warehouse, sistemele de gestiune a cunotinelor, web semantic, sistemele de comer electronic, bibliotecile digitale).

Project Leader Role Engineer Role

Conductor de proiect care este totodat inginer

Figura 3. Prini multipli

Toi managerii de departamente au rol de conductor de proiect; toi conductorii de proiect au rol de manager de departament

Conductorul de proiect este manager de departament

Managerul de departament

este conductor de proiect

Figura 4. Graf ciclic

2. Politici de administrare

Politicile de control al accesului specific accesul pe care utilizatorii l au asupra datelor, iar politicile de administrare specific cine va administra datele. Sarcinile de administrare includ meninerea datelor ntr-o stare curent, asigurnd c metadatele sunt actualizate odat cu modificarea datelor, i asigurnd revenirea n urma cderilor. Administratorul bazei de date (DBA) este responsabil de actualizarea metadatelor, a indecilor i a metodelor de acces i, de asemenea, de asigurarea faptului c regulile de control al accesului sunt aplicate corespunztor. Un rol important l poate avea i responsabilul cu securitatea sistemului (SSO System Security Officer). Problemele legate de securitate pot fi responsabilitatea SSO iar cele referitoare la date pot fi responsabilitatea DBA. Alte politici de administrare se refer la numirea de responsabili asupra datelor. De obicei, posesorii schemelor au control asupra datelor pe care le creeaz i le pot gestiona pe perioada existenei acestora. Exist situaii n care posesorii nu pot fi disponibili pentru gestiunea datelor, caz n care se recurge la numirea unor respnsabili asupra acestora. Figura 5 arat politicile importante de administrare.

Politici referitoare la apartenena datelor i

transferul de date

Politici pentru acordarea

credenialelor i a altor

certificate de securitate

Politici pentru recuperarea i auditarea bazei

de date

Politici de administrare

Figura 5

3. Identificare i autentificare

Identificarea presupune necesitatea ca utilizatorii s funizeze un user ID i o parol. Autentificarea reprezint etapa n care sistemul trebuie s potriveasc user ID-ul cu parola pentru a asigura c persoana este cea care declar c este. Un utilizator poate avea identiti multiple, n funcie de role-urile sale. Au fost raportate numeroase probleme referitoare la schema pe baz de parole. Una dintre acestea este c hacker-ii pot ptrunde n sistem, obine parolele utilizatorilor pentru ca apoi s pretind c sunt acetia. ntr-un sistem centralizat problemele sunt mai simple dect ntr-unul distribuit. Recent, au nceput s fie utilizate tehnicile biometrice. Acestea includ recunoaterea feei i a vocii pentru autentificarea utilizatorului. Este de ateptat rspndirea pe scar larg a tehnicilor biometrice pe msur ce tehnologiile de recunoaterea feei evolueaz.

4. Auditul unui sistem de baze de date

Auditul bazelor de date se realizeaz pentru mai multe scopuri. De exemplu, bazele de date pot fi auditate pentru a se nregistra numrul de cereri lansate, numrul de actualizri, numrul de tranzacii executate, numrul de accesri ale unitilor de stocare secundare. Scopul acestora este proiectarea mai eficient a sistemului. De asemenea, bazele de date pot fi auditate din motive de securitate. De exemplu, n acest mod se poate gsi rspunsul la urmtoarele ntrebri:

- a fost evitat vreo regul de control al accesului, fiind furnizat informaie ctre utilizatori?

- a aprut problema inferenei? - a fost nclcat confidenialitatea? - au avut loc accesri neautorizate?

Auditrile creeaz un audit trail, iar datele de audit pot fi stocate ntr-

o baz de date. Aceast baz de date poate fi analizat pentru a detecta orice secven sau comportament anormal. Au existat multe preocupri asupra utilizrii data mining pentru auditare i detectarea accesrilor neautorizate. Analiza informaiilor de audit este deosebit de important la ora actual, n contextul tranzaciilor comerciale pe web. O organizaie ar trebui s aib

posibilitatea de a demara o analiz i a determina probleme precum fraudele asupra cardurilor de credit i furtul identitilor.

5. Vizualizrile n contextul securitii

Ca mecanism de securitate, vizualizrile au fost studiate att pentru securitatea obligatorie ct i pentru cea opional. De exemplu, s-ar putea s nu dorim s acordm accesul asupra unei ntregi relaii mai ales dac are multe atribute. Prin urmare, DBA-ul ar putea creea vizualizri i acorda acces la acestea. Similar cazului securitii obligatorii, vizualizrilor le pot fi asociate niveluri de securitate. Vizualizrile au anumite probleme specifice cu ele, inclusiv problema actualizrii. Aceasta nseamn c, dac vizualizarea etse actualizat atunci este nevoie s asigurm c relaiile de baz sunt actualziate. . Prin urmare, dac o vizualizare este actualizat de ctre John, iar acesta nu are acces la relaia de baz, poate fi aceasta actualizat?

Aplicarea politicilor de securitate

n anii 70, System R i INGRES au dezvoltat tehnici, cum ar fi mecanismele de modificare a cererilor pentru aplicarea politicilor. Limbajul SQL a fost extins pentru a permite specificarea politicilor de securitate i a regulilor de control al accesului. Mai recent, limbaje precum XML i RDF au fost extinse pentru a specifica politici de securitate.

1. Extensii SQL pentru securitate

Extensiile SQL pentru securitate permit specificarea politicilor. SQL a fost dezvoltat pentru definirea i prelucrarea datelor n sistemele relaionale. Ulterior, au fost dezvoltate diferite versiuni de SQL incluznd SQL pentru obiecte, multimedia i web. SQL a influenat foarte mult definirea i prelucrarea datelor n ultimii 20 de ani. Politicile de securitate pot fi specificate n cadrul definirii datelor. Limbajul SQL conine comenzile GRANT i REVOKE pentru acordarea, respectiv revocarea, drepturilor de acces ale utilizatorilor. De exemplu, dac utilizatorul John primete acces pentru citire asupra relaiei EMP, se poate specifica acest lucru prin:

GRANT read ON emp TO John; Revocarea accesului se poate specifica prin: REVOKE read ON emp FROM John; SQL a fost extins cu constrngeri mai complexe, cum ar fi acordarea accesului pentru citirea unui tuplu dintr-o relaie lui John sau acordarea de acces pentru scriere asupra unui element dintr-o relaie lui Jane.

2. Modificarea cererilor Modificarea cererilor a fost propus prima dat n cadrul proiectului

INGRES. Ideea este aceea de a modifica cererea pe baza constrngerilor. Ilustrm acest algoritm prin cteva exemple. Considerm o cerere a lui John pentru regsirea tuturor tuplurilor din EMP. Presupunem c John are acces pentru citire doar la tuplurile pentru care salariul este mai mic dect 30000 i angajatul nu lucreaz n departamentul de securitate. Atunci cererea: SELECT * FROM EMP; va fi modificat n: SELECT * FROM emp Where salary < 30000 And dept != Security; Clauza where a cererii conine toate constrngerile asociate relaiei. Pot exista constrngeri care implic mai multe relaii. De exemplu, putem avea 2 relaii EMP i DEPT legate prin Dept#. Apoi, cererea este modificat astfel: SELECT * FROM emp, dept WHERE emp.salary

Algoritmul de nivel nalt este prezentat n continuare: Intrare : Cererea Q, mulimea S a constrngerilor de securitate Ieire : Cererea Q modificat For c in S If c relevant_for Q then Modify the where clause of Q via a negation End if; End for; Return Q;

O perspectiv asupra problemei inferenei Problema inferenei a fost studiat n bazele de date statistice civa ani nainte de a deveni un subiect foarte important n MLS/DBMS. Inferena este procesul de lansare a unor cereri i deducere a unor informaii noi din rspunsurile legitime primite. Devine o problem dac utilizatorul nu este autorizat s cunoasc informaia dedus. Printre primii care au studiat problema n bazele de date statistice a fost biroul de recensmnt (SUA). Bazele de date statistice sunt folosite de diferite organizaii, de la biroul de recensmnt pn la organizaii de marketing care doresc s studieze modelele de comportament ale populaiei. n esen, bazele de date statistice furnizeaz sume, medii, deviaii etc., valori foarte utile n studiul populaiei n termeni de numere sau comportament. Exemple de situaii n care poate aprea problema inferenei statistice: furnizarea salariilor medii, dar protejarea valorilor individuale ; informaii referitoare la sntatea dintr-un anumit jude, protejnd nregistrrile individuale ale persoanelor din acel jude. Poate un adversar s obin media salariilor a 10 persoane, apoi 9, apoi 8 .a.m.d ? O alt practic referitoare la bazele de date statistice este s nu fie folosite toate valorile din baza de date, ci s se lucreze cu valori de selecie. Adic, mediile sunt calculate pe baza unui eantion reprezentativ. Din acestea, este mai dificil s se obin informaii individuale protejate.

Inferena statistic a dobndit o importan mai mare odat cu dezvoltarea noilor tehnologii, cum ar fi data warehousing i data mining. De exemplu, tehnologia data warehouse a fost dezvoltat pentru a oferi informaie specific pentru luarea deciziilor, incluznd sume i medii. Datele din data warehouse ar putea fi neclasificate, dar ar putea exista informaii protejate care rezid n baza de date back-end. Pe baza informaiei pe care o ofer data warehouse, se pot determina datele sensibile din baza de date back-end? Data mining ofer informaii necunoscute anterior, folosind diferite tehnici de raionament cum ar fi inferena statistic. Problema inferenei este privilegiat n domeniul data mining. Prin urmare, provocarea const n descoperirea informaiei protejate prin mining. O direcie de cercetare recent se refer la privacy-preserving data mining. Ideea este aceea de a asigura confidenialitatea, dar n acelai timp de a oferi informaii, probabil uor modificate. Abordri ale gestiunii inferenei ntr-un MLS/DBMS Abordrile n soluionarea problemei inferenei pot fi mprite n 2 grupuri: unul bazat pe constrngerile de securitate i altul bazat pe structurile conceptuale. Constrngerile de securitate sunt reguli care atribuie niveluri de securitate datelor. n aceast abordare, unele constrngeri de securitate sunt tratate n timpul procesrii cererilor. Aceasta nseamn c, n timpul operaiei corespunztoare cererii, constrngerle sunt examinate i cererea este modificat. Mai mult, nainte de prezentarea rezultatelor constrngerile sunt examinate pentru a determina ce informaie poate fi prezentat. Aceast abordare permite, de asemenea, ca unele constrngeri s fie procesate n timpul actualizrii bazei de date. Astfel, constrngerile sunt examinate n timpul operaiei de actualizare i datelor le sunt atribuite niveluri adecvate de securitate. n sfrit, anumite constrngeri sunt tratate n timpul proiectrii bazei de date, cnd metadatele sau schemele primesc niveluri de securitate. n al doilea set de abordri, structurile conceptuale sunt folosite pentru a reprezenta aplicaia i raionamentele asupra ei. Dac exist nerespectri poteniale ale securitii prin inferen, atunci acestea pot fi detectate la momentul proiectrii aplicaiei. Mai nti, au fost utilizate grafurile pentru reprezentarea aplicaiilor (Hinke, 1988). Ulterior, au fost utilizate reele semantice i grafuri conceptuale.