1.3 云原生安全的理论基础

正如云原生概念在狭义和广义上有不同的定义一样，云原生安全亦是如此。从狭义上，可以将云原生安全理解为基于云原生架构和技术背景建立的安全防护手段，比传统安全模式更加灵活地适配解决云原生架构下的安全挑战；从广义上，云原生安全是因云而生的，是深度融合了云基础设施并能够充分发挥云原生效能优势的安全系统。本节将基于云原生应用系统特性，融合传统安全体系方法论介绍云原生安全的理论基础。

1.3.1 威胁建模

安全在本质上是一个发现、定位和管理系统风险的过程。对于企业应用而言，安全需求分析、安全测试、安全开发和反复的加固措施也同时伴随着应用迭代，而威胁建模可以在应用设计开发的早期阶段帮助识别应用架构中潜藏的可能引发安全风险的设计缺陷，同时给出相应的安全建议，进一步提升设计开发人员的安全意识和能力，帮助构建企业DevSecOps流程，协同安全、运维、业务开发团队有效降低企业的安全成本。

已经应用云原生技术的企业应该如何定义、管理和规避安全威胁？核心是构建一个端到端的系统架构，架构中需要包含重要的组件交互流程、数据存储方式和安全边界。架构中的组件不仅是一些核心的功能组件，还需要考虑应用生命周期的开发、构建、测试和发布等涉及的所有流程中的关键组件，这样的端到端系统化架构可以由熟悉系统全局的业务架构师和安全团队共同完成。一旦边界和系统中组件的数据交互流程被构建出来，下一步就可以基于不同的威胁模型和情报进行系统建模，尤其需要注意的是跨安全边界的交互。

1.威胁识别

威胁建模理论的发展已经经历了很长的时间，我们可以基于如STRIDE或OCTAVE等成熟框架来构建威胁模型。云原生应用常见的威胁如下。

❑仿冒：攻击者利用泄露的有管理员权限的集群访问凭证发起恶意攻击。

❑篡改：通过篡改集群管控组件参数或通过修改集群apiserver证书等关键配置使集群管控组件无法启动。

❑抵赖：因为没有启动或错误的审计日志，导致无法为潜在的攻击提供证据。

❑信息泄露：攻击者入侵了集群中正在运行的工作负载并窃取了用户信息。

❑拒绝服务：集群中部署了没有定义资源限制的工作负载，攻击者可通过恶意行为消耗整个节点的计算资源，最终导致节点失连。

❑权限提升：攻击者可以利用集群中部署的特权工作负载或通过篡改安全上下文来提权发起进一步的逃逸攻击。

而云原生安全中需要考虑的威胁行为实体如下。

❑内鬼：具有恶意企图并且在建模系统内有权限执行恶意操作的企业内部人员。

❑内部不知情者：在建模系统内有权执行操作的内部人员（假设任何人都可被欺骗）。

❑外部攻击者：在系统外部的恶意攻击者，可以在没有明确授权的前提下利用网络、供应链、物理边界等漏洞对建模系统发起攻击。

当然还有其他可能的行为实体（比如不知情的外部人员），这里没有列举是因为他们的行为影响范围是上述列举实体的子集。

由于云原生技术架构的复杂性，容器技术、编排引擎等核心组件都可能给整个威胁系统引入新的风险，需要企业安全人员在传统基础设施架构威胁之外从社区等途径尽可能全面地获取安全威胁信息。同时由于云原生加速了应用迭代效率，意味着在架构动态变化的同时，需要重新评估当前威胁建模下的安全机制和模型矩阵，看它们是否也需要随之调整。

2.威胁情报

威胁情报是关于已知威胁的广泛信息，用来帮助企业安全管理人员更快速、更明智地进行决策，并且鼓励在对抗攻击时采取主动而非被动行为。

如前文所述，云原生架构下的应用制品会依赖众多第三方软件包，同时容器运行时和编排层框架也包含了复杂的组件。这就意味着威胁情报必须涵盖云原生编排引擎、运行时、核心组件和安全社区等更加广泛的威胁来源，从而能够更加准确地描述云原生攻击类型、攻击路径，并识别攻击影响和范围。

