top of page

Azure AD:n tunnistautumismenetelmien uusi moderni hallinta


Azure AD tunnistautumismenetelmät

Azure Active Directoryn (Azure AD) käyttöön sallittuja tunnistamismentelmiä on hallittu perinteisesti Multi-Factor Authentication (MFA, monivaiheinen tunnistaminen) asetuksilla sekä SSPR-menetelmien asetuksilla (Self-Service Password Reset, salasanan vaihto itsepalveluna). Jatkossa asetukset ovat keskitetty yhteen paikaan, ns. Authentication Method Policyihin. Nämä selkeyttävät ylläpitäjien työtä ja mahdollistavat menetelmien yksityiskohtaisemman hallinnan tarjoten samalla monipuolisempia tapoja tunnistaa käyttäjät. Tässä blogissa kuvataan miten uudet menetelmät otetaan käyttöön ja käsitellään lyhyesti eri menetelmät asetuksineen.


Tämä on yksi pieni esimerkki asioista, joita toteutamme asiakkaidemme Azure AD -ympäristöihin osana hallittuja- ja jatkuvia pilvi-infran palveluitamme.


Huomioitavaa ja rajauksia


Uusi tapa hallita asetuksia on tällä hetkellä vielä ns. preview vaiheessa. Preview:ssä olevat ominaisuudet eivät ole vielä Microsoftin puolelta täysin loppuun asti viilattuja, mutta kokemusten mukaan hyvin toimivia.


Lisäksi suosittelemme tässä vaiheessa uusia tunnistamismenetelmiä vain organisaatioille, joilla on Conditional Access toiminnallisuus lisensoituna. Tämä kuuluu Azure AD Premium P1 tai Premium P2 tilauksiin, jotka yleensä lisensoidaan esimerkiksi Microsoft 365 Business Premium tai Microsoft 365 F3/E3/E5 -tilausten kautta. Tämä suositus johtuu siitä, että vanhalla menetelmällä voi määrittää MFA-vaatimukset käyttäjäkohtaisesti. Uudella menetelmällä vaatimus taas tulee kaikille, eikä tarkempaa hallintaa voi tehdä ilman Conditional Access policyjä (ainakaan vielä).


Suosittelemme lähes poikkeuksetta, että käyttäjille lisensoidaan aina vähintään Azure AD P1 tavalla tai toisella.


Mitä eri tunnistusmenetelmiä Azure AD mahdollistaa?


Microsoft 365-ympäristössä tunnistuksesta tyypillisesti vastaa Azure AD. Sen tarjoamat mahdolliset tunnistusmenetelmät on listattu alla hyvien ja huonojen puolien kera. Huom. taulukossa maininta MFA-kalastelusta tarkoittaa, että menetelmä ei kestä sitä, jos käyttäjä kalastelun yhteydessä tunnistautuu monivaiheisesti. Turvallisemmat menetelmät vaatisivat sen, että käyttäjän lisäksi saataisiin käyttäjän laitetta huijattua.

Menetelmä

Kuvaus

Kommentti

FIDO2 security key

​FIDO2-avain, fyysinen laite, esim. YubiCo tai Thales

Turvallinen, kalastelun kestävä ja salasanattoman kirjautumisen mahdollistava menetelmä. Suositeltava, mutta avaimet maksavat.

​Microsoft Authenticator

Microsoftin Authenticator-sovellus iOS- ja Android-puhelimille

Suositeltava menetelmä yleiseen käyttöön, erityisesti number-matching-tilassa. MFA-kalasteltavissa. Mahdollistaa salasanattoman kirjautumisen.

SMS

Koodi tekstiviestinä ennalta rekisteröityyn numeroon.

Ei suositella ainakaan ensisijainena kirjautumisvaihtoehtona, vaikka Suomessa ns. SIM-swapping onkin epätodennäköinen hyökkäys. Käytettävissä varalla jos ei muuta ole. Ei kestä MFA-kalastelua.

Temporary Access Pass

Väliaikainen pääsyavain

