云原生应用的数据保护方法

NIST内部报告                     NIST IR 8505

云原生应用的数据保护方法

拉马斯瓦米·钱德拉穆利

韦斯利·黑尔斯

2024年9月

本出版物可从以下网站免费获取：

https://doi.org/10.6028/NIST.IR.8505

编译 老烦的草根安全观

2025年2月

1.导言

在云原生应用程序架构不断发展的环境中，数据驻留在多个位置（即本地和云端），确保数据安全不仅仅涉及在服务请求期间指定和授予授权。它还涉及一种全面的策略，对数据在各种协议（例如，gRemote Procedure calls（gRPC）、基于表示性状态传输（REST））之间传输时的数据访问和泄漏进行分类和分析，特别是在短暂和可扩展的微服务应用程序中。

根据NIST网络安全框架（CSF）2.0，传输中的数据是数字数据的三种状态之一。它指的是结构化和非结构化的人类可读文本，这些文本正在从一个位置主动移动到另一个位置，例如通过互联网、专用网络或设备和系统之间。这可能包括从客户端到服务器、服务器之间或从网络的一部分到另一部分的数据传输。

1.1. 现有的数据保护方法及其局限性

传统上，正则表达式（regex）已被广泛用于数据分类，以在关键字和验证器的帮助下识别与预定义类别或数据类匹配的模式，从而提高精度。尽管这种方法被广泛采用和使用，但它有明显的局限性。处理时间与数据量呈线性关系，因此对于非常大的数据集来说是不切实际的。正则表达式还缺乏逻辑计算的能力，而逻辑计算对于信用卡号中的校验和等复杂验证是必要的。它的有效性在很大程度上依赖于与特定关键字的正确接近，如果管理不当，可能会导致潜在的误报和相当大的噪音。

机器学习（ML）通过从数据模式中学习并随着时间的推移而改进，为数据分类提供了有前景的增强，从而提供了一种可扩展和可适应的解决方案。机器学习算法可以处理结构化和非结构化数据，根据历史数据预测数据类别，并在不进行显式重新编程的情况下适应新的模式。这种适应性大大减少了管理复杂数据集所需的时间和计算资源，对静止和运动中的数据都很有效。

为了解决和弥补传统静态数据库存的局限性，在途数据分类最近被视为数据保护的下一个合乎逻辑的步骤。与仅保护存储信息的前者不同，在途分类在数据跨服务和网络协议移动时主动监控和保护数据。这种向网络内实时数据分析的转变带来了新的可观察性能力，消除了对流量镜像和数据复制的需求。

1.2. 数据保护的代理应用

为了满足跨服务转发期间对数据分类的需求，越来越多地部署了一类相对较新的代理内应用程序，称为WebAssembly[1]程序（也称为WASM模块）。WASM模块是一个轻量级的可执行文件，被编译为低级字节码。这个字节码可以是：

a)由使用其关联的WebAssembly编译器（包括C、C++和Rust）用任何语言编写的代码生成

b)在代理内的隔离虚拟机（VM）中使用WASM运行时运行，这允许开发人员增强具有必要功能的应用程序，并像代理中的本机代码一样高效地运行它们。

在过去的几年里，Envoy WASM VM[3]启用了新型的计算和流量处理功能，并允许以沙盒和容错方式构建和部署自定义WASM模块。

此外，WebAssembly模块的以下特性使其在数据保护方面特别有效：

数据发现和分类：WASM模块可以在数据通过网络时动态识别和分类数据，确保敏感信息得到识别和适当处理。

动态数据屏蔽（DDM）：WASM模块可以应用DDM技术来编辑或屏蔽传输中的敏感信息，从而增强隐私和安全性。

用户和实体行为分析（UEBA）：WASM模块可以实时分析用户和实体的行为，检测异常和潜在的安全威胁。

数据丢失防护（DLP）：WASM模块可以通过监控数据传输来执行DLP策略，以防止未经授权的数据泄露。

1.3. 本文件的目的和范围

基于微服务的应用程序的所有服务（如网络、安全、监控）都由一个名为服务网格的集中式基础设施提供，该服务网格的数据平面（执行所有运行时任务）由代理组成。本文档概述了有效数据保护的实用框架，并强调了WebAssembly（WASM）在服务网格架构、多云环境和混合（即本地和基于云的组合）基础设施中的多功能性。通过专注于第4-7层的在线网络流量分析，组织可以增强安全性，简化运营，并利用自适应数据保护措施。

1.4. 本文件的组织

本文件组织如下：

第2节详细描述了WASM模块的执行环境，包括其运行的应用基础设施（即服务网格）、特定的主机环境（即代理）、生成字节码和可执行文件的过程、使用WASM运行时执行模块的过程以及用于访问底层平台的操作系统（OS）资源的应用编程接口（API）（即WebAssembly System interface（WASI））。

