1.4 云原生安全的方法论

基于上一节阐述的云原生安全理论基础，本节将主要介绍国内外在云原生安全领域的典型方法论。

1.4.1 CNCF云原生安全架构

CNCF社区集合了云原生安全领域主要的云服务商代表和领域专家，最早推出了v1版本的《云原生安全白皮书》，奠定了云原生安全的理论基础，也给正在使用云原生技术的云服务商和企业客户提供了重要的理论和实践指导，在业界有着广泛影响力。伴随着云原生技术的飞速发展，2022年CNCF社区推出了v2版本的白皮书，进一步完善和补充了框架内容。

首先，CNCF社区将云原生技术栈分为基础设施、生命周期和云环境三部分，如图1-9所示。这样的云原生技术栈可以适用于不同的云计算服务模式，除了IaaS和PaaS，CaaS（容器即服务，Containers as a Service）和FaaS（函数即服务，Functions as a Service）是云原生环境下典型的应用部署模式，有助于企业充分利用云原生技术红利，简化运维流程，专注应用逻辑，从而有效节约成本。同时，这也对如何在云原生服务模式下保证系统全栈的默认安全提出了新的挑战。

云原生应用生命周期管理的4个典型阶段为开发、分发、部署和运行时，下面基于社区建议简述每个阶段针对性的安全工作。

1.开发

开发阶段的安全管理生命周期如图1-10所示。

开发阶段是应用生命周期起始的第一阶段，基于安全左移原则，需要在应用开发早期阶段就引入必要的安全需求，并且将安全性设计视为整个应用系统设计的重要环节。企业DevOps团队应该利用安全工具在应用构建阶段自动化卡点发现其中影响安全的高危配置和隐藏漏洞，这些问题在生命周期的早期阶段及时发现可以有效降低企业的运维开发成本，提升应用的整体开发上线效率。一方面，企业安全工具应能够以自动化方式无缝集成在开发人员日常工作的IDE和应用构建工具链中，尽可能多地提供上下文相关的安全信息和直观的修复建议；另一方面，企业应用组件开发应基于API驱动，同时采用金丝雀或蓝绿部署模式，以便进一步提升安全测试的自动化水平。

威胁建模是帮助识别应用风险和核心热点代码的有效手段，企业安全运维和测试人员应针对关键业务核心代码构建系统性测试方案，包括对应用程序代码的静态和动态测试、交互性安全测试、渗透测试及部署后对系统的实时冒烟测试。同时，测试人员应当和开发团队协同集成，只有充分了解了开发、构建环境，才能快速执行内部测试流程。另外，应用代码上线前的审核机制也是提升应用安全性的必要措施。

2.分发

分发阶段的安全管理生命周期如图1-11所示。

在云原生应用环境中，应用制品通常是以镜像格式进行规范化打包分发的。在镜像构建的CI流程中，首先应该通过权限控制等手段保证构建服务器的安全隔离性，在此基础上可以集成签名和基于策略的验签环节，同时及时更新安全补丁，保证构建环境的安全、稳定。

镜像的安全扫描是整个软件生命周期中保护容器应用程序的重要环节。通过在供应链流程中集成自动化的镜像扫描，可以帮助开发运维人员了解镜像制品中的漏洞信息，也可以及时发现在开发过程引入的一些第三方依赖包中隐藏的安全漏洞或恶意程序。除了镜像的漏洞扫描，还需要在部署之前通过自动化手段对应用模板的安全配置和资源限制等进行扫描，减少不必要的应用特权配置，避免可能危及系统的安全上下文和系统调用设置。

对于存放制品的仓库，首先需要配置严格的认证、鉴权模型，以保证访问控制的安全性。然后针对供应链流水线的不同阶段创建对应的独立仓库，保证各阶段使用独立类型的测试流程，另外建议团队间使用独立的私有仓库，以保证团队内镜像的来源可信。在镜像的打包构建流程中，需要基于最佳安全实践实施安全加固。对于通用的云原生OCI镜像制品，可以基于SBOM等通用规范进行制品签名，以便于后续制品传播流程中的完整性校验。

3.部署

部署阶段的安全管理生命周期如图1-12所示。

