Securitatea Bazelor de Date Oracle

I.1. Scurta istorie a companiei Oracle

Responsabilii „cu imaginea” din compania Oracle plaseaza inceputurile acesteia prin anul 1977 cand a fost pusa pe picioare firma de consultanta Software Developement Laborat ories (SDL). Fondatorii acesteia erau preocupati, in primul rand, de teoriile si limbajele legate de organizarea si accesul la date, avand ca obiectiv construirea unei baze de date relationale viabile din punct de vedere comercial. Din acest motiv, numele initial al firmei a fost schimbat ulterior in Relational Software Inc (RSI) in 1970. Produsul care urma sa asigure viitorul noii companii a fost denumit Oracle (care, se pare, era si numele unui proiect pentru CIA la care lucrase unul dintre fondatori, de altfel si principalul actionar, Larry Ellison), primii clienti provenind din domeniul agentiilor guvernamentale. Anii ’80 au insemnat confirmare si maturizarea bazei de date (a SGBD – ului mai exact). Reprezentand produsul principal al companiei, numele acesteia a fost schimbat, din nou, firma intitulandu-se de acum inainte simplu Oracle Corporation.

Este recunoscuta astazi contributia esentiala a acestei companii la proliferarea pe piata a sistemelor relationale, piata pe care a castigat pozitia de lider, detinuta si in prezent, in ciuda unei competitii acerbe din partea IBM (lider in domeniul bazelor de date ierarhice implementate pe mainframe-uri), Informix (pana nu demult, cand a fost achizitionata de IBM), Sysbase si, bineinteles (in special in ultima decada), Microsoft cu SQL Server.

O data cu cresterea (s-ar putea spune formidabila) vanzatorilor propriilor sisteme de baze de date rela tionale, conducatorii companiei au decis (1987) sa diversifice oferta de produse, integrate cu bazele de date Oracle, incepand cu o suita de module financiare (astazi dezvoltandu-se un produs din categoria ERP numit Oracle 11i Application Suite) si de gestiune a proiectelor.

Astazi, compania Oracle are o oferta extrem de generoasa si sofisticata, pornind de la serverul de baze de date Oracle9i(2) Database (care constituie baza de integrare a tuturor celorlalte), suita de dezvoltare Oracle 9i Developer Suite (compusa in principal din Oracle 9i Forms, Reports, Designer, JDeveloper, pentru proiectarea si dezvoltarea de aplicatii, dar si WarehouseBuilder sau Discoverer, pentru domeniul intitulat Business Intelligence), la care se adauga serverul de aplicatii, certificat J2EE, Oracle9iApplication Server si, mai nou, suita back-office Oracle Collaboration Suite.

Dupa cum am mentionat inainte, succesul firmei Oracle a fost asigurat in primul rand de serverul de baze de date, in jurul caruia s-au dezvoltat si nucleele celorlalte produse purtand marca Oracle. Maturizarea acestuia a dat de multe ori tonul si a jalonat, am putea spune, insasi evolutia pietei sistemelor relationale comerciale, de aceea merita sa facem o scurta trecere in revista a principalelor versiuni si a contributiilor acestora in peisajul bazelor de date, astfel:

lansarea produsului Oracle de catre programatorii de la SDL a insemnat si startul in domeniul bazelor de date relationale comerciale, construite pe principiile fundamentate matematic de catre regretatul E.F. Codd;

Oracle Version 2 (considerata de fapt prima versiune completa Oracle) a imbunatatit substantial performantele si siguranta produsului lansat anterior care se baza pe caracteristicile relationale introduse in principal de limbajul de acces (SQL) ce avea capabilitati deosebite referitoare, spre exemplu, la subinterogari, joinuri si altele…;

Oracle Version 3 a insemnat rescrierea in intregime a versiunii anterioare in limbajul C, limbaj care asigura o portabilitate rezonabila pe mai multe platforme de operare. Pe langa caracteristicile legate de portabilitate, aceasta versiune a insemnat introducerea exeutiei frazelor SQL respectand principiul atomicitatii in cadrul tranzactiilor;

Oracle Version 4 imbunatateste substantial stabilitatea versiunilor anterioare si introduce o noua caracteristica numita consistenta datelor la citire care asigura intangibilitatea setului initial de date supus prelucrarilor determinate de executia unei fraze SQL. Se deschideau astfel perspectivele concurentei…;

Oracle Version 5 marcheaza proliferarea sistemelor client/server, astfel incat o aplicatie rezidenta pe o masina ieftina, tip PC, sa acceseze datele gestionate de catre un SGBD rezident pe o masina puternica, tip server;

Oracle Version 6 a insemnat un pas important inainte in domeniul scalabilitatii prin imbunatatirea mecanismelor de blocare. S-au introdus acum blocajele la nivel de linie care eliminau anumite efecte asupra concurentei ale blocajelor la nivel de tabela;

Oracle Version 7 se remarca prin introducerea procedurilor stocate, a declansatoarelor, a regulilor declarative privind restrictiile referentiale, trasaturi care au imbunatatit performantele aplicatiilor, dar si consistenta datelor;

Oracle Version 8 a insemnat adaptarea serverului de baze de date la exigentele cererilor de date din ce in ce mai complexe in privinta structurarii lor. Conceptul care a permis stapanirea, intr-o anumita masura, a acestei complexitati a fost obiectul, prin urmare obiectele au inceput sa populeze si bazele de date Oracle alaturi de structurile tabelare „clasice”;

Oracle Version 8i adauga la versiunea anterioara un mic „i” in ton cu noul val de aplicatii bazate pe tehnologiile Internet-ului. In acest sens Oracle a fost primul sistem de baze de date care a inclus un mediu runtime Java direct in motorul bazei de date pentru a permite structurarea logicii procedurilor stocate si in limbajul Java, cel mai nou si mai prolific limbaj de programare din acel moment (si pana astazi). Mai trebuie mentionata, tot in aceasta directie, si introducerea suportului pentru standardul SQLJ care permite introducerea frzelor de acces la date formalizate in SQL direct in procedurile sau metodele scrise in Java, rezidente pe client sau pe server;

Oracle Version 9i a imbunatatit substantial mecanismul de securitate al bazelor de date (de exemplu, introducerea conceptului de baze de date „virtuale”), dar si stabilitatea si scalabilitatea prin introducerea arhitecturii RAC (Real Application Cluster) ce permite rularea unui singur server de baze de date pe un complex format din mai multe noduri (masini independente) si recuperarea transparenta a caderilor oricarui nod din retea. Tot in aceasta versiune este substantial modificata versiunea SQL caracteristica bazelor de date Oracle prin in troducerea de noi trasaturi cerute de aplicatiile gen OLAP (on-line analytical processing) ce vor putea fi implementate direct in bazele de date „obisnuite” fara a fi necesar un motor de prelucrare separata a unor astfel de cereri. De asemenea, facilitatile de stocare si accesare a documentelor XML vin sa completeze noul limbaj SQL destinat bazelor de date Oracle 9i.

Oracle Version 10g este ultima versiune aparuta

II. Generalitati

II.1. Sfaturi din partea expertilor privind securizarea

bazelor de date Oracle

Securitatea bazelor de date este un subiect inca neelucidat intru totul. DON BURLESON care este expert in Oracle sfatuieste administratorii de servere Oracle sa fie mai atenti cu serverele lor (hardware) ca si punct de pornire in incercarea de a securiza o baza de date.

Tot BURLESON a spus ca in privinta lui Oracle cea mai des intalnita problema este aceea de a nu instala corect serverul Oracle si de aici lasand involuntar o bresa in apararea lor impotriva virusilor si a hack-erilor. Oracle este aproape inpenetrabil daca este instalat corect.

Un administrator trebuie sa modifice parolele standard.

In ultimele versiuni Oracle a inbunatatit securitatea introducand row-level security si astfel utilizatorii nu pot vedea decat ce au muncit ei si astfel au limitat numarul atacurilor „pe usa din spate”.

Companiile trebuie de asemenea sa securizeze sistemul in care Oracle este integrat

Aplicatiile Oracle pot fi securizate in mai multe moduri: prin intermediul adaptoarelor Remote Authentication Dial-In User Service (RADIUS), serverelor de autentificare, metode de criptare etc.

Oracle are mai multe metode de autentificare, inclusiv securitatea Kerberos, un sistem de securitate bazat pe cartele si care a mai eliminat din posibilitatile de intrare in baza de date a unor persoane neautorizate, deasemenea Oracle are baze de date private si virtuale(virtual privat databases) care limiteaza acesul catre anumite randuri ale unei tabele, si "securizarea accesului la port" (port access security) in care toate aplicatiile Oracle sunt obligate sa asculte pe un anumit port pentru orice conexiuni.

Securizarea unei baze de date este sarcina unui singur om si anume a administratorului bazei de date.

Securizarea bazei de date a unei organizatii este esentiala in zilele noastre. Bazele de date sunt baza unor sisteme de afaceri cum ar fi serverele web si aplicatiile de tip ERP.

Datele stocate in baze de date de regula includ informatii sensibile cum ar fi informatii legate de angajati si/sau clienti, date despre situatia financiara a societatii si alte date cu caracter confidential.

II. 2. MANAGEMENTUL RISCULUI BAZELOR DE DATE

Bazele de date sunt vulnerabile la bresce de securitate datorita complexitatii lor, a salvarii nesigure a parolelor, setarilor gresite a sistemelor sau a unor portite lasate in sistemul de securitate. Pentru a reduce riscul acestor vulnerabilitati o organizatie trebuie sa aplice principii de securitate cum ar fi:

Mai putine privilegii, un utilizator ar trebui sa aiba acele privilegii care-i permit sa-si indeplineasca atributiunile legate de postul pe care acesta il ocupa in firma;

Apararea sistemului in mai multe nivele de securitate;

Prevenirea aparitiei de bresce in sistemul de securitate este un lucru bun dar detectarea acestor bresce este o necesitate;

Criptarea ar trebui folosita ori de cate ori se poate;

Definirea de politici de securitate.

Urmatoarele principii sunt relevante pentru securizarea bazelor de date:

Secrete si confidentialitate- informatiile nu ar trebui dezvaluite nimanui care nu are acces la ele;

Siguranta, integritate si autenticitate- datele nu ar trebui sa poate fi intentionat sau nu corupte si originile informatiilor ar trebui sa fie verificabile;

Disponibilitate si recuperare- bazele de date ar trebui sa mearga încontinuu si sa se poata recupera date in situatii exceptionale.

Pe langa securizarea bazelor de date este nevoi si de securizarea prin mai multe nivele de protectie. Fara aplicarea principiilor de securitate pe nivele cum ar fi securizarea retelelor oricine ar putea ajunge sa se conecteze la serverul bazei de date prin porturile binecunoscute ocolind securitatea oferita de Sistemul de Operare. Securitatea retelelor poate fi marita prin firewall, listele de acces ale routerelor (ACL) si sistemul de detectie al intrusilor (IDS). Sistemul de Operare trebui de asemenea securizat pentru a nu exista posibilitatea ca cineva sa poata accesa baza de date datorita faptului ca SO a fost prost configurat.

II.3. Aplicarea principiilor de securitate la bazele de date

Autentificarea user-ilor;

Controlul accesului la obiecte si autentificarea aplicatiilor autorizate;

Proceduri si politici de administrare;

Securizarea configurarii initiale;

Auditarea;

Strategiilor de back-up si recuperare.

III. Securitatea bazelor de date Oracle

Oracle pune la dispozitia DBA-ului (DBA = Database Administrator) mai multe nivele de securitate:

Securizarea conturilor pentru validarea utilizatorilor

Securizarea accesului la obiectele bazei de date

Securizarea la nivelul de sistem pentru administrarea privilegiilor globale (generale)

III.1. Securitatea conturilor

Pentru a putea accesa datele dintr-o baza de date Oracle, trebui sa ai acces la un cont din aceea baza de date. Acest acces poate fi direct – prin intermediul conexiunilor utilizatorilor la o baza de date – sau indirect. Conexiunile indirecte includ accesul prin indirect. Conexiunile indirecte includ accesul prin intermediul unor autorizari presetate la legaturile bazei de date. Fiecare cont trebuie sa aiba o parola asociata. Un cont pe o baza de date poate fi de-asemenea legat de contul din sistemul de operare.

Parolele sunt alocate unui utilizator in momentul in care utilizatorul respectiv este creat si pot fi modificate dupa ca utilizatorul a fost creat. Posibilitatile utilizatorului de a modifica parola contului pot fi limitate prin intermediul uneltelor prin intermediul carora primeste acordul de a se loga la baza de date. In baza de date se stocheaza o versiune criptata a parolei intr-un tabel de date. Daca contul este legat direct cu contul sistemului de operare, este posibil sa se omita verificarea parolei.

Incepand cu Oracle8, parolele pot sa expire si DBA-ul poate stabili in ce conditii o parola poate fi refolosita (cu ajutorul istoriei parolelor din baza de date). De asemenea se pot folosi anumite profile care sa permita introducerea parolelor cu anumite restrictii (de exemplu: parola sa aiba o lungime minima), si se pot bloca automat anumite conturi daca sunt mai multe incercari nereusite succesive de logare la acel cont.

III.2. Privilegii legate de obiecte

Accesul la obiectele unei baze de date se mai numeste si privilegiu. Acestea permit anumite comenzi specifice ale bazei de date sa poata fi folosite asupra unor anumite obiecte ale bazei de date, pentru aceasta se foloseste comanda grant. De exemplu daca utilizatorul ION are o tabela numita EMPLOYEE si executa comanda:

atunci toti utilizatorii( PUBLIC) vor putea sa execute instructiuni de tip SELECT pe tabela ANGAJATI a lui ION. Poti crea si grupuri de privilegii – roluri – pentru a administra mai usor privilegiile. Pentru aplicatiile cu un numar foarte mare de utilizatori folosirea rolurilor reduc considerabil numarul de comenzi grant care trebui date. Intru cat rolurile pot fi protejate prin parole si pot fi activate sau dezactivate dinamic, ele adauga un nou nivel de securitate bazei de date.

III.3. Rolurile si Privilegiile de la nivelul sistem

Pot fi folosite rolurile pentru a administra comenzile de la nivelul sistem disponibile utilizatorilor. Printre aceste comenzi se innumara CREATE TABLE si ALTER INDEX. Actiunile asupra fiecarui tip de obicte ale bazei de date sunt autorizate prin privilegii separate. De exemplu: unui user i se poate acorda privilegiul CREATE TABLE dar nu si privilegiul CREATE TYPE. Se pot crea roluri la nivelul sistem care pot acorda utilizatorilor privilegii de care au nevoie fara a le acorda mai multe privilegii decat le sunt necesare in lucrul cu baza de date. Rolurile standard CONNECT si RESOURCE sunt folositoare pentru cele mai de baza privilegii de sistem necesare utilizatorilor si respectiv dezvoltatorilor.

Utilizatorii care au rolul RESOURSE au primit de asemenea si privilegiu de sistem TABLESPACE, si astfel acestia au dreptul de a crea obiecte oriunde in baza de date. Datorita acestui privilegiu trebui sa oferi acest rol RESOURCE pentru departamentele de dezvoltare si de testare.

III.4. Implementarea securitatii

Posibilitatile de securizare in Oracle includ roluri, profile si acordarea directa de privilegii. Pachetul Oracle Enterprise Manager este util pentru administrarea conturilor, rolurilor, privilegiilor si profilelor.

III.4.1. Punctul de pornire: Securitatea Sistemului de Operare

Nu poti accesa o baza de date daca in prealabil nu ai reusit sa accesezi – direct sau indirect – serverul pe care ruleaza aceea baza de date. Primul pas este securizarea platformelor si a retelei pe care aceasta lucreaza.

Oracle foloseste un numar de fisiere la care utilizatorii nu au acces direct. De exemplu: datafiles si redo log sunt scrise si citite doar prin procesele interioare ale lui Oracle. De aceea doar administratorii pot crea si sterge astfel de fisiere si asta la nivelul de sistem de operare.

Datele pot fi copiate in alte tabele fie ca facand parte dintr-o schema de copiere. Pentru a securiza datele, va trebui sa securizeze fiecare baza de date in care datele tale se afla, impreuna cu backupurile ale fiecarei baze de date in parte. Daca cineva poate sa plece cu o copie a bazei de date atunci toate eforturile tale au fost de prisos. Trebuie prevenit accesul neautorizat la toate copiile bazei de date.

III.5. Crearea utilizatorilor

La crearea unui utilizator scopul este acela de a crea un cont securizat si care are acordate privilegiile si setarile default adecvate. Se poate folosi comanda CREATE USER pentru a crea un nou cont pe baza de date. La crearea unui nou cont nu va avea nici o posibilitate si useri nici macar nu se vor putea log-a pana cand nu li se acord acest privilegiu.

Toate setarile necesare pentru creearea unui cont de user pot fi specificate in interiorul unei singure comenzi CREATE USER. Parametrii corespunzatori acestei comenzi sunt prezenteti in Tabelul 1.

Un exemplu de folosire a comenzii CREATE USER este oferit in continuare. In acest exemplu utilizatorul THUMPER este creat, cu parola RABBIT, o tabela spatiu implicita USERS, o tabela spatiu temporara TEMP fara cota si cu profilul implicit.

Din moment ce nu a fost specificat nici un profil, va fi folosit profilul implicit al tabelei.

Din moment ce nu a fost specificata o cota utilizatorul nu poate crea obiecte in baza de date. Pentru a acorda o cota din resurse, se foloseste parametrul quota al lui create user sau alter user asa cum va fi exemplificat mai jos. In exemplu, THUMPER a primit o cota de 100MB din tabela spatiu USERS.

Acum utilizatorul THUMPER poate folosi pana la 100MB din tabela spatiu USERS.

Exceptand numele utilizatorului toti ceilalti parametrii ai comenzii create user pot fi modificati cu ajutorul comenzii alter table.

