Gartner发布2024年SASE融合战略路线图

向云计算和远程工作的转变增加了 SASE 需求，以实现从任何设备的安全访问。安全和风险管理领导者必须将网络和安全融合到一两个明确合作的 SASE 供应商产品中，并淘汰遗留的边界系统。

主要发现

安全访问服务边缘 (SASE) 框架为混合劳动力以及设备、分支机构以及企业应用程序和服务的分散部署提供了统一的连接和安全方法。
传统的网络和安全解决方案不足以满足现代应用程序和网络的需求，给网络和安全管理员带来了复杂性，并为用户带来了糟糕且不一致的体验。
组织可以通过创建与现有 IT 技能、供应商合同和硬件更新周期相一致的战略路线图来加速 SASE 的采用。
组织的目标是通过以下三种方式之一融合和采用 SASE：单供应商 SASE、双供应商 SASE 或托管 SASE。

建议

负责基础设施安全的安全和风险管理 (SRM) 领导者应在其 SASE 路线图中包括以下活动：

与利益相关者合作，目标是实现分支机构连接现代化、推行零信任策略或保护和连接混合员工。
选择具有单通道流量检查、灵活的检查点和路由以及自定义日志记录的融合 SASE 产品，以满足性能、简单性和合规性要求。
整合现有的网络和安全合同，并在进行任何技术评估之前聘请网络和安全工程师，以最大程度地减少重复支出。
创建与首选部署选项一致的候选名单和评估标准，并在购买之前进行试点以验证关键功能要求和用例。

介绍

传统上，大多数网络和安全架构都是以企业数据中心作为访问和安全需求的焦点来设计的，支持相对静态的用户。然而，数字业务推动了对新数字功能（例如云和边缘计算以及随时随地工作计划）的需求，这些需求反过来又将访问需求从强制最终用户连接到托管网络以确保安全转变为确保安全无论他们的位置如何，他们都可以访问。Gartner 的 2023 年云最终用户行为研究表明，目前所有应用程序中有超过 50% 驻留在本地网络和数据中心之外。

基于一系列边界安全设备的网络安全设计不适合满足现代数字企业及其混合数字员工随时随地的动态需求。

传统边界必须转变为一组以用户和应用程序为中心的融合功能，从云端进行管理，并在企业需要时随时随地实施——也就是说，一组动态创建的、基于策略的网络和安全控制融合在一起到 SASE框架中。

与此同时，企业越来越多地追求零信任策略，但发现零信任原则的有意义实施具有挑战性。提供零信任安全态势是 SASE 架构的组成部分，也是新兴 SASE 产品的组成部分。零信任网络模型用持续评估的风险/信任级别取代隐式信任。当交互周围的上下文发生变化时，零信任架构会调整为交互授予的显式信任量，同时仍然对所有流量和数据应用安全检查。

以零信任安全态势敏捷支持数字业务转型工作，同时保持复杂性可控的需求是 SASE 市场的重要驱动力，主要作为基于云的服务提供。SASE 架构（见图 1）融合了网络（尤其是 SD-WAN）和网络安全服务边缘服务，尤其是安全 Web 网关 (SWG)、云访问安全代理 (CASB) 和零信任网络访问 (ZTNA ) 。

图 1：详细的 SASE 视图

自 2019 年定义 SASE 市场以来，行业和客户对SASE 的兴趣激增，这主要是由于现有供应商无法满足现有企业需求。Gartner 客户对 SASE 持续保持兴趣，2022 年下半年到 2023 年上半年的询问量较之前 12 个月增加了 10%。为了满足客户需求，供应商迅速向市场推出新的解决方案。Gartner预测该市场的总可寻址市场 (TAM) 到 2027 年将达到 250 亿美元，五年（2021 年至 2026 年）复合年增长率 (CAGR) 为 29%。在过去 18 个月中，已经进行了几项重大的供应商收购和公告，以构建完整的 SASE 产品组合，包括多种托管 SASE 产品，并且我们预计还会有更多此类活动。