Ylläpidon työkalu, erityisesti hyvä onboarding-tilanteisiin tai tilanteisiin joissa loppukäyttäjä on unohtanut MFA-laitteensa kotiin tai kadottanut sen. Ei kestä MFA-kalastelua. Mahdollistaa voimassa ollessaan salasanattoman kirjautumisen.

Third-party software OATH tokens

Itse kutsuisin TOTP-key:ksi, mutta tämän alle mahtuu ehkä muutakin. Time-based One-Time Password eli TOTP-avaimena toimii 30 sek välein vaihtuva numerokoodi.

TOTP on avoin IETF:n määrittelemä menetelmä ja sen voi toteuttaa useilla eri menetelmillä, esim. puhelimissa MS Authenticatorilla, Google Authenticatorilla tai Authy:llä, mutta TOTPia toteuttavia ohjelmia saa myös tietokoneille erikseen sekä salasanahallintaohjelmistoissa sisäänrakennettuna.

Hyvä lisämenetelmä muiden rinnalle. Ei kestä MFA-kalastelua. Käyttö harkiten, koska mahdollistaa seed-arvojen vuotamisen mikäli käyttäjiä onnistutaan höynäyttämään riittävästi.

Voice call

Puhelu ennalta rekisteröityyn numeroon, “paina #”.

Ei suositella, mutta sopii joihinkin tilanteisiin, esim. jos integroidaan sovellus joka ei kykene vastaanottamaan numerokoodeja. Ei kestä MFA-kalastelua.

Email OTP

Koodi ennalta rekisteröityyn sähköpostiosoitteeseen.

Tämä on käytettävissä vain yhtenä SSPR (salasanojen itsepalveluna vaihtaminen) tunnistamiskeinona. Siihen ok, jos muuten ei löydy kahta tunnistamismenetelmää kaikilta käyttäjiltä.

Certificate-based authentication

Varmenteisiin perustuva tunnistus. Esim. toimikortti.

Tapauskohtaisesti käyttöön. Organisaatio tietänee käyttääkö esim. toimikortteja. Ei käyttöön ilman tarvetta, sekoittaa käyttäjiä.

Security questions

“Kysymys-vastaus” menetelmä, käyttäjä antaa vastauksia kysymyksiin etukäteen ja samat vastaukset pitää löytyä tarkistusvaiheessa.

EI TARJOLLA Preview-vaiheessa. “Kysymys-vastaus” menetelmä. Ei suositella käyttöön, menetelmä on heikko.


Uusien hallintamenetelmien käyttöönotto


Uusiin hallintamenetelmiin (Authentication Method Policy) siirtymä tapahtuu korkealla tasolla seuraavasti:


Vaihtoehto 1:

  1. Onko tarvetta muuttaa asetuksia nykyisestä? Päätä tältä pohjalta uudet asetukset.

  2. Tarkista, että combined security info registration on käytössä (yleensä on)

  3. Tarkista, että ns. break glass -tunnus on olemassa

  4. Toteuta halutut menetelmät uudella tunnistuspolitiikalla

  5. Tiedota käyttäjät, koska muutos saattaa vaatia käyttäjiä rekisteröimään uusia tunnistamismenetelmiä

  6. Käynnistä migraatio

  7. Poista legacy-asetukset käytöstä

  8. Viimeistele migraatio

Vaihtoehto 2:

Ota yhteyttä Bitmoreen 😊


Seuraavaksi käymme läpi edellä mainitut vaiheet yksityiskohtaisemmin.


1. Päätös menetelmistä


Tässä lähden oletuksesta, että käyttöön on valittu Bitmoren suosittelemat menetelmät eli FIDO2, Microsoft Authenticator, Temporary Access Pass, Third-party software OATH tokens ja mahdollisesti myös SMS.


2. Combined Security Info Registration tarkistus


Combined Security Info Registration on syytä olla päällä. Toiminto yhdistää tunnistamiseen ja salasanan vaihtoon itsepalveluna (SSPR) tapahtuvien tunnistamismenetelmien rekisteröinnin. Ilman tätä toimintoa käyttäjät saavat turhan monia toisistaan erillisiä pyyntöjä tunnistamismenetelmien lisäämiseen tunnuksilleen. Uudessa tavassa käyttäjät lisäävät menetelmät yhdellä kerralla osoitteessa https://myaccount.microsoft.com/.


