Oracle vs SQL server – Treci dio

Sigurnost baze podataka

Jedna od očiglednih razlika izmedju SQL Servera i Oracle-a na nivou sigurnosti je da je kod SQL Servera pristup bazi podataka dvofazni proces. Na nivou instance, server održava listu korisničkih naloga koji se nazivaju logins. Logins su nalozi kojima su data prava da se povežu na instancu baze podataka. Ipak, da bi pristupio konkretnoj bazi podataka koja je vlasništvo konkretne instance, login nalog treba da se  mapira na korisnički nalog unutar baze podataka. SQL Server login može biti ili lokalni Windows login ili nalog iz aktivnog direktorijuma ili sertifikovani ključ. Nalog može biti i nešto što je potpuno nezavisno od windows-a: DBA administrator može kreirati nalog koji posjeduje svoju vlastitu autentifikaciju preko username/password-a unutar SQL Servera. U varijanti kada se koristi windows-ov nalog, odnosno nalog koji se vezuje za AD Windowsa govorimo o “trusted” tipu nalogu. Ukoliko koristimo nalog kreiran unutar SQL Servera, govorimo o “non-trusted” tipu nalogu.Za Oracle, ne postoji koncept trusted i non trusted naloga. Nalog običnog korisnika se kreira samo jednom i na jednom mjestu – u bazi podataka. Za razliku od SQL Servera, Oracle ne vrši mapiranje naloga iz operativnog sistema u naloge baze podataka.

Kada se instalira SQL Server, kreira se poseban non-trusted nalog pod imenom sa (akronim za System administrator). sa je ugrađeni DBA nalog koji je vlasnik svake baze podataka koja se kreira na instanci. On ima potpunu kontrolu nad serverom: sa može da kreira, mjenja i briše logins-e i baze, mijenja sistemsku konfiguraciju, spušta instancu i dodjeljuje drugim korisnicima DBA privilegije.

Osim sa naloga, svaka baza podataka će takođe imati i dbo ili database owner nalog. Ovaj nalog će biti mapiran na nivou servera kao glavni korisnik – owner koji je kreirao bazu podataka. Database owner ima sve privilegije unutar svoje baze podataka ali nema nikakvih prava izvan konkretne baze podataka.

Ako razmatramo Oracle, kada se kreira Oracle baza podataka, može biti kreirano desetak naloga sa system nivoom privilegija. Po defaultu, svi ovi nalozi će imati statuse expired i locked osim 4 (dakle, samo 4 će biti aktivna). Četiri specijalna korisnička naloga su sys, system, sysman i dbsnmp. sys nalog je ekvivalentan SQL Server-verovom nalogu sa. Korisnik sys je vlasnik data dictionary-a (Oracle-ov data dictionary je kreiran u sys šemi). Korisnik system ima pristup svim objektima u bazi podataka.

Pored naloga, SQL Server takođe ima unaprijed predefinisano nekoliko fiksnih serverskih rola. Ove fiksne role su poput Windows groupa – mogu da sadrže jedan ili više login-a. Svaka rola ima unaprijed definisani set privilegija. Svi članovi role (korisnici, logins koje kasnije dodjeljujemo ovim rolama) na taj način imaju isti nivo prava nad serverom. Serverska rola sa najvećim nivoom privilegija je sysadmin koja ima isti nivo privilegija kao i dba nalog. Kod SQL Server-a rola ne može da sadrži druge role – ne mogu se prenositi prava iz jedne role u drugu.  Na nivou svake od baza podataka unutar instance takodje postoje role unutar kojih se mogu dodjeljivati privilegije koje važe za konkretnu bazu podataka. Ove role se kasnije dodjeljuju korisnicima – user-ima koji se kreiraju na nivou baze unutar SQL Server instance

Kod Oracle-a takodje srećemo pojam role. Za Oracle, najviši nivo privilegije se dodjeljuje dba roli. Oracle ima poseban tip privilegija sysdba i sysoper. Kod Oraclea korisnik kojem budu dodjeljene sysdba ili sysoper privilegije može izvršavati administrativne operacije (kao što su spuštanje i podizanje baze podataka npr). Oracle dozvoljava da se rolama dodjeljuju (prenose) prava iz drugih rola – rola može da sadrži rolu. Na ovaj način se može formirati čitava hijerarhija rola.

