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 :

1. 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.

2. 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.

3. 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 :

   1. 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.
   2. Secure Private Access trouve PolicyAet vérifie si les conditions correspondent.
   3. É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 (puisque app.intranet.local correspond au domaine associé de l’application Wiki *.intranet.local) et aurait autorisé l’accès.
   4. 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’utilisateur Eng-User5 via PolicyA est autorisé.

   Cependant, si le domaine associé d’App1 avait été *.intranet.local, l’accès à Eng-User5 aurait été refusé, car app.intranet.local aurait correspondu exactement à la stratégie PolicyB, qui interdit l’accès de l’utilisateur Eng-User5.

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 :

1. 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.
2. 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.
3. 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).
4. Attribuez la priorité la plus élevée à la stratégie d’accès. Pour plus de détails, voir Ordre prioritaire.
5. 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 pour App1
  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 :

  1. Supprimez example.okta.com en tant que domaine associé de toutes les applications.
  2. 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).
  3. Masquez cette application sur l’espace de travail.
  4. 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.