Baze de Date pentru Telecomunicaţii

Lucrarea 6

Securitatea bazelor de date

Prof.Coord.: Student:
Dan Galatchi Scarlat Daniela-Andreea
Master: MSR

Bucureşti,2010
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.REZUMAT................................................................................................................31
5.APLICAŢIE PRACTICĂ........................................................................................32
APENDIX:...................................................................................................................51

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.REZUMAT

Securitatea este adesea un subiect supra-estimat care poate cauza multe probleme daca nu
este gândită şi administrată corespunzător. Din fericire, SQL oferă mai multe comenzi
ajutătoare pentru a implementa securitatea într-o bază de date.
Conturile de utilizator sunt iniţial create folosind comanda CREATE USER, care alocă un
username şi o parolă acelui utilizator. După ce contul de utilizator a fost creat, acestui
utilizator îi trebuie alocat un rol pentru a putea să lucreze cu baza de date. Cele trei roluri
puse la dispoziţie de produsul Oracle7 sunt Connect, Resource, şi DBA. Fiecare rol are
diferite nivele de acces la baza de date, Connect fiind cel mai simplu şi DBA oferind acces la
orice.
Comanda GRANT oferă utilizatorului o permisiune sau un privilegiu. Comanda REVOKE
poate lăsa utilizatorul fară această permisiune sau privilegiu. Cele două tipuri de privilegiu
sunt privilegii referitoare la sistem şi privilegii referitoare la obiecte. Privilegiile de sistem ar
trebui monitorizate în detaliu şi nu ar trebui alocate utilizatorilor neexperimentaţi. Oferind
acces la aceste comenzi utilizatorilor neexperimentaţi le oferă acestora posibilitatea (din
neatenţie probabil) să distrugă datele sau baza de date pe te-ai chinuit să o construieşti.
Privilegiile referitoare la obiecte le oferă utilizatorilor accesul la obiectele individuale ce
există în baza de date.
Toate aceste tehnici şi expresii SQL pun la dispoziţie utilizatorului SQL un domeniu larg de
unelte pe care să le folosească atunci când realizează sistemul de securitate. Deşi am pus
accentul pe comportamentele de securitate ale produsului Oracle7, poţi aplica o mare parte
din aceste informaţii propriului tău sistem de baze de date. Adu-ţi aminte că nu contează ce
produs foloseşti, ci este important să întăreşti anumite nivele de securitate ale bazei de date.

31
5. APLICAŢIE PRACTICĂ
Această aplicaţie constă în crearea unei baze de date a unui operator telecom. Cu această baza
de date mai interacţionează mai mulţi utilizatori. Nu toţi utilizatorii au aceleaşi drepturi de
acces la baza de date. Unii vor avea drept de vizualizare a datelor, dar nu de modificare iar
alţii vor avea dreptul să le şi modifice.
I)Se vor crea 3 tabele:
- Clienti_telecom: această tabelă conţine datele clienţilor telecom, printre care
cateva date personale ale acestora, numărul de telefon ce le-a fost alocat, tipul de
abonament pe care îl folosesc şi valoarea facturii acestora. Aceasta va avea
următoarele câmpuri: id, nume, prenume, varsta, categorie, tip_ab, factură.
- Servicii_voce: această tabelă se referă la tipurile de servicii de voce pe care acest
operator le pune la dispoziţie. Acestea sunt: fluture8, fluture12, fluture24, delfin8,
delfin12, delfin24, pantera8, pantera12, pantera24. Acesta tabelă va conţine
următoarele câmpuri: categorie, min_nat, min_int, min_retea, sms_retea, sms_nat,
mms, date_internet.
- Servicii_date: această tabelă prezintă pachetele de date pe care acest operator le
pune la dispoziţie. Aceste pachete sunt: date1, date2, date3. Aceată tabelă are
următoarele câmpur: categorie, volum.
În acest punct se vor folosi comenzile de creare a unui tabel şi descrierea acestora
DESCRIBE <table>
II)Utilizatorii care vor interacţiona cu această bază de date sunt:
- Operator_voce: acest operator este un operator de tip call center şi oferă informaţii
clienţilor referitoare la abonamentul lor, la factură, la opţiunile tipurilor de servicii
de voce.
- Operator_date: acest operator este un operator la fel ca şi cel de voce, oferă
informaţii referitoare la abonamentul clienţilor, factură şi opţiunile tipurilor de
servicii de date.
- Op_imp_voce: acest operator se ocupă implementarea noilor clienţi ce utilizează
servicii de voce, adăugarea acestuia în tabela clienţi telecom, actualizarea datelor
acestora fie personale fie legate de abonament. Acest operator nu are dreptul de a
actualiza valoarea facturii unui client, însă are dreptul de a actualiza restul
informaţiilor. Cu actualizarea valorii facturii se ocupă alt operator. Acest operator
va avea dreptul de eliminarea unul client din tabela clienţ telecom, după ce acesta
încetează să mai folosească serviciile acestui operator.
- Op_imp_date: acest operator se ocupă cu implementarea de noi clienţi pe partea
de servicii de date. Are dreptul de introducerea in tabela clienti_telecom a unor noi
utilizatori, actualizarea informaţiilor acestora (mai puţin datele legate de factură),
vizualizarea lor, ştergerea acestuia din tabela clienţi după ce aceştia încetează
colaborarea cu operatorul.
- Op_factura: acest operator se ocupă cu actualizarea valorii facturii clientului
telecom. Acesta va avea dreptul de a vizualiza datele legate clientului, şi
actualizarea valorii facturii.
În acest punct se vor crea utilizatorii şi din motive de securitate îşi vor schimba parolele la
contul de utilizator, pentru a fi ştiute numai de ei.

