的演变 SASE 建筑

您可能听说过一般网络安全背景下的多种架构原则， SASE 尤其。 业界使用的一些软件架构原则 SASE 上下文是：

• 单通道架构
• 单代理架构
• 运行到完成的架构
• 横向扩展架构
• 单遍并行处理架构
• 自带安全功能架构
• Cloud- 原生架构
• 隔离架构
• API优先架构
• 切片（端到端分段）架构

上述许多架构原则并不新鲜。 单通道、单代理、单通道并行处理和运行到完成架构原则自 2000 年代初 UTM（统一威胁管理）时代以来就很流行，尽管它们之前有不同的名称。

这些架构原则的主要目的是实现

• 更高的吞吐量和资源的有效利用。
• 更低的端到端延迟
• 降低抖动
• 即使在安全服务遭受 DDoS 攻击的情况下也具有更高的弹性（横向扩展）和恢复能力
• 更快地引入新的安全功能（敏捷性）
• 集成多个供应商安全功能，而不会导致效率低下（最佳技术的集成）
• 可采用性（随处运行）
• 单层玻璃

进化

网络安全行业的一大优点是它是动态的。 它在每一代新一代产品中都采用更新的软件和部署架构原则。 它还可以针对复杂的攻击者提供保护。

也就是说，网络安全市场传统上是分散的。 有多个安全供应商提供不同的安全功能。 从创新的角度来看这是好事，必须鼓励并继续下去。 值得注意的是，一个供应商可能并不擅长所有安全功能。

正如您进一步看到的，如果每个供应商都为其安全功能提供完整的堆栈，那么效率将非常低下，从而产生巨大的成本影响。 此外，它可能会带来更多的延迟，这对某些应用程序来说可能是一个挑战。 因此，新的架构原则和最佳实践的适用性。 软件架构的方式应能够解决效率低下的问题，但能够集成多个供应商技术，以实现最佳的网络安全。

收敛前

图1和图2是之前网络安全的两个有代表性的例子 SASE。 图 1 描述了安全互联网访问，图 2 描述了安全私人访问的示例。 请注意，这些图中的安全功能的顺序是任意的，并且执行顺序通常是特定于部署的。

传统上，安全互联网访问是使用多种安全解决方案来实现的，如图 1 所列。erp购买这些安全功能并将其放入服务链中的崛起。 由于许多安全功能需要代理连接，因此业界也将这种链接称为代理链接。

由于每个离散安全解决方案都是自给自足的并且来自多个供应商，因此这些解决方案重复了通用功能。 常见功能包括入口流量监管、出口流量整形、流量过滤以确保只有相关流量进入代理， TCP 终止客户端连接，新 TCP 前往目的地的连接， SSL/TLS 拦截（本身需要模拟目标证书的按需证书生成），包括 TLS 解密和 TLS 加密、代理身份验证（Kerberos、NTLM、OIDC）、HTTP 1.1/2.0 解码。 据估计，每个盒子/虚拟设备中的这一常见功能占用了整个安全解决方案 CPU 资源的 50%。

安全应用程序访问也可以通过链接离散安全解决方案以类似的方式实现，如图 2 所示。这里，多个安全解决方案的通用功能也是相同的。 它几乎类似于安全互联网访问中使用的安全解决方案的常见功能。 一些差异包括 SSL/TLS 终止而不是拦截，并且通过传统方法进行用户身份验证而不是代理身份验证。

安全解决方案中常见功能的平均开销可能高达整个解决方案的 50%。 由于功能的链接，这种架构导致的延迟可能会增加几毫秒。

耳鼻喉科面临的又一重大挑战erp物理和虚拟设备的崛起在于扩展。 最初，扩展是通过使用更大的设备或为基于虚拟机的安全解决方案分配更多的 CPU 和内存资源来实现的。 这称为扩大规模。 如果流量恒定，这对 Ent 来说是有意义的erp人们越来越愿意花钱购买更大的物理/虚拟设备。 但是，如果流量突发，Enterp上升不喜欢看到金钱被浪费。 想象一下一年中只有几天流量较高的情况。 为什么要恩特erp喜欢一整年都把钱花在这些颠簸上吗？ 这导致了下一次演变，安全供应商开始通过以下方式支持横向扩展架构： cloud- 提供服务。 这就像这样的推理 IaaS ，在 Cloud 应用世界。 在横向扩展架构中，在检测到较高流量或由于 DDoS 攻击时会自动启动更多安全解决方案实例，并在需求下降时将其关闭。 图 3 描述了这种横向扩展架构。

