REVIZIJA SIGURNOSTI ORACLE RSUBP-a

SAŽETAK

Revizija informacijskog sustava je proces prikupljanja i procjene dokaza o tome da li informacijski sustav djeluje u skladu sa očuvanjem imovine poduzeća, da li održava integritet podataka, da li učinkovito podržava ciljeve poduzeća, te da li efikasno koristi informatičke resurse. Podaci se danas najviše nalaze u bazama podataka, najčešće u relacijskim bazama podataka. Stoga je sigurnost baza podataka važno područje sigurnosti informacijskog sustava, pa je i revizija sigurnosti baza podataka važno područje revizije sigurnosti informacijskog sustava. U radu se prvo prikazuju osnovni pojmovi i procesi sigurnosti i revizije informacijskog sustava. U nastavku se razmatra sigurnost baza podataka, s naglaskom na najčešće ranjivosti i najčešće prijetnje. Nakon toga se prikazuju mehanizmi zaštite Oracle baza podataka. Slijedi nekoliko pristupa reviziji sigurnosti Oracle baza podataka: pristup same Oracle kompanije, pristup SANS instituta, a zatim pristup jednog od najboljih poznavatelja sigurnosti Oracle baza podataka, Petea Finnigana.

ABSTRACT

Information System Audit (Revision) is a process of gathering evidence and assessment of whether an information system operates in accordance with the preservation of company assets, does it effectively supports the goals of the company, does it maintains the integrity of data and efficiently use IT resources. Today, data are mostly stored in the databases and again, mostly in relational databases. Since the security of database is an important area of IT security then database security audit is an important area of IT security audit. The paper presents the basic concepts and processes in security and IT audit. After that, discusses the database security with an emphasis on the most common vulnerabilities and threats followed by Oracle database safeguards mechanism. Few approaches to Oracle databases security auditing is shown: Oracle company approach, SANS Institute approach and Pete Finnigan approach (one of the best connoisseurs of Oracle database security).

1. UVOD

Revizija informacijskog sustava je proces prikupljanja i procjene dokaza o tome da li informacijski sustav djeluje u skladu sa očuvanjem imovine poduzeća, da li održava integritet podataka, da li učinkovito podržava ciljeve poduzeća, te da li efikasno koristi informatičke resurse. Prema tome, utvrđivanje da li informacijski sustav održava integritet podataka je jedan od važnijih zadataka revizije. Naravno, nije važan samo integritet podataka, važni su i privatnost i raspoloživost podataka. No, integritet je na neki način primaran, jer ne bi puno značilo da su podaci dobro zaštićeni od neovlaštenog čitanja, ili da su raspoloživi, ako su netočni, jer ih je netko neovlašteno promijenio. Podaci se danas najviše nalaze u bazama podataka, najčešće u relacijskim bazama podataka. Stoga je sigurnost baza podataka važno područje sigurnosti informacijskog sustava, pa je i revizija sigurnosti baza podataka važno područje revizije sigurnosti informacijskog sustava. U radu se prvo prikazuju osnovni pojmovi i procesi sigurnosti i revizije informacijskog sustava. U nastavku se razmatra sigurnost baza podataka, s naglaskom na najčešće ranjivosti i najčešće prijetnje. Nakon toga se prikazuju mehanizmi zaštite Oracle baza podataka. Slijedi nekoliko pristupa reviziji sigurnosti Oracle baza podataka. Prvo je prikazan pristup same Oracle kompanije, na temelju publikacije [9]. Nakon toga prikazan je pristup SANS instituta, na temelju publikacije [1], a zatim pristup jednog od najboljih poznavatelja sigurnosti Oracle

baza podataka, Petea Finnigana, na temelju publikacije [4]. Na kraju je dat zaključak.

2. SIGURNOST I REVIZIJA INFORMACIJSKOG SUSTAVA

Informacijski (pod)sustav u današnjim je poduzećima vrlo važan dio cjelokupnog poslovnog sustava. U nekim privrednim područjima, npr. bankarstvu, informacijski je sustav možda i najvažniji podsustav. Stoga se u zadnjih petnaestak godina velika pažnja posvećuje sigurnosti informacijskog sustava. Sigurnost baza podataka, kao vrlo važan dio sigurnosti informacijskog sustava, jače se naglašava zadnjih sedam-osam godina. Kod uvođenja sustava upravljanja sigurnošću informacija (eng. Information Security Management System - ISMS) uobičajeno se primjenjuje tzv. PDCA model upravljanja (Plan-Do-Check-Act): Plan - uspostaviti ISMS: uspostaviti ISMS politiku, ciljeve, procese i procedure važne za upravljanje rizikom i povećanje informacijske sigurnosti kako bi dali rezultate u skladu s ukupnom politikom i ciljevima organizacije, Do - implementirati i izvršavati ISMS: implementirati i izvršavati ISMS politiku, kontrole, procese i procedure, Check - nadgledati i provjeravati ISMS: procijeniti i, gdje je primjenjivo, mjeriti performanse procesa u odnosu na ISMS politiku, ciljeve i praktično iskustvo, te izvještavati upravu o rezultatima,

Act - održavati i poboljšavati ISMS: poduzeti korektivne i preventivne mjere zasnovane na rezultatima interne ISMS revizije (eng. audit) i provjere uprave, kako bi se omogućilo stalno poboljšanje ISMS-a. Kada se želi postići (visoka) sigurnost informacijskog sustava, prije svega se žele postići sljedeće karakteristike informacija (podataka) i procesa: Povjerljivost - svojstvo informacija (podataka) da nisu dostupne ili otkrivene neovlaštenim subjektima, Integritet (cjelovitost) - svojstvo informacija (podataka) i procesa da nisu neovlašteno ili nepredviđeno mijenjani, Raspoloživost (dostupnost) - svojstvo informacija i procesa koje omogućuje pristup i upotrebljivost tih informacija i procesa, tj. njihovu dostupnost na zahtjev ovlaštenog subjekta. Važna su i sljedeća sigurnosna svojstva informacijskog sustava: Neporecivost - svojstvo koje osigurava nemogućnost poricanja izvršene aktivnosti ili primitka informacije (podatka), Dokazivost - svojstvo koje osigurava da aktivnosti subjekta mogu biti praćene jedinstveno do samog subjekta, Pouzdanost - svojstvo dosljednoga, očekivanog ponašanja i rezultata. Kod upravljanja sigurnošću i revizije informacijskog sustava, važno je upravljanje rizicima. Postoje različite definicije pojma rizika, npr. "Rizik je neizvjesnost budućeg događaja" ili "Rizik je vjerojatnost nastanka nekog događaja, koji će imati negativne posljedice na ostvarivanje ciljeva poduzeća" ili, specifično za rizik informacijskog sustava, "Rizik informacijskog sustava je rizik koji proizlazi iz korištenja informacijske tehnologije odnosno informacijskog sustava". Rizik se manifestira preko tri glavna faktora: Prijetnje - događaji vanjske prirode u odnosu na sustav, koji u određenom trenutku utječu na slabe točke sustava, te stvaraju učinke, Ranjivosti - slabosti unutar određenog sustava koje u određenom trenutku mogu biti napadnute od prijetnji, Učinci - kratkoročne i dugoročne posljedice, ako prijetnje napadnu slabosti sustava.

Upravljanje rizikom se sastoji od dva glavna procesa: analize i procjene rizika, te preventivnog i korektivnog djelovanja na rizik. Analiza i procjena rizika sadrži sljedeće potprocese:

- analiza informacijske imovine, - analiza prijetnji, - analiza ranjivosti, - analiza postojeće zaštite, - analiza vjerojatnosti, - mjerenje rizika; može se reći da je mjera

rizika funkcija 4 varijable: vrijednosti resursa, vjerojatnosti ostvarenja prijetnje, ranjivosti i mjera zaštite.

Preventivno i korektivno djelovanje:

- odabir strategije zaštite, - analiza troškova, - uspostava sigurnosnih kontrola.

Kod potprocesa odabira strategije zaštite, mogući su sljedeći odabiri: Smanjivanje rizika - najčešće se radi tako da se smanjuje ranjivost (prijetnja se teško može smanjiti), Transferiranje rizika - prebacivanje učinka rizika na nekog drugog, npr. kupca, dobavljača, osiguravajuće društvo i dr., Izbjegavanje rizika - najčešće se radi o tome da se smanji ili izbjegne prijetnja (a ne da se smanji ranjivost) tako da se izbjegne izvođenje nekog posla (ili procesa i sl.), Prihvaćanje rizika - ako procijenimo da učinci rizika nisu značajni i/ili da je smanjenje ranjivosti teško izvedivo, ova strategija može biti zadovoljavajuća. Za sigurnost informacijskog sustava, važno je provođenje eksterne i interne revizije. Revizija informacijskog sustava je proces prikupljanja i procjene informacija, a potom utvrđivanje dokaza i definiranje nalaza o tome kakav je informacijski sustav nekog poduzeća. Osnovni zadatak revizije informacijskog sustava i korištenja informatičke podrške je - dobiti pouzdane i točne informacije o sigurnosti informacijskog sustava, očuvanju imovine, održavanju integriteta podataka i informacija, te poboljšati djelotvornost, učinkovitost i ekonomičnost poslovanja poduzeća, a sve u cilju ostvarivanja ciljeva i zadataka poslovne politike poduzeća. Proces provođenja revizije (eksterne i interne) informacijskog sustava, slično kao i cjelokupni proces uvođenja sustava upravljanja sigurnošću informacija (ISMS-a) uobičajeno primjenjuje PDCA model upravljanja, samo što su sada aktivnosti u pojedinoj fazi PDCA modela specifično vezane uz proces revizije:

Plan - planiranja revizije: izrada nacrta zadatka revizije IS-a, izrada plana provođenja, prikupljanje informacija o poslovanju, prikupljanje informacija o prethodno provedenim internim revizijama, izrada radne dokumentacije, slanje pisma najave o provođenju revizije IS-a, priprema aktivnosti na terenu, Do - ispitivanja i procjene informacija: procjena djelovanja sustava internih kontrola, ispitivanje usklađenosti poslovnih aktivnosti sa zakonskim propisima i internim aktima poduzeća, ispitivanje usklađenosti sa standardima (ISO 17799 i ISO 27001), provođenje testova pomoću CAAT's alata, prikupljanje dokaza i definiranje nalaza, komunikacija s menadžmentom revidiranog područja tijekom provođenja revizije, vođenje radne dokumentacije, Check - izvješćivanje o rezultatima provedene revizije: završni sastanak s menadžmentom revidiranog područja (iznošenje nalaza, preporuka, korektivnih mjera), pisanje izvješća o provedenoj reviziji i slanje odgovornom menedžmentu, Act – praćenje provođenja preporuka i korektivnih mjera: revizija kontrolnih mjera koje odgovorni menadžment poduzima na temelju izvješća revizije; naime, menadžment revidiranog područja odgovoran je za provedbu i primjenu svih revizijskih preporuka i korektivnih mjera.

3. SIGURNOST SUBP-a, PRIJETNJE I RANJIVOSTI Baze podataka su skupovi neredundantno pohranjenih i organiziranih podataka koje održavaju, distribuiraju i nadziru programi nazvani SUBP - sustavi za upravljanje bazama podataka (eng. DBMS – Database Management System). Najčešći današnji SUBP sustavi su relacijski sustavi, RSUBP (eng. RDBMS). Podaci se danas najviše nalaze u bazama podataka. Relacijske baze podataka mogu čuvati ne samo dobro strukturirane informacije/podatke, već i polu strukturirane ili nestrukturirane informacije/podatke. Zato je sasvim uobičajeno da se i tekstovi, mailovi, slike i sl. čuvaju u (relacijskim) bazama podataka. U bazama podataka nalaze se najtajniji i najvredniji podaci. Nije čudo da su baze podataka na stalnoj meti kriminalne zajednice. Stoga je sigurnost baza podataka jedan od važnijih područja sigurnosti informacijskog sustava, pa je i revizija sigurnosti baza podataka jedan od važnijih područja revizije sigurnosti informacijskog sustava. Publikacija [2] navodi da je osiguranje baza podataka u mnogo čemu slično osiguranju računalnih mreža: "U oba slučaja nastoji se korisniku dati samo neophodne ovlasti, smanjiti ranjivu „površinu“ onemogućavanjem nepotrebnih funkcionalnosti, strogo autorizirati izmjene i nadzirati

pristup, odvojiti funkcionalne blokove, inzistirati na enkripciji, itd. Jedina stvarna razlika je u tome što kod baza podataka svi ovi mehanizmi djeluju unutar samog SUBP-a.". U [2] se navode sljedeće ranjivosti SUBP-a: Konfiguracijski propusti

Slaba zaštita korisničkih računa: SUBP-ovi većinom nemaju mogućnosti zaštite korisničkih računa koje su prisutne kod primjerice operacijskih sustava. Tu se prvenstveno misli na (ne)mogućnost kontrole zaporki provjerama u rječniku i na (ne)mogućnost određivanja roka valjanosti korisničkog računa. Često se tijekom postavljanja SUBP-a izvorno postavljeni i opće poznati korisnički računi i korisničke zaporke ostavljaju aktivnima bez promjene. Neprikladna podjela odgovornosti

Na području upravljanja bazama podataka nije priznata uloga administratora za sigurnost. Zbog toga administratori baza podataka moraju voditi računa o korisničkim računima i zaporkama, u isto vrijeme osiguravajući ispravan rad i zadovoljavajuće performanse administrirane baze podataka. Takva situacija, uz to što otežava posao administratorima, onemogućava efikasno upravljanje ljudskim resursima. Neprikladne metode nadzora

Nadzoru SUBP-a često su pretpostavljeni zahtjevi visokih performansi i štednje diskovnog prostora. Zbog toga je umanjena učinkovitost forenzičke analize i otežano utvrđivanje odgovornosti. Ispravne metode nadzora su ključne u razumijevanju napada na SUBP-ove jer bilježe aktivnosti izravno vezane uz pohranjene podatke. Neiskorištene mogućnosti zaštite baza podataka

Uobičajeno je ugrađivati sigurnosne elemente u pojedine aplikacije, zanemarujući pri tome sigurnost SUBP-a. Nedostatak takvog pristupa je u tome što spomenuti sigurnosni elementi djeluju samo u slučaju kada korisnik za pristup bazi koristi klijentske aplikacije. Postoje mnogi alati (npr. Microsoft Access) koji omogućuju pristup bazi podataka pomoću ODBC-a (eng. Open Database Connectivity) ili nekog drugog protokola koji u potpunosti zaobilazi sigurnosne provjere ugrađene u aplikacije. Jedina pouzdana sigurnosna ograničenja su ona ugrađena izravno u SUBP. Programski propusti unutar SUBP-a

Programski propusti uključuju razne pogreške prepisivanja spremnika koje mogu udaljenim zlonamjernim korisnicima omogućiti izvođenje napada zasnovanih na uskraćivanju resursa (eng. DoS - Denial of Service) napada ili izvršavanje proizvoljnog programskog koda s različitim posljedicama. Propusti u aplikacijama povezanim s bazama podataka

