Ressourcenisolation mit mehreren Mandanten
Es gibt bestimmte Szenarien, in denen die Delegierung der Verwaltung in einem einzelnen Mandanten Ihre Anforderungen nicht erfüllt. In diesem Abschnitt werden die Anforderungen beschrieben, die möglicherweise dazu führen, dass Sie eine Architektur mit mehreren Mandanten erstellen müssen. Organisationen mit mehreren Mandanten können zwei oder mehr Microsoft Entra-Mandanten umfassen. Dies kann zu eindeutigen mandantenübergreifenden Zusammenarbeits- und Verwaltungsanforderungen führen. Architekturen mit mehreren Mandanten erhöhen den Verwaltungsaufwand und die Komplexität und sollten mit Vorsicht verwendet werden. Es wird empfohlen, einen einzelnen Mandanten zu verwenden, wenn Ihre Anforderungen mit einer solchen Architektur erfüllt werden können. Ausführlichere Informationen finden Sie unter Mehrinstanzenfähige Benutzerverwaltung.
Ein separater Mandant schafft eine neue Grenze und erfordert daher eine entkoppelte Verwaltung von Microsoft Entra-Verzeichnisrollen und -Verzeichnisobjekten, Richtlinien für den bedingten Zugriff, Azure-Ressourcengruppen, Azure-Verwaltungsgruppen und anderen Steuerelementen, wie in vorherigen Abschnitten beschrieben.
Ein separater Mandant ist nützlich für die IT-Abteilung einer Organisation, um mandantenweite Änderungen in Microsoft-Diensten wie Intune, Microsoft Entra Connect oder einer Konfiguration mit Hybridauthentifizierung zu überprüfen, während gleichzeitig die Benutzer und Ressourcen der Organisation geschützt sind. Dazu gehört das Testen von Dienstkonfigurationen, die möglicherweise mandantenweite Auswirkungen haben und nicht auf eine Teilmenge von Benutzer*innen im Produktionsmandanten beschränkt werden können.
Die Bereitstellung einer Nichtproduktionsumgebung in einem separaten Mandanten kann während der Entwicklung von benutzerdefinierten Anwendungen erforderlich sein, bei der möglicherweise Daten von Produktionsbenutzerobjekten mit MS Graph oder ähnlichen APIs geändert werden (z. B. Anwendungen, denen Directory.ReadWrite.All-Berechtigungen oder ähnlich umfangreiche Berechtigungen erteilt werden).
Hinweis
Die Microsoft Entra Connect-Synchronisierung in mehreren Mandanten kann bei der Bereitstellung einer Nichtproduktionsumgebung in einem separaten Mandanten nützlich sein. Weitere Informationen finden Sie unter Microsoft Entra Connect: unterstützte Technologien.
Ergebnisse
Zusätzlich zu den Ergebnissen, die mit einer Architektur mit Einzelmandanten wie oben beschrieben erzielt werden, können Organisationen die Ressourcen- und Mandanteninteraktionen vollständig entkoppeln:
Ressourcentrennung
Sichtbarkeit: Ressourcen in einem separaten Mandanten können von Benutzern und Administratoren in anderen Mandanten weder ermittelt noch aufgezählt werden. Auch Nutzungsberichte und Überwachungsprotokolle verbleiben innerhalb der neuen Mandantengrenze. Durch diese Trennung der Sichtbarkeit können Organisationen Ressourcen verwalten, die für vertrauliche Projekte benötigt werden.
Objektspeicherbedarf: Anwendungen, die über Microsoft Graph oder andere Verwaltungsschnittstellen in Microsoft Entra ID und/oder andere Microsoft-Onlinedienste schreiben, können in einem separaten Objektbereich arbeiten. Dadurch können Entwicklerteams während des Lebenszyklus der Softwareentwicklung Tests durchführen, ohne dass diese sich auf andere Mandanten auswirken.
Kontingente: Die Verbrauch von mandantenweiten Azure-Kontingenten und -Limits ist vom Verbrauch der anderen Mandanten getrennt.
Konfigurationstrennung
Ein neuer Mandant stellt einen separaten Satz mandantenweiter Einstellungen für Ressourcen und vertrauenswürdige Anwendungen bereit, deren Anforderungen andere Konfigurationen auf Mandantenebene erfordern. Darüber hinaus ermöglicht ein neuer Mandant die Einrichtung separater Microsoft-Onlinedienste wie Office 365.
Administrative Trennung
Durch eine neue Mandantengrenze stehen Ihnen separate Microsoft Entra-Verzeichnisrollen zur Verfügung, mit dem Sie verschiedene Administratorengruppen konfigurieren können.
Häufige Verwendung
Das folgende Diagramm veranschaulicht einen gängigen Anwendungsfall für die Ressourcenisolation in mehreren Mandanten: eine Vorproduktions- oder Sandboxumgebung, die ein höheres Maß an Trennung erfordert, als mit delegierter Verwaltung in einem einzelnen Mandanten erreicht werden kann.
Contoso ist eine Organisation, die die Mandantenarchitektur des Unternehmens um einem Vorproduktionsmandanten mit dem Namen „ContosoSandbox.com“ erweitert hat. Der Sandboxmandant dient zur Unterstützung der kontinuierlichen Entwicklung von Unternehmenslösungen, die mit Microsoft Graph in Microsoft Entra ID und Microsoft 365 geschrieben werden. Diese Lösungen werden im Unternehmensmandanten bereitgestellt.
Der Sandboxmandant wird online geschaltet, um zu verhindern, dass diese in der Entwicklung befindlichen Anwendungen Produktionssysteme direkt oder indirekt beeinträchtigen, indem sie Mandantenressourcen nutzen oder sich auf Kontingente oder Drosselungsgrenzen auswirken.
Entwickler benötigen während des gesamten Entwicklungslebenszyklus Zugriff auf den Sandboxmandanten – idealerweise per Self-Service-Zugriff, der zusätzliche Berechtigungen erfordert, die in der Produktionsumgebung nicht zulässig sind. Beispiele für diese zusätzlichen Berechtigungen sind das Erstellen, Löschen und Aktualisieren von Benutzerkonten, das Registrieren von Anwendungen, das Bereitstellen von Azure-Ressourcen und das Aufheben dieser Bereitstellungen sowie Änderungen an Richtlinien oder der Gesamtkonfiguration der Umgebung.
In diesem Beispiel verwendet Contoso Microsoft Entra B2B Collaboration zum Bereitstellen von Benutzern aus dem Unternehmensmandanten, um diesen das Verwalten von und das Zugreifen auf Ressourcen in Anwendungen im Sandboxmandanten zu ermöglichen, ohne mehrere Anmeldeinformationen verwalten zu müssen. Diese Funktion ist in erster Linie auf Szenarien mit organisationsübergreifender Zusammenarbeit ausgerichtet. Unternehmen wie Contoso, die über mehrere Mandanten verfügen, können diese Funktion jedoch nutzen, um zusätzlichen Aufwand für die Lebenszyklusverwaltung von Anmeldeinformationen zu vermeiden und das Benutzererlebnis nicht unnötig komplex zu machen.
Verwenden Sie Einstellungen für den mandantenübergreifenden External Identities-Zugriff, um die Zusammenarbeit mit anderen Microsoft Entra-Organisationen über B2B Collaboration zu verwalten. Diese Einstellungen bestimmen sowohl den Grad des eingehenden Zugriffs, den Benutzer in externen Microsoft Entra Organisationen auf Ihre Ressourcen haben, als auch den Grad des ausgehenden Zugriffs, den Ihre Benutzer auf externe Organisationen haben. Darüber hinaus können Sie den MFA-Ansprüchen (Multi-Faktor-Authentifizierung) und Geräteansprüchen (Ansprüche von konformen Geräten und von Microsoft Entra Hybrid Join-Geräten) von anderen Microsoft Entra-Organisationen vertrauen. Ausführliche Informationen und Überlegungen zur Planung finden Sie unter Übersicht: Mandantenübergreifender Zugriff mit Microsoft Entra External ID.
Ein weiterer Ansatz könnte sein, die Funktionen von Microsoft Entra Connect zu nutzen, um die lokalen Microsoft Entra-Anmeldeinformationen mit mehreren Mandanten zu synchronisieren, wobei das Kennwort gleich bleibt, aber die UPN-Domäne der Benutzer anders lautet.
Ressourcenisolation bei mehreren Mandanten
Bei einem neuen Mandanten verfügen Sie über einen separaten Satz von Administratoren. Organisationen können sich für die Nutzung von Unternehmensidentitäten über Microsoft Entra B2B Collaboration entscheiden. Ebenso können Organisationen Azure Lighthouse für die mandantenübergreifende Verwaltung von Azure-Ressourcen implementieren, sodass nicht produktive Azure-Abonnements von Identitäten im entsprechenden produktiven Abonnement verwaltet werden. Azure Lighthouse kann nicht für die Verwaltung von Diensten außerhalb von Azure verwendet werden, wie z. B. Microsoft Intune. Für Anbieter verwalteter Dienste (Managed Service Providers, MSPs) ist Microsoft 365 Lighthouse ein Administratorportal, mit dessen Hilfe sie Geräte, Daten und Benutzer im gewünschten Umfang für kleine und mittlere Geschäftskunden sichern und verwalten können, die Microsoft 365 Business Premium, Microsoft 365 E3 oder Windows 365 Business nutzen.
Auf diese Weise können Benutzer*innen weiter ihre Unternehmensanmeldeinformationen verwenden, und Organisationen profitieren dennoch von den Vorteilen der Trennung.
Microsoft Entra B2B Collaboration sollte in Sandboxmandanten so konfiguriert werden, dass nur Identitäten aus der Unternehmensumgebung mithilfe von Zulassungs-/Verweigerungslisten von Azure B2B integriert werden können. Wenn Sie für Mandanten B2B zulassen möchten, sollten Sie die mandantenübergreifenden Zugriffseinstellungen von External Identities für die mandantenübergreifende Multi-Faktor-Authentifizierung bzw. Gerätevertrauensstellung verwenden.
Wichtig
Architekturen mit mehreren Mandanten und aktiviertem externem Identitätszugriff bieten nur Ressourcenisolation, aber keine Identitätsisolation. Die Ressourcenisolation über Microsoft Entra B2B Collaboration und Azure Lighthouse reduziert die Risiken im Zusammenhang mit Identitäten nicht.
Wenn in der Sandboxumgebung und der Unternehmensumgebung dieselben Identitäten verwendet werden, gelten die folgenden Szenarien für den Sandboxmandanten:
Ein böswilliger Akteur, der einen Benutzer, ein Gerät oder eine Hybridinfrastruktur im Unternehmensmandanten kompromittiert und in den Sandboxmandanten eingeladen wird, kann Zugriff auf die Apps und Ressourcen des Sandboxmandanten erhalten.
Fehlerhafte Vorgänge (z. B. das Löschen von Benutzerkonten oder das Sperren von Anmeldeinformationen) im Unternehmensmandanten können sich auf den Zugriff eingeladener Benutzer*innen auf den Sandboxmandanten auswirken.
Sie müssen eine Risikoanalyse durchführen und möglicherweise eine Isolation von Identitäten in mehreren Mandanten für geschäftskritische Ressourcen in Erwägung ziehen, die einen sehr defensiven Ansatz erfordern. Azure Privileged Identity Management kann dazu beitragen, einige der Risiken zu verringern, indem für den Zugriff auf geschäftskritische Mandanten und Ressourcen zusätzliche Sicherheitsvorkehrungen erzwungen werden.
Verzeichnisobjekte
Der Mandant, den Sie zum Isolieren von Ressourcen verwenden, kann dieselben Arten von Objekten, Azure-Ressourcen und vertrauenswürdigen Anwendungen enthalten wie der primäre Mandant. Möglicherweise müssen Sie die folgenden Arten von Objekten bereitstellen:
Benutzer und Gruppen: Identitäten, die von Engineeringteams für Lösungen benötigt werden, wie z. B. diese:
Administratoren für Sandboxumgebungen
Technische Besitzer von Anwendungen
Entwickler von Branchenanwendungen
Testkonten für Endbenutzer
Diese Identitäten können für Folgendes bereitgestellt werden:
Mitarbeiter, die ihr Unternehmenskonto über Microsoft Entra B2B Collaboration verwenden.
Mitarbeiter, die für die Verwaltung, den Verwaltungszugriff im Notfall oder aus anderen technischen Gründen lokale Konten benötigen.
Kunden, die nicht Nichtproduktionsinstanzen von Active Directory am lokalen Standort benötigen, können ihre lokalen Identitäten auch mit dem Sandboxmandanten synchronisieren, falls dies aufgrund der zugrunde liegenden Ressourcen und Anwendungen erforderlich ist.
Geräte: Der Nichtproduktionsmandant enthält eine geringere Anzahl von Geräten, und zwar nur solche, die für den Entwicklungszyklus von Lösungen erforderlich sind:
Verwaltungsarbeitsstationen
Nichtproduktionscomputer und -mobilgeräte, die für Entwicklung, Testen und Dokumentation benötigt werden
Anwendungen
In Microsoft Entra integrierte Anwendungen: Anwendungsobjekte und Dienstprinzipale für:
Testinstanzen der Anwendungen, die in der Produktion bereitgestellt werden (z. B. Anwendungen, die in Microsoft Entra ID und Microsoft-Onlinedienste schreiben).
Infrastrukturdienste zum Verwalten und Pflegen des Nichtproduktionsmandanten, potenziell eine Teilmenge der im Unternehmensmandanten verfügbaren Lösungen.
Microsoft-Onlinedienste:
In der Regel sollte das Team, das die Microsoft-Onlinedienste in der Produktion besitzt, auch Besitzer der Nichtproduktionsinstanz dieser Dienste sein.
Administratoren von Nichtproduktionstestumgebungen sollten Microsoft-Onlinedienste nicht bereitstellen, es sei denn, genau diese Dienste sollen getestet werden. Dadurch wird eine unangemessene Verwendung von Microsoft-Onlinediensten vermieden, z. B. das Einrichten von SharePoint-Produktionswebsites in einer Testumgebung.
Ebenso sollte die Bereitstellung von Microsoft-Onlinediensten, die von Endbenutzern initiiert werden können (auch als Ad-hoc-Abonnements bezeichnet), gesperrt werden. Weitere Informationen finden Sie unter Was ist die Self-Service-Registrierung für Microsoft Entra ID?.
Im Allgemeinen sollten alle nicht essenziellen Lizenzfeatures für den Mandanten per gruppenbasierten Lizenzierung deaktiviert werden. Dies sollte von demselben Team durchgeführt werden, das Lizenzen im Produktionsmandanten verwaltet, um eine Fehlkonfiguration durch Entwickler*innen zu vermeiden, die möglicherweise nicht wissen, wie sich die Aktivierung lizenzierter Features auswirkt.
Azure-Ressourcen
Alle Azure-Ressourcen, die von Anwendungen mit Vertrauensstellung benötigt werden, können auch bereitgestellt werden. Beispielsweise Datenbanken, virtuelle Computer, Container, Azure-Funktionen usw. Für Ihre Sandboxumgebung müssen Sie die Kosteneinsparungen durch die Verwendung kostengünstigerer SKUs für Produkte und Dienste gegen die geringere Anzahl verfügbarer Sicherheitsfeatures abwägen.
Das RBAC-Modell für die Zugriffssteuerung sollte auch in einer Nichtproduktionsumgebung weiterhin verwendet werden, für den Fall, dass nach Abschluss der Tests Änderungen in die Produktion repliziert werden. Andernfalls können Sicherheitslücken in der Nichtproduktionsumgebung an Ihren Produktionsmandanten übertragen werden.
Ressourcen- und Identitätsisolation mit mehreren Mandanten
Ergebnisse der Isolation
Es gibt einige wenige Situationen, in denen die Ressourcenisolation Ihre Anforderungen nicht erfüllen kann. Sie können sowohl Ressourcen als auch Identitäten in einer Architektur mit mehreren Mandanten isolieren, indem Sie alle mandantenübergreifenden Zusammenarbeitsfunktionen deaktivieren und effektiv eine separate Identitätsgrenze erstellen. Dieser Ansatz ist eine Verteidigungsmaßnahme gegen Vorgangsfehler und Kompromittierung von Benutzeridentitäten, Geräten oder Hybridinfrastrukturen in Unternehmensmandanten.
Allgemeine Nutzung der Isolation
Eine separate Identitätsgrenze wird in der Regel für geschäftskritische Anwendungen und Ressourcen wie beispielsweise kundenorientierte Dienste verwendet. In diesem Szenario hat das Unternehmen Fabrikam beschlossen, einen separaten Mandanten für sein kundenorientiertes SaaS-Produkt zu erstellen, um das Risiko einer Kompromittierung von Mitarbeiteridentitäten zu vermeiden, die sich auf die SaaS-Kunden auswirkt. Das folgende Diagramm veranschaulicht diese Architektur:
Der Mandant „FabrikamSaaS“ enthält die Umgebungen, die für Anwendungen verwendet werden, die Kunden im Rahmen des Geschäftsmodells von Fabrikam angeboten werden.
Isolation von Verzeichnisobjekten
FabrikamSaaS enthält folgende Verzeichnisobjekte:
Benutzer und Gruppen: Identitäten, die von IT-Lösungsteams, Kundensupportteams oder anderem erforderlichen Personal benötigt werden, werden innerhalb des SaaS-Mandanten erstellt. Um die Isolation sicherzustellen, werden nur lokale Konten verwendet, und Microsoft Entra B2B Collaboration ist nicht aktiviert.
Azure AD B2C-Verzeichnisobjekte: Wenn von Kunden auf die Mandantenumgebungen zugegriffen wird, können diese Objekte einen Azure AD B2C-Mandanten und die zugehörigen Identitätsobjekte enthalten. Abonnements, die diese Verzeichnisse enthalten, sind gute Kandidaten für eine isolierte endbenutzerorientierte Umgebung.
Geräte: Dieser Mandant enthält eine geringere Anzahl von Geräten – und zwar nur solche, die zum Ausführen von kundenorientierten Lösungen erforderlich sind:
Sichere Verwaltungsarbeitsstationen
Arbeitsstationen für Supportmitarbeiter (dies kann Techniker umfassen, die in Rufbereitschaft sind, wie oben beschrieben)
Isolation von Anwendungen
In Microsoft Entra integrierte Anwendungen: Anwendungsobjekte und Dienstprinzipale für:
Produktionsanwendungen (z. B. Anwendungsdefinitionen mit mehreren Mandanten)
Infrastrukturdienste zum Verwalten und Pflegen der kundenorientierten Umgebung
Azure-Ressourcen: Hosten die IaaS-, PaaS- und SaaS-Ressourcen der kundenorientierten Produktionsinstanzen.