第3节介绍了数据分类的概念和各种数据保护技术（如数据屏蔽、编校）的使用，以确保使用WASM模块在不同领域或应用场景中的数据安全，如网络流量数据保护、API安全、微分段、日志流量数据保护和大型语言模型（LLM）流量数据保护，以及与监控工具的集成，以实现敏感数据流的可视化。

第4节通过检查WASM模块的开发、部署和执行环境，对WASM模块进行了详细的安全分析，以确保该模块满足安全内核的属性，并能够提供必要的安全保证。

第5节概述了本文档所涵盖的主题，并讨论了WASM模块功能必须如何不断发展，以提供在日益复杂的数据攻击背景下防止数据泄露和泄漏所需的安全保证。

2. Web组装背景

WebAssembly模块被部署用于保护基于微服务的架构上的数据，在这种架构中，整个应用程序（也称为云原生应用程序，因为它在云和混合环境中无处不在）由几个分布式、松散耦合和独立可扩展的组件组成，称为微服务。这类应用程序的所有服务（例如，网络、安全策略执行、状态监控、运行时参数配置）都由称为服务网格的集中式独立于应用程序的服务基础设施提供。该服务网格由一个数据平面组成，该数据平面主要由容纳各种服务模块的代理组成。使用代理提供的API系列，使用服务网格的管理/控制平面实现相关服务模块（例如网络路径确定）。WebAssembly是在服务网格的数据平面代理中实现的一个这样的服务模块生态系统。

2.1. 产地

WASM模块起源于浏览器环境，旨在在内存安全的沙盒中运行，使其比运行客户端JavaScript更安全。在浏览器中运行WebAssembly代码的执行模型在附录A中给出。除了安全性之外，WASM模块还具有以下优点[1]：

性能：由于其针对现代处理器的低级二进制格式，WASM模块提供了接近原生的性能。因此，它被认为是与HTML、级联样式表（CSS）和JavaScript并列的网络“第四语言”，旨在在浏览器中实现高性能应用程序。

广泛支持：它具有广泛的可访问性，并在Chrome、Firefox、Edge和Safari等流行浏览器中得到支持。

2.2. 进入服务器端环境

当Mozilla引入了一个名为WebAssembly系统接口（WASI）的开源项目时，WASM模块从浏览器环境发展到服务器环境，该项目为WebAssemble应用程序访问操作系统资源提供了一个框架[4]。这允许内容交付网络（CDN）使用WebAssembly部署客户的应用程序，而无需让他们访问底层CDN基础设施。

2.2.1. 开发和部署过程

多种语言的WASM编译器的出现使开发人员能够使用他们喜欢的语言来创建服务器端应用程序。此外，服务器端WASM代码可以在容器和VM内运行。它是基于SaaS产品的潜在候选者，就像VM和容器一样。它的可移植性允许应用程序在任何地方运行，使其成为各种用例的有吸引力的选择。

开发WASM模块并使用WASM运行时运行它的步骤是[6]：

源代码编写：程序是用具有目标WASM编译器的语言（如C++、C#、Rust）编写的。

解析：代码被解析为抽象语法树（AST）结构。

编译：然后使用提前时间（AOT）或准时制（JIT）将抽象语法（AST）结构的代码编译成WASM模块。WASM模块以二进制格式生成，可由WASM运行时执行。

WASM运行时加载：WASM运行库加载WASM模块（文件扩展名为.WASM）。如果使用JIT，编译将在加载到WASM运行时后进行。

执行准备（即实例化）：WASM运行时通过分配内存、导入函数和对象以及为模块建立执行环境，从WASM模块创建可执行实例。

代码优化：在执行字节码期间，采用分析来识别频繁执行的代码，并进行渐进式优化/重新优化过程，以逐步提高性能，直到代码高效运行。

图1显示了用不同语言开发程序、将其转换为WASM代码并在不同处理器架构下运行程序的能力[4]。附录B中描述了服务器环境中WASM模块的执行模型及其与容器执行模型的比较。

图1. 生成WASM模块及其执行[4]

2.3. 代理作为WASM平台

代理越来越多地被用作执行WASM模块的平台。在基于云原生和微服务的应用程序中，代理调解服务间的通信。代理中的开源项目，如Envoy，已经扩展了它们的过滤链，以允许调用和执行WASM模块。这些WASM模块可以执行基于策略的授权或实施网络弹性措施，为这些应用程序提供基本的安全控制。此外，这些模块的功能可用于数据保护目的。

基于网络的WASM模块的优点包括：