Činjenica da se SUBP nalazi iza vatrozida ne čini ga apsolutno sigurnim od napada. Postoji nekoliko vrsta napada koje je moguće izvesti kroz vatrozid, a ubacivanje (injekcija) SQL naredbi (eng. SQL injection) je najčešći. To nije napad izravno na SUBP već predstavlja pokušaj promjene parametara koji se šalju aplikaciji (najčešće web aplikacija) s namjerom mijenjanja SQL naredbe poslane bazi podataka.

Studija [8] navodi sljedeće najvažnije ranjivosti i prijetnje kod velikih korporacijskih baza podataka, te rješenja ranjivosti i prijetnji:

Rbr. Ranjivost Opis

1. Podaci koji stoje (data-at-rest) Podaci koji su pohranjeni, barem privremeno, za razliku od podataka koji su u tranzitu preko mreže.

2. Osjetljivi podaci Podaci koji su vrlo važni za organizaciju i široko distribuirani u bazi podataka.

3. Loša aplikacijska arhitektura Zanemarivanje sigurnosti kod dizajniranja aplikacija.

4. Ranjivost zaporki Hakeri otkrivaju zaporke korisnika, te se prijavljuju kao taj korisnik.

5. Nezaključane (unlocked) baze podataka

Baze podataka kompletno otvorene za pristup, bez kontrole pristupa ili auditiranja događaja.

6. Bug-ovi proizvođača SUBP-a Prelivanje spremnika (buffer overflow) i ostale programske greške koje rezultiraju izvršenjem naredbi koje se tipično ne bi smjele izvršavati.

Rbr. Prijetnja Opis

1. Neautorizirani pristup iznutra Prijetnje mogu doći od nezadovoljnih zaposlenika koji korištenjem legitimnih prava pristupa kopaju po podacima, ili od nečasnih zaposlenika koji prodaju informacije najboljem ponuđaču.

2. Napadi grubom silom Napadač ima program pomoću kojeg pokušava iskoristiti svaku riječ u rječniku kao zaporku.

3. Neispravna uporaba alata Korištenje alata za izradu aplikacija na način kojim se može provaliti u bazu podataka.

4. Ukradeno prijenosno računalo Nemarni korisnici, čija su računala (puna podataka) ukradena ili su ih izgubili.

5. Kopiranje podataka na vlastito računalo / uređaj

Korisnici kopiraju podatke iz baze podataka na svoje osobno računalo, PDA uređaj, USB memoriju i dr.

Rbr. Ranjivost Rješenje Opis rješenja

1. Podaci koji stoje Enkripcija Podaci na medijima su kriptirani.

2. Osjetljivi podaci Enkripcija ili/i Auditiranje

Kriptiranje podataka ili/i auditiranje (zapisivanje) korisničkog pristupa osjetljivim podacima i detekcija neautoriziranih pristupa.

3. Loša aplikacijska arhitektura

Procjena ranjivosti Praćenje i zapisivanje događaja u bazi podataka i hitno obavještavanje o abnormalnoj aktivnosti.

4. Ranjivost zaporki Politika zaporki Zaporke moraju imati barem 12 znakova i uključivati slova i brojke.

5. Nezaključane (unlocked) baze podataka

Vatrozid Dozvoliti pristup bazi podataka samo autoriziranim računalima.

6. Bug-ovi proizvođača SUBP-a

Primjena programskih zakrpa

Redovita primjena programskih zakrpa (patches) koje je izdao proizvođač SUBP-a.

Rbr. Prijetnja Rješenje Opis

1. Neautorizirani pristup iznutra

Politika pristupa Politike limitiranja korisničkih privilegija na nužni minumum i postavljanje kontrola.

2. Napadi grubom silom Vatrozid Dozvoliti pristup bazi podataka samo autoriziranim računalima.

3. Neispravna uporaba alata

Procjena ranjivosti Praćenje i zapisivanje događaja u bazi podataka i hitno obavještavanje o abnormalnoj aktivnosti.

4. Ukradeno prijenosno računalo

Enkripcija Kriptiranje podataka.

5. Kopiranje podataka na vlastito računalo / uređaj

Praćenje i auditiranje

Praćenje i auditiranje korisničkog pristupa osjetljivim podacima i detekcija neautoriziranih pristupa.

4. SIGURNOSNE MOGUĆNOSTI ORACLE RSUBP-a

Napomena: ovdje nisu prikazane mogućnosti koje specifično spadaju u Disaster Recovery, tj. koje povećavaju raspoloživost podataka, već su prikazane samo mogućnosti koje utječu na povećanje povjerljivosti i integriteta podataka. 4.1. Identifikacija i autenti(fi)kacija

Na logičkoj (a ne fizičkoj) razini prikaza, može se reći da se Oracle baza podataka sastoji od shema (schema). U Oracle bazi shema i korisnik (user) su u većini slučajeva jedno te isto. No, sa aplikativnog stajališta, moglo bi se reći da postoje aplikacijske sheme i korisničke sheme. Aplikacijske sheme su vlasnici objekata kao što su tablice (podataka), pogledi (views), pohranjene procedure (ili funkcije ili paketi), okidači baze podataka i dr. Korisničke sheme su manje-više prazne, najčešće sadržavaju samo privatne sinonime, pomoću kojih korisnik, iako je prijavljen na svoju (korisničku) shemu, pristupa podacima i ostalim objektima druge sheme - aplikacijske sheme. Kreiranje korisnika (= shema) u Oracle bazi se radi sljedećom naredbom (napomena: naredba CREATE USER ima veliki broj opcionalnih klauzula, ovo je samo osnovni oblik naredbe): CREATE USER neki_korisnik

IDENTIFIED BY neka_zaporka;

Treba napomenuti da prije slanja mrežom, Oracle baza uvijek štiti lozinku kriptiranjem pomoću modificiranog AES algoritma. Zapravo, Oracle baza ne drži kriptiranu vrijednost lozinke, jer bi onda negdje morao biti zapisan i ključ za dekriptiranje, već drži hash vrijednost lozinke. Klijent šalje bazi lozinku uvijek u kriptiranom obliku, bez obzira da li se ostali promet kriptira. Baza dekriptira lozinku, izračuna njenu hash vrijenost i

uspoređuje ju s hash vrijednošću koju ima zapamćenu. Teoretski se može desiti da dvije različite lozinke imaju istu hash vrijednost. Identifikacija i autentikacija u distribuiranoj bazi podataka je složenija. Kod većeg broja baza podataka koje čine distribuiranu bazu, često neki korisnici moraju raditi sa dvije ili više baza (neki i sa svim bazama). Jedan način održavanja mogao bi biti takav da se korisnici ažuriraju isto kao što se ažuriraju u centraliziranoj bazi podataka, tj. da se ažuriraju na svakoj bazi zasebno. U nekim slučajevima je i takvo rješenje zadovoljavajuće. Međutim, ako postoji veliki broj korisnika (npr. nekoliko stotina), čak i kada je broj baza relativno mali, održavanje korisničkih računa postaje teško za administratora, a veliki broj različitih zaporki (na različitim bazama) otežava rad korisnika. Oracle ima rješenje za takvu situaciju – tzv. Enterprise User Security (EUS). No, ta mogućnost ne postoji u Standard ediciji baze, a i za Enterprise ediciju se neke dodatne mogućnosti moraju posebno kupiti kroz opciju Advanced Security. "Enterprise korisnici" se definiraju u direktoriju i njihov identitet ostaje konstantan kroz poduzeće. EUS se temelji na Oracle Identity management infrastrukturi, koja koristi LDAP-suglasan direktorij za centralnu pohranu i održavanje korisnika. Korisnici mogu kroz EUS koristiti "single sign-on" (SSO) ili "single password" autentikaciju, ovisno od konfiguracije koju izabere administrator. Koristeći single sign-on, korisnik se mora autenticirati samo jedanput, a sljedeće autentikacije se odvijaju transparentno. Ova funkcionalnost traži SSL. Single password autentikacija omogućava da se korisnik prijavi na više baza jedinstvenom globalnom zaporkom, iako konekcija na svaku bazu traži posebnu autentikaciju. Zaporke su sigurno pohranjene u centraliziranom LDAP-suglasnom direktoriju i zaštićene sigurnosnim mehanizmima, uključujući enkripciju i Access Control Lists.

