Securitatea este extrem de importantă pentru administratorii de baze de date care încearcă să-și protejeze gigabytele datelor de afaceri vitale de ochii curioși ai unor persoane neautorizate și insideri care încearcă să-și depășească autoritatea. Toate sistemele de gestionare a bazelor de date relaționale oferă un fel de mecanisme de securitate intrinseci menite să minimizeze aceste amenințări. Acestea variază de la protecția simplă a parolei oferită de Microsoft Access la structura complexă a utilizatorului / rolului, susținută de baze de date relaționale avansate precum Oracle și Microsoft SQL Server. Acest articol se concentrează asupra mecanismelor de securitate comune tuturor bazelor de date care implementează Limbajul de interogare structurat (sau SQL ). Împreună, vom trece prin procesul de consolidare a controlului accesului la date și asigurarea siguranței datelor dvs.
Utilizatori
Bazele de baze de date ale serverului suportă un concept de utilizator similar celui utilizat în sistemele de operare pe computer. Dacă sunteți familiarizat cu ierarhia utilizator / grup găsită în Microsoft Windows NT și Windows 2000, veți găsi că grupurile de utilizatori / roluri acceptate de SQL Server și Oracle sunt foarte asemănătoare.
Este foarte recomandat să creați conturi individuale de bază de date pentru fiecare persoană care va accesa baza de date. Este posibil din punct de vedere tehnic să distribuiți conturi între utilizatori sau pur și simplu să utilizați un singur cont de utilizator pentru fiecare tip de utilizator care are nevoie de acces la baza dvs. de date, dar cu siguranță descurajăm această practică din două motive. În primul rând, va elimina răspunderea individuală - dacă un utilizator face o schimbare în baza dvs. de date (să spunem, oferindu-i o majorare de 5.000 $), nu veți putea să îl urmăriți înapoi unei anumite persoane prin utilizarea jurnalelor de audit. Mai mult, dacă un anumit utilizator părăsi organizația dvs. și doriți să îl eliminați din baza de date, veți fi forțat să schimbați parola pe care toți utilizatorii se bazează.
Metodele de creare a conturilor de utilizator variază de la platformă la platformă și va trebui să consultați documentația specifică DBMS pentru procedura exactă. Utilizatorii Microsoft SQL Server ar trebui să investigheze utilizarea procedurii stocate sp_adduser. Administratorii de baze de date Oracle vor găsi comanda CREATE USER utilă. De asemenea, ați putea dori să investigați scheme alternative de autentificare. De exemplu, Microsoft SQL Server acceptă utilizarea securității integrate Windows NT. În cadrul acestei scheme, utilizatorii sunt identificați în baza de date prin conturile de utilizator Windows NT și nu sunt obligați să introducă un ID utilizator și o parolă suplimentară pentru a accesa baza de date. Această abordare este extrem de populară în rândul administratorilor de baze de date, deoarece transferă sarcina administrării conturilor către personalul de administrare a rețelei și oferă ușurința unei singure conectări la utilizatorul final.
roluri
Dacă vă aflați într-un mediu cu un număr mic de utilizatori, veți găsi probabil că crearea conturilor de utilizatori și atribuirea directă a permisiunilor acestora este suficientă pentru nevoile dvs. Cu toate acestea, dacă aveți un număr mare de utilizatori, cel mai probabil veți fi copleșiți de povara menținerii conturilor și a permisiunilor corespunzătoare. Pentru a ușura această povară, bazele de date relaționale sprijină noțiunea de roluri. Rolurile de baze de date funcționează similar cu grupurile Windows NT. Conturile utilizatorilor sunt atribuite rolului (lor), iar permisiunile sunt apoi atribuite rolului în ansamblu, mai degrabă decât conturile individuale de utilizator. De exemplu, am putea crea un rol DBA și apoi adăugăm conturile de utilizator ale personalului nostru administrativ la acest rol. Odată ce am făcut acest lucru, putem atribui o permisiune specifică tuturor administratorilor actuali (și viitorilor) prin simpla atribuire a permisiunii rolului. Încă o dată, procedurile de creare a rolurilor variază de la platformă la platformă. Administratorii MS SQL Server ar trebui să investigheze procedura stocată sp_addrole în timp ce DBA-urile Oracle ar trebui să utilizeze sintaxa CREATE ROLE.
Acordarea permisiunilor
Acum că am adăugat utilizatori în baza noastră de date, este timpul să începem să consolidăm securitatea prin adăugarea permisiunilor. Primul nostru pas va fi acordarea de permisiuni de baze de date adecvate utilizatorilor noștri. Vom realiza acest lucru prin utilizarea instrucțiunii SQL GRANT.
Iată sintaxa instrucțiunii:
GRANT Acum, să aruncăm o privire la această afirmație line-by-line. Prima linie, GRANT Al doilea rând, ON În cele din urmă, linia a patra, CU GRANT OPTION, este opțională. Dacă această linie este inclusă în instrucțiune, utilizatorul afectat are, de asemenea, permisiunea de a acorda aceleași permisiuni altor utilizatori. Rețineți că opțiunea WITH GRANT OPTION nu poate fi specificată atunci când permisiunile sunt atribuite unui rol. Să ne uităm la câteva exemple. În primul nostru scenariu, am angajat recent un grup de 42 de operatori de introducere de date care vor adăuga și menține înregistrările clienților. Ei trebuie să poată accesa informațiile din tabelul Clienți, să modifice aceste informații și să adauge noi înregistrări în tabel. Nu ar trebui să poată șterge în întregime o înregistrare din baza de date. În primul rând, ar trebui să creăm conturi de utilizator pentru fiecare operator și apoi să le adăugăm tuturor într-un rol nou, DataEntry. Apoi, ar trebui să folosim următoarea instrucțiune SQL pentru a le acorda permisiunile corespunzătoare: GRANT SELECT, INSERT, UPDATE Și asta este tot ce există! Acum, să examinăm un caz în care atribuim permisiuni la nivel de bază de date. Dorim să permitem membrilor din rolul DBA să adauge noi tabele în baza noastră de date. În plus, dorim ca aceștia să poată acorda altor utilizatori permisiunea de a face același lucru. Iată instrucțiunea SQL: GRANT CREATE TABLE Observați că am inclus linia WITH GRANT OPTION pentru a vă asigura că DBA-urile noastre pot atribui această permisiune altor utilizatori. După ce ne-am acordat permisiuni, se dovedește adesea necesară revocarea acestora la o dată ulterioară. Din fericire, SQL ne oferă comanda REVOKE pentru a elimina permisiunile acordate anterior. Iată sintaxa: REVOKE [OPȚIUNEA GRANTULUI PENTRU] Veți observa că sintaxa acestei comenzi este similară cu cea a comenzii GRANT. Singura diferență este că GRANT OPTION este specificat pe linia de comandă REVOKE mai degrabă decât la sfârșitul comenzii. De exemplu, să ne imaginăm că vrem să revocăm permisiunea anterior acordată de Mary pentru a elimina înregistrările din baza de date a clienților. Am folosi următoarea comandă: REVOKE DELETE Și asta este tot ce există! Există un mecanism suplimentar susținut de Microsoft SQL Server care merită menționat - comanda DENY. Această comandă poate fi utilizată pentru a refuza în mod explicit permisiunea unui utilizator pe care ar putea-o avea altfel printr-un membru de rol curent sau viitor. Iată sintaxa: DENY Revenind la exemplul nostru precedent, să presupunem că Mary a fost, de asemenea, membru al rolului managerilor, care a avut, de asemenea, acces la masa clienților. Declarația precedentă REVOKE nu ar fi suficientă pentru a-i refuza accesul la masă. Aceasta va elimina permisiunea acordată ei printr-o declarație GRANT care vizează contul de utilizator, dar nu va afecta permisiunile obținute prin calitatea de membru în rolul managerilor. Cu toate acestea, dacă vom folosi o declarație DENY, aceasta va bloca moștenirea permisiunii. Iată comanda: DENY DELETE Comanda DENY creează, în esență, o "permisiune negativă" în controalele de acces la baza de date. Dacă vom decide mai târziu să-i acordăm permisiunea Mariei să elimine rândurile din tabelul Clienți, nu putem folosi pur și simplu comanda GRANT. Această comandă va fi imediat anulată de DENY existentă. În schimb, vom folosi mai întâi comanda REVOKE pentru a elimina intrarea de permisiune negativă după cum urmează: REVOKE DELETE Veți observa că această comandă este exact aceeași cu cea folosită pentru a elimina o permisiune pozitivă. Amintiți-vă că atât comenzile DENY cât și GRANT funcționează într-o manieră asemănătoare, ambele creează permisiuni (pozitive sau negative) în mecanismul de control al accesului la baza de date. Comanda REVOKE elimină toate permisiunile pozitive și negative pentru utilizatorul specificat. Odată ce această comandă a fost emisă, Mary va putea șterge rânduri din tabel dacă este membru al unui rol care posedă această permisiune. Alternativ, o comandă GRANT ar putea fi emisă pentru a oferi permisiunea DELETE direct contului său. De-a lungul acestui articol, ați învățat o afacere bună cu privire la mecanismele de control al accesului acceptate de limba standard de interogare. Această introducere vă va oferi un bun punct de pornire, dar vă încurajez să consultați documentația DBMS pentru a afla măsurile de securitate îmbunătățite susținute de sistemul dvs. Veți găsi că multe baze de date oferă suport pentru mecanisme mai avansate de control al accesului, cum ar fi acordarea permisiunilor pentru anumite coloane.
[ON ]
La
[CU GRANT OPTION]
, este folosit pentru a specifica tabelul afectat pentru permisiunile la nivel de tabel. Această linie este omisă dacă acordăm permisiuni la nivel de bază de date. A treia linie specifică utilizatorul sau rolul cărora li se acordă permisiuni.
Exemple
ON Clienții
La DataEntry
LA DBA
CU OPȚIUNI DE GRANT Eliminarea permisiunilor
ON
DE
ON Clienții
Din Mary
ON
TO Exemple
ON Clienții
La Maria
ON Clienții
Din Mary