您可能听说过网络安全方面的多重架构原则，特别是 SASE。 业界在 SASE 范畴内使用的一些软件架构原则包括

  • 单通道结构
  • 单代理架构
  • 运行到完成架构
  • 扩展架构
  • 单通道并行处理架构
  • 自带安全功能架构
  • 云原生架构
  • 隔离架构
  • 应用程序接口优先架构
  • 切片（E2E 分段）架构

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

  • 高效利用资源，提高吞吐量。
  • 更低的端到端延迟
  • 更低的抖动
  • 即使在安全服务受到 DDoS 攻击的情况下，也具有更高的弹性（扩展）和复原能力
  • 更快地引入新的安全功能（灵活性）
  • 整合多个供应商的安全功能，同时不降低效率（整合最佳技术）
  • 可采用性（随处运行）
  • 单面玻璃

演变

网络安全行业的一大特点是它是动态的。 它在每一代新产品中都采用了更新的软件和部署架构原则。 它还能针对攻击者的复杂性提供保护。 尽管如此，网络安全市场历来比较分散。 有多家安全供应商提供不同的安全功能。 从创新的角度来看，这是一件好事，必须予以鼓励，并应继续下去。 需要注意的是，一个供应商不一定擅长所有的安全功能。 正如你进一步看到的那样，如果每个供应商都为其安全功能提供完整的堆栈，就会造成巨大的低效，从而产生巨大的成本影响。 此外，它还会带来更多的延迟，这对某些应用来说可能是一个挑战。 因此，较新的架构原则和最佳实践非常适用。 软件架构应避免效率低下的问题，并能整合多个供应商的技术，以实现最佳的网络安全。

汇聚之前

图 1 和图 2 是 SASE 前网络安全的两个代表性示例。 图 1 描述了安全互联网接入，图 2 描述了安全专用接入的一个示例。 请注意，这些图片中安全功能的顺序是任意的，执行顺序通常取决于具体部署。 传统上，安全互联网接入是通过多种安全解决方案实现的，如图 1 所示
1.企业购买这些安全功能，并将其置于服务链中。 由于许多安全功能需要代理连接，因此这种链也被业界称为代理链。 由于每个独立的安全解决方案都是自给自足的，而且来自多个供应商，因此这些解决方案的通用功能都是重复的。 常见功能包括入口流量监控、出口流量整形、流量过滤，以确保只有相关流量才会进入代理服务器、TCP 客户端连接终止、面向目的地的新 TCP 连接、SSL/TLS 拦截（本身需要按需生成证书来模拟目的地证书），包括 TLS 解密和 TLS 加密、代理服务器身份验证（Kerberos、NTLM、OIDC）、HTTP 1.1/2.0 解码。 据估计，每个盒子/虚拟设备中的这些通用功能占用了整个安全解决方案 CPU 资源的 50%。 如图 2 所示，通过连锁离散安全解决方案，也能以类似方式实现安全应用访问。
2.在这里，多个安全解决方案的共同功能也是相同的。 它几乎与安全上网中使用的安全解决方案的通用功能一样。 一些不同之处包括 SSL/TLS 终止而非拦截，以及通过传统方法而非代理验证进行用户验证。 安全解决方案中常用功能的平均开销可能高达整个解决方案的 50%。 由于功能链的存在，这种架构导致的延迟可能会增加几毫秒。 使用物理和虚拟设备的企业面临的另一大挑战是扩展问题。 最初，扩展是通过使用更大的设备或为基于虚拟机的安全解决方案分配更多的 CPU 和内存资源来实现的。 这就是所谓的扩大规模。 如果流量是恒定的，企业花钱购买更大的物理/虚拟设备是合理的。 但是，如果流量爆棚，企业不愿意看到资金被浪费。 想想看，一年中只有几天的流量比较大。 为什么企业喜欢在这些凹凸不平的地方花钱买一整年？ 这导致了下一次演变，安全厂商开始通过云交付服务支持扩展架构。 这就好比云应用领域的 IaaS 的道理一样。 在横向扩展架构中，当检测到更高的流量或由于 DDoS 攻击时，会自动调用更多的安全解决方案实例，并在需求下降时将其关闭。 图 3 描述了这种横向扩展架构。 毫无疑问，我们需要扩展功能。 不过，每个安全解决方案都需要一个负载平衡器。 需要这种负载平衡器来平衡安全解决方案多个实例之间的会话负载。 多个负载平衡器遍历需要更多资源，会增加流量会话的端到端延迟。 网络安全架构的下一步发展要应对以下挑战

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

与

  • 一个代理架构
  • 单通道结构

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

如下图 4 所示，所有安全功能都捆绑在一起，代理和其他常用功能只出现一次。 所有安全功能都以运行到完成的方式逐次调用。 因此，这种架构能有效地消耗计算资源。 由于所有函数都在同一用户空间上下文中调用，因此避免了内存拷贝。 此外，单一用户空间进程架构也大大减少了操作系统的上下文切换。 单个代理实例可通过多线程同时处理多个会话，每个线程处理一个会话子集，从而有效利用多核 CPU。 多线程功能还允许并行执行某些安全功能，而不是串行执行给定的流量会话，从而改善延迟。 这种架构被称为 “单通道并行处理”。为了应对突发负载和 DDoS 情况，采用了自动扩展架构，其中一个负载平衡器实例将负责会话负载平衡。 在这种架构中，代理会公开接口应用程序接口。 所有安全功能都与该应用程序接口挂钩。 代理在流量会话处理过程中调用相关的挂钩安全功能。 SASE 解决方案开发人员可能无法实现所有安全功能。 SASE 解决方案开发人员与技术供应商合作，将技术供应商引擎和馈送与代理集成在一起。 这样，SASE 提供商的客户就能获得两全其美的服务–高性能 SASE 和最佳安全实施。 尽管如此，一些技术供应商可能不会以 SDK 的形式提供引擎，用于开发作为代理一部分的安全功能。 他们可能将其作为一项云服务。 DLP 就是一个例子，许多技术提供商都将其作为一项云服务。 此外，在某些情况下，SASE 解决方案提供商可能出于内存限制、避免许可证不兼容、避免使用户空间变得脆弱等原因，不想在代理的同一用户空间进程上下文中集成某些安全功能。

统一架构和自带安全功能

SASE 架构的下一步发展如下所示。 以下图 6 显示了三个要点。通过 ICAP（互联网内容适配协议）支持安全服务：企业可能习惯或喜欢使用其他安全供应商提供的安全服务。IETF 的ICAP规范规定了代理如何与外部内容适配服务（包括安全服务）进行对话。
通过允许外部安全服务，SASE 解决方案提供商可让企业选择自己的安全服务。自带安全功能：根据 IBM 关于 “2022 年数据泄露成本报告 “的安全报告，企业平均需要 277 天来检测和控制数据泄露。 虽然 SASE 提供了很好的政策配置，但某些数据泄露控制可能需要程序规则。 对数据泄露进行分析的组织能够很好地制定这些计划。 由于产品发布需要经过完整的软件开发生命周期，因此供应商可能需要时间来确定 SASE 提供商或安全服务。 为了避免这些延误，新的 SASE 架构为企业的安全团队提供了一种自行开发编程规则并进行部署的方法。 由于这些规则不会导致代理的不稳定，SASE 架构提供了 WASM 运行时，以便将编程规则创建为 WASM 模块。 由于 WASM 运行时充当沙箱，WASM 模块的任何问题都不会导致托管用户空间和其他安全功能插件崩溃/死机。统一代理：安全互联网访问和安全应用程序访问使用一个统一的代理，可以减少内存需求。 某些安全功能（如反恶意软件和 DLP）的引擎和馈送会占用内存。 因此，为每个企业站点建立两个不同的代理服务器实例可能成本很高。 此外，从开发人员的工作效率角度来看，使用一个代理支持所有三种模式（正向、反向和透明）也是一种很好的开发方式。

