Konfigurere identitetsbeskyttelse og MFA i Azure AD

Det er ikke lenger valgfritt å beskytte identiteter i skyen; det er en kritisk komponent i enhver moderne sikkerhetsstrategi . Azure AD, nå Microsoft Entra ID, har blitt det sentrale knutepunktet for autentisering på tvers av Microsoft 365, SaaS-applikasjoner og hybridmiljøer (se Konfigurer Azure AD og SharePoint ), så enhver feil her kan kompromittere hele organisasjonen. Derfor er det så viktig å forstå hvordan du konfigurerer både identitetsbeskyttelse og flerfaktorautentisering (MFA) på riktig og konsekvent måte .

Med riktig konfigurasjon kan du kombinere MFA, betinget tilgang, identitetsbeskyttelse og moderne autentiseringsmetoder (inkludert OATH-tokener og FIDO2-nøkler; se introduksjon til kryptografi ) for å oppnå en balanse mellom sterk sikkerhet og en rimelig brukeropplevelse . Gjennom denne artikkelen vil vi bryte ned alle nøkkelalternativene i detalj: varsler om mistenkelig aktivitet, bruk av OATH-tokener, konfigurasjon av telefonsamtaler, klarerte IP-adresser, verifiseringsmetoder, policyer for betinget tilgang, hybridscenarier med Active Directory og risikobaserte adaptive autentiseringsfunksjoner.

Flerfaktorautentisering er prosessen der brukeren blir bedt om å oppgi én eller flere bekreftelsesfaktorer i tillegg til passordet sitt under pålogging. Dette kan være en kode sendt til en mobilenhet, et push-varsel i Microsoft Authenticator, et OATH-maskinvaretoken, en FIDO2-nøkkel eller til og med biometriske data som et fingeravtrykk (via Windows Hello for Business).

Målet er at selv om en angriper stjeler eller gjetter passordet, vil de bli sittende fast fordi de mangler den andre autentiseringsfaktoren . Gitt volumet av lekket og kjøpt legitimasjon på nettet, og effektiviteten til phishing, har MFA blitt et av de mest effektive forsvarene mot identitetsbaserte angrep , både i Azure AD og lokal Active Directory.

Parallelt legger Microsoft Entra ID Protection til et lag med risikodeteksjon og -vurdering for pålogginger og identiteter. Basert på signaler som uvanlige steder, ukjente enheter, kjente angrepsmønstre eller til og med brukerrapporter, kan systemet flagge kontoer som høyrisiko og tillate at utbedringspolicyer (som å blokkere tilgang eller tilbakestille passord) iverksettes.

I praksis tillater kombinasjonen av MFA med identitetsbeskyttelse og betinget tilgang at ytterligere sikkerhetstiltak kun kreves når konteksten tilsier det (for eksempel når det er høy risiko), noe som reduserer friksjon uten at det går på bekostning av sikkerheten. Denne adaptive tilnærmingen er stadig mer ettertraktet av organisasjoner for sine hybride og eksterne arbeidsmiljøer.

Varsling om mistenkelig aktivitet og høyrisikobrukere

Et av de mest interessante aspektene ved identitetsbeskyttelse i Azure AD er muligheten for brukere å direkte flagge ukjente MFA-forespørsler som mistenkelige. Dette kan gjøres via Microsoft Authenticator-appen (ved å avvise og rapportere forespørselen) eller via telefonsamtalealternativer.

Når en bruker rapporterer en MFA-forespørsel som svindel, logger Entra ID Protection den som brukerrapportert mistenkelig aktivitet og hever kontostatusen til Høyrisikobruker . Derfra kommer dine konfigurerte risikobaserte policyer eller manuelle responsprosesser i spill.

Denne hendelsen gjenspeiles i flere logger og dashbord: i risikodeteksjonsrapporten (deteksjonstype «mistenkelig aktivitet rapportert av brukeren», høyt risikonivå, sluttbrukerens opprinnelse), i påloggingsloggene (autentiseringsresultat som MFA avvist av brukeren ) og i revisjonsloggene som en spesifikk aktivitet. Alt dette er viktig hvis du vil undersøke identitetshendelser eller automatisere responser, og for dette er cybersikkerhetsopplæring for ansatte avgjørende.