在2024 年Gartner CIO 和技术高管调查中，39% 的受访者表示他们已经部署或将在 24 个月内部署 SASE。然而，企业过渡到完整的 SASE框架需要时间。现实情况是，企业在硬件和软件方面已有投资，还剩下时间和价值。分支机构的硬件更新周期平均为四到七年。与现有供应商产品的关系和员工专业知识是另一个因素。此外，大多数大型企业都有独立的网络安全和网络运营团队，这使得 SASE 的采用进一步复杂化。

最后，许多供应商声称提供 SASE 产品，但并未提供所有必需和推荐的 SASE 功能。Gartner 跟踪买家开始 SASE 转型之旅和购买决策的四个独立市场。供应商的所有 SASE 功能并非都处于相同的功能和成熟度级别。我们分析了市场上 SASE 产品的未来和现状之间的差距，以便为 SRM 领导者提供未来几年采用 SASE 的战略路线图、迁移计划和实施建议（见图 2）。

图 2：SASE 融合的战略路线图概述

未来状态

用户和边缘设备可以位于任何地方，并且大多数用户的网络访问是通过互联网访问应用程序和服务，这些应用程序和服务不再是独立的也不是本地的。即使在内部网络上，零信任安全态势也会将网络视为不可信。用户、分支机构和边缘设备需要安全地访问分布在云和数据中心各处的数据和应用程序。SASE 产品提供并保护这种未来状态（即 2025 年及以后；参见表 1）。

表1 ：SASE 产品未来状态