4.2. Autorizacija Kreirani korisnik neće moći ništa raditi ako mu se ne daju određena prava (autorizacija). U Oracle bazi mogu se dati tri vrste prava: Pravo na određenu radnju nad određenim objektom baze (tzv. Object Privileges), npr. pravo čitanja (SELECT) tablice M_DOBAVLJACI čiji je vlasnik korisnik (= shema) RAZVOJ: GRANT SELECT ON razvoj.m_dobavljaci

TO neki_korisnik;

Pravo na određenu radnju nad bilo kojim objektom određene vrste na bazi (tzv. System Privileges), npr. pravo čitanja (SELECT) bilo koje tablice na bazi; ovakva prava u načelu ne bi trebalo davati, jer su preširoka i predstavljaju opasnost za sigurnost baza podataka: GRANT SELECT ANY TABLE

TO neki_korisnik;

Indirektno pravo, dodijeljeno preko rola (uloga) baze podataka; prvo se odgovarajuća prava dodjeljuju roli baze podataka, a onda se jedna (ili, u pravilu, više) rola dodjeljuje korisniku: CREATE ROLE rola1;

GRANT SELECT ON razvoj.m_dobavljaci

TO rola1;

GRANT rola1 TO neki_korisnik;

Roli se mogu dodjeljivati prava kao i korisniku, tj. roli se mogu dodijeliti prava rada sa određenim objektom, sa svim objektima određene vrste, ili se roli može dodijeliti druga rola (ali ne tako da dođe do zatvorene petlje). U praksi se često radi tako da se kreiraju role na dvije razine. Rolama druge razine dodijele se prava rada sa određenim objektima, npr. može se napraviti rola koja ima pravo ažuriranja svih matičnih tablica. Nakon toga se više rola druge razine dodijeli roli prve razine, koja uglavnom predstavlja jednu zaokruženu cjelinu, npr. predstavlja skup prava koja omogućavaju da se radi neki posao. Na kraju se jedna ili više rola dodjeljuje korisniku. Osim autorizacije preko privilegija i rola, Oracle sustav poznaje i dodjelu prava preko profila. Da bi se profili aktivirali, treba u INIT.ORA postaviti parametar RESOURCE_LIMIT = TRUE (a može i sa: ALTER SYSTEM SET RESOURCE_LIMIT = TRUE). Nakon toga se kreira profil (postoji i profil DEFAULT), profilu se dodaju određeni parametri, a profil se dodijeli korisnicima:

CREATE PROFILE profile LIMIT

resource/password_parameters;

i dodjela profila korisniku kod CREATE USER ili ALTER USER. Parametri koji se mogu postaviti kod profila dijele se na resursne parametre i parametre lozinki. Resursni parametri su: SESSIONS_PER_USER, CPU_PER_SESSION, CPU_PER_CALL, CONNECT_TIME, IDLE_TIME i dr. Parametri lozinki su: FAILED_LOGIN_ATTEMPTS, PASSWORD_LIFE_TIME, PASSWORD_REUSE_TIME, PASSWORD_REUSE_MAX, PASSWORD_LOCK_TIME, PASSWORD_GRACE_TIME, PASSWORD_VERIFY_FUNCTION. 4.3. Fina autorizacija - Virtual Private Database (VPD) i Label Security (LS) ) tehnologije

Virtualna privatna baza podataka (Virtual Private Database – VPD, drugi naziv je Row Level Security - RLS) je tehnologija koja omogućava veću sigurnost kod pristupa podacima u bazi podataka, jer omogućava da određeni korisnici gledaju samo određene retke i/ili određene stupce, ali na način koji je fleksibilniji i sa boljim performansama nego klasičan način pomoću pogleda (view-ova) baze podataka. Može se npr. napraviti da određeni korisnik može pristupati samo onim redovima (određene tablice) koji se (redovi) odnose na poduzeća sa kojima korisnik ima pravo raditi, a bez da se radi pogled posebno za njega ili da se mijenja programski kod. VPD tehnologija temelji se na mogućnosti dinamičke modifikacije upita. Kada korisnik pristupa tablici ili pogledu, server baze podataka automatski modificira naredbu koju je korisnik poslao bazi i dodaje u WHERE klauzulu dodatne uvjete (poznate kao predikati), a te dodatne uvjete vraća funkcija koja je implementirana u okviru sigurnosne politike. Za primjenu VPD tehnologije koristi se paket DBMS_RLS, koji omogućava da se automatski dodaje AND uvjet na SQL naredbu:

DBMS_RLS.ADD_POLICY (

-- SHEMA U KOJOJ JE TABLICA

'proba',

-- TABLICA KOJOJ SE DEFINIRA

SIG.POL.

'org_jedinice',

-- NAZIV SIGURNOSNE POLITIKE

'proba_oj_policy',

-- SHEMA U KOJOJ JE FUNKCIJA

'proba',

-- FUNKCIJA KOJA VRAĆA PREDIKAT

'oj_predikat',

-- VRSTA NAREDBE ZA KOJU VRIJEDI

'SELECT'

);

Prethodnom naredbom rečeno je: - da se kreira sigurnosna politika imena

PROBA_POLICY - da se ona primjenjuje nad tablicom

ORG_JEDINICE koja se nalazi u shemi PROBA

- da se funkcija koja vraća predikat zove

OJ_PREDIKAT i da se ta funkcija nalazi u shemi PROBA (slučajno je to ista shema u kojoj se nalazi i tablica, ali u pravilu ne mora biti tako, već se funkcije koje vraćaju predikat obično spremaju u drugu shemu, a ne u istu shemu u kojoj se nalaze tablice podataka)

- da se sigurnosna politika primjenjuje

kod naredbe SELECT. VPD tehnologiju ima samo Enterprise edicija baze. Postoji još jedna tehnologija, Label Security (LS), koja je dodatna opcija Enterprise baze. Namijenjena je prije svega vojsci, policiji, državnoj upravi i financijskim institucijama. Omogućava da se podaci klasificiraju u određene klase i da određena klasa korisnika može mijenjati i i gledati samo određene klase podataka. U načelu se funkcionalnost koju ima LS može postići i sa VPD tehnologijom, pa čak i sa vlastitim rješenjem bez VPD tehnologije (dakle, i u Standard ediciji baze), ali LS tehnologija omogućava da se željena funkcionalnost postigne bez programiranja. No, niti VPD tehnologija ne štiti podatke od privilegiranih korisnika. Oracle ima posebnu opciju, Data Vault, za tu namjenu. 4.4 Standardno auditiranje, Fine-Grained Auditing (FGA) i Audit Vault Auditiranje podataka ne povećava privatnost, integritet ili raspoloživost podataka, ali zato omogućava neporecivost. Kod auditiranja treba