毫无疑问，需要横向扩展功能。 但是，每个安全解决方案都需要一个负载平衡器。 需要此负载平衡器来平衡安全解决方案的多个实例之间的会话。 多个负载均衡器遍历需要更多资源并增加流量会话的端到端延迟。

网络安全架构的下一步发展解决了以下挑战

• 需要更多的计算资源
• 更高的延迟

• 一种代理架构
• 单通道架构

单通道和单代理架构（融合架构）

如下图 4 所示，所有安全功能都与仅出现一次的代理和其他常用功能捆绑在一起。 所有安全功能都以运行到完成的方式一次调用一个。 因此，该架构可以有效地消耗计算资源。 由于所有函数都在同一用户空间上下文中调用，因此避免了内存复制。 此外，一种用户空间进程架构极大地减少了操作系统上下文切换。 单个代理实例可以通过多线程同时处理多个会话，每个线程处理会话的子集，从而有效地利用多核 CPU。 多线程功能还允许对于给定的流量会话并行执行某些安全功能，而不是串行执行，从而改善延迟。 这种架构称为“单通道并行处理”。

为了解决突发负载和DDoS场景，采用自动横向扩展架构，通过一个负载均衡器实例以会话负载均衡的方式进行。

在该架构中，代理公开接口API。 所有安全功能都挂接到该 API 中。 代理在流量会话处理期间调用相关的挂钩安全功能。 所有安全功能可能无法由 SASE 解决方案开发商。 SASE 解决方案开发人员通过将技术供应商引擎和源与代理集成来与技术供应商合作。 这样，客户 SASE 提供商两全其美 – 高性能 SASE 具有最佳的安全实施。

也就是说，一些技术供应商可能不会以 SDK 的形式提供 Engine，用于开发安全功能作为代理的一部分。 他们可能把它当作 cloud 服务。 DLP 就是一个例子，许多技术提供商都将其作为一种 cloud 服务。 此外，在某些情况下，可能 SASE 解决方案提供商可能不会 wan出于内存限制、避免许可证不兼容、避免使用户空间脆弱等原因，不要将一些安全功能集成在代理的同一用户空间进程上下文中。

统一架构&自带安全功能

下一个演变 SASE 架构如下所示。 如下图 6 所示，存在三个突出点。

通过 ICAP（互联网内容适配协议）支持安全服务： 耳鼻喉科erp上升可能习惯或可能喜欢使用其他安全供应商的安全服务。 ICAP IETF 的规范指定了代理如何与外部内容适配服务（包括安全服务）进行通信。 通过允许外部安全服务， SASE 解决方案提供商启用耳鼻喉科erp起身选择自己选择的安全服务。

自带安全功能： 根据 IBM 安全报告“2022 年数据泄露成本报告”，组织平均需要 277 天来检测和遏制数据泄露。 尽管 SASE 提供了非常好的策略配置，可能某些数据泄露遏制需要编程规则。 分析数据泄露的组织处于开发这些程序的有利位置。 根据 SASE 供应商或安全服务提供商可能需要时间，因为产品发布需要经历完整的软件开发生命周期。 为了避免这些延误，新 SASE 架构为 Ent 提供了一种方式erprises 的安全团队自行开发程序化规则并进行部署。 由于这些不会导致代理不稳定， SASE 架构提供 WASM 运行时，以支持将编程规则创建为 WASM 模块。 由于 WASM 运行时充当沙箱，因此 WASM 模块的任何问题都不会导致托管用户空间和其他安全功能插件崩溃/死亡。

