Planera en distribution av villkorsstyrd åtkomst

Det är viktigt att planera distributionen av villkorsstyrd åtkomst för att uppnå organisationens åtkomststrategi för appar och resurser.

Azure Active Directory (Azure AD) Villkorsstyrd åtkomst analyserar signaler som användare, enhet och plats för att automatisera beslut och tillämpa principer för organisationsåtkomst för resurser. Med principer för villkorsstyrd åtkomst kan du skapa villkor som hanterar säkerhetskontroller som kan blockera åtkomst, kräva multifaktorautentisering eller begränsa användarens session när det behövs och hålla dig borta från användaren när den inte är det.

Med den här utvärderingen och tillämpningen definierar villkorsstyrd åtkomst grunden för Microsofts Nolltillit hantering av säkerhetsstatus.

Översikt över villkorsstyrd åtkomst

Microsoft tillhandahåller säkerhetsstandarder som säkerställer en grundläggande säkerhetsnivå som är aktiverad i klientorganisationer som inte har Azure AD Premium. Med villkorsstyrd å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

Förstå principkomponenter för villkorsstyrd åtkomst

Principer besvarar frågor om vem som ska komma åt dina resurser, vilka resurser de ska 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-instruktionerna: Om en tilldelning uppfylls tillämpar du åtkomstkontrollerna.

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ändare eller arbetsbelastningsidentiteter

  • Vilka användare, grupper, katalogroller och arbetsbelastningsidentiteter inkluderas 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 gäller principen för?
  • Vilka användaråtgärder kommer att omfattas av den här principen?
  • Vilka autentiseringskontexter tillämpas den här principen på?

Villkor

  • Vilka enhetsplattformar kommer att inkluderas i eller undantas från principen?
  • Vilka är organisationens betrodda platser?
  • Vilka platser kommer att inkluderas i eller undantas från principen?
  • Vilka typer av klientappar kommer att inkluderas i eller undantas från principen?
  • Har du principer som skulle innebära att Azure AD anslutna enheter eller Hybrid Azure AD anslutna enheter undantas från principer?
  • Om du använder Identity Protection, vill du inkludera inloggningsriskskydd?

Bevilja eller blockera

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

  • Krav på MFA
  • Kräv att enheten är markerad som kompatibel
  • Kräv hybrid Azure AD ansluten enhet
  • Kräv godkänd klientapp
  • Kräva appskyddsprincip
  • Kräv lösenordsändring
  • Användningsvillkor

Sessionskontroll

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

Utfärdande av åtkomsttoken

Åtkomsttoken beviljar eller nekar åtkomst baserat på om användaren 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.

Diagram över utfärdande av åtkomsttoken

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

Detta förhindrar inte att appen har separat auktorisering för att blockera åtkomst. Tänk dig till exempel en princip där:

  • Om användaren är i ekonomiteamet tvingar du sedan MFA att komma åt löneappen.
  • Om en användare som inte är i ekonomiteamet försöker komma åt löneappen får användaren en åtkomsttoken.
  • För att säkerställa att användare utanför ekonomigruppen inte kan komma åt löneappen bör en separat princip skapas för att blockera alla andra användare. Om alla användare utom ekonomiteamet och kontogruppen för nödåtkomst har åtkomst till löneappen blockerar du åtkomsten.

Följ metodtipsen

Villkorsstyrd åtkomst ger dig stor flexibilitet i konfigurationen. Men stor flexibilitet innebär också att du noggrant bör granska varje konfigurationsprincip innan du släpper den för att undvika oönskade resultat.

Konfigurera konton för nödåtkomst

Om du konfigurerar en princip fel kan den låsa organisationerna från Azure Portal.

Minska effekten av oavsiktlig administratörsutelåsning genom att skapa två eller flera konton för nödåtkomst i organisationen. Skapa ett användarkonto som är dedikerat till principadministration och exkluderat från alla dina principer.

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

Kontrollera att minst en princip för villkorsstyrd åtkomst tillämpas för varje app. 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. Detta säkerställer att du inte behöver uppdatera principer för villkorsstyrd åtkomst varje gång du registrerar ett nytt program.

Viktigt

