Empfehlen, wann ein Microsoft Entra-Anwendungsproxy verwendet und konfiguriert werden soll, einschließlich der Authentifizierung

Abgeschlossen

Der Microsoft Entra-Anwendungsproxy ist eine sichere und kostengünstige Lösung für den Remotezugriff auf lokale Anwendungen. „Cloud First“-Organisationen erhalten hiermit einen direkten Weg zur Verwaltung des Zugriffs auf lokale Legacyanwendungen, für die noch keine modernen Protokolle verwendet werden können.

Der Anwendungsproxy wird empfohlen, um Remotebenutzern Zugriff auf interne Ressourcen zu gewähren. Durch den Anwendungsproxy entfällt die Notwendigkeit eines VPN oder Reverseproxys für solche Anwendungsfälle mit Remotezugriff. Er ist nicht für Benutzer im Unternehmensnetzwerk bestimmt. Wenn Benutzer den Anwendungsproxy für den Zugriff auf das Intranet verwenden, können Leistungsprobleme auftreten.

Planen Ihrer Implementierung

Voraussetzungen:

Sie müssen die folgenden Voraussetzungen erfüllen, bevor Sie mit der Implementierung beginnen. Weitere Informationen zur Einrichtung Ihrer Umgebung, einschließlich dieser Voraussetzungen, finden Sie in diesem Tutorial.

• Connectors: Connectors sind einfache Agents, die Sie auf folgenden Komponenten bereitstellen können:
  
  • Lokale physische Hardware
    
  • In einer Hypervisor-Lösung gehostete VM
  • In Azure gehostete VM für die ausgehende Verbindung zum Anwendungsproxydienst
• Microsoft Entra-Anwendungsproxyconnectors:
  • Auf den Connectorcomputern muss TLS 1.2 aktiviert werden, bevor die Connectors installiert werden.
    
  • Stellen Sie die Connectors nach Möglichkeit in demselben Netzwerk bereit, und führen Sie eine Segmentierung nach Back-End-Webanwendungsservern durch. Es empfiehlt sich, vor dem Bereitstellen der Connectors eine Anwendungsermittlung durchzuführen.
    
  • Um Hochverfügbarkeit und Skalierung zu gewährleisten, sollten jeder Connectorgruppe mindestens zwei Connectors zugewiesen werden. Mit drei Connectors sind Sie in dem Fall, dass Sie einen Computer warten müssen, optimal aufgestellt. Orientieren Sie sich bei der Auswahl des Computertyps, auf dem Sie Connectors installieren, an der Tabelle zur Connectorkapazität. Je größer der Computer ist, desto mehr Pufferkapazität und Leistung bietet der Connector.
    
• Einstellungen für Netzwerkzugriff: Microsoft Entra-Anwendungsproxyconnectors stellen per HTTPS (TCP-Port 443) und HTTP (TCP-Port 80) eine Verbindung mit Azure her.
  
  • Die Beendigung von TLS-Datenverkehr für Connectors wird nicht unterstützt. Hierdurch wird für Connectors verhindert, dass diese einen sicheren Kanal zu ihren entsprechenden Azure-Anwendungsproxy-Endpunkten einrichten.
    
  • Vermeiden Sie alle Arten von Inline-Untersuchungen der ausgehenden TLS-Kommunikation zwischen Connectors und Azure. Die interne Untersuchung zwischen einem Connector und Back-End-Anwendungen ist möglich, aber dies kann zu einer Beeinträchtigung der Benutzerfreundlichkeit führen. Aus diesem Grund wird diese Vorgehensweise nicht empfohlen.
    
  • Ein Lastenausgleich der Connectors selbst wird ebenfalls nicht unterstützt und ist auch nicht erforderlich.
    

Wichtige Aspekte vor der Konfiguration des Microsoft Entra-Anwendungsproxys

Die folgenden grundlegenden Anforderungen müssen erfüllt sein, um den Microsoft Entra-Anwendungsproxy konfigurieren und implementieren zu können.

• Azure-Onboarding: Vor dem Bereitstellen des Anwendungsproxys müssen Benutzeridentitäten aus einem lokalen Verzeichnis synchronisiert oder direkt auf Ihren Microsoft Entra-Mandanten erstellt werden. Mithilfe der Identitätssynchronisierung können Benutzer von Microsoft Entra ID vorab authentifiziert werden, bevor ihnen Zugriff auf per Anwendungsproxy veröffentlichte Anwendungen gewährt wird. Außerdem können die benötigten Benutzer-ID-Informationen für einmaliges Anmelden (Single Sign-On, SSO) bereitgestellt werden.
  
