Planera en distribution av villkorsstyrd åtkomst

  • Artikel

Det är viktigt att planera distributionen av villkorsstyrd åtkomst för att uppnå organisationens åtkomststrategi för appar och resurser. Principer för villkorsstyrd åtkomst ger stor flexibilitet i konfigurationen. Men den här flexibiliteten innebär också att du bör planera noggrant för att undvika oönskade resultat.

Villkorsstyrd åtkomst i Microsoft Entra kombinerar signaler som användare, enhet och plats för att automatisera beslut och tillämpa organisationens åtkomstprinciper för resurser. Dessa principer för villkorsstyrd åtkomst hjälper dig att balansera säkerhet och produktivitet, framtvinga säkerhetskontroller när det behövs och hålla dig borta från användaren när det inte är det.

Villkorlig åtkomst är grunden för Microsofts Nolltillit säkerhetsprincipmotor.

Diagram som visar en översikt över villkorsstyrd åtkomst på hög nivå.

Microsoft tillhandahåller säkerhetsstandarder som säkerställer en grundläggande säkerhetsnivå som är aktiverad i klientorganisationer som inte har Microsoft Entra ID P1 eller P2. Med villkorlig åtkomst kan du skapa principer som ger samma skydd som säkerhetsstandarder, men med kornighet. Standardinställningar för villkorlig åtkomst och säkerhet är inte avsedda att kombineras eftersom skapandet av principer för villkorsstyrd åtkomst hindrar dig från att aktivera standardinställningar för säkerhet.

Förutsättningar

Kommunicera ändring

Kommunikation är avgörande för att alla nya funktioner ska lyckas. Du bör proaktivt kommunicera med användarna om hur deras upplevelse ändras, när den ändras och hur du får support om de får problem.

Komponenter för princip för villkorsstyrd åtkomst

Principer för villkorsstyrd åtkomst besvarar frågor om vem som kan komma åt dina resurser, vilka resurser de kan komma åt och under vilka villkor. Principer kan utformas för att bevilja åtkomst, begränsa åtkomst med sessionskontroller eller blockera åtkomst. Du skapar en princip för villkorsstyrd åtkomst genom att definiera if-then-instruktioner som:

Om en tilldelning uppfylls Tillämpa åtkomstkontrollerna
Om du är en användare i Finance som har åtkomst till löneprogrammet Kräv multifaktorautentisering och en kompatibel enhet
Om du inte är medlem i Finance och har åtkomst till löneprogrammet Blockera åtkomst
Om användarrisken är hög Kräv multifaktorautentisering och en säker lösenordsändring

Användarundantag

Principer för villkorlig åtkomst är kraftfulla verktyg. Vi rekommenderar att du undantar följande konton från dina principer:

  • Nödåtkomst eller break-glass-konton för att förhindra kontoutelåsning i hela klientorganisationen. I det osannolika scenariot är alla administratörer utelåst från din klientorganisation, och ditt administrationskonto för nödåtkomst kan användas för att logga in på klientorganisationen för att vidta åtgärder för att återställa åtkomsten.
  • Tjänstkonton och tjänstens huvudnamn, till exempel Microsoft Entra Anslut Sync-konto. Tjänstkonton är icke-interaktiva konton som inte är knutna till någon viss användare. De används normalt av serverdelstjänster som tillåter programmatisk åtkomst till program, men används även för att logga in på system i administrativa syften. Tjänstkonton som dessa bör undantas eftersom MFA inte kan slutföras programmatiskt. Anrop som görs av tjänstens huvudnamn blockeras inte av principer för villkorsstyrd åtkomst som begränsas till användare. Använd villkorsstyrd åtkomst för arbetsbelastningsidentiteter för att definiera principer som riktar sig till tjänstens huvudnamn.
    • Om din organisation har dessa konton som används i skript eller kod kan du överväga att ersätta dem med hanterade identiteter. Som en tillfällig lösning kan du exkludera dessa specifika konton från baslinjeprincipen.

Ställ rätt frågor

Här följer några vanliga frågor om tilldelningar och åtkomstkontroller. Dokumentera svaren på frågor för varje princip innan du skapar den.

Användar- eller arbetsbelastningsidentiteter

  • Vilka användare, grupper, katalogroller eller arbetsbelastningsidentiteter ingår i eller undantas från principen?
  • Vilka konton eller grupper för nödåtkomst ska undantas från principen?

Molnappar eller åtgärder

