Resource-isolatie met meerdere tenants

Artikel
10/24/2023

Er zijn specifieke scenario's wanneer het delegeren van beheer in één tenantgrens niet aan uw behoeften voldoet. In deze sectie zijn er vereisten waarmee u een architectuur met meerdere tenants kunt maken. Organisaties met meerdere tenants kunnen twee of meer Microsoft Entra-tenants omvatten. Dit kan unieke eisen stellen aan de samenwerking tussen tenants en het beheer ervan. Architecturen met meerdere tenants verhogen de overhead en complexiteit van het beheer en dienen voorzichtig te worden gebruikt. We raden u aan om één tenant te gebruiken als aan uw behoeften kan worden voldaan met die architectuur. Zie Gebruikersbeheer voor meerdere tenants voor meer gedetailleerde informatie.

Een afzonderlijke tenant maakt een nieuwe grens en ontkoppelt daarom het beheer van Microsoft Entra-directoryrollen, mapobjecten, beleid voor voorwaardelijke toegang, Azure-resourcegroepen, Azure-beheergroepen en andere besturingselementen, zoals beschreven in de vorige secties.

Een afzonderlijke tenant is handig voor de IT-afdeling van een organisatie om tenantbrede wijzigingen in Microsoft-services te valideren, zoals Intune, Microsoft Entra Verbinding maken of een configuratie voor hybride verificatie tijdens het beveiligen van gebruikers en resources van een organisatie. Dit omvat het testen van serviceconfiguraties die tenantbrede effecten kunnen hebben en die niet kunnen worden beperkt tot een subset van gebruikers in de productietenant.

Het implementeren van een niet-productieomgeving in een afzonderlijke tenant kan nodig zijn tijdens het ontwikkelen van aangepaste toepassingen die gegevens van productiegebruikersobjecten kunnen wijzigen met MS Graph of vergelijkbare API's (bijvoorbeeld toepassingen die directory.ReadWrite.All of een vergelijkbaar breed bereik hebben).

Notitie

Microsoft Entra Verbinding maken synchronisatie met meerdere tenants, wat handig kan zijn bij het implementeren van een niet-productieomgeving in een afzonderlijke tenant. Zie Microsoft Entra Verbinding maken: Ondersteunde topologieën voor meer informatie.

Resultaten

Naast de resultaten die zijn bereikt met één tenantarchitectuur zoals eerder beschreven, kunnen organisaties de interacties tussen resources en tenants volledig loskoppelen:

Resourcescheiding

Zichtbaarheid: resources in een afzonderlijke tenant kunnen niet worden gedetecteerd of geïnventariseerd door gebruikers en beheerders in andere tenants. Op dezelfde manier bevinden gebruiksrapporten en auditlogboeken zich binnen de nieuwe tenantgrens. Door deze scheiding van zichtbaarheid kunnen organisaties resources beheren die nodig zijn voor vertrouwelijke projecten.
Objectvoetafdruk : toepassingen die schrijven naar Microsoft Entra-id en/of andere Microsoft Online-services via Microsoft Graph of andere beheerinterfaces kunnen in een afzonderlijke objectruimte werken. Hierdoor kunnen ontwikkelteams tests uitvoeren gedurende de levenscyclus van softwareontwikkeling zonder dat dit van invloed is op andere tenants.
Quota: het verbruik van tenantbrede Azure-quota en -limieten wordt gescheiden van die van de andere tenants.

Configuratiescheiding

Een nieuwe tenant biedt een afzonderlijke set tenantbrede instellingen die geschikt zijn voor resources en toepassingen met vereisten waarvoor verschillende configuraties op tenantniveau nodig zijn. Daarnaast biedt een nieuwe tenant een nieuwe set Microsoft Online-services, zoals Office 365.

Administratieve scheiding

Een nieuwe tenantgrens omvat een afzonderlijke set Microsoft Entra-adreslijstrollen, waarmee u verschillende sets beheerders kunt configureren.

Veelvoorkomend gebruik

Het volgende diagram illustreert een veelvoorkomend gebruik van resource-isolatie in meerdere tenants: een preproductie- of sandboxomgeving waarvoor meer scheiding is vereist dan kan worden bereikt met gedelegeerd beheer in één tenant.

