ELEKTROTEHNIČKI FAKULTET U BANJOJ LUCI

SEMINARSKI RAD IZ PREDMETA RAČUNARSKE MREŽE (VIŠI KURS)

NAPREDNA ZAŠTITA PODATAKA U ORACLE MREŽNOM OKRUŽENJU

KORIŠTENJEM KRIPTOGRAFSKIH I AUTENTIFIKACIONIH PROTOKOLA

Student: Mladen Todorović 2112/10Mentor: prof. Dr Ratko Dejanović

Banja Luka, april 2011.

SADRŽAJ

UVOD...........................................................................................................................................................2

1. POJAM ORACLE RDBMS.......................................................................................................................3

2. ŠIFROVANJE I INTEGRITET PODATAKA U ORACLE MREŽNOM OKRUŽENJU.........................................5

2.1. ŠIFROVANJE PODATAKA I ŠIFARSKI ALGORITMI PODRŽANI OD STRANE ORACLA........................5

2.2. INTEGRITET PODATAKA...............................................................................................................7

2.2.1. HEŠ FUNKCIJE I ČUVANJE LOZINKI U BAZI PODATAKA.........................................................8

2.2.2. HEŠ FUNKCIJE SA SALTOVANJEM.........................................................................................8

2.3. KONFIGURACIJA ŠIFROVANJA I ZAŠTITE INTEGRITETA PODATAKA U ORACLE OKRUŽENJU.......10

2.3.1. KONFIGURACIJA PARAMETARA ŠIFROVANJA I INTEGRITETA KORIŠTENJEM ORACLE NET MANAGERA.......................................................................................................................................12

3. JAKA AUTENTIFIKACIJA KORISNIKA U ORACLOVOJ NAPREDNOJ SIGURNOSTI...................................14

3.1. RADIUS AUTENTIFIKACIJA..........................................................................................................14

3.1.1. MODOVI RADIUS AUTENTIFIKACIJE...................................................................................16

3.1.2. KONFIGURACIJA RADIUS AUTENTIFIKACIJE KORIŠTENJEM ORACLE NET MANAGERA.......18

3.1.3. NEDOSTACI RADIUS PROTOKOLA.......................................................................................21

3.2. KERBEROS AUTENTIFIKACIJA.....................................................................................................22

3.2.1. OSNOVNI POJMOVI I KONCEPTI.........................................................................................22

3.2.2. CENTAR ZA DISTRIBUCIJU KLJUČEVA..................................................................................23

3.2.3. RAZMIJENA PORUKA U KERBEROS KOMUNIKACIJI............................................................25

3.2.4. KONFIGURACIJA KERBEROS AUTENTIFIKACIJE KORIŠTENJEM ORACLE NET MANAGERA..28

4. SSL PROTOKOL...................................................................................................................................30

4.1. PKI U ORACLE OKRUŽENJU (Wallets).........................................................................................31

4.2. SSL U KOMBINACIJI SA DRUGIM AUTENTIFIKACIONIM METODAMA.........................................32

4.3. KONFIGURACIJA SSL-a POMOĆU ORACLE NET MANAGERA......................................................33

ZAKLJUČAK................................................................................................................................................35

LITERATURA...............................................................................................................................................36

1

UVOD

Velika količina podataka u poslovnim sistemima i potreba za brzom transformacijom i prenosom informacija i znanja mijenjaju paradigme poslovanja, a informacija postaje najjače oružje u borbi sa konkurencijom. Informacioni sistem, odnosno baza podatka koja pruža pravovremene i konzistentne podatke predstavlja konkurentnu prednost u tržišnom nadmetanju. Stoga, takav sistem mora zadovoljavati visoke kriterije koji se tiču sigurnosti i integriteta podataka. Mnoštvo raznovrsnih podataka koji se čuvaju i obrađuju na računarima ili se prenose komunikacijskim putevima zahtjeva efikasnu zaštitu. Uništenje podataka, njihovo neovlašteno modifikovanje ili dolazak u ruke neovlaštenim osobama ili organizacijama može često imati vrlo teške posljedice. Problem je posebno izražen kod nekih organizacija kao što su bankarske, pravosudne, vojne, medicinske i druge. Praktično se može smatrati da je za svakog vlasnika podataka bitna njihova cjelovitost, a najčešće i tajnost. [5].

U ovom seminarskom radu najprije ću izložiti osnovne koncepte i pojmove koji se odnose na sistem Oraclove baze podataka. Oracle je trenutno vodeća svijetska firma najzastupljenija na tržištu relacionih baza podataka. Oraclova baza podataka sama po sebi je veoma zaštićena i posjeduje brojne mehanizme koji obezbjeđuju sigurnost. Njena arhitektura se na prvi pogled čini složenom, ali je uopšteno ona veoma funkcionalna i prilagođena jednom od glavnih ciljeva, a to je sigurnost.

Dalje u radu će biti opisani osnovni koncepti zaštite integriteta podataka i najbolji kriptografski algoritmi koji to obezbjeđuju. Velika pažnja će biti okrenuta ka zaštiti podataka koji se prenose između klijenta i Oraclovog servera baze podataka, te na korisničke lozinke i načine njihove zaštite od pada u ruke neovlaštenih korisnika.

Poseban dio ovog rada biće posvećen i metodama jake autentifikacije korisnika i algoritmima koje one koriste za identifikaciju korisnika. S obzirom da su te metode trenutno jako aktuelne u svijetu mrežnih tehnologija, biće opisan i način njihovog implementiranja u Oraclovom okruženju korištenjem nekih korisničkih alata.

U ovom seminarskom radu su objašnjene tehnike i koncepti kojima se navedeni zahtjevi ostvaruju u najnovijoj verziji Oracle baze: Oracle Database 11g. Takođe se podrazumjeva da su određeni pojmovi iz kriptografije poznati i neće se detaljije razmatrati. Tu se prije svega misli na asimetrične i simetrične šifarske sisteme, infrastrukturu javnih ključeva (PKI), digitalni potis i digitalne sertifikate.

2

1. POJAM ORACLE RDBMS

Na početku ovog rada najprije će biti izneseni i obajšnjeni osnovni pojmovi koji se tiču same Oraclove baze, poput arhitekture, načina komunikacije izmedju klijenta i servera, te bezbjednost koju sistem posjeduje.

Oracle RDBMS (Rational DataBase Management System) je sistem za upravljanje relacionim bazama podataka, koji je trenutno vodeći na tržištu. Oracle baza sastoji se od datoteka pohranjenih na disku poput datoteka sa podacima, privremenih datoteka sa podacima, kontrolnih i parametarskih datoteka, te memorijskih struktura i procesa koji se izvršavaju na baznom serveru. Memorijske strukture i procesi čine instancu baze. Prvi korak prilikom pokretanja baze je izgradnja instance u memoriji. Nakon toga, instanca poziva i čita datoteke na disku. Memorijske strukture koje čine instancu pohranjene su u SGA (System Global Area) memorijskom segmentu. SGA se alocira pri pokretanju instance, a sastoji se od nekoliko komponenata čija se veličina može dinamički mijenjati dok je instanca aktivna.

Povezivanje na instancu baze podataka ostvaruje se pomoću:

Korisničkih procesa Oracle Listenera Oracle Net Clienta

Korisnički proces predstavlja dio softvera koji pokušava da se poveže na bazu podataka. On komunicira sa bazom posredstvom Oraclovih mrežnih servisa (Oracle Net Services), tj. grupom komponenti koje obezbjeđuju mrežnu povezanost preko različitih mrežnih protokola na fizičkom nivou. Mrežni servisi su jako značajni jer pošteđuju administratore i programere složenih podešavanja raznih mrežnih protokola na različitim hardverskim platformama.

Oracle Listener (osluškivač) označava proces koji se uobičajeno izvršava na Oraclovom serveru baze podataka i vrši „osluškivanje“ zahtjeva za uspostavljanje veze, od strane klijentskih aplikacija. Kada se detektuje klijentski zahtjev, uspostavlja se veza sa klijentom, koja se zatim prosleđuje servisnom rukovaocu (Service Hendler) koji je opslužuje, a osluškivač automatski prelazi u stanje čekanja sledećih zahtjeva za uspostavljanje veze [2].

3

Osnovni parametri Oracle Listenera su :

Mrežni protokol: TCP/IP Ime glavnog računara: Ime baznog servera Port: 1521

Oracle Net Client je korisnički adapter koji omogućava upotrebu Oraclovih klijentskih alata (SQL*Plus, Oracle Enterprise Manager, Oracle Net Manager ...) i njihovu uspješnu komuniciranju sa bazom podataka sa bilo koje radne stanice u mreži. Da bi ostvario uspješnu komunikaciju on mora biti prethodno konfugurisan. U slučaju slušaoca konfiguraciona datoteka se zove listener.ora, a u slučaju klijenta tnsnames.ora.

Što se tiče bezbjednosti, potrebno je razlikovati bezbjednost na nivou same baze i na nivou prenosa podataka između klijenta i servera baze podataka. Bezbjednost same baze zasniva se na privilegijama. Te privilegije mogu biti sistemske, tj. one koje omogućavaju izvršavanje akcija nad sistemom i objektne, tj. one koje omogućavaju izvršavanje akcija nad određenim objektima. Da bi se olakšala administracija privilegija u Oraclu se koriste uloge (roles). Uloge nisu ništa drugo do sami objekti baze podataka pomoću kojih se ostvaruje bezbjednost baze. Ulogama se dodjeljuju različite privilegije u bazi, a zatim se same uloge dodjeljuju korisnicima [2].

Danas, u doba internet aplikacija i raznovrsnih internet tehnologija posebnu pažnju treba obratiti na bezbjednost podataka koji se prenose mrežom. Bezbjednost zasnovana samo na provjeri autentičnosti je nedovoljna, jer u istinskoj bezbjednosti učestvuju baza podataka, klijenti i klijentske aplikacije, aplikacijoni server, transakcioni server i mrežni hardver. Zbog svega navedenog u ovom seminarskom radu osnovna tema će upravo biti zaštita podataka od neovlaštenog pristupa upotrebom nekih od najkorištenijih kriptografskih protokola.

4

2. ŠIFROVANJE I INTEGRITET PODATAKA U ORACLE MREŽNOM OKRUŽENJU

Za rješavanje problema računarske sigurnosti, Oraclova napredna sigurnost (Oracle Advances Security) obezbjeđuje privatnost podataka, integritet podataka i provjeru autentičnosti na različite načine. Na primjer, moguće je konfigurisati ili Oracle Net prirodnu enkripciju ili koristiti SSL (Secure Sockets Layer) za zaštitu privatnosti podataka koji se prenose mrežom. Napredna sigurnost također pruža izbor od nekoliko jakih metoda provjere autentičnosti, poput Kerberosa, RADIUSA i uz korištenje smart kartica i digitalnog potpisa, odnosno digitalnih sertifikata.

2.1. ŠIFROVANJE PODATAKA I ŠIFARSKI ALGORITMI PODRŽANI OD STRANE ORACLA

Osjetljive informacije koje putuje preko mreža i Interneta mogu se zaštititi nekim od algoritama šifrovanja. Algoritam šifrovanja transformiše informacije u oblik koji može biti dešifrovan sa ključem za dekripciju. Slika 2.1 prikazuje kako šifrovanje radi i kako se osigurava sigurnost transakcije. Ako npr. administrator pristupa serveru baze i vrši upis povjerljivih podataka, ti podaci bi trebali biti šifrovani prije slanja preko mreže, kako bi izbjegli prisluškivanje. Ako je sva komunikacija između klijenta, baze podataka, te aplikacionog servera šifrovana, onda je vrijednost datih podataka zaštićena.

Sl. 2.1 Šifrovanje podataka [1]

5

Osnovna uloga sigurnog kriptografskog sistema je da konvertuje (šifruje) otvoreni tekst (plaintext) u šifrovani (ciphertext) na osnovu nekog šifarskog ključa na taj način da je veoma teško ili gotovo nemoguće konvertovati šifrovani podatak u originalni bez poznavanja pravog ključa. U simetričnim kriptografskim sistemima za šifrovanje i dešifrovanje podataka koristi se jedan isti ključ [4].

Oracle podržava sljedeće simetrične kriptografske algoritme za žaštitu transporta podataka preko mreže:

RC4 DES Trostruki DES AES

Odabir nekog od gore navedenih algoritama je isključivo opcija korisničke konfiguracije, tj. korisnik ih bira na osnovu razine njihove sigurnosti i performansi koje ti algoritmi obezbjeđuju za različite tipove transfera podataka. Najnoviji Oracle 11g Relese 2 sadrži potpuni komplet svih dostupnih algoritama za šifrovanje i različite dužine šifarskih ključeva, koji nisu bili dostupni u ranijim verzijama.

RC4 šifarski modul je razvijen od RSA Data Security, i predstavlja standard za veoma brzo šifrovanje podataka. On koristi tajni, slučajno generirani ključ jedinstven za svaku sesiju, a sav mrežni promet u potpunosti je zaštićen uključujući i sve vrijednosti podataka, SQL izraze, pohranjene procedure pozive i rezultate. Za RC4 algoritam mogu se koristiti različite dužine ključeva od 40-bita, 56-bita, 128-bita i 256-bita koji se koriste za šifrovanje originalnih podataka. RC4 algoritam je nekoliko puta brži od DES algoritma, pa se stoga koristi za šifrovanje veće količine podataka [4].

Oraclova napredna sigurnost implementira DES (Data Encryption Standard) algoritam sa standardnim 56-bitnim ključem za šifrovanje i DES40, sa 40-bitnom verzijom ključa.

Trostruki DES (3DES) šifarski algoritam je takođe podržan od strane Oraclove napredne sigurnosti. On šifruje blok podataka sa tri prolaza kroz DES algoritm. Na taj način 3DES pruža viši stepen sigurnosti poruke, ali uz degradaciju performansi. Veličina tih degradacija zavisi od brzine procesora koji obavlja šifrovanje. Šifrovanje podataka 3DES algoritmom obično traje tri puta duže nego što bi trajalo šifriranje istog bloka podataka standardnim DES algoritmom. 3DES je dostupan u verziji sa dva i tri ključa, a najučinkovitiji je pri dužini ključa od 112-bita i 168-bita.

6

AES (Advanced Encryption Standard) odobren je od strane Nacionalnog instituta za standarde i tehnologiju (NIST) i trenutno predstavlja standard za kriptografske algoritme. AES je najnoviji kriptografski algoritam razvijen da zamijeni DES. On u suštini simetrični blok – šifarski algoritam, koji može procesirati podatake u blokovima od 128 bita, koristeći šifarske ključeve sa dužinama od 128, 192, 256 i bitova, koji su navedeni kao AES-128, AES-192 i AES-256, respektivno [1].

2.2. INTEGRITET PODATAKA

Šifrovanjem podataka koji se prenose kroz mrežu obezbjeđuje se da neautorizovani korisnici ne mogu pristupiti originalnim podacima iz baze. Oraclova napredna sigurnost obezbijeđuje zaštitu od dvije vrste aktivnih napada:

Modifikacija podataka – Ova vrsta napada se dešava kada neautorizovana 3. strana, poput hakera, presretne poruku, izmjeni je i retransmituje. Npr. presretanjem podatka o nekoj bankovnoj transakciji moguće je izmjeniti vrijednost depozita na bankovnom računu.

Napad ponavljanjem - Ova vrsta napada se dešava kada se presretne jedan podatak koji se zatim neprekidno višestruko puta retransmituje. Npr. ako se presretne vrijednost bankarske transakcije od $100, retransmitovanjem datog podatka 100 puta ukupna vrijednost transakcije iznosiće $10000 [1].

Integritet podataka je veoma važan faktor sigurnosti. On obezbijeđuje da se sa sigurnošću možeme odrediti da li su podaci koji su preneseni preko mreže mijenjani. Zaštita Integriteta podataka se realizuje pomoću message digest, odnosno heš algoritama kao što su MD5 ili SHA – 1. Heš funkcije se izvršavaju nad podacima različite veličine, proizvodeći heš vrijednost h=H(M) fiksne dužine. Heš funkcije treba da zadovoljavaju sljedeće karakteristike:

Za svaki podatak M treba relativno lako izgenerisati h Za datu heš vrijednost h, treba da je izuzetno teško pronaći inverznu

funkciju H', tako da je H'(h)=M Za dati podatak M, treba da je jako teško pronaći podatak M1 koji bi imao

istu heš vrijednost, H(M)=H(M1) [4].

I MD5 i SHA – 1 algoritmi pružaju zaštitu od obe vrste napada. Oni za svaki podatak koji se prenosi kreiraju heš vrijednost, tj. „otisak podataka“, koji se prenosi

7

zajedno sa odgovarajućim podatkaom. Ukoliko je tokom transporta došlo do promjene podatka, automatski se mijenja i njegova heš vrijednost, na osnovu čega se utvrđuje narušavanje integriteta podataka.

2.2.1. HEŠ FUNKCIJE I ČUVANJE LOZINKI U BAZI PODATAKA

Poseban problem predstavlja smještanje i čuvanje lozinki u nekoj od tabela baze podataka. Ukoliko kontrola pristupa sistemu nije dovoljno dobra da odbije neovlaštene upade u sistem može doći do eksponiranja lozinki svih korisnika. Neovlašteni korisnici mogu doći u posjed administratorskih naloga i napraviti nenadoknadivu štetu na sistemu. Zbog toga se informacije o lozinkama obrađuju jednosmjernim heš funkcijama.