1.可扩展性：像Envoy这样的代理可以用WASM模块进行扩展，允许开发人员在不修改代理核心代码库的情况下引入自定义逻辑和功能。这种可扩展性允许无缝集成新特性和功能。

2.安全和隔离：WASM模块在沙盒环境中运行，提供与主机系统和其他模块的隔离。这种隔离通过防止未经授权访问系统资源和减轻潜在漏洞的影响来增强安全性。

3.可移植性：WebAssembly的可移植性确保WASM模块可以在不同的代理实现和平台上一致运行，从而促进了一次编写、随处运行的方法。

4.性能：与用于代理扩展的传统脚本语言相比，WASM模块可能提供更好的性能，因为它们可以被编译成高效的机器代码。

5.策略执行和网络弹性：通过在代理中执行WASM模块，组织可以执行策略，实施授权控制，并在代理级别引入网络弹性措施，确保跨分布式应用程序的一致和集中执行。

6.数据保护：代理中的WASM模块可用于实现数据过滤、转换或加密机制，并确保敏感数据在通过代理时得到保护。

7.生态系统和社区：不断增长的WebAssembly生态系统和社群提供了库、工具和资源，促进了协作，加快了代理扩展和数据保护解决方案的开发。

随着WASM的不断成熟，它在代理中的作用将不断扩大，使代理能够作为安全和应用程序逻辑执行的强大平台。这一演变与数据保护尤其相关，数据保护是当代应用程序开发的核心主题。

2.4. 代理WASM

Envoy Proxy是一种开源边缘和服务代理，在许多服务网格部署中，它在管理微服务之间的流量方面发挥着关键作用。它为各种服务提供的可扩展API的集合被指定为xDS。利用Envoy代理的这些基本、基础API的可扩展性的扩展API是代理的WebAssembly（Proxy-WASM）运行时。

Proxy WASM通过在代理服务器中部署WebAssembly模块来扩展Envoy Proxy的适应性。这种集成允许直接在代理中执行自定义代码，提供独立于平台的安全环境。WebAssembly的模块化使其成为扩展Envoy Proxy功能的理想选择，而无需重新编译或对现有基础设施进行重大更改。

Envoy Proxy中的Proxy WASM架构允许在请求-响应周期的各个阶段无缝集成和执行自定义逻辑。例如，WASM模块可以在继续之前拦截请求、检查有效载荷数据、应用数据分类和编辑数据。这种级别的粒度控制增强了微服务架构的安全性，同时保持了性能和可扩展性。因此，我们可以看到，通过在代理中直接执行数据分类和缓解等任务，可以利用代理WASM为微服务通信实施强大的安全措施。

2.4.1. WASM在不同服务网格架构中的作用

服务网格架构传统上使用sidecar 代理，这些代理被实现为容器，并与Kubernetes中的每个服务一起部署[5]pod。这些sidecar代理管理各自服务的入站和出站流量，为在途分类创建了一个理想的基于WASM的插入点。

此外，较新的架构模式（例如代理实现/部署模型）认识到sidecar代理过多，因为许多服务没有L7级服务。环境代理模式 旨在通过集中和简化流量管理和策略执行来简化sidecar模型。在这种模式中，航路点代理部署在节点级别，为每个命名空间或每个服务帐户提供应用程序服务。他们管理指定范围内服务的所有入口和出口流量。在这两种代理部署模型中，WebAssembly VM以完全相同的方式拦截和分析流量，为基于WASM的数据分类策略和模块提供透明的部署。

除了传统的基于Envoy的服务网格代理之外，还有几个运行时环境可以部署WASM模块来对传输中的敏感数据进行分类。许多API网关现在支持WASM以及商业内容交付网络（CDN）平台，如Fastly的WASM计算平台[16]和Cloudflare的WASM Workers[17]。

2.5. WASI-HTTP

凭借其应用程序二进制接口（ABI），Proxy WASM促进了WebAssembly模块和主机环境（特别是代理）之间的通信。它有一个被各种代理服务器采用的成熟规范，其起源可以追溯到Envoy项目中使用WebAssembly扩展代理服务器功能的努力。Proxy WASM确保为一个代理编写的扩展可以在其他代理中重用，从而促进了一次写入、随处运行的方法。Proxy WASM的ABI和事件驱动流式API已被整合到几个生产级代理中，展示了该项目的实际应用和影响。

相反，WASI-HTTP——一种基于WASM的API——通过迭代来定义接口，以便直接在WASM模块中处理超文本传输协议（HTTP）请求和响应。它旨在为基于WebAssembly的HTTP代理提供一个最小和简化的执行环境，并旨在与现有的web基础设施（如服务工作者和反向代理）无缝集成，而不需要复杂的运行时系统。WASI-HTTP已经在某些环境中投入生产，并支持可扩展和动态的WASM实例创建以响应web流量，为未来的创新奠定了基础，例如通过组件模型链接HTTP中介。

