4. ANDMEBAASIDE TURVAMINE

4.1. Andmebaasid turvamise olemus

Olulisimaks teemaks andmebaaside administreerimisel on andmete turvamine – tuleb tagada, et andmed säiliks, et nad oleksid usaldatavad (õiged) ja et nad oleks kaitstud volitamata kasutamise vastu. Kui need kolm asuja on andmebaaside administreerimise käigus lahendamata muutuvad kõik teised administreerimistoimingud mõttetuks. Samuti muutub mõttetuks kogu seliste andmebaaside kasutamine üldse. Seda selle pärast, et meil on andmed ainult näiliselt olemas ja nende kadu on lihtsalt aja küsimus. Kui parafraseerida Jaapani sõjakunsti käsiraamatut, mis ütleb (see ütlus käib kannatlikkuse kohta) „kui istuda piisavalt kaua jõe ääres, siis ujub lõpuks mööda sinu vaenlase laip“ siis võib rakendamata turbemehhanismiga andmebaaside kohta öelda „kui oodata piisavalt kaua, siis hävinevad andmed lõpuks igas andmebaasis, kus andmeturbe meetmed on rakendamata“. Loomulikult ei ole ka korrektsete andmeturbe meetmetega andmebaasides see oht, et nad riknevad, täielikult kõrvaldatud ja eelnevalt parafraseeritud lauset võik siin kohal parafraseerida natuke teisiti:„kui oodata piisavalt kaua, siis rikneb lõpuks iga andmebaas“. Siin ei saa me aga aga rääkida kuidagi andmete hävinemisest. Seda selle pärast, et korrektselt rakendatud turvameetmetega andmebaasi riknemisel on seal olnud andmed võimalik taastada. See tähendab seda, et riknes küll konkreetne andmebaasi eksemplar (koopia), kuid meie käsutuses on, tänu läbi viidud turvameetmetele, vahendid, mis võimaldavad üles ehitada uue korrektse andmebaasi ja jätkata tööd sealt, kust see pooleli jäi.

Andmebaaside turvamise tähtsus

Loomulikult on „100%-lise efektiivsusega“ andmeturve väga kallis. On kohti kus seda peab rakendama „täie võimsusega“. Samas on aga kohti, kus sõltuvalt tööprotsessi ja andmete iseloomust võib rakendada andmeturbe oluliselt nõrgemat taset. Seejuures on kõikidel juhtudel eesmärgiks tagada tööprotsessi võimalikult väike häirimine, andmete säilimine ja andmete usaldatavus (õigsus). Peamine millega erinevate „võimsustega“ andmeturbe protsesside ja meetodite kehtestamisel „mängida“ saab ongi tööprotsessi normaalse toimimise häirimise tase – andmeturbe protsess peab olema üles ehitatud nii, et andmed ei hävineks ja nende usaldusväärsuse ei kaoks ja et normaalse tööprotsessi taastamise aeg jääks aktsepteeritavatesse piiridesse.

Andmeturbe erinevad tasemed

Süsteemi töövõime taastamise aja planeerimisel võib isegi arvestada sellega, et „õnnetuse“ korral ei säili isegi kõik andmebaasis olevad andmed vaid osa nendest tuleb taastada „käsitsi“. Võtame näiteks väikese firma personali halduse süsteemi. Seal piisab täiesti, kui me varundame andmeid korra ööpäevas, näiteks öösel kell 3:00. Seega kõige suurema andmekadu, mis meil tekkida saab on ühe päeva töö andmed. Kui selles firmas pole ametialaseid liikumisi väga palju võime me täitsa vabalt võtta endale riski teha ühe päeva töö uuesti. Kuna tegemist on toetava funktsiooniga, mis otseselt äritegevust ei mõjuta, siis võime täiesti rahulikult nii käituda.

Andmete taastamine „käsitsi“

Kui me vaatame nüüd sama infosüsteemi mingi tööotsingute kontori seisukohalt, mis osutab lisaks töötajate otsingule ka personaliarvestuse teenust paljudele ettevõtetele, siis midagi sellist me lubada ei saa. Siin on personali infosüsteem äritegevuse aluseks ja iga katkestus toodab kahjumit. Seega peame lisaks iga öistele varunduskoopiatele pidama veel ka andmete muutuste logisid ja tagama nende säilimise sõltumatult töötavast andmebaasist. Sellisel juhul saame me andmebaasi riknemise korral taastada andmebaasi eelmise öö varunduskoopiast ja seejärel lisada sinna muudatuste logi alusel kõik varunduskoopiast saadik andmebaasis tehtud muudatused.

Andmete täielik taastamine

Loomulikult erineb kõrge tasemega andmeturbe maksumus madalama tasemega andmeturbe maksumusest ja need erinevused võivad olla kümneid ja isegi sadu kordi. Seepärast tekkib alati dilemma – kui kõrgele TASUB viia andmeturbe tase. Ega sellel päris ühest vastust ei olegi. Peamised piirid seavad siin ette äriprotsessi iseloom n(võimalikud ärikahjud), eeldatav mingi konkreetse riski ilmnemise tõenäosus ja andmeturbele tehtavate kulutuste (võimalik) suurus. Üldine reegel on see, et andmeturbele ei tohiks kulutada rohkem, kui seda on võimalikud tekkivad kahjud (st kahjude suurus kaalutud nende tekkimise tõenäosusega).

Andmeturbe maksumus

Paraku on tihti nii, et äri iseloom „sunnib peale“ mingid väga ranged andmeturbe meetmed. Heaks näiteks on pank. Tänapäeva pank on 24/7/365 režiimis töötav organisatsioon. Võib öelda, et „keegi töötab kogu aeg“. Kui ka tööpäev on lõppenud, siis toimub läbi internetipankade, makseterminalide ja rahaautomaatide ikkagi aktiivne tegevus. Siin ei ole võimalik mitte kuidagi tingida andmete säilimises – kõik tehingud, mis on tehtud peavad säilima „101%“ kindlusega. Samuti ei ole mitte mingil tingimusel lubatavad sisse murdmised pangasüsteemi. Siin on ka kulude ja nende alusel tehtavate turbetoimingute planeerimine veidi erinev. „Sunnitud“ andmeturbe tasemega firma peab kirjeldama oma tuludes piiri, milleni turbekulud võivad (mitte ei pea) tõusta ja üritama nendes piirides luua nii hea turbe kui võimalik. Kõrgemale kulude tasemele tõustes võib muutuda äri tegemine mõttetuks samuti nagu madala turvatasemelgi

„Sunnitud“ andmeturbe tase

Andmete turvamiseks tuleb rakendada 5 erinevat meetmete kompleksi:

Viis andmeturbe meetmete kompleksi

●

Andmete füüsiline kaitsmine

Füüsiline kaitse

●

Andmete säilismise tagamine

Säilimise tagamine

●

Andmetele juurdepääsu tagamine

Juurdepääsu juhtimine

●

Andmete kasutamise reglementeerimine

Kasutamise reglementeerimine

●

Andmete õigsuse tagamine

Õigsuse tagamine

Nende viie andmeturbe meetmete kompleksi sisu lahtiseletusele ongi pühendatud käesolev loengumaterjal.

Loengumaterjali sisu

4.2. Andmete füüsiline kaitse

Kõik hakkab pihta andmete füüsilisest kaitsest. kui teie andmed ei ole füüsiliselt kaitstud, siis ei ole tähtust, kui palju te panustate ülejäänud nelja meetmete kompleksi, ikkagi jääb teie süsteem haavatavaks. Kui server, kus asuvad teie andmebaasid füüsiliselt ära varastakse siis lähevad kaduma andmed ja olenemata teie teistest turvatoimingutest on vargal võimalik kulutada piisavalt palju aega selleks, et teie andmetele ligi saada ja nad enda jaoks mõistetavaks teha.

Füüsiline kaitse kui kõige alus

Tegelikult on siin tegemist kahe erineva probleemiga. Üks on seotud riistvara „täieliku hävinemisega“ ja seega, isegi kui te olete oma süsteemi suuteline taastama, lisandub taastamise ajale uue riistvara hankimise aeg. Taastama olete te oma süsteemi muidugi sellisel juhul, kui teri varundusseadmed ja meedia olid kusagil mujal, kui varastatud arvuti. Seega võite te olla pärast sedamete vargust „täileikus null-seisus“.

Riistvara „häving“

Teine probleem, millest me juba ka rääkisime on teie jaoks oluliste andmete sattumine teie poolt kontrollitavast piirkonnast välja poole. Seejuures võivad need andmed olla krüpteeritud, hajutatud vms. Aga nende andmete „uuel omanikul“ on piisavalt aega et nende andete „avamisega“ tegeleda – kogu vajalik informatsioon selleks läks kaasa koos andmetega. See kas ta need andmed avab sõltub pigem sellest, kui väga ta neid vajab või tahab.

Andmete kaotamine

Tegelikkuses on andmete ja riistvara võõraste eest füüsiline kaitse ainult füüsilise kaitse üks pool. Tegelikkuses tuleb mõelda ka erinevatele (loodus)õnnetusjuhtumitele. Seda, et lennuk teie majja kukub ja „serveri ära lõhub“juhtub vast harva. Samas on aga erinevate kommunaalsüsteemide rikked üsna sagedased ja seepärast tuleb mõelda serverite (ja seega ka andmebaaside) kaitsele nende eest.

Riistvara häving

Nii näiteks on hea kui serverid ja kettamassiivid saavad toidet UPS-seadmetest. Kuid isegi vaid see ei ole piisav. Seda eriti kettamassiivide korral. Kuna ühegi UPSi autonoomse töö aeg ei ole liiga pikk ja kui see otsa saab lülitub seade ikkagi välja. Kui nüüd ei ole lisatud mingit mehhanismi, mis enne UPSI välja lülitamist lõpetaks kettaseadme töö „normaalse“ seiskamisega, siis võib juhtuda, et äkkväljalülitusel riknevad ketastel salvestatavad struktuurid. Võimsate RAID-seadmete korral (SAN ja NAS), mis normaalses töörežiimis on väga töökindlad ja tagavad andmete säilimise ka üksikute ketaste tõrgete korral, võivad „saba seinast välja tõmbamisel“ käitud väga ettearvamatult. Seega oluline on andmebaasidega seotud seadmete puhul rakendada nn. Smart UPSe, mis suudavad enda poolt hallatavatele seadmetele anda korralduse „normaalseks töö lõpetamiseks“. Ja seda igal juhul, kui tegemist on andmeid hoidva serveriga. Tavalise, mingit rakendust „pööritava“ serveri korral ähvardab teid ka kõige suurema „hävingu“ korrasl peamiselt mingi koguse tarkvara uuesti installeerimine. Andmeid sisaldava serveri puhul võivad teie kaotused olla „igavikulise tähendusega“.

UPS ja sellega seotud probleemid

Nüüd tekkib aga uus probleem – voolu taastumisel seadmed ise käima küll ei lähe. Siit tuleneb mehitatud valve vajadus 24/7/365 süsteemide jaoks, mis toimib 24 tundi ööpäevas. Tase tõuseb.

Mehitatud valve

Veel suuremat ohtu kujutab endast riistvarale veevärk. Seega tuleb, mitte tunda muret, kui uued või vanad on torud serverite läheduses vaid kanda hoolt selle eest, et neid seal poleks. Ja mitte seda, et neid ei oleks serveritega ühes ruumis vaid ka seda, kuidas nad on paigutatud naabruses ja kuidas seal tekkivad kahjud võivad mõjutada serveri ruumi.

Veevärk

Kindlasti tuleb üsna tugevasti mõelda tulekahjuriskide maandamisele Sellesse valdkonda kuuluvad nii tulekindlamate (mitte tulekindlate, sest sellist asja pole olemas) ruumide ehitamine kui ka „riistvarasõbralike“ tulekustutussüsteemide hankimine.

Tuli

Tegelikkuses tuleb vaadata asjale veel laiemalt ja püüda leida üles kõikvõimalikud ja (esialgu) võimatuna näivad ohud ja kõrvaldada need. Selliseks ohuks võib näiteks olla ka naabruses (samas majas?) töötav suure elektritarbimisega ettevõte, akna taga kasvav vana puu, piirkonna seismiline olukord vms.

Ohtude kõike hõlmav analüüs

Kui tegemist on serveritega, milles hoitavad andmed nõuavad kõrgeima tasemega füüsilist kaitset, siis hakkab see mõjutama ka infosüsteemi arhitektuuri. Kuna kõrgematele turbereeglitele vastavate serveriruumide ehitamine ei ole just liiga odav tegevus, siis ´tavaliselt ehitatakse neid vähe. Selle tulemusena koondub kogu andmete salvestamine üksikutesse kohtadesse ja see paneb piirid ka meie võimalustele vabalt vakida infosüsteemi arhitektuurile. Me saame keskenduda ainult nendele mudelitele, kus andmete talletamine toimub tsentraliseeritult.

Füüsilise kaitse taseme mõju infosüsteemi arhitektuurile

4.2.1. Andmete kaitse serveri operatsioonisüsteemi tasemel

Kui serveri riistvara õnnestub kaitsta „raua ja betooniga“, siis serveril olevate andmetega on asi tunduvalt keerulisem. Kuna serveril olevatele andmetele peab ligi saama läbi arvutivõrgu, siis on üsna suur tõenäosus, et andmeid üritatakse rünnata just sealt poolt. Seega andmebaasi serveritle ei tohiks üldse anda kasutajaõigusi serveri kasutamiseks fail-serverina. Enamik kasutatavaid andmebaasisüsteeme ei vaja enda poole pöördumiseks seda, et kasutajal oleksid õigused selles arvutis, kus andmebaas asub. Tavaliselt piisab sellest, kui avada juurdepääsuks andmebaasile operatsioonisüsteemi tasemel mingi port – ülejäänuga saab andmebaasimootor ise hakkama.

Suhtlus läbi avatud pordi

4.2.2. Andmete kaitse tulemüüridega

Selliste andmebaasiserverite kaitseks, mille poole pöördutakse avalikust võrgust, tuleb igal juhul rakendada ka tulemüüre. Sisevõrgus töötavate andmebaasiserverite korral on tulemüüride pigem erandlik. Samas ei tohi seda eriti konfidentsiaalsete andmete puhul sugugi alahinnata.

Tulemüür serveritele avalikus võrgus

4.3. Andmete säilimise tagamine

Andmete säilimise tagamisel on kaks taset nn. off-line ja on-line tase, mis omakorda jagunevad mitmeks tasemeks:

Andmete säilimise tagamise off-line ja on-line tehnoloogias

Off-line 1

Andmete varundamine (backup / restore)

Andmete varundamine

Off-line 2

Andmete varundamine koos varunduskoopiate vahelise andmemuudatuste logide pidamisega

Andmete muutuste logid

On-line 1

Erineva tasemega RAID-kettamassiivide kasutamine

RAID-massiivid

On-line 2

Samas serveriruumis paralleelselt töötavad mitu samades ülesannetes seadet.

Paralleelseadmed

On-line 3

Dubleeritud serveriruumid erinevates, üksteisest piisavalt kaugel asuvates (>5km) geograafilistes punktides.

Dubleeritud serveriruumi

Järgnevalt vaatlemegi neid andmete säilitamise metoodikate erinevaid tasemeid veidi põhjalikumalt, et näidata nende erinevusi ja arutleda nende kasutamise otstarbekuse üle.

4.3.1. Andmete varundamine

Kuna eelnevates loengutes on piisavalt selle protseduuri toimimise seisukohalt, siis piirdume siin ainult sellistel tõikadel, mida on oluline pidada meeles andmeturbe seisukohalt:

●

Kindluskoopiate tegemine on kohustuslik. Tavaliselt saadakse sellest aru siis, kui esimest korda selgub, et neid koopiaid on vaja. Siis selgub, et neid oleks pidanud tegema hakkama juba siis kui see andmebaas loodi ja käima lasti.

Kohustuslikkus

●

