UNIVERZA V MARIBORU

EKONOMSKO-POSLOVNA FAKULTETA

DIPLOMSKO DELO

e-BANČNIŠTVO – NEPREKINJENO DELOVANJE S POMOČJO FUNKCIJE HADR

Kandidat: Robert Hrvatin Študent izrednega študija Številka indeksa: 81579701 Program: Visokošolski strokovni Študijska smer: Podjetniška informatika Mentor: mag., Igor Perko

Šmarje, avgust 2007

2

PREDGOVOR Cilj diplomskega dela je prikazati eno od možnih rešitev za zagotavljanje neprekinjenega poslovanja v bankah in podjetjih, predvsem na področjih, kjer je predvideno delovanje po sistemu 24x71. Pri takih zahtevah je skoraj nemogoče imeti nekoga, ki bo neprestano nadziral sistem. Tudi v primeru takšnega nadzora pa bi prihajalo do časovnih zakasnitev – od trenutka ko se problem pojavi, do trenutka ko se ga odpravi lahko preteče preveč časa, ki ima lahko negativne finančne posledice ali negativne posledice na dobro ime podjetja. Druga vrsta nevarnosti so katastrofe, ki tudi vplivajo na negativne posledice. Zato mora podjetje zagotavljati sisteme neprekinjenega poslovanja. Ena od možnih tehničnih rešitev je funkcija HADR, integrirana funkcija podatkovne baze DB2, ki omogoča repliciranje podatkov. V povezavi z linux-ovo HA funkcijo lahko ponudi podjetju kar nekaj rešitev: rešitev neprekinjenega poslovanja zaradi nastanka incidentov, pri pravilni postavitvi na oddaljeni lokaciji zmanjšanje nevarnosti katastrof, zaradi prehoda na odprtokodne sisteme in konsolidacijo stanja pa še znižanje stroškov. E-Bančništvo postaja vse bolj priljubljeno orodje poslovanja strank z banko. Ko se za tako poslovanje odločimo kot komitenti neke banke, pričakujemo od produkta popolno in zanesljivo delovanje. Pri tem se ne oziramo na težave, ki lahko pri takem poslovanju nastanejo. Še več – od banke pričakujemo, da nam bo omogočala poslovanje 24 ur na dan, 7 dni v tednu. Seveda pa to za banko pomeni izziv, saj želi biti boljša in zanesljivejša od konkurentov. Vsak izziv pa je povezan s stroški, katere želi minimizirati. Prav alternativa med nižjimi stroški in boljšimi (praviloma tudi dražjimi) rešitvami, pa privede do iskanja in preizkušanja novih rešitev. V Banki Koper že nekaj časa delam na različnih sistemskih področjih, kjer vsakodnevno skrbim za varnost in dosegljivost podatkov, hkrati pa se soočam s krčenjem stroškov. Nedvomno si vsak sistemski programer želi upravljati visoko razpoložljive sisteme, delovni izzivi pa so nedvomno iskanje alternativ na odprtokodnih rešitvah. Prav ta razpetost je bila motiv za izbiro teme diplomskega dela. Diplomsko delo prikazuje uporabo ene od mnogih rešitev na odprtokodnem sistemu za zagotavljanje varnosti podatkov in kontinuitete poslovanja. Gre za integracijo licenciranih programov z odprtokodnimi, kjer je bistvo in najbolj pomembno prav dostopnost podatkov, ne glede na katastrofo ali incident, ki se lahko zgodi. Pri tem je pomembno, da imamo izdelane podrobne plane aktivnosti, ki jih moramo izvesti ob različnih izpadih in katastrofah, še bolj pomembno pa je, da upravljamo z sistemom, ki je zmožen sam zaznati napake in se pravilno odzvati v različnih situacijah. Zelo priporočljivo je, da tak sistem upravljamo sami, predvsem zaradi hitrejšega odziva na napake, so pa zelo priporočljive tudi zunanje podpore. Te so seveda bolj ozko in specialistično usmerjene na sam sistem ali program. Sinteza takega upravljanja se kaže v elastičnosti odzivnosti in odpravi napak. Velika hiba odprtokodnih sistemov (npr. Linuxov) je bila v začetku – kar je bil tudi večji pomislek v poslovnem svetu – prav zunanja, specialistična podpora. Vendar se v zadnjem času tudi to spreminja in se za vsak kolikor toliko resen produkt dobi (seveda plačljiva) podpora. Sam prikaz delovanja funkcije za neprekinjeno poslovanje sloni na resnični postavitvi sistema na dveh odsluženih osebnih računalnikih. Ker se v banki že dlje časa poleg drugih

1 24x7: 24 ur 7 dni v tednu.

3

uporablja tudi podatkovna baza DB2, smo iskali funkcijo in sistem, ki bi zagotavljala neprekinjeno poslovanje, ne glede na težave, ki bi lahko nastale pri delovanju sistema, tako pri strojni kot programski opremi. DB2 ima že v sebi integrirano funkcijo HADR, v povezavi z Heartbeat funkcijo linux-a pa lahko postavimo pravo gručo. Testiranje same funkcije sem začel na sistemu Suse 9 linux-u in Heartbeat-u verzije 1.2.3, končal pa na Suse 10 linux-u z Heartbeatom verzije 2.0.8. V obeh primerih sem uporabil DB2 verzije 8.2. Kakor pri vseh odprtokodnih rešitvah, je bilo potrebno tudi tu malo iznajdljivosti, sama končna postavitev sistema pa vsebuje mešane rešitve in orodja, ki so sicer značilna za prejšnje verzije sistemov.

4

VSEBINA PREDGOVOR ..................................................................................................................... 2 1 UVOD ................................................................................................................................ 6

1.1 Opredelitev področja in opis problema ....................................................................... 6 1.2 Namen, cilji in osnovne trditve ................................................................................... 6

1.2.1 Namen................................................................................................................... 7 1.2.2 Cilji ....................................................................................................................... 7 1.2.3 Osnovne trditve .................................................................................................... 7

1.3 Predpostavke in omejitve raziskave ............................................................................ 8 1.4 Raziskovalne metode................................................................................................... 8

2 INTERNET ....................................................................................................................... 9

2.1 Od e-Poslovanja do e-Bančništva.............................................................................. 10 3 e-BANČNIŠTVO ............................................................................................................ 12

3.1 Kaj to je ..................................................................................................................... 12 3.2 Zakonske določbe...................................................................................................... 13 3.3 Prednosti in slabosti e-bančništva ............................................................................. 13

3.3.1 Banka.................................................................................................................. 14 3.3.2 Podjetje ............................................................................................................... 14 3.3.3 Komitent kot fizična oseba ................................................................................. 14

3.4 Vodila e-bančništva ................................................................................................... 15 3.5 e-Bančništvo v Sloveniji – nekaj primerjav .............................................................. 16

4 VAROVANJE PODATKOV......................................................................................... 17

4.1 Različni načini zagotavljanja kontinuitete in varnosti............................................... 17 4.2 Standard BS7799 ....................................................................................................... 19 4.3 Načrtovanje obnovitve po katastrofi – Disaster Recovery Plan (DRP)..................... 20

5 i-NET BANKA BANKE KOPER.................................................................................. 23

5.1 Sistemske zahteve...................................................................................................... 23 5.2 i-Net banka za fizične osebe...................................................................................... 23 5.3 Poslovna i-Net banka................................................................................................. 25

6 FUNKCIJA HADR......................................................................................................... 26

6.1 Linux.......................................................................................................................... 26 6.2 HADR........................................................................................................................ 27 6.3 Postavitev in prireditev testnega sistema................................................................... 28 6.4 Poročilo o izvedenih testih in predlog uporabe ......................................................... 31 6.5 Predvideno produkcijsko okolje ................................................................................ 34

7 SKLEP ............................................................................................................................. 36 POVZETEK / ABSTRACT .............................................................................................. 38 KLJUČNE BESEDE / KEY WORDS ............................................................................. 38

5

SEZNAM UPORABLJENIH KRATIC .......................................................................... 39 VIRI .................................................................................................................................... 40 PRILOGE........................................................................................................................... 42 Priloga 1: PARAMETRI PODATKOVNE BAZE.............................................................. 42 Priloga 2: PREVERJANJE STATUSA BAZE ................................................................... 43 Priloga 3: HA DATOTEKE ................................................................................................ 44 Priloga 4: MON SKRIPTE.................................................................................................. 45 KAZALO SLIK Slika 1: PRIMER UPORABE PPRC FUNKCIJE............................................................... 19 Slika 2: VSTOPNO OKNO V i-NET BANKO (MAESTRAL) ......................................... 24 Slika 3: HADR OKOLJE .................................................................................................... 27 Slika 4: HADR OKOLJE S FUNKCIJO HEARTBEAT .................................................... 28 Slika 5: ARHITEKTURA TESTNEGA SISTEMA............................................................ 29 Slika 6: DB2 CONTROL CENTER.................................................................................... 31 Slika 7: PREDLOG POSTAVITVE PRODUKCIJSKEGA OKOLJA............................... 35

6

1 UVOD »Vedno znova je opaziti, da (vsaj poslovni) uspeh prinašajo ideje in nov razvoj, kjer ne gre toliko za odkritje novega, temveč bolj za novo uporabo že prej odkritega.« (Sušnik 2007, 1). Misel, ki se nedvomno vsakodnevno potrjuje. V podjetjih se informatiki srečujejo z novimi in novimi zahtevki in izzivi – akumulacija znanja, kombinacija različnih rešitev in integracija le teh v že obstoječe rešitve, pa lahko privede hitreje in učinkoviteje do želenih in zahtevanih rešitev.

1.1 Opredelitev področja in opis problema Hiter tehnološki razvoj in bitka za vsako stranko je realnost današnjega dne. Če je bila še pred 15-20 leti misel o udobnem nakupovanju preko svetovnega spleta ali opravljanje bančnih transakcij iz domačega naslonjača utopija, je danes to ne samo realnost, temveč tudi orodje in sredstvo za pridobivanje konkurenčne prednosti in strank. Je močno orožje na konkurenčnem trgu, ki pa ima za sabo veliko strateških, organizacijskih, tehnoloških in operativnih aktivnosti, ki so pogojene tudi z znanjem, pripravljenostjo in angažiranjem človeških potencialov. Za vsem pa seveda stojijo stroški, ki so pomemben dejavnik konkurenčnosti. Prvi del diplomske naloge zajema nekaj teorije o elektronskem bančništvu. Tu so prikazane tudi nekatere primerjave ponudnikov v Sloveniji. Opisani so problemi in pasti, ki nas pri takem poslovanju lahko čakajo. V tem delu je zajet tudi opis in pomen varovanja podatkov, neprekinjenega poslovanja in okrevalnih načrtov. Vse tri zadeve so povezane, saj so okrevalni načrti pomembni za neprekinjeno poslovanje in tudi varovanja podatkov. V drugem delu je opisana ponudba e-bančništva Banke Koper (i-Net Banka) s poudarkom na internetnem bančništvu. Ker se uporablja IBM-ova podatkovna baza DB2, sloni praktični del diplomskega dela na predstavitvi postavitve in prilagoditve sistema za uporabo HADR funkcije za podatkovno bazo DB2 ter testiranje in izide testiranj. Seveda sama funkcija ni edina, ki bi zagotavljala neprekinjenost oz. varnost pred izgubo podatkov, je pa zanimiva predvsem z vidika stroškov, saj sam sistem teče na Linux okoljih, ki so praviloma (če izvzamemo plačljivo podporo) brezplačni. Celotni testni sistem je bil postavljen na ločenem okolju v banki in je realna alternativa obstoječim rešitvam.

1.2 Namen, cilji in osnovne trditve V Banki Koper se – najverjetneje kakor tudi v drugih bankah in podjetjih – srečujemo z vse večjo konkurenčnostjo in pritiski na zniževanje stroškov. Ponuditi potrošniku ali stranki določen produkt ali storitev ne pomeni ponuditi produkt ali storitev kot tako, temveč tudi kvaliteten servis in predvsem zanesljivost. Na drugi strani pa so zakonski in drugi predpisi tisti, ki prisilijo podjetja v iskanje rešitev, ki bodo stranko (oz. vse informacije povezane z njo) varovale. Ne smemo pozabiti, da je stranka vedno v slabšem

7

in podrejenem položaju v primerjavi s podjetjem ali finančno institucijo. Prav ta odnos pa lahko odloča o tem ali stranka biti ali ne biti. Informacije ki se danes pretakajo po poslovnem svetu so izrednega pomena, zato moramo poskrbeti predvsem za to, da jih kot take ne izgubimo, jih hkrati varovati pred zlorabami, predvsem pa jih v vsakem trenutku imeti na razpolago.

1.2.1 Namen Kakorkoli že – varnost informacij, neprekinjenost poslovanja in predvsem možnost okrevanja po katastrofi (kakršnekoli) je vodilo današnjih postavitev informacijskih sistemov. V nekaterih primerih nas v to prisilijo zakonski in drugi predpisi, še boljše pa je, če pridemo do tega spoznanja sami. Informatiki na sistemskih področjih smo vedno bolj izpostavljeni zahtevam po varovanju podatkov, hkrati pa se od nas pričakuje pri postavitvi in uporabi takega sistema minimalne stroške. Pri tem se srečujemo z visoko razpoložljivimi sistemi (ki so dragi, vendar ponujajo sami po sebi že kvalitetne in zanesljive rešitve) ali cenovno ugodnimi rešitvami, kjer pa moramo vložiti precej truda in iznajdljivosti, da tak sistem zaživi. Bistvo pa je vedno varnost podatkov in kontinuiteta poslovanja. Alternativne rešitve so odprtokodni sistemi in rešitve na njih. Namen diplomskega dela je torej prikazati pomembnost neprekinjenega poslovanja oz. okrevanje po katastrofi in pokazati eno izmed rešitev, ki nam to omogoča.

1.2.2 Cilji Cilj diplomskega dela je pokazati pomembnost varovanja podatkov in zagotavljanje njihove razpoložljivosti na primeru internetnega bančništva, ki pa je lahko primer tudi za druge pomembne podatke, ki se pretakajo znotraj posameznega podjetja. To je opisano s pomočjo nekaterih teoretičnih rešitev, standarda BS7799 in predpisi, ter s funkcijo HADR2 v podatkovni bazi DB2 in v povezavi z Linux-HA3 projektom (Heartbeat) . Pri rešitvah, ki jih uvajamo v poslovanje igrajo pomembno vlogo tudi stroški, prav to pa je razlog, da pokazani primer sloni na odprtokodnem sistemu Linux-a. Celo največje korporacije kot so IBM se usmerjajo s svojimi rešitvami na področje linux-ov. Eden večjih pomislekov pri uporabi linux-a je bila podpora, vendar se tudi na tem področju, kakor tudi na področju izobraževanja in certificiranja kadrov, stvari bistveno spreminjajo. Ti segmenti so primerljivi z uporabo in vzdrževanjem licenciranih sistemov.

1.2.3 Osnovne trditve Podatki, ki se pretakajo v poslovnem svetu imajo neprecenljivo vrednost. Zato je naloga vsakega podjetja varovanje in zagotavljanje teh podatkov. To seveda velikokrat pomeni za podjetje strošek, ki se lahko kaže kot nakup nove strojne opreme, nakup programja, izobraževanje kadra ali plačilo izvedbe zunanjemu izvajalcu, ter seveda vzdrževanje takega

2 High Availabilty Disaster Recovery. 3 Linux-HA: Linux High Availability.

8

sistema. Rešitev je mnogo, načinov tudi, vendar so podjetja velikokrat vezana na zgodovino in neke že uveljavljene sisteme. Nove rešitve - novi sistemi pomenijo zato na eni strani izziv, na drugi pa strah pred težavami. Z razumnim kompromisom med novimi in boljšimi, vendar delno nepoznanimi rešitvami na eni strani in starimi, dobro poznanimi, stabilnimi rešitvami na drugi strani, ter z integracijo obojih lahko dosežemo tako vsebinsko kot ekonomsko učinkovite rešitve, ki lahko prinašajo podjetju neko dodano vrednost. Alternative licenciranim programom in rešitvam so odprtokodni sistemi in rešitve, vendar je uvajanje le-teh v veliki meri še odvisno od zagnanosti in pripravljenosti posameznikov.

1.3 Predpostavke in omejitve raziskave Področje elektronskega poslovanja ali pa ožje elektronskega bančništva je precej široko, zato sem se omejil le na internetno bančništvo. Predpostavljam namreč, da je ideja neprekinjenega poslovanja, kakor tudi varstva pred izgubo podatkov tako občutljiva tema, da jo lahko splošno prenesemo na vsa področja tako elektronskega poslovanja kakor tudi elektronskega bančništva. Prav tako je rešitev, ki jo bom opisal v diplomski nalogi le ena izmed mnogih. Glede na postavljene sisteme, finančne zmožnosti in tudi strateških odločitev in vizij, se podjetja srečujejo z raznimi alternativnimi rešitvami, izmed katerih se izbira v danem trenutku najboljše. Mnogokrat gre le za predstavitev ideje, mnogokrat te ideje tudi zaživijo. Drugi del diplomskega dela sloni na konkretnem primeru postavitve sistema, ki je resna alternativa obstoječim rešitvam. Za sam namen diplomskega dela sta bila uporabljena dva rabljena računalnika, kjer je bilo testirano delovanje funkcije. Model se lahko prenese na pravo testno in produkcijsko okolje. Ker je tema precej obširna se delo omejuje le na konkretno funkcijo, s predpostavko, da je vse drugo (strojne in aplikativne rešitve) za ta namen nepomembno oz. predpostavlja, da je tako okolje postavljeno na primernih strežnikih primernih zmogljivosti. Sama podatkovna baza DB2 ni prikazana v podrobnostih, za namen prikaza funkcije so pomembna le nekatere nastavitve znotraj posamezne baze.

1.4 Raziskovalne metode Diplomsko delo sloni na poslovni raziskavi ene od funkcij podjetja (del informatike oz. rešitve). Gre za dinamično raziskavo, saj se ideje in tehnologija v informatiki hitro spreminjajo. Opisana je ena izmed idej, ki se lahko integrira z drugimi rešitvami ali pa se uporablja samostojno. Vsekakor je rešitev podvržena nenehnim spremembam in izboljšavam. V diplomskem delu se prepletata tako deskriptivni kakor tudi analitični pristop. V prvem primeru se prepletajo metoda deskripcije (opisovanje osnovnih dejstev, sistemov, rešitev), komparativna metoda (primerjanje rešitev), kakor tudi metoda kompilacije (povzemanje opazovanj podobnih rešitev neprekinjenega poslovanja). Pri metodi analitičnega pristopa je uporabljena samostojna uporaba induktivnega sklepanja, kjer so analizirane rešitve, ki so opisane v diplomskem delu.

9

2 INTERNET »Svetovno omrežje ni več samo stvar strokovnjakov za računalništvo ali politikov in poslovnežev, ampak je postalo temelj komunikacije vsega sveta« (Perenič in Šalamon 2002, 12). Vsi danes govorijo o internetu, a verjetno malokdo ve, kaj se za tem izrazom pravzaprav skriva. Internet je dejansko skupek računalniških mrež povezanih z TCP/IP4 protokolom, ki omogoča komunikacije med njimi na osnovi skupnega sistema naslavljanja (Sturges 2002, 1). Sam TCP/IP protokol je v bistvu enostaven protokol, sestavljen iz 5 plasti: fizična plast, vezna plast, mrežna plast, transportna plast in aplikativna plast (Halsall 2001, 243-244). Prav njegova relativna enostavnost pa je lahko problem. Nekateri drugi protokoli so bistveno bolj kompleksni in s tem polj varni (npr. SNA5 protokol, po katerem delajo bankomati), vendar s tem tudi neuporabni za svetovni splet. Predhodnik interneta je ARPANET iz šestdesetih let in je nastal za potrebe Ameriške vojske (ibidem), natančneje leta 1969 (Korper in Ellis 2000, 103). Leta 1970 je nastal JANET (Joint Academic Network), ki je skrbel za angleške akademske povezave, istega leta pa se je ARPANET razširil na Usanet novičarske skupine (Sturges 2002, 1). Nekako od leta 1982 se uporablja ime protokola TCP/IP, pomembna letnica pa je še 1991, ko se je pojavil prvi World Wide Web in se je sam protokol začel uporabljati v komercialne namene. Strojna arhitektura sloni na gostiteljih, usmerjevalnikih in vodih (povezave). Gostitelji in usmerjevalniki so ponavadi v lasti podjetij, organizacij, vladnih ustanov ali posameznikov, same povezave pa so ponavadi v lasti telekomunikacijskih podjetij. Vsa pravna in plačilna razmerja so urejena med temi ponudniki (Stugers 2002, 2). Za povezavo odjemalca do ponudnika internetnih storitev se lahko uporablja navadno telefonsko linijo (klicni dostop), ISDN, širokopasovna omrežja - xDSL tehnologije (ADSL,VDSL, HDSL), GPRS, UMTS, predvsem podjetja pa lahko uporabljajo satelitske povezave ali pa optične povezave do ponudnika telekomunikacijskih storitev. Podjetja mnogokrat uporabljajo mešane rešitve, saj služi npr. kot primarna povezava optična povezava, v primeru izpada le-te ali okvare na strojni opremi pa se uporabi ena od drugih povezav, ki so stroškovno ugodnejše. Z internetom pa se pojavljajo tudi problemi. Le-te lahko delimo na škodljive vsebine, druge nevarne vsebine, nezanesljive vsebine, komercializacija vsebin, problem intelektualne lastnine, zasebnost in diskretnost ter internetni kriminal (ibidem, 17). Vsi ti našteti problemi pa so vzrok, da odprtost interneta jemljemo previdno. Predvsem je potrebno sisteme zaščititi (požarni zid, proti virusni programi, redna nadgradnja sistemov z varnostnimi popravki). V vsakem trenutku moramo spoštovati tako zasebnost, diskretnost,

4 TCP/IP: Transmission Control Protocol / Internet Protocol. 5 SNA: Systems Network Architecture.

10

kakor tudi intelektualno lastnino, da ne bi sami (čeprav nehote) postali del internetnega kriminala. Uporabniki svetovnega spleta se morajo zavedati, da se z uporabo le-tega pušča sledi in podatke na sleherni obiskani strani (Perenič in Šalamon 2002, 31) in s tem dejansko tudi zasebnost (ibidem, 54). Pred tem se lahko uporabniki delno zaščitijo z anonimnostjo, brisanjem piškotkov, zaščito pomembnih datotek z gesli ali pa z uporabo samo pravice branja nad datotekami. Še bolj pa je vprašljiva in občutljiva varnost pri spletnih aplikacijah kot so aplikacije e-poslovanja, e-bančništva in drugih. V tem primeru uporabnik ne uporablja spleta le za iskanje določene informacije (podatek, slika, glasba,…), temveč sproža tudi transakcije (Halsall 2001, 26). Proženje transakcij pa zahteva dodatne elemente varnosti, neprekinjenega delovanja in avtentikacije.

2.1 Od e-Poslovanja do e-Bančništva E-Poslovanje pomeni prodajo in nakupovanje dobrin in servisov preko interneta (Korper in Ellis 2002, xi in Greenstaein in Feinman 2002, 2), Govorimo o trgovini s pomočjo elektronskih medijev, vključno z vsemi dodatnimi aktivnostmi (marketing, ankete, raziskave trga, servisiranje in podpora kupcev ter produktov…). V slovenski literaturi zasledimo, da pomeni elektronsko poslovanje sklop poslovne dejavnosti s pomočjo računalniških aplikacij in računalniških omrežij ter obsega (Jerman-Blažič 2001, 11): elektronsko bančništvo, elektronsko trženje, elektronsko trgovanje, spletno trgovino, svetovanje na daljavo, elektronsko zavarovalništvo, računalniško podprto skupinsko delo, delo na daljavo, pouk na daljavo ter avkcije na daljavo. Evropska komisija je postavila definicijo elektronskega poslovanja kot katerokoli obliko poslovanja, kjer stranke delujejo elektronsko namesto da bi bile v fizičnem stiku (ibidem, 2). E-poslovanje lahko razumemo kot naslednika industrijske revolucije, ker ima potencial za spremembo temeljnih načel poslovanja (Korper in Ellis 2002, xi) hkrati pa tudi kot orodje za pridobivanje konkurenčne prednosti (Sichyikul in Chavananon 2001, 260). Splošne sestavine elektronskega poslovanja - torej tudi e-bančništva - so (Toplišek 1998,17):

- elektronsko sporočilo (format, pravne zadeve, avtentikacija…), - omrežje (naslavljanje, odgovornost, odprtost), - učinkovitost in škodljive posledice, - zasebnost (anonimnost, psevdonimi, šifrirne tehnike, ogrožanje), - država in navidezni prostor (pristojnosti, reševanje sporov, zakonske ovire), - intelektualna lastnina, - razmerje med potrošnikom oz. uporabnikom in ponudnikom, - dostop do javnih informacij.

Elektronsko poslovanje lahko delimo na dva dela (Sichyikul in Chavananon 2001, 260 ter Korper in Ellis 2002, 6):

- B2B – Business-to-Business in - B2C – Business-to-Consumer.

11

Po definiciji Jerman-Blažičeve pa obstaja še poslovanje javna in državna uprava – javnost in ljudstvo (Jerman-Blažič 2001, 17). V prvem primeru gre za interakcijo med podjetji (proizvajalci, distributerji, prodajalci, skladišča,…). Največkrat gre za integrirane sisteme, ki omogočajo hitro in učinkovito poslovanje med poslovnimi partnerji. V drugem primeru govorimo o interakciji med podjetjem in njegovim uporabnikom. Gre za prodajo, podporo in servisiranje stranke v vseh segmentih poslovanje le-te s podjetjem. V tretjem primeru pa gre za poslovanje med državnimi institucijami (javna in državna uprava) na eni strani ter posamezniki in podjetji na drugi strani. Dejavnike uspeha uvedbe e-poslovanja lahko delimo na identifikacijo poslovnih priložnosti, izbiro tehnološke infrastrukture in implementacijo rešitve (Sichyikul in Chavananon 2001, 261). Podjetje mora samo opaziti poslovno priložnost, ki jo ponuja elektronsko poslovanje. Kupljena rešitev pomeni v nekaterih primerih že zastarelo oz. uporabljeno rešitev in kot takšna ne prinaša konkurenčne prednosti. Zato mora biti taka izbira tehnoloških rešitev in implementacije rešitve tesno povezana z spoznanimi priložnostmi in vizijami. Rešitev mora biti lastna podjetju. Zanimivo je, da uvedba takega poslovanja pomeni spremembe na vseh področjih znotraj podjetja (organizacijske spremembe, tehnološke spremembe, vizije, cilji,…). Prednosti, ki jih prinaša e-poslovanje glede na tradicionalno poslovanje so priročnost, dosegljivost večjega števila poslovnih partnerjev, obsega večje geografsko področje, nižji stroški, manjša potreba po osnovnih sredstvih, boljši servis, manjši prodajni in marketinški stroški ter krajši poslovni cikli (Greenstaein in Feinman 2002, 3). Dinamika elektronskega poslovanja se kaže v dematerializaciji poslovanja in vztrajni rasti storitev, rasti mobilnosti ljudi, storitev in izdelkov ter spremenjenem načinu dela (Jerman-Blažič 2001, 18). Ker je e-bančništvo del e-poslovanja, veljajo enaka načela tudi zanj. Kljub temu vsebuje e-bančništvo nekatere specifike, saj gre v veliki meri za finančne transakcije (ne pa v celoti). Del storitev e-bančništva sicer ne potrebuje posebnega varovanja (gre za splošne informacije), večinoma pa gre za storitve povezane z določenim komitentom in s tem tudi zavezanost za varovanje tako podatkov kot transakcij (Toplišek 1998, 17).

12

3 e-BANČNIŠTVO

3.1 Kaj to je »E-banking (electronic banking) is the wave of the future.« (Example essays, 2007). Tako začenja poglavje o elektronskem bančništvu zelo obiskana spletna stran www.exampleessays.com. In nedvomno ji moramo pritrditi. E-Bančništvo je val prihodnosti, ki nas bo (je) zajel. Na tem področju se skrivajo neštete možnosti in priložnosti, ki jih bodo morale banke v vse večjem konkurenčnem boju za komitenta izkoristiti in obrniti sebi v prid. Banke lahko s pravilnimi odločitvami in marketinškimi prijemi na področju e-bančništva dosežejo tudi širitev trga. Elektronsko bančništvo lahko definiramo kot avtomatsko ponudbo novih in tradicionalnih bančnih produktov in servisov neposredno strankam s pomočjo elektronskih, interaktivnih komunikacijskih kanalov (FFIEC 2007, 1), se pravi tudi preko telefonov, avtomatov ali terminalov (Toplišek 1998, 17). Elektronsko bančništvo se je začelo z telefonskimi transakcijami in ATM-ji6, ki so že po svoji funkcionalnosti prinesli komitentom več svobode pri opravljanju transakcij, predvsem pa neodvisnost za opravljanje transakcij ne glede na lokacijo domače banke. Preko e-bančništva lahko opravljamo plačilne in druge transakcije, sklepamo razne pogodbe z banko, najamemo kredite ali podaljšujemo limite, naročamo plačilne kartice, ... To pa je vse v duhu zadovoljstva komitenta in zmanjševanja stroškov, tako bančnih kot stroškov komitenta. Praviloma so stroški izvajanja transakcij nižji od stroškov transakcij izvedenih na bančnem okencu, za banko pa odpade v tem primeru strošek delovne sile in vse logistike, ki stoji za bančnim okencem. E-bančništvo je že v osnovi močno vezano na razvoj informacijske tehnologije in je njen pomembni člen. Sam razvoj informacijske tehnologije pa lahko prinaša spremembe v gospodarstvu, preko tega pa posega na vse ravni družbe (Bučar 2002, 2). Lastnosti, ki govorijo v prid e-bančništvu so udobnost, hitrost, priročnost, prilagodljivost. Za njim pa se skrivajo tudi pasti, ki se lahko pokažejo v nepravilnih izbirah, odločitvah, rešitvah in nadzoru (banke), ter zlorabe (banke in komitenti). Prav zaradi tega je potrebna velika previdnost in odgovornost tako na stranki banke ponudnice e-bančništva, kakor tudi samega komitenta. Pri postavitvi svojega sistema e-bančništva morajo finančne institucije upoštevati štiri osnovne dejavnike (FFIEC 2003, 3):

- strateške cilje, - cilje, obseg in kompleksnost opreme, sistema in aktivnosti, - tehnološke izkušnje ter - varnosti in notranjega nadzora.

6 Automatic teller machine.

13

Sama postavitev takega sistema obsega veliko organizacijskih, strojnih in programskih rešitev. Gre za (ibidem) pripravo in načrt spletne strani, pripravo in konfiguracijo požarnega zidu, sistem preverjanja in odkrivanja zlonamernih vdorov, mrežno administracijo, varnostno politiko, strojno postavitev (spletni strežnik), aplikativne rešitve, notranjo strežniško strukturo (mrežni strežniki), programsko podporo, glavni procesni sistem in sistem avtomatskega odločanja.

3.2 Zakonske določbe Celotno elektronsko poslovanje je pravno urejeno v ZEPEP7. Zakon je pil sprejet leta 2000 in je dokaj sodoben ter prilagojen evropskim direktivam. Zadnji popravki zakona in uradno prečiščeno besedilo je bilo objavljeno v Uradnem listu RS št. 98/2004 z dne 9.9.2004. Po mnenju nekaterih je zakon včasih nerazumljiv in okorno napisan (Pavliha in drugi 2002, 10-11). Seveda je samo elektronsko poslovanje predmet tudi drugih predpisov8. Dodatni predpisi, ki spreminjajo dani predpis so 9:

- Zakon o spremembah in dopolnitvah zakona o elektronskem poslovanju in elektronskem podpisu /ZEPEP-A/ (Ur.l. RS, št. 25/2004);

- Zakon o spremembah in dopolnitvah zakona o notariatu /ZN-C/ (Ur. l. RS, št. 73/2004) in

- Zakon o elektronskem poslovanju na trgu /ZEPT/ (Ur. l. RS, št. 61/2006). Podrejeni predpisi pa so:

- Uredba o pogojih za elektronsko poslovanje in elektronsko podpisovanje (Ur. l. RS, št. 77/2000, 2/2001, 86/2006);

- Pravilnik o prijavi overiteljev in vodenju registra overitev v Republiki Sloveniji (Ur. l. RS, št. 99/2001, 42/2007).

Organ, ki je odgovoren za pripravo predpisa je Ministrstvo za informacijsko družbo. Sam ZEPEP je razvrščen v pet poglavij s 55 členi. Prvo poglavje (Pavliha in drugi 2002, 11) opisuje predvsem splošne določbe kot so definicije posameznih pojmov (kaj so podatki v elektronski obliki, elektronsko sporočilo, elektronski podpis, časovni žig, pošiljatelj, prejemnik in drugi). Drugo poglavje opisuje elektronsko poslovanje (pravila elektronskega sporočila in podatki v elektronski obliki). Tretje poglavje ureja elektronski podpis (tehnične zahteve, splošne določbe, kvalificirana potrdila, overitelj, nadzor,…), četrto in peto poglavje pa opredeljujeta kazenske, prehodne in končne določbe.

3.3 Prednosti in slabosti e-bančništva Kot vsaka stvar ima tudi elektronsko bančništvo tako dobre kot slabe strani. Prednosti in slabosti lahko delimo na tri področja in sicer:

- prednosti in slabosti za banko ponudnico; 7 Zakon o elektronskem poslovanju in elektronskem podpisu. 8 Npr. Obligacijski zakonik. 9 Vir: http://zakonodaja.gov.si

14

- prednosti in slabosti za podjetje, ki uporablja elektronsko bančništvo; - prednosti in slabosti za komitenta, kot fizično osebo.

3.3.1 Banka Elektronsko bančništvo pomeni nedvomno priložnost za zmanjševanje stroškov, vendar gledano dolgoročno ali pa vsaj srednjeročno. Z elektronskim bančništvom se manjša potreba po zalednem poslovanju (back-office) in vsej logistiki, ki je povezana s tem. Seveda ne gre za popolno ukinitev zaledja, gre za manjše potrebe in drugače organizirano delo – spreminja se torej profil bančnega uslužbenca. Poleg tega lahko na tak način banka zelo hitro in učinkovito predstavi in ponudi trgu novo storitev, tak način pa lahko izkoristi tudi za širitev tako svojih dejavnosti kot trga, na katerem nastopa. Prednost je tudi zanesljivost. Slabosti se kažejo predvsem v začetnih vložkih, ki so ponavadi zelo visoki. Stroški se kažejo v nabavi strojne opreme in programskih rešitev, ki so lahko razvite v sami banki, v banki z sodelovanjem tudi zunanjih izvajalcev ali pa v celoti z zunanjimi izvajalci. Seveda mora pri teh izbirah biti banka izredno previdna, saj gre za zelo občutljivo področje, kjer se pretakajo zelo zaupljivi podatki. Pri celotnem razvoju rešitve mora biti prisoten tudi temeljiti nadzor, kar pomeni angažiranje in preusmerjanje določenih notranjih virov (strojnih ali človeških).

3.3.2 Podjetje Podjetju pomeni integracija elektronskega bančništva z svojim informacijskim sistemom predvsem racionalizacijo procesov pri poslovanju oz. pri opravljanju plačilnega prometa in vse, kar je s tem povezano v domovini in s tujino. Pomeni prihranek predvsem pri stroških in času pri opravljanju raznih poslov z banko ponudnico. Slabosti pri poslovanju se kažejo predvsem v različnih programskih rešitvah pri posameznih bankah. Začetni vložki so načeloma nižji kot pri bankah ponudnicah, z ustreznimi prijemi pa jih podjetje lahko minimizira. Tudi zlorabe, ki bi se pojavile zaradi poslovanje preko medmrežja so manjše kot pri fizičnih osebah, saj gre v podjetjih praviloma za boljše organizirane postopke in delo, pa tudi poti do banke so bolj varne.

3.3.3 Komitent kot fizična oseba Komitent kot fizična oseba lahko opazi prednosti elektronskega bančništva predvsem v stroških (manjši), pri prihranku časa, udobnosti poslovanja in priročnosti. Želeno transakcijo in informativne izračune lahko opravi kadarkoli in kjerkoli. Začetni strošek pomeni nakup računalnika in drugih komponent, da bi lahko uporabljali e-bančništvo. Slabosti in nevarnosti se kažejo pri uporabi svetovnega spleta. Kot vemo, je medmrežje zelo ranljivo in nudi nešteto možnosti zlorab. V zadnjem času se sicer stvari okoli varnosti izboljšujejo, saj se uvaja tehnologija t.i. pametnih kartic, kjer je možnost

15

zlorabe manjša. V vsakem primeru pa mora komitent biti zelo pazljiv pri uporabi e-bančništva, upoštevati mora vse varnostne nastavitve, uporabljati proti-virusne programe, predvsem pa mora biti pazljiv pri posredovanju kakršnihkoli podatkov preko spleta.

3.4 Vodila e-bančništva Pri razvoju e-bančništva moramo izvesti različne procedure, ki nam bodo omogočile pravilno in uspešno postavitev sistema (FFIEC 2007, 3). Banka mora postaviti in sprejeti strateški plan, raziskati učinek e-bančništva na kapital in zaslužek. V naslednji fazi mora banka izbrati izvajalca (lahko je notranji ali zunanji) in vzpostaviti nadzor nad njim. Velik poudarek mora biti na varnosti in internim nadzorom same izvedbe projekta, skladen pa mora biti tudi z vsemi zakonskimi normativi. V projekt mora biti vključen tudi prodajni management. Projekt ne sme biti zaprt, temveč mora omogočati dopolnjevanje in nadgradnjo, lahko tudi spremembe ali izločitev nekaterih zamisli. Končna ekspertiza mora dati jasno sliko o želenem in izvedenem, o razlikah, vzrokih in možnih rešitvah. Baselski komite za bančni nadzor v svojem dokumentu Risk Management Principles for Electronic Banking (BIS 2007) navaja 4 izzive in 14 vodil, ki naj jih banke uporabijo pri razvoju in vpeljevanju elektronskega bančništva v svoje poslovanje. Izzive, katere naj banke upoštevajo in na katere naj bodo posebej pazljive so hitro rastoča tehnologija in inovacije, integracija informacijskih sistemov z upoštevanjem legalnih verzij, povečevanje odvisnosti banko od informacijske tehnologije, poseben poudarek pa mora veljati zaščiti podatkov, varnosti in nadzoru. Prav tako naj banke pri uvajanju elektronskega poslovanja upoštevajo razne standarde in predvsem naj spoštujejo zasebnost strank. Sama vodila se delijo na tri dele:

a. Nadzor vodstva in managementa (vodila 1-3): - vloga managementa, - vzpostavitev obsežnega nadzora varnosti, - določitev pričakovane prizadevnosti, razmerja in nadzor zunanjih izvajalcev.

b. Nadzor varnosti (vodila 4-10): - avtentikacija e-banking odjemalca, - ne zavračanje odgovornosti za izvedene transakcije, - primerne mere za ločevanje odgovornosti, - avtorizacija na sistemu, bazah podatkov in aplikacijah, - integriteta informacij, podatkov in transakcij, - sledenje transakcij, - zaupnost bančnih informacij. c. Zakonska vodila in zagotavljanje ugleda banke (vodila 11-14): - predstavitev in dostopnost e-bankinga, - zasebnost strank, - zagotavljanje servisa in uporabnosti e-bankinga, - planiranje hitrih odgovorov in rešitev v primeru incidentov.

16

3.5 e-Bančništvo v Sloveniji – nekaj primerjav Čeprav je uporaba interneta v Sloveniji celo nekaj nad povprečjem v EU-25, pa je vendar uporaba e-bančništva krepko za evropskim povprečjem (Vehovar 2007, 16). Razlogi za to naj bi bili v tem, da ni nobenih vidnih prednosti pred drugimi načini (stroški, čas), vendar se na področju stroškov v zadnjih časih stvari nekoliko spreminjajo v prid e-bančništva. Po anketi časopisa Delo (Vir Delo 2006, povzeto po RIS 2006) je spletno bančništvo v Sloveniji uporabljalo 34 % vprašanih, od tega je bilo 52 % zelo zadovoljnih, zadovoljnih 31 %, nezadovoljnih 3 % in zelo nezadovoljnih 9 %. 18 % vprašanih ni uporabljalo e-bančništva a je razmišljalo o tem, 4 % pa je razmišljalo o začetku uporabe v roku 1 leta. Socialdemografska struktura uporabnikov e-bančništva v Sloveniji v glavnem ne odstopa od strukture uporabnikov interneta, v uporabo vstopajo specifični uporabniki, več uporabnikov pridobivajo manjše in tuje banke (lojalni uporabniki), prihaja do zamenjav banke in uporabe dveh ali več ponudnikov e-bančništva, varnost in nizki interes pa so poglavitni dejavniki zaviranja uporabe e-bančništva. To so glavne in le nekatere ugotovitve iz anket decembra 2004 (RIS 2007). Tabela 1: PRIMERJAVA NEKATERIH STROŠKOV E-BANČNIŠTVA

Vrsta stroškov \ Banka NKBM10 SKB NLB Banka Koper11 Študenti/dijaki 12,50 € 10,43 € 10,43 € 0,00 € Fizične osebe 31,30 € 20,86 € 20,86 € 0,00 € Vstopni stroški Pravne osebe 20,86 € / 54,25 € 20,86 € 29,21 € 0,00 € Študenti/dijaki 0,00 € 0,00 € 0,00 € 0,00 € Fizične osebe 0,00 € 0,42 € 0,00 € 0,42 € Mesečna uporaba Pravne osebe 4,17 € 6,26 € 0,00 € 2,92 € / 5,01 € / 9,18 €

interno 0,29 € 0,21 € 0,31 € 0,23 € <50.000 € 0,63 € 0,21 € 0,31 € 0,33 €

Fizične osebe

>50.000 € 4,60 € 2,59 € 0,31 € 3,55 € interno 0,31 € 0,31 € 0,33 € 0,33 €

<50.000 € 0,73 € 0,69 € 0,75 € 0,71 €

Plačilo položnice

Pravne osebe

>50.000 € 4,60 € 0,69 € 0,75 € 5,42 € Vir: NKBM, SKB, NLB, Banka Koper. Tabela 1 prikazuje primerjavo nekaterih stroškov e-bančništva nekaterih bank ponudnic v Sloveniji. Pri vseh bankah so stroški plačilnega prometa manjši od stroškov plačilnega prometa opravljenega na bančnem okencu. Iz tabele je razvidno, da nekatere banke segmentirajo pravne osebe (npr. Banka Koper), pa tudi stroški plačevanja položnic lahko variirajo tudi za 8-krat (pravne osebe nad 50.000 €). Tudi pri stroških položnic pri plačevanju fizičnih oseb prihaja do bistvenih razlik.

