Microsoft 365:n asianmukainen suojaus: Conditional Access, MFA-poikkeukset ja Break-Glass-tilit arjessa

Jotta Microsoft 365 voidaan suojata oikein, ei voi ohittaa Conditional Accessia (käyttöoikeuspohjaiset säännöt Entra ID:ssä, aiemmin Azure AD) ja monivaiheista todentamista (MFA, eli kirjautuminen vähintään kahdella tekijällä). Monissa yrityksissä MFA ja ensimmäiset Conditional-Access-säännöt otetaan nopeasti käyttöön – ja sitten työ vasta alkaa: poikkeukset on perusteltava, hätäkäytöt järjestettävä selkeästi ja toimintaprosessit suunniteltava niin, että turvallisuus ei aiheuta tukivyöryä.

Käytännössä ”M365:n suojaaminen” ei yleensä kaadu periaatteelliseen teknologiaan, vaan arjen asioihin: rajapintojen palvelutilit, Legacy-protokollat, kenttätyö ilman luotettavaa mobiiliverkkoa, ylläpitäjät, joilla on liian laajat oikeudet, tai incident, jossa juuri suojaustoimenpide estää IT:n pääsyn. Tämä artikkeli selkeyttää, miten Conditional Access, MFA-poikkeukset ja Break-Glass-Accounts toimivat yhdessä – ja miten koko kokonaisuutta ajetaan siten, että se pysyy luotettavana myös käyttöönoton jälkeen.

Miksi Conditional Access on vipu – ja miksi pelkkä MFA ei riitä

MFA vähentää varastettujen salasanojen riskiä merkittävästi, mutta MFA ei ole täydellinen pääsynhallintakonsepti. Conditional Access (CA) päättää kontekstin perusteella, missä olosuhteissa pääsy on sallittu: esim. vain hallituilta laitteilta, vain tietyistä maista, vain riskipohjaisen arvioinnin jälkeen tai vain tietyillä asiakasohjelmilla. Tämä on ratkaiseva askel kohti Zero Trustia (turvamalli, jossa oletusarvoisesti ei luoteta pääsyihin, vaan niitä arvioidaan jatkuvasti).

Tyypilliset syyt, miksi pelkkä MFA ei riitä Microsoft 365:ssä:

• Token statt Passwort: Nykyinen todentaminen perustuu tokeneihin (aikarajoitetut pääsyliput). Varastettu token voi ohittaa MFA:n, jos CA ei vaadi lisäehtoja (esim. laitteen tila tai istunnon hallinta).
• Admin-Risiko: Hallintotilit ovat erityisen houkuttelevia. Ilman CA-sääntöjä ylläpitotileille (esim. vain admin-työasemilta tai vain phishing-kestävä MFA) suurin hyökkäyspinta-ala jää avoimeksi.
• „Erlaubt“ ist zu breit: Jos CA ei erottele sovelluksia, tietoluokkia ja käyttötyyppejä, turvallisuus muuttuu nopeasti joko liian väljähköksi tai liian rajoittavaksi – kumpikin aiheuttaa ongelmia.

Toiminnallinen ydin on siis: CA policy-kerroksena, MFA sen osana, sekä selkeä poikkeushallinta ja luotettavat hätäpolut.

Arkkitehtuurikatsaus: mitä Conditional Access Entra ID:ssä todellisuudessa ohjaa

IT-johtamisen ja käytön näkökulmasta on tärkeää ymmärtää CA ei niin, että se olisi ”yksi sääntö”, vaan että se on päätösketju. Entra ID arvioi jokaisella kirjautumisella signaaleja ja soveltaa politiikkoja. Tärkeitä signaaleja ovat:

• Identität: käyttäjät, ryhmät, roolit (esim. privilegioidut roolit kuten Global Administrator).
• Zielressource: pilvisovellus (Exchange Online, SharePoint/OneDrive, Teams, mutta myös kolmannen osapuolen sovellukset Enterprise Appin kautta).
• Client-Typ: selain, modernit asiakasohjelmat, mobiilisovellukset sekä „Legacy Authentication“ (vanhemmat protokollat ilman moderneja tokeneita, esim. vanhemmat IMAP/POP/SMTP-todennusvariantit).
• Gerätezustand: „Compliant“ tai „hybrid joined“ (hallittu laite, tyypillisesti Intunen tai toimialueeseen liittämisen kautta raportoituna laitteen tilana).
• Netzwerk/Standort: Named Locations (määritellyt IP-alueet), maat/alueet, riski-indikaattorit.
• Sitzungsbedingungen: Session Lifetime, App-Enforced RESTrictions, Continuous Access Evaluation (jatkuva uudelleenarviointi riski­tapahtumien yhteydessä).