Prilikom prvog logovanja na sistem korisnik smišlja lozinku. Njeno smještanje u tabelu baze podataka treba obaviti na sledeći način:

Korisnik unosi korisničko ime i lozinku koju ćemo označiti sa lozinkaA Operativni sistem računa heš vrijednost unesene lozinke hA=h (lozinka A ) Dobijena vrijednost se smješta u tabelu kao uređeni par korisničko ime –

heš

Svaki sledeći put kada se korisnik bude prijavljivao navodiće korisničko ime i lozinku. Sistem računara će računati heš vrijednost unesene lozinke i upoređivati je sa heš vrijednošću u tabeli baze podataka. U koliko su te vrijednosti jednake, identitet korisnika je potvrđen. Napadač eventualnim provaljivanjem u sistem može doći do podataka korisničkog imena i heša, ali ne može rekonstruisati lozinku. Ovako zaštićeni sistemi najčešće se napadaju metodama grube sile ili nasilnom izmjenom heša lozinke [6].

2.2.2. HEŠ FUNKCIJE SA SALTOVANJEM

U kriptografiji, pod pojmom salt odnosno saltovanjem se podrazumjeva slučajano generisani niz bitova koji se koristi kao jedan od ulaza u heš funkciju, dok je drugi ulazni parametar najčešće korisnička lozinka. Kao rezultat se dobija heš vrijednost lozinke kombinovane sa slučajno generisanim nizom [8].

Vrlo često se koristi i dijeljenje lozinke na više manjih segmenata koji se hešuju nekim heš algoritmom koji kao ulazni parametar prima slučajno generisani niz bita (S) i

8

heš vrijednost dobijenu heširanjem prethodnog bloka lozinke (c i−1) kao u sledećem primjeru:

c1=p1⨁MD5 (S+ I )

c2=p2⨁MD5 (S+c1 )

...

cn=pn⨁MD5 (S+cn−1)

Gdje je:c i i-ti segment heš vrijednosti koja se dobije kao rezultat,pi i-ti segment lozinke izdjeljene na n dijelova,S slučajno generisani niz bajtova – salt,I inicijalni vektor

Konačna vrijednost heša dobija se spajanjem dobijenih blokova c1…cn

Za najveću učinkovitost salt se čuva tajnim i odvojeno od baze podataka u kojoj su smještene lozinke. U slučaju upada u sistem ili krađe baze podataka salt vrijednost ostaje nedostupna. Da bi dobili lozinku iz ukradenog heša, napadač mora da računa heš vrijednosti slučajnih karaktera i da praktično pokuša da pogoti vrijednost što je gotovo nemoguće ili enormno dugo traje.

Osnovna prednost korištenja saltovanih lozinki je da običan napad pogađanjem niza karaktera saltovane lozinke postaje potpuno neupotrebljiv, pod uslovom da je salt dovoljno velike dužine. To znači da napadač neće biti u mogućnosti da kreira tzv. rainbow tabelu koja u suštini predstavlja riječnik svih mogućih kombinacija (lozinka + salt), jer bi za to bilo potrebno izuzetno mnogo vremena ili jako mnogo resursa.

Pretpostavimo da je ukraden korisnikov tajni ključ koji se koristi za hešovanje lozinke, i da korisnik koristi kao lozinku neku od 200.000 engleskih riječi. Ako sistem koristi 32-bitni salt, to znači da haker mora da računa heš od 232=4.294 .967 .296 salt vrijednosti za svaku od 200.000 riječi posebno. Ukupan broj mogućih kombinacija dakle iznosi 232 ∙200.000=8,5899⋅ 1014. Iako je sama šifra relativno laka za pogoditi, salt je taj koje je čini praktično neprobojnom za sve nelegalne korisnike [7].

Na samom kraju, može se u prednosti saltovanja svrstati i to što se ovim konceptom omogućava korisniku da ima iste lozinke na različitim sistemima. Ako mu neko uspije provaliti, na neki određeni način, u nalog na jednom sistemu, to neće značiti

9

da mu je automatski ugrožen i nalog na drugom sistemu, jer bez obzira na iste lozinke, slučano generisani salt sa velikom sigurnošću nije isti na oba sistema.

2.3. KONFIGURACIJA ŠIFROVANJA I ZAŠTITE INTEGRITETA PODATAKA U ORACLE OKRUŽENJU

Mrežni administrator jednog Oracle okruženja je zadužen za postavljanje parametara šifrovanja i integriteta podataka. Ti parametri se nalaze u fajlu sql.ora, koji obično sadrži sljedeće elemente:

Aktivacija šifrovanja i integriteta Podešavanje šifrovanja i integriteta Podešavanje šifarskog ključa (opciono)

U bilo kojoj računarskoj mreži postoji mogućnost da server i klijent podržavaju

više od jednog kriptografskog i heš algoritma. Kada se ostvari konekcija, server selektuje koji se algoritam koristi sa spiska algoritama koji se nalaze u sqlnet.ora fajlu. To se odvija na taj način što server traži podudaranje algoritama omogućenih i na strani klijenta i na strani servera i odabira prvi algoritam u sopstvenoj listi koji se nalazi i u klijentskoj listi. Ako jedna od strana u komunikaciji ne definiše listu algoritama, svi instalirani algoritmi na toj strani su prihvatljivi. U suprotnom, ako bilo koja strana konfiguriše u listi algoritam koji nije instaliran, konekcija se raskida sa greškom ORA-12650. Moguće je konfigurisati bilo koji kriptografski algoritam omogućen od strane Oracla i bilo koji od dva omogućena algoritma za zaštitu integriteta, a li u jednom trenutku samo jedan kriptografski algoritam i jedan algoritam za zaštitu integriteta podataka se mogu koristiti za svaku sesiju.

Da bi podesili uključivanje šifrovanja i zaštite integriteta podataka, moguće je izabrati četiri definisane vrijednosti kao parametre šifrovanja i integriteta Oraclove napredne sigurnosti. Te četiri vrijednosti su navedene u listi po takvom redosledu da povećavaju nivo sigurnosti:

REJECTED ACCEPTED REQUESTED REQUIRED

10

Vrijednost REJECTED provodi minimalnu količinu sigurnosti između klijentske i serverske komunikacije, dok vrijednost REQUIRED provodi maksimalnu količinu mrežne sigurnosti. Vrijednost ACCEPTED je podrazumjevana za sve parametre (default value).

Vrijednost REJECT se postavlja ukoliko se ne želi odabrati sigurnosni servis iako je zahtjevan od druge strane. Ako je druga strana setovana na REQUIRED, konekcija se prekida sa greškom ORA – 12650, u suprotnom konekcija se nastavlja bez sigurnosnog servisa. Vrijednost ACCEPTED se setuje da omogući sigurnosni servis ako je na drugoj strani REQUIRED ili REQUESTED. U suprotnom sigurnosni servis je isključen. U ovom scenariju strana u komunikaciji ne zahtjeva sigurnosni servis ali ga omogućuje ako to druga strana zahtjeva. Vrijednost REQUESTED se setuje da omogući sigurnosni servis ako druga strana to omogućava. U ovom scenariju strana u komunikaciji definiše da je sigurnosni servis poželjan ali nije zahtjevan. Vrijednost REQUIRED se setuje kada se zahtjeva konekcija. Do prekida u konekciji dolazi kada je druga strana u komunikaciji setovana na REJESTED [1].

U tabeli 2.3. su prikazana stanja sigurnosnog servisa na osnovu kombinacija konfiguracionih parametara klijenta i servera.

Klijentska konf. Serverska konf. KonekcijaREJECTED REJECTED OFFACCEPTED REJECTED OFFREQUESTED REJECTED OFFREQUIRED REJECTED FAILEDREJECTED ACCEPTED OFFACCEPTED ACCEPTED OFFREQUESTED ACCEPTED ONREQUIRED ACCEPTED ONREJECTED REQUESTED OFFACCEPTED REQUESTED ONREQUESTED REQUESTED ONREQUIRED REQUESTED ONREJECTED REQUIRED FAILEDACCEPTED REQUIRED ONREQUESTED REQUIRED ONREQUIRED REQUIRED ON

Tabela 2.3. stanja sigurnosnog servisa [1]

11

2.3.1. KONFIGURACIJA PARAMETARA ŠIFROVANJA I INTEGRITETA KORIŠTENJEM ORACLE NET MANAGERA

Oracle Net Manager je Oraclov klijentski alat pomoću koga je veoma lako i jednostavno konfigurisati potrebne parametre kod procesa šifrovanja i zaštite integriteta podataka. Osim pomenutog ovaj alat omogućava i tzv. Imenovanje koje se koristi za identifikovanje lokacija ili servisa, poput dodjele imena bazi podataka i kreiranje ili konfigurisanje listenera za prijem klijentskih zahtjeva za konekciju.

