Hybridmessaginginfrastruktur mit verbesserter Sicherheit (Webzugriff)

Microsoft Entra ID
Microsoft 365
Office 365

Die in diesem Artikel vorgestellte Lösung ermöglicht Szenarios zum Schutz Ihres Messagingdiensts (Outlook Web App oder Exchange-Systemsteuerung), wenn Postfächer in Exchange Online oder lokalen Exchange-Instanzen gehostet werden.

Aufbau

In dieser Architektur werden die Sicherheitsverfahren der Lösung in zwei Bereiche aufgeteilt:

  • Exchange Online auf der rechten Seite des Diagramms
  • Lokale Exchange-Instanz in einem hybriden oder nicht hybriden Szenario auf der linken Seite des Diagramms

Screenshot, der eine Architektur für verbesserte Sicherheit in einem Webzugriffsszenario zeigt.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Allgemeine Hinweise

  • Diese Architektur verwendet das Verbundidentitätsmodell von Microsoft Entra. Die Logik und der Ablauf für die Kennwort-Hashsynchronisierung und die Passthrough-Authentifizierung sind identisch. Der einzige Unterschied besteht darin, dass Microsoft Entra ID die Authentifizierungsanforderung nicht an lokale Active Directory-Verbunddienste (Active Directory Federation Services, AD FS) umleitet.
  • Das Diagramm veranschaulicht den Zugriff auf Outlook über den Webdienst, der einem auf .../owa endenden Pfad entspricht. Für den Benutzerzugriff über das Exchange Admin Center (oder die Exchange-Systemsteuerung), der einem auf .../ecp endenden Pfad entspricht, gilt der gleiche Ablauf.
  • In den Diagrammen stehen gestrichelte Linien für Standardinteraktionen zwischen dem lokalen Active Directory, Microsoft Entra Connect, Microsoft Entra ID, Active Directory-Verbunddienste (AD FS) und Webanwendungsproxy-Komponenten. Weitere Informationen zu diesen Interaktionen finden Sie unter Erforderliche Ports und Protokolle für Hybrididentitäten.
  • Mit lokale Exchange-Instanz ist Exchange 2019 mit den neuesten Updates und der Rolle „Postfach“ gemeint. Mit lokale Exchange Edge-Instanz ist Exchange 2019 mit den neuesten Updates und der Rolle „Edgetransport“ gemeint. Der Edgeserver ist im Diagramm enthalten, um zu betonen, dass Sie ihn in diesen Szenarios verwenden können. Er wird nicht für die Arbeit mit den hier erläuterten Clientprotokollen verwendet.
  • In einer realen Umgebung ist nicht nur ein Server vorhanden. Sie besitzen eine Reihe von Exchange-Servern mit Lastenausgleich, um Hochverfügbarkeit zu gewährleisten. Die hier beschriebenen Szenarios eignen sich für diese Konfiguration.

Benutzerablauf für Exchange Online

  1. Ein*e Benutzer*in versucht, über https://outlook.office.com/owa auf den Outlook-Webdienst zuzugreifen.

  2. Exchange Online leitet die Benutzer*innen zur Authentifizierung an Microsoft Entra ID um.

    Wenn es sich um eine Verbunddomäne handelt, leitet Microsoft Entra ID die Benutzer*innen zur Authentifizierung an die lokale AD FS-Instanz um. Wenn die Authentifizierung erfolgreich ist, werden die Benutzer*innen zurück an Microsoft Entra ID umgeleitet. (Dieses Verbundszenario wurde für die Übersichtlichkeit des Diagramms weggelassen.)

  3. Microsoft Entra ID erzwingt die Multi-Faktor-Authentifizierung, indem eine Azure-Richtlinie für bedingten Zugriff mit einer MFA-Anforderung für die Browserclientanwendung angewendet wird. Im Abschnitt Bereitstellung dieses Artikels finden Sie weitere Informationen zur Einrichtung einer solchen Richtlinie.

  4. Die Richtlinie für bedingten Zugriff ruft die Microsoft Entra-Multi-Faktor-Authentifizierung auf. Die Benutzer*innen werden zur Multi-Faktor-Authentifizierung aufgefordert.

  5. Die Benutzer*innen schließen die Multi-Faktor-Authentifizierung ab.

  6. Microsoft Entra ID leitet die authentifizierte Websitzung an Exchange Online um, und die Benutzer*innen können auf Outlook zugreifen.