在应用正式部署前，应基于策略模型完成一系列部署前的安全检查，包括镜像签名和完整性校验、部署镜像运行时安全策略（确保满足启动要求的镜像没有高危漏洞或恶意软件等）、部署容器运行时安全策略、主机漏洞和合规性校验及工作负载的网络安全策略校验等，通过一系列的策略治理可以确保应用在运行时的安全合规。

部署基于指标的可观测性实践是云原生应用不可缺少的，可以帮助企业安全运维人员及时洞悉系统安全水平，及时通知相关业务负责人处理安全突发事件，及时采取必要的止血措施，同时能够实现对安全事件的审计和溯源。

4.运行时

运行时阶段的安全管理生命周期如图1-13所示。

应用的运行时阶段包含计算、存储和访问控制三个关键领域。在上述供应链开发、版本分发和部署阶段的安全措施是保证应用在运行时安全的先决条件，在此基础上，需要分别在计算、存储和访问控制领域实施必要的安全防护手段。

（1）计算

计算是云原生的核心，也是一个高度复杂和动态演化的存在。考虑到多数情况下容器应用共享运行在同一个主机内核上，我们应该选择针对容器优化剪裁的主机OS基础镜像，这有助于在内核层面减小攻击面。另外，针对OS基础镜像的CVE漏洞时有发生，关系到上层容器应用的安全和稳定，针对OS漏洞的安全扫描和及时修复也是安全运维的必要操作。

随着云原生应用的发展和普及，在金融机构、政府等对数据隐私安全有强诉求的应用背景下，除了使用发展较早的可信平台模块（TPM）或vTPM作为应用底层硬件信任的基础外，也可结合云原生应用将信任链扩展到操作系统内核及其相关组件，以实现应用从底层启动到系统OS镜像、容器运行时到上层应用镜像的完整加密验证链。与此同时，随着机密计算技术的发展，企业可选择部署基于可信执行环境（Trusted Exection Environment，TEE）的机密计算集群，它可以在应用逻辑加载使用数据的计算流程中实现对敏感数据安全性、完整性和机密性的保护。机密计算对隐私数据的运算都被隔离在封闭的TEE中，整个应用系统中除了运行程序的CPU组件外，像系统内核、操作系统、云服务商均无法接触到数据内容。在此基础上，企业还可以结合使用安全沙箱完成应用数据在节点OS内核层面的隔离，以有效防范容器逃逸风险，构建一个从应用数据加载、运算、使用到运行时的全流程隔离环境。

编排层是云原生应用生命周期管理的核心系统，其安全直接影响应用系统的整体安全性和运行时的持续安全性。Kubernetes作为云原生应用编排引擎的事实标准，近年来针对其公开披露的CVE漏洞层出不穷，攻击者可以利用集群控制面和数据面核心组件的漏洞，通过如目录遍历（Directory Traversal）、条件竞争（TOCTTOU）或伪造请求等特定手段完成提权并成功逃逸容器，进而发起对主机侧甚至整个集群和云账号维度的横向攻击。因此，对于集群编排层控制面和数据面核心组件，集群安全运维人员应当遵循如CIS Kubernetes等安全标准基线完成组件配置的安全加固，同时严格遵守权限最小化等安全准则授权，防止管理权限扩散。同时，企业可以结合云服务商提供的安全特性实施如下编排层安全措施：

❑安全策略治理。通过实施安全策略可以在应用部署时有效审计不符合安全约束的带有特权配置的不规范部署实例，在安全等级较高的应用场景下，可开启对不安全应用部署的强制拦截。

❑审计日志。完备的审计日志是识别和追溯系统入侵、权限滥用、配置不当的最直接和最成熟的方法之一。基于审计日志的分析、关联检索和告警是企业安全团队针对攻击事件最直接的处理手段。安全人员应结合云原生应用特性，针对API审计事件的身份标识、API请求对象模型和操作等关键特性检索关键事件，并通过可视化大盘等方式过滤信息。为了防止攻击者逃逸到主机侧通过删除日志等方式掩盖攻击路径，企业应用应当结合云服务商的日志服务第一时间采集同步日志信息，并对日志的访问权限实施严格的访问控制。

❑证书管理。对于没有将控制面托管运行在云服务商的企业集群，集群CA证书、控制面核心组件证书及相关密钥凭证的生命周期管理也是企业安全运维团队需要关心的核心资产。其中，CA私钥是需要严格保护的敏感信息，对于有泄露风险的CA或组件证书要及时轮转，同时对证书过期时间进行日常监控告警也是保证系统稳定性的必要措施。

