MRR - Kriptografska Zaštita Baza Podataka

Fakultet za informatiku i menadment
Univerzitet Singidunum Beograd
Kriptografska zatita baza podataka

Magistarski rad
Mentor:
Prof. dr Mladen Veinovi, dipl. in.
Kandidat:
Slobodan Damjanovi, dipl. in.
Beograd, maj 2010. godine
Damjanovi , S. 2010. Kriptografska zatita baza podataka
Sadraj:
1. METODOLOGIJA ISTRAIVA KOG RADA.............................................................................................4
2. BAZE PODATAKA I BEZBEDNOST STANDARDNI MEHANIZMI.....................................................8

2.1.
2.2.
2.3.
POVERLJIVOST...................................................................................................................................10
INTEGRITET .......................................................................................................................................12
RASPOLOIVOST................................................................................................................................13
3. ZAKONSKA REGULATIVA .........................................................................................................................14

SARBANES - OKSLI, ODELJAK 404 .....................................................................................................16
PHI, HIPAA......................................................................................................................................19
PCI....................................................................................................................................................23
GRAMM-LEACHY BLILEY ..................................................................................................................25
SB 1386 ............................................................................................................................................27
BASEL II ..........................................................................................................................................29
OSTALE REGULATIVNE MOGU NOSTI ................................................................................................32
NAJBOLJE PRAKSE KADA JE RE O TEHNOLOGIJI I TEHNICI ................................................................33
ZAKJU AK .........................................................................................................................................35
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
3.7.
3.8.
3.9.
4. NAPADI NA BAZE PODATAKA ..................................................................................................................37

ZLOUPOTREBA PRETERANE PRIVILEGIJE ............................................................................................37
ZLOUPOTREBA LEGITIMNE PRIVILEGIJE .............................................................................................38
UVE ANJE PRIVILEGIJE .....................................................................................................................39
RANJIVE TA KE NA PLATFORMI.........................................................................................................39
UBRIZGAVANJE SQL-A .....................................................................................................................40
SLABA KONTROLA DNEVNIKA AKTIVNOSTI .......................................................................................41
ODBIJANJE PRUANJA USLUGE ..........................................................................................................43
KOMUNIKACIONI PROTOKOLI U BAZI PODATAKA...............................................................................44
SLABA AUTENTIKACIJA .....................................................................................................................44
OTKRIVANJE PODATAKA IZ ARHIVE ...................................................................................................45
ZAKLJU AK .......................................................................................................................................45
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
4.8.
4.9.
4.10.
4.11.
5. KRIPTOGRAFSKA ARHITEKTURA..........................................................................................................46
OSNOVE ARHITEKTURE .....................................................................................................................46
KRIPTOGRAFSKI KLJU EVI ................................................................................................................48
PREDLOG REENJA ............................................................................................................................58
ZAKLJU AK .......................................................................................................................................61
5.1.
5.2.
5.3.
5.4.
6. PRIKAZ POSTOJE IH REENJA ZATITE ............................................................................................62
6.1.
6.2.
6.3.
6.4.
6.5.
ORACLE .............................................................................................................................................62
IBM DB2 ..........................................................................................................................................71
MICROSOFT SQL SERVER .................................................................................................................74
MYSQL.............................................................................................................................................93
POSTGRESQL....................................................................................................................................96
7. PRIKAZ SLU AJA .......................................................................................................................................102
7.1.
7.2.
7.3.
MOTIVACIJA ....................................................................................................................................102
PRIKAZ REENJA REALIZACIJE NA ODABRANOM DBMS-U ..............................................................104
REZULTATI ......................................................................................................................................112
8. ZAKLJU AK .................................................................................................................................................115
9. LITERATURA ...............................................................................................................................................116
10.
SPISAK SLIKA .......................................................................................................................................117
11.
SPISAK TABELA ...................................................................................................................................118
12.
PRILOZI..................................................................................................................................................119
Univerzitet Singidunum Beograd, Fakultet za informatiku i menadment
Apstrakt:
Potrebe za zatitom baza podataka su sve vee, posebno u sadanje doba e-trgovine. Zahtevi
za korienjem kriptografskih reenja stiu od strane drave u vidu zakona a od strane
poslovnih partnera u vidi poslovih pravila. U prvom delu rada prikazani su neki od dravnih
zakona i pravila strukovnih udruenja koji eksplicitno trae korienje kriptografije radi
zatite podataka. Spremajui se za odbranu podataka potrebno je upoznati neprijatelja. Dat
je prikaz najeih napada na baze podaka i metode za odbranu. Polazne osnove za
kriptografsku zatitu su date u vidu prikaza ugraenih kriptografskih reenja u trenutno,
vodeim bazama podataka. Veina prikazanih reenja ne poseduje mogunost upravljanja
kriptografskim kljuevima, pa je u nastavku rada predloen jedan model upravljanja
kljuevima. Predloeno reenje je generiko, te omoguuje korienje mnogih simetrinih
ifarskih sistema. Otpor prema uvoenju kriptografije u ve postojee baze podataka lei u
injenici da je potrebno vriti izmene samih baza ali i aplikacija jer se ifrovanjem menja
veliina i tip polaznih podataka. Prikazane su kriptografske tehnike kojima se ne menja
format ifrovanih podataka.
Klju ne re i: bezbednost baza podataka, kriptografija, upravljanje klju evima
Abstract:
The requirements for data protection are increasingly greater, especially nowadays at the time
of e-business. Demands for application of the cryptographic solutions are pouring in from a
state in the form of laws and also from business partners in the form of business rules. In the
first part of the paper some of the state laws have been presented as well as various rules of
some professional associations that explicitly call for the application of cryptography for data
protection. While preparing for data protection it is necessary to get acquainted with an
adversary. The review of the most frequent attacks on the data bases and the protection
methods has been presented. The initial elements for cryptographic protection have been
introduced in the form of a survey of the implemented cryptographic solutions in the main
data bases. Most of the presented solutions lack the capability of managing the cryptographic
keys, so that in the subsequent part of the paper a model of the key management has been
suggested. The proposed solution is generic, so that it enables the application of a variety of
symmetrical cipher systems. Unwillingness to implement cryptography into existing data
bases lies in the fact that it is necessary to make changes within the data bases themselves but
also within the very applications since by introducing ciphering the size and type of the initial
data are also being changed. The cryptographic techniques that do not have impact on the
format of the ciphered data have been shown.
Key words: database security, cryptography, key management
1. METODOLOGIJA ISTRAIVAKOG RADA

1.1. Uvodne napomene i obrazloenje rada
Kompjuteri i tehnologije su postali sastavni deo drutva, a njihova svakodnevna
upotreba se ne dovodi u pitanje. U modernim dravama, celokupna infrastruktura je
automatizovana do odreenog stepena, inei da se svakodnevne ivotne aktivnosti odvijaju
bre i lake. Upravo se u takvom nainu ivota krije i najvea ranjivost. Prestanak protoka
informacija na kritinoj infrastrukturi, bilo da je re o prirodnoj katastrofi ili o napadu koji je
proizveo pojedinac ili grupa, moe dravu da dovede do kamenog doba. Upravo zbog toga se
u doktrinarnim dokumentima, vodeih vojnih i ekonomskih sila, akcenat stavlja na zatitu
najvanijih infrastrukturnih segmenata, a posebno sledeih:
Informacija i komunikacija
Bankarstva i finansija
Energije, ukljuujui elektrinu energiju, naftu i gas i
Transportnog sistema [1].
Ovde je vano uoiti redosled kojim su nabrojani infrastrukturni segmenti. Informacije i
komunikacije imaju vrhunski prioritet. Isto tako kao to drava titi informatiku
infrastrukturu, tako i privatne kompanije stavljaju akcenat na zatitu informacija. Savremeno
poslovanje je nezamislivo bez komunikacija i baza podataka. Baze podataka predstavljaju
izvor informacija za veinu aplikacija koje pomau u obavljanju primarnih aktivnosti svakog
poslovanja. irenjem trita, a samim tim i razvojem organizacija, bez obzira da li su one
dravne ili privatne, uoena je primena sistema baza podataka kao kljune tehnologije za
upravljanje podacima i pomonog sredstva za donoenje odluka.
Strukturu rada, pored metodolokog pristupa, ini est meusobno povezanih delova.
U drugom poglavlju opisani su standardni sigurnosni mehanizmi koji se odnose na baze
podataka.
U treem poglavlju je opisano stanje u zakonodavstvu, ekonomski razvijenih zemalja,
po pitanju zatite podataka. Detaljno je pokriveno est relevantnih zakona, a ostala etiri samo
uvodno. Za svaki zakon je dat pregled sa programerske take gledita, potrebni koraci u
procesu razvoja proizvoda, kao i strategije i tehnike, radi ispunjenja zahteva postavljenih
zakonom. Strategije i tehnike su odvojene u pet glavnih kategorija: poverljivost, integritet,
dostupnost, kontrola i evidencija i provera identiteta.
U etvrtom poglavlju prikazano je deset najeih napada na baze podataka, zajedno sa

predlogom za spreavanjem napada.
U petom poglavlju je opisana kriptografska arhitektura na visokom nivou. Najvei deo
poglavlja razmatra karkteristike kljueva, jer bezbednost kriptosistema u najveoj meri zavisi
od bezbednosti i paljivog rukovanja ovim kljuevima. Posle analize osobina kriptografskih
kljueva i njihove uloge u sistemu, predloen je fiziki model baze podataka za podrku
kriptografskoj zatiti podataka u bazi.
U estom poglavlju su opisana postojea reenja zatite u vodeim komercijalnim
bazama podataka: Oracle, IBM DB2 i Microsoft SQL Server; kao i u bazama otvorenog koda:
MySQL i PostgreSQL. U nekim proizvodima je samo omogueno korienje kriptografskih
primitiva u vidu funkcija, a drugim je izgraena hijerarhija kljueva zajedno sa mehanizmima
za njihovo upravljanje.
U sedmom poglavlju je opisan ifarski mehanizam, koji proizvodi ifrat u istom formatu
kao i otvoreni tekst. Naime, ifrovanjem podataka menja se njihov format i veliina prostora
za njihov smetaj, pa ifrovanje podataka moe zahtevati znaajne izmene u postojeim
bazama i aplikacijama. Prikazana su etiri algoritma koja uvaju format podataka. Vrena su
merenja performansi predloenih reenja zatite podataka sa ouvanjem formata.
1.2. Predmet istraivanja
U ovom radu bie istraena primena kriptografije kao jednog od elemenata zatite
podataka u sistemima baza podataka. Naime, uvanjem podataka u otvorenom obliku,
osetljivi podaci mogu biti ranjivi na napade, kako spolja tako i iz same organizacije. Bez
ozbzira na preduzete mere, uvek e postojati jo jedan od naina da se do podataka doe na
nedozvoljen nain. Da bi se predupredio gubitak podataka, preporuuje se kriptografska
zatita podataka. Analizom postojeih softverskih i hardverskih kriptografskih elemenata koji
su danas na raspolaganju potrebno je utvrditi u kom su stepenu primenljivi na zatitu podataka
u bazama.
1.3. Ciljevi istraivanja

Na osnovu izloene argumentacije, cilj ovog istraivanja je da se ispitaju kriptografske
mogunosti zatite baza podataka, imajui u vidu softverske i hardverske proizvode, koji su
danas na raspolaganju.
Teorijski cilj istraivanja podrazumeva uspostavljanje teorijskih okvira za razvoj
kriptografskih mehanizama u bazama podataka, odnosno definisanje pojmova koji se tiu
bezbednosne politike, vieslojne zatite podataka i zatite u bazama podataka.
Aplikativni cilj istraivanja podrazumeva dizajniranje i testiranje bezbednosnih
mehanizama definisanih teorijskim okvirom, na odabranom primeru baze podataka i analizu
tako dobijenih rezultata.
Krajnji cilj je nalaenje to efikasnijeg i funkcionalnijeg reenja u realizaciji primene
kriptografskih mehanizama. Prilikom iznalaenja reenja, potrebno je odrati balans imeu
fleksibilnosti i modularnosti sistema sa jedne strane i bezbednosti sistema sa druge strane.
1.4. Hipotetiki okvir
Opta hipoteza
Uzimajui u obzir kompleksnost problema i predmeta istraivanja, mogue je postaviti
optu hipotezu da je primena kriptografskih mehanizama najbolje bezbednosno reenje, koje
se mora kombinovati sa klasinim bezbednosnim mehanizmima na bazi kontrole pristupa i
privilegija. Takvu hipotezu potvruju brojni brojni argumenti, meu kojima treba posebno
istai izvetaje o bezbednosnim provalama u baze podatake koje su bile zatiene samo
klasinim mehanizmima zatite kontrole pristupa, zasnovanim na modelu privilegija.
Radna hipoteza
Drugi vaan i specifian parametar savremene zatite baza podataka je upravljanje
kriptolokim kljuevima. Naime, na tritu se nalaze proizvodi koji nude prostu
funkcionalnost ifrovanja i deifrovanja podataka, to je samo manji (jednostavniji) deo
reenja zatite baza podataka. Radna hipoteza se odnosi na dokazivanje da centralno mesto,
kvaliteta i upotrebljivosti ifarskog sistema, pripada upravljanju kriptografskim kljuevima.
1.5. Metode i tehnike istraivanja
U ovom istraivakom radu, pored standardnih logikih metoda indukcije, dedukcije i
apstrakcije, primenjene su razliite nauno-istraivake metode:
metoda analize i sinteze,

statistike metode,
metoda komparacije,
analiza sluaja i
eksperimenta.
Metoda analize i sinteze: U radu je analizirana celina, koja predstavlja informacioni
sistem neke kompanije, a koji se najee nalazi u vidu troslojne arhitekture, rastavljen na
svoje elemente - prezentacioni sloj, aplikacioni sloj i sloj baze podataka. U takvom sistemu
analiziran je i ispitivan uticaj pojedinih elemenata, na celokupnu bezbednost podataka, u
sluaju izbora tog elementa za mesto uvanja kriptolokih parametara, odnosno, za izvoenje
kriptolokih operacija. Sistematizacijom znanja i sintezom rezultata analize, dolo se do
efikasnog i funkcionalnog reenja primene kriptografskih mehanizama.
Statistike metode: U radi su korieni statistiki podaci vodeih svetskih organizacija,
koje se bave prikupljanjem i objavljivanjem podataka o incidentima, koji se tiu baza
podataka. Ovi dokumenti se obino objavljuju na kvartalnom nivou, a prikazuju incidente po
tipu podatka koji je kompromitovan, sektoru u kome se incident dogodio (vladine
organizacije, vojska, zdravstvo, obrazovanje i privreda) i samoj vrsti incidenta (rashodovana
oprema, kraa, izgubljena oprema, web, virus i sl.). Analizom ovih podataka dolo se do
najzastupljenijih napada na baze podataka.
Metod komparacije: U cilju sagledavanja mogunosti upotrebe ugraenih kriptolokih
mehanizama u postojeim bazama podataka, primenjena je komparacija postojeih reenja.
Analiza sluaja: Otpor uvoenju kriptografskih metoda ogleda se u injenici da se
kriptografskim mehanizmima menja tip podatka, koji se smeta u bazu podataka, to na kraju
zahteva i izmene na aplikativnom nivou. Analiziran je i prikazan sluaj u kome je potrebno
ouvati tip podatka kako bi uticaj na aplikativni sloj bio to manji.
Eksperiment: U analizi sluaja koriena su tri metoda, kojim je mogue obezbediti
ouvanje formata podataka, a performanse svakog od tih metoda merene su
eksperimentalnom tehnikom.
2. Baze podataka i bezbednost standardni mehanizmi

Bezbednost baza podataka predstavlja sistem procesa i postupaka kojima se titi baza
podataka od neeljenih aktivnosti. Pod neeljenom aktivnou se moe ukljuiti zloupotreba
legalnog korisnika, zlonamerni napad, ili greka izazvana nepanjom a koju je nainio legalni
korisnik ili proces. Takoe, bezbednost baza podataka je specijalnost unutar discipline
raunarske bezbednosti. Tradicionalno, baze podataka su bile zatiene od spoljnih veza
mrenom barijerom (engl. firewall) ili usmerivaem (engl. router), na prilazu mrei (engl.
network perimeter), gde se baza podataka nalazila na internoj mrei a ne unutar
demilitarizovane zone. Dodatni mreni sigurnosni ureaji koji otkrivaju i upozoravaju na
zlonamerni saobraaj koji se odvija ka i od baze podataka ukljuuju mrene sisteme za
detekciju upada zajedno sa serverskim sistemima za detekciju upada.
Bezbednost baza podataka je postala vanija kako su mrene komunikacije postale
rairenije i otvorenije. Baze podataka pruaju vie nivoa i tipova informacione bezbednosti,
uobiajeno sadranih u reniku podataka same baze, ukljuujui:
Kontrolu pristupa,
Reviziju,
Preveru identiteta,
ifrovanje,
Kontrolu integriteta
Bezbednost baza podataka moe poeti sa procesom stvaranja i izdavanja odgovarajuih
bezbednosnih standarda koji e da vae za relevantne baze podataka. Standardi mogu da
ukljue specifina pravila za razliite baze podataka, skup principa najbolje prakse, a koji se
ne odnose na konkretnu platformu; kao i povezivanje standarda na viem nivou sa pravilima i
zakonskom regulativom. Vaan postupak kod procene bezbednosti baze podataka je postupak
procene ranjivosti. Procena ranjivosti je postupak kojim se pokuavaju pronai slabe take,
koje se mogu iskoristiti i izvesti neeljena aktivnost u bazi podataka. Administratori baza
podataka ili administratori bezbednosti u bazi, pokreu automatske testove radi otkrivanja
slabo (pogreno) konfigurisanih baza podataka. Takoe, stalnim praenjem bezbednosnih
ojaanja baze podataka za koju su zadueni, uklanjaju poznate slabe take i na taj nain
ublauju pretnju koji po bazu podataka ine napadai. Program stalnog nadgledanja
usklaenosti sa bezbednosnim standardima u bazama podataka je vaan zadatak za baze
podataka koje su od presudne vanosti za poslovanje neke organizacije. Dva presudna aspekta
ouvanja bezbednosti baze podataka su upravljanje ispravkama softvera (engl. patch
management), kao i upravljanje i pregled ovlaenja koja su dodeljena objektima unutar baze
podataka (posebno javnih ovlaenja). Ovlaenja koja su data SQL naredbama za rad sa
objektima unutar baze podataka takoe se razmatraju u ovom procesu. Treba napomenuti da
su proces nadgledanja pridravanja pravila i procena ugroenosti slini procesi s kljunom
razlikom da rezultati procene ugroenosti dovode do bezbednosnih standarda koji kasnije
uvode program kontinuiranog nadgledanja. U osnovi, procena rizika je preliminarna aktivnost
gde se utvruje rizik, a program nadgledanja usklaenosti sa pravilima postupak koji se odvija
u procesu procene rizika. Program usklaenosti sa pravilima treba da uzme u obzir zavisnosti
koje postoje na aplikativnom nivou, poto promene na nivou baze podataka mogu imati uticaj
na aplikativni softver ili na aplikativni server. U direktnoj vezi sa ovom tematikom je i
bezbednost aplikacija. Mehanizme provere identiteta i autorizaciju unutar aplikacije treba
uzeti kao efikasno sredstvo za obezbeenje nivoa apstrakcije kojim se aplikacija odvaja od
baze podataka. Glavna prednost apstrakcije je mogunost prijave korisnika na jednom mestu u
sistemu sa vie platformi i baza podataka. Sistem koji dozvoljava prijavu na jednom mestu
treba da uva akreditive korisnika prijavnu identifikaciju i lozinku, a kasnije u ime korisnika
da te akreditive predoi bazi podataka.
Jo jedan bezbednosni sloj, sofisticiranije prirode, ukljuuje nadgledanje mrenog
saobraaja i to onog dela koji se odnosi na protokol baze podataka, kao i nadgledanje
aktivnosti baze podataka koju prouzrokuju softverski agenti. Analiza se moe sprovesti na
transportnom delu radi pronalaska poznatih napada, ili na mrenom delu, s vremene na vreme,
hvatati saobraaj, kako bi se uoili normalni obrasci ponaanja a blokirao saobraaj u sluaju
odstupanja od unapred definisanog obrasca ponaanja, to bi moglo da oznaava poetak
napada. Ovi sistemi, slue da dotatno ojaaju kontrolne mehanizme pored ve poznatih
sistema za detekciji i prevenciju upada u sistem.
Osim alata za nadgledanje i evidenciju koji se nalaze van BP, veina BP poseduju
ugraene mehanizme za evidenciju. Ugraeni sistem evidencije u BP se u pravilnim
vremenskim intervalima preuzima, prebaciju na bezbedni sistem na kome administrator baze
podataka nema pristup. Ovaj mehanizam obezbeuje podelu odgovornosti, koja garantuje da
evidencija, koju je pravila BP automatski, nije menjana od strane administratora BP.
Uopteno govorei, sistem evidencije koju prua baza podataka ne prua dovoljno
mehanizama za podelu odgovornosti, tako da je potreban modul za nadgledanje koji je
mrenog ili serverskog tipa i koji prua vii stepen poverenja u mogunost nadgledanja i
ouvanja digitalnih dokaza.
Nakon to se incident dogodi, korienje forenzike baze podataka je potrebno da bi se
odredio obim nastale tete. Sistem za nadgledanje bezbednosti u BP treba da ukljui redovne
preglede naloga kao i pripadajuuh privilegija kako obinih korisnika tako i privilegija koje
su date automatskim procesima. Lozinke za naloge kojima se slue automatski procesi treba
da budu zatiene odgovarajuim mehanizmima kao to je ifrovanje i kontrola pristupa, a sve
radi smanjenja rizika od kompromitovanja. Za naloge pojedinaca, sistem za proveru identiteta

bi trebalo da bude dvostruk, jedan na novou operativnog sistema a drugi na nivou BP.
U sprezi sa kvalitetnim planom za zatitu BP, potrebno je da postoji i odgovarajui plan
za oporavak, kako bi se osigurali da servis nije prekinut tokom bezbednosnog incidenta ili
incidenta druge vrste a koji rezultuje prekid rada BP. Na primer, repliku BP treba uvati na
lokaciji koja je geografski udaljena od primarne lokacije.
2.1. Poverljivost
Poverljivost je obezbeenje da je informacija dostupna samo onima koji imaju ovlateni
pristup dotinoj informaciji. Procedure za ouvanje poverljivosti moraju da budu paljivo
implementirane. Kljuni aspekti poverljivosti su korisnika identifikacija i autentikacija.
Pouzdana identifikacija korisnika sistema je nuna radi osiguranja efektivnosti politika koje
odreuju koji korisnici imaju pravo pristupa pojedinim podacima. Poverljivost moe biti
naruena na vie naina. Najee pretnje po poverljivost su:
Hakerisanje
Haker je osoba koja ima znanje, sposobnosti i elje da u potpunosti neovlaeno koristi
tue kompjuterske i komunikacione sisteme, na nain da iskoritava bezbednosne slabosti
koje postoje u tim sistemima. [3]
Punim pristupom serveru baze podataka, napada je u stanju da na svoj raunar prebaci
celokupnu bazu podataka. Posle tog trenutka, moe na miru da pregledava bazu, bilo sa
alatima za pretraivanje teksta, ili da podatke jednostavno ukljui u svoj server baze podataka
i da gleda podatke kao i ostali legitimni korisnici.
Veina organizacija se oslanja na mehanizme kontrole pristupa kako bi zatitili podatke.
U ovom sluaju kontrola pristupa nije dovoljna jer je je napada ve doao do podataka. Jedna
od slabosti u pogledu naruavanja poverljivosti je i injenica da je administrator baza
podataka u stanju da pregledava podatke.
Maskiranje
Maskiranje je proces kojim ovlateni korisnik pristupa sistemu, ali pomou lozinki
drugih korisnika. Na taj nain pristupa datotekama kojima inae nema pristup. Maskiranje je
esta pojava u organizacijama gde vie korisnika deli istu lozinku.
Neovlatena korisnika aktivnost

Ovaj tip aktivnosti se pojavljuje kad autorizovani korisnik dobije pristup datotekama
kojima nema pravo pristupa. Slabe kontrole pristupa esto omoguuju pristup
10
neautorizovanim korisnicima koji mogu kompromitovati poverljive podatke. Organizacije se

esto sreu sa problemom kratkih rokova zbog kojih esto u rad stavljaju baze podataka koje
nisu do kraja testiranje. Radi kasnijeg (u hodu), testiranja i ispravki greaka, u bazi podataka
se ostavljaju zadnja vrata (engl. backdoor) koja koriste programerima, testerima i ostalim
lanovima tima da koriste bazu. Kako se podaci ne bi sluajno obrisali ili izmenili esto su ovi
nalozi pasivni - namenjeni samo za itanje (engl. read-only accounts). Nije teko pretpostaviti
ta se deava kad neko iz tima postane zlonameran. Situacija slina ovoj je i ona kada se u
razvoju koriste odvojene baze za razvoj, testiranje i produkciju. Produkcione baze podataka
imaju jau kontrolu pristupa dok je kontrola pristupa bazama namenjenim za razvoj i
testiranje slabija. Ovakav model je dobar sve do onog momenta dok se produkciona baza sa
podacima ne kopira u bazu namenjenu za razvoj i/ili testiranje. [5]
Nezatieno preuzimanje (engl. download) datoteka

Preuzimanje datoteka moe kompromitovati poverljive informacije, ako za vreme
procesa preuzimanja, datoteke budu preneene iz sigurnog okruenja u nesigurno okruenje, u
kojem poverljivim datotekama mogu pristupiti neovlateni korisnici.
Lokalne mree (engl. local area networks)

Lokalne mree predstavljaju posebnu pretnju poverljivosti informacija jer podaci koji
putuju mreom mogu biti kompromitovani u svakom voru mree. Kao odbrana od ove vrste
pretnje mogu se upotrebiti kriptografski protokoli: transport layer security (TLS) kao i
prethodnik secure sockets layer (SSL), koji obezbeuju zatien prenos podataka izmeu
uesnika. [4]
Kompjuterski trojanci
Trojanci - zlonamerni programi (engl. malware, malicious software) u formi korisnih
programa, koji kopiraju (izmeu ostalog) poverljive datoteke u neovlatena podruja sistema,
ukoliko korisnik koji ima pravo pristupa tim datotekama, ne znajui, izvri takav program.
Modeli poverljivosti opisuju akcije koje je potrebno preduzeti da bi se osigurala
poverljivost informacija. Najee koriten model poverljivosti je Bell-La Padula model1 koji
definie odnose izmeu objekata (npr. datoteke, programi, informacioni sistem) i subjekata
(npr. ljudi, procesi). Veze izmeu subjekata i objekata opisane su nivoima pristupa subjekata
objektima koji imaju svoju slojevitu osjetljivost.
Bell-LaPadula model (skra eno BLP) je model automata kojim se obezbe uje kontrola pristupa u vladinim i
vojnim aplikacijama. Model su razvili David Elliott Bell i Leonard J. La Padula pod mentorstvom Roger R
Shell-a, radi formalizacije vieslojnih polisa bezbednosti Ameri kog ministarstva odbrane.
11
Model kontrole pristupa koji sistem deli na objekte, subjekte i operacije je isto esto
koriten model poverljivosti. Model ima definisana pravila koja opisuju koje operacije nad
objektima mogu izvoditi pojedini subjekti.
2.2. Integritet
Integritet - zatita postojanja, tanosti i kompletnosti informacije kao i procesnih
metoda. Potrebno je obezbediti da podaci kojima pristupaju autorizovani korisnici budu
celoviti. Sigurnosne mere ne mogu obezbediti tanost podataka koje korisnici smetaju u baze
podataka, ali mogu obezbediti da se promene nad podacima izvode na ispravan nain. Dodatni
zahtev je obezbediti zatitu procesa i programa kojima se obavlja manipulacija podacima od
neovlatene modifikacije. Potrebno je obezbediti da nijedan korisnik ne moe izvesti
modifikaciju podataka koja moe uzrokovati oteenje ili gubitak sadraja. Kao i kod
poverljivosti, identifikacija i autentikacija korisnika su kljuni elementi politike ouvanja
integriteta. Integritet se takoe moe kompromitovati hakerisanjem, maskiranjem,
neautorizovanim korisnikom aktivnou, nezatienim preuzimanjem datoteka, lokalnim
mreama, trojancima, virusima i sl. Tri su bazina principa uspostave kontrola integriteta:
Dodela samo nunih prava pristupa (engl. need-to-know basis)

Korisnicima treba dodeliti pravo pristupa samo na one datoteke i programe koji su im
potrebni da bi obavljali svoju poslovnu funkciju u organizaciji. Pristup tekuim podacima i
izvornom kodu treba dodatno ograniiti dobro definisanim transakcijama koje osiguravaju da
korisnici mogu menjati podatke na strogo kontrolisan nain kako bi se zatitio integritet.
Poto se od korisnika oekuje da efikasno obavljaju svoj posao, pristupne privilegije treba da
budu razumno dodeljene kako bi se korisnicima omoguila fleksibilnost u radu. Bezbednosne
mere moraju uravnoteiti bezbednosne zahteve sa praktinom produktivnou.
Odvajanje dunosti (engl. separation of duties)

Pokazalo se kao dobra praksa da nijedan zaposleni nema kontrolu nad transakcijom od
poetka do kraja. Dvoje ili vie ljudi treba da budu odgovorni za izvoenje transakcije, npr.
onaj ko ima privilegiju kreiranja transakcije ne bi smeo imati privilegiju za njeno izvoenje.
Rotacija dunosti (engl. rotation of duties)

Poslovne zadatke treba menjati periodino tako da korisnicima bude oteano
zlonamerno preuzimanje kontrole nad transakcijom. Ovaj princip je efikasan kada se koristi u
kombinaciji s odvajanjem dunosti. Meutim, organizacije koje imaju manjak zaposlenih ili
slabije osposobljene zaposlene, nisu u stanju da sprovode rotaciju dunosti.
12
Modeli integriteta opisuju naine ostvarivanja politike integriteta. Ouvanje integriteta

ima tri cilja, koje razliiti modeli postiu na razliite naine:
spreavanje neovlatenih korisnika da menjaju podatke ili programe,
spreavanje ovlatenih korisnika da menjaju podatke ili programe na nepropisan i
neovlaten nain,
odravanje unutranje i spoljne konzistentnosti podataka i programa.
2.3. Raspoloivost
Raspoloivost osiguranje da autorizovani korisnici imaju mogunost pristupa
informaciji i pripadajuim sredstvima kada je usluga potrebna. Iako kriptografija nema
direktnog uticaja na raspoloivost, dva su momenta upotrebe kriptografije koja mogu imati
uticaja na raspoloivost. Kada se podaci kriptografski obezbede, mogu se distribuirati
krajnjim korisnicima na lokacije sa kojih je dostupnost, od strane autorizovanih korisnika, tih
informacija vea. S druge strane, kada se kriptografija ukljui u samu aplikaciju, sistem zavisi
od pristupa kriptografskim kljuevima. U sluaju nedostupnosti kljueva, bilo da je mreni
podsistem u kvaru, kljuevi obrisani ili izmenjeni, ceo sistem je neupotrebljiv. Posebno je
interesantan sluaj kada napada u sistem unese vlastiti klju. Ceo sistem funkcionie, ali su u
tom sluaju podaci ifrovani kljuem napadaa, i to sve do trenutka dok napada ne opozove
klju. Posle toga svi podaci postaju "taoci" vlasnika kljua.
Pri razmatranju raspoloivosti u informacionoj bezbednisti i dalje treba voditi rauna o
fizikim, tehnikim i administrativnim aspektima raspoloivosti. Fiziki aspekti ukljuuju
spreavanje neovlatenog osoblja od pristupa sredstvima za obradu podataka, razliite zatitne
mehanizme za odbranu od poara i poplave i sl. Tehniki aspekti se odnose na mehanizme
otporne na greke (engl. fault-tolerance mechanisms), npr. uparivanje diskova (engl. disk
mirroring) i redudantnost sklopova, programe za kontrolu pristupa i dr. Administrativni
aspekti ukljuuju politiku kontrole pristupa, operativne procedure, planiranje nepredvienih
situacija i obrazovanje korisnika. Adekvatan trening operatera, programera i osoblja
zaduenog za bezbednost moe uticati na smanjenje broja situacija u kojima dolazi do gubitka
raspoloivosti.
13
3. Zakonska regulativa
Usvajanjem novog krivinog zakonodavstva 2003. godine Srbija je po prvi put u sistem
krivinog prava uvela posebna raunarska ili kompjuterska krivina dela koja su imala za cilj
da obezbede efikasnu, kvalitetnu i potpunu zatitu bezbednosti raunarskih podataka odnosno
raunarskog sistema. Tako je Zakon o izmenama i dopunama Krivinog zakona Republike
Srbije (KZ RS) iz aprila 2003. godine u sistem krivinog prava nae zemlje uveo vie
raunarskih (kompjuterskih) krivinih dela i to, u glavi 16a. KZ RS predviena su krivina
dela protiv bezbednosti raunarskih podataka. [7] Na taj nain se i naa zemlja pridruila nizu
zemalja koje se na razliite naine (preventivnim i represivnim merama) pokuavaju
suprotstaviti razliitim oblicima i vidovima zloupotrebe kompjutera odnosno raunara2.
Imajui sve ovo u vidu, kao i tenju nae zemlje ka Evro-atlanskim integracijama,
namee se kao neminovnost usvajanje seta zakona koji bi se odnosili na zatitu privatnosti
podataka u raznim oblastima ivota i rada. Dok se to ne desi ostaje jedino da se zaviri u
budunost, tj. da se prikae stanje u zakonodavstvima tehnoloko naprednih zemalja a koja se
odnose na zatitu podataka. Praksa u tim zemljama je sledea: sve je dozvoljeno do momenta
dok se ne desi problem. Tada se donese skup zakona, kojima se stanje u oblasti regulie, sve
do pojave novog problema. Konkretno, u oblastima u kojima se primenjuju raunari donese se
zakon, a usklaenost sa zakonom kontrolie od strane sertifikacionog tela koje potvruje da li
je organizacija ispunila sve uslove koje od nje zakon trai.
Razumevanje problema vezanog za usklaenost sa zakonom moe biti teak i
frustrirajui napor za programere. Veina programera nema dobru podlogu u pravnoj sferi a
sa druge strane zakonodavac ne poznaje dobro razvoj softvera. Kao posledica se javlja
problem u komunikaciji izmeu ove dve grupe ljudi: jezik zakona a i sami zahtevi opisani u
zakonu ne mogu se jednoznano prevesti u softverske projektne zahteve. Problem je dodatno
uslonjen rastuom koliinom propisa na svim nivoima - dravnom, meunarodnom i
strukovnom - inei tako od zahteva za usklaenou kola u kojem se takvi zahtevi ponekad
i meusobno preklapaju. Ovaj prikaz je pokuaj da se premosti jaz i da se bolje razume
priroda zahteva za usklaenou sa zakonom.
Pokriveno je detaljno est najrelevantnijih zakona, a ostalih etiri samo uvodno. Svaki
zakon ponaosob je pokriven sa etiri podruja:
Pregled zakona: tumai zakona sa programerske take gledita, objanjavajui ta je
potrebno znati radi razumevanja posledica koje zakon ima na razvoj aplikacije.
Bruce Schneier, me unarodno priznati ekspert za bezbednost podataka ima obi aj da kae da zakon titi
podatake ali da kriptografija titi podatke jo bolje.
14
Potrebni koraci u procesu: detaljno objanjenje zahteva koji se odnose na programere.

Uopteno govorei u ovom delu se opisuju vrste podataka koje se smatraju osetljivim i
na koji ih nain treba zatititi.
Tehnologije i tehnike: objanjava strategije i tehnike radi ispunjenja zahteva
postavljenih zakonom. Strategije i tehnike su odvojene u pet glavnih kategorija:
poverljivost, integritet, dostupnost, kontrola i evidencija, i provera integriteta.
Dodatni izvori: daje vezu na izvore gde ze moe nai vie dodatnih informacija o
zakonima o kojima je re.
Nakon odeljka o zakonima, sledi vaan odeljak pod nazivom Tehnologije i tehnike
najbolje prakse. U tom poglavlju su skupljeni najvaniji primeri najbolje prakse koji su
zajedniki za razne delove zakonodavstva. Tako na primer, posle opisa problema poverljivosti
u HIPPA sekciji, mogue je direkno videti poglavlje sa opisom najbolje prakse radi
dopunjavanja znanja o tome kako osetljive podatke drati u tajnosti. U sledeoj tabeli se daje
kratak opis svakog zakona i na ta se odnosi:
Zakon
Odnosi se
Sarbanes-Oksli Privatnost i integritet podataka u kompanijama na berzi
(SOX)
Poverljivost, integritet i dostupnost zdravstvenih informacija
HIPAA
Poverljivost podataka sa platnih kartice zapisanih i koritenih od
PCI
strane trgovaca
Poverljivost i integritet podataka zapisanih od strane finansijskih
GLBA
institucija
Privatnost linih podataka kupaca snimljenih od strane kompanija
SB 1386
koje posluju na teritoriji SAD, savezne drave Kalofornija
Poverljivost i integritet podataka pohranjenih od strane finansijskih
institucija. Dostupnost finansijskog sistema. Integritet finansijskih
BASEL II
informacija u toku prenosa, provera identiteta i integriteta
finansijskih transakcija.
Tabela 1: Set zakona o privatnosti podataka
Usklaenost sa zakonom je vano pitanje i za korisnike softvera. Svoje zahteve po

pitanju usklaenosti sa zakonom korisnici sve vie ukljuuju u proces razvoja softvera.
Jednostavno, to je pitanje koje, ako se ignorie, ugroava poslovanje kako korisnika softvera
tako i njihove proizvoae. Veina zakona se odnosi na upravljanje u IT, kao i na obavljanje
poslovnih procesa u kompaniji.
15
3.1. Sarbanes - Oksli, odeljak 404

3.1.1. Rezime zakona
Posle mnotva finansijskih skandala u velikim kompanijama, kao to je npr. Enron
katastrofa iz 2001 godine, [6] Ameriki Kongres je usvojio, ono to je predsednik Dord Bu
okarakterisao kao najdalekoseniju reformu Amerike poslovne prakse jo od vremena
Frenklin Delano Ruzvelta, zakon, nazvan Sarbanes - Oksli (skraeno SOX).
Svrha ovog zakona je da ulagai kapitala steknu vie poverenja u finansijske izvetaje
kompanija koje trguju na berzi stavljanjem kontrole kompanije na pravo mesto kako bi se
obezbedila poverljivost i integritet finansijskih podataka. Zakon se odnosi na kompanije koje
posluju na berzi u SAD-u, ali ima iru meunarodnu primenu jer se akcijama mnogih velikih
meunarodnih kompanija trguje i na Amerikoj berzi.
Kljuni deo SOX zakona, interesantan za programere, je odeljak 404 pod nazivom
Upravljanje procenama internih kontrola. U ovom poglavlju se od rukovodstva zahteva da
preuzme odgovornost za integritet informacija finansijskog karaktera tako to e procenjivati
IT sisteme i procese podkrepljujui ih vrstim dokazima da je organizacija preduzela potrebne
korake u ouvanju osetljivih podataka. Iako SOX direktno ne spominje IT, posledice po IT
neke organizacije su velike, s obzirom da se protok veine finansijskih podataka, u nekoj
organizaciji, odvija automatski kroz informacioni sistem i obrauje aplikacijama za koje je
odgovorno lice iz IT-a.
SOX je bio glavni pokreta razvoja bezbednosti u IT industriji. Jedan od efekata zakona
je postavljanje bezbednosti infomacija na najvii nivo unutar organizacije. Odeljak 302 SOX
zakona zahteva da generalni direktor (engl. chief executive officer skraeno CEO) i generalni
direktor za finansije (engl. chief financial officer, skraeno CFO) periodino daju pisane
izjave u kojima garantuju da su uspostavljeni odgovarajui kontrolni mehanizmi radi
upravljanja finansijskim informacijama. Odbrana rukovodstva izjavama da sistem ima
manjkavosti, vie ne moe da bude opravdanje, jer upravo rukovodstvo organizacije mora da
predoi uverenje da je sistem pod kontrolom. Zakon takoe predvia strogo kanjavanje, ne
samo organizacije nego i generalnog direktora i direktora finansija, u sluaju pogrenog
interpretiranja pokazatelja finansijskog stanja (engl. state of controls).
Da bi kompanija bila kompatibilna sa SOX zakonom, obavezno je redovno sprovoenje
revizorske kontrole, nezavisne revizorske kue, koja procenjuje kontrole koje se trenutno
sprovode kako bi se osiguralo da podaci budu tani, neizmenjeni, i kao takvi budu odraz
pravog finansijskog stanja kompanije. Donoenje SOX zakona je uticalo da se poveaju izdaci
na IT i bezbednost u IT-u.
16
3.1.2. Obavezni koraci

Od samog uvoenja zakona kompanije imaju odreenih problema da prilike u
kompaniji usklade sa zahtevima zakona, jer nema strogih pravila i brzih recepata kojima bi se
potvrdilo da su ispunjeni zakonski zahtevi. Vremenom se dolo do tumaenja, koje je opte
prihvaeno, da je kompanija usklaena sa SOX zakonom kada spoljna revizorska kua da
sertifikat kojim potvruje da su finansijski podaci pod kontrolom, da se tokom obrade oni ne
lairaju, i da su dostupni samo ovlatenim osobama.
Jedan od obaveza procesa revizorske kontrole je i ustanovljavanje toka finansijskih
podataka. Za veinu kompanija, tok finansijskih podataka se odvija kroz informacione
sisteme. To praktino znai da informacioni sistem treba da obezbedi da finansijski podaci:
ne mogu se menjati od strane neovlatenih lica
ne budu dostupni od strane neovlatenih lica
budu dostupni kad su potrebni ovlatenim licima.
Takoe je potrebna garancija da, ukoliko doe do fizike izmene u infrastrukturi IT, a te
promene su u direktnoj vezi sa finansijskim podacima, promene treba dokumentovati i
istovremeno obavestiti rukovodstvo organizacije.
Implemantacijom usklaenosti sa SOX zakonom, dolazi se do sprovoenja kontrole
pristupa podacima, kao i uklanjanja ranjivih mesta u IT-u, ime se obezbeuje da su podaci
nepromenjeni i sauvani od neautorizovanih osoba. Kao pomo pri usklaivanju sa SOX
zakonom moe da poslui i CORBIT (Control Objectives for Information and Related
Technologies) standard. To je otvoren standard iji su tvorci Institut za upravljanje u IT-u (IT
Governance Institute) i Udruenje za reviziju i kontrolu u informacionim sistemima
(Information Systems Audit and Control Association).
3.1.3. Tehnologije i tehnike

U osnovi, usklaenost sa SOX zakonom se svodi na revizorsku procenu mogunosti
organizacije da ogranii pristup resursima koji upravljaju finansijskim podacima a da se
promene u IT okruenju prate i evidentiraju. Programeri sa svoje strane treba ove zahteve da
imaju u vidi kod razvoja IS.
Poverljivost: Zahtev SOX je da poverljive informacije ne mogu biti izloene
neovlaenim stranama. Trai se korienje prihvatljivih kriptografskih tehnika i
algoritama kako bi se obezbedilo da su podaci dostupni samo ovlaenim korisnicima.
Integritet: Softver treba da obezbedi dokaz da podaci nisu menjani korienjem
kriptografskih tehnika kao to je kriptografski he.
17
Dostupnost: Jedan od zahteva SOX je i dostupnost finansijskih podataka ovlaenom

