Entwerfen einer mehrinstanzenfähigen Architektur für große Institutionen
Für kleinere Institutionen wird eine Architektur mit nur einem Mandanten empfohlen. Für Organisationen mit mehr als einer Million Benutzern empfehlen wir jedoch eine mehrinstanzenfähige Architektur, um Leistungsprobleme und Mandanteneinschränkungen wie Azure-Abonnements und -Kontingente undMicrosoft Entra Dienstgrenzwerte und -einschränkungen zu beheben.
Entwurfsgrundsätze
Berücksichtigen Sie beim Entwerfen Ihrer mehrinstanzenfähigen Architektur die folgenden Entwurfsprinzipien, um Kosten zu senken und die Effizienz und Sicherheit zu erhöhen:
Kosten senken
Verringern Sie die Abhängigkeit von der lokalen Infrastruktur und mehreren Identitätsanbietern.
Ermöglichen Sie Es Benutzern, ihr Konto zu entsperren oder Kennwörter mithilfe von Self-Service zurückzusetzen (z. B. Microsoft Entra Self-Service-Kennwortzurücksetzung).
Effizienz steigern
Standardisieren Sie Architektur, Konfigurationen und Prozesse mandantenübergreifend, um administrative Probleme zu minimieren.
Minimieren der Notwendigkeit, dass Benutzer von einem Mandanten zu einem anderen wechseln müssen
Erhöhen der Sicherheit
Konzentrieren Sie sich darauf, die Sicherheit der Schülerdaten sicherzustellen.
Befolgen Sie das Prinzip der geringsten Rechte: Gewähren Sie nur die Berechtigungen, die zum Ausführen der erforderlichen Aufgaben erforderlich sind, und implementieren Sie Just-in-Time-Zugriff (JIT).
Aktivieren Sie den Zugriff externer Benutzer nur über die Berechtigungsverwaltung oder Microsoft Entra B2B-Zusammenarbeit.
Delegieren Sie die Verwaltung bestimmter Aufgaben an bestimmte Benutzer mit Just Enough Access (JEA), um die Aufgabe auszuführen.
Häufige Gründe für mehrere Mandanten
Organisationen mit weniger als einer Million Benutzern wird dringend empfohlen, einen einzelnen Mandanten zu erstellen, es sei denn, andere Kriterien weisen darauf hin, dass mehrere Mandanten erforderlich sind. Für Organisationen mit mindestens einer Million Benutzerobjekten empfehlen wir mehrere Mandanten, die einen regionalen Ansatz verwenden.
Das Erstellen separater Mandanten hat die folgenden Auswirkungen auf Ihre EDU-Umgebung.
Administrative Trennung
Kann die Auswirkungen eines Administrativen Sicherheits- oder Betriebsfehlers auf kritische Ressourcen einschränken.
Kann die Auswirkungen von kompromittierten Administrator- oder Benutzerkonten einschränken.
Nutzungsberichte und Überwachungsprotokolle sind in einem Mandanten enthalten.
Ressourcentrennung
Datenschutz für Kursteilnehmer. Benutzerobjekte von Kursteilnehmern können nur innerhalb des Mandanten erkannt werden, in dem sich das Objekt befindet.
Ressourcenisolation. Ressourcen in einem separaten Mandanten können nicht von Benutzern und Administratoren in anderen Mandanten ermittelt oder aufgezählt werden.
Objektbedarf. Anwendungen, die über Microsoft Graph oder andere Verwaltungsschnittstellen in Microsoft Entra ID und andere Microsoft Online-Dienste schreiben, können sich nur auf Ressourcen im lokalen Mandanten auswirken.
Quoten. Der Verbrauch von mandantenweiten Azure-Kontingenten und -Grenzwerten ist von dem verbrauch der anderen Mandanten getrennt.
Trennung von Konfigurationen
Stellt einen separaten Satz mandantenweiter Einstellungen bereit, die Ressourcen und vertrauenswürdige Anwendungen mit unterschiedlichen Konfigurationsanforderungen berücksichtigen können.
Aktiviert eine neue Gruppe von Microsoft Online-Diensten, z. B. Office 365.
Zusätzlich zu mehr als einer Million Benutzern können die folgenden Überlegungen zu mehreren Mandanten führen.
Administrative Überlegungen
Sie arbeiten nach Vorschriften, die einschränken, wer die Umgebung basierend auf Kriterien wie Staatsangehörigkeitsland, Wohnsitzland oder Genehmigungsstufe verwalten kann.
Sie haben Complianceanforderungen, z. B. den Datenschutz von Kursteilnehmern, die das Erstellen von Identitäten in bestimmten lokalen Regionen erfordern.
Ressourcenüberlegungen
Sie verfügen über Ressourcen, z. B. für Forschung und Entwicklung, die Sie aus regulatorischen oder unternehmenskritischen Gründen vor Ermittlung, Aufzählung oder Übernahme durch vorhandene Administratoren schützen müssen.
Entwicklungszyklus von benutzerdefinierten Anwendungen, die Daten von Benutzern mit MS Graph oder ähnlichen APIs im großen Stil ändern können (z. B. Anwendungen, denen Directory.ReadWrite.All gewährt wird)
Überlegungen zur Konfiguration
- Ressourcen mit Anforderungen, die mit vorhandenen mandantenweiten Sicherheits- oder Zusammenarbeitsstatus in Konflikt treten, z. B. zulässige Authentifizierungstypen, Geräteverwaltungsrichtlinien, Self-Service-Fähigkeit oder Identitätsüberprüfung für externe Identitäten.
Bestimmen des mehrinstanzenfähigen Ansatzes
In diesem Abschnitt betrachten wir eine fiktive Universität namens School of Fine Arts mit 2 Millionen Studenten in 100 Schulen im gesamten USA. In diesen Schulen gibt es insgesamt 130.000 Lehrer und 30.000 Vollzeitmitarbeiter.
Bei der Bereitstellung mehrerer Mandanten wird ein regionaler Ansatz wie folgt empfohlen:
Beginnen Sie, indem Sie Ihre Schüler- und Lehrkräftecommunity nach geografischen Regionen unterteilen, in denen jede Region weniger als 1 Million Benutzer enthält.
Erstellen Sie einen Microsoft Entra Mandanten für jede Region.
Stellen Sie Mitarbeiter, Lehrer und Schüler in ihrer entsprechenden Region bereit, um die Zusammenarbeit zu optimieren.
Gründe für die Verwendung von Regionen
Ein regionaler Ansatz wird empfohlen, um die Anzahl der Benutzer zu minimieren, die mandantenübergreifend verschoben werden. Wenn Sie einen Mandanten für jede Schulstufe (z. B. Grundschulen, Mittelschulen und Weiterführende Schulen) erstellt haben, müssten Sie benutzer am Ende jedes Schuljahres migrieren. Wenn Benutzer stattdessen in derselben Region verbleiben, müssen Sie sie nicht mandantenübergreifend verschieben, wenn sich ihre Attribute ändern.
Weitere Vorteile eines regionalen Ansatzes sind:
Optimale Zusammenarbeit in jeder Region
Minimale Anzahl von Gastobjekten von anderen Mandanten erforderlich
Wenn ein Mandant über mehr als eine Million Benutzer verfügt, werden Verwaltungserfahrungen und -tools im Laufe der Zeit tendenziell beeinträchtigt. Ebenso werden einige Endbenutzererfahrungen wie die Verwendung der Personenauswahl umständlich und unzuverlässig.
Kleinere Organisationen, die sich für die Bereitstellung mehrerer Mandanten ohne zwingenden Grund entscheiden, erhöhen unnötigerweise ihren Verwaltungsaufwand und die Anzahl der Benutzermigrationen. Dies erfordert auch Schritte, um eine mandantenübergreifende Zusammenarbeit sicherzustellen.
Mandantenübergreifende Zusammenarbeit mit Microsoft Entra B2B-Zusammenarbeit
Microsoft Entra B2B-Zusammenarbeit können Benutzer einen Satz von Anmeldeinformationen verwenden, um sich bei mehreren Mandanten anzumelden. Für Bildungseinrichtungen sind die Vorteile der B2B-Zusammenarbeit:
Zentrales Verwaltungsteam, das mehrere Mandanten verwaltet
Regionsübergreifende Zusammenarbeit von Lehrkräften
Onboarding von Eltern und Erziehungsberechtigten mit ihren eigenen Anmeldeinformationen
Externe Partnerschaften wie Auftragnehmer oder Forscher
Bei der B2B-Zusammenarbeit wird ein Benutzerkonto, das in einem Mandanten (dem Basismandanten) erstellt wurde, als Gastbenutzer zu einem anderen Mandanten (einem Ressourcenmandanten) eingeladen, und der Benutzer kann sich mit den Anmeldeinformationen seines Basismandanten anmelden. Administratoren können auch die B2B-Zusammenarbeit verwenden, um externen Benutzern die Anmeldung mit ihren vorhandenen Konten für soziale Netzwerke oder Unternehmen zu ermöglichen, indem sie einen Verbund mit Identitätsanbietern wie Facebook, Microsoft-Konten, Google oder einem Unternehmensidentitätsanbieter einrichten.
Mitglieder und Gäste
Benutzer in einem Microsoft Entra Mandanten sind entweder Mitglieder oder Gäste basierend auf ihrer UserType-Eigenschaft. Standardmäßig sind Mitgliederbenutzer diejenigen, die nativ für den Mandanten sind. Ein Microsoft Entra B2B-Zusammenarbeitsbenutzer wird standardmäßig als Benutzer mit UserType = Guest hinzugefügt. Gäste verfügen über eingeschränkte Berechtigungen für das Verzeichnis und die Anwendungen. Gastbenutzer können beispielsweise informationen aus dem Mandanten nicht über ihre eigenen Profilinformationen hinaus durchsuchen. Ein Gastbenutzer kann jedoch Informationen zu einem anderen Benutzer abrufen, indem er den Benutzerprinzipalnamen (User Principal Name, UPN) oder objectId bereitstellt. Ein Gastbenutzer kann auch Eigenschaften von Gruppen lesen, zu denen er gehört, einschließlich der Gruppenmitgliedschaft, unabhängig von der Einstellung Gastbenutzerberechtigungen sind eingeschränkt .
In einigen Fällen möchte ein Ressourcenmandant Benutzer aus dem Basismandanten als Mitglieder und nicht als Gäste behandeln. Wenn ja, können Sie die Microsoft Entra B2B-Einladungs-Manager-APIs verwenden, um einen Benutzer aus dem Basismandanten als Mitglied zum Ressourcenmandanten hinzuzufügen oder einzuladen. Weitere Informationen finden Sie unter Eigenschaften eines Microsoft Entra B2B-Zusammenarbeitsbenutzers.
Zentrale Verwaltung mehrerer Mandanten
Onboarding externer Identitäten mithilfe von Microsoft Entra B2B. Externe Identitäten können dann privilegierte Rollen zugewiesen werden, um Microsoft Entra Mandanten als Mitglieder eines zentralisierten IT-Teams zu verwalten. Sie können auch Microsoft Entra B2B verwenden, um Gastkonten für andere Mitarbeiter wie Administratoren auf regionaler oder Bezirksebene zu erstellen.
Dienstspezifische Rollen wie Exchange-Administrator oder SharePoint-Administrator erfordern jedoch ein lokales Konto, das für ihren Mandanten nativ ist.
Die folgenden Rollen können B2B-Konten zugewiesen werden:
Anwendungsadministrator
Anwendungsentwickler
Authentifizierungsadministrator
B2C IEF Keyset-Administrator
B2C IEF-Richtlinienadministrator
Cloud Application B2C IEF Policy Administrator
Cloud Device B2C IEF Policy Administrator
Administrator für bedingten Zugriff
Geräteadministratoren
Gerätebeitritt
Gerätebenutzer
Verzeichnisleser
Verzeichnisautoren
Verzeichnissynchronisierungskonten
Benutzerflowadministrator für externe ID
Administrator für externe ID-Benutzerflowattribute
Externer Identitätsanbieter
Gruppenadministrator
Gastladend
Helpdesk-Administrator
Hybrididentitätsadministrator
Intune-Dienstadministrator
Lizenzadministrator
Kennwortadministrator
Privilegierter Authentifizierungsadministrator
Administrator für privilegierte Rollen
Berichteleser
Eingeschränkter Gastbenutzer
Sicherheitsadministrator
Sicherheitsleseberechtigter
Benutzerkontoadministrator
Arbeitsplatzgerätebeitritt
Benutzerdefinierte Administratorrollen in Microsoft Entra ID die zugrunde liegenden Berechtigungen der integrierten Rollen anzeigen, sodass Sie ihre eigenen benutzerdefinierten Rollen erstellen und organisieren können. Mit diesem Ansatz können Sie den Zugriff präziser als integrierte Rollen gewähren, wenn sie benötigt werden.
Hier ist ein Beispiel, das veranschaulicht, wie die Verwaltung für Administratorrollen funktionieren würde, die delegiert und über mehrere Mandanten hinweg verwendet werden können.
Das native Konto von Susie befindet sich im Mandanten region 1, und Microsoft Entra B2B wird verwendet, um das Konto als Authentifizierungsadministrator zum zentralen IT-Team in den Mandanten für Region 2 und Region 3 hinzuzufügen.
Verwenden von Apps über mehrere Mandanten hinweg
Um Probleme im Zusammenhang mit der Verwaltung von Apps in einer mehrinstanzenfähigen Umgebung zu beheben, sollten Sie das Schreiben von mehrinstanzenfähigen Apps in Betracht ziehen. Außerdem müssen Sie überprüfen, welche Ihrer SaaS-Apps mehrere IdP-Verbindungen unterstützt. SaaS-Apps, die mehrere IDP-Verbindungen unterstützen, sollten einzelne Verbindungen für jeden Mandanten konfigurieren. SaaS-Apps, die mehrere IDP-Verbindungen nicht unterstützen, erfordern möglicherweise unabhängige Instanzen. Weitere Informationen finden Sie unter Vorgehensweise: Anmelden eines Microsoft Entra Benutzers mithilfe des mehrinstanzenfähigen Anwendungsmusters.
Hinweis: Lizenzierungsmodelle können je nach SaaS-App variieren. Wenden Sie sich an den Anbieter, um zu ermitteln, ob in einer mehrinstanzenfähigen Umgebung mehrere Abonnements erforderlich sind.
Verwaltung pro Mandant
Für dienstspezifische Rollen ist eine Mandantenverwaltung erforderlich. Dienstspezifische Rollen erfordern ein lokales Konto, das für den Mandanten nativ ist. Zusätzlich zu einem zentralen IT-Team in jedem Mandanten benötigen Sie auch ein regionales IT-Team in jedem Mandanten, um Workloads wie Exchange, SharePoint und Teams zu verwalten.
Für die folgenden Rollen sind native Konten für jeden Mandanten erforderlich.
Azure DevOps-Administrator
Azure Information Protection Administrator
Abrechnungsadministrator
CRM-Dienstadministrator
Complianceadministrator
Compliancedatenadministrator
Genehmigen der Kunden-Lockbox-Zugriffsberechtigung
Desktop Analytics Administrator
Exchange-Administrator
Insights-Administrator
Business Leader für Insights
Kaizala-Administrator
Lync-Dienstadministrator
Nachrichtencenter-Datenschutzleser
Nachrichtencenterleser
Druckeradministrator
Druckertechniker
Suchadministrator
Editor suchen
Sicherheitsoperator
Dienst-Supportadministrator
SharePoint-Administrator
Teams-Kommunikationsadministrator
Supporttechniker für die Teams-Kommunikation
Supportfachmann für die Teams-Kommunikation
Teams-Dienstadministrator
Eindeutige Administratoren in jedem Mandanten
Wenn Sie über ein IT-Team verfügen, das in jeder Region nativ ist, können Sie die Teams-Verwaltung von einem dieser lokalen Administratoren verwalten lassen. Im folgenden Beispiel befindet sich Charles im Mandanten der Region 1 und hat die Rolle Des Teams-Dienstadministrators. Alice und Ichiro befinden sich in den Regionen 2 bzw. 3 und haben die gleiche Rolle in ihren Regionen. Jeder lokale Administrator verfügt über ein einzelnes Konto, das in seiner Region nativ ist.
mandantenübergreifendes Admin von Rollen
Wenn Sie nicht über einen Lokalen Pool von Administratoren in jeder Region verfügen, können Sie die Rolle "Teams-Dienstadministrator" nur einem Benutzer zuweisen. In diesem Szenario können Sie, wie unten dargestellt, Bob vom zentralen IT-Team in allen drei Mandanten als Teams-Dienstadministrator fungieren lassen, indem Sie in jedem Mandanten ein lokales Konto für Bob erstellen.
Delegierung von Administratorrollen innerhalb eines Mandanten
Administrative Einheiten (AUs) sollten verwendet werden, um Microsoft Entra Benutzer und Gruppen logisch zu gruppieren. Das Einschränken des Verwaltungsbereichs mithilfe von Verwaltungseinheiten ist in Bildungsorganisationen nützlich, die aus verschiedenen Regionen, Bezirken oder Schulen bestehen.
Zum Beispiel ist unsere fiktive Schule der Bildenden Künste auf drei Regionen verteilt, die jeweils mehrere Schulen enthalten. Jede Region verfügt über ein Team von IT-Administratoren, die den Zugriff steuern, Benutzer verwalten und Richtlinien für ihre jeweiligen Schulen festlegen.
Ein IT-Administrator könnte beispielsweise:
Erstellen Sie eine AU für benutzer jede der Schulen in Region 1, um alle Benutzer in dieser Schule zu verwalten. (nicht abgebildet)
Erstellen Sie eine AU, die die Lehrer in jeder Schule enthält, um Lehrerkonten zu verwalten.
Erstellen Sie eine separate AU, die die Schüler in jeder Schule enthält, um Schülerkonten zu verwalten.
Weisen Sie Lehrkräften in der Schule die Rolle "Kennwortadministrator" für die Au "Schüler" zu, damit Lehrkräfte Schülerkennwörter zurücksetzen können, aber nicht die Kennwörter anderer Benutzer zurücksetzen können.
Zu den Rollen, die auf Verwaltungseinheiten beschränkt werden können, gehören:
Authentifizierungsadministrator
Gruppenadministrator
Helpdesk-Administrator
Lizenzadministrator
Kennwortadministrator
Benutzeradministrator
Weitere Informationen finden Sie unter Zuweisen von bereichsbezogenen Rollen zu einer Verwaltungseinheit.
Mandantenübergreifende Verwaltung
Einstellungen werden in jedem Mandanten einzeln konfiguriert. Konfigurieren Sie dann nach Möglichkeit als Teil der Mandantenerstellung, um zu minimieren, dass diese Einstellungen erneut verwendet werden müssen. Einige gängige Aufgaben können zwar automatisiert werden, es gibt jedoch kein integriertes mandantenübergreifendes Verwaltungsportal.
Verwalten von Objekten im großen Stil
Mit Microsoft Graph (MS Graph) und Microsoft Graph PowerShell können Sie Verzeichnisobjekte im großen Stil verwalten. Sie können auch zum Verwalten der meisten Richtlinien und Einstellungen in Ihrem Mandanten verwendet werden. Sie sollten jedoch die folgenden Leistungsüberlegungen verstehen:
MS Graph beschränkt die Erstellung von Benutzer-, Gruppen- und Mitgliedschaftsänderungen auf 72.000 pro Mandant und Stunde.
Die Leistung von MS Graph kann durch benutzergesteuerte Aktionen wie Lese- oder Schreibaktionen innerhalb des Mandanten beeinträchtigt werden.
Die Leistung von MS Graph kann durch andere konkurrierende IT-Administratoraufgaben innerhalb des Mandanten beeinträchtigt werden.
PowerShell, SDS, Microsoft Entra Connect und benutzerdefinierte Bereitstellungslösungen fügen Objekte und Mitgliedschaften über MS Graph mit unterschiedlichen Raten hinzu.
Nächste Schritte
Wenn Sie die Einführung in Microsoft Entra Mandanten noch nicht gelesen haben, können Sie dies tun. Lesen Sie dann: