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:
Onko tarvetta muuttaa asetuksia nykyisestä? Päätä tältä pohjalta uudet asetukset.
Tarkista, että combined security info registration on käytössä (yleensä on)
Tarkista, että ns. break glass -tunnus on olemassa
Toteuta halutut menetelmät uudella tunnistuspolitiikalla
Tiedota käyttäjät, koska muutos saattaa vaatia käyttäjiä rekisteröimään uusia tunnistamismenetelmiä
Käynnistä migraatio
Poista legacy-asetukset käytöstä
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:
Väliaikainen apu käyttäjille, jotka ovat menettäneet muut tunnistamismenetelmänsä, ja jotka ylläpitäjä saa tunnistettua muilla keinoin
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ä).
8. Viimeistele migraatio loppuun asti
Siirry kohtaan Azure AD → Security → Authentication Methods → Policies ja valitse “Migration Complete”
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.
תגובות