Planlæg politikker for betinget adgang
Planlægning af udrulningen af betinget adgang er afgørende for at opnå din organisations adgangsstrategi for apps og ressourcer.
I en mobil første, cloudbaseret verden får dine brugere adgang til organisationens ressourcer overalt ved hjælp af forskellige enheder og apps. Derfor er det ikke længere nok at fokusere på, hvem der har adgang til en ressource. Du skal også overveje, hvor brugeren er, den enhed, der bruges, den ressource, der tilgås, og meget mere.
Microsoft Entra Betinget adgang (CA) analyserer signaler, f.eks. bruger, enhed og placering, for at automatisere beslutninger og gennemtvinge politikker for organisationsadgang for ressourcer. Du kan bruge politikker for nøglecenter til at anvende adgangskontrolelementer som multifaktorgodkendelse (MFA). Ca-politikker giver dig mulighed for at bede brugerne om MFA, når det er nødvendigt af hensyn til sikkerheden, og holde sig ude af brugernes måde, når det ikke er nødvendigt.
Selvom sikkerhed som standard sikrer et grundlæggende sikkerhedsniveau, har din organisation brug for større fleksibilitet, end sikkerhedsstandarden tilbyder. Du kan bruge nøglecenteret til at tilpasse sikkerhedsstandarderne med flere detaljer og til at konfigurere nye politikker, der opfylder dine krav.
Personalegoder
Fordelene ved at udrulle nøglecenter er:
- Øg produktiviteten – afbryd kun brugere med en logonbetingelse, f.eks. MFA, når et eller flere signaler berettiger det. Ca-politikker giver dig mulighed for at styre, hvornår brugerne bliver bedt om at angive MFA, når adgangen er blokeret, og hvornår de skal bruge en enhed, der er tillid til.
- Administrer risici – automatisering af risikovurdering med politikbetingelser betyder, at risikobetonede logons på én gang identificeres og afhjælpes eller blokeres. Kobling af betinget adgang med identitetsbeskyttelse, som registrerer uregelmæssigheder og mistænkelige hændelser, giver dig mulighed for at målrette, når adgangen til ressourcer er blokeret eller lukket.
- Adresser overholdelse og styring – Betinget adgang giver dig mulighed for at overvåge adgang til programmer, præsentere vilkår for anvendelse af samtykke og begrænse adgang baseret på politikker for overholdelse af angivne standarder.
- Administrer omkostninger – hvis du flytter adgangspolitikker til Microsoft Entra ID, reduceres afhængigheden af brugerdefinerede løsninger eller lokale løsninger til nøglecenter og deres infrastrukturomkostninger.
- Zero Trust – Betinget adgang hjælper dig med at bevæge dig mod et miljø, der ikke har tillid til dig.
Forstå politikkomponenter for betinget adgang
Ca-politikker er if-then-sætninger: Hvis en tildeling er opfyldt, skal du anvende disse adgangskontrolelementer. Når administratoren konfigurerer ca-politikker, kaldes betingelser for tildelinger. Politikker for nøglecenter giver dig mulighed for at gennemtvinge adgangskontrol i organisationens apps baseret på visse tildelinger.
Tildelinger definerer de brugere og grupper, der skal påvirkes af politikken, de cloudapps eller -handlinger, som politikken gælder for, og de betingelser, som politikken gælder for. Indstillinger for adgangskontrol giver eller blokerer adgang til forskellige cloudapps og kan muliggøre begrænsede oplevelser i bestemte cloudapps.
Nogle almindelige spørgsmål om tildelinger, adgangskontrolelementer og sessionskontrolelementer:
- Brugere og grupper: Hvilke brugere og grupper medtages i eller udelukkes fra politikken? Omfatter denne politik alle brugere, en bestemt gruppe brugere, mapperoller eller eksterne brugere?
- Cloudapps eller -handlinger: Hvilke programmer gælder politikken for? Hvilke brugerhandlinger er underlagt denne politik?
- Betingelser: Hvilke enhedsplatforme medtages i eller udelukkes fra politikken? Hvad er organisationens placeringer, der er tillid til?
- Adgangskontrolelementer: Vil du give adgang til ressourcer ved at implementere krav som F.eks. MFA, enheder, der er markeret som kompatible, eller Microsoft Entra hybrid-tilsluttede enheder?
- Sessionskontrolelementer: Vil du styre adgangen til cloudapps ved at implementere krav som f.eks. app-gennemtvungne tilladelser eller appkontrol med betinget adgang?
Med introduktionen af Microsoft Entra-agent-id er agentidentiteter nu førsteklasses principaler i Microsoft Entra ID. Ligesom brugere eller tjenesteledere kan agenter målrettes af Conditional Access-politikker — hvilket giver dig mulighed for at anvende de samme Zero Trust-kontroller på AI-agenter, som du anvender på menneskelige identiteter. Du behandler agentidentiteter på samme måde, som du behandler arbejdsbelastningsidentiteter: scoper politikker efter identitetstype, håndhæver passende adgangskontroller og udelukker nød- eller betroede agenter, hvor det er nødvendigt.
Udstedelse af adgangstoken
Adgangstokens gør det muligt for klienter at kalde beskyttede web-API'er sikkert, og de bruges af web-API'er til at udføre godkendelse og godkendelse. I henhold til OAuth-specifikationen er adgangstokens uigennemsigtige strenge uden et angivet format. Nogle identitetsudbydere bruger GUID'er. andre bruger krypterede blobs. Microsoft-identitetsplatformen bruger en række forskellige adgangstokenformater afhængigt af konfigurationen af den API, der accepterer tokenet.
Det er vigtigt at forstå, hvordan adgangstokens udstedes.
Bemærk
Hvis der ikke kræves nogen tildeling, og der ikke er nogen nøglecenterpolitik i kraft, er standardfunktionsmåden at udstede et adgangstoken.
Overvej f.eks. en politik, hvor:
Hvis brugeren er i gruppe 1, skal du tvinge MFA til at få adgang til App 1.
Hvis en bruger, der ikke er i gruppe 1, forsøger at få adgang til appen, er betingelsen "hvis" opfyldt, og der udstedes et token. Udeladelse af brugere uden for gruppe 1 kræver en separat politik for at blokere alle andre brugere.
Følg bedste fremgangsmåder
Strukturen Betinget adgang giver dig stor fleksibilitet i konfigurationen. Stor fleksibilitet betyder dog også, at du skal gennemgå hver konfigurationspolitik omhyggeligt, før du frigiver den for at undgå uønskede resultater.
Konfigurer nødadgangskonti
Hvis du ikke konfigurerer en politik, kan den låse organisationerne ude af Azure Portal. Afhjælpe den utilsigtede administratorlåsning ved at oprette to eller flere nødadgangskonti i din organisation. Du får mere at vide om akutadgangskonti senere i dette kursus.
Konfigurer kun rapporttilstand
Det kan være svært at forudsige antallet og navnene på brugere, der påvirkes af almindelige udrulningsinitiativer, f.eks.:
- Blokerer ældre godkendelse.
- Kræver MFA.
- Implementering af politikker for logonrisiko.
Kun rapporttilstand giver administratorer mulighed for at evaluere nøglecenterets politikker, før de aktiveres i deres miljø.
Udelad lande, hvor du aldrig forventer et logon
Microsoft Entra ID giver dig mulighed for at oprette navngivne placeringer. Opret en navngivet placering, der indeholder alle de lande, hvorfra du aldrig ville forvente, at der skulle logges på. Opret derefter en politik for alle apps, der blokerer logon fra den navngivne placering. Sørg for at fritage dine administratorer fra denne politik.
Fælles politikker
Når du planlægger din nøglecenterpolitikløsning, skal du vurdere, om du har brug for at oprette politikker for at opnå følgende resultater.
Kræv MFA. Almindelige use cases omfatter krav om MFA af administratorer, til specifikke apps, til alle brugere eller fra netværksplaceringer, du ikke har tillid til.
Besvar potentielt kompromitterede konti. Tre standardpolitikker kan aktiveres: Kræve, at alle brugere tilmelder sig MFA, kræver en adgangskodeændring for brugere med høj risiko og kræver MFA for brugere med mellemstor eller høj logonrisiko.
Kræv administrerede enheder. Spredningen af understøttede enheder for at få adgang til dine cloudressourcer hjælper med at forbedre dine brugeres produktivitet. Du ønsker sandsynligvis ikke, at visse ressourcer i dit miljø skal tilgås af enheder med et ukendt beskyttelsesniveau. For disse ressourcer kræver det, at brugerne kun kan få adgang til dem ved hjælp af en administreret enhed.
Kræv godkendte klientprogrammer. Medarbejderne bruger deres mobilenheder til både personlige opgaver og arbejdsopgaver. I BYOD-scenarier skal du beslutte, om du vil administrere hele enheden eller blot dataene på den. Hvis du kun administrerer data og adgang, kan du kræve godkendte cloudapps, der kan beskytte dine virksomhedsdata.
Bloker adgang. Blokering af adgang tilsidesætter alle andre tildelinger for en bruger og har mulighed for at blokere hele organisationen fra at logge på din lejer. Den kan f.eks. bruges, når du overfører en app til Microsoft Entra ID, men du ikke er klar til, at nogen logger på den endnu. Du kan også blokere visse netværksplaceringer fra at få adgang til dine cloudapps eller blokere apps, der bruger ældre godkendelse, i at få adgang til dine lejerressourcer.
Vigtige oplysninger
Hvis du opretter en politik for at blokere adgang for alle brugere, skal du sørge for at udelade nødadgangskonti og overveje at udelade alle administratorer fra politikken.
Byg og test politikker
I hver fase af udrulningen skal du sikre dig, at du evaluerer, at resultaterne er som forventet.
Når nye politikker er klar, skal du udrulle dem i faser i produktionsmiljøet:
- Giv slutbrugerne intern kommunikation om ændringer.
- Start med et lille sæt brugere, og bekræft, at politikken fungerer som forventet.
- Når du udvider en politik til at omfatte flere brugere, skal du fortsætte med at udelade alle administratorer. Hvis administratorer udelades, sikrer du, at nogen stadig har adgang til en politik, hvis en ændring er påkrævet.
- Anvend først en politik på alle brugere, når den er gennemtestet. Sørg for, at du har mindst én administratorkonto, som en politik ikke gælder for.
Opret testbrugere
Opret et sæt testbrugere, der afspejler brugerne i dit produktionsmiljø. Oprettelse af testbrugere giver dig mulighed for at bekræfte, at politikker fungerer som forventet, før du anvender dem på rigtige brugere, og potentielt afbryde deres adgang til apps og ressourcer.
Nogle organisationer har testlejere til dette formål. Det kan dog være svært at genskabe alle betingelser og apps i en testlejer for fuldt ud at teste resultatet af en politik.
Opret en testplan
Testplanen er vigtig for at sammenligne de forventede resultater og de faktiske resultater. Du bør altid have en forventning, før du tester noget. I følgende tabel beskrives eksempeltestcases. Juster scenarierne og de forventede resultater baseret på, hvordan politikkerne for nøglecenteret er konfigureret.
| Navn på politik | scenarie | Forventet resultat |
|---|---|---|
| Kræv MFA, når du arbejder | Autoriseret bruger logger på app, mens der er tillid til en placering/arbejde, der er tillid til | Brugeren bliver ikke bedt om at angive MFA. Brugeren er autoriseret til at få adgang. Brugeren opretter forbindelse fra en placering, der er tillid til. Du kan vælge at kræve MFA i dette tilfælde. |
| Kræv MFA, når du arbejder | Godkendt bruger logger på app, mens der ikke er tillid til en placering/arbejde, der er tillid til | Brugeren bliver bedt om at angive MFA og kan logge på |
| Kræv MFA (til administrator) | Global administrator logger på app | Administratoren bliver bedt om at angive MFA |
| Risikobesærede logons | Brugeren logger på appen ved hjælp af en browser, der ikke er godkendt | Brugeren bliver bedt om at angive MFA |
| Enhedshåndtering | Godkendte brugere forsøger at logge på fra en godkendt enhed | Adgang er tildelt |
| Enhedshåndtering | Godkendte brugere forsøger at logge på fra en uautoriseret enhed | Adgang er blokeret |
| Ændring af adgangskode for risikable brugere | Godkendt bruger forsøger at logge på med kompromitterede legitimationsoplysninger (høj risiko for logon) | Brugeren bliver bedt om at ændre adgangskode, eller adgangen er blokeret på baggrund af din politik |
Licenskrav
- Gratis Microsoft Entra-id – Ingen betinget adgang
- Gratis Office 365-abonnement – ingen betinget adgang
- Microsoft Entra ID Premium 1 (eller Microsoft 365 E3 og op) – Arbejde med betinget adgang baseret på standardregler
- Microsoft Entra ID Premium 2 – Betinget adgang, og du får mulighed for at bruge risikobevarende logon, risikobebetingede brugere og risikobaserede logonindstillinger (fra Identity Protection)