Ovaj alat se pokreće na sl. način:Start > All Programs > Configuration and Migration Tools > Net Manager (Sl.

2.3.1.a)

Sl. 2.3.1.a Izgled prozora Oracle Net Managera

Da bi došli do prozora za konfiguraciju potrebno je sa hijerarhije na lijevoj strani odabrati polje Profile, a zatim na desnoj strani iz kombo-boksa odabrati opciju Oracle Advance Security. Nakon toga dobijamo prozor sa pet tabova, za konfiguraciju načina autentifikacije, integriteta, enkripcije (šifrovanja), SSL-a i drugih parametara.

12

Sl. 2.3.1.b Konfiguracija parametara šifrovanja i integriteta

Na slici 2.3.1.b prikazani su prozori za konfiguraciju šifrovanja i integriteta respektivno. Encryption Type, odnosno Checksum Level predstavljaju vrijednosti parametara Oraclove napredne sigurnosti (REJECTED, ACCEPTED, REQUESTED, REQUIRED). Da bi sačuvali konfiguraciju u sqlnet.ora potrebno je uraditi:

File > Save Network Configuration

Sadržaj sqlnet.ora fajla na serveru, odnosno klijentu bi trebalo da sadrži redove prikazane u tabeli 2.3.1.c.

Na Serveru

SQLNET.CRYPTO_CHECKSUM_SERVER = [accepted | rejected | requested | required]SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (valid_crypto_checksum_algorithm[,valid_crypto_checksum_algorithm])

Na Klijentu

SQLNET.CRYPTO_CHECKSUM_CLIENT = [accepted | rejected | requested | required]SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT = (valid_crypto_checksum_algorithm[,valid_crypto_checksum_algorithm])

Tabela 2.3.1.c Dio sadržaja konfiguracionog fajla, sqlnet.ora [1]

13

3. JAKA AUTENTIFIKACIJA KORISNIKA U ORACLOVOJ NAPREDNOJ SIGURNOSTI

U ovom dijelu će biti govora o principima jake autentifikacije i metoda koje se koriste za jaku autentifikaciju korisnika u Oracle mrežnom okruženju. Aktuelno izdanje Oracle Advance Security 11g R2 podržava dinamičko loadiranje autentifikacionih metoda. To praktično zanači da prilikom instalacije nije potrebno posebno specificirati sve moguće metode autentifikacije, već se bilo koja dostupna metoda može implemetirati u svako doba.

U ovom seminarskom radu će biti opisani sledeći metodi autentifikacije podržani od strane Oraclove napredne sigurnosti:

RADIUS Kerberos SSL

3.1. RADIUS AUTENTIFIKACIJA

RADIUS (Remote Authentication Dial-In User Service) je klijent – server sigurnosni protokol koji se široko kristi da omogući udaljenu autentifikaciju i pristup. Klijent i server razmijenjuju podatke preko RADIUS paketa enkapsuliranih u UDP paketima protokola transportnog sloja. Najčešće se koristi za provjeru identiteta na mrežnim uređajima koji, zbog ograničenih hardverskih resursa ne mogu da čuvaju veliki broj parametara za provjeru identiteta različitih korisnika Moguće je instalirati i konfigurisati mrežu da koristi različite RADIUS standarde, koji uključuju token i smart kartice. Dodatna prednost ovog protokola je što postoji mogućnost mijenjanja autentifikacionog metoda bez modifikacija u Oracle klijentu i Oracle baznom serveru [6].

Jedan RADIUS paket sadrži slijedeća polja:

KOD (Code) – polje dužine jednog bajta na osnovu čije vrijednosti se definiše tip RADIUS paketa, npr. zahtjev za pristup mreži (Access-Request) ili prihvatanje pristupa (Access-Accept).

IDENTIFIKATOR (Identifier, ID) – polje dužine jednog bajta koje omogućava jednostavnu identifikaciju parova zahtjev – odgovor.

DUŽINA (Length) – polje dužine dva bajta koje određuje veličinu paketa

14

AUTENTIFIKATOR (Authenticator) – vrijednost koja se koristi za provjeru ispravnosti odgovora koji šalje RADIUS server i za zaštitu korisničke lozinke.

ATRIBUTI (Attributes) – dio paketa u kome se nalaze proizvoljni atributi koji pripadaju samoj sesiji. Jedini obavezni atributi su korisničko ime i lozinka u zaštićenom obliku. Ostali atributi su opcioni.

Iz perspektive korisnika, kada se želi pristupiti Oraclovom serveru baze podataka, taj se server zapravo ponaša kao RADIUS klijent i obavještava RADIUS server (Sl. 3.1). RADIUS server:

Pretražuje korisničke sigurnosne informacije Prosleđuje informacije o autentifikaciji i autorizaciji između

odgovarajućeg autentifikacionog servera i servera Oraclove baze podataka

Dodjeljuje korisniku pristup bazi podataka Čuva u log fajlovima informacije o sesiji (kada, koliko često i koliko dugo

je korisnik bio konektovan na server baze podataka)

Sl. 3.1 RADIUS u Oraclovom okruženju [1]

Oraclov server baze podataka se ponaša kao RADIUS klijent koji prenosi informacije između Oraclovog klijenta i RADIUS servera. Na isti način RADIUS server prenosi informacije između Oraclovog servera baze podataka i odgovarajućeg autentifikacionog servera. Provjera identiteta korisnika se odvija na sledeći način:

Klijentov zahtjevKorisnik započinje sesiju generisanjem zahtjeva koji obavezno sadrži dva atributa korisnika, User-Name i User-Password. Bajt ID tog paketa se bira proizvoljno. U polju Autentifikator je vrijednost Request Authenticator, koja je generisana od strane generatora pseudoslučajnih sekvenci. RADIUS paket nije zaštićen ni na koji način izuzev njegovog atributa User-Password koji je šifrovan [1].

15

Serverov odgovorNakon prijema zahtjeva, server provjerava da li postoji tajni ključ koji on dijeli sa RADIUS klijentom. Ako takav ključ ne postoji, zahtjev se odbija, u suprotnom server dešifruje vrijednost atributa User-Password i dobija korisničku lozinku. U koliko data lozinka pripada datom paru korisničko ime – lozinka autentifikacija je uspijela. Vrijednost ID koju server šalje se ne mijenja, a vrijednost Request Authenticator se mijenja sa njenom heš vrijednošću [1].

Obrada serverskog odgovoraKada primi odgovor od servera klijent provijerava da li je vrijednost u poljima ID identična u zahtjevu i odgovoru, na osnovu čega zaključuje da se odgovor zaista odnosi na dati zahtjev. Hešovanjem vrijednosti Request Authenticator iz zahtjeva trebala bi se dobiti ista vrijednost kao i u polju Request Authenticator iz odgovora. Ako su date vrijednosti identične klijent smatra da je identitet korisnika uspiješno provjeren i odobrava mu pristup bazi podataka, u suprotnom se sesija raskida [1].

3.1.1. MODOVI RADIUS AUTENTIFIKACIJE

Autentifikacija korisnika može da se odvija u dva moda: Sinhroni mod Asinhorini (Challenge-Response) mod

U sinhronom modu RADIUS za autentifikaciju koristi šifre i SecurID token kartice. Na slici 3.1.1.a je prikazan redoslijed kojim se odvija sinhrona autentifikacija:

1. Korisnik se loguje kucajući svoju šifru. Klijent prenosi podatak o konekcionom stringu do servera baze podataka.

2. Server baze podataka, koji se ponaša kao RADIUS klijent, prenosi podatke do RADIUS servera.

3. RADIUS server prenosi podatke do odgovarajućeg autentifikacionog servera4. Autentifikacioni server vraća Access Accept ili Access Reject poruku nazad

do RADIUS servera.

16

5. RADIUS server prenosi odgovor do servera baze podataka odnosno RADIUS klijenta

6. I na kraju se odgovor prosledi do klijenta [1].

Kada se koristi SecureID autentifikacija, svaki korisnik ima tzv. token karticu koja generiše dinamički broj koji se mijenja svakih 60 sekundi. Da bi dobili pristup serveru baze podataka, odnosno RADIUS klijentu, korisnik mora da unese svoj PIN i broj koji je trenutno generisan na SecureID kartici. Kada autentifikacioni server izvrši validaciju korisnika on vraća accept paket natrag, sve do klijenta.

U asinhronom modu rada nema potrebe da korisnik na početku unosi korisničko ime i

lozinku. Umjesto toga postoji grafički interfejs koji to od korisnika zahtjeva u kasnijim procesima. Na slici 3.1.1.b je prikazan tok asinhrone autentifikacije:

1. Korisnik zahtjeva konekciju na server baze podataka. Klijent prenosi zahtjev do servera baze podataka.

2. Server baze, odnosno RADIUS klijent, prenosi zahtjev do RADIUS servera

3. RADIUS server prenosi zahtjev do odgovarajućeg autentifikacionog servera poput Smart kartica, SecureID ACE ili token servera