licu. To ukljuuje pouzdanost aplikacije, otpornost na DOS napade, korienje
pouzdanih mehanizama za skladitenje podataka (ukljuujui tu i bezbedno skladitenje
i oporavak na geografski udaljenoj lokaciji, redundantne sisteme (kao to je klastering),
i na kraju mehanizme za smetaj i oporavak kriptografskih kljueva u sluaju oteenja
sistema.
Kontrola pristupa: Potrebno je da programeri prue podrku pristupu koji se zasniva
na njegovoj osnovnoj ulozi kao i opozivu naloga. Moda se ukae potreba da aplikacija
mora da prui podrku u ovome tako to e se integrisati u vee okvire upravljanja
identitetom kao to je LDAP. Potrebno je razmotriti prava u vezi pristupa koje daje
aplikacija kada je re o svim osetljivim podacima. Treba voditi rauna o tome da kada
aplikacija bude instalirana, da se uloge unutar baze podataka, pristupa fajlu i ostale
take pristupa podacima odnose iskljuivo na ona pravila koja su privilegovana u
pogledu pristupa takvim podacima.
Kontrola i voenje dnevnika: Jedna od kritinih karakteristika IT-a predstavlja
kontrola i voenje dnevnika u sistemima koji obrauju osetljive podatke. Vano je da se
obezbedi voenje dnevnika u vezi sa relevantnim dogaajima unutar sistema, kao to su
iskljuenja rada kompjutera, restartovanja, ili neuobiajene situacije i dogaaji. Znai da
programeri treba da na bezbedan nain u okviru svojih aplikacija omogue dostavljanje
takvih informacija administratorima. Drugi aspekt koji bi trebalo razmotriti jeste da
podaci u dnevniku ne smeju pruiti uvid u bilo kakvu informaciju koju sistem nastoji da
zatiti, jer bi u suprotnom moglo doi do otkrivanja informacija neovlaenim osobama.
Potrebno je obratiti posebnu panju na to da se izbegne voenje dnevnika koji ukljuuje
bilo kakve osetljive podatke ne postoji nikakva garancija da e pristup dnevnicima i
pristup osetljivim podacima zahtevati identine privilegije.
Izmene u okviru upravljanja: Izmena u okviru rukovoenja predstavlja kritinu taku
kod Sarbanes-Oxley-a zbog injenice da se u tom sluaju od kompanija izriito trai da
obaveste rukovodstvo o bilo kakvim materijalnim izmenama u okviru obrade koja
upravlja dnevnikom finansijkih podataka. O ovome se vodi rauna jedino onda kada se
pravi neki sistem koji treba da upravlja protokom finansijskih podataka, odnosno za
tako neto se moe nainiti konfiguracija na one naine koji bi mogli da izmene takav
protok podataka. Ako se radi ba o takvom sluaju, onda je potrebno podrati ovakav
zahtev tako to e se ponuditi mogunost voenja dnevnika u okviru izmena sistema na
takav nain koji e osigurati da takvi dnevnici ne budu dostupni drugim osobama i da
budu pristupani iskljuivo privilegovanim korisnicima. Uobiajeni napad koji bi
eventualno preduzeli neki od zlonamernih korisnika u smislu neovlaenog pristupa
jeste da oni preplave mehanizam voenja dnevnika sa milionima stavki koje bi onda
doveli ili do gubitka znaajnih informacija ili bi pak moglo doi do 'gubljenja' vanih
18
podataka u gomili nevanih. Od ovakve vrste napada, organizacija se titi tako to e

regulisati voenje dnevnika. Isto tako bi, eventualno, moglo da se razmotri i
povezivanje sa nekim posebnim zatienim sistemom kako bi se zatitili od napada
zlonamernih korisnika.
3.2. PHI, HIPAA

Zakon o prenosivosti u okviru zdravstvenog osiguranja (PHI) i Zakona o odgovornosti
(engl. Health Insurance Portability and Accountability Act)

Zakon o prenosivosti u okviru Zdravstvenog osiguranja i Zakona o odgovornosti HIPAA je izglasao ameriki Kongres 1996. godine. On precizira federalne regulative koje
nalau lekarima, bolnicama i ostalim zaposlenima u zdravstvu da moraju da ispune neke
osnovne standarde kada obrauju elektronske zatiene informacije iz zdravstva (ePHI), kao
to su zdravsteni podaci i izvetaji o pacijentima na leenju. 3
Pre nego to je donet zakon u vezi HIPAA, smatralo se da line informacije o
pojedincima prikupljene u razliitim privatnim bazama podataka predstavljaju vlasnitvo one
organizacije koja je posedovala takvu bazu podataka. Glavni i osnovni koncept HIPAA jeste
ideja da vlasnici baza podataka nisu automatski i vlasnici podataka koji se nalaze u njima
oni su samo posrednici. Ovo predstavlja fundamentalno pomeranje u okviru paradigme zbog
toga to sve one organizacije koje se povinuju HIPAA-u moraju obezbediti garanciju u vezi sa
podacima o pacijentima:
Pristup njihovim sopstvenim podacima i pravo da se zahtevaju ispravke greaka.
Prethodno upoznavanje sa nainom na koji e se koristiti njihova informacija.
Eksplicitno odobrenje koje daju relevantni pojedinci pre nego to se ePHI moe
iskoristiti radi marketinga.
Pravo da se od zdravstvenih organizacija zatrai i oekuje da preduzmu razumne korake
kako bi se obezbedilo da komunikacije izmeu odreenog pojedinca i organizacije budu
smatrane i zadrane kao privatne.
3
Ovi standardi nisu zamiljeni tako da predstavljaju konani komplet ciljeva koji se
postavljaju pred zdravstvene radnike. U stvari, ovde se radi o tome da su takvi standardi tako
koncipirani da poslue kao poetna taka da bi se obezbedilo da svi entiteti odgovorni za
brigu o PHI pacijenata vode rauna o standardnom, minimalnom setu pravila kako bi se
obezbedilo postojanje oekivanog nivoa obavezne zatite. Na ovako neto se isto tako gleda i
kao na poetnu taku za ostvarivanje ambicioznijih ciljeva u okviru nacionalnog sistema
zdravstvene zatite.
19
Pravo da se Agenciji za graanska prava u okviru njihovog Odseka za zdravstvo i

humane usluge mogu podneti albe u vezi formalne privatnosti
Pre nego to se ukae potreba da se regulative primenjuju u okviru celokupnih nosioca i
servisa obezbeenja zdravstvene zatite koji se razlikuju po svojoj veliini, takve regulative su
same po sebi namerno predstavljene kao neodreene (neprecizne). U odeljku HIPAA odredbe
o bezbednosti ine tri razliite grupe zahteva, a svaka od njih navodi specifine mere zatite:
Administrativne mere zatite Obuhvataju pravila za ustanovljavanje i primenu politika
i procedura kompanije (na primer, oporavak nakon nesree i planovi za nepredviene
situacije)
Fizike mere zatite Obuhvataju ogranienja i pravila koja se odnose na fiziki pristup
objektima i ureajima, kontrolu pristupa, kao i na srodne politike i postupke koji se
odnose na fizike entitete odreene organizacije.
Tehniki standardi obuhvataju sve one mere zatite i prakse koji se odnose na tee
uoljive (nedostupne, nerazaznatljive, neopipljive) informacije koje se nalaze u
kompjuterskim sistemima organizacija kao to su prevencija upada u sistem,
usklaivanje podataka i kontrola pristupa.

Postoji nekoliko odredbi HIPAA koje se dele u dva manja odeljka. Prvi deo se bavi
mogunostima prenosivosti podataka o zdravstvenom osiguranju zaposlenih i njihovih
porodica u onim sluajevima kada oni menjaju zaposlenja, i isto tako stvoren je sa namerom
da se obezbedi da zaposleni koji imaju ve odranije odreene podatke o zdravstenom stanju
ne mogu doi u situaciju da im se nepravedno osporava zdravstvena zatita. Drugi deo
obuhvata odredbe o Administrativnim pojednostavljenjima i sadri tri podkategorije:
odredbe o privatnosti, elektronsku razmenu podataka unutar organizacije (HIPAA Electronic
Data Interchange (HIPAA/EDI), i odredbe o bezbednosti (Health Insurance Portability and
Accountability Act," http://en.wikipedia.org/wiki/HIPAA).
Odredbe koje se odnose na privatnost i HIPAA/EDI u ovom delu nisu razmatrane,
budui da one pre svega obuhvataju interne politike i operativne procedure kompanije
Amerika Uprava (ministarstvo) za zdravstvo i humane usluge, Administrativna
pojednostavljenja (uproavanja) u industriji zdravstvene zatite ( U.S. Department of Health
and Human Services, "Administrative Simplification in the Health Care Industry"). Odredbe o
bezbednosti predstavljaju primarnu brigu i nadlenost programera budui da one obuhvataju
specifine tehnike ciljeve u vezi usaglaavanja.
20
Odrebe o bezbednosti obuhvataju:

Obezbeivanje poverljivosti, integriteta i raspoloivosti svih ePHI koje kreira, dobija,
dalje prenosi ili zadrava entitet zdravstvene zatite.
Spreava obelodanjivanje svake ePHI informacije ije se objavljivanje zabranjuje.
Vodi rauna o tome da informacije u sistemu budu pristupane u svrhu praenja u cilju
revizije.
Stara se o tome da autentikacija bude uraena na takav nain da odreeni radnici ili
entiteti budu upravo oni za koje se oni i predstavljaju.
Pre nego to se obavi analiza koraka obrade, znaajno je poblie objasniti dva tipa
specifikacija koji se deklariu u odeljku HIPAA o tehnikim standardima:
Traene specifikacije predstavljaju one stavke koje se mogu uniformno zadovoljiti u
okviru celokupnog standarda, i u okviru svih organizacija. Na primer, dovoljan nivo
solidne procedure ifrovanja u cilju privatnosti podataka koji se odnose na nekog
pacijenta trebalo bi da bude prihvatljiv za svaku onu organizaciju koja se zalae za
usaglaavanje u okviru HIPAA.
Specifikacije koje se konkretno odnose na odreene entitete (Addressable
Specifications) podleu ocenjivanjima u smislu adekvatnosti, a to se opet zasniva na
okolnostima i pragmatinim razmatranjima. Na primer, da bi se udovoljilo zahtevima
sprovoenja revizije HIPAA, potrebno je da organizacije implementiraju neku vrstu
arhiviranja sistema (engl. backup) i skladitenja. Meutim, za malu lekarsku ordinaciju
nije neophodno reenje koje bi bilo na istoj nivou po obimu sa npr. Klinikim Centrom
glavnog grada. Precizirane specifikacije dozvoljavaju da organizacija ostvari izvestan
nivo kontrole kada je re o odreivanju adekvatnosti usaglaavanja. Stavke o
usaglaavanju u okviru precizne lokacije ne bi trebalo meati sa opcionom varijantom,
jer, one se jo uvek vrednuju kao mandatorne.

Postoji nekoliko specifinih tehnologija koje su veoma pristupane i koje praktino
mogu da udovolje potrebama gore pomenutih proceduralnih koraka.
Poverljivost: Svi ePHI moraju da se vode kao poverljivi podaci kako bi se onemoguilo
da neovlaena strana zadobije pristup izvetaju sa podacima o pacijentu. Potrebno je
koristiti adekvatno ifrovanje onda kada se smetaju poverljivi podaci u baze podataka
ili u fajlove, kada se aljetu mreom, i kada se takvi podaci nalaze u memoriji. Softver
je potrebno dizajnirati na takav nain da se algoritmi za ifrovanje mogu nadopunjavati i
da se veliine kljua mogu lako poveavati tako da kvalitet kriptografskog reenja moe
21
da bude u skladu sa uinjenim pomacima u okviru snage raunara i algoritama koji se

koriste za neovlaeno i zlonamerno upadanje u kompjuterske sisteme (algoritmi za
krekovanje).
Integritet: Podaci ne bi trebalo da budu takvi da se mogu modifikovati od strane
neovlaenih osoba ili entiteta. Treba primenjivati principe koji uopte nee uzimati u
obzir mogue privilegije i treba naroito voditi rauna o pojavi greke jer se samo tako
moe minimizirati opasnost od eskalacije privilegovanog statusa. Sve osetljive
informacije trebalo bi da koriste mehanizam za proveravanje integriteta kao to su
HMAC-SHA1 ili digitalni potpis kako bi se smanjila opasnost od neovlaenog
modifikovanja informacija.
Raspoloivost podataka: Budui da oni na koje se odnose podaci imaju garantovano
pravo da dobiju uvid u sopstvene podatke, nedostatak mogunosti uvida u okviru
servisa mogao bi da dovede do toga da se HIPAA tretira tako kao da kri odredbu o
usaglaavanju. Programeri treba da kreiraju takve sisteme koji e adekvatno voditi
rauna o mogunostima pojave greaka i koji e takoe biti u stanju da onemogue sve
napade na servis. Dnevnici o dogaajima trebalo bi da sadre dovoljno informacija da
obezbede mogunost rekonstruisanja aktivnosti sistema do momenta pojave greke tako
da bi se takva greka mogla brzo uoiti i ispraviti.
Revizija i voenje dnevnika: Sve one aktivnosti koje bi eventualno trebalo pratiti
moraju biti dokumentovane. Softverski sistemi moraju da generiu sve neophodne
informacije kod voenja dnevnika da bi se izradio jasan prethodni trag koji daje
naznake na koji nain je neki korisnik ili entitet pokuavao da pristupi i iskoristi resurse
sistema. Dnevnik aktivnosti treba redovno arhivirati kako bi se obezbedilo da se
informacije iz dnevnika ne izgube zbog kvara u sistemu.
Autentikacija: Da bi na ePHI-u radili na bezbedan nain, neophodno je da znamo da
odreeni entitet ili osoba koji rade sa podacima budu legitimni i da imaju ovlaenje za
pristup navedenim informacijama. Odobrenja predstavljaju set preslikavanja koja
povezuju identitet neke osobe ili entiteta sa specifinim setom doputenih operacija.
Sistemi za autentikaciju trebalo bi da budu projektovani sa preciznim ulogama koje se
preslikavaju na dobijanje dozvola kako bi programerima bilo lake da obave
implementiranje a onima koji obavljaju testove da na laki nain prikau sluajve
zloupotrebe.
22
3.3. PCI
Standard zatite podataka u okviru poslovanja pomou kartice (engl. The Payment Card
Industry (PCI) Data Security Standard) predstavlja standard koji se zasniva na bezbednosnim
programima koji su svaki za sebe izradila etiri zasesebna usluna servisa za plaanje
karticom, a to su VISA bezbednosni program za informacije o raunima (AIS) i njegov
pridrueni bezbednosni program za informacije o nosiocu kartice (engl. cardholder
information security program - CISP), Program zatite podataka MasterCard (engl.
mastercard site data protection program - SDP), bezbednosna operativna politika American
Express-a (engl. american express security operating policy - DSOP), i Discover
informaciona bezbednost i usaglaavanja (engl. discover information security and compliance
- DISC).
PCI ustanovljava sveobuhvatni set svetskih bezbednosnih standarda za sve trgovce i
provajdere servisa koji se bave skladitenjem, prenosom, ili obradom podataka nekog vlasnika
kartice iz bilo kog znaajnijeg servisa za platne kartice. Usaglaavanje sa Standardom zatite
podataka u okviru poslovanja plaanja karticom odnosi se na trgovce i provajdere usluga kod
svih kanala plaanja, ukljuujui tu trgovine na malo uz fiziko prisustvo, zatim kada su u
pitanju potanske i telefonske porudbine, i e-trgovina.

Da bi se sertifikovalo usaglaavanje sa PCI, mora se obaviti revizija kako bi se
verifikovalo da se radi o adekvatnom pridravanju standardima. Nakon toga slede
etvoromesene i godinje revizije radi utvrivanja usaglaavanja, pri emu precizni zahtevi
bivaju ovisni od klasifikacije samog trgovca da li se radi o nivou 1, 2, 3 ili 4. Svi trgovci su
podeljeni u razliite nivoe u ovisnosti od obima transakcija plaanja kreditnom karticom koje
oni u proseku ostvare u toku jedne godine u okviru Interaktivnih medija u grupi za
maloprodaju (engl. Interactive Media Retail Group). 4
to vie transakcija obavlja neka orgnizacija, to je i vei stepen osetljivosti u smislu da
li organizacija ispunjava PCI standarde da bi uspeno upravljala rizicima. Ovakvo podvajanje
jeste pokuaj da se izmire potekoe koje se pojavljuju kada se nastoji uspostaviti ravnotea
bezbednosti i praktinih administrativnih poslova. Postoji nekoliko iroko definisanih ciljeva
koje bi programeri za softver unutar trgovinskih organizacija trebalo da slede radi
ostvarivanja PCI usaglaavanja:
Detaljnije u vezi sa kriterijumima selekcije pogledati na http://www.imrg.org/pci_compliance_uk.pdf
23
Zatita podataka nosioca platne kartice.

Implementacija solidnih kontrolnih mera u vezi pristupa
Redovno praenje i testiranje mrea.
Naalost, sposobnosti trgovaca da mogu da prate sluajeve krenja privatnosti i da
primenjuju korektivne mere drastino su umanjene zbog zakonodavstva, i zbog tehnikih
pitanja koja proizilaze iz injenice da su forenziki dokazi za preduzimanje takvih aktivnosti
nepotpuni za potrebe svih trgovaca. Preduzimanje odbrambenih mera je u stvari jedino reenje
za nekog trgovca.

Sledee strategije se odnose na usaglaavanje sa PCI:
Poverljivost i autentikacija: Ovo je osnovni cilj PCI da se zatite informacije sa
kreditnih kartica potroaa. Naalost, programeri ne poseduju kompletnu kontrolu s
kraja na kraj (engl. end-to-end control) kad je re o procesu manipulisanja kreditnom
karticom. U idealnom sluaju, podaci sa kreditne kartice bi mogli da se neposredno
razmene izmeu kompanije koja izdaje kreditnu karticu i pojedinca, ali ovo se retko
dogaa. Podaci sa kreditnih kartica se esto dalje dostavljaju preko nekoliko
posrednika-agenata, a neke od njih potroai ne mogu ni da vide, ali podrazumeva se da
svima njima oni silom prilika moraju da ukau poverenje. Najbolje reenje koje se moe
implementirati gledajui iz perspektive jedne jedine organizacije jeste da se obezbedi da
podaci budu adekvatno ifrovani, te da iskljuivo ovlaeni sistemi ili agenti imaju
pristupa osetljivim informacijama na raunima. Ovo nije ba toliko efikasno reenje s
kraja na kraj, ali ono bi moglo da osigura kompaniju da ona ne plaa visoke kazne koje
bi mogle da se nametnu u sluaju krenja privatnosti i objavljivanja podataka.
Voenje dnevnika i revizija: Ovo je drugi najkritiniji aspekt usaglaavanja sa PCI.
Programeri treba da obezbede da njihov kd omogui interfejs za voenje dnevnika u
vezi svih relevantnih transakcija rauna i pristupa. Naalost, veoma je teko za trgovce
da na proaktivni nain odrede one sluajeve kada se radi o zloupotrebi kreditne kartice,
zbog toga to oni ne poseduju centralizovanu banku ponaanja koja bi mogla da ukae
koji od korisnikih ema su sumnjivi u odnosu na dati raun. Praenje ponaanja jeste
zadatak koje na sebe preuzimaju agencije za izdavanje kreditnih kartica i njihovo dalje
praenje. Iz perspektive programera znaajno je obezbediti da se ova informacija
ubelei u dnevnik, tako da interno razvijene aplikacije ne dovedu do odsustva od
odgovornosti u sluaju kada nadleni dravni organi zahtevaju uvid u prethodno
zabeleene podatke.
24
3.4. Gramm-Leachy Bliley

Ameriki Senat je Zakon Gramm-Leachy Bliley (skraeno GLBA) doneo u novembru
1999 kako bi olakao da industrijski sektor preduzme veliku reformu u okviru finansijskih
servisa. Zakon je predloio senator Fil Gram iz Teksasa kako bi poboljao konkurentske
aktivnosti i prakse u okviru finansijskih servisa industrije tako to bi se obezbedio okvir za
pridruivanje banaka, firmi koje se bave bezbednosnim poslovima, i ostalih provajdera
servisa.
GLBA je nastojao da "modernizuje" finansijske servise drugim reima, da okona sa
regulativama koje su spreavale udruivanje (integrisanje) banaka, kompanija koje posreduju
u trgovini novcem, i osiguravajuim kompanijama. Odbacivanje ovih regulativa je dovelo do
poveanja velikih rizika u smislu da ove nove finansijske institucije imaju pristup
neverovatnoj koliini informacijama o pojedincima, a da pri tom ne bude nikakvih restrikcija
u vezi sa korienjem takvih informacija.5 Sam ovaj postupak ne odreuje eksplicitne zahteve
u vezi sa privatnou i zatitom informacija o klijentu, ali zato postoje tri odredbe koje
predstavljaju zahteve GLBA-a: Odredba u vezi sa privatnou finansijskog poslovanja (engl.
financial privacy rule), Odredba o merama zatite (engl. safeguards rule), i odredbe u vezi
preteksta.
GLBA daje ovlaenja osam federalnih agencija i dravama da mogu da uvode i
primenjuju Odredbu o privatnosti u oblasti finansijskog poslovanja i Odrebu o zatitama.
Privatnost u oblasti finansijskog poslovanja i odredbe o zatitama odnose se na finansijske
institucije, koje obuhvataju banke, firme koje se bave vrednosnim papirima, i kompanije koje
obezbeuju ostale tipove finansijskih proizvoda ili usluga za potroae. Meu ovim uslugama
ubrajaju se davanje pozajmica, posredovanja ili servisiranja bilo kog tipa potroakog kredita,
prebacivanje ili uvanje novca, utvrivanje poreskih pojedinanih prijava, obezbeivanje
finansijskih saveta ili davanje saveta oko uzimanja kredita, kao i obezbeivanje usluga u vezi
stambenih nekretnina ili prikupljanje dugova potroaa. GLBA posebno imenuje CEO-ve
kompanije i direktore koji lino snose odgovornost za bilo kakve zloupotrebe informacija za
koje se utvrdi da se odnose na pojedince. Neuspeh u vezi sa usaglaavanjem sa GLBA ima za
posledicu izricanje zakonskih kazni za finansijsku instituciju koja je uinila prekraj.

GLBA doputa tenje veze meu bankama, firmama koje se bave vrednosnim papirima
i osiguravajuim kompanijama, uz ogranienje da finansijske institucije i njihovi partneri
5
Elektronski informacijski centar za privatnost (Electronic Privacy Information Center, Chris Jay Hoofnagle
and Emily Honig, "Victoria's Secret and Financial Privacy,"
http://www.epic.org/privacy/glba/victoriassecret.html).
25
treba da zatite one line podatke koji nisu javni i da implementiraju razliite naine kontrole
pristupa i kontrole bezbednosti. Najvea briga koju ima GLBA jeste obezbeivanje integriteta
i poverljivosti podataka klijenata kao i informacija o njima. Informacije koje se odnose na
klijenta i njegove line finansijske podatke obuhvataju ime, adresu, broj socijalnog
osiguranja, broj rauna, i svaku drugu informaciju koju klijent upie u prijavu za otvaranje
rauna. U toku prikupljanja zahteva, implementacije, ispitivanja (sprovoenja testova i
razmetanja, vano je da se na umu imaju ovi ciljevi koji se odnose na integritet i poverljivost.
Ako se obrati panja na ovo pitanje u toku svake faze razvojnog ciklusa onda je mnogo manja
verovatnoa da e se neki problem prevideti.

Sledee strategije mogu se primeniti na usaglaavanja u okviru GLBA:
Poverljivost: Sve informacije o klijentu moraju se uvati kao poverljive da bi se
neovlaenim stranama onemoguilo da pristupe raunu klijenta. Programeri moraju
koristiti pouzdana ifrovanja i he, ali isto tako moraju obezbediti da svi programi koji
se inae koriste za manipulisanje ifrom, deifrovanje, i potpisivanje moraju biti
odobreni od strane industrijskog sektora ne koristiti modifikovane kriptografske
module. Treba voditi rauna o tome da ifarski programi budu modularan tako da se
moe zameniti uz minimlne trokove. Ni u kom sluaju se ne uzdati u nesigurne rutine
iz gotovih biblioteka. Moe se desiti da im nedostaje kriptografski kvalitet, ili pak mogu
da sadre slabe take koje kompromituju ceo sistem.
Integritet: Podaci ne bi trebalo da se modifikuju od strane neovlaenih osoba ili
entiteta. Programeri treba da primenjuju principe najmanje privilegije i da pri tom
posebno povedu rauna o mogunosti pojave greki i njihovom uklanjanju kako bi na
taj nain minimizirali opasnost pojave eskalacije privilegije. Kod softvera, manje
uobiajeni programi za uklanjanje greaka predstavljaju ona mesta gde se pojavljuju
neoekivana ponaanja koja mogu dovesti do eskalacije privilegije ili mogu da za
posledicu imaju neoekivanu smetnju. Sve osetljive informacije trebalo bi da koriste
mehanizam za proveru integriteta kao to je to HMAC SHA1 ili digitalni potpis kako bi
se ograniio rizik od neovlaenoe izmene informacije.
Revizija i voenje dnevnika: Sve aktivnosti koje e eventualno biti naknadno iznova
proveravane moraju biti dokumentovane. Softverski sistemi moraju da generiu sve
neophodne informacije u vezi sa voenjem dnevnika kako bi se izradio jasan trag za
reviziju koji ukazuje na to kako neki korisnik ili entitet pokuava da pristupi i iskoristi
resurse. Obezbediti da ovakvo voenje dnevnika se redovno arhivira kako bi se
osiguralo da informacije o reviziji ne budu izgubljene zbog kvara na sistemu. Unoenje
poverljivih informacija u dnevnik nije preporuljivo; moe se desiti da neovlaeno
26
objavljivanje informacija o klijentu moda proistekne od strane pojedinaca koji imaju

legitiman pristup takvim podacima.
Vano je da se analiziraju modeli pristupa korisnika zbog toga to e nelegitimne
aktivnosti obino biti otkrivene tako to se posmatraju modeli korienja koji bi inae
mogli da prou neprimeeni u sluaju kada bi se pristup podacima obavljao preko
legitiminih kanala. Na primer, potrebno je razmatrati vreme pristupa podacima. U
sluaju da se poslovanje sa isplatama u nekoj banci obavlja u vreme uobiajenog radnog
vremena poslovanja banke, a onda se desi da se niz transakcija pojavi na odreenim
raunima u vreme van okvira radnog vremena poslovanja banke, odmah se javlja
sumnja da je u pitanju prekraj. Imajui u vidu da svaka institucija poseduje svoj
sopstveni set pravila o poslovanju, programeri i rukovodioci za operacije bie u stanju
da obave jo ira pretraivanja ovakvih sumnjivih ponaanja kako bi dobili konkretnu
ideju o tome ta bi trebalo pretraiti. Sa take gledita programera, razmiljanja o
tipovima informacija koje mogu biti izdvojene da bi se olakao ovakav pristup zasnovan
na ponaanju utedee vreme i napor na duu stazu.
3.5. SB 1386
SB 1386 predstavlja zakonski nacrt drave Kalifornije koji predstavlja amandman na
postojee zakone o privatnosti i na osnovu njega se unose odredbe kojima se zahteva
obelodanjivanje prekraja privatnosti od strane bilo koje organizacije ili nekog pojedinca koji
uvaju line informacije o klijentima i koji obavljaju poslove u dravi Kalifornija. Informacije
o pojedinim klijentima se u nacrtu zakonu definiu kao one informacije koje sadre prezime i
ime klijenta ili inicijale imena, zajedno sa barem jednom od sledeih dodatnih informacija6:
Broj socijalnog osiguranja.
Broj vozake dozvole ili broj identifikacione (line) karte u dravi Kalifornija
Broj rauna, broj kreditne kartice ili kartice o zaduivanju, u kombinaciji sa bilo kojim
traenim bezbednosnim kodom, ifrom za pristup ili lozinkom koja e dozvoliti
pristupanje finansijskom raunu pojedinca.
Barem jedna od gore pomenutih oblasti mora da bude dostupna u neifrovanom obliku
da bi kao takva oznaavala krenje privatnosti (na primer, u sluaju da bilo koji ili svi podaci
o klijentu budu dostupni drugim osobama, i pri tom su sve druge oblasti i dalje u ifrovanom
obliku, onda se smatra da se ovde ne radi o prekraju). U sluaju da sve line informacije koje
su procurele budu javno na raspolaganju na osnovu drugih izvora, onda se ovako neto ne
6
LegalArchiver.org, "California SB 1386," http://www.legalarchiver.org/sb1386.htm
27
smatra za prekraj. Punovane odredbe u zakonodavstvu SB 1386 stupile su na snagu 1. jula

2003.godine. SB 1386 predstavlja primer kako drave na sopstvenu inicijativu uzimaju u
razmatranje pitanje privatnosti, i kako dalje preduzimaju korake radi zatite privatnih
informacija stanovnika u toj dravi.

SB1386 predstavlja veoma jednostavan, veoma ogranien set pravila koja se
usredsreuju na to da se ouva poverljivost informacija o klijentu. Zahvaljujui tome to
propisi nisu glomazni i ne sadre nikakve dvosmislenosti u okviru pravnog renika oni koji su
zadueni za sprovoenje ovakvih propisa znaajno su pojaali mogunosti da mogu da
primene SB 1386 u velikom broju sluajeva. Ve postoje mnogi dokumentovani sluajevi gde
se utvrdilo da su kompanije uinile prekraje. Radi praktinih razloga i ciljeva, ovaj nacrt
zakona ima dva specifina koraka u vezi sa usaglaavanjem:
Obezbeuje privatnost podataka o klijenutu po svaku cenu.
Daje na uvid sve one sluajeve gde se sve one line informacije koje udovoljavaju
prethodno pomenutim kriterijima sa pravom stavljaju pod lupu jer se sumnja da su
obelodanjene na neprihvatljiv nain ili su pak dospele u posed neke neovlaene osobe
ili entiteta. injenice o otkrivanju podataka moraju da budu neposredno saoptene
oteenim pojedincima i ovo se mora uiniti pravovremeno. Jedino upozorenje u
napomeni u smislu pravovremenog otkrivanja prekraja u vezi privatnosti jeste ono koje
kae da se prethodno mora doneti odluka o tome da li otkrivanje i upoznavanje sa
odreenim podacima o prekraju moe da negativno utie na bilo koje trenutne ili
predstojee istrage kriminalnih radnji.

Sledee strategije mogu se primeniti na usaglaavanja sa SB 1386:
Poverljivost: Obezbeivanje privatnosti kada je re o podacima klijenata predstavlja
jedan od primarnih ciljeva koje uzima u razmatranje SB 1386. Paljivo ispitivanje
zakona u odeljku II, paragraf (e) otkriva i jednu posebnu odredbu: "Kada je re o ovom
odeljku onda se 'line informacije' koje se pominju u njemu odnose na ime neke osobe
ili njegov prvi inicijal i prezime u kombinaciji sa bilo kojim drugim ili jo veim brojem
drugih elemenata podataka, u sluaju kada ili samo ime ili pak elementi podataka nisu
ifrovani". Ova klauzula ide tako daleko da ukazuje i na to da u sluaju da napada
dobije podatke, onda tako neto i ne predstavlja prekraj osim ako jedna oblast nije
ostavljena u neifrovanom obliku. Kada se skladite bilo koji podaci u vezi sa klijentom,
mora se obaviti ifrovanje da bi se izalo u susret obavezi usaglaavanja.
28
Revizija i voenje dnevnika: Jedan od tehniki najzahtevnijih aspekata usaglaavanja

sa SB 1386 i njegovom odredbom o potpunom razotkrivanju podataka jeste pitanje
otkrivanja onog momenta kada dolazi do krenja privatnosti. Iskusni napadai koji
nastoje da ukradu informacije nee uiniti nikakvu tetu sistemima koje kompromituju.
Nedostatak bilo kakvih razaznatljivih nepravilnosti ukazuje na to da nisu prisutni
oigledniji znaci upada koji bi svakako upozorili one koji vode istragu da se radi o
upadima i prekraju. Jedini nain da se na efikasan nain suprotstavite upadima jeste da
se osigura da svaka transakcija bude uneta u dnevnik i da se obavljaju neredovite ali
konzistentne revizije ili na osnovu manuelnog pregleda ili na osnovu pregleda
ponaanja koji e utvrditi analitiki program. Programeri bi trebalo da imaju na umu
ovu informaciju i morali bi da razmotre mogunost raspolaganja neophodnim
interfejsima u svom kodu tako da se prati trag svim relevantnim transakcijama i
njihovoj ispravnosti.
3.6. BASEL II
BASEL II je zvanino poznat kao Meunarodna konvergencija merenja kapitala i
standarda za kapital (engl. International Convergence of Capital Measurement and Capital
Standards). Radi se o okviru koji je ustanovio Bazelski komitet, konzorcijum Centralnih
upravnih banaka (engl. Central Governing Banks) iz nekoliko zemalja. Cilj BASEL II a
jeste da revidira postojee meunarodne standarde koji se koriste radi merenja odrivosti
kapitala neke banke. Prethodni BASEL sporazum se smatra anahronim, zbog toga to se
pojavilo nekoliko novih momenata kod modernog bankarskog poslovanja koji inae nisu na
adekvatan nain prikazani u regulativama. Na primer, prvobitni BASEL sporazum ne uzima u
obzir pitanje arbitrae u oblasti velikog broja trita.7

Najvei deo BASEL II je sroen namenski za potrebe profesionalaca u oblasti
bankarstva. Imajui u vidu da BASEL II predstavlja meunarodni standard, on je napisan na
takav nain da se moe primeniti u raznovrsnim bankarskim sistemima u celom svetu.
Ovakve realnosti predstavljaju opravdanja za injenicu da su zahtevi potpuno nejasni sa take
gledita IT-a, barem kada su u pitanju akcioni ciljevi usaglaavanja. Meutim, postoji i
znaajna grupa raspoloivih prikupljenih informacija koje za potrebe elektronskih bankarskih
7
U sutini arbitraa ukazuje na to da nejednaskosti i neuravnoteenosti na razliitim tritima

moraju biti razmatrani onda kada se ocenjuje vrednost meunarodno aktivnih finansijskih
institucija. Ovo se posebno odnosi na meunarodne banke, zbog toga to njihova procenjena
vrednost uglavnom ovisi od vrednosti akcija za koju se daje potpora na meunarodnim
tritima.
29
i finansijskih usluga opisuju rizike i korake za ublaavanje. Ovo je kompilacija dobijena na

osnovu nekoliko izvora koji se smatraju za najrelevantije za potrebe BASEL II gledano iz
perspektive programera.
Ovo ipak nije sveobuhvatna lista, ali e pomoi da se obezbedi usaglaavanje u odnosu
na BASEL II:
Spreavanje neprihvatljivog otkrivanja informacija.
Onemoguavanje naovlaenih transakcija kako se ove ne bi unosile u kompjuterski
sistem.
Spreavanje neovlaenih promena softvera u toku rutinskog programiranja i
odravanja kada moe doi do generisanja prevarantskih transakcija, a i sto tako se
moe desiti da neke vrste operacija ostanu neproverene, ili moe doi do namernog
blokiranja voenja dnevnika sa ciljem da se zaobie kontrola tako da ovakve aktivnosti
prou neprimeeno.
Onemoguavanje presretanja i modifikovanja transakcija dok se one alju preko
komunikacijskih sistema kao to su telefonske, satelitske mree i raunarske mree.
Spreavanje prekida rada servisa zbog kvara na hardveru ili softveru.

Sledee strategije mogle bi da pomognu da se obezbedi zadovoljavanje gore pomenutih
koraka obrade. Najvei broj tehnika da se obezbedi proces usaglaavanja mogao bi da bude
takav da klijenti dejstvuju kao agenti koji su neposredno u interakciji sa bankama, ili moglo bi
da se radi o transakciji tree strane od jedne finansijske institucije do druge.
Poverljivost: Finansijski podaci se moraju po svaku cenu uvati kao poverljivi i ne
smeju biti pristupani neovlaenim osobama. Programeri treba da primenjuju principe
najmanje privilegije i isto tako moraju obavljati paljivu kontrolu pojava greke kako bi
minimizirali rizik za eskalaciju privilegija ili pojavu neoekivanog kvara. Kod softvera
manje uobiajeno uvoenje rutina oko pronalaenje greaka ukazuju na ona mesta gde
poivaju neoekivana ponaanja koja mogu da dovedu do eskalacije privilegija. Treba
voditi rauna da kriptografske rutine budu modularne kako bi mogle da se eventualno
zamene uz minimalne trokove. Ne treba se uzdati u gotove bibilioteke za ifrovanje
koje ne ulivaju mnogo poverenja zbog injenice da im moda nedostaje kriptografski
kvalitet, ili pak mogu da sadre slabe take koje slabe ili kompromituju ceo sistem.
Raspoloivost: Pre nego to su se bankarski sistemi povezali u danani sloeni sistem,
standardna operativna procedura u toku prekida rada kompjutera obuhvatala je i
prebacivanje na manuelne obrade koje su bile na snazi pre nego to su kompjuteri
30
integrisani u sistem. Meutim, oslanjanje na pogodnosti koje takav automatski sistem

obezbeuje uinila je potpuno nepraktinom opciju da se obavi prelaz na manuelno
raunanje. Kao rezultat toga, zbog vremena dok kompjuter nije u radu neumitno e doi
do gubitaka podataka, pa e stoga postojati i potreba za uvoenje vanrednih mera kako
bi se razreili ovakvi neoekivani dogaaji. Potrebno je da svaki sistem bude bar
najmanje dvostruko redudantan. Otklanjanje kvara trebalo bi da se odmah obavi i ovo bi
trebalo da bude automatizovano za sve ovakve sisteme. Raspoloivost se obino
posebno pominje kao zadatak koji imaju administratori u sistemu i profesionalci iz
oblasti IT, ali programeri mogu da indirektno utiu na raspoloivost nekog sistema tako
to e poboljati prenosivost aplikacija koje razvijaju i to e obezbediti pouzdnost i
robustnost na osnovu dobrih praksi kodiranja.8
Upravljanje promenama: Vano je napomenuti da su programeri odgovorni za izmene
unutar softverskih sistema. Modifikovanje softvera za bankarsko poslovanje omoguuje
obavljanje nazakonitih transkacija na koje nisu uticali virusi iz spoljanjih izvora, ve se
ovde radi o nezadovoljnim programerima ili zaposlenim radnicima. Stoga je neophodno
da na snagu stupe mere koje se tiu odgovornosti kako bi se onemoguilo da druge
osobe ponu da unose samovoljne izmene u kritine softverske sisteme za bankarsko
poslovanje. Revizije softvera trebalo bi esto da obavljaju timovi programera i revizora
kako bi obezbedili opravdanost uvoenja izmena. Kontrolni sistemi programskog kda
isto tako trebalo bi aktivirati i oni e spreavati neovlaeno unoenje izmena, a idealno
bi bilo da se obezbedi neka vrsta kontrolnih lista pristupa, ili bar najminimalnije, trebalo
bi novije izmene podvri reviziji tako da se moe obaviti jasno pretraivanje u okviru
revizije u sluaju da se sumnja na malverzacije.
Autentikacija: Neophodno je da se obezbedi da se transakcije obavljaju iskljuivo od
strane legitimnih agenata. Autentikacija predstavlja primarno sredstvo obezbeivanja da
se zaista radi o agentima koji za sebe tvrde da su to to jesu. Onda kada se
ustanovljavaju autentikacioni sistemi, potrebno je obezbediti da se unesu i pouzdane
lozinke. Ne preporuuje se mogunost naloga bez lozinke ili gost lozinke jer oni ne
odgovaraju odreenim identifikacionim podacima i osobama iji nalozi ili resursi se
trenutno koriste. Prilikom smetanja lozinke, potrebno je obratiti panju na to da se
koristite dovoljno kvalitetna ifra kako bi akreditivi korisnika bili zatieni od napadaa
Kada je re o kriti kim sistemima kod velikih projekata, neke aplikacije se primenjuju unutar celokupnog
heterogenog okruenja kako bi se pove ao broj varijacija i kako bi se moda poboljale anse da svi oni uslovi
koji doprinose kvaru jednog sistema ne uti u na neki drugi deo operativnog okruenja. Na primer, razmotrite
slede e: Server na Web-u bi mogao da se rasporedi na Microsoft Windows NT koji operie po IIS-u, a neki drugi
Web server mogao bi da se rasporedi na Red Hat Linux koji operie na osnovu Apache Web server-a. U slu aju
da crv (kompjuterski virus) iz Interneta dovede do prestanka rada Linux servera, moda ovako neto ne uti e na
servera za Windows. U ovom slu aju varijacije u okviru okruenja pruaju mogu nost nekog stepena zatite na
prili no isti na in po kom principal genetske varijacije po svemu sude i dejstvuje u okviru biolokih sistema
31
koji bi eventualno mogli da im pristupe. Potrebno je uvesti u sistem takve tehnologije

kao to su SSL i digitalni sertifikati.
3.7. Ostale regulativne mogunosti

Ovaj odeljak obezbeuje kratak pregled o dve vrste zakona i standardu za koje se smatra
da e sa manje verovatnoe uticati na razvoj sistema kojima je potrebna zatita.
3.7.1. Zakon o upravljanju bezbednosti informacija na

federalnom nivou
Zakon amerike vlade o upravljanju bezbednosti informacija na federalnom nivou (engl.
The Federal Information Security Management Act skr. FISMA) je proglaen za zvanini
zakon 2002. godine kako bi se dao nalog za donoenje kompleta standarda o bezbednosti
informacija koji se priznaje i na federalnom nivou. Ovaj zakon ukazuje na to da je
usaglaavanje sa standardima obrade informacija na federalnom nivou (engl. Federal
Information Processing Standards skr. FIPS) mandatorno za sve vladine agencije u sluaju
prodaje sofvera za bilo koji ogranak federalne vlade, onda ovako neto mora da bude
usaglaeno. Pored mnogih drugih opisanih zakona, FISMA se usredsreuje na poverljivost,
integritet i raspoloivost osetljivih informacija. Zakon sadri i smernice koje bi se mogle
primeniti radi izraunavanja potencijalnih posledica prekraja na osnovu ega on odreuje
stepen neophodne zatite.
3.7.2. BS 7799
BS 7799 (smernice za upravljanje rizicima bezbednosti informacija) jeste komplet
preporuka koji e najverovatnije postati ISO standard u skoroj budunosti. Radi se o
sveobuhvatnom kompletu standarda koji obuhvataju sledee:
Procena rizika.
Postupanje u sluaju rizika.
Donoenje odluka u okviru upravljanja.
Ponovna procena rizika
Praenje i revizija profila rizika
Rizik u okviru bezbednosti informacija u kontekstu korporativnog rukovoenja
Usaglaavanje sa ostalim standardima i regulativama koji poivaju na riziku.
BS 7799 ima za cilj da pomogne neku organizaciju da ova ustanovi sveobuhvatnu
politiku o bezbednosti informacija.
32
3.7.3. Direktiva EU u vezi sa zatitom podataka

Direktiva EU u vezi sa zatitom podataka (engl. EU Data Protection Directive) je
objavljena u oktobru 1998. godine. Ona definie standard na osnovu kog se moe ocenjivati
zatita osetljivih podataka, i na osnovu koje se moe zabraniti prebacivanje ovakvih podataka
u bilo koju zemlju koja ne ispunjava ovakav standard. Zahvaljujui sloenostima zakona i
naknadnim prekidima u oblasti poslovanja kod mnogih amerikih kompanija, u julu 2000. EU
je doneo Zakon o bezbednoj luci (engl. Safe Harbor Act) kako bi modernizovao ceo ovaj
postupak. Safe Harbor obezbeuje okvir na osnovu kojeg moete obezbediti adekvatnu zatitu
privatnosti u nekoj kompaniji. Mnogi od zahteva o adekvatnosti su proceduralne prirode. Oni
zahtevi koji imaju uticaja na razvoj aplikacija pripadaju dobro poznatim zahevima:
poverljivost, integritet i raspoloivost osetljivih podataka.
3.8. Najbolje prakse kada je re o tehnologiji i tehnici

Pregled najboljih praksi
Mnoge od tehnologija i tehnika koje su opisane za potrebe regulative u gornjem delu
teksta su dosta sline. Odeljci u gornjem delu teksta opisuju svaku oblast koja se primenjuje
na specifino zakonodavstvo. Ovaj odeljak bavi se neto detaljijim opisom glavnih i najboljih
praksi za svaku od oblasti.
Poverljivost: Ne koristiti specijalizovane rutine za ifrovanje ili takve rutine koje ne
ulivaju dovoljno poverenja. Koristiti kriptografske interfejse (engl. application program
interface skr. API) koje daje OS platforma, zbog toga to su oni podrobno proueni i
naveliko testirani. Koristiti asimetrini algoritam kao to je RSA kada nije mogue na
bezbedan nain sauvati tajnu koju izmeu sebe dele strana zaduena za ifrovanje i ona
strana koja deifruje podatke. Simetrini algoritam kao to je AES moe da se koristi
onda kada je mogue da se uzajamno uva tajna pre nego to zapone ifrovana
komunikacija. Znaajno je da se izabere klju adekvatne veliine tako da se samo
ifrovanje ne moe lako dekriptirati. Onda kada se koristiti RSA, izabrati klju sa 2048
bita. A kada se koristi AES, onda izabrati klju sa 128 bita. Ove veliine kljueva daju
izvesni dodatni prostor za ekstenziju ali e na kraju biti neophodno da se i oni zamene
veim kljuevima u sluaju uveanja raunarske moi.
Integritet: He bi trebalo koristiti u svrhu sladitenja poverljivih informacija, kao to su
lozinke, za koje e moda naknadno biti potrebna validacija ali nee biti potrebno da se
ponovo uzimaju u celokupnom obliku. Provere integriteta trebalo bi takoe koristiti
kako bi se osiguralo da poverljivi podaci nisu moda bili zloupotrebljavani. Koristiti
SHA1 radi raunanja he vrednosti i koristiti HMAC-SHA1 onda kada se vri provera
integriteta. Meutim, pri tom je vano imati na umu da algoritam heinga treba tokom
33
vremena izmeni jer se procesorska snaga raunara uveava i prethodni jaki algoritmi
postaju vremenom neadekvatni.
Raspoloivost: Raspoloivost podataka obuhvata korienje reenja skladitenja koja su
pouzdana kao to je RAID i arhiviranje na sekundarnoj lokaciji. Za programere, ovo
znai da aplikacije treba tako projektovati da informacije o kljuu mogu da se pronau u
arhivi i mogu se stoga povratiti ak i u sluaju da doe do ozbiljnog kvara kod sistema.
Tamo gde se koristi ifrovanje, podrazumeva da u tom sluaju postoji neki mehanizam
koji e preneti kljueve kako bi podaci mogli da se iznova vrate u sluaju da se uniti
sam sistem. Jo jedno znaajno razmatranje odnosi se na to da programeri obezbede
mogunost da prevaziu kvar na sistemu. Ovo ujedno znai da kd za kontrolisanje
greke ne bi smeo da oslabi bezbednost sistema i, tamo gde je to podesno, trebalo bi da
takva kontrola prui podrku klasteringu i bezbednom nastavku rada nakon kvara. Zvui
paradoksalno ali postupak obrade greke je naroito est momenat pojave kvara sistema.
Kod projektovanja i implementacije mehanizama za kontrolisanje greaka, treba imati
na umu sledee smernice:
Kreirati konzistentnu arhitekturu za kontrolisanje greke i koristiti je tokom cele
aplikacije.
Ne otkrivati osetljive informacije korisniku onda kada vaa aplikacija ne uspe.
Zabeleiti odstupanja ili povratne vrednosti greke (engl. error return values) za svaki
API poziv koji bi mogao da obezbedi takve informacije.
Potrebno je u sluaju nastanka greke konsolidovati resurse sistema i ne dozvoliti da
ostanu u nebezbednom stanju u memoriji ili na fajl sistemu.
Revizija i voenja dnevnika: Obratiti panju da se ne unose osetljivi podaci kod
voenja dnevnika jer nema nikakve garancije da e pristupanje dnevniku i pristupanje
osetljivim podacima zahtevati iste privilegije. Treba obezbediti da dnevnik o
dogaajima u sistemu bude dostupan administratoru. ak i u sluaju da se u dnevnik ne
ne belei nikakva privatna informacija, informacija koja se nalazi u dnevniku mogla bi
da se iskoristi da bi se dalje podstakli napadi na sistem. Uobiajeni napad koji
zlonamerni korisnici mogu primeniti kako bi manipulisali sa dnevnikom jeste da se
mehanizam voenja dnevnika preplavi sa milionima dogaaja dnevnika koji ili dovode
do toga da znaajne informacije budu izgubljene ili se pri tom zamagljuju vane
informacije. Potrebno je razmotriti voenje dnevnika na odvojeni zatieni sistem radi
odbrane od napada neovlaenih korisnika. Dnevnik o dogaajima treba da sadre
dovoljno informacija kako bi bilo mogue obaviti rekonstrukciju aktivnosti sistema do
bilo koje take kvara tako da se greka moe brzo uoiti i otkloniti.
34
Autentikacija: Pri formiranju autentikacionih sistema, treba oforminti politiku

kvalitetnih lozinki. Kao minimalni zahtev trai se da lozinke imaju po duini sedam
karaktera i da sadre barem jedan karakter koji nije alfabetski ili numeriki. Treba
zabraniti pristup "gostinskim" nalozima ili drugim vidovima pristupanja koji se ne
podudaraju sa konkretnim podacima o identitetu, odnosno sa raunima ili resursima koji
se koriste. Pri skladitenju lozinki, potrebno je korienje dovoljno kvalitetne ifre kako
bi zatitili akreditive od napadaa koji bi eventualno mogli da im pristupe. Potrebno je
uvesti politike lozinki koje e biti tako podeene da akreditivi korisnika budu zastareli
posle definisanog vremenskog perioda. Takoe treba obezbediti da se sistem deaktivira
posle odreenog perioda neaktivnosti.
3.9. Zakjuak
Razumevanje usaglaavanja moe da predstavlja potekou. Postoji mnogo zakona i
informacija o njima koje su razbacane na velikom broju mesta. Postoji i vrlo malo resursa koji
bi mogli da predstave regulativne zahteve koji se odnose na zahteve softverskog razvoja ili na
uticaje i posledice po process razvoja softvera. Meutim, potekoa kod razumevanja
zakonodavstva ne umanjuje njegov znaaj. Ove regulative se aktivno uvode na osnovu
parninih postupaka u sudovima. Sudije i porotnici ne gledaju blagonaklono na potekoe
kada su u pitanju usaglaavanja. Programeri i kompanije bi trebalo da se zabrinu u vezi
posledica koje proizilaze zbog neusaglaavanja u sudovima, kao i sudovima za javno mnenje
onda kada javnost oseti da mu je ugroena privatnost.
Same regulative su moda sloene, ali udovoljavanje zahtevima ne mora da bude. Ovo
se svodi na sledee vane korake:
Utvrditi koje regulative predstavljaju znaajne zahteve za pripadajuu industriju i za
specifinu aplikaciju koja se razvija.
Obezbediti da zahtevi predstavljaju deo procesa formalnog razvoja poev od analize
zahteva i dalje preko projektovanja, implementacije, testiranja i instalacije.
vrsto se drati najboljih praktinih poteza koji su adekvatni u oblastima poverljivosti,
integriteta, raspoloivosti, kontrole i voenja dnevnika, kao i autentikacije.
Razvojna platforma Windows-a, a posebno razvojno okruenje .NET, dovodi do toga da
je izuzetno lako koristiti kriptografiju, karakteristike integriteta podatak i servise autentikacije
korisnika kako bi se udovoljilo najboljim prostupcima iz prakse. Sledea lista predstavlja
saetak kljunih najboljih praksi:
Koristiti odobrene industrijske standardne kriptografske algoritme (kao to su RSA sa
kljuem od 2048 bita)
35
Koristiti proveru integriteta (kao to su HMAC SHA1) kako bi obezbedili integritet

osetljivih podataka.
Koristiti voenje dnevnika o dogaajima kako bi se obezbedilo da modifikovanje i
korienje osetljivih podataka bude podlono kontroli.
Koristiti usluge operativnog sistema kako bi osigurali servise za autentikaciju u cilju
verifikovanja identiteta i uloge svakog onog korisnika koji pokuava da pristupi
osetljivim podacima ili eli da ih modifikuje.
36
4. Napadi na baze podataka

Infrastruktura baze podataka preduzea izloena je izuzetno velikom broju pretnji. Dat
je prikaz najkritinijih pretnji. Za svaku od pretnji data su objanjenja, opte strategije
ublaavanja rizika, i predlog mogueg reenja.
4.1. Zloupotreba preterane privilegije

engl. excessive privilege abuse
U sluaju kada se korisnicima (ili aplikacijama) odobre privilegije za pristup bazi
podataka koje inae prevazilaze zahteve njihove funkcije posla, onda se takve privilegije
mogu zloupotrebiti iz zlonamernih razloga. Na primer, administrator na univerzitetu iji posao
zahteva iskljuivo sposobnost da izmeni informacije o kontaku sa studentom mogao bi
iskoristi izuzetne privilegije koje poseduje u vezi auriranja baze podataka da izmeni ocene.
Neki korisnik baze podataka dolazi u situaciju da poseduje izuzetan broj privilegija iz
jednostavnog razloga to administratori baze podataka nemaju vremena da definiu i auriraju
kontrolne mehanizme granularnih privilegija pristupa. Kao rezultat toga, svi korisnici ili
velike grupe korisnika dobijaju privilegije generikog podrazumevanog pristupa koje daleko
prevazilaze specifine zahteve posla.
Spreavanje zloupotrebe zbog preteranih privilegija

Reenje za preterane privilegije predstavlja kontrola pristupa na nivou upita. Kontrola
pristupa na nivou upita odnosi se na neki mehanizam koji ograniava privilegije za bazu
podataka na minimalni broj neophodnih SQL operacija (SELECT, UPDATE, itd) i podataka.
Granularnost kontrole pristupa podacima mora da ide izvan tabele sve do specifinih slogova i
kolona unutar tabele. Neki mehanizam kontrole pristupa koji je dovoljno granularan i na
nivou upita mogao bi da omogui nekom (prethodno pomenutom) zlonamernom
univerzitetskom administratoru da aurira kontakt informacije, ali da pri tom upozori ako ovaj
pokua da izmeni ocene. Kontrola pristupa na nivou upita korisna je ne samo za otkrivanje
zloupotreba na osnovu preteranih privilegija od strane zlonamernih korisnika, ve isto tako i
za spreavanje ostalih pretnji koje se opisuju u ovom poglavlju.
Veina implementacija sistema za upravljanje bazama podataka - SUBP integriu neki
nivo kontrole pristupa na nivou upita (u obliku trigera), bezbednost na nivou reda (engl. rowlevel security), ali manuelna priroda ovakvih "ugraenih" karakteristika ine ih nepraktinim
za sve prilike izuzev onih koja su najvie ograniena. Proces manuelnog definisanja politike
kontrole pristupa na nivou upita za sve korisnike u okviru slogova tabele kod baze, kolona i
operacija jednostavno trai da mu se posveti mnogo vremena. Da bi stvar bila jo gora, dok se
37
uloge korisnika menjaju tokom vremena, politike na nivou upita moraju se aurirati kako bi
prikazale ovakve nove uloge. Najvei broj administratora baza podataka naao bi se u
nezavidnoj situaciji gde moraju da definiu korisnu politiku koja se odnosi na upit za potrebe
malog broja korisnika a za jedan kratak vremenski period. Kao rezultat ovoga, najvei broj
organizacija dostavlja korisnicima generiki komplet preteranih privilegija pristupa koje vae
za veliki broj korisnika.
4.2. Zloupotreba legitimne privilegije

Zloupotreba moe da doe i od strane legitimnog korisnika. Razmotrimo sluaj nekog
zdravstvenog radnika koji ima zle namere a koji poseduje privilegiju da moe da ima pregled
podataka o nekom pacijentu preko Web aplikacije. Struktura takve Web aplikacije normalno
da ograniava korisnike da imaju uvid u iskljuivo zdravstvene podatke jednog odreenog
pacijenta podatke za druge pacijente nije mogue posmatrati istovremeno i pri tom nisu
dozvoljene nikakve elektronske kopije. Meutim, ovaj zlonamerni zdravstveni radnik moe
da zaobie ovakva ogranienja tako to e se prikljuiti bazi podataka na osnovu aktiviranja
alternativnog klijenta kao to je MS-Excel. Koristei tako MS-Excel i svoje legitimne
akreditive za pristup ovaj radnik moe da povrati i snimi sve podatke o pacijentu.
Malo je verovatno da takve line kopije o podacima sa baza podataka o pacijentu budu
usaglaene sa politikama zatite podataka unutar bilo koje zdravstvene organizacije. Postoje
dva rizika koje bi trebalo razmotriti. Prvi je zlonamerni radnik koji je spreman da za novac
trguje zdravstvenim podacima nekog pacijenta. Drugi (i verovatno ei sluaj) jeste nemaran
zaposleni radnik koji preuzima i pohranjuje velike koliine informacija u svoj klijentski
kompjuter u svrhu legitimnog rada. Kada se jedanput pojave podaci na kompjuteru na krajnjoj
taki (engl. endpoint machine), onda oni postaju ranjivi na napade kao to je trojanci, kraa
lap-topa, itd.
Spreavanje zloupotreba kada se radi o legitimnom pristupu razumevanje

konteksta pristupa bazi podataka
Reenje za zloupotrebe legitimnog pristupa predstavlja kontrola pristupa bazi podataka
koja se primenjuje ne samo za specifine upite koji su opisani u gornjem delu teksta, ve i za
kontekst koji se odnosi na pristup bazi podataka. Na osnovu uvoenja politike za aplikacije
klijenta, vreme u toku dana, lokaciju, itd, mogue je identifikovati korisnike koji koriste
pristup bazi podataka na sumnjiv nain.
38
4.3. Uveanje privilegije

Napadai mogu da iskoriste prednosti koje im prua ranjivost softverske platforme baze
podataka kako bi konvertovali privilegije pristupa iz onih koje se odnose na uobiajenog
korisnika na one koje se vezuju za administratora. Ranjive take se mogu pronai u
skladitenim procedurama, ugraenim funkcijama, implementacijama protokola, i ak kod
SQL iskaza. Na primer, programer u nekoj finansijskoj instituciji mogao bi eventualno da
iskoristi ranjivu funkciju kako bi zadobio administrativnu privilegiju u bazi podataka. Uz
ovakvu administrativnu privilegiju, zlonamerni programer bi dalje mogao da iskljui
kontrolne mehanizme, saini lane raune, obavi prebacivanje novanih sredstava, itd.
Spreavanje uveanja privilegija kontrola pristupa na nivou IPS i upita

Sluajevi uveanja privilegija mogu se spreiti ako se uvede kombinacija tradicionalnih
sistema za prevenciju upada (IPS) i kontrola pristupa na nivou upita. IPS ispituje saobraaj u
bazi podataka kako bi utvrdio modele koji odgovaraju poznatim ranjivim takama. Na primer,
pod uslovom da se zna da je dotina funkcija ranjiva, onda IPS moe da eventualno ili blokira
sve pristupe ka osetljivoj proceduri, ili (ako je to mogue) da blokira samo one procedure u
koje su ugraeni napadi.
Naalost, precizno ciljanje na iskljuivo one baze podataka koje su potvrdile napad na
njih moe da se pokae tekim ako se koristi samo IPS. Uobiajeno je da se mnoge ranjive
funkcije baza podataka koriste u legitimne svrhe. Prema tome, blokiranje pojava svih ovakvih
funkcija nije pravi izbor. IPS mora precizno da odvoji legitimne funkcije od onih koje u sebi
nose ugraene napade. U mnogim sluajevima, jako veliki broj varijacija napada ini da je
ovako neto nemogue. U takvim sluajevima, sistemi IPS se mogu koristiti jedino u modu
uzbunjivanja (nema blokiranja) budui da se verovatno mogu pojaviti pogrene procene.
Da bi se poboljala preciznost, IPS se moe kombinovati sa alternativnim indikatorima
napada kao to su kontrola pristupa na nivou upita. IPS se moe koristiti radi provere da li
zahtev neke baze podataka trai ili ne trai pristup ranjivoj funkciji dok kontrola pristupa na
nivou upita pokuava da otkrije da li ovaj zahtev odgovara ili ne odgovara uobiajenom
ponaanju korisnika. U sluaju da jedan jedini zahtev ukazuje na pristup ka ranjivoj funkciji i
neuobiajeno ponaanje, onda je gotovo sigurno da je napad zapoeo i da je u toku.
4.4. Ranjive take na platformi

Ranjive take u osnovnim operativnim sistemima (Windows, UNIX, itd.) i dodatni
servisi koji se instaliraju u server baze podataka mogu dovesti do pojave neovlaenog
pristupa, oteenja podataka, ili do odbijanja izvrenja usluge. Blaster Worm, na primer,
iskoristio je ranjivost Windows-a 2000 da bi doveo do odbijanja servisiranja.
39
Spreavanje napada na platformu Auriranje softvera i spreavanje

upada
Zatita sredstava (softvera) u bazi podataka od napada na platformu zahteva
kombinovanje uobiajenih auriranja softvera (krpljenje, patches) i sistema za spreavanje
upada (IPS, Instrusion Prevention Systems). Auriranja koja obavlja prodavac dovode do
eliminisanja ranjivih taaka koje se mogu pojaviti u bazi podataka tokom vremena. Naalost,
auriranja u okviru softvera obezbeuju i implementiraju preduzea na osnovu periodinih
ciklusa. U vremenu koje protekne izmeu ciklusa auriranja, baze podataka nisu zatiene.
Osim toga, problemi u vezi sa kompatibilnou ponekad u potpunosti dovode da
nemogunosti auriranja softvera. Da bi mogli da reite ovakve probleme, potrebno je
implementirati IPS. Kao to je to prethodno opisano, IPS ispituje saobraaj u bazama
podataka i identifikuje napade koji su usmereni prema poznatim ranjivim takama.
4.5. Ubrizgavanje SQL-a

Kod nekog napada kod kojeg se ubacuje SQL, napada obino ubacuje (ili injektuje)
neovlaeene instrukcije za bazu podataka u neki od ranjivih SQL upita. Obino napadnuti
kanali podataka obuhvataju pohranjene procedure i parametre za unos (input) Web aplikacije.
Ovakve ubaene instrukcije se dalje prebacuju do baze podataka gde se i izvravaju. Kada
koriste mogunosti ubacivanja SQL napadai eventualno mogu da ostvare nesmetani pristup
celoj bazi podataka.
Spreavanje ubrizgavanja SQL

Da bi se efikasno suprotstavili ubacivanju SQL mogu se kombinovano upotrebiti tri
tehnike: spreavanje upada (IPS), kontrola pristupa na nivou upita (pogledati zloupotrebu
preteranih privilegija), i korelacija dogaaja. IPS moe da identifikuje pohranjene ranjive
procedure ili ubacivanje nizova znakova (stringova) SQL-a. Meutim, IPS sam za sebe nije
dovoljno pouzdan budui da ubacivanje nizova znakova SQL ima nezgodnu osobinu da ukae
na pogrene indikacije. Oni koji upravljaju pitanjem bezbednosti i koji se iskljuivo oslanaju
na IPS mogli bi da budu bombardovani sa "moguim" upozorenjima o ubacivanjima SQL.
Ipak, na osnovu uporeivanja potpisa kod ubacivanja SQL sa drugim prekrajem kao to je
prekraj u vezi kontrole pristupa na nivou upita, moe se izuzetno precizno identifikovati
stvarni napad. Malo je verovatno da bi se potpis kod ubacivanja SQL i neki drugi prekraj
mogli pojaviti u istom zahtevu tokom uobiajene poslovne operacije.
40
4.6. Slaba kontrola dnevnika aktivnosti

Automatizovano beleenje svih osetljivih i / ili neobinih transakcija u bazi podataka
trebalo bi da budu deo osnove koja predstavlja sutinu razvoja bilo koje baze podataka. Slaba
politika kontrole baze podataka predstavlja ozbiljan organizacioni rizik na mnogim nivoima.
Rizik u vezi sa regulativama Organizacije koje poseduju slabe (ili ponekad
nepostojee) mahanizme kontrole baze podataka e sve vie i vie uoavati da dolaze u
raskorak sa regulatornim vladinim zahtevima. Sarbanes-Oxley (SOX) u okviru sektora
finansijskih usluga i prenosivost informacija o zdravstvenoj zatiti (Healthcare Information
Portability) kao i Zakon o odgovornosti (Accountability Act (HIPAA) u sektoru zdravstvenog
osiguranja su samo dva primera vladine regulative sa jasnim zahtevima za kontrolu baze
podataka.
Odvraanja Poput video kamera koje belee likove pojedinaca koji ulaze u banku,
mahanizmi kontrole baze podataka slue da odvrate napadae koji znaju da kontrola i
pregled baze podataka obezbeuju da istrani organi dobiju forenzike detalje koji
mogu da se poveu sa kriminalnom radnjom koju su poinili uljezi.
Otkrivanje i otklanjanje greke Mehanizmi voenja dnevnika predstavljaju jedan od
elemenata odbrane baze podataka. U sluaju da neki napada uspe da zaobie druge
odbrambene mehanizme, podaci iz dnevnika aktivnosti mogu da ukau na postojanje
prekraja kada za to postoje jasni dokazi. Podaci iz dnevnika mogu se iskoristiti da bi se
uspostavila veza sa prekrajem i konkretnim korisnikom koji je nainio takav prekraj
i/ili se moe pristupiti rekonstrukciji sistema.
Softverske platforme baze podataka u principu integriu osnovne mogunosti kontrole
ali one su podlone viestrukim slabostima koje ograniavaju ili iskljuuju mogunost daljeg
razvijanja.
Nedostatak konkretnog korisnika Onda kada korisnici pristupaju bazi podataka
preko Web aplikacija (kao to su SAP, Oracle E-Business Suite, ili PeopleSoft), osnovni
(lokalni) mehanizmi kontrole nisu upoznati sa specifinim identitetima korisnika. U
ovom sluaju, celokupna aktivnost korisnika povezuje se sa imenom pri identifikaciji
korisnika na Web aplikaciji. Prema tome, u sluaju kada lokalni kontrolni protokoli
otkriju da se radi o prevarantskim transakcijama na bazi podataka, ne postoji veza koja
bi mogla da otkrije korisnika koji je za ovako neto odgovoran.
Degradacija performansi Lokalni mehanizmi kontrole baze podataka su na loem
glasu zbog preteranog eksploatisanja CPU i resursa diska. Loe perfomanse do kojih
moe doi kada se obezbede mogunosti kontrole primorava mnoge organizacije da
umanje ili pak u potpunosti eliminiu kontrolu.
41
Razdvajanje odgovornosti Korisnici sa administrativnim pristupom (koji se dobija

legitimnim putem ili zlonamerno) serveru za bazu podataka mogu jednostavno iskljuiti
kontrolni mahanizam kako bi prikrili zlonamernu aktivnost. Zadaci u vezi kontrole u
idealnom sluaju trebalo bi da budu odvojeni kako od administratora za baze podataka
tako i od platforme servera za bazu podataka.
Ograniena granularnost Mnogi lokalni kontrolni mehanizmi ne upisuju detalje koji
su inae neophodni radi podrke detekciji napada, forenzici i otklanjanju greaka. Na
primer, aplikacija klijenta u bazi podataka sa svojim lokalnim mehanizmima ne upisuju
u dnevnik aktivnosti podatke kao to su: izvorna IP adresa, atributi odgovora na upit i
neuspeli upiti.
Vlasniki kontrolni mehanizmi su jedinstveni za platformu servera u bazi podataka
Oracle protokoli su drugaiji od protokola MS-SQL, a protokoli MS-SQL razlikuju se
od Sybase, itd. Za organizacije sa kombinovanim okruenjima baze podataka ovakvo
neto doslovno eliminie implementacije uniformnih, podesivih procesa kontrole u
okviru preduzea.
Spreavanje slabe kontrole

Kvalitetni kontrolni ureaji koji su u osnovi mree bave se najveim brojem slabosti
koje se pripisuju lokalnim alatkama za kontrolu.
Visoka perfomansa Kontrolni ureaji na kojima se zasniva mrea mogu da
funkcioniu paralelno i uz nikakav (nulti) uticaj na perfomansu baze podataka. U stvari,
time to e se obezbediti da procesi kontrole budu prebaeni na mrene ureaje radi
rastereenja, organizacije mogu da oekuju da doe do poboljanja perfomansi u bazi
podataka.
Odvajanje zadataka Kontrolni ureaji u osnovi mree mogu da funkcioniu
neovisno od rukovodilaca za baze podataka pa stoga mogu omoguiti da se po potrebi
odvoje zadaci kontrole od administrativnih zadataka. Osim toga, budui da su mreni
ureaji neovisni od samog servera, oni su isto tako i neranjivi na napade iji cilj je da se
uveaju privilegije a koje obavljaju one osobe koje nisu administratori.
Kontrola na celokupnoj platformi Kontrolni ureaji za mreu u principu pruaju
podrku svim vodeim platformama baza podataka pri emu obezbeuju uniformne
standarde i centralizovane opracije kontrole nad celokupnim velikim heterogenim
okruenjima baze podataka.
Zajedno, ovakve karakteristike umanjuju trokove za server u bazi podataka, zahteve za
uravnoteenje optereenja i administrativne trokove. One isto tako doprinose i boljoj
bezbednosti.
42
4.7. Odbijanje pruanja usluge

Odbijanje pruanja usluge (eng. Denial of Service - DOS) je kategorija generalnog
napada kod kojeg se buduim korisnicima ne dozvoljava pristup aplikacijama na mrei ili
podacima. Odbijanje pruanja mogunosti usluge (DOS) moe se izvesti na osnovu mnogih
tehnika od kojih su mnoge u vezi sa prethodno pomenutim ranjivim takama. Na primer,
DOS se moe realizovati tako to bi se iskoristila ranjivost platforme u bazi podataka sa
ciljem da se prekine rad servera. Ostale uobiajene tehnike DOS obuhvataju oteenje
podataka, preplavljivanje mree (podacima), i preoptereenje resursa servera (memorija,
CPU, itd). Preoptereenje resursa je naroito uobiajeno u okruenjima baze podataka.
Motivacije koje stoje iza DOS su na slian nain raznovrsne. DOS napadi su esto u
vezi sa skandalima oko iznuivanja novca kada neki udaljeni napada neprestano pokuava da
prekine rad servera sve dotle dok rtva ne deponuje novana sredstva na raun u
meunarodnoj banci.
Spreavanje odbijanja pruanja usluga

Zatita od aktiviranja DOS zahteva preduzimanje zatite na viestrukim nivoima.
Neophodne su zatite na svim nivoima mree, aplikacije i baze podataka. U ovom radu
akcenat je na merama zatite unutar baze podataka. U ovom kontekstu koji se odnosi ba na
bazu podataka, preporuuje se razvijanje kontrole broja konencija, IPS, kontrola pristupa
upitu i kontrola vremena odgovora na upit:
Kontrola konekcija: spreava preoptereenje resursa servera tako to se ograniavaju
brzine konekcija, brzine upita i ostale promenljiive (veliine) za svakog korisnika baze
podataka.
Validacija IPS i protokola: spreavaju da napadai iskoriste poznate softverske
ranjivosti da bi oformili DOS. Prepunjenost bafera, na primer, predstavlja uobiajenu
ranjivu taku neke platforme koja se moe iskoristiti da se prekine rad na serveru baze
podataka.
Dinamiko profilisanje: (engl. Dynamic Profiling) automatski obezbeuje kontrolu
pristupa upitu kako bi se otkrile svi neautorizovani upiti koji mogu dovesti do pojave
DOS. Napadi DOS koji uzimaju za cilj ranjive take na platformi, na primer,
najverovatnije bi mogli da iniciraju prekraje kako u okviru IPS tako i u okviru
dinamikog profilisanja. Na osnovu dovoenja ovih prekraaja u korelativni odnos,
moe se ostvariti izuzetnu preciznost.
Ustanovljenje vremena davanja odgovora na upit Napadi DOS na bazu podataka
koji su tako projektovani da preopterete resurse servera dovode do kanjenja odgovora
43
iz baze podataka. Karakteristika ustanovljenja vremena davanja odgovora otkriva

kanjena kako kod individualnih odgovora na upit tako i kod celokupnog sistema.
4.8. Komunikacioni protokoli u bazi podataka

Kod svih prodavaca baza podataka uoava se sve vei broj ranjivih taaka u oblasti
bezbednosti, odnosno u njihovim komunikacionim protokolima u bazi podataka. etiri od
sedam bezbednosnih intervencija kod dva najnovija IBM DB2 FixPacks odnose se na
ranjivosti 1 protokola. Na slian nain, 11 od 23 ranjivih taaka kod baza podataka koje su
otklonjene u najnovijoj etvoromesenoj zakrpi (patch) Oracle-a odnose se na protokole.
Malverzantske aktivnosti koje se ciljno usmeravaju na ovakve ranjive take mogu da variraju
po obimu od neovlaenog pristupa podacima, pa do nanoenja tete podacima, pa sve do
odbijanja pruanja usluge. Crv SQL Slammer2, na primer, je iskoristio slabu taku kod
Microsoft SQLServer protokola da bi iznudio odbijanje pruanja usluge. I da situacija bude
jo gora, nikakvi zapisi o ovakvim malverzantskim vektorima nee postojati u lokalnim
dnevnikim zapisima budui da operacije protokola ne obuhvataju mehanizme upisivanje u
dnevnik aktivnosti.
Spreavanje napada na komunikacione protokole u bazi podataka

Napadi na komunikacioni protokol u bazi podataka moe da se predupredi uz pomo
tehnologije koja se naziva validacija protokola. Tehnologija validacija protokola u sutini
ralanjuje (disasembluje) saobraaj u bazi podataka i uporeuje ga sa oekivanim. U sluaju
da aktivni (stvarni) saobraaj ne odgovara oekivanjima, mogu se dati upozorenja ili blokirati
aktivnosti.
4.9. Slaba autentikacija

Slaba autentikacija omoguava napadaima da pribave identitet legitimnih korisnika
baze podataka kada putem krae ili na neki drugi nain uspeju da dobiju akreditive
neophodne za prijavljivanje. Napada moe da primeni neke od strategija da bi se doepao
akreditiva.
Gruba sila - Napada neprestano unosi kombinacije imena korisnika/lozinku sve dok
doe do one kombinacije koja je ispravna. Proces upotrebe grube sile moe da ukljui
jednostavno nagaanje ili sistematsko nabrajanje svih moguih kombinacija imena
korisnika/lozinke. Napada e esto upotrebiti automatizovane programe kako bi ubrzao
process upotrebe grube sile.
Socijalni ininjering Radi se o planu kod koga napada koristi prirodnu sklonost
ljudi da ukazuju poverenje i na taj nain ubeuju svoje rtve da im dostave akreditive
44
prijavljivanja. Na primer, neki napada moe da se predstavi preko telefona kao da je on

rukovodilac IT-a i da zahteva da mu se dostave akreditivi kod prijavljivanja u svrhu
"odravanja sistema".
Neposredna kraa akreditiva - Neki napada moe da ukrade akreditive za
prijavljivanje tako to e nainiti kopiju dokumenata, fajlova sa lozinkom, itd.
Spreavanje napada na autentikaciju

Jaka autentikacija
Potrebno je implementirati najjae praktine tehnologije za autentikaciju. Dvofaktoraska autentikacija (paketi podataka (tokens), sertifikati, biometrija, itd) su poeljni kada
je to god mogue. Naalost, pitanja trokova i lakoa korienja esto ine dvofaktorsku
autentikaciju nepraktinom. U takvim sluajevima trebalo bi uvesti solidnu politiku u vezi sa
imenom korisnika/lozinke (minimalna duina, raznolikost karaktera, neprepoznatljivost, itd)
Integrisanje aktivnog direktorijuma

Iz razloga podeavanja i lakeg korienja, trebalo bi jake autentikacione mahanizme
integrisati u infrastrukturu aktivnog direktorijuma OS. Izmeu ostalog, infrastruktura
direktorijuma moe da omogui korisniku da koristi samo jedan komplet akreditiva za prijavu
za viestruke baze podataka i aplikacije. Na ovaj nain dvofaktorski autentikacioni sistemi
postaju jeftiniji i/ili se korisnicima olakava memorisanje lozinki koje se redovno menjaju.
4.10. Otkrivanje podataka iz arhive

Mediji za skladitenje podke u bazi podataka esto bivaju nezatieni od napada. Kao
rezultat toga, nekoliko ozbiljnih previda u pogledu bezbednosti su doveli do kraa traka sa
arhiviranim podacima iz baze podataka.
Spreavanje otkrivanja podataka iz arhive

Svi arhivirani podaci iz baze trebalo bi da budu ifrovani. U stvari, postoje predlozi da
DBMS ne mogu da arhiviraju podatke nikako drugaije nego u ifrovanom obliku.
4.11. Zakljuak
Premda je informacija u bazama podataka ranjiva na raznorazne napade, mogue je
drastino smanjiti rizik tako to bi se usredsredilo na najkritinije pretnje. Time to bi obratili
panju na najvee pretnji koje su navedene, organizacije e zadovoljiti zahteve u vezi
usaglaavanja i ublaavanja rizika.
45
5. Kriptografska arhitektura
U ovom poglavlju bie razmatrana kriptografska arhitektura, na visokom nivou, za
tipinu aplikaciju koja bi trebala da skladiti ifrovane informacije u bazi podataka. Najvei
deo poglavlja razmatra karkteristike kljueva jer bezbednost kriptosistema zavisi od
bezbednosti i paljivog rukovanja ovim kljuevima, tako da je odgovarajui prostor posveen
kljuevima. Razmatranje obuhvata naglasak na to da bilo koji dati klju treba koristiti u jednu
jedinu svrhu, te da familije kljueva podravaju taj koncept. Unutar neke familije, kljuevi se
pomeraju kroz razliita stanja onako kako se ti isti kljuevi pomeraju kroz svoj radni ciklus.
Opseg kljua opisuje kako se primenjuju kljuevi unutar sloga baze podataka i odreuje kako
se rukuje potvrdama o ifrovanju podataka.
Koncepti kao to su familija kljua, opseg kljua, radni ciklus kljua, migracija i
zamena kljua od fundamentalnog znaaja su za razumevanje toga kako funkcionie baza
podataka nekog kriptosistema.
5.1. Osnove arhitekture

U teoriji razvoja softverskih projekata poznata su dva stila: iterativni i kaskadni stil
razvoja. softvera. [8]. Prilikom izrade predloga kriptografske arhitekture korien je iterativni
postupak. Prilikom razvoja baze podataka, koja e posluiti kao osnova kriptografske
arhitekture, polo se od modela prikazanog na sledeoj slici. U ovom modelu, aplikacija
pristupa bazi podataka, ifruje i deifruje podatke i sama upravlja kljuevima. Nedostatak
ovakvog modela je oigledan - uloga zatite podataka i korienja podataka je spojena u
jednom entitetu.
Slika 1: Jedan entitet u interakciji sa sistemom
46
U sledeoj iteraciji, Slika 2: Dva entiteta u interakciji sa sistemom, uloge su podeljene

na entitet koji pristupa podacima i na entitet koji ifruje / deifruje i upravlja kriptografskim
kljuevim. Ta dva entiteta sarauju kada korisnik podataka eli da sauva podatke u bazi
(prethodno se moraju ifrovati) i kada iz baze uzima podatke (podatke je potrebno
deifrovati). Iako ovaj model predstavlja poboljanje u odnosu na prethodni, nedostaci ipak
postoje. Problem je i dalje u vezivanju odgovornosti u jednom entitetu koji upravlja
kljuevima i kriptografski obrauje podatke.
Slika 2: Dva entiteta u interakciji sa sistemom
Pored ovog osnovnog nedostatka, predloeni sistem nije modularan. U sluaju

proirivanja sistema sa dodatnim kriptografskim modulima, u ovom predloenom modelu,
tesno su vezani kriptografski modul sa upravljanjem kljuevima. Svaki modul mora "da zna",
i da upravlja kljuevima, to nije dobro. Na kraju se dolazi do sistema koji je prikazan na
sledeoj slici:
Slika 3: Finalni model kriptografske arhitekture
47
Entiteti koji se nalaze u interakciji sa sistemom obuhvataju krajnje korisnike kao to su

osoblje za unos podataka ili klijente na Web sajtu i slubenike bezbednosti koji su zadueni za
administrativne poslove oko upravljanja kljuevima. Osim toga, postoje tipini
automatizovani poslovi koji se odnose na unos, obradu i izdvajanje ifrovanih podataka.
Da bi se sistem implementirao, odnosno da bi se sa vieg nivoa apstrakcije dolo do
konkretnog modela potrebno je analizirati osobine kriptografskih kljueva i njihovu ulogu u
celom sistemu. Tada e biti jasnija uloga entiteta i njihova meusobna interakcija.
5.2. Kriptografski kljuevi

Kriptografija umanjuje konkretan problem zatite mnogih tajni na takav nain da ovaj
postaje problem zatite samo nekoliko tajni [9]. Taj manji broj tajni predstavlja kriptografske
kljueve. Pravilno upravljanje kriptografskim kljuevima je od presudne vanosti za uspeh
postavljenog cilja, a to je bezbednost informacija. Bezbednost informacija koje se
kriptografski tite direktno zavisi od jaine kljueva, efikasnih mehanizama i protokola
povezanih sa kljuevima kao i od zatite kojom se tite sami kljuevi. Kljuevi moraju da se
tite od modifikacije, a tajni i privatni kljuevi od nedozvoljenog pristupa. Upravljanje
kljuevima je iroka oblast. Razlog tome lei u sloenosti sistema koji se pokriva
kriptografskom zatitom, to povlai za sobom veliki broj uesnika u celom razvojnom
procesu a oni mogu biti: administratori, programeri, ininjeri kriptografskih modula, kreatori
protokola, kao i administratori zadueni za bezbednost kljueva. Iz tog razloga bie prikazane
one karakteristike kljueva koje su od presudne vanosti za implementaciju kriptografske
zatite baze podataka. Karakteristike koje su obraene su grupe kljueva i opseg, stanje
kljua, troenje kljua i njegova zamena.
Duina kljua je posebna karakteristika koja znaajno utie na bezbednost a koja se
odreuje na osnovu algoritma za koji se koristi odreeni klju. Kako kriptografski algoritmi
nisu prikazani u ovom radu nee biti daljeg osvrta na duinu kljueva.
Odvajanje kljueva
Odvajanje kljueva predstavlja bezbednosni koncept koji nalae da se odreeni
kriptografski klju koristi iskljuivo u jednu jedinu svrhu. Prednosti odvajanja kljua su
sledee:
Smanjuje se broj entiteta kojima je neophodan pristup kljuu.
Koliina podataka koju treba obraditi pri postupku zamene kljua se odrava na
podnoljivom nivou.
48
Smanjuje se koliina ifrata nastala ifrovanjem datim kljuem tako da napada ima na
raspolaganju manje informacija za eventualno razbijanje ifre.
Ograniava se teta u sluaju da je odreeni klju kompromitovan.
Omoguuje se dizajn razliitih nivoa bezbednosti u zavisnosti od razliitih podataka
koji se tite.
Imajui u vidu da bezbednost kriptografskog sistema zavisi od bezbednosti kljueva,
najbolje je da se broj entiteta kojima je neophodan pristup kljuu odrava na apsolutnom
minimumu. Ograniavanjem korienja kljua u jednu jedinu svrhu, za posledicu ima manji
broj entiteta koji pristupaju kljuu. U kontekstu kriptografske zatite baza podataka, ovakva
obaveza ograniava upotrebu kljua na samo jednu jedinu bazu podataka.
Kljuevi se moraju periodino menjati da bi bili bezbedni. U toku zamene kljua, svi
podaci koji su ifrovni starim kljuem se deifruju i nakon toga se ponovno ifruju ali sa
novim kljuem. Separacija kljueva moe da omogui da ovaj posao bude veoma efikasan, u
nekim sluajevima je mogua i paralelna zamena kljueva.
Jedna klasa napada na kriptografski zatiene podatke, poznatija kao napad pri
posedovanju velike koliine ifrata (engl. ciphertext attacks), oslanja se na posedovanje velike
koliine prikupljenih podataka koji su ifrovani istim kljuem. Korienjem nekoliko
razliitih kljueva ograniava se efikasnost ove klase napada zato to se manja koliina
podataka ifruje svakim pojedinanim kljuem.
U sluaju da eventualno doe do kompromitovanja nekog od kljueva, sve ono to je
ifrovano sa tim kljuem takoe se moe smatrati kompromitovanim. Odvajanje kljueva
ograniava stepen gubitka zato svaki dati klju titi samo neke od podataka, a ostali podaci se
tite drugim kljuevima.
I na kraju, odvajanjem kljueva omoguuje se da snaga zatite bude prilagoena prema
podacima a ne da se svi podaci tite najviim stepenom zatite, troei nepotrebno resurse
sistema. Npr. ako najvei deo neke baze podataka zahteva upotrebu kljueva duine 138 bita
koji se zamenjuju svaka etiri meseca, a pri tom nekoliko kolona u bazi zahteva upotrebu
kljueva duine 256 bita koji se zamenjuju svakih sedam dana, onda bez upotrebe odvajanja
kljua, sve to se nalazi u bazi podataka bi moralo da se ponovno ifruje svakih sedam dana
kljuem duine 256 bita.
Odvajanje kljua se ostvaruje preko familija kljua i opsega kljua.
49
5.2.1. Odvajanje kljueva: familije kljueva

Familija kljua predstavlja jednu grupu kljueva koji se koriste tako da funkcioniu za
isti set podataka. Npr. jedna familija se eventualno moe koristiti za PIN broj kreditne kartice
a druga za podatke o zdravstvenom stanju. Kljuevi se identifikuju imenom svoje familije.
Kljuevi u familiji imaju specifine uloge koje odreuju kako se oni mogu koristiti.
Npr. u bilo kom momentu, samo se jedan klju u nekoj familiji moe koristiti za ifrovanje, i
dok viestruki kljuevi mogu biti korieni za deifrovanje, neka familija esto sadri stare
kljueve koji se ne mogu koristiti za ifrovanje ili deifrovanje. Ovakve uloge se menjaju
tokom vremena i o tome se odluuje na osnovu radnog ciklusa kljua.
Najbolja praksa jeste da se odredi jedna jedinstvena familija za svaku kolonu koju je
potrebno ifrovati. U sluaju da tabela sadri pet zatienih kolona, idealno je da pet familija
budu u stanju da pokriju tabelu. Slika 4: Separacija kljueva, dve familije kljueva prikazuje
dve zatiene kolone pokrivene sa dve familije kljueva.
Slika 4: Separacija klju eva, dve familije klju eva
Meutim, odnos 1:1 izmeu familija i zatiene kolone zahteva da svaki klju bude tako
organizovan i primenjivan kako bi se mogao itati celokupni red. Ovo moe da dovede do
primetno loih perfomansi. Time to se dozvoljava da odreena familija obuhvati sve kolone
donekle se dobija na performansama u administraciji, gde stepen utede zavisi od toga na koji
nain se obrauju kriptografski zahtevi. ak i kada familija kljueva obuhvata celu tabelu,
posebno se ifruje / deifruje svaka kolona, pa je stoga neophodno izvriti testiranje
implementacije sistema da bi se odredio uticaj familija po kolonama na perfomanse. esto se
deava da su dobici, ako ih uopte ima, slabi tako da nisu ni vredni rtvovanja prednosti i
dodatne bezbednosti.
50
5.2.2. Odvajanje kljueva: grupe familija

Sledei nain za odvajanje kljueva predstavlja korienje familija kljueva unutar neke
kolone. U ovakvom nainu korienja familija kljueva potrebno je odrediti kriterijum kojim
e se odrediti koja familija se koristi za koji slog. Tako dobijamo tabelu koja je podeljena na
"trake", jedna grupa slogova se ifruje / deifruje jednom familijom a druga grupa slogova
drugom familijom klueva. Grupe mogu da budu isprepletene ili se mogu nalaziti jedna pored
druge, to zavisi od kriterijuma za izbor familije. Slika 5: Grupe familija nad jednom kolonom
prikazuje primer grupe familija.
Slika 5: Grupe familija nad jednom kolonom
Npr. ako svaki red tabele bude oznaen sa jedinstvenim ID brojem, taj broj bi mogao da
se iskoristi za odreivanje familije. U sluaju da se eli deset familija, familija bi mogla da se
rauna kao ID modulo 10. U okviru ovakvog scenarija, familije 0 pa sve do familije devet
pokrivale bi kolonu, a naknadni novi aurirani podaci bi upadali u istu familiju zato to se ID
kolone ne bi menjao. Ovakav nain odreivanja familija dovodi do formiranja isprepletenih
grupa (pod pretpostavkom da se novi redovi uvek pridodaju tabeli). U sluaju da se za
odreivanje familije koristi mesec u kome je formiran slog, u tabeli bi bile formirane
kontinualne grupe slogova koje ine jednu familiju.
Ovakva strategija moe se dalje proiriti tako da viestruke familije takoe pokrivaju
viestruke kolone. Deset familija iz prethodnog primera mogli bi da obuhvate nekoliko
kolona. Jednostavan sluaj bi zahtevao da sve kolone u datom redu budu pokrivene jednom
istom familijom. Da bi ovako neto funkcionisalo, kriterijum za izbor familije ne sme da
zavisi od kolone: bez obzira koja kolona treba da se ifruje, kriterijumi e na kraju izabrati
istu familiju. Pethodni jedinstveni ID kolone i datum kreiranja sloga zadovoljavaju ovakvu
karakteristiku.
Familija kljua i grupa kljua utiu jedino na ifrovanje novih ili auriranih podataka.
Deifrovanje se uvek utvuje na osnovu informacije sadranoj u potvrdi ifrovanja, koja se
dobija od kripto modula (Slika 3: Finalni model kriptografske arhitekture), zajedno sa
ifratom. U sluaju da doe do izmene familije dok su podaci ifrovani, nita se ne deava sve
51
dotle dok ne doe trenutak auriranja podataka kada je neophodno da se takvi podaci ponovno
ifruju. U tom trenutku nova potvrda ifrovanja e ukazivati na neki klju u novoj familiji.
5.2.3. Odvajanje kljueva: Opseg kljua

Dok familije preslikavaju kljueve u kolone, opsezi kljueva ukazuju na to kako se
kljuevi koriste radi ifrovanja unutar slogova. Onda kada se slog ubaci u tabelu sa zatienim
kolonama, potrebno je utvrditi koji klju ili kljuevi su bili korieni. Potvrda o ifrovanju
koja se dobija od kripto modula sadri ovakve informacije. U neku ruku, opseg kljua
odreuje sa kolikim brojem potvrda o ifrovanju korisnik kriptografske usluge mora da
upravlja.
Kada je re o najuem opsegu, svaka zatiena kolona zahteva svoju sopstvenu potvrdu
o ifrovanju. Ovo je sluaj kada se sledi princip najbolje prakse da se koristi jedna familija
kljua za jednu kolonu, ali ak i onda kada se koristi samo jedna familija za celu tabelu, klju
moe biti uskog opsega. U takvom sluaju, svaka zatiena kolona se vezana sa svojom
potvrdom o ifrovanju. Kod prvobitnog dodavanja sloga u tabelu, sve potvrde o ifovanju e
ukazivati na isti klju. Tokom vremena, meutim, kljuevi u potvrdama o ifrovanju e se
verovatno razdvojiti dok se pojedinane grupe podataka auriraju a ostale grupe ostaju
neizmenjene.
Kljuevi sa uskim opsegom su kompleksniji za upravljanje i zauzimaju vie prostora jer
uvaju vie potvrda o ifrovanju. Oni su isto tako daleko vie fleksibilniji i obezbeuju bolju
bezbednost. Najbolja praksa jeste da se koristi to je mogue ui opseg kljua. Kod najirih
opsega, neophodan je samo jedna potvrda o prijemu zbog toga to su sve zatiene kolone
ifrovane jednim kljuem. Ovo pojednostavljuje upravljanje kljuevima ali ujedno stvara
sloenije upravljanje prilikom migracije kljueva zbog tog to sve zatiene kolone treba da
budu iznova ifrovane ak i onda kada jedna od njih podlee auriranju. iri opsezi su korisni
za grupisanje kolona koje sadre podatke koji se obino menjaju kao grupa. Npr. broj kreditne
kartice i datum njenog isticanja mogli bi da se ubace u zajedniki opseg zbog toga to se u
sluaju da se jedan od njih menja, onaj drugi e se verovatno isto tako promeniti. Slika 6:
Kriptografske potvrde o opsezima prikazuje povezanost opsega sa kriptografskim potvrdama.
Slika 6: Kriptografske potvrde o opsezima

52
Podaci o kriptografskoj potvrdi se mogu uvati u istoj tabeli sa podacima ili u nekoj
odvojenoj tabeli. Kriptografska potvrda je kompleksan podatak i sadri minimum ifrat i
identifukaciju korienog kljua (radi kasnijeg deifrovanja), a u zavisnosti od korienog
kriptografskog algoritma i kriptografski materijal kao to je npr. inicijalizacioni vektori. Broj
familija koje pokrivaju neku tabelu ne moe da bude vei od broja opsega.
Tabela koja ima est zatienih kolona mogla bi da poseduje takvu strukturu da tri
kolone pripadaju jednom opsegu, druge dve kolone da pripadaju nekom drugom opsegu,
odnosno da preostala kolona bude u svom sopstvenom opsegu. Tada se kae da tri opsega
pokrivaju tabelu.
Za tabelu koja je pokrivena sa tri opsega, neophodno je odvojiti smetaj za tri potvrde o
ifrovanju. Tim opsezima se moe dodeliti jedna, dve ili tri familije kljua.
5.2.4. Radni vek kljua

Kljuevi imaju ogranien vek trajanja. to vie podataka bude ifrovano nekim kljuem,
takav klju postaje sve slabiji. Dugi radni ciklus kljua znai da se takav klju suoava sa
veim brojem mogunosti njegovog kompromitovanja. Takoe, napada ima vie
kriptomaterijala kojeg bi eventualno mogao da iskoristi prilikom razbijanja ifre. Da bi se
ublaila ovakva inherentna slabost, kriptografski kljuevi se periodino moraju menjati.
Onda kada se obavlja zamena nekog kljua, svi podaci koji su ifrovani starim kljuem
moraju biti deifrovani a nakon toga se iznova ifruju novim kljuem. Zatim se mora obaviti
brisanje starog kljua kako se ovaj ne bi iznova koristio. Klju u svom radnom clikusu moe
biti u sledeim stanjima [12]:
predstojei
aktivan
istekao
okonan
uniten
kompromitovan.
Prelaz iz jednog stanja u drugo inicira se dogaajima kao to je istek kriptoperioda ili
saznanje da je klju kompromitovan. Na sledeoj slici prikazana su stanja u kojima se moe
nai klju.
53
1
3
2
IEJOTSDERP
4
5
NAVITKA
6
8
NAVOTIMORPMOK
OAKETSI
9
01
NETINU
NANOKO
Slika 7: Stanja klju a sa prelazima
Predstojei: Klju koji postaje aktivan onda kada se javi datum njegovog
aktiviranja. Moe da postoji nekoliko predstojeih kljueva u okviru
jedne familije.
Aktivan: Klju koji se trenutno koristi za ifrovanje i deifrovanje. Moe da
postoji samo jedan jedini aktivan klju u okviru neke familije.
Istekao: Klju koji je nekada bio aktivan ali je zamenjen novijim aktivnim
kljuem. Istekli kljuevi se koriste za deifrovanje podataka koji su
ifrovani starim kljuevima. Moe da postoji nekoliko isteklih kljueva
u okviru jedne familije.
Okonan: Neki klju koje vie nije u upotrebi. Moe da postoji nekoliko
okonanih kljueva u jednoj familiji.
Uniten: Klju koji je izbrisan iz trezora. Moe da postoji nekoliko unitenih
kljueva u okviru jedne familije.
Tabela 2: Dozvoljene kriptografske operacije i stanje kljua ukazuje na one
kriptografske operacije koje su doputene u svakom od stanja.
54
Stanje
ifrovanje
Deifrovanje
Predstojei
Ne
Ne
Aktivan
Da
Da
Istekao
Ne
Da
Okonan
Ne
Ne
Uniten
Ne
Ne
Tabela 2: Dozvoljene kriptografske operacije i stanje klju a
Po formiranju kljua, dodeljuje mu se familija i datum aktiviranja. Datum aktiviranja

ukazuje na datum kada takav klju prelazi u aktivno stanje. Sve dok ne doe taj datum, takav
klju se nalazi u predstojeem stanju i ne moe se koristiti za kriptografske operacije.
Posle datuma aktiviranja kljua, klju postoje aktivan i bilo koji prethodno aktivan klju
u familiji se na taj nain prebacuje u stanje isteka. Aktivno stanje je jedino stanje koje
omoguuje ifrovanje i svi zahtevi za ifrovanjem unutar neke familije kljueva koristi klju
koji je u toj familiji aktivan.
Kljuevi u stanju isteka se nikada vie ne koriste za ifrovanje. Klju koji je istekao
moe se iskljuivo koristiti za deifrovanje podataka koji su ifrovani onda kada je klju bio
aktivan. Stanje isteka je u sutini stanje zadravanja sve do onog trenutka kada se klju moe
zameniti. Najbolje je zameniti kljueve to pre je to mogue, kako on u stanju isteka ne bio
bio dui vremenski period.
Kada se jednom svi podaci koji su bili ifrovani nekim kljuem isteka ponovno ifruju
sa novim kljuem, klju isteka bi trebalo postaviti u stanje okonanja. Stanje okonanja
ukazuje da klju vie nije u upotrebi ali da i dalje postoji u trezoru za kljueve.
Razlika izmeu stanja okonanja i unitenja je u tome to je uniten klju izbrisan iz
trezora za kljueve. U oba ova sluaja, klju se ne moe upotrebiti. Najbolje bi bilo da se iz
trezora za kljueve izbrie kad doe u stanje okonanja to je pre mogue. ak i oni kljuevi
koji se vie ne koriste predstavljaju rizik zbog toga to bi napada eventualno mogao da doe
u posed ifrovanih podataka koji su ifrovani takvim kljuem. Nemarno rukovanje kljuevima
u stanju okonanja moe lako da dovede do kompromitovanja podataka.
Uobiajeni princip koji se odnosi na celokupni radni ciklus kljua jeste da kljuevi ne bi
trebalo da se nalaze u bilo kom od pomenutih stanja due nego to je to neophodno. im neki
klju doe do kraja svog predvienog operativnog perioda u nekom od pomenutih stanja,
trebalo bi da se pomeri u sledee stanje. Na slian nain, kada je re o predstojeim
kljuevima, najbolje bi bilo da se kljuevi ne formiraju za isuvie dug vremenski period
55
unapred. Cilj je da se kljuevi koriste za to je to mogue najkrai period vremena. to je

klju due u upotrebi, vee su mogunosti njegovog kompromitovanja.
5.2.5. Zamor kljua

Prilikom odreivanja familije i opsega kljua, potrebno je uzeti u obzir koliinu
podataka koju treba da zatiti neki klju kako bi se suprotstavili moguoj pretnji izlaganja
informacija. Izlaganje informacija ukazuje na mogunost dolaska do otvorenog teksta uz
pomo ifrata slabe prisutne tragove otvorenog teksta koji je i dalje tu i tamo ouvan u ifratu.
Dok se sve vie podataka ifruje uz pomo nekog kljua, to je vie verovatno da e
ifrovanje izazvati izlaganje otvorenih informacija kroz ifrat, i stoga sistem mora da ogranii
koliinu podataka koja se ifruju takvim kljuem. Analiza isticanja informacija opisana je u
[8] u okviru bibliografskih podataka i obezbeuje odlino uputstvo o tome kako da se odredi
ova granica i stoga se posebno preporuuje. Kada se jednom stigne do granice, verovatnoa
isticanja informacija postaje gotovo sigurna. Klju je u sutini u fazi zamora i njegova dalja
upotreba smanjuje bezbednost. Iz ovih razloga je potrebno odrediti kriptoperiod
Kriptoperiod je vremenski okvir u kome je dozvoljeno korienje kljua od strane
legitimnih korisnika. Prikladno odreen kriptoperiod:
ograniava koliinu podataka koja se titi datim kljuem i time smanjuje koliinu
ifrata dostupnu kriptoanalizi;
ograniava koliinu podataka dostupnih napadau u sluaju kompromitovanja kljua;
ograniava se korienje odreenog algoritma na njeovo predvieno vreme upotrebe;
ograniava se vreme pokuaja naruavanja fizikih, logikih i proceduralnih
mehanizama kojima je klju zatien od napada;
ograniava se vreme za procesorski intezivnu kriptoanalizu.
Nekada se kriptoperiod ograniava u terminima vremena ili sa maksimalnom koliinom
podataka koja se titi kljuem. Kriptoperiod je potrebno paljivo odrediti jer se loom
procenom rizikuje izlaganje kljua neautorizovanoj strani. Postoji mnotvo faktora rizika koji
utiu na mogunost izlaganja kljua i neki od njih su [12]:
jaina kriptografskih mehanizama (npr, algoritam, duina kljua, veliina bloka i mod u
kome radi sistem),
vrsta implementacija kriptografskog mehanizma(npr. implementacija po standardu
FIPS 140-2 Nivo 4 ili softverska implementacija na personalnom raunaru),
radno okruenje (e.g., zatieno okruenje sa kontrolom pristupa, poslovni prostor ili
javno dostupni terminal),
56
koliina informacija ili obavljenih transakcija,

ivotni ciklus samih podataka,
bezbednosna funkcija(ifrovanje, digitalni potpis, generisanje kljueva, zatita
kljueva),
metod unosa kljua (korisnik unosi klju tastaturom, uz pomo drugog kljua,
korienjem ureaja, udaljeno uz pomo PKI),
proces zamene ili generisanja kljua
broj vorita mree koji dele zajedniki klju,
broj kopija kljua i distribucija kopija
pretnja po podatke (od koga se eli postii zatita, koliku tehniku i finansijsku mo
ima napada).
Generalno gledano kratki kriptoperiod znai da je bezbednost na veem nivou.
Meutim, ako se proceni da postoji opasnost od ljudske greke pri zameni kljueva onda e
esta zamena kljueva da povea opasnost po same podatke. Ponekad je bolje koristiti
kurirsku distribuciju kljueva koja nije esta, posebno ako se radi o asimetrinom
kriptografskom sistemu.
5.2.6. Migracija kljua

Prilikom auriranja podataka koji su ve ifrovani, ako se klju kojim su ti podaci
ifrovani nalazi u fazi isteka, dolazi do procesa koji se naziva migracija kljua. U takvoj
situaciji, podaci se deifruju uz pomo kljua u fazi isteka, a promene nad podacima se ifruju
uz pomo aktivnog kljua.
Prilikom migracije treba biti oprezan, jer ako se koristi iroki opseg kljua - pokriva
vei broj kolona, ak i ako bude auriran podskup kolona koji se nalaze u okviru nekog
opsega, sve kolone opsega moraju da budu podvrgnute migraciji. To je zbog toga to se u
potvrdi o ifrovanju nalazi identifikacija kljua koja vai za ceo opseg.
Uski opsezi u potpunosti spreavaju nastanak ovakve situacije zbog toga to svaka
kolona poseduje svoju sopstvenu potvrdu o prijemu. Isto tako aurno zamenjivanje kljueva
koji su doli u fazu isteka smanjuje frekvenciju migracija kljua, a kljuevi koji istiu zato to
su doli do kraja svog korisnog radnog ciklus, trebalo bi zameniti to je to pre mogue.
5.2.7. Zamena kljua

Zamena kljua je postupak zamene kljua u fazi isteka novim aktuelnim aktivnim
kljuem. Proces zamene zahteva da se podaci koji su ifrovani sa kljuem u fazi isteka
deifruju i da se zatim obavi ponovno ifrovanje sa novim aktivnim kljuem. Kada jedanput
57
svi podaci budu iznova ifrovani, klju u fazi isteka trebalo bi da dobije oznaku klju u fazi
povuenosti kako bi se naznailo da ovaj klju vie nije neophodan.
Najbolja praksa ograniavanja jedne familije na jednu kolonu pojednostavljuje zamenu
kljua. U takvom sluaju, neophodno je ispitati samo jednu jedinu kolonu radi prisustva
kljua u fazi isteka, tako da se minimizirati rizik od sluajnog propusta da je u upotrebi klju
koga vie nema. to je vie kolona koje pokrivaju neku familiju, posebno ako se takve kolone
nalaze u razliitim tabelama, to je vei rizik da jedna od njih bude izgubljena, najee zbog
nedokumentovanog auriranja kriptografskog eme.
Rizik gubitka podataka u nekoj fazi auriranja nosi sa sobom ozbiljne posledice zato to
je klju u fazi isteka povuen, i uskoro se kao takav brie u trezoru za kljueve. Dok kljuevi
koji su izbrisani u trezoru za kljueve moda i mogu da se dalje zadre u bezbednoj, offline
arhivi, teko je obaviti deifrovanje na osnovu tako arhivisanih kljueva. U sluaju da klju
bude sklonjen ak i iz arhive, svi podaci koji ostaju ifrovani takvim kljuem se u principu
izgubljeni.
Klju koji dolazi u fazu isteka trebalo bi zameniti to je pre mogue. to due klju
ostaje u sistemu, vei je rizik da takav klju bude kompromitovan. Meutim, zamena kljua
troi dosta procesorske snage imajui u vidu da se deifruje velika koliina podataka a zatim
se obavlja ponovno ifrovanje u relativno kratkom vremenskom periodu. Ti trokovi prilikom
este zamene kljua mogu da budu preterano visoki. Zamena kjua isto tako dovodi do
uvoenja dodatne administracije, ukljuujui tu konfigurisanje i arhiviranje kljueva.
Zamena kljua u toku jedne godine u toku koje se javlja faza njegovog isteka je
razuman potez. U sluaju da je klju aktivan za period od jedne godine i nakon toga njegova
faza isteka se odvija sledee godine, tada je kompletan operacioni period ovakvog kljua dva
(dve godine). Dve godine je dugaki vremenski period za nekog napadaa da moe da smisli
napade na trezor za kljueve, podrku za kljueve, ili procedure administracije za kljueve. U
sluaju da je klju zatien u nekom hardverskom ureaju koji je imun na malverzacije, onda
bi moglo biti razumno da se produi stanje isteka (Expired state) na dve godine.
5.3. Predlog reenja

Posle analize osobina kriptografskih kljueva i njihove uloge u sistemu zatite baze
podataka dolazi se do fizikog modela baze podataka koja podrava pomenute zahteve i
ogranienja spomenuta u prethodnim poglavljima. Da bi predloeni fiziki model bio jasniji
sledi prikaz interakcije izmeu pojedinih komponenti sistema sa slike 3.
58
Korisnik je zainteresovan za podatke. eli da podatke smesti u bazu, te da oni u bazi

budu ifrovani i da prilikom uzimanja podataka iz baze oni budu deifrovani. Mora da poznaje
koju familiju kljueva e koristiti za zatitu podataka. Takoe posle dobijanja ifrovanih
podataka, zajedno sa ifarskom potvrdom, te podatke mora da sauva, u suprotnom nee biti u
stanju da deifruje podatke. U sluaju da se ema baze podataka izmeni i modul Korisnik e
pretrpeti velike izmene.
Kripto modul se sastoji iz dva dela. Jedan deo prima zahtev od Korisnika. Dobija
podatak koji treba ifrovati zajedno sa identifikacijom familije iz koje treba uzeti aktivan
klju. Informacije o kljuevima, ali ne i sami kljuevi, se nalaze u katalogu kljueva. U
katalogu kljueva, pronalazi identifikaciju aktivnog kljua za traenu familiju kljua i
priprema odnosno generie dodatne potrebne podatke kao to je inicijalizacioni vektor. Sve to
alje delu kriptografskog modula zaduenog za ifrovanje. On, na osnovu identifikacije kljua
pronalazi odgovarajui klju u trezoru sa kljuevima, ifruje podatke a ifrat sa ifarskom
potvrdom alje delu koji komunicira sa korisnikom. Razdvajanje Kripto modula na dva dela je
potrebno zbog vee sugurnosti, tako to deo koji komunicira sa korisnikom nema pristupa
trezoru sa kljuevima. Isto tako, deo koji ifruje / deifruje podatke pristupa trezoru sa
kljuevima ali samo da bi iz trezora uzeo kljueve. Odgovornost za kreiranje i uklanjanje
kljueva iz trezora je nadlenost Menadera kljueva.
Slika 8: Dijagram sekvenci za proces ifrovanja
59
Menader kljueva je modul iji je zadatak da kreira, uklanja ili menja kljueve. Ima
pristup Katalogu kljueva i samom Trezoru sa kljuevima. Iz razloga sigurnosti, a potujui
princip deljene odgovornosti, Menader kljueva ne moe da koristi kripto modul, i obrnuto.
Kripto modul ne sme da kreira ili modifikuje kljueve. U celom sistemu, ova komponenta ima
jednu od najosetljivijih uloga.
Sledea slika prikazuje deo fizikog modela baze podataka za podrku upravljanja
kljuevima.
DI_sailA
GOLATAK
KP
OBJANJAVA
D I_k 1KF
sutats
a jnarivitk A_muta D_k
ajilim aF_k
sail A_k
DI_k KP
ROZERT
KORISTI
D I_C APU K
C A PUK
KP
DI_SAILA_ ACITRAK_GESPO 1KF

DI_S AILA_CAPUK_GESPO 2KF
VI_ITSONDILAV_MUTAD
ITSONDILAV_MUTAD
ERFIC_ 4E JND AZ
VI_ACITRAK
ACITRAK
JORBTSOP
V I_li ame
li a m e
LAJICINI_EMIZERP
VI_EMIZERP
EMIZERP
LAJICINI_EMI
VI_EMI
EMI
DI_ retsa m_k 1KF

laji retam
TITI
DI_retsam_k KP
RETSAM
ajnarivitkA_mutaD
lajiretam
Slika 9: Fizi ki model BP za podrku upravljanja klju evima
60
5.4. Zakljuak
Kriptografska arhitektura prikazana u ovom poglavlju predstavlja fleskibilan,
modularan sistem koji se moe prilagoditi mnogim projektima u kojima je potrebno
kriptografski zatititi podatke. Naalost, poveavanjem fleksibilnosti i modularnosti sistema,
uveavaju se i potekoe da se sistem ouva bezbednim. Prilikom dizajna sistema vodilo se
rauna o ravnotei izmeu bezbednosti i funkcionalnosti.
61
6. Prikaz postojeih reenja zatite

U ovom poglavlju opisana su postojea reenja zatite u vodeim komercijalnim
bazama podataka: Oracle, IBM DB2 i Microsoft SQL Server; kao i u bazama otvorenog koda:
MySQL i PostgreSQL. Za neke DBMS dat je prikaz kriptografskih funkcija, dok je u drugim,
prikazana komplenta hijerarhija kljueva zajedno sa mehanizmima za njihovo upravljanje, to
direktno zavisi od stepena implementacije kriptografije u sam DBMS.
6.1. Oracle
Verzija Oracle 10g Release 2 baze podataka, u odnosu na prethodnu verziju, Oracle 9,
donosi veliki broj poboljanja. Kriptoloka poboljanja se odnose na kreiranje potpuno novog
PL/SQL paketa sa imenom DBMS_CRYPTO. U ovoj verziji, kriptoloki paket
DBMS_CRYPTO omoguuje zatitu podataka smetenih u bazi, odnosno zatitu podataka
koji se prenose mreom. Paket omoguuje korienje:
kriptolokih algoritama:
AES
3DES (112 i 168 - bita)
DES
RC4
Kriptografskih he funkcija (kao to je SHA-1)

He funkcija sa kljuem (MAC) kao to je SHA-1
Dopunjavanje do punog bloka: PKCS #5 i dopunjavanje nulama
Izbor ulanavanja kod blok ifraskih algoritama (CBC, CFB, ECB, OFB)
U
prethodnoj
verziji
Oracle
baze,
PL/SQL
paket
sa
nazivom
DBMS_OBFUSCATION_TOOLKIT je posedovao samo DES i 3DES kriptoloki algoritam i
MD5 he funkciju. Namena novog paketa je da zameni stari paket, ali zbog kompatibilnosti
stari paket je i dalje zadran.
62
Mogunosti paketa
Kriptografski algoritmi
DBMS_OBFUSCATION_
TOOLKIT
DES, 3DES
Padding
Ulanavanje
Kriptografske
funkcije
He sa kljuem
Nije podrano
Nije podrano
CBC
he MD5
Kripto pseudo random RAW, VARCHAR2

generator
Podrani tipovi podataka RAW, VARCHAR2
DBMS_CRYPTO
DES, 3DES, AES, RC4,
3DES_2KEY
PKCS5, zeroes
CBC, CFB, ECB, OFB
SHA-1
HMAC_MD5,
HMAC_SH1
RAW,
NUMBER,
BINARY_INTEGER
RAW, CLOB, BLOB
Tabela 3: Pore enje mogu nosti starog i novog kriptolokog paketa, Ora9 - Ora10
DBMS_CRYPTO paket
Iako sama kriptografija ne moe da rei sve pretnje po pitanju bezbednosti, jasno je da
se kriptolokom zatitom osetljivih podataka moe poboljati bezbednost. Novi PL/SQL paket
sadri priznate kriptoloke i he algoritme ukljuujui tu i AES. DBMS_CRYPTO moe da
ifruje i deifruje jednostavne Oracle tipove podataka kao to su RAW i LOB (engl. large
objects veliki objekti, tj. slike, zvuk i ostali multimedijalni podaci smeteni u bazi
podataka). Pored ovih kriptolokih funkcija, radi lakeg razvoja internacionalnih aplikacija,
pridodate su i pomone funkcija za konverziju karakter kodova.
Prikaz paketa DBMS_OBFUSCATION_TOOLKIT

Paket podrava dva blok ifarska algoritma, DES i 3DES. DES je ifarski sistem sa
simetrinim kljuem. DES ifruje podatke u blokovima od 64 bita, korienjem kljua od 56
bita. Iako se proceduri za ifrovanje mora proslediti klju duine 64 bita, DES algoritam
ignorie 8 bita. 3DES je bezbednosno jai algoritam od DES algoritma, jer kljueve koje
koristi imaju 112 odnosno 168 bita, i otporniji je na neke kriptoanalitike napade od svog
prethodnika.
Prilikom instalacije Oracle baze paket DBMS_OBFUSCATION_TOOLKIT se instalira
u SYS emi. Da bi se ovom paketu moglo pristupiti potrebne je imati dozvolu za korienje
paketa.
Prilikom
instalacije
Oracle
baze,
dozvola
za
pristup
BMS_OBFUSCATION_TOOLKIT-u je data PUBLIC roli, meutim, strogo se preporuuje
da se ova dozvola povue, i da se da samo odreenim korisnicima, odnosno rolama.
Upravljanje kluevima
Upravljanje kluevima, ukljuujui generisanje i uvanje kriptografskih kljueva,
predstavlja jedan od najvanijih aspekata kriptografije. U sluaju loe izabranog kljua, ili
slabo uvanog kljua, napadau na sistem je mnogo lake da doe do otvorenih podataka.
63
64
;)tuOrts || ' :cujlK'(enil_tup.tuptuo_smbd 62

;)8 * )2 / )r(htgnel.war_ltu( || ' :atib jorB'(enil_tup.tuptuo_smbd 52
42
;)r(xehotwar =: tuOrts 32
;)'8ftu',yek(war_ot_gnirts.n81i_ltu =: r 22
;)dees >= dees ,1 >= hcihw(yeKteG3SED.tikloot_noitacsufbo_smbd =: yek 12
cujlk ikurtsort ,SED3 az acujlk ejnasireneG -- 02
91
61
;)dees >= dees ,0 >= hcihw(yeKteG3SED.tikloot_noitacsufbo_smbd =: yek 31
cujlk ikurtsovd ,SED3 az acujlk ejnasireneG -- 21
NIGEB 11
;)002(war r 01
;)002(2RAHCRAV tuOrts 9
;)002(2RAHCRAV yek 8
7
;'17A5C98203862B210398217AD68765FBC24CE948' 6
|| '697398D7D82B86216C07A21765FE91BE4D3AC50F' 5
|| '8686224C0398217AD765FE9B8621BC498217AD76' 4
|| '5C0398217AD7C039821765FE9B8621BC50FE4D3A' 3
=: )061(2RAHCRAV dees 2
ERALCED >LQS
;NO TUOREVRES TES >LQS
.detelpmoc yllufsseccus erudecorp LQS/LP
14644314734353145314232453037314 :cujlK
46 :atib jorB
/ 91
;DNE 81
51
;)yek >= yek ,dees >= dees(yeKteGSED.tikloot_noitacsufbo_smbd 21
NIGEB 11
;)61(war r 01
;)23(2RAHCRAV tuOrts 9
;)23(2RAHCRAV yek 8
7
6
5
4
3
;'17A5C98203862B210398217AD68765FBC24CE948'
|| '697398D7D82B86216C07A21765FE91BE4D3AC50F'
|| '8686224C0398217AD765FE9B8621BC498217AD76'
|| '5C0398217AD7C039821765FE9B8621BC50FE4D3A'
=: )061(2RAHCRAV dees 2
ERALCED >LQS
;NO TUOREVRES TES >LQS
U paketu postoje dve funkcije odnosno procedure koje slue za generisanje kljueva a
to su DESGetKey i DES3GetKey. Sve funkcije kao parametar uzimaju sluajan niz od
minimum 80 bajta, i uz pomo DES odnosno 3DES algoritma generiu kriptografski klju.
Slede primeri generisanja kljueva s DES i 3DES algoritmom
Umesto da kripto-sistem napada grubom silom, analiza se uglavnom usmerava na pronalazak
slabosti pri izboru kljueva, ili na nain na koji se kljuevi uvaju u sistemu. Zato je potrebno
problemu generisanja kljueva pristupiti sa velikom panjom. Uglavnom se kljuevi generiu
automatski, korienjem generatora sluajnog niza. Takav nain generisanja kljueva moe
biti prihvatljiv jedino u sluaju da je dobijeni niz kriptoloki siguran. Ako se desi da niz nije
kriptoloki siguran, tj. u sebi poseduje elemente koji se mogu predvideti, sigurnost celog
sistema se naruava. Paket DBMS_OBFUSCATION_TOOLKIT sadri procedure za
generisanje preudosluajnog niza koji se moe koristiti kao klju pri ifrovanju.
/ 82
;DNE 72
1314730334532324632454434413731393030313431313545383446473147363 :cujlK
821 :atib jorB
.detelpmoc yllufsseccus erudecorp LQS/LP
1353431324242373
63231413632393235373836373339324141393642324241493338363334323142413136343835463
:cujlK
291 :atib jorB
Jedinu pomo koju DBMS_OBFUSCATION_TOOLKIT nudi je generisanje kljua;

dok je smetanje i uvanje kljua preputeno korisniku. Kako se sve kriptoloke operacije
izvode na serveru, a ne na klijentu, potrebno je kljueve zatititi na putu od klijent aplikacije
do servera. Ako se tako ne postupi, kljuevi mogu biti kompromitovani na putu kroz mreu.
Oracle nudi potpuno reenje kriptozatite na mrenom sloju. uvanje kljueva predstavlja
vaan deo kriptografije. Da bi podaci ponovo bili u otvorenom obliku, aplikacija koja pristupa
podacima mora da poseduje klju ili da vrednost kljua trai od korisnika. Kljuevi moraju da
budu dostupni na zahtev legalnog korisnika, bez degradacije performansi sistema. Kljuevi se
mogu uvati na sledeim mestima:
uvanje kljueva u bazi podataka
uvanje kljueva u operativnom sistemu
uvanje kljua kod korisnika
uvanje kljua u bazi podataka

uvanje kljueva unutar baze podataka predstavlja reenje koje ne nudi potpunu zatitu,
naroito ako elimo da ifrovane podatke zatitimo od DBA (DBA je u stanju da pristupi bilo
kojoj tabeli unutar baze podataka, pa samim tim i tabeli sa kljuevima. Meutim, to reenje
nudi zatitu od obinog korisnika koji pristupa bazi podataka ili od nekog ko pristupa
fajlovima baze podataka iz operativnog sistema. Kljueve kojima se ifruju podaci, moraju na
neki nain da budu zatieni kako bi bili od koristi. Na primer, ako elimo da zatitimo broj
kreditne kartice (npt. cardnum iz tabele CUSTOMER), neemo nita postii ako kljueve,
kojima se ifruju/deifruju podaci, drimo u istoj tabeli CUSTOMER. Bilo ko, ko ima pristup
tabeli CUSTOMER, moe doi do zatienih podata. Potrebno je kriptografske kljueve za
zatitu broja kartice drati u drugoj tabeli, a u tabeli CUSTOMER uvati spoljni klju
upotrebljenog kriptografskog kljua. Potrebno je razviti posebni programski modul kojim e
se pronai kriptografski klju korien u zatiti broja kreditne kartice. Klju moe dodatno da
bude kriptovan, jednostavnim algoritmom, ija e implementacija da bude implementirana u
gore pomenutom programskom modulu. Poto se PL/SQL moduli izvravaju u virtuelnoj
maini za koju postoje dekompajleri, potrebno je module dodatno zatititi kako bi
dekompajleri bili beskorisni a time kod algoritma nedostupan. Tako e napada imati ifrat,
transormisan klju ali ne i transformaciju kojom bi doao do pravog kljua a time i do
otvorene informacije. Ova ema je dovoljno sigurna da sprei obinog korisnika, sa
65
ovlaenjem itanja CUSTOMER tabele, da proita ifrovane podatke. Takoe, i DBA se

spreava da na jednostavan nain, itajui tabelu sa kljuevima, doe i do otvorenih
informacija. Ova ema moe da bude dodatno ojaana tako to e promena kljueva za
ifrovanje vriti po odreenom planu, ili to e se nain smetaja kljueva promeniti
primenom stroeg kriptografskog postupka.
uvanje kljua u operativnom sistemu

uvanje kljua u nestruktuiranom fajlu unutar operativnog sistema je druga mogunost.
Uz pomo poziva odgovarajue funkcije PL/SQL-a mogue je doi do kljua. Ako se kljuevi
uvaju u fajlu operativnog sistema, podaci zatieni na ovakav nain su sigurni koliko je
suguran fajl u kome se nalaze kljuevi. Naravno, osim pribavljanja sadraja fajla sa
kljuevima, korisnik e morati da ima pristup fajlu u kome se uvaju ifrovani podaci, ili e
kao legitimni korisnik da ima pristup tabeli u kojoj se nalaze ifrovani podaci.
uvanje kljua kod korisnika

Ako aplikacija trai od korisnika da priloi klju, vano je da se koristi zatita na
mrenom nivou, kako klju koji daje korisnik ne bi putovao od korisnika do servera u
otvorenom obliku. U sluaju da korisnik zaboravi klju podaci e biti nedostupni.
U sledeeoj tabeli je dat pregled paketa DBMS_OBFUSCATION:
Rutine
Opis
DES3DECRYPT
Deifruje ulazne podatke 3DES algoritmom
DES3ENCRYPT
ifruje ulazne podatke 3DES algoritmom
DES3GETKEY
Kori enjem 3DES algoritma, uzima kao parametar slu ajan niz, a za
izlaz daje kriptografski klju
DESDECRYPT
Deifruje ulazne podatke DES algoritmom
DESENCRYPT
ifruje ulazne podatke DES algoritmom
DESGETKEY
Kori enjem DES algoritma, uzima kao parametar slu ajan niz, a za
izlaz daje kriptografski klju
MD5
Generie MD5 he vrednost ulaznih podataka
Tabela 4: Rutine paketa DBMS_OBFUSCATION
Paket DBMS_CRYPTO
Umajui u vidu nedostatke koje je imao paket DBMS_OBFUSCATION_TOOLKIT,
u Oracle-u su stvorili PL/SQL paket DBMS_CRYPTO, koji prua vie mogunosti nego
stariji paket. Osim DES i 3DES algoritma koji su postojali i u starijem paketu, implementirani
su AES i RC4 algoritmi, HMAC funkcije su novost u novoj verziji, kao podrka za LOB
format podataka.
66
Korienje rutina paketa DBMS_CRYPTO

DBMS_CRYPTO sadi osnovne kriptografske funkcije i procedure. Paket
DBMS_CRYPTO omoguuje ifrovanje i deifrovanje jednostavnih tipova podataka,
ukljuujui tipove podataka RAW i LOB kao to je npr. zvuk i slika.
Paket omoguuje korienje:
kriptolokih algoritama:
AES
3DES (112 i 168 - bita)
DES
RC4
Kriptografskih he funkcija (kao to je SHA-1)

Ha funkcija sa kljuem (MAC) kao to je SHA-1
Dopunjavanje do punog bloka: PKCS #5 i brisanje
Izbor ulanavanja kod blok ifraskih algoritama (CBC, CFB, ECB, OFB)
Sigurnosni model
Paket DBMS_CRYPTO se instalira u SYS emi. Pristup paket se kasnije, po potrebi,
dodeljuje korisnicima ili ulogama.
Tipovi podataka
Tipovi podataka
Opis
BLOB
ulazni/izlazni binarni LOB
CLOB
ulazni/izlazni tekstualni LOB (ne raunajui NCLOB)
PLS_INTEGER
konstanta koja odreuje vrstu algoritma (koristi se sa

BLOB, CLOB, i RAW tipovima)
RAW
ulazno/izlazni RAW bafer

Tabela 5: Tip podataka koje koriste rutime iz paketa DBMS_CRYPTO
Algoritmi
U ovom paketu su predefinisani sledei kriptografski algoritmi i konstante.
Naziv
Opis
HASH_MD4
Generie 128-bitni he ulazne poruke sa MD4 algoritmom
HASH_MD5
Generie 128-bitni he ulazne poruke sa MD5 algoritmom
HASH_SH1
Generie 160-bitni he ulazne poruke sa SHA algoritmom

Tabela 6: He funkcije paketa DBMS_CRYPTO
67
Naziv
Opis
HMAC_MD5
HMAC_SH11
1
Kao i MD5 he funkcija, osim to se zahteva klju da bi se

verifikovala he vrednost
Kao i SHA he funkcija, osim to se zahteva klju da bi se
verifikovala he vrednost
U skladu je sa IETF RFC 2104 standardom

Tabela 7: MAC funkcije DBMS_CRYPTO paketa
Naziv
Opis
ENCRYPT_DES
DES blok ifarski algoritam. Duina kljua od 56 bita.
ENCRYPT_3DES_2KEY DES blok ifarski algoritam. Trostruki DES algoritam sa

dvostrukom duinom kljua, efektivna duina kljua 112
bita.
ENCRYPT_3DES
DES blok ifarski algoritam, Trostruki DES
ENCRYPT_AES128
AES blok ifarski algoritam, koristi klju duine 128 bita
ENCRYPT_AES192
ENCRYPT_AES256
ENCRYPT_RC4
Strim ifra, koristi tajni, sluajno generisani klju

jedinstven za svaku sesiju.
Tabela 8: ifarski algoritmi DBMS_CRYPTO paketa
Naziv
DES_CBC_PKCS5
DES3_CBC_PKCS5
Opis
ENCRYPT_DES1 + CHAIN_CBC2+ PAD_PKCS53
ENCRYPT_3DES1 + CHAIN_CBC2 + PAD_PKCS
1 dodatno u Tabela 8: ifarski algoritmi DBMS_CRYPTO paketa

2 dodatno u Tabela 10: Izbor ulanavanja kod blok ifarskih sistema paketa
DBMS_CRYPTO
3 dodatno u Tabela 11: Dopunjavanje bloka blok ifara u paketu DBMS_CRYPTO
Tabela 9: DBMS_CRYPTO Blok ifarski paketi
Naziv
Opis
CHAIN_ECB Elektronska kodna knjiga. ifruje svaki blok nezavisno.

CHAIN_CBC Ulanani ifarski blok. Otvoreni tekst je XOR-ovan sa
prethodnim ifarskim blokom pre enkripcije.
CHAIN_CFB
ifrat u povratnoj sprezi. Omoguuje ifrovanje manjih

blokova od duzine bloka.
CHAIN_OFB Izlazna povratna sprega. Omoguuje korienje blok ifre

kao sinhrone strim ifre. Slian kao i CFB, osim to se n-bita
prethodnog izlaznog bloka prebacuje u krajnju desnu
poziciju niza koji eka na ifrovanje.
Tabela 10: Izbor ulan avanja kod blok ifarskih sistema paketa DBMS_CRYPTO
68
Naziv
Opis
PAD_PKCS5 Dopunjavanje bloka koji je u skladu sa

PKCS #5: Password-Based Cryptography Standard
PAD_NONE
Ne vri se dopunjavanje. Duina bloka mora biti

odgovarajua ili e paket da vrati greku.
PAD_ZERO
Dopunjavanje bloka se vri binarnim nulama.
Tabela 11: Dopunjavanje bloka blok ifara u paketu DBMS_CRYPTO
Ogranienja
Tip VARCHAR2 nije podran. Da bi se tip VARCHAR2 ifrovao potrebno ga je
pretvoriti u kodni raspored AL32UTF8 a posle toga pretvoriti u tip podataka RAW. Tek posle
ovih konverzija je mogue ifrovanje podataka tipa VARCHAR2.
Izuzeci
Izuzetak
Opis
CipherSuiteInvalid
28827
Zahtevani ifarski sistem nije definisan.
CipherSuiteNull
28829
Nije postavljen ifarski sistem.
KeyNull 28239
ifarski klju nije odreen ili ima NULL vrednost.
KeyBadSize 28234
DES kljuevi: Data duina kljua je premala. DES kljuevi

moraju biti barem 8 bajta (64 bita).
AES kljuevi: Zahtevana duina kljua nije podrana. AES
kljuevi moraju da budu duine 128, 192, ili 256 bita.
DoubleEncryption
28233
Izvorni podataka je ve ifrovan

Tabela 12: Izuzeci u paketu DBMS_CRYPTO
Korienje He ili Message Authentication Code (MAC) funkcija

Ovaj paket sadri dva tipa jednosmernih he funkcija: HASH funkcije i MAC funkcije.
Hash funkcije rade nad ulaznom porukom proizvoljne duine a kao rezultat rada vraa he
vrednost fiksne duine. He vrednost se moe koristiti za proveru integriteta podataka. He
vrednost odgovara "otisku prsta" neke poruke. He funkcija u paketu DBMS_CRYPTO je
jednosmerna funkcija koja moe generisati he vrednosti od podataka tipa RAW ili LOB.
MAC funkcija je takoe jednosmerna he funkcija sa kljuem. Radi na isti nain kao i
DBMS_CRYPTO.HASH funkcija, osim to proveru he vrednosti moe da uradi vlasnik
kljua. MAC se moe koristiti radi autentikacije datoteka uzmeu korisnika. Takoe,
pojedinac moe da koristi MAC funkciju radi provere integriteta datoteka. Nad odreenim
datotekama se rauna HMAC i stavlja se u posebnu tabelu. Ako bi se raunao samo HASH
tada bi npr. virus mogao da izmeni datoteku a novi HASH smesti u posebnu tabeli i time
69
zamaskirao uinjenu izmenu datoteke. Ovako virus ne zna klju i ne moe da generie
ispravan HASH izmenjene datoteke.
Generisanje i uvanje kljua

Paket DBMS_CRYPTO moe samo da pomogne pri generisanju kljueva za ifrovanje
tako to e generisati kriptoloki dobar niz preudosluajnih brojeva. Mehanizam koji bi
pomogao u odravanju kljueva nije obezbeen. Sigurno generisanje i uvanje kljueva je
preputeno programerima. Takoe treba imati u vidu da se ifrovanje i deifovanje izvrava
na serveru a ne na klijentu. to znai da se klju od klijenta do servera mora preneti u
zatienom obliku.
Iako paket DBMS_CRYPTO nije u stanju automatski da generie kljueve, uz pomo
funkcije RANDOMBYTES moe da generie pseudosluajan niz koji e posluiti kao
materijal za klju. Treba imati u vidu da postoje slabi kljuevi za DES algoritam, i da je
potrebno pre korienja generisanih kljueva izvriti filtriranje poznatih slabih DES kljueva.
Spisak poznatih slabih DES kljueva je dostupan na nekoliko Internet lokacija, a postoji i
obomna literatura o tom problemu9.
Pravila za konverziju tipova parametara

Pretvaranje VARCHAR2 u RAW tip korienjem funkcije
UTL_I18N.STRING_TO_RAW u sledea dva koraka:
o
o
Pretvaranje VARCHAR2 iz teku eg karakter seta u VARCHAR2 u AL32UTF8

karakter set.
Pretvaranje VARCHAR2 tipa koji je u AL32UTF8 karakter setu u RAW tip.
Primer sintakse:
UTL_I18N.STRING_TO_RAW (string, 'AL32UTF8');
Pretvaranje RAW u VARCHAR2 tip korienjem UTL_I18N.RAW_TO_CHAR

funkcije u sledea dva koraka:
o Pretvoriti RAW u VARCHAR2 tip koji je u AL32UTF8 karakter setu.
o Pretvoriti AL32UTF8 karakter set u odgovarajui.
Primer sintakse:
UTL_I18N.RAW_TO_CHAR (data, 'AL32UTF8');
U sluaju da je potrebno sauvati ifrovan podataka RAW tipa unutar polja baze
podataka
koje
je
VARCHAR2
tipa
koristi
se
RAWTOHEX
ili
UTL_ENCODE.BASE64_ENCODE koje e binarni podataka da konvertuju u prihvatljiv
9
Lars Ramkilde Knudsen, New Potentially 'Weak ' Keys for DES amd LOK, SpringerLink, 1995
Reinhard Wobst, Cryptology Unlocked, Wiley, 2007
70
format za VARCHAR2 tip podatka. Treba voditi rauna da funkcija RAWTOHEX na izlazu
daje niz koji je dva puta vei od ulaznog niza a funkcija BASE64_ENCODE za 4/3 duine
ulaznog niza.
6.2. IBM DB2

Kao i veina drugih relacionih baza podataka i IBM-ov DB2 nudi ugraene funkcije za
ifrovanje i deirovanje: ENCRYPT, DECRYPT_BIN, DECRYPT_CHAR, i GETHINT.
ifarski algoritam koji se koristi kod funckija za ifrovanje odnosno za deifrovanje je RC2
blok ifarski algoritam sa dopunom, a 128-bitni tajni klju se dobija saimanjem lozinke
korienjem MD2 algoritma.
Funkcija: ENCRYPT
Sintaksa:
ENCRYPT( otvoreni-tekst {, lozinka-tekst {, asocijacija-tekst } })
Funkcija ENCRYPT vraa vrednost koja je rezultat ifrovanja otvorenog teksta.
Parametar otvoreni-tekst mora biti izraz koji je CHAR ili VARCHAR tipa. Maksimalna
duina otvorenog teksta moe biti 32663 znakova ako se ne odredi parametar asocijacija-tekst
odnosno 32631 znakova ako se odredi. Parametar lozinka-tekst predstavlja lozinku ili ako se
ne specificira koristi se lozinka sesije koja se zadaje naredbom SET ENCRYPTION
PASSWORD. Mora biti izraz tipa CHAR ili VARCHAR sa najmanje 6 bajta a ne vie od 127
bajta. U sluaju da se ne zada, koristi se lozinka sesije koja se zadaje naredbom SET
ENCRYPTION PASSWORD i koja mora biti postavljena pre upotrebe funkcija za ifrovanje
odnosno deifrovanje. Parametar asocijacija-tekst predstavlja izraz tipa CHAR ili VARCHAR
sa maksimalno 32 bajta. To je fraza koja e biti ubaena u ifrat, a moe da pomogne
korisniku da se priseti lozinke. Na primer, ako za lozinku koristimo re GODZILA, koji je
ujedno i naziv kunog ljubimca onda e se re LJUBIMAC koristiti kao asocijacija na
lozinku. Rezultat je tip VARCHAR FOR BIT DATA.
Duina izlaznog niza je:
Kada je zadan parametar asocijacije na lozinku:

duina otvorenog teksta + 8 bajta + dopuna do punog bloka od 8 bajta + 32 bajta za
asocijaciju.
Kada je izostavljena asocijacija na lozinku:

duina otvorenog teksta + 8 bajta + dopuna do punog bloka od 8 bajta.
Prilikom dizajna tabela baze treba voditi rauna o duini polja koja e da uvaju
ifrovanu vrednost.
71
Primer 1: Korienje lozinke sesije:

SET ENCRYPTION PASSWORD = 'FIM209';
INSERT INTO STUDENT(PID) VALUES ENCRYPT('29-01-9668934');
Primer 2: Eksplicitno postavljanje lozinke:

INSERT INTO STUDENT(PID) VALUES ENCRYPT('29-01-9668934',' FIM209');
Primer 3: Asocijacija 'Ljubimac' se smesta zajedno sa ifratom u polje PID:

INSERT INTO STUDENT(PID) VALUES ENCRYPT('29-01-9668934', 'Godzila',
'Ljubimac');
Funkcije: DECRYPT_BIN i DECRYPT_CHAR

Sintaksa:
DECRYPT_BIN enc-data {, lozinka}
DECRYPT_CHAR enc-data {, lozinka}
Funkcije DECRYPT_BIN i DECRYPT_CHAR kao rezultat vraaju deifrovane ulazne
ifrovane podatke. Lozinka koja se koristi pri deifrovanju moe biti eksplicitno odreena u
komandi kao drugi parametar. Ako se izostavi podrazumeva se da je prethodno postavljena sa
naredbom SET ENCRYPTION PASSWORD. Ove funkcije su u stanju da deifruju samo one
podatke koji su rezultat rada funkcije ENCRYPT. ifrovani podaci su podaci koji se nalaze u
izrazima koji su tipa CHAR FOR BIT DATA ili VARCHAR FOR BIT DATA. Ogranienja
koja se postavljaju nad lozinkom koja se koristi pri ifrovanju vae i ovde duina lozinke je
izmeu 6 i 127 znakova. U sluaju da se specificira lozinka koja nije koriena za ifrovanje
sistem e da prijavi greku. U sluaju da se drugi parametar izostavi ili ako ima NULL
vrednost koristie se globalna lozinka postavljena naredbom SET ENCRYPTION
PASSWORD.
Povratna vrednost funkcije DECRYPT_BIN je VARCHAR FOR BIT DATA, a
povratna vrednost funcije DECRYPT_CHAR je VARCHAR. U sluaju da je prilikom poziva
ENCRYPT funkcije odreena i asocijacija na lozinku, ona se prilikom poziva funcija za
deifrovanje ne vraa. Duina povratnog niza znakova e biti ista kao i duina origalnog niza
znakova otvorenog teksta.
U sluaju da se podaci deifruju na sistemu koji koristi kodnu stranicu koja se razlikuje
od kodne strane sistema na kome su podaci ifrovani, mogue je da duina izlaznog niza ne
bude ista kao i duina poetnog otvorenog teksta usled konverzije kodnih rasporeda.
Primer 1: Korienje naredbe SET ENCRYPTION PASSWORD za postavljanje sesijske
lozinke
SET ENCRYPTION PASSWORD = 'FIM209';
INSERT INTO STUDENT(PID) VALUES ENCRYPT('29-01-9668934');
72
SELECT DECRYPT_CHAR(PID) FROM STUDENT;

Kao povratna vrednost dobija se niz: '29-01-9668934'.
Primer 2: Eksplicitno korienje lozinke.
INSERT INTO STUDENT(PID) VALUES ENCRYPT('29-01-9668934', 'FIM209');
SELECT DECRYPT(PID, 'FIM209') FROM STUDENT;
Kao povratna vrednost dobija se niz: '29-01-9668934'.
Naredba: SET ENCRYPTION PASSWORD

Prilikom svakog poziva funkcija ENCRYPT, DECRYPT_BIN i DECRYPT_CHAR
potrebno je odrediti lozinku koja e se koristiti pri ifrovanju ili deifrovanju. Ako se to ne
uradi koristie se globalna lozinka. Naredba kojom se postavlja globalna lozinka je SET
ENCRYPTION PASSWORD. Ova lozinka nije u sprezi sa autentikacijom koja postoji u DB2
ve joj je jedina namena ifrovanja i deifrovanja podataka. Ova naredba nije pod
transkcionim upravljanjem.
Naredba moe biti pozvana interaktivno ili iz aplikacije.
Sintaksa:
SET ENCRYPTION PASSWORD host-varijabla
ili
SET ENCRYPTION PASSWORD 'stringconstant'
Duina lozinke mora da bude izmeu 6 i 127 bajta. Sistem razlikuje velika od malih
slova tako da je potrebno voditi rauna o tome. Ako se koristi host-variabla ona mora da bude
tipa CHAR ili VARCHAR. Duina host-variable takoe mora da bude izmeu 6 i 127 bajta.
Inicijalna vrednost lozinke za ifrovanje je prazan niz znakova ('').
Primer 1: Postavljanje lozinke za ifrovanje
SET ENCRYPTION PASSWORD = 'Sez@me0tv0r1S3'
Funkcija: GETHINT
Sintaksa:
GETHINT( enc-data )
Funkcija GETHINT vraa asocijaciju na lozinku koja je koriena pri ifrovanju
podataka. U pitanju je fraza koja e vlasniku lozinke pomoi da je se priseti ako je zaboravio.
Parametar
enc-data je ifrat dobijen korienjem funkcije ENCRYPT i tipa je CHAR FOR BIT DATA
ili VARCHAR FOR BIT DATA. Rezultat rada funkcije GETHINT je VARCHAR(32). U
sluaju da nije zadavana asocijacija prilikom ifrovanja podatka, tada e funkcija da vrati
NULL vrednost.
73
U sledeem primeru asocijacija 'Ljubimac' je smetena zajedno sa ifratom da bi

pomogla korisniku da se priseti lozinke 'GODZILA'.
INSERT INTO EMP (SSN) VALUES ENCRYPT('289-46-8832', 'Godzila', 'Ljubimac');
SELECT GETHINT(SSN) FROM EMP;
Povratna vrednost je 'Ljubimac'.
6.3. Microsoft SQL Server

O kriptografskoj zatiti podataka se u SQL Serveru 2008 vodilo rauna od samog
poetka. SQL Server koristi jake kriptografske tehnike kako bi zatitio podatke. Sledi prikaz
kriptografskih mogunosti SQL Server 2008. Kriptografski kljuevi tite podatke, to znai
da je zatita samih kljueva centalno mesto u kriptografiji. SQL Server je u stanju da sam vri
upravljanje kljuevima, a to upravljanje moe da prepusti i samom korisniku. Implementirana
je hijerarhija kljueva, koja omoguuje kreiranje tri tipa kljueva koji se kasnije koriste u
zatiti podataka.
SQL Server 2008 nudi niz karakteristika koje nisu postojale u prethodnim verzijama
sistema, i omoguuje vieslojan sistem zatite i na taj nain podrava princip zatita po
dubini. Zatita po dubini podrazumeva da napada nije u stanju da pree neki sloj zatite ako
nije reio prethodni sloj zatite, i gde je svaki naredni sloj tei za probijanje.
Kriptografski elementi ugraeni u SQL Server 2008 omoguuju razne kriptografske
algoritme kao i mogunost upravljanja kljuevima. Da bi se dala mogunost korienja
ugraene kriptografije u SQL Serveru, bilo je potrebno proiriti Transact-SQL novim
naredbama i funkcijama. Arhitektura upravljanja kljuevima se zasniva na hijerarhijskom
upravljanju i omoguuje transparentno korienje kriptografije u ve postojeim aplikacijama.
Postoji i mogunost da sam korisnik upravlja kljuevima, to dodatno obezbeuje sistem od
potencijalnog malicioznog administratora baze podataka.
SQL Server 2008 koristi ifrovanje kada je potrebno da zatiti podatke bez obzira da li
se podaci smetaju u bazu podataka ili se transportuju komunikacionim kanalom van baze.
Podaci se mogu ifrovati prilikom snimanja u bazu podataka, a deifrovati samo prilikom
njihovog izuzimanja od strane autorizovanog korisnika. Prikazane su mogunosti kriptografije
ugraene u SQL Server 2008, kako se one mogu koristiti za zatitu podataka i kako korisnik
tih podataka moe da do njih doe. Prikazani su razliiti kljuevi koji se koriste unutar baze
podataka, koji se koriste kako za zatitu podataka tako i za zatitu samih kljueva.
74
Kriptografija u SQL Serveru 2008

Kriptografija ugraena u SQL Server podrava tri tipa kriptografije, svaki tip koristi
razliit tip kljua i svaki sa viestrukim agoritmima i duinama kljua.
Kriptografija sa simetrinim kljuem je ona u kome se koristi isti klju i za ifrovanje i
za deifrovanje. Zahtev je da entitet koji vri ifrovanje ima isti klju kao i entitet koji e te
podatke da deifruje. To znai da je klju kojim se podaci ifruju / deifruju deljena tajna koju
je mogue sauvati ako se uva unutar SQL Servera.
Nisu svi kriptografski algoritmi podrani na svim Microsoft platformama. Microsoft
preporuuje korienje AES algoritma ako on postoji na serveru, a ako ne onda 3DES.
Asimetrina kriptografija, je ona u kojoj su kljuevi za ifrovanje i deifrovanje razliiti.
SQL Server podrava RSA algoritam sa kljuevima od 512, 1024 i 2048 bita.
Sertifikati su jo jedna forma asimetrine kriptografije. Sertifikati koriste digitalni
potpis kako bi par privatni i javni klju pridruili njihovom vlasniku. SQL Server koristi IETF
X.509 v3 specifikaciju, i moe koristiti interno generisane sertifikate, kao i sertifikate
generisane od strane CA. Sertifikati koriste RSA algoritam za enkripciju.
Ugraeno ifrovanje u Transact-SQL

Da bi ifrovanje bilo potpuno podrano na serveru, bilo je potrebno modifikovati TSQL kako bi ifrovanje / deifrovanje kao i upravljanje kljuevima bilo dostupno dizajnerima
sistema. Prilog 1: Ugraena kriptografija u Transact-SQL prikazuje kriptografske iskaze i
funkcije koji se najee koriste, kao i dozvole potrebne za njihovo korienje. Kao to se iz
priloga moe videti, upravljenje enkripcijom zahteva relativno visoke privilegije. Stoga,
administrator ili vlasnik baze podataka sa velikom panjom treba da odlui kome e dati te
privilegije.
Veina stavki iz priloga e biti prikazane ali pre svega e biti prikazani zajedniki
elementi, poevi sa dozvolama.
Sve CREATE naredbe sadre iskaz AUTHORIZATION koji daje vlasnitvo nas
objektom odreenom korisniku. Upravljanje vlasnitvom nad objektima je u verziji
SQL Servera 2008 lake nego to je to bilo u prethodnim verzijama, ali pre davanja vlasnitva
potrebno je dobro razmisliti kome se daje to pravo, imajui na umu bezbednost servera. Iskaz
AUTHORIZATION je vaan kod kriptografije jer da bi ifrovao/deifrovao podatke korisnik
mora da bude vlasnik nad nekoliko kljueva potrebnih za izvrenje aktivnosti. Alternativno,
korisnik mora da ima dozvolu CONTROL nad kljuevima i sertifikatima.
75
Centralno mesto gde se odvija kriptografija u serveru su nove Transact-SQL funkcije.

Sve funkcije koje implementiraju algoritme sa simetrinim kljuem mogu da vrate podatke
tipa varbinary maksimalne duine od 8000 bajta. To znai da nije mogue ifrovati onaj tip
podatka koji eja veliina prevazilazi ovo ogranienje. U takvim prilikama je potrebno ulazne
podatke podeliti na manje celine, iji e izlaz iz kripto funkcije biti manji od 8000 bajta.
Slino je i prilikom deifrovanje, funkcije koje deifriju vraaju niz od najvie 8000 bajta.
Kako funkcije za deifrovanje (kao i funkcije za ifrovanje) kao izlazni podataka
vraaju podatak tipa varbinary, potreno je eksplicitno izvriti konverziju izlaznih rezultata u
odgovarajui tip, kako ne bi dolo do kolizije pri upotrebi tih podataka.
Funkcije koje ifruju, koristei asimetrini klju ili sertifikat, za ulaz mogu da prime niz ija
se duina rauna po formuli: [duina kljua] mod 8 11.
Razmatranja
Prilikom odluivanja o korienju kriptografije potrebno je razmisliti o performansama
koje se tom prilikom degradiraju. Enkripcija je procesorski intenzivna operacija. Uopteno
govorei, to je algoritam sigurniji, a klju dui, to se zahteva vea procesorska snaga. To
znai da e kriptografska zatita svih podataka u iole veoj bazi, blokirati rad servera bez
obzira na hardversku platformu. Sledei problem je to odreeni algoritni kod ifrovanja daju
niz ija je duina vea od ulaznog niza. Koliko e to poveanje biti, zavisi od samog
algoritma, duine kljua, i od otvorenog teksta koji se ifruje. Radi testiranja kreiran je
Transact-SQL skript koji ifruje niz znakova tipa varchar duine 10, 31 i 83 bajta koristei
sve algoritme raspoloive u SQL serveru. Rezultati su prikazani u tabeli 12. T-SQL skript
ifruje string i belei duinu ifrata funkcijom DATALENGTH(). Svaka stavka u tabeli
prikazuje uveanje ifrovanih podataka u odnosu na otvoreni tekst. Tako je za 3DES
algoritam minimalno poveanje 45% ifrata u odnosu na otvoreni tekst.
Algoritam
3DES
AES 128
AES 192
AES 256
Sertifikat
DES
DESX
RC2
RC4
RSA 1024
RSA 2048
RSA 512
Maksimalno
poveanje
3.80
5.40
5.40
5.40
11.80
3.80
3.80
3.80
3.60
11.80
24.60
5.40
Minimalno
poveanje
0.45
0.54
0.54
0.54
0.54
0.45
0.45
0.45
0.43
0.54
2.08
1.06
Proseno
poveanje
1.77
2.51
2.51
2.51
5.16
1.77
1.77
1.77
1.73
5.16
11.31
3.23
Tabela 13: Pove anje duina izlaznog ifrata u odnosu na ulazni otvoreni tekst
76
Kao to se moe videti iz tabele 12. postoje znatne razlike u tome koliko koji algoritam
uveava ulazne podatke, i to od 43% pa do 2460%. (Ovako visok procenat uveanja je
dobijen kada se niz od 10 znakova ifrovao RSA algoritmom sa kljuem od 2048 bita, ime se
dobija ifrovani niz od 256 bajta. Prilikom implementacije kriptografske zatite podataka
treba imati na umu i ovaj problem.
Upravljanje kljuevima
Najvei problem koji treba reiti kod primene kriptografije je rukovanje kljuevima.
Centralno mesto u zatiti podataka pripada zatiti kriptografskih kljueva. Osim to je, u
odnosu na prethodnu verziju SQL servera 2000, dodato mnotvo funkcija za ifrovanje i
deifrovanje, ugraeni su i mehanizmi za upravljanje, smetanje i zatitu kriptografskih
kljueva. Osim toga, upravljanje kljuevima je implementirano hijerarhijski, gde je svaki vii
nivo zaduen da titi kljueve na sloju ispod sebe. Server podrava i scenario u kome
aplikacija, odnosno korisnik, moe da upravlja samostalno sa kljuevima. Veina opcija za
kreiranje kriptolokih kljueva dozvoljava korienje lozinke kako bi se zatitio klju. U
sluaju da se ta opcija koristi, na korisniku ostaje obaveza da prilikom legitimnog
ifrovanja/deifrovanja priloi traenu lozinku, i naravno da je uva.
Hijerarhija kljueva
Kao to je reeno, zatita i uvanje kljueva je jedna od najvanijih stvari u zatiti
podataka. Sa izuzetkom javnog kljua kod asimetrine kriptografije, klju treba da bude
zatien od neautorizovanog korienja. Bez obzira na kvalitet algoritma, on postaje
bezvredan u sluaju da klju dospe u pogrene ruke. SQL Server implementrira hijerarhiju
kljueva gde svaki nivo tite kljueve na sloju ispod sebe, kao to je prikazano na slici xxx.
Svaka strelica prokazuje na kljueve koje titi.
77
DPAPI, OS nivo
ITIT
SQL Server
Service Master Key
ITIT
AKNIZOL
AKNIZOL
Master klju
baze podataka
IVEUJLK
INIRTEMISA
ITAKIFITRES
IVEUJLK
INIRTEMIS
AKNIZOL
IVEUJLK
INIRTEMIS
IVEUJLK
INIRTEMIS
ICADOP
ICADOP
ICADOP
Slika 10: Hijerarhija klju eva u SQL Serveru 2008
Na vrhu hijerarhije je Data Protection API, ili skraeno DPAPI, koji je deo operativnog
sistema i nalazi se u podsistemu Crypto32. DPAPI je uveden pojavom Windows 2000
operativnog sistema, kao podsistem za uvanje kljueva unutar operativnog sistema. to se
tie SQL Servera 2008 DPAPI titi serverov master klju, koji je glavni klju za svaku
instancu SQL Servera koja je instalirana na raunaru. Servis master klju titi master klju
baze podataka, koji je potreban za svaku bazu podataka koja se nalazi na serveru. Master klju
baze podataka titi sve kljueve koje korisnik kreira, sertifikate, i asimetrine kljueve. Kao
to se vidi na slici 7, master klju baze podataka titi setifikate i asimetrine kljueve. Svaki
od ovih kljueva moe da titi simetrine kljueve, a simetrini kljuevi mogu da tite ostale
simetrine kljueve. Dodatno, svaki od kljueva na nivou baze podataka korisnik moe tititi
lozinkom, i na taj nain preuzeti odgovornost zatite lozinke na sebe. Prilikom dizajna sistema
78
kriptografske zatite treba imati na umu ovu hijerarhiju jer se prilikom svakog kljua
generisanog u bazi treba odluiti kojim kljuem ga titimo.
Kljuevi za ifrovanje
SQL Server obezbeuje dve vrste kljueva: ugraene i korisnike kljueve. Ugraeni
kljuevi su za interne kriptografske servise kao to su zatita kljueva baze podataka, kao i
kljueva koje generie korisnik.
Ugraeni kljuevi
Postoje dva tipa ugraenih kljueva u SQL serveru, servis master klju i master klju
baze podataka za svaku bazu posebno. Iako se ovi kljuevi ne mogu eksplicitno da koriste u
ifrovanju / deifrovanju, oni se koriste implicitno.
Master klju SQL servera

Servis master klju je na vrhu hijerarhije svih kljueva kojima SQL server upravlja.
Poto taj klju titi sve kljueve unutar SQL servera, on je veoma vaan klju. On se
automatski kreira prilikom instalacije SQL servera i ne zahteva nikakvo upravljanje, osim to
bi ga trebalo arhivirati na sigurno mesto van servera. Postoji samo jedan servis master klju za
svaki instaliranu instancu servera. Korisnik ga ne moe ni kreirati ni unititi. Sam klju je pod
zatitom DPAPI (Data Protection API) iz Windows operativnog sistema. Kao i svi kljuevi
koji su pod zatitom DPAPI, klju se titi korienjem akreditiva ulogovanog korisnika. to
se tie SQL servera, korisnik je u stvari servis nalog pod kojim SQL servis radi. To znai da
bilo ko, ko ima pristup tom nalogu moe da pristupi servis master kljuu, to jo jednom
naglaava strogu kontrolu ko moe da pristupi nalogu pod kojim SQL server radi.
Servis master klju direktno titi razliite interne podatke ukljuujui lozinke za
linkovane servere, master kljueve baze podataka kao i mapirane akreditive naloga. Ne
postoji direktan pristup servis master kljuu unutar servera, jedina stvar koja se moe uraditi
je njegovo odravanje. Jedna od prvih stvari koje treba uraditi posle instaliranja SQL servera
je arhiviranje, i to se moe uraditi sa sledeom naredbom:
BACKUP SERVICE MASTER KEY TO FILE = 'C:\KLJUC.DAT'
ENCRYPTION BY PASSWORD = '(/&jzgaWoG1J_)(*(&lkjKwH,4kBYg;]\'
Lozinka u ovoj naredbi ifruje master klju, tako da master klju ne naputa server u
otvorenom obliku. Potrebno je da lozinka bude kvalitetna i da moe da se upamti. (to je u
kontradikciji jedno sa drugim, teko da neko moe da zapamti lozinku koja je data u primeru).
Ako postoji potreba da se restaurira servis master klju to se radi sa naredbom:
RESTORE SERVICE MASTER KEY FROM FILE = ' C:\KLJUC.DAT '
79
DECRYPTION BY PASSWORD = '(/&jzgaWoG1J_)(*(&lkjKwH,4kBYg;]\'

Osim arhiviranja i povraaja, servis master klju se moe i regenerisati. Ovu akciju bi
trebalo izvesti samo u sluaju kompromitovanja master kljua. (Moda bi klju trebao i da se
regenerie u pravilnim vremenskim intervalima, kad klju ostari, gde se vremenski interval
odreuje zahtevanim nivoom zatite). Proces regeneracije se interno odvija u vie koraka. Svi
kljuevi ispod servis master kljua se deifruju starim kljuem, generie se novi servis master
klju, pa se njime ifruju svi kljuevi ispod njega. Ako postoji veliki broj kljueva ispod
servis master kljua, ovakva akcija moe da bude procesorski intenzivna, pa se preporuuje da
se uradi u vreme slabe aktivnosti servera. Sledea naredba regenerie servis master klju:
ALTER SERVICE MASTER KEY REGENERATE

Postoji mogunost da ova naredba ne uspe. To se moe desiti ako se tekui master klju
ne moe da preuzme, ili se kljuevi ispod master kljua na mogu da deifruju starim master
kljuem. Ako se to desi, izvrenje naredbe se prekida i dobija se poruka o greci. U sluaju da
ipak elimo uradimo regenerisanje, potrebno je koristiti kljunu re FORCE, i u tom sluaju
e svi kljuevi ispod master kljua biti zauvek izgubljeni, raunajui i podatke koji su
ifrovani tim kljuevima. Ova opcija je zgodna u sluaju kompromitacije master kljua, i
radije emo unititi kljueve koji tite podatke, nego izgubiti same podatke (podrazumeva se,
naravno, da je prethodno uraena arhiva koju moemo kasnije da restauriramo).
ALTER SERVICE MASTER KEY FORCE REGENERATE
Podaci koji se ne mogu ponovi da ifruju sa naredbom REGENERATE nisu izgubljeni.
Oni se mogu vratiti ako postoji arhivirani servis master klju, a restauracija se vri opcijom
FORCE.
Servis master klju je resurs servera, pa se T-SQL naredba koja njime manipulie moe
izvriti u kontekstu bilo koje baze.
Master klju baze podataka

Sledei klju koji je u hijerarhiji nie od SQL servera je master klju baze. Master klju
baze titi sve kljueve unutar odreene baze. To je simetrini klju koji se koristi direktno od
strane samog servera, a ne od strane korisnika odnosno aplikacija. Postoji samo jedan master
klju po bazi, pokuaj da se kreira jo neki prouzrokuje greku.
Master klju baze podataka se ne kreira automatski po kreiranju baze podataka, ve se
mora kreirati runo, pre kreiranja kljueva za ifrovanje unutar baze:
USE bps
CREATE MASTER KEY ENCRYPTION BY PASSWORD =
'KoR@n0R4n1Ce0DaHZ3wa'
80
proverom se moe ustanoviti da je klju zaista kreiran:

select name from sys.symmetric_keys;
go
name
-------------------------------------##MS_DatabaseMasterKey##
Iako je poznato da se master klju baze ifruje master kljuem severa (servis master),
postavlja se pitanje emu slui opcija PASSWORD pri kreiranju master kljua baze. To je
zbog toga to se master klju baze podataka ifruje i smeta na dva razliita mesta. Jedna
kopija se ifruje master kljuem servera i smeta se u bazui sa imenim master. Druga kopija se
ifruje algoritmom 3DES a klju se generie na osnovu date lozinke i smeta se u samu bazu.
Ako master klju baze postoji, mogue je iskljuiti njegovu zatitu servis master kljuem
korienjem naredbe ALTER MASTER KEY. Ova naredba uklanja klju iz baze master:
ALTER MASTER KEY DROP ENCRYPTION BY SERVICE MASTER KEY
To praktino znai da se master klju baze podataka ne moe otvoriti sa master kljuem
servera, i mora se eksplicitno otvoriti pre upotrebe. Ako se kasnije odluimo da vratimo
masterk klju baze podataka pod zatiti servis master kljua to se moe uraditi naredbom:
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY
Zatita master kljua baze podataka lozinkom je korisna stvar kod premetanja baze
podataka sa jednog servera na drugi. Prilikom odvajanja baze podataka od servera, iz master
baze se uklanja stavka vezana za bazu koja se seli, a istovremeno se uklanja i kopija master
kljua baze koja je pod zatitom servis master kljua. Kada se baza prebaci na novi server, na
tom novom serveru master servis klju je drugaiji, i zatita master kljua baze podataka se ne
uspostavlja automatksi. Da bi se zatita master kljua baze uspostavila sa novi servis master
kljuem, potrebno je otvoriti master klju baze sa lozinkom koju smo dali prilokom njegovog
kreiranja. Posle toga treba upotrebiti naredbu ALTER MASTER KEY da bi se master klju
baze ifrovao servis master kljuem, i da bi se tako zatieni klju smestio u bazu sa imenom
master. To je obrazloenje zato je zgodno imati master klju baze podataka i samom bazi
ifrovan lozinkom.
Master klju baze podataka se uklanja naredbom DROP:
DROP MASTER KEY
1> drop master key
2> go
1> select name from sys.symmetric_keys;
2> go
name
---------------------------------------------(0 rows affected)
81
Master klju baze podataka se moe arhivirati i ponovo vratiti. Dobra je ideja da se
master klju baze podataka arhivira, pre dodavanja kljueva u bazu, u sluaju problema sa
master kljuem baze podataka. Naredba kojom se arhivira klju je:
BACKUP MASTER KEY TO FILE = 'C:\DBKLJUC.DAT'
ENCRYPTION BY PASSWORD = 'Ak0Laz3KoZ@HeL4ZeROG'
Lozinka data u naredbi se koristi za ifrovanje master kljua baze, i tako ifrovan, klju
se upisuje u datoteku. Kasnije se klju moe uzeti u upotrebu sa naredbom RESTORE
MASTER KEY. Lozinka posle iskaza DECRYPTION BY PASSWORD mora biti ista ona
lozinka koja je upotrebljena u vreme arhiviranja (naredba BACKUP MASTER KEY). Kad
se kljue baze deifruje on se mora ponovo ifrovati kako bi se smestio u bazu. Za tu svrhu
koristimo iskaz ENCRYPTION BY PASSWORD. Ova lozinka moe biti ista ona koja je
koriena kod arhiviranja a moe da bide i neka druga.
RESTORE MASTER KEY FROM FILE = 'C:\DBKLJUC.DAT'
DECRYPTION BY PASSWORD = ' Ak0Laz3KoZ@HeL4ZeROG '
ENCRYPTION BY PASSWORD = 'Sw3J3Ist0S4moNj3g4Nema'
Jednom kad master klju postoji unutar baze podataka, mogue je kreirati kljueve
kojima upravlja SQL server. Treba imati na umu da je master klju baze podataka potreban
samo kod korienja kljueva kojima upravlja SQL server. Ako koristimo kljueve kojima
upravljaju korisnici, upotrebom lozinki, master klju baze podataka nije potreban.
Korisniki kljuevi
Druga vrsta kljueva u SQL serveru su korisniki kljuevi. Postoji etiri vrste korisnikih
kljueva i to su:
sertifikati,
asimetrini kljuevi,
simetrini kljuevi,
i lozinke.
Sertifikati
Sertifikat podrazumeva korienje asimetrinih kljueva, odnosno parova tajnog/javnog
kljua. Sertifikat je u stvari digitalno potpisan objekt, koji pridruuje javni klju entitetu koji
poseduje tajni klju. Sertifikat se moe shvatiti kao ovojnica oko javnog kljua. Veina
sertifikata vodi poreklo od sertifikacionog tela kao to je to npr. Verisign ili Thawte ili od
internog sertifikacionog autoriteta kao to je Microsoft Certificate Server. SQL server je isto u
stanju da kreira sertifikate koji se mogu koristiti jedino unutar servera. Sertifikati se oslanjaju
82
na specifikaciju IETF X.509 v3. Treba znati da SQL server ne vri proveru kod eksternog
sertifijkacionog tela, i ne podrava opoziv sertifikata.
Naredba CREATE CERTIFICATE se koristi da bi se sertifikat uneo u bazu podataka,
gde e biti dostupan za ifrovanje podataka. Sertifikat se moe kreirati, uitati iz datoteke,
uitati iz programa koji je potpisan sertifikatom, uitati iz CLR sklopa koji je ve uitan u
CLR unutar SQL servera. Sledea naredba kreira, novi, interni SQL server sertifikat iji je
vlasnik dbo u tekuoj bazi (ako je tekui korisnik dbo):
CREATE CERTIFICATE dboCert
WITH subject = 'Sertifikat korisnika dbo'
Poto u gornjoj naredbi nije data klauzula ENCRYPTION BY, privatni klju jer
ifrovan master kljuem baze. Privatni klju se moe zatititi i lozinkom ako u sledeem
primeru:
CREATE CERTIFICATE FinCERT AUTHORIZATION Petar
ENCRYPTION BY PASSWORD = 'UjkM/(%fdCr1J40oO='
WITH subject = 'Sertifikat finansijskog'
Obe ove naredbe kreiraju samopotpisani, interni sertifikat. Iskaz WITH odreuje
SQL Server da tekstualnu vrednost smesti i polje subject (koje predstavlja metapodatak
specifikacije X.509 i slui za identifikaciju sertifikata). Polje subject je ogranieno na
4096 znakova. Ostale opcije u WITH iskazu odreuju stanje sertifikata kao i vremenski
period u kome e sertifikat biti validan:
CREATE CERTIFICATE ABC
ENCRYPTION BY PASSWORD = ' UjkM/(%fdCr1J40oO='
WITH subject = 'Probni Sertifikat',
START_DATE = '03/20/2007',
EXPIRY_DATE = '12/31/2007'
U sluaju da je datum poetka validnosti u budunosti, gornja naredba e prijaviti
upozorenje da izdati sertifikat (jo) nije validan jer je datum poetka validnosti u budunosti.
Ostale opcije naredbe CREATE CERTIFICATE ukljuuju lozinku kojom se ifruje privatni
klju, putokaz do datoteke iz koje se uzima sertifikat ili putokaz do privatnog kljua. Npr.
sledee naredbe uitavaju sertifikate iz potpisanog programa i iz CRL sklopa koji se ve
nalazi u memoriji:
83
CREATE CERTIFICATE exeSertifikat

FROM EXECUTABLE FILE = 'D:\Program.exe'
CREATE CERTIFICATE NETSertifikat FROM ASSEMBLY UCITANISKLOP
Kao to je to sluaj sa ostalim kriptografskim kljuevima u SQL serveru, i sertifikati se
mogu sauvati u datoteku i kasnije iz nje vratiti. Opciono je mogue osim sertifikata snimiti
privatni klju, koji se mora ifrovati lozinkom.
BACKUP CERTIFICATE FinCert TO FILE = 'C:\FINCert.DAT'
WITH PRIVATE KEY (
ENCRYPTION BY PASSWORD = '0K13$7(23,L1Qaatvlk3dmTb3$',
FILE = 'C:\FINCertPRIVKLJUC.DAT')
Da bi se sertifikat ponovo upotrebio, potrebno je koristiti naredbu CREATE
CERTIFICATE sa opcijom FROM FILE, opciono sa ukljuenjem privatnog kljua dajui
pri tom i novu lozinku kojom se ifruje klju:
CREATE CERTIFICATE FinCert FROM FILE = 'C:\FINCert.DAT'

WITH PRIVATE KEY (FILE = ' C:\FINCertPRIVKLJUC.DAT '
DECRYPTION BY PASSWORD = '0K13$7(23,L1Qaatvlk3dmTb3$'
ENCRYPTION BY PASSWORD = '0K13$7(23,L1Qaatvlk3dmTb3$')
Uklanjanje sertifikata se vri naredbom DROP CERTIFICATE:
DROP CERTIFICATE FinCert
Jednom kad se nae u basi sertifikat je spreman za uporebu od onih koji imaju
vlasnitvo nad njim, odnosno od strane onih koji imaju dozvole CONTROL.
U Transact-SQL-u se mogu koristiti funkcije EncryptByCert i DecryptByCert kako bi se
podaci ifrovali/deifrovali korienje sertifikata.
Funkcija EncryptByCert prima dva argumenta: prvi je identifikacija sertifikata, a drugi
je otvoreni tekst koga treba ifrovati. Funkcija DecryptByCert prima tri parametra: prvi je
identifikator sertifikata, ifrat koji se deifruje, kao i lozinka koja je koriena pri kreiranju
sertifikata (ako postoji). Trei parametar se zahteva samo ako se privatni klju titi lozinkom
koju je dao korisnik a ne master kljuem baze. Postoji jedna pomona funkcija, Cert_ID, koja
vraa identifikaciju sertifikata na osnovu njegovog imena.
1> DECLARE @sifrat varbinary(1000)
2> SET @sifrat = EncryptByCert(Cert_ID('abc'), 'Ovo ne sme niko da sazna!')
3> SELECT @sifrat, datalength(@sifrat)
84
4> SELECT CONVERT(varchar, DecryptByCert(Cert_ID('abc'), @sifrat))

5> go
-------------------------------------------------------------------------------- ----------0x757256CA7F33CA1E9E8FB48925A505D4F73833D47E615F2 128
BCD70CE2A6DB22F071FDDB4BCC832FF1A0749D15EA45D
DE4C789C4F8BCD0CC408EAC06839EF790129ED2EBCE724
EA9BC030600B4FBDDE40F36FB1281029F4B09B653FC5BB8
1BF9657EF435BDC12DC1280D17BCE3C997EEF6D5A58C3F
FB503BCAC3D4B243358C65264
(1 rows affected)
-----------------------------Ovo ne sme niko da sazna!
(1 rows affected)
U sluaju greke, npr. ako sertifikat abc ne postoji ili korisnik koji izvrava skript nije
ovlaen da ga koristi, obe funkcije e vratiti NULL bez ikakve dojave o greci.
2> SET @sifrat = EncryptByCert(Cert_ID('NemaGa'), 'Ovo ne sme niko da sazna!')
4> SELECT CONVERT(varchar, DecryptByCert(Cert_ID('abc'), @sifrat))
5> go
-------------------------------------------NULL
NULL
U sluaju da je sertifikat zatien lozinkom, a ne master kljuem baze, trei parametar
funkcije DecryptByCert mora biti lozinka u Unikod formatu:
2> SET @sifrat = EncryptByCert(Cert_ID('USRPWD'), 'Ovo ne sme niko da sazna!')
4> SELECT CONVERT(varchar, DecryptByCert(Cert_ID(' USRPWD'), @sifrat ))
5> go
-------------------------------------------0xA3A9984C0EE3CCAF20508DFE5592143E05A93A6D22F 128
4CD24C291C4D92BE7C8E15BA9189DAD5A6E1CDF9D54
3F48C7D1BB1AE7ADF4500A9D7B6DB6384C25B2F8B819
DF29767DDC3966DDC7BEDA737FEE787F44A066D42FAF
9827FE4C8EECA2E4AA8D44C74EC3B70A4A3C947BA6BF
F34EA50E53C3E439ED1020C95F58283C28070E
(1 rows affected)
------------------------------NULL
(1 rows affected)
85
Sertifikat 'USRPWD' je kreiran sa korisnikom lozinkom, a gornji skript u liniji 4 nije

prosledio funkciji DecryptByCert tu lozinku kao trei parametar, pa je vrednost koji vraa
funkcija DecryptByCert NULL.
Ispravan skript bi bio:
-- ispravno
DECLARE @sifrat varbinary(1000)
SET @sifrat = EncryptByCert(Cert_ID('USRPWD'), 'Ovo ne sme niko da sazna!')
SELECT @sifrat, datalength(@sifrat)
SELECT CONVERT( varchar, DecryptByCert(Cert_ID('USRPWD'), @sifrat,
N'UjkM/(%fdCr1J40oO='))
go
Asimetrini kljuevi
U sluaju da nam nisu potrebne sve mogunosti koje nude sertifikati, ali i dalje imamo
potrebu da koristimo sistem sa javnim kljuevima, mogu se koristiti asimetrini kljuevi.
Sertifikati nude zgodan nain za prebacivanje javnih kljueva sa jednog servera na drugi. Ako
nema potrebe za migracijom kljueva, a sva kriptografija se zavrava unutar baze podataka,
asimetrini kljuevi su dovoljni za taj posao.
Naredba CREATE ASYMMETRIC KEY u odnosu na naredbu za kreiranje sertifikata
ima manje opcija. Kao i sertifikati i asimetrini kljuevi se mogu tititi master kljuem baze
ili sa lozinkom koju daje korisnik. Sledei primer prikazuje najjednostavniji nain za kreiranje
asimetrinog para kljueva, iji je vlasnik dbo, a titi se master kljuem base podataka
korienje 2048-bitnog RSA algoritma:
CREATE ASYMMETRIC KEY dboAsymKey AUTHORIZATION dbo
WITH ALGORITHM = RSA_2048
Kao i kod ostali kljueva, mogue je pri kreiranju odrediti vlasnitvo nad kljuem. Sledei
primer kreira asimetrini klju iji je vlasnik Pera a kljuevi se tite lozinkom:
CREATE ASYMMETRIC KEY PeraASIMKLJUC
AUTHORIZATION Pera
WITH ALGORITHM = RSA_2048
ENCRYPTION BY PASSWORD = 'o1uWsdg/tkfoi7)=&qszdqjASIsdghLD'
ifrovanje asimetrinim kljuem se vri korienjem funkcije EncryptByAsymKey,
prosleivanjem identifikatora asimetrinog kljua, i otvorenog teksta koji se ifruje. Pomona
funkcija AsymKey_ID se koristi da se dobije identifikator asimetrinog kljua na osnovu
naziva kljua. Funkcija DecryptByAsymKey se koristi za deifrovanje, a prosleuju joj se
identifikator asimetrinog kljua i ifrat kojeg je potrebno deifrovati. Sledei skript koristi
asimetrini klju za ifrovanje, ije je vlasnik dbo, a zatien je master kljuem baze
podataka.
86

SET @sifrat = EncryptByAsymKey(AsymKey_ID('dboAKLJUC'), '!Ovo je tajna!')
SELECT CONVERT(varchar, DecryptByAsymKey(AsymKey_ID('dboAKLJUC'), @sifrat))
U sluaju da je prilikom kreiranja asimetrinog kljua odlueno da se on titi lozinkom, a ne

master kljuem baze, potrebno je funkciji DecryptByAsymKey proslediti tu lozinku kao trei
parametar u unikod formatu:
SET @sifrat = EncryptByAsymKey(AsymKey_ID('PeraAKLJUC'), 'STROGA TAJNA')
SELECT
CONVERT(varchar,
DecryptByAsymKey(AsymKey_ID('PeraAKLJUC'),
N'lhj=789OJHjklhz/iuhKJGjhzgf(/%&'))
@sifrat,
Simetrini kljuevi
Korienje asimetrinih kljueva sa ili bez sertifikata je podesno u onom sluajevima u
kojima podatke treba da ifruje entitet koji se razlikuje od entiteta koji e te podatke kasnije
da deifruje. Cena koja se plaa se rauna u procesorskoj snazi. Algoritmi za ifrovanje sa
asimetrinim kljuem su zahtevaju vie procsorske snage nego oni sa simetrinim kljuem.
Veina baza treba da omogui to bolje performanse prema korisniku, izbegavanje
asimetrinih algoritama e donekle da ublai gubitak performansi. Jo jedna prednost
algoritama za ifrovanje sa simetrinim kljuem je u mogunosti da se titi znatno vea
koliina podataka.
U veini okruenja gde ze zahteva razmena podataka, simetrini kljuevi nisu u stanju
da odgovore izazovu. To je zbog toga to obe strane moraju da imaju isti klju, to predstavlja
veliki izazov za sigurnu razmenu kljua. U tim sluajevima se simetrini klju ifruje
asimetrinim kljuem kako bi se reeio problem razmene simetrinog kljua.
Meutim, ifrovanje simetrinim kljuem je idealno kod serverskih aplikacija kakva je i SQL
server, gde je potrebno podatke smestiti u obliku ifrovanog teksta. Poto podatke ne treba
iznositi van servera, ova vrsta ifrovanja nudi dobru zatitu uz dobre performanse.
U bazi podataka, simetrini kljuevi se mogu tititi korienjem sertifikata, asimetrinih
kljueva, nekim od postojeih simetrinih kljueva ili lozinkom. Simetrini klju se ne moe
tititi korienjem master kljua baze podataka. To je jedina vrsta kljua koja se moe zatititi
kljuem istog tipa. Sa svim moguim opcijama naredba CREATE SYMMETRIC KEY je
istovremeno i fleksibilna i kompleksna. Sledi primer u kome se kreira novi TRIPLE_DES
simetrini klju sa imenom SIMKLJUC, iji je vlasnik korisnik Pera, klju se ifruje
postojeim sertifikatom ABCert korienjem iskaza ENCRYPTION BY CERTIFICATE:
87
CREATE SYMMETRIC KEY SIMKLJUC

AUTHORIZATION Pera
WITH ALGORITHM = TRIPLE_DES
ENCRYPTION BY CERTIFICATE ABCert
Sledea naredba kreira novi simetrini klju koji se ifruje korisnikom lozinkom:
CREATE SYMMETRIC KEY SIMKLJUC2
AUTHORIZATION Pera
WITH ALGORITHM = TRIPLE_DES
ENCRYPTION BY PASSWORD = 'HzjSkG*jhGl1A4utYo24nMbaQd'
Algoritam koji se koristi za izvoenje kljua kojim se ifruje simetrini klju je TRIPL
DES, a ulazni parametar mu je data lozinka u iskazu ENCRYPTION BY PASSWORD.
TRIPL DES je istovremeno i algoritam kojim se ifruje simetrini klju.
Sledea naredba kreira novi klju korienjem RC2 algoritma, koji se titi korienjem
ve postojeeg ASIMKLJUC asimetrinog kljua:
CREATE SYMMETRIC KEY SIMKLJUC
WITH ALGORITHM = RC2
ENCRYPTION BY ASYMMETRIC KEY ASIMKLJUC
Da bi se simetrini klju mogao da koristi bilo za zatitu podataka ili kljueva,
prethodno se mora otvoriti. Otvaranje simetrinog kljua ga deifruje i smeta ga u zatieni
deo SQL servera u otvorenom obliku. To se ostvaruje naredbom OPEN SYMMETRIC
KEY, gde se u iskazu DECRYPTION BY odreuje klju, koji je korien za ifrovanje
simetrinog kljua koga otvaramo, a to moe biti sertifikat, simetrini klju ili lozinka.
Sledea naredba otvara SIMKLJUC koji je zatien sertifikatom dboSERT, koji je korien u
trenutku kreiranja kljua SIMKLJUC:
OPEN SYMMETRIC KEY SIMKLJUC
DECRYPTION BY CERTIFICATE dboSERT
Jednom kada je klju otvoren, moe se koristiti pri upotrebi drugih simetrinih kljueva.
Sledea naredba kreira novi simetrini klju, SIMK2, koristi algoritam DESX, a ifruje se
gore otvorenim kljuem SIMKLJUC:
88
CREATE SYMMETRIC KEY SIMK2

WITH ALGORITHM = DESX
ENCRYPTION BY SYMMETRIC KEY SIMKLJUC
Ono to je otvoreno, mora se i zatvoriti posle upotrebe. Naredba CLOSE
SYMMETRIC KEY uklanja klju iz memorije, i na taj nain ga ini nedostupnim za
korienje, dok se ponovo ne otvori. (Ako se ne uradi zatvaranje, klju e biti zatvoren pri
zatvaranju konekcije). Sledea naredba zatvara klju:
CLOSE SYMMETRIC KEY SIMKX
U sluaju da je potrebno zatvoriti sve kljueve, to se moe postii jednom naredbom:
CLOSE ALL SYMMETRIC KEYS
U sluaju da je master klju baze podataka otvoren eksplicitno, ova e ga naredba
zatvoriti. Kao i kod ostalih simetrinih kljueva, naredba e uiniti master klju nedostupnim
za upotrebu. Ako master klju nije zatien servis master kljuem, bilo koji pokuaj
korienja kljua koji je pod zatitom master kljua baze nee uspeti.
ifrovanje i deifrovanje podataka je slino kao i kod ostalih vrsta kljueva. Pre upotrebe
simetrinog kljua potrebno ga je eksplicitno otvoriti pre ifrovanja i deifrovanja, a kasnije
zatvoriti. Za ifrovanje se koriti funkcija EncryptByKey, koja kao parametre uzima otvoreni
tekst, i GUID kljua koji se koristi ifrovanje. Za deifrovanje se koristi funkcija
DecryptByKey. Funkciji za deifrovanje nije potrebno proslediti GUID kljua. SQL server e
automatski iz kolekcije otvorenih simetrinih kljueva da izabere odgovarajui klju. Ovo je
mogue jer se kao deo ifrata smeta i GUID kljua, koji je korien za ifrovanje. SQL server
e potraiti odgovarajui klju u skupu otvorenih simetrinih kljueva unutar sesije, tako da
nee doi do meanja kljueva razliitih korisnika.
OPEN SYMMETRIC KEY SIMKLJUC
DECRYPTION BY CERTIFICATE ABCERT
DECLARE @cipher varbinary(1000)
SET @ cipher = EncryptByKey(Key_GUID('SIMKLJUC'), 'Ovo je tajna!')
SELECT @ cipher, datalength(@cipher)
SELECT CONVERT(varchar, DecryptByKey(@cipher))
CLOSE SYMMETRIC KEY SIMKLJUC
89
U sluaju da simetrini klju nije otvoren, greka nee biti prijavljena, ve e funkcija
EncryptByKey da vrati NULL vrednost. Sledi par primera u kojima se koristi simetrini klju
koji se titi lozinkom i asimetrinim kljuem:
-- Koristi se simetrini kljuc zasticen lozinkom
OPEN SYMMETRIC KEY SIMKLJUC2
DECRYPTION BY PASSWORD = 'NhGTFDF5GuXIj(7&%R$#'
SET @cipher = EncryptByKey(Key_GUID(' SIMKLJUC2'), 'TAJNA!')
SELECT @cipher, datalength(@cipher)
CLOSE SYMMETRIC KEY SIMKLJUC2
-- Koristi se simetrini kljuc zasticen asimetricnik kljucem
DECRYPTION BY ASYMMETRIC KEY ASIMKLJUC
SET @cipher = EncryptByKey(Key_GUID(' SIMKLJUC3'), 'Ovo je vazna tajna!')
Stvari se malo komplikuju kada se simetrini klju ifruje simetrinim kljuem. Pri
upotrebi simetrinog kljua potrebno je prethodno otvoriti klju kojim je on zatien. Ako
postoji sloena hijerarhija zatite, sam postupak oko otvaranja kljueva moe biti sloen a
time i podloan grekama.
Sledei skript otvara dva simetrina kljua pre postupka ifrovanja. Kako je
SIMKLJUC1 zatiem simetrinim kljuem SIMKLJUC2, koji je zatien sertifikatom
SERTKLJUC, potrebno je otvarati kljueve sledeim redosledom:
DECRYPTION BY CERTIFICATE SERTKLJUC
DECRYPTION BY SYMMETRIC KEY SIMKLJUC2
90

SET @cipher = EncryptByKey(Key_GUID(' SIMKLJUC1'), 'TAJNA-007')
Redosled kojim se kljuevi zatvaraju nije bitan.
Kljuevi lozinke
Da bi se koristilo ifrovanje u bazi podataka nije uvek potrebno snimati kljueve u bazi
podataka. Ako elimo da sami rukujemo kljuevima, bez oslonca na SQL server, i time
preuzmemo uvanje tajne na sebe, koristiemo funkcije EncryptByPassPhrase i
DecryptByPassPhrase. Ovim funkcijama je dovoljna lozinka kao prvi parametar, i otvoreni
tekst kao drugi parametar kod ifrovanja, odnosno ifrovan tekst kod deifrovanja. Algoritam
koji se koristi se ne moe specificirati:
SET @cipher = EncryptByPassphrase('4Faed765', 'Ovo je tajna')
SELECT CONVERT (varchar, DecryptByPassphrase('4Faed765', @cipher))
Treba biti oprezan prilikom korienja lozinki. Lozinke moraju da budu teke za pogaanje.
Server ne nudi pomo oko odreivanja da li je lozinka jaka ili nije.
Microsoft nije dokumentovao kripto-algoritam korien u funkciji EncryptByPassPhrase.
Zakljuak o simetrinim kljuevima

Postoji mnotvo opcija kod korienja kriptografije u SQL serveru, kako u izboru vrsta
kljueva tako i u izboru korienih algoritama. Prilikom izbora koju vrstu kljua koristiti,
treba se rukovoditi parametrima kao to su: brzina algoritma, da li isti entitet ifruje/deifruje
podatke i koliko poveanje ifrovanog teksta utie na smetajne kapacitete.
Korienje kriptografije je potrebno samo ako se koristi odbrana po dubini, ako se
kriptografija ne koristi nee biti ni smanjenje performansi koje unosi kriptografija. Ako je
kriptografija potrebna, treba je koristiti samo tamo gde je neophodna.
Ako neka eksterna aplikacija zahteva ifrovane podatke, onda e sama aplikacija biti
odgovorna za upravljanje kljuevima, pa ako nema drugih razloga za uvanjem kljueva u
bazi podataka moe se koristiti scenario sa lozikama.
91
U sluaju da se podaci ifruju prilikom snimanja u bazu podataka, i da se deifruju

prilikom izuzimanja, treba koristiti simetrine kljueve. Treba izbegavati zatitu simetrinih
kljueva lozinkom, jer je upravljanje lozinkama i njihova razmena meu korisnicima
podlona kompromitaciji.
Ako e se ifrovani podaci razmenjivati meu aplikacijama, koje pristupaju istoj SQL
server bazi jedna od opcija ja i korienje asimetrinih. Primarni korisnik, odnosno vlasnik
podataka, treba da objavi svoj javni klju, a privatni klju da dri u tajnosti.
Ako je potrebno korienje asimetrinih kljueva, uz istovremeno povezivanje
privatnog kljua sa korisnikom ili grupom treba koristiti sertifikate. Ovo je vano kod
ifrovanje/deifrovanja koje se odvija van organizacije u kojoj se nalazi SQL server, kako bo
postojalo strogo uverenje o entitetu koji je izvrio ifrovanje.
Posle instalacije je potrebno arhivirati master klju servera, kao i master klju baze podataka,
a arhivu uvati na sigurnom.
Kriptografski korisni pogledi

SQL server 2008 ima ugraene poglede, koji daju prikaz kljueva i drugih kriptografskih
parametara. Kao i kod ostalih pogleda, rezultat rada e zavisiti od korisnikovih dozvola.
Sys.certificates
Sadri informacije o svim instaliranim sertifikatima u tekuoj

bazi. Sadri sledee informacije: naziv, identifikaciju sertifikata,
identifikaciju vlasnika sertifikata, vrstu zatite, vreme okvir u
kome je sertifikat validan, i na kraju SHA-1 he thumbprint
sertifikata.
Sys.asymmetric_keys
Sadri informacije o svim asimetrinim kljuevima definisanim u

tekuoj bazi. Sadri sledee informacije: naziv, identifikaciju
vlasnika, kako je zatien, identifikaciju, kratak opis algoritma,
duina kljua u bitovima i javni klju, i neke informacije opisnog
karaktera.
Sys.symmetric_keys
Sadri informacije o svom simetrinim kljuevima definisanim u

tekuoj bazi podataka. Sadri informacije koje su sline
informacijama koje daje sys.asymmetric_keys pogled. Dodano
sadri GUID koji jedinstveno identifikuje simetrini klju.
Sys.database_principals Sadri informacije o svim vlasnicima u tekuoj bati podataka.

Ostali pogledi sadre polje princilas_id, preko koga se mogu
dobiti podaci o tome ko je vlasnik kljua.
Sys.key_encryptions
Sadri stavku za svaki primerak iskaza ENCRYPTION BY

naredbe CREATE SYMMETRIC KEY. Simetrini kljuevi e
imati samo jednu stavku, ali e veima master kljeva baze
92
podataka imati dve stavke, jer se master kljuevi baze podataka

mogu ifrovati master kljuem servera i lozinkom.
Tabela 14: Kriptoloki vani sistemski pogledi
Zakljuak
SQL server sadri sve potrebne alate potrebne za ifrovanje i deifrovanje bez potrebe
za veim udubljivanjem u specifinosti pojedinih algoritama. Pored toga jedna od velikih
prednosti je i upravljanje kljuevima. SQL Server omoguuje ifrovanje podataka zasnovano
na sertifikatima, asimetrinim kljuevima, simetrinim kljuevima i lozinkama. Koju vrstu
kljueva izabrati zavisi od zahteva aplikacije, brzine rada kao i od veliine izlaznog ifrata.
6.4. MySQL
MySQL je veoma popularan SUBP otvorenog koda. Najee se koristi od strane
projekata otvorenog koda koji zahtevaju podrku baze podataka. U ugraenom
kriptografskom modulu nalaze se funkcije za ifrovanje / deifrovanje, kompresiju /
dekompresiju kao i he funkcije.
Funkcije za ifrovanje/deifrovanje:
AES_ENCRYPT, AES_DECRYPT, DES_ENCRYPT, DES_DECRYPT
Funkcija: AES_ENCRYPT(string, lozinka)
Ova funkcija ifruje dati znakovni niz, AES algoritmom sa 128-bitnim kljuem.
Funkcija vraa NULL ako je neki od parametara NULL. Dostupna je od MySql verzije 4.0.2.
Inverzna funkcija ovoj je funkcija AES_DECRYPT. Sledi primer poziva:
select aes_encrypt('FIM2009', 'j@kaL0zink@') as primer;
Funkcija: AES_DECRYPT(string, lozinka)
Ova funkcija deifruje tekst koji je prethodno ifrovan AES algoritmom sa kljuem
duine 128 bita, i inverzna je funkciji AES_ENCRYPT(). Korienjem lozinke kao drugog
parametra pri pozivu funkcije dobija se otvoreni tekst. U sluaju da je neki od parametara
NULL, povratna vrednost funkcije je NULL. Funkcija je dostupna u MySQL-u od verzije
4.0.2. Sledi primer poziva:
select aes_decrypt(unhex('76A8388E52326D1765C0C9BA0B284D76'), 'j@kaL0zink@') as
primer;
Kao rezultat dobije se string: "FIM2009".
93
Kako je rezultat ifrovanja, posle poziva funkcije AES_ENCRYPT, dobija se binarni

niz, pa je zbog toga rezultat iz prethodnog primera prebaen u heksadecimalni oblik. Kao
krajnji rezultat je dobijen otvoren tekst, string iz prethodnog primera.
Funkcija: DES_ENCRYPT( string [, klju ] )
Ova funkcija daje ifrovan niz koristei 3DES algoritam sa kljuem duine 128 bita. U
sluaju greke funkcija vraa NULL. Funkcija je dostupa od verzije MySQL-a 4.0.1.
Drugi parametar pri pozivu funkcije je klju, i moe da bude stvarni klju ako je
parametar znakovni niz, ili je indeks kljua (cifra 0 - 9) ako je parametra numeriki, i
predstavlja indeks kljua iz datoteke sa kljuevima. U sluaju da se drugi parametar izostavi
podrazumeva se klju iz datoteke kljueva koji je prvi u spisku.
Da bi funkcija radila potrebno je da je MySQL konfigurisan sa podrkom za SSL.
Takoe je potrebno da postoji datoteka sa kljuevima, a koja se specificira sa opcijom --deskey-file. Sadraj datoteke je tekst sa dve kolone. U prvoj je indeks kljua, cifre 0 - 9, a u
drugoj su kljuevi. Sledi primer poziva:
select des_encrypt('FIM2009', 'j@kaL0zink@') as primer;
Funkcija: DES_DECRYPT (string, [klju])
Ova funkcija deifruje string koji je prethodno ifrovan sa 3DES algoritmom sa kljuem
od 128 bita, tj. ona je inverzna funkciji DES_ENCRYPT. U sluaju greke povratna vrednost
funkcije je NULL. Funkcija je dostupna od verzije 4.0.1. Sledi primer poziva:
select des_decrypt(unhex('FFF2EC8A51C499FF01'), 'j@kaL0zink@') as primer;
Kao rezultat dobije se string: "FIM2009".
Funkcija: ENCODE (string, [lozinka])
Funkcija ifruje zadati string u binarni format, vezujui ga za datu lozinku. Sledi primer
poziva funkcije:
UPDATE korisnik SET loz = ENCODE('sezame', 'fim2009') WHERE idkorisnik = '143';
Funkcija ifruje lozinku sezam sa kljuem fim2009 u smeta u polje loz tabele korisnik
za izabranog korisnika.
Funkcija: DECODE (string, [lozinka])
Ova funkcija deifruje dati string koji je prethodno ifrovan sa zadatom lozinkom.
94
SELECT ENCODE(loz, 'fim2009') FROM korisnik WHERE idkorisnik = '143';

Funkcija deifruje sadraj kolone loz korienjem lozinke fim2009 za zadatog
korisnika. Prethodno je sadraj kolone loz ifrovan funkcijom ENCODE.
Funkcija: ENCRYPT(string[, seed])
Ova funkcija vraa ifrovan tekst korienjem crypt funkcije iz standardne biblioteke.
Kao drugi parametar mogue je zadati string od dva znaka radi poveanja pseudosluajnosti.
Rezultujui string nije mogue deifrovati, pa iz tog razloga funkcija nije pogodna za obradu
korisnikih lozinki. U tu svrhu pogodnije je koristiti funkciju PASSWORD. Sledi primer
poziva funkcije:
UPDATE teachers
SET pwd = ENCRYPT('test', 'JT')
WHERE teacher_id = '730522';
Funkcija: MD5 (string)
Ova funkcija koristi MD5 he algoritam koji da bi kao rezultat vratila vrednost od 128bita u obliku heksadecimalnog broja. Sledi primer poziva funkcije:
SELECT MD5('Test') AS 'MD5( ) Test';
+----------------------------------+
| MD5( ) Test |
+----------------------------------+
| 0cbc6611f5540bd0809a388dc95a615b |
+----------------------------------+
Funkcija: OLD_PASSWORD(string)
Ova funkcija ifruje zadati string korienjem kriptografskog algoritma koji je bio
ugraen u verziju pre MySql 4.1. Rezultat nije mogue deifrovati. Sledi primer poziva
funkcije:
UPDATE teachers
SET pwd = OLD_PASSWORD('test')
Funkcija: PASSWORD(string)
Ova funkcija ifruje lozinku koja se zadaje kao parametar funkcije. Rezultat nije
mogue deifrovati. Ova funkcija se koristi radi zatite korisnikih lozinki koje se smetaju u
neku od korisnikih tabela mysql baze podataka. Sledi primer poziva funkcije:
UPDATE teachers
95
SET pwd = PASSWORD('test')

Funkcija: SHA(string)
Ova funkcija kao rezultat vraa 160-bita he vrednost zadatog stringa. Rezultat je string
koji se sastoji od 40 heksadecimalnih cifara. U sluaju da je ulayni string NULL vrednost
funkcije je NULL. Sledi primer poziva funkcije:
SELECT SHA('test');
+------------------------------------------+
| SHA('test') |
+------------------------------------------+
| a94a8fe5ccb19ba61c4c0873d391e987982fbbd3 |
+------------------------------------------+
6.5. PostgreSQL
PostgreSQL nudi nekoliko nivoa kriptografske zatite, omoguujui time fleksibilnost
pri upotrebi kriptografskih primitiva.
Zatita lozinki
Korisnike lozinke se u bazi podataka smetaju u obliku MD5 he vrednosti, tako da
DBA nije u stanju da zna lozinku dodeljenu odreenom korisniku. U sluaju da se MD5 ha
koristi za autentikaciju klijenta, tada do servera i ne dolazi lozinka u otvorenom obliku, kroz
mreu, od klijenta do servera transportuje se he vrednost.
ifrovanje kolona tabele

Biblioteka pgcrypto omoguuje da odreene kolone tabele budu ifrovane. Ova
mogunost je korisna kada se u tabeli ele zetiti samo odreene kolone, to zbog toga to
ostale kolone nisu osetljive ili zbog poboljanja performansi kod ifrovanja manjeg broja
kolona. Klijent serveru predoava klju i podatke, server deifruje podatke i alje ih u
otvorenom obliku ka klijentu. Otvoreni podaci, i klju za deifrovanje su prisutni na serveru u
kratkom vremenskom intervalu, za vreme komunikacije servera i klijeta. Ona ko ima pristup
DBMS-u, a to je sigurno administrator sistema, ima pristup ovim osetljivim podacima.
ifrovanje lozinke pri prenosu

MD5 autentikacioni mehanizam, dvostruko ifruje lozinku na klijent strani pre nego to
je poalje serveru. Prvi put lozinka se ifruje korienjem korisnikog imena, a drugi put se
koristi salt koji je poslao server pri uspostavi veze. Ovako dvostruko ifrovana lozinka se alje
96
serveru kroz mreu. Dvostruko ifrovana lozinka obezbeuje da se ne moe doi do lozinke,
ali i da se sa istom lozinkom, kasnije, ne moe uspostaviti veza sa serverom.
ifrovanje veze klijent server

SSL konekcija ifruje sve podatke poslate mreem: lozinke, upite, kao i povratne
rezultate upita. Konfiguracion adatoteka pg_hba.conf omoguuje administratoru da odredi
koji serveri e koristiti neifrovanu konekciju a koji ifrovanu konekciju. Takoe, klijenti
mogu da specificiraju da ele konekciju sa serverom preko SSL-a.
SSL obostrana autentifikacija

Postoji mogunost da server i klijent predoe SSL kljueve ili sertifikate kako bi se
meusobno autentifikovali. Iako je, u tom sluaju, potrebno dodatnog administrativnog
podeavanja na obe strane, dobitak je jaa autentifikacija nego kad se koristi samo lozinka. Na
taj nain se spreavaju krae lozinki, gde se raunar pretvara da je pravi server, sve do onog
trenutka dok ne uzme lozinku od klijenta. Takoe, na ovaj nain se spreava napad tipa
"ovek u sredini" (engl. man in the middle attack).
ifrovanje na strani klijenta

U sluaju da ne postoji poverenje u administratora sistema, npr. baza podatake se nalazi
kod internet provajdera, (engl. database as service), potrebno je da se podaci ifruju na strani
klijenta, na taj nain u bazi podataka se podaci nikad ne nalaze u otvorenom obliku. Podaci se
pre slanja na server ifruju, a pre upotrebe deifruju. Postupak ifrovanja i deifrovanja s
odvija na strani klijenta.
6.5.1. Konfiguracija
Kriptografski modul pgcrypto se konfigurie prema podeavanjima koje pronae u
glavnom PostgreSQL configure skriptu. Opcije od interesa su with-zlib i with-openssl.
Bez upotrebe zlib modula, PGP funkcije nisu u stanju da obezbede kompresiju unutar PGP
ifrovanih paketa. Zbog toga to modul pgcrypto ne poseduje matematike funkcije za rad sa
velikim celim brojevima, a koji su osnova kriptografije sa javnim kljuevima, modul pgcrypto
se oslanja na biblioteku OpenSSL po pitanju kriptografije sa javnim kljuevima. Postoje i
dodatne razlike u sluaju korienja podrke koju nudi OpenSSL:
Funkcionalnost
podrazumeva se sa OpenSSL-om
MD5
da
da
SHA1
da
da
SHA256/384/512
da
od verzije 0.9.8
97
Funkcionalnost
podrazumeva se sa OpenSSL-om
Ostali ha algoritmi
ne
da10
Blowfish
da
da
AES
da
da11
DES/3DES/CAST5
ne
da
Raw encryption
da
da
PGP ifrovanje simetrinim kljuem da
da
PGP ifrovanje javnim kljuem
da
ne
Tabela 15: Funkcionalnost pgcrypto modula sa i bez OpenSSL podrke
6.5.2. Bezbednost
Sve funkcije koje su nabrojane, izvravaju se na serverskoj strani. To znai da svi
podaci koji idu od klijenta do servera putuju u otvorenom obliku. Zbog toga je potrebno:
konektovati se na server u lokalu ili koristiti SSL konekciju,
verovati sistem administratoru i DB administratoru.
U sluaju da ne moemo da obezbedimo neku od opcija potrebno je vriti ifrovanje na
strani klijenta.
6.5.3. He opteg tipa

Funkcija: digest( podatak, tip )
Tip predstavlja algoritam koji e se koristiti. Standardni algoritmi su md5 and sha1,
mada mogu biti podrani i drugi algoritmi to zavisi od opcija pri kreiranju kripto modula.
Povratna vrednost funkcije je binarna he vrednost. U sluaju da je potreban he u oblliku
heksadecimalnog stringa, koristi se funkcija encode.
Funkcija: hmac( podatak, klju, tip )
Funkcija rauna he MAC nad podatkom. Tip predstavlja he algoritam, kao u
prethodnoj funkciji. U sluaju da je klju dui od veliine he bloka, prvo e se nad njim
izraunati he a potom e se taj he koristiti kao klju. Funkcija je slina digest funkciji. osim
to je za raunanje hea potreban i klju. Na ovaj nain se spreavaju napadi u kojima se
pored podatka promeni i he vrednost. Povratna vrednost funkcije je binarna he vrednost.
10
Mogu e je izabrati bilo koji he algoritam koga podrava OpenSSL.

AES postoji u OpenSSL-u od verzije 0.9.7. U slu aju da je gcrypto modul kompajliran sa podrkom starijeg
OpenSSL-a, koristi e se ugra eni AES, to prakti no zna i da je podrka za AES uvek dostupna.
11
98
6.5.4. He lozinke
Funkcije crypt i gen_salt se koriste za izraunavanje he vrednosti lozinki. crypt
rauna vrednost neke lozinke a gen_salt vri pripremu parametre za crypt funkciju. Razlike
izmeu he algoritma ugraenog u crypt funkciju i uobiajenih he algoritama MD5 i SHA1
su sledee:
Algoritam poseduje vie ciklusa pa je time i sporiji. Sama lozinka se sastoji, uglavnom,
od malog broja znakova, te je jedan od metoda oteevanja napada grubom silom i
poveanje broja ciklusa koji se koriste u algoritmu.
Korienjem salt bajtova se postie da dva razliita korisnika, sa istom lozinkom imaju
razliite he vrednosti tih lozinki. Ovo je jo jedna mera u spreavanju otkrivanja
vrednosti lozinke.
Identifikacija algoritma se ugrauje u krajnju he vrednost, radi koegzistencije razliitih
he algoritama.
Neki he algoritmi su adaptivni, tj. omoguuju kasnije izmene u vidu promenana nekih
elemenata algoritma, bez uvoenja nekompatibilnosti sa ve postojeim lozinkama. Ove
izmene se koriste radi pojaanja kriptografske vrednosti he funkcija u sluajevima kada
se povea procesorska snaga hardvera koji se koristi u razbijanju lozinki grubom silom.
Podrani algoritmi su:
Algoritam
Maksimalna
Salt
Adaptivan
veliina lozinke
bitovi
Opis
bf
72
da
128
osnova Blowfish,
varijanta 2a
md5
neogranieno
ne
48
osnova md5
xdes
da
24
proireni DES
des
ne
12
originalna unix-ova
crypt funkcija
Tabela 16: Podrani algoritmi kod odre ivanja hea lozinke
Funkcija: crypt( lozinka, salt )

Funkcija rauna he vredlost lozinke u stilu Unix-ove crypt(3) funkcije. Prilikom
generisanja novog hea, potrebno je korienje funkcije gen_salt() radi generisanja nove salt
vrednosti. Pri proveri he vrednsti lozinke, sauvana he vrednost lozinke se koristi kao salt
vrednost.
Funkcija: gen_salt( tip )
99
Generie novi, preudosluajni niz, za korienje kao salt vrednost u funkciji crypt. Za
korienje u adaptibilnim algoritmima, broj iteracija je podrazumevani broj za konkretni
algoritam. Mogui algoritmi - tip parametar, su : des, xdes, md5 i bf.
Funkcija: gen_salt( tip, broj_iteracija )
Jedina razlika u odnosu na prethodnu funkciju je mogunost odreivanja broja iteracija
za neke algoritme. Broj iteracija je direktno proporcionalan vremenu potrebnom za raunanje
he vrednosti lozinke, a samim tim i vremenu potrebnom za njegovo razbijanje. Sa brojem
itreacija treba biti oprezan, jer ako se postavi previsoko, mogue je produiti vreme raunanja
hea lozinke ne nekoliko godina12. Takoe, broj iteracija je ogranien i algoritmom koji se
koristi:
Algoritam
podrazumevana
vrednost
min
max
xdes
725
16777215
bf
31
Tabela 17: Broj iteracija pri generisanju salt vrednosti.
U sluaju korienja xdes algoritma, dodatno ogranienje je da broj iteracija mora biti
neparan. Notes:
6.5.5. PGP ifrovanje

Implementirane funkcije su deo OpenPGP (RFC2440) standarda. Podrano je ifrovanje
sa javnim i tajnim kljuem.
Prikaz ifrovanja
Poruke ifrovane PGP-om se sastoje iz dva paketa:
Paket kljua sesije - ifrovan simetrinim ili javnim kljuem.

Paket podataka ifrovanih kljuem sesije.
ifrovanje s lozinkom:
1. Zadana lozinka se konvertuje u klju he funkcijom String2Key. Ova funkcija je
veoma slina crypt algoritmu, funkcija ima vie cikljusa i u algoritam je ukljuem
salt, a kao rezultat daje klju.
2. U sluaju da je potreban klju sesije bie generisan sluajan niz, inae se se koristiti
String2Key klju kao klju sesije.
12
Prvobitni crypt zasnovan na DES algoritmu je dizajniran da generie 4 he vrednosti u

sekundi, imajui na umu hardver tog vremena. Sporije od 4 he vrednosti po sekundi (vei
broj) bi inio sistem slabo upotrebljivim a bre od 100 he vrednosti u sekundi (manji broj) bi
inio sistem nesigurnim.
100
3. Ako se String2Key klju koristi direktno binarni sadraj kljua e biti u paketu kljua
sesije. U ostalim sluajevima, klju sesije e biti ifrovan sa String2Key kljuem pa
tek onda stavljen u paket sesijskog kljua.
ifrovanje s javnim kljuem:
1. Generie se novi klju sesije.
2. Klju se ifruje s javnim kljuem i stavlja u paket sesijskog kluat.
ifrovanje podataka sesijskim kljuem:
1. Konverzija podataka: konverzija u kodni raspored UTF-8, konverzija kraja reda i
kompresija podataka.
2. Ispred bloka podataka se stavlja blok sluajnog niza. Sluno kao postavljanje
sluajnog inicijalnog vektora (IV kod CBC blok ifarskih sistema).
3. Na kraj se dodaje SHA1 he vrednost prefiksa i podataka.
4. Svi podaci se ifruju kljuem sesije.
Funkcije za ifrovanje / deifrovanje simetrinim kluem:
sintaksa: pgp_sym_encrypt(podatak, lozinka)
sintaksa: pgp_sym_decrypt(podatak, lozinka)
Funkcije za ifrovanje / deifrovanje javnim kljuem:
sintaksa: pgp_pub_encrypt(podatak, javni_klju)
sintaksa: pgp_pub_decrypt(poruka, tajni_klju [, lozinka])
101
7. Prikaz sluaja
ifrovanje podataka za utvrivanje identiteta (engl. personal identification information skr. PII) u bazama podataka, oduvek je bilo teko zbog toga to ifrovanje obino
podrazumeva proirivanje podataka i promenu njihovog formata. U ovom poglavlju bie
prikazan model koji reava ovaj problem, a bie predloene praktine konstrukcije za
ifrovanje JMBG i brojeva kreditnih kartica.
7.1. Motivacija
Zatita podataka, koji su u vezi utvrivanja identiteta neke osobe, (JMBG, broj kreditne
kartice) je potrebna kako bi se umanjile posledice koje se mogu javiti zbog gubitka podataka.
Jedna od prepreka prihvatanja efikasnih metoda za ifrovanje predstavljaju trokovi
modifikovanja ve postojeih baza podataka i aplikacija radi prilagoavanja ifrovanim
informacijama. Ovi trokovi su u vezi sa dve promene koje su neophodne radi prilagoavanja
klasino ifrovanih podataka. Prvo, informacije koje su od kritinog znaaja za privatnost kao
to su brojeva kreditne kartica i brojeva socijalnog osiguranja esto se koriste kao kljuevi i
indeksi u bazama podataka, pa ifrovanje takvih podataka moe zahtevati znaajne izmene u
bazi i aplikacijama. Drugo, sigurno ve postoje aplikacije kod kojih se oekuje da podaci
budu predstavljeni u odreenom formatu; ifrovanje e sigurno dovesti do proirivanja
podataka i izmene tipa podataka, te e biti neophodna izmena formata.
Osim ifrovanja baze podataka u toku eksploatacije, ponekad e biti potrebno nainiti
probne baze podataka koje su sline radnim verzijama baze. esto se deava da proces
razvoja i instalacije za potrebe velikih poslovnih aplikacija obuhvata testiranje neke aplikacije
u odnosu na bazu podataka pre nego to se ona instalira uivo. Meutim, u toku testiranja,
moda je neophodno da se lini podaci pojedinaca iz bezbednog okruenja prebace u manje
bezbedno - testno okruenje. ifrovanje podataka bi omoguilo zatitu podataka, ali bi se pri
tom unitila sposobnost testiranja u odnosu na takve podatke.
Kao dobro reenje, namee se kvalitetan ifarski mehanizam a koji proizvodi ifrat koji
je u istom formatu kao i otvoreni tekst. Algoritmi koji poseduju ovakvo svojstvo nazivaju se
ifarski algoritmi sa ouvanjem formata (engl. format preserving encryption skr. FPE).
Istorijski gledano, najbolji test za neki kriptografski algoritam jeste test vremena. Iz
ovog razloga, potrebno je pronai neki FPE algoritam koji nije nov, ili da se barem moe
redukovati (u okviru izvesne granice) na neku postojeu, poznatu ifru. Algoritmi koji su
predloeni u ovom radu poseduju dokaze o bezbednosi u kriptografskoj literaturi, i zasnivaju
102
se na konstrukcijama koje idu unazad do 1997. godine. Ovo poglavlje opisuje tri metoda koji
se odnose na razliite podsluajeve FPE-a.
Model FPE
Vie nego tipian primer upotrebe FPE predstavlja ifrovanje interne baze podataka
tako da ogranieni broj aplikacija i korisnika (moda nijedan) moe da rekonstruie prvobitne
vrednosti na osnovu FPE ifrovanih vrednosti. U ovakvom scenariju, svaki bezbednosni
mehanizam (FPE, tradicionalno ifrovanje, ili neki drugi mezanizam za kontrolu pristupa)
treba da bude jak uz sledea ogranienja:
Ogranienje 1: Napada poznaje format i vrstu podataka u bazi podataka. Trebalo bi da
pretpostavimo da neki napada zna da se ono to trai odnosi na brojeve kreditne kartice ili
matini broj graanina.
Ogranienje 2: Veliina otvorenog teksta bie relativno mala, u poreenju sa tipinom
veliinom kriptografskog skupa. Blok ifra kao to je AES radi sa blokovima od 128 bita.
Jedinstveni matini broj ima otprilike imaju 48 bita, a brojevi kreditne kartice imaju otprilike
58 bita. Ovo znai da svaki mehanizam (FPE ili neki drugi) mora da prua zatitu od
napadaa kako on ne bi mogao da pristupi funkciji ifrovanja/deifrovanja; u suprotnom,
napada moe jednostavno da krene sa deifrovanje sluajnog niza podataka i na taj nain
moe da dobije veliku koliinu linih identifikacionih podataka. U FPE sluaju, dva druga
znaajna ogranienja moraju da se primene za algoritam:
Ogranienje 3: Podaci se ne mogu proiriti. Onda kada neki FPE algoritam ifruje neki
broj sa N-cifara, on mora i da proizvede broj od N-cifara.
Ogranienje 4: Podaci se moraju ifrovati na deterministiki nain. Podaci se u
principu ifruju i smetaju u bazu podataka, i izuzetno je poeljno da se ouva sposobnost
upotrebe kolone kao kljua ili indeksa, to zahteva da se viestruko ponovljeni podataka
ifruje u isti ifrat pri korienju istog kljua.
Unutar ovih ogranienja, neophodan je algoritam koji e ifrovati podatke
permutovanjem stringova u datom formatu u razliite stringove u tom istom formatu, da
napada, posedovanjem velike koliine ifrata, ne moe nita da zakljui o otvorenom tekstu.
Algoritmi koji zadovoljavaju ovaj standard su izgraeni tako da mogu da opstanu jedino u
FPE okruenju, i u principu se ne preporuuju za ugraivanje u komunikacione aplikacije, ili
druga okruenja gde se moe pretpostaviti da napada ima pristup funkciji
ifrovanja/deifrovanja ili ima pristup neogranienom broju parova ifrata/otvorenog teksta.
Praktini cilj u vezi bezbednosti u ovom sluaju jeste da se trenutno pasivni napad
(kraa baze podataka putem aplikacije, log fajla, ili trake sa arhiviranim podacima) pomeri ka
103
nekom drugaijem moguem napadu za koji e biti neophodna aktivna subverzija proverene
funkcije ifrovanja/deifrovanja, i kod koga e se podaci biti bezbedno sauvani ak i u
sluaju znaajnog broja otkrivanja ifrovanja i deifrovanja.
Test model
Model ifrovanja podataka radi laboratorijskog testiranja ili u cilju razvoja sistema
donekle se razlikuje od krajnjeg PFE modela. U ovom sluaju, postupak ifrovanja ne treba da
bude reverzibilan, ve se koristi da bi se permutovali podaci, a nakon toga klju se odbacuje.
U ovom sluaju, svaka veza izmeu ifrata i otvorenog teksta se eliminie, i najbolje to neki
napada moe da uradi, kada ve nema mogunosti da obavi korelaciju iftara sa otvorenim
tekstom, jeste da ispita sam ifrat.
FPE metodi u donjem delu teksta su vrlo jaki u ovom modelu. Trenutno mnoge
aplikacije koriste he funkcije koje dobijeni blok odesecaju na potreban broj znakova. Na ovaj
nain se omoguuje ouvanje referentnog integriteta, ali se stvara mogunost unutranjih
kolizija (kod kojih delovi podataka daju isti ifrat). Budui da svi FPE algoritmi predstavljaju
permutacije, onda oni garantuju da se delovi podataka ne sukobljavaju u fazi ifrovanja. Ovo
je naroito poeljna karakteristika za kratke koliine podataka, kao to je JMBG i sline, gde
mogunost kolizije nije nezanemarljiva.
7.2. Prikaz reenja realizacije na odabranom DBMS-u

FPE Metodi
Ovaj odeljak detaljnije prezentuje tri praktina FPE metoda. Predstavljamo merenja
perfomansi za ovakve metode i nudimo modifikaciju i poboljanje bezbednosne granice za
Fiestelovu konstrukciju koja se zasniva na Patarinovim rezultatima. Sledei odeljak daje
detaljniji prikaz praktinih FPE ema za primere odreenog broja kreditne kartice i broj
socijalnog osiguranja.
Svaki od ova tri metoda bavi se razliitom veliinom ulaznog skupa podataka, ili iz
razloga bezbednosti ili iz razloga poboljanja performansi. Sledea tabela sumira praktine i
bezbedne granice za svaki od metoda, u smislu celokupne veliine skupa i isto tako u smislu
broja decimalnih cifara nekog formatizovanog stringa. Zadate veliine i formati koji nisu
prikazani u ovoj tabeli mogli bi da se prikau na osnovu primene sloenog metoda koji je
prikazan u odeljku 5. Vrednosti u tabeli su pribline, i stvarne granice zavise od nivoa
bezbednosti koji zahteva odreena aplikacija. Opis pojedinanih algoritama prikazuje na koji
nain je veliina skupa u vezi sa bezbednou i performansom.
104
Metod
Prefiks
Ponavljanje ciklusa
Cycle-walking
Feistelov ciklus
Veliina skupa
(bitovi)
1 - 20
Decimalne cifre
1-6
50 - 63
16 - 19
40 - 240
12 - 80
Tabela 18: Algoritmi kriptografskog o uvanja formata
7.2.1. Metod prefiksa

Metod prefiksa je vrlo jednostavan, ali moe da jedino funkcionie na malim skupovima
podataka. Metod u principu funkcionie tako to se "upisuje" sluajna permutacija u
memoriju, nakon ega se takva permutacija koristi za ifrovanje podataka.
Opis metode prefiksa

Da bi ifrovali podatke metodom prefiksa, prvo izraujemo tabelu koja pohranjuje neku
permutaciju nad celim skupom ifrata, i nakon toga jednostavno potraimo vrednost ifrata uz
pomo otvorenog teksta. Ovo znai da je postupak ifrovanja i deifrovanja vrlo brz.
Inicijalno kreiranje tabele je zahtevnije po pitanju vremena, ali se moe prihvatiti za manje
veliine skupa.
Da bi kreirali tabelu, biramo osnovnu ifru, obino AES ili 3DES. Nakon toga ifrujemo
vrednosti 0 N 1 , gde N predstavlja veliinu ulaznog skupa. Beleimo vrednost indeksa i
njegovu ifarsku vrednost, i nakon toga obavljamo sortiranje po ifarskoj vrednosti. Na
primer, recimo da elimo da ifrujemo podatke u skupu sa jednom cifrom (0 - 9). ifrovanje
vrednosti obavljamo uz pomo AES, nakon sortiranja dobijamo tabelu koja izgleda ovako:
Cifra
7
3
1
2
6
9
4
0
8
5
AES ifrovanje cifri - sortirano

12d76795b5e818b38be9813260ab0c5f
203c3c515ae6101c4858fe07ecb78ec0
25dabcc8862842c228a2d7ac5058b780
416f3563827406dab2efl246393fed32
45bd0fb7d45bd276d499ad4b8cd52e55
4c9c6ecbdflab60ef0b31d753fa594c6
4e20e4d8c4195df66a3cc9fe60f5b98f
5c3f46a3cf7a8da378eb95f546a20ab2
98bc8588c55900703efllfa80447e32c
d99851ff58a9bf03d717ff6601639795
Nakon toga moemo da odbacimo ifrovane vrednosti, ostavljajui samo permutaciju. U

ovom primeru, ifrovanje broja 2 daje 1. Deifrovanje se moe obaviti jednostavno tako da
pronaemo indeks ifrovane vrednosti. Na primer, ifrat od 7 odgovarae otvorenom tekstu za
0. Moemo da pravimo ovakve tabele za svaku veliinu skupa sve do neto ispod veliine
105
osnovne blok ifre. U sluaju da ulazni skup ima istu veliinu kao i blok ifra, onda se blok
ifra koristi direktno.
Podeavanje prefiks ifre (engl prefix cipher tweaking)

Zbog toga to nadifrovanje kod prefiks ifre zahteva ponovnu izradu tabele, bilo bi
poeljno da u izvesnim sluajevima budemo u stanju da primenimo kriptografsko poboljanje
ifre, to e izmeniti funkciju ifrovanja bez ponovne primene kljua. Osnovni metod za
primenu podeavanja T na ifru E (veliine N) koji se pokazao bezbednim jeste da se obavi
sledea operacija, na osnovu koje se ifruje neki otvoreni tekst P i pri tom se koristi klju K.
C E (( E ( P, K ) + T ) mod N , K )
Prirodno je da se ovakva konstrukcija smatra za neefikasnu, zato to ona zahteva dva

pozivanja osnovne ifre. U sluaju prefiks ifre, trokovi ifrovanja odlaze samo na
pretraivanje, pa je zato konstrukcija vrlo brza, i zahteva samo dva memorijska pretraivanja i
jednu dodatnu operaciju. Ova vrsta konstrukcije bie upotrebljena radi ifrovanja jedinstvenog
matinog broja.
Bezbednost prefiks metoda

U literaturi [10] postoji neposredan dokaz da se razbijanja ove konstrukcije svodi na
razbijanje osnovne ifre. Zakljuak je da bi iznalaenje razlike izmeu ove vrste prefiks
permutacije i sluajne permutacije zahtevalo pronalaenje razlike izmeu osnovne ifre i
sluajne permutacije.
7.2.2. Metod Kumulativnog ciklusa

Metod kumulativnog ciklusa (engl. cycle-walking), kao i prefiks metoda, je sasvim
jednostavna, ali primenjuje se na ogranienu klasu skupova. Funkcionie tako to obavlja
ponovljeno ifrovanje otvorenog teksta sa postojeom blok ifrom (AES ili 3DES) sve dotle
dok se izlazna ifra ne pojavi u prihvatljivom opsegu. Da bi obavili ifrovanje nekog teksta P
u opsegu 0
N , pri emu koristimo neku osnovnu ifru E, obavljamo sledeu operaciju:
C E (P)
While C > N
Do C E (C)
to je vea razlika izmeu veliine izlaza osnovne ifre i veliine eljenog izlaznog
skupa, to e biti due vreme ove operacije do njenog okonanja. Da bi ova konstrukcija bila
praktina, N bi trebalo da oznaava broj koji je za neki mali broj bitova krai od izlaznog
rezultata ifre.
106
Bezbednost metoda kumulativnog ciklusa

U literaturi [10] postoji dokaz da ifra Cycle-walking ne umanjuje bezbednost osnovne
ifre. Takoe, [10] sadri dokaz da e se metod okonati u svim sluajevima, premda je
mogue da se pojave retki sluajevi gde e biti neophodan veliki broj ciklusa.
7.2.3. Feistel + Kumulativni Metod

Ovaj metod je sloeniji od prefiks ili ponavljanja ciklusa konstrukcija, ali doputa
ifrovanje najrazliitijih veliina skupa uz dobre performanse.
Opis Feistel + kumulativnog algoritma

Feistel + Kumulativni algoritam se sastoji iz dva glavna dela. Prvo, izrauje se Feistel
mrea koja je najblia veliini otvorenog teksta. Nakon toga ona se koristi za ifrovanje
podataka. Zatim se koristi tehnika kumulativnog ciklusa da bi se osiguralo da ifrat bude u
odgovarajuem opsegu. Zbog toga to se osnovana ifra pravi tako da bude veoma blizu
eljene veliine ifrata (u okviru veliine manje od 2 bita) potreban je veoma mali broj ciklusa
da bi se ifrat postavio u eljeni opseg.
Feistelova konstrukcija za datu duinu bita n sastoji se od viestrukih ciklusa pri emu
se koristi neka pseudo-sluajna funkcija (engl. pseudo-random function PRF) F, koja uzima
n
n
bita i daje izlaz od
bita. Ona za ulaz uzima otvoreni tekst, koji se deli na levu i desnu
2
2
polovinu, sa oznakama L i R (od engl. left i right). Funkcija u ciklusu daje neki novi L i R,
koji je ili izlaz ili pak povratna sprega za sledei ciklus. Ta funkcija obavlja sledeu operaciju
kako bi se izraunale vrednosti za novi L i R:

R' L F(R)
L' R
Sledi detaljan prikaz algoritma:
Feistel mrea: Feistel N , F , X (P )
Ulaz:
P - otvoreni tekst koji se ifruje
P je u opsegu 0 N
F - pseudo-sluajna funkcija
X - broj rundi
107
odrediti najmanje koje zadovoljava 2 2 > log 2 N

( je irina Feistel-ove mree).
odrediti R, L takve da P R 2 + L
for i 0 to x 1
T L trunc( F ( R), )
LR
do
R T
return R 2 + L
Slino kao kod metode kumulativnog ciklusa, FC N , F , X (P ) se definie kao:

C Feistel N , F , X (P )
while C > N
do C Feistel N , F , X (C )
Da bi u potpunosti odredili Feistel-Kumulativ ifru za neki specifian sluaj, neophodno

je doneti odluku u vezi sa dve stvari. Prvo, koliki je broj ciklusa koje treba obaviti.
Neophodne bezbednosne granice se bez veih potekoa mogu ostvariti sa 8 ciklusa za
najvei broj podataka. Drugo, koju funkciju koristiti za PRF. Neophodna jaka sluajna
funkcija od
n
bita za najrazliitije n .
2
Problem izrade PRF-ova se nairoko prouava, i postoje dva metoda koji daju
prihvatljive PRF-ove koje bi se mogle koristiti. Potrebno je pronai presudo-sluajnu funkciju
koja je tano iste irine kao i levi element, tako da L moe da bude podvrgnut operaciji
iskljuivo ili ( ) sa izlazom. U sluaju da je n dovoljno mali, jednostavno uzimanje prvih
n
2
bitova iz AES u principu daje jak PRF. Ako je n vei, moe se uzeti izlaz iz dve instance
AES ifre i zajedno ih podvrgnuti operaciji xor.
Bezbednost Feistel+Kumulativ metode

Bezbednost ove ifre moe se izmeriti na tri razliita naina. Prvi se odnosi na otpornost
na napad od strane napadaa koji ima na raspolaganju neograniene kompjuterske resurse.
Drugi se odnosi na otpornost na napad kod kojeg se koristi gruba sila (engl. brute force).
Trei se odnosi na najpoznatiji napad kod kojeg se pravi razlika izmeu Feistel mree i
sluajnih permutacija.
108
Napadad 1: Napada ima na raspolaganju optimalne i neograniene

kompjuterske resurse
Za svaku Feistel mreu moemo da izmerimo koliinu entropije u odreenoj funkciji, da
procenimo koliko entropije odaje neki par otvorenog teksta/ifrata, i nakon toga izraunavamo
koliko parova otvorenog teksta/ifrata je neophodno za svakog eventualnog napadaa. Ovo je
najjai mogui model bezbednosti. Rezultat ovakve analize [5] jeste da najbolje opremljeni
napada treba
2n parova ifrata / otvorenog teksta, a pokazano je da je 6 rundi Feistelove
mree dovoljno da bi se dobila ova gornja granica. Ovo znai da svaki teoretski protivnik koji
napada 6 ili vie rundi Feistel mrea koje operiu sa 56 bita, to je inae skup neophodan za
brojeve kreditnih kartica, treba da ima na rasplolaganju minimalno 16 miliona parova
otvorenog teksta / ifrata. Za istu ifru koja dejstvuje iznad oblasti broja socijalnog osiguranja,
u kojoj je oko 28 bita, bie potrebno minimalno 16384 parova. Budui da je ovaj broj mali,
bie razmotrane hibridne tehnike u sledeem odljeku radi obrade ovog sluaja. Treba obratiti
panju da za Feistelovu mreu od preko 6 rundi, ove granice se postavljaju za mogueg
napadaa sa najveim raspoloivim resursima i nijedan drugi praktini napad ne moe da se
priblii ovim granicama.
Neogranieni model napada je najinteresantiniji zbog toga to obezbeuje jaku donju
granicu. Trenutno poznati napadi na Feistelove mree su daleko gori od ovakvih granica.
Napad 2: Napada koristi grubu silu

Napada koji bi se donekle najvie mogao uporediti sa napadaem koji poseduje
izuzetne raunarske resurse jeste onaj napada koji pokuava da naini zbir svih onih funkcija
zaokruivanja koje su konzistentne sa parovima otvorenog teksta / ifrata koje je uoio. Ovom
napadau bi trebalo 2 log 2 r+ n parova, i bie mu neophodno da obavi veoma veliki broj
raunanja. Moemo uoiti potekou za organizovanje ovakvog napada tako to emo ispitati
neophodne raunske operacije za napad na malu Feistelovu mreu irine 6 bita kod kojeg se
koristi osam rundi.
Feistelova mrea irine 6 bita e koristiti PRF od tri bita. Postoji 88 or 224 moguih
funkcija vog tipa. Sa osam rundi, za napadaa koji koristi grubu silu bie neophodno da prati
2192 moguih Feistel mrea, i da ih dalje eliminie onda kada ove postanu nekonzistente sa
parovima ifrata / otvorenog teksta. Mogue je da postoji izvesna optimizacija koja bi mogla
da obezbedi praktinost ovakvog napada, ali ini se da ak trivijalno mala Feistel mrea
zahteva, u ovom trenutku, neostvarivu koliinu raunarske snage.
Napad 3: Izvodljiv napad

U radu [10], prikazan je najbolji izvodljiv napad na Feistelove mree. Ovakvi napadi su
u principu ostvarljivi, ali zahtevaju vie parova ifrata/otvorenog teksta od onog broja koje
109
moe da proizvede samo jedan klju, a zahteva i raspolaganje znaajnim raunarskim

resursima. Ovi napadi su takoe jasno rapoznatljivi napadi kojim je napada u stanju da
odlui da li je par otvorenog teksta/ifrata proizveden od strane sluajne permutacije ili ga je
proizvela Feistelova mrea.
Da bi razlikovali neku Feistel mreu irine 2n bita od 8 ili vie rundi od sluajne
permutacije, potrebno je 2 ( r 6) n parova otvoreng teksta/ifrata, i 2 ( r 4) n izraunavanja. Stoga u
sluaju kreditne kartice sa 8 rundi, bilo bi neophodno 256 parova otvorenog teksta/ifrata, i 2112
koraka raunanja. Ovo znai da bi napada trebao da ima svaki pojedinani mogui par
otvorenog teksta/ifrata, i trebalo bi da obavi vie raunskih operacija nego to bi bilo
neophodno da se razbije klju od 80 bita. Poveavanjem broja izraunavanja iznad 8 ini
preduzimanje ovakvih napada jo teim.
7.2.4. Hibridni metod

Mogue je koristiti gore navedene metode u kombinaciji kako bi nam na raspolaganju
bile FPE tehnike koje e dopustiti pristup samo odabranim ciframa nekog broja (na primer,
ograniie aplikaciju korisnikog servisa na poslednje etiri cifre broja socijalnog osiguranja,
dok e nekoj drugoj aplikaciji dozvoliti potpuno korienje broja.) Ovi metodi mogu biti
upotrebljeni da bi se popunila praznina izmeu onog mesta na kom prefiks metod nije
praktian i one pozicije Feisel + Kumulativ konstrukcije gde se ova moda ne bi mogla
smatrati za potpuno bezbednom.
Hibridni metod za brojeve socijalnog osiguranja

Broj socijalnog osiguranja je interesantan zato to je ovo uobiajen tip PII, i on je
dovoljno mali da ne spada u oigledne granice za poznata tri, ve pokazana, FPE metoda.
Primer je dovoljno dobar da se njime moe predstaviti metod koji daje razumne granice
bezbednosti za ceo broj, i isto tako daje korisnu karakteristiku na osnovu koje je mogue da se
ili deifruje ceo broj ili samo etiri poslednje cifre, koje se esto koriste u aplikacijama gde
postoji potreba za potvrivanje identiteta.
Konstrukcija funkcionie na sledei nain. Kao osnovu za konstrukciju se koristi dve
ifre:
Pr e5( P, T , K ) : prefiks ifru na osnovu koje se obavlja ifrovanje svih pet cifara
vrednosti sa kljuem K, i nasumce odabrana vrednost za podeavanje T.

FC 9( P, K ) : ifra Feistel-Kumulativ na osnovu koje se ifruje svih devet cifara
decimalnih vrednosti uz pomo kljua K.

H ( P ) : He funkcija od etiri cifre.
110
Izradite dva kljua, K1 i K2. Podelite broj socijalnog osiguranja na pet inicijalnih cifara
L i poslednje etiri cifre R. Broj za ifrovanje se nakon toga izraunava na osnovu:
E FC 9(Pr e5( L, H ( R), K 1 ), K 2 )
Odreeni entitet moe da dobije uvid u poslednje etiri cifre tako to e mu se dodeliti
samo K 2 . On moe da koristi K 2 kako bi uklonio Feistel ifrovanje. Neki drugi entitet koji
ima pristup kljuevima K 1 i K 2 moe da deifruje ceo broj tako to e prvo da ukloni Feistel
ifrovanje uz pomo K 2 , nakon ega ide dalje na uklanjanje prefiks ifre uz pomo K 1 i
konano deifruje poslednje etiri cifre.
Inicijalno ifrovanje sa prefiks ifrom obezbeuje da mogui napada koji koristi manje
granice Feistel ifre obrauje malu oblast otvorenog teksta i stoga moe da obnovi (u
najgorem sluaju) poslednje etiri cifre broja i ifrovane verzije prvih pet cifara.
Metodi za brojeve kreditne kartice

Brojevi kreditne kartice su interesantan sluaj za FPE, budui da oni nose cifru provere
na kraju broja koji se izraunava uz pomo Luhn algoritma, koji predstavlja modifikovani zbir
cifara. Ovu cifru nije potrebno ifrovati, budui da se ona jednostavno moe iznova izraunati
kada se deifruju preostale cifre.
Postoje tri metoda da se obavi ifrovanje uz pomo ovakvog kontrolnog zbira:
Metod: Transparentno ifrovanje

Cilj ovakvog ifrovanja jeste da se obavi ifrovanje broja kreditne kartice tako da se
ifrovani broj ne moe uoiti na osnovu otvorenog teksta. Ovde se postie ouvanje validnog
kontrolnog zbira (checksum). Ovo je korisno zbog toga to e one aplikacije koje su sumnjive
nastaviti da i dalje funkcioniu bez modifikovanja. Rizik koji se ovde javlja, budui da one ne
mogu da uoe razlike, jeste da kao takve sluajno upotrebe neki od ifrovanih brojeva kao
broj originala. Zato je potrebno ifrovati sve cifre izuzev poslednje koristei neki od FPE
algoritama. Nakon ifrovanja, potrebno je izraunati kontrolnu cifru i dodati je ifrovanom
broju. U ovom sluaju, prednost je u tome to u svakoj aplikaciji koja testira kontrolu zbira
ifrovani brojevi izgledaju identino u odnosu na validne brojeve. Da bi obavili operaciju
deifrovanja, FPE deifruje sve cifre izuzev poslednje, nakon ega se obavlja regenerisanje
cifara kontrole provere na ciframa otvorenog teksta.
Metod: Oznaavanje kontrole zbira

U nekim sluajevima, bilo bi korisno obaviti ifrovanje tako da format bude sauvan, ali
da ipak postoji neka indikacija da je neki broj ifrovan. Na osnovu indukovanja sistematskog
pomaka u kontroli zbira, neki program moe da pouzdano ukae da je izvestan broj ifrovan,
111
ak i onda kada format ostaje isti. Posle ifrovanja broja, rauna se kontrolna cifra uveana za
odreenu konstantu. Ovo obezbeuje da kontrolna cifra postane nevaea, i daje nam pouzdan
metod da se utvrde razlike izmeu ifrovanog i originalnog broja kreditne kartice.
Metod: Kodiranje kontrole zbira

Konstantni pomak kontrole zbira se isto tako moe koristiti da bi se kodirala mala
koliina dodatnih informacija u cifri kontrole zbira. Ovo se moe iskoristiti za odabiranje iz
nekog kompleta kljueva, ime se doprinosi raznolikosti u postojeoj emi rukovanja
kljuevima.
Generie se devet kljueva, ifruju se sve cifre (ali ne i konana) sa jednim od ovih
kljueva, i zamene cifre za kontrolu zbira sa kontrolom zbira plus neki od kljueva na osnovu
ega e biti mogue utvrditi vrednost od 1 do 9. Ovo obezbeuje da kontrola zbira bude
nevalidna, i obezbeuje nam metod da izmenimo kljueve i ubeleimo koji klju je iskorien
za ifrovanje specifine vrednosti bez da se dodaju bilo kakvi drugi podaci u bazu podataka.
Ovo takoe obezbeuje i dodatnu vrednost za odabiranje, ali mora se dopuniti sa drugim
izvorima kako bi se utvrdio pravi klju, u kom sluaju se koristi vie od 9 kljueva.
7.3. Rezultati
7.3.1. Performanse prefiks metoda
Prefiks metod se moe posmatrati kao da ima veoma spori period za pripremu kljua
(izrada permutacije unutar memorije) i veoma brzo vreme ifrovanja i deifrovanja
(obavljanje samo jednog pretraivanja u tabeli). Pitanje u vezi perfomanse svodi se na vreme
koje je neophodno da se izradi tabela i neophodna koliina memorije koja bi sadravala
tabelu.
Jedna od korisnih optimizacija jeste da se u poetku ifruju elementi skupa, a da se
samo ubelee poetna 32 bita u tabeli. Sortiranje tabele se nakon toga moe uraditi na osnovu
ova 32 bitna elementa, i u sluaju da su dva elementa ekvivalentna, poreenje e se obaviti
nad ponovno ifrovanim vrednostima. Ovakva optimizacija smanjuje tabelu i smanjuje
koliinu kopiranja podataka pri sortiranju.
Sledea tabela pokazuje perfomansu prefiks ifre, pri emu se koristi AES-256 kao
osnovna ifra, pri razliim podeenim veliinama skupova na 2.34 Ghz Pentium IV sa
memorijom od 1 GB na Microsoft Windows XP Professional sistemu. Budui da ifrovanje i
deifrovanje nije zahtevan zadatak (zahteva samo jedno pretraivnje memorije), jedino je
prikazano vreme izrade tabele kljua.
112
Tabela pokazuje veliinu otvorenog teksta u bitovima, broj decimalnih cifara koje se
mogu kodirati pomou ifre i vreme potrebno da bi se nainila tabela sa prikazom u
milisekundama.
Bitovi Decimalne cifre
Vreme izrade tabele (ms)
10
0.476
14
5.5
17
62
20
760
Tabela 19: Izrada tabele kod Prefix FPE metode
7.3.2. Performanse metoda kumulativnog ciklusa

Sledea tabela prikazuje performanse metoda ponavljanja ciklusa gde se koristi 3DES
za razliite veliine skupa koje iznose blizu 64 bita. Merenja su vrena na 2.34 Ghz Pentium
IV uz memoriju od 1GB, a obrada se odvijala na Windows XP Professional. Tabela pokazuje
veliinu bita izlaza, broj kodiranih decimalnih cifara i broj operacija ifrovanja u sekundi.
Vremena su beleena na osnovu generisanja sluajne decimalne vrednosti u prikazanom
opsegu, nakon ega se ova pakuje u binarni oblik, a ifrovanje koje koristi 3DES u modu
kumulativnog ciklusa.
Bitovi Cifre ifrovanje / sekunda
54
16
500
57
17
5000
60
18
43000
64
19
150000
Tabela 20: Performanse metoda ponavljanja ciklusa
Kao to se moe videti iz tabele, Kumulativni ciklus metod daje upotrebljivu ifru za
vrednosti u opsegu veliina za brojeve standardne kreditne kartice, ija duina opsega iznosi
od 16-19 cifara.
7.3.3. Performanse Feistel + Kumulativ metoda

Performanska Feistel + Kumulativ metode zavisi od broja rundi koja se koriste i
specifine PRF koja se koristi u samoj rundi. Za svaki otvoreni tekst koji je manji od blok
veliine PRF-a, perfomansa je u sutini i r ( PRF ) , gde r predstavlja broj rundi dok je i
prosean broj ciklusa potreban da bi se dobio prihvatljiv izlaz. Za AES PRF sa odbacivanjem
bita, perfomansa se prilino pribliava i r ( AES ) + ( AES _ SETUP ) . Za AES sa
udvajanjem performanse su za 50% loije.
113
Merenja metoda Feistel+Kumulativ je obavljeno na 2.34 Ghz Pentium IV uz memoriju

od 1 GB na Windows XP Professional sistemu, pri emu se AES koristi kao baza za interni
PRF. Merenje ifre je obavljeno za broj rundi u opsegu od 8 do 128, pri emu se koriste kako
odseak (ili odseena konstrukcija) tako i dodatne PRF konstrukcije.
Ciklus
PRF
128
Trunc
7000
32
Trunc
10500
Trunc
18000
Add
8100
Kod/Sek
Merenje sa velikim brojem rundi je obavljano da bi se ispitala mogunost upotrebe

rundi sa veim brojem iteracija kako bi se osujetila mogunost napada u najgorem sluaju,
napada grubom silom, koji inae moe da ima uspeha kod podataka sa malim brojem bita.
114
8. Zakljuak
1. U radu je istraena kriptografija kao jedna od opcija sigurnosti podataka u sistemima baza
podataka.
Rezultati analize su potvrdili da se primenom kriptografskih mehanizama, u kombinaciji
sa klasinim bezbednosnim mehanizmima kontrole pristupa na bazi privilegija dobija
najbolja zatita podataka u bazama.
2. Istraivanje je potvrdilo da je kriptografija jo jedan bezbednosni sloj, koji se mora mudro
koristiti, poto se u suprotnom celokupna bezbednost nee poveati, a mogua je i
degradacija performansi celog sistema. Najgore od svega je da se moe stvoriti lani
osjeaj sigurnosti.
3. Eksperimentalni rezultati merenja performansi ispitivanih kriptografskih metoda za zatitu
linih identifikacionih podataka, uz ouvanje formata, pokazuju da su performanse svakog
od prikazanih algoritama prihvatljive. Predloeni algoritmi pokrivaju irok opseg
identifikacionih brojeva, od onih od par cifara pa do kreditnih kartica koje idu i do 19
cifara, te se mogu upotrebiti u produkcionom okruenju.
115
9. Literatura
[1]
George Mason University, School of Law: President's Commission on Critical

Infrastructure Protection (PCCIP) Reports
[2] Beauregard , J., E.: Modeling Information Assurance, Air Force Institute Of Technology
[3] Denning, D., Concerning Hackers Who Break Into Computer Systems - National
Computer Security Conf., 1990
[4] Pleskonji, D., Maek, N., orevi B., Cari M., Sigurnost raunarskih sistema i
mrea, Mikro knjiga, 2007.
[5] Kenan, K., Cryptography in the Database, Symantec Press, 2006.
[6] Stanii, M., SARBANES - OKSLI ZAKON, Institut za ekonomiku i finansije.
[7] Jovaevi D., Haimbegovi, T.: Krivinopravna zatita bezbednosti raunarskih
podataka, ZITEH 2008.
[8] Fowler, M., Uml Distilled, Pearson Education, Inc., 2004
[9] Galbreath, N., Cryptography for Internet and Database Applications, Wiley Publishing,
Inc. 2002
[10] Black, J., Rogaway, P., Ciphers with Arbitrary Finite Domains, RSA Data Security
Conference, Cryptographer's Track, Lecture Notes in Computer Science, Springer, 2002
[11] Spies, T., Feistel Finite Set Encryption Mode, Voltage Security, Inc.
[12] NIST Special Publication 800-57, Recommendation for Key Management
116
10. Spisak slika

Slika 1: Jedan entitet u interakciji sa sistemom........................................................................ 46
Slika 2: Dva entiteta u interakciji sa sistemom ........................................................................ 47
Slika 3: Finalni model kriptografske arhitekture...................................................................... 47
Slika 4: Separacija kljueva, dve familije kljueva.................................................................. 50
Slika 5: Grupe familija nad jednom kolonom .......................................................................... 51
Slika 6: Kriptografske potvrde o opsezima .............................................................................. 52
Slika 7: Stanja kljua sa prelazima........................................................................................... 54
Slika 8: Dijagram sekvenci za proces ifrovanja ..................................................................... 59
Slika 9: Fiziki model BP za podrku upravljanja kljuevima ................................................ 60
Slika 10: Hijerarhija kljueva u SQL Serveru 2008................................................................. 78
117
11. Spisak tabela

Tabela 1: Set zakona o privatnosti podataka............................................................................ 15
Tabela 2: Dozvoljene kriptografske operacije i stanje kljua .................................................. 55
Tabela 3: Poreenje mogunosti starog i novog kriptolokog paketa, Ora9 - Ora10 .............. 63
Tabela 4: Rutine paketa DBMS_OBFUSCATION ................................................................. 66
Tabela 5: Tip podataka koje koriste rutime iz paketa DBMS_CRYPTO ................................ 67
Tabela 6: He funkcije paketa DBMS_CRYPTO .................................................................... 67
Tabela 7: MAC funkcije DBMS_CRYPTO paketa ................................................................. 68
Tabela 8: ifarski algoritmi DBMS_CRYPTO paketa ............................................................ 68
Tabela 9: DBMS_CRYPTO Blok ifarski paketi .................................................................... 68
Tabela 10: Izbor ulanavanja kod blok ifarskih sistema paketa DBMS_CRYPTO............... 68
Tabela 11: Dopunjavanje bloka blok ifara u paketu DBMS_CRYPTO................................. 69
Tabela 12: Izuzeci u paketu DBMS_CRYPTO........................................................................ 69
Tabela 13: Poveanje duina izlaznog ifrata u odnosu na ulazni otvoreni tekst .................... 76
Tabela 14: Kriptoloki vani sistemski pogledi ....................................................................... 93
Tabela 15: Funkcionalnost pgcrypto modula sa i bez OpenSSL podrke................................ 98
Tabela 16: Podrani algoritmi kod odreivanja hea lozinke .................................................. 99
Tabela 17: Broj iteracija pri generisanju salt vrednosti.......................................................... 100
Tabela 18: Algoritmi kriptografskog ouvanja formata......................................................... 105
Tabela 19: Izrada tabele kod Prefix FPE metode................................................................... 113
Tabela 20: Performanse metoda ponavljanja ciklusa............................................................. 113
118
12. Prilozi
Naredba T-SQL
Opis
Potrebne
dozvole
ALTER SERVICE
MASTER KEY
Menja karakteristike master kljua servera,

kao to je regenerisanje i oporavak kljua
CONTROL
SERVER
BACKUP/RESTORE
SERVICE MASTER
KEY
Omoguuje arhiviranje/vraanje master

kljua servera
CONTROL
SERVER
CREATE MASTER
KEY
Kreira master klju baze. Novokreirana baza CONTROL nad

bazom
nema klju dok se eksplicitno ovom
naredbom ne kreira.
OPEN/CLOSE
MASTER KEY
Eksplicitno otvara master klju baze

(simetrian klju!). Potreno u sluaju da
kjlu nije snimljen u sys.databases unutar
master baze.
CONTROL nad
bazom
BACKUP/RESTORE
MASTER KEY
Omoguuje snimanje/vraanje master kljua

baze.
CONTROL nad
bazom
DROP MASTER KEY
CONTROL nad
Uklanja master klju baze. Mogue samo u
sluaju da ne postoje kljuevi zatieni ovim bazom
kljuem.
CREATE/ALTER
CERTIFICATE
Kreira/modifikuje sertifikat. Dozvoljava

uitavanj sertifikata iz raznih datoteka i
objekata.
CREATE
CERTIFICATE
u bazi ili
ALTER nad
sertifikatom
CONTROL nad
sertifikatom
DROP CERTIFICATE
Uklanja sertifikat iz baze, samo u sluaju

kada ne postoje kljuevi zatieni
konkretnim sertifikatom
BACKUP
CERTIFICATE
Arhivira sertifikat u datoteku, uz mogunost

uvanja privatnog kljua u posebnoj
datoteci. Sertifikat se vraa u upotrebu
naredbom CREATE CERTIFICATE sa
iskazom FROM FILE.
VIEW
DEFINITION
nad
bazom,
CONTROL nad
sertifikatom
Kreira / modifikuje asimetrini klju sa

izborom algoritma i naina zatite.
CREATE
ASYMMETRIC
KEY nad bazom
/CONTROL nad
kljuem
CREATE/ALTER
ASYMMETRIC KEY
119
DROP ASYMMETRIC
KEY
CREATE/ALTER
SYMMETRIC KEY
Uklanja klju iz baze podataka, samo pod

uslovom da ne postoje kljuevi zatieni
ovim kljuem.
CONTROL nad
kljuem
Kreira/modifikuje simetrini klju, sa

izborom algoritma i naina zatite.
ALTER
ANY
SYMMETRIC
KEY
nad
bazom/ ALTER
nad kljuem
VIEW
DEFINITION
nad kljuem / za
zatvaranje nije
potrebna dozvola
CONTROL nad
kljuem.
OPEN/CLOSE
SYMMETRIC KEY
Deifruje klju i sprema ga za upotrebu /

uklanja klju iz memorije. Zahtevana radnja
pre upotrebe bilo kog simetrinog kljua,
osim master kljua baze podataka.
DROP SYMMETRIC
KEY
Uklanja klju iz baze podataka, samo pod

uslovom da nema podataka i kljueva koji
su zatieni ovim kljuem.
EncryptByCert
DecryptByCert
ifruje / deifruje podatke korienjem

sertifikata
ifruje / deifruje podatke korienje

asimetrinog kljua.
EncryptByAsymKey
DecryptByAsymKey
EncryptByKey
DecryptByKey
EncryptByPassphrase
DecryptByPassphrase
ifruju / deifruju podatke korienjem

simetrinog kljua.
ifrovanje / deifrovanje korisnikom

lozinkom
Za zadati naziv sertifikata vraa njegov ID
Cert_ID
AsymKey_ID
Key_GUID
Za zadati naziv asimetrinog kljua vraa

njegov ID.
Za zadati naziv simetrinog kljua, vraa
njegov GUID
VIEW
DEFINITION
and sertifikatom.
Bez ove dozvole
funkcije vraaju
NULL.
VIEW
DEFINITION
nad asimetrinim
kljuem.
Bez
ove
dozvole
funkcije vraaju
NULL.
Jedino
ogranienje je da
klju mora biti
otvoren,
inae
funkcije vraaju
NULL.
Nema
VIEW
DEFINITION
nad setifikatom
VIEW
DEFINITION
nad asimetrinim
kljuem.
VIEW
DEFINITION
nad simetrinim
120
Key_ID
Za zadati naziv simetrinog kljua vraa

njegov ID
kljuem
VIEW
DEFINITION
nad simetrinim
kljuem.
Prilog 1: Ugra ena kriptografija u Transact-SQL
121

MRR - Kriptografska Zaštita Baza Podataka

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MRR - Kriptografska Zaštita Baza Podataka

Uploaded by

Copyright:

Available Formats

Fakultet za informatiku i menadment

Univerzitet Singidunum Beograd

Kriptografska zatita baza podataka

Beograd, maj 2010. godine

Damjanovi , S. 2010. Kriptografska zatita baza podataka

2. BAZE PODATAKA I BEZBEDNOST STANDARDNI MEHANIZMI.....................................................8

3. ZAKONSKA REGULATIVA .........................................................................................................................14

4. NAPADI NA BAZE PODATAKA ..................................................................................................................37

6. PRIKAZ POSTOJE IH REENJA ZATITE ............................................................................................62

7. PRIKAZ SLU AJA .......................................................................................................................................102

SPISAK SLIKA .......................................................................................................................................117

SPISAK TABELA ...................................................................................................................................118

Univerzitet Singidunum Beograd, Fakultet za informatiku i menadment

Damjanovi , S. 2010. Kriptografska zatita baza podataka

Univerzitet Singidunum Beograd, Fakultet za informatiku i menadment

Damjanovi , S. 2010. Kriptografska zatita baza podataka

1. METODOLOGIJA ISTRAIVAKOG RADA

Univerzitet Singidunum Beograd, Fakultet za informatiku i menadment

Damjanovi , S. 2010. Kriptografska zatita baza podataka

U etvrtom poglavlju prikazano je deset najeih napada na baze podataka, zajedno sa

Univerzitet Singidunum Beograd, Fakultet za informatiku i menadment

Damjanovi , S. 2010. Kriptografska zatita baza podataka

1.3. Ciljevi istraivanja

Univerzitet Singidunum Beograd, Fakultet za informatiku i menadment

Damjanovi , S. 2010. Kriptografska zatita baza podataka

metoda analize i sinteze,

Univerzitet Singidunum Beograd, Fakultet za informatiku i menadment

Damjanovi , S. 2010. Kriptografska zatita baza podataka

2. Baze podataka i bezbednost standardni mehanizmi

Univerzitet Singidunum Beograd, Fakultet za informatiku i menadment

Damjanovi , S. 2010. Kriptografska zatita baza podataka

Damjanovi , S. 2010. Kriptografska zatita baza podataka

radi smanjenja rizika od kompromitovanja. Za naloge pojedinaca, sistem za proveru identiteta

Neovlatena korisnika aktivnost

Damjanovi , S. 2010. Kriptografska zatita baza podataka

neautorizovanim korisnicima koji mogu kompromitovati poverljive podatke. Organizacije se

Nezatieno preuzimanje (engl. download) datoteka

Lokalne mree (engl. local area networks)

Univerzitet Singidunum Beograd, Fakultet za informatiku i menadment

Damjanovi , S. 2010. Kriptografska zatita baza podataka

Dodela samo nunih prava pristupa (engl. need-to-know basis)

Odvajanje dunosti (engl. separation of duties)

Rotacija dunosti (engl. rotation of duties)

Univerzitet Singidunum Beograd, Fakultet za informatiku i menadment

Damjanovi , S. 2010. Kriptografska zatita baza podataka

Modeli integriteta opisuju naine ostvarivanja politike integriteta. Ouvanje integriteta

Univerzitet Singidunum Beograd, Fakultet za informatiku i menadment

Damjanovi , S. 2010. Kriptografska zatita baza podataka

Univerzitet Singidunum Beograd, Fakultet za informatiku i menadment

Damjanovi , S. 2010. Kriptografska zatita baza podataka

Potrebni koraci u procesu: detaljno objanjenje zahteva koji se odnose na programere.

Usklaenost sa zakonom je vano pitanje i za korisnike softvera. Svoje zahteve po

Univerzitet Singidunum Beograd, Fakultet za informatiku i menadment

Damjanovi , S. 2010. Kriptografska zatita baza podataka

3.1. Sarbanes - Oksli, odeljak 404

Univerzitet Singidunum Beograd, Fakultet za informatiku i menadment

Damjanovi , S. 2010. Kriptografska zatita baza podataka

3.1.2. Obavezni koraci

3.1.3. Tehnologije i tehnike

Univerzitet Singidunum Beograd, Fakultet za informatiku i menadment

Damjanovi , S. 2010. Kriptografska zatita baza podataka

Dostupnost: Jedan od zahteva SOX je i dostupnost finansijskih podataka ovlaenom

Damjanovi , S. 2010. Kriptografska zatita baza podataka

podataka u gomili nevanih. Od ovakve vrste napada, organizacija se titi tako to e