WASI-HTTP和代理WASM都在塑造网络和分布式系统中的WebAssembly格局。虽然WASI-HTTP允许在WebAssembly应用程序中简化HTTP通信，但Proxy WASM展示了跨多个代理实现的标准化接口的成功实现。他们的合作开发突显了一种共生关系，WASI-HTTP可能利用Proxy WASM的应用程序二进制接口（ABI）来进一步增强WebAssembly在网络场景中的功能和范围。

2.6. eBPF

使用WASM在第4-7层解析人类可读的文本比扩展伯克利包过滤器（eBPF） 等技术具有几个优势，特别是在处理复杂的应用层数据方面，如HTTP。虽然eBPF在内核中直接进行数据捕获和操作非常强大，但它用于解析详细的HTTP流量可能很复杂，对于某些应用程序来说可能会过多。这种复杂性源于需要在内核中处理HTTP的复杂性——如果管理不当，这项任务可能会限制性能并引入安全问题。此外，eBPF施加了许多限制，需要额外的数据处理和通用计算。

WASM提供了一个安全的沙盒环境，适用于跨多个平台高效执行代码和解析应用层协议。WASM可用于用户空间和服务器环境，允许更容易地与现有的解析库和工具集成，降低复杂性，并可能提高解析操作的可靠性。它的可移植性和嵌入各种运行时环境的能力使其成为网络流量分析任务的实用选择，包括那些涉及处理人类可读文本的协议的任务。

3.传输中的数据保护

数据保护的首要和最基本的任务之一是对数据进行分类，以确定是否需要进一步操作（例如，净化、过滤）。

3.1. 数据分类技术

传输中的数据在结构化和非结构化格式之间可能存在很大差异。对于实时分类和保护，必须注意制定正确的方法。每个分类事件的性能对于确保在过程中添加最小的延迟至关重要。通过在代理中执行WASM模块，组织可以在代理级别实现数据分类和过滤机制。这种方法允许在敏感数据在服务之间流动时对其进行识别和保护。

正则表达式和ML模型可用于这些WASM模块中，以实时检测模式和对数据进行分类，从而实现适当的数据保护措施，如编校、加密或访问控制策略。正则表达式匹配可以识别细微分类方案的复杂模式，机器学习工具可以检测表示分类属性的模式。后一个过程涉及对一组示例数据进行分类，并训练一个或多个模型来分析和分类未来的数据。虽然它可能是最有效的自动分类方法，但它需要大量的设置和管理。训练数据集必须全面，为准确的分类检测提供充足的信息。

与其他对静态数据进行操作的数据分类技术不同，在分析传输时，跨境分类提供了额外的时间维度。当将数据分类与访问或发送时间相结合时，数据流可以可视化和理解。一旦模型在正常的数据流模式上进行了训练，就很明显何时发生了数据访问违规，或者何时建立了不允许的数据流。通过利用代理中WASM模块的功能，组织可以了解数据流，检测异常，并在敏感数据在云原生和基于微服务的应用程序中的服务之间移动时采取主动措施保护敏感数据。

3.2. 数据保护技术

本节描述了WASM模块中数据保护技术——动态数据屏蔽（DDM）、用户和实体行为分析（UEBA）以及数据丢失预防（DLP）在各种应用场景中的实际应用，重点介绍了与每个应用场景相关的域数据。

3.2.1. Web流量数据保护

跨HTTP/2和gRPC等web协议的传输中数据分类使服务和客户端之间的数据流具有可观察性。通过对动态数据进行分类，组织可以监控未经身份验证和经过身份验证的身份如何访问敏感信息。WASM模块可以使用正则表达式和ML模型来识别HTTP有效载荷中的敏感数据模式，并根据配置的策略对机密数据传输进行编辑、屏蔽或阻止。示例应用包括：

电子商务网站：在交易过程中监控信用卡详细信息和个人信息，以确保它们被正确加密和屏蔽，防止未经授权的访问。

医疗保健应用程序：在系统之间传输之前，通过检测和加密敏感信息（如医疗记录和个人标识符）来保护患者数据。

公司通信：扫描和保护内部电子邮件和消息，以防止数据泄露，并确保遵守内部数据保护政策。

3.2.2. API安全

API是敏感数据的关键渠道，经常成为攻击的目标。监控API之间传输的数据对于检测漏洞至关重要，例如应用程序级DDoS攻击、SQL注入或数据泄露。许多API网关和服务网格支持运行WASM模块以增强安全性。这些模块可以实现API流量的身份验证、速率限制和有效负载检查。示例应用包括：