Kindluskoopiate tegemine peab olema regulaarne ja järjepidev protsess. Neid tuleb teha ettemääratud sagedusega ja see sagedus peab olema planeeritud selliselt, et andmete riknemise korral oleks võimalik andmebaas taastada äriprotsessi minimaalselt võimaliku ja vajaliku häirimisega.

Järjepidevus ja perioodilisus

●

Kehtestatud peab olema kindluskoopiate tellimise kord. SEDA TULEB TÄITA.

Tellimise korra olemasolu

●

Aegajalt tuleb teha auditeid, mille käigus kontrollitakse kõigist töötavatest andmebaasidest kindluskoopiate tegemise toimimist. Lisaks selle tuleb kontrollida ka seda, kas need koopiad on ikka kasutatvad. Ei ole mingit kasu kindluskoopiast, mille kasutatavus on meile teadmata ja selle kasutatavus selgub meile alles selle hetkel kui me seda kasutada tahame

Tõestatud kasutatavus

●

Peavad olema määratud vastutavad isikud varundusprotsessi erinevates etappidele.

Vastutavad isikud

●

Kindluskoopiate tegemise protsess peab toimima automaatselt, et vältida inimlikku eksitust/unustamist.

Automaatne protsess

●

Vähemalt üks kindluskoopiate tegemise seade peab olema varus (kas siis enda laos või tarnija juures) selliselt, et põhiseadme riknemisel oleks juba järgmiste kindluskoopiate tegemise ajaks panna uus seade tööle.

Vähemalt üks seade varus

●

Kehtestatud peab olema kindluskoopiate säilitamise kord - kindluskoopia võib osutuda surimaks turvaauguks . Kindluskoopiad peavad olema valvatud sama kindlalt nagu on valvatud serverid. „vedelema jäänud“ kindluskoopia on üks suurimaid andmete lekkimise riske.

Säilitamise kord

●

Kehtestatud peab olema kindluskoopiate vananenud andmekandjate hävitamise kord. Kindluskoopiat ei saa lihtsalt minema visata. See tuleb muuta kasutamatuks.

Hävitamise kord

●

On hea kui kindluskoopiaid ei hoita samas füüsilises kohas kui need seadmed, mille varundamise tulemusena nad on tekkinud. Kui seda tingimust pole võimalik täita tuleks vähemalt üks koopia nädalas viia mujale. Näiteks oma firma teise kontorisse või siis panga deposiitboksi.

Säilitustingimused

●

Kõik varundatava seadmega samas hoones olevad kindluskoopiad tuleb hoida varundatavast seadmest võimalikult (või siis otstarbekalt) kaugel ja säilitatama kõrgeima tulekindlusega seifis.

Ja vee kord ... säilitustingimused

●

Kõigi andmebaaside taastamiseks tuleb koostada taasteplaanid selleks, et rikke tekkimisel oleks täpselt teada, kes, mida ja mis ajal peab tegema selleks et taastada andmebaasi töö. Kõiki taasteplaane tuleb katsetada. Iga kriisi järel, kus mingit taasteplaani kasutati, tuleb kriisi likvideerimise järel teha likvideerimise käigus selgunud täpsustused.

Taasteplaanid, taasteplaanid, ...

4.4. Andmetebaaside kasutamise reglementeerimine

Andmebaaside kasutamise reglementeerimisel on kolm erinevat võimalust: horisontaalsete õiguste kirjeldamine, vertikaalsete õiguste kirjeldamine ja funktsionaalsuse kasutamise piiramine. Kuna kõigest sellest on õiguste kirjeldamise juures räägitud põhjalikult, siis siin peatume asjal ainult põgusalt – süsteemse vaate tagamiseks.

Erinevad piirangud

