从方法论到最佳实践，深度解析企业云原生 DevSecOps 体系构建

本文主要是介绍从方法论到最佳实践，深度解析企业云原生 DevSecOps 体系构建，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

作者：匡大虎

引言

安全一直是企业上云关注的核心问题。随着云原生对云计算基础设施和企业应用架构的重定义，传统的企业安全防护架构已经不能够满足新时期下的安全防护要求。为此企业安全人员需要针对云原生时代的安全挑战重新进行系统性的威胁分析并构建适合企业自身的威胁情报系统，同时在云原生安全体系方法论的指导下，结合云服务商提供的安全产品能力构建端到端的 DevSecOps 流程，维持企业应用全生命周期的持续安全水位。

本文分为四部分，其中第一部分会介绍当下云原生安全的现状以及企业应用在云原生化转型中面临的主要安全挑战；在第二部分中会概要性介绍云原生安全相对成熟的一部分安全体系方法论；在第三部分中会结合之前介绍的理论基础，介绍如何通过部署和实时阿里云 ACK 容器服务和 ACR 容器镜像服务中提供的一些实用的安全产品能力，帮助企业实现或优化 DevSecOps 流程；最后，在第四部分会总结介绍企业在实践 DevSecOps 过程中需要遵循的安全最佳实践。

云原生安全挑战

云原生时代对企业安全的挑战主要来自以下三方面：

云原生平台基础设施架构： 云原生平台层组件相较于传统架构引入了更多的配置项和隔离层，这就给企业安全管理运维人员提出了更高的运维要求。如何保证平台基础设施层的默认安全性，如何在遵循最小化权限原则基础上进行授权操作，如何建立云原生应用系统的安全审计和监控能力，这些新的挑战都需要云服务商和企业安全管理运维人员协同构建并最终实施到企业云原生化转型后的系统应用架构中。
DevOps 软件供应链： 云原生弹性、敏捷和动态可扩展的特征极大地改变了传统应用部署模式，应用自身的生命周期被大幅缩短，而企业应用的迭代效率则大幅提升，在企业供应链架构变革的同时需要构建和实施适配供应链各阶段的安全防护能力。
应用范式上的改变： 随着微服务架构的普适，传统的基于南北向流量的安全边界模式已经变得不使用，企业需要更加细粒度的身份认证和访问控制；同时 Serverless 和函数计算等技术要求云服务商在基础设施层具备更强的安全隔离性和监控能力，而应用的容器形态则需要新的运行时安全监控告警和资产管理模式与之对应。

面对重重的安全挑战，企业的安全现状是如何呢？上图是一些主流云原生安全领域厂商在今年发布的最新报告。其中图片左侧来自 Sysdig 今年的云原生安全使用调查报告，报告显示仍然有 87% 的容器镜像中包含严重或高危等级的漏洞，同时 90% 的企业应用授权并没有被实际使用；从右侧 Paloalto 今年的云原生安全现状报告中企业客户反馈的 Top 5 挑战中也可以看出，面对云原生时代新的安全挑战，企业无论在组织架构、文化和安全运维上都还没有做好充分的准备。

供应链安全也是近两年成云原生安全领域的焦点，我们知道创新和效率是企业发展的关键，在云原生时代的企业开发流程中，开源软件和开发工具可以帮助推动企业提升研发效率。在云原生时代，企业对开源生态越来越依赖，三方软件包的安全成为了无法回避的问题。为此 Gartner 预测：“到 2025 年，全球将有 45% 的组织的软件供应链受到攻击，比 2021 年增加三倍”。在 sonatype 今年的统计中，仅仅在今年已经有超过 24 万 5 千个软件包中被发现包含漏洞，这个数字是从 19 年到 22 年之合的两倍。

由此可见企业的供应链安全也成为攻击者的主要攻击目标，在调查中我们也发现，多数的受访者都清楚的知道来自供应链的安全风险，但只有不到十分之一的企业受访者表示会在生产供应链生命周期的每个阶段进行安全审核和部署防护措施。由此可见企业安全人员的风险意识与有效的供应链风险管理和防护措施的实施之间还是存在了明显的脱节。

在传统的软件开发流程中，安全人员通常是在系统交付之前才开始介入进行安全审核工作，这样的安全流程显然已经无法满足云原生时代下软件供应链的快速迭代流程。