金融服务：通过检测和阻止SQL注入尝试和未经授权的访问尝试，保护处理金融交易的API端点。

社交媒体平台：通过API监控数据流，以防止用户数据泄露，并确保登录凭据和个人消息等敏感信息得到保护。

物联网设备：保护从物联网设备传输到后端系统的数据，并检测可能表明安全漏洞的数据模式中的异常。

3.2.3. 微隔离

在微隔离中，跨境数据分类增强了资产列表报告。这种高级分类使组织能够识别和跟踪关键资产及其数据流，以确保与数据保护策略保持一致。这种精细的洞察力对于处理PII或财务数据的资产尤其有价值，可以加强数据治理和合规工作。

虽然Kubernetes（K8s）网络策略提供了分段，但管理和测试这些策略可能会占用大量资源。传统的网络策略依赖于静态规则集，需要细致的配置和维护。跨动态环境的全面测试带来了运营挑战，这些策略缺乏对数据内容的精细可见性，难以准确区分合法和恶意流量。相比之下，在途数据分类提供了一种动态和精细的方法。通过实时分析数据流，组织可以对网络流量的内容和上下文获得可操作的见解。这使得能够根据数据属性（如敏感级别或合规要求）精确执行安全控制。示例应用包括：

金融机构：实施微隔离，以保护处理交易处理的关键系统，确保只有授权服务才能访问敏感的财务数据。

医疗保健提供者：隔离医院内的网络，以确保医疗设备和患者数据系统与安全性较低的管理网络隔离开来。

零售链：使用实时数据分类来管理销售点系统和后端库存系统之间的数据流，以防止未经授权访问销售数据和客户信息。

3.2.4. 日志流量数据保护

受监管的组织经常面临敏感数据泄露到日志流中的挑战。由于所有日志协议都在第4层运行，并在服务网格内遍历服务代理，因此从源头上解决潜在的泄漏问题，使组织能够在数据分散到各种存储系统之前保护数据，有效地降低了暴露的风险。

示例应用包括：

金融服务：确保交易日志不包含未屏蔽的信用卡号或个人身份信息，以防止意外泄露。

医疗保健提供者：在存储或传输到日志系统之前，通过编辑敏感信息来保护系统日志中的患者数据。

电子商务平台：监控和清理日志数据，防止客户订单详细信息和个人信息泄露。

3.2.5. LLM流量数据保护

由于其可扩展性需求，大语言模型（LLM）通常在服务网格架构内运行。对传输中的即时数据和响应数据进行分类对于治理至关重要。这使组织能够保持对部署的LLM数据流的可见性，并确保符合数据保护的监管标准和组织政策。

示例应用包括：

客户支持系统：监控客户和自动化支持机器人之间的交互，以确保敏感的客户数据不会被无意中暴露或记录。

内容审核：确保LLM为内容审核处理的数据符合隐私法规，以保护用户信息。

数据分析服务：对分析平台中LLM使用的数据进行分类和保护，以防止未经授权访问敏感的业务见解和客户数据。

3.2.6. 信用卡相关数据保护

WASM模块还用于保护与信用卡交易相关的数据，如PCI DSS 4.0规范所述。这是通过将以下功能整合到WASM模块中来实现的：

明确识别并记录存储、处理或传输敏感数据（如持卡人数据、身份验证值、加密密钥）的所有区域。这包括处理持卡人数据的数据库、服务器、应用程序和网段。

生成数据流图或其他技术或拓扑解决方案，以识别跨系统和网络的账户数据流。

确定支付交易各个阶段（如授权、结算、退款和退款）和接受渠道（如有卡、无卡和电子商务）的所有数据流。

3.2.7. 可视化敏感数据流的监控工具

WASM模块还可以编程，以各种格式收集和发送指标和遥测数据到用于可视化敏感数据流的监控工具（例如Prometheus、Grafana）。通过检查敏感数据流随时间的正常速率，可以使用峰值等视觉指标来识别数据泄漏事件和未经授权的数据暴露。随后的调查可以确保遵守数据保护法规，并降低持续数据泄露的风险。

4. WASM模块的安全性分析

为了实现部署WASM模块的安全目标，这些模块执行的整个生态系统必须遵守安全内核的属性：

1.它总是被调用（即不可绕过）。

2.它很小，可以验证。

