UNIVERZA V MARIBORU FAKULTETA ZA ELEKTROTEHNIKO, RAČUNALNIŠTVO IN INFORMATIKO 2000 Maribor, Smetanova ul. 17 Diplomska naloga visokošolskega študijskega programa VARNOST PODATKOVNE BAZE PostgreSQL Študent: Zoran KREBS Študijski program: Visokošolski, Računalništvo in informatika Smer: Informatika Mentor: red. prof. dr. Tatjana WELZER Maribor, april 2008
81
Embed
VARNOST PODATKOVNE BAZE PostgreSQL - core.ac.uk · podatkov, ki jih sre čujemo v okviru svetovnega spleta (slike, zvok, animacije, VRML, Java apleti, ipd). Slabost objektnih baz
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
UNIVERZA V MARIBORU
FAKULTETA ZA ELEKTROTEHNIKO, RAČUNALNIŠTVO IN INFORMATIKO 2000 Maribor, Smetanova ul. 17
Diplomska naloga visokošolskega študijskega programa
The diploma work discusses the database security problem, security and protection
elements which have to be considered when designing databases, methodologies and
techniques for securing databases. The security considerations are applied to the
PostgreSQL database. Additionally, we deal with security mechanisms and solutions which
contribute to higher security. In this context authentication, authorization, inconsistency
protection, database replication, data storage modes and data restoration from backup
copies are focused on.
Zoran Krebs - diplomsko delo 6
UPORABLJENE KRATICE
PB Podatkovna Baza
SUPB Sistem za Upravljanje s Podatkovno Bazo
SQL Structured Query Language
DBMS Database Management System
IS Informacijski Sistem
WAL Write Ahead Log
DRP Disaster Recovery Plan
VRML Virtual Reality Markup Language
OLAP On Line Analytical Processing
ACID Atomicity Consistency Isolation Durability
MVCC Multi-Version Concurrency Control
PITR Poin In Time Recovery
SSL Secure Sockets Layer Protocol
EMEA območje držav Evrope, Bližnjega Vzhoda in Afrike
2PL Two Phase Locking
€ evro
Zoran Krebs - diplomsko delo 7
KAZALO
1. UVOD................................................................................................................................ 9 1.1. Definicija podatkovne baze ...................................................................................... 10 1.2. Klasifikacija podatkovnih baz .................................................................................. 11 1.3. Značilnosti današnjih podatkovnih baz .................................................................... 11 1.4. Kratek opis in zgodovina PostgreSQL ..................................................................... 13
1.4.1. Značilnosti PostgreSQL..................................................................................... 14 1.5. Primerjava z ostalimi produkti ................................................................................. 14
2. VARNOST PODATKOV V PODATKOVNIH BAZAH............................................... 17 2.1. Kratek opis problema varnosti v podatkovnih bazah ............................................... 17
2.1.1. Varnost v spletnem poslovanju (med podjetji).................................................. 18 2.1.2. Varnost v okviru zaključene celote (znotraj podjetja)....................................... 19 2.1.3. Izguba podatkov ................................................................................................ 20 2.1.4. Nekonsistentnost podatkov................................................................................ 22 2.1.5. Okrevalni načrt .................................................................................................. 23
2.2. Zaščita podatkovne baze........................................................................................... 23 2.2.1. Nadzor dostopa .................................................................................................. 24 2.2.2. Zaščita pred nekonsistentnostjo podatkov......................................................... 29 2.2.3. Zaščita pred izgubo podatkov............................................................................ 33 2.2.4. Zaščita pred preveliko obremenitvijo ................................................................ 35
3. VARNOST PODATKOV V PostgreSQL....................................................................... 39 3.1. Logična in fizična urejenost datotek......................................................................... 39 3.2. Nadzor dostopa ......................................................................................................... 41
4.5.1. Omejevanje dostopa do podatkovne baze PostgreSQL..................................... 61 4.5.2. Opis postavitve shem, pravic, uporabnikov ...................................................... 62
Zoran Krebs - diplomsko delo 8
4.5.3. Opis izdelave varnostne kopije podatkovne baze.............................................. 64 4.5.4. Povrnitev podatkov iz varnostne kopije ............................................................ 67 4.5.5. Opis postavitve replikacijskega strežnika ......................................................... 69
5. Zaključek ......................................................................................................................... 78 6. Literatura ......................................................................................................................... 80 KAZALO SLIK
slika 1: delitev uporabnikov, povzeto po [25] ..................................................................... 28 slika 2: primer enostavne mrtve zanke ................................................................................ 31 slika 3: gradniki podatkovne baze PostgreSQL, povzeto po [7] ......................................... 40 slika 4: primer pg_hba.conf datoteke .................................................................................. 61 slika 5: kreiranje podatkovne sheme ................................................................................... 62 slika 6: kreiranje nove uporabniške skupine........................................................................ 63 slika 7: kreiranje uporabnika, določitev skupine ................................................................. 64 slika 8: določimo ime ter mesto datoteke ............................................................................ 66 slika 9: poiščemo varnostno kopijo iz katere želimo povrniti podatke ............................... 68 slika 10: obvestilo, da je povrnitev končana........................................................................ 69 Slika 11: na podatkovni bazi »master« napravimo gručo test1 ........................................... 72 Slika 12: dodajanje podatkovne baze »slave1« v gručo test1 ............................................. 72 Slika 13: Podatkovni bazi »master« in »slave1« se zavedata ena druge ............................. 73 Slika 14: v primeru, da »Running PID« na enem izmed vozlišč ni nastavljen je prišlo do napake v enem izmed prejšnjih korakov ............................................................................. 74 Slika 15: na vozlišču »MasterNode« definiramo povezave do podatkovne baze »slave1« 75 Slika 16: na vozlišču »SlaveNode« definiramo parametre povezave do podatkovne baze »master« .............................................................................................................................. 75 Slika 17: prikazuje, kako napravimo replikacijsko množico............................................... 76 Slika 18: prikazuje, kako smo v podatkovni bazi »master« definirali replikacijsko množico »rep set 1«, ki replicira tabelo »testSchematestTable« na podatkovno bazo »slave1« ....... 77 KAZALO TABEL
• ostalimi podatkovnimi nesrečami (virusi, napake v strojni opremi, napake v
programski opremi, človeške napake)
Osnovni namen zaščite podatkovne baze je zaščita pred grožnjami z uporabo
tehničnega in administrativnega nadzora. Grožnje zaščiti podatkovne baze prihajajo iz
različnih virov:
2 Dovoljena je sprememba s strani pooblaščenega uporabnika s pooblaščenimi procesi in po sprejemljivih poteh
Zoran Krebs - diplomsko delo 18
• fizično okolje (varno okolje za datoteke, procese in opremo, varno pred sevanjem)
• zunanje procedure (zaščita pri posamezniku, zaščita gesel, nadzor aplikacijskih
programov)
• shranjevanje podatkov (kodiranje in prikrivanje podatkov, rezervne kopije)
• programska oprema (nadzor dostopa, napad na transakcije)
• procesor (zaščita pomnilnika, stanje privilegija, zanesljivost delovanja)
• komunikacije (prikrivanje podatkov med prenosom)
Problem varnosti podatkovne baze v podjetjih lahko razdelimo na dva velika sklopa:
• varnost v spletnem poslovanju (zunaj – med podjetji, organizacijami)
• varnost v okviru zaključene celote, to je v zaprtem okolju (znotraj podjetja,
organizacije)
2.1.1. Varnost v spletnem poslovanju (med podjetji)
Varnost je najbolj zaskrbljujoč parameter pri selitvi poslovanja v svetovni splet, zato
bomo v nadaljevanju izpostavili nekatere principe, ki vodijo k varnejši, če že ne popolno
varni, izmenjavi podatkov. Pri nekaterih objektnih jezikih (npr. Java) za varnost skrbi
upravitelj varnosti. Implementirajo ga različna podjetja, ki izdelujejo Java navidezne stroje
(pogosto gre za pregledovalnike). Vanj je vgrajen določen varnostni vzorec, ki apletom3 s
proženjem izjeme in zaustavitvijo izvajanja, preprečuje nedovoljene aktivnosti (dostop do
lokalnih zbirk, povezavo s poljubnim spletnim strežnikom, uporabo različnih protokolov,
klice metod drugih programskih jezikov, itd.). Nekaj več svobode lahko ponudimo
zaupanja vrednim apletom. To dosežemo z uvedbo digitalnega podpisa.
Digitalni podpis temelji na enkripciji podatkov s pomočjo ključa. Ključ je podatek, ki
ga uporabimo pri pretvorbi začetnih podatkov v obliko, ki je nerazumljiva (šifrirana). Če
želimo ponovno prvotno obliko podatkov, potrebujemo isti ali nek drug ustrezen (ne
katerikoli) ključ. Z njim podatke dešifriramo. V ta namen je razvitih več postopkov.
Digitalni podpis temelji na postopku uporabe javnega ključa (angl. public key encryption).
3 aplet je javanski program, ki teče znotraj brskalnika. Je del določene spletne strani in se na računalnik naloži ob odpiranju strani. Za aplet veljajo določene varnostne omejitve, da onemogočimo morebitno škodo.
Zoran Krebs - diplomsko delo 19
Postopek je sledeč: uporabnik si ustvari dva ključa. Prvi se imenuje javni, drugi pa
privatni. Privatni ključ dešifrira podatke šifrirane z javnim ključem. Javni ključ je dobil
ime na podlagi njegove uporabe. Uporabnik namreč le tega javno objavi (prenese ga na
ustrezen temu namenjen strežnik) in s tem omogoči vsem, ki mu želijo poslati podatke
njegovo uporabo. Podatke šifrirane z javnim ključem dešifrira privatni ključ. Z javnim
ključem lahko podatke samo šifriramo. Prav tako je iz javnega ključa praktično nemogoče
dobiti privatni ključ.
Tehniko javnega ključa lahko uporabimo za podpisovanje apletov. Postopek je sledeč:
z uporabo privatnega ključa izdelamo digitalni podpis, ki temelji na določenem apletu.
Uporabnik, ki želi preveriti verodostojnost tega apleta, potrebuje originalni aplet, digitalni
podpis, ki temelji na tem apletu in javni ključ uporabljenega privatnega ključa. Z uporabo
javnega ključa lahko preverimo, ali se podpis in aplet ujemata.
Uporaba zgolj digitalnega podpisa ima vrzeli, ki se lahko zaradi uporabe protokola http
manifestirajo v obliki zlorab. Primer tega je lažno predstavljanje, kjer naslovimo spletni
strežnik, ki se predstavlja kot drug spletni strežnik. Uporaba varnega protokola (npr. SSL –
angl. Secure Sockets Layer Protocol) in s tem strežnika, ki tak protokol podpira, nam
tovrsten problem odpravi. Zagotovi nam avtentičnost strežnika, podatke pa pred
pošiljanjem samodejno šifrira. Šifriranje se vrši na nivoju protokola. Za varno poslovanje
moramo tudi pri apletih temeljiti na varnem protokolu. Za doslednost pri uporabi
protokolov poskrbi upravitelj varnosti, ki ne dopušča uporabe različnih protokolov znotraj
apleta. Praktično to pomeni, da moramo aplet naložiti s protokolom https, če želimo, da
aplet pošilja podatke po tem protokolu torej šifrirane. Omejitev je v tem primeru logična.
Če želimo varno pošiljanje podatkov, moramo tudi sam aplet naložiti s pomočjo protokola,
ki ne dopušča poneverb. Protokol SSL [3] je v takšnem primeru vgrajen v spletni strežnik
oziroma pregledovalnik, zato je dovolj, če aplet pri komunikaciji uporabi razred URL.
2.1.2. Varnost v okviru zaključene celote (znotraj podjetja)
Na spletnih straneh Computer World-a [8] so poročali, da se 80 odstotkov vdorov v
podatkovne baze izvrši od zunaj, kar pomeni, da je v 20 odstotkih možno, da v bazo
podatkov vdre zaposleni v (napadenem) podjetju. Tveganje, da ukradene podatke
posamezniki zlorabijo, se ne more izničiti. »Posledično s tem, je to eden največjih virov
Zoran Krebs - diplomsko delo 20
podatkov varnostne ranljivosti in ena največjih nevarnostih, proti kateri se podjetja le
stežka zavarujejo.«
Če upoštevamo dejstvo, da administrator podatkovnih baz upravlja s programsko
opremo za upravljanje s podatkovnimi bazami in odloča o načinih organizacije in shrambe
vseh občutljivih podatkov, bi lahko bil on popoln vohun, ki bi kopiral ali uporabljal
podatke o podjetju, zaposlenih ali o strankah, v škodoželjne namene. Že preprosta
nemarnost, namerna ali nenamerna, lahko podjetju povzroči obilo preglavic in škodo. Nek
uslužbenec, ki ima običajen dostop do podatkov, bi lahko določene podatke spravil na svoj
prenosni računalnik in ga nesel na poslovno potovanje ... kaj bi se zgodilo v primeru, če bi
prenosnik ukradli, ali če bi ga uslužbenec kje pozabil in bi bili podatki na voljo vsem?
Tovrstnih prevar ni lahko odkriti, še posebej ne tistih, ki prihajajo od znotraj. Vseeno pa je
sedaj na voljo programska oprema, s pomočjo katere lahko varujemo podatke pred
Vidimo, da so poleg vdorov od zunaj zelo pogosti vdori od znotraj na račun
pomanjkljivega fizičnega varovanja računalniške opreme ali slabega izkoriščanja
varnostnih možnosti, ki so v okviru podatkovne baze. Prepogosto se dodeli uporabnikom
kar administratorske pravice nad celotno podatkovno bazo ali celo nad celotnim SUPB. Tu
imamo veliko možnosti: od definiranja shem (shema je posamezni imenski prostor znotraj
podatkovne baze), dodelitve uporabniških računov in gesel uporabnikom, definiranja
minimalnih pravic pri delu s podatkovno zbirko.
2.1.3. Izguba podatkov
Podjetje Hitachi, proizvajalec trdih diskov in shranjevalnih rešitev, je v okviru svojih
rednih raziskav (Hitachi Data Systems Storage Index 2004) [23] [24] naredilo anketo med
840 vodji informatike v 21 državah območja EMEA (Europe, Middle East and Africa) in
ugotovilo, da jih 81% enači pojem dostopnosti podatkov (angl. data availability) s pojmom
neprekinjenega poslovanja (angl. business continuity). To vsekakor jasno kaže, da
zanesljiv dostop do podatkov v vsakem trenutku pogojuje uspešno poslovanje podjetja. Če
lahko sodimo po rezultatih raziskave o izgubi podatkov v Evropi, bo vsaj 6% osebnih
Zoran Krebs - diplomsko delo 21
računalnikov utrpelo izgubo podatkov v enem izmed naslednjih let, kar predstavlja 1,7
milijona "incidentov".
Stanje naj bi bilo precej podobno tudi v ZDA in drugod po svetu. Hitachi navaja nekaj
glavnih razlogov za izgubo podatkov:
• strojna okvara, vključno z okvarami zaradi prenapetosti in odpovedi trdih diskov
(42%);
• človeške napake, kar vključuje pomotoma izbrisane datoteke, neizvajanje ali
napačno izvajanje arhiviranja ipd. (31%);
• programska napaka, napake v programski kodi, ki imajo za posledico
nekonsistentne podatke ali njihovo brisanje (13%);
• virus (raziskava varnostnega podjetja ICSA.NET je pokazala, da je kar 40%
podjetij prijavilo izgubo podatkov zaradi virusov);
• kraja, še posebej kraja prenosnih računalnikov (5%);
• uničenje infrastrukture (poplave, požari, udari strele in prenapetosti, skupaj 3%)
2.1.3.1. Kakšna je (lahko) škoda?
Pri posameznem primeru reševanja podatkov po takšnih incidentih se običajno zgodi
ena od dveh "robnih" možnosti: uspešno povrnemo podatke ali pa jih izgubimo za vedno.
K sreči je po izjavah strokovnjakov podatke možno povrniti v približno 80% vseh
primerov, seveda za določeno ceno [24]. Tako naj bi na primer delo internega strokovnjaka
v podjetju podjetje stalo okrog 30 € na uro, povrnitev podatkov pa naj bi v povprečju
trajala 6 ur, kar torej znese 180 €. Vpoklic pomoči od zunaj pa naj bi ta strošek podvojil,
povprečni znesek torej naraste na 360 €. Že zgoraj omenjene številke niso majhne, še večji
strošek pa predstavlja izguba zaradi nižje produktivnosti uporabnikov, kar vpliva na
prodajo in dobičkonosnost. Nižja produktivnost pomeni v povprečju 25 € na uro, kar v
primeru 6-urnega nedelovanja doda 150 € k stroškom reševanje problema.
Ne pozabimo, to je bila optimistična možnost, ko nam je uspelo izgubljene podatke
povrniti. Kot smo omenili zgoraj, pa je približno 20% primerov reševanja neuspešnih.
Stroški lahko v takem primeru dosežejo vrtoglave vsote. Običajno v teh primerih posežejo
po edini preostali možnosti, to je ponovno ustvarjanje podatkov, kar zahteva več sto ur
Zoran Krebs - diplomsko delo 22
človeškega dela. Tega pa večkrat, posebej kadar gre za izgubo raziskovalnih ali
zgodovinsko pomembnih podatkov, sploh ni možno izvesti. Podobno velja tudi za podatke,
ki jim pravimo intelektualni kapital podjetja, kot so npr. podatkovne baze in baze znanja.
Nekateri viri navajajo, da lahko povprečna vrednost 1 MB poslovno pomembnih podatkov
presega 10.000 €.
Torej lahko ocenimo stroške, ki nastanejo pri takšnem incidentu, ki mu pravimo
reševanje izgubljenih podatkov. Znesek 500 € je povprečen strošek reševanja v primeru
uspešne povrnitve. Kot rečeno so stroški ob popolni izgubi nepredvidljivi, a vsekakor
izjemno visoki, zato lahko kakšno podjetje pripeljejo tudi na rob prepada.
Izguba podatkov evropska podjetja vsako leto stane 4 milijarde evrov, kar pa ne
vključuje stroškov izgube strank, izgube iz poslovanja, izgube tržnega deleža in stroškov
zaradi nenadne neusklajenosti z zakoni, do katere lahko pride ob izgubi določenih
elektronskih dokumentov ali obrazcev. Človeški dejavnik pri izgubi podatkov je zelo
pomemben. Nešteto primerov obstaja, ko so nezadovoljni, odpuščeni ali kako drugače
jezni sodelavci podjetju ali organizaciji povzročili ogromno škodo z namernim uničenjem
ali poškodovanjem podatkov.
2.1.4. Nekonsistentnost podatkov
Nekonsistentnost podatkov je stanje, ko podatkovna baza izgubi celovitost v smislu
enovitosti podatkov. Podatki se pri tem podvajajo, izgubljajo, lahko le povezave med njimi
- »padajo ključi«. V tem primeru govorimo tudi o podatkovni nesreči. Do tega lahko pride
zaradi:
• v primeru izpada komunikacijskih povezav med porazdeljenimi podatkovnimi
bazami (rešitev je ustrezno načrtovanje omrežja - vzpostavitev vzporednih poti)
• slabe dokumentiranosti podatkovne baze, posledično slabo načrtovanje aplikacij
• problem programske napake, napake v programski kodi,
• heterogeni sistemi uporabljajo podatke v različnih formatih, posledica je podvajanje
podatkov
• načrtovanja informacijskega sistema na »tradicionalen način« (razvoj se
osredotoča na posamezne aplikativne segmente, ne upošteva pa se problematika
Zoran Krebs - diplomsko delo 23
razvoja podjetja kot takega. Programske rešitve so ponavadi med sabo operativne
neodvisne )
V primeru, da pride do podatkovne nesreče, je potrebno PB obnoviti. Obnavljanje PB
je v domeni SUPB, ki poteka pod nadzorom upravitelja PB. V namen zagotavljanja
konsistentnosti podatkov se lahko uvede dvojna PB. V primeru, da pride do izpada ene PB,
se lahko ta nadomesti z drugo, kajti diskovna kontrolna enota izpisuje sočasno podatke na
dva fizično ločena diska (se izplača za zelo velike PB, saj olajša delo upravitelja SUPB).
Tovrstna zaščita je precej draga in zato mnogokrat uporabljajo metodo kopiranja.
2.1.5. Okrevalni načrt
Backup4 je dober le toliko, kolikor je dobro restavriranje podatkov. Le to dosežemo z
izdelavo okrevalnih načrtov. Okrevalni načrt ali DRP (angl. Disaster Recovery Plan) je del
procesa, ki omogoča hitro vzpostavitev prvotnega stanja IS. Okrevalni načrt opisuje
postopek, pri katerem element informacijskega sistema (operacijski sistem in druge
programske rešitve) restavriramo iz varnostne kopije, po možnosti na drugi lokaciji in na
drugi strojni opremi (sicer ista platforma, drugačno diskovje, drug model strežnika). Pri
tem se natančno dokumentirajo vsi koraki, potrebni za ponovno vzpostavitev sistema, iz
katerih nastane podrobna dokumentacija, ki opisuje vsa opozorila, ukaze in pasti na katera
lahko naletimo v primeru kritičnih napak in s tem restavriranje celotnega operacijskega
sistema in programskih produktov.
2.2. Zaščita podatkovne baze
Varnost podatkovne baze se odraža skozi zaščito pred grožnjami z uporabo tehničnega
in administrativnega nadzora. Grožnje zaščiti podatkovne baze prihajajo iz različnih virov:
• fizično okolje (varno okolje za datoteke, procese in opremo, varno pred sevanjem)
4 Backup je proces ki opravi hranjenje podatkov na druge medije
Zoran Krebs - diplomsko delo 24
• zunanje procedure (zaščita pri posamezniku, zaščita gesel, nadzor aplikacijskih
programov)
Varnost se odraža (povečuje/zmanjšuje=rezultira) skozi različne ukrepe, predvsem pa
se je potrebno posvetiti varnosti in zaščiti podatkovne baze v fazi načrtovanja podatkovne
baze (analiza tveganja, lastnosti okolja v katerem bodo umeščene podatkovne baze),
implementacije (nevidnost podatkov pred vsiljivci, preprečevanja izmikanja varnostnim
mehanizmom, varnostno testiranje) ter izdelavi različnih varnostnih zahtev in politik
varovanja s področja sistemskega varovanja, varovanja podatkov, zapisovanje dnevnikov
pristopa, transakcij, ipd.
Če želimo, da podatkovna baza zaživi v realnem življenju, mora imeti poleg
funkcionalnosti, kot so varnost, zanesljivost, visoko razpoložljivost, dostopnost,
učinkovitost, tudi ustrezen nadzor nad podatkovnimi bazami. To omogoča sistem za
upravljanje s podatkovnimi bazami (SUPB).
2.2.1. Nadzor dostopa
Varnost (angl. security) pomeni, da so podatki varni pred vsiljivci ter ostalimi
nepoklicanimi uporabniki. Tako je potrebno zagotoviti, da samo pooblaščeni (avtorizirani)
uporabniki podatkovne baze lahko počnejo v bazi to, kar je potrebno in nič več.
Začnimo kar z največjo grožnjo varnosti podatkovne baze, ki jo predstavljajo
uporabniška imena, ki so del standardne namestitve in imajo gesla enaka uporabniškim
imenom, oziroma so njihova gesla javno znana, kot je na primer uporabniško ime SYS,
SYSTEM, ROOT, POSTGRES (ime baze). Namestitvene procedure nekaterih
programskih produktov že zahtevajo od uporabnika svoje geslo, oziroma so ta uporabniška
imena in gesla onemogočena. Začne se torej že ob namestitvi, nadaljuje pa se ob odpiranju
novih uporabnikov, ki imajo geslo največkrat enako uporabniškemu imenu. Če nekomu
uspe dobiti seznam uporabnikov, kar hitro najde nekega uporabnika, ki ima dovolj pravic,
da lahko začne svoj uničevalni pohod po podatkovni bazi. Vidimo, da je politika gesel za
podatkovno bazo ravno tako pomembna kot kakšen drug del sistema [16].
Zoran Krebs - diplomsko delo 25
Na drugo mesto bi lahko postavili neustrezne, prevelike uporabniške pravice. Številni
programski paketi, ki niso dovolj premišljeno zasnovani, zahtevajo določene uporabniške
pravice, brez katerih bi lahko sicer ravno tako delovali, vendar bi bilo potrebno več
administracije in predvsem drugačen pristop od začetka razvoja aplikacije. Na tem mestu
se moramo zavedati, da je najprimernejša strategija dodeljevanja minimalnih pravic
oziroma zgolj tistih, ki jih uporabnik zares potrebuje za svoje redno delo.
Učinkovit nadzor dostopa do podatkovne baze lahko dosežemo skozi:
• ustrezno dodeljevanje uporabniških imen ter gesel uporabnikom (minimalne
pravice)
• ustreznega definiranje baz, shem ter dostopov do njih (pravilno načrtovanje
podatkovne baze)
• definiranje pravic dela nad podatkovnimi tabelami
• enkripcijo podatkov med odjemalcem in podatkovno bazo
• beleženjem dostopov do podatkov ter vrste transakcij (log file)
2.2.1.1. Avtentikacija
Avtentikacija je proces, v katerem se mora strežnik prepričati, da je uporabnik res tisto,
kar trdi, da je. Opravi se preko vnosa uporabniškega imena in gesla uporabnika, ali
uporabe digitalnih potrdil. Avtentikacija se opravlja na nivoju operacijskega sistema ali
podatkovne baze.
Običajna ranljivost statičnih gesel so dobre poznane, še več, gesla že od nekdaj veljajo
za neučinkovito metodo overjanja identitete. Vse več sistemov tako uporablja varnostni
sistem, ki generira enkratno kodo. Koda se generira v posebnem ključu in jo je mogoče
uporabiti le enkrat. Uporabnik tako vnese kodo skupaj s njegovo osebno PIN številko
(pozna jo le uporabnik), v prijavno okno, s čimer je postopek avtentikacije zaključen.
Na tržišču je kar nekaj takšnih rešitev (SafeWord, RSA SecurID,...), ki so vključene v
omrežne produkte kot so Citrix, Nortel Networks, ...
Zoran Krebs - diplomsko delo 26
2.2.1.2. Avtorizacija
Z avtorizacijo določimo do katerih delov aplikacij in do katerih programskih funkcij je
uporabniku odobren dostop in kakšen je nivo dostopa. Avtorizacija se vrši na dveh nivojih,
in sicer:
• na nivoju skupine uporabnikov ali
• na nivoju uporabnika.
V primeru spremembe pravic skupine, se pravice spremenijo tudi uporabniku v okviru
te skupine.
Avtorizacija v podatkovni bazi je postopek, ko strežnik ugotavlja do katerih
podatkovnih zbirk in objektov ima določen uporabnik dostop. Strežnik MS SQL podpira
dva načina verifikacije uporabnikov: avtentikacijo Windows in avtentikacijo SQL
(poseben način, pri katerem se geslo prek omrežja prenese v prikriti obliki). Tudi ostale
podatkovne baze izvajajo avtorizacijo na podoben način.
2.2.1.3. Enkripcija
Enkripcija ali šifriranje je proces v kriptografiji, pri katerem se izvede zamenjava
znakov v sporočilu, tako, da sporočilo, informacija postane nečitljiva za nepooblaščene
osebe oziroma osebe, ki nimajo ustreznega ključa za dešifriranje.
Enkripcija je torej prikrivanje, postopek pri katerem odprto sporočilo spremenimo v
prikrito. Z enkripcijo varujemo podatke pred nezaželenimi vpogledi. Največkrat se
uporablja enkripcija pri prenosu podatkov, sporočil, uporablja pa se tudi v druge namene
(na primer pri zavarovanju podatkov na medijih kot so diski, USB ključi, ipd; zavarovanju
podatkovnih baz, ipd.)
V primeru podatkovnih baz se uporabljajo različni mrežni protokoli za komunikacijo
med strežnikom in odjemalcem. Eden izmed mrežnih protokolov, ki uporablja enkripcijo,
je Kerberos. Kerberos je mrežni avtentikacijski protokol za zagotavljanje varne povezave
med odjemalcem in strežnikom. Kerberos nudi močno avtentikacijsko zaščito, ki temelji na
Zoran Krebs - diplomsko delo 27
kriptografiji z uporabo skritega ključa. Kerberos so razvili 1988 na Massachussets Institute
of Technology (MIT) v okviru projekta Athena. Poznane so še druge metode enkripcije kot
so SHA1, MD5, SSH,...
Ena izmed rešitev zaščite in varovanja podatkovnih baz je tudi enkripcija ali šifriranje
vseh občutljivih podatkov. Šifriranje podatkov je rešitev, seveda pa priporočamo uporabo
pripomočkov tretje osebe od prodajalcev kot na primer Protegity ali Ingrian Networks saj,
če šifriranje opravi podatkovni stroj, ima administrator dostop do ključa in če administrator
res krade podatke, ga šifriranje zagotovo ne bo ustavilo.
Po drugi strani pa, če bodo ključi shranjeni v podatkovni bazi in če postanejo
pokvarjeni, bo obnovitev podatkov izredno težka. »Šifriranje tretje osebe onemogoči
administratorju dostop do ključev, kar omogoči, da se odgovornost porazdeli med
upravljanje in varnost podatkovne baze. Rešitev vključevanja tretje osebe drži ključ stran
od podatkovne baze in vsebuje napredno upravljanje s ključem, kar omogoči lažjo obnovo
podatkov v primeru, da se ključi pokvarijo.«
2.2.1.4. Uporabniške skupine
Uporabniške skupine se definirajo z namenom ustvariti pravice dostopa do podatkov za
skupine uporabnikov. Uporabniki so vsi, ki kakorkoli uporabljajo podatkovno bazo (slika
4.). Delimo jih na neposredne in posredne uporabnike ter upravitelje podatkovne baze.
Neposredni uporabniki komunicirajo s podatkovno bazo preko terminalov ali delovnih
postaj, posredni pa le okvirno podajajo svoje podatkovne zahteve, njihovo izvedbo pa
prepuščajo neposrednim uporabnikom. Neposredni uporabniki so končni uporabniki ali
programerji. Končni uporabniki podatke v podatkovno bazo vnašajo s pomočjo vnaprej
pripravljenih vnosnih mask ter jih pregledujejo z vnaprej pripravljenimi poročili (reports)
oziroma s pomočjo povpraševalnega jezika (SQL). Programerji predstavljajo servis
končnim uporabnikom. Glede na dodeljene pravice spreminjajo strukturo podatkovne baze,
pripravljajo vnosne maske, poročila ter nasploh omogočajo uporabnikom čim lažjo ter
funkcionalno uporabo podatkov.
Zoran Krebs - diplomsko delo 28
Neposredni uporabniki
Upravitelj PB
Končni uporabniki
Programerji
Menijsko vodeni
uporabniki
Aplikacijski programerji
Sistemski programerji
Posredni uporabniki
Parametrični uporabniki
Uporabniki povpraševaln
ega jezika
uporabniki
slika 1: delitev uporabnikov, povzeto po [25]
Upravitelj podatkovne baze (lahko jih je več) ima množico zadolžitev, ki jih je potrebno
izvajati, da se zagotovi razpoložljivost, celovitost in uporabnost podatkov v podatkovni
bazi. Naloge upravitelja:
• definiranje ter ažuriranje notranje, konceptualne ter zunanjih shem;
• kreiranje in inicializacija fizične podatkovne baze;
• skrb za razvoj in vzdrževanje programskih orodij za podporo končnim
uporabnikom in uporabniškim programerjem;
• skrb za zaščito podatkovne baze pred nesrečami in njeno obnavljanje po nesrečah;
• definiranje postopkov za vzdrževanje kvalitete podatkovne baze;
• vzdrževanje sistema gesel in pristopnih dovoljenj za uporabnike;
• nadzorovanje zmogljivosti in uporabe podatkovne baze ter izvajanje ustreznih
reorganizacij in prilagoditev;
• pomoč uporabnikom pri planiranju in uporabi podatkov ter uporabi programskih
orodij, ki so na voljo v okviru SUPB;
Te naloge lahko opravlja ena ali več oseb ob podpori SUPB. Nekatere naloge (npr.
kreiranje shem) lahko v nekaterih okoljih opravljajo tudi končni uporabniki.
Zoran Krebs - diplomsko delo 29
2.2.2. Zaščita pred nekonsistentnostjo podatkov
Delo v podatkovni bazi mora biti pregledno, transparentno. Podatkovne baze ponujajo
v okviru produkta različne rutine, ki zagotavljajo transparentnost, zanesljivost ter seveda s
tem tudi konsistentnost podatkov. Podatkovna baza tako mora izpolnjevati / zagotavljati
lastnosti kot so: zanesljivost, razpoložljivost ter učinkovitost.
Zanesljivost (angl. reliable) pomeni, da je možnost vpogleda v podatke zanesljiva brez
morebitne izgube. Vsaka transformacija podatkovne baze mora biti pričakovana ne
naključna. Razpoložljivost, dostopnost (angl. availability) pomeni, da je podatkovna baza
na voljo, ko jo potrebujemo. S tem ko se uporabnik prijavi v podatkovno bazo pričakuje,
da so mu podatki na voljo v realnem času. Učinkovitost (angl. performance) pomeni, da
uporabnik učinkovito izvaja zahtevane operacije v sprejemljivem, to je v kratkem
odzivnem času.
2.2.2.1. Transakcije, ACID
Transakcija je definirana kot množica akcij, ki pripadajo enemu uporabniku ali
aplikaciji podatkovne baze, ter so nedeljiva celota. Transakcija ima štiri lastnosti in sicer
nedeljivost (angl. Atomicity), veljavnost (angl. Consistency), neodvisnost (angl. Isolation)
ter trajnost (angl. Durability). Funkcionalnost srečamo tudi pod okrajšavo ACID [17]. Je
lastnost podatkovne baze, ki omogoča, da se vsaka transakcija v podatkovni bazi izvede
zanesljivo. Atomicity oziroma nedeljivost označuje pojem, s katerim opišemo pravilo »vse
ali nič«. Vsaka transakcija v podatkovni bazi je nedeljiva in lahko samo popolnoma uspe,
ali pa ne uspe, kar pomeni, da bodo uspele vse spremembe hkrati ali pa nobena.
Consistency oziroma konsistentnost zagotavlja, da je stanje v podatkovni bazi pred in po
transakciji stabilno in da pravila niso porušena. Kadar poskusimo izvršiti transakcijo, s
katero porušimo pravila, ki veljajo v podatkovni bazi, transakcija ne sme uspeti, stanje pa
mora ostati enako, kot je bilo pred njo. V primeru, da transakcija uspe, morajo vse
spremembe postati vidne naenkrat in ne vsaka posebej. Govorimo, da je podatkovna baza
veljavna pred in po izvedeni transakciji. Isolation oziroma izolacija, neodvisnost, nam
zagotavlja, da si transakcije, ki tečejo paralelno in delujejo nad fizično istimi podatki, ena
drugi ne spreminjajo podatke. Durability oziroma trajnost nam zagotavlja da, ko dobi
Zoran Krebs - diplomsko delo 30
uporabnik potrditev uspešnosti transakcije nad podatki, bo transakcija izvršena in ni
mogoča njena zaustavitev. Ponavadi se transakcija zapiše v log file, ki omogoča, da se
transakcija izvede tudi ob nenadni prekinitvi delovanja (angl. system failure).
Transakcija označuje enoto za interakcijo s podatkovnim sistemom, v okviru katere se
zgodi ena ali več interakcij. Transakcija se drži ACID načel in na tak način omogoča
integriteto podatkovnega sistema. Transakcija se zaključi (angl. commit) ali ne
(angl.abort). Transakcije se izvajajo zaporedno ali sočasno.
Transakcije prav tako zagotavljajo, da se lahko posamezne operacije na podatkovni
bazi med sabo povežejo v neko celoto, ki uspe ali ne uspe v enem koraku in za sabo pušča
konsistentno stanje. Danes transakcija za delovanje tipično uporablja »two phase commit«
protokol. Ta protokol zagotavlja, da se vse strani, ki nastopajo v neki transakciji, najprej
dogovorijo, ali je transakcija uspela ali ne, šele nato se zgodi dejanski zapis. To pomeni, da
kadar ena izmed operacij ne uspe, vse ostale pa, se transakcija označi kot neuspela. Seveda
spremembe ne bodo potrjene in vidne v podatkovni bazi. To se bo zgodilo samo, kadar se
bodo vse strani strinjale, da je transakcija uspela.
Kadar govorimo o transakcijah, velikokrat naletimo na naslednje pojme:
• povrnitev v prvotno stanje (angl. Rollback) je proces, ki zagotavlja, da v primeru,
ko transakcija ni bila uspešno zaključena, povrnemo stanje podatkovne baze na
prejšnje stanje.
• povrnitev naprej (angl. Rollforward) je proces, ki zagotavlja, da lahko v primeru
okvare podatkovne baze, le-to restavriramo na točko pred okvaro tako, da ponovno
izvršimo transakcije, ki so že bile izvršene. V primeru okvare, podatkovno bazo
ponavadi obnovimo na neko prejšnjo točko (npr. na včerajšnje stanje). Nato s
pomočjo procesa povrnitve naprej ponovno izvršimo že izvršene transakcije in tako
pridemo na stanje, ki je bilo pred napako. Ponavadi se takšen proces ne izvaja
ročno, ampak s pomočjo orodij, ki jih ponuja podatkovna baza.
• smrtni primež-mrtva zanka (angl. Deadlock) je stanje, ki nastopi, kadar transakcije
čakajo ena drugo, da se dokončajo in sprostijo zapise v tabelah, nad katerimi
delujejo. Na primer, da imamo v sistemu dve transakciji T1 inT2. Prva transakcija
(T1) se bo izvedla na podatku A in nato na podatku B. Druga transakcija (T2) se bo
izvedla najprej na podatku B in nato na podatku A. Če se obe transakciji sprožita
hkrati, potem transakcija T1 zaseže podatek A in transakcija T2 zaseže podatek B.
Zoran Krebs - diplomsko delo 31
Sedaj poskuša transakcija T1 zaseči podatek B, vendar mora počakati, da ga
transakcija T2 sprosti. Hkrati pa poskuša transakcija T2 zaseči podatek A, ki ga je
že zasegla transakcija T1. Ta čaka, da transakcija T2 sprosti podatek, transakcija T2
pa čaka, da transakcija T1 sprosti podatek. Medsebojno čakanje transakcij, da
sprostijo podatke, je pogost problem, ki se pojavlja pri zaseganju podatkov. Sistem
za upravljanje s podatkovno bazo mora poskrbeti za ugotavljanje in reševanje
zaseganj, pri katerih lahko pride do mrtve zanke (slika 5.). Za ugotavljanje, ali je
prišlo do mrtve zanke, se najpogosteje uporabljajo grafi »čaka-na« (wait-for
graphs) ali Petrijeve mreže [12].
Podatek A
Podatek B
Transakcija T1 Transakcija T2
zasežen
zaseženČaka na
Čaka na
slika 2: primer enostavne mrtve zanke
Sistem za upravljanje s podatkovno bazo ugotovi, da je prišlo do mrtve zanke, ko najde
cikel v grafu »čaka-na«. Takrat lahko eno izmed transakcij prekine, razveljavi vse njene
akcije in jo izvede kasneje. S tem drugim transakcijam omogoči izvajanje brez nastopa
mrtve zanke.
Poznamo več tipov transakcij:
• distribuirane transakcije (angl. Distributed transactions) so transakcije, ki delujejo
nad več izvori podatkov (npr dveh podatkovnih bazah). Sistemi, ki podpirajo
distribuirane transakcije, so zelo kompleksni. Verjetno najbolj znani sistem za
podporo distribuiranim transakcijam je MS COM+.
Zoran Krebs - diplomsko delo 32
• vgnezdene transakcije (angl. Nested transactions) so transakcije, ki se zgodijo
znotraj že obstoječe transakcije. Najbolj pomembno je to, da spremembe v
vgnezdeni transakciji niso vidne, dokler ni potrjena glavna transakcija.
• dolgotrajne transakcije (angl. Longrun transactions) so transakcije, ki potrebujejo
dlje časa, da se zaključijo. Za razliko od navadnih transakcij ne vemo, kdaj točno se
bodo zaključile. Prav tako takšne transakcije komunicirajo z viri, nad katerimi
nimamo popolne kontrole (npr. z nekim tujim podjetjem, osebo, ...). V tem primeru
povrnitev v prvotno stanje zagotavljamo z kompenzacijskimi metodami.
Podatkovne baze, ki podpirajo transakcije, se imenujejo transakcijske podatkovne
baze. V to kategorijo spada večina modernih podatkovnih baz, vključno z PostgreSQL.
Transakcijske podatkovne baze zagotavljajo, da jo lahko vzdržujemo na enostaven in
konsistenten način tako, da so vse operacije na njej medsebojno odvisne, kar pomeni, da
se vse naenkrat uspešno zaključijo ali pa sploh ne.
2.2.2.2. Zaklepanje podatkov
Zaklepanje podatkov v primeru podatkovnih baz je postopek, ki ga uporabljamo za
nadzor sočasnega dostopa do podatkov. Ko ena transakcija dostopa do nekega podatka,
zaklepanje onemogoči, da bi ga istočasno uporabljale tudi druge, kar bi lahko pripeljalo do
napačnih rezultatov. Transakcija, ki izvaja ažuriranje (vnos, spremembo ali brisanje)
zapisa, mora biti transparentna. V primeru, da pride do napake med potrjevanjem
transakcije, bo stanje v podatkovni bazi enako, kot je bilo pred pričetkom transakcije.
Zaklepanje je nujno za zaščito integritete podatkov v podatkovni bazi. Sistemi za
upravljanje podatkovnih baz ponujajo mehanizme/metode zaklepanja podatkov. Obstaja
več načinov izvedbe, ki je lahko deljeno (angl. shared locking) ali ekskluzivno zaklepanje
(angl. exclusive lock). Pri tem gre lahko za zaklepanje na nivoju strani (angl. page level
locking) ali zapisov/polja (angl. row-level locking). Namen zaklepanja je zagotovitev
serializacije. Najbolj znan protokol je dvofazno zaklepanje (angl. 2PL-Two phase locking)
[17].
Serializacija je način, kako identificirati načine izvedbe transakcij, ki zagotovijo
ohranitev skladnosti in celovitosti podatkov. Pri tem se držimo urnika, to je zaporedja
Zoran Krebs - diplomsko delo 33
operacij iz množice sočasnih transakcij, ki ohranja vrstni red operacij posameznih
transakcij. Urniki so lahko zaporedni ali nezaporedni. Namen serializacije je poiskati
nezaporedne urnike, ki omogočajo vzporedno izvajanje transakcij brez konfliktov, pri tem
pa dosežemo rezultat, kot če bi se transakcije izvedle zaporedno. Serializacijo je mogoče
zagotoviti z različnimi metodami za nadzor sočasnosti. Metode za nadzor sočasnosti
delimo na:
• optimistične (angl. Optimistic locking): izhajamo iz predpostavke, da je konfliktov
malo, zato dovolimo vzporedno izvajanje, morebitne konflikte preverjamo na
koncu izvedbe transakcije.
• pesimistične (angl. Pesimistic locking): v primeru, da bi lahko prišlo do konfliktov,
se izvajanje ene ali več transakcij zadrži (zaklepanje, časovno označevanje)
2.2.3. Zaščita pred izgubo podatkov
Zanesljivost, varnost ter zaščita podatkov so med seboj povezani pojmi, ki so pogoj za
uspešno poslovanje podjetja. Kljub temu se v podjetjih posveča premalo pozornosti tej
temi, še več, o zaščiti pričnejo razmišljati takrat, ko pride do težav, do izgube podatkov.
Zaščita podatkovnih baz je različna. Lahko se uredi v okviru sistemskega varovanja
strežnika, na katerem je nameščena podatkovna baza, lahko se uredi parcialno (izvajamo
hranjenje le dela diskovja), določene vrste zaščit so urejene v okviru sistema za upravljanje
s podatkovnimi bazami oz. v okviru same podatkovne baze. Metode so odvisne od same
konfiguracije informacijskega sistema, v katerem je podatkovna baza umeščena ter od
potreb podjetja / organizacije.
Najpogostejše metode zaščite so naslednje:
• replikacija podatkovne baze
• sprotno arhiviranje
• dnevno arhiviranje
• zaščita pred veliko obremenitvijo
2.2.3.1. Replikacija podatkovne baze
Zoran Krebs - diplomsko delo 34
Replikacija je proces kopiranja in vzdrževanja podatkovnih objektov, kot so zapisi in
tabele, med podatkovnimi bazami, ki sestavljajo porazdeljen sistem. Razloga za uporabo
replikacije podatkov med strežniki sta večja dostopnost podatkovnih baz (če izpade en ali
več strežnikov) in hitrejši dostop do podatkov (več strežnikov lahko opravi več transakcij
na časovno enoto). Replicirane podatkovne baze so ponavadi razdeljene na lokacijsko
neodvisne računalniške sisteme.
Računalniški sistemi, ki uporabljajo replikacijo, se lahko nahajajo na istem ali ločenih
omrežnih segmentih. S tem, ko jih postavimo na isti omrežni segment, dosežemo predvsem
hitrejši dostop do podatkov. Tako ustvarjena množica sistemov omogoča izvajanje večjega
števila transakcij. Če so uporabniki podatkov locirani na več segmentih, je smiselno
postaviti podatke v njihovo neposredno bližino. Na omrežne segmente, kjer zaradi količine
uporabnikov pričakujemo pogoste dostope do podatkov, postavimo strežnik (ali več) in
podatke repliciramo med oddaljenimi segmenti. Tako dosežemo višjo hitrost dostopa do
podatkov in redundanco strežnikov na ravni omrežja. Vsaka replicirana baza dovoljuje
dostop do vseh podatkov. S pomočjo mehanizma replikacije pa si prizadevamo, da
vsebujejo vse porazdeljene podatkovne baze vedno enake podatke.
Največja prednost replikacije je dosegljivost podatkov v primeru izpada enega izmed
strežnikov. Uporabniki so v tem primeru enostavno in hitro preusmerjeni na enega
(ponavadi najbližjega) izmed drugih strežnikov in izpada ne opazijo. Edina občutna
sprememba zanje je lahko daljši dostopni čas. Druga velika prednost repliciranih
podatkovnih baz je lokalnost dostopov do podatkov. Če so podatki postavljeni na strežnike
na lokalnih omrežnih segmentih, je dostopni čas bistveno krajši v primerjavi s povprečnim
dostopnim časom od centralno lociranih podatkov. Ker uporabniki dostopajo do lokalno
postavljenih podatkov, se tudi omrežje razbremeni in omogoči boljše odzivne čase drugim
aplikacijam.
Pomanjkljivost replikacije je podvajanje podatkov. Vse replicirane podatkovne baze
morajo vsebovati določene ali celo vse podatke, ki se pojavljajo v kateri koli izmed njih.
Pomanjkljivosti replikacije je tudi kompleksnost upravljanja in medsebojne komunikacije
med repliciranimi podatkovnimi bazami. Delno replicirane podatkovne baze vsebujejo le
podmnožico vseh podatkov, ki jih porazdeljene baze hranijo. S tem se zmanjša količina
potrebnega pomnilniškega prostora. Rešitev je kompromis med ceno popolne replikacije
Zoran Krebs - diplomsko delo 35
(zasedanje pomnilniškega prostora) in dostopnostjo podatkov ob izpadu omrežja (določeni
podatki so nedosegljivi).
2.2.3.2. Sprotno arhiviranje
V principu gre za postopek, ki omogoča popolno povrnitev (angl. full recovery)
podatkov v primeru, da pride do izpada računalnika, na katerem je inštalirana podatkovna
baza (npr. okvara diska). Podatkovni strežnik v ta namen ponavadi tvori dnevnik vseh
transakcij, iz katerih potem z orodji naredimo povrnitev podatkov od trenutka, ko smo
pričeli voditi dnevnik. Tu ne gre za klasično hranjenje podatkov, temveč za poseg nad
določeno podatkovno bazo. Proizvajalci so ta način arhiviranja različno poimenovali on-
line backup, Hot backup, PITR-PostgreSQL, prav tako tudi povrnitev podatkov na osnovi
tega načina arhiviranja.
2.2.3.3. Dnevno arhiviranje
Odvisnost podjetij od delovanja informacijskih sistemov in varnosti njihovih podatkov
se hitro povečuje, še zlasti z rastjo obsega e-poslovanja, izmenjave e-pošte in
povečevanjem kompleksnosti spleta elektronskih oziroma digitalnih storitev. Večina
informatikov – pa tudi podjetnikov, menedžerjev in drugih uporabnikov – ve, da moramo
podatke varovati. Koliko pa jih sme verjeti, da so podatki res dovolj dobro varovani, da
bodo arhivski (angl. backup) sistemi delovali, ko jih bodo res potrebovali?
Za izdelovanje arhivskih kopij so na voljo namenske programske kot strojne rešitve
varovanja podatkov. Za potrebe vzdrževanja podatkovnih baz pa so na voljo tudi rešitve, ki
so razvite v okviru samega sistema za upravljanje s podatkovnimi bazami.
2.2.4. Zaščita pred preveliko obremenitvijo
Zoran Krebs - diplomsko delo 36
Podatkovna baza v nekem informacijskem sistemu ponavadi predstavlja eno izmed
ključih točk. Podatkovna baza na nekem manjšem informacijskem sistemu se ponavadi
nahaja na enem strežniku, kar je v primeru manjše obremenitve popolnoma ustrezna
rešitev. Ko naš informacijski sistem raste, se ustrezno povečuje tudi obremenitev
podatkovne baze. Kaj hitro se zato zgodi, da baza postane ozko grlo (angl. bottleneck)
sistema, saj ne more obdelati tako velikega števila zahtev.
Problem lahko rešimo tako, da nadgradimo strojno konfiguracijo našega podatkovnega
strežnika tako, da mu dodamo večje število procesorjev, dodamo pomnilnik ali povečamo
hitrost diskovnih pogonov. To je ponavadi le kratkotrajna rešitev, saj je ponavadi zelo
draga in ne zadostuje, kadar naš informacijski sistem in s tem obremenitev, še nadalje
rasteta.
Da se lahko takšnim situacijam uspešno izognemo, uporabljamo tehnike, s katerimi
porazdelimo obremenitev na nivoju podatkovne baze in s tem povečamo prepustnost
sistema.
2.2.4.1. Podatkovne gruče
Rešitev zgornjega problema predstavlja podatkovna gruča (cluster), ki je sestavljena iz
dveh ali več strežnikov, na katerih teče svoja instanca podatkovne baze, vse instance pa
delujejo nad fizično isto podatkovno bazo, torej nad istimi tabelami in podatki. V grobem
lahko podatkovno gručo opišemo kot:
• podatkovna gruča je sestavljena iz enega ali več strežnikov
• na vsakem strežniku teče svoja instanca podatkovne baze
• vse instance delajo nad enako fizično podatkovno bazo, torej nad istimi tabelami in
podatki
• vse instance uporabljajo skupno konfiguracijo
• vsaka instanca ima oziroma si vodi svoj arhiv in ima možnost povrnitve v primeru
napake
• vse instance paralelno izvajajo transakcije nad fizično enako podatkovno bazo
Takšna ureditev ima kar nekaj prednosti:
• obremenitev se porazdeli med fizično različnimi enotami
Zoran Krebs - diplomsko delo 37
• prepustnost se drastično poveča
• sistem je zelo skalabilen, kar pomeni, da lahko na enostaven način dodamo dodatni
strežnik in z njim še eno instanco podatkovne baze
• strežnik ima lahko relativno poceni strojno konfiguracijo, saj prepustnost
povečujemo tako, da dodajamo dodatne strežnike namesto da nadgrajujemo strojno
opremo
Seveda bore malo podatkovnih baz omogočajo podatkovne gruče. Med njimi so
predvsem komercialne podatkovne baze kot so Oracle, SQL Server, DB2 ter tudi nekaj
odprtokodnih. Po podatkih iz svetovnega spleta tudi MySQL (dopolnjena verzija 5) ter
seveda PostgreSQL. Tako v primeru velikega pomena dostopa do podatkov (24 ur / 7 dni v
tednu) izvedemo postavitve podatkovne gruče. V gručo vedno postavimo dva identična
strežnika s popolnoma enako konfiguracijo. Za postavitev enega vozlišča je dovolj
standarni SQL strežnik. Gručo povežemo z diskovnim poljem. Porazdeljena gruča je
skupina dveh strežnikov, fizično ločena. Ob napakah je mogoče delo brez preklopov in
prekinitev. Gruče ne zagotavljajo varovanja podatkov pred izgubami zaradi napak ali okvar
podatkovnih nosilcev. Tehnologija gruč je pri različnih proizvajlcih znana pod različnimi
imeni (na primer pri Oraclu: Oracle 10g ASM, Oracle 10g RAC)
2.2.4.2. Porazdelitev obremenitve
V informatiki si pod pojmom porazdelitev obremenitve predstavljamo tehniko, s katero
porazdelimo obremenitev med več fizično različnimi enotami, npr. računalniki, procesorji,
diskovnimi pogoni, procesi, podatkovnimi bazami.
Tu se pojavljata dva pojma oziroma dve zahtevi in sicer:
• visoka dostopnost (angl. high availability)
• porazdelitev obremenitve (angl. load balancing).
Kadar govorimo o visoki dostopnosti do podatkov, mislimo predvsem o tem, da v
primeru izpada glavnega strežnika, prevzame delo drugi podatkovni strežnik. Kadar pa
govorimo o porazdelitvi obremenitve, govorimo o tem, da je omogočeno, da različni
računalniki ponujajo iste podatke. V primeru spletnega strežnika lahko dokaj enostavno in
Zoran Krebs - diplomsko delo 38
hitro zagotovimo, da spletne strani ponuja več strežnikov hkrati, prav tako tudi v primeru
podatkovnega strežnika, kjer podatke le beremo. Na žalost pa je v primeru podatkovnega
strežnika potrebno podatke tudi zapisovati. Pri tem je potrebno vedeti, da podatke, ki jih
samo beremo, zapišemo na vse strežnike le enkrat, v primeru spremembe podatkov pa je
potrebno zahtevo zapisati na vse strežnike v istem trenutku. Samo to nam zagotavlja tudi
konsistenco podatkov. V osnovi je takšna sinhronizacija delovanja strežnikov zelo
zapletena. Pri tem na sinhronizacijo ne vpliva le posamezna rešitev za določen podatkovni
strežnik, temveč rešitve za vse strežnike. Enaka rešitev za različni strežnik lahko različno
vpliva Nekatere rešitve ponujajo sinhronizacijo strežnikov tako da dovoljujejo spremembo
podatkov le na enem strežniku, branje pa z vseh (»read/write master server metoda«). Pri
tem velja, da strežniki, s katerih podatke le beremo imenujemo pomožni strežniki »slave
servers«, strežnik na katerega podatke zapisujemo spremembe pa glavni strežnik »master
server«. Porazdelitve obremenitve so lahko sinhrone ali asinhrone. Pri sinhroni porazdelitvi
govorimo v primeru, ko se transakcija, kjer pride do spremembe podatkov ne upošteva,
dokler se ne zaključi na vseh strežnikih. To zagotavlja konsistenco podatkov na vseh
strežnikih hkrati. Asihrona porazdelitev pa dopušča, da pride do zakasnitve med časom
zaključka transakcije in njenim razširjanjem na ostale strežnike. Pri tem obstaja možnost,
da se posamezne transakcije izgubijo, stanje podatkov se izenači šele ob kopiranju z
arhivskega strežnika. Za asinhrono rešitev se odločimo takrat, ko je sinhrona porazdelitev
prepočasna. Moramo namreč vedeti, da je v primeru počasnejšega omrežja sinhrona rešitev
dvakrat ali več počasnejša od asinhrone.
V kontekstu podatkovne baze pojem porazdelitve obremenitve povezujemo z
podatkovnimi gručami. Kadar imamo podatkovno bazo urejeno kot podatkovno gručo,
potrebujemo tudi način, da z njo komuniciramo. V ta namen ponavadi definiramo vstopno
točko-vozlišče, preko katere naš informacijski sistem uporablja podatkovno gručo.
Vstopna točka ponavadi predstavlja enega izmed strežnikov v podatkovni gruči, ki mu naš
informacijski sistem pošilja vse zahteve. Vstopno točko imenujemo tudi gospodar (load
balancer). Njegova naloga je preverjati obremenitev posameznih strežnikov v podatkovni
bazi in glede na to usmerjati zahteve na enega izmed njih. Na takšen način dosežemo
optimalno prepustnost.
Zoran Krebs - diplomsko delo 39
3. VARNOST PODATKOV V PostgreSQL
Kot administrator podatkovne baze smo odgovorni, da uporabniki baze lahko dostopajo
do podatkov, ko jih potrebujejo. Prav tako smo odgovorni, da dodelimo uporabnikom
pravice, ki jih potrebujejo za svoje delo. Tako, glede na varnost in dostop do podatkovne
baze, lahko ločimo dva aspekta. Prvi je, kako dodeliti uporabniško ime in geslo
posameznemu uporabniku, ki se z svojo identifikacijo – prijavo v sistem tudi identificira,
drugi pa je, katere pravice dobi posamezen uporabnik za delo v podatkovni bazi. Tu velja
vse bolj načelo, da dobi pravice, ki jih zares potrebuje za delo in nič več. Tako je naloga
administratorja , da vsakemu uporabniku ali skupini uporabnikov dodeli uporabniška
imena in gesla, ki niso predvidljiva, vodi politiko gesel skozi celotno življenjsko dobo
podatkovne baze ter dodeljuje ravno pravšnje pravice, ki zaživijo ob prijavi uporabnika v
podatkovno bazo.
Kot administrator podatkovne baze smo tako odgovorni za dodeljevanje uporabniških
imen, gesel in uporabniških skupin. Prva izmed nalog pri administraciji podatkovne baze
je, kako dodeliti uporabniška imena. Ena možnost je, da vsakemu uporabniku dodelimo
enolično uporabniško ime in geslo. To je sicer dober način, ni pa vedno praktično. V
primeru dostopa do podatkovne baze preko spleta si verjetno ne želimo, da vsakemu
obiskovalcu spletne strani, dodelimo svoje uporabniško ime in geslo. Dobra rešitev v
takšnih primerih je, da znanemu uporabniku dodelimo enolično uporabniško ime,
nepoznanim gostom pa generično uporabniško ime. Administrator mora prav tako poznati,
kakšno avtentikacijsko metodo izbrati. PostgreSQL ima na voljo več metod avtentikacije,
razvrščene glede na stopnjo varnosti od metode »TRust« do metode »Kerberos«. Katero
metodo bomo uporabili je odvisno, kakšna je občutljivost podatkov, ki jih hranimo[7].
Za administratorja je prav tako pomembno, da pozna, kako je baza zgrajena ter kje se
fizično nahaja, ter kako je PostgreSQL organiziran na logičnem nivoju.
3.1. Logična in fizična urejenost datotek
Gruča (angl. cluster) vsebuje eno ali več podatkovnih baz. Je najvišji člen hierarhije
PostgreSQL sistema hrambe podatkov. Gruča nima imena, dostop do njega pa je mogoč
izključno preko podatkovnega strežnika (postmasterja). Vsaka gruča obstaja le na enem
Zoran Krebs - diplomsko delo 40
imeniku (privzeto je to na mestu inštalacije PostgreSQL-a, to je v delovni mapi C:\Program
Files\PostgreSQL\8.2\data). Podatke lahko zapišemo tudi na drugi delovni imenik, tako da
najprej določimo podatkovni prostor (angl. tablespace), nato pa kreiramo podatkovno bazo
v okviru tega prostora. Podatkovna baza (angl. database) je skupek shem. Ime podatkovne
baze mora biti unikatno za vsako gručo posebej. Shema je zbirka – imenski prostor
posameznih tabel. Imeti mora unikatno ime v vsaki podatkovni bazi. Tabela (angl. table) je
sestavljena iz stolpcev ter vrstic. Vsaka vrstica pomeni en zapis v tabeli. Omogoča
shranjevanje podatkov različnih tipov (slika 6.).
Gruča
Podatkovna zbirka Podatkovna zbirka
Shema Shema Shema Shema
Tabela Tabela Tabela Tabela Tabela Tabela
slika 3: gradniki podatkovne baze PostgreSQL, povzeto po [7]
Glede na organizacijo lahko uporabnik dostopa do podatkovne baze na različnih
nivojih, odvisno od uporabniških pravic, ki mu jih dodelimo. V primeru, ko za določen
objekt ni točno določeno, kam spada, se smatra, da ga lahko vsi vidijo (public).
Po inštalaciji se PostgreSQL nahaja na delovnem imeniku
C:\ProgramFiles\PostgreSQL\8.2. (v nadaljevanju /usr/local/psql) in
vsebuje več podimenikov (bin, data, doc, include, jdbc, lib, npgsql, pgAdminIII,share). Za
nas sta zanimiva predvsem prva dva, to je bin in data. Izvršne datoteke, kot so psql, initdb,
postmaster ter razne »shell procedure«, so shranjene v imeniku »bin« (/usr/local/psql/bin).
V podimenik »data« se hranijo vse informacije o podatkovnih bazah, njihovi strukturi,
uporabnikih, pravicah, ipd. v okviru sistemskih datotek. To so datoteke pg_hba.conf,
pg_ident.conf, pg_VERSION, postgresql.conf, postmaster.opts in postmaster.pid. Pomen
posameznih datotek lahko vidimo v tabeli 2.
Zoran Krebs - diplomsko delo 41
tabela 2: opis pomena datotek
Datoteka Opis pg_hba.conf Podatki o uporabniških računih (vsebuje vrsto povezave, ime podatkovne
baze, uporabniško ime, naslov odjemalca ter avtentikacijsko metodo) za vsak uporabniški račun posebej
pg_ident.conf Podatki o uporabnikih Pg_VERSION Podatki o verziji programskega produkta PostgreSQL postgresql.conf Podatki o nastavitvah PostgreSQL Postmaster.opts Podatki za zagon upravljalca strežnika PostgreSQL, to je postmasterja Postmaster.pid Bližnjica s podatki, kje se upravljalec nahaja
Podimenik »data« prav tako vsebuje 8 podimenikov, in sicer: global, base, pg_log,
pg_xlog, pg_clog, pg_subtrans in pg_tblspc, pg_twophase ter pg_multixact (velja za
verzijo 8.2). Podimenik global povezuje gruče, sheme, podatkovne baze med seboj; imenik
base vsebuje podatke vseh podatkovnih baz, ki pa so razvrščeni zopet v podimenike
/usr/local/psql/data/base/1, 10290. Podrobnejši pregled se nahaja v tabeli 3.
tabela 3: opis pomembnejših podimenikov imenika data (/usr/local/data)
Imenik Opis /global imenik vsebuje informacije o uporabniških računih (pg_shadow),
skupinah uporabnikov (pg_group) ter podatkovnih bazah (pg_database). /base imenik vsebuje podatke vseh podatkovnih baz urejeno po podimenikih /pg_clog imenik vsebuje podatke o vseh uspešnih zapisih v podatkovne baze /pg_xlog imenik vsebuje podatke o neizvedenih transakcijah. V primeru
nenadnega izpada strežnika, se transakcije izvedejo po ponovnem zagonu
/pg_subtrans imenik vsebuje podatke o vgnezdenih transakcijah (nested transactions) /pg_tblspc imenik vsebuje podatke o linkih o navideznih lokacijah podatkov /pg_log imenik vsebuje podatke o dostopu do podatkovne baze, čas dostopa,
kateri uporabnik je dostopal, transakcije katere je izvedel
3.2. Nadzor dostopa 3.2.1. Avtentikacija
Avtentikacija odjemalca se določi s pomočjo konfiguracijske datoteke, ki se tradicionalno
imenuje pg_hba.conf (HBA pomeni host-based authentication). V datoteki je vrsta zapisov,
ki vsebujejo vrsto povezave (local,host,hostssl,hostnossl), ime podatkovne baze,
uporabniško ime, naslov odjemalca ter avtentikacijsko metodo (trust, md5, crypt,
Zoran Krebs - diplomsko delo 42
password, kerberos, ident, pam), po kateri se opravi avtentikacija (tabela 4.). Metode
avtentikacije so bolj podrobno opisane v nadaljevanju, glej poglavje 3.2.3. Ko se aplikacija
na odjemalcu skuša povezati z bazo (npr. psql), pošlje postmasterju uporabniško ime in
ime podatkovne baze. Po sprejemu zahteve postmaster poišče v sistemski datoteki
pg_hba.conf podatke o uporabniku, podatkovni bazi, naslov odjemalca in tip povezave.
Vsakokrat išče od začetka datoteke do trenutka, ko najde ustrezen zapis (vsi podatki se
ujemajo z dobljeno zahtevo s strani odjemalca). V primeru, da pride do konca datoteke, pri
tem pa ustreznega zapisa ni našel, postmaster zavrne dostop do podatkovne baze. Zatem,
ko postmaster pridobi potrjene podatke o ustrezni prijavi, iz zapisa uporabi še dodatne
podatke , kakšno avtentikacijsko metodo uporablja (npr., če je iz zapisa razvidno, da je
avtentikacijska metoda tipa password, zahteva od odjemalca ustrezno geslo). V splošnem
velja, da močnejša kot je avtentikacijska metoda, bolj nadležna je, vendar pa ne smemo
pozabiti, da so ob tem tudi podatki bolj varni [7].
tabela 4: shema konfiguracijske datoteke PG_HBA.CONF Tip povezave Ime podatkovne
baze Uporabnik Naslov odjemalca Avtentikacijska metoda
Local host hostssl hostnossl
IP-address, IP-mask CIDR-adress
Trust, md5, ident, crypt, password, kerberos, pam
Host Test Zoran 127.0.0.1 255.555.555.0
Password
Local Postgres All 127.0.0.1 /32 Ident sameuser
3.2.2. Avtorizacija
Uporabniške pravice so shranjene v datoteki pg_shadow. Do nje dostopamo preko meta
ukaza psql \d pg_shadow, do podatkov v tabeli pg_shadow pa s pomočjo ukaza SELECT.
Pravice, ki jih lahko dodeljujemo posameznemu uporabniku oziroma skupini, so prikazane
v tabeli 5.
tabela 5: pregled pravic Stavek / ukaz Lokacija, kjer je pravica
na voljo Kratek opis
SELECT Tabele, Pogledi, Sekvence
Kontrola pravic pri dostopu do vrstice v tabeli oz. pogledu. Prav tako kontrolira pravice povpraševanja nad sekvencami.
INSERT Tabele, Pogledi, Sekvence
Kontrola pravic pri vnosu novih zapisov v tabelo, pogledi ali sekvenco.
UPDATE Tabele, Pogledi, Kontrola pravic pri spremembi podatkov v tabeli, pogledu
Zoran Krebs - diplomsko delo 43
Sekvence ali sekvenci DELETE Tabele, Pogledi,
Sekvence Kontrola pravic pri brisanju podatkov v tabeli, pogledu ali sekvenci
RULE Tabele, Pogledi, Sekvence
Kontrola pravic pri kreiranjem novih pravil na tabeli ali pogledu.
REFERENCES Tabele Kontrola pravice nad povezavo dveh tabel s pomočjo zunanjega ključa.
TRIGGER Tabele Kontrola pravic pri kreiranju sprožilcev na tabeli. CREATE Podatkovne baze,
Podatkovni prostori, Sheme
Kontrola pravic pri kreiranju new schemas within a database, new objects within a schema, or new indexes (or tables) within a tablespace.
TEMPORARY Podatkovne baze Kontrola pravic pri kreiranju začasnih tabel v okviru podatkovne baze.
EXECUTE Funkcije Kontrola pravic pri izvajanju funkcij. USAGE Sheme,Jeziki Kontrola številčenja objektov znotraj sheme, kontrola
pravic pri kreiranju novih funkcij.
3.2.3. Enkripcija
PostgreSQL ponuja šifriranje podatkov na različnih stopnjah in zagotavlja fleksibilnost
v zaščiti podatkov pred razkritjem, katerih povzročitelji so lahko podatkovne kraje,
brezvestni administratorji ali nezanesljiva/nezaščitena omrežja.
Uporabniška gesla so shranjena s pomočjo šifriranja tipa MD5, tako administrator ne
ve, katero geslo ima uporabnik, ter ga ne more uporabiti. Šifriranje je zagotovljeno v
vsakem primeru, tudi če je uporabnik začasno prijavljen na strežnik, ker šifriranje MD5
zagotavlja, da se podatki šifrirajo, preden se pošljejo preko mreže.
Šifriranje določenih stolpcev v tabeli omogoča, da se prikrijejo podatki, ki so vsebinsko
občutljivi (npr, deli zdravniških kartotek, finančne transakcije, ipd). V tem primeru
odjemalec zagotovi/priskrbi od strežnika ključ za dešifriranje, podatke dešifrira in jih
pošlje uporabniku.
Zaščita sistemske particije diska preprečuje vpogled v podatke, ki se nahajajo na disku.
Šifriranje je odvisno od vsakega operacijskega sistema posebej (Linux – loopback device,
FreeBSD – GBDE). Mehanizem preprečuje vpogled v podatke v primeru kraje diska ali
medija, na katerem so podatki shranjeni, ne preprečuje pa vpogleda v podatke v primeru
napada na računalnik. Namreč v času, ko računalnik oziroma disk deluje (disk mounted),
so podatki nezaščiteni / odprti.
Šifriranje gesel skozi omrežje (MD5) je dvostopenjsko šifriranje gesla odjemalca,
preden se zahteva pošlje strežniku. Izvede se na osnovi uporabniškega imena ter
Zoran Krebs - diplomsko delo 44
naključnega števila, ki je poslan od strežnika, ko je povezava vzpostavljena.
Dvostopenjsko šifriranje preprečuje ne le razkritja uporabniškega gesla, temveč tudi še eno
povezavo z enakim ključem.
Šifriranje podatkov skozi omrežje (SSL) poteka s pomočjo povezav tipa SSL. Pri tem
se šifrirajo gesla, povpraševanja ter vrnjeni podatki. V datoteki pg_hba.conf administrator
nastavi, kdo lahko uporablja odprte in kdo zaprte povezave.
Tu so še možnosti zaščite s strani odjemalca (SSL Host , Client-Side Encryption), prav
tako podpira varne povezave odjemalca do strežnika (SSL, SSH Tunnels)
3.2.4. Uporabniške skupine
Kot administrator podatkovne baze smo dolžni skrbeti za uporabnike, uporabniške
skupine ter pravice, ki jim omogočajo delo s podatki. Odgovorni smo za dodelitev (angl.
grant) ter odvzem (angl. revoke) pravic uporabnikom. V večini primerih se računalniško
okolje nastavi tako, da so uporabniška imena in gesla enaka za dostop do sistemskega
okolja ter podatkovne baze.
Definiranje uporabnika
Novega uporabnika lahko kreiraš s tem, da poženeš ukaz CREATE USER iz odjemalca
(konzola psql), ali pa uporabiš skripto createuser shell.
sintaksa ukaza:
CREATE USER user-name
[[WITH] option ]...
option := SYSID user-id-number
| [NO]CREATEDB
| [NO]CREATEUSER
| IN GROUP groupname [, ...]
| [[UN]ENCRYPTED ] PASSWORD 'password'
| VALID UNTIL 'expiration'
Zoran Krebs - diplomsko delo 45
primer uporabe:
CREATE GROUP uporabniki;
CREATE USER zoran IN GROUP uporabniki;
Uporabniško ime user-name je lahko dolžine največ 31 znakov, prvi znak mora biti črka ali
podčrtaj. Vsa uporabniška imena, gesla in pravice so zapisana v sistemski datoteki
pg_shadow.
Uporabna je opcija SYSID, ki vsakemu uporabniku dodeli tudi identifikacijsko številko
(od 100 dalje). V primeru kreiranja tabele, ki ji določimo lastnika, se tabeli zabeleži tudi
identifikacijska številka uporabnika.
Priprava skupine
Kot administrator podatkovne zbirke lahko definiramo skupine uporabnikov s uporabo
ukaza CREATE GROUP. Skupini uporabnikov kasneje lahko dodeljujemo ali odvzemamo
pravice na enak način kot posameznemu uporabniku. To pride zelo prav, v primeru, ko
odpiraš ali zaključuješ kakšen projekt. Uporabnik lahko pripada več skupinam.
Sintaksa ukaza:
CREATE GROUP group-name [[WITH] option [...]]
option := SYSID group-id-number
| USER username, ...
primer uporabe:
CREATE GROUP uporabniki;
Zoran Krebs - diplomsko delo 46
3.3. Zaščita pred nekonsistentnostjo podatkov
3.3.1. Transakcije, ACID in PostgreSQL
Transakcija je skupina SQL ukazov, ki se smatrajo kot celota. PostgreSQL obljublja,
da se vsi ukazi v okviru ene transakcije zaključijo oziroma nobeden izmed njih. V primeru,
ko se transakcija izvede v celoti, govorimo, da se zaključi (angl. committed). Če se
transakcija ne zaključi, PostgreSQL poskrbi, da se stanje podatkovne baze povrne pred
začetkom izvajanja transakcije. PostgreSQL tako uporablja »Rollback« način zagotavljanja
celovitosti podatkov.
Začetek transakcije zapišemo z ukazom BEGIN, zaključimo pa z ukazom COMMIT.
Vsi ukazi med ukazoma BEGIN in COMMIT so tako ena transakcija, v nasprotnem
primeru je vsak ukaz samostojna transakcija. V času trajanja transakcije so podatki, ki so
predmet transakcije, zaklenjeni pred ostalimi uporabniki, na voljo so le lastniku
transakcije, po zaključku transakcije pa so spremembe v podatkovni bazi logično
zaključene, trajne. Podatki so ponovno na voljo ostalim uporabnikom. Stanje pred
transakcijo dosežemo z ukazom ROLLBACK5.
Izolacija
Pri izolaciji podatkov dostikrat govorimo o problemu zapisovanja »Dirty read«.
Rešitev tega problema v PostgreSQL je mogoča z enim izmed dveh načinov izolacije, to je
z izvedbo ukaza READ COMMITTED. Drugi način izolacije je serializacija
(SERIALIZABLE), ki odpravlja tudi t.i. problem »phantom read«. Ta poleg tega
odpravlja tudi problem »nonrepeatable read«. Pri tem je potrebno povedati, da v splošnem
poznamo štiri stopnje izolacije, PostgreSQL pa ima na voljo le prej omenjena načina, ki pa
po standardih SQL 92 zadostujeta – po principu bolje je več, kot manj [21]. Na tabeli 6. so
prikazane posamezne stopnje izolacije ter problemi, ki jih posamezna stopnja odpravlja.
Izolacije, ki jih PostgreSQL podpira, so obarvane v sivi barvi.
5 Ukaz BEGIN lahko zapišemo tudi kot BEGIN WORK ali BEGIN TRANSACTION, prav tako tudi ukaza COMMIT ter ROLLBACK (COMMIT WORK, COMMIT TRANSACTION, ROLLBACK WORK, ROLLBACK TRANSACTION)
Zoran Krebs - diplomsko delo 47
tabela 6: pregled stopenj izolacije, povzeto po [21] Vrsta problema
Stopnja izolacije
Dirty Read Nonrepeatable Read Phantom Read
Read uncommitted � � �
Read commited - � �
Repeatable read - - �
Serializacija - - -
Legenda: � problem je še zmerom prisoten, mogoč,
- odpravljen
Primer uporabe –sintaksa ukaza:
SET TRANSACTION ISOLATION LEVEL { READ COMMITTED │ SERIALIZABLE}
PostgreSQL ima na voljo pri izvedbi transakcije še eno posebnost. Podatkovna baza ima
možnost, da si zapomni stanje na določenem mestu izvedbe transakcije. To dosežemo tako,
da označimo mesto transakcije, do katere se je transakcija še uspešno izvedla. Označitev
opravimo z zagonom ukaza SAVEPOINT. V primeru preklica transakcije lahko prekličemo
spremembe vse do označene točke.
sintaksa ukaza:
SAVE POINT savepoint-name
ROLLBACK TO SAVEPOINT savepoint-name
primer:
START TRANSACTION;
INSERT INTO artikel VALUES (5,....);
SAVE POINT p1;
INSERT INTO artikel VALUES (6,....);
ROLLBACK TO SAVEPOINT p1;
Zoran Krebs - diplomsko delo 48
Vidimo, da se v primeru preklica transakcije (ROLLBACK) zbrišejo vse spremembe (oba
vnosa v tabelo artikel), če pa izvedemo preklic spremembe do točke p1 (ROLLBACK TO
SAVEPOINT p1), potem se ne vpiše le zadnji vnos v tabelo artikel.
3.3.2. Zaklepanje podatkov
Večina komercialnih, kot tudi odprtokodnih baz, uporablja metodo zaklepanja
podatkov, da lahko koordinira delo med uporabniki. V kolikor posodabljamo tabelo, je
tabela zaklenjena pred spremembami in poizvedbami drugih uporabnikov. Nekatere baze
uporabljajo zaklepanje na nivoju strani (angl. page-level locking) ali zaklepanje na nivoju
vrstice (angl. row-level locking), toda princip zaklepanja je vselej enak, to je, da drugi
uporabniki čakajo, da izvedejo spremembo nad podatki tako dolgo, dokler prejšnji
uporabnik ne zaključi z delom in sprosti zaklenjenih vrstic.
PostgreSQL uporablja drugačen model zaklepanja od ostalih podatkovnih baz. Model
se imenuje večkratno verzioniranje (angl. multi-versioning), skrajšano MVCC način
zaklepanja [15]. Pri tem načinu se princip zaklepanje še zmerom uporablja, vendar dosti
manj pogosto, kot bi pričakovali. Podatkovna baza izdela kopijo vrstic v tabeli, ki jo
nameravamo uporabljati. Drugi uporabnik v primeru dostopa do iste tabele sicer vidi
originalno vsebino le-te, nima pa je možnosti spreminjati ali delati poizvedb - njegova
transakcija čaka na izvedbo naše transakcije, dokler mi ne zaključimo z delom. V primeru,
ko transakcija ne uspe, ne pride do zaključka transakcije (angl. rollback), to ne vpliva na
delo drugega uporabnika. V primeru, ko se transakcija zaključi (angl. commit), originalni
zapis označimo kot zastarel (angl. obsolete). Vse transakcije, ki so tipa READ COMMITTED
takoj vidijo spremembe, transakcije tipa SERIALIZABLE pa še naprej uporabljajo kopijo,
na njej ni dovoljena sprememba ali poizvedba podatkov. Kopija podatkov, ki smo jo
prvotno kreirali, torej zastareli zapisi, se žal ne izbrišejo sami, potrebno jih je ročno
izbrisati iz podatkovne baze. To stori administrator podatkovne baze s pomočjo ukaza
VACUUM. Od verzije 8.2 PostgreSQL že izvaja avtomatično brisanje nepotrebnih zapisov iz
baze.
Transakcijski model MVCC zagotavlja višjo zmogljivost kot ostali modeli, saj
omogoča hkratni dostop do podatkov. Čeprav PostgreSQL uporablja MVCC model, v
določenih primerih še vedno zaklene podatke[21].
Zoran Krebs - diplomsko delo 49
3.4. Zaščita pred izgubo podatkov
3.4.1. Replikacija podatkovne baze
Replikacija je proces pošiljanja ter pomnjenja podatkov v več podatkovnih bazah.
Ponavadi se izvaja na fizično ločenih računalnikih, po možnosti tudi prostorsko ločenih.
PostgreSQL podpira različne replikacijske mehanizme, skozi leta se je prijel predvsem
Slony (tabela 7.). Potrebno je vedeti, da PostgreSQL replikacije nima direktno vgrajene, je
pa mogoča preko prej omenjenih dodatkov. Prejšnje rešitve so bile tehnično zastarele.
tabela 7: Pregled načinov replikacije skozi zgodovino PostgreSQL
Opis Način
replikacije
v uporabi okolje
Windows XP
Slony (trenutno delujoča verzija je Slony-a je
Slony-I ver.1.2.11, v pripravi Slony-II)
Master/Slave 8.x DA
Statement-Based replikacija, Pgpool,Sequoia Master/Slave 7.0.- 7.4 NE
Pgpool-II (Paralelno večstrežniško procesiranje oz.
»Multi-server parallel Query Execution«)
Multi server Višje od
7.4
NE
s pomočjo eRServer rešitve-addOn (Enterprise
Replication Server project)
Master/Slave ver 7.x NE
Slony-I
Slony-I je proces, ki ponuja asinhrono enosmerno replikacijo podatkov v Master/Slave
načinu dela tako, da iz originalne podatkovne baze prenese podatke v poljubno število
kopiranih podatkovnih baz. Asinhronost pomeni, da je stanje podatkov v posamezni
podatkovni bazi v določenem trenutku različno, podatki se ne sinhronizirajo v trenutku,
enosmernost pa, da je spreminjanje podatkov mogoče le v originalni/osnovni podatkovni
bazi. Master/Slave način zapisa pomeni, da se spremembe zapisujejo v glavni strežnik
(master), branje je mogoče z ostalih pomožnih strežnikov (slave). Pri tem Slony-I skrbi, da
Zoran Krebs - diplomsko delo 50
na tabeli, ki jo ažurira, doda kazalec, ki onemogoča njeno spremembo s strani uporabnika.
Slony je kaskadno zasnovan in omogoča, da se spremembe v repliciranih tabelah izvajajo
postopno po posameznih segmentih, glede na original. Sporočilo o spremembi potuje od
osnovne podatkovne baze preko vozlišč do kopiranih podatkovnih baz. Tako se zmanjša
zasedenost mreže med osnovno bazo in ostalimi, ker komunikacija o spremembi poteka
tudi med kopiranimi bazami. Replikacija je zelo uporabna za podatkovna skladišča, za
zahtevnejše poizvedbe, ki lahko poberejo precej sistemskih sredstev. Trenutna verzija
Slony-a je verzija 1.2.11, v načrtovanju je že Slony-II, ki bo podpiral istočasni zapis na
več glavnih strežnikov ter več pomožnih strežnikov (sinhroni multi Master / multi Slave
način replikacije). Slony-I ne omogoča kontrole posameznih vozlišč, ker tudi zato ni
namenjen. Tako ne more ugotoviti, ali je posamezno vozlišče odprto ali ne. V primeru
nestabilnosti vozlišč je potrebno uporabljati še kakšno dodatno orodje, ki podpira to
funkcionalnost. Za uspešno izvajanje replikacije je nujna časovna sinhronizacija vozlišč v
realnem času (Real Time Clocks). Prav tako je potrebna dvosmerna komunikacija med
vsemi vozlišči v okviru posamezne gruče (clustra). Za pravilno nastavitev poteka
replikacije med vozlišči, moramo imeti pravilne, enolično določene poti do le-teh.
Preden se lotimo same replikacije, je pomembno, da se seznanimo z osnovnimi pojmi
replikacije:
• gruča (angl. cluster) je zbirka več podatkovnih baz med katerimi poteka replikacija.
Gručo definiramo iz imena gruče ter imena vozlišč, ki sodelujejo v replikaciji.
• vozlišče (angl. node) je podatkovna baza, ki sodeluje v replikaciji.
• replikacijski set (angl. replication set) je definiran kot zbirka podatkovnih tabel ter
sekvenc, ki so replicirane znotraj gruče. Lahko imamo več takšnih setov, potek
replikacije posameznih setov ni nujno,da je enak.
• izvorno-glavno mesto ter naslovnik
• vsak replikacijski set ima svoj izvor, ki je prostor, kjer je dovoljeno spreminjati
podatke. Je glavno mesto, od koder se ostala vozlišča, ki sodelujejo v replikaciji,
oskrbujejo. Ostala vozlišča imenujemo naslovniki, to so vozlišča, ki sodelujejo v
replikaciji, vendar podatke le prejemajo.
• slon daemons je program - servis, ki omogoča delovanje same replikacije. Pri tem
kontrolira dogodke, ki jih določa replikacijski set. Dogodke delimo na
Zoran Krebs - diplomsko delo 51
konfiguracijske ter sinhronizacijske dogodke. Konfiguracijski dogodki so dogodki,
ki so potrebni za delovanje samega servisa, sinhronizacijski dogodki pa opisujejo
vsebino, potek replikacije. Aktivira se za vsako vozlišče posebej.
• slonik je ukazni – konzolni urejevalnik, v katerem urejujemo konfiguracijo servisa
(odvzem, dodajanje vozlišč, spreminjanje poti do vozlišč, urejanje replikacijskih
setov).
3.4.2. Arhiviranje podatkov v PostgreSQL
V podatkovni bazi PostgreSQL so na voljo trije načini hranjenja-arhiviranja podatkov:
• preko sistemskega/ file system level backupa
• arhiviranje s pomočjo SQL skripte
• sprotno arhiviranje (angl. on-line backup)
System level backup
Vsaka od metod arhiviranja ima svoje prednosti in slabosti. Prva metoda kreira
sistemsko datoteko, v kateri so fizično shranjeni vsi podatki. Metoda uporablja arhivsko
orodje (tar, cpio oziroma backup) za arhiviranje vseh datotek v clustru. Ta način ima kar
nekaj pomanjkljivosti, ki metodo naredijo nepraktično. Prva pomanjkljivost je ta, da je
potrebno podatkovni strežnik zaustaviti, da se vse spremembe zapišejo na disk, šele potem
je mogoče izvesti arhiviranje. Arhivska orodja, kot so tar in podobna orodja, namreč niso
sposobna arhivirati stanja datotek, ki so v spominu, temveč le datoteke, ki so fizično
zapisana disku. Druga pomanjkljivost je v tem, da je velikost arhivske datoteke večja od
ustrezne skripte, ker arhivska datoteka vsebuje podatke o tabelah, indeksih. Prav tako je
nemogoče povrniti le dele gruče, na primer posamezno podatkovno bazo ali posamezno
tabelo. To ni mogoče zaradi tega, ker se podatki o posamezni tabeli zapišejo v dveh delih,
Zoran Krebs - diplomsko delo 52
vsebina tabele je zapisana v datotekah, shranjene v mapi /base, informacija o strukturi pa je
zapisana v dnevniku, ki se nahaja v mapi /pg_clog .
sintaksa ukaza:
Tar –cf backup.tar /usr/local/psql/data
SQL Dump
Druga metoda, tudi največkrat uporabljena, je metoda, ki ustvari SQL skripto, s
pomočjo katere je mogoče opraviti rekonstrukcijo podatkovne baze v primeru porušitve le
te. SQL skripta vsebuje vse informacije, v kateri so shranjene informacije, kako ponovno
generirati podatkovno baz ter obnoviti podatke v njej. V primeru potrebe preprosto
zaženemo skripto za obnovitev podatkov (pg_restore). Za izdelavo arhive se uporabljata
dva ukaza za kreiranje arhivskih skript, in sicer pg_dump in pg_dumpall.
Program/ukaz pg_dump je klient aplikacija in ustvari SQL skripto, ki lahko ponovno
kreira tabele in podatke v podatkovni bazi. V skripti so zajete vse informacije za ponovno
kreiranje sprožilcev, transakcij ter indeksov za vsako podatkovno tabelo posebej. Pri
uporabi ukaza pg_dump je na voljo veliko opcij. Podobno deluje tudi ukaz pg_dumpall.
Ukaz pg_dumpall je primeren za shranjevanje celotnega clustra, ignorira pa podporo
uporabniškega formata zapisa izhodne datoteke (tar, custom), temveč zapiše skripto le v
plain tekst formatu. Žal pa plain format zapisa datoteke ne zna shraniti velikih objektov,
zato ima ukaz pg_dumpall omejeno rabo. Ukaz pg_dump / pg_dumpall lahko zažene le
uporabnik s posebnimi pravicami, to je administrator baze (superuser).
sintaksa ukaza:
pg_dump [options] dbname ime_arhivskega_niza«
Povrnitev podatkov je mogoča z uporabo ukaza pg_restore. Ukaz pg_restore ne zna
povrniti podatkov v plain tekst načinu zapisa datoteke, tu je možna povrnitev v psql
konzolnem načinu dela.
Zoran Krebs - diplomsko delo 53
sintaksa ukaza:
pg_restore clean -d dbname ime_arhivskega_niza
Sprotno arhiviranje (On-line backup) je tretja možnost hranjenja podatkov v
PostgreSQL in deluje s pomočjo dnevnika (WAL – write ahead log). Dnevnik se kreira ves
čas delovanje strežnika in vodi vse spremembe, ki so se zgodile nad podatkovno bazo,
vključno do zadnje kontrolne točke. V dnevniku so zapisane vse transakcije, ki so
povzročile spremembe v podatkovni bazi. Dnevnik se nahaja v mapi pg_xlog. Vodi se
zaradi predvidevanja, da pride do nenadnega izpada strežnika. V tem primeru je mogoče
povrniti podatke na osnovi izdelanega dnevnika. Metodo je priporočljivo kombinirati z
metodo, ki izdela sistemsko datoteko. V kolikor moramo povrniti podatke, izvedemo
restore celotnega sistema ter poženemo dnevnik WAL, ki obnovi podatke vse od zadnje
kontrolne točke do trenutka, ko je strežnik PostgreSQL še deloval.
- a Shranjevanje podatkov, brez sheme - b Dodajanje velikih objektov v varnostno datoteko - c Brisanje sheme pred ponovnim kreiranjem - C Vsebuje tudi ukaze za kreiranje podatkovne baze - f Ime varnostne datoteke - F {c|t|p} Tip zapisa varnostne datoteke (c=custom,t=tar format,p=plain text) - h Ime lokalnega strežnika - i Izdelava varnostne kopije, kljub nesoglasjim med verzijami pg_dump ter
psql - p Številka vrat, preko katerih teče povezava - s Shranjevanje sheme, brez podatkov - S Ime administratorja baze (ponavadi: superuser, postgres, root) - t Shranjevanje določene tabele - U Ime uporabnika baze za dostop do le-te - v Verbose - W Geslo uporabnika, ki dostopa do baze - Z {0-9} Način, stopnja kompresije-stiskanja varnostne datoteke (od 0 do 9) primer uporabe:
Varnostno kopijo v PgAdmin III pripravimo s pomočjo nekaj klikov skozi menijske ukaze.
Ti skozi uporabniško vodeni meni nadomeščajo konzolni način uporabe ukaza pg_dump.
Po zagonu PgAdmin III izberemo najprej strežnik na katerem želimo delati. PgAdmin III
od nas zahteva administratorsko ime in geslo za dostop do strežnika. Po uspešni prijavi na
strežnik, se na zaslonu prikažejo podatkovne baze, ki so nam na voljo. Odpremo željeno
podatkovno bazo ter poiščemo meni Orodja, opcijo Varnostna kopija. V oknu Varnostna
kopija izberemo mesto ter ime datoteke, kamor se shrani varnostna kopija naše podatkovne
baze (slika 11.). Okno potrdimo z gumbom Ok. Varnostna kopija podatkovne baze se
shrani v datoteko s končnico .backup. Okno zapremo s pritiskom na gumb Done. Za
dnevno arhiviranje podatkov ta princip ni primeren, ker nima možnosti avtomatiziranja
procesa. Varnostno kopijo na ta način izvedemo v primeru administracije podatkovne baze
večjega obsega, npr. preselitve podatkovne baze na drug računalnik.
slika 8: določimo ime ter mesto datoteke
Zoran Krebs - diplomsko delo 67
4.5.4. Povrnitev podatkov iz varnostne kopije
Povrnitev podatkov je tako uspešna, kot smo predhodno dobro izdelali varnostno
kopijo. Pri tem je pomembna lokacija, kot tudi medij, kamor hranimo varnostne kopije.
Prav tako je pomembno glede na frekventnost podatkov, koliko kopij izdelujemo. V
nadaljevanju bomo pregledali dve vrsti povrnitve, in sicer:
• s pomočjo pg_restore ukaza v konzolnem načinu dela
• s pomočjo orodja Restore v SUPB PgAdmin III
4.5.4.1. Uporaba ukaza pg_restore v konzolnem načinu dela
Je proces, ki je shranjen v \bin imeniku. Namenjen je obnovi podatkov, ki so bili shranjeni na medij s pomočjo pg_dump. Uporabljamo ga v konzolnem načinu dela. Sintaksa: pg_restore ime_arhivske datoteke ime_podatkovne baze