Universitatea “Politehnica” din Bucureşt

Facultatea de Electronică, Telecomunicaţii şi Tehnologia Informaţiei

Securitatea bazelor de date

Andrei-Alexandru UNGHIANU
Cuprins:

Securitatea bazelor de date.........................................................................................................3

1.ADMINISTRATORUL BAZEI DATE.....................................................................3
2.PRODUSE DE BAZE DATE ŞI SECURITATE...................................................4
3.CUM POATE DEVENII O BAZĂ DE DATE SECURIZATĂ?.........................5
3.1.Personal Oracle şi Securitatea......................................................................5
3.1.1.Crearea de utilizatori.....................................................................5
3.1.2.Crearea de roluri............................................................................8
3.1.3.Privilegiile de utilizator...............................................................12
3.2.De la crearea de roluri la alocarea acestora................................................18
3.3.Definirea unei tabele..................................................................................20
3.4.Folosirea view-urilor în scopuri de securitate............................................23
3.5.O soluţie simplă pentru definiea unei tabele sau view...............................24
3.6.Folosirea Synonym-urilor în locul View-urilor..........................................25
3.7.Folosirea View-urilor pentru rezolvarea problemelor de securitate...........25
3.8.Folosirea clauzei WITH GRANT OPTION...............................................28
4.BIBLIOGRAFIE.......................................................................................................31

2
Securitatea bazelor de date

Astăzi vom discuta despre sucuritatea bazelor de date. Ne vom uita în mod deosebit la diferite
comenzi şi construcţii SQL care să ne ajute să administrăm în mod eficient o bază de date
relaţională.
Ca şi în alte subiecte studiate până acum, modul în care sistemul de management al bazei de
date implementează securitatea, variază de la un produs la altul. Pentru introducerea în
această temă vom folosi Oracle7. La sfârşitul zilei, vom fi capabili să realizăm următoarele:
- crearea de utlizatori
- schimbarea parolelor
- crearea de roluri
- folosirea view-urilor în scopuri de securitate
- folosirea elementelor synonym în locul view-urilor

1.ADMINISTRATORUL BAZEI DATE

Securitatea este adesea un aspect cerut în arhitectura unei baze de date. Majoritatea
profesioniştilor în calculatoare intră în lumea acestora cu câteva cunoştiinţe de hardware sau
de programare, şi tind să se axeze pe aceste arii. De exemplu, dacă şeful tău ţi-ar cere să
lucrezi într-un proiect care cere implemntarea unei baze de date relaţionale, care ar fi primul
pas pe care l-ai face? După ce ai ales un tip de hardware şi software, probabil că ai incepe a
constui arhitectura de bază a bazei de date pentru proiect. Această etapă, în mod gradat va fi
împărţită între mai multe personae – una dintre ele poate implementa interfaţa grafică de
utilizator, alta poate construi componentele de nivel jos. Probabil că tu, după ce vei fi citit
această carte, vei fi solicitat pentru a scrie codul interogările SQL ce oferă funcţionalitate
acestei aplicaţii. Odata cu această sarcină, vine şi responsabilitatea efectivă de a administra şi
menţine operaţională baza de date.
De multe ori, puţin din ce a fost plănuit intră defapt în faza de producţie a aplicaţiei. Ce se
îmtâmplă cand multor utilizatori le este permisă folosirea aplicaţiei peste Wide Area Network
(WAN)? Cu softul avansat ce rulează pe calculatoarele personale din ziua de astăzi, şi cu
tehnologii cum ar fi Open Database Connectivity ( ODBC ) de la Microsoft, orice utilizator
cu acces la reţeaua ta, poate găsi o modalitate de a accesa baza ta de date. ( Nici macăr nu
luăm în considerare complexitatea indusă în momentul în care compania ta decide să
coneteze reţeaua locală la Internet sau la altă reţea de calculatoare de domeniu întins! ). Eşti
pregătit să faci faţă acestei situaţii?

3
Din fericire, producatorii software pun la dispoziţie majoritatea uneltelor necesare pentru
rezolvarea problemei legate de securitate. Fiecare lansare a unui nou sistem de operare se
confruntă cu cerinţe de securitate mai stricte decât prececesorii săi. În plus, majoritatea
producătorilor de baze de date construiesc un anumit grad de securitate pentru produsele lor,
care există independent de sistemul de operare sau securitatea reţelei. Implementarea acestor
comportamente de securitate diferă major de la un produs la altul.

