Azure Lighthouse in zakelijke scenario's

  • Artikel

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.

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 er bij overnames een langetermijnstrategie voor tenantconsolidatie nog niet 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 moet één tenant aanwijzen 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, met beheertaken die door dezelfde set gebruikers worden uitgevoerd.

Aangezien Tenant A al gebruikers bevat in uw organisatie die deze taken voor Tenant A hebben uitgevoerd, kunt u abonnementen onboarden binnen Tenant B en Tenant C, zodat dezelfde gebruikers in Tenant A deze taken kunnen uitvoeren in alle tenants.

Diagram showing users in Tenant A managing resources in Tenant B and 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 blijven 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 enterprise-tenants relaties hebben ingesteld voor het beheren en beheren van tenants, kunnen gebruikers in elke tenant geregistreerde activiteit bekijken om acties te bekijken die door gebruikers in de beherende tenant worden uitgevoerd.

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 Azure Marketplace.

Aangezien zakelijke gebruikers doorgaans directe toegang hebben tot de tenants van de onderneming en er geen behoefte is om een beheeraanbieding te marketen 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 Azure Marketplace. Om ervoor te zorgen dat de aanbieding alleen beschikbaar is voor de juiste tenants, moet u ervoor zorgen dat uw plannen zijn gemarkeerd als 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.

Azure AD B2C

Azure Active Directory B2C (Azure AD B2C) biedt business-to-customer identity as a service. Wanneer u een resourcegroep delegeert via Azure Lighthouse, kunt u Azure Monitor gebruiken om aanmeldings- en controlelogboeken van Azure Active Directory B2C (Azure ACTIVE Directory B2C) 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 AD B2C bewaken met Azure Monitor 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 de resources bekijken en beheren die zijn gedelegeerd aan Tenant A op de pagina Serviceproviders van Azure Portal.

Volgende stappen