Resursisolering med flera klienter

Det finns specifika scenarier när delegering av administration i en enda klientgräns inte uppfyller dina behov. I det här avsnittet finns det krav som kan driva dig att skapa en arkitektur för flera klientorganisationer. Organisationer med flera klientorganisationer kan sträcka sig över två eller flera Microsoft Entra-klienter. Detta kan resultera i unika samarbets- och hanteringskrav för flera klientorganisationer. Arkitekturer med flera klientorganisationer ökar hanteringskostnaderna och komplexiteten och bör användas med försiktighet. Vi rekommenderar att du använder en enda klientorganisation om dina behov kan uppfyllas med den arkitekturen. Mer detaljerad information finns i Användarhantering för flera klientorganisationer.

En separat klient skapar en ny gräns och därför frikopplad hantering av Microsoft Entra-katalogroller, katalogobjekt, principer för villkorsstyrd åtkomst, Azure-resursgrupper, Azure-hanteringsgrupper och andra kontroller enligt beskrivningen i föregående avsnitt.

En separat klientorganisation är användbar för en organisations IT-avdelning för att verifiera ändringar i hela klientorganisationen i Microsoft-tjänster till exempel Intune, Microsoft Entra Connect eller en hybridautentiseringskonfiguration samtidigt som organisationens användare och resurser skyddas. Detta omfattar testning av tjänstkonfigurationer som kan ha effekter för hela klientorganisationen och som inte kan begränsas till en delmängd av användare i produktionsklientorganisationen.

Det kan vara nödvändigt att distribuera en icke-produktionsmiljö i en separat klientorganisation under utvecklingen av anpassade program som kan ändra data för produktionsanvändarobjekt med MS Graph eller liknande API:er (till exempel program som beviljas Directory.ReadWrite.All eller liknande omfattande omfång).

Resultat

Förutom de resultat som uppnåtts med en enda klientarkitektur enligt beskrivningen tidigare kan organisationer helt frikoppla resurs- och klientinteraktionerna:

Resursavgränsning

• Synlighet – Resurser i en separat klientorganisation kan inte identifieras eller räknas upp av användare och administratörer i andra klientorganisationer. På samma sätt finns användningsrapporter och granskningsloggar inom den nya klientgränsen. Den här uppdelningen av synligheten gör det möjligt för organisationer att hantera resurser som behövs för konfidentiella projekt.

• Objektfotavtryck – Program som skriver till Microsoft Entra-ID och/eller andra Microsoft Online-tjänster via Microsoft Graph eller andra hanteringsgränssnitt kan fungera i ett separat objektutrymme. Detta gör det möjligt för utvecklingsteam att utföra tester under livscykeln för programvaruutveckling utan att påverka andra klienter.

• Kvoter – Förbrukningen av Azure-kvoter och -gränser i hela klientorganisationen är separerad från de andra klientorganisationens.

Konfigurationsavgränsning

En ny klientorganisation tillhandahåller en separat uppsättning inställningar för hela klientorganisationen som kan hantera resurser och betrodda program som har krav som behöver olika konfigurationer på klientnivå. Dessutom tillhandahåller en ny klientorganisation en ny uppsättning Microsoft Online-tjänster, till exempel Office 365.

Administrativ separation

En ny klientgräns omfattar en separat uppsättning Microsoft Entra-katalogroller, som gör att du kan konfigurera olika uppsättningar administratörer.

Vanlig användning

Följande diagram illustrerar en vanlig användning för resursisolering i flera klientorganisationer: en förproduktions- eller sandbox-miljö som kräver mer separation än vad som kan uppnås med delegerad administration i en enda klientorganisation.

Contoso är en organisation som har utökat företagets klientarkitektur med en klientorganisation för förproduktion som heter ContosoSandbox.com. Sandbox-klientorganisationen används för att stödja pågående utveckling av företagslösningar som skriver till Microsoft Entra ID och Microsoft 365 med hjälp av Microsoft Graph. Dessa lösningar distribueras i företagsklientorganisationen.

Sandbox-klientorganisationen är online för att förhindra att de program som är under utveckling påverkar produktionssystemen direkt eller indirekt, genom att förbruka klientresurser och påverka kvoter eller begränsning.

Utvecklare kräver åtkomst till sandbox-klientorganisationen under utvecklingslivscykeln, helst med självbetjäningsåtkomst som kräver ytterligare behörigheter som är begränsade i produktionsmiljön. Exempel på dessa ytterligare behörigheter kan vara att skapa, ta bort och uppdatera användarkonton, registrera program, etablera och avetablera Azure-resurser samt ändringar i principer eller övergripande konfiguration av miljön.

