Gartner零信任网络访问市场指南 (2020版)

文/柯善学编译

数字业务的现实是，它需要随时随地访问任何应用程序，而不管用户及其设备的位置如何。而ZTNA（零信任网络访问）恰恰使能了本不适合传统访问方法的数字业务转型场景。尤其是对于那些寻求更灵活、更具响应性的方式与数字业务生态系统、远程工作者、外部合作伙伴进行连接和协作的组织，ZTNA再适合不过。

ZTNA削弱了网络位置的优势地位，消除了过度的隐式信任，代之以显式的基于身份的信任。从某种意义上说，ZTNA创建了个性化的“虚拟边界”，该边界仅包含用户、设备、应用程序。ZTNA还规范了用户体验，消除了在与不在企业网络中所存在的访问差异。最关键的是，它还将横向移动的能力降到最低。

Gartner旗帜鲜明地建议：安全和风险管理领导人应试点ZTNA项目以作为SASE（安全访问服务边缘）战略的一部分，或迅速扩大远程访问。同时也指出：尽管VPN替换是ZTNA采用的一个常见驱动因素，但ZTNA很少能完全替换VPN。2020版指南延续了2019版市场指南中关于ZTNA产品的实现方式（端点启动和服务启动）和ZTNA产品市场的分类方式（即服务产品和独立产品）。

虽然Gartner报告一贯前瞻，但该指南也罗列了一些务实的做法，即在零信任架构还无法全面实现的情况下，如何使用现用技术提升安全性。这样的技术包括：传统VPN、DMZ、PAM、WAF、虚拟桌面、远程浏览器隔离、CDN、API网关。可参见本文“ZTNA备选方案”小节。

综合该指南中“市场建议”和“评估因素”章节内容，可以看出：为了构建一套基于零信任的完整身份访问安全体系，应聚合人员、设备、程序等主体的数字身份、认证因素和IT服务资源属性、环境属性、数据资源安全属性等数据，结合访问控制策略数据，形成统一身份数据视图；应面向云、大数据平台、应用系统的服务与资源，建立基于资源属性的数字身份统一授权管控策略，实现人机交互、系统间互访的统一授权管理，以及基于零信任的细颗粒度访问控制；应集成多因素身份认证（MFA），支撑高强度身份认证；应集成用户行为分析（UEBA），支撑对异常行为的发现与处置。这些都是不可或缺的要素。

本报告译自2020年6月份发布《Gartner零信任网络访问市场指南（2020版）》。虽然从名称上看，这只是一篇市场指南，但其中言简意赅地反映了零信任的诸多技术要点和趋势，值得技术专家了解和关注。

本想只做摘录，但原文很短，译文也就万言。故简单照搬，仅做少许结构调整。并无商业目的，主要是与业界同步信息。若有不妥，请联系笔者删除。

本文目录

一、概述

1）主要发现

2）主要建议

二、市场定义和价值主张

1）ZTNA市场定义

2）ZTNA市场描述

3）ZTNA价值主张

三、市场方向

1）端点启动的ZTNA

2）服务启动的ZTNA

四、市场分析

1）好处和用途

2）风险

3）ZTNA评估因素

4）ZTNA备选方案

五、代表性供应商

1）市场产品分类

2）即服务产品的供应商

3）独立产品的供应商

4）产品选择的趋势

六、市场建议

一、概述

主要发现

• 数字化业务转型要求系统、服务、应用程序编程接口、数据和流程能够通过多种机制随时随地从互联网上的任何用户设备访问。这扩大了攻击者的攻击范围。

• 用户和应用程序已经在云中。因此，安全访问能力也必须向云交付发展。

  许多零信任网络访问产品都是基于云的。

• 传统网络、VPN、DMZ（非军事区）架构中用于建立访问的IP地址和网络位置，通常配置为允许过度的隐式信任和未修复的漏洞，从而使企业面临攻击风险。

