Conturi detaliate de control al accesului și aplicații (Partea 1)
Acest articol discută două noi mecanisme ale sistemului Oracle8i: control detaliat al accesului (Fine Grained Access Control) și contexte ale aplicațiilor securizate (Conținut securizat de aplicație). Atunci când sunt utilizate împreună, acestea oferă noi capabilități de înaltă calitate pentru a asigura securitatea informațiilor din baza de date.
În diverse publicații, controlul detaliat al accesului poate fi numit în moduri diferite. Următoarele sunt sinonimele sale:
Control detaliat al accesului (controlul accesului cu granulație fină)
Pe scurt, controlul detaliat al accesului în Oracle8i este capacitatea de a atașa dinamic un predicat (în cazul clauzelor) la timpul de execuție, atât pentru una cât și pentru toate interogările într-un tabel sau vizualizare. Astfel, a fost posibilă modificarea procedurală a interogării în timpul execuției. Puteți calcula cine execută interogarea, de unde se execută interogarea, când interogarea a început și generează un predicat care îndeplinește aceste criterii. Când utilizați Contexte de aplicație, puteți adăuga neobservate prin mediul înconjurător (de exemplu, prin rolul atribuit utilizatorului aplicației) să adăugați informații suplimentare și să le accesați printr-o procedură sau un predicat.
Un exemplu de control detaliat al accesului poate fi o politică de securitate care determină care șiruri pot fi accesate de diferite grupuri de utilizatori. Politica de securitate formează un predicat a cărui formă depinde de cea legată de baza de date a utilizatorului și de grupul din care face parte. Controlul detaliat al accesului vă permite să convertiți interogarea la "select * from emp" de către diferiți utilizatori în formularul de mai jos:
Interogarea este rescrisă dinamic în
Controlorul poate vedea pe cineva din departamentul dat. Acest exemplu introduce sintaxa pentru obținerea variabilelor context de aplicație - funcția SYS_CONTEXT () încorporată.
Există multe motive pentru a utiliza acest mecanism. Cele mai frecvente dintre acestea sunt:
- Ușor menținut. Controlul detaliat al accesului vă permite să aveți doar o singură masă și o procedură de control stocată, care va înlocui utilizarea mai multor vizualizări. Crearea unui set de vizualizări duce, de obicei, la o creștere a numărului de obiecte baze de date, deoarece fiecare grup de utilizatori necesită crearea unei vizualizări separate. De exemplu, în exemplul de mai sus, cu angajații, managerii și supraveghetorii dintr-un sistem obișnuit, trebuie să creați 3 vizualizări baze de date. Dacă aveți nevoie de alt grup de utilizatori, va trebui să adăugați un alt set de vizualizări pe care trebuie să le gestionați și să le întrețineți. Dacă politica de securitate se modifică (adică, este necesar ca managerii să vadă nu numai subordonații imediați, ci și 2 niveluri mai mici), va trebui să re-creați vizualizările bazei de date, după care toate obiectele care fac referire la aceste vizualizări devin invalide.
- Este implementat pe server. Având în vedere complexitatea gestionării și susținerii unui număr mare de opinii, dezvoltatorii încearcă în mod repetat să stabilească logica aplicației în aplicația în sine. Aplicațiile analizează cine este conectat la baza de date, ceea ce solicită și execută interogarea corespunzătoare. Aceasta protejează datele, dar numai atunci când accesul la acestea se face prin intermediul acestei aplicații. Aceasta reduce capacitatea de a utiliza instrumentele de executare a interogărilor și de a genera rapoarte, precum și alte instrumente de prelucrare a datelor. Probabilitatea creșterii datelor se mărește, deoarece, pentru a face o denaturare, este suficient să vă conectați la baza de date prin orice alte mijloace decât aplicația în cauză și să solicitați date. Datorită includerii logicii de securitate în baza de date, adică a unui mecanism care determină datele pe care utilizatorul le poate vedea, puteți fi siguri că datele vor fi protejate indiferent de mijloacele de acces la acestea, iar recursul poate fi făcut prin orice mijloace puteți accesa datele.
- Împiedicați conectarea la baza de date în numele utilizatorilor generalizați. Datorită controlului detaliat al accesului, fiecare utilizator trebuie să se conecteze la baza de date sub numele propriu. În acest caz, este asigurată responsabilitatea deplină - puteți urmări acțiunile la nivel de utilizator. Anterior, multe aplicații, atunci când lucrau cu vizualizări diferite de date pentru diferiți utilizatori, trebuiau să aplice utilizatori generalizați de baze de date, respectiv, datelor selectate. De exemplu, în cazul descris mai sus al unui angajat / administrator / administrator, în aplicație trebuie create trei conturi. Fiecare angajat trebuie să utilizeze contul "Angajat". Fiecare administrator trebuie să folosească contul "Manager". Fiecare controler trebuie să utilizeze contul "Controller". Acest lucru face imposibilă acțiunile la nivelul adevăraților utilizatori
- Simplificați dezvoltarea aplicației. Controlul detaliat al accesului ia logica de securitate din logica aplicației. Pentru a susține securitatea datelor, un dezvoltator de aplicații se poate concentra mai degrabă asupra aplicației în sine decât asupra logicii accesului la date la nivel scăzut. Deoarece controlul accesului detaliat este pe deplin implementat pe server, aplicațiile moștenesc direct această logică. Anterior, dezvoltatorii de aplicații trebuiau să integreze logica în aplicație, făcând din ce în ce mai dificilă aplicarea, mai întâi pentru dezvoltare și mai ales dificilă pentru sprijinul ulterior. Dacă o aplicație poate accesa date și la aceleași date și din mai multe puncte de aplicare, atunci cea mai simplă modificare a politicii de securitate poate afecta multe zeci de module de aplicație. Prin utilizarea controlului detaliat al accesului. Modificările politicii de securitate nu afectează modulele de aplicație.
- Aplicarea instrumentelor avansate de dezvoltare a aplicațiilor. În multe medii, politica de securitate de la început nu este definită corect și se poate schimba după un timp. Dacă există o fuziune sau o altă modificare structurală sau sunt introduse reguli de confidențialitate, atunci politica de securitate trebuie schimbată. Datorită faptului că controlul accesului este implementat la un nivel apropiat de date, puteți crea condiții pentru dezvoltarea aplicației cu un impact minim atât asupra ei, cât și asupra instrumentelor de dezvoltare. Acesta este unul dintre motivele pentru trecerea la utilizarea automată a noii logici și a tuturor aplicațiilor și instrumentelor care permit accesul la o bază de date cu logică nouă încorporată.
În Oracle8i, există două tipuri de control detaliat al accesului:
Pentru a profita de această ocazie, dezvoltatorul, pe lângă rolurile standard de conectare și de resurse, trebuie să aibă următoarele privilegii:
EXECUTE_CATALOG_ROLE. Permite dezvoltatorului să efectueze funcțiile și procedurile din pachetul dbms_rls. Alternativ, puteți să vă transferați privilegiul numai în pachet prin adăugarea în SYS: grant executați pe dbms_rls pentru a<учетная_запись>.
CREAȚI ORICE CONTEXT: Permite dezvoltatorului să creeze contexte de aplicații.
Contextele de aplicație sunt create de o comandă SQL simplă
OurApp este numele de context, iar Our_Context_Pkg este un pachet PL / SQL prin care sunt setate valorile contextului. Posibilitatea de a folosi contextele aplicațiilor pentru un control detaliat al accesului este de o importanță deosebită din două motive:
Se oferă un mod garantat de setare a spațiului de nume al variabilei. Numai pachetul PL / SQL asociat contextului poate seta valorile acestui context. În acest caz, integritatea valorilor contextului este garantată. Deoarece contextele sunt concepute pentru a restricționa sau a permite accesul la date, trebuie asigurată integritatea valorilor contextului.
Dacă doriți ca politica de securitate să permită unui utilizator care nu este RLS_ADMIN să vadă numai acele linii ale căror "proprietar" el este, executați apoi comanda: \
SQL> crează funcția my_security_function (p_schema în varchar2,
2 p_object în varchar2) returnați varchar2
5 dacă (user = 'RLS_ADMIN') atunci
8 return 'owner = USER';
Predicatul "where owner = USER" va fi adăugat dinamic tuturor interogărilor din tabel cu care această funcție este asociată, ceea ce reduce foarte mult numărul de rânduri disponibile pentru utilizator. Predicatul NULL (gol) este returnat numai dacă RLS_ADMIN este în prezent atașat la baza de date. Predicatul returnat gol arată "1 = 1" sau "TRUE".
Pentru a asocia această funcție cu tabela, trebuie să utilizați procedura PL / SQL "dbms_rls.add_policy". De exemplu, există următorul tabel:
Articole similare
Trimiteți-le prietenilor: