Zaštita i sigurnost informacijskih sustava

Sigurnost baza podataka

mr. sc. Jasenka Anzil

Sveučilište u Zagrebu
Fakultet elektrotehnike i računarstva

Zaštićeno licencijom http://creativecommons.org/licenses/by-nc-sa/2.5/hr/

Creative Commons

 slobodno smijete:
 dijeliti — umnožavati, distribuirati i javnosti priopćavati djelo
 remiksirati — prerađivati djelo
 pod sljedećim uvjetima:
 imenovanje. Morate priznati i označiti autorstvo djela na način kako je
specificirao autor ili davatelj licence (ali ne način koji bi sugerirao da Vi ili
Vaše korištenje njegova djela imate njegovu izravnu podršku).
 nekomercijalno. Ovo djelo ne smijete koristiti u komercijalne svrhe.
 dijeli pod istim uvjetima. Ako ovo djelo izmijenite, preoblikujete ili
stvarate koristeći ga, preradu možete distribuirati samo pod licencom
koja je ista ili slična ovoj.

U slučaju daljnjeg korištenja ili distribuiranja morate drugima jasno dati do znanja licencne uvjete
ovog djela. Najbolji način da to učinite je linkom na ovu internetsku stranicu.
Od svakog od gornjih uvjeta moguće je odstupiti, ako dobijete dopuštenje nositelja autorskog prava.
Ništa u ovoj licenci ne narušava ili ograničava autorova moralna prava.
Tekst licencije preuzet je s http://creativecommons.org/.

2 / 75
Sadržaj

 baze podataka i sustavi za upravljanje bazama podataka

 dokazivanje autentičnosti korisnika baze podataka
 kontrola pristupa
 diskrecijska kontrola pristupa
• kontekstno ovisna zaštita podataka
 mandatna kontrola pristupa
• baze podataka s višerazinskom zaštitom podataka
 kontrola pristupa temeljena na ulogama
 šifriranje podataka
 nadgledanje rada korisnika

3 / 75
Baze podataka i sustavi za upravljanje
bazama podataka
Baza podataka i sustav za upravljanje bazama podataka

 baza podataka
 skup podataka koji su pohranjeni i organizirani tako da mogu zadovoljiti zahtjeve korisnika.
(M. Vetter)
 skup međusobno povezanih podataka, pohranjenih zajedno, uz isključenje bespotrebne
zalihosti (redundancije), koji mogu zadovoljiti različite primjene. Podaci su pohranjeni na
način neovisan o programima koji ih koriste. Prilikom dodavanja novih podataka, mijenjanja i
pretraživanja postojećih podataka primjenjuje se zajednički i kontrolirani pristup. Podaci su
strukturirani tako da služe kao osnova za razvoj budućih primjena. (J. Martin)
 sustav za upravljanje bazom podataka (SUBP) - programski sustav koji:
 omogućava upravljanje podacima u bazi podataka
 može istovremeno upravljati s više baza podataka
 upravlja istovremenim pristupom bazi podataka od strane više korisnika/aplikacija uz
osiguravanje sigurnosti i integriteta baze podataka
 temelji se na odabranom modelu podataka (hijerarhijski, mrežni, relacijski, objektno-
relacijski, objektno-orijentirani)

5 / 75
Zadaće SUBP-a
fizički opis
 trajna pohrana podataka (persistent storage)
 skriva od korisnika detalje fizičke pohrane podataka
 osigurava logičku i fizičku nezavisnost podataka
 osiguravanje programskog sučelja (programming interface)
SUBP
 omogućuje definiciju i rukovanje s podacima
 DDL - Data Definition Language
 DML - Data Manipulation Language
logički opis
 optimiranje metoda pristupa podacima (query optimization)
 zaštita podataka aplikacijski programer
 integritet podataka (integrity)
 pristup podacima - autorizacija, sigurnost (security)
 potpora za upravljanje transakcijama
 kontrola paralelnog pristupa (concurrency control)
 obnova u slučaju razrušenja (recovery)

6 / 75
Komponente SUBP-a
Client Communications DBMS
Manager

Shared Components
Query Parser

module
Authorization
Query Rewriter Process Manager

Query Optimizer
Memory Manager
Plan Executor

Catalog Manager
Execution Engine
Transaction Manager

Scheduler
Data Manager
Administration,
Lock Manager Recovery Manager Monitoring, Utilities

Access Methods Buffer Manager

Manager

Storage

7 / 75
SUBP kao komponenta složenijih sustava

Naive users Application Sophisticated Users DBAs

Programmers

Application Application Query Tools Administration Tools

interfaces programs (Utilities)

DML DDL

DBMS
 Korisnici
 pristupaju bazi tako da postavljaju upite, mijenjaju podatke i izrađuju izvještaje
 različite skupine korisnika:
 korisnici koji povremeno pristupaju bazi koristeći upitni jezik
 korisnici koji često koriste bazu postavljajući standardne upite i radeći standardne promjene
koristeći programirana sučelja (npr. službenici u banci, turističkim agencijama...)
 sofisticirani korisnici koji su dobro upoznati s bazom podataka i koriste je na složeniji način (npr.
inženjeri, znanstvenici, poslovni analitičari)
8 / 75
Administratori

 organiziraju, nadziru i optimiziraju korištenje SUBP-a

 odgovorni za cjelokupnu sigurnost SUBP-a

 administrator poslužitelja baze podataka (database server administrator – DBSA)

 instaliranje i nadogradnja SUBP-a; kreiranje novog korisnika; autorizacija na razini SUBP-a

 administrator baze podataka (database administrator - DBA)

 autorizacija na razini baze podataka (provođenje sigurnosne politike)
 dodjeljivanje i ukidanje ovlasti korisniku baze podataka
 dodjeljivanje sigurnosne klasifikacijske razine korisniku u višerazinskom sigurnosnom
sustavu, u skladu s politikom organizacije

9 / 75
Relacijski model podataka

 objekti u relacijskom modelu podataka su relacije; relacija je skup n-torki

 n-torke opisuju pojedinačne entitete
 entitet - bilo što, što ima suštinu ili bit i posjeduje značajke s pomoću kojih se može razlučiti
od svoje okoline (npr. osoba, objekt, apstraktni pojam, događaj… )
• entitet posjeduje neka svojstva ili atribute koji ga karakteriziraju
• slični entiteti se svrstavaju u skupove entiteta
• identifikatori ili ključevi - skupovi atributa čije vrijednosti jednoznačno određuju entitet u
promatranom skupu entiteta atributi
 shema relacije obuhvaća naziv relacijske sheme i skup atributa
predmet (PREDMET) sifPred nazPred ectsBod nastProg
31503 Baze podataka 6.0 FER-2
• skup atributa { sifPred } je ključ 1228 Baze podataka 5.0 FER-1
relacije predmet n-torke 19670 Matematika 1 7.0 FER-2
21006 Fizika 1 6.0 FER-2
90 Baze podataka 5.0 ETF-4

 operacije: selekcija, unija, razlika, presjek, projekcija, ...

elementarni podatak
 integritetska ograničenja: domenski, entitetski, referencijski, ...
10 / 75
SQL (Structured Query Language)

 temeljen na relacijskom modelu podataka

 objekti u SQL-u su tablice, a ne (formalno definirane) relacije
 temelji se na predikatnom računu i relacijskoj algebri
 objedinjuje funkcije jezika za definiciju podataka i jezika za rukovanje podacima
 jezik za definiciju podataka (Data Definition Language - DDL)
 koristi se za definiranje nove sheme baze podataka ili modificiranje postojeće;
omogućava imenovanje i opis relacija, atributa, ograničenja integriteta i pravila sigurnosti
(CREATE DATABASE, CREATE TABLE, …)
 obavljanje DDL operacija rezultira izmjenom sadržaja rječnika podataka (metapodataka)
 jezik za rukovanje podacima DML (Data Manipulation Language - DML)
 omogućava korištenje skupa operacija za rukovanje podacima u bazi podataka
 neproceduralan upitni jezik
 ne sasvim korektno, pojam se koristi ne samo za operacije dohvata podataka, već i za
operacije izmjene, brisanja i unosa podataka (SELECT, INSERT, UPDATE, DELETE)
11 / 75
SQL-sjednica

 SQL-sjednica (SQL-session) je kontekst u kojem jedan korisnik obavlja niz SQL

naredbi putem jedne veze (SQL-Connection) prema sustavu za upravljanje bazama
podataka
• SQL-sjednica započinje u trenutku kada korisnik, upotrebom klijentske aplikacije,
ostvari vezu (connect) sa sustavom za upravljanje bazama podataka
• SQL-sjednica završava u trenutku kada korisnik prekine vezu (disconnect) prema
sustavu za upravljanje bazama podataka

klijentska
aplikacija
klijentska
aplikacija SUBP klijentska
aplikacija

12 / 75
Sigurnost i zaštita baza podataka
Primjeri narušavanja sigurnosti podataka (1)

 2000 - CD Universe - online prodaja glazbenog sadržaja - ukradeni brojevi kreditnih kartica kupaca;
nakon odbijanja zahtjeva za plaćanjem, brojevi kreditnih kartica objavljeni na Internetu
 prosinac 2000 - Egghead.com - online prodaja - sumnja u krađu više od 3.5 miliona brojeva kreditnih
kartica; skupa istraga i gubitak kupaca dovodi do prestanka poslovanja, iako do upada nije došlo
 2001 - Bibliofind, ogranak Amazon.com specijaliziran za rijetke i out-of-print knjige - ukradene
informacije o gotovo 100 000 kreditnih kartica; napadači su imali pristup bazi podataka četiri mjeseca
prije nego što su otkriveni; Bibliofind se više ne bavi prodajom
 ožujak 2001 - FBI izvještava da je gotovo 50 banaka i maloprodajnih web stranica napadnuto i
kompromitirano od ruskih i ukrajinskih hakera
 studeni 2001 - Playboy.com - ukradene informacije o kreditnim karticama
 2001 - Indiana University - dva puta uspješno napadnut, ukradeni osobni podaci (social security
numbers i adrese)
 2002 - Evans Data provodi istraživanje tržišta - uključeno 750 kompanija, 10% baza podataka je imalo
sigurnosni incident u 2001; "neautorizirani pristup i kvarenje podataka" prijavilo je više od 40% banaka i
firmi koje pružaju financijske usluge, 8% firmi koje pružaju zdravstvenu zaštitu
 listopad 2004 - kompromitirana baza podataka s osjetljivim informacijama o više od 1,4 milijuna
stanovnika Kalifornije uključenih u In-Home Supportive Services (IHSS) program od 2001. Podaci su
bili korišteni u UC Berkeley studiji o kućnoj njezi (imena, adrese, SSN, datumi rođenja)
14 / 75
Primjeri narušavanja sigurnosti podataka (2)

 prosinac 2010 - Gawker Media - izgubljeno približno 1,5 milijuna zapisa o korisničkim računima - napad
je uslijedio nakon izjave o neprobojnosti njihove zaštite
 travanj 2011 - Epsilon Interactive (e-mail marketing) - krađa osobnih podataka milijuna kupaca (e-mail
adrese) za najmanje 50 klijenata, uključujući JPMorgan Chase, Capital One, Marriott Rewards, US Bank,
Citi, Ritz-Carlton Rewards, Walgreens, The College Board, Home Shopping Network
 2006-2009 - Federal Student Aid Division, Department of Education, Dolton, Ill - nelegalan pristup
National Student Loan Database System-u od strane zaposlenice
 rujan 2010 - TSS of San Juan (HMO koji djeluje pod upravom Puerto Rico’s health insurance plan) -
neotkriveni konkurent dobiva pristup bazi podataka TSS članica korištenjem važećih vjerodajnica -
izgubljeni osobni podaci među gotovo 400.000 kompromitiranih zapisa - kaznom od 100.000 dolara
 prosinac 2010 - Mesa County, Western Colorado Drug Task Force - 200.000 zapisa s imenima,
telefonskim brojevima i brojevima socijalnog osiguranja policijskih informatora (narkotici) dostupno na
Web-u - pogreška administratora sustava
 ožujak 2012 - Global Payments (posrednik za između trgovina i kartičnih kuća) - pogođeni MasterCard,
Visa, American Express i Discover Financial Services, banke - ukradeni podaci o 1,5 miliona računa
(neki izvori govore o 10 miliona kartica)

15 15 / 75
Sigurnost baze podataka (1)

 sigurnost baze podataka se osigurava zaštitom na nekoliko razina

 na razini SUBP
• spriječiti pristup bazama podataka ili onim dijelovima baza podataka za koje korisnici
nisu ovlašteni
 na razini operacijskog sustava
• spriječiti pristup radnoj memoriji računala ili datotekama u kojima SUBP pohranjuje
podatke
 na razini računalne mreže
• spriječiti presretanje poruka
 fizička zaštita
• zaštita lokacije poslužitelja sustava za upravljanje bazama podataka
 na razini korisnika
• spriječiti da ovlašteni korisnici bilo nepažnjom bilo namjerno omoguće neovlaštenim
osobama pristup podacima

16 / 75
Sigurnost baze podataka (2)

Defense-in-depth strategija
 zaštita u više slojeva
 ne postoji savršeni zaštitni sloj, metoda ili
proizvod
baza podataka
 proboj jednog sloja ne mora značiti i narušavanje
sigurnosti podataka iz baze podataka
SUBP
 nužna zaštita unutar baze podataka, čak i ako je
aplikacija
implementiran poseban sustav zaštite baze
OS
podataka izvan baze podataka
mreža

17 / 75
Sigurnost baze podataka (3)

 neki od postupaka kojima je bazu podataka moguće učiniti sigurnijom

 ograničiti pristup važnim resursima koji mogu biti pogrešno korišteni, zlonamjerno ili slučajno
kao posljedica pogreške - vatrozidi; kontrola pristupa; virtual private networks (VPN);
antivirusna zaštita
• upravljanje zakrpama (patches)
• sustavi za otkrivanje i sprječavanje upada (Intrusion prevention systems - IPS , Intrusion
detection systems - IDS)
 onemogućiti nepotrebne komponente i servise sustava za upravljanje bazama podataka (npr.
Oracle: XML FTP; SQL Server: Named Pipes access)
 ukloniti/onemogućiti nepotrebne pretpostavljene korisničke račune i lozinke
 izvoditi procese baze podataka pod namjenskim, neprivilegiranim korisničkim računom
 …

18 / 75
Načelo najmanje ovlasti i razdvajanje dužnosti

 načelo najmanje ovlasti (least privilege)

 korisnik ima minimalan skup dozvola koje su neophodne za njegov trenutni zadatak
 pojedinac ima različite razine ovlasti u različito vrijeme, ovisno o zadaći ili funkciji koju
obavlja
 spriječeno obavljanje nepotrebnih i moguće štetnih akcija

 razdvajanje dužnosti (separation of duty - SoD)

 osjetljive zadatke u cijelosti ne može obaviti samo jedan korisnik
 smanjuje se mogućnost zloporabe (važno načelo u financijskim i vojnim okruženjima)

19 / 75
Mehanizmi zaštite na razini SUBP

 identifikacija i dokazivanje autentičnosti

 kontrola pristupa
 šifriranje podataka
 praćenje pristupa podacima

 maskiranje podataka

20 / 75
 Integritet i 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 (tj. uvijek rezultiraju konzistentnim stanjem baze podataka)
• "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 definirana pravila koja korisnici ne smiju narušiti
• pravila se pohranjuju u rječnik podataka
 nezaobilazna su za sve korisnike
 ne opterećuju aplikacijske programe
• SUBP nadgleda rad korisnika i osigurava poštivanje pravila

21 / 75
Dokazivanje autentičnosti

 za dokazivanje autentičnosti korisnika SUBP može koristiti :

 vlastite mehanizme
 mehanizme operacijskog sustava
 posebne module (poseban sloj za upravljanje autentikacijom)

 pri uspostavljanju SQL-sjednice, korisnik se prijavljuje svojim identifikatorom korisnika (user

name, user ID, login ID) te lozinkom (password) ovjerava svoju autentičnost (authentication)
 funkcija CURRENT_USER vraća vrijednost identifikatora korisnika koji se koristi u dotičnoj
SQL-sjednici
• često se koristi i oblik USER (npr. Oracle)

SELECT FIRST 1 CURRENT_USER AS korisnik

FROM mjesto;

korisnik
novak

22 / 75
IBM Informix: Dokazivanje autentičnosti (1)

 interna autentikacija
 lozinka pohranjena u poslužitelju baze podataka (sysIntAuthUsers tablica sysUser baze
podataka) - šifrirana SHA-256 algoritmom (Secure Hash Algorithm)
 operacijski sustav
 posebni moduli (autentikacijski slojevi), npr:
 Pluggable Authentication Modules (PAM)
• za IBM Informix na UNIX i Linux OS
• API za upravljanje autentikacijom, korisničkim računima, sjednicama i lozinkama
 Lightweight Directory Access Protocol (LDAP) Authentication Support za Windows
• za autentikaciju korisnika koristi se LDAP poslužitelj

23 / 75
IBM Informix: Dokazivanje autentičnosti (2)

Održavanje korisnika poslužitelja baze podataka

 preslikavanje interno autenticiranih i vanjskih korisnika (PAM) na profil na razini OS
 ako izvođenje SQL naredbe zahtijeva interakciju poslužitelja baze podataka i OS pozivaju se
svojstva nadomjesnog OS korisnika na računalu-domaćinu poslužitelja baze podataka

 obavlja DBSA: CREATE

CREATE
DEFAULT USER
USER u1;
WITH PROPERTIES USER 'user_os';

CREATE USER u2 WITH PASSWORD 'u2pass';

CREATE USER u3 WITH PASSWORD 'u3pass' ACCOUNT LOCK;
CREATE USER u5 WITH PROPERTIES USER 'u5_os';

ALTER USER u3 MODIFY PASSWORD 'u3passNew';

ALTER USER u2 ACCOUNT LOCK;

RENAME USER u5 TO u5_1; DROP USER u1;

 obavlja korisnik: SET USER PASSWORD OLD 'u2pass' NEW 'u2passNew'

24 / 75
Oracle: Zaštita lozinki (1)

 automatsko i transparentno šifriranje lozinke prije slanja preko mreže; Advanced Encryption
Standard (AES)
 pohrana lozinki šifriranih SHA-1 algoritmom (Secure Hash Algorithm 1)
 provjera složenosti lozinke
 sprječavanje probijanja lozinke u slučaju višekratnih neuspjelih pokušaja prijave
 ograničavanje broja neuspješnih pokušaja prijave
 postepeno povećavanje vremena prije ponovnog pokušaja prijave - smanjenje broja
pokušaja
 isključivanje korisničkog računa
zadnja promjena prva prijava
istek
lozinke nakon perioda
lozinke
trajanja lozinke

period trajanja period

lozinke odgode isteka

25 / 75
Oracle: Zaštita lozinki (2)
 definiranje sigurnosnih profila
CREATE PROFILE obicniKorisnik LIMIT
FAILED_LOGIN_ATTEMPTS 5
PASSWORD_LOCK_TIME 2;
• isključenje korisničkog računa na dva
dana u slučaju pet neuspjelih pokušaja
prijave
 DEFAULT profil
 povezivanje profila s korisnikom
CREATE USER u1 IDENTIFIED BY "pass11!1"
PROFILE obicniKorisnik;
 zaključavanje korisničkog računa
ALTER USER u1 ACCOUNT LOCK;
Parametar
FAILED_LOGIN_ATTEMPTS - broj neuspješnih pokušaja prijave
prije zaključavanja korisničkog računa
PASSWORD_LIFE_TIME - trajanje lozinke (broj dana)
PASSWORD_LOCK_TIME - koliko je dana račun zaključan nakon
određenog broja uzastopnih neuspjelih pokušaja prijave
PASSWORD_GRACE_TIME - broj dana do isteka lozinke (period
odgode - dozvoljena prijava uz upozorenje)
PASSWORD_REUSE_TIME - mogućnost ponovnog korištenja iste
lozinke (u danima)
PASSWORD_REUSE_MAX - potreban broj promjena lozinke prije
ponovnog korištenja lozinke
PASSWORD_VERIFY_FUNCTION - funkcija za provjeru
složenosti lozinke
26 / 75
Kontrola pristupa
Kontrola pristupa

 niz postupaka kojima se utvrđuje i evidentira pokušaj pristupa, te odobrava ili odbija pristup na
temelju unaprijed utvrđenih pravila
 razvoj sustava za kontrolu pristupa - višefazni proces
 sigurnosna politika - pravila pristupa na visokoj razini
• temeljena na načelu treba-znati (need-to-know), kompetentnosti, nadležnosti, sukobu interesa…
• na nju mogu utjecati zakonska i etička pitanja, politike na državnoj ili korporativnoj razini …
• dinamična - mijenja se u skladu s promjenama poslovnih faktora, regulativa i uvjeta u okruženju
• problem preslikavanja nejasnih i dvosmislenih zahtjeva u dobro definirana i jednoznačna pravila
 sigurnosni model - formalni prikaz sigurnosne politike
• diskrecijska kontrola pristupa (discretionary access control - DAC)
• mandatna kontrola pristupa (mandatory access control - MAC)
• kontrola pristupa temeljena na ulogama (role-based access control - RBAC)
 sigurnosni mehanizam - funkcije kojima je implementirana kontrola pristupa

28 / 75
 Mehanizmi kontrole pristupa

 referentni monitor (reference monitor) - pouzdana komponenta koja kontrolira svaki pokušaj
pristupa objektu sustava i utvrđuje je li taj pristup u skladu sa sigurnosnom politikom utjelovljenom
u bazi podataka kontrole pristupa
 uspoređuje sigurnosne atribute korisnika (npr. identifikator korisnika, grupa kojoj korisnik
pripada, razina povjerenja iskazana korisniku) s onima koje imaju resursi (npr. oznaka
osjetljivosti)
Audit

 preduvjet: uspješna identifikacija i autentikacija korisnika file

Referentni
Subjekti Objekti
monitor

Baza podataka
kontrole pristupa

 autorizacija - postupak evidentiranja pravila pristupa

 informacije koje opisuju prava pristupa moraju biti zaštićene od izmjene
 sigurnosni mehanizmi implementirani kroz SQL

29 / 75
Elementi sustava za kontrolu pristupa

 korisnik – entitet koji koristi računalni sustav (osoba, uređaj)

 sjednica (session) - instanca dijaloga korisnika sa sustavom

 subjekt – aktivni entitet koji može inicirati zahtjev za obavljanje operacija na objektima
 proces koji djeluje u ime korisnika
 korisnik može imati više aktivnih subjekata

 objekt - entitet sustava na kojem može biti obavljena operacija

 operacija - aktivan proces pozvan od strane subjekta, koji nakon poziva izvršava funkcije
 dozvola (pravo pristupa, ovlast) određenog načina pristupa objektu u sustavu
 kombinacija objekta i operacije
• za omogućavanje izvođenja iste operacije (npr. SELECT) na dva različita objekta (npr.
tablice student i predmet) potrebne dvije dozvole
• za omogućavanje obavljanja dvaju različitih operacija (npr. UPDATE i SELECT) na istom
objektu (npr. tablici student) potrebne su dvije dozvole
 pozitivna dozvola - ako ne postoji, zatraženi pristup je odbijen
 negativna dozvola - ako postoji, zatraženi pristup je odbijen

30 / 75
Elementi sustava za kontrolu pristupa - dozvola
 klasični pristupi kontroli pristupa:
 zatvorena politika - dozvoljen pristup za koji postoji (pozitivna) dozvola
 otvorena politika - uskraćen pristup za koji postoji (negativna) dozvola
• ako dozvola ne postoji, pristup je dozvoljen

 problemi kod kombiniranog korištenja pozitivnih i negativnih dozvola:

 nepotpunost - za pristup nije specificirana dozvola
• može se izbjeći definiranjem pretpostavljene politike
 nekonzistentnost - za pristup postoji i negativna i pozitivna dozvola
• može se izbjeći definiranjem politike razrješavanja konflikata

 politike razrješavanja konflikata:

 nepostojanje konflikata – postojanje konflikta smatra se pogreškom
 prioritetne su negativne dozvole
 prioritetne su pozitivne dozvole
 ništa nema prioritet – istovremeno postojanje konfliktnih dozvola poništava te dozvole (kao da
nije specificirana nikakva dozvola)
31 / 75
Diskrecijska kontrola pristupa
Diskrecijska kontrola pristupa

 kontrola pristupa na temelju:

 identiteta korisnika koji zahtijeva pristup i
 eksplicitnih pravila pristupa koja utvrđuju tko može izvesti koje akcije na kojim objektom sustava

Način ograničavanja pristupa objektima na temelju identiteta subjekata i/ili grupa kojoj oni pripadaju.
Kontrole su diskrecijske u smislu da je subjekt s nekom dozvolom pristupa sposoban dati tu dozvolu
(možda indirektno) nekom drugom subjektu (osim ako to nije ograničeno s MAC-om).
[US Department of Defense, Trusted Computer Security Evaluation Criteria (TCSEC), DoD
5200.28-STD, 1985]

 koncept vlasništva nad objektom

 vlasnik objekta određuje kome se dozvoljava pristup

33 / 75
Matrica autorizacijskih pravila (Matrica pristupa)

 Lampson (1974); Harrison, Ruzzo i Ullmann - HRU model (1976)

 stanje sustava - trojka (S, O, A)
 stanje autorizacije predstavljeno matricom pristupa A
 stupci – objekti (o)
 retci – subjekti (s)
 element matrice – A[s, o] - ovlasti subjekta s na objektu o

 zahtjev (s,o,a) - pristup dozvoljen ako a postoji u elementu matrice za s i o

OBJEKTI
KORISNICI
Datoteka1 Datoteka2 Program1

u1 read, write read, write execute

u2 read

u3 read execute

34 / 75
System R model (1)

 1970-te - IBM San Jose

 objekti - tablice i pogledi
 dozvole - select, update, insert, delete, drop
 subjekt koji kreira tablicu – vlasnik (ima sve ovlasti nad tablicom)
 dozvola s mogućnošću prenošenja (GRANT opcija)
 subjekt kojemu je vlasnik dodijelio dozvolu može tu dozvolu dodijeliti drugim subjektima (bez
ili sa GRANT opcijom)
 ukidanje dozvola
 kaskadno, na temelju trenutka dodjeljivanja
 ukidaju se sve dozvole koje je dodijelio korisnik kojem se ukida dozvola, a koje ne bi mogle biti
dodijeljene bez postojanja dozvole koja se ukida
 ukidanje dozvola se iterativno primjenjuje na sve korisnike koji su primili dozvole pristupa od svih
korisnika s kojih je dozvola povučena
 zahtijeva pamćenje povijesti i vremena dodjeljivanja dozvola
35 / 75
System R model (2)
 autorizacijski graf - stanje autorizacije
 čvorovi - korisnici
 lûkovi - dodjeljivanje dozvole pristupa
 uz lûk je navedeno vrijeme dodjeljivanja dozvole te je li dozvola prenosiva
55,g  stanje nakon što korisnik u2 ukine
u6
20,g
u2
40,g 50,g
u5
ovlast koju je dodijelio korisniku u4:
u1 u4 80,g u2
u8 20,g
30,g 60,g 70,g u1 u4
u3 u7
30,g 60,g 70,g
u3 u7

 modifikacija System R modela:

 ne gleda se vremenski trenutak dobivanja dozvole – u2 u5
55,g
u6
kaskadno ukidanje uslijedit će ako korisnik više 20,g 40,g 50,g
nema dozvolu s mogućnošću prenošenja u1 u4 80,g
u8
 u4 i dalje ima dozvolu s mogućnošću
30,g
prenošenja koju je dobio od u3 i zadržane u3
60,g 70,g
u7
su sve dozvole koje je u4 dodijelio:

36 / 75
Diskrecijska kontrola pristupa u bazama podataka
 podržana SQL standardom
 podržana u većini današnjih SUBP
 određenom korisniku potrebno je eksplicitno dodijeliti dozvolu za obavljanje određene operacije
nad određenim objektom (autorizacija)
 dozvole su opisane trojkama <korisnik, objekt, vrsta operacije>, npr:
<horvat, ispit, čitanje>
<horvat, ispit, izmjena>
<novak, predmet, čitanje>
 podaci o dodijeljenim dozvolama pohranjuju se u rječnik podataka
 prije obavljanja svake operacije, SUBP provjerava ima li korisnik dozvolu za obavljanje operacije
nad objektom (kontrola pristupa)
 kada korisnik novak pokuša obaviti operaciju čitanja objekta (relacije) predmet, SUBP
provjerava postoji li dozvola u obliku trojke <novak, predmet, čitanje>
Diskrecijska kontrola pristupa
Ako postoji
Zahtjev za pristupom <s, o, p> Pristup dozvoljen
(s, o, p) tada
inače Pristup odbijen

37 / 75
Kontrola pristupa u SQL-u
 Mehanizmi kontrole pristupa
 naredbe za dodjeljivanje (GRANT) i ukidanje dozvola (REVOKE)
 virtualne relacije (view)
 pohranjene procedure
 modifikacija upita

 Objekti
 relacija (tablica, table)
 atribut (stupac tablice, column)
 virtualna relacija (pogled, view)
 pohranjena procedura
 baza podataka (neki sustavi, npr. IBM Informix)

 Vlasnik objekta - korisnik koji je kreirao objekt

 implicitno dobiva dozvole za obavljanje svih vrsta operacija nad objektom, uključujući
 dozvole za dodjeljivanje svih vrsta dozvola nad tim objektom drugim korisnicima i
 uništavanje objekta
38 / 75
IBM Informix: Dodjeljivanje i ukidanje dozvola

 na razini baze podataka: GRANT dbPrivilege TO { PUBLIC | userList }

REVOKE dbPrivilege FROM { PUBLIC | userList }

 na razini [virtualne] relacije:

GRANT tablePrivilegeList ON { tableName | viewName }
TO { PUBLIC | userList | roleList }
[ WITH GRANT OPTION ]

REVOKE tablePrivilegeList ON { tableName | viewName }

FROM { PUBLIC | userList | roleList }
[ CASCADE | RESTRICT ]

 dozvole za ostale vrste objekata biti će objašnjene naknadno

39 / 75
IBM Informix: Vrste dozvola na razini baze podataka
CONNECT  uspostavljanje SQL-sjednice i obavljanje operacija nad objektima za koje je
korisnik dobio dozvolu od vlasnika objekta ili je njihov vlasnik, kreiranje virtualnih i
privremenih relacija
RESOURCE  CONNECT + kreiranje novih objekata u bazi podataka (relacija, indeksa,
ograničenja, pohranjenih procedura …)
DBA  RESOURCE + neovisno o vlasništvu i dozvolama nad objektima u bazi podataka:
sve vrste operacija nad svim objektima, uništavanje svih objekata (uključujući i
bazu podataka)
 korisnik koji kreira bazu podataka je vlasnik te baze podataka i implicitno dobiva
DBA (Database administrator) dozvolu

Primjer:
DBA GRANT DBA TO u1;  nema učinka dodjeljivanje RESOURCE dozvole korisniku
GRANT RESOURCE TO u1; koji već ima DBA dozvolu - korisnik u1 i dalje ima DBA
dozvolu

REVOKE DBA FROM u1;  ukidanjem DBA dozvole, korisnik i dalje ima CONNECT dozvolu
REVOKE CONNECT FROM u1;  za sprečavanje uspostavljanja SQL-sjednice potrebno je ukinuti i
CONNECT dozvolu

40 / 75
IBM Informix: Vrste dozvola na razini [virtualne] relacije

SELECT [(columnList)]  čitanje n-torki (ili vrijednosti navedenih atributa) [virtualne] relacije
UPDATE [(columnList)]  izmjena n-torki (ili vrijednosti navedenih atributa) [virtualne] relacije
INSERT  unos n-torki [virtualne] relacije
DELETE  brisanje n-torki [virtualne] relacije
REFERENCES [(columnList)]  korištenje relacije (ili samo navedenih atributa) kao pozivane
relacije pri definiranju stranog ključa)
INDEX  kreiranje indeksa nad relacijom
ALTER  izmjena strukture relacije i definiranje integritetskih ograničenja
ALL PRIVILEGES  sve vrste operacija nad [virtualnom] relacijom

UPDATE nastavnik SET koef = 0.9*koef

Primjer:
WHERE NOT EXISTS
(SELECT * FROM predmetGrupa
WHERE predmetGrupa.sifNastavnik = nastavnik.sifNastavnik
AND predmetGrupa.akGodina = 2011);
Potrebne dozvole:  pristup bazi podataka
 SELECT: nastavnik.sifNastavnik, nastavnik.koef , predmetGrupa.sifNastavnik, predmetGrupa.akGodina
 UPDATE: nastavnik.koef

41 / 75
"korisnik" PUBLIC

 dodjelom dozvole "korisniku" PUBLIC, dozvolu za obavljanje operacije dobivaju svi

sadašnji i budući korisnici
 to ne znači dodijeliti pojedinačne dozvole svakom od korisnika koji se nalazi u nekom
trenutno postojećem, konačnom skupu korisnika

 Primjer: pretpostavlja se da za relaciju stud do sada nije dodijeljena niti jedna dozvola.
Korisnicima horvat, novak, kolar, petrak, treba dodijeliti CONNECT dozvolu, te svim navedenim
korisnicima osim novaku dodijeliti dozvolu za pregled relacije stud. Pogrešno je rješenje:
GRANT CONNECT TO horvat, novak, kolar, petrak;
GRANT SELECT ON stud TO PUBLIC;
-- uočite: prethodna naredba nije isto što i
-- GRANT SELECT on stud TO horvat, novak, kolar, petrak
REVOKE SELECT ON stud FROM novak;

 svaki korisnik (sadašnji ili budući, uključujući korisnika novak) koji uspostavi SQL-sjednicu s bazom
podataka (uz prethodnu ovjeru autentičnosti) može obavljati operaciju SELECT nad relacijom mjesto
 Ispravno rješenje: GRANT CONNECT TO horvat, novak, kolar, petrak;
GRANT SELECT ON stud TO horvat, kolar, petrak;

42 / 75
Dodjeljivanje prenosivih dozvola
 opcija WITH GRANT OPTION - korisnik kojem je dozvola dodijeljena uz navođenje te opcije,
može tu dozvolu dodjeljivati ostalim korisnicima (unatoč tome što nije vlasnik objekta)
Primjer:
CREATE TABLE ispit (...);
korisnik1 GRANT SELECT ON ispit TO korisnik2 WITH GRANT OPTION;
GRANT SELECT ON ispit TO korisnik3 WITH GRANT OPTION;
GRANT SELECT ON ispit TO korisnik4 WITH GRANT OPTION;
korisnik2
GRANT SELECT ON ispit TO korisnik5;

korisnik4 GRANT SELECT ON ispit TO korisnik6;

korisnik1 GRANT SELECT ON ispit TO korisnik5;

WGO WGO
korisnik2 korisnik4 korisnik6
vlasnik
korisnik1 korisnik5 WGO: WITH GRANT OPTION
WGO
korisnik3
 WITH GRANT OPTION omogućava širenje dozvola bez znanja vlasnika relacije
 ograničavanje širenja dozvola (horizontalno i vertikalno) nije dio SQL standarda
43 / 75
IBM Informix: Ukidanje dozvola (1)
 dozvolu može ukinuti
 korisnik koji je dozvolu dodijelio
 vlasnik objekta ili korisnik s DBA dozvolom u ime korisnika koji ju je dodijelio (AS dio
REVOKE naredbe)
 vlasniku objekta nije moguće ukinuti dozvole nad objektom