新一代 SASE 架构遵循的其他架构原则包括

云本地：正如本博文的通用 SASE 所讨论的，SASE 服务需要在内部部署、云和边缘中使用。 因此，新一代 SASE 架构遵循 “云原生 “原则，使 SASE 可以在任何地方运行。 虽然云原生和 Kubernetes 并不是同义词，但很多时候，声称云原生的解决方案都是基于 Kubernetes 的。 之所以选择让解决方案在 Kubernetes 上运行，是因为所有云/边缘提供商都提供 Kubernetes 即服务，更重要的是，云/边缘提供商保留了完整的 API 接口。 由于 Kubernetes 的 API 接口在云/边缘提供商之间保持一致，因此基于 K8s 的 SASE 解决方案可在云/边缘提供商之间无缝运行。隔离架构：出于效率考虑，当前的 SASE 架构可通过共享用户空间进程实现多个租户会话。 即使租户之间的 IP 地址重叠，也会使用巧妙的方法确保保持一定程度的隔离。 从性能和安全隔离的角度来看，多个租户共享用户空间进程并不是一件好事。 在共享资源的情况下，任何不当行为，如对租户的 DDOS 攻击，都有可能导致其他租户的流量出现性能问题。 此外，对共享用户空间进程的任何攻击都会暴露所有租户的所有秘密/密码/密钥。 有鉴于此，新一代 SASE 架构越来越多地通过专用用户空间进程或专用容器来使用专用代理实例。API 优先架构：当前的 SASE 解决方案提供 CLI 和门户来进行配置和观察。 有些 SASE 解决方案在 CLI/Portal 与后端管理系统之间使用 API，但没有公布。 在某些情况下，应用程序接口并不干净。 新的 SASE 解决方案正在采用 API 优先架构，其中不仅为 CLI 和门户实施定义了 API，还为第三方开发外部编程实体定义了 API。 应用程序接口可通过 terraform 等实现 SecOps 即代码，从简单的脚本开发到复杂的工作流开发。 一般做法是使用 RESTful API、JSON 有效载荷和基于 OpenAPI 的文档，但也有一些 Kubernetes 自定义资源用于配置安全和网络对象及策略。 API First 架构还有望将实际的后台逻辑与实施 RBAC（基于角色的访问控制）分离开来。 行业经验表明，当 RBAC 和业务逻辑结合在一起时，会出现大量漏洞。 因此，业界正逐步将 RBAC 功能分离给外部实体，让应用程序专注于业务逻辑。 同样的逻辑也适用于 SASE 管理系统，其中 SASE 管理系统侧重于 SAE 策略/对象和可观察性，而将 RBAC 功能留给外部实体，如入口代理和 API 网关。 入口代理负责所有身份验证、授权和 API 路由。 好在一个入口代理可以为多个应用程序提供前端服务。 因此，管理员用户只需熟悉跨多个应用程序的一个 RBAC 实体。 为了实现业务逻辑与 RBAC 的分离，API 优先架构解决方案应遵循一些准则。 例如，许多入口代理和 API 网关都希望使用 URI 指向 RBAC 的资源。 就基于工作流程的自动化而言，人们期望管理系统能够标记配置并恢复到旧的标记，以实现传奇模式。 任何 API 优先架构都应遵循行业最佳实践。

摘要

网络安全架构正在从物理/单体实体向虚拟设备和容器演变。 SASE 解决方案采用了许多在应用领域流行的云原生原则，以获得类似云的优势，包括扩展/引入、敏捷性、多云/边缘就绪以及跨多个租户高效使用资源。 请关注本栏目的新架构原则以及 Aryaka 如何利用云技术。

  • CTO Insights 博客

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