Benutzerablauf für lokale Exchange-Instanzen

  1. Ein*e Benutzer*in versucht, über die URL https://mail.contoso.com/owa auf den Outlook-Webdienst zuzugreifen. Die URL verweist auf einen Exchange-Server für den internen Zugriff oder auf einen Webanwendungsproxy-Server für den externen Zugriff.

  2. Der lokale Exchange-Server (interner Zugriff) oder der Webanwendungsproxy-Server (externer Zugriff) leitet den oder die Benutzer*in zur Authentifizierung an AD FS um.

  3. AD FS verwendet die Integrierte Windows-Authentifizierung für den internen Zugriff oder stellt für den externen Zugriff ein Webformular bereit, über das der oder die Benutzer*in Anmeldeinformationen eingeben kann.

  4. Als Reaktion auf eine AF DS-Zugriffssteuerungsrichtlinie ruft AD FS die Microsoft Entra-Multi-Faktor-Authentifizierung auf, um die Authentifizierung abzuschließen. Hier sehen Sie ein Beispiel für eine solche AD FS-Zugriffssteuerungsrichtlinie:

    Screenshot: Beispiel für eine AD FS-Zugriffssteuerungsrichtlinie

    Die Benutzer*innen werden zur Multi-Faktor-Authentifizierung aufgefordert.

  5. Die Benutzer*innen schließen die Multi-Faktor-Authentifizierung ab. AD FS leitet die authentifizierte Websitzung an die lokale Exchange-Instanz um.

  6. Der oder die Benutzer*in kann auf Outlook zugreifen.

Zur Umsetzung dieses Szenarios für lokale Benutzer*innen müssen Sie zusätzliche Konfigurationen in Exchange und AD FS vornehmen, damit AD FS für die Vorauthentifizierung bei Anforderungen für den Webzugriff verwendet wird. Weitere Informationen finden Sie unter Verwenden der anspruchsbasierten AD FS-Authentifizierung mit Outlook Web App.

Sie müssen auch die Integration von AD FS und Microsoft Entra-Multi-Faktor-Authentifizierung aktivieren. Weitere Informationen finden Sie unter Konfigurieren von Azure AD MFA als Authentifizierungsanbieter bei AD FS. (Für diese Integration ist AD FS 2016 oder 2019 erforderlich.) Zum Schluss müssen Sie die Benutzer*innen mit Microsoft Entra ID synchronisieren ihnen Lizenzen für die Microsoft Entra-Multi-Faktor-Authentifizierung zuweisen.

Komponenten

  • Microsoft Entra ID. Microsoft Entra ID ist ein cloudbasierter Identitäts- und Zugriffsverwaltungsdienst von Microsoft. Er ermöglicht eine moderne Authentifizierung, die auf EvoSTS basiert (einem von Microsoft Entra ID verwendeten Sicherheitstokendienst). Er wird als Authentifizierungsserver für lokale Exchange Server-Instanzen verwendet.

  • Microsoft Entra-Multi-Faktor-Authentifizierung. Die Multi-Faktor-Authentifizierung ist ein Prozess, bei dem Benutzer*innen während des Anmeldevorgangs zur Durchführung eines weiteren Identifizierungsverfahrens aufgefordert werden, z. B. per Eingabe eines Codes auf dem Smartphone oder per Fingerabdruckscan.

  • Bedingter Microsoft Entra-Zugriff. Der bedingte Zugriff ist ein Feature, mit dem Microsoft Entra ID Organisationsrichtlinien wie die Multi-Faktor-Authentifizierung erzwingt.

  • AD FS: AD FS ermöglicht die Identitäts- und Zugriffsverwaltung im Verbund, indem digitale Identitäten und Berechtigungen auch jenseits von Sicherheits- und Unternehmensgrenzen mit verbesserter Sicherheit geteilt werden. In dieser Architektur wird der Dienst eingesetzt, um die Anmeldung von Benutzer*innen mit Verbundidentitäten zu vereinfachen.

  • Webanwendungsproxy: Der Webanwendungsproxy authentifiziert den Zugriff auf Webanwendungen vorab mit AD FS. Sie fungiert auch als AD FS-Proxy.

  • Exchange Server: Exchange Server hostet lokale Benutzerpostfächer. In dieser Architektur werden Token verwendet, die Benutzer*innen von Microsoft Entra ID ausgestellt werden, um den Zugriff auf Postfächer zu autorisieren.

  • Active Directory-Dienste: Active Directory-Dienste speichern Informationen zu Mitgliedern einer Domäne, einschließlich Geräten und Benutzer*innen. In dieser Architektur gehören Benutzerkonten zu Active Directory-Diensten und werden mit Microsoft Entra ID synchronisiert.

Szenariodetails

Enterprise Messaging Infrastructure (EMI) ist ein wichtiger Dienst für Organisationen. Der Wechsel von älteren, weniger sicheren Authentifizierungs- und Autorisierungsmethoden zu einer modernen Authentifizierung ist ein wichtiger Schritt in einer Welt, in der Remotearbeit üblich ist. Die Implementierung von MFA-Voraussetzungen für den Zugriff auf Messagingdienste ist eine der effektivsten Methoden, um dieses Ziel zu erreichen.

In diesem Artikel wird eine Architektur vorgestellt, die die Sicherheit in einem Webzugriffsszenario mithilfe der Microsoft Entra-Multi-Faktor-Authentifizierung erhöht.

Die hier vorgestellten Architekturen ermöglichen Szenarios zum Schutz Ihres Messagingdiensts (Outlook Web App oder Exchange-Systemsteuerung), wenn Postfächer in Exchange Online oder lokalen Exchange-Instanzen gehostet werden.