• Anforderungen für bedingten Zugriff: Die Verwendung des Anwendungsproxys für den Intranetzugriff wird nicht empfohlen, da dies die Wartezeit erhöht und sich nachteilig auf Benutzer*innen auswirkt. Wir empfehlen, den Anwendungsproxy mit Vorauthentifizierung und Richtlinien für bedingten Zugriff für den Remotezugriff über das Internet zu verwenden. Wenn Sie bedingten Zugriff für das Intranet bereitstellen möchten, können Sie Ihre Anwendungen modernisieren, sodass sie die Authentifizierung direkt mit Microsoft Entra ID durchführen können. Weitere Informationen finden Sie unter Ressourcen zum Migrieren von Anwendungen zu Microsoft Entra ID.
  
• Diensteinschränkungen: Zum Schutz vor übermäßigem Ressourcenverbrauch durch einzelne Mandanten gelten bestimmte Drosselungsgrenzwerte pro Anwendung und Mandant. Die Grenzwerte finden Sie unter Dienst- und andere Einschränkungen für Microsoft Entra. Die Drosselungsgrenzwerte basieren auf einem Richtwert, der weit über dem typischen Nutzungsvolumen liegt und für die meisten Bereitstellungen ausreichend Puffer bietet.
  
• Öffentliches Zertifikat: Wenn Sie benutzerdefinierte Domänennamen verwenden, müssen Sie ein TLS-/SSL-Zertifikat beschaffen. Je nach den Anforderungen Ihrer Organisation kann die Beschaffung eines Zertifikats einige Zeit dauern. Wir empfehlen Ihnen daher, sich so früh wie möglich darum zu kümmern. Für den Azure-Anwendungsproxy werden Zertifikate vom Typ „Standard“, „Platzhalter“ oder „SAN-basiert“ unterstützt. Weitere Einzelheiten finden Sie unter „Konfigurieren von benutzerdefinierten Domänen per Microsoft Entra-Anwendungsproxy“.
  
• Domänenanforderungen: Das einmalige Anmelden bei Ihren veröffentlichten Anwendungen mithilfe der eingeschränkten Kerberos-Delegierung (Kerberos Constrained Delegation, KCD) erfordert, dass der Server, auf dem der Connector ausgeführt wird, und der Server, auf dem die App ausgeführt wird, in Domänen eingebunden sind und derselben Domäne oder vertrauenswürdigen Domänen angehören. Ausführliche Informationen zu diesem Thema finden Sie unter Eingeschränkte Delegierung von Kerberos für die einmalige Anmeldung zu Ihren Apps mit dem Anwendungsproxy. Der Connectordienst wird im Kontext des lokalen Systems ausgeführt und sollte nicht für die Verwendung einer benutzerdefinierten Identität konfiguriert werden.
  
• DNS-Einträge für URLs
  
  • Vor der Verwendung von benutzerdefinierten Domänen im Anwendungsproxy müssen Sie im öffentlichen DNS einen CNAME-Eintrag erstellen, damit Clients die benutzerdefinierte externe URL in die vordefinierte Anwendungsproxyadresse auflösen können. Wenn für eine Anwendung, die eine benutzerdefinierte Domäne verwendet, kein CNAME-Eintrag erstellt wird, können Remotebenutzer*innen keine Verbindung mit dieser herstellen. Die erforderlichen Schritte zum Hinzufügen von CNAME-Einträgen können von DNS-Anbieter zu DNS-Anbieter variieren. Es ist daher ratsam, dass Sie sich über das Verwalten von DNS-Einträgen und -Ressourceneintragssätzen im Microsoft Entra Admin Center informieren.
    
  • Entsprechend müssen Connectorhosts die interne URL von veröffentlichten Anwendungen auflösen können.
    
• Administratorrechte und -rollen
  
  • Für die Connectorinstallation werden lokale Administratorrechte für den Windows-Server benötigt, auf dem die Installation durchgeführt wird. Darüber hinaus ist für die Authentifizierung und Registrierung der Connectorinstanz bei Ihrem Microsoft Entra-Mandanten mindestens die Rolle Anwendungsadministrator erforderlich.
    
  • Für die Anwendungsveröffentlichung und -verwaltung wird die Rolle Anwendungsadministrator benötigt. Anwendungsadministratoren können alle Anwendungen im Verzeichnis verwalten, z. B. für Registrierungen, SSO-Einstellungen, Zuweisungen und Lizenzierung für Benutzer und Gruppen, Anwendungsproxyeinstellungen und die Einwilligung. Durch diese Rolle kann der bedingte Zugriff nicht verwaltet werden. Die Rolle „Cloudanwendungsadministrator“ verfügt über alle Berechtigungen von „Anwendungsadministrator“, mit Ausnahme der
  • Verwaltung von Anwendungsproxyeinstellungen.
    
• Lizenzierung: Anwendungsproxy ist über ein Microsoft Entra-ID P1- oder P2-Abonnement verfügbar.
  

Anwendungsermittlung

Erstellen Sie eine Bestandsliste mit allen relevanten Anwendungen, die per Anwendungsproxy veröffentlicht werden, indem Sie die folgenden Informationen erfassen:

