当今的 ZTNA 不足以满足多样化的应用

身份验证和授权有多种颜色

零信任网络访问 (ZTNA) 组件 SASE 旨在为 ent 提供安全的入站访问erp增加私人应用程序。 根据零信任架构 (ZTA) 中基于身份的访问控制的核心原则，ZTNA 在验证用户身份并根据用户类型、组和角色对每个 Ent 入站会话执行访问控制方面发挥着至关重要的作用erp上升应用程序。

ZTNA安全在以下场景中具有显着优势：

• 遗留应用程序：出于安全考虑，缺乏内置安全措施的遗留应用程序通常不会暴露给随处工作 (WFA) 用户。 通过利用 ZTNA 作为这些遗留应用程序的前端，可以提供带有证书管理的 HTTPS 终止、使用 OIDC 等协议的身份验证以及基于上下文感知访问控制的授权。 这使得 WFA 用户可以通过 Internet 安全地访问旧版应用程序。
• 损坏的应用程序：尽管在开发时考虑到了安全性，但某些应用程序可能很长时间没有更新。 这些应用程序可能缺乏适当的证书管理，过时或不支持上传新证书或自动续订。 ZTNA 可以作为这些损坏的应用程序的安全替代品，确保安全访问，同时克服其安全限制。
• 新的应用程序架构：现代耳鼻喉科erpRise 应用程序的设计通常会将安全考虑转移到 ZTNA 和服务网格技术等外部实体。 这种方法减轻了应用程序开发人员处理 HTTPS、身份验证和授权的负担，因为安全性已转移到前端实体。 通过集中安全管理，可以实现统一安全策略实施、提高应用程序开发效率以及简化维护等优势。 此外，由于安全更新是在外部处理的，旨在解决安全问题的补丁发布频率可以显着降低。

如今许多 ZTNA 解决方案都擅长前端简单 Enterp崛起的应用程序，但它们无法为多租户应用程序提供身份验证和授权，例如 SaaS 领域广泛应用，提供了卓越的解决方案。

ZTNA 的角色 SaaS 应用程序：在软件即服务的背景下（SaaS我认为，ZTNA 将在加强和增强认证和授权机制方面发挥至关重要的作用。 SaaS 应用程序具有特定的要求，包括多租户、抵御 DoS/DDoS 攻击的弹性以及针对身份验证绕过和权限升级攻击的强大保护。 本文将深入探讨下一代 ZTNA 的功能，这些功能可以帮助减轻或增强身份验证和授权流程 SaaS 应用程序。 请注意，本文不会涵盖 ZTNA 的其他功能，例如 WAAP（Web 应用程序和 API 保护）、HTTPS 终止、各种应用程序实例传入会话的流量管理、SSH/Web 化RDP/VNC 服务，并使应用程序对端口扫描仪不可见。 其主要关注点是 ZTNA 的身份验证和授权方面。