10 Vstopni stroški pravne osebe: internetna različica / namestitvena različica. 11 Mesečna uporaba pravne osebe: mala podjetja / srednja podjetja / velika podjetja.

17

4 VAROVANJE PODATKOV »Varnost informacij ni več odgovornost zaposlenih na nižjih ravneh oddelka za informacijsko tehnologijo« (Egan 2005, xv). Zakaj sploh varovati informacije in podatke? Predvsem zaradi tega, ker lahko izguba podatkov povzroči tako finančne kot nefinančne posledice podjetju (ali banki), v skrajnem primeru pa lahko privede tudi do propada podjetja. Prav zaradi tega je pomembno določilo Sarbanes-Oxleyevega zakona, ki predvideva odgovornost tako upravnih odborov, kakor tudi revizorjev pri nadzoru zmogljivosti in varnosti ključnih informacijskih sistemov (ibidem, xvi). To pomeni večjo odgovornost vodilnih, predvsem pa spremembo miselnosti v poslovanju, kjer se mora varnost integrirati v vse pore poslovanja in je prisotna od strateške do operativne ravni odločanja.

4.1 Različni načini zagotavljanja kontinuitete in varnosti Pri celoviti rešitvi zagotavljanja varnosti moramo upoštevati tri komponente (Egan 2005, 27-30):

- osebje (velikost podjetja, panoga in zapletenost poslovanja); - postopki (pravilniki, standardi, postopki); - tehnologija (sama tehnologija ne rešuje problemov).

V bistvu nam te tri komponente pokažejo, da je celovita varnost stvar ne samo tehnologije temveč dodelanega, organiziranega in sistemiziranega celotnega področja poslovanja. Zavedati se moramo, da prihaja še vedno največ groženj prav iz samega podjetja, zato je prav, da obstaja velika pozornost tudi organiziranosti in varovanju znotraj podjetja (namerna ali nenamerna zlo dejanja), hkrati pa obstajajo tudi zunanje grožnje (hekerski vdori, konkurenca, vohunjenje…). Standardizacija postopkov in aktivnosti zagotavlja v kriznih trenutkih pravilno in hitro reagiranje na incidente, sama tehnologija pa je tista, ki nam te incidente preprečuje ali pa zmanjšuje ti. čas izpada (down-time). Sisteme zagotavljanje varnosti bi lahko razdelili na sisteme, ki preprečujejo poskuse ustvarjanja incidentov (tako namernih kakor tudi nenamernih) in na sisteme, ki zmanjšujejo vpliv incidentov na poslovanje. Incidenti se lahko zgodijo zaradi zlonamernih dejanj (vdori, brisanje podatkov, sabotaža) ali pa nastanejo zaradi okvare strojne oz. programske opreme. Prve incidente lahko preprečujemo z ustrezno infrastrukturo in večplastnim varovanjem (Egan 2005, 140). Plasti varujemo na sledeče načine:

- Prehodi: AAA12, požarni zidovi in VPN, protivirusna programska oprema, zaznavanje vdorov in filtriranje vsebine.

- Strežniki: AAA, protivirusna zaščita, upravljanje pomanjkljivosti, zaznavanje vdorov.

- Odjemalski računalniki: AAA, požarni zidovi in VPN, protivirusna programska oprema, zaznavanje vdorov.

12 AAA: Authentication, Authorization, Accounting (pristnost, pooblaščanje, upravljanje računov).

18

Pri drugih incidentih se uporablja strojne in programske rešitve, ki zagotavljajo nemoteno poslovanje in varovanje podatkov. Tako prehodi in strežniki v prvem primeru, ter vsa strojna oprema v drugem primeru se mora nahajati v ti. kritičnem področju (ibidem, 138), kateri mora biti namenjeno največ varnosti. Gre za jedro računalniškega okolja, kjer se nahaja najpomembnejša strojna oprema in kjer se izvajajo vse najbolj pomembne aplikacije in obdelave podatkov. To jedro mora biti tudi fizično varovano in pod nadzorom (alarmi, vstopne identifikacije, video nadzor). Incidente ali njihove posledice, ki nastanejo zaradi okvare strojne ali programske oprema lahko preprečujemo na več načinov. Najbolj razširjeno in verjetno tudi najstarejše je shranjevanje podatkov na arhivske medije. Včasih so bili to trakovi, nato kasete različnih generacij, CD-ji in DVD-ji, danes pa se že uporabljajo diskovne rešitve, ki simulirajo te medije. Časi restavriranja podatkov iz teh medijev so se skrajševali s prihodom medijev novih generacij, vendar še vedno pomenijo določen čas izpada. Prav tako je potrebno pri teh načinih imeti rezervne strojne kapacitete za primer strojne okvare. Nove zahteve po varnosti in neprekinjenemu poslovanju pa so privedle do rešitev ti. računalniških gruč (clusterjev). Gre za programske rešitve, ki zapisujejo podatke na dve različni lokaciji istočasno. To so lahko že kupljene rešitve (Veritas Cluster, MS Cluster in drugi), ali pa rešitve, ki se jih sestavi iz različnih komponent in programov (eden takih je opisan v nadaljevanju – HADR za bazo DB2 v kombinaciji z Linux Heartbeatom). Pravilno sestavljene gruče so dokaj stabilne, časi izpada so minimalni, vendar se lahko še vedno pojavljajo problemi. Nekako višja raven pa je replikacija podatkov na ravni diskovnih kapacitet. Gre za različne rešitve različnih proizvajalcev diskovnih kapacitet (npr. PPRC13 in FlashCopy pri IBM-u ali Mirror view, SnapShot ali Clon pri EMC²-ju). V bistvu gre za neprestano repliciranje, lahko asinhrono ali sinhrono (PPRC, Mirror View), ali repliciranje v določenem trenutku (FlashCopy, SnapShot ali Clon). Vsak način ima tako prednosti in slabosti. Pri neprestanem repliciranju se pokvarjeni podatek replicira tudi na rezervno lokacijo (enak problem se pojavlja v gručah), pri enkratnem repliciranju, pa izgubimo podatke od zadnjega repliciranja do nastanka incidenta. S pravilno konfiguracijo in kombinacijo naštetih funkcij, pa lahko te pomanjkljivosti zmanjšamo. Vendar še vedno gre za varovanje predvsem v primeru izpada strojne opreme. Slika 1 prikazuje primer postavitve sistema z uporabo PPRC funkcije. Host1 je produkcijski strežnik (lahko tudi mainframe), host2 je strežnik v pripravljenosti, disk1 je primarni disk na SAN14-u, disk2 pa je disk na katerega se replicirajo podatki iz disk1. Primer rešuje sledeče postavitve: host1 - disk1 (produkcijsko okolje), host1-disk2 (primer izpada primarnega diskovnega sistema), host2 - disk1 (primer izpada primarnega strežnika) in host2 - disk2 (primer izpada primarnega strežnika in primarnega diskovnega sistema). V primeru, da sta host2 in disk2 postavljena na oddaljeni lokaciji, rešuje ta postavitev tudi primer sabotaže ali katastrofe. Različne kombinacije sistemov se doseže z vnaprej pripravljenimi parametri za dvig sistema. V takih primerih je čas izpada sestavljen iz časa, ko se ugotovi incident in sprejme odločitev za prehod na rezervno lokacijo (daljši čas) in časa za postavitev sistema (krajši čas).

13 PPRC: Peer-to-Peer Remote Copy. 14 SAN: Storage Area Network.

19

Slika 1: PRIMER UPORABE PPRC FUNKCIJE HOST1 HOST2

DISK1 DISK2

PPRC

4.2 Standard BS779915 Standard BS7799 postavlja kodeks varovanja informacij (Code of practice for information security management). Z standardom sta povezana še standarda BS 7083:1989 – Reccommendations for the accomodation and operating environment of computer equipment in ISO/IEC 2382-1:1993 Information technology – Vocabulary – Fundamental terms. Smiselno in vsebinsko ga dopolnjujeta še SIST BS 7799-2:2003 Sistemi za upravljanje varovanja informacij – Specifiikacija z napotki za uporabo (Information security management system – specification with guidance for use) in SIST ISO/IEC 17799:2003 Informacijska tehnologija – Kodeks upravljanja varovanja informacij (Information technology – Code of practice for information security managemant). Standard opredeljuje namen varovanj informacij kot zagotavljanje neprekinjenega poslovanja in omejevanje poslovna škode na najmanjšo možno mero predvsem s preprečevanjem incidentov ali pa z zmanjševanjem njihovih učinkov. Lastnosti informacij, ki jih moramo varovati so zaupnost (dostopnost), neoporečnost (točnost, popolnost) in razpoložljivost. Grožnje, ki se pojavljajo in so vzrok varovanja so lahko naravne katastrofe ali pa računalniški kriminal, sabotaže, vohunstvo, okvare,… Dejstvo je, da je preventivno delovanje v primerih katastrof ali incidentov cenejše od odpravljanja napak in izpadov. Pri postavljanju sistema varovanja informacij mora podjetje upoštevati tako fizično varovanje, kakor tudi obvladovanje programskih rešitev. Cel načrt bi moral zajeti 10 ključnih nadzorov: dokumentiranje, odgovornost, izobraževanje in usposabljanje, poročanje o incidentih, obvladovanje računalniških virusov, načrt neprekinjenega poslovanja, obvladovanje kopiranja avtorsko zaščitenega programja, varovanje zapisov, zaščita podatkov in usklajenost z varnostno politiko.

15 Povzeto po Code of practice for information security management, Urad RS za standardizacijo in meroslovje.

20

Ocenjevanje tveganj mora sloneti predvsem na ocenjevanju poslovne škode, ki nastane z incidentom in dejanske verjetnosti, da se tak incident zgodi. To tudi postavlja prioriteto posameznim strojnim ali programskim rešitvam, katero se nato upošteva pri načrtovanju aktivnosti. Seveda temelji sestava načrta na vrstah poslovnih sistemov, občutljivosti in pomembnosti informacij, okolja uporabe in morebitnih vgrajenih zaščitah in nadzor v samih rešitvah. Standard zajema 10 poglavij, ki opisujejo od osnovnih opredelitev do zakonskih zahtev. Nekako najbolj zanimivo je 9 poglavje, ki govori o načrtovanju neprekinjenega poslovanja. Cilj je imeti pripravljen akcijski načrt za preprečevanje prekinitev poslovnih dejavnosti. Načrtovanje mora zajemati naslednje ukrepe: postavitev prioritet poslovnih procesov, opredelitev možnih vplivov incidentov na poslovne dejavnosti, definiranje odgovornosti v primeru incidentov, dokumentiranje postopkov in procesov, izobraževanje osebja, preverjanje in dopolnjevanje načrtov. Integralni načrt naj bi zajemal različne ravni: ukrepanje v sili, postopki za rezervno delovanje, postopke za ponovno delovanje in razpored preizkušanja. Ker varovanje ni statična postavka temveč se dinamično spreminja, je potrebno pri dopolnjevanju in nadgrajevanju sistema upoštevati nove tehnologije, nabavo nove opreme, kadrovske in organizacijske spremembe, spremembe z zunanjimi partnerji, spremembe naslovov in telefonskih številk, spremembe poslovnih procesov, spremembe v uporabniških rešitvah, spremembe v načinu obratovanja in spremembe v zakonodaji.

4.3 Načrtovanje obnovitve po katastrofi – Disaster Recovery Plan (DRP) Obnovitev po katastrofi (Disaster recovery) je eden od treh elementov kontinuitete poslovanja (IBM 2005, 6), kamor spada še neprekinjeno poslovanje in visoka razpoložljivost. Skladnost in kombinacija vseh treh elementov lahko pomaga podjetju ali banki uspešno premoščanje nepredvidenih težav, izpadov, sabotaž ali drugih dejanj, ki lahko negativno vplivajo na poslovanje in imajo tako finančne kot ne-finančne posledice. Razlika med visoko razpoložljivostjo in disaster recovery se kaže v tem, da je prva namenjena predvsem lokalnim izpadom, disaster recovery pa pomeni možnost okrevanja na rezervni, oddaljeni lokaciji na različni strojni opremi v primeru, ko je primarni računalniški center bodisi nedosegljiv ali uničen. Ker je kontinuiteta poslovanja (vezano na računalniško infrastrukturo) pomembna za celotno poslovanje in posledično celotno podjetje ali banko, si moramo postaviti pri organiziranju in postavljanju sistema kontinuitete poslovanja naslednja vprašanja (ibidem, 4):

- Ali imamo ustrezen nadzor nad poslovnimi procesi in izpadi računalniške infrastrukture?

- Ali imamo ustrezne računalniške kapacitete za zagotavljanje neprekinjenosti poslovanja?

- Ali imamo postavljena ustrezna pravila glede kontinuitete poslovanja in orodja za upravljanje teh pravil?

21

- Ali lahko z obstoječim denarnim tokom in budgetom zagotavljamo ustrezno računalniško podporo kontinuiteti poslovanja?

Tudi najboljše načrtovani in pripravljeni sistemi se ne morejo popolnoma zavarovati pred katastrofami (Greenstaein in Feinman 2000, 178). Tako naj bi vsako podjetje imelo načrt neprekinjenega delovanja. Vzroki za to so lahko tako naravne katastrofe (poplava, požar, potres in drugi), strojni ali pa tudi človeški dejavnik (izpad strojne opreme, napake, sabotaže, virusi,…). Načrt neprekinjenega delovanja naj zajema (ibidem):

- ocena ranljivosti; - preventiva in zmanjševanje tveganj; - priprava stroškovno učinkovitih rešitev; - zagotavljanje kontinuitete in minimiziranje poslovne prekinitve; - zagotavljanje alternativnih dostopov; - procese pridobivanja izgubljenih podatkov; - priprava načrta in procedur neprekinjenega poslovanja in - šolanje uporabnikov za različne procedure neprekinjenega poslovanja.

Vidimo, da se načrt ujema z BS7799 standardom. Cilj tako pripravljenega načrta je minimizirati finančne posledice in izgube dobrega imena v primeru katastrofe ali katerekoli druge oblike izpada delovanja. Gre za preventivne ukrepe, na katere mora biti organizacija pripravljena (Bloomsbury 2002, 496). Pomembno je da taki načrti nastajajo v sodelovanju z uporabniki sistemov in aplikacij, predvsem pa je pomembno nenehno preverjanje (v nekaterih primerih so to tudi zahteve nekaterih institucij – npr. Banke Slovenije) in nadgrajevanje teh načrtov. Neupoštevanje tega lahko privede do slabih rešitev, ki zahtevajo več časa za prehod od načrtovanega ali še sprejemljivega, v skrajnem primeru pa so lahko tudi neuporabne. Osnovni potek priprave načrta je (ibidem): definiranje ekipe (teamsko delo), ocenitev tveganj, postavitev načrta (ključni uporabniki, odgovornosti, lokacija centra, aktivnosti), simulacija in testiranje ter nenehno izpopolnjevanje in nadgrajevanje. Obstajajo 3 alternativne postavitve rezervnega centra (Greenstaein in Feinman 2000, 180):