2.PRODUSE DE BAZE DATE ŞI SECURITATE

Fiecare furnizor are nevoie de tine pe termen scurt şi pe termen lung. În timpul fazei de
dezvoltare a proiectului, s-ar putea să cumperi un număr mic de licenţe de produs pentru
testare, dezvoltare şi aşa mai departe. Oricum, numărul total de licenţe necesar pentru
producţia bazei de date poate ajunge la numărul sutelor sau chiar miilor. În plus, atunci când
te hotărăşti să foloseşti un anumit produs de baze de date, sunt şanse să îl foloseşti mai mulţi
ani. Mai jos sunt câteva aspecte ce ar trebui reţinute atunci cand examinezi aceste produse:
- Sistemul de management Microsoft FoxPro este un sistem de baze de date
puternic care este folosit în mod principal într-un mediu în care este un singur
utilizator. FoxPro foloseşte un set limitat de comenzi SQL. Acest sistem nu oferă
nicio măsură de siguranţă. De asemenea foloseşte un format al fişierelor de tip
Xbase, fiecare fişier conţinând un table. Indecşii sunt stocate în fişiere separate.
- Sistemul de management al bazei de date relaţionale Microsoft Access
implementează mai mult din SQL. Microsoft Access este încă destinat utilizării
pe platformele PC-urilor, cu toate că acesta conţine un sistem de securitate
rudimentar. Acest produs oferă posibilitatea creării de interogări şi stocarea
acestora în baza de date. În plus, întreaga bază de date şi toate obiectele acesteia
sunt pastrate într-un singur fişier.
- Sistemul de management al bazei de date relaţionale Oracle7 suportă aproape
întregul standard SQL. În plus, Oracle şi-a adăugat propia extensie la SQL, numită
PL*SQL. Acest produs conţine comportamente întregi de securitate, inclusive
capabilitatea de a crea roluri şi asignarea unor permisii şi privilegii asupra
obiectelor din baza de date.
- Serverul Sysbase SQL ca performanţă şi comportament este asemănător cu
produsul Oracle. Serverul SQL oferă de asemenea, oferă un domeniu larg de
trăsături de securitate şi are propia sa extensie relative la limbajul SQL, numită
Transact-SQL.
Scopul descrierii acestor produse este acela de a ilustra aceea că nu toate produsele sunt
potrivite pentru orice tip de aplicaţie. Dacă eşti într-un mediu business, opţiunile tale pot fi
limitate. Factori cum ar fi costul si performanţa sunt extreme de importanţi. Oricum, fară
măsurile de securitate potrivite, orice salvări pe care baza ta de date le face pot fi cu uşurinţă
compensate de probleme de securitate.

4
3.CUM POATE DEVENII O BAZĂ DE DATE SECURIZATĂ?

Până în acest punct nu te-ai preocupat prea mult de “securitatea” bazei de date pe care ai
creat-o. Te-ai gândit ca poate nu ai vrea ca alţi utilizatori să acceseze şi să manipuleze
informaţiile din baza ta de date pe care le-ai introdus cu atenţie? Care ar fi reacţia ta dacă te-
ai loga pe server într-o dimineaţă şi ai descoperi că baza ta de date a fost ştearsă ( aduţi
aminte cât de uşor poate fi folosită comanda DROP DATABASE). Vom examina în detaliu
cum un sistem popular de management al bazei de date (Personal Oracle7) oferă posibilitatea
creării unei baze de date securizate. Vei fi capabil să aplici majoritatea acestor informaţii şi
altor sisteme de management al bazelor de date, deci citeşte aceste informaţii chiar daca nu ai
ales să foloseşti Oracle ca system de management al bazei de date.

NOTĂ: Ţine minte următoarele întrebări pe măsură ce planuieşti sistemul de securitate:

- Cine obiţine rolul de DBA (Administratorul Bazei de Date)?
- Câţi utilizatori vor avea nevoie să acceseze baza de date?
- Ce utilizatori vor avea nevoie de ce privilegii şi ce roluri?
- Cum vei şterge utilizatorii care nu mai au nevoie de acces la baza de date?