❑Secrets加密。如Kubernetes这样的编排引擎针对应用中的敏感信息（如数据库密码、应用证书、认证token等）提供了Secrets模型，便于在应用负载中加载和使用，而敏感信息通常是以明文形式编码使用并落盘存储的，仅通过基本的访问控制策略实现逻辑上的读写隔离。因此，像Secrets这样的独立模型仅可以作为应用处理敏感信息的载体和桥梁，并不能保证企业应用关键信息的安全性，那么应用开发者如何在不破坏密钥可加载和使用的前提下保护其读写和传输的安全性？应避免将密钥以硬编码形式出现在软件生命周期流程中，推荐使用外部的密钥管理系统进行密钥的生命周期管理，同时结合云原生密钥工具在应用运行时完成指定密钥的自动化注入和轮转，以有效地避免硬编码的出现。另外，基于云上的安全零信任原则，Secrets的落盘加密也是推荐使用的安全特性，而Kubernetes也提供了相关的加解密框架，以信封加密的方式高效实现Secrets密文的自动化加解密，保护应用密文在云服务商托管侧的读写安全性。

❑运行时安全和监测。在应用运行时对容器内进程、文件系统和网络的监控与安全防护是不可缺少的，另外一些关键的系统调用和不必要放开的网络访问是攻击者利用CVE进行攻击的重要跳板，在传统方式下对系统调用及容器内东西向网络流量的监控和拦截需要相当的内核领域知识储备并结合复杂的策略配置，而eBPF技术的出现帮助开发者有效屏蔽了内核复杂性，使开发者能够以可编程的方式控制内核行为，这就给安全运维人员提供了在应用运行时灵活监控与拦截关键系统调用和恶意流量的切入点，这也是本书后续将重点关注的内容。另外，在一些对安全合规等级有严格要求及需要保护应用敏感数据的场景，使用安全沙箱容器实现应用内核维度的隔离及使用机密计算对应用的核心数据进行运行时加密，都是提升运行时安全的有效手段。

❑制品安全。云原生制品安全在之前的供应链环节已多次强调其重要性，应通过策略控制生产环境，且只部署经过安全认证和签名校验的镜像与模板等制品源文件，同时要能让企业安全运维人员查看制品出处，做到审计溯源。

❑微服务和服务网格。微服务是云原生时代典型的应用部署架构，随着微服务暴露的端口和API数量激增，整个应用系统的安全稳定性变得无法控制。零信任安全针对微服务架构的特点，通过引入以身份为中心的服务东西向认证、鉴权访问控制去重构传统应用架构下的信任基础。服务网格的不断演进也为微服务之间的交互提供了流量控制、弹性和负载均衡及可观测和安全等特性，同时给零信任在微服务架构下的实施提供了直接方案，有助于缩小应用系统攻击面。

❑Serverless和函数安全。由于Serverless架构和函数服务自身架构的特点，平台底层架构需要在多租户场景下保证租户之间的安全隔离，同时避免因CVE漏洞导致的越权风险。对于上层输入函数，需要确保其供应链安全，对输入函数进行有效的过滤和校验，防止SQL注入等风险；同时通过网络策略等形式限制函数出网请求，防止其对恶意C&C服务器的访问。

（2）存储

云原生的弹性敏捷、可扩展和可迁移在对存储密度、速度等方面有新要求的同时，也对云存储的安全、稳定、可观测性提出了更多的诉求。云原生存储涵盖了一系列技术栈，由于不是本书重点，这里只简单列举一些与安全相关的内容。

1）存储栈。存储解决方案通常是多层架构的复杂系统，架构中的不同模块定义了数据应如何被存储、检索、保护，以及如何与应用侧、编排系统、操作系统交互。任意模块的安全稳定都决定着整个存储系统的安全性。企业运维人员需要保护系统拓扑结构中的每一环节，而不是仅仅在数据访问层实施保护。

