Bewährte Methoden für Web- und SaaS-Anwendungskonfigurationen

Der Anwendungszugriff für veröffentlichte und unveröffentlichte Apps hängt von den Anwendungen und Zugriffsrichtlinien ab, die im Secure Private Access Service konfiguriert sind.

Anwendungszugriff innerhalb von Secure Private Access für veröffentlichte und unveröffentlichte Apps

• Zugriff auf veröffentlichte Webanwendungen und verwandte Domains:

  • Wenn ein Endbenutzer auf einen FQDN zugreift, der einer veröffentlichten Web-App zugeordnet ist, ist der Zugriff nur zulässig, wenn eine Zugriffsrichtlinie explizit mit der Aktion Zulassen oder Zulassenmit Einschränkungen für den Benutzer konfiguriert wurde.

    Hinweis:

    Es wird empfohlen, nicht mehrere Anwendungen dieselbe Anwendungs-URL-Domain oder verwandte Domänen zu verwenden, um eine genaue Übereinstimmung zu erzielen. Wenn mehrere Apps dieselbe Anwendungs-URL-Domain oder verwandte Domänen verwenden, erfolgt der Zugriff auf der Grundlage der exakten FQDN-Übereinstimmung und der Richtlinienpriorisierung. Einzelheiten finden Sie unter Abstimmung und Priorisierung von Zugriffsrichtlinien.

  • Wenn keine Zugriffsrichtlinie mit der veröffentlichten App übereinstimmt oder wenn eine App keiner Zugriffsrichtlinie zugeordnet ist, wird der Zugriff auf die App standardmäßig verweigert. Einzelheiten zu Zugriffsrichtlinien finden Sie unter Zugriffsrichtlinien.

• Zugriff auf unveröffentlichte interne Webanwendungen und externe Internet-URLs:

  Um Zero-Trust zu ermöglichen, verweigert Secure Private Access den Zugriff auf interne Webanwendungen oder Intranet-URLs, die keiner Anwendung zugeordnet sind und für die keine Zugriffsrichtlinie konfiguriert ist. Um bestimmten Benutzern den Zugriff zu ermöglichen, stellen Sie sicher, dass Sie eine Zugriffsrichtlinie für Ihre Intranet-Webanwendungen konfiguriert haben.

  Für jede URL, die nicht als Anwendung in Secure Private Access konfiguriert ist, fließt der Datenverkehr direkt ins Internet.

  • In solchen Fällen wird der Zugriff auf URL-Domänen der Intranet-Webanwendung direkt weitergeleitet und somit der Zugriff verweigert (es sei denn, der Benutzer befindet sich bereits im Intranet).
  • Für unveröffentlichte Internet-URLs basiert der Zugriff auf die Regeln, die für nicht genehmigte Apps konfiguriert wurden, sofern diese aktiviert sind. Standardmäßig ist dieser Zugriff innerhalb von Secure Private Access zulässig. Einzelheiten finden Sie unter Regeln für nicht sanktionierte Websites konfigurieren.

Abstimmung und Priorisierung von Zugriffsrichtlinien

Secure Private Access geht beim Zuordnen einer Zugriffsanwendung wie folgt vor:

1. Ordnen Sie die Domain, auf die zugegriffen wird, der Domain der Anwendungs-URL oder verwandten Domains zu, um eine exakte Übereinstimmung zu erhalten.

2. Wenn eine Secure Private Access-Anwendung gefunden wird, die mit einer exakten FQDN-Übereinstimmung konfiguriert ist, bewertet Secure Private Access alle für diese Anwendung konfigurierten Richtlinien.

   • Richtlinien werden in einer Prioritätsreihenfolge bewertet, bis der Benutzerkontext übereinstimmt. Die Aktion (erlauben/verweigern) wird gemäß der ersten Richtlinie angewendet, die in der Prioritätsreihenfolge übereinstimmt.
   • Wenn keine Richtlinie zutrifft, wird der Zugriff standardmäßig verweigert.