重要的是要注意，角色之间可能会混淆 CASB (Cloud 访问安全代理）和 ZTNA 的背景下 SaaS。 该 CASB 的组成部分 SASE 专注于保护连接 SaaS 耳鼻喉科使用的服务erp上升，其中 enterp上涨的是消费者 SaaS 和 CASB 服务。 另一方面，ZTNA 在 SaaS，旨在保护 SaaS 应用程序本身，使得 SaaS ZTNA 服务的公司消费者。 这种区别对于理解不同角色和职责至关重要 CASB 和 ZTNA 在 SASE 的解决方案。

在之前的文章中关于 身份经纪人，我们探讨了将经纪商纳入其中的众多好处 SASE 解决方案。 讨论的优点主要围绕设计的模块化和简单性，最终增强了 SASE 解决方案。 在本文中，我们将深入探讨身份代理在支持复杂应用程序中的关键作用，特别关注 SaaS 领域广泛应用，提供了卓越的解决方案。

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

ZTNA 的 SASE 擅长为基于策略的授权提供强有力的支持。 内部的授权引擎 SASE 提供管理多个策略表的能力，每个表包含多个策略。 每个策略由多个规则组成，并指定成功匹配后要采取的操作。 规则本身包含各种匹配属性，可以将其分类为源属性和目标属性。

目标属性主要与正在访问的应用程序的资源有关，例如URI 和用于与这些资源交互的方法（例如，GET、PUT、POST、DELETE）。 另一方面，源属性通常与访问资源的主体相关联。 这些属性包含与用户相关的属性，例如名称、组、角色、验证用户凭据的身份验证服务以及其他用户声明。 它们还包括设备上下文属性，这些属性捕获主体使用的设备的安全状态以及用户访问资源的设备的位置。

然而，许多 ZTNA 解决方案在解决全面的身份验证场景方面存在不足，通常将其功能限制为非SaaS 应用程序。 将身份经纪人纳入其中 SASE/SSE 解决方案是朝着实现跨所有类型应用程序的全面身份验证迈出的一步。 虽然可能有人会争辩说 SaaS 供应商拥有在其应用程序中处理身份验证和授权的能力，这一领域已经发生了显着的发展。

在当今敏捷的环境中， SaaS 提供商越来越认识到将安全责任转移给外部实体（例如 SASE。 通过这样做，他们可以提高生产力并增强对整体安全状况的信心，从而受益。 此外，这种方法允许新的 SaaS 提供商可以更快地进入市场，因为他们可以将身份验证和授权转移给外部实体，并主要关注其核心业务逻辑。 SASE 解决方案可以在支持这些新的方面发挥关键作用 SaaS 供应商。

我们相信 SASE 解决方案应该并且将会准备好迎接这一挑战，为复杂的应用程序提供身份验证和授权安全性，例如 SaaS 应用程序。 以下场景给出了一个具有代表性的示例 SaaS 应用并探讨如何 SASE通过集成身份代理，可以帮助从应用程序委派身份验证和授权。

考虑这个例子 SaaS 由多个 API 资源组成的应用程序（托管在 app.example.com）场景：

在这种情况下，我们还假设 IDP SaaS 提供者是 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 租户需要通过 Google 和 Facebook 进行身份验证才能访问公共 API 空间，而 ABC 租户更喜欢通过 LinkedIn 和 GitHub 进行身份验证。

ZTNA中需要以下授权策略来解决上述场景：

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

SASE 解决方案擅长基于属性的访问控制。 这意味着它们可以很好地处理授权功能。 然而，它们在身份验证方面并不是很全面。 在上述策略中，根据用户选择进行身份验证的身份提供商 (IDP) 服务授予不同级别的访问权限。 另外，有些用户可能会故意 want 使用特定的 IDP 服务进行身份验证，以最小的权限访问资源，以避免潜在的数据泄露错误。

身份经纪人的角色

为了解决此类场景，需要身份代理的集成功能。 身份代理充当 OIDC (OpenID Connect) 提供商 SASE/SSE 代理组件，同时充当上游身份服务（身份验证服务）的 OIDC/SAML/LDAP 客户端。

Keycloak 是一个开源 IAM 系统，是许多人的热门选择。 它可以配置为履行身份代理的角色，通常由 SASE 服务提供商和服务网格产品供应商。 因此，这里使用了 Keycloak 术语。 Keycloak 可以灵活地处理各种类型应用程序的身份验证，包括多租户 SaaS 领域广泛应用，提供了卓越的解决方案。

多租户身份验证 SaaS 可以通过以下方式使用“身份代理”来实现应用程序：

一个领域，每个领域一个客户端 SaaS 具有修改后的身份验证流程的应用程序：

如果无法从应用程序中识别应用程序租户 URL 路径或 HTTP 请求标头， SASE 代理组件只能有一个 OIDC 客户端与身份代理进行通信。 在用户身份验证期间，身份代理需要知道要根据哪个 IDP 服务对用户进行身份验证。 Keycloak 提供标准身份验证流程（例如浏览器流程），并允许创建自定义流程并与 Keycloak 客户端关联。 SASE 通过创建身份验证流程来利用此功能，提示用户提供租户信息。 基于此信息，身份验证流程可以提供可用的身份提供商供用户选择。 有了这些信息，代理就可以将用户重定向到适当的身份服务。

一个领域，每个领域有多个客户端 SaaS 应用程序：

如果应用程序租户可以从 URL 或 HTTP 请求标头， SASE 代理组件可以配置为每个应用程序租户使用一个客户端。 在这种情况下，可以采用具有不同身份提供商集的标准浏览器流，并将其与 Keycloak 中相应的客户端实体相关联。 这样做的好处是不会提示用户提供租户名称，因此用户体验更好。

总之，这些策略赋予 SASE 有效处理多租户身份验证的解决方案 SaaS 应用程序，利用 Keycloak 作为身份代理的功能。

基于策略的 OIDC 客户端选择

Keycloak 代理为多个领域和每个领域内的多个客户端提供支持。 它支持标准身份验证流程、自定义身份验证流程的创建以及这些流程与客户端的关联。 Keycloak 代理功能还允许在用户端身份验证机制和后端（上游）身份验证服务之间代理身份验证会话。 我们之前讨论过 Keycloak 如何提示用户识别其应用程序租户并选择身份服务进行身份验证。

这些能力也应该被利用 SASE 代理，充当各种客户应用程序（包括多租户应用程序）的 OIDC 客户端（也称为 OIDC 中继）。

SASE proxy需要支持多个OIDC客户端。 一种方法是为每个客户提供一组 OIDC 客户端，确保特定于客户的身份验证相关配置与其他配置隔离。 通常，每个 SASE 客户的 OIDC 集与 Keycloak 中的领域相关联。

在客户的场景中 SASE proxy有多个应用程序，每个应用程序都有自己的域名，因此有必要在多个应用程序管理员之间提供隔离。 在这种情况下，应配置 OIDC 客户端的子集，为每个应用程序分配一个客户端。

对于许多应用程序来说，如果它们是单租户应用程序或者无法从流量中识别租户（如前所述），则单个 OIDC 客户端就足够了。 但是，如果可以识别租户，则可以为每个应用程序租户配置一个 OIDC 客户端。

由于需要多个 OIDC 客户端， SASE 代理应该提供一种选择适当的 OIDC 客户端的机制。 这就是基于政策的 OIDC 选择变得至关重要的地方。

使用具有多个策略的策略表，每个策略都指向相应的 OIDC 客户端记录。 在车流流动过程中， SASE proxy 检查是否需要 OIDC 身份验证，然后将客户、应用程序域名和应用程序租户与表中的策略进行匹配。 如果找到匹配项，则使用相应的 OIDC 客户端记录与代理进行通信。 一些实现可能有多个策略表，其中一个表专用于每个客户，以加快策略匹配过程。

NextGen ZTNA 将适应多租户应用

ZTNA（零信任网络访问）内 SASE （安全访问服务边缘）解决方案在保护应用程序安全方面发挥着至关重要的作用。 它可以从应用程序中卸载身份验证和授权任务，使开发人员能够专注于其核心业务逻辑。 这种方法提高了生产力并增强了整体安全性。

身份验证绕过和权限提升漏洞在应用程序中很常见，因为并非所有开发人员都具备安全方面的专业知识。 卸载安全性可以消除这些漏洞，确保更强的应用程序弹性。

将安全性集中在一个常见的地方，例如 SASE，简化了安全管理员的工作，他们只需管理所有应用程序的单个界面。

为了实现安全性和灵活性，下一代ZTNA SASE 解决方案应满足不同的应用类型。 许多现有的 ZTNA 解决方案通常难以有效支持多租户应用程序。 未来的增强功能预计将整合身份代理功能和基于策略的 OIDC (OpenID Connect) 客户端选择，以满足广泛的应用场景。

• CTO 见解博客

  Aryaka CTO 见解博客系列提供网络、安全和技术方面的思想领导力 SASE 主题。 为了 Aryaka 产品规格参考 Aryaka 数据表。