paziti na to da realno nije moguće sve auditirati, jer bi takvo auditiranje srušilo performanse sustava i zauzelo bi velike količine diskovnog prostora. Zato treba dobro treba odabrati što će se auditirati. Standardno auditiranje ima i Standard edicija baze. Njega prvo treba parametarski dozvoliti. Nakon toga možemo pokrenuti npr. ovakav selektivni audit: AUDIT INSERT, UPDATE, DELETE ON

komitenti

WHENEVER NOT SUCCESSFUL;

čime smo rekli da želimo auditirati tablicu KOMITENTI za sve tri DML radnje (INSERT, UPDATE, DELETE), ali samo kod neuspjeha tih radnji. Nakon toga možemo pokrenuti npr. ovakav SELECT koji će nam prikazati podatke iz audit tablice:

SELECT TO_CHAR

(timestamp, 'dd.mm.yyyy hh:mm:ss')

vrijeme,

owner,

username,

SUBSSTR (obj_name, 1, 30)

obj_name,

sessionid,

returncode

FROM dba_audit_trail

ORDER BY TO_CHAR

(timestamp, 'yyyy.mm.dd hh:mm:ss')

DESC, 2, 3;

No, ponekad nam je potrebno fino auditiranje. To je moguće izvesti i vlastitim programiranjem, uz pomoć okidača baze i paketa. No, u Enterprise ediciji baze moguće ga je dobiti bez programiranja, korištenjem paketa DBMS_FGA – to je tzv. Fine-Grained Auditing. Problem sa prethodnim auditiranjem je taj da ga privilegirani korisnici mogu isključiti ili zaobići. Oracle nudi posebnu opciju na Enterprise ediciji baze, koja se zove Audit Vault i koja omogućava neoporecivost od strane privilegiranih korisnika. 4.5. Kriptiranje podataka Kriptiranje podataka u prvom redu povećava privatnost podataka. Indirektno može povećati i integritet podataka. No, na raspoloživost kriptiranje može djelovati čak i negativno. U jednom smislu, kriptiranje troši resurse (najviše procesorske). Na taj način, slično kao i auditiranje, može smanjiti raspoloživost zbog smanjenja performansi. S druge strane, kriptirani podaci su zaštićeni od zlonamjernih korisnika, ali mogu biti nepristupačni čak i legalnim korisnicima, ukoliko se izgubi ključ za dekriptiranje.

Kod kriptiranja je općenito moguća primjena simetričnih ili asimetričnih ključeva. Simetrični ključ služi i za kriptiranje i za dekriptiranje podataka. Oracle za kriptiranje/dekriptiranje podataka na diskovima koristi samo simetričnu enkripciju (koja je u pravilu daleko brža), a asimetričnu enkripciju omogućava kod prijenosa podataka između baze i klijenta i kod autentikacije korisnika. Za kriptiranje se može, u svim edicijama baze, koristiti paket DBMS_CRYPTO. Uz dosta programiranja, s tim paketom moguće je napraviti vrlo sofisticirana rješenja. Međutim, uvijek ostaje izazov gdje spremiti ključ – u bazu ili izvan. Što se tiče broja ključeva, osnovne varijante su: jedan ključ za cijelu bazu, jedan ključ za tablicu, jedan ključ za redak, kombinacije prethodnog. Oracle je u Advanced Security opciji omogućio tzv. Transparent Data Encryption (TDE) - podaci se automatski kriptiraju/dekriptiraju. Postoje dvije varijante: TDE Column Security (enkripcija na razini stupca) i TDE Tablespace Security (enkripcija cijelog tablespace-a). No, TDE služi samo za zaštitu podataka na disku, u slučaju da netko neovlašteno dođe do tih podataka, dok su podaci za korisnike baze uvijek transparentno dekriptirani. 4.6. Rekapitulacija sigurnosnih mogućnosti Oracle baze po edicijama

Standard edicija baze ima sljedeće mogućnosti: - standardna identifikacija i autentikacija, - standardna autorizacija (privilegije, role,

profili), - standardno auditiranje - kriptiranje pomoću paketa

DBMS_CRYPTO (programiranjem). Enterprise edicija ima ove dodatne mogućnosti:

- centralizirana identifikacija i autentikacija pomoću Enterprise User Security,

- autorizacija na razini retka pomoću Virtual Private Database (Row Level Security),

- fino granulirano auditiranje (Fine-Grained Auditing).

Dodatne opcije na Enterprise ediciju:

- stroga identifikacija i autentikacija pomoću Advanced Security opcijem,

- autorizacija pomoću Label Security opcije, - autorizacija privilegiranih korisnika pomoću

Data Vault opcije, - auditiranje privilegiranih korisnika pomoću

Audit Vault opcije, - transparentno kriptiranje podataka (TDE)

pomoću Advanced Security opcije.

5. ORACLE PRISTUP REVIZIJI SIGURNOSTI ORACLE RSUBP-a Oracle od baze 9i intenzivno pokušava pomoći svojim korisnicima da bazu podataka učine što sigurnijom. U bazama 10.1 i 10.2 u tome su uspješno nastavili. U sadašnjim verzijama baze 11.1 i 11.2 učinili su još veći pomak nabolje. Oracle u publikaciji [9] (koja se odnosi na bazu 11) preporuča sljedeće: Provjeriti da li je instalirano samo ono što je potrebno Instalacija Oracle softvera moguća je na dva načina – kao tipična instalacija i kao prilagođena (custom) instalacija. Za produkcijske baze preporučljivo je odabrati prilagođenu instalaciju, te instalirati samo ono što je potrebno za rad. Ako se kasnije pokaže da je još nešto potrebno, to se lako može instalirati naknadno. U toku revizije treba provjeriti da li su instalirane samo one opcije koje su potrebne. Provjeriti da li su standardni (default) korisnički računi zaključani Kod instalacije, automatski se kreiraju neki standardni korisnički računi. Automatska instalacija automatski zaključava te korisničke račune. Kod prilagođene instalacije, administrator bi trebao ručno zaključati te korisničke račune. U toku revizije treba provjeriti da li su standardni korisnički računi zaključani. Provjeriti da li su promijenjene standardne korisničke zaporke U toku revizije treba provjeriti da li su promijenjene standardne (default) korisničke zaporke postavljene kod instalacije, te da li su lozinke dovoljno kompleksne (najmanje 10 znakova, mješavina slova i brojki). Provjeriti da li su zaporke privilegiranih korisničkih računa različite U toku revizije treba provjeriti da li su zaporke privilegiranih korisničkih računa (SYSTEM, SYSMAN, DBSNMP) međusobno različite, jer nije dobro da budu jednake. Provjeriti da li je sprovedeno upravljanje zaporkama pomoću profila U toku revizije treba provjeriti da li su pomoću profila definirani barem sljedeći parametri za upravljanje zaporkama: prekid procesa prijave nakon određenog broja neuspješnih pokušaja, definirano trajanja zaporke, definirana (ne)mogućnost ponovne upotrebe iste zaporke, definirana pravila kompleksnosti zaporki.

