Studiu Comparativ Privind Securitatea Datelor 2
STUDIU COMPARATIV PRIVIND SECURITATEA DATELOR
IN BAZE DE DATE
CUPRINS
INTRODUCERE……………………………………………………………………………………..pag.4
BAZE DE DATE. SISTEME DE GESITUNE A BAZELOR DE DATE. NOTIUNI GENERALE………………………………………………………………………………………pag.6
Definiții………………………………………………………………………………………..pag.6
Exemple de SGBD…………………………………………………………..pag.8
SECURITATEA ȘI PROTECȚIA DATELOR IN BAZELE DE DATE………..pag.10
Considerații generale……………………………………………………………………pag.10
2.2 Integritatea datelor……………………………………………………………………….pag.13
2.2.1 Integritatea semantică a datelor…………………………………………pag.14
2.2.2 Controlul accesului…………………………………………………………..pag.16
2.3 Tehnica Blocării……………………………………………………………………………pag.18
2.3.1 Interblocarea resurselor……………………………………………………pag.20
2.4 Salvarea și restaurarea bazelor de date………………………………………….pag.22
2.4.1. Tehnici de bază utilizate in operația de restaurare……………….pag.23 2.4.2. Restaurarea automată……………………………………………………..pag.25
2.4.3. Restaurarea manuală………………………………………………………pag.27
Independența datelor……………………………………………………………………pag.29
Drepturi si privilegii……………………………………………………………………….pag.29
Criptarea datelor si verificare accesului……………………………………………pag.31
Niveluri de acces utilizator în baze de date distribuite……………………….pag.31
STUDIU COMPARATIV PRIVIND SECURITATEA DATELOR IN BAZE DE DATE………………………………………………………………………………………………pag.32
Restricții de integritate…………………………………………………………………..pag.32
Declansatoare……………………………………………………………………………..pag.34
Restrictii în DB2…………………………………………………………………………..pag.35
Restrictii în NonStop SQL……………………………………………………………..pag.35
Restrictii în Oracle………………………………………………………………………..pag.36
Restrictii în SQL Server…………………………………………………………………pag.36
Restrictii în CA-OpenIngres…………………………………………………………..pag.36
3.8 Securitatea datelor in DB2…………………………………………………………….pag.33 3.9 Securitatea datelor în NonStop L……………………………………………………pag.34 3.10 Securitatea datelor în Oracle……………………………………………………….pag.34
3.11 Securitatea datelor în SQL Server…………………………………………………pag.36 3.12 Securitatea datelor în CA-OpenIngres…………………………………………..pag.37
4. APLICATIE
4.1 Implementarea politicilor de securitate intr-o Baza de Date ORACLE
5. CONCLUZII
6. BIBLIOGRAFIE
INTRODUCERE
În ultimii ani, dezvoltarea sistemelor de baze de date reprezintă unul dintre cele mai importante aspecte în domeniul tehnologiei informației, având un impact decisiv asupra modului de organizare și funcționare a numeroaselor instituții și servicii.
Acestea sunt companiile de comunicație, întreprinderile de comerț, serviciile bancare, serviciile de transport, asigurările, universitățile etc. Acestea sunt dependente de funcționarea corectă și neîntreruptă a sistemelor de baze de date.
Sistemele de baze de date sunt o componentă importantă a vieții de zi cu zi în societatea modernă. Zilnic, majoritatea persoanelor desfășoară activități care implică interacțiunea cu o bază de date: depunerea sau extragerea unei sume de bani din bancă, rezervarea biletelor de tren sau de avion, căutarea unei cărți într-o bibliotecă computerizată, gestiunea angajaților dintr-o firmă, cumpărarea unor produse etc.
Bazele de date pot avea mărimi (număr de înregistrări) și complexități extrem de variate, de la câteva zeci de înregistrări (de exemplu, baza de date pentru o agendă de telefon a unei persoane) sau pot ajunge la milioane de înregistrări (de exemplu, baza de
date pentru cărțile dintr-o bibliotecă, baza de date cu stocarea angajaților unei firme sau baza de date unde se păstrează informații despre situația studenților etc).
Marea majoritate a sistemelor de baze de date existente în momentul de față sunt relaționale și există un număr mare de astfel de sisteme comerciale care pot fi achiziționate și folosite pentru propriile dezvoltări. Modelul relațional de baze de date a
fost introdus în anul 1970 de către E.F.Codd, care este cel mai folosit model de stocare a datelor. Acest nou model s-a dezvoltat pornind de la un articol, “A Relational Model of Data for Large Shared Data Banks” (Un model relațional al datelor pentru bănci mari de date folosite în comun), scris de Dr. E. F. Codd în anul 1970. Ideea lui Codd pentru un sistem de administrare a bazelor de date relaționale folosește conceptele matematice de algebră relațională pentru a grupa datele în mulțimi și a stabili relații între submulțimile (domeniile) comune.
În plus față de dezvoltarea unui model de bază de date relațională, alte două tehnologii au condus la dezvoltarea rapidă a ceea ce acum este numit un sistem de baze de date client/server.
Prima tehnologie importantă a fost calculatorul personal, care a făcut posibil ca aplicații ieftine, ușor de folosit, să permită utilizatorilor crearea documentelor și administrarea datelor rapid și corect. Utilizatorii s-au obișnuit să modernizeze continuu sistemele, deoarece rata schimbului a fost echilibrată rapid de scăderea prețului celor mai avansate sisteme.
A doua tehnologie importantă a fost dezvoltarea rețelelor locale de calculatoare (LAN). Deși utilizatorii erau obișnuiți cu terminalele conectate la calculatorul mainframe comun, acum fișierele procesate puteau fi stocate local și accesate de la orice calculator atașat în rețea. Totodată, cantități mari de date puteau fi transferate la serverele de date departamentale. În acest context, sistemul, denumit client/server deoarece procesarea este separată între calculatoarele client și un server de baze de date, constituie o modificare radicală de la programarea aplicațiilor bazată pe calculatoarele mainframe. Această arhitectură este total recursivă, pe rând serverele putând deveni clienți și cere servicii de la alte servere din rețea. Datorită puterii crescute a hardware-ului calculatoarelor personale, informațiile critice (importante) ale bazei de date pot fi memorate pe un server independent, care poate fi înlocuit mai târziu cu foarte puține (sau chiar fără) modificări.
Complexitatea actuală a aplicațiilor de management al bazelor de date face necesară o combinație a procesării tranzacțiilor on-line, a încărcării și a creșterii sprijinului decizional. În scopul satisfacerii acestor necesități, este nevoie de baze de date scalabile și performante care pot fi ajustate dinamic pentru a realiza un compromis între bazele de date (mai mari) și utilizatorii simultani (mai mulți). De asemenea, sunt necesare tehnologii pentru baze de date proiectate pentru a maximiza capacitățile
configurației hardware/software disponibile (incluzând arhitecturi simplu și multi-procesor), precum și pentru valorificarea unor arhitecturi hardware (cum ar fi clustere cuplate larg și mașini paralele puternice). Serverele de date de astăzi se apropie de aceste cerințe – o arhitectură paralelă (de nouă generație) a bazelor de date care furnizează scalabilitate, manevrabilitate și performanță; o regie minimală a sistemului de operare; și o distribuire automată a încărcărilor de lucru. Arhitectura multifilară este proiectată pentru a utiliza cât mai bine resursele hardware și poate fi reconfigurată
dinamic on-line pentru a urmări cererile în schimbare.
Performanța este aspectul critic al succesului, și având în vedere creșterea dramatică a numărului de utilizatori, date fiind aplicațiile de comerț electronic și noile modele de calcul, presiunea exercitată asupra bazelor de date este mai mare ca oricând.
CAPITOLUL 1
BAZE DE DATE. SISTEME DE GESITUNE A BAZELOR DE DATE.
NOTIUNI GENERALE [2],[3],[4]
Definiții
În sensul larg, o bază de date este o colecție de date corelate din punct de vedere logic, care reflectă un anumit aspect al lumii reale și este destinat unui anumit grup de utilizatori. În acest sens, bazele de date pot fi create și menținute manual (un exemplu ar fi fișele de evidență a cărților dintr-o bibliotecă, așa cum erau folosite cu ani în urmă) sau computerizat așa cum sunt majoritatea bazelor de date în momentul de față.
O definiție într-un sens mai restrâns a unei baze de date este următoarea[3]:
O bază de date este o colecție de date centralizate, creată și menținută computerizat, în scopul prelucrării datelor în contextul unui set de aplicații. Prelucrarea datelor se referă la operațiile de introducere, ștergere, actualizare și interogare a datelor.
Colecția de date reprezintă un ansamblu de date organizat după anumite criterii.
Descrierea datelor se întâlnește sub denumirile de catalog de sistem, dicționar de date sau meta-date ceea ce reprezintă date despre date.
Relațiile logice reprezintă asociațiile dintre mai multe entități.
O entitate este un obiect distinct ce trebuie reprezentat în baza de date.
Un atribut este o proprietate ce descrie un anumit aspect al obiectului ce se înregistrează în baza de date.
Simple colecții de fișe sau fișiere de date care conțin date, dar nu permit operații de interogare nu sunt considerate baze de date. De exemplu, datele memorate în fișiere pe disc într-o aplicație de calcul tabelar sau documentele memorate de un editor de texte (ca Microsoft Word) nu sunt considerate baze de date.
Orice bază de date are următoarele proprietăți implicite:
• Baza de date este o colecție logică coerentă de date ce are cel puțin un înțeles
• Baza de date este destinată, construită și populată de date despre un domeniu bine precizat. Ea are un grup de utilizatori și se adresează unui anumit grup de aplicații
Față de vechile metode de înregistrare a datelor privind diferite activități pe fișe (documente scrise) sau chiar în fișiere pe disc, sistemele de baze de date oferă avantaje considerabile, ceea ce explică extinsa utilizare a acestora. Câteva dintre avantajele oferite sunt[7]:
• Controlul centralizat al datelor, putând fi desemnată o persoană ca responsabil cu administrarea bazei de date
• Viteză mare de regăsire și actualizare a informațiilor
• Sunt compacte: volumul ocupat de sistemele de baze de date este mult mai redus decât documetele scrise
• Flexibilitatea ce constă în posibilitatea modificării structurii bazei de date fără a fi necesară modificarea programelor de aplicație
• Redundanță scăzută a datelor memorate, care se obține prin partajarea datelor între mai mulți utilizatori și aplicații. În sistemele de baze de date, mai multe aplicații pot folosi date comune, memorate o singură dată. De exemplu, o aplicație pentru gestionarea personalului dintr-o universitate și o aplicație pentru gestionarea rezultatelor la examene din aceeași universitate care folosește o singură bază de date, pot folosi aceleași informații referitoare la structurarea facultăților.
• Posibilitatea introducerii standardelor priviru a urmări cererile în schimbare.
Performanța este aspectul critic al succesului, și având în vedere creșterea dramatică a numărului de utilizatori, date fiind aplicațiile de comerț electronic și noile modele de calcul, presiunea exercitată asupra bazelor de date este mai mare ca oricând.
CAPITOLUL 1
BAZE DE DATE. SISTEME DE GESITUNE A BAZELOR DE DATE.
NOTIUNI GENERALE [2],[3],[4]
Definiții
În sensul larg, o bază de date este o colecție de date corelate din punct de vedere logic, care reflectă un anumit aspect al lumii reale și este destinat unui anumit grup de utilizatori. În acest sens, bazele de date pot fi create și menținute manual (un exemplu ar fi fișele de evidență a cărților dintr-o bibliotecă, așa cum erau folosite cu ani în urmă) sau computerizat așa cum sunt majoritatea bazelor de date în momentul de față.
O definiție într-un sens mai restrâns a unei baze de date este următoarea[3]:
O bază de date este o colecție de date centralizate, creată și menținută computerizat, în scopul prelucrării datelor în contextul unui set de aplicații. Prelucrarea datelor se referă la operațiile de introducere, ștergere, actualizare și interogare a datelor.
Colecția de date reprezintă un ansamblu de date organizat după anumite criterii.
Descrierea datelor se întâlnește sub denumirile de catalog de sistem, dicționar de date sau meta-date ceea ce reprezintă date despre date.
Relațiile logice reprezintă asociațiile dintre mai multe entități.
O entitate este un obiect distinct ce trebuie reprezentat în baza de date.
Un atribut este o proprietate ce descrie un anumit aspect al obiectului ce se înregistrează în baza de date.
Simple colecții de fișe sau fișiere de date care conțin date, dar nu permit operații de interogare nu sunt considerate baze de date. De exemplu, datele memorate în fișiere pe disc într-o aplicație de calcul tabelar sau documentele memorate de un editor de texte (ca Microsoft Word) nu sunt considerate baze de date.
Orice bază de date are următoarele proprietăți implicite:
• Baza de date este o colecție logică coerentă de date ce are cel puțin un înțeles
• Baza de date este destinată, construită și populată de date despre un domeniu bine precizat. Ea are un grup de utilizatori și se adresează unui anumit grup de aplicații
Față de vechile metode de înregistrare a datelor privind diferite activități pe fișe (documente scrise) sau chiar în fișiere pe disc, sistemele de baze de date oferă avantaje considerabile, ceea ce explică extinsa utilizare a acestora. Câteva dintre avantajele oferite sunt[7]:
• Controlul centralizat al datelor, putând fi desemnată o persoană ca responsabil cu administrarea bazei de date
• Viteză mare de regăsire și actualizare a informațiilor
• Sunt compacte: volumul ocupat de sistemele de baze de date este mult mai redus decât documetele scrise
• Flexibilitatea ce constă în posibilitatea modificării structurii bazei de date fără a fi necesară modificarea programelor de aplicație
• Redundanță scăzută a datelor memorate, care se obține prin partajarea datelor între mai mulți utilizatori și aplicații. În sistemele de baze de date, mai multe aplicații pot folosi date comune, memorate o singură dată. De exemplu, o aplicație pentru gestionarea personalului dintr-o universitate și o aplicație pentru gestionarea rezultatelor la examene din aceeași universitate care folosește o singură bază de date, pot folosi aceleași informații referitoare la structurarea facultăților.
• Posibilitatea introducerii standardelor privind modul de stocare a datelor, ceea ce permite interschimbarea datelor între organizații
• Menținerea integrității datelor prin politica de securitate (drepturi de acces diferențiate în funcție de rolul utilizatorilor), prin gestionarea tranzacțiilor și prin refacerea datelor în caz de funcționare defectuoasă a diferitelor componente hardware sau software.
• Independența datelor față de suportul hardware utilizat.
Sistemul de programe care permite construirea unor baze de date, introducerea informațiilor în bazele de date și dezvoltarea de aplicații privind bazele de date se numește sistem de gestiune a bazelor de date (SGBD).
SGBD sunt azi oferite pe o mare varietate de platforme de calcul, pornind de la calculatoarele personale și până la sistemele de procesare paralelă masivă a datelor, sub medii extrem de diverse, incluzând DOS, Windows, Novell Netware, Macintosh, Unix, OS/2, VMS, OS/400, MVS. Majoritatea liderilor mondiali din industria de programare oferă cel puțin un SGBD, dacă nu mai multe; dintre aceștia, este suficient să amintim IBM, Computer Associates, Sybase Inc., Oracle, Microsoft, Borland.
Sistemul de gestiunea a bazelor de date oferă o vizualizare a datelor, care nu se modifică atunci când se schimbă suportul de memorare fizic, ceea ce asigură imunitatea structurii bazei de date și a aplicațiilor la modificări ale sistemului hardware utilizat.
Un SGBD dă posibilitatea utilizatorului să aibă acces la date folosind un limbaj de nivel înalt, apropiat de modul obișnuit de exprimare, pentru a obține informații, utilizatorul făcând abstracție de algoritmii aplicați privind selecționarea datelor implicate și a modului de memorare a lor. SGBD-ul este o interfață între utilizatori și sistemul de operare. În esență un SGBD permite:
1. definirea bazei de date printr-un limbaj de definire a datelor (DDL) prin care se specifică tipurile de date și structurile precum și constrângerile asupra datelor.
2. extragerea, inserarea, ștergerea și actualizarea datelor din baza de date cu ajutorul unui limbaj de manipulare a datelor (DML) care oferă o facilitate de interogare generală a datelor, denumită limbaj de interogare. Acest limbaj elimină dificultățile sistemelor bazate pe fișiere unde utilizatorul este constrâns să lucreze cu un set fix de interogări pentru a evita apariția de programe noi ce creează probleme majore privind gestionarea lor.
Exemple de SGBD [4], [6]
În momentul de față, pe piață există o ofertă foarte mare de sisteme de gestiune a bazelor de date, de la sisteme care se pot folosi gratuit (fără licență sau cu licență publică), până la sisteme de înaltă performanță, a căror utilizare necesită cumpărarea de licențe. Pentru aceste sisteme există pe site-urile producătorilor versiuni de test numite trial version, pentru care nu se plătește licență, durata folosirii respectivului produs fiind limitată la un număr de zile (30, 60 zile, în funcție de producător).
Microsoft SQL Server este sistemul de gestiune a bazelor de date relaționale multi-utilizator dezvoltat de firma Microsoft pentru sistemele de operare Windows. Au existat mai multe versiuni, cea actuală fiind SQLServer 2000 (SQL Sever 2003 fiind
încă în faza de testare). În toate versiunile, acest sistem de baze de date suportă standardul SQL2, cu implementarea perfomantă a trăsăturilor avansate de stocare și prelucrare a datelor. Există o interfață grafică pentru interacțiunea cu utilizatorul, pentru
folosirea tuturor opțiunilor: de export/ import date, de creare și manipulare a tabelelor, pentru popularea cu date a tabelelor, de creare a interogărilor, a procedurilor stocate, a triggerelor etc.
Microsoft Access este unul din cele mai cunoscute sisteme de gestiune a bazelor de date relaționale pe platforme de calculatoare personale. Microsoft Access dispune de un sistem de control al bazei de date (database engine) și o intefață grafică
pentru interacțiunea cu utlizatorul. Aplicațiile de baze de date în MS Access se pot dezvolta cu multă ușurință datorită generatoarelor de aplicații (wizards) care permit proiectarea vizuală a bazelor de date, a formularelor (forms) pentru interfețele
grafice și a rapoartelor (reports). MS Access este folosit în special pentru aplicații personale sau pentru mici afaceri și licența acestuia se cumpără odată cu cumpărarea licenței produsului Microsoft Office.
Sistemul Oracle este un sistem de gestiune al bazelor de date multi-utilizator foarte puternic, cu implementări pe toate platformele (Windows, Linux, Unix), care oferă atât performanțe de execuție ridicate, cât și un grad mare de protecție și securitate a datelor. În toate versiunile, Oracle oferă implementarea completă a caracteristicilor modelului relațional, conform standardului SQL2, iar ultimele versiuni (Oracle8i, Oracle9i etc) sunt sisteme de gestiune obiect-relaționale distribuite, implementând extensiile orientate obiect prevăzute în standardul SQL3 și oferind posibilitatea de dezvoltare a bazelor de date distribuite.
MySQL este un sistem de gestiune a bazelor de date relaționale cu implementări pentru sistemele de operare Linux, Unix, Windows. Acest sistem se poate utiliza gratuit, fiind open source. Acest sistem este compatibil cu standardul SQL2, dar unele preve-deri ale standardului fiind implementate parțial.
Visual FOX PRO este un limbaj de programare complet, care acceptă un mediu interactiv și un mediu compilat la rulare. Visual FOX PRO este compatibil cu toate versiunile anterioare de FoxPro. Stilul de proiectare a interfeței FoxPro a fost întotdeauna orientat către flexibilitate și ușurință în utilizare. Pe de altă parte, forța și viteza brută au reprezentat dintotdeauna punctul forte al lui FoxPro. Nici un produs creat de celelalte companii axate pe baze de date, care au făcut trecerea la modelul orientat obiect nu a putut rivaliza cu FoxPro în ce privește viteza de execuție a funcțiilor specifice bazelor de date . Și acest mediu conține vrăjitori (Wizard) pentru gestionarea mai multor taskuri.
CAPITOLUL 2
SECURITATEA ȘI PROTECȚIA DATELOR IN BAZE DE DATE [3],[7]
2.1. Considerații generale
În general prin securitate a datelor se înțelege acea funcție a unui SGBD prin care se asigură protecția datelor împotriva unui acces neautorizat. Există două fațete ale conceptului de securitate a datelor: protecția datelor și controlul autorizării.
Protecția datelor [7] se realizează pentru a nu permite utilizatorilor neautorizați să înțeleagă conținutul fizic al datelor sau pentru a preveni distrugerea voită a datelor. Protecția fișierelor simple se poate realiza prin facilitățile oferite de sistemul de operare cu care se lucrează sau prin diferite tehnici de protejare a informațiilor în rețelele de calculatoare. Astfel, în sistemul de operare UNIX administratorul de sistem atribuie drepturi asupra fișierelor: dreptul de citire(deci de a vedea un fișier), dreptul de scriere (deci de a modifica fișierul) și dreptul de execuție.
Cea mai simplă metodă prin care se poate realiza protecția datelor este criptarea acestora. Această tehnică este utilizată atât pentru fișierele stocate pe disc cât și pentru transmiterea în rețea a informațiilor. Decriptarea datelor se poate realiza numai de către utilizatorii autorizați, adică acei utilizatori care cunosc codul utilizat. Există două scheme principale pentru criptare: Data Encryption Standard și schema de criptare cu cheie publică.
Controlul autorizării[7] trebuie să garanteze că numai utilizatorii autorizați pot realiza operații asupra bazelor de date. Fie că este vorba de un SGBD centralizat sau un SGBDD, acestea trebuie să fie capabile să asigure accesul la o parte a bazelor de date numai pentru o parte a utilizatorilor. Controlul autorizării se poate realiza prin intermediul sistemelor de operare și astfel obținem un control centralizat. Controlul autorizării în sistemele de baze de date diferă prin câteva aspecte de controlul tradițional pentru sistemele de fișiere. Astfel, în cazul sistemelor de baze de date trebuie să se asigure drepturi diferite de accesare a acelorași obiecte de către diferiți utilizatori. Este posibil ca pentru anumite obiecte unii utilizatori să aibă anumite drepturi, iar alți utilizatori să aibă alte drepturi asupra acelorași obiecte.
În ceea ce privește controlul autorizării trebuie să facem distincție între controlul asigurat în sistemele centralizate pe de o parte și pe de altă parte controlul asigurat în sistemele distribuite.
Controlul autorizării centralizate
Următoarele trei entități sunt implicate în controlul autorizării:
Utilizatorii, care sunt interesați în execuția programelor
Operațiile implicate în programele de aplicații
Obiectele bazei de date asupra cărora se execută operațiile.
Fiind dat un triplet (utilizator, operație, obiect), controlul autorizării se poate enunța ca fiind funcția sistemului prin care se verifică dacă utilizatorul are voie să execute operația asupra obiectului.
Introducerea unui utilizator în sistem se realizează în principal prin specificarea perechii (nume_utilizator, parolă). În mod unic nume_utilizator identifică un utilizator al sistemului, iar parola autentifică utilizatorul. Pe de altă parte parola, cunoscută numai de utilizatorul respectiv, împiedică intrarea în sistem a unui intrus.
Granularitatea protecției asigurată de un sistem de gestiune a bazelor de date este mai fină decât a sistemelor bazate pe fișiere. La acestea din urmă, granula de protecție este fișierul. Într-un SGBD mecanismul de vizualizare a obiectelor permite protecția chiar prin ascunderea unora dintre acestea. Astfel putem avea atribute, tupluri sau relații hiden (ascunse) și care nu pot fi vizualizate de utilizatorii neautorizați.
Un drept exprimă o relație dintre un utilizator și un obiect pentru o mulțime precizată de operații. Într-un SGBD relațional bazat pe un SQL, o operație este desemnată printr-o instrucțiune (de exemplu SELECTE, INSERT, UPDATE sau DELETE), iar drepturile sunt acordate sau revocate prin instrucțiuni de forma[5],[7]:
GRANT < tip operație> ON <obiect > TO < utilizator>
REVOKE <tip operație> FROM <obiect> TO < utilizator>
sau alte variante în care se pot acorda/revoca mai multe tipuri de operații pentru unul sau mai mulți utilizatori.
Cuvântul cheie public se utilizează pentru a desemna toți utilizatorii. Acordarea/revocarea drepturilor utilizatorilor se poate realiza de către un singur utilizator, o clasă de utilizatori sau administratorii bazei de date. Ei sunt aceia care au toate privilegiile asupra obiectelor bazei de date și ei sunt singurii care pot utiliza instrucțiunile GRANT și REVOKE. Într-un sistem descentralizat problema aceasta este mai complexă. În asemenea sisteme cel care crează un obiect devine proprietarul acestuia și în consecință, are toate privilegiile de a acorda sau revoca drepturile asupra obiectului respectiv. Persoana care primește dreptul asupra obiectului are la rândul ei posibilitatea de a acorda acest drept altor persoane. Această procedură se generalizează și prin urmare aceste persoane pot acorda drepturi altor persoane ș.a.m.d. Problema care apare este aceea în cazul revocării drepturilor. Dacă persoana A acordă dreptul persoanei B asupra efectuării unor operațiuni asupra obiectului O, iar B acordă mai departe aceste drepturi persoanei C și A revocă dreptul lui B atunci automat și C pierde dreptul respectiv. De aceea, pentru a executa instrucțiunea REVOKE, sistemul de gestiune va trebui să memoreze ierarhia acordării drepturilor, iar creatorul obiectului se află în rădăcina acestei ierarhii.
Privilegiile acordate utilizatorilor sunt înregistrate într-un catalog sau director al regulilor de autorizare. Există mai multe moduri de a defini aceste cataloage. Cel mai simplu este să specificăm toate privilegiile într-o matrice a autorizărilor. O linie a acestei matrice definește utilizatorul, o coloană definește obiectul, iar elementul matricei de pe linia și coloana respectivă definește operația autorizată. Operația autorizată se specifică prin tipul operației (de exemplu, SELECT, DELETE etc). Uneori alături de tipul operației se precizează un predicat care aduce anumite restricții cu privire la accesul la informație. Ca exemplu să considerăm următoarea matrice a autorizărilor[7]:
Din această matrice aflăm că George are dreptul de a executa operațiuni de actualizare în relația ANG, iar Irina are dreptul de a executa operația SELECT în relația ASIG numai pentru acele tupluri pentru care atributul RESP are valoarea “Manager IT”.
Există mai multe puncte de vedere cu privire la memorarea unei matrice a autorizărilor. Considerăm că cel mai natural mod este acela prin care memorarea se face prin intermediul unei relații ternare de forma ( nume_persoană, obiect, drept).
Controlul autorizării distribuite
Problemele legate de controlul autorizării într-un sistem distribuit rezidă din faptul că entitățile (obiectele, relațiile etc) sunt distribuite. Aceste probleme se referă la autentificarea utilizatorului la distanță, gestiunea regulilor de autorizare distribuită și tratarea vizualizărilor și grupurilor de utilizatori.
Autentificarea utilizatorilor la distanță este necesară deoarece orice nod al unui sistem de gestiune a bazelor distribuite poate accepta programe inițiate în alt nod și autorizate în noduri aflate la distanță. Pentru a preveni accesul unor utilizatori neautorizați, utilizatorul trebuie să fie identificat și autentificat de asemenea în nodul accesat. Sunt posibile două soluții:
Numele utilizatorului și parola acestuia trebuie să se găsească memorate în toate nodurile din catalogul global
Toate nodurile se identifică pe ele însele; în acest fel un utilizator autorizat de un nod n1 identificat de un nod n2 va fi autorizat de nodul n2.
Regulile de autorizare distribuită sunt enunțate la fel ca în cazul autorizării centralizate. Aceste reguli se memorează în catalog și pot fi duplicate pe fiecare nod sau numai pe acel nod care procesează obiectele distribuite solicitate.
O vizualizare a unor obiecte poate fi considerată de asemenea un obiect compus din toate obiectele respective. Prin urmare acordarea drepturilor asupra unei vizualizări se reduce la acordarea drepturilor asupra obiectelor componente. Aici o soluție poate fi legată de acordarea drepturilor de citire de către proprietarul obiectelor, așa cum s-a văzut mai înainte.
Administrarea unei baze de date se poate simplifica dacă utilizatorii sunt grupați în grupe de utilizatori. De obicei toți utilizatorii unei baze formează o clasă numită public. Acest concept se utilizează atât într-un SGBD centralizat cât și în unul distribuit. Însă în cazul distribuit apare un nivel suplimentar care specifică clasa public pentru un nod particular. Clasa public, chiar și pentru un nod particular formează un grup de utilizatori. Desigur se pot defini și alte grupe de utilizatori prin comenzi specifice.
2.2. Integritatea datelor [7]
Protecția bazelor de date constă într-un set de măsuri umane și facilități oferite de SGBD prin care se urmărește asigurarea integrității datelor, care se concretizează prin corectitudinea datelor introduse și manipulate, și a securității datelor, ce vizează interzicerea accesului la date pentru persoanele ce nu au competențe în folosirea lor. Aceasta capătă o importanță deosebită în contextul extinderii folosirii configurațiilor cu număr mare de utilizatori și cu un volum mare de date de prelucrat.
În ceea ce privește protecția datelor, pot fi puse în evidență două tendințe: protecția împotriva unor defecte sau erori accidentale și protecția completă care realizează în plus față de prima și protecția contra unor acțiuni voite. Teoretic, toate sistemele ar trebui să asigure protecția completă a datelor. În practică însă, costul protecției, care crește pe măsură ce sunt reduse posibilitățile de apariție a unor erori și de violare a confidențialității datelor, este cel care dictează complexitatea metodelor de protecție care vor fi utilizate.
Aspectele protecției bazelor de date ce vor fi prezentate în continuare se bazează pe presupunerea că protecția informației la nivelul sistemului de operare este asigurată.
Corespunzător situațiilor care pot genera apariția unor date incorecte în baza de date, se disting trei aspecte ale asigurării integrității datelor:
1. Asigurarea integrității semantice a datelor- presupune prevenirea introducerii unor date incorecte și a efectuării unor prelucrări greșite. Dacă acest lucru nu va fi împiedicat sau semnalat imediat, datele vor fi utilizate în alte prelucrări, declanșându-se astfel un proces necontrolat de alterare a bazei de date.
Cu cât sesizarea unei erori are loc după o perioadă mai mare, cu atât efectele ei vor fi mai greu sau chiar imposibil de înlăturat.
2.Controlul accesului concurent la date – presupune prevenire unor rezultate incorecte din execuția concurentă a unor prelucrări multiutilizator. De exemplu, în cazul a două prelucrări concurente cai în calcularea salariului mediu lunar al angajaților unei firme și respectiv
unui procent de creștere de 10% salariilor angajaților, există riscul ca salariului mediu să intervină valori actualizate și valori vechi ale salariu, rezultatul fiind evident fără semnificație.
3.Salvarea și restaurarea bazei de date – presupun refacerea baza afectată de funcționarea anormală sau căderea SGBD sau SO sau ca urmare a unor defecte hardware.
2.2.1. Integritatea semantică a datelor [7]
Introducerea unor date incorecte sau prelucrările ce furnizează rezultate greșite trebuie prevenite prin includerea în programele de aplicație a unor secvențe de testare a datelor și prin utilizarea unor facilități de asigurare a integrității semantice a datelor oferite de SGBD. Concret, orice operație asupra datelor trebuie constrânsă să respecte anumite reguli, reguli care reprezintă restricții de integritate.
Restricțiile de integritate se pot clasifica, după modul în care sunt exprimate în:
restricții de integritate structurale;
restricții de integritate de comportament.
Restricțiile de integritate structurale decurg din caracteristicile modelului utilizat pentru reprezentarea datelor și din elementele furnizate la structurii bazei de date. Astfel, la introducerea datelor nu vor fi acceptate valorile care nu aparțin tipului de dată specificat pentru câmpurile respective din înregistrare. Dacă există conceptul de cheie unică, la inserare se va verifica unicitatea cheii. Structurile de date pot impune de asemenea rest tipurile de înregistrări. De exemplu, anumite sisteme impun o relație de forma 1:N între părinte și segmente dependente (dacă segmentul rădăcină conține date despre profesori și segmentele dependente date despre cursuri, sistemul impune automat restricția ca fiecare curs să aibă un singur profesor).
În modelul relațional, există două restricții de integritate asociate cheilor primare și celor externe și anume:
1. Integritatea entității (entity integrity) – conform acesteia, nici un atribut care participă la formarea cheii primare a unei relații nu poate primi o valoare NULL (valoare diferită de blanc sau 0, considerată în lipsa unei valori explicite pentru câmpul respectiv).
Aceasta este o consecință a faptului că o cheie primară trebuie să identifice în mod unic tuplurile unei relații.
2. Integritatea referențială (referențial integrity) – statuează că orice valoare a unei chei externe din relația care referă trebuie să aibă corespondentă o cheie primară cu aceeași valoare în relația referită sau să fie NULL.
Restricțiile de integritate de comportament pot fi incluse în programele de aplicație și verificate în momentul execuției acestora sau pot fi memorate în dicționarul datelor și verificate automat de SGBD la fiecare operație vizată asupra anumitor date.
Această soluție, foarte frecventă în practică, prezintă următoarele dezavantaje:
efortul de programare va fi mai mare și dimensiunea programelor va crește prin includerea părților de cod pentru testarea restricțiilor de integritate.
restricțiile de integritate asociate anumitor date trebuie testate de fiecare program care lucrează cu datele respective; o aceeași parte de cod va trebui repetată în toate aceste programe.
programele de aplicație nu pot controla operațiile efectuate de utilizatori în limbajele de interogare de nivel înalt, existând deci în continuare pericolul afectării integrității datelor.
dacă restricțiile de integritate se schimbă, efortul pentru modificarea tuturor programelor implicate va fi foarte mare.
Toate aceste dezavantaje dispar în cazul specificării restricțiilor de integritate la nivelul SGBD. Acestea pot fi exprimate cu ajutorul limbajului de definire a datelor sau al limbajului de manipulare a datelor, în funcție de particularitățile fiecărui SGBD.
În diferite lucrări de specialitate, o regulă de integritate este reprezentată printr-un tuplu forma:
(o, t, c, p, pa)
unde:
o – reprezintă obiectul asupra căruia se aplică restricția de integritate;
t – indică tipul operației pentru care restricția va fi invocată (INSERT, UPDATE, DELETE);
c – este o condiție care trebuie să fie adevărată pentru ca restricția de integritate să se aplice obiectului o (de exemplu, dacă restricția se referă doar la studenții din facultatea cu codul MAT, condiția va fi de de forma COD_S = 'MAT');
p – restricția de integritate, care trebuie să fie adevărată pentru o realizare a obiectului o, pentru ca operația cerută să poată fi efectuată;
pa – o procedură auxiliară care specifică ce trebuie să facă sistemul dacă p nu este adevărată (poate fi utilizată pentru efectuarea de verificări de integritate foarte complexe, pentru realizarea unei jurnalizări selective ca și pentru întreținerea automată a bazei de date).
De exemplu, regula pentru o restricție de integritate care prevede la inserarea unui tuplu într-o relație cu date despre studenții unei facultăți, incrementarea numărului de studenți este:
o – relația STUDENT
t – INSERT
c – true
p – false
pa – NR_STUDENȚI = NR_STUDENȚI + 1
În practică, complexitatea relațiilor de integritate exprimare și de implementare diferă de la un SGBD la altul.
2.2.2. Controlul accesului [7]
Sistemele monoutilizator răspund unui număr redus de probleme practice care implică utilizarea bazelor de date. Cea mai mare parte a aplicațiilor trebuie concepute pentru a putea funcționa în regim de lucru multiutilizator și implementate pe sisteme care prezintă această caracteristică. Pe lângă aspectele prezentate privind asigurarea integrității datelor, în acest caz apare și necesitatea controlului accesului concurent la date.
În sistemele multiutilizator, sistemul de operare asigură accesul concurent al programelor în execuție la resurse după o anumită disciplină internă. În cazul aplicațiilor care utilizează o aceeași bază de date, întreruperea executării unui proces pentru începerea sau continuarea altora poate conduce la alterarea datelor. Asigurarea integrității datelor în acest context presupune existența unor facilități speciale pentru controlul accesului concurent la date la nivelul SGBD. Pentru prezentarea acestora este necesară explicarea conceptului de tranzacție.
Tranzacția este o secvență de operații care din punctul de vedere al SGBD constituie o unitate de prelucrare, aceasta însemnând că se va accepta fie executarea completă fie, în situația în care acest lucru nu este posibil, nu va trebui reținută nici o modificare făcută de ea asupra bazei de date, SGBD efectuând (automat sau la comandă) derularea înapoi a tranzacției.
O tranzacție este caracterizată de punctul său de început și de punctul de sfârșit. După modul în care acestea sunt definite, tranzacțiile se pot clasifica în:
Tranzacții implicite – sunt acelea pentru care punctele de început și sfârșit sunt automat definite. Pentru SQL-Server de exemplu, toate comenzile de modificare a datelor (INSERT, UPDATE și DELETE) sunt tratate ca tranzacții implicite. În consecință, nici una dintre aceste comenzi nu va putea lăsa baza de într-o stare inconsistentă. Acest lucru este ilustrat prin exemplul 10.1.
Tranzacții explicite – presupun folosirea unor comenzi speciale pentru stabilirea punctelor de început și sfârșit ale tranzacției. În SQL – Server, tranzacțiile explicite permit utilizatorului să grupeze un set de comenzi SQL într-o tranzacție folosind comenzile BEGIN TRANSACTION și COMMIT TRANSACTION pentru precizarea punctelor de început și sfârșit. De asemenea, utilizatorul poate defini puncte de salvare (utile în cazul tranzacțiilor foarte mari) folosind comanda SAVE TRANSACTION sau să deruleze înapoi tranzacția până la punctul de început sau până la puncte de salvare anterioare, folosind comanda ROLLBACK TRANSACTION.
Exemplu: O tranzacție explicită poate fi reprezentată de înregistrarea unui transfer între două conturi, fapt ce presupune debitarea contului X și creditarea contului Y. Aceste transformări vor fi grupate între comenzile BEGIN TRANSACTION și COMMIT TRANSACTION. Tranzacția fiind astfel definită, SGBD va garanta tratarea ei ca o secvență unitară de prelucrări.
BEGIN TRANSACTION
Debit -100 din CONTUL X
Credit +100 în CONTUL Y
COMMIT TRANSACTION
În anumite condiții, utilizatorul poate comanda derularea înapoi a tranzacției. Un exemplu îl constituie o tranzacție care realizează creșterea selectivă a valorilor dintr-o coloană a unei tabele, urmărindu-se menținerea unei limite pentru media acestor valori. În situația în care această limită nu va fi respectată în urma modificărilor făcute, acestea vor fi anulate.
Prin controlul accesului concurent la date se urmărește păstrarea integrității de date în condițiile execuției concurente a tranzacțiilor.
2.3. Tehnica blocării [7]
Aspectele prezentate sunt deci o consecință a execuției concurente necontrolate a tranzacțiilor. Execuția serială a tranzacțiilor (una după alta), care ar asigura consistența bazei de date, nu este posibilă în regim multiutilizator. Ea stă însă la baza criteriului formal de apreciere a efectelor execuției concurente a tranzacțiilor. Conform acestuia, o execuție neserială a unor tranzacții concurente va fi considerată corectă dacă este serializabilă, adică dacă produce același rezultat ca o execuție serială a acelor tranzacții. Dacă SGBD va asigura doar execuții serializabile ale tranzacțiilor, atunci consistența datelor va fi garantată.
Tranzacțiile considerate trebuie să fie independente, astfel ca orice execuție serială a lor să furnizeze același rezultat. În caz contrar, utilizatorul trebuie să se asigure că ele sunt date sistemului în secvența dorită.
Tehnica utilizată de SGBD pentru a asigura execuția serializabilă a tranzacțiilor tehnica blocării. În cea mai simplă formă, blocarea unor date de către o tranzacție interzice celorlalte tranzacții accesul la aceste date. Blocarea se poate aplica la nivelul întregii baze de date, al unui fișier, grup de înregistrări sau înregistrare sau chiar câmp. Generic, în continuare vom vorbi despre resursa sau obiectul blocat.
Soluția de blocare prezentată este prea restrictivă, ea fiind însă folosită de anumite SGBD. În exemplele prezentate, observăm că trebuie urmărite două aspecte:
– accesul la datele pe care un utilizator intenționează să le actualizeze să fie interzis celorlalți utilizatori până la completarea procesului de actualizare;
– accesul la datele pe care un utilizator le citește fără a le actualiza să fie interzis utilizatorilor pentru operații de actualizare și permis pentru operații de citire.
Deci tipul de blocare trebuie diferențiat în funcție de operația care va fi executată asupra datelor respective astfel:
– blocare pentru citire (partajabilă) – datele vor putea fi folosite și de către ceilalți utilizatori însă numai pentru operații de citire;
– blocare pentru scriere (exclusivă) – datele nu vor putea fi accesate de nici un utilizator.
Efectiv, blocarea se realizează prin emiterea de către o tranzacție a unei cereri (explicite sau implicite) de blocare pentru SGBD. Cererea explicită poate fi exprimată în una din următoarele forme:
– în cadrul unei comenzi de manipulare a datelor:
UPDATE ANGAJAȚI WITH EXCLUSIVE LOCK
SET SALARIU = SALARIU *1.1
– printr-o comandă de început a unei tranzacții:
BEGIN TRANSACTION WITH EXCLUSIVE LOCK
BEGIN TRANSACTION WITH SHARED LOCK
– printr-o comandă de deschidere a unui fișier :
OPEN FIȘIER FOR EXCLUSIVE UPDATE
OPEN FIȘIER FOR SHARED READ
Dacă cererea este admisă, tranzacția va continua. Altfel, cererea va fi pusă într-olistă de așteptare până ce resursa vizată va fi eliberată.
Situațiile în care o cerere pentru o anumită resursă poate fi admisă, în condițiile în care există deja o blocare pentru resursa respectivă, sunt ilustrate de matricea compatibilității blocărilor partajabile și exclusive din fig. 2.3.
Fig. 2.3. Matricea compatibilităților
Se observă deci că o blocare pentru citire poate fi acordată altor tranzacții chiar dacă o tranzacție are deja o blocare partajabilă pentru resursa respectivă; blocări exclusive nu pot fi însă acordate până când toate blocările partajabile nu sunt eliberate. Dacă însă o tranzacție a obținut o blocare exclusivă pentru o resursă, nici o altă blocare (partajabilă sau exclusivă) nu va mai putea fi garantată celorlalte tranzacții solicitante.
Accesul concurent la date pe de o parte și complexitatea mecanismului de blocare al unui SGBD pe de altă parte, sunt influențate de granularitatea blocarii. Considerând cele două situații extreme (baza de date și câmpul), putem sintetiza următoarele aspecte:
– blocarea întregii baze de date la o anumită operație a utilizatorului îi pune pe ceilalți utilizatori în imposibilitatea de a accesa concurent datele, în timp ce gestiunea informațiilor de blocare se simplifică foarte mult;
– blocarea unui singur câmp al unei înregistrări lasă posibilitatea de acces concurent celorlalți utilizatori chiar la câmpuri ale aceleiași înregistrări, însă face ca gestionarea informațiilor de blocare să fie foarte complexă.
Cele mai multe SGBD oferă posibilitatea blocării la nivel de înregistrare, la nivelul unui grup de înregistrări pentru care s-a menționat un criteriu de selecție și la nivel de fișier. Pentru administrarea blocărilor se poate recurge la unul din următoarele moduri:
– setarea unui bit pentru resursa respectivă, indicându-se astfel că aceasta este blocată;
– menținerea unei liste a resurselor blocate ce va trebui consultată ori de câte ori intervine o nouă cerere de blocare;
– menținerea resurselor blocate într-o zonă specială a memoriei.
2.3.1. Interblocarea resurselor[7]
Interblocarea (deadlock) este un impas care rezultă când două tranzacții blochează anumite resurse, apoi solicită fiecare resursele blocate de cealaltă. Această situație este ilustrată în fig. 10.4.
Tranzacția A va aștepta la infinit eliberarea resursei Y, blocată de tranzacția B la pasul 2 și, la rândul ei, tranzacția B va intra într-o stare de așteptare infinită pentru resursa X, blocată de A la pasul 1.
La nivelul SGBD trebuie să existe facilități de prevenire sau rezolvare a acestor situații. Astfel, poate fi implementată una din următoarele două strategii:
1.Prevenirea interblocării – presupune ca programele să blocheze toate resursele de care au nevoie încă de la începutul fiecărei tranzacții. În exemplul considerat, tranzacția A ar tebui să blocheze ambele înregistrări încă de la început. Dacă una din resurse ar fi fost deja blocată, ar fi fost necesar să se aștepte până la eliberarea ei.
Această strategie este dificil de implementat și adesea nu este aplicată, deoarece în cele mai multe cazuri, este imposibil de precizat înainte ce resurse vor fi necesare pentru o tranzacție.
Tranzactia A Resurse Tranzactia B
1
Blocare
Asteptare pana la elib. 4
3 resursei x
Asteptare pana la elib. 2
resursei y Blocare
Fig. 10.4 Exemplu de interblocare
2. Soluționarea interblocării – această strategie permite apariția interblocării dar presupune existența unor mecanisme pentru detectarea și eliminarea acesteia. Intern, sistemul poate utiliza pentru aceasta un graf al precedențelor care reflectă dependențele dintre procese din punctul de vedere al ordinii în care acestea trebuie executate. Într-un astfel de graf, fiecare nod reprezintă un proces activ. Arcele se trasează conform următoarei reguli: dacă procesul P deține resursa A și procesul Q o solicită, atunci în graf va fi trasat arcul Q P, care arată că execuția procesului Q este condiționată de cea a procesului P. Existența unui interblocaj va fi semnalat prin prezența unui ciclu în graf. Fig. 10.5. prezintă un astfel de graf și matricea asociată lui.
Fig.10.5 Graf și matricea asociată lui
În matrice, cifra 1 arată că procesul de pe linia respectivă se află în așteptare din cauza procesului de pe coloana corespunzătoare. Algoritmul pentru determinarea interblocajului este următorul:
1. Se efectuează operația logică "SAU" între vectorii asociați liniilor matricei. Rezultatul va fi vectorul V1.
2. Se efectuează operația logică "SAU" între vectorii asociați coloanelor matricei. Rezultatul va fi vectorul V2;
3. Se efectuează operația "SI" între V1 și V2. Rezultatul va fi vectorul V3. Procesele S și R pentru care s-a obținut rezultatul 0 (vezi figura) vor fi eliminate din matrice. Ele nu pot fi implicate într-un blocaj întrucât S nu așteaptă după nici un alt proces (0 pe poziția corespunzătoare din V1) și după R nu așteaptă nici un alt proces (0 pe poziția corespunzătoare din V2);
4. Se elimină liniile și coloanele corespunzătoare proceselor R și S și se reia algoritmul de la pasul 1, până când nici un proces nu va mai fi eliminat. Procesele rămase în matrice vor fi cele între care a intervenit un interblocaj.
În această situație, unul dintre procesele implicate va fi întrerupt, efectele lui de până acum asupra bazei de date vor fi anulate, fiind posibilă apoi continuarea celuilalt. Procesul ce va fi eliminat poate fi:
– procesul cu cele mai puține resurse blocate;
– procesul care nu a făcut încă actualizări asupra bazei de date ;
– procesul cu cea mai mică prioritate;
– procesul cel mai recent început;
– procesul cel mai vechi;
– procesul care a cerut ultimul utilizarea resursei. Procesul abortat urmează să fie reluat ulterior.
2.4. Salvarea si restaurarea bazei de date [7]
Salvarea și restaurarea bazei de date au ca scop readucerea datelor la o formă consistentă în urma unor evenimente care au alterat corectitudinea lor precum:
– funcționarea anormală sau o cădere a SGBD sau SO;
– o defecțiune a suportului fizic pe care este memorată baza de date.
În primul caz, prin întreruperea tranzacțiilor active în momentul respectiv, baza de date va rămâne într-o stare de inconsistență. în cel de-al doilea caz, suportul pe care rezidă baza de date va fi inutilizabil, deci toate datele se vor pierde.
În aceste situații trebuie să fie posibilă refacerea unei stări anterioare consistente a bazei de date. O stare consistentă a bazei de date este starea în care sunt reflectate rezultatele finale ale execuției unor tranzacții, nici o tranzacție nu este în curs de execuție și sunt satisfăcute restricțiile de integritate semantică.
Îndeplinirea cerinței formulate anterior presupune existența și utilizarea unor facilități la nivelul SGBD. Acțiunile întreprinse în acest sens se înscriu în procesul de restaurare al bazei de date.
2.4.1 Tehnici de bază utilizate în operatia de restaurare [7]
O cădere a sistemului lasă baza de date într-o stare de inconsistență care poate consitui un punct de plecare în procesul de restaurare, în timp ce, în cazul unei defecțiuni a suportului pe care este memorată baza de data, restaurarea va fi posibilă doar dacă există o copie anterioară a bazei de date. Pe aceste baze deci, procesul de restaurare va trebui să asigure o stara consistentă a bazei de date, minimizând totodată volumul prelucrărilor pierdute.
Pentru baza de date inconsistentă, aceasta înseamnă eliminarea efectelor tranzacțiilor active în momentul căderii sistemului și reflectarea în baza de date a rezultatelor tranzacțiilor terminate, dar care din motive ce vor fi prezentate ulterior nu apar în baza de date. Pentru o copie anterioară a bazei de date, va trebui să existe posibilitatea ca într-un timp cât mai scurt aceasta să fie adusă la o stare consistentă cât mai apropiată de momentul apariției defecțiunii.
În ambele situații este necesară existența unor informații despre derularea tranzacțiilor până în momentul întreruperii lucrului și aplicarea după caz a uneia din următoarele tehnici de restaurare de bază:
– derularea înapoi a tranzacțiilor necompletate (ROLLBACK) – care presupune anularea modificărilor efectuate de acestea asupra bazei de date;
– derularea înainte a tranzacțiilor completate dar nereflectate în baza de date (ROLLFORWARD) – care presupune efectuarea acelor transformări prin care baza de date restaurată să conțină rezultatele acestora.
Se observă deci că tranzacția poate fi considerată unitatea de restaurare, în sensul că baza de date restaurată trebuie fie să reflecte rezultatele finale ale tranzacțiilor, fie să nu fie afectată de acestea.
Procesul de restaurare utilizează o serie de informații obținute prin aplicarea unei anumite strategii de salvare.
Salvarea, în contextul asigurării integrității bazei de date, este procesul de stocare de date în vederea folosirii lor pentru restaurarea bazei de date. Volumul informațiilor ce se salvează, natura lor și intervalul de timp dintre două operații succesive de salvare, determină strategia de salvare. Aceasta va influența procesul de restaurare a bazei de date. Astfel, stocarea unei cantități mari de date, cu o frecvență mare și în forme diferite (ceea ce are ca efect întreruperi ale lucrului sau mărirea timpului de răspuns în exploatarea bazei de date) face posibilă restaurarea simplă și rapidă a bazei de date. în caz contrar, cu cât informațiile de care dispunem sunt mai sărace, cu atât procesul de restaurare va fi mai complicat și de durată.
Datele salvate pot fi diferite combinații între:
– copii ale bazei de date și copii ale jurnalelor acesteia;
– jurnale ale tranzacțiilor;
– jurnale ale imaginii înregistrărilor din baza de date.
Copiile bazei de date pot fi realizate automat de către sistem la anumite intervale de timp, sau la comanda administratorului bazei de date, ori de câte ori este nevoie, de preferat pe suporturi magnetice diferite de cele pe care rezidă baza de date. În cazul unei deteriorări a discului care păstrază baza de date, acestea constituie singura posibilitate de recuperare a bazei de date. Ele pot fi utilizate însă ca unică sursă de date în procesul de restaurare doar în situația în care prelucrările efectuate între momentul realizării copiilor și cel al apariției unei defecțiuni pot fi reluate. Acest lucru este posibil dacă prelucrările sunt efectuate într-o secvență cunoscută și timpul necesar pentru reprocesarea lor nu este foarte mare sau poate fi acceptat în contextul de lucru particular. Această limită, ca și rata mare a executării unor astfel de copii face ca anumite SGBD să recurgă la efectuarea de copii ale jurnalelor bazelor de date. Volumul datelor ce vor fi copiate este în acest caz mult mai mic, deci durata copierii va fi mai mică, iar procesul de restaurare implică doar într-o mică măsură intervenția umană.
Jurnalul tranzacțiilor este un fișier special întreținut de SGBD, în cure sunt memorate informații despre tranzacțiile efectuate asupra bazei de date, cum ar fi:
– identificatorul sau codul tranzacției;
– momentul începerii execuției tranzacției;
– numărul terminalului sau identificatorul utilizatorului care a inițiat tranzacția;
– datele introduse;
– înregistrările modificate și tipul modificării.
Pe baza lui va putea fi stabilită ulterior succesiunea corectă și natura prelucrărilor efectuate în intervalul de timp pentru care trebuie să se asigure restaurarea bazei de date.
Jurnalul imaginilor se deosebește de jurnalul tranzacțiilor prin aceea că el nu conține descrierea operațiilor efectuate asupra bazei de date ci efectul acestora. Poate îmbrăca una din următoarele forme:
-jurnalul cu imaginea înregistrărilor după modificare (after image) – va conține copia fiecărei înregistrări ce este modificată în forma rezultată după modificare;
– jurnalul cu imaginea înregistrărilor înaintea unei modificări (before image)-va cuprinde copia fiecărei înregistrări ce este modificată în forma inițială, anterioară efectuării modificării;
– jurnal care conține pe cele două de mai sus.
În prima formă, jurnalul imaginilor permite restaurarea bazei de date prin derularea înainte a tranzacțiilor într-un timp mai scurt decât în cazul utilizării jurnalului tranzacțiilor. Nu mai este necesară reprocesarea tranzacțiilor, putând fi utilizat direct rezultatul acestora, reprezentat de ultima imagine modificată a înregistrării respective. În mod similar, cea de-a doua formă a jurnalului imaginilor va putea fi utilizată pentru derularea înapoi a tranzacțiilor, fiind necesară doar regăsirea înregistrării memorate la începutul fiecărei tranzacții. Derularea înapoi a tranzacțiilor este foarte dificilă și uneori chiar imposibilă dacă se folosește doar jurnalul tranzacțiilor. Cea de-a treia formă facilitează mult procesul de restaurare, însă presupune menținerea unui volum mare de informații redundante (pentru o înregistrare ceea ce constituie after image după o modificare va deveni before image la următoarea modificare).
În funcție de defecțiunea care a determinat întreruperea lucrului, restaurarea bazei de date se realizează automat de către SGBD, sau manual, înțelegând prin aceasta că procesul de restaurare va necesita intervenția umană.
2.4.2 Restaurarea automată a bazei de date [7]
Restaurarea automată este determinată de SGBD după oprirea și restartarea sistemului în urma unei căderi. Prin acest proces, baza de date este adusă la o stare consistentă, prin derularea înapoi a tranzacțiilor active în momentul defecțiunii și continuarea tranzacțiilor înregistrate ca finalizate în fișierul jurnal, dar care nu sunt încă reflectate în baza de date.
Situația în care efectele unei tranzacții completată înaintea căderii nu se regăsesc în baza de date ca și existența informațiilor necesare pentru restaurare în fișierele jurnal sunt explicate de modul în care este gestionată memoria principală.
O cerere de aceea la date primită de SGBD va determina transferul unei pagini de disc în memoria principală. Eventualele modificări ale datelor, aflate acum în memoria principală, nu vor fi urmate imediat de rescrierea paginii respective pe disc. Acest lucru poate fi efectuat periodic, la un anumit interval de timp, fie la o cerere explicită a sistemului sau pentru a face loc unei alte pagini de disc solicitată.
Inlocuirea cu o altă pagină are la bază un algoritm de tipul LRN (least-recently-used). Astfel, va fi aleasă pentru a fi înlocuită pagina de la a cărei ultimă actualizare s-a scurs cel mai mare interval de timp. Cu excepția situației în care este necesară înlocuirea unei pagini, rezultă că paginile frecvent utilizate vor fi menținute în memorie, ceea ce duce la reducerea numărului de operații de transfer între memoria principală si suportul extern de memorie, deci la creșterea performanțelor sistemului.
Același regim de păstrare în memorie până la un transfer ulterior pe disc se aplică și informațiilor de jurnalizare a tranzacțiilor. SGBD trebuie însă să asigure înscrierea acestor informații în fișierul jurnal înainte de scrierea datelor modificate în baza de date. Dacă această ordine nu ar fi respectată, o cădere a sistemului după scrierea în baza de date dar înainte de înregistrarea transformărilor respective în jurnal, ar face imposibilă derularea înapoi a tranzacțiilor, cu alte cuvinte, chiar procesul de restaurare al bazei de date. De asemenea, paginile de memorie cu informațiile de jurnalizare a tranzacțiilor, vor fi scrise pe disc automat în momentul execuției unei comenzi de genul COMMIT TRANSACTION. Astfel se explică cum o tranzacție finalizată nu este reflectată de baza de date și cum jurnalul tranzacțiilor poate oferi informațiile necesare procesului de restaurare automată a bazei de date.
În afara aspectelor prezentate, sincronizarea memoriei cu baza de date și fișierul jurnal se realizează și prin executarea unui punct de verificare (checkpoint). SGBD poate executa puncte de verificare automat, la intervale fixe de sau ca răspuns la o comandă explicită CHECKPOINT. Frecvența punctelor de verificare influențează durata procesului de restaurare automată a bazei de date. Aceasta din urmă este direct proporțională cu activitatea tranzacțională a bazei de date desfășurată de la cel mai recent punct de verificare până la căderea sistemului. Restaurarea rapidă a bazei de date va necesita deci o frecvență mare a punctelor de verificare.
Un punct de verificare presupune executarea următoarelor operații:
– înghețarea proceselor active la momentul respectiv;
– forțarea scrierii paginilor de memorie în jurnale și apoi în baza de date;
– scrierea unei înregistrări speciale în jurnalul tranzacțiilor, necesară la restaurare și reluarea prelucrărilor, care indică:
-starea fiecărui proces activ din momentul executării punctului de verificare;
– starea fișierelor temporare de lucru;
– pozițiile în fișierele secvențiale;
– pointeri la cozile de mesaje;
– continuarea proceselor anterior înghețate.
La nivelul SGBD pot exista parametrii de configurare care să influențeze procesul de restaurare automată.
Pentru SQL – Server de exemplu, aceștia sunt:
1. Intervalul de restaurare – reprezintă timpul maxim admis pentru efectuarea restaurării automate în momentul încărcării sistemului. Valoarea acestui parametru este folosită de SGBD în calculul frecvenței de executare a punctelor de verificare, calcul realizat pe baza unui algoritm special. Valoarea implicită a intervalului de restaurare este de 5 minute, ea putând fi modificată în limitele intervalului 1 – 32767 minute.
2. Indicatorul de restaurare – determină ce informații va scrie SGBD în fișierul de erori (error log file) în timpul restaurării automate. Valoarea implicită este 0, în acest caz informațiile rezumându-se la device-ul folosit, baza de date ce este supusă procesului de restaurare, numărul tranzacțiilor derulate înainte și a celor derulate înapoi. Parametrul poate fi setat pe valoarea 1, și astfel informațiile vor include detalii despre modul în care este tratată fiecare tranzacție.
Ambii parametrii pot fi modificați folosind meniurile unui program utilitar SAF (Server Administration Facility) sau prin apelarea procedurii de sistem SP-configure, ca în exemplul următor:
Sp_configure " recovery interval", 4
Sp_configure " recovery flag", 1
reconfigure
Exemplul realizează setarea intervalului de restaurare la 4 minute și ba indicatorului de restaurare la valoarea 1. Comanda de reconfigurare este necesară deoarece setarea indicatorului de restaurare nu are efect deâct după reîncărcarea sistemului. Dacă se doresc informații deepre valorile celor 2 parametrii. Pot fi folosite primele după comenzi în forma:
sp_configure "recovery interval"
sp_configure "recovery flag"
2.4.3. Restaurarea manuală a bazei de date [7]
Restaurarea manuală, denumită astfel pentru că implică intervenție umană și nu pentru că ar fi un proces manual, este necesară în situația distrugerii suportului de memorie externă pe care rezidă baza de date.
În anumite SGBD, acest proces se bazează doar pe efectuarea de copii de siguranță ale bazei de date. Restaurarea va consta în încărcarea celei mai recente copii a bazei de date și reluarea prelucrărilor efectuate din momentul copierii până la producerea defecțiunii.
Pentru realizarea acestor copii se poate recurge la una din următoarei modalități:
1. Cea mai simplă și mai utilizată necesită deconectarea tuturor utilizatorilor de la baza de date, efectuarea copiei, după care utilizatorilor le este permisă reconectarea la baza de date și reluarea lucrului.
2. Mai eficientă, dar necesitând un cost de implementare mai mare, este efectuarea copiilor în mod dinamic, în timp ce utilizatorii accesează baza de date. Această facilitate este utilă în regim de lucru on-line, realizarea copiei fiind transparentă pentru utilizatori. O astfel de copie a bazei de date determina executarea automată a unui punct de verificare. Copia va reflecta starea bazei date din momentul respectiv, inclusiv efectele tranzacțiilor în curs de execuție. SGBD va realiza automat derularea înapoi a acestor tranzacții în procesul încărcării bazei de date, obținându-se astfel o stare consistentă a acesteia.
Timpul consumat de o operație de copiere, dependent de mărimea bazei de date ca și de metoda de copiere utilizată (la nivelul logic sau la nivel fizic), determină stabilirea frecvenței de realizare a copiilor, care are implicații asupra duratei procesului de restaurare. Astfel, cu cât copia bazei de date de care dispunem va fi mai recentă, cu atât restaurarea va fi mai rapidă.
Restaurarea manuală poate fi facilitată dacă, pe lângă copii de siguranță ale bazei de date, SGBD permite și efectuarea de copii ale fișierului jurnal, durnta de realizare a acestora fiind redusă. Acestea se efectuează dinamic și incremental (nu vor conține informații redundante). În intervalul dintre două copieri ale bazei de date se vor realiza mai multe copii ale fișierului jurnal, fiecare dintru aceste reprezentând, din punct de vedere al informațiilor conținute, o continuare a cel anterioare.
Efectuarea unei astfel de copii presupune execuția automată a unui punct de verificare, deci sincronizarea memoriei cu fișierul jurnal și cu baza de date. Tranzacțiile inactive din jurnal (cele pentru care s-a executat COMMIT TRANSATION înaintea punctului de verificare, deci sunt reflectate în baza de date) vor fi șterse din fișier. Procesul de restaurare va presupune încărcarea celei mai recente copii a bazei de date, urmată de încărcarea copiilor jurnalului în ordinea în care au fost efectuate și actualizarea bazei de date pe baza acestora. Restaurarea va avea ca efect recrearea bazei de date din momentul reflectat de informațiile din ultima copie a jurnalului tranzacțiilor.
Exemplificând pentru SQL – Server, SGBD cu facilități puternice pentru restaurarea bazelor de date, procesul de restaurare manuală va consta în (fig. 2.6.):
t0 t1 t2 t3 t4 t5
timp
DUMP DUMP DUMP LOAD DATABASE
DATABASE TRANSACTION TRANSACTION LOAD TRANSACTION A
LOAD TRANSACTION B
Fig. 2.6 Restaurarea manuală a bazei de date
1. Realizarea de copii de siguranță
– efectuarea unei copii dinamice a bazei de date, prin comandă-
DUMP DATABASE baza TO dumpdev(momentul t0)
– efectuarea de copii ale jurnalului tranzacțiilor
DUMP TRANSACTION baza TO discdumpa(momentul t1)
DUMP TRANSACTION baza TO discdumpb(momentul t2)
2. Restaurarea bazei de date pe baza copiilor anterioare în urma incidentului de la momentul t3 (presupunem că un nou disc a fost instalat și s-a alocat spațiu pentru baza de date)
– încărcarea copiei bazei de date
LOAD DATABASE baza FROM dumpdev
– încărcarea copiilor jurnalelor tranzacțiilor în ordinea în care au fost executate:
LOAD TRANSACTION baza FROM discdumpa
LOAD TRANSACTION baza FROM disdumpb
2.5. Independența datelor [4],[7]
Prin independența logică se înțelege capacitatea schimbării schemei concep-tuale fără a atrage după sine schimbări în schema externă sau în programele de aplicație. Este posibilă schimbarea schemei conceptuale prin expandarea bazei de date ca urmare a adăugării de noi tipuri de înregistrări sau a datelor insăși, sau prin reducerea bazei de date ca urmare a reducerii înregistrărilor. Schema conceptuală după aceste operații se referă la schema conceptuală a datelor existente. Un exemplu de expandare al bazei de date este cel de adăugare a unei noi coloane la un tabel.
Independența fizică este reprezentată prin capacitatea de schimbare a schemei interne fără schimbarea schemei conceptuale sau externe. Schimbarea schemei conceptuale poate surveni ca urmare a reorganizării fizice a unor fișiere, prin crearea de noi structuri de acces menite să asigure accesul eficient la date. Dacă sistemul conține SGBD pe mai multe niveluri, catalogul trebuie să reflecte modul în care diverse cereri se imple-mentează la fiecare nivel. Motivele prezentate mai sus pledează pentru utilizarea arhitecturii pe trei nivele.
2.6 Drepturi si Privilegii [4]
Tipurile de privilegii oferite de diverse SGBD sunt foarte variate; în esență însă, ele includ dreptul de a citi date, a scrie date, a crea noi structuri de date (exemplu: baza de date sau tabele într-o bază de date existentă) și dreptul de a executa anumite programe. Privilegiile pot fi garantate implicit (de exemplu, administratorul unei bd poate avea automat dreptul de a crea noi tabele în baza de date, creatorul unei tabele să scrie și să citească conținutul ei etc.) sau explicit (de exemplu, administratorul unei baze de date poate garanta unor utilizatori dreptul de a crea tabele, altora doar pe cel de a scrie în tabelele existente, unora doar de a le citi, iar restului de utilizatori le poate interzice până și citirea).
Privilegiile sunt de obicei asociate:
tuturor utilizatorilor autorizați (“publicul”); de exemplu, majoritatea datelor utilizate în comun de toți utilizatorii unei bd pot fi oricui accesibile în citire (i.e. datele “publice”, despre tranzacții bursiere, cursul valutelor, mersul trenurilor sau al avioanelor, cartea de telefon etc.);
tuturor utilizatorilor dintr-un grup (definit de administratorul bazei de date); de exemplu, toți angajații serviciului de contabilitate al unei firme ar putea alcătui un asemenea grup; privilegiile garantate grupului (de obicei de scriere/citire în anumite tabele și doar de citire în altele) sunt moștenite de toți membri acestuia (acest tip de privilegiere grupată având, evident, două mari avantaje: poate modela fidel organigrama firmelor și simplifică munca administratorului bazei de date);
tuturor utilizatorilor sistem; de exemplu, pe lângă privilegiul de a avea acces nelimitat la toate datele, acest grup sistem are și dreptul de a garanta anumitor grupuri sau utilizatori privilegiile de acces la baza de date, eventual și pe cel de a transmite acest drept (total sau parțial) altor utilizatori;
creatorilor (proprietarilor) de obiecte; de exemplu, creatorului unei tabele i se poate garanta nu doar dreptul de a scrie/citi tabela respectivă, ci și cel de a garanta la rândul lui privilegii altor utilizatori asupra tabelei sale;
utilizatorilor individuali; de exemplu, unui utilizator oarecare U, i se poate garanta cu titlu individual (pe lângă eventualele alte drepturi pe care le-ar avea ca membru în unul sau mai multe grupuri) dreptul de a scrie/citi (și) în tabela T.
Privilegiile se pot acorda în unele SGBD doar pentru porțiuni din tabele. De exemplu, orice angajat ar putea citi datele despre colegii săi de colectiv, cu excepția salariului (accesibil doar șefului de colectiv), fără însă a avea acces la datele despre ceilalți angajați ai firmei. SGBD relaționale pot oferi asemenea privilegii parțiale foarte ușor prin intermediul “punctelor de vedere” (“view”) diferite asupra datelor.
2.7 Criptarea datelor și verificarea accesului [4]
Pe lângă conturi, parole și privilegii de acces la date, unele SGBD oferă mecanisme suplimentare de asigurare a securității datelor. De exemplu, pentru ca datele să nu poată fi modificate sau citite fără a cunoaște o parolă suplimentară, se codifică (criptează) datele înainte de scrierea lor pe disc. SGBD evoluate oferă chiar posibilitatea codificării folosind proceduri de criptare definite de utilizatori.
Unele SGBD mențin în plus “dâre de verificare” (“audit trails”), jurnale în care memorează toate activitățile din sistem (inclusiv eventualele tentative de acces neautorizat). Se pot astfel verifica utilizatorii care au modificat (poate chiar criminal!) datele sau au încercat să violeze interdicțiile de acces.
Niveluri de acces utilizator în baze de date distribuite`[4]
Ierarhie pe patru niveluri de tipuri de acces oferite utilizatorilor, care a devenit între timp aproape un standard în domeniu:
Cereri de la distanță: utilizatorii pot citi și modifica date într-un server aflat la distanță, dar este permisă o singură instrucțiune SQL per tranzacție și per server (deci o instrucțiune nu poate implica decât un server);
Unitatea de lucru de la distanță: utilizatorul poate citi și modifica date într-un server aflat la distanță, dar este permisă o unică tranzacție, ce poate fi alcătuită din oricâte instrucțiuni SQL, implicând însă doar acel server;
Unitatea de lucru distribuit: utilizatorii pot citi și scrie date în mai multe servere per tranzacție, cu condiția ca orice instrucțiune SQL a tranzacției să facă apel la un singur server; actualizarea datelor pe mai multe servere presupune utilizarea protocolului terminării în două faze;
Cereri distribuite: utilizatorii pot citi și scrie date în mai multe servere per tranzacție; orice instrucțiune SQL a tranzacției poate face apel la oricâte servere; actualizarea datelor pe mai multe servere presupune utilizarea protocolului terminării în două faze; optimizarea globală este necesară (în special pentru operații join și reuniune multi-server).
CAPITOLUL 3
STUDIU COMPARATIV PRIVIND SECURITATEA DATELOR IN BAZELE DE DATE
3.1. Restricții de integritate [1],[2], [3]
Menținerea integrității datelor este, de departe, cea mai importantă sarcină permanentă a oricărui SGBD. Ca atare, sunt oferite diverse mecanisme de verificare a consistenței datelor și de impunere a constrângerilor de integritate. Ne vom focaliza din nou atenția numai asupra celor mai des întâlnite asemenea mecanisme.
Cea mai simplă verificare cu putință este cea de încadrare a tuturor valorilor pe care le au datele fiecărei coloane a oricărei tabele dintr-o bază de date într-un interval de valori (explicit precizat de administratorul bazei de date pentru datele fundamentale sau implicit, pentru cele derivate). SGBD relaționale oferă în acest scop cel puțin două mecanisme suport pentru integritatea domeniilor (de valori) și integritatea referințelor.
Relațiile unei baze de date reflectă realitatea modelată și de aceea valorile pe care le conțin trebuie să respecte anumite reguli, care să corespundă celor din realitate.
Constrângerile de integritate (integrity constraints) [2] sunt reguli care se definesc la proiectarea unei bazei de date și care trebuie să fie respectate de orice stare a acesteia.
Din punct de vedere al locului unde sunt definite, constrângerile pot fi constrângeri intra-relatie si constrângeri inter-relatii. Constrângerile intra-relatie sunt reguli care se impun în cadrul unei singure relații si asigură integritatea datelor acesteia. Ele sunt, la rândul lor, de trei categorii: constrângeri de domeniu, constrângeri de tuplu și constrângeri impuse prin dependențe de date (dependențe funcționale, multivalorice sau de joncțiune).
Constrângerile inter-relatii sunt reguli care se impun între două sau mai multe relații. Cele mai importante constrângeri inter-relatii sunt constrângerile de integritarea referentială, care se realizează prin intermediul cheilor straine si asigură asocierea corectă a relațiilor.
Din punct de vedere al modului de definire, constrângerile unei baze date pot fi inerente, implicite si explicite.
Constrângerile inerente sunt cele ale modelului de date însusi, care nu trebuie sa fie specificate la definirea relațiilor, dar sunt respectate prin modul în care se construiesc relatiile.
Constrângerile implicite sunt cele reprezentate în mod implicit în schemele relatiilor prin intermediul instrucțiunilor de definire a datelor. Pentru fiecare model de date există un set de constrângeri implicite care se definesc odată cu definirea schemelor de date ale acestuia. Pentru modelul relațional, constrângerile de domeniu, constrângerile de tuplu si constrângerile de integritate referențială sunt exemple de constrângeri implicite. Constrângerile implicite sunt memorate în baza de date și sistemul de gestiune impune automat respectarea acestora.
Constrângerile explicite sunt constrângeri suplimentare pe care trebuie să le respecte relațiile unei baze de date si care nu sunt impuse automat de sistemul SGBD, ci prin proceduri speciale.
Constrângerile de domeniu[2] sunt condiții impuse valorilor atributelor, astfel încât acestea să corespundă semnificației pe care o au în realitatea modelată. Dat fiind că, în reprezentarea unei relații printr-un tabel, valorile atributelor sunt reprezentate pe coloane, constrângerile de domeniu se mai numesc și constrângeri de coloană. Dintre constrângerile de domeniu, constrângerea NOT NULL si constrângerea de valoare implicita (DEFAULT) sunt constrângeri cu caracter mai general, care se pot aplica oricarui atribut; constrângerea de verificare (CHECK) se poate aplica unor anumite atribute, în functie de semnificatia acestora.
Constrângerile de tuplu: cheia primara și chei secundare[2]. O relatie este definita ca o multime de tupluri, deci tuplurile unei relatii trebuie sa fie distincte. Aceasta înseamna ca într-o relatie nu pot exista doua (sau mai multe) tupluri care sa contina aceeași combinatie de valori ale tuturor atributelor. De obicei, într-o schema de relatie exista o submultime de atribute SK cu proprietatea ca, în orice stare s-ar afla relatia, nu exista doua tupluri distincte ale relatiei care sa aiba aceeași combinatie de valori ale atributelor submultimii respective.
O supercheie (superkey) a unei relatii este o submultime (SK) de atribute ale relatiei care prezinta proprietatea de unicitate, adica orice combinatie de valori ale atributelor supercheii este unica pentru orice stare a relatiei.
Acest lucru înseamna ca, daca se cunoaste combinatia de valori ale atributelor supercheii (valoarea supercheii), atunci acel tuplu poate fi identificat în mod unic. Orice relatie are cel putin o supercheie: multimea tuturor atributelor sale. Un concept mai util în dezvoltarea bazelor de date îl reprezinta conceptul de cheie candidata (sau, mai șimplu, cheie).
O cheie candidata (candidate key) este o supercheie ireductibilă (minimală).
Conform definitiei de mai sus, o cheie candidata CK trebuie sa prezinte proprietatea de unicitate (nu exista doua tupluri diferite ale relatiei care sa contină aceeași combinatie de valori ale atributelor cheii CK) și proprietatea de ireductibilitate (nu exista nici o submultime proprie, nevida a cheii CK care sa aiba proprietatea de unicitate).
O cheie candidata poate sa fie simpla (alcatuita dintr-un singur atribut), sau compusa (alcatuita din mai multe atribute).
Atunci când exista mai multe chei candidate, una dintre ele se alege ca și cheie primara, celelalte chei candidate fiind numite chei secundare, alternative sau unice.
O cheie primara (primary key) este o cheie candidata careia proiectantul îi confera un rol special de accesare și identificare a tuplurilor relatiei[2], [3]. În plus, se impune ca atributelor cheii primare sa nu admita valori de NULL sa nu fie modificate prin operatii de actualizare a datelor.
O cheie secundara (alternativa, unica) (secondary, alternate, unique key) este o cheie candidata care nu a fost desemnata de proiectant ca și cheie primara.
Cheile secundare admit valori NULL pentru unele din atributele lor daca se respecta conditia de unicitate a valorilor.
O cheie primara compusa din atributele existente ale tipului de entitate se numeste cheie naturala. În general, cheile naturale sunt compuse din mai multe atribute (ceea ce produce scaderea eficientei operatiilor relationale) și de cele mai multe ori se folosesc chei artificiale . O cheie primara artificiala este un atribut care se adauga în schema relatiei pentru identificarea unica a tuplurilor. De exemplu, în relatia ANGAJATI se adauga atributul IdAngajat, ca numar de identificare al fiecarui angajat al institutiei:
ANGAJATI(IdAngajat,Nume,Prenume,DataNasterii,Adresa,Salariu)
Acest atribut este o cheie artificiala a relatiei și poate identifica în mod unic un tuplu, deoarece (prin conventie) nu se atribuie același numar de identificare la mai mult de un angajat.
Constrângeri între relatii: cheia straina[2], [3]. O cheie straina (foreign key) este o multime de atribute FK ale unei relatiei R1 care refera relatia R2 și satisface urmatoarele conditii: (a) atributele cheii straine FK sunt definite pe domenii compatibile cu cele ale atributelor unei cheii candidate CK a relatiei R2 și (b) combinatia de valori ale atributelor FK într-un tuplu din relatia R1, fie este identica cu combinatia de valori ale atributelor CK a unui tuplu oarecare din starea curenta a relatiei R2, fie ia valoarea NULL. Cheia straina realizeaza asocierea N:1 între relatiile R1 și R2 (ceea ce este echivalent cu asocierea 1:N între relatiile R2 și R1) și reprezinta o constrângere între doua relatii, numita constrângere referentiala .
3.2. Declanșatoare[4]
Oricâte alte mecanisme de verificare și impunere a constrângerilor de integritate primitive ar mai oferi un SGBD, el tot trebuie să permită (pentru a putea garanta deplina consistență a bazei de date) și impunerea de constrângeri bazate pe predicate oarecare, ad-hoc. Acest lucru este oferit de majoritatea SGBD sub forma procedurilor de tip “declanșator”. Un asemenea declanșator (“trigger”) este o procedură utilizator (scrisă pentru implementarea unei sau mai multor constrângeri predicative oarecare) căreia i se asociază la definire momentul în care execuția ei trebuie declanșată automat de sistem.
Implementările uzuale specifică pentru aceasta coloana (sau coloanele) în care, dacă se încearcă scrierea unei/unor valori, SGBD “apasă” automat pe “declanșator”; dacă declanșatorul constată că noile valori nu violează constrângerea pe care el o impune, SGBD va permite scrierea noilor valori; în caz contrar, scrierea este respinsă, iar SGBD obligat probabil să-și “desfacă” tranzacția care a atentat astfel la integritatea bazei de date.
3.3.Restricții în DB2[4], [5]
DB2 al IBM a fost primul SGBD comercial care a suportat declarații de constrângeri vizând integritatea referințelor (prin clauza FOREIGN KEY a instrucțiunii CREATE TABLE) și impunerea lor automată. El permite și specificarea politicii de urmat în cazul cererii de ștergere a unei linii referite: interzicerea ștergerii, ștergerea în cascadă, împreună cu toate referințele, sau ștergerea doar a liniei respective, cu anularea referințelor (cu excepția cazului în care, cel puțin pentru o referință dintre cele implicate, valorile nule nu sunt permise; atunci ștergerea este interzisă). Actualizarea valorilor de chei primare referite de vreo linie (printr-o cheie străină) este interzisă; similar, valorile cheilor străine pot fi modificate doar în una din valorile existente ale cheii primare referite.
DB2 suportă declanșatoare; în versiunea 4, verificarea integrității domeniilor este extinsă și la mulțimi de valori enumerate (ce pot fi specificate cu ajutorul clauzei CHECK (nume_coloana IN (mulțime_valori)). Administratorii bazei de date pot suspenda temporar impunerea automată a constrângerilor (de exemplu, pentru a încărca mai rapid o tabelă cu date) pentru o tabelă sau o partiție a sa; când se dorește revenirea la normal, invocarea utilitarului CHECK DATA va elimina liniile invalide (ce vor fi plasate în “tabele de excepții”) și va informa sistemul despre încetarea suspendării temporare a verificărilor de integritate pentru datele respective.
3.4. Restricții în NonStop SQL[4], [5]
Integritatea domeniilor de valori este implementată în NonStop SQL al Tandem prin instrucțiunea CREATE CONSTRAINT; aceasta asociază un nume fiecărei constrângeri și permite folosirea de expresii logice și algebrice în definirea lor.
3.5. Restricții în Oracle[4], [5]
Oracle permite impunerea constrângerilor de codomenii (exact ca DB2, cu CHECK, care poate însă include și expresii logice și algebrice), de integritate a referințelor (tot ca în DB2, dar fără opțiunea de ștergere cu anularea pointerilor în referințe) și declanșatoare.
Declanșatoarele sunt proceduri memorate speciale scrise în limbajul de programare extins PL/SQL, care sunt atașate tabelelor și se execută automat exact înainte de sau după un eveniment oarecare (exemplu, execuția unei instrucțiuni INSERT, UPDATE sau DELETE asupra tabelei), o dată per eveniment sau pentru fiecare linie procesată în cadrul evenimentului. Fiecărei tabele i se pot asocia oricâte declanșatoare, inclusiv incluse unul în altul, ce vor fi executate de sistem într-o ordine arbitrară. Administratorii bazei de date pot suspenda temporar execuția automată a declanșatoarelor (din considerente de performanță sau de indisponibilitate temporară a unor date).
3.6. Restricții în SQL Server[4], [5]
SQL Server al Sybase oferă doar “reguli” (pentru specificarea integrității codomeniilor) și declanșatoare (maxim 3 per tabelă, câte unul per INSERT, UPDATE, respectiv DELETE, dar care pot fi recursive -cel mult 16 apeluri- și pot apela alte declanșatoare). Începând cu versiunea 10 abia este disponibilă și impunerea automată a integrității referențiale (dar ștergerile liniilor referite sunt interzise; dacă utilizatorul dorește altfel, el trebuie să-și definească, în continuare, un declanșator corespunzător).
3.7. Restricții în CA-OpenIngres
CA-OpenIngres implementează integritatea codomeniilor cu ajutorul instrucțiunii CREATE INTEGRITY (mulțimile enumerate necesită însă o expresie logică disjunctivă, deci de tipul “c = k1 or c = k2 or … “, unde c este numele coloanei, iar kj sunt elementele codomeniului enumerat!). Declansatoarele se numesc “reguli” și sunt deocamdată singurul mod de a cere impunerea integrității referințelor!. Particularitatea interesantă însă este generalizarea tipurilor de evenimente ce pot declanșa declanșatoare, prin posibilitatea specificării de “evenimentede alarmă” (“event alerters”): acestea sunt evenimente externe SGBD (precum, de exemplu, scăderea stocului sau prețului la un produs sub un anume prag) care provoacă însă și ele execuția imediată a unei aplicații utilizator.
3.8. Securitatea datelor în DB2 [4]
DB2 al IBM suportă instrucțiunile standard SQL de asignare / revocare a privilegiilor GRANT / REVOKE. Lista sa de privilegii este suficient de granulară pentru a permite administratorilor bazelor de date controlul strâns asupra securității datelor. De exemplu, un utilizator ar putea primi dreptul de a crea tabele, dar nu și pe acela al invocării unor utilitare asupra tabelelor respective.
DB2 împarte utilizatorii în 6 clase: administratori sistem, operatori sistem, administratori de bază de date, operatori de gestiune a bazei de date, operatori de control ai bazei de date și public. Fiecare membru al unei asemenea clase moștenește automat anumite privilegii. În plus, este oferit și un “mecanism secundar de autorizare” ce permite definirea de grupuri de utilizatori. DB2 menține automat și jurnale de control al accesului.
DB2 Versiunea 10.1 asigură îmbunătățiri critice pentru securitate și auditare prin introducerea controlului de acces pe linii și coloane (RCAC) ca soluție pentru a vă ajuta să securizați în continuare datele. RCAC este numit uneori control al accesului cu granulație fină sau FGAC.
Controlul accesului pe rând și coloană vă permite să reglați accesul la date la nivel de rând, la nivel de coloană sau ambele. Poate fi utilizat pentru a complementa modelul de privilegii pentru tabelă. Puteți utiliza controlul accesului pe rând și coloană pentru a vă asigura că utilizatorii dumneavoastră au acces doar la datele care sunt necesare pentru munca lor.
Securitatea RCAC vă permite să creați cu ușurință reguli variate de securitate la nivel de date. Aceste reguli de securitate asigură faptul că utilizatorii, care sunt membri de grupuri sau roluri aprobate, văd numai datele pe care au permisiunea să le vadă și înlătură constrângerile de securitate și dificultățile de performanță care derivă din vizualizările complexe și din predicate. Setarea este rapidă și simplă și securitatea este ușor de gestionat chiar și pentru sisteme de întreprindere complexe.
Beneficiile asigurate de RCAC includ:
un proces centralizat, care poate fi executoriu și auditabil și care controlează accesul la date
cost redus asociat cu dezvoltarea și gestionarea regulilor de control al accesului pentru datele operaționale sensibile.
reducerea timpului de evaluare pentru aplicațiile operaționale de proces pentru care aveți cerințe de conformitate sau de audit.
3.9. Securitatea datelor în NonStop SQL[4]
NonStop SQL al Tandem nu are mecanisme proprii de securitate (nici măcar nu oferă GRANT / REVOKE din SQL!); el se bazează în această privință pe sistemul de operare NonStop Kernel cu care este strâns cuplat. Acesta însă oferă doar privilegii la nivel de fișiere, asemănătoare celor din sistemul de operare VMS al DEC (patru privilegii: citire, scriere, execuție, ștergere; patru clase de utilizatori locali: administrator sistem, proprietar obiect, grup, public; și trei de utilizatori distribuiți: proprietar, grup, public).
3.10. Securitatea datelor în Oracle[4]
Serverul Oracle cuprinde un SGBD care controleaza:
– Stocarea de date in sfera bazelor de date dedicate;
– Securitatea bazelor de date si a taskurilor permise pentru anumiti utilizatori;
– Comunicarea si integritatea informatiilor, cand bazele de date sunt distribuite intr-o retea.
– Consistenta si protectia datelor, incluzand arhivarea taskurilor si mecanisme de cautare;
– Recuperarea de date pentru aplicatii utilizand tehnici de optimizare adecvate;
Securitatea (confidentialitatea) datelor semnifica faptul ca accesul la date se face numai printr-o autorizare corespunzatoare si doar controlat (sarcina administratorului bazei de date cu ajutorul SGBD-ului).
In acest sens, SGBD-ul permite: autorizarea si controlul accesului la date, utilizarea view-rilor (vizualizarilor), realizarea unor proceduri speciale, criptarea datelor.
a) Autorizarea si controlul accesului la date este realizat de SGBD prin intermediul parolelor. Acestea identifica clasele de utilizatori, cu anumite drepturi de acces, la anumite date.
b) Utilizarea vizualizarilor (view) este asigurata de SGBD pentru reprezentarea schemelor externe ale bazei de date. Cu ajutorul view, SGBD-ul permite sa se defineasca partitii logice ale bazei de date, definite pentru diferiti utilizatori, in raport cu cerintele acestora de acces la date. Securitatea datelor este asigurata de SGBD prin definirea tuturor drepturilor necesare unui utilizator pentru un view si revocarea drepturilor pentru obiectele initiale.
c) Realizarea unor proceduri speciale de acces asupra datelor este permisa de SGBD. Aceste proceduri se pastreaza in forma precompilata, iar anumitor utilizatori li se va acorda dreptul de executie si li se va interzice accesul direct la obiectele bazei de date.
d) Criptarea este asigurata de SGBD prin oferirea unor rutine de criptare (codificare) a datelor apelate automat sau la cerere si prin existenta unor instrumente care permit utilizatorului sa realizeze propriile rutine de criptare. Criptarea si decriptarea se realizeaza dupa algoritmi specifici, cu o cheie (parola) de acces la rutina.
Componentele unui sistem de criptare sunt:
– Algoritmul de criptare este o rutina care transforma datele initiale intr-o forma cifrata (codificata);
– Cheia de criptare este o valoare secreta (parola) care permite intrarea in algoritmul de criptare;
– Algoritmul de decriptare este o rutina care transforma datele din forma criptata in cea initiala;
– Cheia de decriptare este o parola de intrare in algoritmul de decriptare.
Integritatea datelor se refera la corectitudinea (coerenta) datelor si este asigurata prin protejarea acestora impotriva unor incidente intentionate sau neintentionate.
Componentele SGBD-ului asigura integritatea datelor tratand separat cauzele care pot altera baza de date: integritatea semantica, controlul accesului concurent, salvarea / restaurarea.
a) Integritatea semantica este asigurata prin operatii efectuate de SGBD asupra datelor si a prelucrarilor. Aceste operatii alcatuiesc un set de reguli numit restrictii de integritate. SGBD-ul asigura astfel de restrictii implicite (rezulta din modelul de date implementat) si explicite (proceduri incluse in programele de aplicatie).
b) Accesul concurent asigura coerenta datelor si este un obiectiv al SGBD-ului care se pune mai acut mai ales la baze de date distribuite. In acest sens SGBD-ul are o unitate distincta de prelucrare a datelor numita tranzactie, care este constituita dintr-o secventa de operatii marcata de puncte de inceput si sfarsit. Tranzactia poate fi controlata de SGBD implicit, cand punctele de inceput si de sfarsit sunt automat definite, sau explicit, cand punctele de inceput si de sfarsit sunt definite prin comenzi specifice.
c) Salvarea / restaurarea (backup/recovery) ca facilitate a SGBD-ului permite refacerea consistentei datelor care au fost alterate fizic din diferite motive.
Modelul de securitate Oracle este unul multistrat. Incorporeaza protectia obiectelor si fisierelor atat in interiorul cat si in exteriorul bazei de date, precum si o varietate de politici si strategii.
Straturile de securitate cuprind:
– protectia fisierelor sistemului Oracle (SGBD);
– protejarea codului aplicatiei care interactioneaza cu baza de date Oracle;
– controlul conexiunilor la baza de date;
– controlul accesului la baza de date prin intermediul rolurilor, permisiunilor, triggeri-lor si procedurilor;
– controlul accesului la tabele prin intermediul view-rilor, trigger-ilor si procedurilor;
– controlul folosirii discului;
– controlul folosirii resurselor sistemului (CPU de exemplu);
– asigurarea capacitatii de recuperare;
– activarea unor forme mai complexe de securitate precum criptarea si semnaturi digitale sau acces unic pentru mai multe sisteme relationate (Single sign-on);
– suport pentru baze de date si structuri accesate Web.
Securitatea în Oracle este asigurată în mod standard SQL[5] (GRANT / REVOKE). Trei clase de privilegii diferențiază trei tipuri de utilizatori: sistem (pentru administratorii bazei de date), obiect (pentru utilizatori individuali obișnuiți) și “roluri” (pentru grupuri de utilizatori, deși, la crearea oricărei baze de date, Oracle îi asignează cinci roluri sistem). Jurnalele de verificare a accesului sunt activate / inhibate manual (cu comenzile AUDIT / NOAUDIT).
3.11. Securitatea datelor în MS SQL Server[4]
SQL Server al Sybase oferă Secure Server, un program ce se conformează standardelor de securitate de nivel B1 și B2 elaborate de Pentagon. Conform acestuia, utilizatorii trebuie întâi să fie autorizați de a lucra cu Secure Server, apoi cu o bază de date oarecare (privilegiu pe care, de exemplu, un utilizator din categoria “oaspete” nu îl are decât pentru date considerate publice, dacă administratorul bazei de date nu interzice și aceasta!) și abia în final cu un obiect al bazei de date respective. Privilegiile sunt numite “permisiuni”, sunt gestionate în mod standard SQL (GRANT / REVOKE) și sunt de două niveluri: “comandă” (creare, salvare, interogare, modificare obiecte) și “obiect” (interogare și actualizare date într-o tabelă).
Ierarhia utilizatorilor include trei tipuri de “roluri” (administratori sistem, ofițeri de securitate a datelor și operatori sistem), plus oricâte alte niveluri inferioare de grupuri de utilizatori sau utilizatori individuali obișnuiți. Versiunea 10 include și un jurnal de verificare a accesului; diverse proceduri memorate (vezi capitolul 17) permit ofițerilor de securitate (singurii care au acces la asemenea jurnale!) să urmărească orice încercare de acces, a oricui, la orice obiect.
3.12. Securitatea datelor în CA-OpenIngres[4]
Și viitoarea versiune anunțată (1.1) a CA-OpenIngres se va conforma standardelor de securitate C2 ale Pentagonului. Versiunea curentă însă este doar standard SQL (GRANT / REVOKE). Privilegiile sunt granulare, incluzând: selecție date, inserție, actualizare, ștergere, toate cele precedente și execuție proceduri memorate (care nu necesită nici măcar privilegiul de selecție a datelor procesate de procedură!). Pentru accesul la Knowledge Manager sunt necesare privilegii speciale suplimentare. Pot fi create grupuri de utilizatori având aceleași privilegii; aplicațiile se bucură sau nu de “roluri” (numele generic al privilegiilor ce pot fi acordate sau nu programelor).
Majoritatea bazelor de date gestionate de Ingres sunt publice; se pot însă defini baze de date private, la care au acces doar proprietarul bazei de date, administratorul sistem și eventualii utilizatori cărora le-au fost acordate privilegii de proprietar (administratorul sistem neavând acest drept). Sunt menținute și jurnale de control al accesului, deși acestea sunt mai degrabă o formă primitivă de jurnale de actualizare (care nu există) în care însă nu sunt memorate instrucțiunile și/sau valorile modificate, ci doar data și ora începerii tranzacției, identificatorul acesteia, numele utilizatorului, tipul de operații efectuate (selecție, inserție, actualizare, ștergere) și identificatorul fiecărei tabele accesate.
CAPITOLUL 4
IMPLEMENTAREA POLITICILOR DE SECURITATE ÎNTR-O BAZĂ DE DATE ORACLE
Pentru exemplificare, ca model am ales să prezint administrarea politicilor de securitate intr-o baza de date Oracle. Etapele parcurse de administratorul unei baze de date pentru a administra o bază de date sunt:
Instalarea bazei de date cu acordarea tuturor drepturilor de administrare pentru acesta
Definirea și managementul utilizatorilor bazei de date
Acordarea și revocarea de privilegii și roluri pentru utilizatorii bazei de date.
Vizualizarea jurnalelor de auditare cu monitorizarea activității suspecte a utilizatorilor
Concluzii aplicație?
Etapele instalării unei BD Oracle.
În UNIX si Linux, în mod implicit, DBA aparțin grupului de instalare al sistemul de operare care are privilegiile necesare pentru a crea și șterge fișiere de baze de date.
SYSBA și conexiunile SYSOPER sunt autorizate numai după verificarea cu fișierul parolă sau cu privilegile sistemului de operare și permisele. Dacă se utilizează autentificarea sistemului de operare, atunci baza de date nu utilizează numele de utilizator și parola furnizate. Autentificare sistem de operare este folosit în cazul în care nu există nici un fișier parolă, în cazul în care numele de utilizator sau parola furnizată nu este în acel fișier, sau în cazul în care este furnizat nici un nume de utilizator și o parolă.
Cu toate acestea, dacă autentificarea reușește prin fișierul de parole, atunci conexiunea este conectat cu numele de utilizator. Dacă autentificarea reușește prin intermediul sistemului de operare, atunci este un CONNECT / conexiune care nu înregistrează utilizator specific.
Notă: autentificare OS are prioritate față de autentificare fișier parolă. În mod special, dacă sunteți un membru al OSDBA sau grupul OSOPER pentru sistemul de operare, și vă conectați ca SYSDBA sau SYSOPER, va fi conectat cu privilegii administrative asociate, indiferent de numele de utilizator și parola pe care le specificați.
La instalarea unei baze de date Oracle, conturile predefinite SYS și SYSTEM au rolul de administrator de baze de date (DBA), acordat acestora implicit. Contul SYS în plus, are toate privilegiile ADMIN OPTION și deține datele dicționar. Pentru a vă conecta la contul SYS, trebuie să utilizați clauza AS SYSDBA. Orice utilizator care primește privilegiul SYSDBA se poate conecta la contul SYS folosind clauza AS SYSDBA.
Numai utilizatorii care primesc SYSDBA sau SYSOPER privilegiu, au posibilitatea de a porni și opri instanța bazei de date.
Contului de sistem este acordat rolul DBA în mod implicit, dar nu privilegiul SYSDBA.
Definirea și managementul utilizatorilor bazei de date
Creare utilizator:
Definirea parolei si a drepturilor pentru utilizator (Necorectat de mine)
Autentificare înseamnă verificarea identității unei persoane (un utilizator, dispozitiv, sau altă entitate), care dorește să utilizeze date, resurse, sau aplicații. Validarea că identitatea stabilește o relație de încredere pentru interacțiunile ulterioare. Autentificarea permite, de asemenea, responsabilitatea de a face posibilă pentru a lega accesul și acțiuni la identități specifice. După autentificare, procesele de autorizare poate permite sau limita nivelul de acces și acțiune permise de acea entitate.
Când creați un utilizator, trebuie să decidă cu privire la tehnica de autentificare pentru a utiliza, care poate fi modificată mai târziu.
Parola: Acest lucru este, de asemenea, menționată ca autentificarea de baza de date Oracle. A crea fiecare utilizator cu o parolă asociată care trebuie să fie furnizate în cazul în care utilizatorul încearcă să stabilească o conexiune. La configurarea unei parole, puteți expira parola imediat, care obligă utilizatorul să schimbe parola la prima logare inch Dacă vă decide cu privire la care expiră parolele utilizatorilor, asigurați-vă că utilizatorii au posibilitatea de a schimba parola. Unele aplicații nu au această funcționalitate.
Parolele sunt întotdeauna în mod automat și transparent criptate în timpul rețea (client / server și server / server) conexiuni, prin utilizarea unui Data Encryption Standard (DES) algoritm modificat, înainte de a le trimite în rețea.
Acordarea și revocarea de privilegii și roluri pentru utilizatorii bazei de date.
Într-o bază de date Oracle există două tipuri de privilegii:
• Sistem: Permite utilizatorilor să efectueze acțiuni speciale în baza de date. Fiecare privilegiu sistem permite unui utilizator să efectueze o anumită operațiune sau clasă de operațiuni de baze de date. De exemplu, privilegiul de a crea tabele este un privilegiu sistem. Privilegiile de sistem pot fi acordatăe de către administratorul bazei sau de către o persoană care dă în mod explicit permisiunea de a administra acest privilegiu. Există mai mult de o sută de privilegii de sistem distincte. Multe privilegii de sistem conține clauza ANY.
Aceste privilegii permit să închidă, să pornească , să efectueze sarcini de recuperare și sarcini administrative în baza de date. SYSOPER permite unui utilizator să efectueze activități operaționale de bază, dar fără posibilitatea de a accesa datele utilizatorului. Exemple de privilegii de sistem:
– STARTUP and SHUTDOWN
– CREATE SPFILE
– ALTER DATABASE OPEN/MOUNT/BACKUP
– ALTER DATABASE ARCHIVELOG
– ALTER DATABASE RECOVER
– RESTRICTED SESSION
• Obiect: Permite utilizatorilor să acceseze și să manipuleze un anumit obiect. Fiecare privilegiu de obiect permite unui utilizator să efectueze o anumită acțiune pe un anumit obiect, cum ar fi un tabel, vizualizare, secvență, procedură, funcție, sau pachet. Fără permisiunea specifică, utilizatorii pot accesa numai propriile lor obiecte. Privilegiile de obiect pot fi acordate de către proprietarul unui obiect, de către administrator, sau de un utilizator care a primit în mod explicit permisiunea de a acorda privilegii de obiect.
Revocarea Privilegii de sistem
Privilegii de sistem, care au fost acordate în mod direct cu o comandă GRANT, poate fi revocată de folosind declarația revoca SQL. Utilizatorii cu OPȚIUNE ADMIN pentru un privilegiu sistem pot revoca privilegiul de la orice alt utilizator de baze de date.Revoker nu trebuie să fie același utilizator care a acordat inițial privilegiul.Nu exista efecte în cascadă, atunci când un privilegiu sistem este revocată, indiferent dacă acesta este dă opțiunea ADMIN.
Revocarea Privilegii obiect
Efecte în cascadă pot fi observate atunci când revocarea un privilegiu sistem, care se referă la un date limbaj de manipulare (LMD) operație. De exemplu, în cazul în care privilegiul SELECT ANY TABLE este procedurile acordate unui utilizator, și create de utilizator care utilizează masa, toate procedurile care sunt conținute în schema utilizatorului trebuie recompilat înainte de a putea fi folosit din nou.
Revocarea privilegiilor de obiect, de asemenea, cascade, atunci când se administrează împreună cu GRANT OPTION.
Alocarea de roluri și roluri Utilizatori
Rolurile sunt grupuri de privilegii, acordate utilizatorilor sau la alte roluri. Rolurile sunt concepute pentru a facilita administrarea privilegiilor în baza de date și, prin urmare, pentru a îmbunătăți securitatea.
CAPITOLUL 5
CONCLUZII
Bibliografie
Cârstoiu, D. Baze de date relaționale, Editura Printech,1999
Ionescu, F. Baze de date relaționale și aplicații, Editura Tehnică, 2004
Lupsoiu, C., Savulea, D. Sisteme de baze de date – fundamente teoretice, Ed. Sitech, 2010
Mancas, C. Caracteristici esențiale ale SGBD și SGBC. Editura Ovidius University Press, 2007
Mancas, C. Programarea în SQL ANSI-92 cu aplicații în MS JetSQL 4. Editura Ovidius University Press, 2002
Pribeanu, C. Baze de date și aplicații, Editura MatrixRom, 2000
Lungu, M., Botea, C. Baze de date, Editura All, Bucuresti, 1995
Bibliografie
Cârstoiu, D. Baze de date relaționale, Editura Printech,1999
Ionescu, F. Baze de date relaționale și aplicații, Editura Tehnică, 2004
Lupsoiu, C., Savulea, D. Sisteme de baze de date – fundamente teoretice, Ed. Sitech, 2010
Mancas, C. Caracteristici esențiale ale SGBD și SGBC. Editura Ovidius University Press, 2007
Mancas, C. Programarea în SQL ANSI-92 cu aplicații în MS JetSQL 4. Editura Ovidius University Press, 2002
Pribeanu, C. Baze de date și aplicații, Editura MatrixRom, 2000
Lungu, M., Botea, C. Baze de date, Editura All, Bucuresti, 1995
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: Studiu Comparativ Privind Securitatea Datelor 2 (ID: 124185)
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.