Yleensä asetus on uusilla Azure AD -tenanteilla oletuksena käytössä ja vanhoille sitä on asetettu Microsoftin toimesta käyttöön 1.10.2022 alkaen, mutta kirjoitushetkellä on nähty joitakin Azure AD-tenantteja, joilla se ei ole ollut pakotettu käyttöön. Tarkista tämä Azure AD:n hallintakäyttöliittymästä osoitteessa https://portal.azure.com/#view/Microsoft_AAD_IAM/FeatureSettingsBlade. Jos asetusta ei näy, se on jo käytössä.


3. Break Glass -tunnus


“Tulipalon" sattuessa ns. riko lasi- tai break glass -tunnus on syytä olla olemassa, vaikka autentikointimetodeja ei muuttaisikaan. Tunnuksen ajatuksena on päästä kirjautumaan järjestelmään, vaikka tunnistamismenetelmät kuten MFA olisi häiriön vaikutuksen alaisena tai tunnistusvaatimuksiin olisi tehty virhe ylläpitäjän toimesta. Tunnukselle toteutetaan tätä varten poikkeukset kaikkiin varmentamissääntöihin, sen käyttöä valvotaan ja lisäksi tunnus suojataan erittäin vahvalla salasanalla. Tunnuksen kirjautumissijainnin voi ja kannattaa rajata ennalta määrättyjen turvallisten IP-osoitteiden joukkoon. Voit lukea lisää aiheesta esimerkiksi täältä: https://learn.microsoft.com/en-us/azure/active-directory/roles/security-emergency-access


4. Määrittele uusi Authentication Methods Policy


Bitmoren suosittelemilla menetelmillä (FIDO2, Microsoft Authenticator, Temporary Access Pass ja Third-party software OATH tokens) asetukset tehdään siirtymällä Azure AD:n hallintakäyttöliittymässä kohtaan Security → Authentication Methods, eli https://portal.azure.com/#view/Microsoft_AAD_IAM/AuthenticationMethodsMenuBlade/~/AdminAuthMethods


Huom! Kaikkia menetelmiä voidaan osoittaa/rajata käyttäjäryhmittäin, ja rajausta tuleekin käyttää tarpeen mukaan. Tässä oletetaan yksinkertaisuuden vuoksi että menetelmät osoitetaan kaikille käyttäjille.


4.1 FIDO2 security keys = Sallittu

Azure AD FIDO2 asetukset

Mikäli tarkoituksena ei ole rajata FIDO2 key toimittajia, asetuksissa ei rajata AAGUID:eja:

Azure AD FIDO2 asetukset

4.2. Microsoft Authenticator


Microsoftin tunnistussovellus puhelimille on erinomainen, joskin sen asetukset voivat vaatia huomiointia. Suositus on käyttää Authenticatoria Passwordless -tilassa, mutta myös “any/push” ovat mahdollisia ja varsinkin siirtymävaiheessa suotavia. On myös tilanteita, joissa passwordless ei kirjoitushetkellä ole käyttökelpoinen, esim. jos Azure AD MFA käytetään monivaiheseen tunnistamiseen vaikkapa RDP-kirjautumisissa.


Azure AD Authenticator asetukset

Bitmore suosittelee käyttämään ns. Number Matching -toimintoa, mikäli mahdollista. Siinä pelkän “ok, olen kirjautumassa” -hyväksynnän sijaan käyttäjälle näytetään kaksi numeroa kirjautumisruudulla, jotka syötetään Authenticator-sovellukseen. Tällä vältetään vahingossa tapahtuvat hyväksynnät.


Azure AD Authenticator asetukset

Uutena lisäksi tässä kohtaa voi sallia "Companion Apps", joka kirjoitushetkellä tarkoittaa Microsoft Outlook:in "Authenticator Lite"-toiminnallisuutta. Tämä on suositetavaa sallia, erityisesti BYOD-käyttäjiä ajatellen. Organisaation laitteita käyttäviltä voidaan ja kannattaa edelleen vaatia Microsoft Authenticatorin käyttämistä.


