Ramverk och principer för villkorlig åtkomst
Den här artikeln innehåller ett ramverk för att implementera en persona-baserad arkitektur för villkorsstyrd åtkomst, som den som beskrivs i arkitekturen för villkorlig åtkomst Nolltillit. I den här artikeln finns information om hur du skapar och namnger principer för villkorsstyrd åtkomst. Det finns också en startpunkt för att skapa principer.
Om du inte använder ett ramverk som det som anges här, inklusive en namngivningsstandard, tenderar principer att skapas över tid av olika personer på ett ad hoc-sätt. Detta kan resultera i principer som överlappar varandra. Om personen som skapade en princip inte längre är tillgänglig kan det vara svårt för andra att känna till syftet med principen.
Genom att följa ett strukturerat ramverk blir det lättare att förstå principerna. Det gör det också enklare att täcka alla scenarier och undvika motstridiga principer som är svåra att felsöka.
Namngivningskonventioner
En korrekt definierad namngivningskonvention hjälper dig och dina kollegor att förstå syftet med en princip, vilket möjliggör enklare principhantering och felsökning. Namngivningskonventionen bör passa det ramverk som du använder för att strukturera dina principer.
Den rekommenderade namngivningsprincipen baseras på personas, principtyper och appar. Det ser ut så här:
<CANumber-Persona-PolicyType-App-Platform-GrantControl-OptionalDescription><><><><><><>
Komponenterna i det här namnet beskrivs här:
| Namndel | Beskrivning/exempel |
|---|---|
| CA-nummer | Används för att snabbt identifiera principtypsomfång och ordning. Exempel: CA001-CA099. |
| Persona | Global, Admins, Internals, Externals, GuestUsers, GuestAdmins, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts. |
| Policytyp | BaseProtection, AppProtection, DataProtection, IdentityProtection, AttackSurfaceReduction, Compliance. |
| App | AllApps, O365 (för alla Office 365-tjänster), EXO (för Exchange Online). |
| Plattform | AnyPlatform, Unknown, Windows Telefon, macOS, iOS, Android. |
| Bevilja kontroll | Blockera, ADHJ, Kompatibel, Ohanterad (där ohanterad anges i tillståndet för enheten). |
| beskrivning | Valfri beskrivning av syftet med principen. |
Numreringsschema
För att underlätta administrationen föreslår vi det här numreringsschemat:
| Persona-grupp | Nummerallokering |
|---|---|
| CA-Persona-Global | CA001-CA099 |
| CA-Persona-Admins | CA100-CA199 |
| CA-Persona-Internals | CA200-CA299 |
| CA-Persona-Externals | CA300-CA399 |
| CA-Persona-GuestUsers | CA400-CA499 |
| CA-Persona-GuestAdmins | CA500-CA599 |
| CA-Persona-M365ServiceAccounts | CA600-CA699 |
| CA-Persona-AzureServiceAccounts | CA700-CA799 |
| CA-Persona-CorpServiceAccounts | CA800-CA899 |
| CA-Persona-WorkloadIdentiteter | CA900-CA999 |
| CA-Persona-Developers | CA1000-CA1099 |
Policytyper
Det här är de rekommenderade principtyperna:
| Principtyp | Beskrivning/exempel |
|---|---|
| BaseProtection | För varje persona finns det ett baslinjeskydd som omfattas av den här principtypen. För användare på hanterade enheter är detta vanligtvis känd användare och känd enhet. För externa gäster kan det vara känd användare och multifaktorautentisering. Basskyddet är standardprincipen för alla appar för användare i den angivna personena. Om en specifik app ska ha en annan princip kan du exkludera appen från basskyddsprincipen och lägga till en explicit princip som endast riktar sig mot appen. Exempel: Anta att basskyddet för Internals är att kräva kända användare och kända enheter för alla molnappar, men du vill tillåta Outlook på webben från valfri enhet. Du kan undanta Exchange Online från grundskyddsprincipen och lägga till en separat princip för Exchange Online, där du behöver känd enhet ELLER multifaktorautentisering. |
| IdentityProtection | Utöver basskyddet för varje persona kan du ha principer för villkorsstyrd åtkomst som är relaterade till identitet. Exempel: Blockera äldre autentisering, kräva extra multifaktorautentisering för hög användar- eller inloggningsrisk, kräver känd enhet för registrering av multifaktorautentisering. |
| DataProtection | Den här principtypen anger deltaprinciper som skyddar data som ett extra lager ovanpå basskyddet. Exempel:
|
| AppProtection | Den här principtypen är ett annat tillägg till basskyddet. Exempel:
|
| AttackSurfaceReduction | Syftet med den här typen av princip är att minimera olika attacker. Exempel:
|
| Efterlevnad | Du kan använda en efterlevnadsprincip för att kräva att en användare visar användningsvillkoren för gäster som har åtkomst till kundtjänst. |
App
I följande tabell beskrivs appkomponenten för ett principnamn:
| Appnamn | Beskrivning/exempel |
|---|---|
| AllApps | AllApps anger att alla molnappar är mål för principen för villkorsstyrd åtkomst. Alla slutpunkter omfattas, inklusive de som stöder villkorsstyrd åtkomst och de som inte har det. I vissa scenarier fungerar det inte bra att rikta in sig på alla appar. Vi rekommenderar att du riktar in dig på alla appar i basprincipen så att alla slutpunkter omfattas av principen. Nya appar som visas i Microsoft Entra-ID följer också principen automatiskt. |
| <Programnamn> | <AppName> är en platshållare för namnet på en app som principen adresserar. Undvik att göra namnet för långt. Exempelnamn:
|
Plattformstyp
I följande tabell beskrivs plattformskomponenten för ett principnamn:
| Plattformstyp | beskrivning |
|---|---|
| AnyPlatform | Principen riktar sig till valfri plattform. Du konfigurerar vanligtvis detta genom att välja Valfri enhet. (I principer för villkorsstyrd åtkomst används både ordet plattform och ordet enhet .) |
| iOS | Principen riktar sig till Apple iOS-plattformar. |
| Android | Principen riktar sig till Google Android-plattformar. |
| Windows | Den här principen riktar sig till Windows-plattformen. |
| Linux | Den här principen riktar sig till Linux-plattformarna. |
| Windows Telefon | Principen riktar sig till Windows Telefon-plattformar. |
| macOS | Principen riktar sig till macOS-plattformarna |
| iOSAndroid | Principen riktar sig till både iOS- och Android-plattformar. |
| Okänt | Principen riktar sig till alla plattformar som inte har angetts tidigare. Du konfigurerar vanligtvis detta genom att inkludera Alla enheter och exkluderas alla enskilda plattformar. |
Bevilja kontrolltyper
I följande tabell beskrivs komponenten Bevilja kontroll i ett principnamn:
| Bevilja typ | Beskrivning/exempel |
|---|---|
| Blockera | Principen blockerar inloggning |
| Multifaktorautentisering | Principen kräver multifaktorautentisering. |
| Godkänd | Principen kräver en kompatibel enhet, vilket bestäms av Endpoint Manager, så enheten måste hanteras av Endpoint Manager. |
| CompliantorAADHJ | Principen kräver en kompatibel enhet ELLER en Microsoft Entra-hybrid ansluten enhet. En vanlig företagsdator som är domänansluten är även Hybrid Microsoft Entra ID ansluten. Mobiltelefoner och Windows 10-datorer som är samhanterade eller Microsoft Entra-anslutna kan vara kompatibla. |
| CompliantandAADHJ | Principen kräver en enhet som är kompatibel och Microsoft Entra-hybridanslutning. |
| MFAorCompliant | Principen kräver en kompatibel enhet eller multifaktorautentisering om den inte är kompatibel. |
| MFAandCompliant | Principen kräver en kompatibel enhet OCH multifaktorautentisering. |
| MFAorAADHJ | Principen kräver en Microsoft Entra-hybridanslutning eller multifaktorautentisering om det inte är en Microsoft Entra-hybridanslutning. |
| MFAandAADHJ | Principen kräver en Microsoft Entra Hybrid-ansluten dator OCH multifaktorautentisering. |
| RequireApprovedClient | Principen kräver godkänd klientapp. |
| AppProtection | Principen kräver appskydd |
| Ohanterade | Principen riktar sig till enheter som inte är kända av Microsoft Entra-ID. Du kan till exempel använda den här beviljandetypen för att tillåta åtkomst till Exchange Online från valfri enhet. |
Namngivna platser
Vi rekommenderar att du definierar dessa standardplatser för användning i principer för villkorsstyrd åtkomst:
- Betrodda IP-adresser/interna nätverk. Dessa IP-undernät representerar platser och nätverk som har fysiska åtkomstbegränsningar eller andra kontroller som datorsystemhantering, autentisering på nätverksnivå eller intrångsidentifiering. Dessa platser är säkrare, så tillämpning av villkorsstyrd åtkomst kan vara avslappnad. Överväg om Azure eller andra datacenterplatser (IP-adresser) ska ingå på den här platsen eller ha egna namngivna platser.
- Citrix-betrodda IP-adresser. Om du har Citrix lokalt kan det vara användbart att konfigurera separata utgående IPv4-adresser för Citrix-servergrupperna om du behöver kunna ansluta till molntjänster från Citrix-sessioner. I så fall kan du exkludera dessa platser från principer för villkorsstyrd åtkomst om du behöver det.
- Zscaler-platser, om tillämpligt. Datorer har en ZPA-agent installerad och vidarebefordrar all trafik till Internet till eller via Zscaler-molnet. Därför är det värt att definiera Zscaler-käll-IP-adresser i villkorlig åtkomst och kräva att alla begäranden från icke-mobila enheter går via Zscaler.
- Länder/regioner som företag ska tillåtas med. Det kan vara användbart att dela upp länder/regioner i två platsgrupper: en som representerar områden i världen där anställda vanligtvis arbetar och en som representerar andra platser. På så sätt kan du tillämpa ytterligare kontroller på begäranden som kommer från utanför de områden där din organisation normalt fungerar.
- Platser där multifaktorautentisering kan vara svåra eller omöjliga. I vissa scenarier kan det göra det svårt för anställda att utföra sitt arbete genom att kräva multifaktorautentisering. Personalen kanske till exempel inte har tid eller möjlighet att svara på frekventa multifaktorautentiseringsutmaningar. Eller på vissa platser kan RF-screening eller elektrisk interferens göra det svårt att använda mobila enheter. Vanligtvis använder du andra kontroller på dessa platser, eller så kan de vara betrodda.
Platsbaserade åtkomstkontroller förlitar sig på käll-IP-adressen för en begäran för att fastställa användarens plats vid tidpunkten för begäran. Det är inte lätt att utföra förfalskning på det offentliga Internet, men skydd som tillhandahålls av nätverksgränser kan anses vara mindre relevant än det en gång var. Vi rekommenderar inte att du enbart förlitar dig på plats som ett villkor för åtkomst. Men för vissa scenarier kan det vara den bästa kontrollen som du kan använda, till exempel om du skyddar åtkomsten från ett tjänstkonto lokalt som används i ett icke-interaktivt scenario.
Rekommenderade principer för villkorsstyrd åtkomst
Vi har skapat ett kalkylblad som innehåller rekommenderade principer för villkorsstyrd åtkomst. Du kan ladda ned kalkylbladet här.
Använd de föreslagna principerna som utgångspunkt.
Dina principer ändras förmodligen med tiden för att hantera användningsfall som är viktiga för ditt företag. Här följer några exempel på scenarier som kan kräva ändringar:
- Implementera skrivskyddad åtkomst till Exchange Online för anställda med hjälp av ohanterad enhet baserat på multifaktorautentisering, appskydd och en godkänd klientapp.
- Implementera informationsskydd för att säkerställa att känslig information inte laddas ned utan förbättrat skydd från Azure Information Protection.
- Skydda mot att kopiera och klistra in av gäster.
Flera förhandsversioner går för närvarande till offentlig förhandsversion, så förvänta dig uppdateringar av den föreslagna uppsättningen med startprinciper för villkorsstyrd åtkomst (CA) snart.
Vägledning för villkorsstyrd åtkomst
Nu när du har en startuppsättning med principer för villkorsstyrd åtkomst måste du distribuera dem på ett kontrollerat och stegvis sätt. Vi föreslår att du använder en distributionsmodell.
Här är en metod:
Tanken är att först distribuera principer till ett litet antal användare inom en persona-grupp. Du kan använda en associerad Microsoft Entra-grupp med namnet Persona Ring 0 för den här distributionen. När du har kontrollerat att allt fungerar ändrar du tilldelningen till en grupp, Persona Ring 1, som har fler medlemmar och så vidare.
Sedan aktiverar du principerna med samma ringbaserade metod tills alla principer har distribuerats.
Du hanterar vanligtvis medlemmarna i ring 0 och ring 1 manuellt. En ring 2 eller 3-grupp som innehåller hundratals eller till och med tusentals användare kan hanteras via en dynamisk grupp som baseras på en procentandel av användarna i en viss persona.
Användningen av ringar som en del av en distributionsmodell är inte bara för den första distributionen. Du kan också använda den när nya principer eller ändringar av befintliga principer krävs.
Med en färdig distribution bör du även utforma och implementera de övervakningskontroller som beskrivs i principerna för villkorsstyrd åtkomst.
Förutom att automatisera den inledande distributionen kanske du vill automatisera ändringar i principer med hjälp av CI/CD-pipelines. Du kan använda Microsoft365DSC för den här automatiseringen.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudförfattare:
- Claus Jespersen | Huvudkonsult-ID&s
Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.
Nästa steg
Relaterade resurser
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för