Primjer:  vlasnik baze podataka studAdmin je korisnik bpadmin
 vlasnik relacije mjesto je korisnik horvat

horvat GRANT SELECT, UPDATE ON mjesto TO novak WITH GRANT OPTION;

novak GRANT SELECT, UPDATE ON mjesto TO kolar;

 naredbu: REVOKE UPDATE ON mjesto FROM kolar;

može obaviti korisnik novak jer je novak korisnik koji je dodijelio dozvolu korisniku kolar
 naredbu: REVOKE UPDATE ON mjesto FROM kolar AS novak;

mogu obaviti korisnici horvat i bpamin

44 / 75
IBM Informix: Ukidanje dozvola (2)
 ukidanje dozvole korisniku k1 uz primjenu opcije:
 CASCADE - dozvola se ukida i svim ostalim korisnicima koji su dotičnu dozvolu stekli od
korisnika k1 (neposredno ili posredno) - pretpostavljena opcija
 RESTRICT - dozvola će biti ukinuta jedino ako korisnik k1 nije dalje dodjeljivao ovlasti
temeljem ovlasti stečene pomoću WITH GRANT OPTION
Primjer: korisnik1 REVOKE SELECT ON ispit FROM korisnik2 CASCADE;

WGO WGO
korisnik2 korisnik4 korisnik6

korisnik1 korisnik5
WGO
 dozvolu gube korisnik2, korisnik4 i korisnik6
korisnik3  korisnik5 gubi dozvolu dobivenu od korisnika2, ali
zadržava dozvolu dobivenu od korisnika1

 da je u naredbi bila korištena opcija RESTRICT, SUBP bi odbio obaviti naredbu (bila bi
dojavljena pogreška)

45 / 75
IBM Informix: Dodjeljivanje i ukidanje dozvola - primjer (1)

 korisnik bpadmin mora kreirati bazu podataka studAdmin i relacije student i ispit, te dodijeliti
dozvole korisnicima:
horvat  kreiranje novih objekata (kako bi mogao kreirati relaciju zupanija)
 pregled svih podataka u relacijama student i ispit
 unos, izmjena, brisanje svih podataka u relaciji ispit
novak  pregled svih podataka u relaciji student
 izmjena poštanskog broja i adrese u relaciji student
kolar  pregled svih podataka u relaciji student, osim adrese
STUDENT= {matBr, ime, prez, pbr, adresa}
bpadmin  naredbe obavlja korisnik bpadmin
CREATE DATABASE studAdmin ... ; GRANT SELECT ON student TO horvat;
CREATE TABLE student (...);
GRANT SELECT, INSERT, UPDATE, DELETE
CREATE TABLE ispit (...);
ON ispit TO horvat;
GRANT RESOURCE TO horvat;
GRANT SELECT ON student TO novak;
GRANT CONNECT TO novak;
GRANT CONNECT TO kolar; GRANT UPDATE(pbr, adresa) ON student TO novak;
GRANT SELECT(matBr, ime, prez, pbr)
ON student TO kolar;
46 / 75
IBM Informix: Dodjeljivanje i ukidanje dozvola - primjer (2)
horvat CREATE TABLE zupanija (…)
GRANT SELECT, INSERT, UPDATE
ON zupanija TO novak;
novak SELECT * FROM zupanija;
INSERT INTO zupanija ...;
UPDATE zupanija ...;
DROP TABLE zupanija;
kolar SELECT * FROM zupanija;
horvat GRANT CONNECT TO kolar;
bpadmin
GRANT DBA TO horvat;
horvat GRANT RESOURCE TO novak;
REVOKE DBA FROM bpadmin;
novak CREATE TABLE mjesto (...
REFERENCES zupanija ...);
horvat GRANT REFERENCES
ON zupanija TO novak;
može jer ima RESOURCE dozvolu
može jer je vlasnik relacije zupanija
može jer ima barem CONNECT dozvolu te dozvole koje je
dobio od vlasnika relacije zupanija
ne može jer nije vlasnik objekta niti ima DBA dozvolu
ne može jer nema SELECT dozvolu za relaciju zupanija
ne može jer nema DBA dozvolu
može jer ima DBA dozvolu (dosadašnja RESOURCE
dozvola korisnika horvat je promovirana u DBA dozvolu)
može jer ima DBA dozvolu
ne može jer je bpadmin vlasnik baze
ne može jer nema dozvolu za kreiranje stranog ključa koji se
poziva na primarni ključ relacije zupanija (mogao bi kreirati
relaciju bez stranog ključa jer ima RESOURCE dozvolu)
može jer ima DBA dozvolu i vlasnik je relacije zupanija
47 / 75
IBM Informix: specifično ponašanje
 nakon kreiranja relacije automatski se korisniku PUBLIC dodjeljuju SELECT, INSERT, UPDATE
i DELETE dozvole nad tom relacijom - ako je vrijednost env. varijable NODEFDAC=no
CREATE TABLE stud (...);
REVOKE ALL ON stud FROM PUBLIC;

 ne postoji oblik REVOKE naredbe kojom je moguće ukinuti dozvolu nad pojedinim atributima
relacije
 Primjer: korisniku horvat treba za relaciju stud dodijeliti dozvolu za pregled svih atributa
osim datuma rođenja. Pogrešno rješenje je:
GRANT SELECT ON stud TO horvat;
REVOKE SELECT(datRod) ON stud FROM horvat;

 Ispravno rješenje: GRANT SELECT ( mbrStud, imeStud, prezStud, pbrRod

, pbrStan, jmbgStud )
ON stud TO horvat;

 ne postoji oblik REVOKE naredbe kojom je moguće prenosivu dozvolu preinačiti u neprenosivu
dozvolu (REVOKE GRANT OPTION)
48 / 75
ORACLE: kategorije dozvola

 dozvole se mogu svrstati u dvije općenite kategorije:

 sistemske dozvole
 omogućavaju izvršavanje različitih tipova naredbi
 ne odnose se na neki konkretni objekt baze podataka, već na određenu operaciju ili klasu
operacija nad tipom objekta
 neke od sistemskih dozvola su: CREATE USER; ALTER USER; DROP USER; CREATE
SESSION; CREATE ANY INDEX; ALTER ANY INDEX; DROP ANY INDEKS; CREATE TABLE;
CREATE ANY TABLE; ALTER ANY TABLE; DELETE ANY TABLE; DROP ANY TABLE; INSERT
ANY TABLE; SELECT ANY TABLE; UPDATE ANY TABLE; CREATE VIEW; CREATE ANY
VIEW; DROP ANY VIEW; CREATE PROCEDURE; CREATE ANY PROCEDURE; EXECUTE ANY
PROCEDURE …

GRANT CREATE SESSION TO u1;  korisniku u1 dozvoljeno je uspostavljanje SQL-sjednice

 dozvole nad objektima

 omogućavaju obavljanje određenih operacija na određenom objektu baze podataka
• npr. SELECT, UPDATE, INSERT i DELETE operacije na tablicama, ALTER,
REFERENCES, INDEX i ALL na tablicama, EXECUTE na pohranjenim procedurama
49 / 75
SQL Server: kategorije dozvola

 administrator korisniku treba omogućiti pristup instanci SQL Server poslužitelja (CREATE
LOGIN naredbom) te pristup bazi podataka (CREATE USER naredbom), npr:
CREATE LOGIN loginNameU1 WITH PASSWORD = 'ABCxyz' MUST_CHANGE;
USE stuSluBaza;
CREATE USER u1 FOR LOGIN loginNameU1;

 dozvole se mogu svrstati u dvije općenite kategorije:

• dozvole obavljanja naredbi – kontroliraju obavljanje naredbi kao što su CREATE TABLE,
CREATE VIEW, CREATE FUNCTION, CREATE PROCEDURE, itd.
• dozvole nad objektima baze podataka – kontroliraju obavljanje operacije na postojećem
objektu baze podataka, npr. DELETE, INSERT, SELECT, UPDATE, EXECUTE,
REFERENCES …

50 / 75
SQL Server: negativne dozvole (1)

 osim dodjeljivanja dozvole pristupa (GRANT), omogućeno je postavljanje zabrane, odnosno

dodjeljivanje negativne dozvole (DENY)
 REVOKE ukida dozvole dodijeljene GRANT i DENY naredbama
DENY CREATE TABLE TO u1;  korisniku u1 zabranjuje se izvođenje CREATE TABLE naredbe
REVOKE CREATE TABLE FROM u1;  korisniku u1 ukida se zabrana izvođenja CREATE TABLE naredbe
DENY SELECT (jmbg) ON student TO u1;  korisniku u1 zabranjuje se izvođenje SELECT naredbe
nad atributom student.jmbg
REVOKE SELECT (jmbg) ON student TO u1;  korisniku u1 ukida se zabrana izvođenja SELECT
naredbe nad atributom student.jmbg
 konflikti koji se pojavljuju zbog u2
postojanja negativnih dozvola (1)
SELECT
stud
razrješavaju se u skladu s u1 + • blokirane su (nisu uklonjene):
SELECT
politikom prioritetne su stud (2)
─ (4) • pozitivna dozvola koju je
negativne dozvole: + u3 u4 u1 dodijelio korisniku u3
(3)
SELECT SELECT • pozitivna dozvola koju je
stud + stud
u3 dodijelio korisniku u4
51 / 75
Kontrola pristupa ovisna o sadržaju i kontekstu

 kontrola pristupa ovisna o sadržaju (content-dependent, value-dependent, data-

dependent)
 pristup objektu na temelju sadržaja jedne ili više njegovih komponenata
 kontrola pristupa ovisna o kontekstu (context-dependent, system-dependent)
 pristup objektu ovisi o trenutnom kontekstu - u obzir uzima predikate sustava (vrijeme,
lokacija …), trenutnog korisnika

 dva načina implementacije kontrole pristupa ovisne o sadržaju i kontekstu:

 definiranje virtualnih relacija koje odabiru objekt čiji sadržaj zadovoljava dani uvjet te
dodjeljivanje dozvola na virtualne tablice, umjesto na temeljne tablice
 podržano u svim komercijalnim SUBP- ovima

 povezivanje predikata (ili logičke kombinacije predikata) s autorizacijama

 predikat izražava uvjet nad sadržajem objekta koji mora biti zadovoljen kako bi pristup
bio dozvoljen
 podržan u Oracle SUBP-u

52 / 75
Virtualna relacija (view)
 shema i sadržaj virtualne relacije definirani su izrazom relacijske algebre čiji su operandi
temeljne ili virtualne relacije
 opisuju se u obliku SQL upita - naredbom CREATE VIEW
 u rječniku podataka pohranjena je definicija virtualne relacije
 sadržaj virtualne relacije uvijek odražava sadržaj temeljnih relacija u trenutku izvršavanja
upita u kojem se virtualna relacija koristi
polozeniIspit
CREATE VIEW prosjek (sifPred prosjek
mbr sifPred ocj , prosOcj) AS
100 1001 5 SELECT sifPred, AVG(ocj) sifPred prosOcj
101 1001 4 FROM polozeniIspit 1001 4.00
102 1001 3 GROUP BY sifPred; 1002 3.50
100 1002 2 1003 3.00
101 1002 5
100 1003 3
SELECT MIN(prosOcj) AS minPros
101 1003 3 , MAX(prosOcj) AS maksPros minPros maksPros
FROM prosjek; 3.00 4.00

53 / 75
Implementacija virtualnih relacija

 izvršavanje upita koji sadrže virtualne relacije:

 modifikacija upita
 SUBP ugrađuje elemente definicije virtualne relacije u originalni SQL upit koji koristi
virtualnu relaciju - umjesto originalnog SQL upita izvršava se modificirani SQL upit
 sadržaj virtualne relacije se određuje tek za vrijeme izvršavanja upita koji koristi virtualnu
relaciju

 korištenje materijalizirane virtualne relacije

 SUBP fizički pohranjuje sadržaj virtualne relacije
 promjenom sadržaja neke od temeljnih relacija pomoću kojih je virtualna relacija
definirana, SUBP automatski mijenja i sadržaj materijalizirane virtualne relacije
 prednost: sadržaj virtualne relacije koja se često koristi, a čiji se sadržaj određuje
složenim upitima, ne mora izračunavati prilikom svakog korištenja virtualne relacije
 nedostatak: ako se često mijenja stanje temeljne relacije pomoću koje je virtualna
relacija definirana, troši se dodatno vrijeme radi izmjene sadržaja virtualne relacije
54 / 75
Implementacija virtualnih relacija modifikacijom uputa

ispit stud
 Primjer: mbr predmet ocj mbr ime prez pbrStan
100 Elektronika 3 100 Ivan Kolar 52100
100 Fizika 3 101 Ana Horvat 42230
101 Elektronika 5 102 Jura Novak 52100
101 Fizika 2
studenti koji su položili predmet Fizika
102 Fizika 1
CREATE VIEW polFiz AS
SELECT stud.*, ocj
FROM ispit, stud
korisnik obavlja: WHERE ispit.mbr = stud.mbr
SELECT * FROM polFiz; AND predmet = 'Fizika'
AND ocj > 1;
SUBP modificira upit

SELECT stud.*, ocj

FROM ispit, stud
WHERE ispit.mbr = stud.mbr mbr ime prez pbrStan ocj
AND predmet = 'Fizika' 100 Ivan Kolar 52100 3
AND ocj > 1;
101 Ana Horvat 42230 2

55 / 75
Virtualna relacija: INSERT, UPDATE, DELETE

 obavljanjem INSERT, UPDATE i DELETE naredbi nad virtualnom relacijom mijenja se sadržaj
temeljnih relacija koje se koriste u definiciji te virtualne relacije (SUBP modificira naredbu)
 izmjenjiva (updatable) virtualna relacija - mora biti definirana tako da SUBP može jednoznačno
odrediti koje operacije treba obaviti na temeljnim relacijama
 u glavnom SELECT dijelu definicije virtualne relacije koristi atribute iz samo jedne temeljne
relacije r(R) i pri tome:
• ne sadrži eliminaciju duplikata pomoću DISTINCT
• ne sadrži izraze u listi za selekciju (osim trivijalnih izraza koji sadrže samo ime atributa)
• izostavljeni atributi ne smiju imati NOT NULL ograničenje ili moraju imati pretpostavljenu
(default) vrijednost
• ne sadrži spajanje ili uniju
• ne sadrži grupiranje i postavljanje uvjeta nad grupom (GROUP BY i HAVING)
 navedena ograničenja se ne odnose na podupite unutar WHERE dijela SELECT naredbe

 WITH CHECK OPTION - opcija CREATE VIEW naredbe - nije dozvoljena izmjena ili unos n-torke
putem virtualne relacije ako n-torka nakon obavljanja operacije više ne bi pripadala virtualnoj
relaciji putem koje je izmijenjena ili unesena
56 / 75
Primjena virtualnih relacija u provođenju sigurnosne politike

 omogućavaju prikaz samo informacija koje su korisniku potrebne:

 zbirne informacije i/ili samo neke atribute relacije i/ili samo neke n-torke iz relacije
 korisniku se dodjeljuju ovlasti nad virtualnom relacijom

 ovlasti dobivene pomoću virtualne relacije mogu biti:

 neovisne o vrijednostima - virtualna relacija sadrži samo neke atribute svih zapisa u
temeljnoj relaciji CREATE VIEW studOP (jmbag, imeStudent, prezStudent) AS
SELECT jmbag, imeStudent, prezStudent
FROM student

 ovisne o vrijednostima - virtualna relacija sadrži samo neke n-torke iz temeljne relacije
CREATE VIEW studFER (jmbag, imeStudent, prezStudent) AS
SELECT jmbag, imeStudent, prezStudent
FROM student
WHERE matOrgJed = 'FER'

 kontekstno ovisne - u definiciji virtualne relacije, kao uvjet dohvata koristi se informacija
vezana uz kontekst prilikom izvođenja upita (korisnik, vrijeme izvođenja upita)
57 / 75
Dodjeljivanje kontekstno ovisnih dozvola
Primjer: ispit nast
mbrSt sifPred datIsp ocj sifNast imeN prezN userId
 vlasnik relacija je korisnik horvat
100 100 1.5.2004 3 1001 Slavko Kolar kolar
 svakom nastavniku (korisnicima kolar, … … … … … … … …
ban, novak) omogućiti pregled i izmjenu
predaje
ispita samo iz predmeta koje predaju
sifNast sifPred
LOŠE RJEŠENJE! 1001 100
horvat … …
CREATE VIEW kolarIspiti AS  ponoviti za svakog nastavnika:
SELECT * FROM ispit
WHERE sifPred IN (SELECT sifPred FROM predaje banIspiti, novakIspiti, ...
WHERE sifNast = 1001)  svaki nastavnik upit nad relacijom
WITH CHECK OPTION;
ispit mora pisati na drugačiji način
GRANT SELECT, UPDATE ON kolarIspiti TO kolar;
ISPRAVNO RJEŠENJE!
CREATE VIEW ispitiZaNastavnike AS  "sadržaj" virtualne
SELECT * FROM ispit relacije ovisit će o
WHERE sifPred IN (SELECT sifPred FROM predaje, nast
WHERE predaje.sifNast = nast.sifNast
identifikatoru nastavnika
AND userId = USER) WITH CHECK OPTION; koji je ostvario SQL-
GRANT SELECT, UPDATE ON ispitiZaNastavnike TO kolar, ban, novak; sjednicu
58 / 75
Implementacija eksternih shema pomoću virtualnih relacija

 konceptualna shema: baza podataka u banci

klijent uplataIsplata racun

jmbg ime prez brRac vrijeme valuta iznos brRac jmbgVl tipRac datRac
123456 Ana Horvat 1004 5.5.2007 16:42 HRK 1200.00 1004 123654 kunski 8.9.2005
… … … … … … … … … … …

 za različite aplikacije (kategorije korisnika) definiraju se različite eksterne sheme

• otvaranje računa: klijent, racun
• kunsku uplatu/isplatu: kunRacun, kunUplIspl
• pregled trenutačnog stanja sredstava u banci: pregledStanja

CREATE VIEW pregledStanja CREATE VIEW kunUplIspl AS

CREATE VIEW kunRacun AS (valuta, ukupno) AS SELECT * FROM uplataIsplata
SELECT * FROM racun SELECT valuta, SUM(iznos) WHERE valuta = 'HRK'
WHERE tipRac = 'kunski' FROM uplataIsplata WITH CHECK OPTION;
WITH CHECK OPTION; GROUP BY valuta;

59 / 75
Vlasnik virtualne relacije

 korisnik koji kreira virtualnu relaciju :

 postaje vlasnik virtualne relacije
 za uspješno kreiranje virtualne relacije mora imati dozvolu obavljanja SELECT naredbe za
svaku relaciju uključenu u definiciju virtualne relacije
 ovlasti nad tom virtualnom relacijom ovise o njegovim ovlastima nad korištenim objektima:
• uvijek ima SELECT dozvolu
• prenosivu SELECT dozvolu (s GRANT opcijom) ima samo ako ima prenosivu SELECT
dozvolu za svaku korištenu tablicu
• za izmjenjivu virtualnu relaciju bitne su njegove INSERT, DELETE ili UPDATE dozvole
nad tablicom na čije se zapise kroz virtualnu relaciju utječe - automatski dobiva jednake
dozvole i na tom pogledu

60 / 75
Oracle Virtual Private Database (VPD)

 Row Level Security (RLS), Fine Grained Access Control (FGAC)

 implementacija kontrole pristupa ovisne o sadržaju i kontekstu povezivanjem predikata s
dozvolama
 predikat izražava uvjet nad sadržajem objekta koji mora biti zadovoljen da bi pristup bio
dozvoljen
 navedeni uvjet automatski se dodaje u WHERE dio SQL naredbe koju je potrebno obaviti na
[virtualnoj] tablici na koju se primjenjuje VPD sigurnosna politika
 alternativa korištenju virtualne tablice

 hoće li zapisi biti vidljivi korisniku ovisi o informacijama koje čuvaju

 umjesto skrivanja cijelog zapisa moguće je maskirati samo osjetljive podatke (vrijednosti samo
nekih atributa u zapisu)
 ne može se zaobići - svaki upit koristi definiranu politiku koja uključuje korištenu tablicu

61 / 75
Oracle Virtual Private Database - primjer (1)
zaposlenik sifra ime odjel placa
Primjer: (koristi se shema u_admin)
1 Osoba1 1 3000
 korisniku u1 omogućiti pregled svih zaposlenika
2 Osoba2 1 5000
 korisniku u2 omogućiti pregled zaposlenika uz odjela 1 3 Osoba3 2 3500
 korisniku u3 omogućiti pregled zaposlenika uz odjela 2 4 Osoba4 2 4500

CREATE USER u1 IDENTIFIED BY jzolzv;

 dodjeljivanje potrebnih dozvola korisnicima CREATE USER u2 IDENTIFIED BY utivrvi;
u1, u2 i u3: CREATE USER u3 IDENTIFIED BY p1Q276v;
GRANT CREATE SESSION TO u1,u2,u3;
GRANT SELECT ON u_admin.zaposlenik TO u1,u2,u3;

 definiranje politike pristupa i korištene

CREATE FUNCTION placeZaposlenika
pohranjene procedure:
BEGIN
DBMS_RLS.ADD_POLICY (
object_schema => 'u_admin',
object_name => 'zaposlenik',
policy_name => 'placeZaposlenika',
policy_function => 'placeZaposlenika',
statement_types => 'SELECT');
END;
(v_shema VARCHAR2, v_objekt VARCHAR2)
RETURN VARCHAR2 IS
BEGIN
CASE SYS_CONTEXT('userenv', 'session_user')
WHEN 'U1' THEN RETURN NULL;
WHEN 'U2' THEN RETURN 'odjel=1';
WHEN 'U3' THEN RETURN 'odjel=2';
ELSE RETURN '1=2';
END CASE;
END;

62 / 75
Oracle Virtual Private Database - primjer (2)
 korisnici u1, u2 i u3 obavljaju upit: zaposlenik sifra ime odjel placa
1 Osoba1 1 3000
SELECT * FROM u_admin.zaposlenik
2 Osoba2 1 5000

SUBP modificira upit 3 Osoba3 2 3500

4 Osoba4 2 4500
"pogledi" korisnika u1, u2 i u3 na tablicu zaposlenik
u1: vidi sve n-torke relacije zaposlenik u3:
u2: SELECT * SELECT *
FROM u_admin.zaposlenik FROM u_admin.zaposlenik
WHERE odjel=1; WHERE odjel=2;

sifra ime odjel placa sifra ime odjel placa

1 Osoba1 1 3000 3 Osoba3 2 3500
2 Osoba2 1 5000 4 Osoba4 2 4500

63 / 75
 Oracle Virtual Private Database - primjer (3)
 dodatni zahtjev: korisnici u1, u2 i u3 smiju vidjeti samo plaće manje od 4000
 definiranje politike pristupa i potrebne pohranjene procedure :
BEGIN CREATE FUNCTION sakrijPlace
SYS.DBMS_RLS.ADD_POLICY ( (v_shema VARCHAR2, v_objekt VARCHAR2)
object_schema => 'u_admin', RETURN VARCHAR2 IS
object_name => 'zaposlenik', BEGIN
policy_name => 'sakrivanjePlaca', RETURN 'placa < 4000';
policy_function => 'sakrijPlace', END;
sec_relevant_cols => 'placa',
sec_relevant_cols_opt => DBMS_RLS.ALL_ROWS);
END; zaposlenik

 korisnici u1, u2 i u3 obavljaju upit: sifra ime odjel placa

1 Osoba1 1 3000
SELECT * FROM u_admin.zaposlenik
2 Osoba2 1 5000
 "pogledi" korisnika u1, u2 i u3 na tablicu zaposlenik 3 Osoba3 2 3500
4 Osoba4 2 4500
u1: sifra ime odjel placa
1 Osoba1 1 3000 u2: sifra ime odjel placa u3: sifra ime odjel placa
2 Osoba2 1 NULL 1 Osoba1 1 3000 3 Osoba3 2 3500
3 Osoba3 2 3500 2 Osoba2 1 NULL 4 Osoba4 2 NULL
4 Osoba4 2 NULL

64 / 75
Pohranjene procedure/funkcije (1)

 pohranjena procedura/funkcija je potprogram koji je pohranjen u rječniku podataka i koji se

izvršava u kontekstu sustava za upravljanje bazama podataka
 procedura je potprogram koji u pozivajući program ne vraća rezultat
 funkcija je potprogram koji u pozivajući program vraća rezultat
 koristi se i termin pohranjena rutina (stored routine)

 može biti implementirana kao:

 SQL procedura - napisana u SQL-u
• (napomena: u nastavku se pod pojmom procedura misli na SQL proceduru)
 vanjska procedura (external routine)
• napisana u eksternom programskom jeziku (npr. Java, C++)
• poziva se na isti način kao SQL procedura

65 / 75
Pohranjene procedure/funkcije (2)
 pohranjena je kao objekt u rječniku baze podataka
 izvorni kôd procedure
 "izvršni" kôd - unaprijed preveden i optimiran kôd procedure
• postiže se veća učinkovitost SUBP

 proizvođači SUBP koriste vlastite inačice jezika za definiranje pohranjenih procedura (standard
postoji, ali je rijetko gdje implementiran)
 IBM Informix: SPL (Stored Procedure Language)
 Oracle: PL/SQL (Procedural Language/Structured Query Language)
 Microsoft SQL Server: Transact-SQL

 proširuju mogućnosti SQL jezika proceduralnim elementima koji se koriste u strukturiranim jezicima
(C, Java, ...). Osim SQL naredbi, moguće je korištenje varijabli, naredbi za kontrolu toka programa (if,
for, while, ...), naredbi za rukovanje iznimkama (exception handling) …
 postiže se veća produktivnost programera i smanjuje mogućnost pogreške
 programski kôd potreban za obavljanje nekog postupka koji čini logičku cjelinu implementira se i
testira na samo jednom mjestu

66 / 75
 Primjena pohranjenih procedura u provođenju sigurnosne politike

 SQL omogućuje zaštitu podataka od neovlaštene uporabe na razini objekata (relacije, atributi,
virtualne relacije)
 korisniku se može ograničiti pristup do pojedinih objekata i vrsta operacije koju nad tim
objektima može obaviti (brisanje, izmjena, unos, dohvat)
 nije moguće ograničiti način na koji će korisnik obavljati operacije za koje je dobio dozvolu

 pohranjena procedura omogućuje zaštitu podataka od neovlaštene uporabe na razini funkcija

 korisniku se pridijeli dozvola za obavljanje definirane procedure, umjesto dozvole za pristup
podacima
 time je precizno određen način na koji korisnik smije obaviti operacije nad podacima
• primjena dozvola u skladu s poslovnim pravilima ugrađenim u proceduru
• princip najmanje ovlasti

CREATE PROCEDURE prijaviIspit (JMBAG CHAR(12), sifPred INTEGER, datumRok DATE)

EXECUTE PROCEDURE obaviProvjereUzPrijavu (JMBAG, sifPred, datumRok);
EXECUTE PROCEDURE odrediRbrIzlaz (JMBAG, sifPred, datumRok) INTO rbrIzlaz;
INSERT INTO ispit VALUES (JMBAG, sifPred, datumRok, rbrIzlaz);
END PROCEDURE;

67 / 75
Dozvole za pohranjene procedure/funkcije

 SQL naredbe za dodjeljivanje i ukidanje dozvola za izvršavanje procedura

GRANT EXECUTE ON {procName | funName}
TO {PUBLIC | userList | roleList}
[WITH GRANT OPTION]

REVOKE EXECUTE ON {procName | funName}

FROM {PUBLIC | userList | roleList}
[ CASCADE | RESTRICT ]

68 / 75
IBM Informix: SPL - Primjer

 Korisnik novak je službenik u banci kojem je potrebno omogućiti obavljanje isključivo jedne
vrste bankovne transakcije: prebacivanje iznosa s jednog na drugi račun
racun brRacun stanje CREATE PROCEDURE prebaci (saRacunaBr LIKE racun.brRacun
1001 1250.15 , naRacunBr LIKE racun.brRacun
, iznos LIKE racun.stanje)
1002 -300.00
-- provjeri postoje li zadani brojevi računa
1003 10.25 IF (SELECT COUNT(*) FROM racun
WHERE brRacun = saRacunaBr) = 0 THEN
 zadatak se ne može riješiti RAISE EXCEPTION -746, 0, 'Ne postoji prvi račun';
dodjelom dozvole za obavljanje END IF
IF (SELECT COUNT(*) FROM racun
operacije UPDATE nad relacijom WHERE brRacun = naRacunBr) = 0 THEN
racun korisniku novak (zašto?) RAISE EXCEPTION -746, 0, 'Ne postoji drugi račun';
END IF
-- prenesi zadani iznos
novak UPDATE racun SET stanje = stanje - iznos
WHERE brRacun = saRacunaBr;
UPDATE racun UPDATE racun SET stanje = stanje + iznos
SET stanje = stanje - 60.30 WHERE brRacun = naRacunBr;
WHERE brRacun = 1001; END PROCEDURE;
[Error] No UPDATE permission GRANT EXECUTE ON prebaci TO novak;

EXECUTE PROCEDURE prebaci (1001, 1002, 60.30);  promjene su obavljene

69 / 75
IBM Informix: procedure i zaštita od neovlaštenog pristupa

 sa stanovišta zaštite od neovlaštenog pristupa, postoje dvije vrste pohranjenih procedura:

A. owner privileged procedura CREATE PROCEDURE imeVlasnika.imeProc ()

CREATE PROCEDURE imeProc ()

→ vlasnik je korisnik koji kreira proceduru
• korisnik mora imati barem RESOURCE dozvolu na razini baze podataka da bi u njoj
mogao kreirati owner privileged proceduru

B. DBA privileged procedura CREATE DBA PROCEDURE imeProc ()

• korisnik mora imati DBA dozvolu na razini baze podataka da bi mogao kreirati DBA
privileged proceduru

 o vrsti procedure, razlikuju se odgovori na sljedeća pitanja:

• tko smije koristiti (obavljati) proceduru ?
• koje ovlasti nad objektima baze podataka ima procedura za vrijeme obavljanja ?
70 / 75
IBM Informix: Tko smije obavljati proceduru?
• dozvolu za obavljanje može se pojedinom korisniku dodijeliti naredbom GRANT EXECUTE, a
oduzeti naredbom REVOKE EXECUTE

A. owner privileged procedura

• o vrijednosti env. varijable (NODEFDAC = no) ovisi hoće li nakon kreiranja procedure inicijalno
biti dodijeljena EXECUTE dozvola za PUBLIC
B. DBA privileged procedura
• inicijalno samo korisnici koji imaju DBA dozvolu imaju dozvolu za obavljanje DBA procedure.

Primjer: korisnik kolar kreira proceduru procx i želi korisniku petrak (koji nema DBA dozvolu)
dozvoliti izvođenje procedure (uz NODEFDAC = no):
CREATE PROCEDURE procx ()
... CREATE DBA PROCEDURE procx ()
END PROCEDURE; ...
END PROCEDURE;
REVOKE EXECUTE ON procx FROM PUBLIC; GRANT EXECUTE ON procx TO petrak;
GRANT EXECUTE ON procx TO petrak;

71 / 75
IBM Informix: Ovlasti procedure za vrijeme izvođenja (1)
A. owner privileged procedura
• procedura koristi sve ovlasti:
• korisnika koji je proceduru pokrenuo i
• ovlasti koje ima vlasnik procedure, za koje vlasnik procedure ima dozvolu za prenošenje
(WITH GRANT)
kolar
Primjer: tabA - novak ima dozvolu CREATE PROCEDURE procx ()
koristi tabA, tabB, tabC
tabB - kolar ima dozvolu WITH GRANT END PROCEDURE;
tabC - kolar ima dozvolu REVOKE EXECUTE ON procx FROM PUBLIC;
GRANT EXECUTE ON procx TO novak;
novak
EXECUTE PROCEDURE procx () • procedura uspješno koristi tabA jer novak ima "svoju" dozvolu
• procedura uspješno koristi tabB jer vlasnik procedure kolar
ima prenosivu dozvolu, koja se privremeno prenosi na novaka
• procedura ne može koristiti tabC, jer novak nema dozvolu, a
dozvola koju ima vlasnik procedure kolar nije prenosiva
72 / 75
IBM Informix: Ovlasti procedure za vrijeme izvođenja (2)

B. DBA privileged procedura

• procedura za vrijeme obavljanja ima ovlasti DBA

Primjer: tabA - novak ima dozvolu horvat

CREATE DBA PROCEDURE procx ()
tabB - novak nema dozvolu koristi tabA, tabB
END PROCEDURE;
GRANT EXECUTE ON procx TO novak;
novak
EXECUTE PROCEDURE procx () • procedura uspješno koristi tabA i tabB jer novak za vrijeme
obavljanja procedure privremeno dobije DBA dozvolu
Dodatna razmatranja: što bi se dogodilo kada bi DBA horvat kreirao user privileged proceduru procx?
• vlasnik procedure je DBA, a DBA ima sve ovlasti nad svim objektima u bazi s dozvolom za
prenošenje (WITH GRANT)
• korisnik procedure za vrijeme obavljanja procedure stječe sva prava nad korištenim objektima koje
vlasnik procedure posjeduje s WITH GRANT opcijom → horvat je proceduru mogao kreirati i kao
user privileged proceduru
• čemu onda služi DBA procedura ?
73 / 75
IBM Informix: Ovlasti procedure za vrijeme izvođenja (3)

Dodatna razmatranja-nastavak: čemu onda služi DBA procedura ?

Procedura ne mora nužno biti u vlasništvu korisnika koji ju je kreirao. Postavljanje vlasnika se
obavlja za vrijeme kreiranja procedure.

horvat CREATE DBA PROCEDURE kolar.procx()

koristi tabA, tabB
• DBA horvat kreira DBA proceduru kojoj je
END PROCEDURE; vlasnik kolar (koji nije DBA)
kolar GRANT EXECUTE ON procx TO novak;

novak EXECUTE PROCEDURE procx(); • novak će bez smetnji moći obaviti proceduru bez
obzira na svoje dozvole nad tabA i tabB
 ako horvat umjesto DBA procedure, kreira user privileged proceduru kojoj je vlasnik kolar,
novak za njeno uspješno obavljanje:
• mora imati vlastite dozvole za tabA i tabB, ili
• vlasnik procedure kolar mora imati dozvole s mogućnošću prenošenja za tabA i tabB

74 / 75
Oracle: Ovlasti procedure za vrijeme izvođenja

• ovlasti vlasnika procedure (definer-rights procedure) - pretpostavljena opcija

CREATE PROCEDURE procA() AUTHID DEFINER …

• ovlasti korisnika koji je proceduru pokrenuo (invoker-rights procedure)

CREATE PROCEDURE procB() AUTHID CURRENT_USER …
Primjer:
u1: create table tab1 (d varchar2(40));
insert into tab1 values ('korisnik u1');
grant select on tab1 to u2; create procedure p2 authid definer
create table tab2 (d varchar2(40)); as p_d tab2.d%type;
insert into tab2 values ('korisnik u1'); begin
create procedure p1 authid current_user as select d into p_d from tab2;
p_d tab1.d%type; dbms_output.put_line(p_d);
begin end;
select d into p_d from tab1;
grant execute on p1 to u2;
dbms_output.put_line(p_d);
grant execute on p2 to u2;
end;

create table tab1 (d varchar2(40));

u2: insert into tab1 values ('korisnik u2');
begin u1.p1; end; → korisnik u2
create table tab2 (d varchar2(40));
insert into tab2 values ('korisnik u2'); begin u1.p2; end; → korisnik u1
75 / 75