当今的 ZTNA 无法满足各种应用的需要

认证与授权有多种颜色可供选择

SASE 的零信任网络访问（ZTNA）组件旨在为企业专用应用程序提供安全的入站访问。 根据零信任架构（ZTA）中基于身份的访问控制这一核心原则，ZTNA 在验证用户身份以及根据用户类型、群组和角色对企业应用程序的每个入站会话实施访问控制方面发挥着至关重要的作用。 ZTNA 安全性在以下情况下具有显著优势：

• 传统应用程序：出于安全考虑，缺乏内置安全措施的传统应用程序通常不向 “随时随地办公”（WFA）用户开放。 利用 ZTNA 作为这些传统应用程序的前端，可以提供具有证书管理功能的 HTTPS 终端、使用 OIDC 等协议的身份验证以及基于上下文感知访问控制的授权。 这样，WFA 用户就可以通过互联网安全地访问传统应用程序。
• 已损坏的应用程序：尽管在开发时考虑到了安全问题，但有些应用程序可能长期未更新。 这些应用程序可能缺乏适当的证书管理，对上传新证书或自动更新的支持过时或不支持。 ZTNA 可以替代这些被破坏的应用程序，确保安全访问，同时克服其安全限制。
• 新的应用架构：现代企业应用程序在设计时通常会将安全考虑因素转移到 ZTNA 和服务网格技术等外部实体上。 这种方法减轻了应用程序开发人员处理 HTTPS、身份验证和授权的负担，因为安全性被卸载到了前端实体。 通过集中安全管理，可实现统一安全策略执行、提高应用程序开发效率和简化维护等优势。 此外，由于安全更新由外部处理，旨在解决安全问题的补丁发布频率可以大大降低。

如今，许多 ZTNA 解决方案都能胜任简单企业应用程序的前端工作，但却无法为 SaaS 应用程序等多租户应用程序提供身份验证和授权。 ZTNA 在 SaaS 应用程序中的作用：我认为，在软件即服务（SaaS）应用中，ZTNA 将在加强和改进身份验证和授权机制方面发挥重要作用。 SaaS 应用程序有特定的要求，包括多租户、抵御 DoS/DDoS 攻击，以及对身份验证绕过和权限升级攻击的强大保护。 本文将深入探讨下一代 ZTNA 的功能，这些功能可帮助卸载或增强 SaaS 应用程序的身份验证和授权流程。 请注意，本文将不涉及 ZTNA 的其他功能，如 WAAP（Web 应用程序和 API 保护）、HTTPS 终止、各种应用程序实例传入会话的流量管理、SSH/RDP/VNC 服务的网络化，以及使应用程序不被端口扫描程序发现。 其主要重点是 ZTNA 的认证和授权方面。 值得注意的是，在 SaaS 的背景下，CASB（云访问安全代理）和 ZTNA 的作用可能会被混淆。 SASE 的 CASB 部分侧重于确保与企业使用的 SaaS 服务的连接安全，而企业是 SaaS 和 CASB 服务的消费者。 另一方面，就 SaaS 而言，ZTNA 旨在保护 SaaS 应用程序本身，使 SaaS 公司成为 ZTNA 服务的消费者。 这种区分对于理解 CASB 和 ZTNA 在 SASE 解决方案中的不同作用和责任至关重要。 在上一篇关于身份代理的文章中，我们探讨了将代理集成到 SASE 解决方案中的诸多好处。 讨论的优势主要围绕设计的模块化和简易性，最终提高 SASE 解决方案的复原力。 在本文中，我们将深入探讨身份代理在支持复杂应用，尤其是 SaaS 应用方面的关键作用。

多用户应用程序面临哪些挑战？

SASE 的 ZTNA 在为基于策略的授权提供强大支持方面表现出色。 SASE 内的授权引擎可管理多个策略表，每个策略表包含多个策略。 每个策略都由多个规则组成，并指定成功匹配后要采取的行动。 规则本身包含各种匹配属性，可分为源属性和目的地属性。 目的地属性主要涉及所访问的应用程序资源，如 URI 和用于与这些资源交互的方法（如 GET、PUT、POST、DELETE）。 另一方面，源属性通常与访问资源的主体相关联。 这些属性包括与用户相关的属性，如姓名、群组、角色、验证用户凭证的认证服务以及其他用户要求。 它们还包括设备上下文属性，这些属性可捕捉主体所使用设备的安全状态以及用户访问资源时所使用设备的位置。 然而，许多 ZTNA 解决方案在处理综合身份验证场景方面存在不足，其功能往往仅限于非服务式应用程序。 在 SASE/SSE 解决方案中加入身份代理是实现所有类型应用全面认证的一个渐进步骤。 虽然可以说 SaaS 供应商具备在其应用程序中处理身份验证和授权的能力，但情况已经发生了重大变化。 在当今敏捷的环境中，SaaS 提供商越来越认识到将安全责任卸载给 SASE 等外部实体的优势。 通过这样做，他们可以提高生产率，增强对整体安全态势的信心。 此外，这种方法还能让新的 SaaS 提供商更快地进入市场，因为他们可以把身份验证和授权工作交给外部实体，而把主要精力放在自己的核心业务逻辑上。 SASE 解决方案可在支持这些新的 SaaS 提供商方面发挥关键作用。 我们相信，SASE 解决方案应该而且将会准备好迎接这一挑战，为复杂的应用程序（如 SaaS 应用程序）提供身份验证和授权安全。 以下场景给出了 SaaS 应用程序的一个代表性示例，并探讨了 SASE 如何通过集成身份代理，帮助应用程序进行身份验证和授权。 请看这个由多个 API 资源组成的 SaaS 应用程序（托管在 app.example.com）示例：