4. Autentifikacioni server šalje odgovor u vidu slučajnog broja nazad do RADIUS servera

5. RADIUS server prosleđuje slučajan broj RADIUS klijentu, odnosno serveru baze podataka.

6. Slučajan broj se proledi korisniku, kome se prikaže odgovarajući korisnički interfejs.

17

Sl. 3.1.1.a Tok sinhrone autentifikacije [1]

7. Korisnik odgovara na taj način što dobijeni broj unese u token karticu koja na osnovu njega generiše dinamičku šifru koju korisnik treba da unese u odgovarajuće polje na prikazanom grafičkom interfejsu. Podatak o šifri se zatim prosleđuje do servera baze podataka, odnosno RADIUS klijenta.

8. Server baze podataka, odnosno RADIUS klijent prosleđuje podatak do RADIUS servera.

9. RADIUS server prosleđuje podataka do odgovarajućeg autentifikacionog servera na validaciju

10.Server za autentifikaciju vraća Access Accept ili Access Reject poruku nazad do RADIUS servera.

11.RADIUS server prenosi odgovaor do servera baze podataka, odnosno RADIUS klijenta.

12.Na kraju se odgovor prosledi do samog klijenta.

Kada se radi o smart card autentifikaciji, korisnik se loguje insertujući smart karticu (plastičnu karticu sa ugrađenim integrisanimkolom za autentifikaciju) u hardverski uređaj za očitavanje kartica. Informacija sa smart kartice se prosleđuje do autentifikacionog servera kao što je prethodno opisano. Nakon toga se od korisnika zahtjeva unos PIN-a, kao i drugih informacija koje su sadržane na smart kartici [1].

Veoma često se koristi i autentifikacija sa ActivCard tokenom, što je u suštini ručni uređaj sa malom tastaturom i displejom za dinamički prikaz šifri. Kada korisnik zahtjeva pristup bazi podataka unoseći pri tom šifru, informacija putuje do autentifikacionog servera kao što je prethodno objašnjeno. Autentifikacioni server kao odgovor vraća string koji korisnik treba da unese u token i zatim očita broj sa njegovog disppleja. Za uspješnu autentifikaciju korisnik kao odgovor mora autentifikacionom serveru proslediti generisani broj.

3.1.2. KONFIGURACIJA RADIUS AUTENTIFIKACIJE KORIŠTENJEM ORACLE NET MANAGERA

Nakon pokretanja Oracle Net Managera potrebno je izabrati opciju Oracle Advance Security i kliknuti na tab Authentication. Iz Available Methods izabrati RADIUS. Opcijom Promote postavljamo željeni metod kao primarni metod autentifikacije (Slika 3.1.2.a). Nakon svih podešavanja potrebno je sačuvati konfiguraciju (File > Save Network Configuration), čime je završena konfiguracija na klijentu sa automatskim popunjavanjem sqlnet.ora fajla sa linijom:

SQLNET.AUTHENTICATION_SERVICES=(RADIUS)

18

Sl. 3.1.1.b Tok asinhrone autentifikacije [1]

Sl.3.1.2.a Konfiguracija RADIUS-a u Oracle Net Manageru

Sledeći zadatak jeste konfiguracija RADIUS-a na serveru baze podataka. Tu se praktično mogu izdvojiti tri operacije:

Kreiranje fajla za RADIUS tajni ključ na serveru Konfigurisanje RADIUS parametara na serveru (sqlnet.ora fajl) Setovanje inicijalnih parametara na serveru

Potrebno je omogućiti da svaki RADIUS klijent od RADIUS servera dobije

odgovarajući tajni ključ. Zato, administrator RADIUS servera mora za svakog RADIUS klijenta generisati djeljeni tajni ključ, koji mora biti veći od 16 karaktera. To se riješava na taj način što se prvo na serveru baze podataka kreira direktorij:

ORACLE_HOME\network\security

Nakon toga je potrebno kreirati fajl radius.key, koji će sadržati dijeljeni tajni ključ kopiran sa RADIUS servera, i smijestiti ga u kreirani direktorijum. Radi sigurnosnih mijera treba promjeniti i file permission za radius.key na read only kako bi bio dostupan samo administratoru (Oracle se oslanja na file system kako bi sačuvao ovaj fajl tajnim) [1].

Konfiguracija RADIUS parametara na serveru je slična kao i na klijentu, pa Authentication tab u Orcale Net Manageru treba izgledati kao na slici 3.1.2.a. Osim toga potrebno je odraditi i dodatna podešavanja koja se nalaze na tabu Other Params kao što je to prikazano na slici 3.1.2.b.

19

Sl. 3.1.2.b RADIUS Konfiguracija za server – ostali parametri

Host Name je podešeno na localhost iz razloga što mi je baza na lokalnoj mašini. U suprotnom slučaju treba unijeti odgovarajući naziv hosta.

Port Number definiše broj porta na kome osluškuje RADIUS server. Uobičajena vrijednost je 1645.

Timeout definiše vrijeme koje Oraclov server baze podataka čeka na odgovor od RADIUS servera. Uobičajena vrijednost je 15 sekundi.

Number of Retries definiše broj pokušaja koji Oraclov server baze podataka ima na raspolaganju da ponovo pokuša slanje neuspijlo poslate poruke RADIUS serveru.

Secret File predstavlja lokaciju na kojoj se nalazi fajl sa tajnim ključem na serveru.

Send Accounting se koristi za automatsko kreiranje log fajlova sa informacijama o pristupu Oraclovom serveru baze podataka i za njihovo čuvanje na RADIUS serveru.

Ova opcija se omogućuje unošenjem „ON“ u dato polje, a moguće ju je korititi samo ako i RADIUS i autentifikacioni server to podržavaju.

Challenge Response je opcija koja se uključuje kada se želi aktivirati Challenge Response odnosno asinhroni mod.

20

Default Keyword je ključna riječ koja se šalje serveru kada se želi ostvariti pristup serveru baze podataka.

Interface Class Name je naziv Javine klase koja se koristi za iscrtavanje grafičkog korisničkog interfejsa za unos šifre ili PIN-a.

Na kraju je još potrebno setovati inicijalizacione parametre na serveru baze podataka koji su locirani u fajlu ORACLE_BASE\admin\db_name\pfile sa slijedećim vrijednostima:

REMOTE_OS_AUTHENT=FALSEOS_AUTHENT_PREFIX=""

Veoma je bitno da REMOTE_OS_AUTHENT ne bude setovan na TRUE, jer bi to omogućilo nekome, ko koristi nesiguran protokol, poput TCP, da se loguje na operativni sistem [1].

3.1.3. NEDOSTACI RADIUS PROTOKOLA

Prilikom upotrebe RADIUS protokola javlja se nekoliko pitanja o sigurnosti, koja su posledica arhitekture i implementacije protokola. Prvo pitanje jeste adekvatan izbor kriptografskih algoritama za zaštitu korisničke lozinke. Za tu upotrebu ne bi se trebali koristiti tzv. protočni algoritmi, ali nažalost u tu vrstu spadaju i algoritmi za zaštitu lozinke i generator pseudoslučajnog niza koji koristi MD5 heš algoritam.

Sledeći problem u sigurnosti jeste predvidljivost generatora pseudoslučajnog niza koji se koristi za generisanje atributa Request Authenticator. U suštini sigurnost RADIUS protokola najviše zavisi od nepredvidljivosti ovog algoritma. Danas ne postoji protokol koji bi riješio navedene probleme, mada su sve veće šanse da bi u budućnosti taj nivo mogao dostići protokol Diameter, koji za razliku od RADIUS-a koristi usluge TCP protokola na transportnom sloju. Diameter je još u razvoju [6].

21

3.2. KERBEROS AUTENTIFIKACIJA

Kerberos je jedan od najpoznatijih protokola za provjeru korisničkog identiteta. Ime je dobio po Kerberu, zbog toga što centar za distribuciju ključeva, poput mitskog bića, ima tri „glave“, tj. server sa bazom, server za provjeru identiteta i server za izdavanje karata. Najveća prednost Kerberos sistema jeste tzv. prijavljivanje samo jednom (Single Sign On), koje korisnicima omogućava da se samo jednom prijave na sistem i da nakon toga u skladu sa svojim ovlaštenjima ima pristup Oraclovoj bazi podataka ili drugim mrežnim resursima. To je veoma efikasan način zaupravljanje velikim brojem korisničkih lozinki i naloga, a tokođe se i značajno ubrzava pristup. Osim svega navedenog, kod ovog protokola se povjerljive informacije, poput korisničkih lozinki, nikada ne šalju preko mreže u vidu otvorenog teksta, što ovaj protokol čini otpornim na napade prisluškivanjem i analize mrežnog saobraćaja.

