Lokale Webanwendungen ohne öffentliche IP bereitstellen Azure AD-Anwendungsproxy für die sichere Bereitstellung von WebApps

Beim Azure AD-Anwendungsproxy handelt es sich um einen Clouddienst, der es auch ermöglicht Reverse-Proxy-Funktionen für Webanwendungen bereitzustellen, die On-Premises laufen. Der dient dazu als zentrale Steuerzentrale.

Anbieter zum Thema

sysob IT-Distribution GmbH & Co. KG

Fujitsu Technology Solutions GmbH

Specops Software GmbH

In vielen Unternehmen gibt es Webanwendungen, die On-Premises laufen und bei denen Anwender aus dem Internet auf die internen Dienste zugreifen sollen. Neben der Konfiguration der Firewall muss hier auch ein Rervese-Proxy zum Einsatz kommen, der die Zugriffe aus dem Internet auf diese Dienste steuert.

Das gilt parallel natürlich auch für Webdienste, die über Azure zur Verfügung gestellt werden. Azure AD-Anwendungsproxy kann ältere Webanwendungen genauso sicher im Internet bereitstellen und schützen, wie moderne WebApps On-Premises oder aus der Cloud. Auch mehrere Webanwendungen gleichzeitig sind kein Problem.

Bildergalerie

Bildergalerie mit 5 Bildern

Auch On-Premises-Anwendungen profitieren vom Azure AD-Anwendungsproxy

Der Azure AD-Anwendungsproxy ist dazu in der Lage Anfragen aus dem Internet anzunehmen und an interne Server On-Premises weiterzuleiten. Dadurch werden Zugriffe sicherer und unkomplizierter möglich, da die Firewalls im Unternehmen nicht angepasst werden müssen. Die Kommunikation zwischen Clients, Azure AD-Anwendungsproxy und Webanwendungen laufen über Agenten, die auf den Zielservern installiert sind. Alle Zugriffe der Clients laufen daher über eine feste URL, inklusive Domäne, in Microsoft Azure.

Bei dem Connector des Azure AD-Anwendungsproxy handelt es sich um einen der zahlreichen Azure Hybrid-Agenten, die Funktionen aus Azure in lokale Rechenzentren bringen. Für nahezu alle dieser Agenten gilt, dass keinerlei Änderungen an den Firewalls im Unternehmen vorgenommen werden müssen, auch für den Connector des Azure AD-Anwendungsproxy.

Der Vorteil bei der Verwendung von Azure AD-Anwendungsproxy ist zunächst, dass die öffentliche IP-Adresse eines Unternehmens für eine Webanwendung nicht bereitgestellt und auch nicht öffentlich bekannt sein muss. Hier besteht die Gefahr von DoS-Attacken oder anderen Angriffen, die direkt auf die öffentliche IP-Adresse des Unternehmens zielen. Genau diese schützt der Azure AD-Anwendungsproxy.

Sicherheit in der Microsoft Cloud mit Azure AD Conditional Access

Authentifizierung mit Richtlinien in Azure AD und Microsoft 365 steuern

Schutz vor DDoS-Attacken und moderne Authentifizierungsmethoden für ältere Anwendungen

Azure AD-Anwendungsproxy bringt zusätzlich noch die Möglichkeit in lokale Netzwerke eine Anmeldung an Webanwendungen über Azure AD vorzunehmen. Die eigentliche Authentifizierung erfolgt direkt am Anwendungsproxy, der die Anfragen aus dem Internet über den Agenten auf dem Server ins lokale Rechenzentrum überträgt.

Die Verbindung zwischen den veröffentlichten Diensten im lokalen Rechenzentrum und Azure AD-Anwendungsproxy laufen über einen Connector, der auf den Servern installiert wird. Über diesen Connector erfolgt die komplette Kommunikation zwischen Azure AD-Anwendungsproxy, Client und veröffentlichter Webanwendung. Die öffentliche IP-Adresse des Unternehmens wird dazu genauso wenig benötigt, wie eine Anpassung der Firewall. Gleichzeitig profitieren Unternehmen davon, dass alle Zugriffe über den Anwendungsproxy laufen. Dieser ist zuverlässig vor Malware-Angriffen und DDoS-Attacken geschützt und routet die Zugriffe der Anwender zuverlässig weiter. Der komplette Datenverkehr läuft über den Connector zum Anwendungsproxy. Es gibt keine HTTP/HTTPS-Daten, die über die Firewall laufen.

Zugriff über eigene Internetdomäne