Toiminnan näkökulmasta CA‑konfiguraation laatu riippuu pitkälti siitä, ovatko nämä signaalit luotettavia. Named Location on yhtä hyvä kuin IP‑osoitteiden hygienia. „Compliant“ on yhtä hyvä kuin laitehallintanne ja compliance‑määritelmä. Ja riskinarviointi on hyödyllinen vain, jos käsittelette siitä syntyviä tapahtumia.

Microsoft 365:n suojaaminen Conditional Accessilla oikein: käytännönmukainen politiikkasetti

Yhden „isomman“ säännön sijaan arjessa toimii paremmin muutamasta selkeästi erottuvasta politiikasta koostuva setti. Se vähentää sivuvaikutuksia ja helpottaa vianetsintää häiriötilanteissa. Hyväksi todettu perusmalli koostuu:

1) Peruspolitiikka kaikille käyttäjille: pakota MFA, estä Legacy Authentication

Normaaleille käyttäjätilille peruspolitiikka on: MFA vaaditaan ja Legacy Authentication estetään. Legacy ei tässä tarkoita vain „vanhanaikaista“, vaan teknisesti ongelmallista: nämä protokollat eivät usein tue nykyaikaista MFA‑haastetta ja ovat siksi klassinen sisäänkäynti password spraying ‑hyökkäyksiin.

Tärkeää: älä estä Legacyä „jossain vaiheessa“, vaan suunnittele siirtymävaihe ja mittaus. Tarkista kirjautumislokeista, mitkä clientit/asiakkaat käyttävät edelleen Legacyä. Yrityksissä tähän liittyy usein monitoimitulostimia, Scan‑to‑Mail‑toimintoja tai vanhempia sähköpostiohjelmia erikoisympäristöissä.

2) Admin‑politiikka: selvästi tiukempi kuin peruspolitiikka

Etuoikeutetuille rooleille tulisi olla oma politiikka: pääsy vain määritellyistä admin‑laitteista (esim. „compliant“ ja tarvittaessa erillinen admin‑workstation‑strategia), korkean turvallisuustason MFA (phishing‑resistentti, esim. FIDO2/Passkey tai sertifikaattilähtöinen) sekä mahdollisuuksien mukaan rajoituksia riskimaille/‑sijainneille. Vaikka kaikki yritykset eivät heti ota käyttöön täydellistä privileged access ‑arkkitehtuuria (PAM, eli privilegoitujen pääsynhallintaa), tämä ero kannattaa ottaa käyttöön heti: kompromissoitu admin‑tili on eri vahinkotila kuin kompromissoitu käyttäjätili.

3) Politiikka ulkoiseen yhteistyöhön ja vieraskäyttöön

Vieraskäytöt (B2B Collaboration) synnyttävät usein odottamattomia datapolkuja: vieraat lataavat tiedostoja SharePointista, työskentelevät Teamsissa tai käyttävät projektialustoja. Määritä tässä tarkoituksella, pääsevätkö vieraat vain MFA:lla, suljetaanko tietyt sovellukset ja kuinka pitkä istunnon kesto on. Projektityössä lyhyempi istunnon elinikä on usein perusteltu, koska se vähentää „unohtuneiden kirjautumisten“ riskiä.

4) Politiikka arkaluontoisille datapoluille: suojaa laite tai istunto

Arjessa suojaustarpeet vaihtelevat: myyntihenkilö voi ehkä lukea sähköposteja miltä tahansa laitteelta, mutta ei ladata suuria määriä dataa SharePointista ilman hallittua laitetta. Tällaiset erot toteutetaan eivät niin sanotulla yleisellä „sallittu/kielletty“‑lähestymistavalla, vaan CA‑yhdistelmillä: „pääsy sallittu, jos laite on compliant“ tai „pääsy vain selaimella rajoitetulla istunnolla“. Tämä on vähemmän ehdoton kuin täydellinen esto – ja silti tehokas.

MFA‑poikkeukset: missä ne ovat realistisia – ja miten niitä valvotaan

MFA‑poikkeukset eivät ole heikkouden merkki, kunhan ne on suunniteltu tietoisesti ja operatiivisesti valvottu. Ilman kontrolloituja poikkeuksia syntyy varjoratkaisuja: käyttäjät kiertävät prosesseja, adminit sammuttavat sääntöjä hätiköiden, ja jossain vaiheessa politiikkakokoelma ei enää ole jäljitettävissä.

Tärkeää on ero: MFA‑poikkeus harvoin tarkoittaa „MFA pois“, vaan usein „MFA eri tavalla“ tai „pääsy vain muilla ehdoilla“. Tyypillisiä poikkeusluokkia ovat:

Poikkeustapaus 1: Ei‑interaktiiviset yhteydet ja rajapinnat

Monet prosessiläheiset ohjelmaratkaisut integroituvat M365-palveluihin: sähköpostin lähetys, kalenterin käyttö, SharePoint-tiedostojen säilytys, Teams-ilmoitukset tai Graph-API-kutsut. Tällaiset integraatiot eivät saisi toimia käyttäjätilien kautta, joilla MFA on poistettu käytöstä. Parempi on tekninen pääsy sovellusrekisteröintien kautta (sovellus Entra ID:ssä) selkeillä käyttöoikeuksilla ja salaisuuksien/sertifikaattien elinkaaren hallinnalla. Tämä ei ole „MFA-poikkeus“, vaan toinen todennusmenetelmä, joka on paremmin auditoitavissa.

Toiminnolliset seuraamukset: salaisuudet on kierrätettävä, sertifikaatit vanhenevat ja käyttöoikeudet on uusintatodennettava. Kun suunnittelette integraatioita, määrittäkää omistajuus (kuka uusia sertifikaatit/salaisuudet) ja valvonta (esim. varoitukset ennen vanhenemista). Muuten „turvallisesta“ sovellusautentikoinnista tulee suunnittelematon häiriö.

Poikkeustapaus 2: Laitteet ilman modernia kirjautumista (esim. Scanner, Drucker, Raum-Systeme)

Tässä syntyvät klassiset keskustelut SMTP-relayn, Scan-to-Mailin tai tilapostilaatikoiden ympärillä. Väärä ratkaisu on lähes aina „käyttäjätili ilman MFA:ta“. Parempia ovat tekniset reitit, jotka eivät riipu interaktiivisesta kirjautumisesta: keskitetty sähköpostirelay IP-rajoituksilla, sertifikaatti- tai connector-lähestymistavat, tai erilliset järjestelmäpostilaatikot tiukoilla oikeuksilla. Tärkeää on: laite ei itse voi käsitellä MFA:ta, joten suunnittelun on suojattava siirto- ja verkkopolku.

Poikkeustapaus 3: Hätätila ja rajoitettu saavutettavuus

Kenttätyö, tuotanto tai vuorotyö kohtaavat tilanteita ilman matkapuhelinverkkoa tai ilman yksityisiä mobiililaitteita. Tässä kannattaa varhain pohtia vaihtoehtoisia MFA-menetelmiä: laitepohjaiset tokenit, FIDO2-turva-avaimet, tai Windows Hello for Business (laitteeseen sidottu kirjautuminen). „Väliaikaisesti MFA pois“ on operatiivisesti houkutteleva, mutta huonosti skaalautuva ja vaikea auditoida.

Poikkeustapaus 4: Automaattiset työnkulut käyttäjäkontekstissa

Jotkin vanhat järjestelmät käynnistävät töitä „käyttäjänä“, esimerkiksi SharePoint-latauksia tai raportteja varten. Nykykatsannossa se on riskialtista, koska roolit ja oikeudet sekoittuvat. Jos korvaus ei ole heti mahdollista, toimikaa välitasoilla: rajoitetut palvelutilit, selkeät Named Locations, vahvat salasana-/salaisuuspolitiikat ja johdonmukainen lokitus. Ja: suunnitelkaa migratio sovellusidentiteetteihin omana työpakettinaan, ei „myöhemmin joskus“.

