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:
- Ordnen Sie die Domain, auf die zugegriffen wird, der Domain der Anwendungs-URL oder verwandten Domains zu, um eine exakte Übereinstimmung zu erhalten.
-
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.
-
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
Zugriffenapp.intranet.local
passiert Folgendes:- Secure Private Access durchsucht in diesem Fall alle Richtlinien nach einer exakten Übereinstimmung mit der Domain,
app.intranet.local
auf die zugegriffen wird. - Secure Private Access findet und prüft
PolicyA
, ob die Bedingungen erfüllt sind. - 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.local
Wiki-App übereinstimmen und Zugriff gewährt wordenPolicyB
wäre.app.intranet.local
- 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
zugreiftapp.intranet.local
, stimmen App1 und App2 auf der Grundlage der exakten FQDN-Übereinstimmung überein, sodass derEng-User5
Benutzer Zugriff über erhält.PolicyA
Hätte App1 jedoch stattdessen eine
*.intranet.local
verwandte Domain, dannEng-User5
wäre der Zugriff für verweigert worden, da genau gepasstapp.intranet.local
hättePolicyB
, für die der Benutzer,Eng-User5
, keinen Zugriff hat. - Secure Private Access durchsucht in diesem Fall alle Richtlinien nach einer exakten Übereinstimmung mit der Domain,
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:
-
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
) konfigurierenlogin.microsoftonline.com
mü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.
- Erstellen Sie eine einzige gemeinsame Anwendung mit
- Wählen Sie bei der Konfiguration der App die Option Anwendungssymbol den Benutzern nicht anzeigen . Einzelheiten finden Sie unter Anwendungsdetails konfigurieren.
- 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.
- Weisen Sie der Zugriffsrichtlinie die höchste Priorität zu. Einzelheiten finden Sie unter Prioritätsreihenfolge.
- Ü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ürApp1
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:
- Entfernen Sie example.okta.com als verwandte Domain aus allen Apps.
- 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
). - Verstecke diese App im Workspace.
- 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
.