Var mycket försiktig med att använda blockering och alla appar i en enda princip. Detta kan låsa administratörer från Azure Portal 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. 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.

Konfigurera rapportläge

Det kan vara svårt att förutsäga antalet och namnen på användare som påverkas av vanliga distributionsinitiativ, till exempel:

  • Blockera äldre autentisering
  • Kräver MFA
  • Implementera principer för inloggningsrisk

Med läget Endast rapport kan administratörer utvärdera effekten av principer för villkorsstyrd åtkomst innan de aktiveras i sin miljö. Konfigurera först dina principer i rapportläge och låt dem köras i ett intervall innan de framtvingas i din miljö.

Planera för avbrott

Om du förlitar dig på en enda åtkomstkontroll, till exempel MFA eller en nätverksplats för att skydda dina IT-system, är du sårbar för åtkomstfel om den enskilda åtkomstkontrollen blir otillgänglig eller felkonfigurerad.

Om du vill minska risken för utelåsning vid oförutsedda avbrott planerar du strategier som ska införas för din organisation.

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
  • De molnappar som den gäller för
  • Svaret
  • Vem det gäller för
  • När det gäller (om tillämpligt)

Skärmbild som visar namngivningsstandarderna 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:

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 avbrotts- eller nödsituationsscenarier. Namngivningsstandarden 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 ordningssekvensnummer 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 aktiveras om det uppstår ett MFA-avbrott:

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

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

Med Azure Active Directory kan du skapa namngivna platser. Skapa listan över länder som tillåts och skapa sedan en princip för nätverksblockering med dessa "tillåtna länder" som ett undantag. Detta är 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 princip för villkorsstyrd åtkomst

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

Skapa en princip för villkorsstyrd åtkomst

Se vanliga principer för villkorlig åtkomst för ett försprång. Ett praktiskt sätt är att använda mallen för villkorsstyrd åtkomst som medföljer Microsofts rekommendationer. Se till att du undantar dina konton för nödåtkomst.

Utvärdera princippåverkan

Innan du ser effekten av principen för villkorsstyrd åtkomst i produktionsmiljön rekommenderar vi att du använder följande två verktyg för att köra simuleringen.

Konfigurera rapportläge

Som standard skapas varje princip i rapportläge, vi rekommenderar organisationer att testa och övervaka användningen för att säkerställa avsett resultat innan de aktiverar varje princip.

Aktivera principen i rapportläge. När du har sparat principen i rapportläge kan du se hur inloggningar i realtid påverkas 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 den sammanlagda effekten 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 dina inloggningsloggar till en Log Analytics-arbetsyta .

Simulera inloggningar med hjälp av what if-verktyget

Ett annat sätt att verifiera principen för villkorsstyrd åtkomst är att använda verktyget What If, som simulerar vilka principer som skulle gälla för en användare som loggar in under hypotetiska omständigheter. Välj de inloggningsattribut som du vill testa (till exempel användare, program, enhetsplattform och plats) och se vilka principer som ska tillämpas.

Anteckning

En simulerad körning ger dig en bra uppfattning om vilken effekt en princip för villkorsstyrd åtkomst har, men den ersätter inte en faktisk testkörning.

Testa din princip

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

Utför varje test i testplanen med testanvändare. Testplanen är viktig för att ha en jämförelse mellan förväntade resultat och faktiska resultat. I följande tabell beskrivs exempel på testfall. Justera scenarierna och förväntade resultat baserat på hur dina principer för villkorsstyrd åtkomst konfigureras.

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 .

Å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.

aktivera principbild

  • 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.

exkludera användare och grupper

Anteckning

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

  • Ta bort principen. Om principen inte längre krävs tar du bort den.

Felsöka princip för villkorsstyrd åtkomst

När 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.

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

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

Det går inte att komma till appens felmeddelande

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

  • Inloggningsproblem med villkorsstyrd åtkomst – Förstå oväntade inloggningsresultat som rör villkorsstyrd åtkomst med hjälp av felmeddelanden och Azure AD inloggningslogg.
  • Använda What-If-verktyget – 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.

Nästa steg

Läs mer om multifaktorautentisering

Läs mer om Identity Protection

Hantera principer för villkorlig åtkomst med Microsoft Graph API