Informationstyp	Zu erfassende Information
Diensttyp	Beispiel: SharePoint, SAP, CRM, benutzerdefinierte Webanwendung, API
Anwendungsplattform	Beispiel: Windows IIS, Apache für Linux, Tomcat, NGINX
Domänenmitgliedschaft	Vollqualifizierter Domänenname (FQDN) des Webservers
Speicherort der Anwendung	Ort des Webservers bzw. der Farm in Ihrer Infrastruktur
Interner Zugriff	Die genaue URL für den internen Zugriff auf die Anwendung. Bei einer Farm: Welche Art von Lastenausgleich wird verwendet? Nutzt die Anwendung nicht nur eigene Inhalte, sondern auch aus anderen Quellen? Ermitteln Sie, ob die Anwendung über WebSockets betrieben wird.
Externer Zugriff	Die Lösung des Anbieters, über welche die Anwendung möglicherweise bereits extern zugänglich ist. Die URL, die Sie für den externen Zugriff verwenden möchten. Beim SharePoint stellen Sie einen alternativen Zugriff sicher
Öffentliches Zertifikat	Beschaffen Sie bei Verwendung einer benutzerdefinierten Domäne ein Zertifikat mit einem entsprechenden Antragstellernamen. Bei Vorhandensein eines Zertifikats: Notieren Sie sich die Seriennummer und den Ort, von dem es beschafft werden kann.
Authentifizierungsart	Die Authentifizierungsart, die von der Anwendung unterstützt wird, z. B. Einfach, Integrierte Windows-Authentifizierung, Formularbasiert, Headerbasiert und Ansprüche. Wenn die Anwendung für die Ausführung unter einem bestimmten Domänenkonto konfiguriert ist, sollten Sie sich den vollqualifizierten Domänennamen (FQDN) des Dienstkontos notieren. Notieren Sie sich bei „SAML-basiert“ den Bezeichner und die Antwort-URLs. Bei „Headerbasiert“: die Anbieterlösung und die spezifische Anforderung für den Umgang mit der Authentifizierungsart.
Name der Connectorgruppe	Der logische Name für die Gruppe mit den Connectors, die angegeben werden, um die Kommunikation und das einmalige Anmelden für diese Back-End-Anwendung bereitzustellen.
Benutzer-/Gruppenzugriff	Die Benutzer oder Benutzergruppen, denen externer Zugriff auf die Anwendung gewährt wird.
Zusätzliche Anforderungen	Notieren Sie sich alle zusätzlichen Anforderungen in Bezug auf den Remotezugriff oder die Sicherheit, die bei der Veröffentlichung der Anwendung berücksichtigt werden sollten.

Definieren der Anforderungen der Organisation

Für die folgenden Bereiche sollten Sie die geschäftlichen Anforderungen Ihrer Organisation definieren. Jeder Bereich enthält Beispiele für Anforderungen.

Zugriff

• Remotebenutzer*innen mit in Domänen oder in Microsoft Entra eingebundenen Geräten können sicher per nahtlosem einmaligen Anmelden auf veröffentlichte Anwendungen zugreifen.
• Remotebenutzer mit genehmigten persönlichen Geräten können sicher auf veröffentlichte Anwendungen zugreifen, sofern sie für die mehrstufige Authentifizierung (Multi-Factor Authentication, MFA) registriert sind und die Microsoft Authenticator-App auf ihrem Mobiltelefon als Authentifizierungsmethode registriert haben.

Governance

• Administratoren können den Lebenszyklus von Benutzerzuweisungen zu Anwendungen, die per Anwendungsproxy veröffentlicht werden, definieren und überwachen.

Security

• Nur Benutzer, die Anwendungen über die Gruppenmitgliedschaft oder individuell zugewiesen sind, können auf diese Anwendungen zugreifen.

Leistung

• Im Vergleich mit dem Zugriff auf die Anwendung über das interne Netzwerk kommt es nicht zu einer Verschlechterung der Anwendungsleistung.

Benutzerfreundlichkeit

• Benutzer wissen, wie sie auf ihre Anwendungen zugreifen können, weil sie auf allen Geräteplattformen vertraute Unternehmens-URLs verwenden können.

Überwachung

• Administratoren können die Zugriffsaktivitäten von Benutzern überwachen.

Bewährte Methoden für einen Pilotversuch

Ermitteln Sie die erforderliche Zeit und den Aufwand für die vollständige Einrichtung einer einzelnen Anwendung für den Remotezugriff mit einmaligem Anmelden (SSO). Führen Sie hierzu einen Pilotversuch durch, bei dem die anfängliche Ermittlung, die Veröffentlichung und ein allgemeiner Test berücksichtigt werden. Die Verwendung einer einfachen IIS-basierten Webanwendung, die für die integrierte Windows-Authentifizierung (Integrated Windows Authentication, IWA) vorkonfiguriert ist, ermöglicht die Erstellung einer Baseline. Für einen erfolgreichen Pilotversuch in Bezug auf den Remotezugriff und einmaliges Anmelden ist der Aufwand hierbei nämlich nur gering.