来自 Gartner 的分析师 David Cearley 早在 2012 年就首次提出了 DevSecOps 的概念。相较与传统软件开发的安全流程，DevSecOps 强调从企业安全文化意识，安全流程左移以及构建全链路的自动化流程等几个要点来加固新时期下企业软件供应链安全。Gartner 预测，到 2025 年将有 60% 的企业采用并实践 DevSecOps。DevSecOps 模型强调安全和整体软件开发流程的紧密结合，同时也强调了在不降低企业应用开发迭代速度的前提下，通过执行全面的自动化安全防护措施来确保应用制品和供应链管道的安全性。

在当下，绝大多数的企业云原生安全的发展都落后于应用的云原生化进程，而主要的改进方向也集中在下面这三个方向：

身份和访问管理： 线上授予的权限与实际需要的权限之间存在巨大差异，无疑会给攻击者可乘之机。
漏洞和配置管理： 大多数的企业生产镜像都没有经过安全加固和最小化的裁剪收敛，另外很多线上应用因为开发调式的一时方便而在容器层配置了过高的特权。
监控和响应： 缺少针对容器资产的运行时监控和防护手段，针对突发的攻击事件也无法有效完成定位和溯源。

这些都是企业应用在云原生化进程中亟需优化和解决的主要安全方向。

云原生安全体系方法论

安全在本质上是一个对系统风险发现、定位和管理的流程。在了解云原生安全，而威胁建模可以在应用设计开发的早期阶段，帮助安全人员识别企业应用架构中潜藏的安全风险和设计缺陷。

在上图中，左边是针对云上资源的典型攻击路径分析，我们看到在传统的云服务架构下，针对身份和控制面的不当配置以及网络攻击是攻击者可以利用的主要途径，攻击者可以通过漏洞利用、非授权访问和数据窃取等手段攻击企业服务和数据；而在右边的云原生 K8s 集群的典型攻击路径中，由于云原生技术架构的复杂性，容器应用、运行时、K8s 编排引擎、镜像仓库以及内核层都可能给整个应用系统引入新的风险，同时在网络侧，不同容器微服务应用之间的东西向流量也提供给攻击者更多的可利用目标。而近年来不断爆出云原生社区相关的 CVE 漏洞中，攻击者可以利用的攻击方式也是多种多样，像一般的提权、仿冒、篡改、抵赖、拒绝服务等典型攻击手段都出现在了近两年公开披露的漏洞利用方式中。

为此，需要企业安全人员在传统基础设施架构威胁之外尽可能全面的获取安全威胁信息。同时在企业应用架构发生动态变化的同时，也需要重新评估当前威胁建模下的安全机制和模型矩阵是否也需要随之调整。

ATT＆CK 框架是网络攻击中涉及的已知策略和技术的知识库，其中阿里云也是国内首家针对云原生容器和 Kubernetes 的攻防场景，提出并发布相应 ATT&CK 攻防矩阵的云服务商。在 ATT＆CK 矩阵中详细描述了攻击者在云原生和 Kubernetes 环境发起攻击的过程和手段，可以帮助企业构建容器化应用安全体系，也是企业构建云原生威胁情报体系可以利用和借鉴的基本框架。

整个威胁矩阵由不同的行和列组成，其中行代表了攻击技术，列代表了攻击战术手段。矩阵从左至右可以代表一个通常的容器侧攻击路径。通过了解矩阵中每一个攻击阶段攻击者可以利用的技术手段，可以帮助企业安全运维人员有针对性地进行安全设计和测试演练，当安全事件发生时，也可以帮助有效实施对应的止血和预先的防护措施。

为了进一步理解云原生应用安全风险并构建完整的安全防护方案，企业安全运维人员还需要先进的分析方法，覆盖对应用侧风险、开源组件风险、云基础设施风险和应用运行时风险的完整感知。

为此 Gartner 牵头在已有的云安全态势管理(CSPM)、云基础设施授权管理（CIEM）和云工作负载保护平台（CWPP）等传统主流云平台安全模型的基础上，提出了 CNAPP 云原生应用保护平台框架， 面向云原生应用从开发到运行时刻的全生命周期流程，帮助企业安全团队和 DevSecOps 架构师提供完整视角的应用风险可见性和相应的解决方案。基于 CNAPP 理论框架，信通院在 2022 年云原生产业联盟年会上发布了《云原生应用保护平台（CNAPP）能力要求》，在 CNAPP 理论框架的基础上，进一步细化了规范要求。

从架构图中可以看到 CNAPP 框架集成了之前多个成熟规范的核心特性，可以：

更好地适配云原生应用高速迭代的敏捷特性，通过自动化手段减少错误配置和管理。
减少参与供应链 CI/CD 管道的工具数量。
降低云原生应用安全合规实施复杂性和成本。