在服务网格中的两个代理实现模型的上下文中考虑第一个属性的满意度。在sidecar代理模型中，代理被实现为一个容器，与同一pod中的每个微服务共存，并在与服务相同的网络空间中运行。所有进出微服务的流量都必须通过代理和代理内运行的应用程序。因此，提供部署在代理内部的数据保护功能的WASM模块将始终被调用。在环境代理实现模型中，到与名称空间相关联的服务或服务组的网络链接必须通过托管为指定名称空间的服务或该服务组提供服务的路点代理的节点。不存在到服务或服务组的直接网络路径。同样，WASM模块为必须调用代理范围内的服务提供数据保护。

为了满足安全内核的第二个属性（即安全性是可验证的），必须对WASM模块的整个执行环境进行安全分析。WASM模块的生命周期始于某种支持语言（如C、C++或Rust）的源代码，然后使用目标编译器（如使用LLVM）将其编译为由运行时模块（即WASM运行时）运行的二进制字节码。对操作系统或主机资源的访问是通过调用实现名为WASM系统接口（WASI）的API的模块来实现的。

WebAssembly生态系统的安全分析可以从以下主题来考虑：

1.WASM安全目标和安全功能集

2.内存模型和内存安全

3.执行模型和控制流完整性

4.API访问操作系统/主机资源的安全性

5.防止侧信道攻击

6.防止注射攻击

7.部署和操作安全

4.1. WASM安全目标和安全功能集

WASM安全模型有两个重要目标：（1）保护用户免受有缺陷或恶意模块的攻击，（2）为开发人员提供有用的原语和缓解措施，以便在（1）[8]的约束下开发安全的应用程序。

4.1.1. 用户级安全功能

每个WASM模块都在沙盒环境中执行，该环境使用故障隔离技术与主机运行时分离。这意味着：

应用程序独立执行，如果不通过适当的API，就无法退出沙盒。

应用程序通常以确定性的方式执行，例外情况有限。

此外，每个模块都受其嵌入的安全策略的约束。在web浏览器中，这包括通过同源策略对信息流的限制。在非web平台上，这可能包括POSIX安全模型。

4.1.2. 面向开发人员的安全原语

WebAssembly的设计通过消除其执行语义中的危险特性来促进程序的安全，同时保持与为C/C++编写的程序的兼容性。模块必须在加载时声明所有可访问的函数及其相关类型，即使使用动态链接也是如此。这允许通过结构化控制流隐式执行控制流完整性（CFI）。由于编译后的代码是不可变的，在运行时不可观察，WebAssembly程序受到保护，免受控制流劫持攻击。

函数调用必须指定与函数索引空间或表索引空间中的有效条目对应的目标索引。

间接函数调用在运行时需要进行一种签名检查，所选间接函数的签名类型必须与调用站点指定的签名类型匹配。

受保护的调用堆栈不受模块堆中缓冲区溢出的影响，可确保安全的函数返回。

分支必须指向封闭函数内的有效目的地。

4.2. 内存模型与内存安全

由于WASM只定义了四种主要数据类型，因此针对WASM的编译器在称为线性内存的区域中实现了自己的堆栈，该区域成为WASM程序的主存。线性内存是一个连续的、字节可寻址的内存范围，可以看作是一个非类型化的字节数组。这使得程序能够存储非标量数据和任何需要由模块获取地址的变量[10]。除了线性内存，还有代码空间、执行堆栈和运行时数据结构[11]。执行堆栈主要存储局部变量、全局变量和返回地址。

以WASM为目标的编译器还会在线性内存中为堆创建一个区域。该区域保留在线性存储器的末尾，以便在为线性存储器分配额外空间时可以动态增长。这种线性内存是沙盒——与代码空间、执行堆栈和运行时数据结构脱节[11]——并防止WASM模块访问其他内存区域。这些其他内存区域与运行时的内部内存隔离，除非另有初始化，否则默认设置为零。然而，模块可以通过专用指令访问存储在执行堆栈上的数据。执行堆栈上的实际数据地址永远不会显示给模块。兼容的运行时确保模块不会破坏WASM的内存模型[12]。这是通过在区域级别绑定对线性内存的访问来实现的。如果模块访问线性存储器之外的存储器，程序会捕获并阻止模块访问其分配的存储器之外的数据[11]。

另一类常见的内存安全错误涉及不安全的指针使用和未定义的行为。这包括取消引用指向未分配内存（例如NULL）或已释放内存分配的指针。在WebAssembly中，对于具有固定静态作用域的函数调用和变量，指针的语义已被消除，允许在任何索引空间中引用无效索引，从而在加载时触发验证错误，或者在最坏的情况下在运行时触发陷阱。

然而，边界检查过程是在线性存储器级别执行的，模块可以不受限制地访问整个线性存储器。线性内存不受堆栈金丝雀或保护页等标准技术的保护。因此，缓冲区溢出（当数据超过对象的边界并访问相邻的内存区域时发生）不会影响存储在索引空间中的局部或全局变量。存储在线性内存中的数据也可能覆盖相邻对象，因为边界检查是以线性内存区域粒度执行的，并且对上下文不敏感。