Mit den folgenden Entwurfselementen erhöhen sich die Erfolgschancen Ihrer direkten Pilotimplementierung in einem Produktionsmandanten.

Connectorverwaltung:

• Connectors spielen eine wichtige Rolle, wenn es um die Bereitstellung des lokalen Kommunikationskanals für Ihre Anwendungen geht. Die Verwendung der Connectorgruppe Standard ist für anfängliche Pilottests für veröffentlichte Anwendungen geeignet, bevor diese in der Produktion in Betrieb genommen werden. Anwendungen, die erfolgreich getestet wurden, können dann in Connectorgruppen in der Produktion verlagert werden.
  

Anwendungsverwaltung:

• Ihre Mitarbeiter können sich am besten an eine externe URL erinnern, wenn diese vertraut und relevant ist. Vermeiden Sie das Veröffentlichen Ihrer Anwendung über unsere vordefinierten Suffixe „msappproxy.net“ oder „onmicrosoft.com“. Geben Sie stattdessen eine vertraute verifizierte Domain der obersten Ebene an, die mit einem logischen Hostnamen als Präfix versehen ist, z. B.intranet. <customers_domain>.com.
  
• Schränken Sie die Sichtbarkeit des Pilotanwendungssymbols für eine Pilotgruppe ein, indem Sie das Startsymbol im Azure MyApps-Portal ausblenden. Sobald die Anwendung produktionsbereit ist, können Sie sie der jeweiligen Zielgruppe zur Verfügung stellen, entweder im gleichen Vorproduktions-Tenant oder indem Sie die Anwendung auch in Ihrem Produktions-Tenant veröffentlichen.
  

Einstellungen für einmaliges Anmelden: Einige Einstellungen für einmaliges Anmelden verfügen über spezifische Abhängigkeiten, deren Einrichtung zeitaufwendig sein kann. Vermeiden Sie daher Verzögerungen bei der Änderungssteuerung, indem Sie sicherstellen, dass die Einrichtung der Abhängigkeiten rechtzeitig geregelt wird. Dies umfasst auch das Einbinden von Connectorhosts in die Domäne, um einmaliges Anmelden per eingeschränkter Kerberos-Delegierung (KCD) durchzuführen, sowie das Durchführen anderer zeitaufwendiger Aktivitäten.

TLS zwischen Connectorhost und Zielanwendung: Da die Sicherheit an oberster Stelle steht, sollte zwischen dem Connectorhost und den Zielanwendungen immer TLS verwendet werden. Dies gilt vor allem, wenn die Webanwendung für die formularbasierte Authentifizierung (FBA) konfiguriert wird, da die Benutzeranmeldeinformationen dann auf effektive Weise als Klartext übertragen werden.

Inkrementelles Implementieren und Testen jedes Schritts: Führen Sie nach dem Veröffentlichen einer Anwendung einen grundlegenden Funktionstest durch, um sicherzustellen, dass alle Benutzer- und Geschäftsanforderungen erfüllt sind, indem Sie die folgenden Schritte ausführen:

1. Testen und überprüfen Sie den allgemeinen Zugriff auf die Webanwendung bei deaktivierter Vorauthentifizierung.
   
2. Wenn dies erfolgreich verläuft, können Sie die Vorauthentifizierung aktivieren und Benutzer und Gruppen zuweisen. Testen und überprüfen Sie den Zugriff.
3. Fügen Sie anschließend die SSO-Methode für Ihre Anwendung hinzu, und testen Sie erneut, um den Zugriff zu überprüfen.
4. Wenden Sie je nach Bedarf Richtlinien für den bedingten Zugriff und MFA an. Testen und überprüfen Sie den Zugriff.

Problembehandlungstools: Beginnen Sie bei der Problembehandlung immer mit der Überprüfung des Zugriffs auf die veröffentlichte Anwendung mit dem Browser auf dem Connectorhost, und vergewissern Sie sich, dass die Anwendung wie erwartet funktioniert. Je einfacher Ihr Setup ist, desto leichter kann die Grundursache ermittelt werden. Erwägen Sie daher, Probleme bei einer Minimalkonfiguration zu reproduzieren, z. B. indem Sie nur einen Connector und kein SSO verwenden. In einigen Fällen können Webdebugtools, z. B. Fiddler von Telerik, unerlässlich sein, um Probleme mit dem Zugriff oder dem Inhalt in Anwendungen zu behandeln, auf die über einen Proxy zugegriffen wird. Fiddler kann auch als Proxy fungieren und zum Verfolgen und Debuggen von Datenverkehr für mobile Plattformen, z. B. iOS und Android, sowie für praktisch alle anderen Komponenten verwendet werden, für die das Routing über einen Proxy konfiguriert werden kann.

Implementieren Ihrer Lösung

Bereitstellen des Anwendungsproxys

Veröffentlichen von Anwendungen mit dem Anwendungsproxy

Beim Veröffentlichen von Anwendungen wird vorausgesetzt, dass Sie alle Voraussetzungen erfüllt haben und über mehrere Connectors verfügen, die auf der Seite für den Anwendungsproxy als registriert und aktiv angezeigt werden.

Sie können Anwendungen auch mit PowerShell veröffentlichen.

Unten sind einige bewährte Methoden angegeben, an die Sie sich beim Veröffentlichen einer Anwendung halten sollten:

• Verwenden von Connectorgruppen: Weisen Sie eine Connectorgruppe zu, die für die Veröffentlichung der einzelnen Anwendungen angegeben wurde. Um Hochverfügbarkeit und Skalierung zu gewährleisten, sollten jeder Connectorgruppe mindestens zwei Connectors zugewiesen werden. Mit drei Connectors sind Sie in dem Fall, dass Sie einen Computer warten müssen, optimal aufgestellt. Lesen Sie auch den Artikel Veröffentlichen von Anwendungen in getrennten Netzwerken und an getrennten Standorten mithilfe von Connectorgruppen. Dort wird beschrieben, wie Sie Ihre Connectors mithilfe von Connectorgruppen nach Netzwerk oder Standort segmentieren.
• Festlegen des Timeouts für die Back-End-Anwendung: Diese Einstellung ist in Szenarien hilfreich, in denen die Anwendung für die Verarbeitung einer Clienttransaktion ggf. mehr als 75 Sekunden benötigt. Ein Beispiel hierfür ist der Fall, in dem ein Client eine Abfrage an eine Webanwendung sendet, die als Front-End für eine Datenbank fungiert. Das Front-End sendet diese Abfrage an seinen Back-End-Datenbankserver und wartet auf eine Antwort. Wenn die Antwort eingeht, ist für die Konversation auf Clientseite bereits ein Timeout aufgetreten. Wenn Sie die Timeouteinstellung auf „Lang“ festlegen, beträgt der Zeitraum 180 Sekunden, damit auch längere Transaktionen abgeschlossen werden können.
• Verwenden von geeigneten Cookietypen
  • Nur-HTTP-Cookie: sorgt für zusätzliche Sicherheit, indem der Anwendungsproxy das HTTPOnly-Flag in die HTTP-Antwortheader „set-cookie“ einfügt. Diese Einstellung trägt dazu bei, Exploits abzuwehren, z. B. Cross-Site Scripting (XSS). Behalten Sie bei dieser Einstellung für Clients bzw. Benutzer-Agents, die keinen Zugriff auf das Sitzungscookie benötigen, die Option „Nein“ bei. Beispiel: Verbindungsherstellung eines RDP/MTSC-Clients mit einem Remotedesktopgateway, das per Anwendungsproxy veröffentlicht wird.
  • Sicheres Cookie: Wenn ein Cookie mit dem Attribut „Secure“ festgelegt wird, fügt der Benutzer-Agent (clientseitige App) das Cookie nur dann in HTTP-Anforderungen ein, wenn die Anforderung über einen per TLS geschützten Kanal übertragen wird. Auf diese Weise wird das Risiko verringert, dass ein Cookie über Klartextkanäle kompromittiert werden kann.
  • Beständiges Cookie: ermöglicht es, das Sitzungscookie des Anwendungsproxys zwischen Browserschließungen beizubehalten, indem es gültig bleibt, bis es abläuft oder gelöscht wird. Dies wird für Szenarien genutzt, in denen eine umfangreiche Anwendung, z. B. Office, auf ein Dokument in einer veröffentlichten Webanwendung zugreift, ohne dass der Benutzer erneut zum Authentifizieren aufgefordert wird. Gehen Sie beim Aktivieren aber mit Bedacht vor, da es bei beständigen Cookies passieren kann, dass für einen Dienst der unberechtigte Zugriff ermöglicht wird, falls nicht zusätzlich weitere Kontrollen eingebaut werden. Diese Einstellung sollte nur für ältere Anwendungen verwendet werden, bei denen keine Cookies zwischen Prozessen freigegeben werden können. Es ist besser, Ihre Anwendung zur gemeinsamen Nutzung von Cookies zwischen Prozessen zu aktualisieren, als diese Einstellung zu verwenden.
