Azure AD:n tunnistautumismenetelmien uusi moderni hallinta

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.

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

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

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.

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.

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.

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.

Lisää aiheesta: https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-temporary-access-pass

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.

Lisää aiheesta: https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-oath-tokens

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.

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.

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.

Lisää aiheesta: https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-certificate-based-authentication

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.

6. Migraation käynnistys

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

7. Vanhojen määritysten poisto

Poista vanhat MFA- ja SSPR-määritykset. MFA, poista kaikki menetelmät: https://account.activedirectory.windowsazure.com/UserManagement/MfaSettings.aspx?culture=en-US&BrandContextID=O365

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

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ä).

https://portal.azure.com/#view/Microsoft_AAD_IAM/PasswordResetMenuBlade/~/AuthenticationMethods

8. Viimeistele migraatio loppuun asti

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

https://portal.azure.com/#view/Microsoft_AAD_IAM/AuthenticationMethodsMenuBlade/~/AdminAuthMethods

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ää

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

• MFA = Multi-Factor Authentication, monivaiheinen tunnistus

• SSPR = Self-Service Password Reset, salasanan vaihto itsepalveluna, ks https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-howitworks

• Combined Security Info Registration, MFA + SSPR menetelmien yhdistetty rekisteröinti, ks. https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-registration-mfa-sspr-combined

• TAP = Temporary Access Pass, väliaikainen pääsyavain

• TOTP = Time-based One-Time Password, aikasidottu kertakäyttösalasana, https://en.wikipedia.org/wiki/Time-based_one-time_password

• Microsoftin ohje: https://learn.microsoft.com/en-us/azure/active-directory/authentication/how-to-authentication-methods-manage

• Yubico FIDO2-avaimet (YubiKey): https://www.yubico.com/products/

• Thales FIDO2-avain: https://cpl.thalesgroup.com/access-management/authenticators/fido-devices

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.