Kao što je rečeno ranije, SQL Server login može biti ili trusted (Windows nalog) ili non-trusted. To znači da SQL Server korisnik može biti provjeravan preko 2 tipa autentifikacije: trusted ili non-trusted. Kada se koristi trusted ili Windows autentifikacija, SQL Server će se ponašati kao da je korisnik koji se prijavljuje na bazu već provjeren od strane Windows operativnog sistema. Ukoliko korisnik ima validan nalog u AD ili na lokalnom Windows Serveru, SQL Server neće od tog korisnika tražiti da se autentifikuje ponovo kroz username / password prilikom povezivanja na SQL Server bazu podataka.  Kod non-trusted metoda authentifikacije, SQL Server će zahtjevati od korisnika da unese username i password. SQL Server će tada uporediti unešene podatke za username/password sa svojim vlastitim podacima u svojoj internoj listi korisnika.

Kod Oracle-a, korisnik može biti autentifikovan na 3 različita načina:

  • Data Dictionary
  • Password File
  • Operativni sistem (ovo je različito od SQL Server trusted connection methoda autentifikacije)

Među pobrojanim načinima, data dictionary metod je najčešći metod za autentifikaciju korisnika na Oracle bazu podataka. Ostala 2 metoda se koriste kada baza podataka nije raspoloživa ili kada se ne izvršava instanca baze podataka. Kada se obični korisnik pokušava povezati na Oracle bazu podataka koja je već otvorena, njegovi autentifikacioni podaci se provjerava u odnosu na informacije koje se čuvaju u data dictionary Oracle baze podataka. Mada ovaj metod radi dobro za obične korisnike, DBA i sistem administratori koji imaju potrebu da kreiraju, otovre, startuju ili spuste bazu ne mogu biti verifikovani kroz ovakav metod autentifikacije. Ovo je zato što Oracle instanca može da radi a da pri tome baza podataka nije podignuta ili čak nije ni kreirana. DBA će biti jedini korisnik koji može kreirati ili otvoriti bazu podataka iz instance. Pošto u tom trenutku nije aktivan data dictionary za autentifikaciju, Oracle ima potrebu za nekim oblikom eksterne autentifikacije korisnika. Ovaj oblik eksterne autentifikacije može biti realizovan kroz password file ili kroz operativni sistem na kojem hostuje Oracle instanca.

Password file sadržii parove username / password za naloge kojima su dodjeljene sysdba ili sysoper privilegije. Kada se Oracle korisnik konektuje na bazu podataka sa nekom od ove dvije privilegije, on može startovati, monitrati, otvoriti, zatvoriti, demontirati, spustiti ili promjeniti strukturu baze podataka.

Ukoliko je korisnik direktno prijavljen na server na kojem hostuje Oracle instanca, tada takav korisnik može koristiti i autentifikaciju operativnog sistema. Sa validacijom na nivou operativnog sistema, Oracle provjerava da li korisnik koji pokušava da se prijavi član grupe unutar operativnog sistema koja je vlasnik Oracle softvera.Na windows serveru, to je lokalna windows grupa ora_dba, za Unix sisteme, to je tipično dba grupa. Ukoliko je taj korisnik član privilegovane grupe, nije potrebno da se prijavljuje sa posebnim username i password.

Da bi pojasnili  kako ovo funkcioniše, razmotrimo 2 primjera.

U komandi u nastavku, sys korisnik pokušava da se sa privilegijama sysdba poveže na bazu dbname koristeći password file authentication

CONNECT sys/password@DBNAME AS SYSDBA;

U komandi uu narednom primjeru, korisnik se direktno povezuje sa servera na kojem hostuje Oracle. Pošto je taj korisnik već validovan na nivou operativnog sistema i njegov nalog je član grupe operativnog sistemakoja je vlasnik Oracle instalacije, takvom korisniku nije potrebna dodatna provjera u vidu posebnog username i password. Umjesto toga, on unosi samo simbol “/”.

CONNECT / AS SYSDBA;

Treba ukazati i na razliku u tretiranju šeme baze podataka između ova dva RDBMS-a. Kod Oracle-a, prilikom kreiranja korisnika na bazi podataka se kreira schema koja je u potpunosti vezana za njega. Izmedju korisnika i scheme je 1:1 odnos. Schema pretstavlja skup svih objekata baze podataka kojima korisnik može na neki način pristupati (select, insert, update, delete, execute, modify).

Kod SQL servera je stvar drugačija. Šemu kreira neki korisnik (tipično admin) i definiše skup tabela, procedura, funkcija, view-ova i ostalih baznih objekata sa odredjenim skupom privilegija nad svakim od tih objekata. U narednoj iteraciji se definišu korisnici ili role koji pripadaju konkretnoj šemi. Sa ovakvog stanovišta je interesantno rješenje da se aplikativni moduli definišu na nivou šeme a onda da se korisnicima dodjele prava rada nad tako definisanom šemom.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s