Kerberos protokol razvila je firma MIT, osamdesetih godina prošlog vijeka ali je on tek počeo da se koristi 1989. godine i verzije 4. U verziji 5 uklonjeni su praktično svi bitniji nedostaci ovog protokola i omogućeno je njegovo korištenje na svim hardverskim platformama, a danas predstavlja jedan od najznačajnijih protokola za provijeru identiteta u mrežnom okruženju. Najčešće se ipak koristi na Windows operativnim sistemima.

Srce Kerberosa jeste centralni entitet ili centar za distribuciju ključeva, KDC (Key Distribution Center), koji u suštini predstavlja manju bazu podataka u kojoj su smiješteni provijereni parametri svih entiteta Kerberos sistema. Svi drugi entiteti bezuslovno vijeruju ovom centru entitetu. Umjesto da koristi lozinke server klijentu šalje specijalne šifrovane poruke kada ovaj pošalje zahtjev za konekciju. Te poruke su obično ograničenog perioda važenja (8 – 24h), a još se nazivaju i kartama ili propusnicama [6].

3.2.1. OSNOVNI POJMOVI I KONCEPTI

Svaki entitet u Kerberos sistemu poput korisnika, racunara, servera baze podataka, mrežnog servisa, itd. opisan je odgovarajućim imenom u bazi KDC servera. To ime čini jednoznačno identifikovanje entiteta u čitavom sistemu i dio je principala.

Principal je običan string koji sadrži odgovarajući tajni ključ koji je poznat samo KDC serveru i entitetu koji je opisan tim principalom. Taj ključ se koristi za šifrovanje poruka koje se razmijenjuju u postupku provjere identiteta. Struktura principala definisana je u specifikaciji protokola, a uopšteno ima oblik:

22

Identity/instance@realm

Identity – polje koje definiše polje ime entiteta (računara, servera, baze, servisa) i obavezno je za svaki principal.

Instance – polje koje nije obavezno, ali je korisno za bliže određivanje entiteta, jer definiše npr. računar na kome je servis pokrenut ili grupu kojoj korisnik pripada itd.

realm – polje koje u terminologiji Kerberosa označava domen. On je jedinstven za svaki Kerberos sistem posebno i jednostavno ga razgraničava od bilo kog drugog Kerberos sistema u okruženju. Prema konvenciji ova oblast najčešće odgovara DNS imenu domena organizacije, s tim što se označava velikim slovima. Npr. oblast za DNS domen vet.gov.ba označava se VET.GOV.BA

Primjer Kerberos principala:

mladen.todorovic/dbadmin@VET.GOV.BA – znači da je korisnik mladen.todorovic član grupe dbadmin u organizaciji sa domen imenom vet.gov.ba

ssh/server.vet.gov.ba@VET.GOV.BA – znači da je ssh servis na računaru server.vet.gov.ba aktivan

3.2.2. CENTAR ZA DISTRIBUCIJU KLJUČEVA

Kao što je već ranije pomenuto, KDC server je jezgro Kerberos sistema i entitet kome svi bezuslovno vjeruju i kome se svi entiteti obraćaju kada hoće da provjere nečiji entitet. KDC server se sastoji od slijedeće tri komponente najčešće implementirane u jednom servisu:

Baza principala

Ova baza sadrži sve principale Kerberos sistema sa odgovarajućim tajnim ključevima. Konkretna implementacija zavisi od konkretnog operativnog sistema, a njeno kompromitovanje ugrožava sigurnost cijelog sistema.

Server za provjeru identiteta, AS (Authentication Server)Server za provjeru identiteta izdaje TGT kartu (Ticket Granting Ticket) svim klijentima koji žele da se prijave na sistem. TGT karta se izdaje prilikom prijavljivanja na sistem i klijentima omogućava da kasnije traže kartu za pristup Oraclovoj bazi podataka i drugim mrežnim servisima.

23

Server za dodijelu karata, TGS (Ticket Granting Server)Za razliku od servera za provjeru identiteta koji klijentima izdaje inicijalnu TGT kartu prilikom logovanja na sistem, server za dodijelu karata je zadužen za izdavanje karata za pristup Oraclovoj bazi podataka ili nekim mrežnim resursima. Klijent mora prvo poslati inicijalnu TGT kartu i ime željenog resursa kome želi da pristupi, a zatim TGS provjerava da li data karta ispravna i prihvata ili odbacuje zahtjev.

Centar za distribuciju ključeva mora biti stalno dostupan kako bi čitav sistem funkcionisao bez problema. U koliko bi server otkazao ni jedan entitet ne bi mogao da se prijavi na sistem. Zbog toga se često uvodi i dodatni server za distribuciju ključeva, ili sekundarni server. Njegova svrha je prvenstveno da preuzme kontrolu primarnog servera u slučaju otkaza, a vrlo često postoji potreba i za uvođenjem više od jednog takvog servera. U slučaju postojanja jednog primarnog i više sekundarnih servera važno je obezbijediti i njihovu međusobnu sinhronizaciju, kako bi se na svima nalazili ažurirani podaci [6].

Kerberos karte koje izdaje server za dodijelu karata služe isključivo za provjeru identiteta entiteta koji zahtjeva pristup serveru baze podataka ili nekom drugom mrežnom resursu i za uspostavljanje tajnog ključa koji će se koristiti za šifrovanje podataka tokom komunikacije. Svaka Kerberos karta sadrži sljedeće podatke:

Ime principala koji zahtjeva pristup Ime principala za koji se traži pristup Vremenska oznaka Rok važenja karte Lista IP adresa sa kojih se može koristiti karta Tajni ključ za komunikaciju sa traženim resursom

Vremenska oznaka i rok važenja karte su veoma bitni parametri jer obezbijeđuju dodatnu sigurnost komunikacije. Prilikom prijema zahtjeva server upoređuje vrijeme kreiranja zahtjeva i lokalno vrjeme, te ako je razlika veća od maksimalne dozvoljene (inicijalno 5 min) zahtjev se odbija. Svaka karta ima i svoj važenja u kom se mora iskoristiti i nakon isteka tog roka postaje neupotrebljiva. Rok važenja karte štiti sistem od napada ponavljanjem u kome neovlašćeni korisnik prvo presreće i snima mrežni saobraćaj, a zatim ga neograničeno puta ponavlja [6].

24

3.2.3. RAZMIJENA PORUKA U KERBEROS KOMUNIKACIJI

Kerberos je u najvećem dijelu zasnovan na Needham-Schroederovom protokolu za provjeru identiteta uz dodatne funkcionalnosti koje su implementirane u najnovijim verzijama ovog protokola. Na slici 3.2.3. prikazana je standardna razmijena poruka u Kerberos komunikaciji.

Sl. 3.2.3 Razmijena poruka u Kerberos komunikaciji

1. KRB_AS_REQ zahtjevPostupak provijere identiteta započinje slanjem ovog zahtjeva KDC

autentifikacionom serveru. Zahtjev se šalje u obliku otvorenog teksta i sadrži slijedeće:

Ime principala kerberos klijenta koji inicira zahtjev Vremensku oznaku (lokalno vrijeme u momentu slanja zahtjeva) Ime principala TGS servera Rok važenja karte

2. KRB_AS_REP odgovorKada primi zahtjev klijenta KDC AS server sprovodi kompletnu proceduru

opisanu u prethodnom poglavlju koja uključuje provjeru klijentskog principala u bazi, vremensku oznaku, rok važenja itd. U koliko su svi uslovi ispunjeni server

25

Klijent KDC (AS + TGS)

Oraclov server baze podataka

[1] KRB_AS_REQ

[2] KRB_AS_REP

[3] KRB_TGS_REQ

[4] KRB_TGS_REP

[6] KRB_SRV_REQ

[6] KRB_SRV_REP

priprema odgovor šifrovan tajnim ključem koji je poznat samo KDC serveru i klijentu. KRB_AS_REP odgovor se sastoji od dva dijela. Prvi dio je šifrovan korisnikovim tajnim ključem i sadrži sljedeće elemente:

Ključ sesije koji će klijent koristiti u nastavku komunikacije sa TGS serverom. Ovim ključem će korisnik u nastavku šifrovati sve poruke upućene TGS serveru.

Ime principala TGS servera Rok važenja karte

Drugi dio poruke sadrži već pomenutu TGT kartu šifrovanu ključem koji poznaju samo KDC AS i TGS serveri i korisnik je ne može dešifrovati. Tako šifrovanu TGT kartu korisnik čuva u svojoj keš memoriji i koristi je pri slanju zahtjeva za pristup Oraclovoj bazi podataka ili nekim drugim mrežnim resursima unutar Kerberos sistema. Kada karta istekne klijent mora zatražiti izdavanje nove karte novim generisanjem KRB_AS_REQ zahtjeva. Šifrovana TGT karta sadrži sljedeće:

Ključ sesije koji klijent koristiti u komunikaciji sa TGS serverom Ime principala Kerberos klijenta Rok važenja karte Vremensku oznaku KDC servera Klijentovu IP adresu, koja se dobija iz inicijalnog KRB_AS_REQ zahtjeva

3. KRB_TGS_REQ zahtjev

Nakon primanja KRB_AS_REP poruke, klijent svojim tajnim ključem kojeg dijeli sa KDC serverom dešifruje prvi dio poruke koja sadrži ključ sesije za dalju komunikaciju sa TGS serverom. U koliko je dešifrovanje uspjelo klijent dobijeni ključ zajedno sa dobijenom TGT kartom (koju ne može dešifrovati) smiješta u keš. U ovom trenutku klijent nema pristup bazi podataka ili nekom drugom mrežnom resursu unutar Kerberos sistema, ali posjeduje ključ i TGT kartu koji mu omogućavaju da od TGS servera zatraži taj pristup. Kada klijent želi da pristupi npr. Oraclovom serveru baze podataka on prvo šalje TGS serveru KRB_TGS_REQ zahtjev koji sadrži sljedeće:

Ime principala Oraclovog servera baze podataka Rok važenja karte TGT kartu iz keša Autentifikator koji jedinstveno identifikuje svaki zahtjev za pristup i

potvrđuje da klijent posjeduje ključ sesije

4. KRB_TGS_REP zahtjev

26

Nakon primanja klijentovog zahtjeva, KDC TGS server formira odgovor sa novim ključem sesije koji će klijent koristiti za razmjenu poruka sa Oraclovom bazom podataka za koju je tražio pristup. Format ovog odgovora sličan je odgovoru koji generiše AS server u koraku 2. Poruka se takođe sastoji iz dva dijela, gje je prvi dio šifrovan ključem sesije ugovorenim u prva dva koraka. Poruka se sastoji od sledećih komponenti:

Ime principala Oraclovog servera baze podataka Rok važenja karte Ključ sesije za razmjenu poruka sa Oraclovim serverom baze podataka

Drugi dio poruke je TGS karta za pristup Oraclovim serverom baze podataka šifrovana tajnim ključem koga dijele KDC TGS server i Oraclov server tako da ga klijent ne može dešifrovati. TGS karta sadrži sledeće:

Ključ sesije za razmjenu poruka sa Oraclovim serverom baze podataka Ime klijentovog principala Rok važenja karte Vremenska oznaka Klijentovu IP adresu

Klijent dešifruje primljenu poruku ključem sesije iz prvog koraka, a zatim smiješta dobijenu TGS kartu i novi ključ sesije u keš memoriju. Klijent dalje koristi TGS kartu i ključ sesije prilikom pristupa Oraclovim serverom baze podataka [6].

5. KRB_SRV_REQ zahtjevOvaj zahtjev se upućuje direktno Oraclovim serverom baze podataka i pored TGS karte sadrži upit kojim se npr. od baze zahtjevaju određeni podaci

6. KRB_SRV_REP zahtjevKada primi KRB_SRV_REQ zahtjev server dešifruje TGS kartu i provjerava je, te ako je još uvijek važeća prelazi na pripremu podatke iz baze, koji predstavljaju rezultat dobijenog upita. Podaci se šifruju ključem sesije i šalju nazad klijentu kao odgovor.

3.2.4. KONFIGURACIJA KERBEROS AUTENTIFIKACIJE KORIŠTENJEM ORACLE NET MANAGERA

27

Nakon pokretanja Oracle Net Managera potrebno je izabrati opciju Oracle Advance Security i kliknuti na tab Authentication. Iz Available Methods izabrati KERBEROS5. Opcijom Promote postavljamo željeni metod kao primarni metod autentifikacije (Slika 3.2.4.a). Nakon toga treba izabrati tab Other Params i na njemu iz opcije Authentication Service izabrati opciju KERBEROS(V5). U polje Service potrebno je unijeti ime koje je će Oraclova baza koristiti za dobijanje Kerberos karti. Čim se u polje unese određeno ime ostali parametri se automatski aktiviraju (Slika 3.2.4.b). Nakon svih podešavanja potrebno je sačuvati konfiguraciju (File > Save Network Configuration), čime je završena konfiguracija na klijentu odnosno serveru, sa automatskim popunjavanjem sqlnet.ora fajla sa linijama:

SQLNET.AUTHENTICATION_SERVICES=(KERBEROS5)SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=kservice

Sl. 3.2.4.a Podešavanje Kerberos autentifikacije Sl. 3.2.4.b Podešavanje Kerberos autentifikacije

Parametar Credential Cache File definiše putanju do keš fajla.

Parametar Configuration File definiše putanju do Kerberos konfiguracionog fajla. On sadrži ime principala standardnog KDC servera i mapu principala ostalih hostova.

Parametar Realm Translation File definiše putanju do tzv. translacionog fajla koji se koristi da mapira imena hostova u imena principala.

28

Parametar Key Table definiše putanju do fajla gdje su mapirani Kerberos principali sa njihovim tajnim ključevima. Koristi ih Oraclov server za dešifrovanje dolazećih autentifikacionih poruka od strane klijenta.

Parametar Clock Skew definiše koliko sekundi je dozvoljeno da prođe od izdavanja Kerberos karte prije nego što se ona bude proglašena nevažećom [1].

Kao što je bio slučaj kod RADIUS-a i ovdje je potrebno postaviti inicijalne parametre:

REMOTE_OS_AUTHENT=FALSEOS_AUTHENT_PREFIX=""

I u Kerberos sistemu je veoma bitno da REMOTE_OS_AUTHENT ne bude setovan na TRUE, jer bi to omogućilo nekome, ko koristi nesiguran protokol, poput TCP, da se loguje na operativni sistem [1].

4. SSL PROTOKOL

SSL predstavlja industrijiski standardni protokol originalno dizajniran od strane Netscape Communication korporacije za sigurnu komunikaciju i razmjenu podataka preko mreže. SSL koristi RSA kriptografski algoritam sa javnim ključem za provjeru

29

identiteta klijenta, DES i RC4 algoritme za šifrovanje podataka i SHA i MD5 heš funkcije za provjeru integriteta podataka.

SSL podržava sigurnu autentifikaciju korisnika direktno preko nekog od ugrađenih autentifikacionih metoda (RADIUS, Kerberos,...) ili indirektno preko eksternog autentifikacionog servera, ili oboje. Tradicionalna SSL autentifikacija na web stranicama se oslanja na samo serversku autentifikaciju, tako da korisnici vjeruju serveru sa kojim komuniciraju. Oraclova napredna sigurnost zahtjeva i klijentsku i serversku autentifikaciju, a kao faktori autentifikacije mogu se koristiti korisničko ime i lozinka, smart i token kartice, dvofaktorska autentifikacija i X.509 digitalni sertifikati [1].

Kada se digitalni sertifikati koriste za autentifikaciju klijenta, svaka krajnja tačka ima svoj digitalni certifikat koji sadrži javni ključ. Krajnja tačka koristi odgovarajući privatni ključ za digitalno potpisivanje podataka prije slanja do druge krajnje tačke, koja provjerava potpis koristeći javni ključ učesnika sa kojim komunicira. Digitalni potpis se realizuje algoritmima kao što su RSA i Digital Signature Standard (DSS). Pored provjere autentičnosti korištenjem sertifikatima, SSL takođe treba da podrži listu opozvanih certifikata, odnosno tzv. Certificate Revocation List (CRL) [3].

Dakle, koristeći SSL prilikom komunikacije između klijenta i Oraclovog servera, moguće je:

Šifrovati konekciju između klijenta i softvera Autentifikovati bilo kog klijenta ili aplikacionog servera na Oraclov server

baze podataka koji je konfigurisan da komunicira preko SSL protokola

Ovaj protokol formira poseban komunikacioni sloj smješten iznad transportnog sloja, a ispod aplikacionog. Protokol je transparentan i potpuno nezavisan od aplikacionog sloja, a zaštićenu vezu uspostavlja prije nego što aplikacioni sloj primi ili pošalje prvi bajt podataka. SSL protokol za rukovanje, odnosno uspostavljanje sesije se naziva SSL Handshake i uključuje slijedeće korake:

Klijent i server utvrđuju koji šifarski algoritam će koristiti za šifrovanje podataka

Server šalje svoj sertifikat klijentu, a klijent provjerava da li je dati sertifikat potpisan od strane mjerodavnog sertifikacionog tijela (CA)

Klijent šalje svoj sertifikat serveru koji je digitalno potpisao svojim privatnim ključem, a server korištenjem javnog ključa klijenta vrši verifikaciju potpisa, a zatim provjerava da li je dati sertifikat potpisan od strane mjerodavnog sertifikacionog tijela (CA)

30

Klijent i server razmjene ključeve korištenjem kriptografije javnih ključeva. Na osnovu ovih informacija svako generiše ključ sesije koji se koristi za šifrovanje i dešifrovanje podataka tokom komunikacije [6].