- 2 organizaciji (ali več) si delijo kapacitete (Mutual aid pact); - prodajalec v določenem času (12-24 ur) nabavi novo opremo (Cold site – Create

and ship); - polno operativna rezervna lokacija (Hot site).

Katero rezervno postavitev bo podjetje izbralo je odvisno od tega, kakšna je občutljivost izpada (pomembnost podatkov) in kolikšni so lahko časi izpadov ter seveda stroški. Načrti neprekinjenega poslovanja lahko zajemajo posamezne segmente (lahko tudi same aplikacije), najboljši pa so tisti, ki zajemajo podjetje in poslovanje kot celoto. Načrti morajo biti sestavljeni tako, da se lahko vsak njihov segment uporabi posamično (npr. izpad strežnika z xy aplikacijo) ali pa kot celoto (malo verjetnosti za uporabo – samo v primeru res velike katastrofe). Prav zaradi tega je iz tehničnega vidika (načrt mora biti integriran v strategijo poslovanja podjetja ali banke) pomembno sodelovanje pri pripravi v prvi vrsti sistemskih in aplikativnih vzdrževalcev, v fazi testiranja in potrjevanja pa tudi

22

uporabnikov. Odvisno od priprave načrta lahko uporabnik opazi izpad (npr. uporaba rezervne aplikacije) ali pa ne (za uporabnika se ne spremeni način dela). Tudi pri tehničnih rešitvah se pojavljajo razlike. Najboljše so tiste, kjer je rezervni center identična slika produkcijskega okolja. Vendar je to tudi najdražja rešitev, zato podjetja uporabljajo mešane rešitve. Pri bolj pomembnih aplikacijah (core business) se uporablja enaka strojna oprema v gručah ali pa v visoki pripravljenosti, za manj pomembne (kjer daljši časovni izpadi bistveno ne vplivajo na poslovanje) pa se uporablja manj zmogljivo strojno opremo, podatke (lahko tudi aplikacije) pa se prepisuje iz arhivskih medijev. To je tudi vzrok, da se podjetje načrta loti preudarno in v sodelovanju z uporabniki ter upoštevajoč strategijo in cilje podjetja določi prioritete tako aplikacij kot tudi vrstnega reda izvajanja aktivnosti pri uporabi načrta. Pri celovitih rešitvah in načrtih se predvsem v večjih podjetjih ali bankah, kjer gre za kompleksne sisteme različnih aplikacij z zahtevami 24x7 (tudi e-bančništvo), pojavijo težave s testiranjem načrta in simulacijo izpadov. Uporaba različnih aplikacij je lahko bolj intenzivna v določenem dnevnem terminu, obdelave podatkov se lahko izvajajo v različnih časovnih terminih. Zaradi tega je pomembno, da se načrt pripravi in testira še v fazi priprave samega okolja oz. aplikacije in se ga nato dopolnjuje glede na spremembe v produkcijskem okolju. Kasneje se testiranja izvede v terminih, ko prekinitve najmanj prizadenejo uporabnika (sobote, nedelje, prazniki, nočne ure), lahko tudi po posameznih segmentih. Pri vsakem testiranju je pomembno, da je pripravljen akcijski plan za primere težav pri postavljanju rezervnega okolja tako, da se lahko čim hitreje postavi prvotno produkcijsko okolje in s tem minimizira čase prekinitev. Vsi dogodki (težave, potek in izidi) morajo biti dokumentirani. Če se ugotovi kakršnekoli odstopanja tako pri vzpostavitvi, kakor tudi pri izidih testiranja, je potrebno odstopanja odpraviti in ponoviti testiranja. Le tako se potrdi pravilnost okrevalnega načrta in s tem njegov smisel in namen.

23

5 i-NET BANKA BANKE KOPER16 Uporabnik i-net banke lahko postane oseba s stalnim bivališčem v Sloveniji, ki ima pri banki odprt račun in na podlagi ugodno rešene vloge s strani banke. Imetnik računa pri banki lahko pooblasti uporabnika i-net banke da opravlja storitve za njegov račun. Pri sklepanju pogodbe se uporabnik zaveže, da bo osebno številko skrbno varoval, banka pa da bo opravila naročene storitve, seveda če bodo izpolnjeni pogoji (npr. stanje na računu). Vendar pa banka ne prevzema odgovornosti pri morebitnih napakah in prekinitvah na komunikacijskih kanalih.

5.1 Sistemske zahteve Sama aplikacija, ki podpira delovanje i-net banke dandanes ni požrešna, saj jo lahko namestimo že na računalnik s procesorjem Pentium 120 ali več in 64 MB RAM-a. Potrebni prostor na trdem disku je 32 MB. Potrebujemo še zaslon z resolucijo 800x600 točk (najmanj) in modem. Potrebni operacijski sistem je Microsoft Windows od verzije 95 naprej. Kot uporabnik tu pogrešam še druge rešitve, kot so npr. Linux okolja ali Macintosh. Za dostop do interneta se uporablja Microsoft Explorer 5.5 ali novejši in Netscape 6.1 ali novejši. Glede na širok izbor spletnih brskalnikov tudi tu pogrešam še druge rešitve (npr. odprtokodni Mozzila – čeprav izhaja iz Netscape Navigatorja se pri uporabi pojavljajo težave). Če uporabnik dostopa do i-Net banke preko požarnega zidu, morajo biti odprta vrata 80 (http) in 443(https). Varnost poslovanja z i-Net banko je podprto na več ravneh. Elementi varnosti so požarni zid, šifriranje podatkov na svetovnem spletu, šifriranje podatkov elektronske pošte s PGP standardom in identifikacija s tajno številko. Poleg tega so vgrajene varovalke kot so varnostni sistem proti ugibanju PIN-a, varnostni sistem proti hkratni prijavi in varnostni sistem samodejne odjave.

5.2 i-Net banka za fizične osebe Do i-Net banke lahko dostopamo preko spletne strani banke Koper ali neposredno na naslovu https://i-banka.banka-koper.si. Za dostop sta na razpolago dva paketa: Burja in Maestral. Razlikujeta se po tem, da prvi uporablja stacionarni čitalec kartic v kombinaciji s certifikatom, drugi pa prenosni čitalec kartic oz. generator naključnega gesla. Oba uporabljata pametno – čip kartico. Paket Maestral mogoča tudi spremembo uporabniškega imena. Po prijavi dobimo seznam računov, tudi pooblaščenih. Račune lahko pregledujemo podrobneje, prav tako storitve (npr. trajniki, čekovni blanketi, nezapadli nalogi...) na računu, pod vsakim računom pa dobimo tudi informativno premoženjsko bilanco. Izpis prometa lahko opravimo za 10 dni, 1 mesec, 2 meseca ali 3 mesece. Nezapadli nalogi nam pokažejo naloge, ki niso bili obdelani zaradi treh razlogov: nalog čaka na izvršitev, ali

16 Vir: Interna in reklamna gradiva Banke Koper.

24

nalog je bil oddan z datumom vnaprej, ali nalog z napako. Napaka se lahko pojavi zaradi nepravilnosti računa prejemnika ali nezadostnega stanja na računu stranke. Slika 2: VSTOPNO OKNO V i-NET BANKO (MAESTRAL)

Naročanje storitev nam omogoča naročilo čekovnih blanketov, plačilnih kartic, lahko posredujemo vlogo za prekoračitev sredstev na osebnem računu, lahko naročimo redno obveščanje za izbrane račune, vežemo tolarska ali devizna sredstva in najamemo mini kredite. Plačila lahko izvedemo s posebno položnico, plačilnim nalogom ali internim nalogom za prenos. Plačila se lahko opravljajo med računi na banki, na račune pravnih oseb, na račune na drugih bankah ali v tujino. Plačilo se lahko izvede takoj, ali pa na datum, ki ga napovemo. Pri zunanjih plačilih mora biti to delavni dan, sama aplikacija pa nas opozori, če je datum neustrezen. Pomanjkljivost, ki jo pogrešam kot uporabnik pri notranjih plačilih, je avtomatski izpis podatkov na podlagi številke računa (podobno kot pri plačilu pravnim osebam). Resda je dejansko nemogoče dobiti podatke fizičnih oseb pri drugih bankah (zaupnost in varnost podatkov), bi pa bilo zelo priročno, če bi lahko dobili podatke vsaj za komitente banke. Pri plačilih si lahko ustvarimo tudi lastni imenik, kjer nam ostanejo podatki o nalogih, seveda brez zneskov. To je priročno, če plačujemo npr. vsak mesec položnico istemu podjetju. Tako jo pokličemo iz imenika, vstavimo samo znesek, datum plačila in plačilo je izvedeno. Vse nezapadle naloge lahko pregledujemo v posebni izbiri, po potrebi jih lahko izbrišemo in ponovno pripravimo.

25

Prodaja, nakup in menjava deviz se opravlja v okviru deviz, ki jih imamo na računu. Seveda bi bilo priročno, če bi lahko opravili nakup deviz, katere na računu še nimamo. Pri novi valuti moramo namreč najprej položiti ali opraviti nakup na bančnem okencu. Info izračuni nam pripravijo informativne izračune za depozite, posojila in menjavo deviz.

5.3 Poslovna i-Net banka Dostop do Poslovne i-Net banke je možen s certifikatom in PIN-om. Poslovna i-Net banka je namenjena pravnim osebam za opravljanje elektronskega plačilnega prometa v državi in tujini, zajema pa tudi druge bančne posle kot so: kreditno in depozitno poslovanje, pregledovanje podatkov o računu, stanja na računih, prilive in odlove, pregledovanje arhivskih podatkov, naročanje različnih storitev in poslovnih informacij. Je odprt sistem in se stalno nadgrajuje z novimi funkcijami, ki bodo pravnim osebam olajšala poslovanje z banko. Dostopna je 24 ur na dan, 365 dni v letu. Storitve lahko opravljamo na tekoči dan, ali pa z zamikom. Prednost je tudi hitri obveščanje in pregledovanje. Tako dobimo ažurno stanje o računu. Tako za stranko kot banko pomeni poslovanje nižje stroške. Poslovna i-Net banka pomeni za stranko udobno poslovanje iz sedeža podjetja, prihrani tudi čas nošenja nalogov na banko, čas reklamacij se skrajša. Funkcije Poslovne i-Net banke lahko delimo na tri sklope. V prvem sklopu lahko navedemo plačilni promet, ki zajema plačevanje iz računa v državi in v tujino in upravljanje s sredstvi na računu (Cash Management). V drugi sklop sodijo storitve: storitve vezane na poslovanje s poslovnim računom, izmenjava podatkov z banko po varnih poteh (npr. plače), reševanje reklamacij in pošiljanje mnenj kontaktni osebi v banki, prejemanje, shranjevanje in tiskanje izpiskov. Tretji sklop, ki je največji zajema informacije in operacije. Tu lahko pregledujemo osnovne podatke o računu (imetnik, pooblaščenec, status...), celotni Cash Management (računi, stanja, kreditne linije), pregledovanje prometa in prilivov na računu, pregledujemo nezapadle naloge in ustvarimo osebni imenik. V tem sklopu lahko pregledujemo tudi obvestila strankam, navodila in pomoč, arhiv prometa in razne šifrante (TRR, banke, države, ...). Prav tako lahko hitro in enostavno podpišemo nezapadli nalog, pregledamo posamezni nalog ali opravimo informativne izračune in pregledujemo tečajne liste. Za varnost je poskrbljeno na več ravneh. Uporablja se osebno digitalno potrdilo na pametni kartici in PIN. Med banko in stranko se vzpostavljajo varne poti z uporabo sodobnih kriptografskih rešitev. V primeru zaklepanja PIN-a (trikratni napačni vnos) se uporablja geslo za ponovno aktivacijo. Za plačilne naloge in storitve se uporablja digitalni podpis. Poslovna i-Net banka omogoča dva statusa: vnašalec in podpisnik. Vnašalec lahko vnaša in pregleduje samo »svoje« naloge, podpisnik pa je pooblaščen za avtorizacijo plačilnega prometa. Višja stopnja varnosti je kolektivno podpisovanje, kar pomeni več podpisnikov za avtorizacijo naloga. V skladu z ZEPEP se uvaja digitalni podpis, ki povečuje varnost pri podpisovanja plačilnega prometa oz. nalogov. Digitalni podpis podpira osebno digitalno potrdilo in sodobne kriptografske mehanizme. Digitalni podpis je v takem primeru potreben za avtorizacijo ali brisanje nalogov, vnašanje sprememb na plačilne naloge ali naročanje storitev. Digitalni podpis se izvede z izbiro osebnega digitalnega potrdila in vnosom PIN-a.

26

6 FUNKCIJA HADR V svetu se vse bolj uveljavljajo odprtokodne rešitve. Če so te rešitve bile še pred kratkim namenjene le računalniškim navdušencem, pa so zadnje čase vse večja alternativa licenciranim programom. Tudi največji proizvajalci računalniških tehnologij so zaznali priložnost v povezovanju svojih rešitev z sistemi kot je linux. Danes skorajda ni podatkovne baze, ki ni prirejena za delovanje tudi na linux okoljih. Ena takih je tudi DB2 proizvajalca IBM, ki v kombinaciji integrirane funkcije HADR z linuxovo funkcijo HA omogoča postavitev sistema neprekinjenega delovanja. V podjetjih, kjer se DB2 uporablja kot centralna baza podatkov, je zato odločitev za prehod iz licenciranega sistema na linux sistem toliko lažja.

6.1 Linux Začetki linux-a segajo v leto 1991, ko je v Helsinkih Linus Torvalds želel nadgraditi in razširiti verzijo minix-a (okrnjena verzija unix-a). Nekako do leta 1994 se je sistem razvijal do stabilne verzije. Jedro (kernel) sistema je napisano in distribuirano pod GNU17 licenco, kar pomeni da je ne-plačljivo. Številni navdušenci po svetu so tako razvijali svoja jedra. Danes poznamo veliko število različnih linux-ov, nekateri so se preusmerili v podjetniške sisteme (npr Red Hat, Suse,…). Vendar se tudi linux počasi komercializira. Sama jedra so sicer res ne-plačljiva, podpora, nadgrajevanje in popravki pa so ponavadi (vsaj pri večjih in resnejših sistemih) plačljivi. Razlogi, zakaj izbrati linux so sledeči (Ball 2002, 3-4):

- majhni ali nikakršni stroški nabave linux-a; - grafični vmesnik je vse bolj podoben windows-u; - linux je hiter, stabilen, nadgradljiv in robusten sistem; - deluje na različnih strojnih opremah; - skoraj za vsak tip CPU-ja obstaja verzija linux-a; - obstajajo različna razvojna orodja za integracijo z drugimi sistemi in - usmerjanje velikih proizvajalcev na linux sisteme.

Na področju šolanja upravljanja in uporabe linux-a je vse več ponudbe, prav tako se dobi podporo za različne sisteme, kar je bila še pred kratkim glavna zamera linux sistemom pri uporabi v poslovnem svetu. Prednosti, ki jih prinaša linux so (Eilert in sodelavci 2003, 3):

- polna funkcionalnost (sistemsko upravljanje, varnost); - arhitekturna neodvisnost (PC, Alpha, mainframe, izvorna koda se lahko prevaja

na različnih strojnih arhitekturah); - podpora standardom in novim tehnologijam (npr. 64-bitna tehnologija); - linux je Open Source projekt (izvirno kodo se lahko vidi in spreminja, vendar se

jo mora tako popravljeno dati nazaj v uporabo tudi drugim uporabnikom brezplačno).

17 GNU: General public licence.

27

6.2 HADR IBM-ova DB2 UDB (DB2 Universal Database) baza je zmogljiva baza podatkov namenjena velikim podatkovnim zbirkam velikih podjetij, hkrati pa dovolj fleksibilna da zadovolji potrebe tudi srednje in manjših podjetij. HADR – High Availability Disaster Recovery je integrirana, visoko razpoložljiva funkcija baze DB2, ki omogoča hiter prehod, enostavno nastavitev in upravljanje. HADR funkcija je bila razvita na Informix podatkovni bazi, kasneje pa je bila integrirana v DB2 UDB od verzije 8.2 naprej (ITtollbox 2007). Gre za par strežnikov, ki se sinhronizirata na ravni podatkovne baze (ibidem). Omogoča neprekinjeno poslovanje tako v primeru posameznega izpada, ali v kombinaciji z HA (High Availability) tudi v primeru izpada celotnega primarnega strežnika. Hadr funkcija dela po principu »log record shipping« tehnologiji, ki omogoča da so transakcije, ki so izvedene na primarni bazi podatkov uporabne tudi na bazi v pripravljenosti (repliciranje). Obstaja več načinov postavitve. Razlike so v tem ali se na uporabnikovi strani izvede prehod na sekundarno bazo, ali pa se izvede prehod na strežniku ročno ali avtomatsko s pomočjo funkcije HA. Tipičen primer postavitve HADR okolja prikazuje slika 3. V primeru izpada primarne podatkovne baze ali primarnega okolja, DB2 uporabnik preusmeri povezavo na strežnik 2 (hadrepf2). Slika 3: HADR OKOLJE

Hadrepf1Primarna baza

podatkov

Hadrepf2Sekundarna baza

podatkov v pripravljenosti

Delovna postaja 1 Delovna postaja 2

HADR

Slika 4 pa prikazuje uporabo funkcije HADR v kombinaciji z HA. HA skrbi za nadzor (Heartbeat v sodelovanju z mon programom) vseh ključnih servisov na primarnem strežniku (baza, mreža, procesi, aplikacije,…). V primeru, da pride do izpada se ti servisi aktivirajo na sekundarnem strežniku. Če se v konfiguraciji uporabi ti. VIP naslov (Virtual IP), uporabnik sploh ne zazna izpada. V nasprotnem se sicer pri prvi uporabi baze pojavi

28

opozorilo, da je povezava na primarno bazo prekinjena, da pa se nova-ekvivalentna baza nahaja na drugemu (Hadrepf2) strežniku. Priporočljivo je, da se za Heartbeat uporabi svoje ločeno omrežje (ločene mrežne kartice v svojem omrežju). Slika 4: HADR OKOLJE S FUNKCIJO HEARTBEAT

Hadrepf1Primarna baza

podatkov

Hadrepf2Sekundarna baza

podatkov v pripravljenosti

Delovna postaja 1 Delovna postaja 2

HeartBeat

HADR

6.3 Postavitev in prireditev testnega sistema Testni sistem je bil postavljen na dveh rabljenih računalnikih Pentium III z 512 MB RAM-a in 930 kHz taktom ter dvema mrežnima karticama. Za operacijski sistem je bil uporabljen Suse Linux Enterprise server 10. Sama instalacija je bila standardna, dodatno je bila narejena volume skupina za podatkovno bazo. Pri namestitvi podatkovne baze je bil uporabljen le DB2.WSE produkt (DB2 Workgroup Server Edition for Linux). Sama Linux namestitev vsebuje Heartbeat 1.2.3, vendar je bil kasneje nameščen paket HaertBeat 2.0.8. Verzija 2.0.8 je bila ob postavitvi sistema najvišja stabilna verzija Heartbeata. Slika 5 prikazuje arhitekturo sistema: imena strežnikov, IP naslovi v lokalnem omrežju in privatnem omrežju, ime DB2 instanc in baze, poti HADR in Heartbeat-a.

29

Slika 5: ARHITEKTURA TESTNEGA SISTEMA

Ethernet

Hadrepf1IP:100.100.100.1

VIP:100.100.100.5DB2 instanca: db2instp

Baza: TESTNADB

Hadrepf2IP:100.100.100.2

VIP:100.100.100.5DB2 instanca: db2insts

Baza: TESTNADB

Delovna postaja 1IP:100.100.100.3

Delovna postaja 2IP:100.100.100.4

192.168.100.1 192.168.100.2

Dedicirana mrežaza HeartBeat

Ethernet - HADR in HeartBeat

Za celovito namestitev in prireditev sistema so bile potrebne naslednje aktivnosti (Kitaura in drugi 2005, 7):

- namestitev RSH18 (omogoča izvajanje ukazov iz enega noda na drugi); - namestitev DB2 in kreiranje instanc; - postavitev HADR podatkovne baze; - namestitev in postavitev Heartbeat z IPfail opcijo; - namestitev in prireditev mon programa (nadzorovan s Heartbeatom); - prireditev HADR virov (nadzorovani z Heartbeatom); - zagon Heartbeata ter - namestitev odjemalca in testiranje.

Sama namestitev RSH-ja se je izvedla ob instalaciji sistema. DB2 je bila nameščena v svojo mapo, kreirane so bile skupine in uporabniki (imena instanc). Za instanco je bilo uporabljeno ime db2instp (db2 instanca primarna) oziroma db2insts (sekundarna). V /etc/services so bile dodane naslednje vrstice: hadrinstp 18819/tcp, hadrinsts 18820/tcp in xinstp 18817/tcp. Nato je bila ustvarjena baza TESTNADB na primarnem strežniku in z orodjem backup in restore prenesena na rezervni strežnik. V prilogi 1 so navedeni parametri, ki so bili vpisani v konfiguracijsko datoteko posamezne baze. HADR je bil zagnan na rezervni bazi z ukazom »db2 start hadr on db TESTNADB as standby« ter na primarni bazi z ukazom »db2 start hadr on db TESTNADB as primary«. Z ukazom »db2 get snapshot for all on TESTNADB« preverimo v kakšnem statusu sta bazi (priloga 2).

18 RSH: Remote shell utility.

30

Heartbeat je ena ključnih komponent Linux-HA (High-Availabilty Linux)19 projekta. Program lahko zazna izpade vozlišč ali virov, komunikacij ali pa se ga lahko uporablja kot upravljalnik gruč. Heartbeat je bil nameščen posebej (verzija 2.0.8). Za pravilno delovanje potrebuje še knjižnico libnet, ki pa je bila nameščena že pri namestitvi samega sistema. Pri konfiguraciji Heartbeata so pomembne tri datoteke (priloga 3): authkeys (šifrirani ključ), ha.cf (časovni parametri, imena ali naslovi strežnikov, vrata) in haresources (navede se ime strežnika, VIP naslov, mon in ime skripte, ki jo bo izvedel mon). Zelo pomembna je datoteka ha.cf, kjer so navedeni strežniki, ki so postavljeni v gručo, ter mrežne kartice, skozi katere se strežniki sporazumevajo z Heartbeatom. Priporočljivo je imeti dve taki poti (po lokalnem omrežju in po privatnem omrežju). Če je definirana samo ena pot lahko pride do problemov, saj je lahko primarna stran aktivna in do nje dostopajo uporabniki, hkrati pa se aktivira še rezervna stran, do katere lahko tudi dostopajo uporabniki. Problem nastane zaradi tega, ker sta obe bazi podatkov (primarna in rezervna) v določenem trenutku aktivni in se zato tudi spreminjata, kar privede do nekonsistentnosti baze in izgube podatkov. Rešitev je funkcija IPfail za Heartbeat, ki uporablja ping na določen naslov v omrežju (v praksi je to gateway). Zagon Heartbeat funkcije se izvede z ukazom »heartbeat start«. Sam uporabljeni Heartbeat sicer lahko nadzira tudi servise (poleg virov), vendar je grafični vmesnik za oblikovanje nadzora nekoliko okoren in vsebuje še vedno nekaj napak. Zato je bil za celovito delovanje uporabljen mon, ki lahko nadzira in izvaja akcije tudi nad servisi. Deluje kot vir, ki ga nadzira Heartbeat. Mon paket je bil nameščen is spletne strani ftp://ftp.kernel.org/pub/software/admin/mon/. Za svoje pravilno delovanje potrebuje še nekatere Pearl-ove programe (Time::Period, Time::HIRes, Convert::BER in Mon::*), ki pa jih je treba posebej prevajati (make install). Konfiguracijska datoteka mon.cf ima navedene skupine nadzorov določenih servisov s časovnimi intervali. V teh skupinah sta tudi navedeni skripti, ki se zaženeta za nadzor servisa oziroma v primeru izpada (priloga 4). Vsak nadzirani servis oz. vir (lokalna db2 instanca, rezervna db2 instanca, HADR par, mrežni priključek) je definiran v svoji skupini, kjer se zaganjajo skripte prirejene tem virom. Pri zagonu Heartbeata je zelo pomembna datoteka haresources. Ta namreč pove na katerem strežniku (v praksi je to lokalni) se zaganja Heartbeat, aktivira VIP naslov ter zažene mon servis s parametri iz datoteke Hadr. Pri zaustavljanju se najprej zaustavi mon, sprosti vire, deaktivira VIP naslov in nato zaustavi Heartbeat. Zelo pomembno je, da je sam Heartbeat aktiven na obeh straneh, mon servis pa samo na trenutno aktivni strani. Šele ko se na primarni strani mon zaustavi, Heartbeat to sporoči rezervni strani, kjer se zažene mon in začne upravljati z definiranimi servisi oz. viri. Kot uporabnik (client) podatkovne baze je bil na delovni postaji (windows okolje) nameščen kar DB2 Control center (DB2 Administration Tools Environment). Orodje je napisano v programskem jeziku java in služi za celotni nadzor in upravljanje podatkovne zbirke DB2. Z njim se lahko upravlja več instanc na istem ali različnih strežnikih po različnih protokolih (TCP/IP, APPC, APPN, NPIPE ali lokalno). Z orodjem se lahko ustvari ali upravlja tudi z HADR pari. Iz slike 6 je razvidno, da so bile narejene 3 povezave s protokolom TCP/IP: na primarni strežnik, na sekundarni strežnik in na VIP naslov (hadrfloat). Prve dve povezavi so se uporabljale za upravljanje baze (upravljanje HADR,

19 Vir: http:// www.linux-ha.org/Heartbeat.

31

ustvarjanje tabel in vnos podatkov,…) ter testiranje vpliva izpadov na uporabnika pri uporabi statičnega IP naslova. Zadnja je bila namenjena testiranju vpliva izpadov na uporabnika pri uporabi navideznega IP naslova, kar je tudi realna opcija postavitve produkcijskega okolja. Povezava na strežnik hadrepf2 je bila vzpostavljena samo za namen grafičnega nadzora HADR funkcije, saj sama DB2 baza ne dovoli dostopa do podatkov, če je ta baza v stanju HADR pripravljenosti (standby). Slika 6: DB2 CONTROL CENTER

6.4 Poročilo o izvedenih testih in predlog uporabe Testiranje pravilnosti delovanja funkcije in postavitve sistema je potekalo od 18 do 20 junija 2007. Testiralo se je delovanje uporabnika oz. dostop do baze podatkov tako čez VIP naslov, kakor tudi neposredno čez fizični IP naslov primarnega in/ali sekundarnega strežnika. Pri vseh izpadih so bili spremljani tudi logi na strežnikih (/var/log/messages) ali pa so bili izpisani statusi baze podatkov. Pred vsakim testom je bilo vzpostavljeno začetno stanje baz podatkov. Izvedeni so bili naslednji testi: a) nadziran prehod primarne baze na sekundarno lokacijo (controlled failover test):

- Status baz pred izvedbo testa:

HADR status Primarna baza Nadomestna baza Vloga Primary Standby Status Peer Peer Sinhronizacijski mod Nearsync Nearsync Status povezave Povezana Povezana

32

Test se je izvedel z zaustavitvijo Heartbeat servisa (heartbeat stop) na primarnem strežniku.

- Status baz po izvedbi testa:

