I den här artikeln beskrivs en arkitektur för villkorsstyrd åtkomst som följer Nolltillit principer. Arkitekturen använder en persona-baserad metod för att bilda ett strukturerat ramverk för villkorsstyrd åtkomst.
Arkitektur för villkorlig åtkomst Nolltillit
Du måste först välja en arkitektur. Vi rekommenderar att du överväger antingen en målarkitektur eller en Nolltillit arkitektur för villkorsstyrd åtkomst. Det här diagrammet visar motsvarande inställningar:
Arkitekturen Nolltillit villkorlig åtkomst är den som bäst passar principerna för Nolltillit. Om du väljer alternativet Alla molnappar i en princip för villkorsstyrd åtkomst skyddas alla slutpunkter av de angivna beviljandekontrollerna, till exempel känd användare och känd eller kompatibel enhet. Men principen gäller inte bara för slutpunkter och appar som stöder villkorsstyrd åtkomst. Den gäller för alla slutpunkter som användaren interagerar med.
Ett exempel är en slutpunkt för enhetsinloggningsflöde som används i olika nya PowerShell- och Microsoft Graph-verktyg. Flöde för enhetsinloggning är ett sätt att tillåta inloggning från en enhet där det inte går att visa en inloggningsskärm, till exempel en IoT-enhet.
Ett enhetsbaserat inloggningskommando körs på den angivna enheten och en kod visas för användaren. Den här koden används på en annan enhet. Användaren går till https://aka.ms/devicelogin och anger användarnamn och lösenord. Efter inloggningen från den andra enheten lyckas inloggningen på IoT-enheten i användarkontexten.
Utmaningen med den här inloggningen är att den inte stöder enhetsbaserad villkorlig åtkomst. Det innebär att ingen kan använda verktygen och kommandona om du tillämpar en baslinjeprincip som kräver känd användare och känd enhet för alla molnappar. Det finns andra program som har samma problem med enhetsbaserad villkorlig åtkomst.
Den andra arkitekturen, den målinriktade , bygger på principen att du endast riktar in dig på enskilda appar som du vill skydda i principer för villkorsstyrd åtkomst. I det här fallet skyddas enhetsinloggning för slutpunkter som tidigare omfattades av alla molnappar, till exempel grafanrop till Microsoft Entra-ID, inte av principerna för villkorsstyrd åtkomst, så de fortsätter att fungera.
När du använder enhetsinloggning som exempel för att särskilja de två arkitekturerna kan du autentisera med enhetsinloggning. Enhetsinloggning kan eventuellt tillåtas för ett eller några enskilda program, eftersom varje program är målbart och därmed kan undantas i en princip för villkorsstyrd åtkomst som kräver enhetsbaserad inloggning.
Utmaningen med målarkitekturen är att du kanske glömmer att skydda alla dina molnappar. Trots detta skulle du välja alla valbara program i principerna för villkorsstyrd åtkomst. Du lämnar åtkomst till de program som inte kan väljas oskyddade. Exempel är åtkomst till Office-portalen, Azure EA-portalen (företagsavtal) och säkerhetsinformationsportalen, som alla är mycket känsliga portaler.
Ett annat att tänka på är att antalet Office 365- och Microsoft Entra-appar ökar med tiden, eftersom Microsoft och partner släpper nya funktioner och när DINA IT-administratörer integrerar olika program med Microsoft Entra-ID. Åtkomst till alla sådana program skyddas endast om du har en mekanism som identifierar alla nya appar som stöder villkorlig åtkomst och som automatiskt tillämpar en princip på den. Det kan vara svårt att skapa och underhålla ett sådant skript.
Dessutom är det maximala antalet appar som stöds för en princip för villkorsstyrd åtkomst cirka 250. Du kanske kan lägga till så många som 600 appar innan du får ett felmeddelande om att nyttolasten överskrids, men det antalet stöds inte.
Personer med villkorsstyrd åtkomst
Det finns många sätt att strukturera principer för villkorsstyrd åtkomst. En metod är att strukturera principer baserat på känsligheten för den resurs som används. I praktiken kan den här metoden vara svår att implementera på ett sätt som fortfarande skyddar åtkomsten till resurser för olika användare.
Du kan till exempel definiera en princip för villkorsstyrd åtkomst som kräver en känd användare och en känd enhet för åtkomst till en känslig resurs som måste nås av både gäster och anställda. När gäster försöker komma åt från en hanterad enhet fungerar inte åtkomstbegäran. Du skulle behöva justera principen för villkorsstyrd åtkomst för att uppfylla båda kraven, vilket vanligtvis skulle resultera i en princip som uppfyller det mindre säkra kravet.
En annan metod är att försöka definiera åtkomstprinciper baserat på var en användare befinner sig i organisationen. Den här metoden kan resultera i många principer för villkorlig åtkomst och kan vara ohanterlig.
En bättre metod är att strukturera principer som rör vanliga åtkomstbehov och paketera en uppsättning åtkomstbehov i en persona för en grupp användare som har samma behov. Personas är identitetstyper som delar vanliga företagsattribut, ansvarsområden, upplevelser, mål och åtkomst.
Att förstå hur företagets tillgångar och resurser används av olika personer är en viktig del i utvecklingen av en omfattande Nolltillit strategi.
Några föreslagna personer med villkorsstyrd åtkomst från Microsoft visas här:
Microsoft rekommenderar också att du definierar en separat persona för identiteter som inte ingår i någon annan persona-grupp. Detta kallas global persona. Global är avsedd att tillämpa principer för identiteter som inte finns i en persona-grupp och principer som ska tillämpas för alla personer.
I följande avsnitt beskrivs några rekommenderade personer.
Globala
Global är en persona/platshållare för principer som är allmänna till sin natur. Den används för att definiera principer som gäller för alla personer eller som inte gäller för en specifik persona. Använd den för principer som inte omfattas av andra personer. Du behöver den här personen för att skydda alla relevanta scenarier.
Anta till exempel att du vill använda en princip för att blockera äldre autentisering för alla användare. Du kan göra den till en global princip i stället för att använda en grupp med äldre principer som kan vara olika för olika personer.
Ett annat exempel: du vill blockera ett visst konto eller en användare från specifika program, och användaren eller kontot är inte en del av någon av personas. Om du till exempel skapar en molnidentitet i Microsoft Entra-klientorganisationen är den här identiteten inte en del av någon av de andra personas eftersom den inte har tilldelats några Microsoft Entra-roller. Du kanske fortfarande vill blockera identiteten från åtkomst till Office 365-tjänster.
Du kanske vill blockera all åtkomst från identiteter som inte omfattas av någon persona-grupp. Eller så kanske du bara vill framtvinga multifaktorautentisering.
Admins
I det här sammanhanget är en administratör alla icke-gästidentiteter, molnbaserade eller synkroniserade, som har något Microsoft Entra-ID eller annan Administratörsroll för Microsoft 365 (till exempel i Microsoft Defender för molnet Appar, Exchange, Defender för Endpoint eller Efterlevnadshanteraren). Eftersom gäster som har dessa roller omfattas av en annan persona undantas gäster från denna persona.
Vissa företag har separata konton för de känsliga administratörsroller som den här persona baseras på. Optimalt använder administratörer dessa känsliga konton från en PAW -arbetsstation (Privileged Access Workstation). Men vi ser ofta att administratörskonton används på standardarbetsstationer, där användaren bara växlar mellan konton på en enhet.
Du kanske vill differentiera baserat på känsligheten för molnadministratörsroller och tilldela mindre känsliga Azure-roller till Internals-persona i stället för att använda separata konton. Du kan sedan använda JIT-höjning (Just-In-Time) i stället. I det här fallet riktas en användare mot två uppsättningar principer för villkorsstyrd åtkomst, en för varje persona. Om du använder PAW:er kanske du också vill införa principer som använder enhetsfilter i villkorsstyrd åtkomst för att begränsa åtkomsten så att administratörer endast tillåts på PAW:er.
Utvecklare
Utvecklarnas persona innehåller användare som har unika behov. De baseras på Active Directory-konton som är synkroniserade med Microsoft Entra-ID, men de behöver särskild åtkomst till tjänster som Azure DevOps, CI/CD-pipelines, enhetskodflöde och GitHub. Utvecklarnas persona kan inkludera användare som anses vara interna och andra som betraktas som externa, men en person bör bara vara i en av personas.
Internals
Internals innehåller alla användare som har ett Active Directory-konto synkroniserat med Microsoft Entra-ID, som är anställda på företaget och som arbetar i en standardroll för slutanvändare. Vi rekommenderar att du lägger till interna användare som är utvecklare i utvecklarnas persona.
Externa
Den här personen innehåller alla externa konsulter som har ett Active Directory-konto synkroniserat med Microsoft Entra-ID. Vi rekommenderar att du lägger till externa användare som är utvecklare i utvecklarnas persona.
Gästerna
Gäster har alla användare som har ett Microsoft Entra-gästkonto som har bjudits in till kundklientorganisationen.
GuestAdmins
GuestAdmins-persona innehåller alla användare som har ett Microsoft Entra-gästkonto som har tilldelats någon av de tidigare nämnda administratörsrollerna.
Microsoft365ServiceAccounts
Den här personen innehåller molnbaserade (Microsoft Entra ID) användarbaserade tjänstkonton som används för att komma åt Microsoft 365-tjänster när ingen annan lösning uppfyller behovet, som att använda en hanterad tjänstidentitet.
AzureServiceAccounts
Den här personen innehåller molnbaserade (Microsoft Entra ID) användarbaserade tjänstkonton som används för att komma åt Azure-tjänster (IaaS/PaaS) när ingen annan lösning uppfyller behovet, som att använda en hanterad tjänstidentitet.
CorpServiceAccounts
Den här personan innehåller användarbaserade tjänstkonton som har alla dessa egenskaper:
- Härstammar från lokal Active Directory.
- Används lokalt eller från en IaaS-baserad virtuell dator i ett annat (moln) datacenter, till exempel Azure.
- Synkroniseras till en Microsoft Entra-instans som har åtkomst till valfri Azure- eller Microsoft 365-tjänst.
Det här scenariot bör undvikas.
WorkloadIdentiteter
Den här persona innehåller datoridentiteter, till exempel Microsoft Entra-tjänstens huvudnamn och hanterade identiteter. Villkorlig åtkomst stöder nu skydd av åtkomst till resurser från dessa konton, med vissa begränsningar när det gäller vilka villkor och beviljandekontroller som är tillgängliga.
Komma åt mallkort
Vi rekommenderar att du använder åtkomstmallkort för att definiera egenskaperna för varje persona. Här är ett exempel:
Mallkortet för varje persona innehåller indata för att skapa specifika principer för villkorsstyrd åtkomst för varje persona.
Vägledning för villkorsstyrd åtkomst
Granska ett ramverk för villkorsstyrd åtkomst som innehåller en strukturerad metod för grupperingsprinciper baserat på de personas som skapats.
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
- Utbildningsväg: Implementera och hantera identitet och åtkomst
- Vad är villkorsstyrd åtkomst?
- Vanliga principer för villkorsstyrd åtkomst