Die Webanwendungen werden über die Domäne "msappproxy.net" bereitgestellt. Die Anwender greifen mit der festgelegten URL des Webdienstes auf Azure zu und der Azure AD-Anwendungsproxy nimmt die Anfrage entgegen, authentifiziert den Benutzer über Azure AD und leitet bei erfolgreicher Authentifizierung die Anfrage an den Webdienst On-Premises oder in Azure weiter. Hier besteht auch die Möglichkeit mit Conditional Access in Azure AD zu arbeiten, also der Überprüfung, ob sich Benutzer am jeweiligen System basierend auf ihrem Aufenthaltsort und Zeit überhaupt anmelden dürfen.

Die Kommunikation erfolgt zwischen Connector auf dem internen Server und Microsoft Azure, die Anwender kommunizieren wiederum zwischen dem Internet und Azure AD-Anwendungsproxy. Wer sich umfassender mit der Einrichtung auseinandersetzen will, findet auf der Seite „Veröffentlichen von lokalen Apps für Remotebenutzer mit dem Azure AD-Anwendungsproxy“ ausführliche Informationen über die Microsoft-Dokumentation.

Azure AD Identity Protection erklärt

Sicherheit für Benutzerkonten in Azure Active Directory

So funktionieren die Zugriffe von Anwendern über den Azure AD-Anwendungsproxy

Im ersten Schritt geben die Benutzer die URL ein, die für die Webanwendung hinterlegt ist. Das kann zum Beispiel "outlookjoos.msappproxy.net" sein. Der Anwendungsproxy leitet die Anfrage zur Authentifizierung an Azure AD weiter. Wenn sich der Benutzer an Azure AD erfolgreich angemeldet hat, bekommt er ein Anmeldetoken durch Azure AD.

Die Anmeldedaten gehen an den Azure AD-Anwendungsproxy, der diese prüft und bei erfolgreicher Anmeldung die Anforderung des Zugriffs von dem jeweiligen Benutzer an den Anwendungsproxy-Connector weiterleitet. Der Connector läuft auf einem internen Server im Netzwerk. Dabei kann es sich um den gleichen Server handeln, der auch die Webanwendung bereitstellt, es kann sich aber auch um einen anderen Server handeln.

Wenn die Authentifizierung mit SSO konfiguriert ist, authentifiziert der Connector den Anwender direkt an Active Directory. Ist kein SSO im Einsatz, muss sich der Benutzer für den Zugriff auf die Anwendung nochmal authentifizieren. In den meisten Umgebungen werden die Admins sicher mit der Active Directory-Synchronisierung zwischen AD und Azure AD arbeiten. In diesem Fall melden sich die Benutzer an Azure AD an und erhalten danach Zugriff auf die Webanwendung über den konfigurierten SSO-Zugang.

Nach der erfolgreichen Authentifizierung des Anwenders per SSO oder zusätzlicher manueller Authentifizierung an Active Directory, sendet der Connector die Anforderung des Anwenders an die Webanwendung im internen Netzwerk. Die Antwort der Webanwendung erfolgt jetzt über den Connector zum Anwender.

Praxistipps für den Einsatz des Azure AD-Anwendungsproxy

Damit der Connector auf einem Server installiert werden kann, muss sichergestellt sein, dass ein Registryschlüssel korrekt gesetzt ist, der die HTTP2-Protokollunterstützung für die Kerberos-Delegierung in WinHTTP steuert. Das geht über den folgenden Befehl in der PowerShell:

Auf dem Server, der den Connector für den Azure AD-Anwendungsproxy bereitstellt muss noch TLS 1.2 aktiviert sein. Microsoft empfiehlt an dieser Stelle die Anpassung eines Registryschlüssels:

Ressourcenzugriff in Azure AD sichern - Hackerangriffe abwehren

Privileged Identity Management in Azure AD und Microsoft 365

Der Server, auf dem der Anwendungsproxy-Connector installiert ist, muss in der Lage sein, ausgehende Verbindungen zu den Ports 80 und 443 zu öffnen. Generell sollten die Verbindungen zum Connector nicht durch andere Dienste getrennt werden, sondern immer zwischen Connector-Server und Azure ablaufen.

Die Einrichtung des Azure AD-Anwendungsproxy erfolgt über die Verwaltung von Azure AD im Azure-Verwaltungsportal. Hier kann auch das Azure AD Admin Center zum Einsatz kommen, das über die URL https://aad.portal.azure.com erreicht wird. Die Installationsdateien für den Connector sind über die Schaltfläche "Connectordienst herunterladen" bei "Anwendungsproxy" im Azure AD Admin Center zu finden.

(ID:48299986)