For å aktivere denne funksjonen, gå til Microsoft Entra-administrasjonssenteret, naviger til Entra ID > Autentiseringsmetoder > Innstillinger og aktiver alternativet «Rapporter mistenkelig aktivitet» . Hvis du lar den være satt til «Administrert av Microsoft», forblir funksjonen inaktiv, så du bør gjennomgå denne innstillingen hvis du vil at brukerne dine aktivt skal delta i å oppdage angrep.

Du kan også definere en rapportkode som brukere skriver inn under taleanrop for å markere forsøket som mistenkelig, forutsatt at du også har lastet opp egendefinerte talehilsener for leietakeren. Hvis du ikke konfigurerer noe, er standardkoden 0, uavhengig av hva du definerer i policyen.

Risikostyring med Microsoft-lisenser. Skriv inn ID P1

Med en P1-lisens er mulighetene for identitetsbeskyttelse noe mer begrensede, men du kan fortsatt se og undersøke risikodeteksjoner knyttet til brukere som har flagget MFA som mistenkelig. Disse deteksjonene vises i risikorapporten, påloggingsloggene og revisjonsloggene, noe som gir deg et godt utgangspunkt for rettsmedisinsk analyse.

Tiltakene i dette scenariet er vanligvis manuelle eller halvautomatiske: IT-teamet eller støttetjenesten kan kreve at brukere utfører en tilbakestilling av passord ved hjelp av SSPR (Self-Service Password Reset) eller endrer passordet på deres vegne. Arbeidsflyter kan også automatiseres ved hjelp av Microsoft Graph eller PowerShell for å tvinge frem passordendringer, tilbakekalle aktive økter eller til og med midlertidig deaktivere kontoen mens problemet undersøkes.

I miljøer uten P2 kan du også utnytte risikohendelser gjennom Graph API-er for å bygge dine egne responsarbeidsflyter , integrere dem med billettsystemer eller SIEM/SOAR-løsninger, og dermed oppnå mer profesjonell orkestrering av identitetshendelser.

Automatisk risikokorrigering med Microsoft Enter ID P2

Med P2-lisenser kommer den kraftigste komponenten inn i bildet: risikobaserte retningslinjer for betinget tilgang . Disse retningslinjene lar systemet automatisk iverksette handlinger som å blokkere pålogging eller kreve tilbakestilling av passord når en bruker er merket som høyrisiko (for eksempel etter å ha rapportert mistenkelig aktivitet).

I innstillingene for betinget tilgang kan du gå til Betingelser > Brukerrisiko og angi regler som reagerer på verdier som høy eller middels risiko. Et klassisk eksempel er å konfigurere brukere med høy risiko til å endre passordet sitt før de kan fortsette , eller de vil bli låst ute inntil en administrator gjennomgår saken.

Denne adaptive autentiseringsmodellen integreres sømløst med MFA: i stedet for å kreve en annen faktor statisk, kan du heve autentiseringskravene basert på sanntidsrisiko (uvanlig plassering, mistenkelig IP-adresse, avvikende oppførsel osv.). På denne måten blir ikke brukeren overveldet av MFA-forespørsler når alt er «normalt», men terskelen heves så snart noe tyder på et potensielt angrep.

OATH-tokener og TOTP-koder i Azure AD

I tillegg til den klassiske Microsoft Authenticator-appen støtter Entra ID OATH TOTP-maskinvaretokener som genererer tidsbaserte engangskoder (OTP-er), vanligvis hvert 30. eller 60. sekund, ved hjelp av SHA-1. Dette alternativet er godt egnet for organisasjoner som foretrekker dedikerte fysiske enheter for MFA på grunn av interne retningslinjer, regulerte sektorer eller brukere uten en bedriftssmarttelefon.

Disse tokenene leveres vanligvis med en fabrikkprogrammert hemmelig nøkkel (seed). For å bruke dem med Azure AD må denne nøkkelen legges inn i leietakeren via en CSV-fil. Det er noen viktige begrensninger: den hemmelige nøkkelen er begrenset til 128 Base32-kodede tegn , kan bare inneholde bokstavene a–å og a–Å og sifrene 1 til 7, og må overholde det forventede formatet for at systemet skal godta den.

Det er også mulig å bruke programmerbare, rekonfigurerbare OATH TOTP-maskinvaretokener , og behandle dem på samme måte som programvaretokener. Støtte for maskinvare-OATH-tokener er imidlertid en del av en offentlig forhåndsvisning, med de implikasjonene det medfører: potensielle endringer, begrensninger og ytterligere bruksvilkår som beskrevet i Azure Previews-avtalen.