ATT&CK框架是网络攻击中涉及的已知策略和技术的知识库，其中针对容器和Kubernetes的ATT&CK攻防矩阵面向云原生和容器场景，详细描述了攻击者在云原生和Kubernetes环境中发起攻击的过程与手段，可以帮助企业构建容器化应用安全体系，提高云原生容器安全水平，也是企业构建云原生威胁情报体系可以利用和借鉴的基本框架，如图1-6所示。

整个威胁矩阵由不同的行和列组成，其中行代表攻击技术，列代表攻击战术手段，从左至右代表一个通常的容器侧攻击路径。对矩阵中各攻击技术的概要说明如下：

❑初始访问。这是攻击者利用集群环境发起攻击的第一步，企业内部云账号认证凭证、集群kubeconfig访问凭证及主机登录凭证等关键密钥的泄露有可能让攻击者直接获得初始访问权限，集群暴露了未授权访问端口和系统内应用漏洞，也有可能成为攻击者可以利用的突破口。

❑执行。在成功获得集群访问权限后，攻击者需要继续执行恶意代码发起进一步的攻击，这样的后门程序可以通过创建源自恶意镜像的容器负载或通过客户端工具远程登录到容器内部完成执行。

❑持久化。攻击者还需要通过部署恶意控制器、执行后门程序的定时任务或直接通过特权逃逸到主机侧修改控制平面组件和授权配置等方式进一步获取集群控制权，进而固化攻击方式。为此，集群中需要通过策略治理等手段约束可以在集群中部署的可信仓库列表，以及严格限制集群中部署工作负载的特权配置，同时对容器中的异常行为进行实时监控告警。

❑权限提升。在集群容器环境中，攻击者有多种手段试图逃逸并最终获得主机甚至集群的最高权限。作为集群的安全管理人员和集群应用的开发者，需要严格遵循最小化权限原则来设置应用负载的安全配置，不给攻击者可乘之机。

❑防御逃逸。当攻击者入侵成功并获得了集群控制权后，会主动逃逸系统的安全防御监测。比如清理集群审计日志、使用系统组件名称伪装和混淆等增加安全运维的难度。而企业安全人员可以通过对主机上执行的Shell命令或exec进入容器后执行的调用行为进行安全审计，来发现类似的攻击行为。

❑窃取凭证。凭证是攻击者可以利用的直接武器，当攻击者成功入侵后，一定会通过各种手段尝试获取集群Secrets、高权限Service Account、云账号AK等，作为发起进一步攻击的凭证跳板。而集群应用环境中的密钥安全管理和签发短时凭证是防止攻击者窃取凭证的有效手段。

❑探测。除了窃取凭证，攻击者还会试图通过访问集群apiserver、kubelet或通过内网扫描等方式了解集群中的可用资源和授权信息。此时，对集群apiserver或相关网络服务的调用审计可以帮助企业及时发现可疑的探测攻击。

❑横向移动。指攻击者在侵入容器后进一步逃逸攻击主机侧、集群甚至整个云账号的攻击方式。限制集群应用容器的系统特权、收敛容器中的token权限、最小化集群授权等安全加固措施均可增加攻击者横向移动的难度。

❑影响。到了这个阶段，以破坏为目的的攻击者可能通过劫持资源、DoS攻击、加密勒索等手段直接影响了系统可用性。企业应用需要部署完备的运行时安全检测来响应攻击，同时默认对工作负载配置应用软硬资源限制，以降低事件影响。

1.3.2 坚守安全准则

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

1.默认安全

默认状态下的安全性是整个系统安全体系的根基，不仅决定了生产系统的稳定性，也直接关联了上层安全方案的运维和实施成本。实现系统的默认安全需要遵循如下原则：

❑将安全性融入设计要求。在系统设计阶段，安全性就应当作为基本且必要的需求融入进去，并在安全专家的指导下审核架构设计中隐藏的风险。结合前文提及的威胁建模理论，将红/蓝/紫军的攻防演习自动化集成到软件供应链管道中，在业务和安全团队的协同配合下不断优化安全设计。

