IP tinklo aktyviosios saugos stebėsena - analizė

1.IP tinklo aktyviosios saugos stebėsenos realizavimas 1.1.Tinklo stebėsenos konkrečios struktūros aprašymas Praktinio tyrimo tikslas - išanalizuoti esamą įmonės UAB „Alna Intelligence" situaciją, išsiaiškinti problemas, kylančias dirbant su kom­panijos CA (Computer Associates) sukurta tinklo aktyviosios saugos stebėjimo bei valdymo sistema Unicenter Service Desk, suprojektuoti naujus / papildomus reikalavimus sistemai ir įgyvendinti juos programiškai. Visa tai išspręs informacijos apdorojimo procesų keliamas problemas bei spartins sistemos duomenų apdorojimo procesą. „Alna Intelligence" veiklos sritis - IT ūkio priežiūra, konsultaci­jos, sistemų valdymas bei aptarnavimas, infrastruktūros diegimas. „IT Intelligence" paslauga yra sukurta atsižvelgiant į šiuolaiki­nių įmonių poreikį ne tik užtikrinti nenutrūkstamą informacinių si­stemų darbą, bet ir siekti konkurencinio pranašumo savo versle per gilesnį ir efektyvesnį informacinių technologijų panaudojimą. Teikiant „IT Intelligence" paslaugą, vadovaujamasi IT paslaugų valdymo geriausiomis praktikomis (ITIL), IT paslaugų valdymo standarto ISO 20000 nuostatomis bei taikomos modernios IT paslau­gų procesų automatizavimo ir valdymo priemonės - CA Unicenter Service Desk [1]. IT infrastruktūros biblioteka (angį. Information Technology Inf-rastructurc Library, ITIL). Tai labiausiai pasaulyje paplitusi metodo­logija, de facto pripažinta IT paslaugų valdymo standartu. Ji patrauk­li tuo, kad nepriklauso nei nuo technologijų, nei nuo pardavėjų. Paremta „geriausiomis praktikomis" ir standartine terminologija, ITIL metodologija leidžia kiekvienai įmonei sukurti specifinius, tik jų verslo poreikius atitinkančius IT paslaugų valdymo procesus [2]. Rečiau su IT susiduriantiems verta paaiškinti - ITIL metodolo­gija apima šiuos pagrindinius IT paslaugų valdymo procesus: paslau­gų palaikymą, paslaugų diegimą, saugumo valdymą, programinės įrangos valdymą, ICT infrastruktūros valdymą, verslo perspektyvų įvertinimą ir paslaugų valdymo įgyvendinimo planavimą (1 pav.) [3]. pav. IT valdymo procesų diegimas pagal ITIL „Alna Intelligence" didžiuojasi vieni pirmųjų Lietuvoje savo veikloje pritaikę ITIL metodologiją. Specialios programinės įrangos „Unicenter Service Desk" pagalba, „Alna Intelligence" ne tik pageri­no, savo teikiamų paslaugų kokybę, bet ir padvigubino darbo našu­mą - IT ūkio aptarnavimo efektyvumo lygis jau siekia Europos Są­jungos standartus. Nuo šiol vienas „Alnos Intelligence" darbuotojas gali prižiūrėti 300-400 bendrovės klientų standartizuotų darbo vietų. Tuo taipu Lietuvoje vidutiniškai IT ūkio aptarnavimo efektyvumo rodiklis siekia vos apie 60 kompiuterių vienam IT specialistui. Svar­biausia, kad taip taupomas darbo laikas, efektyviau vykdomas IT ūkio aptarnavimas, klientai gauna didesnę naudą. Naujos kokybės IT ūkio aptarnavimo paslaugos itin parankios tarptautinėms įmonėms, turinčioms savo padalinius skirtingose vals­tybėse, mat naujos sistemos pagalba galima realizuoti sudėtingus, daugiaetapius, daugelyje skirtingų geografinių vietų vykstančius pro­jektus. „Alna Intelligence" jau dabar aptarnauja klientų IT ūkius Vo­kietijoje, Nyderlanduose, Didžiojoje Britanijoje, Baltijos ir kitose ša­lyse [2]. Unicenter Service Desk skirtas organizacijoms, norinčioms įsi­diegti paslaugų palaikymo sprendimą, pagrįstą ITIL geriausia prakti­ka. Produktas yra sertifikuotas Pink Elephant Pink Verify kaip ITIL Service Support Enhanced. Be to, CA yra užmezgę ryšius su dauge­liu parterių, taip galėdami pasiūlyti glaudžias integracijas su įvairiau­siomis aplikacijomis, sisteminėmis programomis, tik organizacijai būdingomis taikomosiomis programomis [4]. Unicenter Service Desk - pagalbos tarnybos priemonė, kuri pade­da organizacijoms susitvarkyti su šiuolaikinių sudėtingų paslaugų ir palaikymo reikalavimų iššūkiais. Ši priemonė suteikia visapusišką ir laipsnišką paslaugų valdymo sprendimą, kuris gali funkcionuoti kaip savarankiškas produktas nedideliame versle ar pagalbos tarnybos sky­riuje, arba gali būti integruotas į didesnius verslo valdymo sprendimus, ar būti korporatyvinio verslo valdymo branduoliu. Ši technologija yra sukurta siekiant išgauti maksimalią investicijų naudą ir užtikrinti, kad paslaugų ir palaikymo sprendimai galėtų plėstis augant poreikiams ir būtų pritaikomi kiekvienai įmonei pagal jos poreikius. Unicentcr Service Desk yra sukurtas ir pritaikytas darbui tiek darbuotojams priklausantiems nuo IT infrastruktūros, tiek įvairiausio lygio vadovams- vadybininkams, projektų vadovams besidomin­tiems paslaugų lygio valdymu, tiek technikos vadovams, kurie priva­lo planuoti išlaidas techniniam palaikymui ir naujos techninės /programinės įrangos pirkimui, tiek patiems sistemų administrato­riams, norintiems optimizuoti savo darbą ir pagaliau pradėti dirbti strategijos, o ne gaisrų gesinimo linkme [5]. • Specifikacija - užsakovas turi suprasti ko jis siekia. Teikiant IT servisą, sunkiausia išsiaiškinti ko tiksliai norima. Reikia išversti verslo kalbą į IT, taip, kad pokalbis būtų suprantamas abiems pusėms. Paklausus, atsakoma, kad „noriu jog viskas gerai veiktų". Kas yra „viskas" ? Ką reiškia „gerai veikia" ? Po šių klausimų atsakymo, lyg akmuo nukrenta nuo vadovo gležnos krūtinės, o serviso tiekėjas iškart gauna krūvą pliusų į savo sąskaitą. Bėda yra ta, kad geriausiai atsakymą žino pats užsakovas, bet nemoka jo gerai suformuluoti. Todėl užsakovai neperka produktų ar servisų, jie perka sprendimus. • Tinkamumas - ar pasirinktas produktas tinka pagal užsakovo specifikaciją. Užsakovai nori žinoti, kad tai ką gauna yra tinkama jo poreikiui tenkinti • Vienodumas - kiekvieną kartą gauti tą patį. Kitaip tariant, ar tai visuomet išliks tuo pačiu, kai užsakovas sugrįš pakartotinai arba „turiu ir žinau, kur gauti dar". • Kaina pagal prekę - „kiek moku, tiek gaunu". Kaina privalo būti ne per didelė už prekę. Tačiau, jei rinkos kaina pakankamai didelė, užsakovo nedomina kiek uždirba paslaugos tiekėjas, todėl per didelės maržos nebūna, būna blogos prekės už per didelę kainą. • Bendravimas - kas ir kada vyksta. Užsakovas nori būti informuotas apie tai, kas daroma, kada daroma ir kaip daroma. Taip pat kas bus daroma, jei kils papildomų problemų. Kaip pasakė vienas iš viduramžių budelių „pati mirtis nėra baisi - baisus jos laukimas nežinioje". 2.Tinklo stebėsenos protokolų ir programų apžvalga 2.1.Informacijos apsaugos metodų ataskaitų generavimo procese tyrimas Šiame skyriuje pasirinkta „Petri tinklų" sistemų projektavimo metodologija. Teoriniame lygmenyje „Petri tiekių" pagalba kuriama ir modeliuojama E-Valdžios sistema. Tiriant informacijos apsaugos metodus sistemos projektavimo ir modeliavimo žingsniuose stengiamasi įvertinti šiuos pagrindinius vertinimo kriterijus: a) Lankstumas b) Patikimumas c) Našumas d) Kaina. Atliekant „Petri tinklų" analizę būtina pereiti prie kuriamos sistemos teorimo modeliavimo mechanizmo ir apra­šymo. Turi būti išanalizuoti geriausių informacijos apsaugos savybių radimo (pasiekimo) būdai ir keliai. Informacinės saugos problemos tyrinėjamos ir sprendžiamos jau seniai. Ypač jos aktualios dabar, kada plačiai plinta lokaliniai ir globaliniai tinklai. Informacinės saugos problema yra viena iš pagrindinių atvirųjų sistemų teorijos ir praktikos problemų. Apsaugos priemonės turi užtikrinti informacijos konfidencialumą, aktualumą, prieinamumą. Bet jeigu valstybinėms organizacijoms svarbiausia informacijos konfidencialumas, o informacijos aktualumas suprantamas kaip informacijos pastovumas, tai komercinėms struktūroms svarbiausia informacijos aktualumas ir duomenų bei jų apdorojimo paslaugų prieinamumas. Komercinės organizacijos, palyginus su valstybinėmis, yra atviresnės ir dinamiskesnės, todėl grėsmė joms skiriasi ir kiekybiniu ir kokybiniu atžvilgiu. Įvairios paskirties kompiuterinių sistemų informacinės saugos užtikrinimas yra viena iš aštriausių informacinių technologijų problemų. Galima konstatuoti, kad nežiūrint į daugelio organizacijų, dirbančių šioje srityje, pastangas, ši problema nėra išspręsta. Užfiksuojama vis daugiau informacinės saugos incidentų, turinčių sunkias pasekmes didelėms organizacijoms. Šio augimo pagrindinės priežastys yra dvi. Augantis informacinių technologijų verslo ir valdymo procesuose vaidmuo, ir to pasėkoje didėjantys reikalavimai informacinei saugai kompiuterinėse sistemose. Klaidų ir trikių kaina informacinėse sistemose auga. Didėja informacinių procesų sudėtingumas. Tai kelia padidintus reikalavimus personalo, atsakingo už informacinę saugą, kvalifikacijai. Adekvačių sprendimų, užtikrinančių priimtiną informacinę saugą už atitinkamą kainą, priėmimas tampa vis sudėtingesniu uždaviniu. Pirma priežastis objektyvi, jai galima tik priešpastatyti organizacijos sugebėjimą tenkinti augančius reikalavimus informacinės saugos srityje. Antros priežasties neutralizavimui būtina atitinkama personalo, atsakingo už informacinę saugą, kvalifikacija ir objektyvus informacinės saugos užtikrinimo posistemės įvertinimas. Informacijos saugumas yra gyvybiškai svarbus verslo sėkmei. Duomenis apie finansinę padėtį, produktų gamybą, prekes, saugomas sandėlyje, ir kt. ypač svarbu patikimai saugoti. Nuo to priklauso kiekvieno verslo sėkmė. Netgi menkutis informacijos nutekėjimas apie gamybos ir pirkimo planus, apie tiekėjus ir klientus gali privesti įmonę prie bankroto ribos. Pagrindinis saugumo uždavinys - kontroliuoti ir saugoti priėjimą prie bendrų įmonės duomenų. Informacijos saugumo svarba pabrėžtina ne tik verslui. Informacijos saugumas ypač svarbus valstybinėms organizacijoms, kur duomenų nutekėjimas gali priversti prie katastrofinių padarinių. Taip pat informacija ir jos saugumas yra svarbus dalykas įvairioms kitoms struktūroms, nepelno organizacijoms, viešos paskirties įmonėms bei asmeniniam vaitojimui. Taigi informacijos saugumas yra svarbus uždavinys bet kuriai įmonei, organizacijai ar paprastai sistemai. Siame darbe kaip informacinė sistema pasirinkta E-Valdžios sistema. E-Valdžia nagrinėjama kaip sistema jungianti vidinius procesus, išorinius procesus bei nuotolinį priėjima prie sistemos. Vidinių procesų pagrindu veikia valdžios institucijų sąveika, naudojant informacines technologijas. Išorinių procesų dėka yra galimas verslo, įvairių organizacijų ir bendruomenių pasijungimas prie valdžios institucijų resursų. Piliečiai turi priėjimo teisę prie valdžios institucijų teikiamos informacijos naudojant interneto ryšį. E-Valdžia - tai informacijos ir komunikacijos technologijų (IKT) panaudojimas tam, kad pagerinti viešųjų organizacijų veiklą. Yra trys pagrindinės E-Valdžios sritys: • Valdžios procesų tobulinimas: e-Administravimas • Piliečių pajungimas: e-Piliečiai ir e-Servisai • Išorinių sąveikų kūrimas: e-Visuomenė. E-Valdžioje informacijos ir komunikacijos technologijos taikomos šiose srityse: • Valdžia ir Piliečiai (G2C Government and Citizens) • Valdžia ir Verslai (G2B) • Valdžia ir Darbuotojai (Tarnautojai) (G2E) • Valdžia ir Valdžia (G2G). Tai daroma tam, kad supaprastinti ir patobulinti demokratijos, valdymo ir verslo aspektus valdžioje. E-Valdžios modelyje ir jos panaudojime plačioje visuomenėje, versle, organizacijų veikloje ir bendradarbiavime bei naujų servisų suteikime centralizuotuose portaluose matyti, kokia tai yra didelė informacinė sistema. Čia susiduriama su didžiuliais informacijos kiekiais, kur reikalingas patikimas duomenų apdorojimas, o taip pat turi būti užtikrintas patikimas duomenų perdavimas tinklais nutolusiems E-Valdžios vartotojams. Vartotojų autentifikavimas taip pat yra vienas iš svarbiausių uždavinių šioje sistemoje. Turi būti apžvelgtos fizinės ir kompiuterinių tinklų grėsmės organizacijose ir jų informacinėse sistemose, o tuo pačiu ir išanalizuota informacijos apsaugos taikymo sritys šiose dalyse. Turi būti išanalizuotos fizinės apsaugos problemos, o taip pat ir kompiuterinių tinklų saugumo ypatybės. Nagrinėjami patikimi vartotojų tapatybės atpažinimo būdai. Taip pat metodai, taikomi autentiflkacijos srityje. Nagrinėjami patikimo informacijos perdavimo užtikrinimo būdais. Analizuojama kokie metodai naudojami kriptografijoje, perduodant informaciją ryšio tinklais. 2.2. Petri tinklų panaudojimas Dar 1962 metais pasirodė pirmas darbas apie Petri tinklus. Jo autorius K. A. Petri (VFR) aprašė naują informacinių srautų sistemos modelį. Modelis buvo sudarytas remiantis prielaida, kad atskiros sistemos dalys funkcionuoja asinchroniškai ir konkuruoja tarpusavyje. Ryšiai tarp atskirų dalių buvo vaizduojami grafu arba tinklu. Dažniausiai Petri tinklai naudojami modeliuojant sistemas, kuriose vienu metu gali įvykti keletas įvykių ir yra apribojimai procesų dažnumui, sekai. Įvykiams yra suteikiami prioriteto įvertinimai. Tai labai patogus būdas informaciniams procesams aprašyti, kuomet valdymo sistemose vyksta konfliktinės situacijos, lygiagretūs atsitiktiniai ir nedeterminuoti procesai. Labai plačios yra Petri tinklų taikymo sritys: 1. Paskirstytos duomenų bazes. 2. Lygiagretus programavimas. 3. Lanksti gamyba. 4. Diskrečių įvykių sistemos. 5. Daugiaprocesorinės sistemos. 6. Didelio duomenų srauto apdorojimas. 7. Kompiliatoriai ir operacinės sistemos. S. Loginis programavimas. 9. Neuroniniai tinklai. 10. Formaliosios kalbos. 11. Asinchroninės grandinės ir struktūros. I Procesas. Pateikiamas Petri tinklų panaudojimo pavyzdys. Pavaizduotas tinklas yra labai paprastas rysiu tarp dviejų procesų Petri tinklo modelis. pav. Petri tinklų panaudojimo Šiuolaikinės valdymo sistemos daugiausia yra hibridinės - tolydiniai ar mišrūs objektai valdomi diskretiniais valdikliais. Valdymo algoritmui modeliuoti puikiai tinka spalvotieji Petri tinklai. Tolydiniai objektai aprašomi diferencialinėmis lygtimis, kurias patogu apibūdinti struktūrinėmis schemomis. Ypatingą reikšmę įgauna sąsaja tarp Šių modelio dalių ir laiko įvertinimas, nes laikas (laiko momentas) gali būti vienas iš valdančiųjų faktorių. Taigi projektuojant įvairias informacines sistemas patogu naudoti Petri tinklų architektūrą. Jos pagalba galima nagrinėti sistemą ypač detaliai, nes kiekvienas sistemos žingsnis aprašomas atskirais komponentais. Kiekvienos sistemos projektavime ir užsakovui ir sistemos kūrėjui svarbūs yra šie kriterijai: sistemos lankstumas, patikimumas, našumas ir žinoma kaina. Taigi kuriant E-Valdžios sistemą kiekviename žingsnyje yra naudojama Petri rinkių architektūra. Kiekviena sistemos posistemė turi būti suskaidoma į komponentus - operacijas ir būsenas. Reikiamose suskaidytos sistemos vietose turi būti realizuoti atitinkami informacijos apsaugos metodai (reikiamos apsaugos operacijos). Taip pat Petri tinklų pagalba būtina ištirti sistemos lankstumą, patikimumą bei našumą tam, kad pasiekti optimaliausią sistemos variantą. Be abejo iš atskirų sistemos elementų turi būti paskaičiuota sistemos kainą. Jei sistemos kūrėjų ar užsakovų netenkina suprojektuotos sistemos lankstumas, patikimumas, našumas ar kaina, tokia sistema turi būti suprojektuota iš naujo, ir joje turi būti pasiektas optimaliausias lankstumo, patikimumo ir našumo variantas ir tuo pačiu kaina. 2.3.Duomenų saugos projektavimo modelis Duomenų saugyklų sukūrimas leidžia vartotojui nagrinėti turimus duomenis, naudojant įvairius daugiamačius duomenų bazės pjūvius, kurti naujus išvestinius rodiklius, juos palyginti, grupuoti pagal dominančius kriterijus, analizuoti skirtingais agregavimo lygiais. Šiame darbe detaliai išanalizuotas duomenų saugyklos projektavimo procesas, kurio metu, remiantis naudotojų poreikiais ir esamos duomenų bazės schema, sukuriama saugyklos schema, pirminių duomenų transformavimo ir perkėlimo į saugyklą procesai, duomenų analizės modeliai ir saugyklos duomenų transformavimo į analizės modelius bei saugyklos atnaujinimo procesai. Sudaryta projektavimo metodika, kurioje didelis dėmesys skiriamas schemų tipų pasirinkimui, kelių schemų jungimui, duomenų normalizavimui ir saugyklos lankstumui. Metodika suformuluota remiantis literatūros Šaltinių analize ir praktine patirtimi, įgyta kuriant saugyklą Miškų informacinei sistemai MS SQL serverio priemonėmis. Duomenų saugyklos autoriumi laikomas B. uimon, kuris apibūdino duomenų saugyklas taip: „Duomenų saugykla yra analizės sritims (temoms) orientuotas (angį. subject oriented), integruotas, laiko chronologijos tvarka išdėstytas nemodifikuojamų duomenų rinkinys, skirtas valdymo sprendimams paremti"[3]. Ji aprūpina vadybininkus ir analitikus patikima informacija, kuri reikalinga operacinei analizei ir sprendimų priėmimui. Gali kilti klausimas, kodėl reikia kurti duomenų saugyklas -jukjos kaupia didelius perteklinės informacijos kiekius, dubliuodami gausią informaciją, kuri ir taip registruojama duomenų bazėse ar operacinių sistemų failuose. Saugyklos reikalingos todėl, kad analizuoti duomenis operacinėse sistemose tiesiog neįmanoma arba labai sudėtinga. Taip yra dėl daugelio priežasčių, tame tarpe ir dėl duomenų paskirstymo bei skirtingų DBVS formatų. Net jeigu visi įmonės duomenys saugomi viename serveryje, analitikui bus sunku vykdyti paiešką sudėtingose, kartais supainiotose struktūrose. Norėdamas atlikti analizę, vartotojas su duomenimis turi vykdyti įvairias operacijas: sumuoti, transformuoti, prognozuoti, ir panašiai. Tam jis turi turėti veikimo erdvę ir nesupainioti faktinių duomenų su skaičiuojamaisiais, o dar svarbiau - netyčia jų nesugadinti. Tokiu būdu saugyklos tikslas - sukaupti duomenis analizei vienoje vietoje ir juos pateikti tam pritaikytomis, suprantamomis struktūromis. Yra dar viena priežastis, pagrindžianti saugyklos atsiradimą - sudėtingos analitinės užklausos stabdo įmonės darbą, atliekamą su operatyviais duomenimis, ilgam blokuodamos lenteles ir užimdamos serverio resursus. 2.3.1.Duomenų saugyklų schemos Duomenų saugyklos duomenų modelis skiriasi nuo įprasto reliacinių ar objektinių/reliacinių struktūrų, kuriomis saugomi duomenys kasdieninių operacijų duomenims kaupti skirtose duomenų bazėse. Tai daugiamatis duomenų modelis, vadinamas kubu. Jei saugykla kuriama reliacinėje duomenų bazėje, daugiamatis modelis atvaizduojamas reliaciniu tam tikros struktūros modeliu. Pagrindinės reliacinėje bazėje kuriamos saugyklos duomenų struktūros sudėtinės dalys yra faktų ir dimensijų lentelės. Centrinis saugyklos taškas yra faktų lentelė. Paprastai joje saugomi agreguoti operaciniai duomenys apie analizuojamus objektus ir įvykius. Faktų lentelės atributai vadinami matavimais (angf. measures). Jie išreiškia analizuojamas dalykinės srities savybes. Saugyklos naudojimo metu faktų reikšmės nuolat atnaujinamos, įtraukiant naujus duomenis, atsiradusius įmonės operacinėje duomenų bazėje. Dimensijų lentelės turi nekeičiamus arba retai keičiamus duomenis, dažnai jos sudaro dimensijų hierarchijas. Faktų lentelių pirminiai raktai būna sudaryti iš išorinių raktų rinkinio, kuriame kiekvienas elementas yra atitinkamos dimensijos pirminis raktas. Saugyklų schemos turi kelias tipines struktūras, kurios buvo nagrinėtos [7 ]: plokščia, terasinė, žvaigždės, žvaigždyno, snaigės tipo schema. Projektuojant duomenų saugyklas, reikia išanalizuoti naudotojų reikalavimus bei operacinės duomenų bazės schemą, apibrėžti analizės sritis, kubus, faktus ir matavimus, dimensijas, jų elementus ir hierarchijas, faktų skaičiavimo formules. Tai sudėtingas uždavinys, skirtingas nuo įprastų duomenų bazių projektavimo. pav. Žvaigždės tipo schemos struktūra Būdingas dimensinio modelio kūrimo veiksmas yra objektų klasifikavimas į tris kategorijas: • Operaciniai objektai, kurie aprašo specifinių verslo įvykių, pavyzdžiui, užsakymų, savybes. Tai svarbūs objektai, iš kurių sudaromos faktų lentelės žvaigždės tipo schemoje • Komponentiniai objektai, kurie tiesiogiai susiję su operaciniu objektu ryšiu „vienas su daug". Šie objektai detaliau nurodo kiekvienos verslo operacijos komponentus. Komponentiniai objektai atsako į šiuos klausimus apie verslo įvykį: „kas", „ką", „kada", „kur", „kaip" ir „kodėl". Iš šių objektų sudaromos dimensijų lentelės žvaigždės tipo schemoje. • Klasifikavimo objektai, susiję su operaciniais objektais ryšiu „vienas su daug", t.y. operaciniai objektai funkcionaliai priklauso nuo komponentinio objekto. Klasifikavimo objektai vaizduoja duomenų modelio hierarchijas, kurias taip pat galima sujungti į dimensijų lenteles žvaigždės schemoje [1]. Kitas svarbus veiksmas - identifikuoti hierarchijas. Hierarchijos yra ypač svarbi koncepcija dimensiniame modeliavime. Hierarchija vadinama maksimalia, jeigu jos negalima išplėsti į viršų arba į apačią, įtraukiant kitą objektą. Objektas vadinamas minimaliu, jei tai yra maksimalios hierarchijos apačioje ir maksimaliu, jei yra viršuje. Minimalius ir maksimalius objektus lengva identifikuoti, kadangi minimalūs objektai neturi „vienas su daug" ryšių, o maksimalūs objektai neturi „daug su vienu" ryšių. Trečias žingsnis - sudaryti dimensinius modelius, naudojant hierarchijų sutraukimą ir agregavimą. 2.3.2.Duomenų saugyklos projektavimo procesas Projektuojant duomenų saugyklą, organizacijos duomenų bazė paprastai jau egzistuoja. Saugyklos tikslas -pateikti juos kiekvienam naudotojui jo užklausų vykdymui tinkamu būdu. Šiame darbe suformuluotas projektavimo procesas paremtas [2, 3, 4, 5] šaltinių analize ir eksperimentiniu kūrimu. Projektavimo procesui buvo keliami tokie reikalavimai: • Saugyklos schema turi agreguoti duomenis, bet iki tokio laipsnio, kad galėtų tenkinti detaliausias kiekvieno vartotojų užklausas. Todėl projektuojant saugyklą turi būtį išanalizuoti visi esami ir numatomi vartotojų poreikiai. • Saugyklos schema turi būti lanksti, kad būtų galimąją keisti arba plėsti, palaipsniui įtraukiant naujas sritis. Netikslinga sukurti visą didžiulę saugyklą iš karto, nes kūrimo metu gali išryškėti klaidos ar galimi efektyvesni sprendimai. Tikslinga kurti ją palaipsniui, iteracijomis, kiekvienoje iteracijoje tobulinant rezultatus. Formuluojant reikalavimus saugyklai, pirmiausia atliekama vartotojų poreikių analizė ir išskiriamos pagrindinės analizės sritys arba temos (angį. subjects) [2, 3, 6]. Analizės sritys dažnai sutampa su funkcinių padalinių ar atskirų specialistų atliekamos analizės sritimis. Analizės srities reikalavimus pateikia tos srities naudotojas. Pradiniai reikalavimų duomenys yra naudotojų užklausų aibė ir saugyklos atributų aibė. Kadangi visų užklausų iš anksto numatyti negalima, stengiamasi įvertinti galimai didesnę numatomų užklausų aibę. Kiekvienas naudotojas taip pat nurodo jį dominančių matavimų ir dimensijų atributus bei jų išvedimo būdus, kurie aprašomi lentelėmis. Kartu su naudotojo apibrėžtais reikalavimais nagrinėjama pirminė duomenų bazės schema ir naudotojų ataskaitos. Šie reikalavimai lyginami tarpusavyje. Atskirų analizės sričių faktai dažnai būna tarpusavyje nepriklausomi, tačiau dimensijos dažnai sutampa. Duomenų saugyklos projektavimo procesas susideda iš kelių etapų, kurie pavaizduoti 2 paveiksle. Kiekvienai analizės sričiai išskiriami faktai ir dimensijos bei sudaroma tos srities saugyklos schema. Faktai atitinka ataskaitų skaitines reikšmes ir pirminės duomenų bazės transakcijų atributus. Dimensijos atitinka ataskaitų stulpelius ir pirminės duomenų bazės komponentines bei klasifikacines esybes. Sulyginant ataskaitų stulpelius, transakcijų atributus ir naudotojo išreikštus poreikius, šiame darbe siūloma sudaryti faktą ir dimensijų matricas pradžioje kiekvienai sričiai, po to sujungti šias matricas į bendrą matricą. Pagrindiniai principai: didžiausio detalumo faktų nustatymas ir dimensijų nepriklausomumas. Esant nepriklausomoms dimensijoms, gaunama normalizuota saugyklos schema. Priklausomos dimensijos vaizduojamos hierarchijomis, tai yra, schema Įgauna snaigės pavidalą. Kalbant apie duomenų saugyklas, pabrėžiama, kad jose dažniausiai saugomi nenormalizuoti, pertekliniai duomenys ir tokiu būdu pasiekiamas skaitymo užklausų efektyvumas. Tačiau ir daugiamačiams duomenims galima nustatyti kokybinius reikalavimus. Tačiau tokius reikalavimus nagrinėja nedaug autorių. [5] šaltinyje apibrėžtos daugiamatės norminės formos: • Pirma daugiamatė norminė forma (1DNF) reikalauja, kad faktų schema ir dimensijos būtų susieti dalykinės srities funkcinėmis priklausomybėmis, faktų schema išsaugotų dalykinės srities apibendrinimo ir detalizavimo galimybes bei įkūnytų daugiamatį matavimų kontekstą. Taigi 1DNF užtikrina daugiamačio modelio tikslumą pilnumą ir nepertekliškumą. • Jei schema yra 2DNF, galima atskirti, kurie dimensijų lygiai neprivalomi. 2DNF užtikrina galimybę išvengti prieštaringų užklausų ir žinoti, kada dirbama su nepilna informacija. • 3DNF - dimensijos išdėstytos į hierarchijas ir faktų schema negali turėti nulinių reikšmių. Pagal daugiamačių norminių formų reikalavimus sudaryta schema susideda iš faktų bei dimensijų schemos ir agregavimo apribojimų. Šiame darbe siūloma saugyklos projektavimo metodika užtikrina trečios daugiamatės norminės formos modelį. Norint sudaryti saugyklos schemą kuri tenkintų daugiamatės normalizacijos reikalavimus, pirmiausia reikia identifikuoti faktų lenteles. Tam nagrinėjami naudotojų reikalavimai ir pirminės duomenų bazės schema. Dažnai viena analizės sritis turi vieną faktų lentelę. Norint gauti tam tikro fakto dimensijas iš pirminės duomenų bazės schemos, reikia identifikuoti visas lenteles, kurios turi ryšį su fakto lentele 1:N. Kiekvienai dimensijos lentelei taip pat reikia identifikuoti lenteles, kurios turi su ja ryšį 1:N, kol pasiekiamos nepriklausomos esybės. Taip gaunamos dimensijų hierarchijos. Reikia pažymėti, kad nustatant dimensijų hierarchijas, gali būti sudėtingesnių atvejų, kai tarp skirtingų hierarchijos lygių egzistuoja tarpinės lentelės. Tai taip vadinamosios silpnos esybės, kurios rodo, kad žemesnio ir aukštesnio dimensijos lygio yra daugiamatis ryšys. Tarpinių lentelių duomenys priskiriami aukštesniam dimensijos lygiui. Jungiant atskirų sričių schemas į bendrą saugyklos schemą kai kuriems faktams naudojamos tos pačios dimensijos. Tai leidžia daugkartinį dimensijų duomenų naudojimą bet saugyklos schema darosi painesnė. Daugiamatės schemos projektavimo ir pirminių duomenų perkėlimo į saugyklą metu atliekami transformavimo procesai detaliau parodyti 3 paveiksle. Sudarant duomenų saugyklos modelį, svarbu skirti tris modelių tipus, dalyvaujančius transformacijos procese iš operacinės aplinkos į sprendimų paramos sistemą: • bendras įmonės duomenų modelis; • saugyklos duomenų modelis; • duomenų saugyklos analizės srities modelis (dažnai atitinkantis įmonės posistemio duomenų modelį). Pradinis duomenų saugyklų kūrimo taškas yra bendras įmonės duomenų modelis. Be šito modelio yra labai sunku organizuoti duomenų saugyklos struktūrą ir jos duomenų turinį. Jis apima visas įmonės operacines duomenų bazes (duomenų šaltinius) ir duoda pagrindą integravimui ir suvienodinimui intelektualiame lygyje. Siame darbe saugyklos kūrimas buvo lengvesnis, kadangi visi nagrinėjamos Miškų informacinės sistemos (IS) duomenys saugomi centrinėje duomenų bazėje, kurios schemos fragmentas parodytas 4 paveiksle. Ši bazė turi virš 200 lentelių ir gilias ryšių hierarchijas. Suprojektuoti pilnos apimties saugyklą būtų labai didelis uždavinys, be to, bazė nuolat plečiasi, atsiranda naujos analizės sritys. Šiame darbe buvo sukurta saugykla kelioms pagrindinėms analizės sritims, tačiau tam tikslui buvo analizuojama visa pirminės DB struktūra. Kuriamai duomenų saugyklai pasirinkta snaigės schema. Sklypų snaigės schema pateikta 5 paveiksle. Snaigės schemos centre yra faktų lentelė, kurią naudoja dimensinės užklausos. Joje saugomi realus duomenys (faktai). Faktų lentelės raktas susideda iš dimensijų pirminių raktų, faktų matavimai yra skaitiniai atributai - kiekiai, kurie gali būti sumuojami, agreguojami įvairioms statistinėms operacijoms, skaičiuojamas jų vidurkis, maksimali/minimali reikšmė. Dimensijos rodo, nuo ko priklauso faktai, kokiais pjūviais galima juos nagrinėti. Sudarant schemas kitoms analizės sritims, buvo naudojamos tos pačios dimensijos, todėl gautą schemą būtų galima pavadinti snaigių spiečiumi 3.Konkretaus stebėsenos vykdymo algoritmo aprašymas 3.1.Duomenų transformavimo užklausos Yra du pagrindiniai faktoriai reikalingi aprašyti duomenų transformavimui iš operacinės aplinkos į duomenų saugyklos aplinką: duomenų pasirinkimas ir transformacijos taisyklės, kurios aprašo, kaip duomenys perkeliami į saugyklą. Duomenų perkėlimui į saugyklos duomenų struktūras buvo naudojamas Microsoft SQL DBVS įrankis DTS (Data Transformation Service), atliekantis duomenų transformacijas. DTS pagalba galima kopijuoti duomenų struktūras bei pačius duomenis iš vienos duomenų bazės į kitą, kurti duomenų perdavimo aplinkas, taip pat papildyti saugyklas duomenimis iš operacinių šaltinių. Norint saugyklą užpildyti duome­nimis, reikalingas DTS paketo sukūrimas ir jo vykdymas. Sukurti DTS paketą galima DTS Package Editor įrankiu. Jo paleidimui reikia prisijungti prie serverio naudojant SQL Server Enterprise Manager, kuris palaiko duomenų sau­gyklą, po to Data Transformation Setyice aplinkoje susikurti naują paketą. Jame sukuriami keli duomenų šaltiniai. Sekan­čiame 6 paveiksle matomas DTS paketas su jame sukurtais duomenų šaltiniais ir transformacija tarp jų. Pirmame transformavimo žingsnyje panaikinami ryšiai tarp lentelių bei pirminiai raktai. Pvz.: ryšiui panaikinti tarp Apskritis ir Rajonas lentelių yra užrašoma tokia užklausa; ifexists (select *Jrom dbo.sysobjects where id ~-^objectJd(N'[dbo].[FKRajonas Apskritis]') and objectproperty(id, N'IsForeignKey') = I) alter table [dbo].[Rajonas] drop constraint FK^Rajonasjipskritis go Prieš transformuojant duomenis į saugyklą, reikia panaikinti pirminius raktus duomenų lentelėse. Pirminiams raktams panaikinti yra užrašoma tokia užklausa: alter table [dbo]. [Apskritis] drop constraint [PK_ApskritisJ go. Antrame transformacijos žingsnyje saugykla užpildoma duomenimis. Norint įvykdyti transformaciją tarp skirtingų šaltinių, pirma reikia nurodyti tarp kokių šaltinių bei kokia transformacija bus vykdoma. Kuriant saugyklos faktų lentelės užklausą, reliacinėje duomenų bazėje užklausai vykdyti naudojamos tokios lentelės bei ryšiai tarp jų pavaizduoti 7 paveiksle. Užklausai vykdyti generuojamas SQL sakinys: Medžiu riisys.mr id. Vietoves, kdvid. Miškujipai.mtipjd. Žemes_naudm_k.ateg.zkjd, Geo_objektai.pr_id, Geo objektai.pl AS Maketas!.amz kljcod, Maketas 1'0.turis, Kv_skl.kvjd EROM Mišku tipai INNER JOIN Maketas! INNER JOIN Medžiuj^usys ON Maketas I.mrjd = Medziu_rusys.mrjdON MiškuJipaimtipjd = Maketas l.mtipid INNER JOIN Geo_objektai INNER JOIN Rysiaijsu_viet ON Geo_objektai.skljd = Rysiaijiu_viet.sk! Jd INNER JOIN Vietoves ON Ryšiaijujviet.kdvjd - Vietoves.kdvjd INNER JOIN Žemesjiaudmjkateg ON Geo_objektaizk_id = Žemes _naudm _kateg.zk_id INNER JOIN Sklypai ON Geojobjektai.sk!Jd = Sklypaiskljd INNER JOIN Urėdijos INNER JOIN Kv_skl ON Uredijos.mujd = Kvjkl.mujd ON Geo_objektai.sk!Jd - Kv__skl.sk/Jd ON Maketas i.skijd = Sklypai.sk/_id INNER JOIN MaketasIO ON Sklypai.sk!Jd = Maketas 10.skljd 3.2. Duomenų analizės kubai OLAP kubai buvo kuriami naudojantis MS SQL Server 2000 Analysis Services įrankiu. Buvo sukurti trys kubai imantys duomenis iš saugyklos su skirtingomis duomenų dimensijomis. Kubo kūrimo etapai: • Duomenų šaltinio pasirinkimas • Fakto lentelės pasirinkimas • Matavimų išskyrimas • Dimensijų išskyrimas • Kubo apdorojimas Prieš kuriant duomenų kubą pir­miausia reikia nurodyti duomenų serverį bei duomenų bazę, iš kur bus imami duomenys. Pasirinkus faktą lentelę, iš­skyrus fakto matavimus, bei pasirinkus dimensijas turime tokią duomenų kubo struktūrą, kur fakto matavimai yra sumuojami duomenys. Suprojektavus duomenų kubą, reikia atlikti jo apdorojimą. Jis rekomenduojamas, kad užtikrinti tikslius rezultatus vartant kubą. Jei apdorojimas vyksta sėkmingai, suprojektuotas kubas yra teisingas ir duoda teisingus rezultatus teisingi, priešingu atveju apdorojimo metu išmetamas klaidos pranešimas, kad apdorojimas nesėkmingas, tuo atveju reikia ieškoti klaidų projektavimo žingsniuose. Yra trys atvejai, kai kubą reikia apdoroti: jei buvo pakeista kubo struktūra, reikia atlikti pilną kubo apdorojimą; jei duomenų saugykla pasipildė naujais duomenimis, reikia atlikti atnaujintų duomenų apdorojimą; ištrynus arba pakeitus kubo duomenų šaltinį, reikia atlikti viso duomenų kubo apdorojimą. 3.3.. Sukinio lentelės ir vartotojų ataskaitos Sukinio (angį. pivot) lentelės paslauga yra pirminė programos sąsaja bendraujanti su MS SQL Server 2000 Analysis Services. Ji naudojama kurti vartotoją programas, kurios bendrauja su daugiamačiais duomenimis. Sukinio lentelės pagalba vartotojas gali analizuoti duomenų kubą jam patogiu būdu, realiu laiku keisti informacijos peržiūros pjūvį gali vartyti pateiktą informacinį kubą, analizuoti informaciją grafikų pavidalu. Toliau pateiktas pavyzdys, kaip galima analizuoti duomenis sukinio lentelės pagalba. Duomenų analizei atlikti pirmiausia reikia nurodyti duomenų šaltinį, t.y. kur yra sukurtas duomenų kubas Išsirinkus duomenų kubą, konstruojame sukinio lentelę. Pavyzdžiui, mus domina tokia informacija: koks minkštųjų lapuočių plotas, tūris ir aukštis Vilniaus (Tolkūno) bei Kauno (Švendubrės) apskrityse, kai miško tipas yra kiškiakopūstinė ir viksvinė-vilkdalginė bei žemių kategorija yra savaiminis medynas, ir 2002 metais. Dimensijas bei faktų matavimus sudedame tokia tvarka: • į duomenų vietą sukeliame visus faktų matavimus, t.y. plotas, tūris, amžius; • į stulpelius - metus bei žemių kategorijos dimensijas; • į eilutes - miško tipus, medžių rūšis bei geografines vietovių dimensijas. Paruošus sukinio lentelę reikia nurodyti konkrečius duomenis, kurie mus domina: • miško žemių tipą pasirenkame kiškiakopūstinį bei viksvinį vilkdalginį; • medžių rūšis - kiti minkštieji lapuočiai; • metai - 2002; • žemių kategorija - savaiminis medynas; • geografinės vietovės: • Vi !niaus( Anykščių raj., Toikūno vietovė) • apskritis; • Kauno (Druskininkų raj., Švendubrės vietovė) apskritis. Pasirinkę mus dominančius kriterijus, gauname ataskaitą (10 pav.). Suformuotai ataskaitai galima suformuoti grafinį vaizdą. Formuojant sukinio lentelę, galimi įvairiausi sukiniai duomenų analizei atlikti. Jeigu duomenų saugykla pasipildo naujais duomenimis, vartotojui reikia atnaujinti sukinio lentelės duomenis. 10 pav. Sklypo analizės srities vartotojo ataskaita Duomenų saugyklų projektuotojams sudaryta saugyklų kūrimo metodika, apimanti projektavimo procesą ir schemų tipų pasirinkimą. Formuojant schemą, kompleksiškai nagrinėjami vartotojų poreikiai ir esama duomenų bazės schema, laikomasi daugiamačio modelio normalizavimo, didžiausio reikiamo detalumo principų, siūlomas praktiškai pasiteisinęs iteracinio kūrimo metodas. Remiantis šiais principais, galima sukurti lanksčią saugyklos schemą, kurią galima plėsti naujoms analizės sritims. Pasiūlyti principai naudingi dar ir todėl kad netikslinga sukurti visą didžiulę saugyklą iš karto, nes kūrimo metu gali išryškėti klaidos ar galimi efektyvesni sprendimai. Tikslinga kurti ją palaipsniui, iteracijomis, kiekvienoje iteracijoje tobulinant rezultatus. Pasiūlyta metodika formalizuota sudarant saugyklos projektavimo proceso, saugyklos schemos, transformavimo ir atnaujinimo procesų modelius. Išanalizuotos ir įsisavintos MS SQL serverio saugyklų kūrimo ir analizės (OLAP) priemonės, aprašyta DTS duomenų transformavimo, daugiamačio kubo modelio sudarymo OLAP įrankio aplinkoje bei sukinio lentelių sukūrimo ir naudojimo metodika. Išanalizuotas Miškų informacinės sistemos duomenų modelis, operacinės duomenų bazės schema ir veiklos analizės poreikiai. Šios analizės pagrindu suprojektuota duomenų saugykla svarbiausioms analizės sritims: sklypų, medynų, kirtimų ir atkūrimo analizei. Saugyklos schema paremta snaigės tipo schema. MS SQL Server 2000 priemonėmis sukurta eksperimentinė Miškų IS saugykla pagrindinėms analizės sritims, realizuoti duomenų transformavimo komponentai, skirti saugyklos užpildymui duomenimis bei jų atnaujinimui. Saugykla užpildyta duomenimis, sukurti analizės kubai ir sukinio lentelės vartotojams. Numatytos saugyklos plėtimo galimybės naujų analizės sričių ar pirminės duomenų bazės plėtimo atveju. 3.3.Vieno prisiregistravimo sistemos Augant informacinėms sistemoms, vartotojai ir sistemų administratoriai, atlikdami savo funkcijas, susiduria su vis sudėtingesne sąsaja. Vartotojams paprastai tenka prisiregistruoti keliose sistemose, susiduriant su atitinkamu prisiregistravimo dia­logu kiekiu, kiekvienas iš jų gali pareikalauti skirtingų vartotojo vardų ir slaptažodžių. Administratoriai susiduria su vartotojų sąskaitų tvarkymu skirtingose sistemose, atsiranda daug painiavos, norint užtikrinti sistemos saugumą ir vientisumą [1 ]. Vartotojas prisijungia prie pagrindinio serverio, po to dar turi nurodyti vartotojo vardą ir slaptažodį, tikrindamas paštą, be to, vėl autentifikuoti save, kreipdamasis į duomenų bazių, serverį. Atitinkamai ir administratoriui reikia kelis kartus kurti vartotojui sąskaitas įvairiuose serveriuose, nustatinėti kreipties kontrolės teises. Taip jau istoriškai susiklostė, kad paskirstyta skaičiavimo sistema (Distributed Computing Environment - DCE) susideda iš komponentų, kurie veikia kaip nepriklausomos saugos sritys. Šie komponentai apjungia individualias platformas su susijusia operacine sistema ir programomis. Kadangi komponentai veikia kaip nepriklausomos sritys, tai galutinis vartotojas turi save identifikuoti ir auten-tifikuoti nepriklausomai kiekvienai sričiai, su kuria jis nori sąveikauti. Kaip tik toks scenarijus 1 pav. ir pavaiz­duotas. Vartotojas pradžioje sąveikauja su pirmine sritimi, pateikdamas savo vartotojo vardą ir slaptažodį. Paprastai priminė sritis atitinka darbo stoties prisijungimą prie serverio, nustatant sisteminius kintamuosius, asmeninį katalogą, kitus parametrus. IŠ priminės srities aplinkos vartotojas gali jungtis prie antrinių sričių, vėlgi autentifikuo-damas save su kitu vartotojo vardu ir slaptažodžiu [1]. Norint efektyviai koordinuoti ir integruoti vartotojo registraciją bei vartotojų sąskaitų tvarkymą, reikia keisti autentifikavimo schemą, vartotojo autentifikavimui paliekant vieną pagrindinį serverį, su kuriuo ir vyks autenti-fikacija. SSO atveju sistemai reikia surinkti iš vartotojo visus identifikacijos duomenis, reikalingus prisijungti prie kitų sistemų. Vartotojui jungiantis į pradinę sritį pateikta informacija gali būti naudojama prisijungti prie kitų sričių keliais budais: • Tiesiogiai. Vartotojo pateikta informacija perduodama kitai sričiai kaip antro prisiregistravimo dalis. • Netiesiogiai. Vartotojo pateikta informacija naudojama išgauti kilų to vartotojo vardų ir slaptažodžių porų informacijai, saugomai SSO informacinėje bazėje. Tada išgauta informacija automatiškai naudojama jungiantis į kitas sritis. • Betarpiškai, t.y. jungiantis prie pirminės srities, automatiškai prisijungiama ir prie visų antrinių sričių. • Laikinai išsaugota ir naudojama tik paties vartotojo jam reikiamu laiku. Administravimo požiūriu SSO modelis reiškia vieną vartotojo sąskaitą (account), kuria naudojasi visos sude­damosios sritys. Yra keli svarbūs SSO sistemos modelio saugos aspektai: • Antrinės sritys turi pasitikėti pirmine sritimi tam, kad: • teisingai patvirtintų vartotojo identiškumą ir autentiškumą, • apsaugotų autentiškumo informaciją, naudojamą vartotojo identiškumui nustatyti, nuo neautorizuoto naudojimo. • Autentifikavimo duomenys turi būti apsaugoti, perduodant juos tinklu tarp pirminės ir antrinių sričių. SSO sistemos turi daug privalumų tiek vartotojui, tiek administratoriui: • Paprasta naudoti. Vartotojai kartą prisijungia ir gauna visas jiems suteiktas teises be papildomą slaptažodžių įvedimo. • Slaptažodis skirtas tik vietinei darbo stočiai. Kad prisijungtų, vartotojas įveda vieną slaptažodį, kuris saugo as­meninių raktų duomenų bazę, esančią vietiniame kompiuteryje, todėl slaptažodžio nereikia siųsti per tinklą. • Paprastesnis administravimas. Administratoriai gali kontroliuoti, kam kokias teises suteikti, tvarkydami sertifi­katų, naudojamų tarp kliento ir serverio, sąrašus. Šie sąrašai yra trumpesni negu vartotojų vardų ir slaptažodžių sąrašai, be to, taip dažnai nesikeičia. • Kreipties kontrolė nesikeičia. SSO pakeičia autentifikavimo mechanizmą, bet nekeičia kreipties kontrolės mechanizmo, todėl pereinant prie SSO sistemos, nereikia keisti jau esamų kreipties kontrolės sąrašų. • Sumažėja vartotojo prisiregistravimo trukmė, taip pat sumažėja galimybė apsirikti, suvedant ne tą slaptažodį ar vartotojo vardą. • Padidėja apsauga. Vartotojas, turėdamas prisiminti kelis slaptažodžius, dažniausiai juos užsirašo ir pasideda kur nom lengvai pasiekiamoje vietoje. SSO atveju vieną slaptažodį prisiminti nėra sunku. • Pagreitėja naujų vartotojų įtraukimas bei kreipties kontrolės sąrašų modifikavimas. Be eilės privalumų, SSO sistemos turi ir keletą trūkumų [2]: • Ne visos sistemos "moka" tokiu būdu autentifikuotis -jos dažniausiai naudoja tradicinį, vartotojo vardo ir slap­tažodžio aulentifikavimą. • Nėra visiškai išbaigtų. SSO sistemų. Kad ir plačiausiai naudojama Kerberos v5 Beta7 vis dar yra kūrimo sta­dijoje. • Jei jau hakeriai kažkokiu būdu sužino vartolojo vardą ir slaptažodį, jie gauna visas to vartotojo teises į atitinka­mus serverius. • Kadangi autentifikavimui naudojamas vienas serveris, jis ir tampa pagrindiniu atakų taikiniu. • Kadangi prisijungiama centralizuotai prie vieno serverio, tai jam neveikiant (ar dėl sisteminių gedimų, ar dėl hakerių atakų), niekas niekur negali prisijungti. Išvados Nors SSO sistema labai pažangi bei patogi, būtina imtis atitinkamų priemonių, norint, kad ji būtų saugi bei patikima: • Šifruoti pagrindiniame serveryje esančius vartotojų sertifikatus. • Apsaugoti pagrindinį serverį ugniasiene (firevvall), leidžiant prie jo prisijungti tik iŠ tam tikrų adresų ir tik prie tam tikrų portų. • Šifruoti tinklu perduodamus raktus, slaptažodžius bei kitus svarbius duomenis. • Kadangi paprastą slaptažodį vis tiek nėra sunku nulaužti, o jį nulaužus atsivertų vist keliai, naudoti tik sudėtingus slaptažodžius, kuriuose būtų ir didžiųjų raidžių, ir skaičių, ir specialių ženklų, dažnai keisti slaptažodį. Dar geriau - naudoti biometrinę autentifikavimo sistemą, atpažįstančią pagal piršto atspaudus ar akies rainelę [3]. • Numatyti sąskaitos užblokavimą po keieto nesėkmingų bandymų prisiregistruoti. • Numatyti, kad vartotojas būtų automatiškai atjungiamas po tam tikro neveikimo periodo (timeout). • Naudoti bent vieną rezervinį serverį, darant veidrodinį pagrindinio serverio atspindį ar replikuojant duomenis. • Numatyti atsarginę galimybę prisijungti administratoriui prie pagrindinio serverio, jei neveiktų SSO sistema. • Registruoti visus veiksmus su autentifikavimo sistema. • Sekti veiksmus su sistema, numatyti sistemos veiksmus, aptikus bandymą įsilaužti. Taigi, prieš keičiant įmonės kompiuterinio tinklo autentifikavimo struktūrą iš daugkartinio prisiregistravimo (1 pav.) į SSO (2 pav.), reikėtų gerai apgalvoti, ar tikrai tokią sistemą pavyks patikimai apsaugoti, ar visi autentifi-kacijos reikalaujantys sistemos komponentai mokės autentiftkuoti vartotojus naujuoju būdu, ar vartotojai sugebės Literatūros sąrašas I. GARŠVA, E. Kompiuterių sistemų saugumo modeliavimas: daktaro di­sertacija. Vilnius, 2006. 2. Prieiga per internetą:

Daugiau informacijos...

★ Klientai rekomenduoja

Šį rašto darbą rekomenduoja mūsų klientai. Ką tai reiškia?

Mūsų svetainėje pateikiama dešimtys tūkstančių skirtingų rašto darbų, kuriuos įkėlė daugybė moksleivių ir studentų su skirtingais gabumais. Būtent šis rašto darbas yra patikrintas specialistų ir rekomenduojamas kitų klientų, kurie po atsisiuntimo įvertino šį mokslo darbą teigiamai. Todėl galite būti tikri, kad šis pasirinkimas geriausias!