Opplastingsprosessen for tokener gjøres ved hjelp av en CSV-fil med kolonner som UPN, serienummer, hemmelig nøkkel, tidsintervall, produsent og modell. Etter at den er lastet opp fra Enter ID > Multifaktorautentisering > OATH-tokens , behandler tjenesten filen og lar deg se formateringsfeil i en nedlastbar CSV-fil.

Når feilene er rettet, må hvert token aktiveres manuelt : administratoren velger «Aktiver» og skriver inn engangskoden som vises av enheten, som permanent kobler tokenet til brukeren. Hver person kan kombinere opptil fem tokenbaserte eller appbaserte autentiseringsfaktorer samtidig, noe som gir betydelig fleksibilitet for redundans eller overgang mellom metoder.

Innstillinger for telefonsamtaler og talemeldinger

En annen mye brukt metode for MFA i Azure AD er telefonverifisering via taleanrop . Brukere mottar et automatisk anrop, og for å fullføre autentiseringen trykker de på #-tasten eller skriver inn en PIN-kode, avhengig av konfigurasjonen. Denne opplevelsen kan tilpasses i stor grad, spesielt i miljøer der taleanrop fortsatt er den foretrukne eller nødvendige metoden.

Som standard bruker Microsoft lands- eller regionspesifikke telefonnumre for å foreta anrop. I USA finnes det for eksempel flere forhåndsdefinerte numre, og i andre land finnes det en spesifikk liste. Det er viktig å dele disse numrene med brukere eller be dem legge dem til i tillatelseslistene sine hvis de bruker spamfiltre, for å unngå problemer med levering av anrop.

Hvis du foretrekker det, kan du også definere ditt eget nummer for oppringer-ID for MFA-anrop, men det må være et amerikansk nummer. Dette alternativet konfigureres under Entra ID > Multifaktorautentisering > Innstillinger for telefonsamtaler , hvor du ganske enkelt skriver inn ønsket nummer og lagrer endringene.

Et annet interessant tilpasningsalternativ er bruken av tilpassede talemeldinger . I stedet for Microsofts standard taleopptak kan du laste opp dine egne lydfiler i .wav- eller .mp3-format, med en maksimal størrelse på 1 MB og en varighet på mindre enn 20 sekunder. Hvis meldingen er for lang, kan verifiseringen mislykkes fordi brukeren ikke vil kunne svare før opptaket er ferdig.

Språket brukeren hører avhenger både av språket som oppdages i nettleseren eller konteksten deres, og språkene som er tilgjengelige i de tilpassede meldingene som lastes opp av administratoren. Hvis det for eksempel bare er en hilsen på tysk, vil den meldingen bli spilt av for både tysktalende brukere og andre, med mindre det finnes mer passende alternativer på andre språk.

Microsoft tilbyr standardskript for ulike typer meldinger (vellykket autentisering, standardhilsener, svindelmeldinger, nye forsøk, aktivering osv.), som du kan bruke som grunnlag for å spille inn din egen lyd . For å konfigurere dem, gå tilbake til delen for telefonsamtaleinnstillinger, velg «Legg til hilsen», velg meldingstype og språk, og last opp lydfilen.

Avansert MFA-tjenestekonfigurasjon og klarerte IP-adresser

I tillegg til verifiseringsmetoder tilbyr den eldre MFA-tjenestekonfigurasjonsportalen alternativer som klarerte IP-adresser, programpassord og funksjonen «Husk flerfaktorautentisering». Selv om Microsoft i økende grad fremmer bruken av betinget tilgang og en enhetlig autentiseringspolicy, er denne portalen fortsatt relevant i mange miljøer.

Klarerte IP-adresser lar brukere som kobler seg til fra bedriftens intranett (spesifikke IP-segmenter) omgå MFA i visse nettleserflyter. Denne funksjonen er tilgjengelig med Microsoft Entra ID P1 og er nyttig for å redusere friksjon i nettverket, samtidig som MFA for ekstern tilgang opprettholdes.

I administrerte leietakere kan du definere opptil 50 IP-områder i CIDR-notasjon som anses som klarerte. I forente leietakere kan du også aktivere alternativet «Alle forente brukere» slik at brukere som er autentisert via AD FS fra intranettet, omgår MFA, forutsatt at AD FS utsteder riktig varsel (insidecorporatenetwork), konfigurert via en regel for kravutstedelse.