❑编排。云原生存储是面向应用的声明式应用层存储，通过编排系统为开发者提供了文件系统（如挂载绑定）、存储管理器及基于编排策略的用户或组级别的权限管理能力。运维管理人员可以利用策略治理能力限制容器运行时使用root权限，同时配置权限最小化的用户和组。基于零信任、最小化权限原则及严格实施的访问控制策略是保护云原生存储架构安全的关键。

❑系统拓扑和数据保护。理解整个应用系统的存储拓扑架构是安全防护的前提。常见的拓扑包括所有计算节点访问中央式的存储服务、在多节点上部署分布式存储，以及将应用负载和存储负载整合在同一节点的超融合模式等。针对不同的系统拓扑架构，需要有对应的分层安全机制保护存储数据及分布式存储之间传输的数据。存储系统中的一个关键能力是在保护系统中持久化数据的前提下面向被授权的用户提供权限范围内的数据，其中包括奇偶校验、镜像、纠删码和创建副本等通用技术。接下来是针对数据完整性的校验，包括对块存储、对象存储或文件存储增加哈希及校验和，在保护数据的同时防止数据被恶意篡改。

❑缓存与数据服务。缓存在应用系统中处处可见，在有效提升存储系统性能的同时，需要严格控制缓存层的访问控制安全策略，防止攻击者通过缓存层获取后端数据。

❑数据服务。存储系统通常会实现一些数据服务，通过提供额外的功能来补充核心存储功能，这些功能可以在堆栈的不同层实现，可能包括创建副本和快照（数据的时间点副本）。这些服务通常用于对数据副本进行远程移动，同时必须确保对远程数据使用相同的访问控制和安全策略。

❑物理层或非易失性层。云原生存储并不局限于狭义的云原生虚拟架构，而是重用了云存储在底层基础设施中的红利，也包括虚拟和物理存储能力。应用中的存储系统最终会将数据持久化在某种非易失性的物理介质上。固态硬盘等现代物理存储通常支持自身加密等安全能力，同时在数据设备离开安全域时一定不要忘记安全擦除业务数据。

2）存储加密。存储加密是保证数据安全的核心手段，通常我们说的数据加密包括数据的传输加密和落盘加密。在传输阶段，通常需要使用客户端和服务端双向TLS加密保证传输加密；在数据落盘时，需要结合密钥管理系统（云上或安全等级更高的本地专有HSM），基于标准的对称加密等算法进行数据的保护。考虑到加密对系统性能的影响，需要结合数据的具体逻辑和合规要求等因素设计数据加密的隔离维度，以及是否使用缓存、信封加密等手段提升性能。

3）存储卷保护。对存储卷的保护最重要的是保证只有授权范围内的工作负载容器才可以对其访问，基本且必要的安全措施是定义命名空间维度的信任边界，在此基础上通过安全策略治理等手段防止容器对节点上敏感路径的挂载，以及限制只有合适的节点能够访问目标卷。同时，需要严格限制特权容器的部署，因为特权容器在被攻击者利用后可以使用更多的系统能力进行逃逸，从而挂载节点上的关键数据信息。

（3）访问控制

1）身份和访问控制。以身份为核心的访问控制系统是云原生应用在零信任原则下的安全基石。针对云原生弹性、微服务架构等特性，鉴权方案需要在设计上遵循最小粒度的访问控制原则。由于多云、混合云架构已经在企业中日渐普及，基于特定云服务商的访问控制解决方案已经不能满足多云环境下的分布式应用的认证、鉴权需求，基于通用标准的OIDC（Open ID Connect）或SAML（Security Assertion Markup Language）2.0协议的联合身份体系将是未来被广泛应用的标准方案。

在微服务架构下，应用系统服务间的所有东西向请求都需要配置双向的TLS认证，同时利用通用的鉴权模块配置服务维度的授权，在特殊场景下可以通过配置七层策略达到更细粒度的访问控制。在云原生应用生命周期被大幅缩短的前提下，需要通过统一的身份凭证系统下发和管理服务依赖的临时密钥，同时配置相应的吊销机制。在零信任的前提下，系统内部所有的人机交互和机机交互都必须经过认证、鉴权、审计。