4.3. SMS = sallittaan (tietyin ehdoin)


SMS voidaan sallia mikäli se on organisaatiolle välttämätöntä. Suomalaisilla liittymillä kotimaisissa verkoissa menetelmä on suhteellisen turvallinen, mutta on maita ja verkkoja joissa ns. SIM swap on arkipäivää. Suositus on olla käyttämättä menetelmää, jos mahdollista. Jos SMS sallitaan, jättäisin ainakin “Use for sign-in” eli ns. first-factor tunnistamisen sillä pois, jolloin SMS voi käyttää vain toissijaisena tunnistamismenetelmänä.


Vaikka Suomessa ns. SIM-swap hyökkäys ei ole kovin todennäköinen, yhtenä riskinä SMS:n käytölle todentamisemenetelmänä pidän mobiililaitteisiin kohdistuvia haittaohjelmia, jotka hankkivat pääsyn SMS-viesteihin. Suomessa nähtiin vastikään FluBot-haittaohjelmakampanja, joka levisi varsin laajasti Android-laitteisiin.


Azure AD SMS asetukset

4.4. Temporary Access Pass = sallittu


Temporary Access Pass, tuttavallisesti TAP on ehdottoman suositeltavaa ottaa käyttöön. Menetelmällä Azure AD:n ylläpitäjä voi luoda käyttäjälle väliaikaisen MFA-kelpoisen salasanan, jonka voimassaoloaika sekä käyttökerrat voidaan määrätä. Menetelmälle on kaksi erityistä käyttökohdetta:

  1. Väliaikainen apu käyttäjille, jotka ovat menettäneet muut tunnistamismenetelmänsä, ja jotka ylläpitäjä saa tunnistettua muilla keinoin

  2. Laitteiden ja palveluiden (kuten MFA:n) käyttöönotto tilanteessa, jossa käyttäjälle ei ole vielä saatu rekisteröityä muuta monivaiheisen tunnistamisen menetelmää, eli ns. muna-kana-tilanne.

MFA-menetelmien rekisteröintiä ja muuttamista varten on syytä vaatia monivaiheinen tunnistus, koska muuten MFA-kalastelussa onnistunut hyökkääjä pystyy rekisteröimään omat tunnistusmenetelmänsä ja siten helposti säilyttämään pääsynsä pidempään.


Azure AD Temporary Access Pass asetukset


4.5. Third-party software OATH tokens = sallittu


OATH (Open Authentication) menetelmä (Itse puhun TOTP:ista) voidaan ottaa käyttöön harkinnan jälkeen mikäli se sopii organisaation vaatimuksiin. Menetelmä mahdollistaa useiden muiden tunnistussovellusten käytön Microsoft Authenticatorin lisäksi, kuten esim. Google Authenticatorin ja Authyn.


Riippuen sovelluksesta ulkopuolinen taho voi saada tietoonsa ns. seed- tai siemenarvon, jolla koodi voidaan rekisteröidä. Riskinä on, että loppukäyttäjä ottaa käyttöön Authenticator-sovelluksen, joka vuotaa tietoja ulkopuolisille, joten tämä tulee ottaa huomioon MDM-hallinnassa ja käyttäjien kouluttamisessa.


Azure AD OATH Tokens asetukset

4.6. Puhelinsoitto (voice call) = sallittaan tietyin ehdoin


Puhelinsoitto on menetelmä, jossa käyttäjän rekisteröimään puhelinnumeroon soitetaan puhelu, ja käyttäjä kuittaa kirjautumisen painamalla “#”. Menetelmää voidaan käyttää kutakuinkin samoin rajoittein kuin tekstiviestiä. Suosittelen, että menetelmää ei sallita ainakaan kaikille käyttäjille vaan vain tarpeen mukaan.


Azure AD Voice call asetukset

4.7. Email OTP = sallitaan


Email OTP (One Time Password) on menetelmä, jossa käyttäjän ennalta rekisteröimään sähköpostiosoitteeseen lähetetään koodi, joka syötetään kirjautumisen vahvistamiseksi. Tätä menetelmää voi suositella, koska menetelmää voi käyttää vain salasanan resetoinnissa (SSPR) yhtenä tunnistamismenetelmänä. Mikäli muita menetelmiä on riittävästi, tämä voidaan jättää sallimattakin.

Azure AD Email OTP asetukset

4.8.Certificate-based authentication = sallitaan tarvitteassa


Varmenteilla tunnistaminen on erittäin luotettava, kalastelun kestävä menetelmä. Menetelmä suositellaan ottamaan käyttöön mikäli esim. toimikortteja aiotaan käyttää Azure AD -tunnistamiseen.


Azure AD Certificate-Based Authentication asetukset


5. Käyttäjien tiedotus


Riippuen lähtötilanteesta loppukäyttäjät saattavat saada “more information required” -kehotteen muutoksen jälkeen seuraavalla kirjautumiskerrallaan. Pidempään M365-käyttäjinä olleet käyttäjät todennäköisesti ovat tottuneet näkemään näitä kehotteita, mutta suosittelemme silti tiedottamaan muutoksesta.


Azure AD more information required -ilmoitus

6. Migraation käynnistys


Käynnistä migraatio, joka salliii vanhan ja uuden tavan menetelmien hallinnalle rinnakkain.


Azure Authentication method migraatio

7. Vanhojen määritysten poisto


Azure MFA ja SSPR asetuksien poisto

SSPR, Azure AD → Password reset, tarkista että "All" on valittu kohdassa “Self service password reset enabled”. https://aad.portal.azure.com/#view/Microsoft_AAD_IAM/PasswordResetMenuBlade/~/Properties


Azure AD SSPR asetukset

Password reset, Authentication Methods, tarkista, että menetelmiiä vaaditaan haluttu määrä (suositus:2), ja että tästä näkymästä on poistettu kaikki valinnat (tämä on ns. legacy-näkymä).




8. Viimeistele migraatio loppuun asti


Siirry kohtaan Azure AD → Security → Authentication Methods → Policies ja valitse “Migration Complete”

Azure Authentication method migraatio

Mikäli jokin vaatimus ei täyty, saat virheilmoituksen Manage migration -velholta. Esimerkiksi, jos vanhat menetelmät ovat vielä käytössä. Toimi virheilmoituksen mukaisesti korjataksesi tilanne.


Muutoksen jälkeen voit tarkistaa esim. vanhan SSPR-näkymän, jossa ei voi enää lisätä menetelmiä, vain valita montako tunnistusmenetelmää vaaditaan salasanan resetointiin. Suosittelemme vaatimaan kaksi menetelmää

Azure AD Authentication methods

Loppusanat


Olennaista on, että kaikilla organisaatioilla on vähintään MFA käytössä. Sen hallinta tapahtuu taas parhaiten Conditional Access Policyin, jotka vaativat “hinnat alkaen” -M365-tilauksia parempia lisenssejä. Bitmore suosittelee, että alle 300 hengen organisaatiot käyttävät M365 Business Premiumia. Se on ensimmäinen lisenssitaso, jolla tietoturvaa saadaan toteutettua riittävällä tasolla. Alemmat tasot jättävät paljon yksittäisen työntekijän toimenpiteiden vastuulle.


Blogissa kuvatut asetukset voidaan tehdä myös toistettavasti PowerShell/GraphAPI-rajapintaa hyödyntämällä, mutta kyseinen toteutus jää tämän artikkelin ulkopuolelle.


Seuraavana askeleena tunnistamismenetelmien suhteen käymme läpi Conditional Access Authentication Strength -määritykset ja mitä ne mahdollistavat, https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-strengths. Tästä lisää blogissamme tulevaisuudessa.


Viitteet ja termit

Huomioikaa, että näiden tietojen käyttö tapahtuu omalla vastuulla, ja asetukset, määritelmät ja muut Azure AD:n yksityiskohdat ovat voineet muuttua kirjoitushetken jälkeen.


Muokkaukset 14.2.2023: typoja, tarkennus SSPR-metodeihin.

377 katselukertaa

Aiheeseen liittyvät päivitykset

Katso kaikki

Commentaires