对于企业应用，安全需求分析、安全测试、安全开发和反复的加固措施也同时伴随着应用的迭代。我们知道企业安全文化意识以及开发、安全运维团队之间的流程协同是 DevSecOps 能够有效实施的关键，在 CNAPP 框架中，也同样强调研发和运维侧双向反馈飞轮，加强企业安全可视性和对风险的洞察力，从整体上改善企业安全态势。

上图中的研发和运维侧双向反馈飞轮主要分为下面两个方向：

从开发到生产： 基于安全左移原则，将安全集成到开发人员的工具链中，在代码创建阶段就通过自动化构建管道触发安全测试，以降低后续安全风险和运维成本。
从生产到开发： 需要企业安全管理人员全面监控线上应用和平台配置，并结合运行时安全配置上下文，提前识别风险并考虑风险处理等级预案，同时将相应的加固措施落实到新的开发迭代流程中。

只有通过这样不断循环反馈，才能保证在云原生下应用的高速迭代的过程中持续的安全水位。

企业在 DevSecOps 的落地实践中可以充分利用云原生技术，同时结合云服务上的安全产品能力以及部署成熟的安全三方产品也可以帮助企业快速构建 DevSecOps 能力。

企业应用的安全性需要贯穿应用程序的整个生命周期。开发是整个应用生命周期的第一个阶段，其结果是创建用于部署和配置应用的云原生模版、容器镜像、应用二进制等云原生制品，这些制品正是运行时被攻击利用的主要源头，相应这个阶段针对不同制品安全扫描就显得格外重要。

构建分发阶段包括基于 CI/CD 自动化流程的各种系统测试，尤其针对开源软件，需要进行明确的漏洞风险分级卡点机制，同时加入自动化的加签机制以支持制品的可信校验。

部署阶段负责进行一系列 “飞行前 ”检查，以确保将部署到运行环境中的应用程序符合整个企业组织的安全和合规规范。

运行时阶段的安全包括计算、存储和访问控制三个关键领域的安全能力。运行时环境的安全性取决于前几个阶段安全实践的有效性，同时需要企业在配置管理、身份和访问控制以及运行时威胁检测方向上基于安全原则实现高效的自动化监控和管理能力，并且通过全局性的安全资产管理和态势感知能力不断发现风险并反馈到生产开发及供应链各环节。

最后，企业应用安全需要防患于未然，完备的审计和溯源分析能力以及精准的风险阻断能力可以帮助企业安全运维人员从容应对突发的攻击事件，并在规划的指导下做出快速的决策和响应。

最后，安全左移和循环反馈是指导企业基于 DevSecOps 理念实施安全防护的主要原则。 在应用制品的供应链生命周期中应尽早地以自动化方式嵌入安全，通过引入自动化的安全扫描和巡检机制，在早期发现并治理常见的软件 CVE 漏洞，可以帮助团队以低成本的方式扼杀风险，同时整体提升团队安全意识。

企业在落地并实践了安全左移理念后，并不意味着安全工作的结束。在应用的生产运行阶段，安全管理人员可以采集并掌握更全面的安全上下文信息，并通过威胁分析发现更多在供应链环节无法暴露的安全设计和配置上的问题，只有通过不断的反馈和更新，才能够保持企业应用系统的整体安全水位，同时应对无法预知的安全挑战。

阿里云容器服务 ACK &容器镜像服务 ACR 安全产品能力

通过上面的介绍，我们对云原生安全面临的挑战以及当下比较成熟的云原生安全理论体系有了初步的了解，下面我会具体介绍阿里云 ACK 和 ACR 服务中面向企业提供了哪些安全相关的产品能力，可以帮助企业实现或优化 DevSecOps 流程。

首先，围绕 DevSecOps 流程中的核心防护能力和自动化要求，阿里云 ACK 和 ACR 服务也沉淀了 DevSecOps 产品能力，帮助企业实现安全可信的软件供应链。

在镜像构建阶段，客户提交源代码变更后，自动触发 ACR EE 的云原生应用交付链功能，开始容器镜像构建，支持自动安全扫描，如果识别到镜像中存在风险，会自动阻断构建流程并钉钉报警。用户可以一键修复镜像中存在的 CVE 漏洞。在镜像交付阶段，ACR 和 ACK 可以基于客户的秘钥进行镜像的加签与验签，确保整个交付链路无篡改。在容器应用运行时，云安全中心可以对 ACK 集群中运行时风险进行防护、感知，以及阻断处理。

今年，我们推出了集群容器安全概览功能， 可以帮助企业安全管理员更好感知集群配置、应用镜像、容器运行时的安全风险，提升整体安全水位。