• ZTNA提供自适应、身份识别、精确访问。

  它削弱了网络位置的优势地位，消除了过度的隐式信任，代之以显式的基于身份的信任。

• ZTNA提高了应用程序访问的灵活性、敏捷性、可扩展性，使数字业务能够蓬勃发展，而无需将内部应用程序直接暴露在互联网上，降低了攻击风险。

• 尽管VPN替换是ZTNA采用的一个常见驱动因素，但ZTNA很少完全替换VPN。

• 组织通过ZTNA，可以允许非受管设备和外部合作伙伴安全地访问应用程序，而无需信任设备连接。

• 最近向远程劳动力的转移，加速了ZTNA的采用，以解决传统VPN访问的硬件和带宽限制。

主要建议

负责基础设施安全的安全和风险管理领导，应该：

• 部署ZTNA产品，该产品依赖于多个上下文因素，以建立和调整应用程序级访问的信任。

  停止那些主要依赖IP地址和网络位置作为信任的代理。

• 如果您的传统远程访问VPN由于扩大的远程劳动力而遇到容量或带宽限制，请评估使用基于云的ZTNA来卸载一些用例。

• 替换面向员工和合作伙伴的应用程序的设计，这些应用程序将服务暴露于直接的互联网连接。

  一个特别有益的用例是试点一种数字业务服务的ZTNA部署，在该服务中需要合作伙伴能够访问。

• 对不需要全面网络访问的用户，逐步淘汰基于传统VPN的接入，并开始逐步采用ZTNA。

  这减少了对支持广泛部署的VPN代理的持续需求，并引入了无代理的身份和设备感知访问，这有助于从受管和非受管设备进行访问。

• 选择与通用多因素认证产品集成的ZTNA产品，将身份保证扩展到单一因素之外，这是对基于上下文的自适应访问控制ZTNA原则的重要补充。

• 选择与组织的安全访问服务边缘（SASE）架构计划一致的ZTNA产品，或展示强大的供应商安全访问服务边缘（SASE）产品路线图，以使未来的网络和安全，能从云端作为服务交付。

二、市场定义和价值主张

ZTNA市场定义

Gartner将零信任网络访问（ZTNA）定义为一种产品和服务，这些产品和服务创建了一个基于身份和上下文的逻辑访问边界，该边界围住了一个用户和一个应用程序或一组应用程序。

应用程序被隐藏以避免被发现，并且通过信任代理将访问限制为命名实体的集合。信任代理在允许访问之前验证指定参与者的身份、上下文和策略遵从性，并最小化网络中其他位置的横向移动。

ZTNA消除了经常伴随其他形式的应用程序访问的过度隐式信任。

ZTNA市场描述

打破了原有的“内部即可信”、“外部即不可信”的安全模式。当用户成为移动用户，当“外部”业务伙伴需要访问时，虚拟专用网（VPN）和非军事区（DMZ）就变得普遍起来，但它们同时给予攻击者滥用的过度隐性信任。数字业务的现实是，它需要随时随地访问任何应用程序，而不管用户及其设备的位置如何。

新模型——零信任网络（ZTN，zero-trust networking）——提出了一种抽象和集中化访问机制的方法，使得安全工程师和工作人员能够对其负责。ZTNA以零信任的默认拒绝姿态开始。它基于人员及其设备的身份以及其他属性和上下文（如时间/日期、地理位置和设备姿态）授予访问权限，并自适应地提供当时所需的适当信任。其结果是一个更具弹性的环境，具有更好的灵活性和更好的监控。ZTNA在呼唤那些寻求更灵活、更具响应性的方式与数字业务生态系统、远程工作者、合作伙伴进行连接和协作的组织。