Din fereastra OEM Security Manager se pot crea useri sau se pot crea useri asemanatori altor useri deja existenti. Aceasta caracteristica iti permite sa creezi utilizatori noi care au aceleasi caracteristici ca si utilizatorii deja existenti. Figura 1 arata figura initiala a ferestrei Security Manager cu user-ul THUMPER selectat. Cu ajutorul utilitarului OEM se pot atribui unui utilizator nou roluri, privilegii de sistem, privilegii de obiecte si cota. In figura 1 autentificarea prin parola permite realizarea unei parole personalizate, scopul acelui cont este de a fi global – folosit pentru administrarea bazei de date de la distanta – sau contul va fi identificat extern. Obtiunea de expirarea a parolei este disponibila si contul poate fi crea inchis sau deschis.

Se pot crea useri noi selectand optiunea „general” si dand un click cu butonul drept al mouse-ului sau selectand optiunea „Create” din meniul de obiecte in timp ce se

III.6. Stergerea utilizatorilor

Un user se poate sterge cu ajutorul comenzii drop user. Aceasta comanda are un parametru CASCADE care sterge toate obiectele din schema user-ului si apoi sterge user-ul. Daca un utilizator este proprietarul unor obiecte atunci pentru stergerea sa este nevoie de CASCADE. Un exemplu simplu de stergere a unui user este prezentat in continuare:

Orice tabel virtual(view), sinonim, procedura, functie sau pachet care se refera la obiectele user-ului sters vor fi trecute in starea INVALID. Daca un alt user este creat cu acelasi nume mai tarziu, noul user nu va mosteni de la cel dinaintea sa nimic. Utilitarul OEM ofera posibilitatea „remove”(sterge) care permiter ca un utilizator sa fie sters. OEM afiseaza si o fereastra de confirmare inainte ca utilizatorul sa fie sters.

III.7. Privilegii la nivelul sistem

Se pot folosi rolurile de la nivelul sistem pentru a imparti comenzile de la nivelul sistem folosite pentru administrarea bazei de date. Un DBA poate crea roluri-sistem personalizate sau le poate folosi pe cele standard care au venit odata cu baza de date.

Se poate folosi clauza with grant option sau comanda grant pentru ai permite acestuia se acorde privilegii altor utilizatori.

Tabelul 2 prezinta 11 roluri-sistem oferite de Oracle. Folosind aceste roluri DBA-ul poate limita privilegiile de la nivelul sistem oferite de rolurile de management ale bazei de date. Pe langa rolurile prezentate in tabelul 2 baza de date mai poate include roluri generate cu ajutorul lui Advanced Queuing Option (AQ_USER_ROLE si AQ_ADMINSTRATOR_ROLE) si cu ajutorul lui OEM Intelligent Agents (rolul SNMPAGENT).

Rolul CONNECT este acordat de regula utilizatorilor finali. Cu toate ca are anumite posibilitati de creare de obiecte (inclusiv create table) nu ofera user-ului nici o cota pe nici o tabele-spatiu. Din moment ce utilizatorii nu vor avea nici o cota pe nici o tabela-spatiu, nu vor putea crea nici un tabel decat daca DBA-ul ii va acorda o cota.

Rolul RESOURCE este acordat dezvoltatorilor. Acest rol ofera dezvoltatorilor de aplicatii privilegiile utilizate cu frecventa cea mai mare.

Rolul DBA – include toate privilegiile – sistem cu optiunea de a le putea acorda si altor user-i.

Rolurile IMP_FULL_DATABASE si EXP_FULL_DATABASE sunt folosite pentru operatiile de import si export a bazelor de date. Aceste roluri fac parte din rolul DBA si pot fi folosite de acesta pentru a acorda privilegii de management limitate.

Daca unui user i se acorda rolul DELETE_CATALOG_ROLE, atunci acesta poate sterge inregistrari din tabela SYS.AUD$. Tabela SYS.AUD$ este locul in care se scriu inregistrarile audit. Acordand aceste privilegii unui uilizator i se acorda practic dreptul de a sterge inregistrari din tabela de audit, fara a-i acorda acestui user si alte drepturi de administrator.

Rolurile SELECT_CATALOG_ROLE acorda user-ilor privilegii de select si execut asupra dictionarelor de date obiect. SELECT_CATALOG_ROLE nu acorda user-ului dreptul de a face interogari pe tabelele de executare dinamica.

EXECUTE_CATALOG_ROLE acorda user-ilor dreptul de a executa proceduri si functii care fac parte din dictionarul de date.

Rolul CREATE_TYPE este activat in Oracle8i daca foloseste optiunea obiect ( "Object Option" ), si astfel acestia pot crea noi tipuri abstracte de date.

Pentru crearea unor conturi noi este nevoie de optiunea DBA-ului, dar totusi se poate selecta un grup de privilegii necesare creerii de conturi noi.

De exemplu, se poate crea un rol la nivelul-sistem numit ACCOUNT_CREATOR. Aceasta se poate doar sa creezi conturi noi si alte drepturi de-ale DBA-ului. Comanda SQL este:

