Anbefalte retningslinjer for betinget tilgang – Del 1 av 2

Sikkerhetsmodellen i Microsoft 365 og Azure er identitetsdreven og sentrert rundt ressurstilganger, basert på selskapets Zero Trust-arkitektur. Identiteter er brukere, prosesser og enheter – alt som kan autentiseres og autoriseres.

Tilganger styres av en policymotor som kalles Betinget tilgang. Den fungerer som beslutnings- og håndhevelsespunkt og evaluerer kontinuerlig om det skal gis adgang til en ressurs, som omfatter applikasjoner og data.

Avgjørelser fattes på grunnlag av statiske forutsetninger, som gruppetilhørighet og sted, og dynamiske signaler, som bruker- og enhetsrisiko. Tilgang kan tillates, begrenses eller blokkeres. Det kan kreves at sårbarheter utbedres og faresignaler fjernes, avhengig av hvilke policyer du konfigurerer.

I del 1 drøftes konseptene og et sett med anbefalteretningslinjer. I del 2 gis en trinnvis beskrivelse av hvordan du setter dem opp.

Hva er betinget tilgang?

Betinget tilgang er hjørnesteinen i Microsofts Zero Trust-initiativ. Betingelsene som legges til grunn, tar utgangspunkt i disse størrelsene:

• Bruker- og stedsbasert. Hold følsomme data beskyttet ved å begrense brukertilgang basert på geolokasjon eller IP-adresse med stedsbaserte policyer for betinget tilgang.
• Enhetsbasert. Sørg for at bare registrerte og klarerte enheter får tilgang til bedriftsdata med enhetsbasert betinget tilgang.
• Applikasjonsbasert. Arbeidet behøver ikke stoppe opp når bruker ikke er på bedriftsnettverket. Sikre tilgang til bedriftsskyen og lokale apper og oppretthold kontroll med betinget tilgang.
• Risiko-basert. Beskytt dine data mot ondsinnete hackere med risikobaserte policyer som kan benyttes på alle apper og alle brukere, enten lokalt eller i skyen (krever Entra ID Premium P2).

For å oppnå maksimal sikkerhet ønsker vi at enheter deltar i godkjenningsprosessen. Det krever at de er innrullert i Microsoft Intune, selskapets plattform for mobil enhets- og applikasjonsbehandling. Med samsvarspolicyer setter du opp regler de må innfri: sikker oppstart, kryptert lagring, OS-versjon, oppdatert programvare osv. Om de ikke oppfyller kriteriene, slipper de ikke inn før svakhetene er eliminert; det betyr at brukere ikke kan logge på Microsofts skyplattformer fra dem. Et tilleggsmoment er at Defender for Endpoint/Business kan endre samsvarsstatus når det oppdages skadevare.

Med Entra ID Premium P1 (og Microsoft 365 Business Premium) angir vibetingelser med utgangpunkt i bruker/gruppemedlemskap, fysisk oppholdssted, enhetshelse og apper. Men det er nødvendig med Premium P2 for å sette opp retningslinjer for risikobasert brukertilgang, som bestemmer om vi har å gjøre med risikofylte pålogginger eller risikable/kompromitterte brukere. Denne oppgaven tar Entra ID Identitetsbeskyttelse seg av.

Zero Trust-tilgangskontroll

Strategier for effektive tilgangskontroller benytter prinsippet: «Aldri stol på noe. Alltid verifiser.» Det fattes informerte avgjørelser på bakgrunn av signaler fra alle tilgjengelige datapunkter, som omfatter enhetsrisiko (enhetsadministrasjon, trusseldeteksjon m.m.) og brukerisiko (multifaktor-autentisering, atferdsanalyse osv.). Basert på virksomhetenes retningslinjer tas det så beslutninger som anvendes på innkommende forespørsler og re-evalueres under sesjonen. Policyene håndheves på tvers av alle ressurser, som inkluderer moderne og helst også eldre applikasjoner. Disse igjen er innfallsporten til våre bedriftsdata, livsnerven i de fleste virksomheter.

Sikkerhetsstandarder

Nye leietakere (tenants) er satt opp med Sikkerhetsstandarder,som er lite fleksible og ikke kompatible med verken betinget tilgang eller identitetsbeskyttelsen i Entra ID (Azure AD). Til gjengjeld bidrar de til å sikre en virksomhet umiddelbart og gir en god idé om hvilke retningslinjer Microsoft anser for å være beste praksis. De sørger for enhetlig registrering av MFA og krever at administratorer alltid skal benytte MFA, brukere bare ved faresignaler. Det gjelder for tilgangen til alle skyapper. Eldre protokoller blokkeres. I Azure kreves MFA for administrative handlinger. Med en lisens på Entra ID Premium bør du deaktivere Sikkerhetsstandarder og gjenskape policyene med betinget tilgang samt plusse på med flere.

Bakgrunn for anbefalte retningslinjer

I Entra ID Premium P2 dukker det med jevne mellomrom opp en veiviser for MFA (ikke observert i P1). På kortet står det: «Reduser kompromitterte brukerkontoer med flerfaktorautentisering. Det er 99,99 % mindre sannsynlig at brukerkontoer blir kompromittert når du aktiverer godkjenning med flere faktorer (MFA). Vi veileder deg gjennom konfigureringen og hjelper deg med å bestemme de beste alternativene for din organisasjon.» I siste inkarnasjon tok veiviseren hensyn til at ikke alle i vår tenant har en lisens på Entra ID Premium P2. Dermed er de fleste av de grunnleggende reglene på plass: Krev MFA for administratorer, Blokker alle eldre pålogginger som ikke støter MFA, Krev MFA for eksterne og gjestebrukere og Krev MFA for interne brukere (administratorer ikke inkludert), mens Avansert risiko-deteksjon er forbeholdt Entra ID Premium P2-brukere.

En annen kilde er Microsofts policymaler. For fjernarbeidere (Remote work) kan man se nærmere på Securing security info registration og for administratorer (Emerging threats) kan man ta med Require phishing-resistant multifactor authentication for admins.

Grunnleggende oppsett av betinget tilgang

De grunnleggende policyene for betinget tilgang som bør være på plass, er som vist ovenfor. Tilgangene som beskyttes med MFA, gjelder uavkortet for alle skyapper. Det gjøres ingen unntak for såkalte klarerte nettverk. Det er heller ikke involvert noen sikkerhetsgrupper.

Require MFA for admins vil gjelde for 13 admin-kontoer (ikke bare global administrator). Påloggingsfrekvensen for disse rollene bør settes lavt, for eksempel til én dag; for andre kontoer vil den typisk være 90 dager.

Require MFA for external and guest users angår brukere som er autentisert i en annen tenant eller av en annen identitetstjeneste, som Google eller Outlook.com. Kravet om MFA autoriserer tilgangen for brukerne.

Block all legacy sign-ins that don't support MFA gjelder også for alle brukere og dekker Exchange ActiveSync-klienter. De omfatter eldre Office-klienter og andre e-postprotokoller som POP, IMAP og SMTP. Mange kunder ønsker å legge til unntak for skrivere, skannere og multifunksjonsmaskiner som benytter gammeldags SMTP Auth. Microsoft har OAuth 2.0-støtte for POP, IMAP og SMTP, som ikke blokkeres, men det er ikke mange klienter som bruker disse protokollene ennå.

Require MFA for all users er nødvendig så sant ikke alle bruker Entra ID Identitetsbeskyttelse.

Require compliant Azure AD device godtar pålogginger bare fra enheter som er konfigurert i overensstemmelse med virksomhetens samsvarspolicyer i Microsoft Intune. Samsvarsstatus kan også endres av Defender for Endpoint/Business; det gjelder for Windows, Android, iOS/iPadOS, men fortsatt ikke for macOS.

I hybride miljøer med lokalt Windows AD bør man legge til Require compliant or hybrid Azure AD joined device or multifactor authentication for all users fra Create new policy from templates (Preview).

Blocked Countries skal som minimum inneholde land som Russland, Kina, Iran og Nord-Korea (om man ikke reiser dit). Det gir et ekstra beskyttelseslag, selv om IP-adresser kan forfalskes.

Require MFA and password change when high-risk users are detected og Require MFA when risky sign-ins are detected gjelder ikke for standard Microsoft 365 Business Premium; disse to policyene er knyttet til Entra ID Identitetsbeskyttelse.

Require multifactor authentication for Azure management er nødvendig om noen Azure-tjenester er integrert i Microsoft 365, så som Microsoft Sentinel.

Når disse grunnleggende retningslinjene er satt opp, kan man skrittvis forfine tilgangene. Betinget tilgang autentiserer ikke brukere – dét er det Entra ID som gjør – men autoriserer adgangen til ressurser. Den stiller ytterligere krav til hvilke betingelser som må oppfylles. Policymotoren i betinget tilgang opererer ikke ovenfra og ned, men trekker inn alle regler i den endelige evalueringen. Sånn kan man for eksempel gi begrenset adgang til SharePoint og Exchange fra enheter som ikke er registrert i Intune og dermed ikke krever samsvar, sammen med policyene som er satt opp her.

Eldre MFA per bruker (ikke anbefalt)

For ordens skyld bør det nevnes at det finnes en tredje måte å sette opp MFA på i Microsoft 365: Eldre MFA per bruker, også omtalt som Office 365 MFA, bør unngås. Innstillingene her overstyrer de to andre metodene, som er sikkerhetsstandarder og betinget tilgang. Velg Godkjenning med flere faktorer i Microsoft 365-administrasjonssenter. Sørg for at alle brukere er deaktivert for MFA.

Avsluttende ord

Grensesnittet i Entra ID bruker engelsk, og vi har holdt oss til samme språk. I neste del for du en trinnvis beskrivelse av hvordan man setter opp de anbefalte retningslinjene for betinget tilgang.