4.1. PKI U ORACLE OKRUŽENJU (Wallets)

Sertifikaciono tijelo ili Sertifikacioni autoritet, CA predstavlja jezgro čitavog PKI sistema. Čitavo povjerenje sadržano u PKI infrastrukturi zavisi od digitalnog potpisa CA koji se formira na bazi asimetričnog kriptografskog algoritma, kao što je RSA, i asimetričnog privatnog ključa CA. U najkraćem, ideja se sastoji u tome da određeno ovlašte tijelo (CA) preuzme lične podatke određenog korisnika (klijenta) i njegov javni ključ, te nakon toga preuzete podatke formatira na standardizovan način u obliku digitalnog sertifikata, koga zatim digitalno potpiše. Digitalni sertifikat, na osnovu digitalnog potpisa CA, predstavlja pouzdanu vezu identiteta određenog korisnika i njegovog javnog ključa. Standard za formiranje digitalnih sertifikata je X.509 i mogu ga prepoznati standardni programi za pretraživanje poput različitih browsera [1].

Wallet je Oraclov kontejner koji se koristi za smještanje privatnih ključeva, digitalnih sertifikata i vjerodostojnih sertifikata koje koristi SSL. U Oraclovom okruženju svaki entitet koji želi komunicirati preko datog protokola mora imati wallet koji sadrži X.509 verziju sertifikata, privatnih ključeva i listu sertifikata kojima se vjeruje. Dakle Wallet igra ulogu sličnu smart kartici [1].

Wallet se može konfigurisati veoma lako korištenjem Oracle Wallet Managera. Oracle Wallet Manager predstavlja još jedan od Oraclovih alata koje administratori sigurnosti koriste da:

generišu par javni-tajni ključ i kreiraju zahtjevani sertifikat sačuvaju korisnički sertifikat zajedno sa njegovim privatnim ključem konfigurišu listu sertifikata kojima se vjeruje

4.2. SSL U KOMBINACIJI SA DRUGIM AUTENTIFIKACIONIM METODAMA

Konfiguracija u kojoj se SSL koristi u kombinaciji sa drugim autentifikacionim metodama podržanim od strane Oraklove napredne sigurnosti najbolje je prikazana na slici 4.2. U ovom primjeru SSL je iskorišten da inicira i uspostavi handshake (serversku

31

autentifikaciju), a alternativna autentifikaciona metoda se koristi za autentifikaciju klijenta [1].

Sl. 4.2. SSL u kombinaciji sa drugim autentifikacionim metodama [1].

1. Klijent zahtjeva konekciju na Oraklov server baze podataka2. SSL započinje handshake tokom koga se server autentifikuje klijentu i u

dogovoru sa njim ustanovi koji će se kriptografski algoritam koristiti za šifrovanje podataka

3. Kada se handshake završi uspješno, korisnik traži pristup bazi podataka4. Oraclov server baze podatka autentifikuje korisnika pomoću autentifikacionog

servera, koristeći autentifikacioni metod RADIUS ili Kerberos5. Nakon validacije koju sprovede autentifikacioni server, Oraclov server baze

podataka dozvoljava pristup autorizovanom korisniku i on može pristupiti bazi na siguran način preko SSL-a.

4.3. KONFIGURACIJA SSL-a POMOĆU ORACLE NET MANAGERA

Prije nego se pređe na samu konfiguraciju SSL-a potrebno je provjeriti da je wallet uspješno kreiran i aktivan. To se može uraditi pokretanjem Oracle Wallet Managera i provjerom da li je status sertifikata „Ready“ i da li je automatsko logovanje

32

uključeno. Ukoliko do tada nije bio kreiran ni jedan wallet potrebno ga je kreirati opcijom Wallet > New. Pojavi se prozor u kome je potrebmo unijeti lozinku za novi wallet. Kreiranje novog praznog walleta završava se sa Wallet > Save In System Default. Da bi SSL mogao funkcionisati potrebno je u njega dodati i korisnički sertifikat. Da bi kreirali PKCS#10 sertifikat potrbno je uraditi sledeće:

Selektovati malo prije kreirani wallet i odabrati opciju Operations > Add Certificate Request. Pojavljuje se prozor prikazan na slici 4.3.a

Sl. 4.3.a Kreiranje sertifikata u walletu

Od korisnika se zahtjevaju informacije poput imena, naziva organizacije, organizacione jedinice, grada i države. Za dužinu ključa preporučuje se da se ne uzima vrijednost manja od 1024. Klikom na OK završeno je kreiranje sertifikata [1].

Nakon što je kreiranje walleta i sertifikata uspješno urađeno ostaje još samo da se SSL konfiguriše na klijentu i serveru. To se lako može uraditi upotrbom Oracle Net

33

Managera, koji je do sada više puta korišten prilikom konfiguracije šifrovanja, integriteta, te metoda autentifikacije (RADIUS i Kerberos). Izgld prozora je prikazan ana slici 4.3.b.

Sl. 4.3.b Konfiguracija SSL-a na serveru i klijentu

Važno je još samo napomenuti da treba voditi računa o tipu kriptografskih algoritama koji se izaberu, jer se oni moraju podudarati na serveru i na klijentu. Ostale opcije poput uključivanje CRL listi, zahtjevanja izričite verzije SSL-a i klijentske autentifikacije su opcione.

ZAKLJUČAK

34

Prateći razvoj informacionih tehnologija, sa posebnim osvrtom na baze podataka, može se zaključiti da se sve veća i veća pažnja poklanja sigurnosti, bilo da se to odnosi na žaštitu podataka, sigurnu komunikaciju, vjerodostojnu identifikaciju i sl. Danas se nove tehnike, protokoli, algoritmi i softverska riješenja pojavljuju gotovo svakodnevno, ali se svi oni zasnivaju na jednoj prostoj i najbitnijoj činjenici, a to je da moraju biti u potpunosti sigurni po sve svoje korisnike i njihove podatke. Osnovni zaključak je dakle, da ako želimo realizovati proizvod konkurentan na tržištu on mora posjedovati savremene mehanizme zaštite i ispunjavati sve potrebne standarde.

Ovim radom sam nastojao pokazati sve prednosti Oraclove napredne sigurnosti koja na izuzetno visokom nivou implementira sve danas standardne metodologije zaštite. Izloženi su osnovni principi metoda šifrovanja podataka, koji se prenose kroz mrežu, provjere njihovog integriteta i načina zaštite od pada u ruke neautorizovanih korisnika.

Jasno se može doći do zaključka da sve opisane metode sigurnosti imaju svoje prednosti i mane. Koja će od njih biti iskorištena u konkretnom sistemu zavisi najviše od njega samog. Koja će se metoda zaštite podataka sprovesti i koji će autentifikacioni algoritam biti implementiran zavisi od mnogo činilaca poput arhitekture i načina funkcionisanja čitavog sistema. Prije konkretnog izbora pomenutih metoda potrebno je uraditi analizu sistema, uočiti potencijalne slabe tačke i vrste napada koji bi bili učinkoviti i koje treba na sve načine onemogućiti. Dakle, može se zaključiti, da je implementacija sigurnosti usko povezana sa samom funkcionalnošću sistema.

Oraclova baza podataka, odnosno podaci koji se u njoj čuvaju, predstavljaju srž i najbitniji dio sistema jer njihovom obradom dobijamo informacije čija vrijednost na tržištu može iznosti ogromnu svotu novaca, ili pak može biti od izuzetne važnosti korisniku u čijem je vlasništvu. Upravo zbog toga je sama arhitektura Oraclove baze podataka konstruisana na taj način da obezbjedi unutrašnju sigurnost kroz određeni set autorizacionih šema, a dalje upotrebom nekog od opisanih protokola i zaštitu cjelokupnog sistem izgradjenog nad njom.

LITERATURA

35

[1] Advanced Security Administrator's Guide, Oracle 11g R2, decembar 2010.

[2] Beginning Oracle programming, Sean Dillon, Christopher Beck, Thomas Kyte, Joel Kalman, Howard Rogers, Wrox Press Birmingham, 2002.

[3] Guide to SSL VPNs, Sheila Frankel, Paul Hoffman, Angela Orebaugh, Richard Park, National Institute of Standards and Technology Gaithersburg, jul 2008.

[4] Kriptografija I kompjuterska zaštita, dr Milan Marković, Banja Luka, januar 2009.

[5] Sigurnost podataka u Oracle bazi, Vedran Vrbanić, Fakultet elektrotehnike i računarstva Zagreb, februar 2009.

[6] Sigurnost računarskih sistema I mreža, Dragan Pleskonjić, Nemanja Maček, Borislav Đorđević, Marko Carić, Mikroknjiga, Beograd 2007.

[7] http://www.ucertify.com/article/salt-cryptography.html

[8] http://cryptodox.com/Salt_%28cryptography%29

36