统一代理： 用于安全互联网访问和安全应用程序访问的一个统一代理可以减少内存需求。 某些安全功能（例如反恶意软件和 DLP）的引擎和源会占用大量内存。 为每个 Ent 启动两个不同的代理实例erp因此，上升地点的成本可能很高。 此外，从开发人员生产力的角度来看，拥有一个支持所有三种模式（正向、反向和透明）的代理也是一种良好的开发实践。

新一代遵循的附加架构原则 SASE 建筑是

Cloud 本国的： 正如《环球》中所讨论的 SASE 这个的 博客文章, SASE On-Prem 需要服务， Clouds 和边。 因此，新一代 SASE 架构遵循'Cloud 原生的原则 SASE 任何地方工作。 尽管 Cloud 很多时候，native 和 Kubernetes 不是同义词，解决方案说 cloud 本机是基于 Kubernetes 的。 选择让解决方案在 Kubernetes 上运行的原因是： cloud/edge 提供商提供 Kubernetes 即服务，更重要的是，API 接口保持完整 cloud/边缘提供商。 由于 Kubernetes 具有一致的 API 接口 cloud/edge 提供商，基于 K8s SASE 解决方案工作无缝ssly 穿过 cloud/边缘提供商。

隔离架构： 电流 SASE 出于效率原因，架构允许多个租户会话通过共享用户空间进程进行。 即使租户之间存在重叠的 IP 地址，也可以使用巧妙的方法来确保维持某种程度的隔离。 从性能和安全隔离的角度来看，多个租户共享用户空间进程并不是一件好事。 使用共享资源时，任何不当行为（例如对租户的 DDOS 攻击）都可能导致其他租户的流量出现性能问题。 此外，对共享用户空间进程的任何利用都可能暴露所有租户的所有秘密/密码/密钥。 新一代人牢记以上几点 SASE 架构越来越多地通过专用用户空间进程或专用容器来使用专用代理实例。

API优先架构： 电流 SASE 解决方案提供CLI和Portal来配置和观察。 一些 SASE 解决方案使用 CLI/Portal 与后端管理系统之间的 API，但未进行宣传。 在某些情况下，API 并不干净。 新的 SASE 解决方案正在采用 API 优先架构，其中 API 不仅为 CLI 和门户实施定义，而且还为第三方开发外部编程实体定义。 API 通过 terraform 等实现 SecOps-as-code，从简单的脚本开发到复杂的工作流程开发。

通常的做法是使用 RESTful API、JSON 有效负载以及基于 OpenAPI 的文档，但有些还公开 Kubernetes 自定义资源来配置安全和网络对象和策略。

API First 架构还有望将实际后端逻辑与 RBAC（基于角色的访问控制）的实现分开。 行业经验表明，当 RBAC 和业务逻辑结合时，会存在大量漏洞。 因此，业界正朝着将 RBAC 功能分离给外部实体的方向发展，让应用程序专注于业务逻辑。 同样的逻辑也适用于 SASE 管理系统，其中 SASE 管理系统专注于 SAE 策略/对象和可观察性，并将 RBAC 功能留给外部实体，例如入口代理和 API 网关。 入口代理负责所有身份验证和授权以及 API 路由。 一件好事是一个入口代理可以前端多个应用程序。 因此，管理员用户只需熟悉多个应用程序中的一个 RBAC 实体。 对于业务逻辑与 RBAC 的分离，API 优先架构解决方案预计将遵循一些准则。 例如，许多入口代理和 API 网关期望使用 URI 来指向 RBAC 的资源。 在基于工作流的自动化的情况下，期望管理系统可以标记配置并恢复到旧标签以启用传奇模式。 任何 API 优先的架构都应该遵循行业最佳实践。

总结

网络安全架构正在从物理/整体实体发展到虚拟设备和容器。 许多 cloud-在应用程序世界中流行的本机原则正在被采用 SASE 解决方案以获得 cloud- 类似的好处，包括横向扩展/缩小、敏捷性、多功能性cloud / 边缘就绪，并跨多个租户有效地使用资源。 请留意这个空间，了解新的架构原则以及如何 Aryaka 正在利用 cloud类技术。

• CTO 见解博客

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