Web 和 SaaS 应用程序配置的最佳实践

Last published : Oct 24, 2026
已发布和未发布的应用程序的应用程序访问取决于 Secure Private Access 服务中配置的应用程序和访问策略。
Related information
应用程序配置和管理

Secure Private Access 中已发布和未发布应用程序的应用程序访问

  • 访问已发布的 Web 应用程序和相关域：
    • 当最终用户访问与已发布的 Web 应用程序关联的 FQDN 时，仅当为该用户明确配置了操作为 允许 或 允许（带限制） 的访问策略时，才允许访问。
      注意：
      建议不要让多个应用程序共享相同的应用程序 URL 域或相关域以进行精确匹配。如果多个应用程序共享相同的应用程序 URL 域或相关域，则根据精确的 FQDN 匹配和策略优先级提供访问。有关详细信息，请参阅访问策略匹配和优先级。
    • 如果没有访问策略与已发布的应用程序匹配，或者应用程序未与任何访问策略关联，则默认情况下拒绝访问该应用程序。有关访问策略的详细信息，请参阅自适应访问策略配置和管理。
  • 访问未发布的内部 Web 应用程序和外部 Internet URL：
    为了启用零信任，Secure Private Access 拒绝访问未与应用程序关联且未配置应用程序访问策略的内部 Web 应用程序或内网 URL。要允许特定用户访问，请确保为您的内网 Web 应用程序配置了访问策略。
    对于 Secure Private Access 中未配置为应用程序的任何 URL，流量将直接流向 Internet。
    • 在这种情况下，对内网 Web 应用程序 URL 域的访问将直接路由，因此访问被拒绝（除非用户已在内网中）。
    • 对于未发布的 Internet URL，如果启用，访问将基于为未经批准的应用程序配置的规则。默认情况下，Secure Private Access 允许此访问。

访问策略匹配和优先级

Secure Private Access 在匹配应用程序以进行访问时执行以下操作：
  1. 将访问的域与应用程序 URL 的域或相关域进行精确匹配。
  2. 如果找到配置了精确 FQDN 匹配的 Secure Private Access 应用程序，则 Secure Private Access 会评估为该应用程序配置的所有策略。
    • 策略按优先级顺序进行评估，直到用户上下文匹配。操作（允许/拒绝）将根据优先级顺序中第一个匹配的策略应用。
    • 如果没有策略匹配，则默认拒绝访问。
  3. 如果未找到精确的 FQDN 匹配，则 Secure Private Access 会根据最长匹配（例如通配符匹配）来匹配域，以查找应用程序和相应的策略。
    示例 1：考虑以下应用程序和策略配置：
    应用程序 应用程序 URL 相关域
    内网 https://app.intranet.local *.cdn.com
    维基 https://wiki.intranet.local *.intranet.local
    策略名称 优先级 用户和关联应用程序
    PolicyA 高 Eng-User5 (内网)
    PolicyB 低 HR-User4 (维基)
    如果 HR-User4 访问 app.intranet.local，则会发生以下情况：
    1. Secure Private Access 会搜索所有策略，以查找与所访问域（在本例中为 app.intranet.local）的精确匹配项。
    2. Secure Private Access 找到 PolicyA，并检查条件是否匹配。
    3. 由于条件不匹配，Secure Private Access 在此处停止，并且不会继续检查通配符匹配项，即使 PolicyB 本来会匹配（因为 app.intranet.local 确实与 Wiki 应用程序的 *.intranet.local 相关域匹配）并授予访问权限。
    4. 因此，HR-User4 被拒绝访问 Wiki 应用程序。
    示例 2：考虑以下应用程序和策略配置，其中在多个应用程序中使用相同的域：
    应用程序 应用程序 URL 相关域
    App1 xyz.com app.intranet.local
    App2 app.intranet.local -
    策略名称 优先级 用户和关联的应用程序
    PolicyA 高 Eng-User5 (应用1)
    PolicyB 低 HR-用户7 (应用2)
    当用户 Eng-User5 访问 app.intranet.local 时，App1 和 App2 都将根据精确的 FQDN 匹配进行匹配，因此 Eng-User5 用户通过 PolicyA 获得访问权限。
    但是，如果 App1 将 *.intranet.local 作为相关域，那么对 Eng-User5 的访问将被拒绝，因为 app.intranet.local 将精确匹配 PolicyB，而用户 Eng-User5 没有访问权限。

应用程序配置最佳实践

以下部分提供了有关应用程序配置最佳实践的更多信息。

IdP 域必须拥有自己的应用程序

建议不要将 IdP 域作为相关域添加到您的内部网应用程序配置中，而是建议执行以下操作：
  • 为所有 IdP 域创建单独的应用程序。
  • 创建策略以允许所有需要访问 IdP 身份验证页面的用户访问，并将该策略设置为最高优先级。
  • 从应用程序配置中隐藏此应用程序（通过选择“不向用户显示应用程序图标”选项），以使其不会在商店中列出。有关信息，请参阅 配置应用程序详细信息。
隐藏应用程序
注意：
此应用程序配置仅启用对 IdP 身份验证页面的访问。对单个应用程序的进一步访问仍取决于各个应用程序配置及其各自的访问策略。
示例配置：
  1. 将所有常见的 FQDN 配置到各自的应用程序中，并在适用时将其分组。
    例如，如果您有几个应用程序使用 Azure AD 作为 IdP，并且您必须配置 login.microsoftonline.com 和其他相关域 (*.msauth.net)，请执行以下操作：
    • 创建一个通用应用程序，其中 https://login.microsoftonline.com 作为应用程序 URL，*.login.microsoftonline.com 和 *.msauth.net 作为相关域。
  2. 在配置应用程序时，选择不向用户显示应用程序图标选项。有关详细信息，请参阅配置应用程序详细信息。
  3. 为通用应用程序创建访问策略，并为所有用户启用访问。有关详细信息，请参阅配置访问策略。
  4. 为访问策略分配最高优先级。有关详细信息，请参阅优先级顺序。
  5. 验证诊断日志，确认 FQDN 与应用程序匹配，并且策略按预期执行。

相同的相关域不得属于多个应用程序

相关域必须是应用程序独有的。冲突的配置可能会导致应用程序访问问题。如果多个应用程序配置了相同的 FQDN 或通配符 FQDN 的某种变体，则可能会遇到以下问题：
  • 网站停止加载或可能显示空白页。
  • 访问 URL 时可能会出现访问被阻止页面。
  • 登录页面可能无法加载。
因此，我们建议在单个应用程序中配置唯一的关联域。
不正确的配置示例：
  • 示例：跨多个应用程序的重复相关域
    假设您有两个应用程序，两者都需要访问 Okta (example.okta.com)：
    应用程序 应用程序 URL 域 相关域
    App1 https://code.example.net example.okta.com
    App2 https://info.example.net example.okta.com
    策略名称 优先级 用户和关联的应用程序
    拒绝 App1 访问 HR 高 用户组 HR 适用于 App1
    授予“所有人”访问 App1 的权限 中 允许用户组“所有人”访问 App1
    授予“所有人”访问 App2 的权限 低 允许用户组“所有人”访问 App2
    配置问题： 尽管目的是让所有用户访问 App2，但用户组 HR 无法访问 App2。用户组 HR 被重定向到 Okta，但由于第一个拒绝访问 App1 的策略而被阻止（App1 也具有与 App2 相同的相关域 example.okta.com）。
    这种情况对于 Okta 等身份提供商很常见，但也可能发生在其他具有共同相关域的紧密集成应用程序中。有关策略匹配和优先级的详细信息，请参阅访问策略匹配和优先级。
    上述配置的建议：
    1. 从所有应用程序中删除 example.okta.com 作为相关域。
    2. 专门为 Okta 创建一个新应用程序（其应用程序 URL 为 https://example.okta.com，相关域为 *.okta.com）。
    3. 从商店中隐藏此应用程序。
    4. 为策略分配最高优先级以消除任何冲突。
    最佳实践：
    • 一个应用程序的相关域不得与另一个应用程序的相关域重叠。
    • 如果发生这种情况，必须创建一个新的已发布应用程序来覆盖共享的相关域，然后相应地设置访问权限。
    • 管理员必须评估此共享相关域是否必须作为实际应用程序出现在商店中。
    • 如果应用程序不应出现在商店中，则在发布应用程序时，选择不向用户显示应用程序图标选项以将其从商店中隐藏。

解决相同相关域导致的冲突

在应用程序相关域与另一个应用程序域重叠的场景中，管理员可以根据特定要求，通过连接器设备将这些应用程序路由到外部或内部。 Secure Private Access 控制台中的路由表（设置 > 应用程序域）提供了所有应用程序所有已配置域的全面列表。此表显示了每个域的关键信息，包括路由类型。管理员可以通过单击相应域条目旁边的编辑图标轻松修改路由类型。
主路由表显示任何域的以下信息：
  • FQDN/IP： 期望配置流量路由类型的 FQDN 或 IP 地址。
  • 类型： 应用程序类型。添加应用程序时选择的内部、内部 – 绕过代理或外部。
    • 内部 - 应用程序是外部的，但流量必须通过连接器设备流向外部网络。
    • 内部 – 绕过代理 - 域流量通过 Citrix Cloud Connector™ 路由，绕过在连接器设备上配置的客户 Web 代理。
    • 外部 – 流量直接流向互联网。
    重要：
    如果存在冲突，则表中相应行会显示一个警报图标。要解决冲突，管理员应单击与该条目关联的三角形图标并更改应用程序类型。
  • 资源位置： 内部类型路由的资源位置。如果未分配资源位置，则在相应应用程序的“资源位置”列中显示一个三角形图标。将鼠标悬停在图标上时，将显示以下消息。
    缺少资源位置。确保此 FQDN 关联了资源位置。
  • 状态： “状态”列中的切换开关可用于禁用路由条目的路由，而无需删除应用程序。当切换开关关闭时，路由条目不生效。此外，如果存在精确匹配的 FQDN，管理员可以选择启用或禁用路由。
  • 备注： 显示备注（如果有）。
  • 操作： 编辑图标用于添加资源位置或更改路由条目类型。删除图标用于删除路由。
注意：
应用程序域表的迷你版本可用于在应用程序配置期间做出路由决策。迷你路由表可在 Citrix Secure Private Access™ 服务管理控制台的“应用程序连接”部分中找到。

深层链接 URL

对于深层链接 URL，必须将内部网应用程序 URL 域添加为相关域：
示例：
内部网应用程序的 URL 配置为 https://example.okta.com/deep-link-app-1 作为主应用程序 URL 域，相关域具有内部网应用程序 URL 域，即 *.issues.example.net。
在这种情况下，单独创建一个 URL 为 https://example.okta.com 的 IdP 应用程序，然后将相关域设置为 *.example.okta.com。