未来状态	描述
一致的策略执行和覆盖所有类型的访问，无论位置如何，并支持本地决策	SASE 架构支持将分布式策略执行到最有意义的执行“边缘” 。敏感数据和恶意软件检查等安全策略一致应用于所有设备的所有访问方法。执行点可以位于公有云、互联网边缘、供应商接入点 (POP) 甚至终端本身。这将需要在全球分布的 POP 上部署基于软件、硬件中立的架构，并在消费点（通常是用户）附近执行策略。客户可以根据业务策略、性能和合规性要求选择要检查的流量并将其定向到特定的执行点。完全分布式的云架构允许在本地做出一些安全决策——解决延迟敏感、合规性、数据主权和间歇性访问用例——以及基于高级分析在云中做出的其他决策。对于分支机构和边缘位置，支持小型硬件或虚拟设备，但作为分布式云的一部分进行管理，并通过瘦分支、重云架构实施。无论用户是在远程、在分支机构、还是在校园或总部，都会一致地应用策略。
通过统一的策略控制平面简化管理	SASE 管理控制平面与执行节点分离，允许对统一策略、数据存储和高级分析进行集中管理。管理界面将允许从单个简单的控制台和集中式仪表板管理安全和网络策略，以进行故障排除、报告、分析和配置。它还必须实现一组强大的 API，以便能够以编程方式与其他安全工具集成，以解决特定的用例。机器学习 (ML) 是自动化策略创建和管理不可或缺的一部分。
敏感数据可见性和控制以及威胁检测	敏感数据可见性和控制是 SASE 的关键核心能力。这可以通过结合使用本地代理、在线流量检查和基于 API 的云服务检查来实现。先进的数据安全技术和数据丢失防护 (DLP) 引擎将以最小的误报和漏报率检测和保护敏感数据。还提供可见性以及针对恶意内容和网络攻击的保护。
一致覆盖所有类型的实体，包括分支机构、园区和边缘位置的用户和设备	SASE 产品可保护用户、用户集合（分支机构）和边缘设备以及托管和非托管设备的访问。对于受管设备，通常会使用软件代理；但是，在需要时也可以支持非托管设备，而无需使用代理（例如，用于承包商或第三方访问）。在分支机构，本地设备（通常是 SD-WAN 硬件）充当分支机构的共享代理，用于无代理的设备（例如打印机）。这提供了流量优先级、连接故障转移以及本地安全功能（例如防火墙和分段）。
集成 SD-WAN、SSE 和POP	SASE 可以由一个供应商、两个明确合作的供应商或通过托管 SASE 来完成。无论部署如何，SASE 都必须完全集成在POP 中，以最大限度地提高解决方案的灵活性和可扩展性，将用户和设备连接到最近的云实例，从而最大限度地减少延迟并最大限度地延长正常运行时间。
在云端以线速对加密流量和内容进行单次检查	加密的网络会话和内容在云端以线速进行检查，并支持最新版本的SSL/TLS。会话及其内容将被解密一次，并使用单通道并行架构扫描恶意软件和敏感数据，而不是一次扫描给定的内容以查找恶意软件/攻击，然后再次使用单独的引擎来扫描敏感数据。
高可用性、低延迟服务以及合同强制执行的 SLA	SASE 产品将使用可弹性扩展、可组合的架构来构建，以提供可动态适应客户需求的高性能和弹性服务。多个且地理上分散的执行点（大多数 SASE 供应商在全球拥有数十个 POP）使 SASE 提供商能够承诺合同 SLA，以实现高可用性和低延迟，检查加密流量或检查敏感数据也不例外。随着 SASE 的不断发展，客户对其 SASE 提供商更高的透明度和弹性的期望也会随之提高。
提供零信任网络安全态势	SASE 产品以基于用户身份和上下文的明确、持续评估的自适应风险和信任级别取代了传统网络模型中的隐式信任。在连接到 SaaS 应用程序和私有应用程序等企业资源时，这种零信任安全态势应扩展到所有设备，无论位置如何（远程、校园、分支机构或总部），即通用 ZTNA 。连接后，将监控实体、设备、会话和相关行为是否存在异常或危险行为。根据风险，采取适应性措施，例如修改访问权限。
无缝的最终用户体验	SASE 产品通过将标准安全策略和控制扩展到托管和非托管设备并根据用户和终端上下文调整访问，提供相同的用户和访问体验，无论位置或设备如何。SASE 产品将在托管设备上使用统一终端代理，从而向用户隐藏访问复杂性（例如，转发代理、需要时创建隧道、设备安全状态）。将支持所有常见操作系统和设备类型 - Windows、Mac OS 、Linux 、iOS 和 Android。SASE 将使用数字体验监控 ( DEM )集成用户数字体验的端到端测量和优化，以提供应用程序和传输层性能的全面可见性。
接入工程的统一 IT 责任	在 SASE 架构中，单个跨职能 IT 团队负责访问设计、选择、工程和运营，涵盖网络安全和网络，并为世界各地的所有实体提供安全访问。广域网工程和网络安全工程演变成一种新兴的“接入工程”复合角色（对支持应用程序创建的平台工程这一新兴 IT 角色的补充）。
先进的人工智能和机器学习网络以及安全运营效率	SASE 供应商利用先进的 ML 和 AI 技术（例如生成式 AI），通过主动建议网络和安全策略更改来改善最终用户体验，从而实现更好的弹性和正常运行时间。集成的 AIOps 功能使管理员能够保持弹性并避免在基础设施发生故障时出现停机。更先进的 SASE 产品将主动发出警报并防止停机，而无需人工干预。

资料来源：Gartner（2023 年 12 月）

当前状态

传统的基于边界的安全设备、CASB、SWG、ZTNA、防火墙和 SD-WAN 功能的不同供应商，以及网络安全和网络的独立组织结构的组合，创建了供应商、代理、控制台的复杂且难以管理的集合（见表2）。

表2 ：SASE 产品现状

