Securizarea bazelor de date

Securizarea bazelor de date

1. Tehnici de securizare

Sarcina de a se asigura securitatea bazelor de date este impartita intre sistemul de gestiune al bazelor de date si sistemul de operare. Acestea pot sa asigure fiecare in totalitate o parte din functiile de asigurare a securitatii sau pot sa fie complementare in realizarea acestora. Atributiile in asigurarea securitatii bazelor de date sunt exemplificate in tabelul urmator (tabelul 22):

Tabelul 22. Atributii in asigurarea securitatii bazelor de date

Controlul asupra atacurilor

Anterior am vazut ca, din date nesenzitive, prin diverse interogari ale bazei de date au rezultat date senzitive.

Pentru a se preintampina acest lucru se pot aplica urmatoarele metode:

suprimarea cererilor cu rezultate senzitive;

aproximarea rezultatelor;

limitarea rezultatelor unei cereri care dezvaluie date senzitive;

combinarea rezultatelor.

Cererile de acces la elementele bazei de date care au ca rezultat afisarea unor rezultate senzitive sunt rejectate fara nici un raspuns. Datele senzitive nu vor fi afisate. Rezultatul unei astfel de interogari va fi corect, dar nu va fi afisat catre utilizator.

In cazul unei astfel de cereri sistemul va putea sa afiseze rezultate apropiate de cele reale. Acuratetea rezultatului la o interogare care poate dezvalui date senzitive trebuie sa fie mica.

Limitarea rezultatului unei cereri, care dezvaluie date senzitive se poate face in cazul in care acesta este 1 (unu).

Daca pe exemplul anterior de la capitolul 2, paragraful 2.3.1 (figura 75), vom aplica pe rand atacuri cu functii de forma exemplificata in figura 76 si vom centraliza rezultatele sub forma de tabel (tabelul    23), vom vedea ca avem rezultate dominante care trebuie suprimate.

Figura 75. Tabela supusa atacului

Figura 76. Atacul indirect folosind functia COUNT conditionat

Tabelul 23. Centralizarea rezultatelor

In aceasta situatie trebuie sa suprimam cererile care au ca rezultat valori dominante (1) sau sa nu permitem afisarea rezultatelor chiar daca cererea se executa in asa fel incat rezultatele sa fie afisate sub forma urmatoare (tabelul 24):

Tabelul 24. Afisarea cu suprimare a rezultatelor

Se observa ca situatia nu este rezolvata, trebuind sa modificam si sumele pe linii si pe coloane pentru a se crea confuzie si a nu se mai putea extrage date senzitive.

Combinarea rezultatelor se face prin afisarea acestora intr-o plaja de valori care sa nu permita extragerea datelor exacte. Facand o contorizare pe tip de sanctiuni si gruparea acestora pe sexe, vom avea situatii dominante (tabelul 25):

Tabelul 25. Rezultate contorizari

Solutia ar fi combinarea coloanelor pentru a nu se putea extrage date exacte. Combinam coloanele cu 0"cu si cu 3". Rezultatul este urmatorul (tabelul 26):

Tabelul 26. Combinarea rezultatelor

Pentru a se preintampina atacurile este necesar sa se tina o evidenta amanuntita pentru fiecare utilizator, chiar daca acest lucru presupune o activitate complexa si implica timp.

De asemenea, trebuie facuta o analiza a cererilor care pot fi rau intentionate.

Pentru a preintampina extragerea datelor senzitive din bazele de date am realizat un program care monitorizeaza toate operatiile efectuate de utilizatori pe bazele de date. Operatiile de monitorizare efectuate de acest program au fost prezentate in acest capitol, paragraful 4.5.1. La acest punct suntem interesati doar de fisierul baza de date accesat de utilizator, tipul de operatii efectuate si listarea acestora. In acest mod, toate operatiile efectuate de utilizatori pot fi analizate si se pot trage concluzii privind securitatea bazelor de date ale firmei. O prezentare detaliata si listingul programului sunt oferite la anexa 1.   

Securitatea bazelor de date multinivel

Se disting trei caracteristici de baza ale securitatii bazelor de date:

Securitatea unui singur element poate fi diferita de securitatea altui element din aceeasi inregistrare sau de valoarea aceluiasi atribut. Aceasta implica implementarea securitatii pentru fiecare element in parte.