• Übersetzen von URLs in Headern: Sie aktivieren dies für Szenarien, in denen das interne DNS nicht so konfiguriert werden kann, dass es mit dem öffentlichen Namespace der Organisation übereinstimmt (auch als „geteiltes DNS“ bezeichnet). Behalten Sie für diesen Wert die Einstellung „Ja“ bei, sofern für Ihre Anwendung nicht der ursprüngliche Hostheader in der Clientanforderung benötigt wird. Die Alternative besteht darin, für den Connector den FQDN in der internen URL zu verwenden, um den eigentlichen Datenverkehr weiterzuleiten, und den FQDN in der externen URL als Hostheader. In den meisten Fällen sollte diese Alternative die gewohnte Funktion der Anwendung ermöglichen, wenn von einem Remotestandort darauf zugegriffen wird. Für Ihre Benutzer geht aber der Vorteil einer übereinstimmenden internen und externen URL verloren.
• URLs übersetzen in Anwendungstext: Aktivieren Sie für eine App die Option zum Übersetzen von Links im Anwendungstext, wenn Sie möchten, dass Links dieser App in Antworten an den Client übersetzt werden. Wenn diese Funktion aktiviert ist, werden alle internen Links, die vom Anwendungsproxy in HTML- und CSS-Antworten an Clients gefunden werden, bestmöglich übersetzt. Dies ist hilfreich bei der Veröffentlichung von Apps, die im Inhalt entweder hartcodierte absolute Links oder NetBIOS-Kurznamenlinks aufweisen, oder von Apps mit Inhalten, die Links zu anderen lokalen Anwendungen enthalten.

Aktivieren Sie in Szenarien, in denen eine veröffentlichte App Links zu anderen veröffentlichten Apps enthält, die Linkübersetzung für jede Anwendung, damit Sie die Benutzeroberfläche auf App-Ebene steuern können.

Angenommen, Sie haben drei Anwendungen, die über den Anwendungsproxy veröffentlicht werden und miteinander verknüpft sind: Vorteile, Ausgaben und Reisen. Dazu gibt es eine vierte Anwendung, Feedback, die nicht über den Anwendungsproxy veröffentlicht wird.

Wenn Sie die Linkübersetzung für die App „Vorteile“ aktivieren, werden die Links zu „Ausgaben“ und „Reisen“ an die externen URLs für diese Apps umgeleitet, damit auch Benutzer von außerhalb des Unternehmensnetzwerks auf die Apps zugreifen können. Links von „Ausgaben“ und „Reisen“ zurück zu „Vorteile“ funktionieren nicht, da die Linkübersetzung für diese beiden Apps nicht aktiviert wurde. Für den Link zu „Feedback“ erfolgt keine Umleitung, weil keine externe URL vorhanden ist. Benutzer, die die App „Vorteile“ nutzen, können also nicht von außerhalb des Unternehmensnetzwerks auf die App „Feedback“ zugreifen.

Zugreifen auf Ihre Anwendung

Es gibt mehrere Optionen zum Verwalten des Zugriffs auf Ressourcen, die über den Anwendungsproxy veröffentlicht wurden. Sie sollten also die am besten geeignete Option für Ihr jeweiliges Szenario und Ihre Anforderungen an die Skalierbarkeit wählen. Häufige Ansätze sind: Verwendung von lokalen Gruppen, die per Microsoft Entra Connect synchronisiert werden, Erstellung von dynamischen Gruppen in Microsoft Entra ID basierend auf Benutzerattributen, Verwendung von Self-Service-Gruppen, die von einem Ressourcenbesitzer verwaltet werden, oder eine Kombination all dieser Ansätze. Unter den verlinkten Ressourcen sind die jeweiligen Vorteile beschrieben.

Die einfachste Vorgehensweise beim Zuweisen des Zugriffs auf eine Anwendung für Benutzer ist die Verwendung der Optionen unter Benutzer und Gruppen im linken Bereich Ihrer veröffentlichten Anwendung und die direkte Zuweisung von Gruppen oder Einzelpersonen.

Sie können Benutzer*innenn auch den Self-Service-Zugriff auf Ihre Anwendung ermöglichen, indem Sie eine Gruppe zuweisen, in der die Benutzer*innen derzeit nicht Mitglied sind, und die Self-Service-Optionen konfigurieren.

Wenn die Option aktiviert ist, können sich Benutzer dann am MyApps-Portal anmelden und den Zugriff anfordern. Dies wird entweder automatisch genehmigt, und sie werden der bereits zugelassenen Self-Service-Gruppe hinzugefügt, oder es ist eine Genehmigung einer angegebenen zuständigen Person erforderlich.

Gastbenutzer können auch eingeladen werden, auf interne Anwendungen zuzugreifen, die per Anwendungsproxy über Microsoft Entra B2B veröffentlicht wurden.

Für lokale Anwendungen, auf die normalerweise anonym zugegriffen werden kann und die keine Authentifizierung erfordern, kann es ratsam sein, die Option in den Eigenschaften der Anwendung zu deaktivieren.