当前状态	描述
与位置相关的策略执行不一致	一些拥有基于传统设备的安全业务的供应商在从云本地提供解决方案方面进展缓慢。通过多次收购构建的产品具有不同的政策执行选项。SASE 提供商的云架构的选择可能会限制组织使用该服务的能力（请参阅注释3）。一些以云为中心的 SASE 产品提供本地安装的执行点（通常是软件设备），以实现低延迟本地策略执行。
使用不同的管理控制台和策略进行复杂的管理	一些从一组采购中集成 SASE 功能组合的供应商对于不同的功能有不同的控制台（或同一控制台中的不同选项卡）。这些单独的控制台更难使用，增加了出错的可能性和复杂性，降低了安全性，同时限制了效率。其他公司则使用与合作伙伴的服务链或网络功能虚拟化 (NFV) 来提供他们尚未提供的服务，或者将他们获得的技术拼接在一起，从而使管理和策略管理变得复杂。一些采用传统以设备为中心的业务模型的供应商在本地和云中使用不同的架构，具有不同的管理控制台和不同的功能。
基本或不存在的敏感数据可见性和控制，以及基本的威胁检测能力	一些供应商提供非常有限的敏感数据发现功能，其他供应商合作，而其他供应商仅提供基本的模式匹配。领先的 SASE 和SSE供应商为所有渠道和所有安全功能提供一致的覆盖范围，但并非所有供应商都提供这一点。很少有企业为本地系统或端点提供可选的敏感数据扫描。一些 SASE 供应商不拥有自己的威胁情报和检测功能，而是从第三方许可威胁检测和情报源。最后，并非每个供应商都包含远程浏览器隔离 (RBI) 和网络沙箱功能。
独立于 SD-WAN 和边缘策略的孤立安全策略	大多数大型企业都有独立的网络安全团队和网络团队。一些非常大的企业甚至可能有单独的 SWG、CASB 和远程访问（VPN 和 ZTNA）团队。虽然许多 SD-WAN 实施都会征求安全意见，但分支机构访问转型决策很少来自统一的跨职能团队。
不同的 SSE 和 SD-WAN	许多组织已经实施了 SSE 和 SD-WAN 产品，但它们并未明确集成。几乎所有 SSE 和 SD-WAN 产品都可以使用 IPsec 等标准协议进行轻松集成。然而，要实现双供应商 SASE，SSE 和 SD-WAN 产品之间必须进行明确的深度集成，包括管理平面集成、为企业提供改进和自动化配置的动态流量引导、改进的故障排除和可见性以及主动/被动流量转向。
具有多个检查点的低效架构会忽略加密流量或导致性能显着下降	来自设备背景的 SASE 供应商通常拥有虚拟设备形式的整体架构，难以动态扩展以支持更高吞吐量的连接。合作填充功能的 SASE 供应商通常会在到达最终目的地的途中跨不同服务进行乒乓流量。SASE 供应商使用了不同的方法来检查加密流量，企业需要测试此功能以确定其对延迟和吞吐量的影响。
基本 SLA，很少有合同处罚或由弹性架构支持	一些供应商针对可用性提供合同SLA 。针对延迟的 SLA 不太常见，并且即使提供，也往往仅解决区域访问性能或仅解决一种访问通道（例如 SWG）。一些供应商在检查敏感数据或服务无法维护时会有例外。SLA 应在全球范围内应用于所有访问机制和执行策略，无一例外。并非所有供应商都提供从边缘到云的本机弹性来支持其 SLA，并依赖差异化的云架构来支持其 SLA 承诺。
基本或没有零信任功能，缺乏检查，并且与终端安全和管理工具的集成有限	SASE 的某些 ZTNA 组件无法选择在整个会话期间对所有检查引擎保持一致，从而消除了对这些连接进行敏感数据和恶意软件检查的能力。一些基于代理的 ZTNA 产品在首次连接时仅具有基本的设备安全态势评估功能。其中一些与本地终端保护平台（EPP）或统一终端管理（UEM）代理集成。许多（但不是全部）提供代理和无代理 ZTNA ，满足员工和第三方或自带设备 (BYOD) 访问用例。
最终用户体验支离破碎且令人沮丧	对于仅提供部分功能或通过不同收购拼凑而成的 SASE 产品，可能需要多个代理。有些支持远程用户的 ZTNA，但当远程用户进入本地时不支持此模型。一些供应商提供代理，但仅适用于 Windows/macOS ，不适用于 Linux 或移动设备。大多数 SASE 提供商至少提供基本的 DEM，但市场上提供高级集成 DEM 产品的供应商却很少。
手动干预网络和安全策略和运营	团队使用有限的、孤立的自动化功能来管理最终用户的网络和安全基础设施的正常运行时间和性能。对策略进行静态的手动审核，团队主要是事件驱动的，当发生停机且用户受到影响时，使用“全体人员齐心协力”的事件响应措施来调查和恢复服务。

资料来源：Gartner（2023 年 12 月）

差距分析和相互依赖性

阻碍 SASE 迁移的最重要的差距包括：