2）密钥和凭证管理。完备的密钥管理方案对于企业应用的安全、稳定至关重要。在企业应用系统开发部署的供应链流程中，任何一个环节对敏感信息的硬编码都有可能导致泄露风险，通过使用云上KMS服务，可以在应用开发、测试、构建等生命周期流程中使用统一的方式进行密钥读写，避免硬编码问题的出现。同时，KMS服务支持自动化的密钥轮转能力，进一步降低了敏感信息泄露和传播的风险，对数据安全等级有较高要求的企业应尽可能使用硬件安全模块（HSM）对密钥进行物理隔离，从而实现更安全的保护。

如何在工作负载中安全地使用密钥也是企业开发运维中需要特别注意的问题。从指定的文件系统路径或环境变量中读取是工作负载中消费密钥的基本方式，那么如何将HSM或KMS服务中的密钥信息自动化注入应用容器内的指定路径下呢？像Kubernetes这样的编排引擎针对敏感信息实现了非持久化的自动化注入机制，用于将存储在外部密钥管理系统中的敏感信息以存储卷的形式动态挂载到应用容器内，同时支持密钥的自动化轮转机制，避免了敏感信息以Secrets等模型实例的形式持久化保存在系统中，防止攻击者通过审计日志或恶意提权导致的信息泄露。

除此之外，实施落盘加密和使用基于底层硬件加密技术的机密计算容器也是提升密钥与凭证安全性的有效措施。特别是在如金融支付、隐私认证或涉及知识产权的核心数据链路，除了保证核心敏感信息在读写和传输过程中的安全性外，还需要保证机密信息在节点内存运算和存储过程中的安全可信，在此场景下推荐使用机密计算技术，以保证敏感信息在代码使用过程中的完整性，实现数据全生命周期的安全可信。

3）服务可用性。保持业务应用服务的稳定、可用是企业安全运维的基本目标。在云原生应用面临的网络攻击中，拒绝服务攻击（DoS）和分布式拒绝服务攻击（DDoS）是最为常见的攻击形式。攻击者试图通过大量恶意冗余流量来淹没企业应用服务或上游网络的正常业务请求流量，使系统网络过载，从而达到服务不可用的攻击目标。

通过有效的访问控制手段来限制或减少应用服务的攻击面是针对此类攻击的基本防御措施，比如从应用设计上收敛涉及对外流量的组件，同时将计算资源配置在负载均衡之后，并通过配置统一的访问控制规则和Web应用防火墙来控制能到达应用的流量。除此之外，基于eBPF技术也能够从系统底层识别攻击流量，并在恶意流量进入内核网络堆栈处理之前完成丢弃处理，从而实现对拒绝服务攻击的高效防御。

1.4.2 云原生应用保护平台

Gartner在2021年8月首次发布了《云原生应用保护平台创新洞察》报告，该报告面向云原生应用，旨在通过一系列安全合规集成方案完整地阐述云原生应用从开发到运行时全生命周期的安全模型框架。

1.模型框架和双向反馈能力

在云原生架构下，企业应用通常是基于容器编排引擎或Serverless化的无服务器PaaS层构建的，同时在应用侧又依赖主机侧、云服务商和企业内部数据中心等多方向的网络请求。为了理解云原生应用安全风险并进一步构建完整的安全防护方案，企业安全运维人员需要先进的分析方法，覆盖对应用侧风险、开源组件风险、云基础设施风险和应用运行时风险的完整感知。在企业应用云原生化的同时，企业内部安全架构的重点也相应地从对基础设施的安全加固转向对上层应用负载侧的防护。在这个转型过程中，企业安全生产和运维面临着如下风险：

❑企业开发和安全团队缺乏必要的技能。Gartner的一次调查显示，在企业开发运维流程管道中实践DevSecOps时，评分最高的挑战就是内部缺乏必要的安全知识。

❑企业内部组织架构不成熟，尤其是在应用初期阶段，功能迭代的压力会导致安全手段实施的滞后。

❑企业现有的传统安全防护方案（如CWPP、WAF等第三方安全平台工具）难以整合到云原生当下的DevOps流程中。

❑开发和安全团队各自为政。开发团队不希望接入侵入式的安全卡点流程或者拒绝使用一些误报率高的低效安全工具；而安全团队缺乏对应用全局的了解，使得很难完成对应用整体安全架构的全局治理。

❑企业负责安全防护投入与采购的人员和实际负责应用生命周期管理的团队往往来自不同部门，很容易因为不明确的边界导致企业在安全上的投入无法对症下药。