Husk at hvis du bruker NPS-utvidelsen til å gi MFA til lokale applikasjoner, vil IP-adressen Azure AD ser alltid være NPS-serverens, så bruk av klarerte IP-områder fungerer kanskje ikke som forventet. Det er også viktig å huske at utenfor bedriftsnettverket vil MFA fortsatt være nødvendig, uavhengig av om klarerte IP-adresser er definert.

Den anbefalte måten å administrere klarerte steder i dag er gjennom betinget tilgang med navngitte steder . Fra Påloggings-ID > Betinget tilgang > Navngitte steder kan du opprette en ny plassering, merke den som klarert og definere IP-områder (for eksempel 40.77.182.32/27). Disse plasseringene brukes deretter i policyer for betinget tilgang for å avgjøre når MFA er nødvendig.

Aktiver klarerte IP-adresser ved hjelp av betinget tilgang eller eldre tjenester

Hvis du vil justere konfigurasjonen av eldre klarerte IP-adresser med betinget tilgang, finnes det et spesifikt alternativ for «Konfigurer klarerte IP-adresser for flerfaktorautentisering» i delen for navngitte steder. Der kan du angi både bruk av AD FS-intranettvarsling for forente brukere og de spesifikke offentlige IP-områdene som skal anses som klarerte.

Hvis du foretrekker å fortsette å bruke den eldre tjenestekonfigurasjonen , finner du også alternativene «For forespørsler fra forente brukere på intranettet mitt» og «For forespørsler fra et bestemt område med IP-adresseundernett» på den siden, med samme CIDR-notasjonslogikk og områdegrenser. Denne konfigurasjonen vil fortsette å bli respektert inntil du har fullført migreringen til policyen for moderne autentiseringsmetoder.

Tilgjengelige verifiseringsmetoder og håndtering av disse

Azure AD tilbyr et bredt spekter av autentiseringsmetoder som kan brukes for både MFA og SSPR, avhengig av konfigurasjonen din. Støttede flerfaktorautentiseringsmetoder inkluderer: Microsoft Authenticator, Authenticator Lite (i Outlook), Windows Hello for Business, FIDO2-sikkerhetsnøkler, OATH-maskinvaretokener, OATH-programvaretokener, SMS og taleanrop.

I tillegg finnes det metoder som e-postbekreftelse eller sikkerhetsspørsmål, som ikke regnes som MFA, men kan brukes som bekreftelsesfaktorer for SSPR. Det finnes også apppassord, som er utviklet for eldre applikasjoner som ikke støtter moderne autentisering og som brukes spesifikt i MFA-scenarier per bruker.

Microsoft anbefaler å bruke policyen for godkjenningsmetoder for å administrere alle disse metodene . Denne policyen er tilgjengelig under Påloggings-ID > Sikkerhet > Godkjenningsmetoder > Policyer. Denne enhetlige konsollen lar deg aktivere eller deaktivere metoder for forskjellige brukergrupper, definere tilleggsparametere (for eksempel å konfigurere passordløs godkjenning med Microsoft Authenticator som viser plassering og appnavn), og kontrollere både MFA og SSPR fra ett sted.

Parallelt forblir eldre policyer på plass: MFA-innstillinger i 365-administrasjonssenteret (som påvirker MFA per bruker og MFA med betinget tilgang) og innstillinger for SSPR-autentiseringsmetoder (Brukere > Tilbakestilling av passord > Autentiseringsmetoder). Disse policyene synkroniseres ikke automatisk med den nye, enhetlige policyen, så i løpet av sameksistensperioden bør du sørge for at de konfigureres konsekvent på tvers av linjen.

Behandlingsrekkefølgen når flere policyer eksisterer samtidig er: først policyen for autentiseringsmetoder, deretter de eldre MFA-innstillingene og til slutt SSPR-innstillingene. Azure AD respekterer konfigurasjonene til alle policyene, så hvis en metode er tillatt i noen av dem, kan brukeren registrere og bruke den. For å blokkere en metode fullstendig, må du begrense den i alle relevante policyer.

I selve konsollen for autentiseringsmetoder finner du også en migreringsseksjon som angir ditt nåværende stadium: Før migrering, Migrering pågår eller Migrering fullført. Selv om du er i de to første tilstandene, brukes fortsatt eldre policyer. Når du velger Migrering fullført, vil bare de moderne policyene for autentiseringsmetoder bli respektert, og de gamle vil bli ignorert.