Kõigil andmebaasidel on olemas horisontaalsete õiguste tagamise mehhanismid. See väljendub kasutajate kirjeldamises ning neile süsteemsete ja objekti õiguste andmises (vt loeng nr. 3). Lühidalt kokkuvõtte antakse kasutajatele õigused tegutsemiseks (süsteemsed õigused), mis tähendab õigusi luua ja muuta andmebaasi struktuuri kirjeldusi, protsess ja muid andmebaasis paiknevaid instrumente ja objekti õigused, mis tähendab õigusi erinevatele andmebaasi objektidele (tabelid, vaated, protseduurid) juurde pääsuks. Kui süsteemsed õigused kirjeldatakse kas õiguste keelamise või lubamisena (jah/ei tüüpi õigused), siis objekti õigustel on võimalik kirjeldada objekti struktuurne alamhulk, mida võib kasutada (tabelite ja vaadete puhul veergude loend) ja sinna juurde veel nende kasutamise tase (tabelite ja vaadete puhul kas vaatamime (SELECT), lisamine (INSERT), kustutamine (DELETE), uuendmaine (UPDATE) või siis mõni kombinatsioon nendest.

Horisontaalsed õigused e. Süsteemsed ja objekti õigused

Vertikaalsed õigused ehk õigused andmekomplektide (kirjete) kasutamiseks ei ole üldjuhul nii determineeritud nagu seda on horisontaalsed õigused. Horisontaalsete õiguste mõte seisneb selles, et kõigil kasutajatel ei ole õigus SUDIda (SELECT, UPDATE, DELETE, INSERT) kõiki samas andmebaasitabelis asuvaid andmeid, vaid ainult osasid nendest. Loomulikult on igas andmebaasis väga palju tabeleid, kus kõikidel kasutajatel on õigus vähemalt näha kõiki kirjeid (näiteks erinevad teatmik-tüüpi tabelid).

Vertikaalsed õigused e. õigused kirjete kasutamiseks

On veel kolmaski õiguste reglementeerimise viis so. Õiguste andmine kasutatavale rakenduste funktsionaalsusele. Nende õiguste teostamine ei käi otseselt andmebaasi ülesannete hulka – need õigused realiseeritakse läbi rakenduste. Paraku on need õigused kirjeldatud tavalislet selles samas andmebaasis, mida rakendus kasutab oma tööks. Nende õiguste edukas või ebaedukas haldamine võib olla tõsiseks põhjuseks andmebaasiga töötamise takistamisel. Siin pole küll tegemist enam töövõime takistamisega vaid teise väga olulise teguri mõjutamisega, mille nimi on andmebaasi kasutatavus. See on küll üks osa andmebaasi serverite käideldavusest ei puuduta aga otseselt andmebaasi töövõimet.

Funktsionaalsed piirangud

4.5. Andmetele juurdepääsu tagamine

Andmebaaside turvamine ei tähenda ainult andmebaasides olevate andmete kaitsmist erinevate füüsiliste ja loogiliste meetoditega kõikvõimaliku hävimise ja rünnakute vastu ning kasutajate õiguste piiramist nende tegelike ametialaste volitustega. Andme turve tähendab ka andmete kasutamise võimaluse tagamist kõigile kasutajatele, kellel selleks on volitused ja protsessidele, mis seda vajavad. Kõikidel eelnevalt kirjeldatud turbe meetoditel on mõte ainult siis, kui kõik kellel selleks on volitused ja kes seda vajavad saavad ka tegelikult kasutada eesmärgi päraselt neid kaitstavaid andmeid. Selle aluseks on juurdepääs andmetele. Andmetele juurdepääsu tagamise meetmed puudutavad andmetele juurdepääsu tagamise tehnilisi aspekte – servereid, serveritele installeeritud tarkvara, andmesalvestusseadmeid ja andmetele juurdepääsu kanaleid ehk arvutivõrku.

Juurdepääs andmetele

4.5.1. Serverite haldamine

Serverite puhul saame rääkida riistvara töövõime ja adekvaatse jõudluse tagamisest. Töövõime ja jõudlus on küll omavahel tihedalt seotud asjad, kuid omavad täiesti erinevat tähendust. Andmebaasi serveri töövõime all mõeldakse serveri riistvara võimet teha tööd so. hoida pidevalt ilma tõrgeteta töös serverile installeeritud tarkvara võtta vastu läbi kanalite tulnud teateid ja saata kanalitesse teateid. Serveri töövõimele ei saa jääda lootma st. ei piisa sellest, kui me ostame uue riistvara ja jääme siis ootama päeva, millal see töö lõpetab. Serveri töövõimet tuleb pidevalt monitoorida. Tavaliselt hakkab riistvara enne „lõplikku lagunemist“ andma ajutisi tõrkeid, mis ilma monitoorimiseta ei pruugi silmagi paista. Kui aga teostada riistvara pidevat seiret, siis on selliseid pisitõrkeid võimalik aegsasti märgata, selgitada välja nende põhjused ja võtta tarvitusele meetmed nende põhjuste kõrvaldamiseks.

Serveri töövõime ja selle monitoorimine

Serveri töövõime ei ole seotud ainult rikete ja nende kõrvaldamisega. Serveri töövõime tagamiseks muutuvas maailmas on vaja mõni kord tarvis teha muudatusi ka siis, kui serveril enesel otseselt midagi viga polegi. Kuna kõigi serverite põhiülesandeks on pakkuda läbi võrgu teenust kasutajatele, siis sõltub serveri töövõime üsna suurel määral tema „ühilduvusest väliskeskkonnaga“ so. Arvutivõrgu tehnilise seadmestikuga ja teiste arvutivõrgus olevate seadmetega. Nii võib näiteks arvutivõrgu konfiguratsiooni muutmine kutsuda esile vajaduse teha muudatusi ka serveri konfiguratsioonis. On halb, kui välise keskkonna olulisi muudatusi ei panda õigel ajal tähele ja serveri töövõime saab seetõttu häiritud.

Serveri töövõime ja tehnilised muudatused

Server võib olla täiesti töövõimeline aga siiski võib olla probleeme selle kasutamisega, kuna serveri jõudlus ei pruugi vastata teenindavate kasutajate töötlusjõudluse vajadustele. Jõudluse probleemid väljenduvad kasutajate ooteja pikkuses ja teenindavate protseduuride täitmise ajas. Lihtsalt öeldes - kasutajad peavada ootama vastuseid oma toimingutele liiga kaua ja teenindavad protseduurid täituvad liiga kaua. Kasutajate ooteaeg on suurtes piirides peamiselt emotsionaalne näitaja ja sõltub suuresti kasutajate harjumusest. Kui näiteks kasutajad on harjunud saama vastuseid oma päringutele umbes 1 sekundiga, siis 2 sekundine ooteaeg ei ole veel probleemiks. Kui vastused hakkavad saabuma 5 sekundiga ei ole seegi veel võib-olla väga suureks probleemiks. Kui aga vastuste ooteaeg jõuab 10 sekundini hakkavad kasutajad täiesti kindlasti nurisema. Kui aga olid kusagil mingid kasutajad, kelle harjumuslik ooteaeg on kogu aeg olnud ca 20 sekundit ja seda vähendada 10-le sekundile, siis nende jaoks toimub oluline töökeskkonna paranemine ja nad on oma 10-ne sekundi üle väga rõõmsad. Teenindavate protseduuride puhul on asi hoopis konkreetsem. Teenindav protseduur täidab mingit konkreetset ülesannet. Oma olemuselt on neid kahte sorti – ühed mis käivituvad kalenderplaani alusel (nn. patch-protsessid) ja teised, mis käivituvad kasutaja mingi tegevuse tulemusena. Kui teiste puhul on tegemist sisuliselt kasutaja ooteaega mõjutavate toimingutega siis siis esimese ei mõjuta seda kuidagi. Nende puhul on kriteeriumiks puhtalt täitmiseks kuluv aeg ja see, kas nad suudavad oma töö sellise kiirusega ära teha, et nad ei häiri süsteemi teiste komponentide tööd. See tähendab näiteks seda, et kui meie infosüsteemis on sellised tööd, mis tuleb ära teha öösel kella 24:00-st kuni 6:00-ni, siis serveri jõudlus peab olema selline et ta tõepoolest jõuab selle ajavahemiku sees ära teenindada kõik vajalikud protsessid. Kui mitte, siis tuleb läbi viia serveri ümberehiustööd või server välja vahetada.

Jõudlusprobleemid

Kuidas siis probleemi lahendada. Milline on see piir, millal peaks hakkama mõtlema serveri jõudluse tõstmisele? Patch-protsesside puhul on see piir suhteliselt kergesti määratav – kui protseduuride täitmise aeg hakkab lähenema kriitilisele piirile siis tulebki seda teha. Seejuures ei tohi oodata „viimase piirini“ vaid kõike seda tuleb teha piisava ajavaruga, et mitte lasta seda kriitilist piiri tõepoolest üle minna. Näiteks panga puhul võib tähendada see, kui öösel ei jõuta kõiki vajalikke protsesse ära teha, et panka ei saa hommikul õigel ajal lahti teha ja ka internetipangad jäävad seisma. Kogu sellise jõudluse haldamise aluseks on muidugi serverite töö monitoorimine.

Jõudluse haldus batch-protsesside korral

Nagu eel pool mainitud, on kasutajate ooteaja pikkus suhteliselt emotsionaalne asi, aga emotsioonidele süsteemide administreerimist üles ehitada on võimatu. Kasutajate ooteaja pikkus peab olema ette määratud tööprotsessi iseloomu alusel st., et infosüsteemi loomise käigus tuleb määrata, milline tohib olla kasutaja maksimaalne ooteaeg. Edaspidi tuleb vaid seda monitoorida ja määratud piirile lähenemisel tuleb teha serverite parendustöid, et viia tegelik olukord vastavusse kehtestatud normidele.

Jõudluse haldus kasutajate vajadustest / mugavusest lähtudes

4.5.2. Kettamassiivide haldus

Kettamassiivide tehnilise töövõime ja jõudluse kohta kehtib kõik see sama, mis serverite puhulgi. Tegelikult ongi ju siin tegelikult tegemist eriotstarbeliste serveritega, mille ülesandeks on anda võrgu kasutusse andmesalvestusseadmed. Nende töövõimet ja jõudlust tuleb monitoorida analoogiliselt serveritega. Tegelikkuses tulebki süsteemi vajalikku jõudlust monitoorida kompleksselt üle serverite ja nende poolt kasutatavate kettamassiivide selleks, et aru saada, kus tekkivad jõudluse probleemid (kus on pudelikael), kas serveris või kettamassiivis.

Serveri jõudlus vs. kettamassiivi jõudlus

Salvestusmahtude haldamisel on jällegi peamiseks „relvaks“ kasutatud mälumahtude monitooring – vaba kettamahu ammendumine viib kogu süsteemi töövõime kohe nulli. Kuna teada on maksimaalselt kasutatav kettamälu maht ja kui teada kasutatud mälumahu muutumist, siis on selle põhjal võimalik välja arvutada mälu ammendumise tendents ja seega ennustada ka üsna täpselt seda, millal praegusel hetkel vaba mälu maht ammendub. Seega piisavalt vara, et jõuda piisava ajavaruga suurendada mälumahte, tuleb alustada uute seadmete valiku ja hanke protsessi.

Salvestusseadmete mahu ammendumise mõju süsteemi töövõimele

Salvestusseadmete puhul ei tohi ära unustada nende, võrreldes teiste seadmetega, kriitilist vananemise protsessi. Tänapäeval on endiselt (juba ca viimased 50 aastat) andmebaaside salvestamisel kasutatavad seadmed on kõvakettad ja nende massiivid. Need, nagu teada, sisaldavad aga kiiresti pöörlevaid osi. Mis aga pöörleb see kulub. Kõikide selliste seadmete puhul on teada nende keskmine eluiga. Sellest lähtuvalt tuleb iga kettaseadme ostmisel planeerida juba ette ka tema välja vahetamise aeg, mitte jääda ootama, milla ta laguneba hakkab.

Kettasedamete kulumisest tulenevad toimingud

4.5.3. Andmebaasiserverite tarkvara haldus

Andmebaasiserveri tarkvara töövõime tagamine on üks osa serveri enda töövõime tagamisest – kui serveri riistvara on töövõimelina ja seda on ka serveri tarkvara siis on ka server töövõimeline. Andmebaasiserveri tarkvara töövõimelisuse monitoorimine on sama oluline kui riistvara monitooriminegi – me ei saa lootma jääda, et see töötab nö „iseenesest igavesti“ pärast seda kui see on käivitatud. Andmebaasiserveri tarkvara (mootori) töö monitoorimiseks tuleb teha etteantud ajavahemiku tagant andmebaasi poole pöördumisi ja kontrollida nende edukust. Nõrgema monitooringu korral tuleks teha (Read Only (Isolation Level 0) režiimis) kontrollpäringuid kogu töö seisukohalt olulistesse tabelitesse. Seejuures peab vaatama seda, et päringud poleks serverile liiga koormavad – pole ju mõtet koormata serverit maha testpäringutega. Tugevama monitooringu korral peaks üritama ka andmebaasi andmeid salvestada. Seda selle pärast, et pärimise ja kirjutamise mehhanismid on täiesti erinevad ja takistused nendele tekkivad täiesti erinevatel põhjustel. Kirjutamise testi jaoks tuleks aga teha just ainult selleks ettenähtud andmebaasitabelid.

Andmebaasiserveri mootori monitoorimine: lugemine ja kirjutamine

Oluline asi, mida peab monitoorima andmebaasimootori korral on kettapinna kasutamine st. vaba kettamälu mahu kahanemine. Miks peab seda siin eraldi tegema, kui seda sama tehakse juba kettamassiivide halduse käigus nii või teisiti? Seda selle pärast, et andmebaasiserveri mootori poolt hallatav kettamaht on tavaliselt ainult osa selle kettamassiivi kogu mahust. Seega võib füüsilisel kettal olla veel ruumi piisavat samas kui andmebaasimootorile eraldatud vaba kettapinna maht hakkab ammenduma.

Vaba kettapinna mahu kahanemise monitoorimine

On veel üks oluline asi, mida andmebaasiserverite juures tuleb monitoorida – see on operatiivmälu kasutus. Kui operatiivmälu vajadus ületab selle olemasoleva mahu siis hakkab toimima selline protsess nagu swapimine – st. mälust kirjutatakse ketastele need osad, mida serverisl just sellel hetkel oma töötegevuse täitmiseks vaja ei ole selleks, et vabastada mälu nende protsesside jaoks, mis just hetkel täituvad. Järgmisel hetkel aga vajavad mällu laadimist just need asjad, mis eelnevalt olid ketastele salvestatud, sest nendega seotud protsesside täitmise aeg jõudis kätte. Kettale salvestatakse aga ajutiselt peatatud protsesside andmed jne. See võtab tohutult aega ja serveri jõudlus langeb järsult. Seega kui sellised situatsioonid ei ole etteennustatavad ja ennetavate tegevustega kõrvaldatud muutuvad kõik muud serveri jõudluse tõstmiseks tehtavad administreerimsitegevused mõttetuks.

Operatiivmälu kasutuse monitoorimine

Mitmete suuremate ja keerulisemate andmebaasisüsteemide puhul on oluline ka kasutatava operatiivmälu sisemise struktuuri muutumise monitoorimine. Seda tehakse tavaliselt selle sama andmebaasisüsteemi vahenditega ja tulemusi kasutatakse konkreetse andmebaasimootori häälestamiseks. See on tavaliselt suureks abiks tarkvara häälestusest tingitud jõudlusprobleemide lahendamisel.

Andmebaasi mootori poolt kasutatav operatiivmälu sisemise struktuuri monitoorimine

4.5.4. Kanalite haldamine

Kanalite, st. arvutivõrgu, haldus on oma iseloomult sarnane serverite riistvara haldusega – kehtib kõik see sama, mis serverite riistvara puhulgi.

Arvutivõrk – spetsiifilise funktsiooniga riistvara aga ikkagi vaid riistvara

Monitoorida tuleb töövõimet ja jõudlust (läbilaske võimet). Viimast on vaja analüüsida koos serverite ja kettamassiivide jõudlusega selgitamaks välja, et ega jõudluse pudelikaelaks pole hoopis äkki kanalite läbilase. Ei pea vist enam lisama, et probleemide avastamisel tuleb neile leida lahendused :)