32
III)Drepturile utilizatorilor asupra celor trei tabele:
- Operator_voce va avea rolul de connect şi permisiunea de a executa comanda
SELECT asupra tabelei servicii_voce şi asupra unui view creat pentru acesta, un
view ce conţine informaţii despre client (nume, prenume, nr_telf, tip_ab unde
categoria este voce).
- Operator_date va avea rolul de connect şi permisiunea de a executa comada
SELECT asupra tebelei servicii_date şi asupra unui view creat special pentru
acesta, cu câpurile: nume, prenume, nr_telf, tip_ab din tabela clienti_telecom,
unde categoria este cea de date.
- Op_imp_voce va avea rolul de connect şi permisiunea de a executa comenzi
asupra tebelei clienti_telecom: SELECT, UPDATE(asupra tuturor coloanelor din
tabela clienţi_telecom mai puţin cea care se referă la valoarea facturii),
permisiunea de a executa DELETE atunci când un client încetează a mai folosi
serviciile operatorului şi comanda INSERT când există un nou client. Acesta mai
poate executa comanda SELECT asupra tabelei servicii_voce.
- Op_imp_date are aceleaşi drepturi ca şi op_imp_date dar se ocupă cu
implementarea serviciilor de date. Pe lângă aceste privilegii acesta mai poate
executa şi comanda SELECT asupra tabelei servicii_date.
- Op_factura va avea rolul de a modifica voloarea facturii. Va executa comanda
UPDATE asupra tabelei client_telecom.
În acest punct se vor aloca rolurile de connect tuturor utilizatorilor. Nu am dorit un altfel de
rol pentru aceştia deoarece cea mai sigură metodă de securitate o prezintă acest rol unde
utilizatorii au cele mai restrânse permisiuni. S-a dorit acest lucru deoarece, s-a dorit un
control deplin asupra permisiunilor fiecărui utilizator în parte, astfel că acestea au fost
definite pentru fiecare, manual. Aceste drepturi au fost manipulate de către owner, cel care a
creat baza de date.
De asemenea tot în acest punct s-au introdus câteva date în tabel pentru a putea executa
rolurile acestora pe datele din tabele. Tot din motive de securitate s-au creat view-uri asupra
tabelei clienti_telecom. Aceste view-uri nu includ toate datele din tabela, ceea ce se dorea,
pentru că s-a dorit a fi ascunse câteva date din aceasta tabele. Utilizatorii care au drepturi
asupra acestori view-uri nu au acces direct la datele din tabela clienti_telecom şi nu pot vedea
toate datele din acesta. Pot vedea doar datele de pe anumite coloane ce le sunt de interes.
Un alt obiectiv atins în acest punct îl reprezintă alocarea permisiunilor, aşa cum au fost
prezentate mai sus, fiecărui utilizator în parte.
IV)Din cauza numărului restrâns de angajaţi, s-a hotărât ca utilizatorilor operator_date şi
operator_voce să li se acorde permisiune de a executa select asupra view-ului, folosindu-se
opţiunea WITH GRANT OPTION. Motivul pentru care se face acest lucru este faptul că în
momentul în care unul din operatori pleacă în concediu, poate să îi paseze responsabilităţile
sale celuilalt utilizator, fară ai preda contul său pe perioada absenţei lui. Când se va intoarce
din concediu nu îi va mai lasa acestuia permisiunile, şi îi va revoca dreptul asupra tabelelor
sale.
În acest punct se vor folosi comenzile GRANT cu opţiunea WITH GRANT OPTION şi
comanda REVOKE.
V)Din motive administrative se va concedia un utilizator. Pentru a realiza asta de va folosi
comanda DROP.

33
Rezolvare:
I)
Se crează tabela clienti_telecom cu următoarele câmpuri: id (id-ul de utilizator), nume,
prenume, nr_telf, factura, categoria, tip_ab. Id-ul şi factura sunt de tip number, numele,
prenumele sunt de tip varchar, iar categoria şi tip_ab pot lua valori restranse. Categoria poate
lua doar 2 valori, voce sau date, iar tip date poate una din valorile prezentate în figura de mai
jos. Dacă valorile introduse în coloanele categoria şi tip_ab nu fac parte din acele valori
impure, tabela nu este creată. Datele nu pot fi nule.
Tabela Clienti_telecom:

Tabela servcii de date conţine tipurile de servicii de date pe care operatorul telecom le poate
oferi. Acestea sunt prezentate în figura de mai jos.
Tabela servicii_date:

34
Tabela servicii de date conţine opţiunile pe care serviciul de date le poate lua. Acestea sunt de
tip number şi poate avea campuri în care este permisă valoarea null.
Tabela servicii_voce:

În figura de mai jos sunt descrise tabelele create.

35
II) Crearea utilizatorilor ce vor interacţiona cu baza de date şi alocarea acestora rolul de
connect.
Crearea conturilor de utilizator este prezentată în figura de mai jos. Aceştia au parola oracle,
însă şi-o pot schimba ca măsură de securitate.

Din motive se securitate utilizatorii îşi vor schimba parola de utilizator. Mai jos este prezentat
modul cum aceştia o fac. Să luam ca exemplu utilizatorul operator_voce. Acesta se
conectează la baza de date cu vechea parolă şi execută următoarea instrucţiune:

La fel vor face şi restul utilizatorilor.

36
III) Alocarea rolului connect acestor utilizatori nou creaţi.
În figura de mai jos se alocă rolul de connect tuturor utilizatorilor. S-a dorit alocarea acestui
rol pentru a avea un control cât mai strict asupra permisiunilor acestora.

Pentru a putea vedea efectele rolurilor şi permisiunilor asupra bazei de date, pe care le alocăm
utilizatorilor, este util să avem câteva date în tabele
Se vor introduce câteva date în tabele:
Tabela servicii_date:

37
Tabela clienti_telecom:

Datorită modului de afişare în linia de comandă, am ales să nu afişez toate coloanele,

deoarece acestea se suprapuneau. În consecinţă am vizualizat pe rând câteva coloane de
interes din tabelă.

38
39
Tabela servicii_voce:

40
Crearea view-urilor asupra cărora li se dau drepturi urilizatorilor operator_voce şi
operator_date. Doresc să creez view-uri pentru a nu aloca acces direct utilizatorilor la tabela
clinti_telecom. Acest lucru se poate face şi ajutorul synonym-urilor, însă doresc sa nu permit
accesul deloc la anumite coloane din respectiva tabela, şi pentru a realiza acest lucru voi
folosi view-uri.

41
Crearea vire-urilor info_date şi info_voce:

Datorită faptului că sunt prea multe coloane, aceste coloane nu încap toate în fereastră şi am
ales să afişez doar câteva informaţii din aceast view.

42
Vom aloca privilegiile utilizatorilor operator_voce şi operator_date. Aceşti utilizatori vor avea
privilegiul select asupra tabelei servicii_voce/servicii_date şi asupra view-ului
info_voce/info_date.

Vom testa privilegiile acestora. Ne vom conecta la baza de date cu utilizatorul operator_voce
şi vom încerca tabela clienti_telecom, servicii_voce, servicii_date, view-ul info_voce şi
info_date.
Ar trebui să avem acces la tabelele servicii_voce şi info_voce deoarece acestui utilizator i-a
fost alocat privilegiul select supra acestor două tabele.
Nu va trebui să avem acces la restul tabelelor: clienti_telecom, servicii_date, info_date. Nu i
s-a alocat niciun privilegiu utilizatorului oprator_voce asupra acesto trei tabele.
Acest lucru se poate vedea în figurile de mai jos.

43
44
Asemănătorva fi rezultatul pentru operator_date, cu excepţia ca acesta va avea acces la tabela
servicii_date şi nu servicii_voce, şi va avea acces la view-ul info_date şi nu la info_voce.
După cum se poate observa mai sus acestora le-a fost interzis accestul la toate datele
utilizatorului. Le este permis doar accesul la datele de interes. Aceasta este o măsură de
securitate.
Vom aloca privilegii utilizatorilor op_imp_voce şi op_imp_date. Aceşti utilizatori au
permisiunea de a executa select, delete, insert şi update a datelor din coloanele nr_telf,
categoria şi tip_ab.

Vom încerca permisiunile acestora. Ne vom conecta cu utilizatorul op_imp_date şi vom

încerca să adăugam un client, sa vizualizăm date, să ştergem un client din tabelă şi să
modificăm numele unui client şi tipu de abonament.

45
Rezultatele sunt cum ne aşteptam, acest operator nu are dreptul de a modifica alte coloane
decât cele care i-au fost permise. Acesta este o măsură de securitate.

46
Vom aloca privilegii utilizatorului op_factura.
Acesta va avea drept de SELECT asupra tabelei clienti_telecom şi dreptul de a executa
comanda UPDATE asupra coloanei factura din aceeaşi tabelă.

Vom încerca să ne conectăm la baza de date cu utilizatorul op_factura şi vom încerca să

vefectuăm comanda SELECT asupra tabelelor clienti_telecom, servicii_date, servicii_voce,
info_date, info_voce.
Apoi vom incerca să executăm comanda UPDATE asupra coloanei factura şi tip_ab din
tabela clienţi_telecom.

47
După cum vedeţi, acest utilizator nici nu ştie de existenţa acestor tabele la care nu are acces.

A funcţionat cum ne aşteptam. Acest utilizator poate modifica doar coloana factura a tabelei
clienti_telecom, dar nu poate modifica alte valori ale altor coloane. Aceasta este o măsură de
securitate.

48
IV) Acordarea permisiunilor folosind opţiunea with grant option

După ce s-a facut acest lucru să presupunem că operator_date pleacă în concediu. Înainte să
plece îi pasează sarcinile utilizatorului operator_voce.

După ce se termină perioada de concediu, acesta nu îi mai lasă drepturile alocate

utilizatorului operator_voce. Nu îi mai permite accesul la tabelele sale.

49
V)
Dacă se doreşte concedierea unui operator, se şterge contul de utilizator al acestuia. Să
presupunem că va pleca op_imp_voce.

După cum observaţi nici unul din utilizatorii pentru care s-au creat view-urile nu au acces
direct la datele originale. Aceasta este o măsură de securitate, deoarece unele detalii despre
aceste produse le sunt ascunse acestora. Ar fi putut fi vorba despre date importante la care nu
s-ar fi dorit accesul (în această aplicaţie datele pe care nu le pot accesa acesti utilizatori nu
sunt de o importanţă majoră).

50
APENDIX:
Răspunsuri la întrebări:
1. CONNECTION este un privilegiu ce se alocă asupra unei tabele ci nu un rol, iar în
sintaxa de mai sus nu este specificată nicio tabela, ci doar utilizatorului cui i se alocă.
O astfel de sintaxă este folosită atunci când se alocă un rol unui utilizator. Aceste
roluri sunt: CONNECT, RESOURCE şi DBA.
2. 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.
3. În acest caz, baza de date adaugă acest privilegiul la domeniul de privilegii al fiecărui
utilizator. Ca urmare toţi utilizatorii pot utiliza comanda SELECT.
4. Da.

5. Comanda este incorectă. Lipseşte parametrul user. Mai jos este prezentată sintaxa
corectă şi rezultatul introducerii comenzii din enunţul întrebării.

51
6. Da.

7. Ar avea privilegiu de SELECT acei utilizatori care necesită informaţii care se

regăsesc în tabela mea.

52