Ristiin rastiin tenantista toiseen,
eli Azure AD cross-tenant access in a nutshell
Virtuaalisen kollaboraation, kuten Teamsin käytön myötä käyttäjien vierailut yhteistyöorganisaatioiden M365-ympäristöihin on luonnollisesti kasvanut. Samalla on kasvanut huoli näiden vieraskäyttäjien tietoturvasta, ja organisaatioissa on laitettu päälle Conditional Accessista MFA-vaatimuksia myös Guest-tunnuksille.
Loppukäyttäjän näkökulmasta ylimääräiset MFA-rekisteröinnit ja -vahvistukset voivat olla vaikeita hahmottaa tai hallinnoida. Etenkin tuo toiseen organisaatioon rekisteröidyn vierailijatunnuksen MFA:n hallinnointi on hieman mutkan takana käyttäjän vinkkelistä. Kirjoittelinkin tästä aiheesta viime vuonna: https://digikuu.fi/vieraille-kuppi-kahvia-ja-vahvaa-tunnistautumista
Vaan mikä avuksi jos vieraskäyttäjiä on paljon ja ATK-osaston käsille olisi parempaakin tekemistä kuin koittaa pelata MFA-pingistä tässä puun ja kuoren välissä?
Apuja Azure AD Cross-tenant accessista
Myös Microsoft on kuullut tämän tuskaisen parahduksen IT-helppareiden suunnalta, ja siellähän on laitettu tuotekehitysosasto töihin! Kuten näillä lisenssimaksuilla voisi olettaakin. 😉
Kesällä heilahti tuotantomoodiin eli GA:ksi Azure AD:n External Identities valikosta löytyvä Cross-tenant access -asetukset. Otetaanpa ytimekäs katsaus siihen mitä tämä pitää sisällään!
Vierailijatunnusten passintarkastus yleistasolla
Vilkaistaan ensin nyt nämä oletusasetukset, vaikka setä Microsoft on sitä mieltä, että se ei ole se ensimmäinen sivu joka tähän pimeyteen saavuttaessa on oleellinen.
Default settings -sivulla määritetään miten vierailijatunnusten toimintaa kontrolloidaan yleistasolla tässä ympäristössä.
Ja sitähän voidaan hallita vihdoinkin sekä sisään- että ulospäin tapahtuvassa viestinnässä!
Vaan mitä ovat nämä B2B collaboration ja B2B direct connect?! *
*Oispa vuosi 2kjotain ja DC hubit surisemassa.. #tietäjättietää #vainlinuxdistrojatässäjaetaankaverienkesken
Perinteistä vierailijatunnuksen käyttöä kuvaa B2B collaboration -kontrollit. Nämä purevat siis Guest tunnuksien toimintaan, ja näiden avulla voidaan kontrolloida sallitaanko vierailijatunnusten tulla tähän meidän ympäristöön (Inbound), tai voidaanko meidän ympäristön käyttäjiä kutsua vieraskäyttäjiksi toisiin M365-ympäristöihin (Outbound). Oletuksena tämä on sallittu.
B2B direct connect -skenaario liittyy mm. Teamsin Shared Channeliin, ja tässä tapauksessa kyseessä ei ole Guest-tunnukset, vaan Shared Channeliin kutsuttu käyttäjä pääsee kanavalle kotitenanttinsa identiteetin turvin suoraan, siis ilman vierailijatunnusta. Oletuksena tämä on estetty.
Sisäänpäin tulevan kommunikaation osalta hallintaa tehdään kaikkien käyttäjien osalta, mutta ulospäin oletussääntö voidaan kohdentaa tiettyihin käyttäjiin tai ryhmiin.
Ja miten External applications liittyy tähän kuvioon?
Erittäin hyvä kysymys sieltä takarivistä! Käyttäjä/ryhmä tason lisäksi tätä hallintaa voidaan tehdä sovellustasolla, ja sovellus tarkoittaa tässä tapauksessa joko Microsoftin tuottamaa tai kolmannen osapuolen tuottamaa Azure AD:hen rekisteröityä Enterprise appia. Eli pääsy voidaan sallia tai estää yksittäisten sovellusten osalta valitsemalla ne valikosta tai listaamalla App Id:t.
Sitten se Iso Pihvi, eli halutaanko luottaa vierailijan oman ympäristön MFA:han tai luotettuun laitteeseen!
Sisäänpäin suuntaavan megalomaanisen yhteistyötanssin osalta voidaan määrittää, että luotamme vieraskäyttäjän oman organisaation vahvaan tunnistautumiseen tai luotettuihin laitteisiin. Tämä on se, mikä voi vähentää merkittävästi oman ATK-osaston murinaa ja vieraskäyttäjien tuen tarvetta. Tietysti tätä ennen pitää olla määritettynä Conditional Access -säännöstö vierailijatunnuksille, jotta tästä ominaisuudesta on hyötyä.
Huom! Jos ulkopuolisilta käyttäjiltä vaaditaan MFA:ta, B2B Direct connectin, eli käytännössä Teamsin jaettujen kanavien toiminta edellyttää, että luotto ulkopuolisen organisaation MFA:han on otettu käyttöön. Muuten ulkoisen käyttäjän pääsy jaetulle kanavalle päättyy kauniiseen virheilmoitukseen, ja sormen hakeutumiseen lähimpään suuhun.
Mutta voiko naapureihin luottaa?
Tämä lienee kysymys, jota kannattaa hieman pohtia omista lähtökohdista. Sinänsä MFA:n tai luotetun laitteen vaatiminen vieraskäyttäjän kotiorganisaatiossa on jo suuresti tietoturvaa parantava tekijä, mutta toisaalta me emme voi tietää millä kriteereillä laitteet ovat luotettuja, tai mikä laitteiden käyttöpolitiikka ylipäätään on. Erillisen vahvan tunnistautumisen edellyttäminen voidaan nähdä myös tietoturvan lisäkerroksena.
Entä jos tämän voisikin määrittää organisaatiokohtaisesti?
Senhän voi! Organizational settings -kohdasta pääsemme lisäämään esim. kumppaniorganisaation tenantin listalle, ja voimme määrittää edellä läpikäydyt asetukset kyseiselle organisaatiolle. Organisaatiokohtaiset asetukset ajavat yleisten asetusten päälle.
Tämä mahdollistaa esimerkiksi yleisellä tasolla vierastunnusten käytön estämisen, mutta organisaatiokohtaisen sallimisen. Toki kaikkea ei kannata tehdä vain siksi että se on mahdollista. Juurihan tässä haluttiin ATK-osaston työkuormaa vähentää 😉
Mites tämä tarkastusprosessi sitten käytännössä toimii?
Microsoftin dokumentaatiosta löytyy hyvä kaavio aiheesta: https://docs.microsoft.com/en-us/azure/active-directory/external-identities/authentication-conditional-access
Lyhyesti kuvattuna:
Jos vieraskäyttäjän vastaanottava ympäristö (Resource tenant) luottaa käyttäjän oman ympäristön (Home tenant) vahvaan tunnistautumiseen tai laitteisiin, käyttäjä pääsee sisään joko ilman erillistä vahvistusta, tai sitten suorittamalla MFA:n omaa Home ympäristöään vasten. Jos luottamusta Home tenantin suuntaan ei ole määritetty käyttöön, käyttäjältä pyydetään MFA Resource tenanttia vasten.
Kai ne tästäkin rahaa haluaa?
Ei välttämättä. Tämä toiminnallisuus edellyttää Azure AD Premium P1 lisenssiä molemmista päistä, joka pitäisi luonnostaan löytyä jos Conditional Accessia ajetaan muutenkin ympäristöissä. Eli sen puoleen ei muuta kuin kovaa ajoa!
– Pilvikuiskaaja Riku Mustila