3. Wenn keine exakte FQDN-Übereinstimmung gefunden wird, vergleicht Secure Private Access die Domain anhand der längsten Übereinstimmung (z. B. eine Platzhalterübereinstimmung), um Anwendungen und entsprechende Richtlinien zu finden.

   Beispiel 1: Betrachten Sie die folgenden App- und Richtlinienkonfigurationen:

   Anwendung	Anwendungs-URL	Verwandte Domain
   Intranet	https://app.intranet.local	*.cdn.com
   Wiki	https://wiki.intranet.local	*.intranet.local

   Richtlinienname	Priorität	Benutzer und zugehörige Apps
   Richtlinie A	Hoch	Eng-User5 (Intranet)
   Richtlinie B	Niedrig	HR-Benutzer4 (Wiki)

   Bei HR-User4 Zugriffen app.intranet.localpassiert Folgendes:

   1. Secure Private Access durchsucht in diesem Fall alle Richtlinien nach einer exakten Übereinstimmung mit der Domain, app.intranet.local auf die zugegriffen wird.
   2. Secure Private Access findet und prüft PolicyA, ob die Bedingungen erfüllt sind.
   3. Da die Bedingungen nicht übereinstimmen, stoppt Secure Private Access hier und überprüft nicht weiter die Platzhalter-Treffer, obwohl sie mit der zugehörigen Domain der *.intranet.localWiki-App übereinstimmen und Zugriff gewährt worden PolicyBwäre. app.intranet.local
   4. Daher HR-User4 wird der Zugriff auf die Wiki-App verweigert.

   Beispiel 2: Betrachten Sie die folgenden Apps und Richtlinienkonfigurationen, bei denen dieselbe Domain in mehreren Anwendungen verwendet wird:

   Anwendung	Anwendungs-URL	Verwandte Domain
   App 1	xyz.com	app.intranet.local
   App 2	app.intranet.local	-

   Richtlinienname	Priorität	Benutzer und zugehörige Apps
   Richtlinie A	Hoch	Eng-User5 (App1)
   Richtlinie B	Niedrig	HR-User7 (App 2)

   Wenn der Benutzer Eng-User5 zugreift app.intranet.local, stimmen App1 und App2 auf der Grundlage der exakten FQDN-Übereinstimmung überein, sodass der Eng-User5 Benutzer Zugriff über erhält. PolicyA

   Hätte App1 jedoch stattdessen eine *.intranet.local verwandte Domain, dann Eng-User5 wäre der Zugriff für verweigert worden, da genau gepasst app.intranet.local hätte PolicyB, für die der Benutzer, Eng-User5, keinen Zugriff hat.

Bewährte Methoden zur App-Konfiguration

IDP-Domains müssen über eine eigene Anwendung verfügen

Anstatt IDP-Domains als verwandte Domains in Ihren Intranet-App-Konfigurationen hinzuzufügen, empfehlen wir Folgendes:

• Erstellen Sie separate Anwendungen für alle IDP-Domänen.
• Erstellen Sie eine Richtlinie, um allen Benutzern den Zugriff auf die IDP-Authentifizierungsseite zu ermöglichen, und behalten Sie die Richtlinie mit der höchsten Priorität bei.
• Blenden Sie diese App in der App-Konfiguration aus (indem Sie die Option Anwendungssymbol den Benutzern nicht anzeigen auswählen), damit sie nicht im Workspace aufgeführt wird. Weitere Informationen finden Sie unter Anwendungsdetails konfigurieren.

Hinweis:

Diese App-Konfiguration ermöglicht nur den Zugriff auf die IDP-Authentifizierungsseite. Der weitere Zugriff auf einzelne Anwendungen hängt immer noch von den einzelnen App-Konfigurationen und ihren jeweiligen Zugriffsrichtlinien ab.

Beispielkonfiguration:

1. Konfigurieren Sie alle gängigen FQDNs in ihren eigenen Apps und gruppieren Sie sie gegebenenfalls.

   Wenn Sie beispielsweise einige Apps haben, die Azure AD als IdP verwenden, und Sie weitere verwandte Domänen (*.msauth.net) konfigurieren login.microsoftonline.commüssen, gehen Sie wie folgt vor:

   • Erstellen Sie eine einzige gemeinsame Anwendung mit https://login.microsoftonline.com als Anwendungs-URL *.login.microsoftonline.com und *.msauth.net als zugehörigen Domänen.
2. Wählen Sie bei der Konfiguration der App die Option Anwendungssymbol den Benutzern nicht anzeigen . Einzelheiten finden Sie unter Anwendungsdetails konfigurieren.
3. Erstellen Sie eine Zugriffsrichtlinie für die gemeinsame Anwendung und ermöglichen Sie den Zugriff für alle Benutzer. Einzelheiten finden Sie unter Konfigurieren einer Zugriffsrichtlinie.
4. Weisen Sie der Zugriffsrichtlinie die höchste Priorität zu. Einzelheiten finden Sie unter Prioritätsreihenfolge.
5. Überprüfen Sie die Diagnoseprotokolle, um sicherzustellen, dass der FQDN mit der App übereinstimmt und dass die Richtlinie erwartungsgemäß durchgesetzt wird.