❑基于最佳安全实践设置系统配置。安全运维人员应当在最佳实践的指导下初始化应用系统的默认配置，而对于云服务商来说，这样的初始化配置方式应当以一种简单、透明的方式提供给终端用户，在屏蔽后端复杂实现的同时也需要考虑额外的配置成本。如果这些安全功能和配置项对终端运维人员设置了过高的门槛，或缺乏必要的文档说明和自动化API，那么就需要重新优化实现。

❑谨慎使用不安全配置。对于系统中可能增加安全风险的配置，需要告知用户并明确提示风险，让用户在知晓风险的前提下有意识地开启不安全配置。

❑针对线上应用提供安全加固选项。已经发布上线的应用系统中可能存在已知的安全设计缺陷，此时加固应用配置很可能导致兼容性问题，影响线上业务的稳定性，需要加固方案具备兼容性和可逆性，保证应用系统能够平滑过渡到安全终态。

❑可继承的默认安全。在多层系统架构下，底层架构的安全配置通常可被上层架构继承，在云原生安全架构下也是如此。在夯实基础设施层安全配置的同时可抽象出与上层对应的安全能力，进一步加固容器应用侧安全，实现系统的纵深防御。

❑默认安全配置应当能阻止通用的漏洞利用。默认安全配置应当能帮助系统抵御常见的安全攻击和漏洞利用。通过在软件供应链管道中集成自动化的配置校验和安全审核，比如强制应用程序以非root身份启动或启用seccomp配置约束应用运行时对系统调用的使用，可以在应用发布前帮助发现并修复程序中隐藏的远程代码执行（RCE）、文件目录遍历、凭证泄露和提权等通用的漏洞利用路径。

❑针对特例提供可配置的安全白名单选项。通常来说，默认安全配置中过于严格的安全约束可能导致和应用层业务需求的冲突。此时应针对特例提供直观的白名单配置，仅开放业务依赖的最小特权，同时结合策略引擎进行自动化控制和审计。

❑明确系统中的安全限制。任何系统都不可能做到百分之百的安全，但是这些安全限制需要在系统中被明确声明并记录在设计流程中，比如为了Kubernetes系统组件的正常运行，需要在集群节点上默认绑定一些云服务商资源的访问权限，在明确告知终端用户配置原因和可能引发安全风险的应用场景之外，还需要不断寻求替代和安全收敛方案。

2.权限最小化

众所周知，权限最小化原则是企业安全运维中最基本也是最重要的准则之一。在传统应用架构下，系统的权限管理员需要基于权限最小化原则对内部人员授权。在云原生架构下，授权管理不止针对企业中的账号系统，同时需要考虑松耦合微服务架构下众多服务身份的授权。这就要求系统权限管理员在理解业务应用目的和使用场景的前提下，严格遵循权限最小化原则在服务维度授权。

3.安全左移、防护右移

云原生敏捷、不可变基础设施等特性大大提高了企业应用开发迭代的效率，也很大程度上改变了企业软件从设计、开发、编译打包、测试、分发到部署的发布流程，而这样的流水线可以称为软件供应链。在传统软件开发流程中，安全审核只有在应用开发完成即将上线发布前才会被强制介入，而这样的审核要么需要安全管理人员对应用全局有完整的掌控，要么只是流于表面的例行检查，无法有效提升软件的安全性，同时也不再适应云原生时代敏捷、高效的应用迭代速率。

为了解决安全防护与软件开发流程日益严重的脱节问题，安全左移的理念应运而生。相较于传统软件开发模式下安全流程的介入方式，安全左移更强调在供应链流程的早期阶段通过自动化的手段发现并解决安全问题，并且这样的安全措施应当能够无缝嵌入供应链的各个环节。安全左移不仅能够有效降低软件自身漏洞而导致的应用风险，而且能够有效降低企业的开发运维成本。在Paloalto《2022年云原生安全报告》中可以看到，将安全左移实践到自身供应链环节的企业在安全态势评级中得到优秀等级的概率是其他企业的9倍。