Kanalite läbilaske võime vs. serverite ja kettamassiivide jõudlus

Kuna kanalite riknemisel muutub kogu andmebaasi teenus kätte saamatuks, siis on kanalite monitoorimine üsna tähtis. Seda mitte selleks, et avastada, et kanal on „maha kukkunud“. Sellest annavad meile teada kasutajad kohe, kui nad enam tööd teha ei saa. Oluline on avastada kanalites esinevaid tõrkeida ja tegeleda nende kõravaldamisega selliselt, et vältida tõrgete kuhjumisel tekkivaid kanalite töö täielikku peatumist või siis olulist läbilaske võime vähenemist.

Kanal kui olulise tõrke allikas

4.6. Kokkuvõte: tulemus - andmete õigsuse (usaldatavuse) tagamine

Loomulikult oleks võinud selle peatüki kirjutada ka käesoleva loengu algusesse näidates kõigepealt ära eesmärgi ja seejärel hakata kirjeldama selle saavutamise teid. Paraku on on asja sisulist olemust kirjeldada palju lihtsam kui tema struktuursed komponendid on üheselt mõistavad. Seepärast ongi kokkuvõte sellele loengule kirjutatud kui saavutatud tulemuse kirjeldus. Tegelikult ei erine ju saavutatud tulemus karvavõrdki püstitaud eesmärgist, kui tulemus vastab eesmärgile.