❑多数云安全态势管理（CSPM）平台缺乏企业所需的基础设施即代码（IaC）的扫描能力，无法实现与企业内部开发管道的集成。

❑安全预算分散在企业内部不同的角色人员之间，对于开发运维管道流程中的安全能力而言，多数时候被集成在IDE工具或代码仓库中，也是多数开发人员能够直接接触到的安全特性，这部分安全能力由于自身重合性导致开发运维人员只会选择使用其熟悉平台内置的安全工具，而企业也缺乏对供应链安全的整体投入。

❑缺少对Kubernetes自身安全配置的扫描和加固。

以上风险很大程度上来自企业内部安全防护手段和观念发展的滞后，以及开发运维团队和安全部门之间的边界问题。为此，Gartner与其他主流云服务商和云安全厂商在已有的CSPM、云基础设施授权管理（CIEM）和CWPP等传统主流云平台安全模型的基础上，提出了云原生应用保护平台（Cloud Native Application Protection Platform，CNAPP）框架，针对云原生应用从开发到运行时的全生命周期流程，为企业安全团队和DevSecOps架构师提供完整视角的应用风险可见性和相应的解决方案，包括应用依赖的开源软件、自定义代码、容器制品、云基础设施配置和运行时防护等维度，如图1-14所示。

除此之外，相较于传统模型，CNAPP更加强调通过如下原则进一步提升企业应用安全水平：

❑更好地适配云原生应用高速迭代的敏捷特性，通过自动化手段减少错误配置和管理。

❑减少参与供应链CI/CD管道的工具数量。

❑降低云原生应用安全合规实施的复杂性和成本。

❑强调企业内部开发、运维和安全部门的协同一致：对于开发人员，需要允许安全扫描等工具无缝集成到其开发管道和平台中；对于安全人员，尽可能左移安全措施，在强调供应链主动发现并修复安全风险的同时，减少对运行时保护的依赖。

❑帮助企业安全部门深入了解云原生下的典型攻击路径，包括身份、权限、网络和基础设施配置等多维度的溯源与分析。

研发和运维侧的双向反馈飞轮是CNAPP模型中的核心机制，可以帮助加强企业安全可视性和对风险的洞察力，从整体上改善企业安全态势，如图1-15所示。

从研发侧反馈到生产运维阶段，可通过如下安全措施实现预期状态：

❑通过静态安全扫描和软件成分分析等手段保证制品的安全合规。

❑通过基线分析等手段识别制品的默认行为和预期连接。

❑基于漏洞和恶意代码扫描明确剩余漏洞，采取运行时安全防护措施。

❑基于最小化权限原则授权。

❑通过策略治理等手段保证制品的安全完整性。

在生产运维阶段，可通过如下平台侧安全措施不断反馈研发侧可以加固和修复的安全问题：

❑通过动态安全扫描和交互式监视等安全工具识别应用代码漏洞。

❑基于云原生安全态势感知方案识别安全资产，收敛权限并设置安全策略。

❑基于云原生应用负载安全防护手段发现并阻断运行时安全攻击事件。

❑基于云原生运行时安全监控手段为开发阶段提供应用运行时安全上下文。

❑基于云原生安全巡检工具识别应用高危配置和潜在攻击风险。

2.对企业安全的指导意义

对于企业安全运维管理团队，CNAPP框架强调了以下几点：

❑在企业云原生应用中需要实施完整的安全手段，涵盖从应用开发到生产运行的完整供应链流程。

❑基于安全左移原则，将安全集成到开发人员的工具链中，在代码创建阶段就通过自动化构建管道触发安全测试，以降低后续安全风险和运维成本。

❑不存在无懈可击的完美应用，开发人员应关注风险和威胁等级最高的漏洞，以避免不必要的开发运维成本。

❑全面扫描应用制品和平台配置，并结合运行时安全配置上下文，提前考虑风险处理等级预案。

基于CNAPP理论框架，信通院在2022年云原生产业联盟年会上发布了《云原生应用保护平台（CNAPP）能力要求》，进一步细化了规范要求，同时在云原生制品安全、基础设施安全、运行时安全、双向反馈能力和环境适配能力五大方向上提出了具体的评测标准和分级能力要求，为企业云原生安全建设和评估提供了重要的规范和参考标准。