Skip to main content

29 Tekniikkaa

29Tekniikka logo

Microsoft Entra ID -palvelut ja identiteetinhallinta

Käyttäjätunnukset ovat nykyään se paikka, johon hyökkäykset kohdistuvat ensimmäisenä. Ei palomuuriin, ei palvelimiin, ei sovelluksiin. Tunnuksiin. Jos hyökkääjä saa käsiinsä toimivan tunnuksen ja siihen liittyvät oikeudet, hän on sisällä. Kaikki muu on yksityiskohtia.
Microsoft Entra ID on se järjestelmä, joka hallitsee näitä tunnuksia Microsoft-ympäristössä. Se tunnettiin aiemmin nimellä Azure Active Directory, ja nimi vaihdettiin vuonna 2023. Nimen vaihdos ei ollut kosmeettinen. Entra ID ei ole pelkästään hakemisto, jossa käyttäjät ovat. Se on joukko palveluita, jotka hallitsevat sitä, kuka pääsee mihin, millä ehdoilla ja milloin.
Tässä tekstissä käydään läpi sitä, mitä Entra ID:llä oikeasti tehdään, mitkä osat siitä ovat olennaisia ja missä kohdissa organisaatiot kompastuvat.

Mitä Entra ID on ja mitä se ei ole

➠ Entra ID on pilvipalvelu, joka toimii Microsoftin infrastruktuurissa. Se ei ole sama asia kuin perinteinen Active Directory, vaikka ne usein sekoitetaan keskenään. Active Directory on edelleen se, joka pyörii organisaation omilla palvelimilla ja hallitsee Windows-työasemia ja tiedostojakoja. Entra ID on se, joka hallitsee pilvipalveluiden käyttöä – Microsoft 365, Azure, Teams, SharePoint ja niin edelleen.
➠ Nämä kaksi järjestelmää elävät usein rinnakkain. Käyttäjä kirjautuu työasemaansa Active Directoryn kautta ja pilvipalveluihin Entra ID:n kautta. Näiden välinen synkronointi on oma kokonaisuutensa, ja se on yksi niistä asioista, joissa menee helposti pieleen.
➠ Entra ID ei ole pelkästään käyttäjähakemisto. Siihen kuuluu useita osia, joita voi ottaa käyttöön erikseen tai yhdessä. Näitä ovat muun muassa monivaiheinen todennus, ehdollinen käyttöoikeus, identiteettien suojaus, etuoikeutettujen identiteettien hallinta, ulkoisten identiteettien hallinta ja identiteettien hallintakehys.
➠ Jokainen näistä ratkaisee eri ongelman. Yhdessä ne muodostavat kokonaisuuden, joka määrittelee sen, miten organisaatio hallitsee identiteettejä.

Monivaiheinen todennus – se perusasia, joka on yhä kesken

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 – se osa, jota harva käyttää täysimääräisesti

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.

Identiteettien suojaus – automaattinen riskien arviointi

➠ Identity Protection on Entra ID:n osa, joka arvioi kirjautumisten riskitasoa automaattisesti. Se katsoo useita signaaleja – sijaintia, laitetta, selainta, käyttäytymistä – ja päättelee, onko kirjautuminen todennäköisesti legitimiteetti vai ei.
➠ Jos riskitaso on korkea, voidaan määritellä, että kirjautuminen estetään tai että käyttäjältä vaaditaan lisätodennus. Jos riskitaso on keskitaso, voidaan vaatia salasanan vaihtaminen. Jos riskitaso on matala, kirjautuminen sallitaan normaalisti.
➠ Tämä toimii parhaiten yhdessä ehdollisen käyttöoikeuden kanssa. Identity Protection antaa signaalin, ehdollinen käyttöoikeus määrittelee, mitä signaalista seuraa.
➠ Ongelma on se, että moni organisaatio ei ole ottanut Identity Protectionia käyttöön lainkaan. Se on lisenssikysymys. Ominaisuus vaatii Entra ID P2 -lisenssin, joka on kalliimpi kuin peruslisenssi. Mutta jos organisaatiolla on jo Microsoft 365 E5 -lisenssi, Identity Protection sisältyy siihen. Moni ei tiedä tätä.

Etuoikeutettujen identiteettien hallinta

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.

Ulkoisten identiteettien hallinta

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.

Hybridi-identiteetti – se osa, joka on aina monimutkainen

➠ Jos organisaatiolla on sekä paikallinen Active Directory että Entra ID, nämä kaksi pitää saada keskustelemaan keskenään. Tämä tapahtuu yleensä Entra Connect -työkalulla, joka synkronoi käyttäjät ja ryhmät paikallisesta hakemistosta pilveen.
➠ Tämä synkronointi on yksi niistä asioista, jotka näyttävät yksinkertaisilta mutta eivät ole. On olemassa useita eri tapoja toteuttaa se. On olemassa useita eri tapoja määritellä, mitä synkronoidaan ja mitä ei. Ja on olemassa useita eri tapoja, joilla synkronointi voi mennä pieleen.
➠ Tyypillisiä ongelmia ovat esimerkiksi se, että synkronointi hidastuu tai pysähtyy, kun käyttäjiä on tarpeeksi. Tai se, että synkronointi ylikirjoittaa pilvessä tehdyt muutokset. Tai se, että synkronointi ei ole ollut päällä viikkoon eikä kukaan ole huomannut.
➠ Nämä eivät ole teoreettisia ongelmia. Ne ovat asioita, joita näemme säännöllisesti, kun käymme läpi organisaatioiden ympäristöjä.

Missä organisaatiot kompastuvat

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.

Miten työ etenee

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.

Keitä me olemme

➠ Teemme tätä työtä itse. Emme alihanki projekteja eteenpäin. Se kuka myy on se joka tekee.
➠ Kerromme rehellisesti, jos jokin ei ole realistista. Jos nykyinen konfiguraatio on riittävä eikä sitä kannata muuttaa, sanomme sen. Jos jokin korjaus vaatii enemmän kuin mitä organisaatiolla on resursseja, sanomme sen.
➠ Emme myy sinulle sitä mitä