Husk å bruke flerfaktorautentisering og klarerte enheter.

Funksjonen «Husk flerfaktorautentisering» har som mål å redusere friksjonen for brukeren ved å la dem hoppe over ytterligere verifiseringer i et konfigurert antall dager etter at flerfaktorautentiseringen er fullført på en enhet og i en nettleser. Den fungerer ved å bruke en permanent informasjonskapsel som lagres i nettleseren når brukeren velger alternativet «Ikke spør igjen på X dager».

Så lenge informasjonskapselen er gyldig (ikke har blitt slettet eller utløpt), og brukeren bruker samme nettleser, vil ikke MFA bli forespurt på nytt i den spesifikke konteksten. Hvis de bytter nettleser på samme enhet eller sletter informasjonskapslene sine, vil verifisering bli forespurt på nytt. Dette alternativet er bare tilgjengelig i nettleserbaserte flyter, ikke i applikasjoner som ikke er nettlesere , selv om Azure AD i disse applikasjonene fortsatt sjekker alderen på den siste flerfaktorautentiseringen når oppdateringstokener valideres.

Denne funksjonaliteten kan redusere antallet MFA-forespørsler betydelig i webapplikasjoner, men antallet dager må kalibreres nøye: å sette det under den typiske 90-dagers tokenutløpet i moderne klienter kan faktisk øke hyppigheten av MFA-forespørsler i visse apper. Videre kan det å kombinere denne funksjonen med betinget tilgang føre til en økning eller reduksjon i MFA-forespørsler basert på de konfigurerte reglene.

For å aktivere det, gå til Tjenesteinnstillinger > Husk flerfaktorautentisering fra den eldre MFA-tjenestekonfigurasjonsportalen, merk av for «Tillat brukere å huske flerfaktorautentisering på klarerte enheter» og angi antall dager (90 eller mindre anbefales for en god brukeropplevelse). Fra det tidspunktet vil brukerne se alternativet «Ikke spør igjen» når de går gjennom MFA.

Aktiver MFA med policyer for betinget tilgang

Selv om Azure AD lar deg aktivere MFA direkte på brukerbasis, anbefaler Microsoft å bruke betingede tilgangspolicyer for å kontrollere når og hvem som må bruke flerfaktorautentisering. Dette gir et mye høyere granularitetsnivå og er bedre egnet for virkelige scenarier: kritiske apper, tilgang fra upålitelige nettverk, privilegerte roller og så videre.

For å bruke betinget tilgang med MFA trenger du en leietaker. Det fungerer med P1- eller prøvelisenser , og en konto med minst rollen som administrator for betinget tilgang (noen MFA-alternativer kan også administreres med rollen som administrator for godkjenningspolicy). Det anbefales også å ha en testbruker som ikke er administrator og en testgruppe (for eksempel «MFA-Testgruppe») for å validere opplevelsen uten å påvirke hele organisasjonen.

Den typiske tilnærmingen innebærer å opprette en policy som gjelder for et bestemt sett med brukere eller grupper, og som utløses for bestemte skyapplikasjoner eller spesifikke handlinger. Deretter velger du «Gi tilgang» i tilgangskontrollene og merker av for «Krev flerfaktorautentisering» som en nødvendig betingelse. Policyen kan stå i rapportmodus for å observere effekten før den aktiveres.

Et klassisk testeksempel er å bruke policyen på testgruppen og en ressurs som «Windows Azure Services Management API» eller selve Microsoft Entra-administrasjonssenteret. Dette viser deg hvordan MFA blir forespurt eller brukeren blir bedt om å registrere seg for MFA hvis de ikke allerede har gjort det, når de får tilgang til disse ressursene.

Sluttbrukeropplevelsen består vanligvis av: en første pålogging uten MFA til en ubeskyttet ressurs, en utlogging og deretter tilgang til den beskyttede ressursen, hvor brukeren blir veiledet gjennom MFA-registreringsprosessen (ved hjelp av en autentiseringstelefon, en jobbtelefon med en internnummer eller en mobilapp). Etter at registreringen er fullført, utløser påfølgende pålogginger til den beskyttede ressursen verifisering i henhold til den konfigurerte metoden (push-varsel, SMS, telefonsamtale, appkode osv.).

Hybridscenarier med Active Directory og MFA

I mange miljøer forblir lokal Active Directory kjernen i identitetsinfrastrukturen , mens Azure AD leverer autentiseringsfrontend for Microsoft 365 og skyapplikasjoner. I disse tilfellene er det en stor utfordring å distribuere MFA konsekvent både lokalt og i skyen.

Active Directory tilbyr kun innebygd MFA-støtte via smartkortautentisering , som ikke bør forveksles med MFA for AD FS. For å styrke interaktive pålogginger eller RDP på ​​servere og PC-er, integrerer mange organisasjoner løsninger som Windows Hello for Business eller tredjeparts MFA-leverandører (f.eks. Duo) direkte i endepunkter eller jump-servere. Identitetsrobusthet og høy tilgjengelighet er viktige hensyn i disse designene.

Når man bruker skybaserte identitetstjenesteleverandører som Entra ID, er det vanlig å bruke verktøy som Microsoft Entra Connect (tidligere Azure AD Connect) for å synkronisere identiteter mellom lokal Active Directory og skyleietakeren. Derfra håndheves MFA, betinget tilgang og identitetsbeskyttelse på Entra ID-laget for alle applikasjoner som autentiserer direkte mot det.

Entra-leietakere uten premiumlisenser kan bruke sikkerhetsstandarder for å aktivere et grunnleggende sett med sikkerhetsinnstillinger, inkludert obligatorisk MFA og blokkering av eldre autentisering. Uten P1 eller P2 er imidlertid betinget tilgang ikke tilgjengelig, noe som begrenser muligheten til å definere spesifikke regler (etter applikasjon, plassering, risiko osv.) betydelig.

Med abonnementer som Microsoft 365 Business, E3, E5 eller Entra ID P1/P2-lisenser er betingede tilgangspolicyer derimot ulåste og kan kombineres med MFA per bruker ved behov. Både Microsoft 365 og Office 365 støtter MFA via SMS, taleanrop og Microsoft Authenticator, mens Entra ID legger til flere alternativer som FIDO2, Windows Hello, OATH-tokens og mer.

Applikasjoner som bruker moderne autentisering (som OpenID Connect eller OAuth2) og integreres direkte med Entra ID, kan sømløst utnytte alle disse betingede tilgangsfunksjonene. For eldre eller lokale applikasjoner som ikke kommuniserer direkte med Entra, kan Azure AD Application Proxy eller integrering med Network Policy Server (NPS) brukes til å legge inn MFA i autentiseringsflyten.

Adaptiv autentisering og identitetsbeskyttelse

Den nåværende trenden innen identitetssikkerhet går utover å bare bruke MFA på en enhetlig måte. Ideen er å øke eller redusere autentiseringskrav basert på kontekst, risiko og brukerens historiske atferd. Det er her adaptiv autentisering kommer inn i bildet.

Entra ID Protection analyserer kontinuerlig risikoen knyttet til både brukeren og innloggingsprosessen: uvanlige steder, ukjente enheter, mønstre knyttet til roboter eller brute-force-angrep, påloggingsinformasjon funnet på stjålne lister, osv. Når risikoen er høy, kan det utløse korrigerende tiltak, som å kreve at brukeren tilbakestiller passordet sitt eller direkte blokkere tilgang inntil en administrator griper inn.

Ved å kombinere disse funksjonene med betinget tilgang kan du utforme retningslinjer som: «hvis brukerrisikoen er høy, blokker tilgang» eller «hvis påloggingsrisikoen er middels høy, krev MFA». På denne måten oppstår verifiseringskrav bare i mistenkelige situasjoner, mens brukeren under normale omstendigheter ikke ser noen endringer i sin vanlige arbeidsflyt.

Dette ekstra laget utfyller de andre forsvarsmekanismene (patching, nettverkssegmentering, endepunktbeskyttelse, loggovervåking osv.) for å styrke den generelle motstandskraften mot angrep. Det er viktig å huske at MFA alene ikke er nok , men at det er en av de mest effektive komponentene i en identitetssentrert og grundig forsvarsstrategi.

Til syvende og sist lar nøye konfigurasjon av autentiseringsmetoder, MFA, betinget tilgang, klarerte IP-adresser, SSPR og identitetsbeskyttelse, både i skyen og i hybridmiljøer med Active Directory, deg bygge en svært sterk barriere mot legitimasjonstyveri, phishing-angrep og lateral bevegelse, samtidig som du opprettholder en brukeropplevelse som er akseptabel for daglig bruk.