Provjeriti da li je dobro upravljana dodjela rola SYSDBA i SYSOPER U toku revizije treba provjeriti da li su role SYSDBA i SYSOPER date samo onim korisnicima koji to trebaju dobiti. Također, treba provjeriti da li se radi auditiranje neuspješnih prijava kao SYSDBA i SYSOPER. Provjeriti da li je uključena zaštita Oracle rječnika podataka Oracle rječnik podataka čine (meta)tablice baze podataka. One su privilegiranim korisnicima pristupačne kao i druge tablice - mogu se ne samo čitati, već i mijenjati. Privilegirani korisnici su u ovom slučaju oni koji imaju ANY sistemske privilegije. Takve pristupe treba zabraniti. U toku revizije treba provjeriti da li je parametar 07_DICTIONARY_ACCESSIBILITY postavljen na FALSE, čime se štiti rječnik od privilegiranih korisnika. Provjeriti da li se postupa u skladu s principom davanja minimalnih potrebnih prava U toku revizije treba provjeriti da li su dana minimalna prava za obavljanje posla, ili je dato više od toga, što nije dobro za sigurnost. Naročito treba provjeriti da li su nepotrebno date DBA privilegije – njih trebaju imati samo oni korisnici koji zaista jesu DBA administratori. Provjeriti PUBLIC privilegije Postoje brojni Oracle paketi koji su standardno dati na izvršavanje svakome, preko standardne (pseudo)role PUBLIC (GRANT EXECUTE ON neki_paket TO PUBLIC). U bazi 11 napravljena su poboljšanja koja omogućuju da se ponekad može zadržati velika sigurnost i bez skidanja prava izvršavanja tih paketa od strane PUBLIC role (bez REVOKE EXECUTE ON neki_paket FROM PUBLIC). U slučaju kada to kod nekih paketa nije moguće, u toku revizije treba provjeriti da li su prava izvršenja takvih paketa skinuta roli PUBLIC i dodijeljena onim korisnicima (direktno ili indirektno, preko neke specifične role) koji trebaju imati pravo izvršenja tog paketa. Drugim riječima, nije dobro da pravo izvršenja Oracle paketa bude nekontrolirano dodijeljeno roli PUBLIC. Provjeriti da li je eliminirana autentikacija udaljenih korisnika preko operativnog sustava Udaljeni korisnici mogu se, ovisno o postavkama parametra REMOTE_OS_AUTHENT, prijavljivati na bazu indirektno, preko prijave na operativni sustav. To nije dobro sa stanovišta sigurnosti. U toku revizije treba provjeriti da li je parametar REMOTE_OS_AUTHENT postavljen na FALSE (to je standardna vrijednost i ne bi ju trebalo mijenjati). Provjeriti da li je ograničen pristup Oracle datotekama preko operativnog sustava

Oracle datotekama "izvana" mogu pristupati i oni korisnici koji nemaju prava pristupa "iznutra", ako im to dozvoljavaju prava pristupa na razini operativnog sustava. U toku revizije treba provjeriti da li je na razini operativnog sustava pristup Oracle datotekama dozvoljen samo osobama koje bi to trebale imati. (Napomena: publikacija [9] ne naglašava da često nekim Oracle datotekama ne bi trebao pristupati čak ni administrator baze, već samo administrator (operativnog) sustava – na taj način se podupire podjela odgovornosti.) Provjeriti da li je Oracle listener pravilno konfiguriran za sigurnost U toku revizije treba provjeriti da li je Oracle listener konfiguriran za optimalnu sigurnost. Provjeriti da li je spriječena promjena listenera u toku rada U toku revizije treba provjeriti da li je ADMIN_RESTRICTIONS_LISTENER postavljeno na ON (što je standardna vrijednost, koju treba ostaviti), čime se sprečava promjena listenera u toku rada (runtime change). Provjeriti da li su Oracle procesi zaštićeni od klijenata sa specifičnih adresa Moguće je zabraniti (ili dozvoliti) pristup Oracle procesima od strane specifičnih IP adresa, pomoću Oracle Net valid note checking security mogućnosti. Da bi se ta mogućnost mogla koristiti, u SQLNET.ORA (Oracle Net konfiguracijska datoteka) treba biti postavljen parametar TCP.VALIDNOTE_CHECKING = YES. Nakon što je taj parametar postavljen na ON, moguće je navesti listu IP adresa koje ne mogu pristupati Oracle procesima, pomoću TCP.EXCLUDED_NODES = {lista_IP_adresa}, odnosno listu adresa koje mogu pristupati, pomoću TCP.INVITED_NODES = {lista_IP_adresa}. U toku revizije treba provjeriti da li je TCP.VALIDNOTE_CHECKING = YES i koji su zapisi u TCP.EXCLUDED_NODES i TCP.INVITED_NODES. Provjeriti da li je otežan pristup nekim servisima operativnog sustava UNIX i Windows platforme posjeduju brojne servise. Kao i kod servisa baze, treba vidjeti da li su pojedini servisi operativnog sustava potrebni. Ako nisu potrebni, treba ih onemogućiti. U toku revizije treba provjeriti da li su zatvoreni UDP i TCP priključci (portovi) do nepotrebnih servisa operativnog sustava. Provjeriti da li je promet mrežom zaštićen kriptiranjem U ovisnosti od edicije baze (Standard edicija, Enterprise edicija, dodatne opcije na Enterprise ediciju), moguće je primijeniti različite načine

kriptiranja prometa između klijenata, servera baze podataka i aplikacijskih servera. U toku revizije treba provjeriti da li je primijenjena maksimalna enkripcija koju pojedina edicija baze omogućava. Provjeriti da li su primijenjene sve sigurnosne zakrpe (patches) Oracle već nekoliko godina redovito i često objavljuje sigurnosne zakrpe. Nekada su (npr. u bazi 9) te sigurnosne zakrpe znale biti problematične, tj. rješavale su jedan problem, a donosile drugi, tako da se korisnici nisu lako odlučivali na njihovu primjenu. Objavljene sigurnosne zakrpe tako mogu dovesti do paradoksalne situacije – umjesto da povećavaju sigurnost sustava, smanjuju ga, jer sada široka zajednica potencijalnih napadača lako vidi slabosti sustava. Budući da su u novijim verzijama Oracle baze (10, a naročito 11) sigurnosne zakrpe znatno poboljšane, uglavnom nema razloga da se ne primijene odmah nakon objave (naravno, uvijek prvo treba probati na testnoj bazi). Stoga, u toku revizije treba provjeriti da li su primijenjene sve objavljene sigurnosne zakrpe i, ako nisu, zašto nisu (npr. pokazalo se da postoji neki bug koji je jako problematičan za produkcijsku bazu). Na temelju iznesenoga, vidi se da Oracle u publikaciji [9] navodi one radnje koje općenito treba primijeniti na bilo kojoj (Oracle) bazi podataka. Stječe se dojam da Oracle u ovoj publikaciji ne stavlja dovoljan naglasak na potrebu boljeg praćenja vrlo privilegiranih (DBA) korisnika. Više se stavlja naglasak na to da se DBA privilegije ne dodjeljuju nepotrebno (što je svakako u redu). No, praksa je pokazala da znatan broj malverzacija dolazi i od legalno privilegiranih korisnika, a ne samo od onih koji su nelegalno, ili propustom drugih, došli do DBA privilegija. Istina, za dobro praćenje privilegiranih korisnika često je u Oracle bazi potrebno imati dodatne opcije (koje se dodatno naplaćuju, nema ih niti Enterprise edicija), kao što su Data Vault opcija ili Audit Vault opcija. Također, ova Oracle publikacija nigdje ne spominje da bi kod revizije sigurnosti trebalo poznavati strukturu podataka konkretne baze i provjeriti konkretne podatke (a ne samo podatke Oracle auditiranja).

6. DRUGI PRISTUPI REVIZIJI SIGURNOSTI ORACLE RSUBP-a

6.1. Pristup prema SANS Institute publikaciji SANS (SysAdmin, Audit, Network, Security) Institute je osnovan 1989. kao organizacija za istraživanje i edukaciju na području sigurnosti informacija. U njegovim programima sudjeluje oko