ZTNA提供了对资源的可控的身份感知和上下文感知的访问，减少了攻击面。ZTNA提供的隔离性，提升了连接性，消除了直接向Internet公开应用程序的需要。Internet仍然是不受信任的传输；信任代理调解应用程序和用户之间的连接。信任代理可以是由第三方提供商管理的云服务，也可以是自托管服务（以客户数据中心中的物理设备或公共IaaS云中的虚拟设备的形式）。一旦信任代理评估了用户的凭据和其设备的上下文，信任代理就与逻辑上靠近应用程序的网关功能通信。在大多数情况下，网关建立到用户的出站通信路径。在某些ZTNA产品中，代理仍保留在数据路径中；在其他产品中，只有网关保留在数据路径中。

在许多情况下，用户和设备的行为会被持续监控，以防出现异常行为，正如Gartner的持续自适应风险和信任评估（CARTA）框架所述。

从某种意义上说，ZTNA创建了个性化的“虚拟边界”，该边界仅包含用户、设备和应用程序。ZTNA还规范了用户体验，消除了在与不在企业网络中所存在的访问差异。

ZTNA价值主张

尽管ZTNA产品在技术方法上有所不同，但它们提供的基本价值主张大体相同：

• 将应用程序和服务，从公共互联网上的直接可见性中移除。

• 针对命名用户对指定应用程序的访问，启用精确性（“刚好及时”和“刚好足够”）和最小权限，即只有在对用户身份、设备的身份和卫生状况（高度建议）、上下文进行评估之后。

• 启用独立于用户物理位置或设备IP地址的访问，除非策略禁止（例如，针对世界特定地区）。访问策略主要基于用户、设备、应用程序的身份。

• 只允许访问特定的应用程序，而非底层网络。这限制了对所有端口和协议或所有应用程序的过度访问，因为其中有些可能是用户无权访问的。最关键的是，它还将横向移动的能力降到最低，因为这是困扰许多企业的有害威胁。

• 提供网络通信的端到端加密。

• 针对敏感数据处理和恶意软件形式的过度风险，提供了可选的对通信流量的检查。

• 启用可选的会话监视，以指示异常行为，如用户活动、会话持续时间、带宽消耗。

• 为访问应用程序（无代理或通过ZTNA代理）提供一致的用户体验，无论网络位置如何。

三、市场方向

随着越来越多的组织向远程工作过渡，ZTNA激起了这些组织的兴趣，以寻求比VPN更灵活的替代方案，并对位于本地和云中的应用程序进行更精确的访问和会话控制。

ZTNA供应商继续吸引风险投资资金。这反过来又鼓励新的创业公司进入一个日益拥挤的市场，并寻求差异化的方式。这一市场的并购活动正在进行中，目前已有多家初创企业被大型网络、电信和安全供应商收购。

Gartner已经识别出ZTNA供应商在为市场开发产品和服务时采用的两种不同方法：一种是端点启动的ZTNA，另一种是服务启动的ZTNA。

端点启动的ZTNA

这类产品更接近于最初的云安全联盟（CSA）软件定义边界（SDP）规范。安装在被授权的最终用户设备上的代理，将其安全上下文的信息发送到控制器。控制器提示设备上的用户进行身份验证，并返回允许的应用系统列表。在对用户和设备进行身份验证之后，控制器通过一个网关提供设备的连接性，该网关屏蔽了服务免受Internet的直接访问。该屏蔽作用可保护应用程序免受拒绝服务（DoS）攻击和其他威胁，而如果将它们放在传统的DMZ中，它们则将承受这些威胁。一旦控制器建立连接性，一些产品将保留在数据路径中；而其他产品则自行从数据路径中删除。

由于需要安装某种形式的代理或本地软件，端点启动的ZTNA很难（即便不是不可能）在非受管设备上实现。

在某些情况下，第三方统一端点安全（UES）产品（用户可能比全面设备管理更愿意接受）可以向信任代理提供态势评估。（概念模型见图1）

图1：端点启动ZTNA的概念模型

服务启动的ZTNA

