Monivaiheinen todennus eli MFA on yksinkertainen ajatus. Pelkkä salasana ei riitä. Pitää olla toinenkin todiste. Puhelin, avain, biometrinen tunniste, jotain sellaista, jota pelkällä salasanalla ei saa.
Microsoft on tarjonnut MFA:ta vuosia, ja se on ollut oletuksena uusissa tenanteissa jo pidempään. Silti monessa organisaatiossa MFA on käytössä vain osalle käyttäjistä, tai se on käytössä mutta sen voi ohittaa.
Tämä on ongelma. Tutkimukset osoittavat, että valtaosa tietomurroista estettäisiin, jos MFA olisi käytössä kaikilla käyttäjillä ja kaikissa kirjautumisissa. Tämä ei ole mielipide, se on mittaus.
Kun käymme läpi organisaation Entra ID -ympäristöä, ensimmäinen asia, jonka tarkistamme, on MFA:n kattavuus. Kysymme kolme asiaa. Onko MFA pakollinen kaikille käyttäjille. Onko se pakollinen kaikissa kirjautumisissa. Ja voiko sen ohittaa jollain tavalla.
Usein vastaus on, että MFA on käytössä mutta se ei ole pakollinen. Tai se on pakollinen mutta sitä ei valvota. Tai se on pakollinen mutta jollain käyttäjällä on poikkeus, koska joskus vuonna 2019 joku päätti että hän tarvitsee sellaisen.
Nämä poikkeukset ovat niitä, joihin hyökkääjät tarttuvat.
Ehdollinen käyttöoikeus on Entra ID:n keskeisin ominaisuus. Se määrittelee sen, millä ehdoilla käyttäjä saa kirjautua sisään. Ei pelkästään sitä, onko käyttäjällä oikeus, vaan sitä, missä tilanteessa oikeus toteutuu.
Käytännön esimerkki. Kirjautuminen Suomesta työasemalta, joka on organisaation hallinnassa, sallitaan pelkällä salasanalla. Kirjautuminen ulkomailta henkilökohtaiselta laitteelta vaatii MFA:n. Kirjautuminen maasta, jossa organisaatiolla ei ole toimintaa, estetään kokonaan. Kirjautuminen, jossa on havaittu epätavallista toimintaa, vaatii salasanan vaihtamisen ja MFA:n.
Monessa organisaatiossa ehdollinen käyttöoikeus on käytössä mutta vain osittain. On ehkä määritelty, että MFA vaaditaan, jos käyttäjä on ulkomailla. Mutta ei ole määritelty, mitä tapahtuu, jos käyttäjä on Suomessa mutta käyttää henkilökohtaista laitetta. Tai mitä tapahtuu, jos käyttäjätunnus on vuotanut ja sitä yritetään käyttää.
Tyypillisiä ehtoja ovat käyttäjän sijainti, laitteen tila, sovellus, johon ollaan kirjautumassa, ja riskitaso, joka on arvioitu kirjautumisen yhteydessä. Näiden perusteella voidaan määritellä, vaaditaanko MFA, sallitaanko kirjautuminen, estetäänkö se vai vaaditaanko jotain muuta toimenpidettä.
Tämä on sitä, mitä ehdollisella käyttöoikeudella tehdään. Se ei ole binäärinen sääntö, jossa kaikki sallitaan tai kaikki estetään. Se on joukko ehtoja, jotka yhdessä määrittelevät sen, mitä tapahtuu.
Nämä ovat niitä kohtia, joissa ehdollinen käyttöoikeus muuttuu pelkästä lisäominaisuudesta oikeaksi turvamekanismiksi.
Yksi suurimmista riskeistä missä tahansa ympäristössä on se, että jollain käyttäjällä on enemmän oikeuksia kuin hän tarvitsee. Tämä pätee erityisesti järjestelmänvalvojiin.
Entra ID:ssä on rooleja, joilla on laajat oikeudet. Global Administrator voi tehdä käytännössä mitä tahansa. Privileged Role Administrator voi myöntää itselleen tai muille mitä tahansa oikeuksia. Application Administrator voi hallita sovelluksia ja niiden käyttöoikeuksia.
Jos näitä rooleja on pysyvästi usealla käyttäjällä, riski on merkittävä. Jos yksi näistä tunnuksista varastetaan, hyökkääjä saa käytännössä täydet oikeudet.
Privileged Identity Management eli PIM ratkaisee tämän. Sen sijaan, että käyttäjällä olisi pysyvästi korkeat oikeudet, oikeudet myönnetään määräajaksi ja vain silloin, kun niitä tarvitaan. Käyttäjä pyytää oikeutta, perustelee miksi hän tarvitsee sen, ja oikeus myönnetään määräajaksi. Sen jälkeen se poistuu automaattisesti.
Tämä ei ole pelkästään tekninen kontrolli. Se on myös prosessi. Se pakottaa organisaation miettimään, kuka oikeasti tarvitsee mitäkin oikeuksia ja miksi.
Nykyaikaisessa ympäristössä käyttäjät eivät ole pelkästään organisaation omia työntekijöitä. He ovat myös kumppaneita, asiakkaita, alihankkijoita ja vierailijoita. Jokaisella näistä on omat tarpeensa ja omat riskinsä.
Molemmissa malleissa on omat haasteensa. B2B:ssä ongelma on se, että ulkoisia käyttäjiä kertyy helposti satoja tai tuhansia, eikä kukaan muista, ketkä he ovat ja mihin heillä on pääsy. B2C:ssä ongelma on se, että asiakkaiden tunnukset ovat alttiina samoille uhille kuin työntekijöiden tunnukset, mutta heitä ei voi pakottaa samoihin käytäntöihin.
Entra ID tukee kahta mallia ulkoisten identiteettien hallintaan. B2B-yhteistyö on tarkoitettu kumppaneille ja alihankkijoille. Siinä ulkoinen käyttäjä käyttää omia tunnuksiaan, jotka on liitetty organisaation hakemistoon. B2C puolestaan on tarkoitettu asiakkaille. Siinä käyttäjät rekisteröityvät itse ja heillä on omat tunnuksensa.
Kummassakin tapauksessa ratkaisu on sama. Pitää olla selkeä prosessi sille, miten ulkoisia käyttäjiä hallitaan. Milloin heidät lisätään, milloin heidät poistetaan, mitä he saavat tehdä ja miten sitä valvotaan.
Olemme nähneet monta Entra ID -ympäristöä. Osa on hyvin hoidettu, osa ei. Tässä on yleisimmät asiat, jotka menevät pieleen.
MFA on käytössä mutta sitä ei valvota. Kukaan ei tiedä, kuinka moni käyttäjä on rekisteröinyt toisen todennusmenetelmän ja kuinka moni ei.
Ehdollinen käyttöoikeus on käytössä mutta käytännöt ovat vanhentuneet. Ne on määritelty silloin, kun organisaatio oli erilainen, eikä niitä ole päivitetty sen jälkeen.
Vieraat käyttäjät kertyvät eikä kukaan poista niitä. Ne, jotka ovat lähteneet organisaatiosta, jäävät voimaan. Ne, jotka eivät enää tarvitse pääsyä, säilyttävät sen.
Järjestelmänvalvojan roolit ovat pysyviä. Ne myönnetään kerran, eikä niitä oteta pois. Kukaan ei muista, kenellä on mitä.
Lokitus on päällä mutta lokit eivät mene minnekään. Ne ovat olemassa mutta kukaan ei katso niitä. Poikkeukset jäävät huomaamatta.
Nämä ovat asioita, joita voi korjata. Ne eivät vaadi uutta teknologiaa. Ne vaativat sen, että joku katsoo, mitä ympäristössä on ja miten se on konfiguroitu.
Aloitamme kartoituksella. Käymme läpi, mitä Entra ID:n ominaisuuksia on käytössä ja miten ne on konfiguroitu. Tämä vie yleensä muutaman päivän riippuen ympäristön koosta.
Sitten teemme korjaussuunnitelman. Priorisoimme ne asiat, joilla on suurin vaikutus ja jotka ovat nopeimmin toteutettavissa. Osa korjauksista on teknisiä, osa prosessimuutoksia.
Sen jälkeen tunnistamme puutteet. Mitä puuttuu, mitä on väärin konfiguroitu, mitä ei valvota.
Toteutus etenee vaiheittain. Jokaisen vaiheen jälkeen tarkistamme, että muutokset toimivat eivätkä riko mitään olemassa olevaa.