Diagram van een veelvoorkomend gebruiksscenario.

Contoso is een organisatie die de tenantarchitectuur van het bedrijf heeft uitgebreid met een preproductietenant genaamd ContosoSandbox.com. De sandbox-tenant wordt gebruikt ter ondersteuning van doorlopende ontwikkeling van bedrijfsoplossingen die schrijven naar Microsoft Entra ID en Microsoft 365 met behulp van Microsoft Graph. Deze oplossingen worden geïmplementeerd in de bedrijfstenant.

De sandboxtenant wordt online gebracht om te voorkomen dat de toepassingen die worden ontwikkeld direct of indirect invloed hebben op productiesystemen door tenantresources te gebruiken en quota te beïnvloeden of beperkingen.

Ontwikkelaars hebben tijdens de ontwikkelingslevenscyclus toegang nodig tot de sandboxtenant, idealiter met selfservicetoegang waarvoor aanvullende machtigingen zijn vereist die zijn beperkt in de productieomgeving. Voorbeelden van deze aanvullende machtigingen zijn het maken, verwijderen en bijwerken van gebruikersaccounts, het registreren van toepassingen, het inrichten van Azure-resources en het ongedaan maken van de inrichting daarvan en wijzigingen in beleid of de algemene configuratie van de omgeving.

In dit voorbeeld maakt Contoso gebruik van Microsoft Entra B2B Collaboration om gebruikers van de bedrijfstenant in te richten, zodat gebruikers die resources kunnen beheren en openen in toepassingen in de sandbox-tenant zonder meerdere referenties te beheren. Deze mogelijkheid is voornamelijk gericht op scenario's met samenwerking tussen organisaties. Ondernemingen met meerdere tenants zoals Contoso kunnen deze mogelijkheid echter gebruiken om extra beheer van de levenscyclus van aanmeldingsgegevens en complexiteit van de gebruikerservaring te voorkomen.

Gebruik instellingen voor toegang tussen tenants voor externe identiteiten om te beheren hoe u samenwerkt met andere Microsoft Entra-organisaties via B2B-samenwerking. Deze instellingen bepalen het niveau van binnenkomende toegangsgebruikers in externe Microsoft Entra-organisaties voor uw resources en het niveau van uitgaande toegang die uw gebruikers hebben voor externe organisaties. U kunt ook meervoudige verificatie (MFA) en apparaatclaims (compatibele claims en aan Microsoft Entra gekoppelde claims) vertrouwen van andere Microsoft Entra-organisaties. Zie Toegang tussen tenants in Microsoft Entra Externe ID voor meer informatie en planningsoverwegingen.

Een andere benadering zou kunnen zijn om gebruik te maken van de mogelijkheden van Microsoft Entra Verbinding maken om dezelfde on-premises Microsoft Entra-referenties te synchroniseren met meerdere tenants, waarbij hetzelfde wachtwoord behouden blijft, maar het UPN-domein van de gebruikers verschilt.

Isolatie van resources in meerdere tenants

Met een nieuwe tenant hebt u een afzonderlijke set beheerders. Organisaties kunnen ervoor kiezen om zakelijke identiteiten te gebruiken via Microsoft Entra B2B-samenwerking. Op dezelfde manier kunnen organisaties Azure Lighthouse implementeren voor crosstenantbeheer van Azure-resources, zodat niet-productie Azure-abonnementen worden beheerd door identiteiten in de productie-tegenhanger. Azure Lighthouse kan niet worden gebruikt voor het beheren van services buiten Azure, zoals Microsoft Intune. Voor Managed Service Providers (MSP's) is Microsoft 365 Lighthouse een beheerportal waarmee apparaten, gegevens en gebruikers op schaal kunnen worden beveiligd en beheerd voor middelgrote en kleine bedrijven (MKB) die gebruikmaken van Microsoft 365 Business Premium, Microsoft 365 E3 of Windows 365 Business.

Hierdoor kunnen gebruikers hun bedrijfsreferenties blijven gebruiken en tegelijkertijd de voordelen van scheiding bereiken.

Microsoft Entra B2B-samenwerking in sandbox-tenants moet zo worden geconfigureerd dat alleen identiteiten uit de bedrijfsomgeving kunnen worden toegevoegd met behulp van lijsten voor toestaan/weigeren van Azure B2B. Voor tenants die u wilt toestaan voor B2B, kunt u overwegen om instellingen voor External Identities voor toegang tot meerdere tenants te gebruiken voor meervoudige verificatie/apparaatvertrouwen voor meerdere tenants.

Belangrijk

Architecturen met meerdere tenants waarvoor toegang door externe identiteiten is ingeschakeld, bieden alleen isolatie van resources, maar zorgen niet voor identiteitsisolatie. Resource-isolatie met behulp van Microsoft Entra B2B-samenwerking en Azure Lighthouse beperken geen risico's met betrekking tot identiteiten.

Als de sandboxomgeving identiteiten deelt met de bedrijfsomgeving, zijn de volgende scenario's van toepassing op de sandboxtenant:

Een kwaadwillende actor die inbreuk maakt op een gebruiker, een apparaat of een hybride infrastructuur in de bedrijfstenant en wordt uitgenodigd in de sandboxtenant, kan toegang krijgen tot de toepassingen en resources van de sandboxtenant.
Een operationele fout (bijvoorbeeld het verwijderen of intrekken van referenties) in de bedrijfstenant kan van invloed zijn op de toegang van een uitgenodigde gebruiker in de sandbox-tenant.

U moet de risicoanalyse uitvoeren en mogelijk identiteitsisolatie overwegen via meerdere tenants voor bedrijfskritieke resources waarvoor een zeer defensieve benadering is vereist. Azure Privileged Identity Management kan helpen een aantal risico's te beperken door extra beveiliging in te stellen voor toegang tot bedrijfskritieke tenants en resources.

Directory-objecten

De tenant die u gebruikt om resources te isoleren, bevat mogelijk dezelfde typen objecten, Azure-resources en vertrouwende toepassingen als uw primaire tenant. Mogelijk moet u de volgende objecttypen inrichten:

Gebruikers en groepen: Identiteiten die nodig zijn voor teams die oplossingen ontwikkelen, zoals:

Sandboxomgevingsbeheerders.
Technische eigenaren van toepassingen.
Ontwikkelaars van line-of-business-toepassingen.
Eindgebruikersaccounts voor testdoeleinden.

Deze identiteiten kunnen worden ingericht voor:

Werknemers die hun bedrijfsaccount gebruiken via Microsoft Entra B2B-samenwerking.
Werknemers die lokale accounts nodig hebben voor beheer, noodbeheer of andere technische redenen.

Klanten die niet-productie Active Directory on-premises hebben of vereisen, kunnen hun on-premises identiteiten ook synchroniseren met de sandboxtenant, indien nodig door de onderliggende resources en toepassingen.

Apparaten: de niet-productietenant bevat een beperkt aantal apparaten in de mate die nodig is in de ontwikkelingscyclus van de oplossing:

Beheerwerkstations
Niet-productiecomputers en mobiele apparaten die nodig zijn voor ontwikkeling, testen en documentatie

Toepassingen

Geïntegreerde Microsoft Entra-toepassingen: Toepassingsobjecten en service-principals voor:

Testexemplaren van de toepassingen die in productie zijn geïmplementeerd (bijvoorbeeld toepassingen die schrijven naar Microsoft Entra ID en Microsoft onlineservices).
Infrastructuurservices voor het beheren en onderhouden van de niet-productietenant, mogelijk een subset van de oplossingen die beschikbaar zijn in de bedrijfstenant.

Microsoft Online-services:

Normaliter moet het team dat eigenaar is van de Microsoft Online-services in productie de eigenaar zijn van het niet-productie-exemplaar van die services.
Beheerders van niet-productietestomgevingen mogen Microsoft Online Services niet inrichten, tenzij deze services specifiek worden getest. Dit voorkomt ongepast gebruik van Microsoft-services, bijvoorbeeld het instellen van SharePoint-productiesites in een testomgeving.
Op dezelfde manier moet het inrichten van Microsoft Online-services die kunnen worden gestart door eindgebruikers (ook wel ad-hocabonnementen genoemd) worden vergrendeld. Zie Wat is selfserviceregistratie voor Microsoft Entra ID?voor meer informatie.
Over het algemeen moeten alle niet-essentiële licentiefuncties worden uitgeschakeld voor de tenant met behulp van groepslicenties. Dit moet worden gedaan door hetzelfde team dat licenties beheert in de productietenant, om onjuiste configuratie te voorkomen door ontwikkelaars die mogelijk niet weten wat het effect is van het inschakelen van gelicentieerde functies.

Azure-resources

Alle Azure-resources die nodig zijn voor vertrouwende toepassingen kunnen ook worden geïmplementeerd. Bijvoorbeeld databases, virtuele machines, containers, Azure-functies, enzovoort. Voor uw sandbox-omgeving moet u de kostenbesparingen afwegen van het gebruik van goedkopere SKU's voor producten en services met de beschikbare beveiligingsfuncties.

Het RBAC-model voor toegangsbeheer moet nog steeds worden gebruikt in een niet-productieomgeving voor het geval wijzigingen worden gerepliceerd naar productie nadat de tests zijn afgerond. Als u dit niet doet, kunnen beveiligingsfouten in de niet-productieomgeving worden doorgegeven aan uw productietenant.

Isolatie van resources en identiteiten met meerdere tenants

Isolatieresultaten

Er zijn beperkte situaties waarin resource-isolatie niet aan uw vereisten kan voldoen. U kunt zowel resources als identiteiten isoleren in een architectuur met meerdere tenants door alle mogelijkheden voor samenwerking tussen tenants uit te schakelen en effectief een afzonderlijke identiteitsgrens op te bouwen. Deze aanpak is een verdediging tegen operationele fouten en inbreuk op gebruikersidentiteiten, apparaten of hybride infrastructuur in bedrijfstenants.

Veelvoorkomend gebruik van isolatie

Een afzonderlijke identiteitsgrens wordt doorgaans gebruikt voor bedrijfskritieke toepassingen en resources, zoals klantgerichte services. In dit scenario heeft Fabrikam besloten om een afzonderlijke tenant te maken voor hun klantgerichte SaaS-product om het risico te voorkomen dat schendingen van werknemersidentiteiten hun SaaS-klanten treffen. Het volgende diagram illustreert deze architectuur:

De FrabrikamSaaS-tenant bevat de omgevingen die worden gebruikt voor toepassingen die worden aangeboden aan klanten als onderdeel van Fabrikams bedrijfsmodel.

Isolatie van directory-objecten

De directory-objecten in FabrikamSaas zijn als volgt:

Gebruikers en groepen: identiteiten die nodig zijn voor IT-oplossingsteams, klantenservicemedewerkers of ander benodigd personeel worden gemaakt in de SaaS-tenant. Om isolatie te behouden, worden alleen lokale accounts gebruikt en is Microsoft Entra B2B-samenwerking niet ingeschakeld.

Azure AD B2C-directory-objecten: als de tenantomgevingen toegankelijk zijn voor klanten, kan deze een Azure AD B2C-tenant en de bijbehorende identiteitsobjecten bevatten. Abonnementen die deze directory's bevatten, zijn goede kandidaten voor een geïsoleerde klantgerichte omgeving.

Apparaten: deze tenant bevat een verminderd aantal apparaten; alleen de oplossingen die nodig zijn om klantgerichte oplossingen uit te voeren:

Veilige beheerwerkstations.
Werkstations voor ondersteuningspersoneel (dit kunnen technici zijn die kunnen worden opgeroepen, zoals hierboven beschreven).

Isolatie van toepassingen

Geïntegreerde Microsoft Entra-toepassingen: Toepassingsobjecten en service-principals voor:

Productietoepassingen (bijvoorbeeld toepassingsdefinities met meerdere tenants).
Infrastructuurservices voor het beheren en onderhouden van de klantgerichte omgeving.

Azure-resources: host de IaaS-, PaaS- en SaaS-resources van de klantgerichte productie-exemplaren.

Delen via