Prima comanda creaza un rol numit ACCOUNT_CREATOR. Cea de a doua comanda ii acorda user-ului posibilitatea de a se log-a ("CREATE_SESSION”) si sa modifice conturi ( "CREATE USER" si "ALTER USER" ). Se poate creea acest rol si utilizand utilizatorul OEM ( Fig 1 ) si acordandu-i privilegii (Fig 2)

Posibilitatea de a creea rolul ACCOUNT_CREATOR este utila atunci cand este implementat un pachet software. Mai multe aplicatii externe lui create presupune ca vom avea drepturi DBA complete pe baza de date cand de fapt nu au nevoie decat de drepturile CREATE USER si ALTER USER.

Implicit rolurile sunt activate la fiecare log-are.Putem modifica rolul implicit al unui user prin clauza DEFAULT ROLE sau comanda alter user. De exemplu se poate modifica un utilizator sa nu aiba nici un rol implicit.

Poti modifica rolul implicit:

Sau un rol sa nu fie activ in momentul pornirii sesiunii:

Daca un utilizator nu are un rol la nivel-sistem cum ar fi CONNECT, atunci invocarea de transformare a rolului in modul implicit va esua dand eroarea:

Trebuie sa la acorzi user-ilor roluri invocate de a spune care din ele este implicit.

III.8. Profilul utilizator

Se pot folosi profilele pentru a limita cantitatea de resurse – de sistem si de baza de date – disponibile unui user si sa administrezi restrictiile parolelor.Daca nu sunt create profile intr-o baza de date, atunci profilul implicit, care specifica surse nelimitate pentru toti user-i vor fi folositi.

Resursele care pot fi limitate prin profile apar in tabelul 3.

Dupa cum apare si in tabel mai multe surse pot fi limitate.Totusi, toate restrictiile sunt reactionare, nu se ia nici o masura pana cand user-ul nu a depasit limita de resurse. De aceea profilele nu vor fi prea mare ajutor in prevenirea interogarilor care folosesc foarte multe resurse pana cand ajunge la limita.O data ajunse la limita toate comenzile SQL vor fi oprite.

Profilele sunt create prin comanda CREATE PROFILE.Comanda ALTER PROFILE, exemplificata mai jos, este folosita la modificarea profilelor existente.In acest exemplu profilul implicit ( "DEFAULT" ) pentru baza de date este modificat pentru a permite un timp de asteptare de maximum o ora:

III.9. Administrarea parolelor

Incepand cu Oracle 8 se pot folosi profile pentru administrarea expirarii, a reutilizarii si a complexitatii parolelor.De exemplu se poate limita durata de viata a unei parole si blocarea unui cont a carui parola este prea veche. Deoarece se poate forta o parola sa fie potrivita din punct de vedere al complexitatii si complexitate si bocarea unui cont care are incercari repetate de log-are.

De exemplu deca configurati FAILED_LOGIN_ATTEMPTS din profilul utilizatorului la 5, atunci 5 log-ari eronate vor fi permise pentru acel cont, la a 6-a incercare contul va fi blocat.

Daca sunt 6 incercari concomitente gresite de conectare la contul JANE, contul va fi automat blocat si apoi cand se va folosii parola corecta va primii eroarea:

Pentru a debloca contul se foloseste clauza ACCOUNT UNLOCK a comenzii ALTER USER asa cum urmeaza:

Dupa deblocarea contului accesul la contul JANE va fin din nou permis.Se poate bloca manual un cont folosind clauza ACCOUNT LOCK a comenzii ALTER USER:

Daca un cont este blocat datorita incercarilor eronate de log-are se va debloca automat cand valuarea profilului PASSWORD_LOCK_TIME este depasita.De exemplu daca PASSWORD_LOCK_TIME are valoarea 1, atunci contul JADE va fi blocat pentru o zi si apoi se va debloca.

Se poate stabili o durata maxima de viata a unei parole prin intermediul PASSWORD_LIFE_TIME.De exemplu se pot forta utilizatorii din porfilul LIMITED_PROFILE sa isi schimbe parolele la fiecare 30 de zile.

In acest exemplu, comanda ALTER PROFILE este folosita pentru a modifica profilul LIMITED_PROFILE.Valoarea lui PASSWORD_LIFE_TIME este 30, deci user-ii care folosesc acest profil vor trebui sa-si schimbe parola la fiecare 30 de zile.Daca parola a exipirat trebuie schimbata la urmatoarea log-are exceptand cazul in care profilul are specificate o perioada de gratie pentru parolele expirate.("PASSWORD_GRACE_TIME")

Un cont expirat este diferit de un cont blocat.Un cont blocat poate fi automat deblocat intr-un interval de timp.Un cont expirat trebuie reactivat manual de catre DBA.

Pentru a reactiva un cont expirat trebui executata comanda ALTER USER ca in exemplul:

Urmatoarea data cand JANE incearca sa se conecteze la contul sau, cand introduce parola i se va cere o noua parola pentru cont.

Poti deocamdata sa fortezi user-ii sa-si schimbe parolele cand acceseaza pentru prima data contul, cu ajutorul clauzei PASSWORD EXPIRE a comenzii CREATE USER. Comada CREATE USER totusi permite folosirea profilului PASSWORD_LIFE_TIME pentru a-i impune o data de expirare.

III.10. Prevenirea refolosirii parolelor

Pentru a prevenii refolosirea unei porole unul din prefilele: PASSWORD_REUSE_MAX sau PASSWORD_REUSE_TIME.Aceste profile se exclud reciproc.Daca unul din ele are o valoare atunci celalalt trebuie sa fie setat pe UNLIMITED.

Parametrul PASSWORD_REUSE_TIME specifica numarul de zile care trebuie sa treaca inainte ca o parola sa fie refolosita.De exemplu daca valoarea lui PASSWORD_REUSE_TIME este 60, atunci numai poti refolosi parola in 60 de zile.

Parametrul PASSWORD_REUSE_MAX specifica numarul de parole care trebuie schimbate pana cand o parola poate fi refolosita.Daca incearci sa refolosesti parola pana se ajunge la limita,

Oracle va refuza cererea.

De exemplu:

Daca userul JADE incearca sa refoloseasca o parola recenta, acesta incercare va esua.

De exemplu:

si apoi o schimba din nou:

La urmatoartea schimbare de parola ea incarca sa refoloseasca o parola recenta si incercarea esueaza :

Nu poate refolosi niciuna din parolele sale recente , va trebui sa gaseasca o parola noua. Istoria parolelor este salvata intr-o tabela numita „USER_HISTORY$” in schema SYS. In aceasta tabela, Oracle salveaza id-ul utilizatorului, valoarea parolei criptata cand a fost creata. Cand valoarea lui „PASS_REUSE_TIME”este depasita sau numarul de schimbari depaseste „PASS_REUSE_MAX”, inregistrarile cu parolele respective sunt sterse din „SYS.USER_HISTORY$”. Daca o varianta noua criptata se potriveste cu o varianta deja existenta, parola noua este refuzata.

Datorita faptului ca parolele sunt salvate intr-o tabela apartinand lui SYS, datele sunt salvate in tabela-spatiu SYSTEM. Deci va rezulta o istorie foarte mare pentru un numar foarte mare de user-i care trebuie sa-si schimbe parola frecvent si prin urmare este nevoie de resurse mari pentru tabela-spatiu SYSTEM.

III.11. Configurarea complexitatii parolelor

Parolele utilizatorilor pot fi obligate sa satisfaca anumite cerinte de complexitate. De exemplu se poate cere sa aiba o anumita lungime minima, sa nu fie cuvinte simple si sa contian acel putin un semn de punctuatie.

Parametrul PASSWORD_VERIFY_FUNCTION al comenzii CREATE PROFILE si ALTER PROFILE specifica numele functiei care va evalua parolele.

Pentru a simplifica intarirea complexitatii parolelor Oracle ofera o functie numita VERIFY_FUNCTION. Implicit aceasta functie este creata doar daca rulezi script-ul „utldmg.sql” aflat in „/rdbms/admin” in directorul Oracle. Mai jos este aceasta functie:

Primele 3 clauze „IF” verifica daca parola este identica cu username, daca

parola are mai putin de 4 caractere si daca paroala este un set de cuvinte specifice.

Urmatoarea sectiune majora a functiei este verificarea sirului de caractere din care e format parola. Pentru a putea trece aceste verificari parola trebuie sa aiba cel putin este un caracter, un numar si un semn de punctuatie.

Urmatoarea sectiune a functiei compara vechea parola cu cea noua caracter cu caracter. Daca nu sunt cel putin 3 diferente parola este refuzata.

Ultiam comanda din script nu este o parte a functiei este comanda ALTER TABLE care schimba profilul implicit. Comanda de mai sus creaza urmatoarele limite: durata de viata a parolelor este de 60 de zile, cu o peroiada de gratie de 10 zile; nu se pot refolosi parolele pe o perioada de 1800 de zile si contul se blocheaza dupa 3 incercari nereusite succesive si se deblocheaza automat dupa 1 minut.

Daca modifici profilul implicit trebuie sa te asiguri ca toti utilizatorii profilului il pot folosi.

III.12. Legarea conturilor DB de cele ale Sistemului de Operare

Utilizatorii au dreptul de a accesa date din momentul in care au intodus un username si o parola valabile. Totusi, este posibil sa se profite de sistemul de operare sa ofere un nivel aditional de autentificare a user-ilor.

Contula bazei de date poate fi cuplat cu contul sistemului de operare aflat pe acelasi server. Cele doua conturi vor diferi doar prin prefixul numelui contului de pe baza de date, Prefixul implicit este OPS$, dar poate fi modificat prin parametrul OS_AUTHENT_PREFIX din fisierul init.ora. Prefixul poate fi setat ca NULL si deci nu va mai fi nici un prefix.

De exemplu, fie contul de pe sistemul de operare numit FARMER. Contul de pe baza de date corespunzator este OPS$FARMER fara parola ca mai jos:

Slash („/”) tine locul combinatiei username/password care ar fi ceruta in mod normal pentru acces.

Conturile pot fi create cu parole. Consider contul OPS$FARMER. Comanda de creare trebuie sa fie in felul urmator:

Cu toate ca parola nu va fi folosita, ea tot poate fi speficata. Datorita faptului ca acest cont are o parola este posibil sa accesezi contul OPS$FARMER de pe alt sistem de operare daca stii parola contului de pe baza de date.

Sunt 2 modalitati de ocolire pentru aceasta problema posibila:

Se poate crea un cont fara parola, folosind clauza IDENTIFIED EXERNELLY, cum va fi facut mai jos. Aceasta clauza ocoleste nevoia de parola pentru cont in timp ce se pastreaza legatura dintre contul de pe calculator si contul de pe baza de date.

Cand este folosita clauza IDENTIFIED EXTERNELLY, se forteaza baza de date sa valideze contul de pe sistemul de operare folosit la accesarea bazei de date. Contul de pe sistemul de operaresi contul de pe baza de date trebuie sa fie identic (cu exceptia prefixului).

Se poate crea un cont cu o parola imposibila. Aceasta metoda previne user-ul de a se log-a in orice cont, altul decat cel prin sistemul de operare.

Exista situatii in care ar trebui lasati user-i sa aiba conturi cu OPS$ si o parola utilizabila. Daca user-ul se va log-a direct prin sistemul de operare sau de la distanta prin intermediul SQL*NET, folosirea unui cont cu parola poate fi avantajos. Daca un dezvoltator se va conecta la baza de date prin intermediul sistemului de operare, acesta nu va vrea sa introduca parola pentru a putea testa un script si aici il ajuta forma contului cu OPS$. Daca user-ul se va conecta de la distanta si REMOTE_OS_AUTHENT nu este configurat pe TRUE in init.ora, va avea nevie de parola.

Folosirea fisierelor- parola pentru autentificare

In majoritatea cazurilor user-i cu drepturi DBA pot fi autentificati de sistemul de operare. De exemplu, pe sistemul UNIX, un membru al grupului DBAse paote conecta intern (CONNECT INTERNAL) in fisierul „/etc/group”. Daca user-i cu rol DBA nu pot fi autentificati de sistemul de operare, va trebui sa creezi si sa pastrezi un fisier-parola.

Pentru a crea un fisier-parola:

Crearea fisierului cu ajutorul utilitarului ORAPWD.

ORAPWD este un utilitar ORACLE care genereaza fiserul-parola. La executia comenzii ORAPWD trebuie specificat numele fisierului-parola care trebuie creat inainte de parola pentru SYS si acces intern. Parametrul ENTRIES ii spune lui Oracle cate intrari vor fi in fisierul-parola. Fisiserul numai poate fi marit decat daca valoarea lui ENTRIES este mai mare. Daca se depaseste numarul de intrari veu primi eroarea ORA-1996. La recrearea fisierului-parola va trebui sa reacorzi privilegiile SYSDBA si SYSOPER.

Configurarea parametrului initial REMOTE_LOGIN_PASSWORD_FILE pe valoarea EXCLUSIVE in fisierul init.ora. Opreste si reporneste baza de date asa incat schimbarea parametrului sa aiba efect.

Acorda privilegiile SYSOPER si SYSDBA fiecarui user care are nevoie sa administreze baza de date, ca si in exemplu SYSDBA ii acorda user-ului DBA autoritate; SYSOPER lasa utilizatorul sa faca operatii pe baza de date. Pentru ai acorda unui user sprijinul SYSOPER sau SYSDBA trebuie sa fie conectat intern. User-ii privilegiati ar trebui sa se conecteze la baza de date folosind o comanda similara cu :

Se poate folosi comanada REVOKE pentru a retrage privilegiile sistem unui utilizator, ca in exemplu:

Pentru a vedea cine are privilegiile-sistem SYSDBA si SYSOPER trebuie lansata interogarea V$PWFILE_USERS. Acest parametru are valoarea TRUE in coloana SYSDBA, si daca userul are privilegiul SYSDBA, si are valoarea TRUE in coloana SYSOPER daca user-ul are privilegiul SYSOPER.

III.13. Protectia parolei

Si in Conturile si Rolurile pot fi protejate prin parole. Parolele pentru ambele sunt configurate cand sunt create si pot fi modificate prin comenzile ALTER USER si ALTER ROLE.

Parola initiala a unui cont poate fi configuirata prin comanda CREATE USERS. In exemplul care urmeaza contul THUMPER este creat cu parola initiala RABBIT.

Parolele conturilor pot fi modificate cu ajutorul comenzii ALTER USER. Ca in exemplu:

Incepand cu Oracle 8 se poate folosi comanda PASSWORD pentru a schimba parola unui user. Valorile parolei nu sunt afisate pe ecran.

Pentru a-ti schimba propria ta parola da comanda SQL PASSWORD, ca in exemplul:

Pentru a-ti schimba parola unui alt user se da comanda PASSWORD urmata de nume_utilizator.

Si ti se va cere noua parola a lui Jane si inca odata pentru verificare. Daca user-ul nu doreste sa foloseasca comanda password, atunci va fi nevoit sa foloseasca urmatoarea comanda:

Comanda PASSWORD simplifica procesul de schimbare a parolei care e important in Oracle 8i din moment ce poti obliga user-i sa-si schimbe parolele.

Parolele pentru roluri sunt configurate in momentul in care rolul este creat prin intermediul comenzii CREATE ROLE. Nu este nevoie sa configurezi o parola pentru un rol dar daca exista una, trebuie introdusa la activarea rolului de catre user.

Se poate folosi comanda ALTER ROLE pentru a modifica parolele asociate rolurilor. Ca si parolele pentru user-i si acestea pot fi identificate extern („identified externelly”), astfel intarind legatura dintre contul sistemului de operare si rol. Se poate scoate o parola asociata unui rol prin intermediul clauzei NOT IDENTIFIED, ca si in exemplu:

Dupa executarea acestei comenzi rolul ACCOUNT_CREATOR nu va mai fi protejat prin parola.

Rolurile pot fi legate de privilegiile sistemului de operare. In marea majoritate a sistemelor UNIX , procesul de verificare foloseste fisierul /etc/group. Pentru a-l putea folosi pentru orice sistem de operare, parametrul de pornire OS_ROLES din fisierul init.ora trebuie sa fie TRUE.

Urmatorul exemplu, de verificare a procesului, este pentru o instanta a bazei de date numita „Local” pe sistemul de operare UNIX. Fisierul de pe server contine urmatoarea intrare:

Aceasta intrare atribuie rolul MANAGER contului numit „DORA”. Sufixul „_d” indica faptul ca acest rol trebuie sa i se atribuie implicit cand se conecteaza. Sufixul „_a” ar fi indicat ca acest rol trebuie atribuit cu optiunea de administrator („WITH ADMIN OPTION”). Daca acelasi rol ar fi trebuit sa fie si default cu optiunea admin pentru acelasi user atunci sufixul ar fi devenit „_od”. Daca acelasi role ar fi trebuit atribuit mai multor persoane atunci numele utilizatorilor ale acestora ar fi trebuit sa apara in intrarea din fisierul /etc/group, ca in exemplu:

Daca este folosita aceasta optiune atunci toate rolurile vor fi activate prin sistemul de operare.

III.14. Privilegii la nivel obiect

Privilegiile de la nivelul obiect acorda user-ilor accesul la date care nu le apartin. Se pot crea roluri pentru a usura administrarea privilegiilor.

Privilegiile sunt create cu ajutorul comenzii GRANT si sunt inregistrate in dictionarele de date. Accesul la tabele, tabele virtuale, secvente – ca si sinonimele lor – plus posibilitatea de a executa proceduri, functii de a acorda pachete si tipuri. Aceste privilegii apar in tabelul 4.

Se poate folosi clauza WITH ADMIN OPTION pentru a-i da posibilitatea user-ului sa acorde si el mai departe drepturi pe obiect. Ca si in exemplul urmator.

Daca tabela EMPLOYEE este partitonata, nu poti acorda privilegiul SELECT pe doar o partitie a sa. Totusi poti crea o tabela virtuala care sa ia datele dintr-o singura partitie a sa. Totusi poti crea o tabela virtuala („view”) care sa ia datele dintr-o singura partitie si sa le acorzi dreptul de SELECT pe aceea tabela virtuala.

Administratrea privilegiilor poate deveni foarte usor o activitate care consuma mult timp. Fiecare user trebuie sa primieasca privilegiile cele mai adecvate pentru fiecare obiect al bazei de date.

Cu ajutorul rolurilor administrarea privilegiilor a devenit mult mai usoara. Rolurile sunt grupuri de privilegii, apoi rolurile sunt acordate user-ilor, simplificand considerabil administrarea privilegiilor.

In urmatorul exemplu se vede utilizarea rolurilor. In el sunt create 2 roluri. Primul, APPLICATION_USER, are privilegiul-sistem CREATE SESSION, un user care a primit acest rol va putea sa se conecteze la baza de date, si cel de-al doilea rol este DATA_ENTRY_CLERK care acorda privilegii pe tabele:

Rolurile pot fi acordate si altor roluri. De exemplu se poate acorda rolul APPLICATION_USERS rolului DATA_ENTRY_CLERK, ca in exemplu:

Apoi rolul poate fi acordat unui user. Acest rol poate fi activat dinamic in timpul sesiunii userului cu ajutorul comenzii SET ROLE.

Fig. 8

Rolurile si privilegiile sistem(cum ar fi CREATE TABLE) pot fi acordate userilor cu preivilegiul de a-l acorda mai departe si altor user-i. In cazul rolurilor este folosita optiunea: „WITH ADMIN OPTION”. In exemplul urmator rolul DATA_ENTRY_CLERK creat in prealabil este acordat utilizatorului BPOTTER, impreuna cu dreptul de admninistrare a rolului.

Cu acest privilegiu utilizatorul BPOTTER poate acorda (GRANT) sau revoca (REVOKE) rolul altor utilizatori sau il poate sterge.

Felul dinamic al rolurilor este foarte folositor pentru restrictionarea privilegiilor utilizatorilor. Daca un rol este activ cand un user porneste o aplicatie (prin comanda SET ROLE) si apoi se dezactiveaza la parasirea aplicatiei, utilizatorul nu poate beneficia de privilegiile oferite de acest rol decat prin intermediul aplicatiei.

De exemplu in momentul in care MCGREGOR se conecteaza la aplicatie comanada:

poate fi executata. In momentul in care utilizatorul paraseste aplicatia comanda:

va dezactiva toate privilegiile care i-au fost acordate prin intermediul rolurilor.

Se poate folosi comanda REVOKE pentru a revoca privilegiile si rolurile pentru user-i. Se pot revoca doar o parte din privilegii (specificandu-le pe fiecare) sau toate privilegiile (prin tastarea ALL).

In urmatorul exemplu, un privilegiu este revocat din tabela EMPLOYEE a unui utilizator, in timp ce privilegiile unui alt utilizator sunt revocate complet:

In urmatorul exemplu utilizatorului HELPDESK i se revoca rolul ACCOUNT_CREATOR:

Datorita faptului ca conturile utilizatorilor sunt sterse complet cu ajutorul comenzii:

, privilegiile „CLEANUP” (curatare) a conturilor sterse nu mai este necesar. Comanda REVOKE este folosita mai ales cand user-i isi schimba starea sau cand aplicatiile se muta dintr-un mediu (cum ar fi cel de test) in altul (cum ar fi productia).

Este o mare deosebire intre a revoca (REVOKE) privilegiile atribuite cu comanda GRANT OPTION si cele atribuite cu comanda WITH ADMIN OPTION. Sa presupunem ca THUMPER atribuie lui MCGREGOR acces la tabela EMPLOYEE cu optiune de atribuire:

MCGREGOR poate acum sa acorde dreptul de atribuire lui BPOTTER cu optiunea „WITH GRANT OPTION”:

Daca THUMPER revoca atribuirea lui MCGREGOR:

BPOTTER nu mai poate accesa tabela EMPLOYEE a lui THUMPER.

III.15. Privilegii de afisare

Informatiile privitoare la privilegiile care au fost acordate sunt salvate in dictionarul de date. Aceste date sunt disponibile prin intermediul tabelelor virtuale asupra dictionarului de date.

Se pot folosi tabelele virtuale afisate in tabelul 5 pentru a afisa privilegiile care au fost acordate in baza de date.

De exemplu se pot afisa ce privilegii-sistem au fost acordate si cu ce roluri:

Pentru a primii tabela acordarilor de drepturi pentru user-i, acum ar trebui cautate 2 tipuri de acordari:

acordari explicite de drepturi pentru user-i

cele care sunt acordate prin intermediul rolurilor

Pentru a vedea drepturile acordate explicit trebuie interogat DBA_TAB_PRIVS ca in:

Pentru a vedea tabela de privilegii acordate prin roluri, trebuie sa fie gasite inregistrarile user-ilor in DBA_ROLES_PRIVS si comparate cu tabela rolurilor(ROLE_TAB_PRIVS)

Aceasta interogare va gasi tabela rolurilor acordate unui anumit user.

Pentru a vedea limitele profilului se poate folosi interogarea USER_RESOURCE_LIMITS.

USER_PASSWORD_LIMITS descrie profilul parolelor pentru user. Nu exista nici o versiune „DBA” a acestei interogari, este limitata doar la versiunea curenta a user-ului. Pentru a vedea costurile corespunzatoare fiecarei resurse lansati interogarea RESOURCE_COST. Administratorul bazei de date poate accesa tabela virtuala DBA_PROFILES pentru a vedea limitele resurselor pentru toate profilele.

Pe langa aceste tabele virtual mai sunt 2 tabele fiecare cu cate o coloana care ilustreaza privilegiile si rolurile active in acel moment pentru acea sesiune. Acestea sunt:

SESSION_PRIVS si SESSION_ROLES sunt disponibile pentru toti utilizatorii.

IV. LIMITAREA COMENZILOR DISPONIBILE

IV.1. Profilul user de produs

Incepand cu SQL*PLUS s-a mai adaugat un nivel de securitate – anumite comenzi pot fi dezactivate pentru anumiti user-i. Astfel user-i cu privilegiul UPDATE pe o tabela pot fi impiedicati de la a folosi SQL*PLUS pentru a updata intru mod necontrolat.

Aceasta capacitate le permite administratorilor sa impiedice user-i sa acceseze sistemul de operare prin intermediul comenzii „HOST”. Aceasta piedica este utila cand o aplicatie contine o optiune de a accesa SQL*PLUS si nu vrei ca user-i sa aiba acces la sistemul de operare.

Pe langa revocarea posibilitatii de folosire a comenzii HOST din SQL*PLUS, se mai poate revoca si folosirea comenzii CONNECT. Eliminand aceste 2 comenzi vom forta user-i sa ramana in conturile lor. In exemplul urmator se poate vedea rezultatul acestor comenzi cu acest nevel de securitate la locul sau:

Pentru a creea acest nivel de securitate trebuie creata tabela profilului user-ului de produs. Scriptul de creeare a lor se numeste pupbld.sql si se gaseste in /sqlplus/admin. Acest script creaza mai multe tabele si tabele virtuale si ar trebui rulat din contul SYSTEM.

Pentru SQL*PLUS cea mai importanta tabela poate fi accesata prin intermediul unui sinonim numit PRODUCT_USER_PROFILE. In tabelul 6 apar coloanele cheie din PRODUCT_USER_PROFILE.

IV.2. Securitatea parolei in timpul conectarii

Cand se conecteaza un client la un server, sau de la o baza de date la alta prin legaturi, Oracle transmite parola introdusa intr-un format necriptat, o cripteaza doar daca i se impune. Incepand cu Oracle 8, se pot configura parametrii care sa forteze serverul Oracle sa cripteze parolele. Pentru aceasta se urmaresc pasii:

Pe calculatoarele client se configureaza parametrul ORA_ENCRYPT_LOGIN din fisierul sqlnet.ora pe TRUE

Pe server se configureaza DBLINK_ENCRYPT_LOGIN din fisierul init.ora pe TRUE.

Odata setati parametrii si baza de date repornita parolele se vor transmite criptat de la un calculator client la server sau de la server la server.

IV.3. Criptarea parolelor

Cunoasterea modului in care baza de date cripteaza parolele ajuta administratorul in realizarea mai multor sarcini altfel imposibile. Printre care si configurarea parolelor imposibile si posibilitatea de a deveni un alt utilizator.

IV.3.1. Cum sunt salvate parolele

Cand o parola este configurata pentru un cont sau un rol, baza de date salveaza versiunea criptata a parolei in dictionarul de date. Configurarea aceleasi parole pentru 2 user-i va avea ca rezultat 2 versiuni criptate diferite. Pentru toate parolele versiunea criptata are o lungiem de 16 caractere si contine numere si litere mari(de tipar).

Cum se confirma o parola? La introducerea unei parole in timpul conectarii, acea parola este criptata si aceasta versiune este comparata cu cea existenta in dictionarul de date. Daca sunt identice atunci parola este validata si autentificarea a fost realizata cu succes.

IV. 3.2. Configurarea parolelor imposibile

Cunoasterea modului in care sunt salvate parolele este importanta pentru ca adauga noi optiuni pentru securizarea conturilor.

Consider urmatoarele conturi si parole selectate de urmatoarea interogare. Interogarea returneaza username si password din tabela virtuala DBA_USERS:

Din moment ce parolele nu sunt salvate in dictionarul de date – doar versiunea criptata a lor este – cum stie „IMPORT” ce parole sunt?

„IMPORT” executa comenzi SQL. In timpul unui import complet, acesta executa o versiune nedocumentata a instructiunii CREATE USER.

Se poate folosi aceeasi comanda pentru a configura criptarea pentru orice cont. Atata timp cat versiunea ta contrazice regulile de criptare care la au fost stabilite(16 caractere, toate literele mari), va fi imposibila autentificarea. Rezultatul va fi un cont care este accesibil doar de pe contul sistemului de operare corect de pe server.

In urmatorul exemplu criptarea este „no way”, si apoi este interogat tabela virtuala DBA_USERS:

Accesarea contului OPS$FARMER este posibila doarprin intermediul contului FARMER de pe server, si chiar si atunci este accesibil doar prin /autologin. Parolele imposibile sunt utile la blocarea conturilor care nu sunt OPS$, si care la care sa nu te poti conecta niciodata direct, cum ar fi SYS.

IV.3.3 Schimbarea user-ului

Din moment ce parolele cripate se pot configura te poti log-a temporar intr-un alt cont si apoi sa-l configurezi la loc cu vechea sa parola fara ca macar sa o cunosti. Ceea ce iti ofera posibilitatea de a schimba user-ul ceea ce poate fi foarte util in testare, repararea problemelor aparute cu baza de date.

Pentru a-ti schimba user-ul trebuie sa treci prin pasii urmatori:
Interogrezi DBA_USERS pentru a vedea versiunea criptata curenta a parolei pentru acel cont

Lansezi comanda ALTER USER pentru a reseta versiunea criptatata a parolei dupa ce ai terminat

Salveaza comanda ALTER USER intr-un fisier

Schimba parola utilizatorului

Acceseaza contul utilizatorului si incepi testarea

Dupa ce testarea a luat sfarsit, rulezi fisierul care contine comanda ALTER USER pentru a restabili versiunea criptata a parolei la valoarea sa initiala.

Aceste proces este realizat automat prin intermediul script-ului SQL*PLUS . Acest script generaza automat comanda necesara resetarii contului utilizatorului indata ce testarea sa incheiat.

Acest script genereaza ca si output un script numit reset.sql. Acest fisier va avea 3:

prima va contine comanda ALTER USER cu clauza VALUES urmata de versiunea criptata a parolei

a doua linie va contine o comanda HOST care va sterge fisierul reset.sql

si cea de a treia contine o comanda EXIT pentru a parasi SQL*PLUS.

Comanda rm –f din cea de a doua linie va fi in locuita de comanda de stergere a sistemului de operare.

Acum putem trece mai departe la pasii 4 si 5 care implica schimbarea parolei utilizatorului (prin interemediul comenzii ALTER USER) si accesarea contului.

Acum vei fi log-at in contul MCGREGOR. Dupa ce sa incheiat testarea, se conecteaza la SQL*PLUS si ruleaza scriptul reset.sql de mai jos:

Daca testezi mai multe conturi simultan trebuie sa precizezi username in fisierul reset.sql, altfel primul fisier reset.sql poate fi sters de versiunile ulterioare. Daca se aplica rationamentul conturilor de tipul OPS$ trebuie sa fii atent pentru ca caracterul $ este un caracter special in unele sisteme de operare cum ar fi UNIX.

Contul va fi resetat la valoarea sa initiala si implicit si la parola sa initiala. Testarea a avut loc fara a cunoaste parola initiala si fara a distruge parola contului.

V. Concluzii

Securitatea bazelor de date este un subiect inca neelucidat intru totul. DON BURLESON care este expert in Oracle sfatuieste administratorii de servere Oracle sa fie mai atenti cu serverele lor (hardware) ca si punct de pornire in incercarea de a securiza o baza de date.

Tot BURLESON a spus ca in privinta lui Oracle cea mai des intalnita problema este aceea de a nu instala corect serverul Oracle si de aici lasand involuntar o bresa in apararea lor impotriva virusilor si a hack-erilor. Oracle este aproape inpenetrabil daca este instalat corect.

Un administrator trebuie sa modifice parolele standard.

In ultimele versiuni Oracle a inbunatatit securitatea introducand row-level security si astfel utilizatorii nu pot vedea decat ce au muncit ei si astfel au limitat numarul atacurilor „pe usa din spate”.

Companiile trebuie de asemenea sa securizeze sistemul in care Oracle este integrat

Aplicatiile Oracle pot fi securizate in mai multe moduri: prin intermediul adaptoarelor Remote Authentication Dial-In User Service (RADIUS), serverelor de autentificare, metode de criptare etc.

Oracle are mai multe metode de autentificare, inclusiv securitatea Kerberos, un sistem de securitate bazat pe cartele si care a mai eliminat din posibilitatile de intrare in baza de date a unor persoane neautorizate, deasemenea Oracle are baze de date private si virtuale(virtual privat databases) care limiteaza acesul catre anumite randuri ale unei tabele, si "securizarea accesului la port" (port access security) in care toate aplicatiile Oracle sunt obligate sa asculte pe un anumit port pentru orice conexiuni.

Securizarea unei baze de date este sarcina unui singur om si anume a administratorului bazei de date.

VII. ANEXA

JavaChatFrame.java

import java.awt.*;

import java.awt.event.*;

import javax.swing.*;

import java.net.*;

import java.io.*;

public class JavaChatFrame extends JFrame {

//Construct the frame

BorderLayout borderLayout1 = new BorderLayout();

JMenuBar menuBar1 = new JMenuBar();

JMenu menuFile = new JMenu();

JMenuItem menuFileExit = new JMenuItem();

JMenu menuHelp = new JMenu();

JMenuItem menuHelpAbout = new JMenuItem();

JMenuItem menuOpenSesion = new JMenuItem();

JMenuItem menuInfoHost = new JMenuItem();

ChatDlg chatDlg;

Reciver frame_recv;

public JavaChatFrame() {

enableEvents(AWTEvent.WINDOW_EVENT_MASK);

try {

jbInit();

frame_recv = new Reciver(null, this);

frame_recv.start();

}

catch (Exception e) {

e.printStackTrace();

}

}

//Component initialization

public ChatDlg getChatDlg() { return chatDlg; }

private void jbInit() throws Exception {

this.getContentPane().setLayout(borderLayout1);

this.setSize(new Dimension(400, 300));

this.setTitle("JavaChat");

menuFile.setText("File");

menuFileExit.setText("Exit");

menuFileExit.addActionListener(new ActionListener() {

public void actionPerformed(ActionEvent e) {

fileExit_actionPerformed(e);

}

});

menuHelp.setText("Help");

menuHelpAbout.setText("About");

menuOpenSesion.setText("Deschide sesiune…");

menuOpenSesion.setToolTipText("Deschide o sesiune noua la o adresa specificata");

menuInfoHost.setText("<<localhost>> informatii…");

menuInfoHost.setToolTipText("Informatii despre acest host…");

menuHelpAbout.addActionListener(new ActionListener() {

public void actionPerformed(ActionEvent e) {

helpAbout_actionPerformed(e);

}

});

menuOpenSesion.addActionListener(new ActionListener() {

public void actionPerformed(ActionEvent e) {

openSesion_actionPerformed(e);

}

});

menuHelp.add(menuHelpAbout);

menuBar1.add(menuFile);

menuBar1.add(menuHelp);

menuFile.add(menuOpenSesion);

menuFile.addSeparator();

menuFile.add(menuFileExit);

this.setJMenuBar(menuBar1);

}

//File | Exit action performed

public void fileExit_actionPerformed(ActionEvent e) {

frame_recv.stop();

frame_recv.closeerver();

System.exit(0);

}

public void openSesion_actionPerformed(ActionEvent e) {

ConectionDlg cDlg = new ConectionDlg(this, "Connect to…", false);

cDlg.setLocation(350,350);

cDlg.setModal(true);

cDlg.show();

String p = cDlg.getHostName();

if(p == null) return;

chatDlg = new ChatDlg(this, p, false);

try{

Socket c = new Socket(InetAddress.getByName(p), 4561);

DataOutputStream douts = new DataOutputStream(c.getOutputStream());

douts.writeBytes("init"+'\n');

chatDlg.setClientSocket(c);

}catch(IOException ex) {System.out.println(ex.getMessage());}

//mai trebuie adugat aici

}

//Help | About action performed

public void helpAbout_actionPerformed(ActionEvent e) {

JavaChatFrame_AboutBox dlg = new JavaChatFrame_AboutBox(this);

Dimension dlgSize = dlg.getPreferredSize();

Dimension frmSize = getSize();

Point loc = getLocation();

dlg.setLocation((frmSize.width – dlgSize.width) / 2 + loc.x, (frmSize.height – dlgSize.height) / 2 + loc.y);

dlg.setModal(true);

dlg.show();

}

//Overriden so we can exit on System Close

protected void processWindowEvent(WindowEvent e) {

super.processWindowEvent(e);

if (e.getID() == WindowEvent.WINDOW_CLOSING) {

fileExit_actionPerformed(null);

}

}

}

ChatDld.java

//Title: JavaChat

//Version:

//Copyright: Copyright (c) 2005

//Author: Barbu Razvan

//Company:

//Description: un program de chating in JAVA

import java.awt.*;

import javax.swing.*;

//import borland.jbcl.control.*;

import java.net.*;

//import borland.jbcl.layout.*;

import java.awt.event.*;

import java.io.*;

public class ChatDlg extends JDialog {

JPanel panel1 = new JPanel();

Socket client, server;

Reciver recv;

BorderLayout xYLayout1 = new BorderLayout();

JButton buttonSend = new JButton();

JButton buttonClose = new JButton();

DataOutputStream douts;

JTextField textField = new JTextField();

List listConv = new List(10, false);

public ChatDlg(JavaChatFrame frame, String title, boolean modal) {

super(frame, title, modal);

try {

jbInit();

pack();

}

catch (Exception ex) {

ex.printStackTrace();

}

recv = new Reciver(listConv, frame);

setSize(new Dimension(400,240));

}

public ChatDlg() {

this(null, "", false);

}

public void setClientSocket(Socket c){

try{

client = c;

douts = new DataOutputStream(c.getOutputStream());

}catch(IOException e) {System.out.println(e.getMessage());}

}

public void setServerSocket(Socket c){

server = c;

recv.set_dins(server); //va aranja si reciverul in mod corespunzator

}

public void startit(){

recv.start();

show(true);

}

void jbInit() throws Exception {

panel1.setLayout(xYLayout1);

// xYLayout1.setHeight(282);

// xYLayout1.setWidth(488);

textField.setText(null);

buttonSend.setLabel("Send!");

buttonSend.addActionListener(new java.awt.event.ActionListener() {

public void actionPerformed(ActionEvent e) {

buttonSend_actionPerformed(e);

}

});

buttonClose.setLabel("Close conection !");

buttonClose.setToolTipText("Nu apasa\\nDecat daca vrei sa inchizi conexiunea]");

buttonClose.addActionListener(new java.awt.event.ActionListener() {

public void actionPerformed(ActionEvent e) {

buttonClose_actionPerformed(e);

}

});

getContentPane().add(panel1);

panel1.add(listConv, BorderLayout.NORTH);

panel1.add(textField, BorderLayout.CENTER);

panel1.add(buttonSend, BorderLayout.EAST);

panel1.add(buttonClose, BorderLayout.SOUTH);

}

void buttonSend_actionPerformed(ActionEvent e) {

String p = textField.getText();

listConv.add(p);

listConv.select(listConv.getItemCount());

p = textField.getText() + '\n';

textField.setText(null);

try{

douts.writeBytes(p);

}catch(IOException ex) {System.out.println(ex.getMessage());}

}

void buttonClose_actionPerformed(ActionEvent e) {

try{

douts.writeBytes("Conexiune terminata… PA!"+'\n');

}catch(IOException ex1) {System.out.println(ex1.getMessage());}

dispose();

}

}

JavaApp.java

import javax.swing.UIManager;

import java.awt.*;

public class JavaApp {

boolean packFrame = false;

//Construct the application

public JavaApp() {

JavaChatFrame frame = new JavaChatFrame();

//Validate frames that have preset sizes

//Pack frames that have useful preferred size info, e.g. from their layout

if (packFrame)

frame.pack();

else

frame.validate();

//Center the window

Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();

Dimension frameSize = frame.getSize();

if (frameSize.height > screenSize.height)

frameSize.height = screenSize.height;

if (frameSize.width > screenSize.width)

frameSize.width = screenSize.width;

frame.setLocation((screenSize.width – frameSize.width) / 2, (screenSize.height – frameSize.height) / 2);

frame.setVisible(true);

}

public static void main(String[] args) {

try {

UIManager.setLookAndFeel(new com.sun.java.swing.plaf.windows.WindowsLookAndFeel());

//UIManager.setLookAndFeel(new com.sun.java.swing.plaf.motif.MotifLookAndFeel());

//UIManager.setLookAndFeel(new com.sun.java.swing.plaf.metal.MetalLookAndFeel());

}

catch (Exception e) {

}

new JavaApp();

}

}

Reciver.java

//Title: JavaChat

//Version:

//Copyright: Copyright (c) 1998

//Author: Barbu Razvan

//Company:

//Description: un program de chating in JAVA

import java.io.*;

import java.net.*;

import java.awt.*;

import java.awt.event.*;

import javax.swing.*;

public class Reciver extends Thread {

Socket rcv, c;

DataInputStream dins;

DataOutputStream douts;

ServerSocket ssocket;

ChatDlg chatDlg;

List m_tp;

String str, in, cor;

JavaChatFrame frm;

public Reciver(List tp, JavaChatFrame jcf){

super();

try{

if(tp == null) ssocket = new ServerSocket(4561);

m_tp = tp;

}catch(IOException e) {System.out.println(e.getMessage());};

frm = jcf;

}

public void run(){

while(true)

try{

if(m_tp == null){

rcv = ssocket.accept();

dins = new DataInputStream(rcv.getInputStream());

cor = dins.readLine();

if(cor.compareTo("init") == 0){

c = new Socket(rcv.getInetAddress(), 4561);

douts = new DataOutputStream(c.getOutputStream());

douts.writeBytes("res"+'\n');

chatDlg = new ChatDlg(frm,

rcv.getInetAddress().getHostName(), false);

chatDlg.setClientSocket(c);

chatDlg.setServerSocket(rcv);

chatDlg.startit();

}

else if(cor.compareTo("res") == 0){

chatDlg = frm.getChatDlg();

chatDlg.setServerSocket(rcv);

chatDlg.startit();

}

}

else{

in = dins.readLine();

m_tp.add(in);

m_tp.select(m_tp.getItemCount()-1);

}

}catch(IOException e){}

}

public void set_dins(Socket c) {

try{

dins = new DataInputStream(c.getInputStream());

}catch(IOException e) {System.out.println(e.getMessage());}

}

public void set_dins(DataInputStream din) { dins = din; }

public void closeerver(){

try{

ssocket.close();

}catch(IOException e) {}

}

}

ConectingDlg.java

//Title: JavaChat

//Version:

//Copyright: Copyright (c) 1998

//Author: Barbu Razvan

//Company:

//Description: un program de chating in JAVA

import java.awt.*;

import javax.swing.*;

//import borland.jbcl.layout.*;

//import borland.jbcl.control.*;

import java.awt.event.*;

public class ConectionDlg extends JDialog {

JPanel panel1 = new JPanel();

GridLayout xYLayout1 = new GridLayout(4, 0);

JLabel jLabel1 = new JLabel();

JTextField textFieldHost = new JTextField();

JButton buttonOk = new JButton();

JButton buttonCancel = new JButton();

String hostName;

public ConectionDlg(Frame frame, String title, boolean modal) {

super(frame, title, modal);

try {

jbInit();

pack();

}

catch (Exception ex) {

ex.printStackTrace();

}

hostName = null;

}

public ConectionDlg() {

this(null, "", false);

}

void jbInit() throws Exception {

panel1.setLayout(xYLayout1);

// xYLayout1.setHeight(105);

// xYLayout1.setWidth(400);

jLabel1.setText("Conecteaza-te la calculatorul …..");

textFieldHost.setText("localhost");

buttonOk.setText("Start chating");

buttonOk.addActionListener(new java.awt.event.ActionListener() {

public void actionPerformed(ActionEvent e) {

buttonOk_actionPerformed(e);

}

});

buttonCancel.setText("Cancel");

buttonCancel.addActionListener(new java.awt.event.ActionListener() {

public void actionPerformed(ActionEvent e) {

buttonCancel_actionPerformed(e);

}

});

getContentPane().add(panel1);

panel1.add(jLabel1, null);//, new XYConstraints(21, 18, 258, -1));

panel1.add(textFieldHost);//, new XYConstraints(20, 39, 353, -1));

panel1.add(buttonOk, null);//, new XYConstraints(19, 69, -1, -1));

panel1.add(buttonCancel, null);//, new XYConstraints(117, 69, -1, -1));

}

void buttonOk_actionPerformed(ActionEvent e) {

hostName = textFieldHost.getText();

dispose();

}

void buttonCancel_actionPerformed(ActionEvent e) {

dispose();

}

public String getHostName() { return hostName;}

}

JavaChatFrame_AboutBox.java

import java.awt.*;

import java.awt.event.*;

import javax.swing.*;

import javax.swing.border.*;

public class JavaChatFrame_AboutBox extends Dialog implements ActionListener{

JPanel panel1 = new JPanel();

JPanel panel2 = new JPanel();

JPanel insetsPanel1 = new JPanel();

JPanel insetsPanel2 = new JPanel();

JPanel insetsPanel3 = new JPanel();

JButton button1 = new JButton();

JLabel imageControl1 = new JLabel();

ImageIcon imageIcon;

JLabel label1 = new JLabel();

JLabel label2 = new JLabel();

JLabel label3 = new JLabel();

JLabel label4 = new JLabel();

BorderLayout borderLayout1 = new BorderLayout();

BorderLayout borderLayout2 = new BorderLayout();

FlowLayout flowLayout1 = new FlowLayout();

FlowLayout flowLayout2 = new FlowLayout();

GridLayout gridLayout1 = new GridLayout();

String product = "JavaChat";

String version = "";

String copyright = "Copyright (c) 1998";

String comments = "un program de chating in JAVA ";

public JavaChatFrame_AboutBox(Frame parent) {

super(parent);

enableEvents(AWTEvent.WINDOW_EVENT_MASK);

try {

jbInit();

}

catch (Exception e) {

e.printStackTrace();

}

//imageControl1.setIcon(imageIcon);

pack();

}

private void jbInit() throws Exception {

//imageIcon = new ImageIcon(getClass().getResource("your image name goes here"));

this.setTitle("About");

setResizable(false);

panel1.setLayout(borderLayout1);

panel2.setLayout(borderLayout2);

insetsPanel1.setLayout(flowLayout1);

insetsPanel2.setLayout(flowLayout1);

insetsPanel2.setBorder(new EmptyBorder(10, 10, 10, 10));

gridLayout1.setRows(4);

gridLayout1.setColumns(1);

label1.setText(product);

label2.setText(version);

label3.setText("Copyright () 2003 by Liviu Draghici");

label4.setText(comments);

insetsPanel3.setLayout(gridLayout1);

insetsPanel3.setBorder(new EmptyBorder(10, 60, 10, 10));

button1.setText("OK");

button1.addActionListener(this);

insetsPanel2.add(imageControl1, null);

panel2.add(insetsPanel2, BorderLayout.WEST);

this.add(panel1, null);

insetsPanel3.add(label1, null);

insetsPanel3.add(label2, null);

insetsPanel3.add(label3, null);

insetsPanel3.add(label4, null);

panel2.add(insetsPanel3, BorderLayout.CENTER);

insetsPanel1.add(button1, null);

panel1.add(insetsPanel1, BorderLayout.SOUTH);

panel1.add(panel2, BorderLayout.NORTH);

}

protected void processWindowEvent(WindowEvent e) {

if (e.getID() == WindowEvent.WINDOW_CLOSING) {

cancel();

}

super.processWindowEvent(e);

}

void cancel() {

dispose();

}

public void actionPerformed(ActionEvent e) {

if (e.getSource() == button1) {

cancel();

}

}

}

VI. Bibliografie

BrainTree Security Software, Security at the Heart of B2B E -Transactions, 1999,http://www.sqlsecure.com/Whitepapers/3 –

Tier_Data_Security/WP_Download/bti_down2/B2bwp.pdf

BrainTree Security Software, Securing PeopleSof t •Data,

http://www.sqlsecure.com/Whitepapers/3 –

Tier_Data_Security/WP_Download/bti_down2/Pswp.pdf)

BrainTree Security Software, Client/Server Database Security,

http://www.sqlsecure.com/Whitepapers/3 –

Tier_Data_Security/WP_Download/bti_down2/Cswp.pdf

Internet Security Systems, Securing Database Servers,

http://documents.iss.net/whitepapers/securingdbs.pdf

Internet Security System, Database Scanner – Getting Started, Version 4.1, Jan 2001, URL http://documents.iss.net/literature/DatabaseScanner/DBS41_ug.pdf

Heney W, Theriault M, Oracle Security, CA, O’Reilly, 1998

Oracle, Database Security in Oracle8i, An Oracle Technical White Paper, November 1999,URL: http://technet.oracle.com/deploy/security/ seceval/pdf/seceval_wp.pdf