Azure Lighthouse in zakelijke scenario's

  • Artikel
  • 4 minuten om te lezen

Een veelvoorkomende situatie voor Azure Lighthouse is wanneer een serviceprovider resources beheert in Azure Active Directory (Azure AD)-tenants die eigendom zijn van klanten. De mogelijkheden van Azure Lighthouse kunnen ook worden gebruikt om het beheer van meerdere tenants te vereenvoudigen binnen een onderneming die gebruikmaakt van meerdere Azure AD-tenants.

Eén tenant versus meerdere tenants

Voor de meeste organisaties is beheer eenvoudiger met één Azure AD-tenant. Als u alle resources binnen één tenant hebt, kunt u beheertaken centraliseren door aangewezen gebruikers, gebruikersgroepen of service-principals binnen die tenant. U wordt aangeraden waar mogelijk één tenant voor uw organisatie te gebruiken.

Sommige organisaties moeten mogelijk meerdere Azure AD-tenants gebruiken. Dit kan een tijdelijke situatie zijn, omdat er overnames zijn geweest en er nog geen strategie voor langetermijnconsolidatie van tenants is gedefinieerd. In andere tijden moeten organisaties mogelijk doorlopend meerdere tenants onderhouden vanwege volledig onafhankelijke dochterondernemingen, geografische of juridische vereisten of andere overwegingen.

In gevallen waarin een architectuur met meerdere tenants is vereist, Azure Lighthouse u helpen beheerbewerkingen te centraliseren en stroomlijnen. Met behulp Azure Lighthouse kunnen gebruikers in één beherende tenant op een gecentraliseerde, schaalbare manier beheerfuncties voor verschillende tenants uitvoeren.

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 we Tenant A noemen. Uw organisatie verkrijgt vervolgens Tenant B en Tenant C en u hebt zakelijke redenen waarvoor u deze als afzonderlijke tenants moet onderhouden. U wilt echter voor alle beleidsdefinities, back-upprocedures en beveiligingsprocessen dezelfde beleidsdefinities, back-upprocedures en beveiligingsprocessen gebruiken, met beheertaken die worden uitgevoerd door dezelfde set gebruikers.

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

Diagram met gebruikers in Tenant A die resources beheren in Tenant B en Tenant C.

Beveiligings- en toegangsoverwegingen

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.

In beide geval moet u het principe van de minste bevoegdheden volgen bij het definiëren van welke gebruikers toegang hebben tot gedelegeerde resources. Dit helpt ervoor te zorgen dat gebruikers alleen de machtigingen hebben 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 beherende 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 beheerde en beheerde tenantrelaties tot stand hebben gebracht, kunnen gebruikers in elke tenant geregistreerde activiteiten bekijken om acties te zien die worden ondernomen door gebruikers in de beherende tenant.

Overwegingen voor onboarding

Abonnementen (of resourcegroepen binnen een abonnement) kunnen worden onboarding naar 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 het niet nodig is om een beheeraanbieding op de markt te brengen of te promoten, is het meestal sneller en eenvoudiger om Azure Resource Manager implementeren. Hoewel de richtlijnen voor onboarding verwijzen naar serviceproviders en klanten, kunnen ondernemingen dezelfde processen gebruiken om hun tenants te onboarden.

Als u dat liever hebt, kunnen tenants binnen een onderneming worden ge onboardd door een Managed Services-aanbiedingte 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 als privé zijn gemarkeerd. 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 een business-to-customer-identiteit als een service. Wanneer u een resourcegroep delegeert via Azure Lighthouse, kunt u Azure Monitor gebruiken om aanmeldings- en controlelogboeken van Azure Active Directory B2C (Azure AD B2C) naar verschillende bewakingsoplossingen te routen. 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 Monitor Azure AD B2C with Azure Monitor (Controle van Azure Monitor.

Terminologienotities

Voor beheer tussen tenants binnen de onderneming kunnen verwijzingen naar serviceproviders in de Azure Lighthouse-documentatie worden toegepast op de beherende tenant binnen een onderneming, dat wil zeggen de tenant die de gebruikers omvat die resources in andere tenants via Azure Lighthouse. Op dezelfde manier kunnen verwijzingen naar klanten worden toegepast op de tenants die resources delegeren die moeten worden beheerd via gebruikers in de beherende tenant.

In het voorbeeld dat hierboven wordt beschreven, kan tenant A bijvoorbeeld worden zien als de tenant van de serviceprovider (de beherende tenant) en tenant B en Tenant C als de tenants van de klant.

Als u doorgaat met dit voorbeeld, kunnen Tenant A-gebruikers met de juiste machtigingen gedelegeerde resources bekijken en beheren op de pagina Mijn klanten van de 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 de Azure Portal.

Volgende stappen