在这种情况下，我们还假设 SaaS 提供商的 IDP 是 example-idp。 有两个租户：XYZ 和 ABC，它们各自的 IDP 服务是 XYZ-idp 和 ABC-idp。 每个租户还有两个合作伙伴，每个合作伙伴都有自己的 IDP 服务。 XYZ-P1-idp 和 XYZ-P2-idp 是 XYZ 合作伙伴的 IDP 服务。 ABC-P1-idp 和 ABC-P2-idp 是 ABC 合作伙伴的 IDP 服务。 此外，XYZ 租户需要通过谷歌和 Facebook 进行身份验证才能访问公共 API 空间，而 ABC 租户则更喜欢通过 LinkedIn 和 GitHub 进行身份验证。 ZTNA 需要以下授权策略来解决上述问题：

1. 域 = app.example.com；user-role=app-admin；authservice=example-idp；uri = /service-admin-api/* ALLOW：允许已成功登录 example-idp 服务并拥有 app-admin 角色的任何用户访问域 app.example.com 的应用程序 admin-api 下的所有资源。
2. Domain = app.example.com; user-group=admin-group; authservice=XYZ-idp; uri = /tenants/XYZ/tenant-admin-api/* ALLOW：允许任何成功登录 XYZ-idp 服务并拥有 admin-group 角色的用户访问 XYZ/tenant-admin-api 下的所有资源。
3. Domain = app.example.com; user-role=admin-role; authservice=ABC-idp; uri = /tenants/ABC/tenant-admin-api/* ALLOW：允许通过 ABC-idp 服务验证的任何具有 admin 角色的用户访问 ABC/tenant-admin-api 资源
4. Domain = app.example.com; authservice=XYZ-idp; uri = /tenants/XYZ/tenant-user-api/*，/tenants/XYZ/collaboration-api/*，/tenants/XYZ/public-api/* ALLOW：允许任何通过 XYZ-idp 服务成功验证的用户访问规则中指定的资源
5. Domain = app.example.com; authservice=ABC-idp; uri = /tenants/ABC/tenant-user-api/*，/tenants/ABC/collaboration-api/*，/tenants/ABC/public-api/* ALLOW：允许任何通过 ABC-idp 服务成功验证的用户访问规则中指定的资源
6. Domain = app.example.com; authservice=XYZ-P1-idp; uri = /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* ALLOW：允许通过 XYZ-P1-idp 服务验证的用户访问 XYZ 协作空间。
7. Domain = app.example.com；authservice=XYZ-P2-idp；uri = /tenants/XYZ/collaboration-api/*，/tenants/XYZ/public-api/* ALLOW：允许通过 XYZ-P2-idp 服务验证的用户访问 XYZ 协作空间。
8. Domain = app.example.com; authservice=ABC-P1-idp; uri = /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* ALLOW：允许通过 ABC-P1-idp 服务验证的用户访问 ABC 协作空间。
9. Domain = app.example.com；authservice=ABC-P2-idp；uri = /tenants/ABC/collaboration-api/*，/tenants/ABC/public-api/* ALLOW：允许通过 ABC-P2-idp 服务验证的用户访问 ABC 协作空间。
10. Domain = app.example.com; authservice=google.com; uri = /tenants/XYZ/public-api/* ALLOW：允许所有通过 google.com 验证的用户访问 XYZ 公共应用程序空间。
11. Domain = app.example.com; authservice=facebook.com; uri = /tenants/XYZ/public-api/* ALLOW：允许所有通过 facebook.com 验证的用户访问 XYZ 公共应用程序空间
12. Domain = app.example.com; authservice=linkedin.com; uri = /tenants/ABC/public-api/* ALLOW：允许所有通过 linkedin.com 验证的用户访问 ABC 公共应用程序空间
13. Domain = app.example.com; authservice=github.com; uri = /tenants/ABC/public-api/* ALLOW：允许所有通过 github.com 验证的用户访问 XYZ 公共应用程序空间
14. Domain（域） = app.example.com； DENY（拒绝）： 如果上述规则均不匹配，则拒绝访问应用程序。

SASE 解决方案擅长基于属性的访问控制。 这意味着它们能很好地处理授权功能。 不过，在身份验证方面，它们并不十分全面。 在上述策略中，根据用户选择验证的身份提供者（IDP）服务，授予不同级别的访问权限。 此外，一些用户可能会故意希望通过特定 IDP 服务进行身份验证，以最小的权限访问资源，从而避免潜在的数据外泄错误。

身份中介的作用

要解决这些问题，就需要身份代理的综合功能。 身份代理作为OIDC（OpenID Connect）提供者向SASE/SSE代理组件提供服务，同时作为OIDC/SAML/LDAP客户端向上游身份服务（认证服务）提供服务。 开源 IAM 系统 Keycloak 是许多人的首选。 它可配置为履行身份代理的角色，通常由 SASE 服务提供商和服务网格产品供应商使用。 因此，这里使用的是 Keycloak 术语。 Keycloak 可灵活处理各种类型应用的身份验证，包括多租户 SaaS 应用。 多租户 SaaS 应用程序的身份验证可通过 “身份代理 “以下列方式实现：每个 SaaS 应用程序有一个领域和一个客户端，并有修改过的身份验证流程： 在无法从 URL 路径或 HTTP 请求头识别应用租户的情况下，SASE 代理组件只能有一个 OIDC 客户端与身份代理进行通信。 在用户身份验证过程中，身份代理需要知道要根据哪个 IDP 服务对用户进行身份验证。 Keycloak 提供标准身份验证流程（如浏览器流程），并允许创建自定义流程和与 Keycloak 客户端关联。 SASE 通过创建身份验证流程，提示用户提供租户信息，从而利用了这一功能。 根据这些信息，身份验证流可以提供可用的身份供应商供用户选择。 有了这些信息，代理就能将用户重定向到适当的身份服务。每个 SaaS 应用程序使用一个领域和多个客户端： 如果可以通过 URL 或 HTTP 请求头识别应用租户，则可将 SASE 代理组件配置为每个应用租户使用一个客户端。 在这种情况下，可以使用具有不同身份提供者集的标准浏览器流，并将其与 Keycloak 中的相应客户端实体关联起来。 这样做的好处是不会提示用户提供租户名称，从而获得更好的用户体验。 总之，这些策略使 SASE 解决方案能够利用 Keycloak 作为身份代理的功能，有效处理多租户 SaaS 应用程序的身份验证。

基于策略的 OIDC 客户选择

Keycloak 代理商支持多个领域和每个领域内的多个客户。 它支持标准身份验证流、自定义身份验证流的创建以及这些流与客户端的关联。 Keycloak 中介功能还允许在用户端认证机制和后端（上游）认证服务之间中介认证会话。 我们之前讨论过 Keycloak 如何提示用户识别其应用租户并选择身份服务进行身份验证。 SASE 代理也应利用这些功能，因为它是各种客户应用程序（包括多租户应用程序）的 OIDC 客户端（也称为 OIDC 中继）。 SASE 代理需要支持多个 OIDC 客户端。 一种方法是为每个客户设置一组 OIDC 客户端，确保客户特定的身份验证相关配置与其他配置隔离。 通常，每个 SASE 客户的 OIDC 集都与 Keycloak 中的一个领域相关联。 在 SASE 代理客户拥有多个应用程序（每个应用程序都有自己的域名）的情况下，有必要在多个应用程序管理员之间提供隔离。 在这种情况下，应配置一个 OIDC 客户端子集，为每个应用程序分配一个客户端。 对于许多应用程序来说，如果它们是单租户应用程序，或者从流量中无法识别租户，那么单个 OIDC 客户端就足够了（如前所述）。 不过，如果可以识别租户，则可以为每个应用程序租户配置一个 OIDC 客户端。 由于需要多个 OIDC 客户端，SASE 代理应提供选择适当 OIDC 客户端的机制。 这就是基于政策的 OIDC 选择变得至关重要的原因。 使用一个包含多个策略的策略表，每个策略都指向相应的 OIDC 客户端记录。 在流量流动过程中，SASE 代理会检查是否需要 OIDC 身份验证，然后根据表中的策略匹配客户、应用域名和应用租户。 如果发现匹配，则使用相应的 OIDC 客户端记录与代理进行通信。 有些实施可能有多个策略表，每个客户专用一个表，以加快策略匹配过程。

下一代 ZTNA 将适应多租户应用

SASE（安全接入服务边缘）解决方案中的 ZTNA（零信任网络接入）在确保应用程序安全方面发挥着至关重要的作用。 它可以卸载应用程序中的身份验证和授权任务，让开发人员专注于核心业务逻辑。 这种方法既能提高生产率，又能增强整体安全性。 身份验证绕过和权限升级漏洞在应用程序中很常见，因为并非所有开发人员都具备安全方面的专业知识。 卸载安全性可以消除这些漏洞，确保应用程序具有更强的恢复能力。 将安全集中到 SASE 等通用系统中，可简化安全管理员的工作，他们只需管理所有应用程序的单一界面。 为了实现安全性和灵活性，SASE 解决方案中的下一代 ZTNA 应能满足各种应用类型的需求。 许多现有的 ZTNA 解决方案往往难以有效支持多租户应用程序。 预计未来的增强功能将包括身份代理功能和基于策略的 OIDC（OpenID Connect）客户端选择，以满足各种应用场景的需要。

• CTO Insights 博客

  Aryaka CTO Insights博客系列提供有关网络、安全和SASE主题的思想领导。
  有关Aryaka产品规格，请参阅Aryaka数据表。