Identity Management

Autor: Mihkel Soomere (AK41).

11.12.2011 - POOLELI

Sissejuhatus

Identity Management (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.

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 on võib infosüsteemid 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.

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üüpiliselt on identiteedihalduse tarkvara südameks andmebaas, mis seostab kasutajakontod erinevatest infosüsteemidest. Iga infosüsteemi juures on vahend (agenttarkvara, andmebaasi triger, spetsiaalne klienttarkvara vms.) jälgimaks muudatusi. Kui toimub infosüsteemis muudatus, teavitatakse identiteedihalduse keskset andmebaasi, mis edastab tehtud muudatused teistesse infosüsteemidesse.

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.

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.

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).

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.

Kolmas näidisstenaarium 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ü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. 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. Sellised piirangud ja nõuded muudavad identiteedihalduse reaalse ülesseadmise väljaspool standardseid lahendusi väga keeruliseks. Teisalt ongi erilahendused just täpselt see, milleks identiteedihaldust enim vaja on. 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 ning Enimlevinud identiteedihalduse tarkvarad on: • Novell Identity Management • Microsoft Forefront Identity Management • IBM Tivoli Identity Manager 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 esimeset ning lubab muuta nendes korraga andmeid. Selliste süsteemide ehitamine on samuti ajamahukas (samuti raha neelav) ning tekitab küsimuse – miks mitte kasutada standardtarkvara?