DevSecOps 的实践依赖企业内部深层次的协同，而不同的工具和实践流程会阻碍跨部门协作的高效性和生产力。通过标准化的平台能够简化部门间沟通和学习成本，让供应链流程更加透明高效。

ACK、ACR 充分利用云原生技术，在企业供应链流程的关键路径上构建了核心能力，面向企业安全管理员提供了开箱即用的产品能力，安全人员可以通过简单的可视化白屏操作完成制品校验，安全巡检、策略实施等供应链安全防护能力，同时通过不同维度的可视化监控和报表直观的了解并管理应用安全，帮助企业安全管理人员第一时间洞察风险，应对攻击。

默认状态下的安全性是整个系统安全体系的根基，不仅决定了生产系统的稳定性，也直接关联了上层安全方案的运维和实施成本。为此，在企业应用系统的设计阶段，安全性就应当作为基本且必要的需求融入设计环节，并在安全专家的指导下审核架构设计中潜藏的风险。

企业应用使用哪种凭据访问云资源？基于默认安全和权限最小化原则，在应用内直接使用 AK 以及在节点上直接绑定云资源访问权限都是安全上不推荐的做法，此时可以将 RRSA 方案集成到企业应用设计和编码环节，通过 RRSA 方案，可以实现基于 K8s serviceaccount，与阿里云 RAM 服务完成基于 OIDC 协议的访问控制认证，并实现以应用维度最小化隔离授权云资源访问权限。

密钥管理一直是企业应用上云的核心问题，云服务商有哪些安全方案可以帮助保护应用密钥？用户又应该在 K8s 环境中采取哪些安全措施帮助管理和使用密钥？应用密钥应该存储在哪里？这些都是企业客户经常会问到的一些基本问题。为此，首先应避免密钥在应用中的硬编码问题。 在应用系统开发部署的供应链流程中，任何一个环节对敏感密钥的硬编码都有可能导致泄露风险。通过使用云上 KMS 服务，可以在应用开发、测试、构建等生命周期流程中使用统一方式进行密钥的读写，避免硬编码出现；同时云上的 KMS 服务支持自动化的密钥轮转能力，进一步降低了敏感信息泄露传播的安全风险，同时也可帮助企业应用满足合规需求。

通过部署 ack-secret-manager 插件可以将 KMS 凭据管家中管理的企业密钥以 K8s secret 的形式同步导入到业务集群中，企业应用可以直接通过文件挂载的方式使用密钥，在避免密钥硬编码问题的同时保证了业务代码的兼容性，在新版本的 ack-secret-manager 中还支持对接KMS服务升级后的专属 KMS 实例，提供更强的密钥安全性隔离保证。

K8s 社区基于 CSI 存储标准扩展实现了 secrets-store-csi-driver 用于将存储在外部密钥管理服务中的密钥以 volume 存储卷的形式挂载到应用 pods 中。和 ack-secret-manager 方案不同，该机制避免了 K8s secret 实例的创建，带来的好处一是避免 etcd 中出现明文 secret 信息，二来可以在大规模场景下避免 secret 堆积；同时应用仍旧可以保持原先的文件路径方式读取密钥，避免了额外的程序改造代价。

基于该插件机制我们实现了阿里云自己的 secrets-store-csi-driver-provider，并且支持通过 ACK 应用市场在集群中一键化部署该插件，同样可以将阿里云 KMS 凭据管家中保存的密钥凭据以文件形式同步到应用容器中，同时支持后端凭据修改后的同步更新能力，保证业务容器中密钥信息的实时性。

当然这里也会有“最后一把密钥”的问题，由于插件需要调用 KMS 凭据管家服务的权限，如何在集群中保护插件对 KMS 服务请求的凭据呢？这里推荐使用 RRSA 方案，可以将 KMS 凭据的请求权限绑定在插件使用的独立 serviceaccount 上，避免将权限泄露给应用 pod 中。

对于数据安全性有严格要求的场景，比如当下火热的 AI 大模型，金融支付、隐私认证或涉及知识产权的核心数据计算，除了保证这些核心敏感信息在读写和传输过程中的安全性，还需保证机密信息在云上节点内存运算和存储过程中的安全可信。今年我们还和 Intel 以及 CoCo 社区合作，基于 Intel TDX 机型实现了新一代的可信执行加密环境，帮助实现企业数据全生命周期的安全可信。

在应用运行时，云原生工作负载区别于传统基于虚机的应用服务有如下特点：

短暂的生命周期，只有秒级的生命周期；
编排引擎会根据节点实时资源动态调度工作负载，网络IP等应用元数据可能随应用重启不断变化；
出于基础设施不可变性，对运行时环境的修改在工作负载重启后不会保留。