Wenn Sie für diese Option die Einstellung „Nein“ beibehalten, können die Benutzer auf die lokale Anwendung über den Microsoft Entra-Anwendungsproxy zugreifen, ohne dass Berechtigungen erforderlich sind. Gehen Sie hierbei also mit Bedacht vor.

Aktivieren der Vorauthentifizierung

Vergewissern Sie sich, dass anhand der externen URL über den Anwendungsproxy auf Ihre Anwendung zugegriffen werden kann.

1. Navigieren Sie zu Identität>Anwendungen>Unternehmensanwendungen>Alle Anwendungen, und wählen Sie die App aus, die Sie verwalten möchten.

2. Wählen Sie Anwendungsproxy.

3. Wählen Sie im Feld Vorauthentifizierung in der Dropdownliste die Option Microsoft Entra ID und dann Speichern.

Wenn die Vorauthentifizierung aktiviert ist, fordert Microsoft Entra ID Benutzer zuerst zur Authentifizierung auf. Ist einmaliges Anmelden konfiguriert, wird der Benutzer anschließend auch von der Back-End-Anwendung überprüft, bevor der Zugriff auf die Anwendung gewährt wird. Wenn Sie den Vorauthentifizierungsmodus von „Passthrough“ in „Microsoft Entra ID“ ändern, wird auch die externe URL mit HTTPS konfiguriert. Alle Anwendungen, für die ursprünglich HTTP konfiguriert wurde, sind dann also per HTTPS geschützt.

Einmaliges Anmelden aktivieren

Mit einmaligem Anmelden (SSO) erzielen Sie die bestmögliche Benutzerfreundlichkeit und Sicherheit, weil sich Benutzer nur einmal beim Zugreifen auf Microsoft Entra ID anmelden müssen. Nachdem für einen Benutzer die Vorauthentifizierung erfolgt ist, wird einmaliges Anmelden vom Connector des Anwendungsproxys durchgeführt, um für die lokale Anwendung die Authentifizierung im Namen des Benutzers zu erreichen. Die Anmeldung wird von der Back-End-Anwendung so verarbeitet, als ob es sich um den Benutzer selbst handeln würde.

Bei Auswahl der Option Passthrough können Benutzer auf die veröffentlichte Anwendung zugreifen, ohne sich gegenüber Microsoft Entra ID authentifizieren zu müssen.

Einmaliges Anmelden ist nur möglich, wenn der Benutzer, der den Zugriff auf eine Ressource anfordert, von Microsoft Entra ID identifiziert werden kann. Ihre Anwendung muss also zur Vorauthentifizierung von Benutzern mit Microsoft Entra ID konfiguriert sein, damit einmaliges Anmelden funktioniert. Andernfalls sind die SSO-Optionen deaktiviert.

Arbeiten mit anderen Arten von Anwendungen

Der Microsoft Entra-Anwendungsproxy kann auch Anwendungen unterstützen, die für die Nutzung der Microsoft Authentication Library (MSAL) entwickelt wurden. Hierbei werden native Client-Apps unterstützt, indem von Microsoft Entra ID ausgestellte Token genutzt werden, die in den Headerinformationen von Clientanforderungen empfangen wurden, um die Vorauthentifizierung im Namen von Benutzern durchzuführen.

Verwenden des bedingten Zugriffs zur Erhöhung der Sicherheit

Für die Anwendungssicherheit sind erweiterte Sicherheitsfunktionen erforderlich, mit denen der Schutz vor und die Reaktion auf komplexe Bedrohungen in der lokalen Umgebung und in der Cloud sichergestellt werden kann. Am häufigsten erlangen Angreifer mit unsicheren, standardmäßigen oder gestohlenen Benutzeranmeldeinformationen Zugriff auf Unternehmensnetzwerke. Mit den identitätsgesteuerten Sicherheitsfunktionen von Microsoft wird die Nutzung von gestohlenen Anmeldeinformationen eingedämmt, indem sowohl Identitäten mit als auch ohne Berechtigungen verwaltet und geschützt werden.

Die folgenden Funktionen können verwendet werden, um den Microsoft Entra-Anwendungsproxy zu unterstützen:

