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

已发布和未发布应用程序的应用程序访问权限取决于在 Secure Private Access 服务中配置的应用程序和访问策略。

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

• 访问已发布的 Web 应用程序和相关域：

  • 当最终用户访问与已发布的 Web 应用程序关联的 FQDN 时，只有在为用户明确配置了访问策略“允许”或“有限制地允许”操作时，才允许访问。

    注意：

    建议不要让多个应用程序共享同一个应用程序 URL 域或相关域以实现精确匹配。如果多个应用程序共享同一个应用程序 URL 域或相关域，则将根据精确的 FQDN 匹配和策略优先级提供访问权限。有关详细信息，请参阅访问策略匹配和优先级。

  • 如果没有任何访问策略与已发布的应用程序相匹配，或者应用程序与任何访问策略均不关联，则默认情况下，对该应用程序的访问将被拒绝。有关访问策略的详细信息，请参阅访问策略。

• 访问未发布的内部 Web 应用程序和外部 Internet URL：

  为了启用零信任，Secure Private Access 拒绝访问与应用程序无关且未为应用程序配置访问策略的内部 Web 应用程序或内联网 URL。要允许特定用户访问，请确保为 Intranet 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	相关域
   Intranet	https://app.intranet.local	*.cdn.com
   Wiki	https://wiki.intranet.local	*.intranet.local

   策略名称	优先级	用户和关联应用程序
   PolicyA	高	Eng-User5（内联网）
   PolicyB	低	HR-User4 (Wiki)

   如果 HR-User4 访问 app.intranet.local，则会发生以下情况：

   1. Secure Private Access 会在所有策略中搜索与正在访问的域名完全匹配的内容，在这种情况下为 app.intranet.local。
   2. Secure Private Access 会查找 PolicyA 并检查条件是否匹配。
   3. 由于条件不匹配，Secure Private Access 在此停止，不会继续检查通配符是否匹配，尽管 PolicyB 本来可以匹配（因为在 Wiki 应用程序的相关域 *.intranet.local 中 app.intranet.local 确实匹配）并给出了访问权限。
   4. 因此 HR-User4 被拒绝访问维基应用程序。

   示例 2：考虑以下应用程序和策略配置，其中在多个应用程序中使用同一个域：

   应用程序	应用程序 URL	相关域
   App1	xyz.com	app.intranet.local
   App2	app.intranet.local	-

   策略名称	优先级	用户和关联应用程序
   PolicyA	高	Eng-User5 (App1)
   PolicyB	低	HR-User7 (App2)

   当用户 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 时，可能会出现“阻止访问”页面。
• 登录页面可能无法加载。

因此，我们建议在单个应用程序中配置唯一的相关域。

错误的配置示例：

• 示例：在多个应用程序中复制相关域

  假设您有 2 个应用程序都需要访问 Okta（example.okta.com）：

  应用程序	应用程序 URL 域	相关域
  App1	https://code.example.net	example.okta.com
  App2	https://info.example.net	example.okta.com

  策略名称	优先级	用户和关联应用程序
  拒绝 App1 给 HR	高	App1 的用户组 HR
  授予所有人访问 App1 的权限	中	允许访问用户组 Everyone to App1
  授予所有人访问 App2 的权限	低	允许访问用户组“所有人”对 App2 的访问权限

  配置问题： 尽管目的是向所有用户授予对 App2 的访问权限，但用户组 HR 无法访问 App2。HR 用户组被重定向到 Okta，但由于第一个拒绝访问 App1（也与 App2 具有相同的相关域 example.okta.com）的策略而被卡住。

  这种情况对于诸如 Okta 之类的身份提供商来说非常常见，但也可能发生在具有共同相关域的其他紧密集成的应用程序中。有关策略匹配和优先级的详细信息，请参阅访问策略匹配和优先级划分。

  上述配置的建议：

  1. 从所有应用程序中移除 example.okta.com 作为相关域名。
  2. 仅为 Okta 创建新应用（应用 URL 为 https://example.okta.com ，相关域为 *.okta.com）。
  3. 在工作区中隐藏此应用程序。
  4. 为策略分配最高优先级，以消除任何冲突。

  最佳实践：

  • 应用程序的相关网域不得与其他应用程序的相关网域重叠。
  • 如果发生这种情况，必须创建一个新发布的应用程序以覆盖共享的相关域，然后应相应地设置访问权限。
  • 管理员必须评估此共享相关域是否需要在 Workspace 中显示为实际应用程序。
  • 如果应用程序不得出现在 Workspace 中，则在发布应用程序时，选择“不向用户显示应用程序图标”选项以将其隐藏在 Workspace 中。

深度链接 URL

对于深度链接 URL，必须将内联网应用程序 URL 域添加为相关域：

示例：

内联网应用程序配置了 https://example.okta.com/deep-link-app-1 URL 作为主应用程序 URL 域，相关域具有 Intranet 应用程序 URL 域，即 *.issues.example.net。

在这种情况下，使用 URL https://example.okta.com 分别创建 IdP 应用程序， 然后将相关域名设置为 *.example.okta.com。