组织孤岛、现有投资和技能差距——这些是迁移规划中必须考虑的最大差距。完整的 SASE 实施需要跨安全和网络团队采取协调一致的方法。对于中型企业来说，这是一个更容易解决的问题，因为可能不存在单独的安全团队。在大型组织内，这些组织结构、预算流程和职责是相当严格的。一些供应商将被替换，并且那些相关的技能集将需要重新用于与业务流程和应用程序所有者合作创建策略。
架构和POP —— SASE 解决方案是云交付的，但供应商的架构“云原生”程度各不相同。传统设备和虚拟设备架构需要分解为更小的、可扩展的组件。使用公有云 IaaS 进行 POP 与拥有 POP 是 SASE 提供商之间的差异，这可能会影响某些地区的采用。云 POP 的位置应位于分支机构和用户位置的合理距离内（例如 100 公里），以最大限度地减少最后一公里的延迟。对于非 SASE 部署、多供应商 SASE 实施甚至某些单一供应商 SASE 产品来说，多个 POP 之间的流量发夹和乒乓是一个问题。每个企业都有不同的合规性要求，并且对数据检查、日志存储和流量路由有隐私要求。缺乏地理分散、统一服务和执行点数量也会影响 SASE 提供商承诺可用性和延迟SLA的能力。
敏感数据可见性和控制——这是一项高优先级的功能，但也是 SASE 供应商最难解决的问题之一。即使具有强大数据安全性的供应商也可能在覆盖范围上存在差距，例如，缺乏应用数据分类标签的能力以及扫描本地数据存储和终端存储的敏感数据的能力。将数据发送给第三方进行敏感数据识别并不是一个可持续或具有成本效益的选择。DLP 检查必须由 SASE 产品本机提供，并在本机功能不存在的情况下提供选项。一个例子是通过第三方终端和电子邮件安全集成以及与数据安全状态管理 (DSPM) 产品的集成将 DLP 扩展到渠道以使用数据分类元数据。
SASE 安全服务成熟度——随着市场的成熟，不同供应商的 SASE 功能仍然存在很大差异。企业需要优先考虑对融合功能的需求与对持续最佳功能的需求，直到缩小差距。一些供应商将自己定位为 SASE 产品，通过合作伙伴关系填补了核心 SASE 功能的空白，但通过服务菊花链和/或网络功能虚拟化来提供核心服务并不是可持续的长期选择。SASE 四个市场的能力成熟度差异很大，这与每个市场的买家的优先事项密切相关。单一供应商 SASE 产品的兴起以及 SD-WAN 和 SSE 提供商之间的合并（请参阅注释 1）使技术合作伙伴关系面临长期风险。
对扩展用例的支持有限——市场上的大多数 SASE 提供商都专注于支持 SASE 的核心用例：使用托管设备将分支机构和扩展劳动力（例如员工和承包商）连接到 Web、SaaS 和私有应用程序。不同提供商对超出核心 SASE 价值主张的扩展用例的支持有所不同，例如保护第三方特权用户从非托管设备进行访问以及保护现场物联网 (IoT) 设备到工业边缘计算平台的安全。由于解决范围内的 SASE 用例所需的供应商数量增加，这增加了复杂性，并减少了从融合网络和安全性中获得的价值。

迁移计划

根据差距分析，我们提出了未来几年的以下路线图和行动项目，作为适合大多数企业的SASE 采用和迁移规划的模板。虽然单一供应商方法可以提供图 3中详细介绍的所有内容，但每个企业都必须确定完全融合的方法对其需求是否有意义，如果是，则需要多长时间。企业无法切换并采用 SASE。因此，许多大型组织将在未来三年内使用明确合作的网络和安全供应商。绝大多数企业采用 SASE 需要三到五年的时间，优先考虑在简化网络安全策略管理、消除复杂性和冗余供应商以及通过采用零信任安全态势降低风险等方面最有机会的领域3（参见图3）。

图 3：SASE 融合的战略路线图时间表

因此，我们根据典型企业 SASE 采用的预期时间表，将建议分为高优先级、中优先级和低优先级部分。

更高优先级

