Automatisieren von Azure-Azure-Zielzonen ü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 ein Vorgang oder eine Implementierung den anderen Mandanten beeinflusst, sei es beabsichtigt oder versehentlich, verringert sich.
In den folgenden Abschnitten finden Sie Diagramme und Anleitungen zu den Ansätzen, die Sie ausführen können. Wählen Sie aus, welcher Ansatz für Sie am besten geeignet ist, basierend auf Ihren Anforderungen, Überlegungen und Empfehlungen zum Automatisieren Ihrer Azure-Landingzonen-Bereitstellungen bei der Verwaltung mehrerer Microsoft Entra-Mandanten.
Anmerkung
Lesen Sie zuerst die folgenden Artikel, um einen Überblick über Microsoft Entra-Mandanten zu erhalten:
Ansätze
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 gängigste Ansatz in Multitenant-Szenarien. Dieser Ansatz behält die erforderliche Trennung und Isolierung zwischen Microsoft Entra-Mandanten bei, was die häufigste Anforderung bei Verwendung eines mehrinstanzenfähigen Ansatzes ist.
Ansatz 2 – Die Registrierung gemeinsam genutzter Anwendungen (Multitenant) 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 befasst sich mit der Automatisierung der Bereitstellung und des Betriebs von Azure-Landezonen 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 Landungszonen finden Sie unter Plattform- vs. Anwendungslandungszonen.
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), Benutzerschaft oder Administration.
Bei diesem Ansatz gibt es mehr Komponenten zum Verwalten, die pro Microsoft Entra-Mandant dupliziert werden. Einigen Organisationen könnten regulatorische Compliance-Kontrollen auferlegt werden, die diese Art von Trennung und Isolierung erfordern.
Anmerkung
Wenn Ihre Organisation nur die Verwendung von verwalteten Identitäten für die Plattformautomatisierung zulässt, müssen Sie diesen Ansatz oder einen Ansatz verwenden, der sich einzeln bei jedem Mandanten anmeldet. Verwaltete Identitäten unterstützen aktuell keine mandantenübergreifenden Szenarien in einem allgemein verfügbaren Zustand. Weitere Informationen finden Sie unter diesen häufig gestellten Fragen.
Dies ist jedoch jetzt in der öffentlicher Vorschau für benutzerseitig zugewiesene verwaltete Identitäten verfügbar, indem eine Vertrauensstellung zwischen der Anwendung selbst und einer mehrinstanzenfähigen Entra ID-Anwendung konfiguriert wird. Weitere Informationen zur Konfiguration finden Sie unter Konfigurieren einer Anwendung, um einer verwalteten Identität (Vorschau)zu vertrauen. Dies kann jetzt Ansatz 2 – Registrierung gemeinsam genutzter Anwendungen (Multitenant) mit mehreren Dienstprinzipalen zu einer praktikable Option für Ihre Bereitstellung machen.
Identitäten für Plattformadministratoren und Entwickler – Ansatz 1
Bei diesem Ansatz sollten Identitäten auch in jedem Microsoft Entra-Mandanten isoliert werden, was 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 sorgfältig die Auswirkungen der Administrator- und Entwicklerproduktivität nach diesem Ansatz.
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 (Multitenant) 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 basierend auf der Anwendungsregistrierung ein Dienstprinzipalname (Service Principal Name, SPN) in diesem Mandanten erstellt. Diese Aktion ermöglicht es den Workern, die die Pipelinetasks und -schritte ausführen, sich mit einem einzelnen Satz von Anmeldeinformationen bei einem der Microsoft Entra-Mandanten anzumelden.
Tipp
Informationen zur Beziehung zwischen Anwendungsregistrierungen und Unternehmensanwendungen (Dienstprinzipien) 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 Konvertieren in eine mehrinstanzenfähige Anwendung und Erteilen einer mandantenweiten Administratoreinwilligung für eine Anwendung.
Tipp
In der öffentliche Vorschauversion können benutzerseitig zugewiesene verwaltete Identitäten jetzt Szenarien mit mehreren Mandanten unterstützen, indem eine Vertrauensstellung zwischen der Identität und einer mehrinstanzenfähigen Entra ID-Anwendung konfiguriert wird. Weitere Informationen zur Konfiguration finden Sie unter Konfigurieren einer Anwendung, um einer verwalteten Identität (Vorschau)zu vertrauen.
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 gespeichert werden, z. B. Azure Cosmos DB oder Azure Table Storage.
Wenn Sie mehrere Umgebungen wie Entwicklung, Test oder Produktion verarbeiten, können sie auf die gleiche Weise gesteuert werden, indem sie dieselben oder separate Anwendungsregistrierungen und Unternehmensanwendungen mit Pipelines verwenden.
Sie können entweder für jeden Microsoft Entra-Mandanten separate Pipelines erstellen oder eine einzige Pipeline verwenden. Die Auswahl basiert auf Ihren Anforderungen.
Anmerkung
Azure Lighthouse funktioniert ähnlich diesem 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 Rollen "Eigentümer" und "Benutzerzugriff" sind in der Regel in allen Azure-Zielzonen-Bereitstellungsszenarien 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.