Kuinka dokumentoida, hyväksyä ja poistaa poikkeukset

Poikkeukset ovat käytössä hyväksyttäviä vain, jos niillä on elinkaari. Käytännössä toimiva on kevyt menettely, joka välttää byrokratian mutta on silti auditoitava:

1. Perustelu yhdellä lauseella: Mihin liiketoiminta- tai operatiiviseen toimintaan se liittyy (esim. „Scan-to-Mail sijaintiin X“)?
2. Tekninen luokittelu: Mitkä sovellukset/protokollat, mitkä tilit, mitkä datapolut?
3. Kompensoivat kontrollit: Mikä rajoittaa riskiä (IP-rajoitus, vain välttämättömät oikeudet, valvonta)?
4. Voimassaoloaika: Jokaiselle poikkeukselle määritetään arviointipäivämäärä. Ilman arviointia se poistetaan tai uudelleenhyväksytään.
5. Omistaja: Kuka on vastuussa, jos tulee ongelma tai poikkeus vanhenee?

Tämän avulla poikkeuksista ei tule „hyviä“, mutta ne muuttuvat hallittaviksi. Juuri tämä on arjessa ero robustin M365-turvapohjan ja sääntöjen rehottavan sekasorron välillä.

Break-Glass-tilit: Hätäkäyttö ilman turva-aukkoa

Break-Glass-tilit ovat hätätilitunnuksia Tenantin käyttöön, kun tavalliset ylläpitäjäkäsitteet eivät toimi – esimerkiksi Conditional Accessin virheellisen konfiguraation, MFA-palveluntarjoajan vian tai identiteettitapahtuman vuoksi. Tarkoitus on selvä, mutta toteutuksessa on tyypillisiä sudenkuoppia: Break-Glass-tili, jota ei koskaan testata, ei auta hätätilanteessa. Break-Glass-tili, joka on liian helposti saavutettavissa, on houkutteleva hyökkäyskohde.

Mitä Break-Glass ei ole

• Ei päivittäinen ylläpitäjätili: Sitä ei saa käyttää normaalissa tuotantokäytössä.
• Ei poikkeusten keräilypaikka: Se ei korvaa huolellista CA-suunnittelua.
• Ei ”meillä on yksi, riittää” -asennetta: Ilman prosessia, testausta ja hälytyksiä se on vain teoreettinen suunnitelma.

Break-Glassin käytön perusperiaatteet

Käytännöllinen ratkaisu perustuu kolmeen tavoitteeseen: saavutettavissa hätätilanteessa, vaikea hyökätä normaalikäytössä ja hyvin jäljitettävissä.

• Ainakin kaksi tiliä: Redundanssi suojaamaan lukituksilta, virhekäytöiltä tai kompromettoituneilta tunnuksilta.
• Tarkasti suojattu: Pitkät, satunnaiset salasanat; ei sähköpostin edelleenlähetyksiä; ei käyttöä sovelluksiin tai integraatioihin.
• Tarkasti rajattu CA-poikkeus – mutta tiukka: Tyypillisesti poikkeus tietyistä CA-politiikoista, jotta hätätilassa ei lukittaisi itseään omien sääntöjen takia. Samanaikaisesti muiden suojausmekanismien on oltava voimassa: käyttöön perustuvat hälytykset, rajoitettu roolijako, tunnistetietojen erillinen säilytys.
• Lokitus ja hälytys: Jokaisen kirjautumisen on aiheutettava välitön signaali (SIEM/SOC tai vähintään sähköposti/Teams-hälytys incident-postilaatikkoon). Break-Glassin käyttö on määritelmän mukaan turvallisuustapahtuma.

Keskeinen seikka: päättäkää tietoisesti, käytetäänkö Break-Glassia MFA:n kanssa vai ilman. Monet organisaatiot pitävät sen ilman MFA:ta, jotta toimintaan pystytään MFA-vian aikana. Tällöin kompensoivien kontrollien on kuitenkin oltava erityisen huolellisia (säilytys, pääsy salasanaan, hälytykset, säännöllinen vaihtaminen). Vaihtoehtoisesti Break-Glass voidaan varustaa laitteistopohjaisella MFA:lla (esim. FIDO2), joka ei riipu matkapuhelinverkosta. Tärkeää ei ole „oikea“ ideologia, vaan hätäpolku, joka toimii käytännössä teidän kontekstissanne.

Rolloutin todellisuus: näin vältätte lukitukset ja tukipiikit

Monet CA-/MFA-käyttöönotot epäonnistuvat eivät teknisesti vaan organisatorisesti: liian nopeasti, liian laajasti, ilman telemetriaa ja ilman selkeää tukiprosessia. Vakaa käyttöönotto etenee vaiheittain ja mittauspistein.

Vaihe 1: Näkyvyyden luominen (ennen estämistä)

Käyttäkää Sign-in-lokeja ja analytiikkaa selvittääksenne: Mitä sovelluksia käytetään? Mitkä clientit ovat „legacy“? Mitkä sijainnit/IP-alueet ovat todellisia? Mitkä käyttäjät kokevat erityisen paljon kirjautumisongelmia? Ilman näitä tietoja jokainen politiikka on sokealento.

Vaihe 2: Pilottiryhmät todellisilla erityistapauksilla

Pilotit eivät saa olla pelkästään „IT ja muutama vapaaehtoinen“. Ottakaa tietoisesti mukaan reunatapauksia: kenttähenkilöstö, tuotantolaitokset, projektilaiset, joilla on vierailijakäyttöoikeus, sekä vähintään yksi osasto, joka käyttää tyypillisiä kolmannen osapuolen työkaluja. Tavoitteena ei ole harmonia, vaan todellisten kompastuskivien varhainen löytäminen.

Vaihe 3: Helpdesk-playbookien määrittely

Kun MFA pakotetaan, tukipyynnöt lisääntyvät: laitteenvaihdot, kadonneet puhelimet, uudet työntekijät, tili lukittuna liian monen yrityksen jälkeen. Määritelkää, mitä ensimmäisen tason tuki saa ratkaista (esim. MFA:n nollaus identiteetin varmistamisen jälkeen) ja milloin eskaloidaan. Ilman toimintaohjeita kaikki eskaloi – ja ylläpitäjistä tulee pullonkaula.

Vaihe 4: Tekninen jälkityö omana backlogina

CA paljastaa piilevät tekniset velat: vanhentuneet sähköpostiasiakasohjelmat, dokumentoimattomat skannerit, salasanaa sisältävät skriptit Task Schedulerissa tai integraatiot, jotka käyttävät edelleen Basic Authia. Suunnitelkaa nämä jälkityöt näkyviksi työpaketeiksi. Muuten ne jäävät „pysyviksi poikkeamiksi“.

Tyypillisiä käyttövirhekuvioita – ja miten ne luokitellaan nopeammin

Arkityössä tarvitaan nopeita hypoteeseja. Jotkin mallit toistuvat:

’Yhtäkkiä Outlook ei enää toimi’

Yleisiä syitä: legacy-asiakasohjelma, vanha profiili tai CA-estohyppy puuttuvan laitetilan vuoksi. Tarkistakaa: asiakasohjelmatyyppi sign-in-lokista, käytetty CA-politiikka ja onko laite merkitty vaatimustenmukaiseksi. Operatiivinen korjaus ei yleensä ole „poista politiikka“, vaan „modernisoi asiakasohjelma“ tai „siisti laitehallinta“.

’Palvelu XY ei voi enää lähettää sähköposteja’

Usein taustalla on SMTP-autentikoinnin muutos, muuttunut relay-politiikka tai uusi CA-sääntö, joka kattaa vahingossa myös tekniset tilit. Tässä auttaa selkeä arkkitehtuuripäätös: lähetys Relay/Connectorin kautta käyttäjäkirjautumisen sijaan, IP-rajoituksella ja lokituksella (jäljitettävyys incidentissä).

’Admin ei pääse enää tenanttiin’

Tämä on hetki, jota varten Break-Glass on tarkoitettu. Jos Break-Glass-käyttöoikeuskaan ei toimi, puuttuu yleensä testattu hätäpolku tai poikkeus on rakennettu väärin. Siksi: harjoitelkaa käyttöä säännöllisesti (dokumentoiden kuka testaa milloin ja miltä hälytys näyttää).

