Azure-landingszones automatiseren voor meerdere tenants
Als uw organisatie meerdere Microsoft Entra-tenants met Azure-landingszones (ALZ) heeft, is automatisering een of meerdere keren belangrijk. Automatisering helpt om de ALZ-implementatie op schaal te beheren en te onderhouden voor alle gebruikers. Er zijn veel benaderingen voor het automatiseren van ALZ-implementaties in meerdere tenants. De aanpak die u gebruikt, is afhankelijk van de redenen waarom uw organisatie meerdere Microsoft Entra-tenants heeft.
U hebt bijvoorbeeld meerdere Microsoft Entra-tenants als u een onafhankelijke softwareleverancier bent. Waarschijnlijk wilt u uw zakelijke en SaaS-oplossingen gescheiden houden van Microsoft Entra-tenants. Het risico dat een bewerking of uitvoering van invloed is op de andere tenant, of dit nu bedoeld of per ongeluk is, vermindert.
De volgende secties bevatten diagrammen en richtlijnen over de benaderingen die u kunt gebruiken. Kies welke benadering het meest geschikt is voor u op basis van uw vereisten, overwegingen en aanbevelingen voor het automatiseren van uw Implementaties van Azure-landingszones bij het verwerken van meerdere Microsoft Entra-tenants.
Notitie
Bekijk eerst de volgende artikelen voor een overzicht van Microsoft Entra-tenants:
Benaderingen
Er zijn twee benaderingen voor het automatiseren van de implementatie van Azure-landingszones in meerdere Microsoft Entra-tenants.
Benadering 1: volledige isolatie is de meest voorkomende benadering in scenario's met meerdere tenants. Deze benadering houdt de vereiste scheiding en isolatie tussen Microsoft Entra-tenants bij, wat de meest voorkomende vereiste is bij het gebruik van een multitenant-benadering.
Benadering 2: registratie van gedeelde toepassingen (multitenant) met meerdere service-principals wordt vaak gebruikt in MSP-scenario's (Managed Service Provider). In deze benadering kan een patroon voor implementatiestempels worden gebruikt om de implementatie van een bijna identieke architectuur op grotere schaal te automatiseren voor meerdere huurders.
Beide benaderingen worden gegeven als voorbeelden en inspiratie. U kunt de benaderingen in uw implementaties combineren en afstemmen op basis van de vereisten van uw organisatie.
Belangrijk
In dit artikel wordt beschreven hoe u de implementatie en werking van Azure-landingszones automatiseert als het platform in elke Microsoft Entra-tenant die uw organisatie heeft. De benaderingen, aanbevelingen en overwegingen in dit artikel zijn niet bedoeld om te worden gebruikt door toepassingsteams die hun services en toepassingen implementeren en gebruiken in hun landingszones (abonnementen). Zie Platform versus toepassingslandingszonesvoor meer informatie over de verschillende typen landingszones.
Benadering 1 – Volledige isolatie
In deze benadering is het primaire doel om elke Microsoft Entra-tenant gescheiden te houden van elkaar in alle automatiseringsonderdelen, zoals:
- Een Git-opslagplaats.
- GitHub Actions of Azure Pipelines (inclusief zelf-gehoste runners, indien deze worden gebruikt).
- Identiteiten die worden gebruikt voor het uitvoeren van taken binnen automatisering, zoals beheerde identiteiten die zijn toegewezen aan zelf-gehoste runners, service principal names (SPNs), gebruikers of beheerders.
In deze benadering zijn er meer onderdelen om te beheren die worden gedupliceerd per Microsoft Entra-tenant. Sommige organisaties hebben mogelijk controles voor naleving van regelgeving opgelegd die dit type scheiding en isolatie vereisen.
Notitie
Als uw organisatie alleen het gebruik van beheerde identiteiten toestaat voor platformautomatisering, moet u deze benadering of een benadering gebruiken die zich afzonderlijk aanmeldt bij elke tenant. Beheerde identiteiten ondersteunen momenteel geen scenario's tussen tenants in een algemeen beschikbare toestand. Zie deze veelgestelde vragenvoor meer informatie.
Dit is echter nu beschikbaar in openbare preview voor User-Assigned Beheerde Identiteiten door een vertrouwensrelatie tussen zichzelf en een Entra ID-multitenant-toepassing te configureren. Zie meer informatie over het configureren hiervan in Een toepassing configureren om een beheerde identiteit (preview)-te vertrouwen. Hierdoor kan Benadering 2 – registratie van gedeelde toepassingen (multitenant) met meerdere service-principalen een haalbare optie voor uw implementatie zijn.
Identiteiten voor platformbeheerders en ontwikkelaars - Benadering 1
Bij deze benadering moeten identiteiten ook worden geïsoleerd in elke Microsoft Entra-tenant, wat betekent dat elke platformbeheerder of ontwikkelaar een afzonderlijk gebruikersaccount binnen elke tenant nodig heeft om bewerkingen in die tenant uit te voeren. Deze accounts worden ook gebruikt voor toegang tot de hulpprogramma's voor ontwikkelaars, zoals GitHub of Azure DevOps, voor elk van de tenants. Houd zorgvuldig rekening met de gevolgen van de productiviteit van beheerders en ontwikkelaars volgens deze aanpak.
Microsoft Entra B2B en/of Azure Lighthouse kan worden gebruikt, maar roept de vraag op waarom er afzonderlijke Microsoft Entra-tenants zijn.
Benadering 2: registratie van gedeelde toepassingen (multitenant) met meerdere service-principals
In deze benadering wordt een toepassingsregistratie gemaakt in de beherende Microsoft Entra-tenant. In elke Microsoft Entra-tenant die u wilt beheren, wordt er een SPN (Service Principal Name) gemaakt in die tenant, op basis van de registratie van de toepassing. Dankzij deze actie kunnen werknemers die verantwoordelijk zijn voor de uitvoering van de pijplijntaken en -stappen zich met één set inloggegevens aanmelden bij een van de Microsoft Entra-tenants.
Fooi
Zie Toepassings- en service-principalobjecten in Microsoft Entra IDvoor informatie over de relatie tussen toepassingsregistraties en bedrijfstoepassingen (serviceprincipes).
Belangrijk
In deze benadering moeten de registratie van één toepassing en de bijbehorende bedrijfstoepassingen (service-principals) worden bewaakt op abnormale activiteiten in uw SIEM-hulpprogramma's (Security Information and Event Management), omdat dit een account met hoge bevoegdheden is. Het moet waarschuwingen verzenden en mogelijk automatisch actie ondernemen, afhankelijk van de ernst van de waarschuwing.
In het vorige voorbeeld bevindt één app-registratie zich in de contoso.onmicrosoft.com Microsoft Entra-tenant en bevindt een bedrijfstoepassing zich in elk van de Microsoft Entra-tenants die zijn gekoppeld aan de app-registratie. Met deze installatie kan een pijplijn alle Microsoft Entra-tenants verifiëren en autoriseren met behulp van de registratie van één app. Voor meer informatie, zie Uw toepassing multitenant maken en een tenantomvattende beheerderstoestemming verlenen aan een toepassing.
Fooi
Door de gebruiker toegewezen beheerde identiteiten, in openbare previewversie, kunnen nu multitenant-scenario's ondersteunen door vertrouwen tussen zichzelf en een Entra ID-multitenant-toepassing te configureren. Zie meer informatie over het configureren hiervan in Een toepassing configureren om een beheerde identiteit (preview)-te vertrouwen.
Wanneer u een gecentraliseerde pijplijn gebruikt, moet u mogelijk een kleine toewijzingstabel maken die gegevens bevat die de Microsoft Entra-tenants en andere metagegevens correleren, zoals de omgeving, gekoppelde abonnementen, organisatienaam en id-object-id die wordt gebruikt voor verificatie en autorisatie. Deze gegevens kunnen worden aangeroepen tijdens het uitvoeren van de pijplijn in een stap die gebruikmaakt van een aantal logica en voorwaarden om te bepalen in welke Microsoft Entra-tenant deze wordt geïmplementeerd en met welke identiteiten. De gegevens kunnen worden opgeslagen in services, zoals Azure Cosmos DB of Azure Table Storage.
Wanneer u meerdere omgevingen, zoals ontwikkeling, testen of productie, verwerkt, kunnen ze op dezelfde manier worden beheerd met behulp van dezelfde of afzonderlijke toepassingsregistraties en bedrijfstoepassingen met pijplijnen.
U kunt besluiten om afzonderlijke pijplijnen te hebben voor elke Microsoft Entra-tenant of om één pijplijn te gebruiken. De keuze is van u op basis van uw vereisten.
Notitie
Azure Lighthouse werkt op dezelfde manier, maar Azure Lighthouse staat de toewijzing van de RBAC-eigenaar, de beheerder van gebruikerstoegang en rollen met DataActions-machtigingen niet toe. Zie Rolondersteuning voor Azure Lighthousevoor meer informatie.
De rol eigenaar en gebruikerstoegang zijn doorgaans vereist in alle implementatiescenario's van de Azure-landingszone. Met deze vereiste wordt Azure Lighthouse verwijderd als optie voor het volledige aspect van de platformautomatiseringsimplementatie van Azure-landingszones, maar het is in sommige scenario's nog steeds nuttig. Zie Azure Lighthouse-gebruik in ALZ multitenantvoor meer informatie.
Identiteiten voor platformbeheerders en ontwikkelaars - Benadering 2
Bij deze benadering hebben platformbeheerders en ontwikkelaars doorgaans alleen toegang nodig tot de beherende Microsoft Entra-tenant. Met deze toegang kunnen ze gebruikmaken van de ontwikkelaarstools, zoals GitHub of Azure DevOps, waar alle tenants worden geïnstalleerd en beheerd.
Ze hebben mogelijk toegang tot de andere Microsoft Entra-tenants via Microsoft Entra B2B of Azure Lighthouse. Ze gebruiken hetzelfde account van de beherende tenant of ze hebben mogelijk afzonderlijke accounts, zoals het voorbeeld in de eerste benadering.