I det här exemplet använder Contoso Microsoft Entra B2B Collaboration för att etablera användare från företagsklientorganisationen för att göra det möjligt för användare som kan hantera och komma åt resurser i program i sandbox-klientorganisationen utan att hantera flera autentiseringsuppgifter. Den här funktionen är främst inriktad på scenarier för samarbete mellan organisationer. Företag med flera klienter som Contoso kan dock använda den här funktionen för att undvika ytterligare livscykeladministration för autentiseringsuppgifter och komplexitet i användarupplevelsen.

Använd inställningar för åtkomst mellan klientorganisationer för externa identiteter för att hantera hur du samarbetar med andra Microsoft Entra-organisationer via B2B-samarbete. De här inställningarna avgör både vilken nivå av inkommande åtkomst användare i externa Microsoft Entra-organisationer har till dina resurser och nivån på utgående åtkomst som användarna har till externa organisationer. De låter dig också lita på multifaktorautentisering (MFA) och enhetsanspråk (kompatibla anspråk och Microsoft Entra hybridanslutna anspråk) från andra Microsoft Entra-organisationer. Mer information och planeringsöverväganden finns i Åtkomst mellan klientorganisationer i Externt ID för Microsoft Entra.

En annan metod kunde ha varit att använda funktionerna i Microsoft Entra Connect för att synkronisera samma lokala Microsoft Entra-autentiseringsuppgifter till flera klienter, behålla samma lösenord men skilja på användarnas UPN-domän.

Resursisolering för flera klientorganisationer

Med en ny klientorganisation har du en separat uppsättning administratörer. Organisationer kan välja att använda företagsidentiteter via Microsoft Entra B2B-samarbete. På samma sätt kan organisationer implementera Azure Lighthouse för hantering mellan klientorganisationer av Azure-resurser så att icke-produktionsbaserade Azure-prenumerationer hanteras av identiteter i produktionsmotsvarigheten. Azure Lighthouse kan inte användas för att hantera tjänster utanför Azure, till exempel Microsoft Intune. För leverantörer av hanterade tjänster är Microsoft 365 Lighthouse en administratörsportal som hjälper till att skydda och hantera enheter, data och användare i stor skala för små och medelstora företagskunder (SMB) som använder Microsoft 365 Business Premium, Microsoft 365 E3 eller Windows 365 Business.

Detta gör att användarna kan fortsätta att använda sina företagsautentiseringsuppgifter samtidigt som fördelarna med separation uppnås.

Microsoft Entra B2B-samarbete i sandbox-klientorganisationer bör konfigureras för att endast tillåta att identiteter från företagsmiljön registreras med hjälp av Tillåt/neka-listor i Azure B2B. För klienter som du vill tillåta för B2B bör du överväga att använda inställningar för åtkomst mellan klientorganisationer för multifaktorautentisering för flera klientorganisationer\Enhetsförtroende.

Om sandbox-miljön delar identiteter med företagsmiljön gäller följande scenarier för sandbox-klientorganisationen:

• En illasinnad aktör som komprometterar en användare, en enhet eller hybridinfrastruktur i företagsklientorganisationen och bjuds in till sandbox-klientorganisationen kan få åtkomst till sandbox-klientorganisationens appar och resurser.

• Ett driftfel (till exempel borttagning av användarkonton eller återkallande av autentiseringsuppgifter) i företagsklientorganisationen kan påverka åtkomsten för en inbjuden användare till sandbox-klientorganisationen.

Du måste göra riskanalysen och potentiellt överväga identitetsisolering via flera klienter för affärskritiska resurser som kräver en mycket defensiv metod. Azure Privileged Identity Management kan bidra till att minska vissa av riskerna genom att införa extra säkerhet för åtkomst till affärskritiska klienter och resurser.

Katalogobjekt

Den klientorganisation som du använder för att isolera resurser kan innehålla samma typer av objekt, Azure-resurser och betrodda program som din primära klientorganisation. Du kan behöva etablera följande objekttyper:

Användare och grupper: Identiteter som behövs av lösningstekniker, till exempel:

• Sandbox-miljöadministratörer.

• Tekniska ägare av program.

• Verksamhetsspecifika programutvecklare.

• Testa slutanvändarkonton.

Dessa identiteter kan etableras för:

• Anställda som kommer med sitt företagskonto via Microsoft Entra B2B-samarbete.

• Anställda som behöver lokala konton för administration, akut administrativ åtkomst eller andra tekniska skäl.

Kunder som har eller kräver icke-produktionsbaserad Active Directory lokalt kan också synkronisera sina lokala identiteter med sandbox-klientorganisationen om det behövs av de underliggande resurserna och programmen.

Enheter: Icke-produktionsklientorganisationen innehåller ett minskat antal enheter i den utsträckning som behövs i lösningsutvecklingscykeln:

• Administrationsarbetsstationer

• Icke-produktionsdatorer och mobila enheter som behövs för utveckling, testning och dokumentation