165,000 profesionalaca (iz područja sigurnosti) iz cijelog svijeta, koji dolaze i iz korporacija i iz znanstvenih ustanova. SANS (uglavnom) besplatno daje na raspolaganje veliku kolekciju dokumenata iz različitih područja informacijske sigurnosti. Ovdje je prikazan pristup reviziji sigurnosti Oracle baze na temelju SANS publikacije [1]. Kako je navedeno u njenom uvodu, publikacija [1] pisana je sa stanovišta eksternog revizora informacijskog sustava. Prvo su prikazane faze revizije: faza planiranja (koja se sastoji od prikupljanja informacija i procjene rizika), faza evaluacije i testiranja sigurnosnih kontrola, faza izvještavanja. U fazi planiranja revizije, u prvoj podfazi se prikupljaju sljedeće informacije:

- svrha informacijskog (pod)sustava čija se revizija radi, npr. da li je riječ o informacijskom sustavu koji podržava važan poslovni proces za firmu,

- struktura sustava: dijagram mreže, informacije o bazi podataka, informacije o OS-u,

- sigurnosne politike i planovi, - organizacija i njene procedure, npr.

organizacijski dijagram, priručnici o procedurama.

Druga podfaza u fazi planiranja revizije je procjena rizika. U publikaciji se pretpostavilo da je procjena rizika pokazala kako je jedan od najvećih sigurnosnih problema u firmi sigurnost (Oracle) baze podataka, pa se daljnja revizija temelji na tome. Uz kratak prikaz općih koraka faze evaluacije i testiranja sigurnosnih kontrola, te kratak prikaz faze izvještavanja, publikacija dalje daje detaljan prikaz faze evaluacije i testiranja sigurnosnih kontrola na Oracle bazi, što će biti prikazano u nastavku. Klasifikacija informacijskih resursa na temelju kritičnosti i osjetljivosti Potrebno je saznati koja vrsta informacija je spremljena u bazi podataka (u podsustavu čija se revizija radi). Klasifikaciju podataka moraju napraviti vlasnici podataka, jer oni najbolje poznaju važnost pojedinih podataka. Na temelju izvršene klasifikacije moći će se kod revizije procijeniti da li su uspostavljene dostatne kontrole. Klasifikacija je temelj za kasniju evaluaciju rola, privilegija i profila u bazi podataka. Održavanje liste autoriziranih korisnika i njihovih prava Ovdje se provjerava da li su korisnički računi u bazi podataka dobro postavljeni. Prije svega, gleda se

da li korisnički računi odgovaraju zaposlenicima u firmi. Npr., možda postoji korisnički račun zaposlenika koji je napustio firmu, ili možda više zaposlenika koristi isti korisnički račun. Dalje, gleda se da li korisnički računi imaju odgovarajuća prava, ili su možda dana prevelika prava. Provjeravaju se i korisnički računi koji se standardno instaliraju kod instalacije Oracle baze, da li su zaključani i, ako nisu, da li im je možda ostavljena standardna (default) zaporka. Uspostava fizičkih i logičkih kontrola za prevenciju i detekciju neautoriziranog pristupa Prvo se analiziraju postojeće role (i njihove privilegije) i profili, a onda kako su role i profili dodijeljeni korisničkim računima. Trebao bi biti poštovan princip najmanjih potrebnih privilegija. Dalje se gleda sljedeće:

- da li je dodjela prava izvršena sa ADMIN opcijom, što znači da takav korisnik može dalje davati ista prava drugima,

- da li su prava dodijeljena PUBLIC

(pseudo)roli minimalna (što je preporučljivo),

- da li je došlo do promjene standardnih

(default) rola, npr. rola CONNECT, RESOURCE,

- da li se i kako koriste pogledi (views),

- tko je vlasnik pohranjenih procedura i na

koji se način koriste: sa pravima kreatora procedure, ili sa pravima korisnika procedure,

- kako se upravlja zaporkama; da li se

koriste profili sa parametrima za lozinke, - da li je od pristupa zaštićena tablica

SYS.USER$, u kojoj se nalaze hash vrijednosti zaporki, čije poznavanje olakšava pokušaj pogađanja zaporke (pomoću odgovarajućih programa); hash vrijednosti zaporki mogu se naći i u backup datotekama, što znači da treba provjeriti da li se te datoteke štite na razini operativnog sustava,

- da li je parametar

07_DICTIONARY_ACCESSIBILITY postavljen na FALSE, čime je zaštićen rječnik podataka,

- da li se koristi autentikacija baze na

temelju operativnog sustava – preporučljivo je da se to ne koristi,

- da li su na razini operativnog sustava

dobro zaštićene različite Oracle datoteke: datoteke podataka, log datoteke, export datoteke, trace datoteke i dr.,

- da li se negdje koriste skripte sa

hardkodiranim zaporkama – ne bi trebale postojati,

- da li možda korisnici imaju mogućnost

pristupa bazi preko nekog alata kao što je SQL+ ili Toad i sl. – ne bi trebali imati takav pristup,

- da li je instalirano samo ono što je nužno,

ili i neke opcije koje trenutačno nisu potrebne,

- da li su razvojna i testna baza isto dobro

osigurane – često one sadrže podatke kopirane iz produkcijskih baza, a sadrže i informacije koje olakšavaju potencijalnom napadaču pristup u produkcijske baze,

- da li postoje linkovi između baza (database

links) i, ako postoje, kakve posljedice to može imati na sigurnost.

Monitoriranje pristupa, istraživanje povreda sigurnosti i poduzimanje odgovarajućih akcija za popravak Prethodno navedene kontrole su preventivne. Kontrole o kojima je ovdje riječ su kontrole za detekciju i za korekciju napada. Monitoriranje se može napraviti pomoću različitih varijanti Oracle auditiranja – standardnog auditiranja, fino granuliranog auditiranja, ili posebnih opcija. Standardno auditiranje ima tri najvažnije varijante:

- auditiranje na razini naredbe, bilo slučaju njenog uspjeha ili neuspjeha,

- auditiranje na razini privilegije, kada netko npr. koristi privilegiju isključivanja okidača baze,

- auditiranje na razini konkretnog objekta, npr. određene tablice.

Može se primijetiti da je SANS publikacija dobra mješavina metodoloških i tehničkih rješenja za reviziju sigurnosti informacijskog (pod)sustava temeljenog na Oracle RSUBP-u. Sadrži veliki broj tehničkih rješenja, iako ne toliko kao Oracle publikacija, ali zato naglašava važnost metodoloških rješenja, od kojih je naročito važan naglasak na klasifikaciju informacijskih resursa na temelju kritičnosti i osjetljivosti i na važnost poznavanja konkretnih podataka (pod)sustava čija se revizija radi.

6.2. Pristup Petea Finnigana Pete Finnigan (UK) je jedan od najboljih poznavatelja sigurnosti Oracle baze podataka. Autor je jedne knjige iz tog područja i brojnih članaka, a čest je predavač u UK, USA, Skandinavskim zemljama, Sloveniji i dr. Ovdje je ukratko prikazan njegov pristup reviziji sigurnosti Oracle baze, na temelju publikacije [4]. Autor naglašava da se sigurnosti Oracle baze podataka može podijeliti u sljedeća četiri područja:

- dizajniranje sigurnog sustava prije implementacije,

- sigurno konfiguriranje Oracle baze, - upotreba odgovarajućih mogućnosti Oracle

baze koje su ključne za sigurnost: auditiranje, enkripcija, FGA, VPD…,

- revizija sigurnosti Oracle baze.

Glavni koraci u reviziji sigurnosti Oracle baze su: - planiranje revizije, - odabir ciljanog (pod)sustava, - intervjuiranje ključnog osoblja, - analiza verzija, zakrpa, aplikacija, - analiza korisnika i korisničkih zaporki, - analiza datoteka, - analiza mreže, - analiza konfiguracije baze podataka.

