Meilleures pratiques de configuration des applications Web et SaaS
L’accès aux applications publiées et non publiées dépend des applications et des stratégies d’accès configurées dans le service Secure Private Access.
Accès aux applications publiées et non publiées via Secure Private Access
-
Accès aux applications Web publiées et aux domaines associés :
-
Lorsqu’un utilisateur accède à un nom de domaine complet associé à une application Web publiée, l’accès n’est autorisé que si une stratégie d’accès est configurée explicitement avec l’action Autoriser ou Autoriseravec restrictions pour l’utilisateur.
Remarque :
Il est recommandé de faire en sorte que plusieurs applications ne partagent pas le même domaine d’URL d’application ou des domaines associés pour obtenir une correspondance exacte. Si plusieurs applications partagent le même domaine URL d’application ou des domaines associés, l’accès est fourni en fonction de la correspondance exacte du FQDN et de la hiérarchisation des stratégies. Pour plus de détails, consultez la section Correspondance et hiérarchisation des stratégies d’accès.
-
Si aucune stratégie d’accès ne correspond à l’application publiée ou si aucune application n’est associée à une stratégie d’accès, l’accès à l’application est refusé par défaut. Pour plus de détails sur les stratégies d’accès, voir Stratégies d’accès.
-
-
Accès à des applications Web internes non publiées et à des URL Internet externes :
Pour activer la sécurité Zero Trust, Secure Private Access refuse l’accès aux applications Web internes ou aux URL intranet qui ne sont pas associées à une application et pour lesquelles aucune stratégie d’accès n’est configurée pour l’application. Pour autoriser l’accès à des utilisateurs spécifiques, assurez-vous qu’une stratégie d’accès est configurée pour vos applications Web intranet.
Pour toute URL qui n’est pas configurée en tant qu’application dans Secure Private Access, le trafic est directement dirigé vers Internet.
- Dans de tels cas, l’accès aux domaines URL des applications Web de l’intranet est acheminé directement et l’accès est donc refusé (sauf si l’utilisateur se trouve déjà dans l’intranet).
- Pour les URL Internet non publiées, l’accès dépend des règles configurées pour les applications non autorisées, si elles sont activées. Par défaut, cet accès est autorisé dans Secure Private Access. Pour plus de détails, voir Configurer les règles pour les sites Web non autorisés.
Correspondance et hiérarchisation des stratégies d’accès
Secure Private Access effectue les opérations suivantes lorsqu’une application correspond à la stratégie d’accès :
- Fait correspondre le domaine auquel vous accédez au domaine de l’URL de l’application ou à des domaines associés pour obtenir une correspondance exacte.
-
Si une application Secure Private Access configurée avec un FQDN à correspondance exacte est trouvée, Secure Private Access évalue toutes les stratégies configurées pour cette application.
- Les stratégies sont évaluées par ordre de priorité jusqu’à ce que le contexte utilisateur corresponde. L’action (autoriser/refuser) est appliquée à la première stratégie correspondante dans l’ordre de priorité.
- Si aucune stratégie ne correspond, l’accès est refusé par défaut.
-
Si aucune correspondance exacte de nom de domaine complet n’est trouvée, Secure Private Access fait correspondre le domaine en fonction de la correspondance la plus longue (telle qu’une correspondance de caractères génériques) pour rechercher les applications et les stratégies correspondantes.
Exemple 1 : considérez les configurations d’applications et de stratégies suivantes :
Application URL de l’application Domaine associé Intranet https://app.intranet.local
*.cdn.com Wiki https://wiki.intranet.local
*.intranet.local Nom de la stratégie Priorité Applications utilisateur et associées Stratégie A Élevé Eng-User5 (Intranet) Stratégie B Faible Utilisateur RH 4 (Wiki) Si
HR-User4
accède àapp.intranet.local
, voici ce qui se passe :- Secure Private Access recherche toutes les stratégies présentant une correspondance exacte avec le domaine auquel vous accédez,
app.intranet.local
dans le cas présent. - Secure Private Access trouve
PolicyA
et vérifie si les conditions correspondent. - Étant donné que les conditions ne correspondent pas, Secure Private Access s’arrête là et ne vérifie pas les correspondances de caractères génériques, même si la stratégie
PolicyB
aurait correspondu (puisqueapp.intranet.local
correspond au domaine associé de l’application Wiki*.intranet.local
) et aurait autorisé l’accès. - L’accès à l’application Wiki
HR-User4
est donc refusé.
Exemple 2 : considérez la configuration des applications et des stratégie suivante dans laquelle le même domaine est utilisé dans plusieurs applications :
Application URL de l’application Domaine associé App1 xyz.com app.intranet.local App2 app.intranet.local - Nom de la stratégie Priorité Applications utilisateur et associées Stratégie A Élevé Eng-User5 (App1) Stratégie B Faible Utilisateur RH 7 (App 2) Lorsque l’utilisateur
Eng-User5
accède àapp.intranet.local
, App1 et App2 correspondent en raison de la correspondance exacte du FQDN et, par conséquent, l’accès de l’utilisateurEng-User5
viaPolicyA
est autorisé.Cependant, si le domaine associé d’App1 avait été
*.intranet.local
, l’accès àEng-User5
aurait été refusé, carapp.intranet.local
aurait correspondu exactement à la stratégiePolicyB
, qui interdit l’accès de l’utilisateurEng-User5
. - Secure Private Access recherche toutes les stratégies présentant une correspondance exacte avec le domaine auquel vous accédez,
Meilleures pratiques en matière de configuration des applications
Les domaines IDP doivent disposer de leur propre application
Au lieu d’ajouter des domaines IDP en tant que domaines associés dans les configurations de votre application intranet, nous vous recommandons de procéder comme suit :
- Créez des applications distinctes pour tous les domaines IDP.
- Créez une stratégie autorisant tous les utilisateurs qui en ont besoin à accéder à la page d’authentification IDP, puis accordez la priorité absolue à cette stratégie.
- Masquez cette application (en sélectionnant l’option Ne pas afficher l’icône de l’application aux utilisateurs) dans la configuration de l’application afin qu’elle ne soit pas énumérée sur l’espace de travail. Pour plus d’informations, voir Configurer les détails de l’application.
Remarque :
cette configuration d’application permet uniquement l’accès à la page d’authentification IDP. L’accès ultérieur à des applications individuelles dépend toujours des configurations individuelles des applications et de leurs stratégies d’accès respectives.
Exemple de configuration :
-
Configurez tous les FQDN courants dans leurs propres applications, en les regroupant le cas échéant.
Par exemple, si quelques applications utilisent Azure AD comme fournisseur d’identité et que vous devez configurer
login.microsoftonline.com
et d’autres domaines associés (*.msauth.net
), procédez comme suit :- Créez une seule application commune avec
https://login.microsoftonline.com
comme URL de l’application*.login.microsoftonline.com
et*.msauth.net
comme domaines associés.
- Créez une seule application commune avec
- Sélectionnez l’option Ne pas afficher l’icône de l’application aux utilisateurs lors de la configuration de l’application. Pour plus de détails, voir Configurer les détails de l’application.
- Créez une stratégie d’accès pour l’application commune et autorisez l’accès à tous les utilisateurs. Pour plus de détails, voir [Configurer une stratégie d’accès]((/en-us/citrix-secure-private-access/service/admin-guided-workflow-for-easy-onboarding-and-setup#step-3-configure-an-access-policy-with-multiple-rules).
- Attribuez la priorité la plus élevée à la stratégie d’accès. Pour plus de détails, voir Ordre prioritaire.
- Consultez les journaux de diagnostic pour vérifier que le nom de domaine complet correspond à l’application et que la stratégie est appliquée comme prévu.
Les mêmes domaines associés ne doivent pas faire partie de plusieurs applications
Le domaine associé doit être propre à une application. Des configurations conflictuelles peuvent entraîner des problèmes d’accès aux applications. Si plusieurs applications sont configurées avec le même nom de domaine complet ou une variante du nom de domaine complet générique, vous risquez de rencontrer les problèmes suivants :
- Les sites Web cessent de se charger ou peuvent afficher une page blanche.
- La page Accès bloqué peut s’afficher lorsque vous accédez à une URL.
- Il est possible que la page de connexion ne se charge pas.
Nous vous recommandons donc de configurer un domaine associé unique dans une seule application.
Exemples de configuration incorrecte :
-
Exemple : dupliquer des domaines associés dans plusieurs applications
Supposons que vous disposiez de deux applications nécessitant toutes deux un accès à Okta (example.okta.com) :
Application domaine de l’URL de l’application Domaine associé App1 https://code.example.net
exemple.okta.com App2 https://info.example.net
exemple.okta.com Nom de la stratégie Priorité Applications utilisateur et associées Refuser App1 à HR Élevé Groupe d’utilisateurs HR
pourApp1
Autoriser tout le monde à accéder à App1 Moyen Activer l’accès du groupe d’utilisateurs Everyone à App1 Autoriser tout le monde à accéder à App2 Faible Activer l’accès du groupe d’utilisateurs « Tout le monde » à App2 Problème de configuration : bien que l’intention était d’autoriser tous les utilisateurs à accéder à App2, le groupe d’utilisateurs HR ne peut pas accéder à App2. Le groupe d’utilisateurs HR est redirigé vers Okta, mais est bloqué en raison de la première stratégie qui a refusé l’accès à App1 (qui possède également le même domaine associé
example.okta.com
qu’App2).Ce scénario est très courant pour les fournisseurs d’identité tels qu’Okta, mais il peut également se produire avec d’autres applications étroitement intégrées ayant des domaines associés communs. Pour plus de détails sur la correspondance et la hiérarchisation des stratégies, voir Correspondance et priorisation des stratégies d’accès.
Recommandation pour la configuration ci-dessus :
- Supprimez example.okta.com en tant que domaine associé de toutes les applications.
- Créez une nouvelle application uniquement pour Okta (avec l’URL de l’application
https://example.okta.com
et un domaine associé de*.okta.com
). - Masquez cette application sur l’espace de travail.
- Attribuez la priorité la plus élevée à la stratégie afin de supprimer tout conflit.
Meilleure pratique :
- Les domaines associés d’une application ne doivent pas chevaucher les domaines associés d’une autre application.
- Dans ce cas, une nouvelle application publiée doit être créée pour couvrir le domaine associé partagé, puis l’accès doit être défini en conséquence.
- Les administrateurs doivent évaluer si ce domaine associé partagé doit apparaître en tant qu’application réelle dans Workspace.
- Si l’application ne doit pas apparaître dans Workspace, lors de la publication de l’application, sélectionnez l’option Ne pas afficher l’icône de l’application aux utilisateurs pour la masquer dans Workspace.
URL de lien profond
Pour les URL de lien profond, le domaine de l’URL de l’application intranet doit être ajouté en tant que domaine associé :
Exemple :
L’URL de l’application intranet est configurée avec https://example.okta.com/deep-link-app-1
comme domaine d’URL principal et le domaine associé est configuré avec le domaine de l’URL de l’application intranet, c’est-à-dire *.issues.example.net
.
Dans ce cas, créez séparément une application IdP avec une URL https://example.okta.com
puis un domaine associé tel que *.example.okta.com
.