Appar

Microsoft Entra-integrerade program: Programobjekt och tjänstens huvudnamn för:

• Testa instanser av de program som distribueras i produktion (till exempel program som skriver till Microsoft Entra ID och Microsoft onlinetjänster).

• Infrastrukturtjänster för att hantera och underhålla icke-produktionsklientorganisationen, potentiellt en delmängd av de lösningar som är tillgängliga i företagsklientorganisationen.

Microsoft Online Services:

• Vanligtvis bör det team som äger Microsoft Online Services i produktion vara det som äger den icke-produktionsinstansen av dessa tjänster.

• Administratörer av icke-produktionstestmiljöer bör inte etablera Microsoft Online Services om inte tjänsterna testas specifikt. Detta förhindrar olämplig användning av Microsoft-tjänster, till exempel att konfigurera SharePoint-produktionsplatser i en testmiljö.

• På samma sätt bör etablering av Microsoft Online-tjänster som kan initieras av slutanvändare (även kallade ad hoc-prenumerationer) låsas. Mer information finns i Vad är självbetjäningsregistrering för Microsoft Entra-ID?.

• I allmänhet bör alla icke-nödvändiga licensfunktioner inaktiveras för klientorganisationen med hjälp av gruppbaserad licensiering. Detta bör göras av samma team som hanterar licenser i produktionsklientorganisationen för att undvika felkonfiguration av utvecklare som kanske inte vet effekten av att aktivera licensierade funktioner.

Azure-resurser

Alla Azure-resurser som behövs för att lita på program kan också distribueras. Till exempel databaser, virtuella datorer, containrar, Azure-funktioner och så vidare. För sandbox-miljön måste du väga kostnadsbesparingarna med att använda billigare SKU:er för produkter och tjänster med de mindre tillgängliga säkerhetsfunktionerna.

RBAC-modellen för åtkomstkontroll bör fortfarande användas i en icke-produktionsmiljö om ändringar replikeras till produktion efter att testerna har avslutats. Om du inte gör det kan säkerhetsbrister i icke-produktionsmiljön spridas till produktionsklientorganisationen.

Resurs- och identitetsisolering med flera klienter

Isoleringsresultat

Det finns begränsade situationer där resursisolering inte kan uppfylla dina krav. Du kan isolera både resurser och identiteter i en arkitektur för flera klientorganisationer genom att inaktivera alla samarbetsfunktioner mellan klientorganisationer och effektivt skapa en separat identitetsgräns. Den här metoden är ett skydd mot driftfel och komprometterande av användaridentiteter, enheter eller hybridinfrastruktur i företagsklientorganisationer.

Gemensam isoleringsanvändning

En separat identitetsgräns används vanligtvis för affärskritiska program och resurser som kundinriktade tjänster. I det här scenariot har Fabrikam beslutat att skapa en separat klientorganisation för sin kundriktade SaaS-produkt för att undvika risken för att medarbetarens identitetsintrång påverkar deras SaaS-kunder. Följande diagram illustrerar den här arkitekturen:

FabrikamSaaS-klientorganisationen innehåller de miljöer som används för program som erbjuds till kunder som en del av Fabrikams affärsmodell.

Isolering av katalogobjekt

Katalogobjekten i FabrikamSaas är följande:

Användare och grupper: Identiteter som behövs av lösnings-IT-team, kundsupportpersonal eller annan nödvändig personal skapas i SaaS-klientorganisationen. För att bevara isolering används endast lokala konton och Microsoft Entra B2B-samarbete är inte aktiverat.

Azure AD B2C-katalogobjekt: Om klientmiljöerna nås av kunder kan den innehålla en Azure AD B2C-klientorganisation och dess associerade identitetsobjekt. Prenumerationer som innehåller dessa kataloger är bra kandidater för en isolerad konsumentinriktad miljö.

Enheter: Den här klientorganisationen innehåller ett minskat antal enheter. endast de som behövs för att köra kundinriktade lösningar:

• Säkra administrationsarbetsstationer.

• Supportpersonal arbetsstationer (detta kan inkludera ingenjörer som är "jour" enligt beskrivningen ovan).

Isolering av program

Microsoft Entra-integrerade program: Programobjekt och tjänstens huvudnamn för:

• Produktionsprogram (till exempel programdefinitioner för flera klientorganisationer).

• Infrastrukturtjänster för att hantera och underhålla den kundinriktade miljön.

Azure-resurser: Är värd för IaaS-, PaaS- och SaaS-resurserna för de kundriktade produktionsinstanserna.

Nästa steg

• Introduktion till delegerad administration och isolerade miljöer

• Grunderna i Microsoft Entra

• Grunderna för Azure-resurshantering

• Resursisolering i en enda klientorganisation

• Bästa praxis