Gäller den här principen för alla program, användaråtgärder eller autentiseringskontexter? Om ja:

  • Vilka program eller tjänster gäller principen för?
  • Vilka användaråtgärder omfattas av den här principen?
  • Vilka autentiseringskontexter tillämpas den här principen på?
Filtrera för program

Genom att använda filter för program för att inkludera eller exkludera program i stället för att individuellt ange dem hjälper det organisationer:

  • Skala enkelt och rikta in dig på valfritt antal program.
  • Hantera enkelt program med liknande principkrav.
  • Minska antalet enskilda principer.
  • Minska fel vid redigering av principer: Du behöver inte lägga till/ta bort program manuellt från principen. Hantera bara attributen.
  • Övervinna begränsningar för principstorlek.

Villkor

  • Vilka enhetsplattformar ingår i eller undantas från principen?
  • Vilka är organisationens kända nätverksplatser?
    • Vilka platser ingår i eller exkluderas från principen?
  • Vilka klientappstyper ingår i eller exkluderas från principen?
  • Behöver du rikta in dig på specifika enhetsattribut?
  • Om du använder Microsoft Entra ID Protection, vill du ta med inloggnings- eller användarrisker?
Användar- och inloggningsrisk

För organisationer med Microsoft Entra ID P2-licenser kan de inkludera användar- och inloggningsrisker i sina principer för villkorsstyrd åtkomst. Dessa tillägg kan bidra till att minska friktionen av säkerhetsåtgärder genom att kräva multifaktorautentisering eller säker lösenordsändring endast när en användare eller inloggning anses vara riskabel.

Mer information om risker och dess användning i principen finns i artikeln Vad är risk.

Blockera eller bevilja kontroller

Vill du bevilja åtkomst till resurser genom att kräva ett eller flera av följande?

  • Multifaktorautentisering
  • Enheten markeras som kompatibel
  • Använda en Hybrid-ansluten Microsoft Entra-enhet
  • Använda en godkänd klientapp
  • Appskydd princip som tillämpas
  • Lösenordsändring
  • Användningsvillkor accepteras

Blockera åtkomst är en kraftfull kontroll som du ska ha tillräckligt med information om för att använda. Principer med blockeringsinstruktioner kan ha oavsiktliga sidoeffekter. Korrekt testning och validering är avgörande innan du aktiverar kontrollen i stor skala. Administratörer bör använda verktyg som rapportläge för villkorsstyrd åtkomst och verktyget What If i villkorlig åtkomst när de gör ändringar.

Sessionskontroller

Vill du framtvinga någon av följande åtkomstkontroller i molnappar?

  • Använda apptvingande begränsningar
  • Använda appkontroll för villkorsstyrd åtkomst
  • Framtvinga inloggningsfrekvens
  • Använda beständiga webbläsarsessioner
  • Anpassa utvärdering av kontinuerlig åtkomst

Kombinera principer

När du skapar och tilldelar principer måste du ta hänsyn till hur åtkomsttoken fungerar. Åtkomsttoken beviljar eller nekar åtkomst baserat på om de användare som gör en begäran har auktoriserats och autentiserats. Om beställaren kan bevisa att de är de som de påstår sig vara, kan de komma åt de skyddade resurserna eller funktionerna.

Åtkomsttoken utfärdas som standard om ett villkor för villkorlig åtkomst inte utlöser en åtkomstkontroll.

Den här principen förhindrar inte att appen har sin egen möjlighet att blockera åtkomst.

Tänk dig till exempel ett förenklat principexempel där:

Användare: EKONOMIGRUPP
Åtkomst: LÖNEAPP
Åtkomstkontroll: Multifaktorautentisering

  • Användare A finns i EKONOMIGRUPPEN, de måste utföra multifaktorautentisering för att få åtkomst till LÖNEAPPen.
  • Användare B finns inte i EKONOMIGRUPPEN, utfärdas en åtkomsttoken och får åtkomst till LÖNEAPPen utan att utföra multifaktorautentisering.

För att säkerställa att användare utanför ekonomigruppen inte kan komma åt löneappen kan en separat princip skapas för att blockera alla andra användare, till exempel följande förenklade princip:

Användare: Inkludera alla användare/exkludera FINANCE GROUP
Åtkomst: LÖNEAPP
Åtkomstkontroll: Blockera åtkomst

Nu när användare B försöker komma åt LÖNEAPPen blockeras de.

Rekommendationer

Med tanke på våra lärdomar i användningen av villkorsstyrd åtkomst och stöd till andra kunder finns här några rekommendationer som baseras på våra lärdomar.

