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.
Manager-ul de
divizie are toate
drepturile de acces
ale unui manager de
departament

Managerul de
departament are
toate drepturile de
acces pe care le are
un manager de
grup

Manager de
grup
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

Managerul de
departament
este conductor
de proiect

Toi managerii de
departamente au rol
de conductor de
proiect; toi
conductorii de
proiect au rol de
manager de
departament
Figura 4. Graf ciclic

Conductorul de
proiect este
manager de
departament

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 de
administrare

Politici
referitoare la
apartenena
datelor i
transferul de
date

Politici pentru
acordarea
credenialelor i
a altor
certificate de
securitate
Figura 5

Politici pentru
recuperarea i
auditarea bazei
de date

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 ntro 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<30000
And emp.dept#=dept.dept#
And dept.name != Security;

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.