这类产品更接近于谷歌BeyondCorp的愿景。与应用程序安装在同一网络中的连接器，建立并维护到提供者的云的出站连接（有些实现称为“由内向外”）。用户向提供者（provider）进行身份验证，以访问受保护的应用程序。反过来，提供者使用企业身份管理产品验证用户。只有验证成功后，流量才会通过提供者的云，从而将应用程序与通过代理的直接访问隔离开来。企业防火墙不需要为入站流量打开。但是，提供者的网络成为必须评估的网络安全的另一个要素。

服务启动ZTNA的优点是，终端用户的设备上不需要代理，这使得它成为非受管设备的一种有吸引力的方法。缺点是应用程序的协议必须基于HTTP/HTTPS，从而限制了通过如HTTP之上安全Shell（SSH）或远程桌面协议（RDP）访问web应用程序和协议的方式。最近，一些较新的供应商开始提供额外的协议支持。（概念模型见图2）

图2：服务启动ZTNA的概念模型

有一些供应商支持将两种方案结合起来的混合用例，包含两种风格：

• 一种风格，是将模型组合到单个产品中，使客户能够为某些应用程序选择端点启动的会话，为其他应用程序和具有非受管设备的用户选择服务启动的会话。

• 另一种风格，是提供带有最终用户代理的服务启动模型，以支持遗留协议。

四、市场分析

互联网是用来连接事物而非阻止的。有了IP地址和路由，任何东西都可以与任何东西对话（默认允许）。而身份验证这个棘手的问题，是在协议栈的高层处理的。

然而，攻击者滥用了这种信任。当企业开始连接互联网时，攻击者迅速移动，依靠网络防火墙在内部创建“可信”据点；当员工开始移动时，VPN通过扩展网络将内部信任扩展到远程员工，而攻击者非法获取VPN凭据以滥用此信任；当需要外部访问时，服务又会移动到DMZ中，从而使它们暴露给攻击者。

过度的隐性网络信任，会产生过度的潜在风险，从而受到攻击。网络访问（甚至“ping”或查看服务器或应用程序的权限）不应该是给定的。它应该基于用户、设备的身份和上下文来获得。

越来越多的互联网连接服务，以及服务和用户几乎可以位于任何IP地址的越来越大的可能性，再加上向越来越多远程工作人员的转变，加剧了旧模式的弱点。

好处和用途

ZTNA的好处是立竿见影的。与传统的VPN类似，带入ZTNA环境的服务在公共互联网上不再可见，因此，可以抵御攻击者。此外，ZTNA在用户体验、灵活性、适应性、策略管理的易用性方面，也带来了显著的优势。对于基于云的ZTNA产品，可扩展性和易采用性是额外的好处。

总之，ZTNA使能了不适合传统访问方法的数字业务转型场景。由于数字转型的努力，大多数企业在境外拥有的应用程序、服务和数据将多于境内。基于云的ZTNA服务，将安全控制放在用户和应用程序所在的位置——即云中。一些较大的ZTNA供应商已经在全球范围内投资了很多POP点（points of presence），以满足时延敏感的要求，并满足区域性的审计和检查要求。

有一些用例适合于ZTNA：

• 向合作生态系统成员开放应用程序和服务，如分销渠道、供应商、承包商或零售店，而无需VPN或DMZ。访问过程与用户、应用程序、服务的耦合更紧密。

• 规范应用程序访问的用户体验——ZTNA消除了公司网络内部和外部的区别。

• 基于用户行为派生角色——例如，如果用户的电话在一个国家，但其PC在另一个国家，并且两者都试图登录到同一应用程序，则应允许合法访问，同时应阻止失陷的设备。

• 在不信任本地无线热点、运营商或云提供商的情况下，将加密从端点一直携带到ZTNA网关（它可能与它正在保护的应用程序运行在同一服务器上）。

• 为IT承包商和远程或移动员工提供特定于应用程序的访问，作为基于VPN的访问的替代。

• 控制对应用程序（如基于云的应用程序）的管理性访问，作为完备特权访问管理（PAM）工具的最低替代方案。

• 在并购活动中扩展对收购组织的访问，而无需合并网络、合并目录或配置站点对站点VPN和防火墙规则。

• 在网络或云中隔离高价值企业应用程序，以减少内部威胁，并影响管理性访问职责的分离。

• 在个人设备上验证用户——ZTNA可以通过降低全面管理要求和实现更安全的直接应用程序访问，提高安全性并简化自带设备（BYOD）项目。

• 在物联网网段上，创建物联网设备的安全飞地或基于虚拟设备的连接器，进行连接。

• 在敌意网络上隐藏系统，例如用于协作的系统，否则会开放给公共互联网。

风险

尽管ZTNA大大降低了总体风险，但并没有完全消除所有风险，如以下示例所示：

• 信任代理可能成为任何一种失效的单点。当服务关闭时，通过ZTNA服务完全隔离的应用程序将停止工作。精心设计的ZTNA服务，应包括物理和地理冗余，具有多个入口和出口点，以最大限度地降低中断影响整体可用性的可能性。此外，供应商的SLA（或缺少SLA）可以指示他们对其产品的看法有多稳健。应支持带有SLA的供应商，以尽量减少业务中断。

• 信任代理的位置会给用户造成延迟问题，对用户体验产生负面影响。精心设计的ZTNA产品，应提供多个POP，结合对等关系，以提高冗余度，同时减少延迟。

• 攻击者可能试图破坏信任代理系统。虽然不太可能，但风险并不是零。建立在公有云上或主要互联网运营商中的ZTNA服务，可得益于提供商强大的租户隔离机制。然而，租户隔离的崩溃，将允许攻击者渗透到供应商的客户的系统中，并在其内部和之间横向移动。

  受损的信任代理应立即故障转移到冗余的信任代理。如果它不能，那么它就应该关闭——也就是说，如果它不能转移滥用，它就应该断开与互联网的连接。应支持采取这种立场的供应商。

  此外，请验证供应商是否维护了自己的安全运行团队，这些团队勤勉地监视其基础设施，以发现影响服务完整性的问题。

• 受损的用户凭据，可能允许本地设备上的攻击者观察和渗出设备中的信息。结合设备身份验证和用户身份验证的ZTNA架构，在一定程度上遏制了这种威胁，阻止了攻击传播到设备本身之外。建议在可能的情况下，MFA应该与任何ZTNA项目一起使用。

• 考虑到信任代理失效和用户凭据的问题，管理员帐户应准备好防范攻击。限制管理员的数量，并监视他们的活动，以减少内部威胁，并支持默认情况下需要对管理员进行强身份验证的供应商。

• 一些ZTNA供应商已选择将其开发重点放在仅支持web应用协议（HTTP/HTTPS）上。通过ZTNA服务承载遗留应用程序和协议，对供应商的开发和客户的部署都是一项更具技术挑战性的工作。

• 市场在不断变化，较小的供应商可能消失或被收购。

ZTNA评估因素

在评估ZTNA技术时，需要提出以下关键问题：

• 供应商是否要求安装端点代理？支持什么操作系统？什么移动设备？代理在其他代理已经存在的情况下表现如何？

• 供应商是否支持受管和非受管设备的ZTNA（理想情况下两者都支持）？

• 供应商是否将ZTNA作为一项服务提供，或是否要求客户安装和管理ZTNA代理（理想情况下使用兼容两者的混合架构）？

• 该产品是否能够在不需要统一端点管理（UEM）工具的情况下，对设备进行安全态势评估（操作系统版本、修补程序级别、密码和加密策略等）？

  是否提供了在非受管设备上实现此目的的选项？

• 产品是否使用本地代理来确定设备健康和安全状况，作为访问决策的一个因素？它是否需要辅助产品来执行端点评估，如网络准入控制或UEM？ZTNA供应商与哪些供应商合作，或者他们是否提供自己的产品？

  该产品是否与任何领先的UES或EPP（端点保护平台）/EDR（端点检测与响应）提供者集成，以深入了解设备安全态势？