.

Eesmärk vs. tulemus

Miks on oluline andmebaasides olevate andmete õigsuse/usaldusväärsuse tagamine? Aga selle pärast, et kui andmebaasides hoitavad andmed pole usaldusväärsed, siis muudab see mõttetuks kõik nende andmetega seotud protsessid. See kui me ei saa andmeid usaldada on oluliselt halvem situatsioon, võrreldes sellega, kui meil on andmeid puudu aga olemasolevaid võime me usaldada. Esimesel juhul, kui meie tegevused baseeruvad mitteusaldatavatel andmetel, on kõigi meie tegevuste tulemused mitte-usaldusväärsed. Seejuures ei ole teada selle mitteusaldatavuse määr. Teisel juhul, kui meil on küll andmeid vähem, kuid olemasolevad andmed on usaldusväärsed, on meie tegevuse tulemused mitte võib-olla nii täielikud aga samas täiesti usaldusväärsed.

Andmete usaldatavus

Püüame anda sellele lühikese põhjenduse. Infotöötluse eesmärk on andmete muutmine informatsiooniks, sest (äri)protsesside juhtimises tekkivatele küsimustele on võimalik vastata ainult siis, kui omada informatsiooni ja teadmisi, kuidas seda informatsiooni kasutada eksisteerivate probleemiude/ülesannete lahendamisel. Andmeid on võimalik informatsiooniks muuta (lisades andmetele konteksti) ainult siis, kui need andmed on olemas, kui on teada, millised andmed on olemas, kui vajalikele andmetele on tagatud juurdepääs ja kui andmed on usaldusväärsed.

Andmete muutmine informatsiooniks

Andmed vs. Informatsioon

Kui nüüd vaadata seda viimast lauset, siis siin on kaetud kõik aspektid, mida käsitlesime ülal pool.

On siiski üks andmete usaldatavuse tagamise meetod, millest me rääkinud pole. Me võime kaitsta oma andmebaasiservereid turvaruumidega, teha varunduskoopiaid, piirata kasutajate õigusi – ikkagi jääb oht, et kasutaja teeb oma õiguste piires midagi lubamatud. See tähendab seda, et kasutatakse oma volitusega lubatud tegevusi tehakse aga midagi sellist, mida ei tohiks teha selleks, et näiteks teenida ebaseaduslikku tulu. Samuti on võimalikud pahatahtlikud andmebaasides asuvate andmete rikkumised. Lisaks sellele on suur osa tegevusi, millest andmebaasi ei jää maha ühtegi märki. Nendeks on kõikvõimalikud raportid, mille pahatahtliku kasutamise tulemusena võib informatsioon firmast välja lekkida.

Volituste ületamine volituste piirides

Selliste asjade vähendamiseks on ainult üks võimalus. Andmebaasid tuleb projekteerida sellise struktuuriga, et saeal kirjutatakse andmeid üle nii vähe kui võimalik ja füüsilist andmete kustutamist igapäevase töö käigus ei tehta. Andmete üle kirjutamise asemel suletakse „ebavajalikuks muutunud“ andmed kuupäevaga ja kirjutatakse uus aktiivne kirje koos muutunud andmetega andmebaasi märkides selle kehtivuse alguskuupäeva. Andmete füüsilise kustutamise asemel tuleb ka need sulgeda kustutamise (kehtetuks tunnistamise) kuupäevaga. Kõikidesse kirjetesse kirjutatakse andmete looja ja sulgeja tunnus. Lisaks sellele logitakse ka kõiki tehtud tegevusi kasutajate lõike sekundilise täpsusega. Seda kõike tuleb kombineerida töölepingu tekstiga, kus peaksid olema kirjas nii jälgimise fakt, kui ka sanktsioonid tööreeglite rikkumise eest töös infosüsteemi ja andmetega

Andmete ja tegevuste logimine

Töölepingu osatähtsus

Sellega koos peab käima kasutajate teavitamine sellest, et kõikidest andmebaasis tehtud tegevustest (ka andmete pärimisest) jääb ajalugu maha. Kui inimene teab, et ilma märki maha jätmata ei õnnestu tegevusi teha, siis suure tõenäosusega ta seda ka ei tee.

Jälgimisest teavitamine

Nüüd on võimalik logidele panna peale jälgimise ja analüüsi süsteem, mis etteantud mustrite järgi püüab avastada infosüsteemi väärkasutusi. Kui nüüd peaks selguma, et keegi on midagi kuritegelikku või pahatahtlikku teinud (see võib selguda nii analüüsisüsteemi töö tulemusena kui lihtsalt kaastöötajate tähelepanekute tulemusena), siis saab nii andmete muutuse ajaloost, kui tegevuste logidest täpselt järele uurida, mis toimus. Seejuures ei saa me teada ainult kes ja mida tegi vaid meil on andmete muutuste ajaloos ja tegevuste logis kirjas kõik vajalik selleks, et taastada andmete usaldusväärsus.

Rünnete tagajärgede kõrvaldamine

Rünnete avastamisel ja süüdlaste leidmisel on mõistlikkuse piires (mitte liialt seda üle dramatiseerides) anda sellest teada organisatsiooni töötajatele. See parandab üldist turvalisust. See võib osutuda vahel ja mõnedes ettevõtetes problemaatiliseks, sest sellise info levimine väljaspoole ettevõtet võib oluliselt kahjustada ettevõtte ärihuve. Sellisteks ettevõteteks on näiteks pangad, kindlustusseltsid, investeerimisfondid jms. ettevõtted, mis tegelevad klientide varade haldamisega.

Töötajate teavitamine rünnetest