3.1.Personal Oracle şi Securitatea

Oracle7 implementează securitatea folosind trei construcţii:

- Utilizatori
- Roluri
- Privilegii

3.1.1.Crearea de utilizatori
Utilizatorii sunt repreznetaţi prin conturi la care sunt ataşate nume, şi cărora le este permis să
se conecteze la baza de date Oracle. Sintaxa SQL utilizată pentru a crea un tilizator este
următoarea:
SINTAXĂ:
CREATE USER user
IDENTIFIED {BY password | EXTERNALLY}
[DEFAULT TABLESPACE tablespace]
[TEMPORARY TABLESPACE tablespace]
[QUOTA {integer [K|M] | UNLIMITED} ON tablespace]

5
[PROFILE profile]

Dacă este aleasă opţiunea By password, sistemul atenţionează utilizator ca trebuie să

introducăo parolă de fiecare dată cand se conectează. Ca exemplu, crează un username:

De fiecare dată când mă voi conecta cu usernem-ul Dani, şi mi se fa cere să intru parola:
oracle.
Dacă este aleasă opţiunea EXTERNALLY, Oracle va folosi username-ul şi parola de la
calculator. Când te conectezi la calculatorul tau, automat esti conectat si la baza de date
Oracle.

NOTĂ: Anumite implementări te lasă să foloseşti parola external sau a sistemului de

operare, ca parolă implicită când foloseşti SQL (IDENTIFIED externally). Oricum, noi
recomandam forţarea utilizatorului să introducă o parolă utilizând clauza IDENTIFIED BY
(IDENTIFIED BY password).

După cum puteţi vedea uitându-vă la restul sintaxei CREATE USER, Oracle permite de
asemenea crearea de locaţii de stocare pentru fişierele bazei de date, numite tablespaces. Poţi
să aflii mai multe despre acestea examinând documentaţia Oracle. La fel ca oricărei alte
comezi de tip CREATE pe care le-ai învăţat în această carte, există o comandă ALTER.
Acesta arată astfel:
SINTAXĂ:
ALTER USER user
[IDENTIFIED {BY password | EXTERNALLY}]
[DEFAULT TABLESPACE tablespace]
[TEMPORARY TABLESPACE tablespace]
[QUOTA {integer [K|M] | UNLIMITED} ON tablespace]

6
[PROFILE profile]
[DEFAULT ROLE { role [, role] ...
| ALL [EXCEPT role [, role] ...] | NONE}]

Poţi folosi această comandă pentru a folosi toate opţiunile utilizatorului, inclusiv parola şi
profilul. De exemplu putem schimba parola utilizatorului Dani, astfel:

Pentru a schimba locaţia implicită tablespace, daţi comanda:

Pentru a elimina un utilizator, utilizaţi comanda DROP USER, care elimină intrarea
utilizatorului în sistemul bazei de date. Sintaxa pentru această comandă este:
SINTAXĂ:
DROP USER user_name [CASCADE];

7
Dacă este aleasă opţiunea CASCADE, toate obiectele ce aparţin utlizatorului sunt eliminate
odata cu eliminarea contului acestuia. Dacă nu este folosită opţiunea CASCADE şi
utilizatorul reprezentat prin user_name încă deţine toate obiectele, nu este permisă eliminarea
acelui cont de utiliazator. Acest comportament este într-un fel derutant, dar este folositor în
cazul ştergerii conturilor de utilizator.

3.1.2.Crearea de roluri
Un rol este un privilegiu sau o colecţie de privilegii care permit unui utilizator să execute
anumite funcţii în baza de date. Pentru a permite un rol unui utilizator, se foloseşte
următoarea sintaxă:
SINTAXĂ:
GRANT role TO user [WITH ADMIN OPTION];

Dacă opţiunea WITH ADMIN OPTION este folosită, acel utilizator poate crea roluri altor
utilizatori.

8
Pentru a elimina un rol, se foloseşte comanda REVOKE.
SINTAXĂ:
REVOKE role FROM user;

Odată ce te-ai conectat la sistem folosind contul creat anterior, se aplică limitele permise
contului creat(pentru contul de utilizator Dani sau Student, utilizatorului Operator i s-a ataşat
un rol, insă nu a fost definit deocamdată niciun privilegiu acestui rol). Te poţi conecta, dar
acesta e tot ceea ce poţi face. Oracle te lasă să te conectezi cu următoarele drepturi de
utilizator:
- Conectare
- Resource (cu rol de creare proceduri, tabele, cluster, trigger şi altele)
- DBA (administrator de baze de date)