Tillämpa principer för villkorsstyrd åtkomst för varje app

Se till att varje app har minst en princip för villkorsstyrd åtkomst tillämpad. Ur ett säkerhetsperspektiv är det bättre att skapa en princip som omfattar Alla molnappar och sedan exkludera program som du inte vill att principen ska gälla för. Den här metoden säkerställer att du inte behöver uppdatera principer för villkorsstyrd åtkomst varje gång du registrerar ett nytt program.

Dricks

Var mycket försiktig med att använda blockering och alla appar i en enda princip. Detta kan låsa administratörer och undantag kan inte konfigureras för viktiga slutpunkter som Microsoft Graph.

Minimera antalet principer för villkorsstyrd åtkomst

Att skapa en princip för varje app är inte effektivt och leder till svår administration. Villkorlig åtkomst har en gräns på 195 principer per klientorganisation. Den här principgränsen för 195 inkluderar principer för villkorsstyrd åtkomst i alla tillstånd, inklusive läget endast för rapporter, på eller av.

Vi rekommenderar att du analyserar dina appar och grupperar dem i program som har samma resurskrav för samma användare. Om till exempel alla Microsoft 365-appar eller alla HR-appar har samma krav för samma användare skapar du en enda princip och inkluderar alla appar som den gäller för.

Principer för villkorsstyrd åtkomst finns i en JSON-fil och filen är bunden till en storleksgräns som vi inte förväntar oss att en enskild princip ska växa längre än. Om du använder en lång lista med GUID:er i din princip kan du nå den här gränsen. Om du stöter på dessa gränser rekommenderar vi alternativ som:

Läget Konfigurera endast rapport

Som standard skapas varje princip som skapas från mallen i rapportläge. Vi rekommenderar organisationer att testa och övervaka användningen för att säkerställa det avsedda resultatet innan de aktiverar varje princip.

Aktivera principer i rapportläge. När du har sparat en princip i rapportläge kan du se effekten på inloggningar i realtid i inloggningsloggarna. I inloggningsloggarna väljer du en händelse och navigerar till fliken Endast rapport för att se resultatet av varje rapportprincip.

Du kan visa aggregerade effekter av dina principer för villkorsstyrd åtkomst i arbetsboken Insikter och rapportering. För att komma åt arbetsboken behöver du en Azure Monitor-prenumeration och du måste strömma inloggningsloggarna till en log analytics-arbetsyta.

Planera för avbrott

Planera återhämtningsstrategier för din organisation för att minska risken för utelåsning under oförutsedda störningar.

Ange namngivningsstandarder för dina principer

En namngivningsstandard hjälper dig att hitta principer och förstå deras syfte utan att öppna dem i Azure-administratörsportalen. Vi rekommenderar att du namnger principen för att visa:

  • Ett sekvensnummer
  • Molnapparna som den gäller för
  • Svaret
  • Vem gäller för
  • När det gäller

Diagram som visar exempel på namngivningsstandarder för principer.

Exempel: En princip för att kräva MFA för marknadsföringsanvändare som kommer åt Dynamics CRP-appen från externa nätverk kan vara:

Diagram som visar ett exempel på namngivningsstandard.

Ett beskrivande namn hjälper dig att hålla en översikt över implementeringen av villkorsstyrd åtkomst. Sekvensnumret är användbart om du behöver referera till en princip i en konversation. När du till exempel pratar med en administratör på telefonen kan du be dem att öppna principen CA01 för att lösa ett problem.

Namngivningsstandarder för nödåtkomstkontroller

Utöver dina aktiva principer implementerar du inaktiverade principer som fungerar som sekundära elastiska åtkomstkontroller i avbrott eller nödsituationsscenarier. Din namngivningsstandard för beredskapsprinciperna bör innehålla:

  • AKTIVERA I NÖDFALL i början för att få namnet att sticka ut bland de andra principerna.
  • Namnet på avbrott som det ska gälla för.
  • Ett ordningsföljdsnummer som hjälper administratören att veta i vilken ordning principer ska aktiveras.

Exempel: Följande namn anger att den här principen är den första av fyra principer som ska aktiveras om det uppstår ett MFA-avbrott:

  • EM01 – AKTIVERA I NÖDFALL: MFA-avbrott [1/4] – Exchange SharePoint: Kräv Microsoft Entra-hybridanslutning för VIP-användare.

Blockera länder/regioner som du aldrig förväntar dig inloggning från

