UNIVERZITET ZA POSLOVNE STUDIJE BANJA LUKA

FAKULTET ZA IT I DIZAJN

GRAFIČKI DIZAJN

SIGURNOST BAZA PODATAKA

Seminarski rad

Profesor: prof. dr Mihajlo Travar Student: Simona Jovanović

Uvod

Baza podataka (eng. Database) je organizovana zbirka informacija. U bazama podataka

pohranjuju se brojne informacije iz svih mogućih područja. Različiti programi
(računovodstveni, organizacijski, istraživački itd.) zahtevaju različite informacije, a one se u
današnje doba pohranjuju u bazama podataka. Alati za uređivanje, stvaranje i upravljanje
bazama podataka objedinjeni su pod jednim nazivom SUBP - sistem za upravljanje bazama
podataka (eng. DBMS- Database Management System). Neki od najpoznatijih SUBP-a su:
Oracle, DB2, MySQL, Informix, PostgreSQL i SQL server.

Uz baze podataka dolaze i napadi zlonamernih korisnika koji se žele domoći informacija
pohranjenih unutar SUBP-a. Posledice takvog napada mogu rezultirati krađom identiteta,
brojeva kreditnih kartica, financijskim gubicima, gubicima privatnosti, narušavanjem
nacionalne sigurnosti te drugim brojnim opasnim posledicama koje su rezultat pristupa
osetljivim podacima. Kako su se razvijali SUBP-ovi, tako je postajala sve očitija potreba za
njihovom sigurnošću. Zbog toga su svakom novom varijantom (kod svih proizvođača)
dodavane brojne sigurnosne opcije, kao i sigurnosne nadogradnje koje bi uklanjale ranjivosti.

Sve većom upotrebom Interneta, privatno i na radnom mjestu, javio se imperativ osiguravanja
baza podataka od pristupa iz vanjskog svijeta. Ne samo zaštitom mrežnih resursa na kojima se
SUBP nalazi, kao što su postavljanje firewall-a i ažuriranjem programskih paketa ne
poslužiteljima, nego i zaštitom samog SUBP-a postavljanjem dozvola pristupa i sigurnosnih
politika. Zaštita baza podataka je od ključne važnosti za sigurnost bilo kojeg informacijskog
sistema iz razloga što je sama količina osjetljivih informacija pohranjena u tim bazama velika i
što o njoj često ovisi jako velik broj ljudi. Takođe je postalo vrlo lako pribaviti programske
pakete popularnih SUBP-ova, što zlonamernim korisnicima omogućuje istraživanje i
pronalaženje sigurnosnih propusta.

U mnogo čemu je osiguranje baza podataka slično osiguranju računarskih mreža. U oba slučaja
nastoji se korisniku dati samo neophodne ovlasti, smanjiti ranjivu „površinu“
onemogućavanjem nepotrebnih funkcionalnosti, strogo autorizovati izmene i nadzirati
pristup, odvojiti funkcionalne blokove, insistirati na enkripciji, itd. Jedina stvarna razlika je u
tome što kod baza podataka svi ovi mehanizmi djeluju unutar samog SUBP-a.
 Sigurnost baze podataka

Pojmovi integritet i sigurnost baze podataka se često spominju zajedno, međutim radi se o
dva različita aspekta zaštite podataka.

Integritet baze podataka (database integrity) - operacije nad podacima koje korisnici obavljaju
su ispravne (podaci se štite od ovlaštenih korisnika).

Sigurnost baze podataka (database security) - korisnici koji obavljaju operacije nad podacima
su ovlašteni za obavljanje tih operacija (podaci se štite od neovlaštenih korisnika).

Među ovim pojmovima postoje i sličnosti. U oba slučaja:

 moraju biti definisana pravila koja korisnici ne smeju narušiti

 pravila se pohranjuju u rečnik podataka, nezaobilazna su za sve korisnike, ne
opterećuju aplikacijske programe
 SUBP nadgleda rad korisnika i osigurava poštivanje pravila

Za zaštitu informacija pohranjenih u bazi podataka posetoje tri ključna elementa: To su:
poverljivost, integritet i dostupnost.

Sigurnost baze podataka se osigurava zaštitom na nekoliko nivoa:

 na nivou SUBP - sprečiti pristup bazama podataka ili onim dijelovima baza podataka
za koje korisnici nisu ovlašteni
 na nivou operacijskog sistema - sprečiti pristup radnoj memoriji računara ili
datotekama u kojima SUBP pohranjuje podatke
 na nivou računarske mreže - sprečiti presretanje poruka
 fizička zaštita - zaštita lokacije poslužitelja sistema za upravljanje bazama podataka
 na nivou korisnika - sprečiti da ovlašteni korisnici bilo nepažnjom bilo namerno
omoguće neovlaštenim osobama pristup podacima
 Autentifikacija

