Suurimmaksi ongelmaksi työn edetessä ilmeni kaupallisten tuotteiden testaaminen ja sitä kautta niiden kattava analysointi. Tuotteiden soveltuvuutta Kaukaan tietohallinnon tarpeisiin jouduttiin analysoimaan osittain teoreettiselta pohjalta. Oman ratkaisumallin toteuttamiseen tähtäävien tutkimusten taustalla oli toive taloudellisten kustannusten minimoinnista. Mikäli ympäristöön pystyttäisiin toteuttamaan oma sovellus, syntyisi merkittäviä säästöjä kaupallisiin tuotteisiin verrattaessa. Toisaalta, vaikka oman ratkaisun toteuttaminen olisikin mahdollista, se tuskin tuottaisi pitkällä tähtäimellä skaalautuvaa mallia. Muutokset Oracle Net -verkkorajapinnassa tai muissa sovelluksen käyttämissä rajapinnoissa vaatisivat sovelluksen päivittämistä sekä testaamista tulevaisuudessa. Tästä johtuen kaupalliset ratkaisut lienevät turvallisempia tulevaisuuden toiminnan varmistamisen kannalta.
Tutkituista kaupallisista tuotteista parhaiten tarkoitukseen sopii Oraclen identiteetin hallinta, jota käyttämällä niin Linux- kuin Windows-alustallakin toimivien tietokantojen
käyttäjien autentikointi ja auktorisointi saadaan keskitettyä Active Directory -hakemistopalveluun. Windows-alustalla toimivien Oraclen tietokantojen osalta
autentikointi ja auktorisointi voidaan keskittää Active Directory -hakemistopalveluun myös Oraclen Windows-natiivin autentikointiadapterin avulla. Tällöin vältytään taloudellisilta panostuksilta ja saavutetaan OIM-ratkaisua vastaavat hyödyt helposti.
Molemmat tuotteet edistävät nykyisin käytössä olevien menetelmien tietoturvaa ja täyttävät UPM-Kymmene Oyj:tä koskevassa SOX-lainsäädännössä esitetyt tietoturvan vaatimukset.
MIIS-ratkaisu ei puolestaan täyttänyt asetettuja vaatimuksia autentikoinnin osalta. Sen avulla ei voida toteuttaa Kerberoksen kaltaista kertakirjautumismallia, eikä sen avulla pystytä hyödyntämään vahvempia autentikoinnin menetelmiä. Lisäksi sen toimintaperiaate, jossa tietokantakäyttäjien salasanat synkronoidaan, on tietoturvan osalta kyseenalainen. Auktorisointiin MIIS sen sijaan tarjoaa varsin käytännöllisen menetelmän ohjelmoitavien konnektorien ansiosta. Kyseisen tuotteen hankkiminen pelkästään tietokantakäyttäjien auktorisointiin ei ole kuitenkaan perusteltua.
Oman ratkaisumallin osalta tutkimuksissa päädyttiin tulokseen, jonka mukaan oman turvallisen ja toimivan autentikointimallin toteuttaminen ympäristöstä löytyvien ohjelmointirajapintojen avulla on mahdotonta. Oracle Net -verkkorajapinnan protokolla-analyysi osoitti, ettei kyseistä rajapintaa hyödyntäviä sovelluksia voi kehittää ilman avointa lähdekoodia. Protokolla-analyysin tuloksien mukaan, ei tietokantayhteydestä kyetä selvittämään käyttäjätunnusta, koska se välitetään tietokannalle salattuna.
Kappaleessa 2 puolestaan todettiin: Autentikointi koostuu kahdesta vaiheesta:
ensimmäisessä vaiheessa henkilö väittää olevansa henkilö X ja toisessa vaiheessa varmistetaan, että henkilö todella on väittämänsä henkilö X. Käyttäjää on mahdoton autentikoida, jos ei tiedetä kuka hän väittää olevansa. Tämä on juuri se ongelma, joka teki oman sovelluksen kehittämisestä mahdottoman.
Tietokantakäyttäjien auktorisointiin sen sijaan voidaan kehittää sovellus, jonka avulla
Oracle-tietokantojen auktorisointi voidaan keskittää Active Directory -hakemistopalveluun. Tätä johtopäätöstä tukevat tutkimustulokset Oraclen JDBC- ja
OCI- sekä Active Directory -hakemistopalvelun ADSI-ohjelmointirajapintoihin.
Sovelluksessa tarvittavien toimintojen toteuttamiseen rajapinnoista löytyy valmiit metodit, joiden hyödyntäminen on verrattain helppoa. Mikäli Kaukaalla päädytään toteuttamaan tietokantakäyttäjien auktorisointimalli, jossa hallinnointi keskitetään Active Directory -hakemistopalveluun, on näiden ohjelmointirajapintojen hyödyntäminen varteenotettava toteutustapa.
Tutkimusten aikana kävi kuitenkin ilmi, että tietokantakäyttäjien auktorisoinnin keskittämisen hyöty on olematon. Kaukaalla toimivien tietokantaylläpitäjien kanssa käytyjen keskustelujen perusteella tietokantakohtaisista ylläpitotoimista käyttäjien auktorisointi muodostaa hyvin pienen osan. Uusien käyttäjien lisääminen tietokantaan tapahtuu lokaalista tietokannasta käsin ja samassa yhteydessä käyttäjille myönnetään heidän sillä hetkellä tarvitsemansa roolit. Näihin rooleihin muutoksia tapahtuu suhteellisen harvoin, lähinnä organisaation rakenteen tai käyttäjän henkilökohtaisen työnkuvan muuttuessa. Todellinen hyöty hallinnoin keskittämisestä saavutettaisiin, jos käyttäjätunnuksien lisääminen tietokantaan voitaisiin automatisoida tapahtuvaksi Active
keskittäminen Active Directory -hakemistopalveluun ei siis juurikaan vähennä ylläpitäjien lokaaleihin tietokantoihin kohdistuvaa työn määrää. Lisäksi hallittavuuden kannalta ongelmaksi voi ilmetä tarvittava uusien ryhmien määrä Active Directory -hakemistopalvelussa. Yhdessä tietokannassa voi olla parhaimmillaan 11 erilaista roolia, joka tarkoittaa, että Active Directory -hakemistopalveluun on lisättävä 11 uutta ryhmää tietokantaa kohden.
Työn tutkimuksissa ja kokeellisissa testeissä havaittiin, että käytännössä Kerberos-autentikoinnin implementointi heterogeenisen ympäristöön on vaativaa ja tietyissä tapauksissa jopa mahdotonta. Lisäksi Kerberos on hyvin herkkä reagoimaan muutoksiin, sillä hyvinkin pienet ja merkityksettömältä tuntuvat muutokset konfiguraatiotiedostoihin saattoivat johtaa tilanteeseen, jossa Kerberos-autentikointi ei enää toiminut. Monesti tämä tapaisten virhetilanteiden selvittämiseen saattoi kulua päiviä. Tietoturvan näkökulmasta Kerberos autentikointiin perustuvaa kertakirjautumismallia voidaan pitää osaltaan kyseenalaisena. Kaikkien käyttäjälle määriteltyjen oikeuksien saaminen yhdellä kirjautumistapahtumalla altistaa infrastruktuurin tilanteisiin, joissa kyseistä ominaisuutta voidaan väärinkäyttää.
Lukitsematon työasema tai mahdollinen istunnon kaappaus ovat uhkakuvia, joita on syytä tarkoin analysoida ennen täydellisen kertakirjautumismallin toteuttamista.
Kaukaan infrastruktuuriin on suositeltavaa toteuttaa redusoidun kirjautumisen mukainen autentikointimalli, jossa tiettyjen tietojärjestelmien autentikointi toteutetaan Kerberoksella. Yhtiön toiminnan kannalta arkaluontoista informaatiota sisältävien tietojärjestelmien käyttäjäautentikointiin on syytä harkita vaihtoehtoisia vahvan autentikoinnin tai hybridi-arkkitehtuurin menetelmiä. Redusoidun kirjautumismallin implementoinnin vaatimukset on huomioitava jo tietojärjestelmien suunnitteluvaiheessa.
Tämä vaatii tietojärjestelmän toimittajan informoimista riittävän ajoissa. Tehokkuutta, suorituskykyä ja luotettavuutta vaativat Oracle-tietokannat kannattaa pitää tulevaisuudessakin Linux-alustalla. Näiden tietokantojen käyttäjien autentikointi tulee toteuttaa hyödyntämällä Oraclen tietoturvan laajennoksen tarjoamia vahvempia autentikoinnin menetelmiä. Alemman prioriteetin tietokannat kannattaa toteuttaa Windows-alustalle, jolloin autentikointia ja auktorisointia voidaan tehostaa käyttämällä
Oraclen Windows-natiivia autentikointiadapteria ilman taloudellisia kustannuksia.
Linux-alustalla toimivien Oracle tietokantojen käyttäjien auktorisoinnissa kannattaa
pysytellä nykyisessä toimintamallissa, sillä keskittämisellä Active Directory -hakemistopalveluun ei saavuteta niin suuria ylläpitäjien työmäärien vähennyksiä tai
helpotuksia, että sen toteuttaminen kannattaisi. Oraclen asiakasohjelmien nimenselvitys sen sijaan kannattaa keskittää Active Directory -hakemistopalveluun lokaalin nimenselvityksen sijaan. Näin tietokantojen nimitietojen muutosten kontrollointi keskittyy yhteen hallittuun pisteeseen.