Näin vältät jouluisen identiteettikriisin

Joulu on rauhoittumisen, hiljentymisen ja perheen keskeisen yhdessäolon aikaa, irtiotto arjesta. Silloin on hyvää aikaa miettiä myös identiteettien hallintaan ja käyttöön liittyviä asioita.

Onko meillä tarvetta enää omalle identiteetin ja pääsyn hallintajärjestelmälle (IAM)? Vai voisiko saman saada ensisijaiselta pilvipalvelun tarjoajalta? Pysyvätkö identiteetit pilvessä turvassa? Ostaisiko kokonaispalvelun avaimet käteen -periaatteella vai tekisikö asiat itse? Entä ovatko meidän JML-prosessimme (joiners-movers-leavers) kunnossa? Onko käyttäjillä liikaa käyttöoikeuksia tai liian vähän? Onko kaikki käyttäjäryhmät otettu huomioon, myös asiakkaat? Onko kaikki identiteetteihin liittyvät riskit listattu? Entä ovatko käytettävyys ja käyttökokemus kohdallaan? Kuinka automaatiota voisi lisätä? Onko kustannustaso oikea? Tulevatko liiketoiminnan tarpeet hoidettua? Pystymmekö reagoimaan riittävän nopeasti mihin tahansa muutoksiin?

Hei oikeasti! Näitä on turha miettiä jouluna!

Muutama huomio ja vinkki hautumaan siihen ajankohtaan, kun lomakauden jälkeen asioita aletaan taas miettiä ja suunnitella:

• IAM, IDM, AC, MFA, SSO, IGA, PAM, PIM, PUM, RBAC, ABAC, ZSP, JIT jne. Lyhenteiden lista on loputon.  Mitä nämä käytännössä tarkoittavat meille? Liian kryptistä ja mystistä. Identiteetinhallinnan oikeat vastaukset eivät löydy teknologiatoimittajien lyhennehässäköistä.
  .
• Myöskään analyytikoiden trendit ja teknologiatoimittajien asettaminen paremmuusjärjestykseen eivät tarjoa käytännönläheistä lähestymistapaa. Minkä käytännön ongelman Zero Trust esimerkiksi ratkaisee? Analyytikoiden maagiset nelikentät ja muut vastaavat lähinnä kertovat, kuinka paljon tietyn teknologiatuotteen toimittaja on investoinut kyseiseen analyytikkoon.
  .
• Teknologia ratkaisee ongelmia ja tuo lisäarvoa liiketoimintaan, mutta silti asioita ei kannata kehittää teknologialähtöisesti. Jos näin tehdään, ajaudutaan pois raiteilta heti lähdössä ja lopputulos yleensä tuottaa lisäarvoa vain kustannuksiin. Teknologian ja tuotteen ostaminen on vain pieni osa kokonaisuutta.
  .
• Pidä kustannukset, käyttäjäkokemus, tehokkuus ja tietoturva tasapainossa. Riskipohjainen malli on tässä hyvä apuväline, kun vielä muistaa, että riskejä on monenlaisia.
  .
• Tunnista ja ota huomioon erilaiset käyttäjäryhmät mahdollisimman ajoissa. Näin pystyt minimoimaan erilaisten täsmäratkaisuiden tarpeen ja rakentamaan kokonaisvaltaisen ratkaisun. Nykyisin käyttäjäryhmien rajat ovat todella häilyviä. Sama henkilö voi käyttää palveluita työntekijänä, asiakkaana tai vaikka teknisenä tukena. Tasapaino järkkyy, jos meillä on eri identiteettiratkaisu jokaista ryhmää varten.
  .
• Vältä päällekkäisyyksiä ja monimutkaisuutta. Identiteetit eivät ole oma saarekkeensa tai siilonsa eli niitä varten ei tarvita omaa erillistä käyttäytymisanalytiikkaa, tekoälyä, lokienhallintaa tai mitään muutakaan, mikä voi olla yhteistä kokonaisuudelle. Usein auttaa se, että otetaan pari askelta taakse ja ajatellaan kokonaisuutta hieman tarkemmin.
  .
• Pääkäyttäjät ja administraattorit ovat yksi käyttäjäryhmä, joka pitää huomioida, mutta heitäkään varten ei tarvita kokonaan erillistä ja irrallista järjestelmää. Privileged Access Management (PAM) voidaan hyvin ajatella tämän käyttäjäryhmän liiketoimintasovelluksena, joka integroidaan identiteettijärjestelmiin kuten muutkin liiketoimintasovellukset.
  .
• Vanhoja prosesseja ei kannata sellaisinaann automatisoida. Sen sijaan ensin pitää kyseenalaistaa, minkä jälkeen uudistetaan, selkeytetään ja yksinkertaistetaan prosessit. Sitten toteutetaan toiminta työkaluihin mukauttaen ja säätäen prosesseja vielä tässäkin vaiheessa, sillä kaikkeen eivät työkalut taivu ja loputon räätälöinti on todella kallista.
  .
• Onko organisaatiolla riittävät kyvykkyydet hoitaa identiteettiasiat itse? Tätä kannattaa pohtia tarkkaan ja pitkällä tähtäimellä. Lyhytkestoinen ulkopuolinen apu saattaa vain pahentaa asioita, sillä jatkuvan muutoksen hallitseminen on elintärkeää liiketoiminnan kannalta.
  .
• DevOps? Taas joku trendisana, joka ei ole pohjimmiltaan jatkuvaa muutoshallintaa kummallisempaa. Varaudu, suunnittele ja resursoi muutoshallinta huolellisesti. Ketterät toimintatavat, joita DevOps tarjoaa eivät ole huono asia. Olivat menetelmät mitä tahansa, muutoshallinta ei toimi ilman budjettia ja osaavia resursseja.
  .
  Ja vielä tärkein pointti lopuksi:
  .
  
• Älä koskaan unohda tai vähättele käyttäjäkokemuksen merkitystä. Kaikki tehty työ ja käytetty raha ovat hukkaan heitettyä, jos käyttäjät eivät ole tyytyväisiä ja käytä järjestelmiä. Tyytymätön käyttäjä löytää aina kiertotien, joka aiheuttaa tietoturvaongelmia ja lisää suunnittelemattomia kustannuksia.

Näillä evästyksillä toivotan Hyvää Joulua sekä menestyksekästä ja turvallista tulevaisuutta!