Izidi: Heartbeat se je uspešno zaustavil. Mon servis se je uspešno zagnal na rezervnem strežniku. Status baze na rezervnem strežniku je bil pravilen. Čas preklopa baze je bil 5 sec. Uporabnik vezan na statični IP naslov je zaznal izpad, vendar je bil preusmerjen na drugi strežnik. Uporabnik vezan na VIP naslov ni zaznal izpada. Podatki v bazi so bili pravilni. Vsi dogodki so se beležili v log datoteke. Zaključek: test je bil uspešen, funkcija je delovala pravilno. b) test izpada instance na primarnem strežniku Test je bil izveden z ukazom »su – db2instp –c “ db2_kill”« na primarnem strežnik. S tem je bila zaustavljena primarna baza podatkov. Izidi: vloge so ostale nespremenjene. Po 10 sec se je ponovno vzpostavila primarna baza podatkov. Uporabnik je zaznal izpad v intervalu cca 10 sec. Zaključek: test je bil uspešen, funkcija je delovala pravilno. c) test izpada instance na rezervnem strežniku Test je bil izveden z ukazom »su – db2insts –c “ db2_kill”« na rezervnem strežnik. S tem je bila zaustavljena rezervna baza podatkov. Izidi: vloge so ostale nespremenjene. Po 30 sec se je ponovno vzpostavila rezervna baza podatkov ter prešla v Peer status. Uporabnik ni zaznal izpada. Zaključek: test je bil uspešen, funkcija je delovala pravilno. d) test izpada strežnika Test je bil izveden z ukazom »shutdown –Fr now« na primarnem strežniku. S tem se je strežnik zaustavil in ponovno zagnal. Izidi: mon servis se je uspešno zagnal na rezervnem strežniku (hadrepf2). Rezervni strežnik je prevzel vlogo primarnega. Status baze na rezervnem strežniku je bil pravilen. Čas preklopa baze je bil 5 sec. Uporabnik vezan na statični IP naslov je zaznal izpad, vendar je bil preusmerjen na drugi strežnik. Uporabnik vezan na VIP naslov ni zaznal

HADR status Primarna baza Nadomestna baza Vloga - Primary Status - Nepovezana Sinhronizacijski mod - Nearsync Status povezave - Nepovezana

33

izpada. Podatki v bazi so bili pravilni. Zaradi varnostnih razlogov se HADR funkcija sama ne aktivira pri zagonu strežnika. Ko je bil strežnik hadrepf1 aktiven, je prevzel vlogo rezervnega strežnika. HADR funkcija je bila zagnana ročno s parametrom statusa baze standby. Ponovni zagon heartbeat funkcije in zaustavitvijo le-te na trenutno primarnem (hadrepf2) strežniku, je povzročilo vrnitev v prvotno stanje (primarni strežnik=hadrepf1, rezervni strežnik=hadrepf2). Zaključek: test je bil uspešen, funkcija je delovala pravilno. e) test izpada mrežnega priključka na primarnem strežniku: Test je bil izveden z prekinitvijo mrežne povezave (izvlečen kabel) na primarnem strežniku. Izidi: mon servis se je uspešno zagnal na rezervnem strežniku (hadrepf2). Rezervni strežnik je prevzel vlogo primarnega. Status baze na rezervnem strežniku je bil pravilen. Čas preklopa baze je bil 5 sec. Uporabnik vezan na statični IP naslov je zaznal izpad, vendar je bil preusmerjen na drugi strežnik. Uporabnik vezan na VIP naslov ni zaznal izpada. Podatki v bazi so bili pravilni. Zaključek: test je bil uspešen, funkcija je delovala pravilno. f) test izpada privatnega mrežnega priključka na primarnem strežniku: Test je bil izveden z prekinitvijo privatne mrežne povezave (izvlečen kabel) na primarnem strežniku. Izidi: ni prišlo do sprememb in prevzemanja vlog. V log datotekah je bil zabeležen izpad. Zaključek: test je bil uspešen, funkcija je delovala pravilno. g) test izpada obeh mrežnih priključkov na primarnem strežniku: Test je bil izveden s prekinitvijo obeh omrežnih povezav (izvlečena oba kabla) na primarnem strežniku. Izidi: V obeh primerih povezave je bil zaznan izpad na strani uporabnika v časovnem intervalu cca 30 sec. Na primarnem strežniku je mon servis zaznal izpad priključkov in po cca 20 sec sprožil zaustavitev baze podatkov (zabeleženo v log datoteki). Zaključek: test delno uspešen. Zaradi časovne zakasnitve je izpad zaznal tudi uporabnik, vezan na VIP naslov. Prav tako je bil predolg čas preklopa rezervne baze v status primarne. h) test izpada obeh omrežnih priključkov na rezervnem strežniku: Test je bil izveden z prekinitvijo obeh omrežnih povezav (izvlečena oba kabla) na rezervnem strežniku.

34

Izidi: izpada za uporabnike ni bilo. V log datotekah so bili zabeleženi vsi dogodki. Na rezervnem strežniku se je zagnal mon, ki je ugotovil napake na priključkih in zato zaustavil rezervno bazo podatkov. Zaključek: test je bil uspešen, funkcija je delovala pravilno. Predlog uporabe: s testiranjem različnih izpadov se je potrdilo pričakovano delovanje funkcije HADR in Heartbeat-a. Funkcija se je pokazala zelo primerna pri vseh testiranih scenarijih razen pri izpadu obeh omrežnih priključkov, kjer pa gre samo za časovno zakasnitev. To je problem prehoda s funkcijo Heartbeata in mon servisa. Sama HADR funkcija pa je v vseh scenarijih poskrbela za ažurno in pravilno vsebino baze podatkov. Zato se funkcija zdi primerna za zagotavljanje neprekinjenega poslovanja in okrevalnega načrta ter se jo priporoča pri postavitvi vseh DB2 podatkovnih baz v podjetju. V sklopu tega se priporoča tudi prehod strežniških sistemov, na katerih so nameščene podatkovne zbirke DB2, na linux okolja. S takim prehodom se lahko konsolidira strežniška arhitektura, saj se lahko navedena funkcija uporablja z večjim številom strežnikov. V tem primeru potrebujemo en rezervni strežnik z več instancami DB2 baze podatkov na katerega se veže več primarnih strežnikov z različnimi DB2 bazami podatkov. Seveda pa je potrebno pri prehodu na tak sistem definirati in organizirati nadzor sistema in sistem obveščanja (SMS, elektronska pošta) za pravilno in pravočasno odzivanje na morebitne izpade.

6.5 Predvideno produkcijsko okolje Ker so se testi funkcije HADR pokazali kot dobra rešitev, se predlaga prehod take rešitve v produkcijsko okolje. Rešitev se lahko uporabi za vse različne baze DB2 v banki. Možnosti postavitve so sledeče: a) za zelo intenzivne I/O podatkovne baze (med katere se spada tudi baza internetnega bančništva) se predlaga postavitev samostojnih strežnikov. Ker aplikacija internetnega bančništva dela po principu 24x7 se predlaga postavitev strojno popolnoma enakega para strežnikov. Za večjo zaščito, zanesljivost in razpoložljivost v primeru katastrof, se priporoča uporabo zunanjih diskovnih kapacitet (SAN) na dveh lokacijah. Prav tako mora biti rezervni strežnik postavljen na oddaljeni lokaciji (priporočljivo najmanj 30 km). Tako postavitev prikazuje slika 7. b) za manj intenzivne baze podatkov se priporoča virtaulizacijo z uporabo ESX strežnika ali Xen-a. Za take baze se priporoča konsolidacijo z uporabo enega rezervnega strežnika za več primarnih baz podatkov. Glede na določene prioritete in I/O intenzivnosti, se primarne strežnike razvrsti v skupine z enim I/O bolj intenzivnem in 3-4 manj I/O intenzivnimi strežniki. Zaradi centraliziranega upravljanja se prav tako priporoča uporabo zunanjih diskovnih kapacitet.

35

Slika 7: PREDLOG POSTAVITVE PRODUKCIJSKEGA OKOLJA

Primarni strežnik Rezervni strežnik

Stikalo Stikalo

Stikalo Stikalo

Disaster Recovery CenterProdukcijsko okolje Dodeljeno / privatno omrežje

Zunanje diskovnekapacitete

Zunanje diskovnekapacitete

Ethernet LAN

Priporočljiva razdalja 30 km.Povezava z optičnimi kabli.

36

7 SKLEP Podjetja se vse bolj zavedajo pomembnosti varovanja podatkov. Izguba podatkov, razkritje podatkov ali samo časovni zamiki uporabe podatkov ali informacij, imajo lahko na podjetje ali banko velike finančne in/ali nefinančne posledice. V poslovnem svetu je tehničnih rešitev za take probleme veliko, od podjetja ali banke pa je odvisno kakšne rešitve bo uporabilo in na kakšen način bo te rešitve integriralo v svoje poslovanje. Ena od takšnih rešitev je tudi HADR funkcija podatkovne baze DB2 proizvajalca IBM. Funkcija v povezavi z linux HA projektom nudi resnično dobro izbiro pri zagotavljanju neprekinjenega poslovanja in varovanja podatkov. Seveda obstajajo tudi druge, mogoče uporabniku prijaznejše rešitve. Dejstvo je, da je v svetu linux-a še vedno pomembno navdušenje posameznikov, kar pomeni več samostojnega dela pri uporabi takega sistema. Vendar so take rešitve ponavadi cenejše in bolj prirejene posamezni ali sklopu specifičnih zahtev. Seveda igra pri postavitvi sistema varovanja podatkov in neprekinjenega poslovanja veliko vlogo organizacijska struktura, predvideni stroški in predvsem kritična ocena znotraj podjetja o prioritetah, občutljivosti in pomembnosti posameznih sistemov. Z upoštevanjem nekaterih standardov, dobre prakse in izkušenj drugih lahko postavimo sistem prilagojen našim zahtevam in pričakovanjem. Kakorkoli – informacija oz. podatek je danes pomembna »surovina« poslovanja. Tako surovino moramo zaščitit in jo hkrati imeti vedno in dovolj na razpolago. Podjetje ali banka, ki se tega zaveda brez prisile zakonskih ali drugih zahtev ima nedvomno prednost pred tistimi, ki take sisteme postavljajo samo zaradi zahtev. Te zahteve ponavadi pogojujejo samo tehnične rešitve, celotni sistem varovanja podatkov in neprekinjenega poslovanja pa zajema celoto delovanja - od strateških odločitev pa vse do operativnega dela. Gre za usmeritve in cilje podjetja, za organizacijske in finančne prijeme, kadrovanje in predvsem sodelovanje tako po vertikalni kakor po horizontalni ravni. Postavitev in uporaba takšnega sistema zahteva celovito delo ekipe in ne le posameznikov. Vse večji zahtevki po zniževanju stroškov ne smejo pomeniti zmanjševanja varnosti in kakovosti rešitev. V nobenem primeru ne sme biti cena odločilen dejavnik pri nakupu rešitev za neprekinjeno delovanje in varovanje podatkov. Odločitev mora sloneti na pomembnosti aplikacij in podatkov, ki se bodo na teh sistemih pretakali. Cene visoko razpoložljivih (high-end) rešitev so resda za marsikatero podjetje nedosegljiva, vendar pa opažam velikokrat pomanjkanje analiz tveganja, ki bi upravičila ali zavrnila nakup take rešitve. Seveda je z upravljalskega vidika, pa tudi z vidika varnosti in neprekinjenega poslovanja taka rešitev idealna, vendar za lastnika draga. Alternativa licenciranim programom in visoko razpoložljivih sistemov so odprtokodni sistemi in njihove rešitve ter srednje razpoložljivi sistemi (mid-range). S pravilno uporabo teh sistemov lahko tudi dosežemo visoko razpoložljivost. Vendar je v tem primeru potrebno večje angažiranje človeških potencialov, potrebna je njihova iznajdljivost in zagnanost. Pri uvajanju takih sistemov je zelo pomembna podpora in zaupanje vodstvenega kadra. Pri prehodu je potrebno upoštevati znanje upravljanja takih sistemov in možnost vključevanja v obstoječe sisteme. V poslovnem svetu se opaža vse večji poudarek prav na teh rešitvah, zato menim, da so primerne tudi za naša podjetja in banke. Glede na razširjenost podatkovne baze DB2

37

in opravljene teste menim, da je prehod baze na linux okolja in upravljanje s funkcijo HADR in HA pravilna odločitev in alternativa obstoječim sistemom. Sklep lahko zaključim s trditvijo, da so odprtokodni sistemi dobra rešitev, vendar samo, če slonijo na predhodni analizi in se lahko vključujejo v obstoječe sisteme. Podjetje ali banka mora razpolagati s človeškimi viri, ki lahko take sisteme upravljajo in nadzirajo. Sam prehod ali nove postavitve morajo biti podprte z obsežnimi testiranji, v katere so vključeni tudi končni uporabniki podatkov in informacij.

38

POVZETEK / ABSTRACT V poslovnem svetu imajo informacije vse večjo težo in veljavo. Prav zato morajo podjetja posvečati veliko pozornost varovanju podatkov. Pri zahtevah 24x7 (kamor spada tudi e-bančništvo) pa morajo posvetiti tudi pozornost na neprekinjeno poslovanje. Za celovito rešitev varovanja in neprekinjenega poslovanja se uvajajo Disaster recovery centri. Načrti, potrebne akcije in odgovornosti pa so zapisane v Disaster recovery planih. Ob vsem tem pa se podjetja in banke soočajo z zmanjševanjem stroškov. Alternative licenciranim programom so zato odprtokodne rešitve, kot je linux. Linuxov HA projekt in DB2 funkcija HADR lahko pri pravilni postavitvi predstavljata rešitev, ki zagotavlja neprekinjeno poslovanje zaradi različnih incidentov. In business information has been gaining importance and value. That is why firms ought to devote a great deal of attention to data protection. In 24x7 demands (that include e-banking) attention has to be paid to constant, uninterrupted operations. In order to secure a complete protection of uninterrupted operations Disaster Recovery Centers are being introduced where Disaster Recovery Plans define plans, actions and responsibilities. Firms deal with cost reduction as well, thus open sources solutions such as linux can be used as alternative to licenced programs. Properly installed linux HA project with HADR function of DB2 databases is a cost-free solution that guarantees uninterrupted operations despite various incidents.

KLJUČNE BESEDE / KEY WORDS e-Bančništvo / e-Banking e-Poslovanje / e-Business DB2 UDB – DB2 Universal database Rezervni računalniški center / DRC – Disaster Recovery Center Načrt okrevanja po katastrofi / DRP – Disaster Recovery Plan Linux-ov projekt visoke razpoložljivosti / HA - Linux High Availability project HADR – High Availability Disaster Recovery Heartbeat i-Net Banka Internet Linux

39