Sunt necesare cateva perimetre se securitate care vor reprezenta arii de acces la anumite date care uneori se pot suprapune.

Securitatea unui intreg poate fi diferita de securitatea unui element individual. Aceasta poate fi mai mare sau mai mica.

Pentru a se asigura securitatea bazelor de date se pot aplica urmatoarele metode [HSST95]

partitionarea bazei de date;

criptarea;

blocarea integritatii;

blocarea senzitivitatii;

securitatea front-end";

filtru comutativ;

vederi ale bazei de date.

Partitionarea bazei de date

Baza de date este impartita in baze de date separate, fiecare dintre acestea cu propriul ei nivel de securitate. Operatia mai poarta numele de atomizarea bazei de date. Ca efect secundar, aceasta operatie va distruge avantajul principal al bazei de date dar imbunatateste precizia.

Criptarea

Daca datele senzitive sunt criptate, un utilizator care ajunge din intamplare in posesia unor date senzitive nu va putea sa le interpreteze si sa se foloseasca. Aceasta criptare este insa vulnerabila la atacuri cu text clar sau cand atacatorul substituie forma de criptare cu o alta. Pentru a se preintampina aceasta se pot face urmatoarele:

folosirea de criptari diferite pentru aceeasi inregistrare si diferite chei pentru fiecare camp;

criptarea campurilor inregistrarii folosind metoda block chaining (CBC, CFB etc.).

Aceste metode de criptare sunt exemplificate in figura urmatoare (figura 77).

Figura 77. Criptarea inregistrarii

Blocarea integritatii

Reprezinta o cale folosita atat pentru blocarea integritatii, cat si pentru limitarea accesului la baza de date. Metoda mai poarta si denumirea de spray paint" deoarece fiecare element este colorat in functie de senzitivitatea acestuia. Culoarea este mentinuta cu elementul pe care-l caracterizeaza si nu intr-o baza de date separata.

Fiecare data va contine trei elemente:

Datele vor fi stocate in text clar pentru sporirea eficientei.

Referitor la clasificare, aceasta trebuie sa fie:

nefalsificabila - un utilizator rauvoitor nu va putea crea o noua data senzitiva pentru un element;

unica - utilizatorul rauvoitor nu va putea sa copieze un nivel de senzitivitate dintr-un alt element;

secret - utilizatorul rauvoitor nu va putea sa determine senzitivitatea pentru un obiect oarecare.

Suma de control criptografica, pentru a putea sa fie unica, trebuie sa contina date despre:

inregistrare;

camp;

date ale elementului (figura 78).

Figura 78. Suma de control criptografica

Blocarea senzitivitatii

Blocarea senzitivitatii reprezinta o combinatie a doua elemente:

existenta unui identificator unic (numarul de inregistrare);

nivelul de securitate.

Trebuie sa nu se permita aflarea a doua elemente care au acelasi nivel de securitate doar prin cautarea in portiunea de securitate a blocarii integritatii. Ca rezultat al criptarii, continutul blocarii, in special nivelul de securitate, este ascuns (figura 79).

Securitatea front-end

Securitatea front-end (cunoscuta si sub denumirea de garda) este asigurata de un mecanism de tip monitor.

Secventa de interactiuni intre utilizator si mecanismul front-end este urmatoarea:

utilizatorul se identifica front-end;

utilizatorul transmite o cerere mecanismului front-end;

mecanismul front-end verifica autorizatia utilizatorului de a acces la date;

mecanismul front-end trimite o cerere catre sistemul de gestiune al bazei de date (SGBD);

sistemul de gestiune al bazei de date (SGBD) efectueaza o operatie de acces de tip I/O;

sistemul de gestiune al bazei de date (SGBD) trimite rezultatul interogarii catre mecanismul front-end;

mecanismul front-end verifica validitatea datelor extrase cu ajutorul sumelor de control si verifica daca datele pot fi disponibile catre utilizator conform nivelului de acces al utilizatorului;

mecanismul front-end va formata datele pentru utilizator;

se transmit datele catre utilizator.

Filtru comutativ

Filtrul comutativ interactioneaza atat cu utilizatorul, cat si cu sistemul de gestiune al bazei de date (SGBD).

Filtrul comutativ va reformula cererile in felul urmator:

