Monessa organisaatiossa on painettu viime vuodet käyttäjiä, dataa ja laitteita pilveen kuin sitä kuuluisaa käärmettä pyssyyn. Tietoturvan rajat on piirretty uudelleen Zero trust -mallia mukaillen. On Azure AD Joinia, Hybrid Joinia ja Intunella hallittua Ränkylää™. Mutta mistä Azure AD ja Conditional Access tunnistaa esimerkiksi laitteen käyttöjärjestelmän tai selaimen? Entä luotetun, hallitun laitteen? Miksi Conditional Accessissa on hyvä määritellä koukku myös tunnistamattomille laitteille? Pitäisikö Conditional Accessin sääntöjä muutenkin aika ajoin vilkaista, ja tehdä jopa uusiksi?!
Jos nämä asiat kutittavat nenääsi, on aika ottaa jälleen hyvän asennon lisäksi kuppi lempijuomaasi, ja jatkaa kaivamista. Ja kyllä, saa se olla skottilaistakin. Ei meillä lasketa.
Mozilla/5.0 ja muut hemaisevat stringit
Kun päivittäin vaellamme internetin tyrskyissä valitsemallamme selaimella, selain lähettää HTTP pyyntöjen mukana nettipalveluille jonkin verran tietoa sekä itsestään että laitteesta, jota käytämme. Tätä tietoa kulkee mm. User agent stringissä, jotka esimerkiksi Google Chrome selaimessa ovat muotoa:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
Tässä kerrotaan osimoilleen seuraavat asiat:
- Historiallisista syistä (Suuri Selainsota joskus ysärillä) likimain kaikki selaimet mainostavat olevansa Mozilla/5.0 yhteensopivia
- Käytettävä laite tai käyttöjärjestelmä (Windows 10, 64bit), mobiiililaitteilla usein myös laitteen malli
- Ja sitten yhteensopivuuksien vuoksi lisää erilaisia alustoja ja moottoreita ja selaimia versioineen
- Lisäksi esim. hakukoneiden botit kertovat joskus myös URL-osoitteen, josta voi löytää lisää tietoa ko. vierailijasta
Jokaisella selaimella ja sovelluksella tämä on omanlaisensa, ja kulloinkin kyseessä oleva user agent tunnistetaan yleensä koko rimpsun perusteella. Oleellista on siis kokonaisuus, ei niinkään se mitä erinäisiä alustoja/selaimia/versioita on lueteltuna ja missä järjestyksessä.
No mitä sitten? No sitä sitten, että tätä kyseistä rimpsua hyödyntää myös Azure AD tunnistaessaan kirjautuvaa selainta ja käyttöjärjestelmää.
Kyllä, myös käyttöjärjestelmää. Ja juuri siksi tämä on hyvä ymmärtää. Tämä ominaisuus on dokumentoitu myös Microsoftin ohjesivuilla:
Ovella tarkastamme passit!
Conditional Accessissa tehdään usein sääntöjä käyttöjärjestelmän perusteella. Windows käyttäjiltä vaaditaan jotain, MacOS käyttäjiltä jotain, ja mobiilikäyttäjiltä jotain. Ja variaatioita löytyy yhtä paljon kuin Conditional Access -taiteilijoitakin. Myös organisaation tarpeet sanelevat ehtojen asettamista.
Azure AD:n ovella Conditional Access sitten tarkastaa passit, mutta vain sen mukaan mitä säännöissä on ohjeistettu. Ja tämä passintarkastus käyttöjärjestelmän osalta nojaa vahvasti User agent stringiin.
Kirjautumiseen liittyvä User agent tieto löytyy Azure AD:n Sign-in lokista Basic info -välilehden alaosasta:
Tässä tapauksessa on kirjautuminen tehtiin Chrome selaimella Windows 11 laitteella. User agent string näyttää seuraavalta:
Ja sen mukaan tehty tulkinta laitteesta ja selaimesta:
Sehän meni melkein oikein. Käyttöjärjestelmänä pitäisi olla Windows 11, vaan eipäs ole! User agent stringiin pohjautuva käyttöjärjestelmän tunnistus on selainten kehittäjien mielestä ”so last season” ja sen tilalle on tullut User agent Client hints -toiminne. Tai siis pitäisi ehkä tulla? Noh, käytännössä aika moni web-palvelu tulee vielä pitkään tunnistamaan Windows 11 laitteet virheellisesti Windows 10 laitteiksi.
Conditional Accessin osalta sääntö oli asetettu vaatimaan luotettua ja vaatimukset täyttävä laite, joten tämä kirjautuminen estettiin, koska laite ei ollut Compliant:
Mutta mikäs kansalaisuus tässä passissa on?
User agent tiedossa on se vinha puoli, että sen voi myös halutessaan määrittää itse, eli spooffata kuten lontooksi sanotaan. Tämä käy kohtuullisen helposti esim. selaimessa kehittäjätyökalujen kautta. Siispä samalla työasemalla ja samalla selaimella saadaan tarvittaessa MacOS:lta näyttävä lippu salkoon:
Ja kirjautuvasta laitteesta syntyy hieman erilainen tulkinta:
Tässä kohtaa Conditional Access ajaa myös MacOS:lle kohdennetut säännöstöt, eikä Windowsille kohdennettuja. Jos sellaisia siis löytyy!
Käyttäjän on suhteellisen helppoa halutessaan vaihtaa laitteekseen esim. tuo MacOS tai mobiililaite, ja kokeilla olisiko Conditional Accessin osalta tarjolla kevyemmät vaatimukset eri härveleille.
”Finally a girl is no one”
Koska User agent stringin voi siis määrittää täysin vapaasti, voimme käyttää esim. kuvitteellista KuuSelainta ja KuuOS käyttöjärjestelmää:
Tässä tapauksessa Azure AD ei pysty tunnistamaan näitä kuvitteellisia otuksia, ja kirjautumisen laitetiedot ovat tyhjät:
On siis mahdollista kirjautua tunnistamattomalla laitteella ja selaimella. Tässä tapauksessa Conditional Access ei kykene kohdistamaan mitään käyttöjärjestelmäkohtaisesti tehtyjä sääntöjä.
No entäpä ne tunnetut tai luotetut laitteet?
Luotettujen laitteiden (Azure AD Joined ja Hybrid Azure AD Joined) tunnistaminen perustuu aiemmin tapahtuneeseen luottosuhteen luomiseen, eli laite on jollain tavalla liitetty Azure AD:hen. Liitosten anatomia on avattu eri skenaarioiden osalta melko hyvin tehtaan dokumentaatiossa:
https://docs.microsoft.com/en-us/azure/active-directory/devices/device-registration-how-it-works
Liitoksen yhteydessä laite saa Primary Refresh Tokenin (PRT), jonka avulla kertakirjautuminen pilvisovelluksiin tapahtuu. Tuon PRT:n mukana kulkee myös laitteen liitoksen yhteydessä luotu DeviceID-tieto, jonka perusteella Azure AD tunnistaa laitteen, ja pystyy kertomaan onko laite merkattu vaatimukset täyttäväksi. Tätä varten selaimesta pitää löytyä tuki PRT:n välittämiselle kirjautumisen yhteydessä. Chromium pohjainen Microsoft Edge tukee tätä natiivisti, Google Chrome vaatii joko Windows 10 Accounts tai Office -lisäosan, ja Mozilla Firefoxista tämä tuki voidaan aktivoida asetuksista.
Kun laite on tunnistettu luotettavasti, Conditional Access voi lukea Azure AD:sta laitteen tiedot, ja päättää sen perusteella sallitaanko kirjautuminen. Laite ei siis itse kerro olevansa luotettu, se tieto tulee Azure AD:sta joko Intunen Compliance säännön (Compliant) tai laiteliitoksen tyypin perusteella (Hybrid Azure AD Joined tai Azure AD Joined). Laitteen ja kirjautumisen tiedoissa näkyvä Managed-tieto kertoo onko laite liitetty Intuneen.
Koukut veteen ja kalaonnea vuodelle 2022!
Azure AD:n ja Conditional Accessin kyky tunnistaa kirjautuva laite ei siis ole ihan kovinta terästä, jos kyseessä ei ole luotettu laite. Tämän vuoksi on siis äärimmäisen tärkeää huomioida Conditional Access säännöstössä myös ne laitteet ja skenaariot, joita ei tunnisteta tai määritetä erikseen, ja jopa estää niillä kirjautuminen, jos mahdollista. Ja Zero trust idean mukaisesti olisi parempi luottaa vain tunnettuihin laitteisiin.
Vanhat Conditional Access säännöstöt on hyvä katselmoida ajatuksella läpi, ja miettiä mitä ei ole tullut aiemmin miettineeksi. Kannattaa myös harkita vanhimpien sääntöjen tekemistä uudelleen jossain vaiheessa, sillä ainakin oman kokemukseni mukaan vanhat säännöt eivät välttämättä toimi oikein, ainakaan jos niiden asetuksia koittaa muuttaa. Vanhat säännöt voi tunnistaa mm. siitä, että Conditional Accessin Policies-listauksessa niiltä puuttuu luontipäivämäärä, eli Creation Date. Conditional Accessin toiminnot myös kehittyvät jatkuvasti ja se on toinen hyvä syy ajoittain pohtia voisiko jotain vielä parantaa.
On myös hyvä pitää mielessä, että monivaiheinen tunnistautuminen (MFA) ei sekään ole 100% suojaava. Nykyään kalastelutyökalut pystyvät käsittelemään myös MFA:lla suojatut kirjautumiset, ja siinä samalla vielä matkivat täydellisesti yritykselle brändättyä kirjautumissivua – täysin automaattisesti. Myös tässä mielessä luotettujen laitteiden tunnistamiseen perustuva pääsynhallinta on hyvä juttu. Pelkän MFA:n varaan ei kannata ihan kaikkea pidemmän päälle laskea, vaikka se vielä toistaiseksi parantaa huomattavasti tietoturvaa.
Kannattaa siis laittaa mahdollisimman laajalti koukkuja vesille, ja uhrata yleisesti hieman aikaa tietoturvan parantamiseen myös tänä vuonna. Vastustajilta kun löytyy kosolti sekä koukkuja että aikaa viritellä niitä.
Tietoturvallista alkanutta vuotta 2022!
Cheers!
– Pilvikuiskaaja Riku Mustila
