Sicherheitsaspekte beim Remotezugriff auf Apps mit dem Microsoft Entra-Anwendungsproxy

In diesem Artikel werden die Komponenten beschrieben, die Ihre Benutzer und Anwendungen schützen, wenn Sie den Microsoft Entra-Anwendungsproxy verwenden.

Im folgenden Diagramm ist dargestellt, wie mit Microsoft Entra ID der sichere Remotezugriff auf Ihre lokalen Anwendungen ermöglicht wird.

Sicherheitsvorteile

Der Microsoft Entra-Anwendungsproxy bietet viele Sicherheitsvorteile. Zu diesen Vorteilen gehören:

• Authentifizierter Zugriff
• Bedingter Zugriff
• Beendigung des Datenverkehrs
• Alle ausgehenden Zugriffe
• Analytik und maschinelles Lernen in der Cloud
• Remotezugriff als Dienst
• Microsoft Distributed Denial of Service (DDoS)-Schutzdienst

Authentifizierter Zugriff

Nur authentifizierte Verbindungen können auf Ihr Netzwerk zugreifen, wenn Sie die Vorabauthentifizierung von Microsoft Entra verwenden.

Der Microsoft Entra-Anwendungsproxy basiert auf dem Microsoft Entra-Sicherheitstokendienst (Security Token Service, STS) für die gesamte Authentifizierung. Die Vorauthentifizierung blockiert in ihrer Natur eine erhebliche Anzahl anonymer Angriffe, da nur authentifizierte Identitäten auf die Back-End-Anwendung zugreifen können.

Wenn Sie passthrough als Ihre Vorauthentifizierungsmethode auswählen, erhalten Sie diesen Vorteil nicht.

Bedingter Zugriff

Wenden Sie umfassendere Richtlinienkontrollen an, bevor Verbindungen mit Ihrem Netzwerk hergestellt werden.

Beim bedingten Zugriff können Sie Einschränkungen definieren, um zu steuern, wie Benutzer auf Ihre Anwendungen zugreifen können. Sie können Richtlinien erstellen, mit denen Anmeldungen basierend auf dem Standort, der Authentifizierungssicherheit und dem Risikoprofil des Benutzers eingeschränkt werden.

Sie können den bedingten Zugriff auch verwenden, um mehrstufige Authentifizierungsrichtlinien zu konfigurieren und Ihrer Benutzerauthentifizierung eine weitere Sicherheitsebene hinzuzufügen. Ihre Anwendungen können auch über den bedingten Zugriff von Microsoft Entra an Microsoft Defender für Cloud-Apps weitergeleitet werden, um Echtzeitüberwachung und -kontrollen über Zugriffs - und Sitzungsrichtlinien bereitzustellen.

Verkehrsbeendigung

Der gesamte Datenverkehrsvorgang wird in der Cloud beendet.

Da es sich beim Microsoft Entra-Anwendungsproxy um einen Reverseproxy handelt, wird der gesamte Datenverkehr zu Back-End-Anwendungen beim Dienst beendet. Der Dienst stellt die Sitzung nur mit dem Back-End-Server wieder her, was bedeutet, dass Ihre Back-End-Server nicht für direkten HTTP-Datenverkehr verfügbar gemacht werden. Diese Konfiguration bedeutet, dass Sie besser vor gezielten Angriffen geschützt sind.

Alle Zugriffe sind ausgehend

Sie müssen keine eingehenden Verbindungen mit dem Unternehmensnetzwerk öffnen.