随着安全左移理念的发展，企业研发运维DevOps流程也随之扩展为DevSecOps。DevSecOps作为云原生时代下的安全开发实践模式，并不仅仅局限于云原生安全，在整个企业应用运维领域都是一个热门的概念，也是安全左移理念的最佳实践。那么，企业应当如何构建自己的DevSecOps流程呢？首先至少应当具备如下组件：

❑完整的自动化CI/CD流水线，以及满足企业应用构建、测试、打包分发和部署上线的基础设施层资源。

❑SDLC（软件开发生命周期）软件，包括IDE等构建工具以及静态/动态应用安全测试和软件成分分析等自动化测试工具。

❑仓库，包括应用源代码仓库和应用镜像仓库。

❑可观测监控工具，集成日志审计、自动化监控告警和自定义监控指标配置等能力的可视化运维管理平台。

而完成DevSecOps转型的企业需要具备如下条件：

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

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

❑实现供应链安全自动化。在应用制品的供应链生命周期中应尽早地以自动化方式嵌入安全，同时以自动化方式扫描、发现并治理常见的软件CVE漏洞。通过引入自动化的安全扫描和巡检机制，团队可以在早期扼杀风险，同时整体提升安全意识。

❑充分利用云原生带来的技术红利。企业在DevSecOps的落地实践中可以充分利用云原生技术，包括不可变基础设施和声明式的策略治理能力。同时，部署成熟的安全第三方产品也可以帮助企业快速构建DevSecOps能力。

❑构建供应链SBOM（Software Bill Of Materials，软件物料清单）。SBOM是描述供应链制品中软件包依赖树的一组元数据，包括供应商、版本号和组件名称等关键信息。SBOM可以帮助企业跟踪软件开发生命周期中开源组件之间的依赖关系，增强开源代码的可视性和透明度。企业可以将SBOM集成到自身的DevSecOps流程管道中，为所有软件制品自动生成SBOM，同时在关键节点自动化验证SBOM并使用SBOM数据持续评估安全和合规风险。据Gartner预测，到2025年，超过60%的采购或自建关键基础设施软件的企业将在实践中授权并落地SBOM。可以预见，SBOM将在未来的供应链安全中扮演重要角色。

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

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

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

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

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

最后，企业应用安全需要防患于未然，在后续章节中我们会围绕eBPF技术重点介绍如何构建云原生应用的主动免疫、精确审计和风险阻断能力，从而帮助企业安全运维人员从容应对突发的攻击事件，并在规划的指导下做出快速的决策和响应。

4.零信任

零信任安全最早是由Forrester首席分析师John Kindervag在2010年提出的，其核心思想是“Never Trust，Always Verify”。在零信任安全模型中，只要系统处于网络中，默认情况下任何用户都不可信，任何时刻、任何环境下设备和服务的身份权限都需要被持续验证。安全是建立在信任链之上的，如果信任链被打破，那么对资源的访问权限应该被自动取消。直到2020年8月，美国国家标准与技术研究院（NIST）正式发布了“Zero Trust Architecture”，对零信任架构进行了深入的诠释。近两年，在信通院等机构的领导下，我国对零信任理论框架的研究和推广也进入了飞速发展的阶段。可以说经历了十年的演变，零信任已经发展成为新的安全架构。

当然，零信任的发展不应仅停留在理论体系上，也不应仅是企业办公网接入层面的零信任，还应包含企业生产内部设备及应用侧的零信任。目前在各大云服务商落地的零信任产品中，比较知名的包括谷歌的BeyondCorp和ALTS，以及微软发布的Zero Trust零信任框架等。

在云原生时代，企业IT架构已经从传统的单机房模式进化为多云、混合云模式，传统机房架构下的安全信任域在如今的云原生IT架构下已不复存在，而构建在主机之上的容器应用层在结合Kubernetes的编排调度能力后，针对主机的传统安全防护能力也不足以保护云原生企业应用。同时，在应用加速微服务化转型的当下，授权管理的对象已不再局限于终端用户，如何保证微服务之间相互访问的身份管理和权限控制成为新的课题。在零信任下，安全架构从“网络中心化”走向“身份中心化”，其关键是以身份为中心进行访问控制。