正因为云原生工作负载自身特点，在应用运行时，当前大多数云原生安全产品对容器侧用户态进程的检测分析都存在不足。而 eBPF 天然的技术优势是提升云原生应用安全可观测性和实现精细化安全事件响应的有力武器。

在 ACK 集群中，我们提供了针对 K8s 应用的 exec 活动审计能力，通过 eBPF agent 可以实时获取容器负载中执行的系统调用，并关联映射到在容器实例中执行的具体进程，从而帮助安全运维人员获取攻击者进入到容器实例后发起攻击的命令审计，有效帮助针对安全事件的溯源和止血。

同时我们也和 SLS 日志服务提供的强大日志分析检索能力结合，针对云原生的典型漏洞，提供了可疑的漏洞利用活动的溯源和告警能力，并且通过时间线图表的方式直观的展现给企业安全人员。

员工离职后的权限清理问题也是困扰很多企业权限管理员的难题。 在 ACK 默认提供的 x509 证书认证模式下，企业安全运维人员很可能由于疏漏在删除 RAM 账号或角色前忘记吊销和清理 kubeconfig 权限。

通过 ack-ram-authenticator 组件，ACK 托管集群可以通过 Webhook 方式、基于阿里云 RAM 完成请求认证。相较于 ACK 集群默认提供的 x509 证书认证模式，使用 ack-ram-authenticator Webhook 认证方式有如下优点：

适配企业通过云 SSO 场景，提供灵活可控的数据面 RBAC 授权；
角色 SSO 对接场景下 apiserver 审计日志中包含企业 IDP 中的身份信息，有效支持对扮演同一角色的不同 IDP 用户的行为审计；
企业员工离职删除 RAM 账号或 RAM 角色时，可自动清理其在账号所有 ACK 集群中的认证访问权限。

企业 DevSecOps 安全最佳实践

“木桶的最大容积取决于最短的一块木板”，云原生安全同样遵循这样的木桶原则。由于云原生技术栈的复杂性，企业安全管理和运维人员更需要在安全准则的指导下，全面充分的了解全局安全风险，提升系统“最低点”安全水位。

零信任安全最早由 Forrester 首席分析师 John Kindervag 在 2010 年提出，其核心思想是“Never Trust， Always Verify”。在零信任安全模型中，只要处于网络中，默认情况下任何用户都不可信，任何时刻任何环境下设备和服务的身份权限都需要被持续验证。

权限最小化原则是企业安全运维中最基本也是最重要的准则之一。 传统应用架构下，系统的权限管理员需要基于权限最小化原则对内部人员授权。在云原生架构下，授权管理不止针对企业中的账号系统，同时需要考虑松耦合微服务架构下众多服务身份的授权。

安全左移不仅可以有效降低软件自身漏洞而导致的应用风险，同时也能够有效降低企业开发运维成本。

企业安全管理人员需要在安全系统设计中规划和覆盖应用周期中的每个阶段，在安全左移和循环反馈原则的指导下，结合 CNAPP 等规范框架的理论指导下完成安全产品能力的建设。

这里也列举了企业生产供应链中在开发，构建部署、运行时和反馈阶段环节需要具备的一些核心能力，时间关系就不一一介绍了。

DevSecOps 在企业的落地实践离不开企业文化理念上的转变，在 DevSecOps 体系中，安全应当是企业内部团队共同的目标，而不应只是安全团队自身的职责；企业开发、运维和安全团队应当协同起来，设定统一的目标并共担责任，同时定义团队之间的交流互动方式，能够有效提升业务迭代效率。

下面几个方向是企业管理人员在企业文化 DevSecOps 转型中需要关注的重点方向：

人员： 拥有合适的人才是 DevSecOps 的基础。安全培训和培养安全拥护者一直是让安全变得重要的首选解决方案；同时 DevSecOps 需要在安全和效率之间取得适当的平衡，另外持续学习，掌握最新的漏洞和策略对于保证应用程序的安全至关重要。
流程： 制定正确的流程可以确保每个人都站在同一起跑线上，并为安全一致性和凝聚力奠定基础。
工具： 成功实施 DevSecOps 战略的最后一个要素是工具。Kubernetes 安全领域拥有众多工具，可以解决 Kubernetes 和云原生安全的各个层面的问题。当然，在研究和实施安全工具时，也需要避免使用存在重大缺陷的工具。
绩效： 在重视生产效率和版本迭代的前提下，可以将 DevSecOps 的实施列入团队绩效考核，并且通过一些具体指标和分级问责机制的建立也是让 DevSecOps 快速融入团队的有效途径。