Aceste trei roluri au diferite privilegii.

NOTĂ: Dacă ai privilegiile necesare, poţi creea propriul tău rol, să dai privilegii rolului tău, şi
apoi să dai rolul acesta apoi unui altui utilizator din motive de securitate.

Rolul CONNECT
Rolul CONNECT poate fi vazut ca un role de început. Unui utilizator care are rolul Connect i
se pot da diferite privilegii ce îi permit acestuia sau acesteia să manipuleze cumva baza de
date.

9
Rolul Connect permite utilizatorului următoarele operaţii: select, update, si ştergerea de
înregistrări din tabele ce aparţin altor utilizatori (după ce au fost atribuite permisiunile
necesare). Utilizatorul poate de asemenea crea tabele, view-uri, secvenţe, cluster-e şi
synonyms.
Rolul RESOURCE
Rolul Resource oferă utilizatorului mai mult acces la baza de date oracle. În plus faţă de
permisiunile pe care le oferă rolul Connect, rolul Resource oferă posibilitarea creării de
proceduri, trigger-e şi indecşi.

10
Rolul DBA
Rolul DBA include toate privilegiile. Utilizatorii cu acest rol sunt capabili să facă orice
sistemului de baze de date. Ar trebui să se păstreze cât mai mic numărul de utilizatori cu acest
rol pentru a asigura integritatea sistemului.

Urmărind cei trei paşi, utilizatorului Operator2 i s-au dat rolurile Connect, Resource şi DBA.
Acest lucru este oarecum redundant deoarece rolul DBA le cuprinde pe celelalte două roluri,
deci poţi renunţa la celelalte două, după cum urmează:

11
Operator2 poate face orice are doreşte cu rolul de administrator DBA.

3.1.3.Privilegiile de utilizator
După ce te-ai hotărat ce roluri să dai utilizatorilor tăi, următorul pas este să hotărăşti ce
permisiuni să aibă acesti utilizatori asupra obiectelor din baza de date. (Oracle7 numeşte
aceste permisiuni privilegii.) Aceste tipuri de privilegii variază, depinzând de rolul care a fost
atribuit utilizatorului. Dacă creezi un obiect, poţi atribui anumite privilegii utilizatorilor
asupra acelui obiect, atâta timp cât rolul acestora le permite accesul la acel privilegiu. Oracle
defineşte două tipuri de privilegii care pot fi atribuite utilizatorilor: privilegii referitoare la
sistem şi privilegii referitoare la obiecte. (A se vedea tabelul 1 şi 2.)
Privilegiile referitoare la sistem se aplică pe întregul sistem. Sintaxa utlizată pentru a atribui
un privilegiu de sistem este următoarea:
SINTAXĂ:
GRANT system_privilege TO {user_name | role | PUBLIC}
[WITH ADMIN OPTION];

Opţiunea WITH ADMIN OPTION oferă posibilitatea atribuirii acestui privilegiu altui
utilizator.

12
Accesul utilizatorului la VIEW-uri
Următoarea comandă permite tuturor utilizatorilor sistemului să aibă acces de tip CREATE
VIEW în baza lor de date.

ANALIZĂ:
Cuvântul cheie public înseamnă că toate are lumea are privlegii de tip CREATE VIEW.
Evident, privilegiile de sistem oferă acces aproape la toate setările de sistem. Privilegiile de
sistem ar trebui atribuite numai anumitor utilizatori sau utilizatorilor care au nevoie de aceste
privilegii. Tabelul 1 prezintă privilegiile de sistem care se regăsesc şi în meniul de help al
produsului Personal Oracle7.

AVERTIZMENT: Fii atent când atribui privilegii utilizând parametrul public. Acest tip de
atribuire permit tuturor utilizatorilor să aibă acces la privilegiile bazei de date, ceea ce
probabil nu ai vrea.

Tabel 1.Privilegii de sistem

Privilegiu de sistem Operaţiuni permise

ALTER ANY INDEX Permite celui căruia îi este atribuit

privilegiul să modifice orice index în orice
schemă