Autentifikacija znači potvrđivanje identiteta korisnika koji želi koristiti podatke, resurse ili
aplikacije. Potvrđivanjem tog identiteta uspostavljamo odnos povjerenja za buduće
interakcije. Autentifikacija isto tako omogućuje povezivanje pristupa i aktivnosti sa određenim
identitetom.

Svaka baza podataka ima autentifikacijksu proceduru. Proceduru kroz koju je korisnik
primoran dati svoje korisničko ime i lozinku te druge slične identifikacijske i autorizacijske
elemente. Jednom kad je korisnik autentifikovan, baza podataka „zna“ ko je korisnik i
dodeljuje mu ovlašćenja. Većina baza podataka dozvoljava kontrolu administratora nad
mogućnostima kako se obavlja autentifikacija. Ukoliko je administrator nepažljiv, vrlo lako bi
mogao dovesti bazu podataka u opasnost. Autentifikacija se može provoditi na nivou
operacijskog sistema ili unutar samog SUBP.

SUBP-ovi većinom nemaju mogućnosti zaštite korisničkih računa koje su prisutne kod na
primer operativnih sistema. Tu se prvenstveno misli na (ne)mogućnost kontrole lozinki
proverama u rečniku i na (ne)mogućnost određivanja roka valjanosti korisničkog računa. Često
se tokom postavljanja SUBP-a izvorno postavljeni i opšte poznati korisnički računi i korisničke
zaporke ostavljaju aktivnima bez promene.

Korisničke račune, nužne za pristup bazi podataka, potrebno je definisati u skladu s

tradicionalnim metodama upravljanja korisničkim računima. To podrazumijeva promjenu
izvorno postavljenih lozinki, onemogućenje korisničkog računa nakon određenog broja
neuspelih prijava, enkripciju lozinki, ograničenje pristupa podacima, onemogućenje
neaktivnih korisničkih računa te upravljanje životnim ciklusom korisničkih računa.

Bitno je postaviti ograničenje broja neuspješnih pokušaja prijave nakon kojeg sledi
zaključavanje tog istog računa i postupno povećanje vremena pre ponovnog pokušaja prijave,
te na taj način onemogućiti “brute force” probijanje lozinke. Lozinka treba biti dovoljne dužine,
te je poželjno korisiti posebne znakove. Administrator može pomoću niza alata onemogućiti
dužinom kratke i jednostavne lozinke. Takvi alati rade isključivo ako se autentifikacija ne
obavlja na operativnom sistemu nego unutar same baze podataka.
 Autorizacija

Nakon autentifikacije, sledi proces autorizacije koji može dozvoliti ili ograničiti nivo pristupa i
aktivnosti dodjeljenih tom identitetu.

Možemo postaviti ograničenja na količinu raznih sistemskih resursa koji se nalaze na

raspolaganju svakom korisniku. Na taj način, možemo sprečiti nekontrolisanu potrošnju
vrijednih resursa sistema. To je vrlo korisno u velikim, višekorisničkim sistemima, gde su
resursi sistema jako skupi. Preterano korištenje resursa od strane jednog ili više korisnika može
štetno uticati na druge korisnike baze podataka. Oraclova baza podataka nam omogućuje
kontrolisanje resursa kao što su sesije, vremenski odaziv CPU-a, pozivni nivo, te ostalih
resursa.

Kontrola pristupa

To je niz postupaka kojima se utvrđuje i evidentira pokušaj pristupa, te odobrava ili odbija
pristup na temelju unapred utvrđenih pravila. Jedna od najosnovnijih metoda zaštite podataka
je ograničenje pristupa podacima određenim korisnicima. Na ovaj način osigurava se
poverljivost podataka. Ona se može ostvariti autentifikacijom korisnika ili davanjem posebnih
privilegija i prava nad podacima (čitanje, pisanje, ili oboje). Kontrola pristupa definisana je na
tri načina: obavezna kontrola pristupa (MAC), diskretna kontrola pristupa (DAC) i kontrola
pristupa zasnovana na ulogama (RBAC).

MAC i DAC daju ovlasti određenim korisnicima ili grupama koje sadrže korisnike kojima se želi
dati pristup. MAC pravila se primenjuju na nivou sistema i smatraju se sigurnijima. DAC pravila
se primjenjuju na razini korisnika, smatraju se dinamičkim, a usmerena su na sadržaj. Na
primer , ako se jednom korisniku dodeli samo delimično čitanje ovisno o nekom svojstvu (pr.
čitanje samo parnog broja hotelske sobe u registru hotela) radi se o MAC pravilima. RBAC
omogućuje davanje određenih prava i ograničenja korisnicima za pristupanje bazi podataka.
Prava uključuju naredbe odabira podataka, modifikovanje podataka ili manipulisanje strukture
baze podataka.

Kontrola pristupa posjeduje i „odobri/povuci odobrenje“ (eng. grant/revoke) koja omogućuje

dinamično davanje dozvole pristupa određenom korisniku. Problem koji nastaje pri ovakvom
pristupu sigurnosti je mogućnost davanja ovlaštenja korisniku koji ima kriminalne namere te
može načiniti štetu na sistem, a korištenje se dodatno komplikuje ako korisnici često moraju
menjati uloge.

GRANT privileges
[ON relation]
TO users
[WITH GRANTOPTION]

REVOKE privileges
[ON relation]
FROM users
[WITH GRANTOPTION]

Svakom se korisničkom računu moraju dodeliti određene privilegije kako bi korisnik mogao
koristiti bazu. Sistemske privilegije omogućuju korisnicima spajanje na bazu, kreiranje
objekata u bazi, dodavanje novih korisnika i slično. Prava nad objektima pak omogućuju
izvođenje upita i menjanje podataka u tablicama. Korisniku se može omogućiti da sistemske
ovlasti i prava nad objektima prenosi drugim korisnicima. Npr. Oracle baza funkcioniše na least
privilege principu. To znači da bi svaki korisnik trebao imati samo minimum ovlasti koje mu
trebaju da obavlja posao. Stoga novi korisnici ne mogu raditi apsolutno ništa – ne mogu se čak
niti spojiti na bazu dok im se ne dodijeli sistemska CREATE SESSION ovlast. Ako se tada
novi korisnik spoji na bazu, opet mu to neće mnogo značiti, jer nema pravo na pregled ili
kreiranje niti jedne tablice – administrator mu mora dodijeliti SELECT TABLE i CREATE
TABLE ovlasti. Korisnicima se može omogućiti da svoja prava prenose drugim korisnicima.

LEAST PRIVILEGE NAČELO

Ovo načelo temelji se na dozvoli pristupa samo onim podacima baze i funkcionalnostima
SUBP-a koji su korisnicima neophodno potrebni, obzirom na njihov status i opis posla. Pri tome
treba voditi računa o ugrađivanju opisanih ograničenja izravno u SUBP, a ne u klijentsku
aplikaciju koja pristupa nekoj od pohranjenih baza podataka. U svrhu podizanja računarske
sigurnosti, ne preporučuje se izravno dodeljivanje ovlasti pojedinim korisničkim računima.
Puno je bolji način da se oblikuju tzv. uloge (eng. roles ) i da se njima dodele pojedine ovlasti.
Nakon toga se svakom korisniku dodaju uloge koje mu pripadaju. Na taj način jedan korisnik
može zauzeti više uloga, a olakšano je dodeljivanje i oduzimanje ovlasti vezanih uz radne
zadatke.
 ULOGE (eng. roles)

Ako se u bazi podataka nalazi nekoliko hiljada tablica i ako je broj korisnika velik, dodeljivanje
pojedinačnih ovlasti svakom korisniku je mukotrpan i dugotrajan posao za administratore.
Takođe, kada se ovlast dodeli korisniku, on je može koristiti u bilo kojem trenutku, a to nekad
nije poželjno (na primjer, ako administrator želi zabraniti pristup tablicama u vreme dok se na
bazi analizira njihova veličina i struktura indeksa kako bi se upiti automatski mogli
optimizovati). Oba navedena problema se mogu rešiti primenom uloga.

Uloga je skup sistemskih ovlasti i ovlasti nad objektima u bazi. Ta se prava dodeljuju grupno te
se mogu aktivirati ili deaktivirati unutar sesije. Na primer, neka postoje tri skupine korisnika:
pripravnici, zaposlenici i menadžeri. Menadžeri mogu pregledavati i mijenjati podatke u svim
tablicama, zaposlenici mogu pregledavati podatke u svim tablicama, ali menjati samo neke,
dok pripravnici ne mogu menjati podatke niti u jednoj tablici. Kako ne bi svakom korisniku
morali posebno dodeljivali ovlasti, možemo kreirati te tri uloge, dodeliti im ovlasti koje im
trebaju, te zatim te uloge dodeliti korisnicima.

Slika 1 - Uloge, docs.oracle.com

Ispitivanje
Ispitivanje se koristi za praćenje pristupa bazi podataka i aktivnosti korisnika. Takođe,
ispitivanje se može koristiti za identifikaciju korisnika koji pristupa objektima u bazi podataka
te koje akcije se obavljaju i koji podaci su promenjeni. Nažalost, ispitivanje ne donosi odbranu
od napada ali pridonosi računarskoj forenzici nakon napada kako bi se lakše identifikovao
propust i način iskorištavanja spomenutog propusta koji se koristio za upad u bazu podataka.
Uobičajene kategorije ispitivanja baza podataka uključuju nadgledanje pokušaja ulaza u bazu
podataka, aktivnosti upravljačkog jezika za podatke (eng. data control language, DCL),
aktivnosti definicijskog jezika za podatke (eng. data definition language DDL) i aktivnost jezika
za manipulaciju podacima (eng. data manipulation language, DML). Nadgledanje pokušaja
ulaza u bazu podataka obuhvata sve informacije o uspješnim i neuspješnim pokušajima
autorizacije na bazu podataka. DCL ispitivanja beleže promene uloga i privilegija korisnika kao
i brisanja i dodavanja korisnika. DDL ispitivanja, s druge strane beleže promene na šemi baze
podataka kao što su izmena strukture tablice ili atributa tipova podataka.

Kriptiranje

Element poverljivosti podataka najbolje se osigurava preko metoda kriptiranja koje se

implementiraju na SUBP. Metode su posebno korisne kada se podaci spremaju na sekundarne
spremnike podataka kao na primjer pomoćni poslužitelj za kopije. Kriptiranje bi se trebalo
shvatati kao poslednja linija odbrane kad sve ostale sigurnosne mere zakažu. Dve najčešće
tehnike koje se koriste pri kriptiranju u bazama podataka su kriptiranje podataka pri prenosu
i kriptiranje podataka u mirovanju.

U svrhu kriptiranja podataka pri prenosu većina SUBP-ova podržava komunikaciju upotrebom
SSL (eng. Secure Socets Layer ) zaštitnog protokola. Kod kriptiranja podataka u mirovanju
potrebno je kriptirati samo one najosetljivije, te ono može biti izvedeno na tri nivoa:

1. na nivou skladišta podataka (eng. storage level encryption),

2. na nivou baze podataka (eng. database-level encryption),
3. na aplikacijskoj nivou (eng. application level encryption).

Moguće je raditi i enkripciju datoteka (eng. file-based ), ali takav pristup ne štiti od napada
kroz SUBP. Enkripcija na nivou programskog interfejsa (eng. API - Application Programming
Interfaces ) podrazumeva kriptiranje komunikacije među pojedinim podsistemima SUBP-a.
Ona je složena i zahteva puno posla što povećava rizik od pogreške.

Najslabiju podršku baze podataka imaju za tzv. ' transparent ' enkripciju. To je enkripcija koja
se automatski primjenjuje pri svakoj promeni ili unosu potencijalno osetljivih podataka.
Automatska primena enkripcije znači da nema potrebe za eksplicitnim pozivanjem
enkripcijskih funkcija. Time se izbegavaju programerske pogreške kao što su pozivanje
pogrešnih enkripcijskih funkcija, pozivanje ispravnih funkcija, ali s pogrešnim parametrima ili
njihovo nepozivanje u slučajevima kada je to potrebno. Ovo se postiže premeštanjem
enkripcije s nivoa aplikacijskog sloja na sloj baze podataka.

Kontrola integriteta

Kontrola integriteta osigurava se preko semantičkih ograničenja integriteta. Kad god korisnik
pokušava izmijeniti podatke, nakon što mehanizmi kontrole pristupa omoguće korisniku rad,
semantički podsustav započinje provjeru jesu li izmijenjeni podaci semantički točni.
Semantička točnost podataka se ovjerava preko skupine uvjeta ili predikata koji se moraju
uskladiti sa trenutnim stanjem baze. Kako bi se omogućilo otkrivanje zlonamjernog rukovanja
podacima, podaci se dodatno digitalno potpisuju.

Fizička sigurnost

Kada se govori o sigurnosti baze podataka uključena je i fizička sigurnost baze podataka. Da bi
se ona osigurala, potrebno je zadovoljiti određene uvjete. Neki od uvjeta su: dovoljno
rashlađivanje prostorija u kojima se drže poslužitelji, video nadzor sklopovlja poslužitelja,
protuprovalne sustave, dozvola pristupa samo ključnim djelatnicima ASP-a te postojanje
redundantnih sustava.

Firewall

Kod zaštita baza podataka uglavnom se koriste sledeći bedemi:

  Paketno filtrirani bedemi - nadgledaju izvorne i odredišne IP adrese bilo koje veze i
proveravaju ih prema ugrađenom setu pravila kako bi odlučili da li bi se veza trebala
dozvoliti ili ne. Ne proveravaju sadržaj pa ih je lako zaobići.
 Aplikacijski usmernici (eng. application proxy) - zamenjuju klijenta na poslužiteljskoj
strani odnosno poslužitelja na klijentskoj strani. Dozvoljavaju i prekidaju te dvije veze
po potrebi, a sav promet prolazi kroz njih.
 Inspecijski vatrozidi - procesori paketa koji provjeravaju čitave sjednice. Provjeravaju
postoje li protokoli te postoje li zlonamjerno oblikovani paketi. Provjeravaju
konzistentnost tablica stanja prometa i provjeravaju stanje TCP veze, adresne
translacije i druge. Ovi vatrozidi podržavaju korištenje VPN (eng. Virtual private
network) veza.

Sistem za detekciju provale

Sustav detekcije provale IDS (eng. Intrusion detection system) sakuplja informacije sa brojnih
osjetila unutar računala i računarskih mreža, te analizira te informacije kako bi našao indikacije
zlonamernih aktivnosti u računalnoj mreži. Osim detekcije upada, ovakvi alati pružaju širok
spektar funkcija kao što su analiza korisničke aktivnosti, statistička analiza abnormalnih
aktivnosti, pregled dnevnika operacijskih sustava i brojne druge. Osetila su aplikacije na
računalu koje prikupljaju podatke te često te podatke beleže u dnevnike (eng. logs). Nakon što
su podaci skupljeni, analiziraju se ili u intervalnom modu ili u realnom vremenu. Analiza se
obavlja bazirano na signaturama, statističkoj analizi, analizi integriteta ili kombinaciji ovih
metoda. Nedostatak ovakvog sistem je prilično često lažno alarmiranje korisnika.

Sistem prevencije provale

Sistem prevencije provale IPS (eng. intrusion prevention system) izvodi jednaku zadaću kao i
IDS, ali s dodatnom mogućnošću blokiranja prepoznatog pokušaja provale.

IPS na glavnom računalu (eng. Host based) - implementira se koristeći aplikacijske slojeve API
(eng.application programming interface) koji se koriste za komunikaciju operacijskog sustava
i aplikacija. Provjerava se svaki sistemski poziv prema pravilima pristupa koji se automatski
generiraju. Svrha ovih IPS-a je blokiranje napada prepisivanjem spremnika(eng. buffer
overflow), sprečavanje izmene registarskih vrijednosti i prepisivanja deljenih dinamičkih
biblioteka (DLL, eng. dynamic link library).

Poznati napadi i propusti

Zlonamerno korištenje ovlasti

Kada se korisnicima ili aplikacijama dodjeli veća razina ovlasti nego što im je potrebna čest je
slučaj zlouporabe danih ovlasti. Ovaj propust uglavnom je uzrokovan administratorovim
nedostatkom vremena da regulira zadatke koje pojedini korisnik mora i može obavljati te se
vrlo često događa da korisnik dobije velike ovlasti nad bazom podataka nad kojom mu je
potrebno pregledati svega par redaka. Rješenje ovog propusta bio bi mehanizam
ograničavanja pristupa na razini upita. Tako bi se neke osnovne radnje na negranuliranim
podacima mogle obavljati, dok bi se ostale nedozvoljene radnje blokirale i dojavljivale
administratoirma. Implementacija ovakvog rješenja trebala bi biti potpuno automatizirana te
bi se trebao koristiti programski paket izvan SUBP-a koji nema takvih mogućnosti (u protivnom
je posao za administratora vrlo težak ako ne i nemoguć).

Drugi slučaj zlonamjernog korištenja privilegija je korištenje legitimnih ovlasti. Primjerice, ako
korisnik posjeduje ovlast čitanja i spremanja podataka na računalo i u slučaju da je to računalo
ukradeno, ili korisnik podijeli osjetljive informacije s dugima, tad postoji opasnost od
otkrivanja osjetljivih informacija. Rješenje ovakvog problema bilo bi kontekstualna kontrola
pristupa, odnosno pod kojim okolnostima se pristupa bazi podataka. Primjeri kontekstualne
provjerue su: vrijeme pristupa, izvorišna IP adresa, volumen podataka koji se koristio,
aplikacijski klijent i slično.

SQL

Č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 ugnježđivanje 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.
Napadač umeće ili ugnježđuje neautorizirane izraze baze podataka u ranjivi SQL podatkovni
kanal. Ciljani kanali podataka uključuju spremljene procedure, ali najčešće i ulazne parametre
web aplikacije. Napadači iskorištavaju činjenicu da programeri često ulančavaju SQL naredbe
sa korisnički unesenim parametrima te tako mogu jednostavno umetnuti SQL izraze. Umetnuti
izrazi se šalju na bazu podataka gdje se potom izvršavaju.

Primjer jednostavnog SQL injection-a:

Napadač bi mogao iskoristiti navedeni kod tako da na URL postavi dodatni izraz „OR 1=1“ čiji
će uvjet biti uvijek zadovoljen (jer je 1=1 točna izjava pa će cijeli izraz, zbog OR operacije,
također uvijek biti istinik) primjerice:

http://www.mydomain.com/products/products.asp?productid=123 or 1=1

A potom bi mogao nadodati i naredbu „drop table“ koja briše cijelu tablicu podataka:

http://www.mydomain.com/products/products.asp?productid=123; DROP TABLE Products

Sprečavanje ugnježđivanja SQL naredbi može biti jednostavno ako se poznaje mehanizam
napada. Dva su moguća pristupa: provjera korisničkih unosa i korištenje parametriziranih
upita. Prvi pristup se odnosi na prihvaćanje samo onih unosa koji se sastoje od dozvoljenih
znakova, a to su najčešće samo alfanumerički znakovi. Korištenje parametriziranih upita znači
povezivanje varijabli umjesto ulančavanja znakovnih nizova.

DoS napadi

DoS napad je posljedica propusta koja uzrokuje nemogućnost pristupa resursu. U ovom slučaju
radi se o bazi podataka odnosno o web aplikaciji. DoS stanje može se kreirati preko različitih
tehnika kao što su korupcija podataka, mrežno preplavljivanje (preopterećenje) i
preopterećenje računalnih resursa te iskorištavanjem ranjivosti platforme i/ili okoline na kojoj
se baza podataka nalazi. Primjer DoS napada slične izvedbe kao i umetanje SQL koda je
korištenje dugih posebno oblikovanih regularnih izraza.
Prevencija DoS napada zahtjeva zaštite na višestrukim razinama kao što su mrežna,
aplikacijska i razina baze podataka. Učinkovita obrana protiv DoS napada na razini mreže
ostvaruje se korištenjem dinamičkog poslužitelja, koji pruža višestruke dretve za rukovanje
vezama i postavlja ograničenja na vrijeme izvođenja pojedinih naredbi.

Ranjivosti komunikacijskih protokola

Rastući broj mrežnih ranjivosti identificira se u komunikacijskim protokolima baza podataka.

Aktivnosti koje ciljaju na ovakav tip ranjivosti mogu sezati od neautoriziranog pristupa bazi
podataka i korupcije podataka pa do izazivanja stanja uskraćivanja usluge. Ranjivosti
komunikacijskih protokola mogu se zaobići tehnologijom koja se naziva validacija protokola.
Svaki komunikacijski paket se kod te tehnologije rastavlja te se uspoređuje je li u skladu s
očekivanjem. U slučaju da stvarni promet ne odgovara očekivanjima on se može blokirati.

Komercijalne baze i baze otvorenog koda

Baze otvorenog koda su one čiji je izvorni kod dostupan svakom korisniku. Dozvoljene su
modifikacije i nadogradnje, ali se ne smiju licencirati (naplaćivati). Komercijalne baze
podataka nemaju dostupan programski kod, naplaćuje se njihovo korištenje te je uglavnom
zabranjena njihova modifikacija od strane krajnjeg korisnika (eng. End user licence agreement,
EULA). Svaka od opcija ima svoje prednosti i nedostatke. Na primjer, komercijalne baze
podataka obično uključuju i dodatne programske pakete i korisničku podršku kao i korisničke
treninge koju pruža proizvođač. Baze otvorenog koda generalno su fleksibilnije i jeftinije pri
korištenju i održavanju. Druga prednost baza otvorenog koda je kompatibilnost sa drugim
tehnologijama i postojećim sustavima. Sa strane sigurnosti koda, nakon brojnih istraživanja u
računalnoj industriji, pokazalo se da su baze otvorenog koda obično bolje od komercijalnih
zbog velike podrške zajednice. Nažalost, to se odnosi samo na neke od SUBP-a, dok primjerice
jedan od većih predstavnika baza podataka otvorenog koda, MySQL nema implementirane
sigurnosne mogućnosti, vanjsku autentifikaciju, sigurnost na razini redaka i sl. Unatoč tim
problemima, razvojni timovi sve više se oslanjaju na baze podataka otvorenog koda jer im se
sigurnost kontinuirano poboljšava u korak sa komercijalnim bazama podataka.
 Primena zakrpi i testiranje

Iako sve zakrpe uklanjaju ranjivosti treba ih oprezno primjenjivati zbog mogućnosti unošenja
novih pogreški u sustav. Jedino oružje protiv takvih pogrešaka je ispitivanje. Neke zakrpe
postavljaju zahtjeve na sustav na kojem se primjenjuju. Te zahtjeve i opseg zakrpe je potrebno
poznavati kako bi se utvrdilo postoji li uopće potreba za njezinom primjenom.

Izrada sigurnosnih kopija

Postoje različiti tipovi grešaka i problema koji se mogu javiti u radu s bazom podataka.
Oporavak od nekih grešaka je automatski, dok druge zahtijevaju intervenciju administratora.

Ako SQL naredba uzrokuje grešku, baza automatski poništava efekte naredbe korištenjem
undo podataka i transformacijskih vektora. Pogreška se može dogoditi i na razini korisničkog
procesa koji je pokrenuo transakciju. Najčešći je uzrok prekid veze između klijenta i
poslužitelja. Ovakve slučajeve rješava pozadinski proces PMON na način da poništava efekte
transakcije i gasi serverski proces te oslobađa zauzetu memoriju.

Tipičan problem koji svakako zahtijeva angažman administratora je oštećenje diskova koji
čuvaju podatke. Kontrolna datoteka i redo log datoteke moraju u svakom trenutku biti
zaštićene multipleksiranjem. Ako se datoteke multipleksiraju na različite diskove, uvijek je
moguće upotrijebiti kopije s ispravnih diskova. Budući da postoji malena vjerojatnost da se
pokvare svi diskovi na kojima se nalaze multipleksirane kopije, dodatna mjera sigurnosti je
arhiviranje kontrolne i redo log datoteka. Podatkovne datoteke se ne mogu multipleksirati,
stoga je jedina opcija kreiranje sigurnosnih arhivskih kopija.

Sigurnosna politika

Sigurnosna politika je temeljana na načelu treba-znati (eng. need to know), kompetentnosti,

nadležnosti itd. Na nju mogu utjecati zakonska I etička pitanja, politike na državnoj ili
korporativnoj razini. Ona se mjenja u skladu s promjenama poslovnih faktora, regulativa i
uvjeta u okruženju.
Sigurnosna politika se dijeli na:

 Sistemska sigurnosna politika

 Podatkovna sigurnosna politika
 Korisnička sigurnosna politika
 Politika upravljanja lozinkama
 Revizorska politika

Sistemska sigurnosna politika

Svaka baza podataka ima jednog ili više administratora odgovornih za održavanje svih aspekta
sigurnosne politike, a to su sigurnosni administratori. Ako se radi o relativnoj maloj bazi
podataka, onda je moguće da ja administrator baze podataka odgovoran i za sigurnost baze
podataka. U slučaju da se radi o velikoj bazi podataka onda je za taj posao zadužena
odgovarajuća osoba ili grupa ljudi koji imaju ovlasti sigurnosnog administratora.

Njezine podgrane su:

 Upravljanje korisnicima baze podataka – ovisno o veličini baze podataka i količini posla
potrebnog za upravljanje korisnicima, moguće je da sigurnosni administrator bude
jedini korisnik sa ovlastima korištenja naredbi CREATE, ALTER, ili DROP na korisnicima
baze podataka, ili taj posao može obavljati više sigurnosnih administratora. U svakom
slučaju takva odgovornost je predviđena samo za osobe od povjerenja
 Autentifikacija korisnika – mora biti omogućena autentifikacija korisnika (potvrda da
se radi o ispravnom korisniku)
 Operacijska sistemska sigurnost – administratori baze podataka moraju imati ovlasti
kreiranja I brisanja datoteka, dok ostali korisnici baze podataka nebi smjeli imati takve
ovlasti

Sigurnosna politika podataka

Sigurnosna politika podataka uključuje mehanizme koji kontrolišu pristup i korištenje baze
podataka na objektnoj razini. Takva politika odlučuje koji korisnik ima pristup spefifičnoj šemi
objekta i koje specifične vrste aktivnosti su dozvoljene tom korisniku.

Podatkovna sigurnosna politika primarno ovisi o razini sigurnosti koju želimo za podatke u bazi
podataka. Na primer, moguće je prihvatiti i nisku razinu sigurnosti baze podataka, ako želimo
omogućiti da svaki korisnik može kreirati bilo koju šemu objekta, ili da može dodijeliti ovlasti
za njihove objekte bilo kojem korisniku sistema.

Sigurnost podataka bi zapravo trebala ovisiti o osetljivosti podataka koji se nalaze u toj bazi
podataka. Ako informacija nije osetljiva, tada nije potrebna visoka razina sigurnosti, no ukoliko
je informacija od velike važnosti, ta razina bi trebala biti na visokoj razini.

Korisnička sigurnosna politika

Korisnička sigurnosna politika dijeli se na:

 Opšta korisnička sigurnost – za sve vrste korisnika baze podataka, razmatra sigurnost
lozinki i upravljanje ovlastima
 Sigurnost krajnjeg korisnika – sigurnosni administratori moraju odrediti politiku za
sigurnost kranjeg korisnika. Ako baza podataka ima veliki broj korisnika, sigurnosni
administrator može odlučiti koje grupe korisnika se mogu grupirati u korisničke grupe,
te zatim kreirati uloge nad tim grupama. Svaka uloga ima određene ovlasti koje su im
dodeljene
 Administratorska sigurnost – kao i za sve ostale korisnike baze podataka treba postojati
sigurnosna politika i za administratore. Ako se radi o velikoj bazi podataka i ako ona
ima nekoliko različitih vrsta administratora, sigurnosni administrator može grupirati
srodne administrativne ovlasti u nekoliko administrativnih uloga. Zatim se te uloge
mogu dodijeliti određenim administratorima. Ukoliko se radi o maloj bazi podataka i
ako ona sadrži mali broj administratora, moguće je kreirati jednu ulogu i dodeliti je
svim administratorima.
 Sigurnost aplikacijskog programera – aplikacijski programeri su jedinstveni korisnici