• Benutzer- und standortbasierter bedingter Zugriff: Schützen Sie vertrauliche Daten, indem Sie den Benutzerzugriff per geografischem Standort oder über eine IP-Adresse mit Richtlinien für den standortbasierten bedingten Zugriff einschränken.
• Gerätebasierter bedingter Zugriff: Stellen Sie per gerätebasiertem bedingtem Zugriff sicher, dass nur registrierte, genehmigte und konforme Geräte auf Unternehmensdaten zugreifen können.
• Anwendungsbasierter bedingter Zugriff: Wenn sich ein Benutzer außerhalb des Unternehmensnetzwerks befindet, muss ihn das nicht von der Arbeit abhalten. Schützen Sie den Zugriff auf die Cloud- und lokalen Apps des Unternehmens, und behalten Sie mit bedingtem Zugriff die Kontrolle.
• Risikobasierter bedingter Zugriff: Schützen Sie Ihre Daten vor böswilligen Hackern, indem Sie eine risikobasierte Richtlinie für bedingten Zugriff verwenden, die auf alle Apps und Benutzer angewendet werden kann – lokal und in der Cloud.
• „Meine Apps“ in Microsoft Entra: Nachdem Sie Ihren Anwendungsproxydienst bereitgestellt und die Anwendungen sicher veröffentlicht haben, können Sie für Ihre Benutzer einen einfachen Hub einrichten, über den sie alle ihre Anwendungen erkennen und auf sie zugreifen können. Steigern Sie über Meine Apps die Produktivität mit Self-Service-Funktionen, z. B. der Möglichkeit zum Anfordern des Zugriffs auf neue Apps und Gruppen oder zum Verwalten des Zugriffs auf diese Ressourcen im Namen von anderen Personen.

Verwalten Ihrer Implementierung

Erforderliche Rollen

Microsoft empfiehlt die Vorgehensweise, bei der jeweils die geringstmöglichen Rechte gewährt werden, die für die Erledigung der erforderlichen Aufgaben mit Microsoft Entra ID benötigt werden. Informieren Sie sich über die unterschiedlichen verfügbaren Azure-Rollen, und wählen Sie die passende Rolle aus, um die jeweiligen Anforderungen der einzelnen Personen zu erfüllen. Einige Rollen müssen unter Umständen nur vorübergehend angewendet und können nach Abschluss der Bereitstellung wieder entfernt werden.

Geschäftliche Rolle	Geschäftsaufgaben	Microsoft Entra-Rollen
Helpdesk-Administrator	Normalerweise auf die Qualifizierung der von Endbenutzern gemeldeten Probleme und die Durchführung von begrenzten Aufgaben beschränkt, z. B. Änderung der Kennwörter von Benutzern, Annullierung von Aktualisierungstoken und Überwachung der Dienstintegrität.	Helpdeskadministrator
Identitätsadministrator	Lesen von Microsoft Entra-Anmeldeberichten und -Überwachungsprotokollen zum Debuggen von Problemen, die sich auf den Anwendungsproxy beziehen.	Sicherheitsleseberechtigter
Anwendungsbesitzer	Erstellen und Verwalten aller Aspekte von Unternehmensanwendungen, Anwendungsregistrierungen und Anwendungsproxyeinstellungen.	Anwendungsadministrator
Infrastrukturadministrator	Zertifikatrollover-Besitzer	Anwendungsadministrator

Durch das Geringhalten der Anzahl von Personen mit Zugriff auf sichere Informationen oder Ressourcen wird das Risiko verringert, dass ein böswilliger Akteur Zugriff darauf erhält oder ein autorisierter Benutzer versehentlich eine sensible Ressource kompromittiert.

Benutzer müssen aber weiterhin die täglichen Vorgänge durchführen, für die Berechtigungen benötigt werden. Das Erzwingen von Richtlinien auf Just-In-Time-Basis für das Privileged Identity Management, um den bedarfsgesteuerten privilegierten Zugriff auf Azure-Ressourcen und Microsoft Entra ID zu ermöglichen, ist deshalb unser empfohlener Ansatz zur effektiven Verwaltung des Administratorzugriffs und der damit verbundenen Überwachung.

Berichterstellung und Überwachung

Microsoft Entra ID liefert Ihrer Organisation in Überwachungsprotokollen und Berichten zusätzliche Erkenntnisse zur Anwendungsnutzung und betrieblichen Integrität. Der Anwendungsproxy vereinfacht auch stark das Überwachen von Connectors im Microsoft Entra Admin Center und in Windows-Ereignisprotokollen.

Überwachungsprotokolle für Anwendungen

Diese Protokolle enthalten ausführliche Informationen zu Anmeldungen bei Anwendungen, die mit einem Anwendungsproxy konfiguriert sind, sowie zum Gerät und dem Benutzer, das bzw. der auf die Anwendung zugreift. Überwachungsprotokolle stehen im Microsoft Entra Admin Center und in der Überwachungs-API zum Export bereit. Außerdem sind Nutzungs- und Insights-Berichte für Ihre Anwendung verfügbar.

Überwachung des Anwendungsproxyconnectors

Die Connectors und der Dienst führen alle Aufgaben in Bezug auf Hochverfügbarkeit aus. Sie können den Status Ihrer Connectors auf der Seite „Anwendungsproxy“ im Microsoft Entra Admin Center überwachen.

Windows-Ereignisprotokolle und -Leistungsindikatoren

Connectors verfügen über Administrator- und Sitzungsprotokolle. Die Administratorprotokolle enthalten wichtige Ereignisse und die dazugehörigen Fehler. Die Sitzungsprotokolle enthalten alle Transaktionen und die dazugehörigen Verarbeitungsdetails.