Informationen zum Anwenden der Multi-Faktor-Authentifizierung in anderen Hybridmessagingszenarios finden Sie in den folgenden Artikeln:

Andere Protokolle wie IMAP oder POP werden in diesem Artikel nicht behandelt. Es wird davon abgeraten, sie für die Erteilung von Benutzerzugriff zu verwenden.

Mögliche Anwendungsfälle

Diese Architektur ist für die folgenden Szenarios relevant:

  • Verbesserung der EMI-Sicherheit
  • Einführung einer Zero-Trust-Sicherheitsstrategie
  • Anwendung hoher Sicherheitsstandards für Ihren lokalen Messagingdienst während des Übergangs zu Exchange Online oder bei parallelem Betrieb mit Exchange Online
  • Erzwingung von strengen Sicherheits- oder Complianceanforderungen in geschlossenen Organisationen oder Organisationen mit höchsten Sicherheitsvorschriften wie in der Finanzbranche

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Überblick über die Säule „Zuverlässigkeit“.

Verfügbarkeit

Die allgemeine Verfügbarkeit hängt von der Verfügbarkeit der beteiligten Komponenten ab. Informationen zur Verfügbarkeit finden Sie in den folgenden Artikeln:

Die Verfügbarkeit lokaler Lösungskomponenten hängt vom implementierten Design, der Hardwareverfügbarkeit und den internen Betriebs- und Wartungsroutinen ab. Informationen zur Verfügbarkeit einiger dieser Komponenten finden Sie in den folgenden Artikeln:

Resilienz

Weitere Informationen zur Resilienz der Komponenten in dieser Architektur finden Sie in den folgenden Artikeln:

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Weitere Informationen zur Sicherheit der Komponenten in dieser Architektur finden Sie in den folgenden Artikeln:

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Die Kosten für Ihre Implementierung hängen von Ihren Microsoft Entra ID- und Microsoft 365-Lizenzkosten ab. Die Gesamtkosten umfassen auch die Kosten für Software und Hardware für lokale Komponenten, den IT-Betrieb, Schulungen und Projektimplementierung.

Für diese Lösung ist mindestens Microsoft Entra ID P1 erforderlich. Informationen zu den Preisen finden Sie unter Microsoft Entra-Preise.

Weitere Informationen zu Exchange finden Sie unter Preise für Exchange Server.

Weitere Informationen zu den Preisen für AD FS und den Webanwendungsproxy finden Sie unter Preise und Lizenzierungsoptionen für Windows Server 2022.

Effiziente Leistung

Leistungseffizienz ist die Fähigkeit Ihrer Workload, eine effiziente Skalierung entsprechend den Anforderungen der Benutzer auszuführen. Weitere Informationen finden Sie unter Übersicht über die Säule „Leistungseffizienz“.

Die Leistung hängt von der Leistung der beteiligten Komponenten und des Unternehmensnetzwerks ab. Weitere Informationen finden Sie unter Leistungsoptimierung für Office 365 mithilfe von Baselines und Leistungsverlauf.

Weitere Informationen zu lokalen Faktoren, die die Leistung in AD FS-Szenarios beeinflussen, finden Sie in den folgenden Artikeln:

Skalierbarkeit

Weitere Informationen zur Skalierbarkeit von AD FS finden Sie unter Planen der AD FS-Serverkapazität.

Weitere Informationen zur Skalierbarkeit von lokalen Exchange Server-Instanzen finden Sie unter Bevorzugte Architektur für Exchange 2019.

Bereitstellen dieses Szenarios

Befolgen Sie diese allgemeinen Schritte, um das Szenario umzusetzen:

  1. Beginnen Sie mit dem Webzugriffsdienst. Erhöhen Sie seine Sicherheit, indem Sie eine Azure-Richtlinie für bedingten Zugriff für Exchange Online anwenden.
  2. Verbessern Sie die Sicherheit des Webzugriffs für lokale EMIs, indem Sie die anspruchsbasierte AD FS-Authentifizierung verwenden.

Einrichten einer Richtlinie für bedingten Zugriff

Gehen Sie wie im Folgenden beschrieben vor, um wie in Schritt 3 des Flows für Onlinebenutzer*innen weiter oben in diesem Artikel beschrieben eine Microsoft Entra-Richtlinie für bedingten Zugriff einzurichten, die die Multi-Faktor-Authentifizierung erzwingt:

  1. Konfigurieren Sie Office 365 Exchange Online oder Office 365 als Cloud-App:

    Screenshot: Konfigurieren von Office als Cloudanwendung

  2. Konfigurieren Sie den Browser als Client-App:

    Screenshot: Anwendung der Richtlinie auf den Browser

  3. Wenden Sie im Fenster Gewähren die Anforderung „Multi-Faktor-Authentifizierung“ an:

    Screenshot: Anwendung der Multi-Faktor-Authentifizierung

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte