Tunnistamisen yhden luukun periaate

Onneksi, suureksi onneksemme salasana on vähitellen katoava menetelmä sen varmistamisessa, että palvelua käyttää vain ne henkilöt, joille se on tarkoitettu. Salasana on peräisin ATK:n arkaaiselta kaudelta. Silloin järjestelmiä oli vähän ja käyttäjät olivat motivoituneita jokaiseen tekniseen yksityiskohtaan. Sittemmin ATK kehittyi IT:ksi ja AI:ksi. Palveluja on paljon ja niin on myös salasanoja.

Vielä ATK:n renessanssissa tietoturva-asiantuntijat suosittelivat muistisääntöjä vaikeasti arvattavien salasanojen hallintaan. Toteutettiin salakirjoituksella suojattuja salasanaholveja, jotka olivat synkronoitavissa renessanssin tuomien pilvessä sijaitsevien tiedostonjakopalvelujen avulla.

ATK:n valistuksen ajassa pyritään salasanoista eroon kokonaan. Vielä ei olla siinä modernissa maailmassa, jossa ne olisivat jo historiaa, mutta suunta on hyvä. Internet tarjoaa lisääntyvässä määrin luotettavia tunnistuspalveluja, joissa salasanaa tarvitsee käyttää vain harvoin. Esimerkiksi Microsoft Office Live -käyttäjät saavat puhelimeensa herätteen yrittäessään tunnistautua. Salasanan käytön voi ohittaa tai tunnistustapahtumaa vahvistaa kuittaamalla kirjautumistapahtuma puhelimen tunnistussovelluksella.

Palvelut kytketään tunnistusmenetelmiin federoinniksikin kutsutulla menetelmällä. Aivan kuten Margaretan aloitteesta Kalmarissa syntynyt kauppaunioni, federoitaessa palvelut sopivat tunnistusratkaisun kanssa luottosuhteen. Luottosuhteen avulla palveluun päästään kirjautumaan tunnistusmenetelmän avulla luotettavasti samoin, kuin federaation piirissä oleviin muihinkin palveluihin. Kun federoinnin piirissä on useita palveluja, käyttäjä ei tarvitse salasanaa niihin kaikkiin erikseen, vaan ainoastaan menetelmän tunnistautua luotettavasti tunnistusratkaisuun.

Azure AD Applikaatiot esimerkiksi mahdollistavat palveluille käyttää edellä mainittua Microsoft Live -kirjautumista. Samalla organisaation tunnuksella, jolla käytetään Outlook-sähköpostia, voidaan kirjautua yrityksen kaikkiin palveluihin.

Mutta kuinka toimia asiakkaiden tunnistamisen osalta? Yrityksen työntekijöiden osalta ollaan salasanojen arkaaisesta ATK-ajasta jo pitkällä edistyksen ajassa, mutta liian moneen verkkokauppaan ja oma asiointi -sivustoon asiakkaat joutuvat vielä kirjautumaan perinteisin tavoin.

Kuluttaja-asiakkaillekin on federoituja tunnistusratkaisuja. Myös Googlen, Microsoftin ja Applen kuluttajatunnuksia varten on omat tunnistusratkaisunsa. Haasteeksi nykyajan kehittäjälle tulee, että palvelun liittäminen yhteen tunnistusratkaisuun ei riitä. Vaikka melkein kaikilla on Google-tunnus, kaikki eivät sitä halua käyttää, vaan käyttävät mielummin vaikkapa IPhone-puhelimeensa mieltämäänsä Applen tunnusta.

Tunnistusratkaisujen konsolidointi on mahdollista. Puhutaan tunnistamisen broker-mallista. Tunnistusmenetelmät voidaan konsolidoida yhden brokerin taakse, jolloin palvelun ei tarvitse muodostaa luottosuhdetta kuin yhteen kohteeseen: brokeriin. Broker huolehtii tunnistuspalveluihin kytkeytymisen. Se tekee helpoksi lisätä tai vaihtaa tunnistuspalveluja ilman, että varsinaiseen palveluun, kuten verkkokauppaan tai oma asiointi -palveluun tarvitsee tehdä muutoksia.

Parhaillaan broker-ratkaisuun on kytketty identiteettien hallintaratkaisu, jolloin myös asiakkaiden tunnistamisessa saadaan samat edut, jotka ovat tuttuja yritysten IdM-ratkaisuista. Asiakkaat voivat kuitenkin edelleen tunnistautua tutuilla tunnistuspalveluilla ja heidän ei tarvitse muistella tai tallentaa erillisiä salasanoja.

Miten ollakkaan, tällainen broker-toteutus on saatavilla! Jos olet kiinnostunut kuulemaan ja näkemän lisää, tiedän muutamia tosi mukavia kavereita, jotka ovat innoissaan demonstroimaan asiaa.