零信任在本质上是对企业重要数据或权限的保护，数据加密是传统意义上的保护方式，但在云原生时代，这并不是一个完整的安全方案，需要结合零信任概念，在数据落盘、通信、运算和使用等全流程加密的基础上提供细粒度的身份和权限校验。在实践中需要包含下列要素：

❑信任链。构建大型企业IT系统的信任需要从最基本的信任根开始，通过一系列标准化流程建立一个完整的信任链。其中针对不同的请求主体需要建立对应的信任根，比如：针对人员身份的信任根可以使用MFA（多因子认证）；针对云上主机可以使用芯片厂商提供的安全芯片，基于机密计算技术的不可篡改性实现硬件级别的信任根；针对软件服务，可通过可信构建及对源代码和应用镜像的完整性校验建立信任根。

❑身份。零信任架构下一切请求主体都应当具有身份，而所有访问链路都应该包含足够的请求上下文信息，比如请求者、授权者、访问目的、方式和时间地点等元数据信息，以便在访问控制策略中使用这些信息建立信任关系。

❑持续验证。零信任的理念并不是打破信任，而是强调没有传统意义上绝对信任的假设。我们需要在软件供应链和应用生命周期的各个环节持续进行访问控制，以确保主体的持续可信和动态监测，防止信任滥用。

图1-8为零信任理论体系下的典型架构，架构中各模块的具体功能如下：

❑信任评估引擎。作为策略决策依赖的数据源，持续提供主体信任等级评估、资源安全等级评估及环境评估等数据。

❑访问控制引擎。基于权限最小化原则，以请求为单元，对访问请求基于上下文、信任等级和安全策略进行动态的权限判定。

❑访问代理。可通过多种形式拦截访问请求，发起对请求主体的身份认证和权限判定。

❑身份安全管理平台。可以是云服务商提供的访问控制系统或企业内部的身份管理平台，以及符合标准规范的4A（认证、账号、授权、审计）等系统。

在实践中要注意对访问主体和客体模型与接口的抽象定义，如何能够在描述清晰、直观且易用的基础上实现针对主体和客体的细粒度访问控制是方案落地的关键点。在云原生领域，如服务网格和Kubernetes原生的网络策略模型都是已经被广泛应用的零信任安全方案。

1.3.3 安全观测和事件响应

云原生安全设计需要贯穿应用系统的整个生命周期，通过威胁建模以及基于安全准则的系统安全设计和方案实施，可以在很大程度上帮助应用在事前抵御攻击，同时在事件发生时最小化爆炸半径，避免风险扩大化。在此基础上，还需要构建适合云原生架构特点的安全观测和事件响应能力，实现应用系统安全运营的高效闭环。

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

❑短暂的生命周期，尤其是一些无状态的工作流任务，很可能只有秒级的生命周期。

❑编排引擎会根据节点的实时资源动态调度工作负载，网络IP等应用元数据可能随工作负载的重启而不断变化。

❑由于基础设施的不可变性，对运行时环境的修改在工作负载重启后不会保留。

正因为云原生工作负载自身的特点，在应用运行时，当前大多数云原生安全产品对容器侧用户态进程的检测分析都存在不足。同时针对云原生环境的攻击也日益增多，如何识别应用系统中更多的漏洞和攻击，如何有效防御未知攻击，如何对监测到的攻击事件实现自动拦截、修复等响应动作，同时降低误报、漏报率，是判断云原生环境下安全产品价值的关键指标，而eBPF技术正是提升云原生应用安全观测能力和实现精细化安全事件响应的有力武器。

通过eBPF可以实时获取容器负载中执行的系统调用，并关联映射到容器实例中执行的具体进程上，从而让安全人员可以直观地获取攻击者通过exec等权限进入容器实例中发起攻击的命令，有效帮助针对安全事件的溯源和“止血”。在后续章节中将会详细介绍eBPF技术在云原生安全观测和事件响应方面的应用案例。