baze podataka koji zahtevaju specijalne grupe ovlasti kako bi odradili svoj posao. Za
razliku od krajnjih korisnika, programerima su potrebne sistemske ovlasti poput
 CREATE TABLE, CREATE PROCEDURE i ostale. Potrebno im je dodeliti samo nužne
sistemske ovlasti kako bi ograničili nijhove sveukupne ovlasti u bazi podataka
 Sigurnost aplikacijskog administratora – u velikim bazama podataka trebalo bi
razmotriti dodeljivanje sledećih ovlasti aplikacijskim administratorima: kreiranje uloga
za aplikacije i upravljanje ovlastima svake aplikacijske uloge, kreiranje i upravljanje
objektima koje koriste aplikacije baze podataka i održavanje i ažuriranje aplikacijskog
koda.

Politika upravljanja lozinkama

Sigurnosni sistem lozinki baze podataka zahjteva da lozinke budu tajne u svakom trenutku.
Pošto su lozinke osetljive na krađe, krivotvorenja i zloupotrebe, Oraclovu bazu podataka, kako
bi omogućila veću kontrolu i sigurnost baze podataka, kontrolišu sigurnosni službenici putem
korisničkih profila.

Revizorska politika

Sigurnosni administratori trebaju definisati revizorsku politiku za svaku bazu podataka.

Revizija predstavlja praćenje i snimanje odabranih aktivnosti korisnika baze podataka. Može
biti bazirana na individualnim aktivnostima ili na kombinaciji faktora koje uključuju: ime,
aplikaciju, vreme itd. Sigurnosna politika može izazivati reviziju kada neko pristupa ili menja
specifične elemente baze podataka.

Zaključak

U bazi podataka su spremljni važni i osetljivi podaci preduzeća, stoga je vrlo važno te podatke
zaštititi i njima upravljati na pravi način. Kao glavne preporuke za čuvanje sigurnosti baze
podataka su stalna nadogradnja programskih paketa, odvajanje baze na sigurne segmente
mreže, korištenje enkripcije pri transferu i skladištenju osetljivih podataka, korištenje
autorizacije autentifikacije i uloga.

Svi SUBP-ovi sadrže ranjivosti i nije moguće odrediti niti najsigurnijeg niti najranjivijeg među
njima. Jedino je sa sigurnošću moguće tvrditi kako je najsigurniji onaj sistem koga se najbolje
poznaje. Dobro poznavanje arhitekture i funkcionalnosti sustava od strane administratora,
omogućuje njegov siguran rad. Broj funkcionalnosti koje SUBP posjeduje može takođe biti
pokazatelj njegove sigurnosti, odnosno nesigurnosti. Veći broj funkcionalnosti znači i veće
mogućnosti za pojavljivanje ranjivosti. Preporuke vezane uz sigurnost baza podataka se mogu
sažeti u sledeći popis: korisnicima je potrebno dodeljivati samo neophodne ovlasti, posebnu
pažnju potrebno je posvetiti upravljanju korisničkim računima i lozinkama, ispravno
primenjene metode nadzora i periodičke analize mogu uvelike pomoći prilikom otkrivanja
napada, a time i olakšati pronalaženje ranjivosti i njihovo uklanjanje, korištenje enkripcije
zlonamernim korisnicima otežava pristup osetljivim informacijama, kako korisničkim
zaporkama, tako i svim ostalim podacima pohranjenim u bazi, postavljanje poslužitelja s
bazom podataka u unutarnju mrežu čini ga daleko sigurnijim, a primena sistema dozvoljenih
IP adresa dodatno smanjuje verovatnost udaljenih napada. Za sigurnost SUBP-a je vrlo važna
stalna i redovita primena zakrpi. Pri tome treba uvijek voditi računa o tome da je prvi korak
kod uklanjanja ranjivosti spoznavanje njenog postojanja.

Literatura

[1] Centar informacijske sigurnosti. Zaštita baza podataka.

http://www.cis.hr/files/dokumenti/CIS-DOC-2012-08-059.pdf. Kolovoz 2012.
[2] CARNet CERT. Nacionalno središte za sigurnost računalnih mreža i sustava. Sigurnost sustava
za upravljanje bazama podataka. http://www.cert.hr/sites/default/files/CCERT-PUBDOC-
2006-10-171.pdf. Listopad, 2006.
[3] mr. sc. Anzil, Jasenka. Zaštita i sigurnost informacijskih sustava: Sigurnost baza podataka.
Sveučilište u Zagrebu. Fakultet elektrotehnike i računarstva.
https://www.fer.unizg.hr/_download/repository/06_sigurnost_baza_podataka_-_1._dio.pdf.