• 信任代理支持哪些认证标准？是否可以与场内目录或基于云的身份服务集成？信任代理是否可以与组织的现有身份提供者集成？信任代理是否支持MFA？

• 有没有用户和实体行为分析（UEBA）功能，可以识别ZTNA保护环境中何时发生异常情况？

• 一些ZTNA产品部分或全部作为基于云的服务交付。这是否满足组织对数据检查和日志记录的安全性和常驻性要求？供应商是否经过一个或多个第三方认证，供应商是否与客户共享评估报告？

• 供应商在全球的出入境点（称为边缘位置和/或POP）在地理上的差异有多大？供应商使用哪些边缘/物理基础设施提供商或托管设施？

• 供应商是否提供“冷土豆路由”（cold-potato routing），即尽快将最终用户设备引入供应商网络，或者供应商是否只允许“热土豆路由”（hot-potato routing），即最终用户的流量穿越更多的公共互联网？

• 当ZTNA服务受到持续攻击时，供应商的技术行为是什么？服务是故障时自动关闭（fail closed）（从而阻止数字业务伙伴访问企业服务）还是故障时自动打开（fail open）？对于特定的企业应用程序，是否可以有选择地选择故障时自动关闭或自动打开？如果故障时自动打开能力是一项要求，不要忘记添加其他防御层来保护不再被ZTNA服务屏蔽的应用程序。

• 该产品是否只支持web应用程序，或者遗留应用程序是否也能获得同样的安全优势？

• 供应商选择了什么算法和密钥长度？不允许使用不安全的传输层安全（TLS）版本吗？供应商的产品描述是否显示了对当代和标准密码实践的理解，或者是否掺入了太好而不太真实的密码“蛇油”（snake oil）？

• 用户和设备通过身份验证后，信任代理或网关是否仍驻留在数据路径中？这种做法值得考虑。留在数据路径中的信任代理或网关提供了更高的可见性，并可以监视异常和可疑的活动。然而，它们可能成为瓶颈或单点故障。支持故障转移的设计，可缓解此问题，但可能容易受到试图绕过检查的分布式拒绝服务（DDoS）攻击。

• 供应商能否提供会话流和内容的检查，以检查不适当的敏感数据处理、恶意软件检测、异常行为？

• 该产品是否支持单包授权（SPA）作为对信任代理身份验证的初始形式？SPA允许代理忽略任何通信尝试，除非第一次尝试包含专用的加密数据包。

• 部分或全部地掩蔽、允许或禁止入站连接，在多大程度上是隔离应用程序安全要求的一部分？也许对内容交付网络（CDN）的最低保护就足够了。不同的企业应用程序可能有不同的需求。

• 提供商是否维持缺陷奖励计划，并制定可信、负责任、公开或私人披露政策？对于软件提供商来说，不断地测试和消除产品漏洞是至关重要的。应该支持那些主动这么做的提供商。

• 供应商是否提供了一个安全的API，用于用户到应用程序分段的编程管理？

• 供应商支持多少应用程序？如果您需要超过允许的最大值，如何管理（例如，通过单个管理控制台支持多租户管理）？

• 许可模式是什么？是按用户还是按带宽？如果在合同有效期内超过使用量会怎样？（您是否失去了访问权限，是否需要补偿款，或者是否将宽限期延长到下一次续订）？

• 供应商是否有其他安全访问服务边缘（SASE）组件，如安全web网关（SWG）、云访问安全代理（CASB）、防火墙即服务（FWaaS）和软件定义WAS（SD-WAN；可能是合作伙伴提供的）？（他们是否有与SASE一致的产品路线图，包括网络组件）？

ZTNA备选方案

ZTNA有几种可供内部和外部用户团体使用的应用程序替代方法：