Private Netzwerkverbinder verwenden nur ausgehende Verbindungen zum Microsoft Entra-Anwendungsproxydienst. Es ist nicht nötig, Firewall-Ports für eingehende Verbindungen zu öffnen. Herkömmliche Proxys erfordern ein Umkreisnetzwerk (auch bekannt als demilitarisierte Zone (DMZ) oder ein abgeschirmtes Subnetz und zulassen nicht authentifizierte Verbindungen am Netzwerkrand. Bei Verwenden des Anwendungsproxys benötigen Sie kein Umkreisnetzwerk, da alle Verbindungen ausgehend sind und über einen sicheren Kanal erfolgen.

Weitere Informationen zu Konnektoren finden Sie unter Grundlegendes zu privaten Microsoft Entra-Netzwerkkonnektoren.

Analysen und Machine Learning auf Cloudebene

Erhalten Sie modernsten Sicherheitsschutz.

Da er Teil von Microsoft Entra ID ist, verwendet der Anwendungsproxy Microsoft Entra ID Protection mit Daten des Microsoft Security Response Center und der Digital Crimes-Einheit. Gemeinsam identifizieren sie proaktiv kompromittierte Konten und bieten Schutz vor Hochrisikoanmeldungen. Zahlreiche Faktoren bestimmen, welche Anmeldeversuche ein hohes Risiko darstellen. Zu diesen Faktoren gehören infizierte Geräte, anonymisierende Netzwerke und atypische oder unwahrscheinliche Standorte.

Viele dieser Berichte und Ereignisse sind bereits über eine API für die Integration in Ihre Sicherheitsinformations- und Ereignisverwaltungssysteme (Security Information and Event Management, SIEM) verfügbar.

Remotezugriff als Dienst

Sie müssen sich nicht mit dem Warten und Patchen von lokalen Servern beschäftigen.

Software ohne die richtigen Patches ist immer noch eine häufige Ursache für eine große Zahl von Angriffen. Der Microsoft Entra-Anwendungsproxy ist ein Internetskalierungsdienst, der sich im Besitz von Microsoft befindet. So erhalten Sie immer die neuesten Sicherheitspatches und -upgrades.

Um die Sicherheit von Anwendungen zu verbessern, die vom Microsoft Entra-Anwendungsproxy veröffentlicht werden, blockiert Anwendungsproxys Webcrawlerroboter vom Indizieren und Archivieren Ihrer Anwendungen. Jedes Mal, wenn ein Webcrawler versucht, die Einstellungen des Roboters für eine veröffentlichte Anwendung abzurufen, antwortet der Anwendungsproxy mit einer robots.txt-Datei, die User-agent: * Disallow: / enthält.

Microsoft Distributed Denial of Service (DDoS)-Schutzdienst

Anwendungen, die über einen Anwendungsproxy veröffentlicht werden, sind gegen Distributed Denial of Service (DDoS)-Angriffe geschützt. Microsoft aktiviert diesen Schutz automatisch in allen Rechenzentren. Der Microsoft DDoS-Schutzdienst bietet eine permanente Überwachung des Datenverkehrs und eine Echtzeitabwehr gängiger Angriffe auf Netzwerkebene.

Hinter den Kulissen

Der Microsoft Entra-Anwendungsproxy besteht aus zwei Teilen:

• Der cloudbasierte Dienst: Dieser Dienst wird in der Microsoft-Cloud ausgeführt und ist der Ort, an dem externe Clients und Benutzer eine Verbindung herstellen.
• Der lokale Connector: Eine lokale Komponente, der Connector lauscht auf Anforderungen vom Microsoft Entra-Anwendungsproxydienst und verarbeitet Verbindungen mit internen Anwendungen.

Ein Flow zwischen dem Connector und dem Anwendungsproxydienst wird in folgenden Fällen eingerichtet:

• Der Connector wird zuerst eingerichtet.
• Der Connector bezieht Konfigurationsinformationen vom Anwendungsproxydienst.
• Ein Benutzer greift auf eine veröffentlichte Anwendung zu.

Der Connector verwendet ein Clientzertifikat, um den Anwendungsproxydienst für nahezu alle Aufrufe zu authentifizieren. Die einzige Ausnahme zu dieser Vorgehensweise ist hierbei der anfängliche Setupschritt, bei dem das Clientzertifikat eingerichtet wird.

Installieren des Connectors

Bei der Ersteinrichtung des Connectors treten die folgenden Flow-Ereignisse ein:

1. Der Connector registriert sich während der Installation beim Dienst. Das Installationsprogramm fordert Benutzer auf, ihre Microsoft Entra-Administratoranmeldeinformationen einzugeben. Das aus dieser Authentifizierung abgerufene Token wird dann an den Microsoft Entra-Anwendungsproxydienst übermittelt.
2. Der Anwendungsproxydienst wertet das Token aus. Er überprüft, ob der Benutzer mindestens ein Anwendungsadministrator im Mandanten ist. Wenn der Benutzer nicht beteiligt ist, wird der Prozess beendet.
3. Der Connector generiert eine Clientzertifikatanforderung und übergibt sie mit dem Token an den Anwendungsproxydienst. Der Dienst überprüft wiederum das Token und signiert die Clientzertifikatanforderung.
4. Der Connector verwendet dieses Clientzertifikat für die zukünftige Kommunikation mit dem Anwendungsproxydienst.
5. Der Connector führt einen anfänglichen Pull der Systemkonfigurationsdaten vom Dienst mithilfe seines Clientzertifikats aus und kann Anforderungen annehmen.

Aktualisieren der Konfigurationseinstellungen

Wenn der Anwendungsproxydienst die Konfigurationseinstellungen aktualisiert, treten die folgenden Flow-Ereignisse ein:

1. Der Connector stellt die Verbindung mit dem Konfigurationsendpunkt im Anwendungsproxydienst mit dem dazugehörigen Clientzertifikat her.
2. Das Clientzertifikat wird überprüft.
3. Der Anwendungsproxydienst gibt Konfigurationsdaten an den Connector zurück (z. B. die Connectorgruppe, zu welcher der Connector gehören soll).
4. Der Connector generiert eine neue Zertifikatanforderung, wenn das aktuelle Zertifikat mehr als 180 Tage alt ist.

Zugreifen auf veröffentlichte Anwendungen

Wenn Benutzer auf eine veröffentlichte Anwendung zugreifen, treten zwischen dem Anwendungsproxydienst und dem privaten Netzwerkconnector die folgenden Ereignisse ein:

1. Der Dienst authentifiziert den Benutzer für die App.
2. Der Dienst platziert eine Anforderung in der Connectorwarteschlange.
3. Ein Connector verarbeitet die Anforderung aus der Warteschlange.
4. Der Connector wartet auf eine Antwort.
5. Der Dienst streamt Daten an den Benutzer.

Lesen Sie weiter, um mehr Informationen dazu zu erhalten, was in den einzelnen Schritten passiert.

1. Der Dienst authentifiziert den Benutzer für die Anwendung

Wenn die Anwendung die Passthrough-Methode als Pre-Authentication-Methode verwendet, überspringen Sie die Schritte in diesem Abschnitt.

Die Microsoft Entra-ID leitet Benutzer an den STS weiter, um sich zu authentifizieren, wenn die Anwendung für die Vorauthentifizierung mit microsoft Entra-ID konfiguriert ist. Die folgenden Schritte werden ausgeführt:

1. Der Anwendungsproxy überprüft die Anforderungen der Richtlinien für Bedingten Zugriff. Dieser Schritt stellt sicher, dass der Benutzer der Anwendung zugewiesen ist. Wenn die zweistufige Überprüfung erforderlich ist, fordert die Authentifizierungssequenz den Benutzer zu einer zweistufigen Authentifizierung auf.
2. Der Microsoft Entra STS stellt ein signiertes Token für die Anwendung aus und leitet den Benutzer an den Anwendungsproxydienst zurück.
3. Der Anwendungsproxy prüft, ob das Token für die richtige Anwendung ausgestellt wurde, signiert und gültig ist.
4. Der Anwendungsproxy setzt ein verschlüsseltes Authentifizierungs-Cookie, um die erfolgreiche Authentifizierung bei der Anwendung anzuzeigen. Das Cookie enthält einen Ablaufzeitstempel basierend auf dem Token von Microsoft Entra ID. Das Cookie enthält auch den Benutzernamen, auf dem die Authentifizierung basiert. Das Cookie wird mit einem privaten Schlüssel verschlüsselt, der nur dem Anwendungsproxydienst bekannt ist.
5. Der Anwendungsproxy leitet den Benutzer zurück zur ursprünglich angeforderten URL.

Wenn ein Teil der Vorauthentifizierungsschritte fehlschlägt, wird die Anforderung des Benutzers verweigert, und der Benutzer wird eine Meldung angezeigt, die die Quelle des Problems angibt.

2. Der Dienst fügt eine Anforderung in die Connectorwarteschlange ein.

Connectors halten eine ausgehende Verbindung zum Anwendungsproxydienst offen. Bei Empfang einer Anforderung reiht der Dienst diese in eine Warteschlange für eine der offenen Verbindungen ein, damit sie vom Connector verarbeitet werden kann.

Die Anforderung enthält Anforderungsheader, Daten aus dem verschlüsselten Cookie, den Benutzer, der die Anforderung vornimmt, und die Anforderungs-ID. Obwohl die Daten des verschlüsselten Cookies mit der Anfrage gesendet werden, wird das Authentifizierungs-Cookie selbst nicht gesendet.

3. Der Connector verarbeitet die Anforderung aus der Warteschlange.

Auf Grundlage der Anforderung führt der Anwendungsproxy eine der folgenden Aktionen durch:

• Wenn die Anforderung ein einfacher Vorgang ist (z. B. ohne Daten im Text wie bei einer RESTful-API-GET-Anforderung), stellt der Connector eine Verbindung zur internen Zielressource her und wartet dann auf eine Antwort.

• Wenn der Anforderung im Hauptteil Daten zugeordnet sind, (z. B. bei einem RESTful APIPOST-Vorgang), stellt der Connector mithilfe des Clientzertifikats eine ausgehende Verbindung zur Anwendungsproxyinstanz her. Es stellt diese Verbindung her, um die Daten anzufordern und eine Verbindung zur internen Ressource zu öffnen. Nach Erhalt der Anforderung vom Connector beginnt der Anwendungsproxydienst damit, Inhalte vom Benutzer zu akzeptieren und Daten an den Connector weiterzuleiten. Der Connector leitet die Daten wiederum an die interne Ressource weiter.

4. Der Connector wartet auf eine Antwort.

Nachdem die Anforderung/Übertragung des gesamten Inhalts an das Back-End abgeschlossen ist, wartet der Connector auf eine Antwort.

Nach dem Erhalt einer Antwort stellt der Connector eine ausgehende Verbindung zum Anwendungsproxydienst her, um die Headerdetails zurückzugeben und mit dem Streamen der Rückgabedaten zu beginnen.

5. Der Dienst streamt Daten an den Benutzer.

Zu diesem Zeitpunkt findet eine gewisse Bearbeitung der Anwendung statt. Der Anwendungsproxy übersetzt z. B. Header oder URLs.

Nächste Schritte

• Anwendungsproxy-Netzwerktopologie
• Private Netzwerkanschlüsse