ALTER ANY PROCEDURE Permite celui căruia îi este atribuit

privilegiul să modifice orice procedură
stocată sau funcţie din schemă

ALTER ANY ROLE Permite celui căruia îi este atribuit

privilegiul să modifice orice rol din baza de

13
 date

ALTER ANY TABLE Permite celui căruia îi este atribuit

privilegiul să modifice orice tabel sau view
din schemă

ALTER ANY TRIGGER Permite celui căruia îi este atribuit

privilegiul să activeze, dezactiveze sau să
creezeun trigger în orice schemă

ALTER DATABASE Permite celui căruia îi este atribuit

privilegiul să modifice orice baza de date

ALTER USER Permite celui căruia îi este atribuit

privilegiul să modifice orice utilizator.
Acest privilegiu oferă posibilitatea celui
căruia i-a fost atribuit, să modifice parola
unui altui utilizator sau a metodei de
autentificare, stabilirea unor tablespace-uri
implicite şi temporare, şi stabilirea unor
roluri implicite

CREATE ANY INDEX Permite celui căruia îi este atribuit

privilegiul să creeze un index în orice
tabelă în orice schemă

CREATE ANY PROCEDURE Permite celui căruia îi este atribuit

privilegiul să creeze proceduri stocate sau
funcţii în orice schemă

CREATE ANY TABLE Permite celui căruia îi este atribuit

privilegiul să creeze în orice bază de date.

CREATE ANY TRIGGER Permite celui căruia îi este atribuit

privilegiul să creeze un trigger de baze de
date în orice schemă asociat unui tabel în
orice schemă

CREATE ANY VIEW Permite celui căruia îi este atribuit

privilegiul să creeze view-uri în schemă

CREATE PROCEDURE Permite celui căruia îi este atribuit

privilegiul să creeze proceduri stocate sau
funcţii în propria lor schemă

CREATE PROFILE Permite celui căruia îi este atribuit

privilegiul să creeze profile

CREATE ROLE Permite celui căruia îi este atribuit

privilegiul să creeze roluri

CREATE SYNONYM Permite celui căruia îi este atribuit

privilegiul să creeze elemente synonym în

14
 propria lor schemă

CREATE TABLE Permite celui căruia îi este atribuit

privilegiul să creeze tabele în proria lor
schemă

CREATE TRIGGER Permite celui căruia îi este atribuit

privilegiul să creeze un trigger în propia lor
schemă

CREATE USER Permite celui căruia îi este atribuit

privilegiul să creeze conturi de utilizator

CREATE VIEW Permite celui căruia îi este atribuit

privilegiul să creeze în propia lor schemă

DELETE ANY TABLE Permite celui căruia îi este atribuit

privilegiul să şteargă înregistrări din tabele
sau view-uri din orice bază de date sau sp
golească tabele din orice schemă

DROP ANY INDEX Permite celui căruia îi este atribuit

privilegiul să elimine indecşi din orice
schemă

DROP ANY PROCEDURE Permite celui căruia îi este atribuit

privilegiul să elimine proceduri stocate sau
funcţii din orice schemă

DROP ANY ROLE Permite celui căruia îi este atribuit

privilegiul să elimine roluri

DROP ANY SYNONYM Permite celui căruia îi este atribuit

privilegiul să elimine elemente synonym de
tip privat din orice schemă

DROP ANY TABLE Permite celui căruia îi este atribuit

privilegiul să elimine tabele din orice
schemă

DROP ANY TRIGGER Permite celui căruia îi este atribuit

privilegiul să elimine trigger-e din orice
schemă

DROP ANY VIEW Permite celui căruia îi este atribuit

privilegiul să elimine view-uri din orice
schemă

DROP USER Permite celui căruia îi este atribuit

privilegiul să elimine utilizatori

EXECUTE ANY PROCEDURE Permite celui căruia îi este atribuit

privilegiul să execute proceduri sau funcţii

15
 GRANT ANY PRIVILEGE Permite celui căruia îi este atribuit
privilegiul să permită orice privilegiu de
sistem

GRANT ANY ROLE Permite celui căruia îi este atribuit

privilegiul să atribuie orice rol în baza de
date

INSERT ANY TABLE Permite celui căruia îi este atribuit

privilegiul să înregistrări într-o tabelă şi
view-uri într-o schemă

LOCK ANY TABLE Permite celui căruia îi este atribuit

privilegiul să blocheze tabele şi view-uri în
orice schemă

SELECT ANY SEQUENCE Permite celui căruia îi este atribuit

privilegiul să facă referire la orice secvenţă
din orice schemă

SELECT ANY TABLE Permite celui căruia îi este atribuit

privilegiul să interogheze tabele, view-uri
în orice schemă

UPDATE ANY ROWS Permite celui căruia îi este atribuit

privilegiul să actualizeze înregistrări în
orice bază de date

Privilegiile referitoare la obiecte sunt privilegii ce pot fi folosite împotriva anumitor obiecte
ale bazei de date. Acestea sunt prezentate în tabelul 2.

Tabel 2. Privilegii referitoare la obiecte

ALL

ALTER

DELETE

EXECUTE

INDEX

INSERT

REFERENCES

16
 SELECT

UPDATE

Poţi folosi următoarele forme ale comenzii GRANT pentru a altor utilizatori acces la tabelele
tale:
SINTAXĂ:
GRANT {object_priv | ALL [PRIVILEGES]} [ (column
[, column]...) ]
[, {object_priv | ALL [PRIVILEGES]} [ (column
[, column] ...) ] ] ...
ON [schema.]object
TO {user | role | PUBLIC} [, {user | role | PUBLIC}] ...
[WITH GRANT OPTION]

Pentru a elimina un privilegiu referitor la obiect pe care l-ai atribuit unui utilizatr, foloseşte
comanda REVOKE cu următoarea sintaxă:
SINTAXĂ:
REVOKE {object_priv | ALL [PRIVILEGES]}
[, {object_priv | ALL [PRIVILEGES]} ]
ON [schema.]object
FROM {user | role | PUBLIC} [, {user | role | PUBLIC}]
[CASCADE CONSTRAINTS]

17
3.2. De la crearea de roluri la alocarea acestora
Crează o tabelă Salariati cu următoarea structură:
NAME, CHAR(30)
SALARY, NUMBER
AGE, NUMBER

Crează doi utilizatori telecom1 şi telecom2:

ANALIZĂ:
Până acum, ai creat 2 utilizatori şi ai alocat fiecăruia câte un rol diferit. Prin urmare, ei vor
avea diferite permisiuni când vor lucra cu baza de date. Prima dată crează tabela Salarii cu
următoarele informaţii:

18
Pentru acest exemplu, ai putea aloca diferite privilegii acestei tabele după nişte criterii alese
arbitrar. Presupunem că în momentul de faţă deţii privilegii de administrator şi poţi aloca
orice privilegiu de sistem. Chiar dacă nu ai privilegii de administrator, poţi să aloci privilegii
referitoare la obiectele bazei de date, asupra tabelei Salarii deoarece o deţii (presupunând că
tocmai ai creat-o).
Deoarece telecom2 are rolul de Connect, vei dori ca acesta să aibă doar privilegiul SELECT.

Deoarece telecom1 i-a fost alocat rolul Resource, îi vei permite să execute comenzile
SELECT şi INSERT asupra tabelei. Îi vei permite de asemenea să actualizeze doar valorile
aparţinând coloanei Salariu din tabela telecom.

19
Acum că au fost creaţi utilizatorii şi această tabelă, trebuie să vezi cum se accesează o tabelă
care a fost creată de alt utilizator. Atât lui telecom1 cât şi lui telecom2 le-a fost alocată
permisiunea de a executa comanda SELECT asupra tabelei telecom. Oricum, dacă teelcom2
încearcă să acceseze tabela telecom, va primi un mesaj în care i se va spune că aceasta nu
există pentru că Oracle are nevoie de username sau schema ce deţine tabela pentru a întoarce
numele tabelei.

3.3.Definirea unei tabele

Trebuie reţinut username-ul celui care a creat tabela telecom (al meu a fost system).
Pentru ca telecom1 să poată executa SELECT asupra tabelei telecom, trebuie să indexeze
tabela cu acel username.

Aici telecom1 a fost avertizat că acea tabelă nu există. Acum folosiţi username-ul celui care a
creat tabela (system în acest caz):

20
ANALIZĂ:
După cum vezi de data aceasta interogarea a funcţionat. Acum testează privilegiile de acces
ale telecom2. Prima dată conectează-te cu username-ul telecom2 (se foloseşte parola definită
mai sus, şi anume oracle).

A funcţionat cum ne aşteptam. Acum încearcă să inserezi o nouă înregistrare în tabelă.

21
ANALIZĂ:
Această operaţie nu a funcţionat deoarece telecom2 nu beneficiază de privilegiul e a executa
comanda INSERT asupra tabelei telecom.

Încă o dată, telecom2 încearcă să beneficieze de privilegiile care i s-au dat. Normal, ea are
drept de UPDATE, însă doar pentru înregistrările corespunzătoare coloanei nr_telf.

22
ANALIZĂ:
După cum se vede actualizarea tabelei merge, atâta timp cât telecom2 respectă privilegiile ce
i-au fost alocate.

3.4.Folosirea view-urilor în scopuri de securitate

Cum am menţionat în materialele anterioare, View-urile sunt tabele virtuale pe care le pouteţi
folosi pentru a prezenta o vedere asupra datelor care diferă de modul fizic faţă de cum sunt
păstrate în baza de date. Astăzi veţi învăţa mai multe despre modul cum puteţi folosi aceste
view-uri pentru a implementa măsuri de securitate.
Ma devreme aţi învăţat aceea că atunci când un utilizator doreşte să acceseze o tabelă sau un
obiect al bazei de date, elemente ce sunt deţinute de alt utilizator, trebuie să se facă referire la
username-ul celui ce a creat obiectele. După cum puteţi să vă imaginaţi, acest procedeu mai
complex în cuvinte, când este vorba de scrierea mai multor interogări într-un singur rând. Cel
mai important, utilizatori noi ai bazei de date trebuie prima dată să determine cine este
deţinătorul tabelei şi apoi pot extrage date din aceasta, ceea ce nu este ceva ce aţi vrea să facă
toţi utilizatorii. O soluţie mai simplă este prezentată prezentată în paragraful ce urmează.

23
3.5.O soluţie simplă pentru definiea unei tabele sau view
Presupunând că te-ai logat ca teltelecom1, utilizator creat anterior. După cum aţi observat, ca
telecom1 să poată accesa conţinutul tabelei telecom, acesta trebuie să folosească următoarea
comadă:

Dacă ar fi să creaţi un view numit telecom_VIEW, un utilizator a putea să extragă date din
aceasta fără nicio problemă.

24
ANALIZĂ:
Interogarea anterioară a îmtors aceleaşi rezultate ca şi cea din system.telecom.

3.6.Folosirea Synonym-urilor în locul View-urilor

SQL oferă un obiect denumit synonym (sinonim). Un synonym oferă un alt nume pentru o
tabelă. Există două tipuri de synonym-uri: private şi publice. Orice utilizator cu rolul resource
poate crea un synonym de tip privat. Pe de altă parte, doar un utilizator cu rol de DBA poate
crea un synonym public.
Sintaxa pentru un synonym de tip public este următoarea.
SINTAXĂ:
CREATE [PUBLIC] SYNONYM [schema.]synonym
FOR [schema.]object[@dblink]

3.7.Folosirea View-urilor pentru rezolvarea problemelor de securitate

Să presupunem că v-aţi răzgandit şi aţi decis ca nici telecom1 şi nici telecom2 să nu poată să
aibă acces la toate datele din tabela telecom. Puteţi folosi view-uri pentru a schimba această
situaţie şi să le permiteţi examinarea informaţiilor proprii.

25
Acum conectează-te cu username-ul lui telecom1 şi testează accesul la datele din view-ul ce a
fost creat pentru acesta.

26
După cum se poate observa, telecom1 nu mai are acces la tabela telecom ci doar la view-ul ce
i-a fost creat şi i s-a alocat un privilegiu asupra acestuia.
Decontaţi-vă şi conectaţi-vă pe contul de utilizator al telecom2 pentru a testa privilegiile pe
care acesta le are asupra tabelei şi asupra view-ului care i-a fost creat şi asupra căruia i s-a
alocat un privilegiu.

ANALIZĂ:
După cum puteţi vedea, accesul la tabela telecom a fost complet controlat folosind view-uri.

27
SQL vă oferă posibilitatea de a crea aceste view-uri cum doriţi şi apoi să alocaţi permisiuni
celorlalţi utilizatori asupra acestora. Această tehnică vă permite o flexibilitate mare.
Sintaxa pentru a elimina un synonym este:
SQL> drop [public] synonym synonym_name;

NOTĂ: Până acum, ar trebui să fi înţeles cât de important este să menţinem un număr cât mai
mic de utilizatori cu rol de DBA. Un utilizator cu acest nivel de acces, are acces complet
asupra tuturor comenzilor şi operaţiilor ce se pot executa asupra bazei de date. Ţine-ţi minte
că pentru a putea importa sau exporta date din baza de date trebuie să aveţi acces de nivel
DBA dacă folosiţi Oracle sau acces de nivel SA dacă folosiţi Sybase.

3.8.Folosirea clauzei WITH GRANT OPTION

Ce credeţi că ar putea să se întâmple dacă telecom2 i-ar pasa privilegiul ei de UPDATE lui
telecom1? La prima vedere ai putea să crezi că telecom2, pentru că este entuziasmat de
privilegiul lui, UPDATE, este capabil să îl paseze mai departe altor utilizatori cărora le este
permisă folosirea acestui privilegiu, însă nu îl deţin. Oricum, folosirea expresiei GRANT aşa
cum a fost folosită mai devreme, nu îi permitea utilizatorului telecom2 să aloce mai departe
altor utilizatori privilegiile lui.

Aceasta este sintaxa comenzii GRANT ce a fost introdusă mai devreme.

28
SINTAXĂ:
GRANT {object_priv | ALL [PRIVILEGES]} [ (column
[, column]...) ]
[, {object_priv | ALL [PRIVILEGES]} [ (column
[, column] ...) ] ] ...
ON [schema.]object
TO {user | role | PUBLIC} [, {user | role | PUBLIC}] ...
[WITH GRANT OPTION]
Ceea ce ne interesează în acest moment este opţiunea WITH GRANT OPTION de la sfârşitul
comenzii. Când privilegiile de obiect sunt alocate şi este folosită opţiunea WITH GRANT
OPTION, aceste privilegii pot fi pasate mai departe şi altor utilizatori. Deci dacă doriţi ca
telecom2 să paseze mai departe lui telecom1 aceste privilegii, se precedează astfel:

Apoi telecom2 se poate conecta la baza de date şi da următoarea comandă:

Acum ne putem conecta cu username-ul lui telecom1 să verificăm dacă într-adevăr acesta are
areste privilegii asupra tabelei telecom.

29
Nu uitaţi că mai sus când am creat view-urile atât pentru telecom1 cât şi pentru telecom2, li s-
a revocat amândurora dreptul la privilegiul SELECT asupra tabelei telecom. Însă apoi i s-a
atribuit din nou utilizatorului telecom2 acest privilegiu, dar nu şi lui telecom1. Telecom1 are
acest privilegiu nu de la utilizatorul ce a creat tabela, ci de la telecom2 care i l-a pasat lui mai
departe.

30
4.BIBLIOGRAFIE

1. Burtescu, E. Problems of Inference in Databases in „Education, Research & Business

Technologies“. The Proceeding of the 9th International Conference on Economic Informatics,
INFOREC Printing House, Bucharest, 2009
2. Burtescu, E. Databse security, in „Knowledge Management. Projects, Systems and
Technologies“, International Conference „Knowledge Management. Projects, Systems and
Technologies“, Bucharest, November 9-10, 2006, INFOREC Printing House, Bucharest,
2006
3. Hsiao, S.B. and Stemp, R. Computer Security, course, CS 4601, Monterey, California,
1995
4. McCarthy, L. IT Security: Risking the Corporation, Prentice Hall PTR, 2003
5. Proctor, P.E. and Byrnes, F.C. The Secured Enterprise, Prentice Hall PTR, 2002
6. * * * Security Complete, Second Edition, SYBEX Inc., 2002
7.http://www.oracle.com/index.html, 03.01.2019
8.http://www.microsoft.com/romania/Servere/SQL/default.mspx, 04.01.2019
9.http://www.microsoft.com/sqlserver/2008/en/us/default.aspx, 04.01.2019
10.http://office.microsoft.com/ro-ro/access/default.aspx, 05.01.2019

31