SEZNAM UPORABLJENIH KRATIC AAA – Authentication, Authorization and Accounting – nadzor prijave ADSL – Asymmetric Digital Subscriber – izvedenka xDSL APPC – Advanced Program to Program Communication – protokol za komunikacijo med računalniki po omrežju na aplikacijski ravni ATM – Asynchronous Transfer Mode – asinhroni telekomunikacijski protokol B2B – Business-to-Business – elektronsko poslovanje med podjetji B2C – Business-to-Consumer – elektronsko poslovanje med podjetjem in uporabnikom GNU – General Public License – sistem prostega programja GPRS – General Packet Radio Service – mobilna podatkovna storitev HADR - High Availability Disaster Recovery – visoko razpoložljivi sistem za okrevanje po katastrofi HDSL - High bit rate Digital Subscriber line – izvedenka xDSL HTML - Hypertext Markup Language – jezik za izdelavo spletnih strani HTTP Hypertext Transfer Protocol – komunikacijski protokol za prenos informacij po spletu (WWW) HTTPS – HTPP, ki uporablja SSL za kodiranje (varnost) Linux HA - Liunux Haigh Availability projekt – projekt visoke razpoložljivosti NPIPE – Named Pipe – enosmerna tehnika pretakanja informacij od enega k drugemu procesu PIN – Personal Identification number – osebna identifikacijska številka PPRC – Peer-to-Peer remote copy – protokol za neprestano kopiranje podatkov na oddaljeno lokacijo SAN – Storage area Network – arhitektura povezave strežnikov na oddaljene diskovne kapacitete, knjižnice ali optične jukebox-e SNA - Systems Network Architecture – IBM-ova mrežna arhitektura SSL – Secure Sockets Layer – mrežni protokol za kriptografiranje TCP/IP - Transmission Control Protocol /Internet Protocol – protokol za nadzor prenosa/ internetni protokol UDSL – Unidirectional DSL – izvedenka xDSL UMTS – Universale Mobile Telecommunication System – sestavni del tretje generacije mobilnih sistemov URL - Ubiform Resource Locator – naslov spletnih strani v spletu VDSL – Very-high-bit-rate DSL – izvedenka xDSL VIP – Virtal IP – navidezni IP naslov VPN – Virtual Private Network – navidezno privatno omrežje WWW World Wide Web – svetovni splet xDSL – Digital Subscriber line – tehnologija prenosa digitalnih podatkov po telefonski liniji

40

VIRI

1. Bank for International Settlements http://www.bis.org/publ/bcbs98.pdf [20.5.2007] 2. Banka Koper d.d. http://www.banka-koper.si [30.4.2007] 3. Ball, Bill s soavtorji. 2002. Red Hat Linux 7.2 Unleashed. Indianapolis: SAMS. 4. Bloomsbury Publishing PLC. A Bloomsbury reference book. 2002. Business the

Ultimate resource. 5. Bučar, Maja. 2002. Informacijska tehnologija kot razvojna priložnost za Slovenijo.

Naše gospodarstvo 1-2: 1-9. 6. Egan, Mark in Tim Mather. Prevajalec: Bedrač, Milan. 2005. Varovanje informacij:

grožnje, izzivi in rešitve: vodnik za podjetja. Ljubljana: Pasadena. 7. Eilert, John s soavtorji. 2003.Linux on the Mainframe. New Jersey: Prentice Hall. 8. Example Essays http://www.exampleessays.com [30.4.2007] 9. FFIEC – Federal Financial Institutions Examination Cuncil. 2003. E-Banking - IT

Examination Handbook. 10. Federal Financial Institutions Examination Council http://www.ffiec.gov/ffiecinfob

ase/html_pages/bcp_book_frame.htm [25.5.2007] 11. Greenstaein, Marilyn Ph.D., and Todd M. Feinman. 2000. Electronic commerce :

Security, Risk Management and Control. Boston: The McGraw-Hill Companies, Inc.

12. Halsall, Fred. 2001. Multimedia communications – Applications, Networks, protocols and Standards. Harlow: Person Education Limited.

13. IBM – International Business Machines. International Technical Support Organization. 2005. IBM TotalStorage Business Continuity Solutions Overview.

14. ITtoolbox http://blogs.ittoolbox.com/database/technology/archives/is-hadr-hard-49 42 [10.5.2007]

15. Jerman – Blažič, Borka s soavtorji. 2001. Elektronsko poslovanje na internetu. Ljubljana: GV založba.

16. Kitaura, Mary Lynn, M. Ng, S. Raspudic, A. Subramanian, J. Yang. 2005. Automating DB2 Universal Database (DB2 UDB) HADR Failover using Heartbeat for Linux. Toronto: IBM Toronto Software Lab.

17. Korper, Steffano in Juanita Ellis. 2000. The E-commerce book - Building the e-empire. San Diego: Academic press.

18. Nova Kreditna banka Maribor d.d. http://www.nkbm.si [30.4.2007] 19. Nova Ljubljanska banka d.d. http://www.nlb.si [30.4.2007] 20. Pavliha, Marko, in Borka Jerman Blažič s soavtorji. 2002. Zakon o elktronskem

poslovanju in elektronskem podpisom s komentarjem. Ljubljana: GV Založba. 21. Perenič, Gorazd, in Brane Šalamon. 2002. Pojdite varno v svet. Ljubljana: Perenič

svetovanje d.o.o. 22. Raba Interneta v Sloveniji. http://www.ris.org/ [20.6.2007] 23. Register predpisov RS. http://zakonodaja.gov.si/ [20.5.2007] 24. Sichyikul, Vatcharaporn in Sivaporn Chavananon. 2001. Electronic Commerce and

Electronic Business Implementation Success Factor. V e-Everything: e-Commerce, e-Government, e-household, e-Democracy Volume 1, urednik B. O'Keefe in drugi. Kranj: Moderna organizacija.

25. SKB Banka d.d. http://www.skb.si [30.4.2007]

41

26. Sturges, Paul. 2002. Public internet access in libraries and information services. London: Facet Publishing.

27. Sušnik, Matjaž. 2007. Specializirani ali vsestranski? Sistem. Maj 2007: 1. 28. Toplišek, Janez. 1998. Elektronsko poslovanje. Ljubljana: Založba Atlantis. 29. Urad RS za standardizacijo in meroslovje pri Ministrstvu za znanost in tehnologijo.

1997. Slovenski standard PSIST BS 7799 Kodeks varovanja informacij. 30. Vehovar, Vasja. 2007. Internetu se napoveduje cvetoča prihodnost. Moje Finance,

marec 2007:14-17.

42

PRILOGE Priloga 1: PARAMETRI PODATKOVNE BAZE a) parametri na obeh bazah DB2COMM=tcpip dbm.cfg datoteka: SVCENAME xinstp b) parametri na primarni bazi (db.cfg datoteka baze TESTNADB) HADR_LOCAL_HOST 100.100.100.1 HADR_REMOTE_HOST 100.100.100.2 HADR_LOCAL_SVC 18819 HADR_REMOTE_SVC 18820 HADR_REMOTE_INST db2insts c) parametri na rezervni bazi (db.cfg datoteka baze TESTNADB) HADR_LOCAL_HOST 100.100.100.2 HADR_REMOTE_HOST 100.100.100.1 HADR_LOCAL_SVC 18820 HADR_REMOTE_SVC 18819 HADR_REMOTE_INST db2instp

43

Priloga 2: PREVERJANJE STATUSA BAZE a) status primarne baze HADR Status Role = Primary State = Peer Synchronization mode = Nearsync Connection status = Connected, 27.06.2007 09:02:03.865995 Heartbeats missed = 0 Local host = 100.100.100.1 Local service = 18819 Remote host = 100.100.100.2 Remote service = 18820 Remote instance = db2insts timeout(seconds) = 120 Primary log position(file, page, LSN) = S0000013.LOG, 385, 00000000040010FC Standby log position(file, page, LSN) = S0000013.LOG, 385, 00000000040010FC Log gap running average(bytes) = 0 b) status nadomestne baze HADR Status Role = Standby State = Peer Synchronization mode = Nearsync Connection status = Connected, 27.06.2007 09:05:10.018948 Heartbeats missed = 0 Local host = 100.100.100.2 Local service = 18820 Remote host = 100.100.100.1 Remote service = 18819 Remote instance = db2instp timeout(seconds) = 120 Primary log position(file, page, LSN) = S0000013.LOG, 385, 00000000040010FC Standby log position(file, page, LSN) = S0000013.LOG, 385, 00000000040010FC Log gap running average(bytes) = 0

44

Priloga 3: HA DATOTEKE a) datoteka authkeys #3 md5 Hello! auth 1 1 md5 123456hadr789 b) datoteka ha.cf # File to write debug messages to debugfile /var/log/ha-debug # File to write other messages to logfile /var/log/ha-log # Facility to use for syslog()/logger logfacility local0 # keepalive: how long between Heartbeats? keepalive 2 # deadtime 5 # warntime: how long before issuing "late Heartbeat" warning? # See the FAQ for how to use warntime to tune deadtime. warntime 10 # Very first dead time (initdead) initdead 120 # What UDP port to use for bcast/ucast communication? udpport 694 # (note: auto_failback can be any boolean or "legacy") auto_failback off bcast eth1 bcast eth0 node hadrepf2 node hadrepf1 #respawn userid /path/name/to/run respawn hacluster /usr/lib/Heartbeat/ipfail c) datoteka haresources # #node-name resource1 resource2 ... resourceN hadrepf1 100.100.100.5 mon Hadr #

45

Priloga 4: MON SKRIPTE a) skripta HADR #!/bin/ksh # Definira temp datoteko temp_stat_file=/Heartbeat/scriptTemp.stat #Ustvari temp datoteko touch $temp_stat_file > /dev/null 2> /dev/null chmod a+w $temp_stat_file > /dev/null 2> /dev/null # DB2HADRDBNAME=TESTNADB # Ime lokalne instance tempHost=$(echo $HOSTNAME) case $tempHost in hadrepf1) DB2INST=db2instp;; hadrepf2) DB2INST=db2insts;; esac # Bere argumente case "$1" in # Argument = "start", poglej HADR vlogo na tej strani, # Vloga = standby, naredi “HADR takeover “; # če takeover ni uspešen, naredi “takeover by force”. start) hadrRole=$(su - $DB2INST -c "db2 get snapshot for all on $DB2HADRDBNAME" |grep -i "Role" |awk '{print $3 }') if [[ $hadrRole = "Standby" ]]; then logger -i -p notice -t $0 "su - $DB2INST -c db2 takeover hadr on db $DB2HADRDBNAME" su - $DB2INST -c "db2 takeover hadr on db $DB2HADRDBNAME" > /dev/null if [[ $? = "0" ]]; then logger -i -p info -t $0 "Info: db2 takeover succeed " else logger -i -p notice -t $0 "su - $DB2INST -c db2 takeover hadr on db $DB2HADRDBNAME by force" su - $DB2INST -c "db2 takeover hadr on db $DB2HADRDBNAME by force" > /dev/null if [[ $? = "0" ]]; then logger -i -p notice -t $0 "Notice: Takeover by force je uspesen" else logger -i -p err -t $0 "ERROR: Takeover by force je neuspesen" fi

46

fi # HADR vloga = primary, ne naredi takeover. else logger -i -p notice -t $0 "Notice: Primarna DBFC je zagnana na tej strani" fi;; # Argument = "stop", ne naredi ničesar. stop) logger -i -p notice -t $0 "Notice: stop Heartbeat";; # Argument = "status", pokaži uporabniku # Heartbeat informacijo na tej strani. status) logger -i -p notice -t $0 "Notice: get $DB2HADRDBNAME status....." echo "----------------------------------" >> $temp_stat_file # Če je mon pid aktiven na tej strani, pomeni da so vsi Heartbeat # viri aktivni na tej strani; če ne, so vsi # viri aktivni na drugi strani if [[ -f /etc/ha.d/mon.pid ]]; then echo " Heartbeat viri tečejo na tej strani " >> $temp_stat_file else echo " Heartbeat viri tečejo na drugi strani" >> $temp_stat_file fi echo "----------------------------------" >> $temp_stat_file echo $HOSTNAME >> $temp_stat_file echo "" >> $temp_stat_file # HADR informacije na tej strani su - $DB2INST -c "db2 get snapshot for all on DBFC" |grep - A14 "HADR Status" >> $temp_stat_file # Pokaži vse informacije cat $temp_stat_file 1>&2 rm -f $temp_stat_file;; esac exit 0 b) del konfiguracijske datoteke mon.cf # splošni parametri cfbasedir = /etc/ha.d/mon-0.99.2 alertdir = /etc/ha.d/mon-0.99.2/alert.d mondir = /etc/ha.d/mon-0.99.2/mon.d maxprocs = 20 histlength = 100 randstart = 60s

47

# tip avtentikacije: authtype = getpwnam # hostgroup serversbd1 dns-yp1 foo1 bar1 hostgroup db2_inst hadrepf1 hostgroup db2_inst_remote hadrepf1 hostgroup hadr_stat hadrepf1 hostgroup gateway 100.100.100.24 192.168.200.2 # nadzor virov # Vir 1: lokalna db2 instanca watch db2_inst service db2inst interval 10s monitor db2_inst.monitor allow_empty_group period wd {Mon-Sun} alert db2inst_down.alert alertevery 600s alertafter 2 # Vir 2: rezervna db2 instanca . . . c) skripta db2_inst.monitor # Skripta monitorira lokalno DB2 instanco #!/bin/ksh # DB2HADRDBNAME=TESTNADB # Dobi ime lokalne instance tempHost=$(echo $HOSTNAME) case $tempHost in hadrepf1) DB2INST=db2instp;; hadrepf2) DB2INST=db2insts;; esac # Pregleda ali je lokalna instanca aktivna; return = 0 če je aktivna # Return = 1 če je instanca neaktivna INSTUP=$(su - $DB2INST -c "db2pd -inst" |grep -i "Database Partition" |grep -c "Active") if [ $INSTUP -eq 0 ] then logger -i -p error -t $0 "ERROR: DB2 INSTANCA $DB2INST JE DOL" exit 1 else logger -i -p info -t $0 "INFO: DB2 INSTANCA $DB2INST JE GOR"

48

exit 0 fi d) skripta db2inst_down.alert #!/bin/ksh # Skripta poskuša narediti restart lokalne DB2 instance če je ta dol # DB2HADRDBNAME=TESTNADB # Dobi ime lokalne instance tempHost=$(echo $HOSTNAME) case $tempHost in hadrepf1) DB2INST=db2instp;; hadrepf2) DB2INST=db2insts;; esac logger -i -p notice -t $0 "NOTICE: POSKUŠAM ZAGNATI INSTANCO" # Restart the DB2 instance su - $DB2INST -c "db2start" if [[ $? = "0" ]]; then logger -i -p info -t $0 "INFO: DB2 INSTANCA SE BO ZAGNALA" su - $DB2INST -c "db2 activate db $DB2HADRDBNAME" else logger -i -p ERROR -t $0 "ERROR: DB2 INSTANCA SE NE MORE ZAGNATI" fi