Med Microsoft Entra-ID kan du skapa namngivna platser. Skapa listan över länder/regioner som tillåts och skapa sedan en nätverksblockeringsprincip med dessa "tillåtna länder/regioner" som ett undantag. Det här alternativet skapar mindre omkostnader för kunder som är baserade på mindre geografiska platser. Se till att undanta dina konton för nödåtkomst från den här principen.

Distribuera principer för villkorsstyrd åtkomst

När du är klar distribuerar du dina principer för villkorsstyrd åtkomst i faser.

Skapa dina principer för villkorsstyrd åtkomst

Se principmallar för villkorsstyrd åtkomst och Vanliga säkerhetsprinciper för Microsoft 365-organisationer för ett försprång. Dessa mallar är ett praktiskt sätt att distribuera Microsoft-rekommendationer. Se till att du undantar dina konton för nödåtkomst.

Utvärdera effekten av principen

Vi rekommenderar att du använder följande verktyg för att utvärdera effekten av dina principer både före och efter ändringar. En simulerad körning ger dig en bra uppfattning om vilken effekt en princip för villkorsstyrd åtkomst har. Den ersätter inte en faktisk testkörning i en korrekt konfigurerad utvecklingsmiljö.

Testa dina principer

Se till att du testar undantagskriterierna för en princip. Du kan till exempel exkludera en användare eller grupp från en princip som kräver MFA. Testa om de exkluderade användarna uppmanas att använda MFA eftersom kombinationen av andra principer kan kräva MFA för dessa användare.

Kör alla tester i testplanen med testanvändare. Testplanen är viktig så att du kan jämföra det förväntade och det faktiska resultatet. I följande tabell beskrivs några exempel på testfall. Justera scenarierna och det förväntade resultatet baserat på hur dina principer för villkorsstyrd åtkomst är konfigurerade.

Policy Scenario Förväntat resultat
Riskfyllda inloggningar Användaren loggar in på appen med en webbläsare som inte har godkänts Beräknar en riskpoäng baserat på sannolikheten att inloggningen inte utfördes av användaren. Kräver att användaren självreparerar med hjälp av MFA
Enhetshantering Behörig användare försöker logga in från en auktoriserad enhet Åtkomst beviljad
Enhetshantering Behörig användare försöker logga in från en obehörig enhet Åtkomst blockerad
Lösenordsändring för riskfyllda användare Behörig användare försöker logga in med komprometterade autentiseringsuppgifter (högriskinloggning) Användaren uppmanas att ändra lösenord eller åtkomst blockeras baserat på din princip

Distribuera i produktion

När du har bekräftat påverkan med läget endast rapport kan en administratör flytta växlingsknappen Aktivera princip från Endast rapport till På.

Återställa principer

Om du behöver återställa dina nyligen implementerade principer använder du ett eller flera av följande alternativ:

  • Inaktivera principen. Om du inaktiverar en princip ser du till att den inte tillämpas när en användare försöker logga in. Du kan alltid komma tillbaka och aktivera principen när du vill använda den.

  • Undanta en användare eller grupp från en princip. Om en användare inte kan komma åt appen kan du välja att undanta användaren från principen.

    Varning

    Undantag bör användas sparsamt, endast i situationer där användaren är betrodd. Användare bör läggas till i principen eller gruppen igen så snart som möjligt.

  • Om en princip är inaktiverad och inte längre krävs tar du bort den.

Felsöka principer för villkorsstyrd åtkomst

Om en användare har problem med en princip för villkorsstyrd åtkomst samlar du in följande information för att underlätta felsökningen.

  • Användarhuvudnamn
  • Användarens visningsnamn
  • Operativsystemnamn
  • Tidsstämpel (ungefärligt är ok)
  • Målprogram
  • Klientprogramtyp (webbläsare kontra klient)
  • Korrelations-ID (detta ID är unikt för inloggningen)

Om användaren har fått ett meddelande med länken Mer information kan hen samla in det mesta av den här informationen åt dig.

Skärmbilder av ett exempel på ett felmeddelande och mer information.

När du har samlat in informationen kan du läsa följande resurser:

  • Inloggningsproblem med villkorsstyrd åtkomst – Förstå oväntade inloggningsresultat relaterade till villkorsstyrd åtkomst med hjälp av felmeddelanden och Inloggningslogg för Microsoft Entra.
  • Använda verktyget What-If – Förstå varför en princip tillämpades eller inte tillämpades på en användare under en viss situation eller om en princip skulle tillämpas i ett känt tillstånd.

Relaterat innehåll