• 传统VPN仍然流行，但鉴于数字业务的动态特性，它们可能无法为公开服务提供足够的风险管理，并且可能更难管理。传统的VPN也可能会为大多数移动员工带来规模和带宽问题。

  始终要求设备和用户身份验证的VPN，可提供与ZTNA类似的结果；但是，基本的网络访问型VPN则不能。

  对于进入企业系统的第三方特权访问，PAM工具可以是VPN的有用替代品。

• 通过基于反向代理的web应用防火墙（WAF）公开web应用程序是另一种选择。使用WAF即服务（即云WAF），流量在交付到目的地之前通过提供商的WAF服务进行检查。为了避免误报或潜在的应用程序故障，云WAF和其他WAF一样，通常需要一些时间来测试和调整规则。由于受保护的服务在公共internet上仍然对攻击者可见，因此隔离受限于WAF的强度。

  然而，面向合作伙伴和员工的应用程序通常不是WAF的候选对象。

• 部署虚拟桌面是一种有用的方法，可以让非受管设备上的用户使用一组应用程序，本质上是向每个人“投影”公司桌面策略。场内VDI正在让位于桌面即服务（DaaS，desktop as aservice），后者由大型超大规模云提供商提供，如AWS和Microsoft Azure。

• 远程浏览器隔离产品提供了另一个选项，特别是对支持web的应用程序访问进行隔离。这里，浏览器会话本身是从最终用户的设备呈现的，并且通常是在服务中，从企业网络（例如，基于云的远程浏览器服务）呈现的，在双方提供隔离。一些ZTNA供应商还提供远程浏览器隔离产品。询问路线图计划以及隔离是否将成为未来聚合服务的一部分。

• 选择保留现有的设计模式并在传统DMZ中公开数字业务应用，仍然是替代方案。然而，DMZ对现代攻击仅提供了有限的隔离（通常是反向代理WAF）。此外，DMZ仍会让所有攻击者发现应用程序。

• CDN可以吸收DDoS攻击，降低bot攻击的噪声和威胁，防止网站被破坏。但是，它们不提供应用程序级别的保护，也不提供匿名性——以站点为目标的攻击者可以发现该站点受到CDN的保护，并可能试图利用CDN中存在的漏洞进行攻击。许多CDN包括一个基本的云WAF。

• 不需要完整的交互式互联网连接、只需向公共互联网暴露API的应用程序，可以通过API网关进行保护，尽管ZTNA也可以在这里工作。API网关执行身份认证、验证授权并协调应用程序API的正确使用。如果应用程序本身缺少确保API安全性的机制，则这一点尤其有用。大多数API网关还通过本机监视工具或与流行的安全信息和事件管理（SIEM）工具集成，来公开所有活动的日志。应该支持与企业目录和单点登录（SSO）协议集成的API网关。

五、代表性供应商

市场产品分类

ZTNA产品和服务由供应商以两种方式提供：

• 即服务产品：作为云服务

• 独立产品：作为客户负责支持的独立产品

即服务产品（见表1）比独立产品需要更少的设置和维护。它们通常需要在最终用户或服务端进行资源调配，并通过供应商的云来路由流量以执行策略。

独立产品（见表2）要求客户部署和管理产品的所有要素。

此外，一些主要的IaaS云提供商为其客户提供ZTNA功能。

即服务产品的供应商

表1：ZTNA即服务的代表性供应商

独立产品的供应商

表2：独立ZTNA的代表性供应商

产品选择的趋势

显然，在客户交互中，即服务风格正在迅速超过独立风格。

据Gartner估计，超过90%的客户正在实现即服务风格。

独立风格主要吸引那些不喜欢云计算的企业。

云和本地访问代理的一种新兴混合方法是第三种选择，它吸引了那些希望优化应用程序策略规则以实现对应用程序的远程和本地访问的组织。一些供应商提供ZTNA作为企业的服务或部署。（表1列出了最符合其核心架构的供应商。）

