Identity Management

Autor: Mihkel Soomere (AK41).

Sissejuhatus

Identity Management ehk identiteedihaldus on teenus, mis tegeleb olemite sidumisega erinevates süsteemides olevate identiteetidega ja identiteetide erinevate atribuutidega. Olemid on tüüpiliselt inimesed, arvutid, hooned jms. Identiteedid on tüüpiliselt inimeste või arvutite kasutajakontod, hoonete kirjed registrites vms. Atribuudid on näiteks inimese nimi või telefoninumber, arvuti seerianumber, hoone aadress vms. Ei tasu lasta end petta sõnast "identiteet" - identiteedihaldus võib siduda suvaliste olemite seoseid, mitte ainult inimeste, nagu "identiteet" lubaks arvata.

Identiteedihalduse koht reaalsetes infosüsteemides

Ideaalses maailmas on kõik olemit kirjeldavad andmed kirjeldatud ühes keskses süsteemis, millest ülejäänud süsteemid andmed kätte saavad. Praktilises maailmas on paraku mitmeid infosüsteeme, mis sisaldavad sarnast või kattuvat infot. Võivad puududa ka tehnilised võimalused või otstarbekus koondada andmed ühte süsteemi. Näiteks võib infosüsteemil puududa võimekus viidata välistele andmetele või on vastav funktsionaalsus väga kallis või töömahukas. Kuna andmed ajas muutuvad, muutub üha keerulisemaks hoida andmeid eri süsteemide vahel ajakohasena. Siin tulevadki mängu identiteedihalduse tooted.

Identiteedihalduse töömehhanism

Tüüpiliselt on identiteedihalduse tarkvara südameks andmebaas, mis seostab kasutajakontod erinevatest infosüsteemidest ning erinevad atribuudid. Seda nimetatakse metabaasiks (metabase, meta-directory). Väärib märkimist, et metabaas ei sisalda otsest infot olemite kohta (näiteks nime, numbreid vms), vaid infot identiteetide ja atribuutide seostamiseks. Iga infosüsteemi juures on vahend (agenttarkvara, andmebaasi trigger, spetsiaalne klienttarkvara vms.) jälgimaks muudatusi. Kui toimub infosüsteemis muudatus, teavitatakse identiteedihalduse keskset andmebaasi, mis edastab tehtud muudatused teistesse infosüsteemidesse.

Identiteedihaldus kataloogisüsteemide liidestamisel

Tüüpilised näited on näiteks erinevate kataloogiteenuste (LDAP põhised süsteemid) liidestamine. Näiteks on asutuses kasutuses Novell eDirectory, kuid ärivajadused nõuavad kõrvale Microsoft Active Directory püstitamist. Inimesed vajavad kasutajakontosid mõlemasse süsteemi, kuid kataloogide vahel andmete ajakohasena hoidmine on probleemne. Abiellumise puhul vahetatakse nime, muutuvad telefoninumbrid ja e-posti aadressid, vahetatakse paroole. Käsitsi sellise info haldamine on äärmiselt töömahukas. Siin tulevadki mängu identiteedihalduse tooted.

Tüüpiline tööolukord

Näiteks eDirectorys muudetakse kasutaja telefoninumbrit. eDirectory kataloogi jälgiv agent edastab muudatuse teavituse identiteedihalduse andmebaasi, mis omakorda edastab muudatuse teistesse seotud infosüsteemidesse, siinkohal Active Directory’sse. Näide on lihtsustatud, kuid kajastab tüüpilist töömehhanismi.

Kasutusstsenaarium süsteemidest, mis ei toeta väliseid identiteete

Teine näidisstsenaarium on MySQL andmebaasimootor, mis ei toeta erinevalt teistest suurematest mootoritest (Oracle, Microsoft SQL, IBM DB2) ei toeta väliseid kasutajakontosid (näiteks üle LDAP liidese). Ärivajadustest sõltuvalt võib siiski olla tarvis kasutada MySQL puhul väliseid kasutajakontosid. Identiteedihalduse süsteem võimaldab seda kaudselt, luues andmebaasi kasutajakontod ning hoides nende info sünkroonis muude infosüsteemidega.

Seda stsenaariumi võib laiendada ka tüüpnäitena operatsioonisüsteemidele, mis mingil põhjusel pole seotud mõne kataloogisüsteemiga. Näiteks rangete turvanõuete tõttu ei ole Linuxi veebiserver seotud kataloogiteenusena, kuid on tarvis sinna luua mõned kontod, mis peaksid olema samad muude süsteemidega. Identiteedihaldus võimaldab seda teha sarnaselt MySQL näitena.

Kasutusstsenaarium tihedalt seotud andmetega sisusüsteemides

Kolmas näidisstsenaarium on raamatupidamise andmebaasi ajakohasena hoidmine. Erinevalt eelmistest näidetest ei ole siin tarvis sünkroonida kasutajakontosid, vaid olemite atribuute. Näiteks on raamatupidamise süsteemis alati sünkroonitud kasutaja üldandmed, temaga seotud teised olemid (kasutada antud vahendid, näiteks arvuti või auto) ning nende olemite olulised andmed (arvuti füüsiline asukoht asutuses, mis pärineb varahalduse süsteemist või auto läbisõit, mis pärineb GPS jälgimise infosüsteemist).

Sellise tihedalt seotud süsteemi loomine on võimalik, kuid erinevalt esimesest kahest näitest palju keerulisem. Esimesed näited kirjeldasid väga tüüpilisi standardstsenaariumeid, millega tulevad identiteedihaldused toime väga lihtsalt, viimane on aga erilahendus, mis võib nõuda palju rohkem arendustööd.

Tüüpiliselt sarnanevadki identiteedihalduse juurutused kolmanda stsenaariumiga, kus seotakse kokku palju erinevaid infosüsteeme, näiteks:

• Erinevad kataloogiteenused
• Erinevad andmebaasimootorid
• Läbipääsusüsteemid
• Andmebaaside sisuosad
• Dokumendihaldussüsteemid
• Muud eriotstarbelised infosüsteemid

Identiteedihaldussüsteemide kitsas- ja keerukuskohad

Identiteedihaldussüsteem peab arvestama ka erinevate süsteemide piirangutega. Näiteks võib ühes kataloogisüsteemis mõni atribuut olla multi-value (näiteks võib kasutaja olla mitu telefoninumbrit), kuid teises single-value. Samuti lisab keerukust erinevate süsteemide poliitikad. Näiteks, kui parooli sünkroonimisel on sihtsüsteemis paroolipoliitika, mis keelab lihtsad paroolid, võib parooli sünkroonimine ebaõnnestuda. Probleemiks võivad osutuda ka nii lihtsad asjad kui täpitähed või erimärgid, Unicode’st rääkimata.

Paroolide sünkroonimine

Kõige keerulisem on üldjuhul sünkroonida paroole. Paroole salvestatakse infosüsteemides üldjuhul räsina ning olemasolevat parooli teada ei saa. Samuti kasutavad infosüsteemid erinevaid tüüpi räsisid ning lihtne räsi kopeerimine ühest süsteemist teise ei toimi. Õnneks on üldjuhul paroolivahetuse ajal mingi aja parool saadav ka avatekstina. Seda näiteks selleks, et võrrelda parooli paroolipoliitika nõudmistega või rakendada sellele räsifunktsiooni. On olemas ka liidesed parooli teadasaamiseks (enamik kataloogisüsteeme) paroolivahetuse hetkel. Samas on ka süsteeme, kust on tehniliselt võimatu vastavate liideste puudumisel parooli kätte saada (näiteks Lotus Domino). Selliste süsteemide puhul tuleb paroole vahetada mõnes muus infosüsteemis või spetsiaalses identiteedihalduse liideses, mis edastab uue parooli teistele infosüsteemidele.

Paroolide sünkroonimise turvarisk

See võib osutuda ka turvariskiks, kuna parooli on identiteedihalduse andmebaasi ja teiste infosüsteemide vahel tarvis transportida avatekstina. Selle tõttu on väga oluline kasutada turvatud kanaleid (näiteks TLS või IPSec tunneleid).

Sünkroonimine erisused

Võib olla vajalik ma teatud muudatusi ignoreerida, käigu pealt transformeerida või ühe infosüsteemi muutmisel teisest andmed kustutada. Näiteks on ei tohi Linuxi veebiserveris saada parooli muuta. Kui ründaja saab ligipääsu serverile ning üritab mõne muu süsteemida liidestatud kasutaja parooli muuta, ei tohi see olla võimalik. Vastasel juhul võib ründaja saada ligipääsu teistelegi süsteemidele, mis muidu poleks võimalik (kui on salvestatud vaid räsi). Transformeerida on tarvis andmeid näiteks erinevates regioonis olevate süsteemide vahel. Näiteks kasutatakse USA’s ja Euroopas erinevat kümnenderaldajat, mis võib valesti kasutamisel tekitada raamatupidamises probleeme. Kustutada võib olla tarvis näiteks töötaja liikumisesl ühest hoonest teise, mille järel kustutakse kasutaja andmed läbipääsusüsteemist.

Tüüpiline näide on kasutajanimede olukord. Tihti kasutatakse Active Directory's kasutajanimekuju eesnimi.perekonnanimi. Teisalt on SQL'is punkt eraldaja ning eDirectory's märgib see kasutaja konteksti (asukohta kataloogipuus). Identiteedihaldus võib seda lahendada mitut moodi. Ühel juhul võidakse kasutajanime muuta süsteemiga sobivaks, näiteks eemaldades punkti või asendadades selle teise märgiga. Teisel juhul võidakse see jätta samaks ning kasutada SQL'is või eDirectory's erimärgi escapemist.

Enimlevinud identiteedihalduse tarkvarad

Enimlevinud identiteedihalduse tarkvarad on:

• Novell Identity Management
• Microsoft Forefront Identity Management
• IBM Tivoli Identity Manager

Erinevate tarkvarade vahel ei ole funktsionaalsuselt erilisi vahesid, pigem on vahe tehnilises lahenduses. Novelli ja Microsofti lahendusi on Eestis ka edukalt rakendatud.

Muud identiteedihalduse lahendused

Ka teisi infosüsteeme liidestavaid süsteeme võib käsitleda identiteedihaldussüsteemidena. Üks suuremaid Eesti-siseseid süsteeme on X-tee. Kuigi selle primaarne eesmärk on lubada turvalisi päringuid erinevate registrite ja andmekogude vahel, kasutatakse seda ka erinevate andmekogude andmete sünkroonimisel.

Iseehitatud liidesed ja süsteemid kvalifitseeruvad samuti identideedihalduse lihtsamate variantidena. Näiteks on sageli kasutuses iseehitatud paroolivahetusveeb, mis muudab parooli mitmetes infosüsteemides korraga. Teine lahendus on „kolmas“ infosüsteem, mis esitab andmeid kahest esimesest ning lubab muuta nendes korraga andmeid. Väikese modifikatsioonina võib see kolmas süsteem ka just andmeid sünkroonida. Kui veidi järele mõelda, oleme leiutanud uuesti ratta ehk siis identiteedihaldussüsteemi.

Kokkuvõte

Välja toodud piirangud ja nõuded muudavad identiteedihalduse reaalse ülesseadmise väljaspool standardseid lahendusi väga keeruliseks. Teisalt algavadki identiteedihalduse süsteemid just standardlahendustest ning hiljem laienevad erilahendustele. Tehniliselt ei ole selline töö enamasti probleem, kuna pakutavad lahendused on väga paindlikud.

Skaala teises otsas on tohutu käsitsitöö, mis suuremas asutuses ja kogukamates infosüsteemides toob kaasa otseselt mõõdetava suure tööjõukulu. Samuti kipuvad inimesed tegema vigu ning unustama, mis suunab fookuse jällegi automaatsüsteemidele.

Samas ei ole siiski tegemist võluvitsaga, mis kõik haldus-, audentimise- ja sisuprobleemid lahendab. Identiteedihalduse tarkvarad on üldjuhul ka üsna kallid, mis eriti esmasel juurutamisel viib kulud väga kõrgeks. Siiski ei tasu end rahanumbritel hirmutada lasta, sest tasuvusaeg võib olla vägagi kiire.