Teilen über

Sicherheitsaspekte beim Remotezugriff auf Apps mit dem Microsoft Entra-Anwendungsproxy

  • Artikel

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.

Diagramm des sicheren Remotezugriffs über den Microsoft Entra-Anwendungsproxy

Sicherheitsvorteile

Der Microsoft Entra-Anwendungsproxy bietet viele Sicherheitsvorteile. Die Liste der Vorteile sind:

  • 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 Vorabauthentifizierung blockiert naturgemäß eine erhebliche Anzahl anonymer Angriffe, da nur authentifizierte Identitäten auf die Back-End-Anwendung zugreifen können.

Wenn Sie Passthrough als Vorauthentifizierungsmethode wählen, haben 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 Richtlinien für die Multi-Faktor-Authentifizierung zu konfigurieren und so eine weitere Sicherheitsebene für Ihre Benutzerauthentifizierungen zu schaffen. Darüber hinaus können Ihre Anwendungen auch über einen bedingten Microsoft Entra-Zugriff an Microsoft Defender-for-Cloud-Apps weitergeleitet werden, um Echtzeitüberwachung und Steuerungsmöglichkeiten durch Zugriffs- und Sitzungs-Richtlinien zu ermöglichen.

Beendigung des Datenverkehrs

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. Die Sitzung kann nur mit dem Back-End-Server wiederhergestellt werden, was bedeutet, dass Ihre Back-End-Server nicht dem direkten HTTP-Verkehr ausgesetzt sind. Die Konfiguration bedeutet, dass Sie besser vor gezielten Angriffen geschützt sind.

Gesamter Zugriff in ausgehender Richtung

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

Private Netzwerkconnectors verwenden nur ausgehende Verbindungen mit dem Microsoft Entra-Anwendungsproxydienst. Es ist nicht nötig, Firewall-Ports für eingehende Verbindungen zu öffnen. Herkömmliche Proxys erfordern ein Perimeter-Netzwerk (auch DMZ, demilitarisierte Zone oder Umkreisnetzwerk genannt) und erlauben den Zugriff auf 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 Connectors finden Sie unter Grundlegendes zu privaten Microsoft Entra-Netzwerkconnectors.

Analysen und Machine Learning auf Cloudebene

Setzen Sie auf Sicherheit und Schutz auf dem neuesten Stand.

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. Zusammen identifizieren wir proaktiv kompromittierte Konten und ermöglichen den Schutz vor Anmeldungen mit hohem Risikofaktor. Wir berücksichtigen zahlreiche Faktoren, um zu bestimmen, welche Anmeldeversuche mit hohem Risiko behaftet sind. Zu diesen Faktoren zählen das Markieren infizierter Geräte, das Anonymisieren von Netzwerken sowie 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.

Zur Erhöhung der Sicherheit von Anwendungen, die vom Microsoft Entra-Anwendungsproxy veröffentlicht werden, blockieren wir die Indizierung und Archivierung Ihrer Anwendungen durch Webcrawlerroboter. Wenn ein Webcrawler versucht, die robots-Einstellungen für eine veröffentlichte Anwendung abzurufen, antwortet der Anwendungsproxy mit einer Datei namens „robots.txt“, 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 läuft in der Microsoft Cloud und ist der Ort, an dem die externen Client-/Benutzerverbindungen hergestellt werden.
  • Dem lokalen Connector: Als lokale Komponente lauscht der Connector auf Anfragen vom Microsoft Entra-Anwendungsproxydienst und wickelt die Verbindungen mit den internen Anwendungen ab.

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

  • Bei der Ersteinrichtung des Connectors.
  • Der Connector bezieht Konfigurationsinformationen vom Anwendungsproxydienst.
  • Ein Benutzer greift auf eine veröffentlichte Anwendung zu.

Hinweis

Die gesamte Kommunikation erfolgt über TLS und verläuft immer vom Connector zum Anwendungsproxydienst. Der Dienst gilt nur für ausgehenden Datenverkehr.

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. Die Connectorregistrierung beim Dienst erfolgt im Rahmen der Connectorinstallation. Benutzer werden aufgefordert, 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 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 ruft mit seinem Clientzertifikat zunächst die Systemkonfigurationsdaten aus dem Dienst ab und ist nun bereit, Anforderungen entgegenzunehmen.

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 Anwendung
  2. Der Dienst fügt eine Anforderung in die Connectorwarteschlange ein.
  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 Passthrough als Vorauthentifizierungsmethode verwendet, werden die Schritte in diesem Abschnitt übersprungen.

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

  1. Anwendungsproxy überprüft auf Richtlinienanforderungen für bedingten Zugriff. Der 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 einer der Schritte vor der Authentifizierung fehlschlägt, wird die Anfrage des Benutzers abgelehnt, und der Benutzer erhält eine Meldung, die auf die Quelle des Problems hinweist.

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 in der Anforderung im Textbereich Daten zugeordnet sind, (z. B. bei einem RESTful-APIPOST-Vorgang), stellt der Connector mithilfe des Clientzertifikats eine ausgehende Verbindung zur Anwendungsproxyinstanz her. Die Verbindung wird zum Anfordern der Daten und zum Öffnen einer Verbindung mit der internen Ressource hergestellt. 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