Introducere … … …. ..2 [618574]
1
Cuprins
Introducere …………………………………………………………… ……… .………………… ..2
I. Aspecte ale securității bazelor de d ate………………………. ……… .……………… .….3
I.1. Securitate la nivel de sistem ……………………………………… ………………… ….5
I.2. Securitate la nivel de date …………………………………… …………………… …… 6
I.3. Securitate la nivel de utilizator i………………….…….. …… ………………………… 6
I.4. Controlul accesului autorizat în sistemele centralizate ……………………… ……… …7
I.5. Administrarea privilegiilor ș i a role-urilor ………………………………… …… ……..8
I.6. Acordarea privilegiilor și a role-urilor ……………………………… ……………… 14
I.7. Revocarea privilegiilor și a role-urilor ……………………………… ……………… ..16
I.8. Administr area utilizatorilor, parolelor ș i a resurselor ……………… ……………… …17
I.9. Administrarea pa rolelor și a resurselor utilizâ nd profiluri …………………… …… …20
I.10. Metode de autentificare a utilizatorilor …………………………… …………… ……. 25
I.10.1. Autentificarea folosind Secure Sockets Layer ………………………… ………. 26
I.10.2. Autentificarea la baza de date folosind Kerberos ……………… …………….29
II. Descrierea modelului, formulare a problemei și a constrângerilor ……………… ………30
II.1. Noțiuni generale și formularea probleme i…………………… ……………… …… …30
II.2. Identificarea entităților ……………….…….. ……………………………… ……. .…31
II.3. Cardinalitățile relațiilor ce se stabilesc între entități ……………………………… .…31
II.4. Diagrama entitate -relați e………………………….. ………………………… ………33
II.5. Diagrama conceptuală ……………………………….. …………………… ……… …37
II.6. Schema relațională ……………………………………….. ….……… ………… …… 38
II.7. Crearea tabelelor ………………………………………….. ………… …………… …39
II.8. Tipuri de constrângeri definite …………………………………………… ……..……39
III.
Auditarea ………………………………………… …………… …… …………… ………42
III.1. Opțiuni de audit……………. …………………………………….. ….…… ……… ……42
III.2. Mecanisme pentru audi t………………………………………….. …… ………… …46
III.3. Informații despre audit ……………………………………………….. ………….. …48
IV. Elemente de securitate …………………………………….. …………… …………. …… 49
IV.1. Criptarea datelor ………………………………………….. ……… …………… …… 49
IV.2. SQL Injection ………………………………………….. ………… ……………… …51
V. Implementarea aplicației …………………………………….. ……… ……………. ……55
V.1. Descrie rea aplicației …………………………………………….. …… ……….. …… 55
V.2. Ecranele aplicației ………………………………………….. ……… …………. …… 55
Bibliografie ………………………………………….. ……… ………………………… …… 59
2
Introducere
Lucrarea de disertație își propune să prezinte securitatea unei baze de date care deserve ște
o instituție, numită Ghișeul Unic, ce are drept scop eliberarea documentelor de identitate și a
pașapoartelor simple turistice pentru cetățenii români.
Structura lucrării conține cinci capitole și o bibliografie .
În primul capitol se realizează o introducere în domen iul securității bazelor de date, fiind
descrise nivelurile de securitate și element ele fundamentale ale securității bazelor de date: accesul
autorizat, administrarea utilizatorilor, parolelor, privilegiilor și a role -urilor , autentificarea
utilizatorilor .
În capitolul al doile a este proiectată baza de date, fiind prezentate noțiunile generale și
modelul de date al aplicației. Sunt identificate e ntitățile modelului și sunt prezentate diagrama
conceptuală și diagrama entitate -relație. De asemenea, sunt descri se entitățile și atributele acestora,
precum și relațiile dintre enti tăți.
În capitolul al treilea este descrisă auditarea bazei de date, implementată din motive de
securitate, pentru a se găsi răspunsul la următoarele întrebări: a fost evitată vreo regulă de control
al accesului, fiind furnizată informație către utilizatori, a apărut problema inferenței, a fost
încălcată confidențialitatea, au avut loc accesări neautorizate?
În capitolul al patrulea sunt descri se elemente de securitate ale aplicației : una dintre cel e
mai periculoase vulnerabilități, cu efecte devastatoar e asupra diverselor activități – SQL Injection ,
modalități de protejare a datelor curente și arhivate – criptarea datelor și securitatea parolelor.
În capitolul al cincilea este prezentată implementarea aplicației de actualizare a bazei de
date aferente Ghișeului Unic. Sunt prezentate funcționalitățile aplicației, tehnologia în care este
realizată aceasta, bibliotecile folosite.
Concluziile la aceast ă lucrare conduc la faptul că securitatea bazei de date utilizată de
Ghișeul Unic este foarte importantă, având în vedere că această instituție procesează și stochează
date cu caracter personal, protejate de către legislația în vigoare.
Lucrarea se închei e prin partea de bibliografie.
I. Aspecte ale securit ății bazelor de date
3
Securit atea prezintă un interes deosebit, într-o continuă creștere , în proiectarea și
dezvoltarea bazelor de date. Î n mod uzual, nu se pun e în discuție existenț a securit ății, numai cât
de complexă va fi aceasta. Un sistem de gestiune a bazelor de date ( SGBD ) este caracterizat prin
existența mai mult or niveluri de securitate, pe l ângă cele oferite d e sistemul de operare sau de
rețea. De regulă, un SGBD deț ine conturi pentru utilizatori, care necesit ă parol e de conectare ce
trebuie autentificat e pentru ca datele să fie accesate .
De asemenea, rafinamentul securității este oferit de mecanisme le specifice fiecărui SGBD,
precum gru purile, role-urile, privilegiile ș i profilurile. Aceste niveluri stabilesc politica de
securitate, nu prevă d doar constr ângeri. Astfel, o instituție publică poate acorda accesul cetățenilor
la datele pe care le gestionează , dar accesul va fi autorizat printr -un nume și parolă. Pe de altă
parte, personal ul instituției poate avea acces la informații despre toate datele gestionate.
Sistemul de gestiune a bazei de date la care se referă prezenta lucrare este Oracle .
Securitatea datelor este asigurat ă în sistemul Oracle în primul r ând prin intermediul
utilizatorului de dat e. În sensul folosit de Oracle , un utilizator al bazei de date este , de fapt , un
cont și nu se identific ă cu persoana care accesează baza de date . În general, mai multe persoane
pot folosi acelaș i cont de acces. Orice obiect al bazei d e date este proprietatea unui utilizator,
schema unui utilizator cuprinz ând toate obiectele pe care acesta le de ține. Pentru a accesa un
obiect, un utilizator trebuie s ă fie proprietarul acelui obiect sau să aibă privilegiile necesare pentru
această operaț ie. Privilegiile pot fi acordate direct unui utilizator sau pot fi grupate î n role-uri, care
la rândul lor pot fi acordate utilizatorului.
Sistemul Oracle conține propriul lui sistem de securitate care previne accesul neautorizat
la baza de date. Sistemul de securitate al bazei de date Oracle este realizat prin intremediul
utilizatorilor bazei de date. Serverul bazei de date solicit ă numele utilizatorului și parola pentru
fiecare accesare a bazei de date .
O schem ă este o colec ție de obiecte disponibile unui utilizator. Obiectele schemei sunt
structuri logice ce se refer ă efectiv la datele unei baze de dat e precum tabele, vizualizări , secvenț e,
indec și, sinonime etc.
Fiecărui utilizator al bazei de date îi sunt acordate anumite drepturi cunoscute sub numele
de privilegii. Un privilegiu este permisiunea de a executa o ac țiune sau de a accesa un obiect
aparținând unui alt utilizator. Î n Oracle , un utilizator nu poate executa niciun fel de acț iune f ără a
avea privilegiul s ă o fac ă. În acest sens unui utilizator îi pot fi acordate sau revocate privilegii.
Accesul unui utilizator la baza de date este administrat printr -un numă r de drepturi numite
privilegii sistem sau privilegii la nivelul bazei de date, care permit utilizatorului s ă efectueze
opera ții precum conectarea la baza de date și crearea de obiecte. Odat ă ce utilizatorul a creat
4
obiecte ale bazei de date, el este apoi responsabil pentru acorda rea de drepturi altor utilizatori
pentru obiectele care în sunt proprietatea lui. Aceste drepturi sunt numite privilegii obiect.
Role-urile sunt utilizate pentru a simplifica administrarea privilegiilor. Astfel, î n loc de a
acorda un anumit privilegiu direct un ui utilizator, privilegiile sunt acordate unui role, iar un role
este acordat la râ ndul lui unui utilizator. Altfel spus , role-urile reprezint ă un grup de privilegii.
Securi tatea datelor este o funcție importantă a unui sistem de baze de date, care protejeaz ă
datele împotriva accesului neautorizat, componente le acesteia fiind protejarea datelor și controlul
accesului autorizat.
Protejarea datelor este necesar ă pentru a nu pe rmite utilizatorilor neautorizaț i să înțeleag ă
conținutul fizic al datelor. Această funcție este oferită , de obicei, de sistemele de operare,
centralizate sau distribuit e. Principala abordare a protejă rii datelor es te criptare a lor, lucru util în
cazul în care informația este stocată pe disc, cât și atunci când informația este transmisă î ntr-o
rețea. Datele criptate pot fi decriptate numai de către utilizatorii autorizați, care „știu” codul.
Controlul accesului autorizat trebuie să asigure că numai utilizatorii autorizați efectuează
operaț ii care le sunt pe rmise asupra bazei de date. Mai m ulți utilizatori diferiț i pot avea acces la
un volum mare de date sub controlul unui singur sistem centralizat sau distribuit. SGBD -ul,
centra lizat sau distr ibuit, trebuie să fie capabil să restricționeze acc esul unei părț i din utilizatori la
o parte din date. Controlul accesului autorizat a fost oferit mult timp de c ătre sistemul de operare
și ulterior de către sisteme de operare distribuite, ca serviciu al sistemului de fișiere. Î n acest
context, este oferit un control centralizat.
Controlul accesului autorizat î n sistemele de baze de date difer ă în anum ite privințe de cel
din sistemele tradiționale de fișiere. Autorizările trebuie să ofere unor utilizatori diferiți drepturi
diferite pe aceleaș i obiecte ale bazei de date. Această necesitate implică specifi carea obiectelor
într-un mod mai precis decât după nume ș i diferențierea î ntre grupurile de utilizatori. De asemenea,
controlul descentralizat al acce sului autorizat este important î ntr-un context distribuit.
Securi tatea unei baze de date presupune monitorizarea acț iunilor realizate de utilizatori
asupra a cesteia sau a supra obiectelor sale. Î n acest sens, sistemul foloseș te scheme de obiecte pe
domenii de securitate.
Unui utilizator îi este asociat un nume definit î n baza de date , cu ajutorul căruia poate
accesa obiectele acesteia. O biectele bazei de date sunt conținute î n scheme. Definirea utilizatorilor
și a schemelor de obiecte ajut ă administratorii s ă asigure securitatea bazei de date.
În momentul creării unui utilizator, administratorul bazei de date define ște un domeniu de
securitate pentru acesta . În cadrul domeniului de securitate sunt specificate metodele de
autentificare, spațiile tabel implicite ș i cele tem porare, profilul pentru restricț ionarea folosirii
resurselor bazei, privilegiile ș i role-urile acordate utilizatorului respectiv.
5
I.1. Securitate la nivel de sistem
Securitatea la nivel de sistem [1] presupune administrarea adecvată a utilizatorilor,
alegerea metodel or de autentificare a acestora și stabilirea securității sistemului de operare gazdă.
Fiecare bază de date are unul sau mai mulț i administratori care sunt responsabili de asigu rarea
politicilor de securitate. În situația în care baza de date este de dimens iuni reduse, ad ministratorul
bazei de date poate avea și responsabilităț i de securitate.
Utilizatorii sunt cei care accesează informațiile din baza de date, astfel că este deosebit de
important modul de administrare al acestora. În general, administratoru l de securitate este singurul
utilizator al bazei de date care deține dreptul de administrare a celorlalț i utilizator i, ce include
creare a, modificare a, eliminare a acestora .
Sistemul furnizează mai multe metode de autentificare a utilizatorilor bazei de da te,
folosind p arole, sistemul de operare gazdă , servicii de reț ea sau protocolul SSL (Secure Sockets
Layer ), autentificare ș i autorizare de tip proxy .
La nivelul sistemului de opera re pe care rezidă server -ul și aplicaț iile de baze de date
trebuie ca:
Administratorii bazei de date să aibă privilegii de creare, respectiv de ștergere a fiș ierelor;
Utilizatorii obi șnuiți ai bazei de date să nu dețină privilegii de creare sau de ștergere a
fișierelor utile funcționă rii bazei de date;
Admi nistratorii de securitate să dețină privilegii de modificare a domeniului de securitat e
pentru conturile disponibile în sistemul de operare, în situația în care identificarea role-
urilor pentru utilizatorii bazei de date Oracle se realizează prin sistemul de operare.
I.2. Securitate la nivel de date
Securitatea la nivel de date [1] include mecanisme de control al accesului la date ș i al
gradului de utilizare a obiectelor bazei. Se stabilesc utilizatorii care au acces la un anumit ob iect
și tipurile de acț iuni permise asu pra sa. Î n acest sens, se acordă utilizatorilor bazei de dat e anumite
privilegii sistem și obiect, care pot fi grupate î n role-uri. De asemenea, pentru fiecare obiect al
unei scheme sunt definite acț iunile care vor fi auditate.
O altă modalitate de stabilire a securităț ii la aces t nivel o reprezint ă folosirea vizualizărilor.
Acestea pot restricț iona accesul la datele unui tabel, prin excluderea unor coloane sau linii.
Sistemul permite implementarea politicilor de securitat e prin folosirea unor funcț ii și asocierea
6
acestora la tabele sau vizualizări, ca de exemplu, fine-grained acce ss control . O astfel de funcț ie
genereaz ă automat o condi ție WHERE într-o instrucț iune SQL, restricț ionând, astfel, accesul la
anumite linii de date.
I.3. Securitate la nivel de utilizator i
Stabilire a securităț ii la nivel de utilizatori [1] se realizează prin intermediul parolelor și
prin acordarea privilegiilor.
În situația în care autentificarea utilizatorilor este administrată de baza de date, a tunci
administratorii tr ebuie să dezvolte politici de securitate pentru parole , cum ar fi să impun ă
utilizatorilor bazei de date să -și schimbe parolele la anumite interval e de timp, lungimea parolelor
să aibe o dimensiune suficient de mare, iar în componenț a acesto ra să intre atâ t litere, c ât și cifr e.
Administrarea privilegiilor pentru diferite tipuri de utiliz atori are o importanță deosebită .
Astfel, pentru baze de date cu mulț i utilizatori, administrarea p rivilegiilor se realizează mai eficient
folos ind role-uri. Î n schimb, at unci c ând numărul de utilizatori este scăzut, se recomandă să se
acorde privilegii expli cite pentru fiecare utilizator și să se evite folosirea role-urilor.
Administrato rii pentru securitate trebuie să dezvolte politici de securitate inclusiv pentru
admini stratorii bazei de date , în funcție de dimensiunea acesteia . Astfel, în cazul unor baze de date
foarte mari, care necesită mai mulț i administratori, administratorul de securitate trebuie sa decidă
care sunt grupurile de privilegii de administrare și să le includ ă în role-uri de administrare , iar
pentru baze de date mici este suficientă crearea unui singur role specific ș i acordarea acestuia
tuturor administratorilor bazei de date .
De asemenea, administrato rii de securitate trebuie să creeze politici de securitate pentru
dezvoltatorii de aplicații care se conectează la baza de date. În scopul creării obiectelor, se pot
acorda privilegii direct dezvoltatorilor sau numai administratorilor bazei de date, care să
definească obiectele la ce rerea acestora.
Dezvoltatorii de aplicaț ii sunt singurii utilizator i ai bazei de date care necesită grupuri
speciale de privilegii. Spre deoseb ire de utilizatorii finali, aceș tia au nevoie de privi legii sistem
specifice activităț ii lor. Privilegiul sistem CREATE este acordat dezvoltatorilor pentru ca aceș tia
să poată crea obiectele necesare în aplicaț ii. În situația în care dezvoltatorii de aplicaț ii au privilegii
pentru crearea obiectelor, administrato rul de securitate trebuie să contro leze limitele de fo losire a
spațiului bazei de date pent ru fiecare dezvoltator î n parte.
I.4. Controlul accesului autorizat î n sistemele centralizate
În controlul accesului autorizat (1) sunt implicați trei actori principali:
7
utilizatorii, care declanșează execuția aplicațiilor;
operațiile, care sunt incluse în aplicații;
obiectele bazei de date asupra cărora se efectuează operațiile.
Cont rolul accesului autorizat constă în validarea triplet ului sus -menționat. O autorizare
poate fi vă zută ca un triplet , compus din utilizator, tipul opera ției, definiț ia obiectului triplet , care
specifică dacă acel utilizator are dreptul de a efe ctua o operație de acel tip asu pra obiect ului. Pentru
a controla autoriză rile corect, un SGBD necesită definire a utilizatorilor, a obiectelor ș i a
drepturilor.
Introducerea unui utilizator în sistem se face , de obicei , printr -o pereche formată din nume
utilizator și parol ă. Numele utilizatorului identific ă în mod unic utilizatorul, în timp ce parol a,
cunoscută numai de acel utilizator, îl autentific ă pe acesta . Ambele sunt cerute în momentul
conect ării la sistem.
Obiectele car e trebuie protejate sunt submulțimi ale bazei de date. Î ntr-un sistem relaț ional
obiectele se pot defini atât după tipul lor (vederi , relatii, tupluri, atribute) , cât și după conț inutul
lor, folosind predicate de selecț ie. De asemenea, mecanismul vizualiză rilor permite protejarea
obiectelor prin simpla ascundere a unor submulțimi ale relațiilor .
Un drept exprimă o rel ație între un utilizator ș i un obiec t pentru un anumit set de operaț ii,
iar controlul accesului autorizat poate fi car acterizat prin cine anume acordă drepturile.
Un privilegiu este dreptul de a executa anumite comenzi SQL și poate consta în dreptul de
conectare la baza de date, creare de tabele, selectare a liniilor din tabelul altui utilizator, execuț ie
a procedurilor stocate create de alt utiliza tor etc. Privilegiile pot fi de tip sistem sau obiect și trebuie
să fie acordate utilizatorilor numai dacă su nt absolut necesare î n activitatea acestora. Acordarea
excesiv ă de privilegii poate compromite securit atea bazei de date.
Un role este un grup de privilegii î nrudite care pot fi acordate sau revocate simultan
utilizatorilor sau altor role-uri. Folosirea role-urilor permite:
simplificarea administrării privilegiilor – prin crearea unui role ce conține toate
privilegiile necesare , acord ându -se, apoi, acest role fiecărui membru al grupului ;
administrarea dinamică a privilegiilor – modificarea privilegiilor u nui grup de
utilizatori se va face la nivelul role-ului care le conț ine și se propag ă automat pentru
fiecare utilizator care are asociat role-ul respectiv;
activarea selectivă a privilegilor – role-urile pot fi activate sa u dezactivate selectiv,
astfel încât să permită un control ridicat al privilegiilor acord ate utilizatorilor.
I.5. Administrarea privilegiilor ș i a role-urilor
8
Acțiunile pe care un utilizator le poate efectua asupra bazei de date sunt ad ministrate prin
privilegiile sistem [1] acordate acestuia. Acestea variază de la permi siunea de a se conecta la o
bază de date ( CREATE SESSION ), până la dreptul de a cr ea un tabel ( CREATE ANY TABLE ) sau
index ( CREATE ANY INDEX ) sau de a șterge un tabel ( DROP ANY TABLE ) sau index ( DROP
ANY INDEX ) din schema oric ărui utilizator. Următorul tabel prezintă o listă a privile giilor sistem :
Privilegiul sistem Comanda SQL Operaț iuni permise de acordare a privilegiului
Analiza ANALYZE ANY Analizează un tabel, cluster sau index di n orice schemă
Auditare AUDIT ANY Audit ează un obiect din orice schemă
AUDIT SYSTEM Activează sau dezactivează folosirea comenzilor de
auditare
Baza de date ALTER DATABASE Modifică baza de date; adaugă fisiere î n sistemul de
operare prin int ermediul Oracle
Biblioteca CREATE LIBRARY Creeaz ă biblioteci externe în propria schemă
CREATE ANY LIBRARY Creeaza bi blioteci externe în orice schemă
DROP LIBRARY Șterge bibl ioteci externe din propria schemă
DROP ANY LIBRARY Șterge bi blioteci externe din orice schemă
Cluster CREATE CLUSTER Creea ză un cluster în propria schemă
CREATE ANY CLUSTER Creea ză un cluster în orice schemă
ALTER ANY CLUSTER Modifică orice cluster din orice schemă
DROP ANY CLUSTER Șterge orice cluster din orice schemă
Index CREATE ANY INDEX Creează un index pe orice tabel în orice schemă
ALTER ANY INDEX Modif ică orice index din orice schemă
DROP ANY INDEX Șterge orice index di n orice schemă
Legă turile bazei de
date CREATE DATABASE LINK Creează o legătură privată a bazei de date în propria
schemă
Legă turile publice
ale bazei de date CREATE PUBLIC DATABASE
LINK Creează legă turi publice a le bazei de date
DROP PUBLIC DATABASE
LINK Șterge legă turi publice a le bazei de date
Privilegiu GRANT ANY PRIVILEGE Acordă orice privilegiu sistem
Procedura CREATE PROCEDURE Creează proceduri, funcții și pachete în propria schemă
CREATE ANY PROCEDURE Creează proceduri, fun cții și pachete în orice schemă
ALTER ANY PROCEDURE Compilează orice procedură, funcție sau pachet din orice
schemă
DROP ANY PROCEDURE Șterge orice procedură, funcție sau pachet di n orice
schemă
EXECUTE ANY PROCEDURE Execută orice procedură sau funcț ie sau face referire la
orice variabilă publică a unui pachet din orice schemă
Profil CREATE PROFILE Creează un profil
ALTER PROFILE Modifică orice profil din baza de date
ALTER RESOURCE COST Setează costur ile pentru resursele utilizate î n toate
sesiunile utilizatorilor
Rol CREATE ROLE Creează un rol
ALTER ANY ROLE Modi fică orice rol din baza de date
9
DROP ANY ROLE Șterge orice rol din baza de date
GRANT ANY ROLE Acordă orice rol din baza de date
Secvenț a CREATE SEQUENCE Creea ză o secvență în propria schemă
CREATE ANY SEQUENCE Creează o secvență în orice schemă
ALTER ANY SEQUENCE Modifică orice secvență din orice schemă
DROP ANY SEQUENCE Șterge orice secvență din orice schemă
SELECT ANY SEQUENCE Referă orice secvență din orice schemă
Segment de revenire CREATE ROLLBACK
SEGMENT Creează seg mente de revenire
ALTER ROLLBACK
SEGMENT Modifică segmente de revenire
DROP ROLLBACK SEGMENT Șterge segmente de revenire
Sesiune CREATE SESSION Creează conexiunea la baza de date
ALTER SESSION Permite fol osirea comenzilor ALTER SESSION
RESTRICTED SESSION Creează conexiunea la baza de date atunci când aceasta a
fost pornită utilizâ nd STARTUP RESTRICT
Sinonim CREATE SYNONYM Creează un sinonim în propria schemă
CREATE ANY SYNONYM Creeaz ă un sinonim în orice schemă
DROP ANY SYNONYM Șterge orice sinonim din orice schemă
Sinonim public CREATE PUBLIC SYNONYM Creează un sinonim public
DROP PUBLIC SYNONYM Șterge un sinonim public
Sistem ALTER SYSTEM Permite fo losirea comenzilor ALTER SYSTEM
Spaț iu tabel CREATE TABLESPACE Creează un spațiu tabel; adaugă fișiere î n sistemul de
operare prin intermediul Oracle
ALTER TABLESPACE Modifică un spațiu tabel; adaugă fișiere î n sistemul de
operare prin intermediul Oracle
MANAGE TABLESPACE Activează și dezactivează orice spațiu tabel; începe și
termină arhivarea spațiilor tabel
DROP TABLESPACE Șterge un spaț iu tabel
UNLIMITED TABLESPACE Utilizează o cantitate nelimitată a oricărui spaț iu tabel
indiferent de cotele specifice atribuite
Tabel CREATE TABLE Creează un tabel î n propria schema; premite creearea de
indecși pe tabelele din propria schemă
CREATE ANY TABLE Creează un tabel în orice schemă
ALTER ANY TABLE Modifică orice tabel în orice s chemă și compilează orice
vizualizare în orice sch emă
BACKUP ANY TABLE Exportă obiecte din orice schemă
DROP ANY TABLE Șterge sau trunchează orice tabel di n orice schemă
LOCK ANY TABLE Blochează orice t abel sau vizualizare din orice schemă
COMMENT ANY TABLE Comentează orice tabel, vizualizare , coloana din orice
schemă
SELECT ANY TABLE Inter oghează orice tabel, vizualizare , instantaneu din orice
schemă
INSERT ANY TABLE Inserează rânduri î n orice tabel sau vizualizare din orice
schemă
UPDATE ANY TABLE Actualizează rânduri din orice tabel sau vizualizare din
orice schemă
DELETE ANY TABLE Șterge râ nduri din orice tabel sau vizualizare din orice
schemă
10
Tranzacț ii FORCE TRANSACTION Forțează comiterea sau derularea înapoi a unei tranzacții
distribuite nesigure în baza de date locală
FORCE ANY TRANSACTION Forțează comi terea sau derularea înapoi a oricărei
tranzacții distribuite nesigure în baza de date locală
Trigger CREATE TRIGGER Creeaz ă un declanșator al bazei de date în propria schemă
CREATE ANY TRIGGER Creează un declanșator al bazei de date în orice schemă ce
este asociată cu orice tabel din orice schemă
ALTER ANY TRIGGER Activează, dezactivează sau compilează orice declanșator
al bazei de date din orice schemă
DROP ANY TRIGGER Șterge ori ce declanșator din orice schemă
Utilizator CREATE ANY USER Creează utilizatori, atribuie cote în orice spațiu tabel,
setează spații tabel temporare sau implicite și atribuie un
profil ca parte a comenzii CREATE USER .
BECOME ANY USER Devine un alt utilizator
ALTER USER Modifică caracteristicile altor utilizatori: modific ă parola
orică rui utilizator, atribuie cote spa țiilor tabel, setează
spații tabele temporare s au implicite , atribuie profiluri și
roluri într -o comandă ALTER USER
DROP USER Șterge un alt utilizator
Vizualizare CREATE VIEW Creează o vizualizare în propria schemă
CREATE ANY VIEW Creează o vizualizare în orice schemă
DROP ANY VIEW Șterge orice vizualizare din orice schemă
Tabelul I .1. Privilegiile sistem din Oracle
Deoarece privilegiile de sistem sunt puternice, se recomandă să nu se acorde utilizatorilor
obișnuiti privilegii de tip ANY asupra tabelelor dicț ionarului datelor , cum ar fi UPDATE ANY
TABLE . Pentru a securiza accesul la dicț ionar ul datelor, parametrul de iniț ializare
O7_DICTIONARY_ACCESIBILITY trebuie să aibă valoarea FALSE. În acest caz, accesul la
obiectele schemei SYS este per mis doar utilizatorului care deț ine schema SYS sau care se
conectează ca administrator. Privilegiile si stem acordate utilizatorilor vor permite accesul la
obiectele din alte scheme, dar nu la cele din schema SYS.
Pentru administrarea bazei de date exist ă două privilegii sistem speciale, SYSOPER și
SYSDBA . Aceste priv ilegii permit accesul la instanț a bazei de date, chi ar dacă aceasta nu este
deschisă. Atunci când un utilizator cu privilegiul sistem SYSOPER sau SYSDBA se conectează la
baza de date , îi este asociată o schemă obiectuală implicită , nu cea corespunză toare username -ului
său. Pent ru privilegiul de sistem SYSDBA această schemă este SYS, iar pentru privilegiul sistem
SYSOPER este PUBLI C. Privilegiul SYSOPER perm ite folosirea comenzilor de bază, dar fără
posibilitatea de a vizualiza datele utilizatorilor ( STARTUP, SHUTDOWN, ALTER DATABASE,
CREATE SPFILE etc.). Privilegiul SYSDBA permite utilizatorului să execute orice tip de operație
asupra bazei de date ș i a obiectelor sale.
Privilegiile obiect sunt d repturi de a executa anumite acț iuni asupra unui obiect specific al
schem ei: tabel, vizualizare, secvență, procedură, funcț ie, pachet etc. De exemplu, ALTER TABLE,
DELETE TABLE, SELECT TABLE și UPDATE TABLE sunt privilegii obiect. Un ele obiecte, ca
11
de exemplu grupările, indecșii, declanș atorii, leg ăturile de baze de date nu au asociate privilegii
obiec t. Folosirea lor este controlată de privilegiile sistem. De exemplu, pentru a modifica o
grupare , utilizatorul trebuie să fie proprietarul grupării sau să dețină privilegiul sistem ALTER ANY
CLUSTER.
În ceea ce priveș te respectarea privilegiilor, obiectul schemei este echivalent cu sinonimul
său. În situaț ia în care se acordă un privilegiu pentru un obiect, acesta este valabil și pentru
sinonimul său și reciproc , iar d acă sinonimul este eliminat, atunci toate privilegiile obiectului au
în continuare efect, chiar dacă privilegiile au fost a cordate doar pentru sinonimul să u.
Un role este un grup de privilegii î nrudite care pot fi acordate sau revocate simultan
utilizatorilor sau altor role-uri. Pot fi create aplicații care să interogheze dicționarul datelor și să
activeze sau să dezactiveze automat unele role-uri, în funcție de utilizatorul care î ncearc ă să
execute aplicația respectivă .
Role-urile au următoarele caracteristici:
pot fi acordate sau revocate utilizatorilor folosin d aceleași comenzi ca și î n cazul
privilegiilor sistem;
pot cuprinde atât privi legii sistem, cât ș i privilegii obiect;
pot fi protejate prin folosirea parolelor;
trebuie să aibă un nume unic, difer it de conturile utilizatorilor ș i de celelalte role-uri
din baza de date;
nu sunt conținute în schema nici unui utilizator;
caracteristicil e lor pot fi regăsite în dicț ionarul datelor.
La crearea bazei de date Oracle se creează automat role-uri predefinite. Acestora li se pot
acorda sau revoca alte privilegii sau role-uri. Un exemplu de role predefinit este CONNECT care
include privilegiile sistem CREATE SESSION , ALTER SESSION , CREATE DATABASE LINK ,
CREATE SEQUENCE , CREATE TABLE , CREATE SYNONIM , CREATE VIEW , CREATE
CLUSTER .
Sistemul Oracle oferă role-urile DELETE_CATALOG_ROLE ,
EXECUTE_CATALOG_ROLE și SELECT_CATALOG_ ROLE, pentru a pe rmite accesul la
vizualiz ările dicț ionarului datelor, tuturor utilizatorilor care nu deț in un role DBA .
Crearea unui role necesistă privilegiul sistem CREATE ROLE și se realizeaz ă prin
comanda cu același nume. După creare, role-ul nu are privilegii sau role-uri asociate, acestea
putând fi acordate ulterior.
Comanda prin care se creează un role are urmatoarea sintaxă :
CREATE ROLE nume_role
12
{NOT IDENTIFIED l IDENTIFIED tip_autorizare };
În situția în care este folosită clauza NOT IDENTIFIED , atunci nu se cere mai nici o
autorizare pentru role-ul respectiv. Această opțiune este implicită.
Clauza tip_autorizare specifică urmă toare le categorii de autorizări:
prin baza de date ( IDENTIFIED BY parola );
prin intermediul unei aplicații care utilizează pachete specifice (IDENTIFIED USING
[schema. ]nume_pachet );
externă, realizâ ndu-se prin sistemul de operare, reț ea sau alte surse externe
(IDENTIFIED EXTERNALLY );
globală (IDENTIFIED GLOBALLY ).
Dacă autorizarea role-ului se face prin sist emul de operare, atunci informaț iile pentru
fiecare utilizator trebu ie configurate la acest nivel. În cazul autorizării prin rețea, dacă utilizatorii
se co nectează la baza de date prin Oracle Net, atunci role-urile nu pot fi autorizate de către sistemul
de operare.
Autori zarea globală presupune existenț a role-urilor globale. Un role global se definește î n
baza de date, dar nu poate fi acordat de la acest nivel altui utilizator sau role. Atunci când un
utilizator global încearcă să se conecteze la baza de date , este interogat direct orul de servicii pentru
a se obț ine role-urile globale asociate.
Schimbarea modului de autorizare a unui role se face folosing comanda ALTER ROLE.
Pentru aceasta este necesar privilegiul sistem ALTER ANY ROLE sau un role cu opț iuni d e
administrare.
Unui utilizator î i pot fi acordate mai multe role-uri. La fiecare conectare a utilizatorului
este activat î n mod automat un role implicit, chiar dac ă acesta nu are asociat explicit nici un role.
Un role implicit este specificat folosind cla uza DEFAULT ROLE din comanda ALTER USER:
ALTER USER nume_utilizator DEFAULT ROLE
{role[,role] l ALL [EXCEPT role[, role … ] ] | NONE }.
Folosind opț iunea ALL, toate role-urile acordate u tilizatorului devin implicite. Î n acest caz,
la conectare utilizatorul va beneficia doar de privil egiile care i -au fost acordate în mod explicit.
Clauza DEFAUL T ROLE nu poate fi folosită pentru role-uri care nu au fost acordate
utilizatorului, acordate prin intermediul altor role-uri sau administrate prin servicii externe.
Atunci câ nd un role este activ, utilizatorul poate folosi privilegiile acordate prin
intermediul acestuia. Dacă role-ul este inactiv, atunci utilizatorul poate folosi doar privil egiile care
i-au fost acordate î n mod explicit sau care fac parte din alte role-uri deț inute de acesta. Activarea
sau dezactivarea role-urilor persistă doar pentru sesiunea curentă. În sesiunile urmă toare,
utilizatorul va avea activate din nou role-urile implicite.
13
Pentru activarea sau dezactivarea role-urilor este utilizată comanda SET ROLE . Aceasta
are urmatoarea sintaxa:
SET ROLE {role [IDENTFIED BY parola ]
[,role [IDENTIFIED BY parola ]…]
| ALL [ EXCEPT role [, role … ]] | NONE };
Clauza IDENTIFIED BY precizeaz ă parola necesară pentru autorizarea role-ului. Folosind
opțiunea ALL, sunt activate toate role-urile acordate utilizatorului curent, cu excepția celor care
apar î n clauza EXCEPT. Opțiunea NONE asigură dezactivarea tuturor role-urilor care erau
acordate utilizatorului respectiv.
I.6. Acordarea privilegiilor ș i a role-urilor
Privilegiile ș i role-urile [1] pot fi acordate utilizatorilor sau altor role-uri folosind comanda
GRANT sau utilitarul Oracle Enterprise Manager.
Nu pot acorda privilegii sistem sau role-uri dec ât utilizatorii că rora le -au fost acor date
aceste privi legii cu optiunea WITH ADMIN OPTION a comenzii GRANT sau utilizatorii care deț in
privilegiul sistem GRANT ANY ROLE.
Utilizatorii nu pot acorda role-uri autoriza te global. Acordarea, respectiv revocarea unui
astfel de role este controlată în î ntregime prin directorul de servicii.
Comanda SQL prin care se acordă privilegii sistem sau role-uri unui utilizator are
următoarea sintaxă :
GRANT {privilegiu_sistem | role} [,{privilegiu_sistem | role} …]
TO {nume_utilizator | role | PUBLIC }
[,{nume_utilizator | role | PUBLIC } … ]
[WITH ADMIN OPTION ];
Opțiunea PUBLIC permite acordarea privilegiilor sistem tuturor utilizatorilor bazei de
date. Clauza WITH ADMIN OPTION permite utilizatorilor să acord e mai departe privilegiile
sistem și role-urile respective altor ut ilizatori sau role-uri.
Privileg iile asupra obiect elor nu pot fi acordate împreună cu privilegii sistem sau cu role-
uri, în cadrul aceleiaș i comenzi GRANT . Acordarea de privilegii obiect utilizatorilo r sau role-urilor
poate fi fă cută de proprietarul obiectului sau de un utilizato r căruia i s-a acordat priv ilegiul asupra
obiect ului respectiv, cu opț iunea WITH GRANT OPTION . Comanda folosită pentru acordar ea unui
privilegiu obiect este:
GRANT {privilegi u_obiect [(lista_coloane )]
[, privilegiu_obiect [(lista_coloane )…]
14
| ALL [PRIVILEGES ] }
ON [nume_schema. ] obiect
TO {nume_utilizator | role | PUBLIC }
[,{nume_utilizator | role | PUBLIC } …]
[WITH GRANT OPTION ];
Prin opț iunea lista_coloane se precizează coloanele u nui tabel sau ale unei vizualizări
pentru care se acordă privileg iul. Această opțiune poate fi folosită atunci câ nd sunt acordate
privilegii obiect de tip INSERT, REFERENCES sau UPDATE. Opțiunea ALL permite acordarea
tuturor privilegilor obiect pent ru care utilizatorul ce inițiază comanda GRANT are opț iunea WITH
GRANT OPTION.
Clauza ON [nume_schema. ]obiect precizează obiectul relativ la ca re este acordat
privilegiul. Opț iunea PUBLIC permite acordarea privilegiilor obiect tuturor utilizatorilor bazei de
date.
Clauza WITH GRANT OPTION permite utilizatorilor să acorde privilegii obiect altor
utilizatori sau role-uri. Această clauză nu poate fi utilizată atunci câ nd privilegiul obiect este
acordat unui role.
În ceea ce priveș te privilegiile referitoare la comenzile LMD, acestea sunt acordate pentru
operaț iile DELETE, INSERT, SELECT și UPDATE asupra unui tabel sau unei vizualiză ri, doar
utilizatorilor sau role-urilor care trebuie să interogheze sau să prelucreze datele respective.
Privilegiile INSERT și UPDATE se pot restricț iona pentru anumite coloane ale tabelului.
În cazul unui privilegiu INSERT restricț ionat pentru anumite coloane, inserarea unei linii permite
inserarea de valori doar pentru coloanel e accesibile. Coloanele restricț ionate primesc valor i
implicite sau null. În cazul unui privilegiu UPDATE restricț ionat, vor putea fi modificate doar
coloanele pentru care utilizatorul are acest drept.
Privilegiile ALTER, INDEX și REFERENCES permit executarea de operaț ii LDD asupra
unui tabel. Un utilizato r care încearcă să execute o comandă LDD trebuie să aibă anumite privilegii
sistem sau obiect. De e xemplu, pentru a crea un declanș ator asupra unui ta bel, utilizatorul trebuie
să dețină privilegiul asupra obiect elor ALTER TABLE și privilegiul sistem CREATE TRIGG ER.
Privilegiul REFERENCES poate fi acordat unei anumite coloane a unui tabel. Astfel, tabelul
respectiv este folosit ca tabel „părinte” pentru orice cheie extern ă care trebuie creată .
În unele cazuri este necesară suprimarea unui role din baza de da te. Deoarece crear ea
obiectelor nu este dependentă de privilegiile primite prin role-uri, tabelele și celelalte obiecte nu
vor fi șterse în momentul suprimă rii role-ului. Comanda SQL de ștergere a unui role este DROP
ROLE. Pentru folosirea acestei c omenzi este necesar privilegiul sistem DROP ANY ROLE sau un
role cu opț iuni de administrare.
15
I.7. Revocare privilegiilor ș i a role-urilor
Pentru a revoca privilegii sau role-uri [1] se poate folosi comanda REVOKE sau utilitarul
Oracle Enterprise Manager . Un utilizator care are opț iunile de acordare și de administrare a unui
privilegiu sau role, le poate revoca pe acestea orică rui role sau utilizator al bazei de date. Un
utilizator care deț ine privilegiul GRANT ANY ROLE poate revoca orice role.
Sintaxa gener ală a comenzii de revocare a unui privilegiu sistem sau role este urmă toarea:
REVOKE <privilegiu_sistem | role> [<privilegiu_sistem | role> …]
FROM <nume_utilizator | role | PUBLIC >;
Opțiunea PUBLIC permite revocarea privilegiilor sistem sau a role-urilor tuturor
utilizatorilor bazei de date.
Sintaxa generală a comenzii de revocare a unui privilegiu obiect este:
REVOKE <privilegiu_obiect [, privilegiu_obiect …]
| ALL [PRIVILEGES] >
ON [nume_schema.]obiect
FROM <nume_utilizator | role | PUBLIC>
[,<nume_utilizator | role | PUBLIC>…]
[CASCADE CONSTRAINTS] ;
Opțiunea ALL permite revocarea tuturor privilegiilor obiect acordate utilizatorului. Prin
clauza ON se identifică obiectul la care se referă privilegiul ce trebuie revocat. Clauza FRO M
identifică utilizatorii sau role-urile pentru care este revocat privilegiul obiect. Op țiunea PUBLIC
determină revocarea unor privilegii obiect tuturor utilizatorilor bazei de date.
Clauza CASCADE CONSTRAINTS permite suprimarea c onstrângerilor de integrit ate
referențială definite folosindu -se privilegiile REFERENCES sau ALL.
Definiț iile obiectelor care depind de privilegiile LMD de sistem sau asupra obiect elor pot
fi afectate dacă privilegiile respective sunt revocate. De exemplu, dacă privilegiul sistem SELECT
ANY TABLE a fost acordat unui utilizator care apoi a creat proceduri sau vizualizări ce folosesc un
tabel din altă schemă , atunci revoca rea acestui privilegiu determină invali darea procedurilor sau a
vizualiză rilor respective. De asemenea, dacă o procedură include comenzi SQL prin care su nt
selectate datele unui tabel ș i este revocat priv ilegiul obiect SELECT asupra tabelului respectiv,
atunci procedura nu se mai execută cu succes.
16
Definiț iile obiectelor pentru care sunt necesare privilegiile obiect ALTER și INDEX nu sunt
afectate în situația în care aceste privilegii sunt revocate. De exemplu, dac ă privilegiul INDEX este
revocat unui utilizator care a creat un index asupra unui tabel ce aparține altui utilizator, indexul
respectiv va continua să existe și după revocare.
Revocarea unui privilegiu obiect poate determina efectul de revocare în cascadă a acestuia.
De exemplu, dacă utilizatorului U1 i se acordă privilegiul obiect SELECT pe un tabel, cu opț iunea
WITH GRANT OPTION , iar acesta îl acordă utilizatorului U2, atunci revocarea privilegiului
utilizatorului U1 va determina automat r evocarea acestui pr ivilegiu și pentru utilizatorul U2.
I.8. Administrarea utilizatorilor și resurselor
În funcț ie de licenț ele deținute pentru siste mul Oracle , trebuie limitat numărul de sesiuni
concurente și de utilizatori conectaț i la baz a de date (1). Aceasta se realizează prin setarea
parametrilor de iniț ializare de tip LICENSE.
Licențele pentru folosirea c oncurentă limitează numă rul de sesiuni care pot fi c onectat e
simultan la baza de date. Numă rul maxim de sesiuni concurente , parametrul LICENSE
_MAX_SESSIONS , poate fi precizat î nainte de a porni instanț a și modificat î n timp ce baza de date
este p ornită. Atunci când această limită este atinsă , sistemul va t rimite uti lizatorilor un mesaj prin
care îi anunță acest lucru. Î n acest caz, se pot conecta la baza de date numai utilizatorii care au
privilegiul RESTRICTED SESSION.
Limitarea numărului de utilizatori restricționează numărul autoriză rilor individuale de
folosi re a sistemului. Precizarea numă rului maxim de utilizatori care pot fi creați î n baza de date
se face înainte de pornirea unei instanț e (LICENSE_MAX_USERS ). Această limită poate fi
modificată în timpul funcționă rii instan ței, prin folosirea comenzii ALTER SYSTEM. Dup ă
depă șirea ei, nu mai pot fi creați noi utilizatori. Î n acest caz, sistemul va t rimite un mesaj p rin care
anunță că numă rul maxim de utilizatori permiș i a fost atins.
Vizualizarea V$LICENSE din dicț ionarul da telor permite identificarea setărilor curente
privind limitările impuse : numă rul cu rent de sesiuni ale utilizatorilor , respectiv numă rul maxim de
sesiuni concurente atins de la momentul porni rii instanței și numărul maxim de utilizatori care pot
fi creați .
Fiecare bază de date Oracle conține o listă de utilizatori. Pentru a accesa baza d e date, un
utilizator trebuie să execute o aplica ție a bazei de date și să se conecteze la o instanță a acesteia,
folosind un cont valid definit în baza de date.
Crear ea unui utilizator se realizează prin comanda CREATE USER. Pentru a avea dreptul
de folosire a acestei c omenzi este necesar privilegiul sistem CREATE USER. În general,
17
administrator ul de securitate este singurul care are acest privilegiu. Crearea unui utilizator const ă
în definirea ident ității sale , nume ș i parol ă, specificarea profilului, a spa țiului tab el implicit, a cotei
de folosire a spa țiului tabel și a spațiului tabel temporar î n care sunt create segmentele temporare.
Forma simplificată a comenzii CREATE USER este următoarea:
CREATE USER nume_utilizator
IDENTIFIED
{BY parola l EXTERNALLY
| GLOBALLY AS CN=nume_user, alte_atribute_de_identificare’ }
[DEFAULT TABLESPACE nume_spatiu_tabel ]
[TEMPORARY TABLESPACE nume_spatiu_tabel ]
[QUOTA {intreg [{K | M}] | UNLIMITED } ON nume_spatiu_tabel ]
[PROFILE nume_profil ]
[PASSWORD EXPIRE ]
[ACCOUNT {LOCK | UNLOCK }]};
Numele unui utilizato r trebuie să fie unic. Un utilizator și un role nu pot avea acelaș i nume.
Modul de autentificare poate fi realizat prin baza de date ( IDENTIFIED BY parola ), extern
(IDENTIFIED EXTERNALLY ) sau prin protocolul SSL (IDENTIFIED GLOBALLY AS
‘specificaț ie_identificare’ ). Șirul specificaț ie_identificare furnizează un mod de identificare la
nivelul directorului de servicii.
Fiecare uti lizator trebuie să aibă asociat un spaț iu tabel implicit , DEFAULT
TABLESPACE , în care sistemul stocheaz ă obiectele create de utiliza tor, dacă nu se specifică un alt
spațiu tabel pentru acestea. Spaț iul tabel implicit este SYSTEM.
Pentru fiecare utili zator se poate specifica un spațiu tabel temporar. Acest spaț iu tabel este
folosit pentru stocarea segmentelor temporare care sunt necesare comenzilor SQL inițiate de că tre
utilizator. Dacă nu este specificat un spaț iu tab el temporar, sistemul alocă î n mod impli cit
utilizatorului spaț iul tabel temporar care a fost defini t la crearea bazei de date. Dacă nici a cesta nu
a fost specificat, spaț iul tab el temporar implicit este SYSTEM.
Cu scopul de a preveni consumul excesiv al spaț iului bazei de date se pot preci za limite de
folosire pentru spaț iile tabel la care are acces utilizatorul. Aceste limite sunt specificate prin clauza
QUOTA. Dacă limita spaț iului tabel este 0, atunci utilizatorul nu mai poate crea obiecte noi, iar
pentru obiectele existente în spaț iul tabel respectiv acesta nu își poate aloca spațiu suplimentar.
Opțiunea UNLIMITED presupune folosirea neli mitată a spaț iului tabel respectiv.
Privilegiul sistem UNLIMITED TABLESPACE permite utilizatorilor să dețină spaț iu tabel
nelimitat. Acest privilegiu ar e prioritate față de toate limitele specificate pentru spaț iile tabel
alocate utilizatorului respectiv.
18
De asemenea, la crearea unui utilizator se poate specifica profilul a cestuia. Profilurile
facilitează administrarea parolelor ș i a limitelo r de folosir e a resurselor. Dacă nu este specifi cat
nici un profil, se asociază unul implicit. Clauza PASSWORD EXPIRE presupune că parola
utilizatorului trebuie schimbată la prima conectare la baza de date.
Blocarea sau deblocarea contului unui utilizator se realizează folosi nd clauza ACCOUNT ,
cu opț iunile LOCK, respectiv UNLOCK .
Pentru a modifica o opț iune a domeniului de securitate a unui utilizator (modul de
autentificare, limit ele unui spaț iu tab el, revocarea unui spaț iu tabel, profilul) este necesar
privi legiul sistem ALTER USER. De obicei, acest privilegiu este deț inut doar de administratorul
de securitate. Comanda folosită este ALTER USER, iar modifică rile specificate prin aceasta nu
afectează sesiunea curentă a utilizatorului.
Singura opț iune pe care fi ecare utilizator o poate modifica pentru propriul cont este parola.
Pentru aceasta nu este necesar un privileg iu sistem special, altul decâ t cel de conectare l a baza de
date. Comanda folosită are urmă toarea sintaxă :
ALTER USER nume_utilizator IDENTIFIED BY parola;
Ștergerea unui utilizator implic ă eliminarea acestuia ș i a schemei asociate din dicț ionarul
datelor, ceea ce determină ștergerea imediată a tuturor obiectelor conținute în schemă . Dac ă se
dorește pă strarea schemei unui u tilizator, iar acesta trebuie să piardă dreptul de a accesa baza de
date, atunci i se va revoca utilizatorului respectiv privilegiul CREATE SESSION.
Nu se poate elimina un utilizator care este conectat la baza de date. Pentru a putea elimina
un utilizator este necesar p rivilegiul sistem DROP USER. Dacă schema utilizatorului conține
obiecte, trebuie folosită opț iunea CASCADE pentru a ș terge at ât utilizatorul, cât ș i toate obiectele
asociate, inc lusiv cheile externe care referă tabelele deținute de utilizator. Dacă utilizatorul are
obiecte asociate și nu este utilizată această clauză, atunci sistemul returnează un mesaj de eroare,
utilizatorul nefiind eliminat. Si ntaxa comenzii folosite pentru ștergerea unui utilizator este:
DROP USER nume_utilizator [CASCADE ];
Fiecare bază de date conț ine un grup de utilizatori numit PUBLIC. Deoarece orice utilizator
al bazei de date face p arte î n mod automat din grupul PUBLIC, privilegiile ș i role-urile acordate
acestui grup sunt accesibile tut uror utilizatorilor. Ca membru al acestui grup utilizatorul poate
consulta toate tab elele din dicț ionarul datelor prefixate de USER sau ALL.
Se pot acorda sau revoca grupului PUBLIC orice privilegii sistem, privilegii asupra
obiect elor sau role-uri. Din motive de securitate, este recomandabil să se ac orde doar privilegiile
sau role-urile care îi interesează pe toț i membrii grupului. Acordarea sau revocarea unor privilegii
sistem sau asupra obiect elor grupului PUBLIC poate c onduce la recompilarea vizualizărilor,
procedurilor, funcț iilor, pachetelor ș i declanșatorilor.
19
I.9. Administrarea pa rolelor și a resurselor utilizâ nd profiluri
Un profil este un set de limită ri de resurse [1] care poate fi atribui t unui utilizato r al bazei
de date. Fiecare bază de date Oracle permite definirea unui număr nelimitat de pro filuri. Acestea
trebuie create ș i administrat e doar dacă politica de securitate a bazei de date cere ca utilizarea
resurselor să fie limitată . Pentru a putea folosi profilurile, mai întâi se creează categorii d e grupuri
de utilizatori similari.
Profilurile pot fi atribuite fiecărui utilizator î n part e, folosind comanda CREATE USER sau
ALTER USER sau se pot defini profiluri implicite care sunt asociate tuturor utilizatorilor care nu
au un profil specific.
Pentru a crea un profil este necesar privilegiul sistem CREATE PROFILE. În momentul
creării se pot stabili limitele folosirii unor resurse particulare sau parametrii pentru parole.
Comanda prin care se cr eează un profil este urmă toarea:
CREATE PROFILE nume LIMIT
[SESSIONS_PER_USER valoare ]
[CPU_PER_SESSION valoare ]
[CPU_PER_CALL valoare ]
[CONNECT_TIME valoare ]
[IDLE_TIME valoare ]
[LOGICAL_READS_PER_SESSION valoare ]
[LOGICAL_READS_PER_CALL valoare ]
[PRIVATE_SGA valoare ]
[COMPOSITE_LIMIT valoare ]
[FAILED_LOGIN_ATTEMPTS valoare ]
[PASSWORD_LIFE_TIME valoare ]
[PASSWORD_REUSE_TIME valoare ]
[PASSWORD_REUSE_MAX valoare ]
[PASSWORD_LOCK_TIME valoare ]
[PASSWORD_GRACE_TIME valoare ]
[PASSWORD_VERIFY_FUNCTION {funcție | NULL | DEFAULT }];
Pentr u fiecare parametru care apare în comandă se poate preciza o valoare întreagă sau
opțiunea UNLIMITED, respectiv DEFAULT. Opțiunea UNLIMITED indică posiblitatea de
folosire nelimitată a resursei respective. Dacă se foloseș te DEFAULT, atunci limita de fo losire a
resursei va fi preluată din profilul implicit.
20
Fiecare bază de date deține un profil implicit. Toate limită rile de resurse nespecificate
pentru profilurile particulare vor fi setate auto mat la valorile implicite. La c rearea bazei de date ,
server -ul Oracle defineș te profilul implicit DEFAULT.
Sistemul Oracle poate autentifica utilizator ii folosind informaț ii stocate î n baza de date.
Cea mai importantă informație de autentificare o reprezintă parola asociată unui utilizator. Aceasta
este crip tată și stocată în dicț ionarul d atelor. Utilizatorul poate oricând să -și schimbe propria
parolă .
Pentru a asigura confidenț ialitatea parolelor, siste mul permite criptarea acestora în timpul
conexiunilor din reț ea (client/server sau server/server ). Dacă este activată aceas tă funcționalitate
atât pe maș ina client, cât ș i pe server, sistemul codifică parolele înainte de a le trimite î n rețea,
folosind o versiune modificată a algoritmului de criptare DES (Data Encryption Standard ).
În situația în care utilizatorul introduce parola gre șit de un numă r speci ficat de n ori,
sistemul blochează contul asociat acestuia. În funcț ie de modul de configurare, contul poate fi
deblocat automat, după un interval specif icat de timp, sau manual, de către administrator ul bazei
de date. Prin parametrul FAILED_LOGIN_ATTEMPTS se precizează numă rul de conectă ri care
pot e șua înainte de blocarea contului, iar prin parametrul PASSWORD_LOCK_TIME numărul de
zile î n care acesta va fi blocat.
Administratorul bazei de date poate b loca manual un cont, folosind comanda ALTER
USER. În acest caz, contul nu mai poate fi deblocat auto mat, administratorul trebuind să -l
deblocheze explicit.
Prin parametrul PASSWORD_LIFE_TIME se poate specifica perioada de valabilitate a
unei parole. După această perioadă, parola expiră și trebuie schimbată. La prima încercare de
conectare după expirare apare un mesaj p rin care utilizatorul este atenționat că trebuie să-și
schimbe parola într -un anumit numă r de zile , perioad ă în care are î ncă dreptul de con ectare.
Aceast ă perioadă este precizat ă prin parametrul PASSWORD_GRACE_TIME. Dacă parola nu este
schimbat ă până la terminarea perioadei de gra ție, atunci contul se blochează automat.
Se recomandă ca schimbarea parolelor să nu se facă folosind comanda ALTER USER ,
deoarece aceasta nu realizează verificarea completă a complexităț ii parolei. Este preferabil ca
pentru schimbarea unei parole să se utilizeze funcț ia OCIPasswordChange ().
Pentru a verifica dacă o parolă nou specificată nu a mai fost utilizată anteri or este păstrat
un istori c al parolelor. Prin parametrul PASSWORD_REUSE_TIME se poate preciz a intervalul de
timp, exprimat în număr de zile, după care se poate refolosi o parolă. Î n urma execuț iei script -ului
utlpwdmg.sql , server -ul Oracle creează î n schema SYS funcț ia implicit ă VERIFY_FUNCTION
care asigură verificarea complexității unei parole. Aceasta verifică dacă parola î ndeplinește
următoarele condiț ii:
21
are lungimea de cel puț in 4 caractere ;
nu coincide cu username -ul;
include cel putin o literă , o cifră ș i un caracter special ;
nu este un cuvânt simp lu din lista de elemente interne;
difer ă de par ola anterioară cu cel puț in 3 caractere .
Rutina de verificare a complexității parolelor poate fi modificată sau se p oate crea o rutină
nouă, în sch ema SYS. Comanda CREATE PROFILE permite, prin intermediul parametrului
PASSWORD_VERIFY_FUNCTION , precizarea unei funcț ii PL/SQL pentru verif icarea
complexităț ii parolelor.
Pentru fiecare utilizator, sistemul permite specificarea unei limite de folo sire a resur selor
disponibile, în cadrul domeniului să u de securitate. Astfel, se controlează consumul resurselor
importante ale sistemului. Limitarea resurs elor este o metodă deose bit de utilă î n cazul sistemelor
multiuser , unde acestea sunt costisitoare. Consu mul ex cesiv al resurselor, de către unul sau mai
mulți utilizatori, poate fi în detrimentul celorlalț i utilizatori ai bazei de date.
Sistemul poate controla utilizarea resurselor la nivel de sesiune – session level , la nivel de
apel – call level sau la ambele ni veluri.
În momentul cone xiunii unui utilizator la o bază de date se creează o sesiune. Fiecare
sesiune consumă timp CPU (timp de încă rcare al procesorului) și memorie. Dacă utilizatorul
depășeș te limita de consum a resurselor, sistemul anulează comanda cur entă și returnează un mesaj
prin care indică depășirea limitei și sunt permise doar operaț ii de tip COMMIT , ROLLBACK sau
deconectare. Toat e celelalte operaț ii produc erori.
Sistemul permite ș i limitarea altor r esurse la nivel de sesiune: numă rul de sesiuni
concurente p entru fiecare utilizator, timp ul în care o sesiune poate rămâne inactivă , timpul de
conectare consu mat pentru fiecare sesiune, spaț iul SGA (folosit de zonele private SQL) al unei
sesiuni etc.
Pentru procesarea comenzilor SQL sau altor tipuri d e apeluri că tre sistem este necesar un
timp CPU . În medie, apelurile nu sunt mari consumatoare de timp CPU. În schimb, o comanda
SQL poate implica multe interogă ri care pot fi mari consumatoare ale acestei resurse. Pentr u a
preveni folosirea inadecvată a timpului CPU , se pot f ixa limite pentru fiecare apel î n parte sau
pentru apelurile din cadrul unei anumite sesiuni.
Operaț iile I/O sunt unele dintre cele mai costisitoare operaț ii într-un sistem de baze de date.
De aceea, sistemul permite limitarea citirilor blocurilor logice de date, la nivel de apel sau de
sesiune. Citirea blocurilor logice de date include citirea blocurilor de date din memorie și de pe
disc. Limitările presupun nu mărarea blocurilor citite î n timpul unui apel sau pe parcursul unei
sesiuni.
22
Opțiunile de limit are a resurselor care intervin î n comanda CREATE PROFILE sunt
urmă toarele:
SESSION_PER_USER – numă rul maxim de sesiuni concurente ;
CPU_PER_SESSION – timpul de încărcare a procesoru lui pentru o sesiune, exprimat
în secunde ;
CPU_PER_CALL – timpul de încă rcare a proceso rului pentru un apel, exprimat în
secunde ;
CONNECT_TIME – timpul t otal al unei sesiuni, exprimat în minute ;
IDLE_TIME – timpul de inactivitate continuă pe pa rcursul unei sesiuni, exprimat în
minute ;
LOGICAL_READS_PER_SESSION – numărul de blocuri de date citite î ntr-o sesi une,
inclusiv blocurile ci tite din memorie sau de pe disc ;
LOGICAL_READS_PER_CALL – numă rul de blocuri de date citite pe parcur sul unui
apel pentru a procesa o comandă SQL;
PRIVATE_SGA – dimensiunea spaț iului SGA alocat unei sesiuni ;
COMPOSITE_LIMIT – costul total al resurselor pentru o sesiune .
Înainte de crearea profilurilor ș i specificarea limitelor de f olosire a res urselor asociate lor,
trebuie să se determine valorile estimative pentru fiecare limită de resurse. Estimarea ace stor limite
se poate face evaluâ nd tipul de opera ții pe ca re le execută o categorie de utilizator i. De exemplu,
dacă o categorie d e utilizatori, în mod normal, nu face un numă r mare de citiri din blocurile logice
de date, atunci valorile parametrilor re feritori la acest tip de resursă pot fi mari. De obicei, cea mai
bună cale de a determina valoarea aproximativă a limitei de folosire a resurselor pentru un profil
al unui utilizato r dat este consultarea informaț iilor istorice cu privire la o cuparea fiecărui tip de
resurse. Pentru a obț ine statistici referitoare la folosirea resurselor se poate utiliza componenta d e
monitorizare a utilitarului OEM sau SQL*Plus . De exemplu, administratorul de securitate poate
folosi clauza AUDIT SESSION pentru a obț ine informaț ii despre limitele CONNECT_TIME ,
LOGICAL_READS_PER_SESSION și LOGICAL_READS_PER_CALL.
Pentru ca profilurile să aibă efect , trebuie să fie pornită opț iunea de limitare a resurselor
pentru baza de date. Activarea sau dezactivarea acestei opțiuni se poate face î naintea p ornirii bazei
de date sau în timp ce aceasta este deschisă. Î n acest sens, este folosit parametr ul de iniț ializare
RESOURCE_LMIT (TRUE pentru activare, FALSE pentru dezactivare).
După cum se observă , comanda CREATE PROFILE permite limitarea costului total al
resurselor. Astfel, utilizat orul poate folosi orice resurse dorește, dar suma cantităț ilor re surselor
consumate nu poate depăși această limită. Un profil poate folosi limită ri explicite de resurse,
23
concomitent cu limitarea costului total al resurselor. Atinger ea uneia dintre limite determină
oprirea activitații utilizatorului î n sesiune. Folosirea limitărilor compuse permite mai multă
flexibilitate. Valoarea corectă a unei limite compuse de resurse depinde de cantitatea t otală de
resurse folosită î n medie de un utilizator.
Limită rile de resurse la nivel de apel ( LOGICAL_READS_PE R_CALL , CPU_PER_CALL )
sunt impuse fiecărui apel inițiat î n timpul execuț iei unei comenzi SQL. Depăș irea unei a dintre
aceste limite determină î ntrer uperea procesării comenzii ș i anularea acesteia, se siunea
utilizatorului fiind menținută .
După ce profilul a fost creat, el poate fi asociat utilizatorilor bazei de date. Nu este posibil
ca un utilizator să aibă conco mitent mai multe profiluri. Dacă un profil este atribuit unui utilizator
care are deja unul, noul profil îl va î nlocui pe cel vechi. Aso cierea profi lurilor nu afectează sesiunea
curentă . Profilurile pot fi atribuite numai utilizatorilor și nu unui role sau unui alt profil.
Folosind comanda ALTER PROFILE se pot modifica limit ările de resurse ale unui profil.
Pentru a ceasta este necesar privilegiul sistem ALTER PROFILE. Orice utilizator care deț ine acest
privilegiu poate modifica limitările profilului implicit. Inițial, nu există limită ri de resu rse în
profilul implicit , acestea au valoarea UNLIMIT . Pentru a preveni consumul nelimitat de resurse,
administratorul de securitate a sistemului va trebui să modifice acest lucru în profil.
Modificările fă cute asu pra unui profi l nu vor afecta sesiunea curentă . Acestea vor deveni
active pentru sesiunile ulterioare.
Ștergerea unui profil necesită privilegiul sistem DROP PROFILE. Comanda SQL folosită
are urmă toarea sintaxă :
DROP PROFILE nume_profil [CASCADE ];
Opțiunea CASCADE se folosește dacă profilul este asociat mai multo r utilizatori. Aceasta
determină disoci erea profilului respectiv de toți utilizatorii care îl aveau alocat. Î n mod automat,
sistemul va atri bui acestora profilul implicit.
Sistemul menține o serie de vizualizări în dicționarul datelor care conțin informaț ii des pre
utilizatorii bazei de date ș i despre pro filuri:
DBA_TS_QUOTAS – descrie cotel e spaț iilor tabel pentru utilizatori;
USER_PASSWORD_LIMITS – descrie valorile parametr ilor referitori la parole, setaț i
prin comanda CREATE PROFILE ;
DBA_PROFILES – listează toate profilurile împreună cu limitele lor ;
USER_RESOURCE_LIMITS – afișează limită rile de resurse pentru utilizatorul c urent ;
RESOURCE_COST – afișează costul fiecărei resurse ;
V$SESSTAT – listează statistici despre sesiunile utilizatorilor ;
24
V$STATNAM – afișează numele statisticilor lista te prin vizualizarea anterioară ;
PROXY_USERS – descrie utilizatorii bazei de date care își pot asuma id entitatea altor
utilizatori.
I.10. Metode de autentificare a utilizatorilor
Autentificarea reprezintă procesul prin care este certificată identitatea utilizatorilor care
inițiază o conexiune la baza de date. Metoda cea mai cunoscută de autentificare este cea bazată pe
parole. Pe lângă această metodă, baza de date Oracle oferă suport pentru implementarea unor
metode sigure de autentificare c u ajutorul unor servicii third -party de autentificare, cum ar fi SSL
– Secure Sockets Layer , care folosește certificate digitale pentru a verifica identitatea utilizatorilor
care se conectează la baza de date.
Având la dispoziție un instrument centralizat care autentifică toți membrii unei rețele
(autentificarea clienților la servere, a serverelor la servere sau a utilizatorilor atât la clienți, cât și
la servere) riscul ca unul dintre nodurile din rețea să își falsifice identitatea se poate diminua
semnif icativ.
De asemenea, autentificarea centralizată oferă beneficiul modelului single sing -on, ce le
permite utilizatorilor să acceseze mai multe aplicații și conturi cu ace leași parole. Folosind single
sing-on utilizatorul va trebui să introducă doar o sing ură dată parola, iar apoi va fi conectat automat
la orice alt serviciu, fără a i se mai cere username -ul și parola aferentă.
Un sistem centralizat de autentificare în rețea interacționează cu serverul Oracle , cu
serverul de autentificare și cu utilizatorii care încearcă să se conecteze la serverul Oracle .
Etapele procesului de autentificare în rețea sunt:
1. Un utilizator solicită servicii de autentificare de la serverul de autentificare. Clientul își
dovedește identitatea prin furnizarea unui cod sau a unei parole.
2. Serverul de autentificare validează identitatea utilizatorului și îi oferă fie un tichet, fie
niște credențiale care pot să includă și un timp de expirare.
3. Clientul transmite aceste credențiale serve rului Oracle și, în același timp , solicit ă o
conexiune la baza de date.
4. Serverul Oracle trimite înapoi credențialele către serverul de autentificare pentru a le
verifica validitatea.
5. Serverul de autentificare verifică apoi credențialele și notifică serveru l Oracle .
6. În cazul în care credențialele au fost acceptate de către serverul de autentificare, atunci
serverul Oracle autentifică utilizatorul. Dacă în schimb acestea au fost respinse, atunci
autentificarea eșuează, iar conexiunea la baza de date este respinsă.
Baza de date Oracle suportă următoarele metode de autentificare sigură:
25
Secure Sockets Layer (SSL) ;
Kerberos ;
Remote Authentication Dial -In User Service (RADIUS) .
I.10.1. Autentificarea folosind Secure Sockets Layer
Secure Sockets Layer [4] este un protocol standard dezvoltat inițial de Netscape
Communications Protocol pentru a securiza conexiunile de la nivelul unei rețele . Ulterior, Internet
Engineering Task Force a preluat dezvoltarea acestui protocol și l -a redenumit în Transport Layer
Security .
Pe lângă capacitatea protocolului SSL de a cripta comunicarea dintr -o rețea și de a asigura
integritatea datelor, baza de date Oracle suportă și autentificarea pe bază de certificate digitale
SSL.
Există două modalități de a folosi SSL pentru a securiza comunicarea dintre client și server:
1. Utilizarea protocolului SSL doar pentru criptarea conexiunilor dintre client și server;
2. Autentificarea oricărui client sau server (de exemplu Oracle Weblogic Server ) la orice
server de baze de date Oracle configurat să comunice prin SSL.
Funcționalitățile SSL pot fi folosite independent sau pot fi combinate cu alte metode de
autentificare suportate de baza de date Oracle . De exemplu, se poate folosi doar partea de criptare
oferită de SSL, iar pentru autentifica re se poate implementa Kerberos . SSL suportă următoarele
variante de autentificare:
Doar serverul se autentifică la client;
Atât serverul se autentifică la client, cât și clientul la server;
Nici clientul, nici serverul nu se autentifică unul la celălalt, folosind astfel doar
criptarea conexiunii.
Infrastructura cu chei publice (PKI – Public Key Infrastructure )
Aceast ă infrastructură reprezintă o colecție de produse hardware și software [5], politici și
proceduri , care asigură securitatea de bază necesară schimbului de informații dintre două entități.
Criptografia tradițională cu chei private sau cu chei simetrice necesită o singură cheie ce
este cunoscută și folosită de două sau mai multe entități pentru a -și securiza comunicarea.
Această cheie este folosită atât pentru criptarea, cât și pentru decriptarea mesajelor, fiind
necesară transmiterea în prealabil a acesteia, printr -o metodă sigură, participanților la comunicare .
De aici rezultă și dezavantajul major al acestei metode și anume acela că este dificil ă distribui rea
și stoc area cheii într-un mod sigur.
26
Criptografia cu chei publice rezolvă această problem ă, introducând perechi de chei publice
și private și o singură metodă de a le distribui. Cheia publică este folosită pentru a cripta mesajele
care pot fi decriptate doar de posesorul cheii private. Cheia privată este stocată împreună cu alte
credențiale într -un container criptat numit wallet .
Algoritmii cu chei publice pot asigura securitatea mesajului, însă ei nu pot garanta și
securitatea comunic ării, în trucât nu verifică și identitățile entităților care comunică. Pentru a stabili
o comunicare sigură, este important să se verifice că într -adevăr cheia cu care s -a criptat mesajul
aparține destinatarului. Astfel, există riscul atacului de timp man-in-the-middle , în care un intrus
interceptează schimbul de chei și substitu ie cheia publică legitimă cu propria cheie.
În scopul evitării acestui tip de atac, este necesar să se verifice posesorul cheii publice,
acest proces fiind numit autentificare. Auten tificarea se poate realiza cu ajutorul unei autorități de
certificare care este o entitate third -party , folosită de ambii participanți la comunicare.
În sistemul Oracle , infrastructura cu chei publice are următoarele componente:
1. Autoritatea de certificare – este o entitate terță, sigură, care atestă identitatea altor
entități, cum ar fi utilizatori, baze de date, administrator i, clienți și servere. În
momentul în care o entitate cere să fie certificată , autoritatea de certificare îi verifică
identitatea și îi eliberează un certificat semnat cu cheia privată a autorității. Fiecare
entitate dintr -o rețea își poate obține propriile certificate de la o singură autoritate sau
chiar de la mai multe. În mod implicit, la crearea unui wallet , baza de date Oracle
instalează automat o listă de certificate sigure semnate de VeriSign , RSA, Entrust și
GTE Cyber Trust .
2. Certificatul – este creat atunci când cheia publică a unei entități este semnată de o
autoritate de certificare sigură și garantează că informațiile de identificare ale unei
entități sunt corecte, iar cheia publică îi aparține într -adevăr entității respective. Un
certificat conține numele entității, cheia publică, data de expirare, un număr de serie,
informații despre lanțul de certificate și informații l egate de privilegiile asociate
certificatului. Atunci când o entitate dintr -o rețea primește un certificat, aceasta verifică
dacă certificatul este sigur, în particular dacă a fost semnat de o autoritate de certificare
sigură. Un certificat rămâne valid pâ nă la data expirării sau până când este revocat.
3. Listele de revocare a certificatelor – în general, atunci când o autoritate de certificare
semnează un certificat asociind o cheie publică cu identitatea unui user, acesta este
valid pentru o anumită perioadă de timp. În urma unor evenimente care pot invalida un
certificat înainte ca data sa de expirare să fie atinsă, autoritatea de certificare revocă
certificatul și îl adaugă într -o listă de certificate revocate. De asemenea, autoritatea de
certificar e publică periodic aceste liste pentru a alerta utilizatorii certificatelor că nu se
27
mai po ate folosi cheia publică asociată unui certificat revocat pentru a stabili identitatea
unui utilizator. În sistemul Oracle , în momentul în care un server sau un clie nt primește
un certificat al unui utilizator, certificatul poate fi validat verificându -i-se dat a de
expirare, semnătura sau dacă a fost revocat.
4. Wallet – este un fișier folosit pentru a stoca informații legate de autentificare precum
chei private, certifi cate, certificate sigure solicitate de SSL. Într-un mediu Oracle ,
fiecare entitate care comunică prin SSL trebuie să aibă un wallet care să conțină un
certificat X509 v.3 , o cheie privată și o listă de certificate sigure. De asemenea, Oracle
furnizează un produs numit Oracle Wallet Manager , cu ajutorul cărora se pot face
următoarele operații:
Generarea unei perechi formată dint r-o cheie publică și una privată , precum și
crearea unei cereri de certificat;
Stocarea unui certificat al unui utilizator care s e potrivește cu cheia privată ;
Configurarea de certificate sigure.
5. Module hardware de securitate – în contextul SSL sunt niște dispozitive hardware
folosite pentru a stoca informații criptografice.
I.10.2. Autentificarea la baza de date folosind Kerberos
Kerberos este un protocol de autentificare (6) ce se bazează pe un sistem de autentificare
third -party (KDC – Key Distribution Center ) care îi furnizează clientului niște tichete cu ajutorul
cărora își poate demonstra identitatea în fața furnizoru lui de servicii (în acest caz, furnizorul de
servicii este baza de date Oracle ). Datele sch imbate în timpul acestui proces sunt criptate cu chei
simetrice.
Procesul de autentificare prin Kerberos presupune următorii pași:
1. Clientul Oracle solicit ă de la KDC un tichet iniț ial numit Ticket Granting Ticket (TGT) .
Comanda cu care se solicit ă tichetul este okinit .
2. Centrul de distribuire a cheilor ( KDC ) îi oferă clientului Oracle tichetul iniț ial. Acest
tichet constă într -un mesaj cripta t ce va fi decriptat cu parola i ntrodusă la executarea
comenzii okinit . TGT-ul este stocat într -un cache de credențiale ( credential cache ).
3. În momentul în care clientul va încerca să se conecteze la baza de date, va fi trimisă în
mod transparent o cerere către KDC pentru a -i furn iza un Service Ticket . Acest tichet
va fi transmis mai târziu către baza de date.
4. KDC -ul îi trimite clientului tichetul de tip Service Ticket sub forma unui mesaj criptat
cu o cheie cunoscută de către baza de date.
28
5. Clientul trimite tichetul către serverul bazei de date care va folosi acest tichet pentru a
verifica identitatea clientului.
6. Sesiunea dintre client și baza de date este stabilită.
II. Descrierea modelului, formularea problemei și a constrângerilor
II.1. Noțiuni generale și formularea problemei
O bază de date reprezintă un ansamblu de date integrat [2], anume structurat și dotat cu o
descriere a acestei structuri. Descrierea structurii poartă numele de dicționar de date sau metada te
și creează o interdependență între datele propriu zise și programe.
Baza de date conțin e nucleul de date necesare unui sistem informatic. Astfel, poate fi
considerată drept o reprezentare a unor aspect e ale realității unei instituții publice , modelată pr in
intermediul datelor. Diferitele obiecte din cadrul realității ce prezintă interes sunt denumite clase
sau entități. Pentru aceste obiecte sunt achiziționate și memorate date referitoare la diferite
caracteristici.
Proiect ăm o bază de date care să poată fi utilizată pentru gestiunea actelor de identitate
eliberate cetățenilor români, pornind de la următoarele ipoteze de lucru:
Ghișeul Unic reprezintă acea instituție publică pentru eliberarea și evidența actelor de
identitate ale cetățenilor români;
Baza de date reține informațiile privind persoanele, domiciliul acestora și documentele
care le -au fost eliberate: carte de identitate și pașaport simplu ;
În baza de date sunt stocate în tabele denumite nomenclatoare , informațiile privind
unitățile administrati v-teritoriale, artere de circulație, precum și locațiile unice în care
persoanele își pot stabili domiciliul .
Cerințele tehnice necesare modelului bazei de date sunt următoarele:
descrierea modelului, formularea problemei și a constrângerilor – entitățile, atributele
și cheia primară a fiecărei entități, cardinalitățile relațiilor ce se stabilesc între entități,
tipurile de constrâ ngeri care vor trebui create pentru a respecta cerințele impuse;
diagrama Entitate Relație;
descrierea entităților, relațiilor și atributelor ;
diagrama conceptuală ;
29
normalizarea modelului ;
crearea bazei de date .
II.2. Identificarea entităților
Entitățile analizate [2] a fi participante la structura modelului real sunt următoarele:
Persoana : cetățeni români, identificatorul unic fiind codul numeric personal (CNP);
Document de identitate : act oficial emis de o autoritate publică, care face dovada
identității unei persoane, a cetățeniei și domiciliului acesteia, pe teritoriul național,
precum și pe teri toriul anumitor state, identificatorul unic fiind format din seria și
numărul acesteia;
Pașaport simplu : act oficial emis de o autoritate publică, care face dovada identității
unei persoane și a cetățeniei acesteia, în afara granițelor naționale, identific atorul unic
fiind form at din numărul acestuia;
Domiciliu : reprezintă locul unde persoana își are principala așezare, în vederea
exercitării drepturilor sale civile, identificatorul unic fiind codul domiciliului ;
Ghișeu unic : instituție publică pentru eliberarea și evidența actelor de identitate și a
pașapoartelor simple , identificatorul unic fiind codul ghiș eului
;
Operatori : funcționari din cadrul Ghișeului Unic, desemnați să proceseze datele cu
caracter personal și să actualizeze baza de date , identificatorul unic fiind codul de
operator
;
Certificate de stare civilă : acte oficiale emise de autorități publice, care fac dovada
identității unei persoane sau a statutului civil , identifica torul unic fiind format din seria
și numărul acestuia
;
UAT (unitate administrativ teritorială):
parte componentă a teritoriului țării, cu
populaț ia și instituțiile aferente, denumită și organiza tă prin lege ( județele, orașele și
comunele), identificatorul unic fiind codul UAT
;
Artere de circulație : parte componentă a unui UAT
, identificatorul unic fiind codul
arterei .
II.3. Cardinalitățile relațiilor ce se stabilesc între entități
Conform regulilor de proiectare a diagramei E/R a modelului (1), cardinalitatea minimă
este indicată în paranteze, iar cardinalitatea maximă se scrie fără paranteze. Relațiile se clasifică
în funcție de cardinalitate în: relații one-to-one (1:1), relații one-to-many (1:M), și relații many -to-
30
many (M:M). O relație este descrisă prin două atribute, în funcție de cum se va citi relația
respectivă.
Referitor la relațiile din model, se pot face observațiile de mai jos:
Relația „Domiciliu pentru Persoana ” este o relație one-to-many (1:M), cu cardinalitatea
minimă 1:1. Cardinalitatea a fost dedusă astfel: la un domiciliu pot locui mai multe persoane, dar
o persoană locuiește la un singur domiciliu.
Relația „Ghișeu pentru Persoana ” este o relație one-to-many (1:M), cu cardinalitatea
minimă 1:1. Cardinalitatea a fost dedusă astfel: la un ghiseu se pot depune mai multe cereri, dar o
persoană depune cerere la un singur ghișeu .
Relația „Persoana pentru Cerificate ” este o relație one-to-many (1:M), cu cardinalitat ea
minimă 1:1. Cardinalitatea a fost dedusă astfel: o persoană deține mai multe certificate, dar un
certificat este deținut de o singură persoană.
Relația „Persoana pentru Document_identitate ” este o relație one-to-one (1:1).
Cardinalitatea a fost dedusă astfel: o persoană deține un singur document valid, iar un document
este eliberat unei singure persoane.
Relația „Persoana pentru Pasaport_simplu ” este o relație one-to-one (1:1). Cardinalitatea
a fost dedusă astfel: o persoană deține un singur pașaport simplu valid, iar un pașaport simplu este
eliberat unei singure persoane.
Relația „Ghișeu pentru Operatori ” este o relație one-to-many (1:M), cu cardinalitatea
minimă 1:1. Cardinalitatea a fost dedusă astfel: într-un ghișeu unic lucrează unul sau mai mulți
operatori, dar un operator lucrează într -un singur ghișeu.
Relația „Ghișeu pentru Document_i dentitate ” este o relație one-to-many (1:M), cu
cardinalitatea minimă 1:1. Cardinalitatea a fost dedusă astfel: un ghișeu u nic eliberează mai multe
documente, dar un document este eliberat de un singur ghișeu.
Relația „Ghișeu pentru Pasaport_simplu ” este o relație one-to-many (1:M), cu
cardinalitatea minimă 1:1. Cardinalitatea a fost dedusă astfel: un ghișeu unic eliberează mai multe
pașapoarte simple , dar un pașaport simplu este eliberat de un singur ghișeu.
Relația „UAT pentru Domiciliu ” este o relație one-to-many (1:M), cu cardinalitatea
minimă 1:1. Cardinalitatea a fost dedusă astfel: un UAT conține mai multe domicilii, dar un
domiciliu este localizat într -un singur UAT .
Relația „Artere_circulatie pentru Domiciliu ” este o relație one-to-many (1:M), cu
cardinalitatea minimă 1:1. Cardinalitatea a fost dedusă astfel: o arteră de circulație conține mai
multe domicilii, dar un domiciliu este localizat într -o singur ă arteră de circulație.
31
Relația „UAT pentru Artere de circulație ” este o relație one-to-many (1:M), cu
cardinalitatea minimă 1:1. Cardinalitatea a fost dedusă astfel: un UAT conține mai multe artere de
circulație , dar o arteră de circulație este localizat ă într-un singur UAT .
II.4. Diagrama entitate -relație
Diagrama E/R reprezintă un model neformalizat [1] pentru a înfățișa un sistem din lumea
reală. Es te un model de date conceptual de nivel înalt, dezvoltat de Peter Chen în 1976, pentru a
facilita proiectarea bazelor de date. O diagramă E/R este reprezentarea grafică a unei colecții de
entități, relații, constrângeri, condițion ări, care descriu complet o bază de date.
În alcătuirea diagramei entitate -relație, au fost aplicate următoarele reguli de reprezentare:
Entitățile sunt reprezentate prin dreptunghiuri;
Relațiile dintre entități sunt reprezentate prin arce neorientate;
Atributele care reprezintă chei primare trebuie marcate prin simbolul #, plasat la
sfârșitul numelui acestor atribute;
Cardinalitatea minimă este indicată în paranteze, iar cea maximă se scrie fără
paranteze.
Etapele pentru proiectarea diagramei entitate -relație sunt următoarele :
Identificarea entităților din cadrul sistemului analizat;
Identificarea relațiilor dintre entități și stabilirea cardinalității;
Identificarea atributelor aferente entităților și asocierilor dintre entități;
Stabilirea atributelor de identificare a entităților (stabilirea cheilor).
Diagrama E/R
32
M(1) M M(0) 1
localizat1
localizat3
M(1) localizat2 M
M locuiește M(1)
deține1 1
M
1
M(1) lucreză M
deține2
M d epune_cerere M(1) 1 1
M M
eliberează 2
1
1 deține1
1
eliberează 1
Atributele entităților sunt prezentate în următorul tabel:
Entitate Atribut Descriere Tip Constrângeri DOMICILIU
cod_domiciliu #
judet
cod_uat
cod_artera
numar_strada
bloc
etaj
scara
apartament
UAT
cod_uat #
denumire
tip
den_județ ARTERE_CIRCULATIE
cod_artera #
denumire
cod_uat
CERTIFICATE
serie #
numar #
tip
cnp
data_emitere
data_anulare
cod_uat OPERATORI
cod_op #
nume_op
parola
drepturi
status
data_start
data_stop
cod_ghiseu
detalii PERSOANA
cnp #
nume
prenume
data_nastere
sex
cod_uat_nastere
pren_tata
pren_mama
cetățenie
GHISEU_UNIC
cod_ghiseu #
denumire
cod_uat
DOCUMENT_IDENTITATE
serie #
numar #
cnp
data_emitere
data_expirare
tip
cod_emitent
data_anulare
fotografie PASAPORT_SIMPLU
numar #
cnp
data_emitere
data_expirare
tip
cod_emitent
data_anulare
fotografie
33
Ghiseu_unic cod_ghiseu Număr unic alocat INT
Ghiseu_unic denumire Denumirea ghișeului CHAR
Ghiseu_unic cod_uat Număr unic pentru un UAT INT
Operatori cod_op Număr unic alocat operatorului INT
Operatori nume_op Numele operatorului CHAR
Operatori parola Parola CHAR
Operatori drepturi Drepturile alocate CHAR
Operatori status Activ sau Revocat CHAR
Operatori data_start Data activării DATE
Operatori data_stop Data revocării DATE
Operatori cod_ghiseu Număr unic alocat ghișeului în
care lucrează INT
Operatori detalii Date despre operator CHAR
Persoana cnp Identificatorul unic al
persoanei CHAR
Persoana nume Numele persoanei CHAR
Persoana prenume Prenumele persoanei CHAR
Persoana data_nastere Data de naș tere a persoanei DATE
Persoana sex Sexul persoanei CHAR F/B
Persoana cod_uat_nastere Codul localității de naș tere INT
Persoana pren_tata Prenume le tatălui persoanei CHAR
Persoana pren_mama Prenume le mamei persoanei CHAR
Persoana cetățenie Cetățenia dobândită CHAR ”ROMÂNĂ”
Domiciliu cod_domiciliu Număr unic alocat INT
Domiciliu judet Denumirea județului din care
face parte localitatea CHAR
Domiciliu cod_uat Număr unic alocat unei
localități INT
Domiciliu cod_artera Număr unic alocat unei artere
de circulație INT
Domiciliu numar_strada Numărul străzii INT
Domiciliu bloc Denumire a imobil ului CHAR
Domiciliu etaj Etajul CHAR
Domiciliu scara Scara (intrare) CHAR
Domiciliu apartament Apartament ul CHAR
Uat cod_uat Număr unic alocat unui UAT INT
Uat denumire Denumire a entității
administrativ -teritoriale CHAR
Uat tip Tipul entității administrativ –
teritoriale CHAR
Uat den_judet Denumire a județ ului din care
face parte CHAR
Artere_circulatie cod_artera Număr unic pentru o arteră de
circulație INT
Artere_circulatie denumire Denumirea unei artere de
circulație CHAR
Artere_circulatie cod_uat Număr unic alocat unui UAT INT
Document_identitate serie Seria actului de identitate CHAR
Document_identitate numar Numărul actului de identitate INT
Document_identitate cnp Identificatorul unic al
persoanei deținătoare CHAR
Document_identitate data_emitere Data eliberării actului de
identitate DATE
Document_identitate data_expirare Data expirării actului de
identitate DATE
34
Document_identitate tip Tipul actului de identitate CHAR CI/CIP/CIE
Document_identitate cod_emitent Număr unic alocat emitentului INT
Document_identitate data_anulare Data anulării actului de
identitate DATE
Document_identitate fotografie Fotografia atașată actului de
identitate BLOB
Pasaport_simplu numar Numărul pașaportului INT
Pasaport_simplu cnp Identificatorul unic al
persoanei deținătoare INT
Pasaport_simplu data_emitere Data eliberării pașaportului DATE
Pasaport_simplu data_expirare Data expirării pașaportului DATE
Pasaport_simplu tip Tipul pașaportului CHAR PE/PT
Pasaport_simplu cod_emitent Număr unic pentru emitentul
pașaportului INT
Pasaport_simplu data_anulare Data anulării pașaportului DATE
Pasaport_simplu fotografie Fotografia atașată pașaportului BLOB
Certificate serie Seria certificatului CHAR
Certificate numar Numărul certificatului INT
Certificate cod_uat Emitentul certificatului INT
Certificate data_emitere Data emiterii certificatului DATE
Certificate tip Tipul certificatului CHAR
Cerere_doc cod_cerere Număr unic alocat cererii de
eliberare a documentului INT
Cerere_doc cod_ghiseu Număr unic alocat instituției
emitente a documentului INT
Cerere_doc cnp Identificatorul persoanei
solicitante CHAR
Cerere_doc data_cerere Data depunerii cererii DATE
Cerere_doc data_solutionare Data soluționă rii cererii DATE
Cerere_doc data_respingere Data respingerii cererii DATE
Cerere_pass cod_cerere Număr unic alocat cererii de
eliberare a pașaportului INT
Cerere_pass cod_ghiseu Număr unic alocat instituției
emitente a pașaportului INT
Cerere_pass cnp Identificatorul persoanei
solicitante CHAR
Cerere_pass data_cerere Data depunerii cererii DATE
Cerere_pass data_solutionare Data soluționă rii cererii DATE
Cerere_pass data_respingere Data respingerii cererii DATE
Domiciliu_persoana cnp Identificatorul persoanei CHAR
Domiciliu_persoana cod_domiciliu Număr unic alocat unui
domiciliu INT
Domiciliu_persoana data_start Data stabilirii la o adresă DATE
Domiciliu_persoana data_stop Data plecării de la o adresaă DATE
II.5. Diagrama conceptuală
Diagrama conceptuală (2) aferență modelului ales este contruită din diagrama E/R prin
adăugarea tabelelor asociative și prin marcarea cheilor externe.
Transformarea entităților se face astfel:
35
Entitățile independente devin tabele independente. Cheia primară nu conține chei
externe.
Entitățile dependente devin tabele dependente. Cheia primară a entităților dependente
conține cheia primară a entității de care depinde (cheie externă), plus unul sau mai
multe atribute adiționale.
Transformarea atributelor se face astfel:
Un atribut singular devine o coloană .
Atributele multiple devin tabele dependente ce conțin cheia primară a entității și
atributul multiplu. Cheia primară este o cheie externă, plus una sau mai multe coloane
adiționale.
Entitățile devin tabele, iar atributele lor devin coloane în aceste tabele. Pentru relații
1:1 și 1:n, atributele relațiilor vor aparține tabelului care conține cheia externă, iar
pentru relații M:M , atributele v or fi plasate în tabele asociative.
UAT = {#cod_uat, denumire, tip, den_ judet }
ARTERE_CIRCULATIE = {#cod_artera , denumire, cod_uat }
DOMICILIU = {#cod_domiciliu , den_ judet, cod_uat , cod_artera , numar_strada, bloc, etaj,
scara, apartament }
GHISEU_UNIC = {#cod_ghiseu , denumire , cod_uat }
OPERATORI = {#cod_op , nume_op , parola, drepturi, status, data_start, data_stop, cod_ghiseu ,
detalii }
PERSOANA = {#cnp, nume, prenume, data_nastere, sex, cod_uat_nastere , pren_tata,
pren_mama, cetățenie }
DOMICILIU_PERSOANA = {#cnp, #cod_domiciliu , data_start, data_stop}
DOCUMENT_IDENTITATE = {#serie , #numar , cnp, data_emitere, data_expirare, tip,
cod_emitent , data_anulare, fotografie }
PASAPORT_SIMPLU = {#numar , cnp, data_emitere, data_expirare, tip, cod_ emitent ,
data_anulare, fotografie }
CERTIFICATE = {#serie , #numar , tip, cnp, cod_uat , data_emitere }
CERERE_DOC = {#cod_cerere , cod_ghiseu , cnp, data_cerere, data_solutionare,
data_respingere }
CERERE_PASS = {#cod_cerere , cod_ghiseu , cnp, data_cerere, data_solutionare,
data_respingere }
36
I.6. Schema relațională
DOMICILIU
cod_domiciliu
judet
cod_uat
cod_artera
numar_strada
bloc
etaj
scara
apartament
CERTIFICATE
serie
numar
tip
cnp
data_emitere
data_anulare
cod_uat
PERSOANA
cnp
nume
prenume
data_nastere
sex
cod_uat_nastere
pren_tata
pren_mama
cetățenie
UAT
cod_uat
denumire
tip
den_județ ARTERE_CIRCULATIE
cod_artera
denumire
cod_uat
DOCUMENT_IDENTITATE
serie
numar
cnp
data_emitere
data_expirare
tip
cod_emitent
data_anulare
fotografie GHISEU_UNIC
cod_ghiseu
denumire
cod_uat
PASAPORT_SIMPLU
numar
cnp
data_emitere
data_expirare
tip
cod_emitent
data_anulare
fotografie PERSOANA_H
cnp
nume
prenume
pren_tata
pren_mama
DOCUMENT_IDENTITATE_H
serie
numar
cnp
data_emitere
data_expirare
tip
cod_emitent
data_anulare
fotografie
CERERE_PASS
cod_cerere
cod_ghiseu
cnp
data_cerere
data_solutionare
data_respingere CERERE_DOC
cod_cerere
cod_ghiseu
cnp
data_cerere
data_solutionare
data_respingere PASAPORT_SIMPLU_H
numar
cnp
data_emitere
data_expirare
tip
cod_emitent data_anulare
fotografie
DOMICILIU_PERSOANA
cnp
cod_domiciliu
data_start
data_stop
DOMICILIU_PERSOANA_H
cnp
cod_domiciliu OPERATORI
cod_op
nume_op
parola
drepturi
status
data_start
data_stop
cod_ghiseu
detalii
37
II.7. Crearea tabelelor
Sintaxa comenzii de creare a unei tabele (2) este următoarea:
CREATE TABLE [schema.]nume_tabela (nume_coloana_1 tip_coloana_1
[DEFAULT expresie_1],
nume_coloana_2 tip_coloana_2 [DEFAULT expresie_2],
. . .
nume_coloana_n tip_coloana_n [DEFAULT expresie_n]);
Această comandă trebuie particularizată pentru fiecare ta belă în parte și apoi rulată pentru
crearea acesteia .
II 8. Tipurile de constrângeri definite
Chei primare
1. tabela UAT: CONSTRAINT pk_uat PRIMARY KEY ( cod_uat );
2. tabela artere _circulatie : CONSTRAINT pk_artere_circulatie PRIMARY KEY (cod_artera);
3. tabela domiciliu : CONSTRAINT pk_domiciliu PRIMARY KEY (cod_domiciliu);
4. tabela ghiseu _unic: CONSTRAINT pk_ghiseu_unic PRIMARY KEY (cod_ghiseu);
5. tabela operatori : CONSTRAINT pk_operatori PRIMARY KEY (cod_op );
6. tabela persoana : CONSTRAINT pk_persoana PRIMARY KEY (cnp);
7. tabela certificate : CONSTRAINT pk_certificate PRIMARY KEY (serie,numar) ;
8. tabela domiciliu_persoana : CONSTRAINT pk_dom_pers PRIMARY KEY (cnp, cod_domiciliu) ;
9. tabela document_identitate : CONSTRAINT pk_doc_id PRIMARY KEY (serie,numar) ;
10. tabela docu ment_identitate_h : CONSTRAINT pk_doc_id_h PRIMARY KEY (serie,numar) ;
11. tabela pasaport_simplu : CONSTRAINT pk_pasaport_simplu PRIMARY KEY (numar );
12. tabela pasaport_simplu_h : CONSTRAINT pk_pasaport_simplu_h PRIMARY KEY (numar );
13. tabela cerere_doc : CONSTRAINT pk _cerere_doc PRIMARY KEY ( cod_cerere );
14. tabela cerere_pass : CONSTRAINT pk_cerere_pass PRIMARY KEY ( cod_cerere );
Chei străine
1. tabela artere_circulatie : CONSTRAINT fk_uat foreign key(cod_uat) REFERENCES UAT (cod_uat) ;
2. tabela domiciliu : CONSTRAINT fk_dom_uat foreign key(cod_uat) REFERENCES UAT(cod_uat);
3. tabela domiciliu : CONSTRAINT fk_art_c foreign key(cod_artera) REFERENCES UAT(cod_artera);
4. tabela ghiseu_unic : CONSTRAINT fk_g_u_uat foreign key(cod_uat) REFERENCES
UAT(cod_uat);
38
5. tabela operatori : CONSTRAINT fk _op_g_u foreign key(cod_uat) REFERENCES GHISEU_UNIC
(cod_ghiseu);
6. tabela persoana : CONSTRAINT fk_pers_uat_nast foreign key(cod_uat_nastere) REFERENCES
UAT(cod_uat);
7. tabela persoana_h : CONSTRAINT fk_pers_h foreign key(cnp) REFERENCES PERSOANA(cnp);
8. tabela certificate : CONSTRAINT fk_cert_pers foreign key(cnp) REFERENCES PERSOANA(cnp);
9. tabela certificate : CONSTRAINT fk_cert_uat foreign key(cod_uat) REFERENCES UAT(cod_uat);
10. tabela domiciliu_persoana : CONSTRAINT fk_dom_pers_dom foreign key(cod_domiciliu)
REFERENCES DOMICILIU(cod_domiciliu);
11. tabela domiciliu_persoana : CONSTRAINT fk_dom_pers_pers foreign key(cnp) REFERENCES
PERSOANA(cnp);
12. tabela domiciliu_persoana_h : CONSTRAINT fk_dom_pers_h_pers foreign key(cnp)
REFERENCES PERS OANA(cnp);
13. tabela domiciliu_persoana_h : CONSTRAINT fk_dom_pers_h__dom foreign key(cod_domiciliu)
REFERENCES DOMICILIU(cod_domiciliu);
14. tabela document_identitate : CONSTRAINT fk_doc_id_pers foreign key(cnp) REFERENCES
PERSOANA(cnp);
15. tabela document_identi tate: CONSTRAINT fk_doc_id_ghiseu_unic foreign key(cod_emitent)
REFERENCES GHISEU_UNIC(cod_ghiseu);
16. tabela document_identitate_h : CONSTRAINT fk_doc_id_h_pers foreign key(cnp) REFERENCES
PERSOANA(cnp);
17. tabela document_identitate_h : CONSTRAINT fk_doc_id_h _ghiseu_unic foreign key(cod_emitent)
REFERENCES GHISEU_UNIC(cod_ghiseu);
18. tabela pasaport_simplu : CONSTRAINT fk_pass_s_pers foreign key(cnp) REFERENCES
PERSOANA(cnp);
19. tabela pasaport_simplu : CONSTRAINT fk_pass_s_ghiseu_unic foreign key(cod_emitent)
REFERENCES GHISEU_UNIC(cod_ghiseu);
20. tabela pasaport_simplu_h : CONSTRAINT fk_pass_s_h_pers foreign key(cnp) REFERENCES
PERSOANA(cnp);
21. tabela pasaport_simplu_h : CONSTRAINT fk_pass_s_h_ ghiseu_unic foreign key(cod_emitent)
REFERENCES GHISEU_UNIC(cod_ghiseu);
22. tabela cerere_doc : CONSTRAINT fk_c_doc_g hiseu foreign key(cod_ghiseu) REFERENCES
GHISEU_UNIC(cod_ghiseu);
23. tabela cerere_doc : CONSTRAINT fk_c_doc_pers foreign key(c np) REFERENCES
PERSOANA (cnp);
39
24. tabela cerere_pass : CONSTRAINT fk_c _p_ghiseu foreign key(cod_ghiseu) REFERENCES
GHISEU_UNIC(cod_ghiseu);
25. tabela cerere_pass : CONSTRAINT fk_c _p_pers foreign key(cnp) REFERENCES
PERSOANA(cnp);
Chei de verificare
1. tabela UAT: CONSTRAINT ck_tip_uat CHECK (tip in ( ’RURAL’,’URBAN’ ));
2. tabela operatori : CONSTRAINT ck_dr CHECK (drepturi in ( 'DI', 'PS', 'DP', 'V', 'N', 'AD'));
3. tabela operatori : CONSTRAINT ck_status CHECK (status in ( ‘A’,’R’));
4. tabela persoana : CONSTRAINT ck_sex CHECK (sex in ( 'F', 'B'));
5. tabela persoana : CONSTRAINT ck_cet CHECK (cetatenie in ('ROMÂNĂ '));
6. tabela certificate : CONSTRAINT ck_tip_c CHECK (tip in ( 'CC', 'CN'));
7. tabela document_identitate : CONSTRAINT ck_tip_doc CHECK (tip in ( 'CI', 'CIP', 'CIE'));
8. tabela document_identitate_h : CONSTRAINT ck_tip_doc_h CHECK (tip in ( 'CI', 'CIP', 'CIE'));
9. tabela pasaport_simplu : CONSTRAINT ck_pass CHECK (tip in ( 'PE','PT'));
10. tabela pasaport_simplu_h : CONSTRAINT ck_pass CHECK (tip in ( 'PE','PT'));
40
III. Auditarea
Auditarea (2) presupune monitorizarea și înregistrarea selectivă a acț iunilor utilizatorilor unei
baze de date. Procesul de a uditare este folosit pentru a investiga activit ăți suspecte, cum ar fi ștergeri
din tabele de către un utilizator neaut orizat , caz în care administrato rul de securitate trebuie să verifice
toate conexi unile la baza de date ș i operațiile de ș tergere a liniilor din tabelele bazei de date pentru a –
l identifica.
De asemenea, procesul de auditare este folosit pentru a monitoriza și grupa datele pe categorii
de activităț i specifice î n cadrul bazei de date , astfel că administratorul bazei de date trebuie să
colecteze statistici despre tabele le care au fost modificate, numărul de operaț ii I/O executate, durata
medie a unei sesiuni, privilegiile sistem folosite, num ărul de utilizatori care s -au conectat simult an la
diferite intervale de timp etc.
III.1. Opțiuni de audit. Exemple
Controlul acțiunilor î ntreprinse asupra elementelor unei baze de date este realizat prin
comanda AUDIT , iar rezultatele verificărilor sunt înregistrate î ntr-un tab el, AUD$ , al dicț ionarului
datelor, cunoscut sub denumirea de audit trail. Pentru a preveni completarea totală a spaț iului tabel
asociat, periodic se șterg înregistră ri din tabelul AUD$. Se recomandă ca tabelul AUD$ să nu aparțină
spațiului tabel SYSTEM . De asem enea, acesta trebuie protejat î mpotriva accesului neautorizat.
Sintaxa simplificată a comenzii AUDIT este urmă toarea:
AUDIT {comanda_SQL [, comanda SQL … ]
| privilegiu_sistem, [, privilegiu_sistem… ]
[BY utilizator ]
| ON [nume_schema. ]obiect }
[BY {SESSION l ACCESS }]
[WHENEVER [NOT ]SUCCESFUL ];
Sistemul Oracle suportă trei tipuri genera le de audit, la nivel de comandă , privilegiu sa u obiect
ale unei scheme. Operaț iile de audit pot fi definite la nivel de sesiune sau acces. Pentru a dezactiva
optiunile de audit inițiate printr -o comandă AUDIT , se utilizeaz ă comanda NOAUDIT asupra acelor
opțiuni.
Auditul la nivel de comandă se referă la verifică ri selective asupra comenzilor SQL, care se
găsesc în una dintre următoarele două categorii:
41
1. comenzi LDD relative la un anumit obiect al schemei (de exemplu, AUDIT TABLE verifică
toate comenzile CREATE și DROP TABLE );
2. comenzi LMD referitoare la anu mite obiecte ale schemei, dar fără să se specifice numele
acestora (de exemplu, AUDIT SELECT TABLE controlează toate operaț iile SELECT
asupra tabelelor și vizualiză rilor).
Sistemul Oracle permite verificarea selectivă a execuț iilor comenzilor SQL. Execuțiile eșuate
se pot verifica doar dacă structura SQL este validă, iar eșuarea s -a produs din ca uza referirii unui
obiect inexi stent sau a lipsei unei autoriză ri adecvate. Comenzile care eșuează pentru c ă nu au fost
valide, nu pot fi verificate.
Pentru verificarea exclusivă a execuțiilor cu succes se utilizează clauza WHENEVER
SUCCESSFUL a comenzii AUDIT , iar pentru a verifica doar execuțiil e eșuate, clauza WHENEVER
NOT SUCCESSFUL a aceleiași comenzi. Dacă nu este folosită nici una dintre clauzele menț ionate
mai sus, verificarea se realizează î n ambele cazuri.
Auditu l la nivel de privilegii asigură verificarea se lectivă a comenzilor care necesită privilegii
sistem. De exe mplu, verificarea privilegiului sistem SELECT ANY TABLE permite monitori zarea
comenzilor care se execută folosind acest privilegiu.
Privilegiile asupra obiect elor sunt verificat e înaintea privil egiilor sis tem. Dacă sunt setate
opțiuni de audit pentru comenzi ș i privilegi i similare, atunci este generată o singură î nregistrar e pentru
audit. De exemplu, dacă comanda CREATE TABLE și privilegiul sistem CREATE TABLE sunt ambele
verificate, atunci se ge nerează o singura î nregi strare de audit, de fiecare dată când este creat un tabel.
Auditul la n ivel de obiect al schemei constă î n verificarea comenzilor LMD specifice ș i a
comenzilor GRANT sau REVOKE pentru obiectele schemei.
Se pot verifica acele comenzi care ref eră tabele, vizualizări, secvenț e, proceduri stocate,
funcții, pachete. Procedurile din pachete nu pot fi verificate individual. De aseme nea, comenzile care
referă grupări, indecș i sau sinonime, nu pot fi verificate direct. Totuș i, se poate verifica accesul la
aceste obiecte î n mod indirect, prin ver ificarea operațiilor care afectează tabelul de bază .
Exemplu:
Se consideră următoarea secvență SQL:
AUDIT SELECT ON persoana;
CREATE VIEW pers_doc_id AS
SELECT a.cnp, nume, prenume
FROM persoana a, document_identitate b
WHERE a.cnp = b.cnp;
42
AUDIT SELECT ON persoana SELECT * FROM pers_doc_id;
Urmare a interogării vizualiză rii pers_doc_id sunt generate două înregistrări de auditare,
corespunzătoare interogării vizualiză rii pers_doc_id , res pectiv tabelului de bază persoana .
Interogarea tabelului de bază document_identit ate nu generează înregistră ri de verificare, deoarece
pentru acest tabel nu este activată opț iunea de AUDIT SELECT .
Opțiunile de audit pot fi specificate la nivel de sesiune sau acces, folosind clauzele BY
SESSION, respectiv BY ACCESS ale comenzii AUDIT.
Auditarea la nivel de sesiune are ca r ezultat inserarea unei singure înregistrări î n tabelul AUD$
pentru fiecare utiliz ator și obiect al schemei, î n timpul sesiunii care include o acț iune auditat ă.
Acțiunea de audit la nivel de acces presupune inserarea unei înregistrări î n tabelul AUD$
pentru fiecare execuție a unei operații care este monitorizată. Operaț iile de audit la nivel de comenzi
sau de privilegii, aplicate pentru comenzi LDD nu pot fi p recizate decâ t la nivel de acces.
Opțiunile de audit la nivel de comenzi sau privi legii permit ca monitorizarea să se realizeze
pentru un anumit utilizator sau pentru un grup de ut ilizatori. Prin utilizarea operaț iei de audit asupra
unui grup de utilizator i se poate minimiza numărul de î nregistră ri din tableul AUD$.
Exemplu: se dispun e auditarea comenzii SELECT TABLE folosite de utilizatorii oper_1,
oper_2 și oper_3 :
AUDIT SELECT TABLE BY oper_1, oper_2 , oper_3 ;
Triggeri pentru auditare
Un declan șator (trigger ) este un bloc PL/SQL (3) sau apelul CALL al unei proceduri PL/SQL
care se execută automat ori de că te ori are loc un anumit eveniment declan șator. Triggerii sunt de
două tipuri: la nivelul bazei de date și la nivel de aplica ție. În acest material, obiectul de interes este
categoria triggerilor la nivelul bazei de date.
Triggerii la nivelul bazei de date se clasifică la rândul lor în trei categorii:
1. triggeri LMD – pot fi executați o singură dată la nivelul unei comenzi LMD pe o tabelă,
indiferent de numărul de înregistră ri afectate sau pot fi executați FOR EVERY ROW .
Acestora le corespund tipurile de triggeri BEFORE STATEMENT , AFTER STATEMENT,
BEFORE EACH ROW, AF TER EACH ROW ;
2. triggeri INSTEAD OF – declan șați de comenzi LMD pe o vizualizare;
43
3. triggeri SYSTEM – declanșa ti de evenimente precum pornirea sau oprire a bazei de date,
comenzi LDD , conectare/deconectare utilizator. Acestora l e corespund tipurile de triggeri
AFTER EVENT, BEFORE EVENT .
Interogarea tabelei SYS.TRIGGER$ sau a vizualiză rii ALL_TRIGGERS oferă informa ții despre
toți trigge rii de la nivelul bazei de date:
SELECT DISTINCT trigger_type FROM all_triggers ;
Pentru auditare, putem crea triggeri personaliza ți care să înregistreze anumite informa tii de
interes. În general, vom crea o tabelă specială pentru stocarea informa țiilor monitorizate.
Triggerii construiț i de noi se reg ăsesc la interogarea tabelului TRIGGER$ și a view-urilor
ALL_TRIGGERS, USER_TRIGGERS .
Astfe l, în auditare , sunt adecva ți în special triggerii LMD la nivel de instruc țiune, având în
vedere următoarele aspecte referitoare la procesare a triggerilor :
1. triggerii construi ți nu trebuie să influen țeze activitatea normală din baza de date , scopul
auditului este s ă monitorizeze pasiv și să înregistreze activitatea pentru analiz a ulterioară .
Prin urmare NU vom defini triggeri INSTEAD OF care s ă deturneze rezultatele din tabelele
vizate c ătre tabela de audit ;
2. triggerii LMD la nivel de instruc țiune ș i la nivel de înregistrare pot coexista. Vor fi apela ti:
Trigger BEFORE instruc țiune
Pentru fiecare înregistrate afectată
Trigger BEFORE înregistrare
Opera ție LMD propriu -zisă
Trigger AFTER înregistrare
Trigger AFTER instruc țiune
3. Triggerii defini ți de utilizatori vor fi executa ți doar dacă din punct ul de vedere a sistemului
Oracle instruc țiunea este corectă ș i poate avea loc. Pentru o instruc țiune LMD greșit
construită sau care încalc ă unele constrângeri , nu se va ajunge până la triggerul definit de
utiliz ator, ci eroarea va fi returnată î nainte.
În exemplu de mai jos (8), creăm doi trigger i care înregistrează în tabela de audit
TAB_AUDIT_PASAPORT , informații despre opera tiile LMD de ștergere pe tabela
PASAPORT_SIMPLU și numărul de înregistr ări afectate pe aceasta:
drop table tab_audit_pasaport;
create table tab_audit_pasaport (
id_secv number(4) primary key, utilizator varchar2(20), sesiune number(10), host
varchar2(100), timp date, delta_inreg number(5,2));
44
drop s equence secv_aud_pasaport;
create sequence secv_aud_pasaport start with 1 increment by 1;
create or replace trigger auditare_pasaport_before
before delete on pasaport_simplu
declare
st number;
sir varchar2(200);
begin
selec t count(*) into st from pasaport_simplu;
select substr(sys_context('userenv', 'current_sql'), 1, 200) into sir from dual;
dbms_output.put_line('Before: ' || st);
dbms_output.put_line('Current sql: ' || sir);
insert into tab_audit_pasaport values(secv_au d_pasaport .nextval,
sys_context('userenv', 'session_user'), sys_context('userenv', 'sessionid'),
sys_context('userenv', 'host'),sysdate, st);
end;
/
create or replace trigger auditare_pasapor t_after
after delete on pasaport_simplu
declare
st number;
st_vechi number;
sesiune_actuala varchar2(100);
id_vechi number;
begin
select count(*) into st from pasaport_simplu;
select sys_context('userenv', 'sessionid') into sesiune_actuala from dual;
select max(id_secv) into id_vechi from tab_audit_pasaport
where sesiune=sesiune_actuala;
select delta_inreg into st_vechi from tab_audit_pasaport
where sesiune=sesiune_actuala and id_secv=id_vechi;
dbms_output.put_line('AFTER: ' || st);
update tab_audit_ pasaport set delta_inreg = st_vechi – st
where sesiune = sesiune_actuala and id_secv = id_vechi;
end;
/
III.2. Mecanisme pentru audit
Înregistrarea informaț iilor (2) pentru audit poate fi activată sau dezactivată. În situația în care
opțiunea de auditare este activă, atunci se permite oricărui utilizator autorizat să specifice opțiuni
pentru audit, rezervâ nd administratorului de securitate dreptul de control asupra înregistrării
informaț iilor de audit.
Informațiile de audit conț in nume le contului, identificator ul sesiunii, identificatorul maș inii
client, numele schemei de obiecte care a fost accesată, operațiile executate sau inițiate, codul rezultat
în urma compilării operaț iei, privilegiile sistem folosite etc.
Activarea sau dezactiva rea operațiilor de audit pentru o instanță se realizează prin parametrul
de initializare AUDIT_TRAIL . Acest parametru poate a vea una din urmatoarele valori:
45
1. TRUE sau DB (se activează operațiile de audit și informațiile despre acestea sunt
înregistrate î n tabelul AUD$ al bazei de date);
2. OS (se activează operațiile de audit și informaț iile despre acestea sunt înregistrate î n tabelul
audit trail al sistemului de operare);
3. FALSE sau NONE (se dezactivează operaț iile de audit).
Atunci când opțiunea de audit devine activă se generează verificări asupra înregistrărilor pe
durata derulării fazelor de execuț ie a comenzilor. Comenzile SQL din interiorul unităț ilor de program
PL/SQL sunt verificate individual.
Chiar dacă auditul bazei de date nu este activat, siste mul Oracle înregistrează întotdeauna î n
tabelul audit trail al sistemului de operare, informații despre următoarele acțiuni care au loc asupra
bazei:
1. pornirea instanț ei: utilizatorul care a pornit instanța, identificatorul maș inii client , data și
momentul de timp, etc. ;
2. oprirea instanț ei: utilizatorul care a închis instanța, identificatorul maș inii client , data și
momentul de timp, etc. ;
3. sesiunile utilizatorilor cu privilegii de administrare.
Opțiunile de audit la nivel de comenzi SQL sau privilegii au efec t pe timpul conexiunii unui
utilizator la baza de date , pe toat ă durata sesiunii . Schimbările opț iunilo r de audit la nivel de comenzi
și privilegii nu afectează sesiu nea curentă. Modifică rile au efect numai asupra noilor sesiuni inițiate.
În schimb, modifi cările opțiunilor de audit la nivel de obiecte ale schemei au efect imediat, inclusiv
pentru sesiunea curentă .
Operaț ia de audit a baz ei de date nu permite monitoriză ri la nivel de coloană . În situația în care
acest lucru este necesar, se pot folosi rutine speciale pentru auditare : proceduri stocate, declanșatori .
Baza de date permite mecani sme de audit integrate, astfel încât monitoriză rile pot fi realizate automa t,
fără intervenț ia utilizatorilor.
Începând cu versiunea Oracle9i , Compania Oracle oferă procedee de auditare granulară, fine-
grained auditing , prin care se permite monitorizarea accesului la date. Administratorul de securitate
poate utiliza pachetul DBMS_FGA cu scopul de a crea politici de audit pent ru un anumit tabel.
În situația în care fiecare l inie returnată de o interogare î ndeplinește condițiile de audit, atunci
se înregistrează î n tabelul AUD$ un eveniment de audit care include username -ul, codul SQL,
variabilele de legatură , identificatorul se siunii, momentul de timp etc.
46
Opțional , admi nistratorii de securitate pot defini modalități de prelucrare ș i procesare a
evenimentelor de audit. Astfel , la prelucrarea unui eveniment de audit se pot trimite mesaje de
avertizare administratorului de securitate , informaț iile relevante fiind livrate printr -un mecan ism
asemănă tor de clanș atorilor.
III.3. Informații despre audit
Informaț iile despre opțiunile de audit și evenimentele de audit înregistrate se pot obține
consultând dicț ionarul datel or. Dint re cele mai importante vizualiză ri referitoare la auditul bazei de
date, se remarcă :
1. ALL_DEF_AUDIT_OPTS – opțiunile implicite pentru audit;
2. DBA_STMT_AUDIT_OPTS – opțiunile de audit la nivel de comandă ;
3. DBA_PRIV_AUDIT_OPTS – opțiunile de audit la nivel de privilegiu ;
4. DBA_OBJ_AUDIT_OPTS – opțiunile de audit la nivel de obiect ;
5. DBA_AUDIT_TRAIL – toate înregistră rile de audit trail ;
6. DBA_AUDI T_OBJECT – înregistră rile de audit trail referitoare la obiectele schemei ;
7. DBA_AUDIT_SESSION – înregistră rile di n audit trail pentru operaț iile de audit la nivel
de sesiune ;
8. DBA_AUDIT_STATEMENT – înregistă rile de audit t rail referitoare la comenzi.
47
IV. Elemente de securitate
IV.1. Criptarea datelor
Principala abordare a protejării datelor este criptarea lor (2), lucru util atât în cazul în care
informația este stocată pe disc, cât și atunci când informația este transmisă într -o rețea. Datele criptate
pot fi decriptate numai de utilizatorii autorizați.
La nivelul SGBD această facilitate poa te îmbrăca două forme:
existența unor rutine speciale care realizează criptarea datelor la cerere sau automat;
existența unor instrumente care permit utilizatorului să -și realizeze propriile rutine de
criptare.
Procesul efectiv de criptare presupune utili zarea unui sistem de cifrare, ale cărui componente
sunt:
Algoritmul de criptare – realizează transformarea datelor din forma inițială în forma
criptată (cifrată);
Cheia de criptare – valoare ce constituie o intrare a algoritmului de criptare, aleasă
dintr -o mulțime de chei posibile;
Algoritmul de decriptare – realizează transformarea datelor din forma criptată în forma
inițială;
Cheia de decriptare – valoare ce constituie o intrare a algoritmului de decriptare.
Sistemul O racle suportă algoritmi de cri ptare :
simetrici – pentru criptarea datelor stocate , aceștia folosesc aceeași cheie pentru
criptarea datelor și pentru decriptarea lor ;
asimetrici – pentru autentificare a utilizatorilor bazei de date ș i pentru comunica ția între
client ș i baza de date. În cadrul acestor algoritmi, receptorul generează 2 chei: o cheie
privată ce va fi folosită de el pentru decriptare și o cheie publică pe care o trimite
emitentului pentru a cripta mesajul .
Următorii a lgoritmi simetrici de criptare sunt disponibili și î n sistemul Oracle:
DES (Data Encryption Standard) . Sistemul DES criptează un bloc de text clar de 64
biti într-un text criptat tot de 64 biti, utilizând 56 bit i dintr -o cheie de 64 biti;
3-DES (Triple Data Encryption Standard) . Are la bază formula :
48
c = DES k3(DES−1k2 (DES k1(m))) î n varianta 3DES -ede
sau formula c = DES k3(DES k2 (DES k1(m))) î n varianta 3DES -eee
unde k1, k2, k3 sunt chei de 56 bit i (folosind astfel împreună 168 bi ți dintr -o cheie de
192 biți solicitată ), DES k este criptarea DES cu cheie k, DES-1k este criptarea DES cu
cheie k, m este blocul de 64 de biti original. Dacă k1=k2 sau k2=k3 sau k1=k2=k3,
varianta 3DES devine DES.
AES (Advanced Encryption Standard) . Sistemul AES criptează un bloc de text clar de
128 biți într-un text criptat tot de 12 8 biți, utilizând o cheie de 128, 192 sau 256 bi ți.
Exemplu (3): datele de autentificare ale operatorilor ghișeelor unice (cod_op, nume_op și
parola din tabela OPERATORI ) vor fi criptate ( AES-128, PAD_PKCS5, CHAIN_CBC ) și stocate în
tabela OPERATORI_CRIPT , astfel: înregistrările impare (1,3,…) vor fi criptate cu cheia
CHEIE_IMPAR , iar înregistrările pare (2,4,…) vor fi criptate cu cheia CHEIE_PAR .
Cele două chei vor fi generate automat și stocate în baza de date. Se vor crea secven ța
SECV_IDCHEIE și tabela TABELA_CHEI (idcheie#, cheie, tabela). Procedura
CRIPTARE_PAR_IMPAR fără parametri va gener a în mod automat două chei private CHEIE_IMPAR
și CHEIE_PAR pe câte 16 bytes fiecare , care se vor stoca în tabela TABELA_CHEI , cu cheie primar ă
din secven ța SECV_IDCHEIE .
DROP sequence secv_idcheie;
create sequence secv_idcheie increment by 1 start with 1;
drop table tabel_chei;
create table tabel_chei (idcheie number primary key, cheie raw(16) not null, tabel varchar2(30) not null);
drop table operatori_cr ipt;
create table operatori_cript (cod_op_cript varchar2(100) primary key, nume_op_cript varchar2(100),
parola_cript varchar2(100));
create or replace procedure criptare_par_impar
as
cheie_impar raw(16);
cheie_par raw(16);
cursor c is select cod_op,nume_op, parola from operatori;
raw_cod_op raw(100);
raw_nume_op raw(100);
raw_parola raw(100);
mod_operare number;
rezultat_cod_op raw(100);
rezultat_nume_op raw(100);
rezultat_par ola raw(100);
contor number :=1;
begin
cheie_impar := dbms_crypto.randombytes(16);
cheie_par := dbms_crypto.randombytes(16);
dbms_output.put_line('Cheie impar: ' || cheie_impar);
dbms_output.put_line('Cheie par: ' || cheie_par);
insert into tabel_chei values(secv_idcheie.nextval, cheie_impar, 'OPERATORI');
49
insert into tabel_chei values(secv_idcheie.nextval, cheie_par, 'OPERATORI');
mod_operare := dbms_crypto.encrypt_aes128 + dbms_crypto.pad_pk cs5 + dbms_crypto.chain_cbc;
for l in c loop
raw_cod_op := utl_i18n.string_to_raw(to_char(l.cod_op), 'AL32UTF8');
raw_nume_op := utl_i18n.string_to_raw(to_char(l.nume_op), 'AL32UTF8');
raw_parola := utl_i18n.string_to_raw(to_char(l.parola), 'AL32UTF8');
if (mod(contor, 2) = 1)then
rezultat_cod_op := dbms_crypto.encrypt(raw_cod_op, mod_operare, cheie_impar);
rezultat_nume_op := dbms_crypto.encrypt(raw_nume_op, mod_operare, cheie_impar);
rezultat_parola := dbms_crypto.encrypt(raw_parola, mod_operare, cheie_impar);
insert into operatori_cript values(rawtohex(rezultat_cod_op), rawtohex(rezul tat_nume_op),
rawtohex(rezultat_parola));
contor := contor + 1;
else
rezultat_cod_op := dbms_crypto.encrypt(raw_cod_op, mod_operare, cheie_par);
rezultat_nume_op := dbms_crypto.encrypt(raw_nume_op, mod _operare, cheie_par);
rezultat_parola := dbms_crypto.encrypt(raw_parola, mod_operare, cheie_par);
insert into operatori_cript values(rawtohex(rezultat_cod_op), rawtohex(rezultat_nume_op),
rawtohex(rezultat_parola));
contor := contor + 1;
end if;
end loop;
commit;
end;
/
execute criptare_par_impar;
select * from tabel_chei;
select * from operatori_cript;
IV.2. SQL Injection
SQL Injection (2) este una dintre cele mai periculoase vulnerabilități, cu efecte devastatoare
asupra activități lor de orice natură , deoarece conduce la expunerea informațiilor sensibile stocate în
baza de date a unei aplicații. Această vulnerabilitate apare atunci când este oferită unui atacator
posibilitatea de a influența cererile SQL pe care o aplicație le transferă unei baze de date back -end.
SQL Injection este un atac în care codul SQL este inserat sau adăugat în parametrii aplicației
sau ai utilizatorului, care sunt ulterior transmiși server -ului SQL pentru parsare și execuție. Orice
procedură care construiește instrucțiuni SQL poate fi vulnerabilă.
Forma primară de SQL Injection constă î n inserarea directă de cod în parametrii care sunt
concatenați cu comenzile SQL și executarea acestor comenzi.
Un ata c mai puțin direct injectează cod în șiruri de caractere care sunt destinate stocării într –
un tabel sau ca metadate. Când șirurile de caractere stocate sunt concatenate într -o comandă SQL
dinamică, acest cod este executat. Atunci când o aplicație Web eșuea ză să „curețe” în mod adecvat
parametrii care sunt transmiși instrucțiunilor SQL create dinamic, este posibil ca un atacator să
modifice construirea instrucțiunilor SQL din back -end.
50
În situația în care un atacator este capabil să modifice o instrucțiune SQL, este posibil ca
aceasta să fie executată cu aceleași drepturi ca ale utilizatorului aplicației. Atunci când este utilizat
serverul SQL pentru a executa comenzile care interacționează cu sistemul de operare, procesul se va
executa cu aceleași drepturi ca ale componentei care a executat comanda și care, de obicei, are drepturi
puternice.
Un exemplu tipic este o cerere care în clauza WHERE foloseste valori primite la runtime.
De cele mai multe ori ținta atacurilor de SQL I njection sunt formularele de login neprotejate
la astfel de atacuri. De exemplu, p entru a putea evita astfel de atacuri , utilizatorul FORMS_USER
adaugă la tabela OPERATOR o coloană care va stoca parolele în forma criptată:
alter table operatori add parola_cript varchar2(32);
Pentru testare, populăm cu dummy data acest câmp, folosind cunoștintele despre criptare:
grant all on dbms_crypto to forms_user;
De asemenea, creă m funcția pentru criptare:
create or replace FUNCTION criptare1(pass IN VARCHAR2) RETURN VARCHAR2 AS
raw_sir RAW(20);
raw_parola RAW(20);
rezultat RAW(20);
parola VARCHAR2(20) := '12345678';
mod_operare NUMBER;
textcriptat VARCHAR2(32);
BEGIN
raw_sir:=utl_i18n.string_to_raw(pass,'AL32UTF8');
raw_parola :=utl_i18n.string_to_raw(parola,'AL32UTF8');
mod_operare := DBMS_CRYPTO.ENCRYPT_DES +
DBMS_CRYPTO.PAD_ZERO + DBMS_CRYPTO.CHAIN_ECB;
rezultat := DBMS_CRYPTO.ENCRYPT(raw_sir,mod_operare,raw_parola);
textcriptat := RAWTOHEX (rezultat);
RETURN textcriptat;
END;
/
În continuare, administratorul Aplicației de Gestiune a Documentelor de Identitate ale
Persoanelor actualizează parolele din tabela operatori :
update operatori set parola_cript=criptare1('parola1') where cod_op=10000;
update operatori set parola_cript=criptare1('parola2') where cod_op=10001;
Presupunem că butonului de „ LOGIN ” de pe formular îi corespunde o procedur ă stocat ă creat ă
de administratorul Aplicației de Gestiune a Documentelor de Identitate ale Persoanelor , care are ca
scop verificarea dac ă exist ă potrivire între numele de utilizator și parola introduse prin formular .
Această procedură va avea următorul cod :
51
CREATE OR REPLACE PROCEDURE VERIFICA_LOGIN (P_NUMEUSER VARCHAR2,
P_PAROLA VARCHAR2) AS
v_ok NUMBER(2) := -1;
BEGIN
EXECUTE IMMEDIATE 'select count(*) from operatori where
nume_op='''||P_NUMEUSER||''' and parola_cript = criptare1('''||P_PAROLA||''')' into v_ok;
dbms_output.put_line('select count(*) from operatori where
nume_op='''||P_NUMEUSER||''' and parola=criptare1('''||P_PAROLA||''')');
IF v_ok=0 THEN
DBMS_OUTPUT.PUT_LI NE('Verificarea a eșuat');
ELSE
DBMS_OUTPUT.PUT_LINE('Verificarea a reușit');
END IF;
END;
/
Prin apelul acestei proceduri s -ar putea întâmpla atacuri mali țioase cu parametrii r ău
intenț ionați:
1. EXEC VERIFICA_LOGIN('Vasilescu','Vasilescu1234');
select count(*) from operatori where nume_op='Vasilescu' and parola_cript =
'C73F3D2F0B2155A088ACC351F8D9EE2A';
'Verificarea a reușit'
2. EXEC VERIFICA_LOGIN('Vasilescu','Vasilescu1111');
select count(*) from operatori where nume_op='Vasilescu' and parola_cript =
C73F3D2F0B2155A03F76181FB9A644AC;
'Verificarea a eșuat'
3. EXEC VERIFICA_LOGIN('Vasilescu ''–','Vasilescu1234');
select count(*) from operatori where nume_op='Vasilescu' –' and parola_cript =
'C73F3D2F0B2155A088ACC351F8D9EE2A';
'Verificarea a reușit'
4. EXEC VERIFICA_LOGIN('GHISEU_UNIC '' OR 1=1 –','DOCUMENT');
select count(*) from operatori where nume_op=' GHISEU_UNIC' OR 1=1 –' and
parola_cript = '2129F1C9002B3E6A';
'Verificarea a reușit'
Prin ad ăugarea apostrof urilor și a celor două liniuțe se inhib ă drept comentariu partea de parol ă
din cererea Select . Mai mul t, clauza OR permite în acest caz anularea și a testului de existen ță a
numelui de utilizator în tabel ă.
În scopul p rotecției de astfel de atacuri , se procedează la înlocuirea concaten ării din șirul ce
reprezint ă comanda SQL cu variabile legate – bind variables . Astfel, procedura VERIFICA_LOGIN ,
va avea următorul conținut:
CREATE OR REPLACE PROCEDURE VERIFICA_LOGIN_SAFE (P_NUMEUSER
VARCHAR2, P_PAROLA VARCHAR2) AS
v_ok NUMBER(2) := -1;
BEGIN
52
select count(*) into v_ok from utilizator where nume_op=P_NUMEUSER and parola =
criptare1(P_PAROLA);
IF v_ok=0 THEN
DBMS_OUTPUT.PUT_LINE('Verificarea a eșuat');
ELSE
DBMS_OUTPUT.PUT_LINE('Verificarea a reușit');
END IF;
END;
/
La apel, acum se furnizeaz ă parametrii dup ă cum urmeaz ă:
1. ACCEPT NUME PROMPT 'NUME OPERATOR:'
'NUME OPERATOR:Vasilescu
ACCEPT PAROL PROMPT 'PAROLA OPERATOR:'
'PAROLA OPERATOR:Vasilescu1234
EXEC VERIFICA_LOGIN_SAFE ('&NUME','&PAROL');
Verificarea a reușit
2. ACCEPT NUME PROMPT 'NUME OPERATOR:'
'NUME OPERATOR:Vasilescu
ACCEPT PAROL PROMPT 'PAROLA OPERATOR:'
'PAROLA OPERATOR:Vasilescu11111
EXEC VERIFICA_LOGIN_SAFE ('&NUME','&PAROL');
Verificarea a eșuat
3. ACCEPT NUME PROMPT 'NUME OPERATOR:'
'NUME OPERATOR:Vasilescu'' –
ACCEPT PAROL PROMPT 'PAROLA OPERATOR:'
'PAROLA OPERATOR:Vasilescu11111
EXEC VERIFICA_LOGIN_SAFE ('&NUME','&PAROL');
Verificarea a eșuat
4. ACCEPT NUME PROMPT 'NUME OPERATOR:'
'NUME OPERATOR: 'GHISEU_UNIC '' OR 1=1 –
ACCEPT PAROL PROMPT 'PAROLA OPERATOR:'
'PAROLA OPERATOR:Vasilescu11111
EXEC VERIFICA_LOGIN_SAFE ('&NUME','&PAROL');
Verificarea a eșuat
53
V. Implementarea aplicației
V.1. Descrierea aplicației
Aplicația trebuie să constitue un instrument care să faciliteze gestionarea activităților
desfășurate într-un Ghișeu Unic, respectiv de emitere și gestiune a documentelor de identitate.
Aplicația se bazează pe șapte entități principale, care au legătură cu celelalte tabele: ghișeu
unic, operatori, persoana, domiciliu persoana, certificate, document de iden titate și pasaport simplu.
Utilizatorii care se conectează la aplicație aparțin unui Ghișeu Unic. În aplicație sunt definite
Ghișee Unice pentru fiecare unitate administrativ -teritorială. Fiecare utilizator are aceleași drepturi
și poate procesa cereri de eliberare acte de identitate doar pentru persoanele care domiciliază pe raza
de compet ență a unității administrativ -teritoriale.
Accesul în aplicație se face pe bază de user-i Oracle cu parolă. În aplicație trebuie definiți câte
doi utilizatori pentru fiecare Ghișeu Unic:
select * from operatori;
Cod Nume op. Parola Drepturi Status Data Start Data Stop Cod Ghișeu Detalii
1 Op_AB_1 *** O A 01.01.2019 31.12.2019 1 Operator Alba -Iulia
2 Op_AB_2 *** O A 01.01.2019 31.12.2019 1 Operator Alba -Iulia
3 Op_AG_1 *** O A 01.01.2019 31.12.2019 2 Operator Pitești
4 Op_AG_2 *** O A 01.01.2019 31.12.2019 2 Operator Pitești
… ……… ……… ………… …….. …………. …….. ………… …………..
Un utilizator se conectează la aplicație apelând link -ul:
http://computer_1:8890/forms/frmservlet
V.2. Ecranele aplicației
După conectarea la aplicație, p rimul ecran al aplicației afișează denumirea, logo-ul aplicației
și fereastra pentru completarea user-ului și parolei pentru conectare . De asemenea, există și opțiunile
pentru recuperarea user-ului și a parolei, în cazul în care acestea au fost uitate. Dacă autentificarea a
reușit, se va activa buton ul Start .
54
Acționând butonul Start , este apelată fereastra în care sunt afișate datelor persoanei care a
depus cererea de eliberea a documentului de identitate, selectând din meniul Query , opțiunea E xecute .
De asemenea, această fereastră are butoane le pentru apelarea rapidă a ecranelor cu funcții
cheie și un buton Exit care încheie sesiunea de lucru.
55
În situația în care persoana nu este deținătoare a unui document de identitate, datele acesteia
trebuie înregistrate în baza de date, selectând din men iul Query , opțiunea Enter .
Acționând butonul Document Identitate , se va afișa fereastra cu informațiile despre actele de
identitate. Tab-ul de Carte de identitate afișează informațiile despre documentul de identitate, iar tab-
ul de Pasaport afișează informațiile despre pașaportul simplu deținut de către persoana respectivă.
56
La eliberarea unui nou document de identitate, informațiile privind actul precedent vor fi
stocate în tabela document_identitate_h , respectiv pasaport_simplu_h . De asemenea, dacă în datele
de stare civilă ale persoanei intervin modificări, datele anterioare sunt inserate în tabela persoana_h
și pot fi vizualizate acționând butonul Nume Anterioare :
57
Bibliografie
1. Ileana Popescu, Alexandra Alecu, Letitia Velcescu, Gabriela Florea – Programare
avansată în Oracle9i, Editura Tehnică, 2004 ;
2. Lect. Univ. Dr. Letiția Velcescu. Curs Aplicații profesionale în bazele de date. București:
Universitatea din București – Facultatea de Matematică și Informatică, 2015.
3. Lect. Univ. Dr. Gabriela Mihai. PL/SQL – Concepte generale . București: Universitatea
din București – Facultatea de Matematică și Informatică, 2012.
4. https://jontech.ro/2015/01/protocoale -de-securitate -ssl-tls-si-ssh-2/. Protocoale de securitate
SSL/TLS, [Citat 06 01 2015] ;
5. http://www.marketwatch.ro/articol/2696/Tehnologia_PKI_ –
cheia_integritatii_informatiei/ . Tehnologia PKI – „cheia“ integrității informației , [Citat 16
11 2007];
6. http://www.aut.upt.ro/~bgroza/Slides/Slides_Autentificare.pdf
7. https://support.microsoft.com/ro -ro/help/907272/kerberos -authentication -and-
troubleshooting -delegation -issues
8. http://docs.oracle.co m/cd/B10501_01/server.920/a96521/audit.htm
9. http://www.datadisk.co.uk/html_docs/oracle/auditing.htm
10. http://www.galaxyng .com/adrian_atanasiu/cript.htm
11. http://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_securing_data.htm#CH
DCGGBH
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Introducere … … …. ..2 [618574] (ID: 618574)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.