未来 18 个月：

与数字化劳动力转型团队合作，通过 SASE 实现远程和移动劳动力随时随地的访问。采用基于统一愿景的架构，为所有远程/移动工作人员提供“一个分支机构”，无论其位置和应用程序位于何处。
组建联合网络和安全团队/工作组，制定三到五年的 SASE 转型路线图，涵盖用户、分支机构、边缘位置和分布式应用程序的安全访问策略。在 SASE 路线图中规划和巩固零信任网络计划：

o 包括负责分支机构转型和 WAN 重新设计以直接访问互联网和多协议标签交换 (MPLS) 卸载项目的人员。

o 将 SASE 与云转型之旅和路线图保持一致，以从本地应用程序迁移到 SaaS。

o 共同制定未来安全数字分支的愿景，采用细分支、重云架构。

在购买前试用 SASE 产品，解决关键功能需求，与包括网络和安全工程师在内的团队一起证明相关用例。
设定两到四年的目标，以零信任网络访问取代95%的主要传统网络级 VPN 访问。采用基于云的 ZTNA（通常与 SSE 提供商部署的代理保持一致）来取代内部和扩展员工用例和托管设备的传统 VPN 访问。
使用与 RBI 集成的无客户端 ZTNA 作为 SASE 的一部分来解决高风险 VPN 使用案例，以实现统一的 DLP 和威胁防御功能，例如：

o 承包商和第三方访问

o 非托管设备访问

o 云管理员和开发人员访问权限

利用安全性和分支机构设备/硬件的每一个更新机会来采用 SASE ：

o 在使用物理网络安全设备的情况下，我们建议企业尽快更换这些设备并转向 SASE 或 SSE。

o 与能够满足SASE 路线图的新供应商签订不超过三年的合同。设定一个目标，在合同中途重新评估 SASE 提供商环境，以验证所选的 SASE 提供商是否仍符合长期业务需求。然而，如果决定更换供应商，就要做好高成本的准备。根据业务需求进行更改，而不仅仅是降低订阅价格。

o 如果近期发生分支刷新，请加速 SSE 的部署，并将零信任网络访问扩展到分支中的托管设备，并采用防火墙即服务 (FWaaS)。

o 将提供商更广泛的 SASE 功能纳入试点中。例如，即使不立即需要 SaaS 安全功能，也应该将其包含在标准中。这有助于选择最佳的长期解决方案，并且优先选择 SSE 而不是点解决方案来实现 SaaS 安全。

通过在更新SWG、CASB和 ZTNA时整合供应商来削减成本并降低复杂性。现在，在竞争激烈的 SSE 市场中，这三种服务通常由一家供应商提供（图 1 和图 3 中云服务的右侧）。对于 SSE 来说，评估提供商与现有边缘的集成能力是一项关键要求。但是，如果 SD-WAN 推动了需求，请评估单一供应商产品（提供图 1 和图 3 中所示的全套功能的供应商）。
通过有关映射到企业需求、对等关系、加密流量检查性能和扩展能力的 POP 数量和位置的具体问题来扩展 SASE RFI/RFP 要求：

o 要求带有惩罚措施的合同 SLA 。SLA 应无一例外地解决端到端延迟、吞吐量和服务可用性问题。

o 评估 SASE 提供商的本机恢复能力以应对停机，例如提供策略的边缘或终端缓存。

MSE 应评估单一供应商 SASE 产品或托管 SASE 产品，而不是明确合作的供应商，以简化 SASE 的采购、安装、配置和持续运营。
较大的组织应评估使用单一供应商 SASE 与使用 SD-WAN 和 SSE 供应商之间的明确合作伙伴关系方法的利弊，包括整合的时间表。在这两种情况下，在此决策中都要考虑摊销投资和员工技能的时间，以及提供商 SASE 能力的成熟度。
当使用两个供应商时，需要与控制台集成和技术支持建立明确的合作伙伴关系。
忽略供应商的炒作，因为“SASE 清洗”现象猖獗，并专注于交付特定的业务和用户结果。

中优先级

在未来18至36个月内，企业应：

