Zero Trust-Konfiguration für mehrinstanzenfähige Verteidigungsorganisationen
Dieser Artikel zeigt mehrinstanzenfähigen Organisationen, wie sie Konfigurationen in Microsoft Entra ID anwenden und allgemeine Zero Trust-Anforderungen für die Verteidigung erfüllen. Befolgen Sie diese Empfehlungen, um die richtige mehrinstanzenfähige Identitätsarchitektur einzurichten und Zero Trust in Ihrer Umgebung zu implementieren.
Abbildung 1: Beispiel einer mehrinstanzenfähigen Verteidigungsarchitektur mit Zero Trust-Konfigurationen.
Bestimmen der Identitätsarchitektur
Microsoft Entra ID-Mandanten sind die Grundlage Ihrer Identitätsarchitektur. Ein Mandant ist eine Identitätsgrenze in Microsoft Entra ID. Eine Organisation mit einem Microsoft Entra-Mandanten verfügt über eine Einzelmandantenarchitektur. Organisationen, die mehr als einen Microsoft Entra-Mandanten verwenden, verfügen über eine mehrinstanzenfähige Architektur.
Nutzen eines einzelnen Mandanten. Ein einzelner Mandant ist einfacher zu verwalten und senkt die Kosten durch betriebliche Effizienz. So können Sie eine Zero Trust-Umgebung einfacher konfigurieren. Ein einzelner Mandant vermeidet die Fragmentierung der Benutzerfreundlichkeit durch mehrere Anmeldeinformationen. Außerdem hilft er dabei, isolierte Lösungen zu verhindern, die Sie später integrieren müssen. Sie sollten bestrebt sein, Ihre Daten, Microsoft 365 und Azure-Clouddienste in einem einzigen Mandanten zu haben. Wenn Sie bereits über mehrere Microsoft Entra-Mandanten verfügen, sollten Sie erwägen, Ihre Umgebung zu konsolidieren, um einen einzelnen Mandanten zu verwenden. Sie können Mandanten konsolidieren, indem Sie Azure-Abonnements von Ihren sekundären Mandanten auf den primären Mandanten übertragen. Weitere Informationen finden Sie unter Übertragen eines Azure-Abonnements in ein anderes Microsoft Entra-Verzeichnis.
Anwendungsfälle mit mehreren Mandanten. Es gibt Gründe, warum Verteidigungsorganisationen eine mehrinstanzenfähige Architektur verwenden sollten. Große und komplexe Verteidigungsorganisationen benötigen möglicherweise mehrere Microsoft Entra-Mandanten für Sicherheit, Compliance und Kollaboration (siehe Tabelle 1).
Tabelle 1. Gründe für das Verwenden oder Erstellen mehrerer Mandanten.
| `Reason` | Beispiel |
|---|---|
| Datenschutz oder Sicherheit erfordert eine tiefere Trennung der Daten | Eine OIG (Office of Inspector General)-Organisation benötigt Unabhängigkeit. |
| Delegierung und Segmentierung der Verwaltung | Eine Organisation hat nicht die Fähigkeit, eine andere Organisation zu verwalten. |
| Datenhoheit und/oder Dateneigentum | Eine Organisation hat nicht die rechtliche Befugnis, die Daten einer anderen Organisation zu verwalten. |
| Netzwerk und IT-Organisation | Es ist weder möglich noch vorteilhaft, mehrere IT-Architekturen großer Unternehmen in einer einzelnen Unternehmensarchitektur zusammenzufassen. |
| SOC-Überwachung und Reaktion auf Vorfälle | Das SOC benötigt einen separaten Mandanten, um seine Rollen und Zuständigkeiten zu verwalten. |
Wenn Sie mehrere Microsoft Entra-Mandanten benötigen, sollten Sie externe Microsoft Entra External ID-Identitäten (B2B) und Azure Lighthouse verwenden. Diese Features unterstützen mehrinstanzenfähige Verteidigungsorganisationen. Weitere Informationen finden Sie unter Mandantenmodelle für eine mehrinstanzenfähige Lösung.
Identifizieren von Mandantentypen
Mehrinstanzenfähige Verteidigungsorganisationen können Microsoft Entra-Instanzen kategorisieren, die sie entweder als primäre oder sekundäre Instanzen verwenden. Jede Organisation sollte einen Mandanten als primären Mandanten identifizieren und festlegen. Alle anderen Mandanten sind sekundär. Abbildung 1 zeigt eine Verteidigungsorganisation mit einem primären Mandanten und n sekundären Mandanten (zwei sekundäre Mandanten werden dargestellt).
Identifizieren Sie den primären Mandanten. Die meisten Verteidigungsorganisationen erstellen den primären Mandanten, wenn sie sich für Microsoft 365 registrieren. Der primäre Mandant enthält (1) alle Benutzeridentitäten und Microsoft 365-Lizenzen, (2) Geräte und (3) Anwendungen (siehe Abbildung 1). Verteidigungsorganisationen verwenden häufig Microsoft Entra Connect, um die Identitäten aus der lokalen Active Directory-Instanz mit dem primären Microsoft Entra-Mandanten zu synchronisieren.
Einige Verteidigungsorganisationen nutzen Microsoft 365 in einem gemeinsamen Mandanten, der sich im Besitz einer externen Agentur befindet und von dieser betrieben wird. Diese Agentur fungiert als Shared Service Provider für Microsoft 365. Ihre Organisation verwaltet oder steuert den freigegebenen Mandanten zwar nicht, er enthält aber die lizenzierten Microsoft Entra-Identitäten, die Benutzer*innen wahrscheinlich für Office 365 und andere Anwendungen verwenden. In diesem Szenario ist der Shared Service Provider-Mandant Ihr primärer Mandant.
Identifizieren Sie alle sekundären Mandanten (wenn mehrinstanzenfähig). Alle anderen Mandanten, die von der Organisation verwaltet werden, sind sekundäre Mandanten. Möglicherweise verfügen Sie über sekundäre Mandanten, wenn Sie Anwendungen in die Cloud migriert haben, bevor Sie eine Azure-Zielzone auf Unternehmensebene einrichten. Sie verwenden in der Regel sekundäre Mandanten, um (4) Azure-Workloads mit externen Benutzern (B2B-Gäste) oder (5) rein Cloudkonten zu verwalten (siehe Abbildung 1).
Verwenden Sie die Entscheidungsstruktur. Die einfachste Möglichkeit, Ihren primären Mandanten zu finden, ist die Betrachtung der Identitätslizenzen, die Sie in Microsoft Entra ID haben.
Der Mandant mit Ihren Microsoft 365-Lizenzen ist Ihr primärer Mandant (siehe Abbildung 2). Der primäre Mandant ist möglicherweise nicht der erste Mandant, der von Ihrer Organisation erstellt wurde, sondern der Standard Mandant mit allen Ihren Benutzern und Microsoft 365-Lizenzen sein sollte.
Wenn Ihre Organisation Microsoft 365 nicht verwendet, ist jeder Microsoft Entra-Mandant mit EMS-Lizenzen (Enterprise Mobility and Security) Ihr primärer Mandant. In diesem Mandanten haben Sie den Domänennamen Ihrer Organisation hinzugefügt und überprüft. Der Mandant verwendet häufig hybride Identitäten oder ist in ein HR-System integriert (siehe Abbildung 2).
Abbildung 2. Eine Entscheidungsstruktur zum Bestimmen des primären und sekundären Microsoft Entra-Mandanten.
Um Microsoft Entra ID als Zero Trust-Plattform einzurichten, benötigen Sie einen Mandanten, der mit Ihren Benutzeridentitäten befüllt und für benutzer- und gerätebasierte Zugriffsrichtlinien lizenziert ist. Die Microsoft 365-Lizenzierung bündelt diese Zero Trust-Funktionen mit Office 365. Wenn Sie nicht Microsoft 365 verwenden, sollten Sie Enterprise Mobility + Security E5 in Betracht ziehen, um einen cloudbasierten Identitätsanbieter für Zero Trust einzurichten. Weitere Informationen finden Sie unter Auswählen Ihrer Identitätsautorität.
Konfigurieren von Zero Trust
Beim Verwalten von Identitäten in Microsoft Entra ID sollten Sie die folgenden Empfehlungen für jeden Mandantentyp berücksichtigen. Es gibt allgemeine Empfehlungen für alle Mandantentypen, die Sie als erstes übernehmen sollten. Nachdem Sie diese allgemeinen Empfehlungen implementiert haben, suchen Sie die Empfehlungen für Ihren spezifischen Mandantentyp (primär oder sekundär) und wenden dann diese Empfehlungen an.
Weitere Informationen zum Sichern von Microsoft Entra-Mandanten mit Zero Trust finden Sie unter Zero Trust Rapid Modernization Plan und Security Rapid Modernization Plan.
Alle Mandanten
Sie sollten die folgenden Empfehlungen in allen Microsoft Entra-Mandanten implementieren.
Richten Sie Konten und Prozeduren für den Notfallzugriff ein. Erstellen Sie zwei oder mehr Notfallzugriffskonten, um zu vermeiden, dass Sie aus Ihrem Microsoft Entra-Mandanten ausgesperrt werden. Diesen Konten müssen Sie die Rolle „Globaler Administrator“ zuweisen. Bei den Konten sollte es sich um reine Cloudkonten handeln. Reine Cloudkonten verwenden die Domäne *.onmicrosoft.com . Weitere Informationen finden Sie unter Verwalten von Administratorkonten für den Notfallzugriff.
Wichtig
Microsoft empfiehlt, Rollen mit den geringsten Berechtigungen zu verwenden. Dies trägt zur Verbesserung der Sicherheit Ihrer Organisation bei. „Globaler Administrator“ ist eine Rolle mit umfangreichen Berechtigungen, die auf Notfallszenarios beschränkt sein sollte, in denen Sie keine vorhandene Rolle verwenden können.
Schützen von Microsoft Entra ID vor lokalen Angriffen Befolgen Sie bewährte Methoden, die unter Sichern des privilegierten Zugriffs beschrieben sind. Weisen Sie Microsoft Entra-Berechtigungen nur cloudbasierten Benutzerkonten mit gegen Phishing resistenten Anmeldeinformationen zu, wie Hardwarehauptschlüssel oder zertifikatbasierte Authentifizierung. Verwenden Sie keine Verbundidentitäten für Verwaltungszwecke. Weitere Informationen hierzu finden Sie unter Schützen von Microsoft 365 vor lokalen Angriffen.
Verwenden Sie Privileged Identity Management. Verwenden Sie Microsoft Entra Privileged Identity Management (PIM), um Rollenzuweisungen für Microsoft Entra ID- und Azure-Rollen zu verwalten. Außerdem sollten Sie PIM verwenden, um die berechtigte Gruppenmitgliedschaft für privilegierte Sicherheitsgruppen zu verwalten. Richten Sie regelmäßige Zugriffsüberprüfungen für berechtigte Administratoren und externe Benutzer (B2B-Gäste) ein.
Aktivieren Sie die cloudbasierte Authentifizierung für alle Benutzer. Cloudbasierte Authentifizierungsmethoden sind sicherer als die Verbundauthentifizierung. Sie bieten bessere SSO-Funktionen in Kombination mit in Microsoft Entra eingebundenen Geräten. Die Verbundauthentifizierung macht Microsoft Entra ID anfällig für lokale Active Directory-Kompromittierungen.
Durch die zertifikatbasierte Authentifizierung in Microsoft Entra ist es hinfällig, einen Verbund von Microsoft Entra-Domänen herzustellen. Die Microsoft Entra-Authentifizierung unterstützt die folgenden kennwortlosen Authentifizierungsmethoden:
- Sicherheitsschlüssel (FIDO2/Hauptschlüssel)
- Zertifikatbasierte Authentifizierung
- Microsoft Authenticator
- Windows Hello for Business
Richten Sie grundlegender Richtlinien für den bedingten Zugriff ein. Die Baseline für bedingten Zugriff variiert je nach Organisation und Anforderungen. Erstellen Sie einen Kernsatz von Richtlinien für bedingten Zugriff für alle Microsoft Entra-Mandanten. Verwenden Sie Identitäts-, Geräte-, Anwendungs- und Risikobedingungen in Ihrem Richtliniensatz. Schließen Sie Konten für den Notfallzugriff aus Ihren Richtlinien für bedingten Zugriff aus.
Microsoft Entra ID Protection unterstützt Organisationen dabei, identitätsbasierte Risiken zu erkennen, zu untersuchen und zu beseitigen. Um Risikoanmeldungen und Benutzer zu schützen, erstellen Sie Richtlinien für bedingten Zugriff mit Risikobedingungen. Verwenden Sie separate Richtlinien für Risikobenutzer und Risikoanmeldungen. Erhöhen Sie angewendete Steuerelemente mit Risikostufe für jeden Risikotyp. Um die Produktivität der Benutzer mit Sicherheit auszugleichen, vermeiden Sie die Verwendung des Block-Steuerelements in risikobasierten Richtlinien.
Hinweis
Benutzer können Anmelderisiken mit MFA selbst beheben. Um Benutzern zu ermöglichen, Anmelderisiken selbst zu beheben, konfigurieren Sie das Berechtigungssteuerelement für die MFA- oder Authentifizierungsstärke in einer auf Anmelderisiken basierenden Richtlinie für bedingten Zugriff.
Benutzer können Benutzerrisiken selbst beheben, indem sie ihre Kennwörter ändern. Um Benutzern zu ermöglichen, Benutzerrisiken selbst zu beheben, konfigurieren Sie eine auf Benutzerrisiken basierende Richtlinie für bedingten Zugriff mit dem Berechtigungssteuerelement Kennwortänderung erforderlich".
Achtung
Kennwortlose Benutzer, die sich nur mit kennwortlosen Methoden wie der auf Entra-Zertifikaten basierenden Authentifizierung, Passkey oder Windows Hello for Business anmelden, könnten durch das Berechtigungssteuerelement Kennwortänderung erforderlich blockiert werden, wenn sie ihr Kennwort nicht in Microsoft Entra- D zurücksetzen können.
Entwerfen Sie Richtlinien für den bedingten Zugriff für Ihre Organisation mithilfe der Prüfliste für die Richtlinie für bedingten Zugriff (siehe Tabelle 2). Verwenden Sie Modus „Nur melden“, um Richtlinien für bedingten Zugriff zu testen, bevor Sie sie in der Produktion bereitstellen.
Tabelle 2: Beispiel-Checkliste für Richtlinien für bedingten Zugriff.
| Richtlinienname | Benutzer | Anwendungen | Bedingungen | Zuweisungssteuerelement |
|---|---|---|---|---|
| MFA für alle Benutzer | Allen Benutzern | Alle Apps | Keine | - Phishing-sichere MFA |
| Vorschreiben der Verwendung verwalteter Geräte | Allen Benutzern | Alle Apps | None | - Anfordern eines hybrid in Microsoft Entra eingebundenen oder kompatiblen Geräts |
| Schützen von Anmeldungen mit mittlerem Risiko | Allen Benutzern | Alle Apps | Mittleres Anmelderisiko | - Phishing-sichere MFA - Erzwingen eines kompatiblen Geräts - Anmeldehäufigkeit: 1 Stunde (entsprechend der Risikotoleranz Ihrer Organisation anpassen) |
| Schützen von Anmeldungen mit hohem Risiko | Allen Benutzern | Alle Apps | Hohes Anmelderisiko | - Phishing-sichere MFA - Erzwingen eines kompatiblen Geräts - Anmeldehäufigkeit: Jedes Mal |
| Schützen von Benutzern mit hohem Risiko | Allen Benutzern | Alle Apps | Benutzer mit hohem Risiko | - Phishing-sichere MFA - Erzwingen eines kompatiblen Geräts - Anmeldehäufigkeit: Jedes Mal |
| Sichern der Microsoft Entra-Verwaltung | Microsoft Entra-Rollen | Alle Apps | Keine | - Phishing-sichere MFA - Erfordern einer kompatiblen Arbeitsstation mit privilegiertem Zugriff (Privileged Access Workstation, PAW) mithilfe von Gerätefiltern |
| Sichere Cloudverwaltung | Allen Benutzern | Azure-Verwaltung Google Cloud Platform Amazon Web Services |
Keine | - Phishing-sichere MFA - Erfordern einer kompatiblen Arbeitsstation mit privilegiertem Zugriff (Privileged Access Workstation, PAW) mithilfe von Gerätefiltern |
Die in Tabelle 2 festgelegte Beispielrichtlinie richtet sich an kennwortlose Organisationen, bei denen alle Benutzer nur Phishing-sichere MFA von verwalteten Geräten verwenden. Privilegierte Benutzer verwenden in Intune verwaltete Privileged Access Workstations (PAW). Anstatt eine Kennwortänderung für Benutzer mit hohem Risiko zu erfordern, erzwingt die Richtlinie für Risikobenutzer die Steuerelemente für die Authentifizierungsstärke und die Anmeldehäufigkeit. Diese Steuerelemente bieten einige Schutzmaßnahmen, beheben jedoch nicht das Risikoniveau des Benutzers in Microsoft Entra ID Protection. Ihr Sicherheitsteam sollte Benutzer mit hohem Risiko untersuchen und korrigieren.
Mehr Informationen zur Bereitstellung von bedingtem Zugriff finden Sie unter Planen einer Bereitstellung für bedingten Zugriff.
Verwenden Sie primäre Mandantenidentitäten für den Zugriff auf alle Anwendungen. Benutzer sollten über ihre Identität im primären Mandanten auf Anwendungen zugreifen können. Sie müssen Anwendungen im primären Mandanten registrieren. Richten Sie eine Richtlinie zum Registrieren von Anwendungen beim primären Mandanten ein, unabhängig vom Hostingstandort der Anwendungsinfrastruktur.
Verwenden Sie für Legacy-Anwendungen, die keine modernen Authentifizierungsprotokolle unterstützen, den Dienst Microsoft Entra-Anwendungsproxy im primären Mandanten. Der Microsoft Entra-Anwendungsproxy stellt Zero Trust-Features von Microsoft Entra ohne Codeänderungen in vorhandenen Legacy-Anwendungen bereit.
Wenn ein Shared Service Provider oder eine externe Agentur Ihren primären Mandanten kontrolliert, sollten sie die Anwendungsregistrierungsberechtigungen delegieren. Wenn der Service Provider diese Delegierung nicht anbietet, müssen Sie Anwendungen beim sekundären Mandanten registrieren, den Ihre Organisation stattdessen verwaltet. Benutzer sollten jedoch weiterhin auf diese Anwendungen zugreifen, ohne eine neue Identität im sekundären Mandanten zu erstellen. Weisen Sie für diesen Setup Ihren Benutzern im primären Mandanten den Benutzerzugriff mithilfe externer Identitäten (B2B-Gäste) zu. Weitere Informationen finden Sie unter Sichere Anwendungen mit Zero Trust.
Verwenden Sie Microsoft Entra ID, um andere Cloudumgebungen zu verwalten. Microsoft Entra ID ist nicht nur eine Identitätsplattform für Azure und Microsoft 365. Verwenden Sie Microsoft Entra ID, um Zugriff auf andere Cloudumgebungen zu erhalten. Zu diesen Umgebungen gehören beliebte SaaS (Software-as-a-Service)-Produkte und Cloudplattformen wie Amazon Web Services (AWS) und Google Cloud Platform (GCP). Weitere Informationen finden Sie unter Microsoft Entra-Anwendungskatalog.
Verwenden einer sicheren Cloud Computing-Architektur (SCCA). Jede Verteidigungsorganisation sollte eine SCCA-konforme Zielzonenarchitektur bereitstellen. Die Zielzone sollte sich in Azure-Abonnements befinden, die an den primären Mandanten angefügt sind.
Segmentieren Sie die Azure-Ressourcenverwaltung in einem einzelnen Mandanten. Sie sollten Azure Rollen für die Ressourcen und die Verwaltung von Isolation für Abonnements in einem Unternehmensbereich nutzen, Azure-Zielzone. Erwägen Sie die Übertragung von Abonnements von sekundären Mandanten auf den primären Mandanten.
Verwenden Sie Microsoft Entra Permissions Management. Microsoft Entra Permissions Management ist die CIEM-Lösung (Cloud Infrastructure Entitlement Management) von Microsoft. Sie sollten Microsoft Entra Permissions Management verwenden, um Einblicke in Berechtigungen zu erhalten, die allen Identitäten zugewiesen sind. Sie sollten es auch verwenden, um die schleichende Berechtigungsausweitung in der Multicloudumgebung Ihrer Organisation nachzuverfolgen.
Verwenden Sie Microsoft Entra ID Governance. Verwenden Sie Microsoft Entra ID Governance, um den Lebenszyklus der Zugriffszuweisung für Benutzer*innen und Gäste zu automatisieren. Führen Sie Zugriffsüberprüfungen durch, um den Zugriff auf Ihre Cloudumgebung Benutzern zu entfernen, die sie nicht mehr benötigen.
Schützen Sie Workloadidentitäten. Verwenden Sie das Feature Microsoft Entra Workload ID, um adaptive Zero Trust-Richtlinien für Anwendungsidentitäten (Dienstprinzipale) in Microsoft Entra ID zu verwalten und anzuwenden.
Aktivieren Sie Defender for Cloud für Ihr Unternehmen. Verwenden Sie Microsoft Defender for Cloud für Ihre Multicloudumgebung. Stellen Sie sicher, dass Sie die erweiterten Sicherheitsfeatures aktivieren, um Azure-Ressourcen zu überwachen und Konfigurationsrisiken zu beheben. Der Defender for Cloud-Schutz erstreckt sich über Azure hinaus, um Sie bei der Sicherung von Hybrid- und Multicloudumgebungen zu unterstützen.
Stellen Sie Sentinel bereit, und verbinden Sie alle verfügbaren Datenquellen. Aggregieren Sie Sicherheitstelemetriedaten in einem SIEM wie Microsoft Sentinel. Stellen Sie Sentinel bereit, und verbinden Sie alle Sicherheitssignaldatenquellen, indem Sie Datenconnectors konfigurieren.
Primäre Mandanten
Sie sollten die folgenden Empfehlungen nur im primären Mandanten implementieren.
Endbenutzer*innen verfügen nur über eine Identität in Azure AD. Synchronisieren Sie lokale Active Directory Domain Services mit dem primären Microsoft Entra-Mandanten. Die Synchronisierung füllt Microsoft Entra ID mit Benutzern, Gruppen und Geräten für die Organisation auf. Externe B2B-Gäste sind möglicherweise in sekundären Mandanten vorhanden, aber Benutzer müssen sich nur einen Benutzernamen für alle Anwendungen und Dienste merken. Die Benutzerfreundlichkeit und Zero Trust-Ergebnisse sind am besten, wenn Sie die Identitäten im primären Mandanten für die Windows-Anmeldung und den Anwendungszugriff verwenden.
Verbinden und verwalten Sie Geräte mit dem primären Mandanten. Der primäre Microsoft Entra-Mandant enthält alle Benutzer und Geräte innerhalb der Organisation. Binden Sie Windows-Geräte mit Microsoft Entra-Join (oder Microsoft Entra Hybrid Join) in den primären Mandanten ein, und verwalten Sie diese mit Microsoft Intune. Verwenden Sie die Intune-Richtlinie, um Microsoft Defender for Endpoint bereitzustellen, um die XDR (Extended Detection and Response)-Funktion zu aktivieren.
Delegieren Sie Anwendungsregistrierungsberechtigungen. Enterprise-Apps, einschließlich des Anwendungscode, der in einem beliebigen Azure-Abonnement ausgeführt wird, verwenden den primären Microsoft Entra ID-Mandanten für die Benutzeridentität. Ermöglichen Sie Entwicklern die Berechtigung für die Microsoft Entra-Rolle „Anwendungsentwickler“ oder eine benutzerdefinierte App-Registrierungsrolle mithilfe von Privileged Identity Management. Mit dieser Konfiguration können Entwickler, die Anwendungen in sekundären Mandanten erstellen, diese beim primären Mandanten für die Identität registrieren.
Fügen Sie PaaS (Platform-as-a-Service)-Dienste an, die eine Endbenutzeridentität benötigen. Einige PaaS-Dienste wie Azure Files und Azure Virtual Desktop hängen von hybriden Identitätskonfigurationen oder Lizenzberechtigungen ab. Sie müssen diese Dienste für Azure-Abonnements im primären Mandanten bereitstellen.
Sekundäre Mandanten
Sie sollten die folgenden Empfehlungen im sekundären Mandanten implementieren.
Erwerben sie Lizenzen, die für die Microsoft Entra-Verwaltung erforderlich sind. Sie benötigen Lizenzen, um erweiterte Sicherheitsfeatures in sekundären Mandanten zu aktivieren. Berücksichtigen Sie die Lizenzen, die Sie für Benutzer, Workloads und Geräte benötigen.
Benutzeridentitäten. Sie benötigen Microsoft Entra ID Premium P2-Lizenzen für Mandantenadministratoren und Notfallzugriffskonten. Wenn Sie ein Verwaltungsmodell für eine externe Identität (B2B-Gast) verwenden, müssen Sie einem lokalen Benutzer im Mandanten mindestens eine Microsoft Entra ID Premium P2-Lizenz zuweisen. Mit diesem Setup können Sie Premium-Features wie bedingten Zugriff und Identitätsschutz aktivieren. Weitere Informationen finden Sie unter Allgemeine Überlegungen zur mehrinstanzenfähigen Benutzerverwaltung.
Workloadidentitäten. Sie sollten Premium-Workloadidentitäten verwenden, um Workloadidentitäten mit Zugriff auf Ressourcen im primären Mandanten zu schützen, z. B. MS Graph-API.
Geräteverwaltung Möglicherweise müssen Sie Geräte mit Microsoft Intune im sekundären Mandanten verwalten. Wenn ja, müssen Sie Enterprise Mobility + Security (EMS)-Lizenzen erwerben.
Konfigurieren Sie mandantenübergreifender Zugriffsrichtlinien (Cross-Tenant Access Policies, XTAP). Mit den Einstellungen für mandantenübergreifenden Zugriff für Microsoft Entra External ID (Microsoft Entra B2B) kann ein sekundärer Mandant bestimmten Ansprüchen des primären Basismandanten vertrauen. Fügen Sie den primären Microsoft Entra-Mandanten als Organisation hinzu, und erweitern Sie die eingehenden Vertrauensstellungen um Folgendes:
- Multi-Faktor-Authentifizierung (MFA) von Microsoft Entra-Mandanten vertrauen
- Konformen Geräten vertrauen
- In Microsoft Entra eingebundenen Hybridgeräten vertrauen
- Optional: Automatisches Einlösen von Einladungen mit dem Mandanten.
Verwalten Sie den sekundären Mandanten mit Identitäten aus dem primären Mandanten. Reduzieren Sie den Verwaltungsaufwand und die Kosten, indem Sie externe Benutzer (B2B-Gäste) aus dem primären Mandanten verwenden, um den sekundären Mandanten und Azure-Ressourcen zu verwalten. Weisen Sie Microsoft Entra-Rollen gemäß Microsoft Entra-Rolle mit den geringsten Rechten nach Aufgabe mithilfe von Microsoft Entra Privileged Identity Management zu. Verwenden Sie vom Endbenutzer initiierten Zugriff oder die mandantenübergreifende Synchronisierung, um den Verwaltungsaufwand beim Onboarding externer Identitäten im sekundären Mandanten zu reduzieren.
Verwenden Sie Azure Lighthouse, um den Sentinel-Zugriff vom primären Mandanten zu erleichtern. Azure Lighthouse bietet Ihnen eine weitere Möglichkeit, Azure mandantenübergreifend zu verwalten. Azure Lighthouse verwendet Azure Resource Manager (ARM)-Vorlagen, um Identitäten in einem externen Mandanten Azure-Rollen zuzuweisen. Bei diesem Ansatz werden keine B2B-Gastbenutzerobjekte verwendet. Wenn sich ein Administrator beim Portal anmeldet, um Azure zu verwalten, werden alle Ressourcen in allen Mandanten angezeigt. Diese konsolidierte Ansicht enthält Abonnements mit Berechtigungen, die von Azure Lighthouse zugewiesen wurden. Da kein B2B-Gastobjekt vorhanden ist, muss der Administrator keine Verzeichnisse wechseln. Verwenden Sie Azure Lighthouse, um die Verwaltung von Microsoft Sentinel über Mandanten hinweg zu vereinfachen.