Dieselben verwandten Domains dürfen nicht Teil mehrerer Anwendungen sein

Die zugehörige Domain muss für eine App eindeutig sein. Widersprüchliche Konfigurationen können zu Problemen mit dem App-Zugriff führen. Wenn mehrere Apps mit demselben FQDN oder einer Variante des Platzhalter-FQDN konfiguriert sind, treten möglicherweise die folgenden Probleme auf:

• Die Websites werden nicht mehr geladen oder es wird möglicherweise eine leere Seite angezeigt.
• Die Seite Blockierter Zugriff wird möglicherweise angezeigt, wenn Sie auf eine URL zugreifen.
• Die Anmeldeseite wird möglicherweise nicht geladen.

Daher empfehlen wir, eine eindeutige verwandte Domain zu verwenden, die in einer einzigen App konfiguriert werden kann.

Beispiele für falsche Konfigurationen:

• Beispiel: Duplizieren verwandter Domains in mehreren Anwendungen

  Angenommen, Sie haben 2 Apps, bei denen beide Zugriff auf Okta benötigen (example.okta.com):

  App	Anwendungs-URL-Domäne	Verwandte Domain
  App 1	https://code.example.net	beispiel.okta.com
  App 2	https://info.example.net	beispiel.okta.com

  Richtlinienname	Priorität	Benutzer und zugehörige Apps
  App1 der Personalabteilung verweigern	Hoch	Benutzergruppe HR für App1
  Jedem Zugriff auf App1 gewähren	Medium	Zugriff auf die Benutzergruppe Everyone to App1 aktivieren
  Jedem Zugriff auf App2 gewähren	Niedrig	Zugriff auf die Benutzergruppe “Jeder“ auf App2 aktivieren

  Problem mit der Konfiguration: Obwohl beabsichtigt war, allen Benutzern Zugriff auf App2 zu gewähren, kann die Benutzergruppe HR nicht auf App2 zugreifen. Die Benutzergruppe HR wird zu Okta umgeleitet, hängt aber aufgrund der ersten Richtlinie fest, die den Zugriff auf App1 verweigerte (die auch dieselbe verwandte Domain example.okta.com wie App2 hat).

  Dieses Szenario ist bei Identitätsanbietern wie Okta sehr verbreitet, kann aber auch bei anderen eng integrierten Apps mit gemeinsamen verwandten Domänen auftreten. Einzelheiten zum Abgleich und zur Priorisierung von Richtlinien finden Sie unter Abgleich und Priorisierung von Zugriffsrichtlinien.

  Empfehlung für die obige Konfiguration:

  1. Entfernen Sie example.okta.com als verwandte Domain aus allen Apps.
  2. Erstellen Sie eine neue App nur für Okta (mit der Anwendungs-URL https://example.okta.com und einer zugehörigen Domain von *.okta.com).
  3. Verstecke diese App im Workspace.
  4. Weisen Sie der Richtlinie die höchste Priorität zu, um Konflikte zu beseitigen.

  Bewährtes Verfahren:

  • Die verwandten Domains einer App dürfen sich nicht mit den verwandten Domains einer anderen App überschneiden.
  • In diesem Fall muss eine neue veröffentlichte App erstellt werden, die die gemeinsame verwandte Domain abdeckt, und dann sollte der Zugriff entsprechend eingerichtet werden.
  • Administratoren müssen prüfen, ob diese gemeinsame verwandte Domain als tatsächliche App in Workspace angezeigt werden muss.
  • Wenn die App nicht in Workspace erscheinen darf, wählen Sie beim Veröffentlichen der App die Option Anwendungssymbol den Benutzern nicht anzeigen, um sie in Workspace auszublenden.

Deep-Link-URLs

Für Deep-Link-URLs muss die URL-Domain der Intranetanwendung als zugehörige Domain hinzugefügt werden:

Beispiel:

Die URL der Intranet-App ist https://example.okta.com/deep-link-app-1 als Hauptanwendungs-URL-Domäne konfiguriert, und die zugehörige Domäne hat die URL-Domäne der Intranetanwendung, d. h. *.issues.example.net

Erstellen Sie in diesem Fall separat eine IdP-App mit URL https://example.okta.com und dann der zugehörigen Domain als *.example.okta.com.