I innlegget Veiviser og maler for MFA med Betinget tilgang demonstrerte vi hvordan du på en enkel måte kan sette opp multifaktor-autentisering (MFA) basert på Microsofts anbefalinger om beste praksis. Det gir de grunnleggende reglene. Her fortsetter vi med retningslinjer for bare å godta pålogginger fra enheter som er registrert i Intune, og som er i samsvar. Dessuten bør du blokkere tilgang etter sted, fra land/regioner der organisasjonen din vet at trafikk ikke skal komme fra. Det bidrar ytterligere til å herde sikkerheten og stenger ikke-klarerte brukere og enheter ute allerede ved inngangsdøren. Enkelte kan oppfatte disse policyene for å være for strenge, så vi åpner til slutt opp for å begrense tilgang til SharePoint-, OneDrive- og Exchange-innhold fra ikke-administrerte enheter.
Anatomien i Betinget tilgang
Betinget tilgang er hjørnesteinen i Microsofts identitetsdrevne sikkerhet. Den bringer sammen signaler, tar beslutninger og håndhever organisasjonspolicyer for å gi tilgang til ressurser. Den grunnleggende oppbygning ser sånn ut:
Reglen må ha et navn. Den må tildeles brukere, grupper eller roller; her er det mulig å legge til unntak. Den gjelder for sky-apper eller handlinger. Det kan settes opp betingelser; her middels eller høy påloggingsrisiko.
Her vil vi ikke blokkere, men gi tilgang, riktig nok under forutsetning av at bruker oppgir MFA. Sesjoner omhandles nedenfor. Det er viktig å merke seg at policyene kan – og enkelte ganger først bør – settes opp i rapporteringsmodus.
Grunnleggende regler for MFA
I forrige blogg endte vi opp med dette oppsettet. Dette gjenskaper reglene for Sikkerhetsstandarder. Veiviser, maler og grensesnittet er på engelsk, så vi holder oss til det her.
Require MFA for admins (Krev MFA for administratorer) krever MFA for 13 administrator-roller som svarer til beskyttelsen med Sikkerhetsstandarder. Det anbefales å legge til minst to unntak for global administrator for såkalte «knus glass»-kontoer, så du ikke låser deg ute av organisasjonen.
Require MFA for external and guest users (Krev MFA for eksterne og gjestebrukere) krever at alle eksterne brukere alltid legitimerer seg med MFA for tilgang til alle sky-apper.
Block all legacy sign-ins that don't support MFA (Blokker alle eldre pålogginger som ikke støtter MFA) er tildelt alle brukere. Betingelsene er eldre autentiseringsklienter: Exchange ActiveSync-klienter og andre klienter. Tilgangskontrollene er blokker tilgang. Her kan det være aktuelt å legge til unntak for multifunksjonsskrivere og skannere som bruker SMTP Auth.
Require MFA and a password change when high-risk users are detected (Krev MFA og passordendring når høyrisikobrukere oppdages) krever at alle brukere med en lisens på Azure AD Premium P2 endrer passord når det vurderes at brukerkontoen er i fare for å være kompromittert.
Require MFA when risky sign-ins are detected (Krev MFA når risikable pålogginger oppdages) gjelder for alle brukere med Azure AD Premium P2-lisens ved risikobetonte pålogginger.
Require multifactor authentication for all users (Krev multifaktor-autentisering for alle brukere) gjelder for brukertilgang til alle sky-apper. Her ekskluderer du brukere som er lisensiert med Azure AD Premium P2. Standard for å huske MFA på enheter er 90 dager.
Krev pålogging fra administrerte enheter
Du beskytter ytterligere tilgangen til bedriftsressurser ved å kreve at brukere bare kan logge på fra en administrert enhet som er i samsvar med dine retningslinjer. Klikk på Create new policy from templates (Preview) – Opprett ny policy fra maler (forhåndsvisning). Velg Devices. Da får du opp skjermbildet ovenfor. Velg Require compliant or hybrid Azure AD joined device or multifactor authentication for all users. Klikk på Create Policy.
Policyer du oppretter basert på maler, er alltid i rapporteringsmodus. Det er tre betingelser her: (1) Krev MFA, (2) krev at enheten er i samsvar og (3) krev at enheten er hybrid Azure AD-tilkoblet. Vi kan fjerne første betingelse siden den er ivaretatt av reglene vi har satt opp allerede. Vi har ikke noe hybrid Azure AD-miljø og tar vekk dette kravet. Så slår vi på policyen.
Blokkere tilgang etter sted
Microsoft anbefaler ytterligere at vi blokkerer tilgang etter sted, fra land/regioner der organisasjonen du vet at trafikk ikke skal komme fra. Først må du definere steder, så sette opp en regel.
Velg Named locations og oppgi et navn. Kryss av for de land du ønsker å blokkere. Her har vi først valgt alle, så opphevet blokkeringen for Norge, Sverige, Danmark og Tyskland pluss en del flere. Hvis du velger Land/Regioner, kan du eventuelt velge å inkludere ukjente områder. Klikk på Create.
Policyen må ha et navn. Vi har kalt den Blocked Countries. Den er tildelt alle brukere med én ekskludering for ikke å stenge oss ute. Den gjelder for tilgangen til alle sky-apper. Det er satt opp én betingelse for Selected locations som viser til stedene vi skal blokkere. Tilgangskontrollen er Block access. Her kan det være lurt å starte forsiktig med å ha policyen i rapporteringsmodus for å teste den med VPN-forbindelser. Steder og regioner fungerer ikke med hundre prosents nøyaktighet.
Begrens tilgang til innhold fra ikke-administrerte enheter
Her har vi igjen satt opp policyen fra en mal. Den finnes under Devices og heter Use application enforced restrictions for unmanaged devices (Bruk app-håndhevede begrensninger for ikke-administrerte enheter).
Dette er en generisk policy for Betinget tilgang. Sky-appen som er valgt, er Office 365. Du må konfigurere policyen for å begrense tilgangen til SharePoint-, OneDrive- og Exchange-innhold fra ikke-administrerte enheter. For Exchange Online må du for eksempel inn i PowerShell:
Med readonly kan vedlegg vises og redigeres i nettversjonene av Office, som Word eller Excel Online. Vedlegget kan lagres i OneDrive for Business, men det er ikke mulig å laste ned vedlegget lokalt til en enhet. En annen mulighet er ReadOnlyPlusAttachmentsBlocked, som blokkerer for vedlegg i Outlook på nettet. Omdøp policyen til eksempelvis Exchange enforced restrictions for unmanaged devices. Den endelige policyen må se sånn ut:
Avsluttende ord
Da har vi satt opp de grunnleggende reglene for å komme i gang med sikkerhetsmodellen Zero Trust (Null tillit). Arkitekturen er identitetsdreven og sentrert rundt kontroll av ressurstilganger. Vi stoler ikke på noe som helst, men verifiserer alltid. Både brukeridentiteter og enheter deltar i autentiseringen (bekrefte hvem de er) og autoriseringen (avgjøre hva de skal ha adgang til).
Betinget tilgang brukes som policymotor for en Zero Trust-arkitektur som dekker både policydefinisjon og policyhåndhevelse. Basert på ulike signaler eller forhold, kan betinget tilgang blokkere eller gi begrenset tilgang til ressurser. Sånn blir identiteten (sammen med enheter) til ditt nye kontrollplan eller din nye brannmur, om du vil.