4.3. 执行模型和控制流完整性

WASM代码在实例化模块或在给定实例上调用导出函数时执行[12]。WASM模块的执行行为是根据对程序状态进行建模的抽象机器来定义的。此抽象机包括一个记录操作数值和控制构造的堆栈，以及一个包含全局状态的抽象存储。

WASM主要通过语言本身的执行语义来实现控制流的完整性。WASM字节码[12]的定义限制了可能表达的构造。它定义了有效的代码构造，以及控制流如何只能跳到有效构造的开头。不允许任意跳转（例如goto语句）；仅提供结构化的控制流。因此，语法上有效的WASM模块只能跳到有效构造的开头（例如，条件构造或函数）[11]。

影响控制流完整性的另一个因素是通过限制间接函数调用来防止调用重定向。对模块可以间接调用的函数施加限制。为了间接调用函数，该模块提供了一个表的运行时索引。此表保存了模块定义或导入的函数的签名，这些函数可以间接调用。当进行间接调用时，运行时会检查调用签名和被调用函数的签名是否匹配。如果存在类型不匹配或表访问越界，则会出现陷阱[11]。

4.4. API访问操作系统和主机资源的安全性

默认情况下，WASM无权访问主机的资源（例如，文件系统、网络、系统调用）。模块可以导入主机或其他模块提供的外部定义函数。许多用例通用的API目前正在WASI中标准化[13]。WASI的基于能力的安全模型允许引入经过验证的安全运行时系统，如[14]所示。

4.5. 防止侧信道攻击

WASM语言规范[12]明确指出，侧通道攻击将由运行时解决。目前，Wasmtime实施了几种形式的Spectre缓解措施。对间接调用和其他一些指令中使用的运行时索引的边界检查得到了缓解，以确保猜测达到确定性[15]。然而，可能会发生一些侧信道攻击，例如对模块的定时攻击。将来，运行时或工具链可能会提供额外的保护，例如代码多样化或内存随机化，如寻址空间布局随机化（ASLR）或有界指针（即“胖”指针）。

4.6. 防止代码注入和其他攻击

控制流完整性和受保护的调用栈可防止直接代码注入攻击。因此，WASM程序不需要常见的缓解措施，如数据执行保护（DEP）和堆栈崩溃保护（SSP）。然而，WebAssembly的语义并不能消除其他类型的错误。虽然攻击者无法执行直接代码注入攻击，但可以使用针对间接调用的代码重用攻击来劫持模块的控制流。然而，在WebAssembly中，使用短指令序列（即“小工具”）的传统面向返回编程（ROP）攻击是不可能的，因为控制流完整性确保了调用目标是在加载时声明的有效函数。

同样，在WebAssembly中也可能出现竞争条件，例如检查时间到使用时间（TOCTU）漏洞，因为除了按顺序执行外，没有提供执行或调度保证。另一个安全限制是没有审计工具来跟踪WASM模块所做的更改。

4.7. 部署和操作安全

到目前为止描述的安全功能与运行时安全有关。以下功能与部署和操作完整性的控制有关。

在代理中创建WASM过滤器的能力可以通过服务网格中的本机访问机制（例如RBAC）进行控制。

只允许使用HTTP和gRPC协议的调用。

即使进行这些调用，也只能使用代理已知的集群。同样，对来自代理已知集群的响应进行检查。

5.总结和结论

本文档描述了如何在服务网格代理中开发和部署WASM模块，以实时保护云原生应用程序架构中传输的数据。各种数据保护技术也可用于保护各种应用场景的不同领域中的数据。WASM模块可以为提供敏感数据流可视化图像的监控工具提供遥测数据。对WASM模块开发、部署和执行环境进行详细的安全分析，可以确保通过将模块作为应用程序基础设施环境的一部分（例如，服务网格代理）运行来获得必要的安全保证。

WASM模块内置的数据分类和保护技术必须不断发展，以跟上对数据日益复杂的攻击的步伐，这些攻击会导致新形式的数据泄露、数据泄漏和其他形式的数据泄漏。

参考

[1]Doerrfeld B（2023）Wasm：Kubernetes之外的下一代？可在https://cloudnativenow.com/features/wasm-the-next-generation-beyond-kubernetes/

[2]Krasnov M（2020）网络大会是我们所知道的互联网的终结https://betterprogramming.pub/webassembly-is-the-end-of-the-internet-as-we-know-it-9085a49cbc7b 

[3]WebAssembly（2024）的概念。可在https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts#see_also