本市场指南中列出的供应商并不意味着一份详尽的清单。本节旨在提供对市场及其产品的更多了解。

六、市场建议

鉴于公共互联网所代表的重大风险，以及为了在企业系统中站稳脚跟而损害暴露于互联网的系统的吸引力，企业需要考虑将数字业务服务与公共互联网的可见性隔离开来。ZTNA隐藏了服务以免被发现和侦察，同时建立了真实的、基于身份的栅栏，这比过去简单混淆的概念使攻击者更难以绕过。

对于传统的VPN访问，寻找这样的场景：其中的目标用户集，一旦通过ZTNA服务执行工作后，就能在改善组织的总体安全状况方面提供即时价值。在大多数情况下，这很可能是一个面向合作伙伴或员工的应用程序。ZTNA项目是朝着更广泛的零信任网络（默认拒绝）安全态势迈出的一步。

对于基于DMZ的应用程序，评估哪些用户集需要访问。对于那些具有一组已定义用户的应用程序，计划在未来几年内将它们迁移到ZTNA服务。通过将这些应用程序迁移到公共云IaaS，可以作为此架构转换的催化剂。

具体建议如下：

• 对ZTNA项目进行预算和试点，以证明ZTNA对组织的益处。

• 如果VPN替换是主要目标，则计划保留VPN一段时间，同时验证ZTNA产品可以替换VPN的所有用例。为远程工作者测试ZTNA产品的延迟，并设定实际期望，要求ZTNA交付的应用程序延迟不低于现有VPN。

• 为用户到应用程序的映射制定计划。基于角色的访问控制（RBAC）可以帮助解决这个问题。避免允许所有用户访问所有应用程序（生成策略的观察阶段除外）。

• 识别哪些应用程序和工作流不适合ZTNA，并将其排除在范围之外。这包括访问和下载非结构化数据和面向消费者的应用程序。

• ZTNA市场正在崛起，因此只需签署短期合同（即不超过12至24个月），以在市场增长和成熟时保持更大的供应商选择灵活性。

• 对于大多数数字业务场景，支持提供ZTNA即服务的供应商，以便于部署、提高可用性和抵御DDoS攻击。支持那些无需在防火墙中打开监听服务（入站连接）的供应商，因为这是典型的ZTNA即服务风格。

• 当安全需求要求在现场安装ZTNA产品时，应选择能够尽可能减少防火墙开口数量的供应商。

• 如果命名用户要使用非受管设备，则计划部署基于反向代理的ZTNA产品或服务，以避免安装代理。

• 确保供应商支持组织和合作伙伴现在使用的身份验证协议，包括企业的标准身份存储，以及将来预期使用的任何身份验证协议。可用范围越广越好，包括云SSO提供商和SaaS化交付的访问管理提供商。

• 不要期望合作伙伴使用你的身份存储。需要对SAML、OAuth、OIDC和类似身份联合功能的支持。

• 评估供应商查询其他类型设备代理（如UEM、EDR、移动威胁防御（MTD））的能力的有效性，以获得用于改进自适应访问决策的更多上下文。

• 攻击者将瞄准ZTNA信任代理。对于基于云的产品，请评估其DoS和故障转移架构。要求供应商支持管理员帐户的高级别安全性和监视。对于本地ZTNA产品，使用支持本地部署的云工作负载保护平台（CWPP）工具，加固主机操作系统（请参阅“云工作负载保护平台市场指南”）。主要依赖默认拒绝的策略，仅通过允许列表来显式定义允许在系统上执行的代码。不要仅仅依靠补丁来保持系统的坚固性。

• 如果你选择一家规模较小的供应商，应考虑在合同中加入适当条款并在需要时列出备选供应商名单，准备潜在的购置。否则，考虑到云基础设施、SWG、FWaaS、CASB和SASE架构中包含的其他产品的优势，应通过支持提供ZTNA作为强大SASE产品基础的一部分的供应商，来限制供应商风险。

声明：本文来自网络安全观，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。