Hyvin toimiva käyttäjä- ja pääsynhallinta (Identity and Access Management, IAM) on välttämätön edellytys digitalisaatiolle, sujuville prosesseille ja tietosuojalle. IAM on laaja kokonaisuus, joka liittyy organisaatiossa moneen asiaan, kuten melkeinpä kaikkiin tietojärjestelmiin sekä henkilöstöhallinnon ja asiakkuuden hallinnan prosesseihin. Sen kehitystä ja varsinkaan tuotehankintoja ei kannata tehdä ilman riittävää pohjadokumentaatiota, jossa on kuvattu muun muassa IAM-ratkaisun laajuus ja riippuvuudet. Mutta kuinka IAM-arkkitehtuurin kuvaamisessa kannattaa sitten edetä?
ICT-ratkaisuja voi toki kuvata monella tavalla. Arkkitehtuuri on kokemukseni mukaan tehokkain, kattavin ja selkein tapa kuvata laajoja kokonaisuuksia. Arkkitehtuuriin ei kuitenkaan kannata hukkua, vaan laatia vain ne kuvaukset, joille on oikeasti käyttöä. Yleensä IAM toteutetaan valmistuotteilla, joten perinteisiä, usein melko työllistäviä määrittelyitä ei ole edes tarvetta tehdä.
Kuvaa sekä nykytila että tavoitetila. Nykytilan kuvaus voi olla karkeammalla tasolla kuin tavoitetilan - lähinnä sen tarkoituksena on luoda pohja tavoitetilan ja sen toteutuksen suunnittelulle. Arkkitehtuurin ei kannata olla liian yksityiskohtainen, vaan kuvata yksityiskohdat erikseen teknisessä suunnittelussa.
Kuvaukset kannattaa laatia jollakin avoimella, määrämuotoisella kuvaustavalla, joka kattaa edellä mainitut kuvausnäkökulmat (esim. ArchiMate® 3). Näin kuvaukset ovat yksiselitteisesti ymmärrettävissä (esim. mahdollisilla toimittajilla).
IAM-arkkitehtuurin kuvaamisessa kannattaa edetä seuraavilla askelilla:
- Inventoi nykyiset tietojärjestelmät. Aloita kuvaamalla nykyiset tietojärjestelmät, niiden väliset tietovirrat käyttäjä- ja käyttöoikeustietojen osalta sekä käyttäjä- ja pääsynhallinnan nykyinen toteutus kussakin järjestelmässä. Tunnista myös ulkoiset järjestelmät, joita organisaation käyttäjät käyttävät sekä organisaation omat järjestelmät, joilla on ulkoisia käyttäjiä.
- Tunnista käyttäjäryhmät ja kuvaa kustakin käyttäjäksi tuleminen sekä olennaiset hallittavat muutostilanteet. Tunnista järjestelmien käyttäjäryhmät (esim. omat työntekijät, väliaikainen työvoima, yhteistyökumppanit, asiakkaat, jne.). Yleensä IAM-kehitys keskittyy joko sisäisiin tai ulkoisiin käyttäjiin, koska käytettävät IAM-ratkaisut ovat usein erillisiä. Rajaa siis alustavasti kehittäminen tiettyihin käyttäjäryhmiin (yleensä keskeisimpiin). Jatka kuvaamalla prosessikuvauksina käyttäjäksi tuleminen (ts. miten kunkin ryhmän käyttäjä käyttäjätunnuksen saa) sekä tilanteet, jotka vaikuttavat käyttäjän käyttöoikeuksiin (esim. käyttöoikeuksien tilaaminen, valtuuttaminen, työntekijän poistuminen ja pitkä poissaolo töistä). Prosessikuvausten perusteella on helppo tunnistaa mm. työllistävät manuaaliset vaiheet, pullonkaulat ja epäjatkuvuudet.
- Kuvaa ratkaisun reunaehdot. Kuvaa käyttäjä- ja pääsynhallinnan reunaehdot, kuten omaan ympäristöön integroituvat kumppanien järjestelmät, käytettävät Suomi.fi -palvelut (esim. tunnistus ja valtuudet) sekä lainsäädännöstä (esim. tietosuoja-asetus) nousevat vaatimukset. Tätä kautta tiedät, mikä on liikkumavara IAM-ratkaisuarkkitehtuurin suunnittelussa.
- Suunnittele IAM-tavoitearkkitehtuuri. IAM-tavoitearkkitehtuuri kuvaa maalin, johon IAM-kehityksessä halutaan mennä. Nykytilaa kuvatessa esiin on jo varmasti tullut asioita, joita halutaan kehittää. Tätä kautta kannattaa tavoitetilan suunnittelu aloittaa muotoilemalla selkeät IAM-kehityksen tavoitteet. Näitä voivat olla esimerkiksi kertakirjautumisen ja identiteetinhallinnan käyttöönotto sekä peruskäyttöoikeuksien myöntäminen automaattisesti. Tavoitteet konkretisoidaan tavoitetilan arkkitehtuurikuvilla. Arkkitehtuurissa kuvataan lähdejärjestelmät (joiden tietoihin käyttäjät ja mahdollisesti myös käyttöoikeudet perustuvat) sekä kohdejärjestelmät (joiden käyttäjiä ja käyttöoikeuksia hallintaan). Kuvaa myös IAM-komponentit, joille oletettavasti on tarvetta (esim. tunnistus, identiteetinhallinta, roolipohjainen käyttövaltuushallinta ja kertakirjautuminen) sekä näiden tietovirrat muihin järjestelmiin. Laadi myös aiemmin tehdyistä prosessikuvauksista tavoitetilan versiot tässä vaiheessa, niin kaikille on selvää mikä toiminnassa tulee muuttumaan.
- Suunnittele etenemispolku. Etenemispolku ottaa kantaa erityisesti siihen, mitä IAM-komponentteja otetaan käyttöön ja missä vaiheessa sekä missä järjestyksessä kohdejärjestelmät tuodaan keskitetyn IAM:in piiriin. Etenemispolussa IAM-kehitys kannattaa palastella hallittavan kokoisiin palasiin, jotka voidaan toteuttaa projekteissa. Kohdejärjestelmien tuontiin voi mennä paljonkin aikaa, riippuen esimerkiksi kohdejärjestelmien määrästä ja käytettävästä identiteetinhallintatuotteesta.
- Kuvaa ja ohjeista IAM-ratkaisu tuleville kehitysprojekteille. Tavoitteena jatkossa pitäisi olla, että uudet käyttöönotettavat tietojärjestelmät hyödyntävät yhteisiä IAM-komponentteja, eivätkä kehitä omia käyttäjä- ja pääsynhallinnan ratkaisuja (ellei ole aivan pakko). Tätä varten tarvitaan selkeä ohjeistus, jossa kerrotaan käytännönläheisesti, mitä uuden tietojärjestelmän kehityksessä tai hankinnassa tulee huomioida, että käyttäjä- ja pääsynhallinta tulee toteutettua yhteisen mallin mukaisesti.
Toki IAM-arkkitehtuuri ei ole ainoa dokumentaatio, joka IAM-kehityksen yhteydessä kannattaa laatia. Muuta välttämätöntä dokumentaatiota on paljonkin, esimerkiksi tekninen suunnittelu konfiguraatio- ja integraatiokuvauksineen sekä käyttäjien ohjeet. Jos arkkitehtuurikuvaukset on laadittu kunnolla, on muun dokumentaation tuottaminen helpompaa.
Tutustu myös maksuttomiin IAM-materiaaleihimme!
Webinaarit
IAM-arkkitehtuurin kuvaaminen käytännössä
Onnistu käyttäjä- ja pääsynhallinnan (IAM) kehittämisessä
IAM:sta apua GDPR valmistautumiseen
Webinaarien tallenteet ovat saatavilla BrightTALK-palvelussa (vaatii ilmaisen rekisteröitymisen).
White Paperit
WHITE PAPER 01/16 IAM haltuun ymmärtämällä kokonaisuus
WHITE PAPER 02/16 Näin onnistut IAM:in käyttöönotossa