[4]TechTarget（2022）服务器端WebAssembly准备在2023年起飞。可在https://www.techtarget.com/searchitoperations/news/252527414/Server-side-WebAssembly-prepares-for-takeoff-in-2023 

[5]Medium（2023）WASM和Kubernetes——应用程序开发的新时代。可在https://medium.com/@seifeddinerajhi/wasm-and-kubernetes-a-new-era-of-cloud-native-application-deployment-b3c59b39f640

[6]Podobnik TJ（2023）WASM运行时与容器：冷启动延迟（第1部分）。可在https://levelup.gitconnected.com/wasm-runtimes-vs-containers-performance-evaluation-part-1-454cada7da0b  

[7]ITPro（2024）今天的WASM，明天的AI：KubeCon扩大了其影响力。可在https://www.itprotoday.com/ai-machine-learning/wasm-today-ai-tomorrow-kubecon-expands-its-reach  

[8]Security.md（2018）WebAssembly安全。可在https://github.com/WebAssembly/design/blob/main/Security.md

[9]Huang W，Paradies M（2021）计算存储环境中WebAssembly和eBPF作为卸载机制的评估。可在https://marcusparadies.github.io/files/ebpf_vs_wasm_report.pdf

[10]Lehmann D，Kinder J，Pradel M（2020）一切旧的都是新的：WebAssembly的二进制安全性。第29届USENIX安全研讨会（USENIX Security 20），第217-234页。可在https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann

[11]哈斯A、罗斯伯格A、舒夫DL、蒂泽BL、霍尔曼M、高曼D、瓦格纳L、扎凯A、巴斯蒂安·JF（2017）。使用WebAssembly加速web。PLDI 2017:第38届ACM SIGPLAN编程语言设计与实现会议论文集（ACM，巴塞罗那），第185-200页。https://doi.org/10.1145/3062341.3062363  

[12]WebAssembly社区组（2023）。WebAssembly规范。2.0版草案（2023年4月24日草案）。可在https://webassembly.github.io/spec/ 

[13]WebAssembly社区组（2023）。WebAssembly系统接口。可在https://github.com/WebAssembly/WASI

[14]Johnson E，Laufer E，赵Z，Gohman D，Narayan S，Savage S，Stefan D，Brown F（2023）WaVe:一个可验证的安全WebAssembly沙盒运行时。2023 IEEE安全与隐私研讨会（SP）（IEEE，旧金山），第2940-2955页。https://doi.org/10.1109/SP46215.2023.10179357  

[15]浪费时间（2023）。安全-浪费时间。可在https://docs.wasmtime.dev/security.html   

[16]快速文档（2023）。计算。可在https://docs.fastly.com/products/compute 

[17]WebAssembly（Wasm）（2024）工人。可在https://developers.cloudflare.com/workers/runtime-apis/webassembly/

附录A.浏览器中Web组装的执行模型

WASM运行时起源于支持运行本机代码的浏览器（即用C、C++、Rust等低级语言编写的代码）。

图2. 浏览器中WASM模块的开发与执行

WebAssembly程序通过编译器（也称为WebAssembly-目标编译器）运行，该编译器将代码输入到符合LLVM的语言中，并生成二进制.wasm文件。该文件由JavaScript互操作层加载到现有的JavaScript代码中，并由WebAssembly运行时执行[2]。.wasm文件是二进制格式的低级汇编语言文件。

C、C++和Rust的WASM编译器获取用这些语言编写的源代码，并将其编译成WASM模块。然后生成加载和运行模块所需的JavaScript“粘合”代码，并使用HTML文档显示代码的结果。这一过程的细节在[3]中进行了解释。

附录B.容器和WASM模块执行模型的比较

图3.容器和WASM模块执行栈的比较

容器映像是通过在容器运行时（如docker）中将包含应用程序逻辑的程序与其依赖项（如运行时库）组合而创建的。容器是一个完整的文件系统（即实用程序、二进制文件），生成的映像应该用于指定的操作系统内核和处理器架构（例如Intel、Arm）。例如，如果Raspberry Pi操作系统正在运行docker镜像，那么必须为基于Linux镜像的C/C++应用程序创建一个镜像，并为ARM处理器架构进行编译。否则，容器将无法按预期运行[5]。

相比之下，WASM模块和二进制文件是预编译的C/C++应用程序，不依赖于与主机操作系统或系统架构耦合，因为它们不包含预编译的文件系统或低级操作系统原语。在WASI支持的运行时期间，每个目录和系统资源都连接到WASM模块，然后使用WASM运行时运行。换句话说，WASI用于访问操作系统控制下的所有资源，基本上将代码与其对平台架构的依赖性解耦。

原文始发于微信公众号（老烦的草根安全观）：云原生应用的数据保护方法