Zanimljivo je da autor drži da za reviziju treba odabrati "živi" produkcijski sustav, a da ponekad može poslužiti i potpuni klon (npr. kopija baze koja služi za Disaster Recovery). Naravno, u toku revizije se takav produkcijski sustav smije samo čitati, te se ne smije narušiti performansa ili raspoloživost produkcijskog sustava. Autor naglašava da treba imati popis za provjeru (checklist) kao bazu za reviziju, ali drži da su liste koje se uobičajeno koriste preglomazne, sadrže i par stotina provjera (uključujući i jednu čiji je on autor, i koja se često koristi, a može se naći na stranicama SANS instituta). Puno je bolje napraviti jednostavniju, kraću listu i koncentrirati se na ono bitno što se revizijom nastoji postići. Nakon intervjuiranja ključnog osoblja, u toku revizije treba provjeriti instalirani softver, koja je verzija baze, da li su instalirane zakrpe, koji su korisnički računi. Zatim, kod analize zaporki treba provjeriti da li su zaporke:

- različite od korisničkog imena - različite od standardno postavljenih

(default), - jednake nekoj riječi iz rječnika, - prekratke.

Nakon toga se radi revizija datoteka operativnog sustava (vezanih za bazu), te analiza mreže. Kod analize konfiguracije baze, gledaju se dodjele privilegija, rola i profila, provjeravaju se inicijalizacijski parametri i dr. na temelju liste za provjeru. Važno je provjeriti da li su instalirane standardne (default) Oracle sheme. Treba analizirati koji su korisnički računi oni privilegiranih korisnika (administratora), koji su računi običnih korisnika, a koji su računi aplikacijskih shema. Pritom treba koristiti već pripremljene skripte (upite), a autor publikacije je napisao velik broj takvih skripti i stavio ih na raspolaganje. Nakon što završi prethodno prikupljanje podataka i analiza, treba napisati izvještaj. Autor preporuča da se nalazi označe stupnjem važnosti, npr. od 1 do 3. Važno je odabrati kritične propuste i odrediti kada će se nešto popraviti (npr. odmah, čim je prije moguće, kad bude moguće i sl.). Važno je ne pretjerati u broju, već odabrati 10 (maksimalno 20) ključnih propusta koje treba popraviti (a top 10 approach). Jedna nit koja se provlači kroz cijelu publikaciju je da (zlonamjerni) hakeri ne slijede pravila i da kod sprečavanja njihovih (ne)djela trebamo razmišljati kao oni.

7. ZAKLJUČAK Sigurnosti nekih područja informacijskog sustava, kao što su mreže, serverska i klijentska računala, posvećuje se velika pažnja već petnaestak godina. Sigurnost baza podataka, kao vrlo važan dio sigurnosti informacijskog sustava, jače se naglašava zadnjih sedam-osam godina. To isto vrijedi i za reviziju sigurnosti baza podataka. Kako navodi publikacija [2], osiguranje baza podataka u mnogo čemu je slično osiguranju računalnih mreža: "U oba slučaja nastoji se korisniku dati samo neophodne ovlasti, smanjiti ranjivu „površinu“ onemogućavanjem nepotrebnih funkcionalnosti, strogo autorizirati izmjene i nadzirati pristup, odvojiti funkcionalne blokove, inzistirati na enkripciji, itd. Jedina stvarna razlika je u tome što kod baza podataka svi ovi mehanizmi djeluju unutar samog SUBP-a.". Stoga, kod uspostave sigurnosti baze podataka, a tako i kod revizije sigurnosti treba, uz opća metodološka znanja o reviziji informacijskog sustava, određena znanja o mrežama, operativnim sustavima i sl., imati i dosta detaljna tehnička znanja o konkretnoj bazi podataka (odnosno o

konkretnom sustavu za upravljanje bazom podataka). Nažalost, u svemu tome ne pomaže činjenica da se konkretni SUBP sustavi dosta razlikuju. No, niti dobro metodološko znanje i znanje o konkretnoj bazi podataka nisu dovoljni. Potrebno je i dobro poznavanje konkretnih aplikacija, prije svega strukture i sadržaja podataka. Naime, napadači ne napadaju sustav za upravljanje bazom podataka zbog softvera, već podataka. Treba znati koji se podaci nalaze u bazi podataka, koji su od njih najkritičniji, koji je njihov tok kroz aplikaciju, gdje su ranjiva mjesta za napad na te podatke. Moglo bi se reći da za reviziju (ali i uspostavu) sigurnosti baze podataka vrijedi ova "formula": Sigurnost baza podataka =

Poznavanje metodika sigurnosti informacijskog sustava + Poznavanje konkretnog sustava za upravljanje bazama podataka + Poznavanje konkretnih podataka u bazi.

Literatura:

[1] Andresen, E. (2002): Conducting a Security Audit of an Oracle Database, SANS Institute Reading Room, http://www.sans.org/reading_room/whitepapers/auditing/ conducting_a_security_audit_of_an_oracle_database_19 (studeni 2009.) [2] CARNet CERT (2006): Sigurnost sustava za upravljanje bazama podataka, CARNet CERT, http://datapodium.com/dokumenti/uploads/hacking/ Sigurnost_sustava_za_upravljanje_bazama_podataka.pdf (studeni 2009.) [3] Date, C.J. (2004): An introduction to Database Systems (8.izdanje), Addison-Wesley [4] Finnigan, P. (2008): Oracle Security Auditing, PeteFinnigan.com Limited, http://www.petefinnigan.com/Oracle_Security_Audit_RISK20086Slides.pdf (studeni 2009.) [5] Knox, D, C. (2004): Effective Oracle Database 10g Security by Design, McGraw-Hill [6] Krakar, Z. (2009): Odabrana poglavlja revizije IS-a - materijali s predavanja, FOI [7] Litchfield, D. (2007): The Oracle Hacker's Handbook: Hacking and Defending Oracle, Wiley [8] Nichols, R. (2007), Database Security: An Inventory of Threats, Vulnerabilities, and Security Solutions, University of Oregon - Applied Information Management, https://scholarsbank.uoregon.edu/xmlui/bitstream/handle/1794/7680/2007-nichols.pdf?sequence=1 (studeni 2009.) [9] Oracle Corporation (2008): Oracle Database Security Checklist, Oracle White Paper, http://www.oracle.com/technology/deploy/security/ database-security/pdf/twp_security_checklist_database.pdf (studeni 2009.) [10] Oracle Corporation (2009): Advanced Security Administrator's Guide 11.2, Oracle manual [11] Oracle Corporation (2009): Enterprise User Security Administrator's Guide 11.2, Oracle manual

Podaci o autoru:

Zlatko Sirotić, dipl.ing. Istra informatički inženjering d.o.o., Pula e-mail: zlatko.sirotic@iii.hr Autor radi oko 25 godina na informatičkim poslovima. Najveći dio radnog vijeka proveo je u poduzeću Istra informatički inženjering d.o.o, Pula, gdje radi i sada. Radio je na svim poslovima u izradi softvera: anal iza, dizajn, programiranje, uvođenje, obuka korisnika, održavanje. Oracle proizvode (baza, Designer, Forms, Reports, JDeveloper) koristi zadnjih 12-tak godina. Objavljivao je stručne radove na kongresima "Hotelska kuća", na konferencijama CASE, KOM, HrOUG (Hrvatska udruga Oracle korisnika), u časopisima "InfoTrend" i "Ugostiteljstvo i turizam", a neka njegova programska rješanja objavljena su na web stranicama firmi Quest i Oracle.