sistemul de gestiune al bazei de date (SGBD) va efectua cat mai multe sarcini posibile rejectand cat mai multe cereri inacceptabile care dezvaluie date senzitive;

selectarea datelor la care utilizatorul poate sa aiba acces.

Filtrul comutativ poate fi folosit atat asupra inregistrarilor, cat si asupra atributelor sau elementelor.

La nivelul inregistrarilor, filtrul cere datele dorite plus suma de control criptografica; daca acestea verifica acuratetea si accesibilitatea datelor, atunci acestea pot fi transmise catre utilizator.

La nivel de atribut, filtrul verifica daca toate atributele din cererea utilizatorului sunt accesibile acestuia, si daca da, transmite cererea catre managerul bazei de date. La revenire va sterge toate cererile la care utilizatorul nu poate sa aiba acces.

La nivel de element, sistemul va cere datele solicitate si suma de control criptografica. Cand sunt returnate, acestea verifica apartenenta la niveluri de securitate pentru fiecare element.

Vederile

Vederile reprezinta un subset al bazei de date la care utilizatorul poate avea acces. Vederile pot reprezenta un subset al bazei de date pentru un singur utilizator, in acest caz cererile celorlalti utilizatori vor accesa acelasi tip de date. Datele care sunt accesibile unui utilizator se obtin prin filtrarea continutului bazei de date originale. Utilizatorul nu este constient de existenta tuplurilor care lipsesc din vederea respectiva. O vedere poate fi definita din mai multe tabele, pentru care utilizatorul detine privilegiul corespunzator de utilizare, dar nu si de folosire a tabelelor de baza. Utilizarea, in acest caz a vederilor, este mai restrictiva decat simpla detinere a privilegiilor acordate utilizatorului asupra tabelelor de baza. SGBD-ul stocheaza definitia vederii in baza de date. Cand SGBD-ul intalneste o referire la o vedere, cauta aceasta definitie si transforma cererea respectiva intr-o cerere echivalenta catre tabelele care constituie sursa vederii, dupa care efectueaza cererea.

Folosirea vederilor pentru asigurarea securitatii bazelor de date mai este intalnita in literatura de specialitate si sub denumirea de securitate discretionara si este caracteristica sistemelor bazate pe SQL.

Folosirea vederilor bazelor de date are ca efect crearea unor facilitati in exploatare, dar poate aduce si dezavantaje (tabelul 27).

Tabelul 27. Avantajele si dezavantajele folosirii vederilor

Cu ajutorul instructiunilor SQL se pot crea vederi orizontale si verticale. Sintaxa este urmatoarea:

Exemplificam pe tabela urmatoare (SALA)(tabelul 28).

Tabelul 28. Tabela SALA (salariati)

Crearea vederii orizontale se face in felul urmator:

CREATE VIEW SORT_O

SELECT *

FROM SALA

WHERE SALB >

Rezultatul va fi urmatorul:

SORT_O

Crearea vederii verticale se face in felul urmator:

CREATE VIEW SORT_V

SELECT NUME, SALB, COMP

FROM SALA

Rezultatul va fi urmatorul:

SORT_V

Se pot aplica, de asemenea, si combinatii ale acestora; in acest fel se creeaza vederi mixte. Vom considera urmatorul scenariu (figura 80):

Figura 80. Scenariu de lucru pentru crearea vederilor mixte

Structura bazelor de date pentru acest scenariu este exemplificata in cele ce urmeaza. Pentru personalul angajat vom avea urmatoarea structura (tabelul 29):

Tabelul 29. Structura personal angajat (SALA)

CNP - Cod numeric personal (identificator unic)

Pentru obiectivele pe care firma le are de executat vom avea urmatoarea structura (tabelul 30):

Tabelul 30. Structura proiecte firma (PROI).

DENP - denumire proiect, OBIE - obiectiv, CLIE - client/beneficiar, MANA - responsabil proiect.

Tabela de legaturi are urmatorul continut (tabelul 31):

Tabelul 31. Tabela de legaturi (LEGA)

Aplicam vederile.

CREATE VIEW SALA_PROD AS

SELECT CNP, NUME, COMP FROM SALA

WHERE COMP = P

Cu rezultatul (tabelul 32):

Tabelul 32. Vedere SALA_PROD.

si