如果仍然使用多个供应商，请重新评估 SASE 架构和路线图。单一供应商 SASE 正在迅速成熟，并且对于越来越多的企业来说是可行的，尽管一些拥有独立网络和网络安全团队的组织仍然会追求最佳策略并将目标整合到两个提供商：

o 扩展企业 SASE 策略以包括边缘计算用例。

o 如果使用多个供应商，则需要明确的合作伙伴关系，并提供支持集成的工程和技术支持。

当独立SWG、CASB 和 VPN 设备达到使用寿命时，将其淘汰，如果需要最佳安全性，则用基于云的 SSE 替换它们。一些组织可能需要保留访问和安全性的备份方法，但这成本高昂，并且需要业务合理性来保留传统的热备用或冷备用基础设施。
尽可能消除物理防火墙，并使用FWaaS 进行分支机构保护，尤其是入站和出站流量：

o 逐步停止在分支机构使用单独的物理防火墙。

o 对分支机构采取拒绝一切、零信任的安全态势。

尽可能淘汰MPLS 的使用，并为大多数分支机构采用纯互联网传输：

o 作为其中的一部分，评估用于分支机构 WAN 连接的新兴超大规模产品，因为它们成为 WAN 服务的替代方案。

在 SASE 或 SSE 部署计划的背景下，超越最初的 ZTNA 部署，并实施基于风险的系统方法来逐步淘汰所有网络级 VPN 和基于DMZ的服务：

o 使用基于机器学习的方法来了解应用程序访问要求，以构建策略和管理持续运营。

o 将 ZTNA 扩展到更多用例，例如统一本地和远程策略实施的通用 ZTNA、云应用程序访问和 IoT/OT 访问。

o 扩展 ZTNA 以包括针对威胁、敏感数据和异常行为的会话检查。

将敏感数据的可见性和控制扩展到公共云中的静态数据以及企业不可见的云到云服务。
集成自适应访问控制，通过与 IdP 集成来控制对 SaaS 应用程序的访问，并通过 RBI 或反向代理方法控制非托管设备对 SaaS 的访问。
逐步淘汰剩余的基于 DMZ 的应用程序，并转向指定用户（例如合作伙伴和供应商）基于 SASE 的访问。
将网络和安全团队协调为统一的访问工程方法。根据组织的不同，它可能位于单个组织中，也可能由同意并协调 SASE 运营结果的现有团队成员组成。
扩展 SASE 功能以包含集成 DEM。
评估现有的 SASE 提供商保护网络物理系统的能力，或者是否需要专用的网络物理系统保护平台来保护组织的设备。
利用融合了 CASB、SWG 和 ZTNA 功能的 SSE 解决方案，实现满足所有访问需求的单一代理。

注意：列出的建议可能会加快，以适应硬件更新周期和分支机构转型计划。

较低优先级

三到五年后，大多数组织都可以实现 SASE 未来的战略目标状态。具体来说，针对分支机构、边缘、园区、总部和远程访问需求的统一战略方法涵盖私有应用程序、互联网和云应用程序访问：

重新审视 SASE 迁移计划，因为市场已经成熟，并且该技术预计将成为主流。设定一个战略目标，即使用不超过一两个 SASE 提供商、使用单一供应商或紧密集成的显式合作伙伴关系。
扩展 SASE 迁移策略以满足具有类似网络和网络安全策略要求的分布式组合应用程序的需求。这可能由现有的 SASE 供应商或新的初创公司提供，从服务到服务而不是最终用户的角度解决这个问题。
随着 SASE 的成熟，供应商将越来越多地扩展其 SASE 框架，以解决边缘计算和无线连接物联网设备等差距。随着新功能上线，扩展 SASE，以进一步统一企业的安全策略和可见性。
根据一开始就承诺的明确的、可衡量的 SASE 目标进行交付。具体例子包括：

o 95% 的网络级 VPN 访问被消除

o 95% 的DMZ 服务被内部和第三方服务淘汰

o 专线数量减少 80% ，因为其中大部分转移到互联网

o 通过零信任访问控制进行隔离和保护的应用程序百分比

o 提高最终用户满意度

o DEM 的改进和稳定性（例如，减少延迟）