Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Een veelvoorkomend scenario voor Azure Lighthouse omvat een serviceprovider die resources beheert in de Microsoft Entra-tenants van de klant. De mogelijkheden van Azure Lighthouse kunnen ook worden gebruikt om het beheer van meerdere tenants binnen een onderneming die gebruikmaakt van meerdere Microsoft Entra-tenants te vereenvoudigen. In dit scenario kunnen gebruikers in een van de tenants van het bedrijf beheertaken uitvoeren op de andere tenants via Azure Lighthouse, zonder dat andere serviceproviders hierbij betrokken hoeven te zijn.
Eén versus meerdere tenants
Voor de meeste organisaties is het beheer eenvoudiger met één Microsoft Entra-tenant. Door alle resources binnen één tenant te hebben, kunnen beheertaken worden gecentraliseerd door aangewezen gebruikers, gebruikersgroepen of service-principals binnen die tenant. We raden u aan waar mogelijk één tenant voor uw organisatie te gebruiken.
Sommige organisaties moeten mogelijk meerdere Microsoft Entra-tenants gebruiken. Dit kan een tijdelijke situatie zijn, omdat wanneer overnames zijn uitgevoerd en er nog geen strategie voor tenantconsolidatie op lange termijn is gedefinieerd. Andere keren moeten organisaties mogelijk meerdere tenants doorlopend onderhouden vanwege volledig onafhankelijke dochterondernemingen, geografische of juridische vereisten of andere overwegingen.
In gevallen waarin een multitenant-architectuur vereist is, kan Azure Lighthouse helpen bij het centraliseren en stroomlijnen van beheerbewerkingen. Met behulp van Azure Lighthouse kunnen gebruikers in één beheertenant functies voor beheer tussen tenants uitvoeren op een gecentraliseerde, schaalbare manier.
Architectuur voor tenantbeheer
Als u Azure Lighthouse in een onderneming wilt gebruiken, moet u bepalen welke tenant de gebruikers bevat die beheerbewerkingen uitvoeren op de andere tenants. Met andere woorden, u wijst één tenant aan als de beherende tenant voor de andere tenants.
Stel dat uw organisatie één tenant heeft die tenant A wordt aangeroepen. Uw organisatie verwerft vervolgens Tenant B en Tenant C en u hebt zakelijke redenen waarvoor u ze als afzonderlijke tenants moet onderhouden. U wilt echter dezelfde beleidsdefinities, back-upprocedures en beveiligingsprocessen voor al deze definities gebruiken, waarbij beheertaken worden uitgevoerd door dezelfde set gebruikers.
Aangezien Tenant A al gebruikers in uw organisatie bevat die deze taken voor Tenant A hebben uitgevoerd, kunt u Tenant A aanwijzen als de beheertenant. Vervolgens kunt u abonnementen onboarden in Tenant B en Tenant C, zodat ze worden gedelegeerd aan Tenant A. Tijdens het onboardingproces maakt u autorisaties die machtigingen verlenen aan gebruikers in tenant A, zodat ze beheertaken kunnen uitvoeren in Tenant B en Tenant C.
Overwegingen voor beveiliging en toegang
In de meeste bedrijfsscenario's wilt u een volledig abonnement delegeren aan Azure Lighthouse. U kunt er ook voor kiezen om alleen specifieke resourcegroepen binnen een abonnement te delegeren.
Zorg er in beide gevallen voor dat u het principe van minimale bevoegdheden volgt wanneer u definieert welke gebruikers toegang hebben tot gedelegeerde resources. Dit helpt ervoor te zorgen dat gebruikers alleen beschikken over de machtigingen die nodig zijn om de vereiste taken uit te voeren en vermindert de kans op onbedoelde fouten.
Azure Lighthouse biedt alleen logische koppelingen tussen een beheerde tenant en beheerde tenants, in plaats van fysiek gegevens of resources te verplaatsen. Bovendien gaat de toegang altijd in slechts één richting, van de beherende tenant tot de beheerde tenants. Gebruikers en groepen in de beherende tenant moeten meervoudige verificatie gebruiken bij het uitvoeren van beheerbewerkingen op beheerde tenantresources.
Ondernemingen met interne of externe governance- en nalevingsrails kunnen Azure-activiteitenlogboeken gebruiken om te voldoen aan hun transparantievereisten. Wanneer ondernemingen relaties tussen beherende en beheerde tenants tot stand brengen, kunnen gebruikers in elke tenant geregistreerde activiteit bekijken om acties te zien die gebruikers in de beherende tenants hebben ondernomen.
Zie Aanbevolen beveiligingsprocedures voor meer informatie.
Overwegingen voor onboarding
Abonnementen (of resourcegroepen binnen een abonnement) kunnen worden geïmplementeerd in Azure Lighthouse door Azure Resource Manager-sjablonen te implementeren of via Managed Services-aanbiedingen die zijn gepubliceerd naar Microsoft Marketplace.
Omdat zakelijke gebruikers doorgaans directe toegang hebben tot de tenants van de onderneming en er geen behoefte is om een beheeraanbieding op de markt te zetten of te promoten, is het meestal sneller en eenvoudiger om Azure Resource Manager-sjablonen te implementeren. Hoewel de richtlijnen voor onboarding verwijzen naar serviceproviders en klanten, kunnen ondernemingen dezelfde processen gebruiken om hun tenants te onboarden.
Als u wilt, kunnen tenants binnen een onderneming worden ge onboardd door een aanbieding voor beheerde services te publiceren naar Microsoft Marketplace. Om ervoor te zorgen dat de aanbieding alleen beschikbaar is voor de juiste tenants, moet u ervoor zorgen dat uw plannen zijn ingesteld op privé. Met een privéabonnement geeft u de abonnements-id's op voor elke tenant die u wilt onboarden, en niemand anders kan uw aanbieding krijgen.
Externe ID van Microsoft Entra
Microsoft Entra External ID biedt bedrijf-naar-klant identiteit als dienst. Wanneer u een resourcegroep delegeert via Azure Lighthouse, kunt u Azure Monitor gebruiken om aanmeldings- en controlelogboeken van Microsoft Entra external ID te routeren naar verschillende bewakingsoplossingen. U kunt de logboeken bewaren voor langdurig gebruik of integreren met SIEM-hulpprogramma's (Security Information and Event Management) van derden om inzicht te krijgen in uw omgeving.
Zie Azure Monitor instellen in externe tenants voor meer informatie.
Terminologienotities
Voor beheer tussen tenants binnen de onderneming kunnen verwijzingen naar serviceproviders in de Documentatie van Azure Lighthouse worden begrepen om van toepassing te zijn op de beherende tenant binnen een onderneming, dat wil gezegd: de tenant die de gebruikers bevat die resources in andere tenants beheren via Azure Lighthouse. Op dezelfde manier kunnen alle verwijzingen naar klanten worden begrepen om toe te passen op de tenants die resources delegeren die moeten worden beheerd via gebruikers in de beherende tenant.
In het bovenstaande voorbeeld kan tenant A bijvoorbeeld worden beschouwd als de tenant van de serviceprovider (de beherende tenant) en Tenant B en Tenant C als de tenants van de klant.
Als u verdergaat met dit voorbeeld, kunnen tenant A-gebruikers met de juiste machtigingen gedelegeerde resources bekijken en beheren op de pagina Mijn klanten van Azure Portal. Op dezelfde manier kunnen tenant B- en tenant C-gebruikers met de juiste machtigingen details over hun delegaties bekijken en beheren op de pagina Serviceproviders van Azure Portal.
Volgende stappen
- Verken opties voor resourceorganisatie in multitenant-architecturen.
- Meer informatie over beheerervaring in meerdere tenants.
- Meer informatie over hoe Azure Lighthouse werkt.