CREATE VIEW COMP_ANTR AS SELECT DENP, OBIE, COMP FROM PROI, LEGA, ANGA WHERE SALA.CNP = LEGA.CNP AND LEGA.DENP = PROI.DNP

Cu rezultatul (tabelul 33):

Tabelul 33. Vedere COMP_ANTR

Acest mecanism de securitate este aplicat in SQL. La definirea vederilor prin CREATE VIEW, se poate limita accesul numai la bazele de date al caror proprietar este utilizatorul respectiv, folosind o conditie selectie cu cuvantul cheie USER, prin care se da identificatorul utilizatorului. Orice operatie din baza de date se face numai pe baza unei autorizari pentru acea operatie. Initial, sistemul acorda toate drepturile de operare pentru administratorul sistemului (SYSADM) si nu acorda nici un drept celorlalti utilizatori. Ulterior, drepturile de operare pentru utilizatori sunt stabilite de catre administratorul sistemului prin intermediul instructiunii GRANT si revocate prin instructiunea REVOKE. Sintaxa acestor comenzi este exemplificata in figura 81.

Figura 81. Sintaxa comenzilor GRANT si REVOKE

2. Arhitecturi pentru asigurarea securitatii
bazelor de date

La ora actuala exista doua abordari majore pentru asigurarea securitatii bazelor de date. Acestea au in vedere increderea care poate fi acordata celor doua elemente care vor interactiona cu bazele de date, si anume: sistemul de gestiune al bazelor de date (SGBD) si sistemul de operare (SO[1]).

Tinand cont de acestea, vom avea urmatoarele doua abordari:

arhitectura cu subiecti siguri;

arhitectura cu subiecti nesiguri.[2]

Arhitectura cu subiecti siguri porneste de la presupunerea ca atat SGBD-ul, cat si SO care vor interactiona cu bazele de date sunt sigure (de incredere). Aceasta abordare se intalneste la majoritatea SGBD-urilor (Sybase, Informix, Ingres, Oracle, DEC, Rubix).

Arhitectura cu subiecti nesiguri porneste de la presupunerea ca SO este sigur, dar SGBD-ul este nesigur.

Aceasta arhitectura este implementata in trei variante:

arhitectura cu blocarea integritatii;

arhitectura integrata;

arhitectura replicata/distribuita.

Acest tip de arhitectura se implementeaza la SGBD-urile TRUEDATA si Oracle, precum si la altele mai putin cunoscute, aflate in faza de prototipuri, Mitre si SeaView.

Arhitectura cu subiecti siguri este prezentata in figura 82.

Figura 82. Arhitectura cu subiecti siguri

Intrucat se pleaca de la presupunerea ca atat SDBD-ul, cat si SO asigura o protectie suficienta, mecanismele de securitate de tip front end nu sunt implementate in versiuni sofisticate. Se observa ca atat utilizatorii cu drepturi depline (superutilizatorii), cat si utilizatorii cu restrictii au acces la date beneficiind de securitatea asigurata de SGBD si SO.

Arhitecturile cu subiecti nesiguri merg pe presupunerea ca SO asigura o protectie de nivel inalt, iar SGBD-ul o protectie medie. In acest caz, mecanismele de securitate de tip front end trebuie sa asigure o securitate ridicata.

Arhitectura cu blocarea integritatii este prezentata in figura 83.

Se observa ca mecanismul de securitate front end dispune de o puternica unitate de criptare, care asigura accesul la date atat pentru utilizatorul cu drepturi depline, cat si pentru utilizatorul care are restrictii la accesare. Fiecare, insa, la datele pentru care are drepturi de accesare.

In cazul arhitecturii integrate (figura 84), accesul se face prin doua tipuri distincte de SGBD-uri. Sistemul de operare, care este considerat sigur, va avea un rol important in asigurarea accesului la datele care sunt dispuse pe disc. Din punct de vedere al accesului la date se observa o asemanare cu arhitectura replicata/distribuita (figura 85).

Arhitectura replicata/distribuita (figura 85) foloseste un mecanism de replicare sigur care va canaliza cererile. Utilizatorul cu drepturi depline (superutilizatorul) va avea acces, prin intermediul acestui mecanism, si la datele utilizatorului cu restrictii (daca este specificat aceasta in drepturile de acces).