’Liian monta poikkeusta – kukaan ei hahmota tilannetta’

Tämä on governance-ongelma. Konsolidoikaa politiikat, määrittäkää review-rituaali (esim. kuukausittain 30 minuuttia) ja poistakaa poikkeukset, joilla ei ole enää omistajaa tai tarkoitusta. Tekninen työ ei ole glamouria, mutta se on ero hallittavan turvallisuuden ja historiallisesti kasautuneiden erikoisoikeuksien välillä.

Valvonta ja jäljitettävyys: mitä todella tarvitsette

CA ja MFA tuottavat paljon tapahtumia. Jos keräätte kaiken, hukutatte itsenne; jos ette analysoi mitään, havaitsette ongelmat liian myöhään. Käytännölliset kolme tasoa ovat:

• Hälytys kovista tapahtumista: Break-Glass-kirjautuminen, ylläpitäjän kirjautuminen epätavallisista maista, estotapahtumat kriittisissä sovelluksissa.
• Säännölliset tarkastelut: tärkeimmät estosyyt, käyttäjät joilla on MFA-ongelmia, legacy-autentikointiyritykset, uudet sovellukset/Enterprise-sovellukset.
• Audit-jälki poikkeuksille: kuka on hyväksynyt minkä poikkeuksen, millä päättymispäivällä ja milloin sitä on tarkasteltu?

Jos teillä on jo keskitetyt lokitus- ja incident-prosessit (SIEM, ticketing, change-management), juurruttakaa CA-muutokset niihin. Conditional Access ei ole „pieni asetus“, vaan tuotantokriittinen käyttöoikeustaso.

Työmäärä ja vastuut: kuka toimittaa mitä?

CA-/MFA-projekteja aliarvioidaan, koska ne näyttävät pelkiltä konfiguraatioilta. Todellisuudessa ne ovat rajapintaprojekte identiteetin, päätelaitteiden, verkon ja liiketoimintaprosessien välillä. Selkeä vastuumalli vähentää kitkaa:

• Identity-Team / Entra Admins: politiikkojen suunnittelu, roolimalli, Break-Glass, sovellusrekisteröinnit.
• Client-hallinta (esim. Intune): vaatimustenmukaisuuden määrittely, laitteiden tila, Authenticatorien ja passkeyjen käyttöönotto, laitteiden elinkaaren hallinta.
• Verkko: IP-alueet Named Locations -kohteille, Proxy-/TLS-tarkastuksen poikkeukset, sijaintimuutokset.
• Business-sovellusten Service Owner: integraatiopolut (Graph/SMTP/SharePoint), legacy-autentikoinnin korvaaminen, salaisuuksien kierto.
• Helpdesk: vakioprosessit MFA:n nollaamiseen, laitevaihtoihin ja käyttäjien sisään-/uloskirjaukseen.

Tärkein johtamispäätös ei usein ole „MFA kyllä/ei“, vaan: Onko meillä aikaa ja resursseja jälkitöihin (legacy-järjestelmien purku, integraatioiden modernisointi, laitehallinnan vakauttaminen)? Ilman tätä työtä tietoturvaetu jää odotuksia pienemmäksi — tai käyttö muuttuu tarpeettoman raskaaksi.

Yhteenveto: turvallisuus paranee, kun hätätila ja poikkeukset ovat osa järjestelmää

Microsoft 365:n asianmukainen suojaaminen edellyttää Conditional Accessin ylläpitämistä keskeisenä ohjauskerroksena — ei kertaluonteisena konfiguraationa. MFA on pakollinen, mutta varsinainen käyttölaatu syntyy selkeistä poikkeuskäytännöistä (määräaika, omistaja ja kompensoivat kontrollit) sekä testaetuista, valvotuista ja organisatorisesti sijoitetuista break-glass-tileistä. Kun nämä kolme elementtiä suunnitellaan yhdessä, tiliriskit vähenevät, auditoitavuus saavutetaan ilman ylimääräistä kuormitusta ja estetään, että turvallisuusmääräykset kääntyvät häiriötilanteessa itseään vastaan.

Keskustele projektista tai modernisointihankkeesta yhdessä Net-Base kanssa.