Automatisieren Sie Azure Landing Zones über mehrere Mandanten hinweg
Wenn Ihre Organisation über mehrere Microsoft Entra-Mandanten mit Azure-Zielzonen (ALZ) verfügt, ist eine oder mehrere Male die Automatisierung entscheidend. Die Automatisierung hilft dabei, die ALZ-Bereitstellung über alle Mandanten hinweg erfolgreich zu betreiben und zu verwalten. Es gibt viele Ansätze, um ALZ-Bereitstellungen über mehrere Mandanten hinweg zu automatisieren. Der Ansatz, den Sie ergreifen, hängt von den Gründen ab, warum Ihre Organisation mehrere Microsoft Entra-Mandanten hat.
Beispielsweise verfügen Sie möglicherweise über mehrere Microsoft Entra-Mandanten, wenn Sie ein unabhängiger Softwareanbieter sind. Wahrscheinlich möchten Sie Ihre Unternehmens- und SaaS-Lösungen von Microsoft Entra-Mandanten getrennt halten. Das Risiko, dass sich ein Vorgang oder eine Bereitstellung auf den anderen Mandanten auswirkt, ob beabsichtigt oder versehentlich, verringert sich.
Die folgenden Abschnitte enthalten Diagramme und Anleitungen zu den Ansätzen, die Sie verwenden können. Wählen Sie basierend auf Ihren Anforderungen, Überlegungen und Empfehlungen für die Automatisierung Ihrer Bereitstellungen von Azure-Zielzonen bei der Behandlung mehrerer Microsoft Entra-Mandanten den für Sie am besten geeigneten Ansatz aus.
Hinweis
Lesen Sie zuerst die folgenden Artikel, um einen Überblick über Microsoft Entra-Mandanten zu erhalten:
Vorgehensweisen
Es gibt zwei Ansätze, um die Bereitstellung von Azure-Zielzonen über mehrere Microsoft Entra-Mandanten hinweg zu automatisieren.
Ansatz 1: Vollständige Isolation ist der am häufigsten verwendete Ansatz in Szenarien mit mehreren Mandanten. Dieser Ansatz behält die erforderliche Trennung und Isolation zwischen Microsoft Entra-Mandanten bei, was die häufigste Anforderung bei Verwendung eines mehrinstanzenfähigen Ansatzes ist.
Ansatz 2: Gemeinsame Anwendungsregistrierung (mehrinstanzenfähig) mit mehreren Dienstprinzipalen wird häufig in MSP-Szenarien (Managed Service Provider) verwendet. Bei diesem Ansatz kann ein Bereitstellungsstempelmuster verwendet werden, um die Bereitstellung einer fast identischen Architektur für mehrere Mandanten im großen Stil zu automatisieren.
Beide Ansätze werden als Beispiele und Inspirationen bereitgestellt. Sie können die Ansätze in Ihren Bereitstellungen basierend auf den Anforderungen Ihrer Organisation kombinieren und abgleichen.
Wichtig
Dieser Artikel behandelt die Automatisierung der Bereitstellung und des Betriebs von Azure-Zielzonen als Plattform in jedem Microsoft Entra-Mandanten, über den Ihre Organisation verfügt. Die Ansätze, Empfehlungen und Überlegungen in diesem Artikel sollen nicht von Anwendungsteams verwendet werden, die ihre Dienste und Anwendungen in ihren Zielzonen (Abonnements) bereitstellen und betreiben. Weitere Informationen zu den verschiedenen Arten von Zielzonen finden Sie unter Plattform- und Anwendungszielzonen.
Ansatz 1 – Vollständige Isolation
Bei diesem Ansatz besteht das Hauptziel darin, jeden Microsoft Entra-Mandanten über alle Automatisierungskomponenten hinweg voneinander isoliert zu halten, z. B.:
- Ein Git-Repository.
- GitHub Actions oder Azure Pipelines (einschließlich selbstgehosteter Runner, falls sie verwendet werden).
- Identitäten, die zum Ausführen von Automatisierungsaufgaben verwendet werden, z. B. verwaltete Identitäten, die selbstgehosteten Runnern zugewiesen sind, Dienstprinzipalnamen (Service Principal Names, SPNs), Benutzern oder Administratoren.
Bei diesem Ansatz gibt es mehr Komponenten zum Verwalten, die pro Microsoft Entra-Mandant dupliziert werden. Einige Organisationen haben möglicherweise Kontrollen zur Einhaltung gesetzlicher Bestimmungen, die diese Art von Trennung und Isolation vorschreibt.
Hinweis
Wenn Ihre Organisation nur die Verwendung verwalteter Identitäten für die Plattformautomatisierung zulässt, müssen Sie diesen Ansatz oder einen Ansatz verwenden, der sich bei jedem Mandanten einzeln anmeldet. Verwaltete Identitäten unterstützen keine mandantenübergreifenden Szenarien. Weitere Informationen finden Sie unter diesen häufig gestellten Fragen.
Identitäten für Plattformadministratoren und Entwickler – Ansatz 1
Bei diesem Ansatz sollten Identitäten auch in jedem Microsoft Entra-Mandanten isoliert werden. Dies bedeutet, dass jeder Plattformadministrator oder Entwickler ein separates Benutzerkonto innerhalb jedes Mandanten benötigt, um Vorgänge innerhalb dieses Mandanten auszuführen. Diese Konten werden auch für den Zugriff auf die Entwicklertools wie GitHub oder Azure DevOps für jeden Mandanten verwendet. Berücksichtigen Sie nach diesem Ansatz sorgfältig die Auswirkungen der Administrator- und Entwicklerproduktivität.
Microsoft Entra B2B und/oder Azure Lighthouse kann verwendet werden, aber diese Option stellt die Begründung für separate Microsoft Entra-Mandanten.
Ansatz 2: Gemeinsame Anwendungsregistrierung (mehrinstanzenfähig) mit mehreren Dienstprinzipalen
Bei diesem Ansatz wird eine Anwendungsregistrierung im verwalteten Microsoft Entra-Mandanten erstellt. In jedem Microsoft Entra-Mandanten, den Sie verwalten möchten, wird in diesem Mandanten basierend auf der Anwendungsregistrierung ein Dienstprinzipalname (SPN) erstellt. Diese Aktion ermöglicht es den Mitarbeitern, die die Pipelinetasks und -schritte ausführen, sich mit einem einzelnen Satz von Anmeldeinformationen bei einem der Microsoft Entra-Mandanten anzumelden.
Tipp
Ausführliche Informationen zu den Beziehungen zwischen Anwendungsobjekten und Dienstprinzipalobjekten finden Sie unter Anwendungs- und Dienstprinzipalobjekte in Microsoft Entra ID.
Wichtig
Bei diesem Ansatz sollten die Einzelanwendungsregistrierung und die zugehörigen Unternehmensanwendungen (Dienstprinzipale) auf ungewöhnliche Aktivitäten in Ihren SIEM-Tools (Security Information and Event Management) überwacht werden, da es sich um ein Konto mit hohen Berechtigungen handelt. Je nach Schweregrad der Warnung sollte er Warnungen senden und möglicherweise automatisch Maßnahmen ergreifen.
Im vorherigen Beispiel befindet sich eine einzelne App-Registrierung im contoso.onmicrosoft.com Microsoft Entra-Mandanten, und eine Unternehmensanwendung befindet sich in jedem der Microsoft Entra-Mandanten, die mit der App-Registrierung verknüpft sind. Dieses Setup ermöglicht es einer Pipeline, sich mit der einzelnen App-Registrierung für alle Microsoft Entra-Mandanten zu authentifizieren und zu autorisieren. Weitere Informationen finden Sie unter Hinzufügen der Mehrinstanzenfähigkeit zu Ihrer Anwendung.
Wenn Sie eine zentralisierte Pipeline verwenden, müssen Sie möglicherweise eine kleine Zuordnungstabelle erstellen, die Daten enthält, die die Microsoft Entra-Mandanten und andere Metadaten korrelieren, z. B. die Umgebung, zugeordnete Abonnements, Organisationsname und Identitätsobjekt-ID, die für die Authentifizierung und Autorisierung verwendet werden. Diese Daten können während der Ausführung der Pipeline in einem Schritt aufgerufen werden, der einige Logik und Bedingungen verwendet, um zu steuern, für welchen Microsoft Entra-Mandanten sie bereitgestellt werden und mit welchen Identitäten. Die Daten können in Diensten wie Azure Cosmos DB oder Azure Table Storage gespeichert werden.
Wenn Sie mehrere Umgebungen wie Entwicklung, Test oder Produktion verarbeiten, können diese auf die gleiche Weise gesteuert werden, indem sie die gleichen oder separaten Anwendungsregistrierungen und Unternehmensanwendungen mit Pipelines verwenden.
Sie können für jeden Microsoft Entra-Mandanten separate Pipelines verwenden oder eine einzelne Pipeline verwenden. Die Wahl liegt bei Ihnen, je nach Ihren Anforderungen.
Hinweis
Azure Lighthouse funktioniert ähnlich wie dieser Ansatz, aber Azure Lighthouse lässt die Zuweisung des RBAC-Besitzers, des Benutzerzugriffsadministrators und der Rollen mit DataActions-Berechtigungen nicht zu. Weitere Informationen finden Sie unter Rollenunterstützung für Azure Lighthouse.
Die Zugriffsrollen "Besitzer" und "Benutzer" sind in der Regel in allen Bereitstellungsszenarien für Azure-Zielzonen erforderlich. Diese Anforderung entfernt Azure Lighthouse als Option für den gesamten Bereitstellungsaspekt der Plattformautomatisierung von Azure-Zielzonen, ist aber in einigen Szenarien weiterhin nützlich. Weitere Informationen finden Sie unter Azure Lighthouse-Verwendung in ALZ mit mehreren Mandanten.
Identitäten für Plattformadministratoren und Entwickler – Ansatz 2
Bei diesem Ansatz benötigen Plattformadministratoren und Entwickler in der Regel nur Zugriff auf den verwaltenden Microsoft Entra-Mandanten. Dieser Zugriff gewährt ihnen Zugriff auf die Entwicklertools wie GitHub oder Azure DevOps, in denen alle Mandanten bereitgestellt und von dort aus betrieben werden.
Sie haben möglicherweise Zugriff auf die anderen Microsoft Entra-Mandanten über Microsoft Entra B2B oder Azure Lighthouse. Sie verwenden dasselbe Konto aus dem Verwaltungsmandanten, oder sie verfügen über separate Konten, wie im Beispiel im ersten Ansatz.