云原生安全白皮书.pdf

1云原生安全白皮书Cloud Native Security Whitepaper目录目录执行摘要.3目标.3问题分析.3全生命周期的不同阶段.3开发阶段.3分发阶段.4部署阶段.4运行时阶段.4建议.4结论.5引言.6目标受众.6云原生目标.6云原生的层次结构.6生命周期.7生命周期流程.8开发阶段.8分发阶段.10部署阶段.13运行时环境.15计算.15存储.19访问.21安全保证.22威胁建模.22端到端架构.22威胁识别.23威胁情报.23应急响应.232云原生安全白皮书Cloud Native Security Whitepaper安全堆栈.24环境.24零信任架构.25最小权限.25角色与职责.26合规性.26监管审计.26角色和用例.27行业.27企业.27小企业.27金融.27医疗.27学术与教育.27公共部门.28云原生安全的演变.28总结.29缩略词和词汇表.29参考文献.29致谢.303云原生安全白皮书Cloud Native Security Whitepaper执行摘要目标当前，采用云原生的开发和部署模式已日渐成为技术行业的发展趋势。同时，整个生态系统，包括技术、产品、标准和解决方案，也正在不断扩展，要求决策者要时刻了解复杂的设计。特别是CISO，要在这个动态发展的领域，实践业务价值。同时，云原生模式还鼓励改变消费模式，并采用现代化工作流（例如敏捷方法和 DevOps 流程），这就要求将安全集成进来。问题分析由于传统的基于边界的安全已不再可行，同时由于云原生明确关注快速开发与部署，在这种情况下，安全问题也就变得很复杂。这就要求转变安全范式来保护应用，将基于边界的安全方式转变为更接近动态工作负载的安全方式。动态工作负载是基于属性和元数据（例如标签）来确定的。通过这种方法，可以识别并保护工作负载，满足云原生应用的规模化需求，同时还能适应不断变化的需求。安全范式的转变要求提高在应用安全生命周期中的自动化程度，并通过设计架构（例如零信任）来确保其安全。将容器化作为云原生环境中的一项核心变化，也需要新的最佳实践。容器化的安全实施会涉及组织机构内的多个相关方，并且会对追求业务目标的开发人员和运维人员的工作效率产生重大影响。云原生应用仍然需要开发、分发、部署和运维，但是这种范式就决定了，要有效实现这些目标，需要新的安全机制。可以在应用生命周期的不同阶段（“开发”、“分发”、“部署”和“运行时”），对云原生开发进行建模。云原生安全与传统安全方法的不同之处在于，可以确保在生命周期的不同阶段将安全嵌入进来，而不是通过单独管理的安全干预措施来确保生命周期的安全。要注意，如果不对这些概念、工具和流程的使用和集成进行长期的教育和培训，云原生的落地和应用可能就会难以难以为继，甚至被打回原形。全生命周期的不同阶段开发阶段云原生工具旨在在应用生命周期的早期阶段引入安全。安全测试需要及早发现不合规情况和配置错误，以便缩短可行性反馈的周期，进行持续改进。这种方法可以确保，可以按照针对管道中其他问题而提出的类似工作流（例如 bug 修复或 CI 故障）解决安全故障问题。通常，需要先解决好这些安全问题，才能推动软件在管道中的进一步操作。这种模式的现代化安全生命周期是围绕着代码开发而展开的，代码开发遵循的是推荐的设计模式（例如 12-Factor），并确保了所交付工作负载的完整性。从概念上来讲，云原生与基础架构即代码（IaC）密切相关，旨在确保通过早期安全检查集成，让控件能够按预期状况运行。通过这些控件和集成可以尽早识别错误配置并实施 IaC 和编排清单中的最佳实践，以减少长期成本并提高安全价值。4云原生安全白皮书Cloud Native Security Whitepaper分发阶段在支持软件快速迭代的模型中，软件供应链安全尤其重要。云原生应用生命周期需要采用一些方法，不仅可以验证工作负载本身的完整性，还可以验证工作负载的创建过程和运维方式。加之需要一直使用开源软件和第三方运行时镜像（包括上游依赖项的层），面临的挑战就更大了。生命周期管道中存在的工件（例如容器镜像）需要进行连续的自动扫描和更新，确保免受漏洞、恶意软件、不安全编码方法和其他不当行为的侵害。完成这些检查后，重要的是对工件进行加密签名以确保完整性并强制执行不可否认性。部署阶段在整个开发和分发阶段集成了安全后，可以实现实时、持续验证候选工作负载属性（例如，验证签名的工件，确保容器镜像和运行时安全策略以及验证主机的适用性）。与工作负载一起部署安全工作负载的可观测性功能，可以以高度信任的方式监控日志和可用指标，对集成安全进行补充。运行时阶段预计云原生环境在设计时就会提供策略实施和资源限制功能。运行时工作负载的资源限制（例如Linux 内核 cgroup 隔离）是在云原生环境中集成到应用生命周期的更高级别时的限制性和可观测性示例。可以将云原生运行时环境本身分解为相互关联的组件层，这些组件具有不同的安全问题（例如，硬件、主机、容器镜像运行时、编排）。1在云原生运行时环境中，全球各行各业及各类组织机构都采用了微服务架构用于各类应用。应用通常由几个独立的、单一用途的微服务组成，这些服务通过容器编排层进行服务层抽象后进行通信。确保这种相互关联的组件体系结构安全的最佳实践包括：确保只有经过批准的进程才能在容器命名空间内运行，防止和通知未授权的资源访问情况，监控网络流量来检测恶意工具的活动。服务网格是另一种常见的抽象，它为编排服务提供了整合和补充的功能，而不会对工作负载软件本身进行任何更改（例如 API 流量日志、传输加密、可观测性标记、身份验证和授权）。建议云原生安全旨在确保实现像传统安全模型一样的谨慎性、完整性、信任和威胁防护，同时整合了临时性、分布式和不变性等现代概念。这些瞬息万变的环境支持故障转移，以便进行快速迭代。在这种环境中，需要在开发管道中实现自动化，以此来确保最终结果的安全性。组织机构必须认真分析并应用这些核心安全概念，缩短对加固和环境控制的延迟，并且需要让参与的第三方遵循相同的标准，同时平衡与云功能相关的、针对其安全支持者的持续教育和培训。由于还要考虑到其他层的复杂性，而且还需要关注广泛的组件网格，因此，必须通过在整个生命周期内以及在运行时环境中集成安全，来防止未经授权的访问。强烈建议组织机构根据相关攻击框架2来评估安全防御堆栈，明确防御堆栈能够涵盖哪些威胁。此外，组织机构需要采用一些新的1另一个要考虑的模型是云、群集、容器和代码：https:/kubernetes.io/docs/concepts/security/overview/2示例MITRE ATTCK 框架（Kubernetes）5云原生安全白皮书Cloud Native Security Whitepaper方式和方法将安全左移，扩大 DevOps 的能力。对于在生命周期内进行的创新，需要在管道之前、之中、之后持续妥善地验证所有组件。3结论在整个组织机构中有策略地执行云原生安全时，可以大规模地实现高可用性、保证、弹性和冗余，从而确保客户和开发人员能够按预期的速度安全访问所需资源。安全本身仍然是一个跨学科领域，不能与开发生命周期隔离开来，也不能视为纯粹的技术领域。开发人员、运维人员和安全人员必须加强交流和合作，才能继续推动该领域和行业的发展。与任何技术创新一样，人、激情以及整个发展过程共同造就了云原生社区，并实现了云原生安全。3安全左移后，通常会让组织机构忽略对运维安全的监控。但安全存在于生命周期的所有阶段，并且组织机构必须不断评估其业务和技术流程的方方面面，这样才可能超越现代安全范式，从而形成一种文化和习惯。6云原生安全白皮书Cloud Native Security Whitepaper引言本文旨在让组织机构及其技术领导者对云原生安全、如何在生命周期流程中嵌入安全以及确定最合适的应用时的考虑因素有一个清晰的了解。云原生安全是一个多目标、多约束的问题领域，涵盖了许多专业知识和实践领域。从身份管理到存储解决方案，几乎所有的 Day 1 和 Day 2 运维都与安全领域有所重叠。但是，云原生安全不仅仅包括这些领域。它也是一个关于人的问题领域，包含了个人、团队和组织机构。它是人和系统与之交互并更改云原生应用和技术的机制、流程和意图。目标受众我们的目标受众是希望提供安全的云原生技术生态系统的私营企业、政府机构或非营利组织的首席安全官（CSO）、首席信息安全官（CISO）或首席技术官（CTO）。其他相关者可能包括负责设计和实施安全云原生产品和服务的项目经理、产品经理、计划经理和架构师。除此之外，对云原生安全有浓厚兴趣的任何人都可以参考此文档。云原生目标容器和微服务架构的采用和创新带来了许多挑战。在现代化的组织机构中，缓解网络安全漏洞这一需求的优先级已经明显上升。随着围绕上云的创新在不断加速，威胁形势也随之加剧。安全负责人有责任采取措施来预防、检测和响应网络威胁，同时满足严格的合规性要求，从而保护人类和非人类4资产。过去人们常说，安全的实施会阻碍 DevOps 团队的速度和敏捷性。因此，安全负责人必须让 DevOps 团队更紧密的集成在一起，加强相互理解，共同对网络风险负责。组织机构必须要共享要采用的云原生安全采用模式及架构，确保行业以高优先级实施安全措施，并将这些安全措施整合到整个现代化应用开发生命周期中来。最重要的是，突出安全体系架构与安全负责人之间的协同作用，并符合组织机构在漏洞管理、零信任、云安全和 DevSecOps 等方面的安全目标，这些都应该是最高优先级的事项。本文通篇所描述的概念并非是说某种产品或组件优于另一种产品或组件，而是无论选择哪些服务，都可以使用。云原生的层次结构4人力资本是任何组织成功所必需的重要资产，由此带来的相应知识产权和关系资本同样需要受到保护。7云原生安全白皮书Cloud Native Security Whitepaper图 1云原生堆栈由基础层、生命周期层和环境层组成。云原生堆栈可以使用不同的部署模型（IaaS、PaaS、CaaS 和 FaaS）来部署。每个部署模型都提供了更多的抽象，以简化云原生环境的管理和运维。由于其中一些模型是众所周知的并且已经使用了多年，因此，我们将重点介绍云原生的特有模型。容器即服务（CaaS）模型可以让用户通过利用基于容器的虚拟化平台、应用编程接口（API）或Web 门户管理接口来编排和管理容器、应用和集群。CaaS 通过将安全策略作为代码嵌入，以此来帮助用户构建可扩展的容器化应用，并在私有云、本地数据中心或公有云上运行。CaaS 有助于简化容器的构建过程。通过微服务编排和部署，CaaS 可以帮助企业加快软件的发布速度，并可以在混合环境和多云环境之间移植，从而降低基础架构的成本和运营成本。CaaS 模型可节省成本，因为它可以帮助企业简化容器管理，同时让企业可以仅仅支付希望使用的 CaaS 资源的成本费用。CaaS 将容器作为其基本资源，而对于 IaaS 环境，则使用虚拟机（VM）和裸机硬件主机系统。功能即服务（FaaS）是另一种云原生部署模型，这是一种云服务，可以让企业用户通过执行代码对事件作出响应，而无需关心通常与构建和启动微服务相关的复杂基础架构。在云中托管软件应用通常需要配置和管理虚拟环境，管理操作系统和 Web 组件等。使用 FaaS 服务后，物理硬件、虚拟机操作系统和 Web 服务器软件管理都由云服务商自动处理。因此，用户可以专注于微服务代码中的各个功能，同时仅为所使用的资源付费，并可以充分利用云提供的资源弹性。生命周期云原生环境中的生命周期是指让弹性、可管理和可观测的工作负载在云环境中运行的技术、实践和流程。如图 1 所示，生命周期由四个连续的阶段组成：开发、分发、部署和运行时。每个阶段都是对前一个阶段的拓展和延伸，同时允许并支持工作负载的安全执行。8云原生安全白皮书Cloud Native Security Whitepaper生命周期流程供应链的管理和适用的安全基准对于安全实施至关重要。供应链组织机构有责任确保，可以在生命周期过程中对他们正在开发的工作负载供应链进行可行的安全分析。供应链安全可以分为两部分：提供环境创建工作负载的工具和服务的安全（例如开发人员工具）以及构成工作负载本身的组件的安全（例如库、依赖项和镜像）。供应链实施后，需要确保供应链本身的完整性可以验证，并且可以对软件供应链产生的工件进行签名以验证来源。因此，组织机构在使用依赖项时必须谨慎行事，因为上游依赖程序包可能不可避免地包含安全漏洞。验证所使用的第三方程序包的真实性和完整性对于确保依赖项按预期运行，且不会受到入侵至关重要。云原生应用的一个主要特征是软件复用，这些软件可能以开源软件包和容器镜像的方式，通过开源仓库进行构建和分发。因此，对于开发人员、运维人员和安全人员而言，重要的一点是要确保应用中的工件和依赖项不包含已知的恶意软件和漏洞来源。容器镜像中存在恶意软件是运行时环境中的重要攻击向量5。必须在 CI 管道以及容器镜像仓库中对容器镜像和软件包定期或按需进行漏洞扫描。通过这些方法可以确保软件分发和持续运行的安全性及可验证性。将漏洞扫描整合到工作负载生成管道中来，这样组织机构就可以加强对开发团队的反馈，并能够进一步阻止分发或部署不安全或易受攻击的更新软件。定期扫描软件还会发现现有软件中新发现的漏洞升级。安全基准安全基准（例如 NIST 应用容器安全指南、互联网安全中心（CIS）、NIST 微服务安全策略和OpenSCAP）可为开发团队和组织机构提供创建“默认安全”的工作负载的指南。这些基准的采用和实施可以让团队开展测试，强化安全基准。但是，这并没有考虑到数据流和测试平台的自定义使用。安全从业人员应将其作为一项指南，而不是一个检查清单。接下来的几节将详细分析在整个应用生命周期中集成安全的含义、工具、机制和最佳实践。开发阶段5https:/ Native Security Whitepaper图 2需要确保云原生应用在整个生命周期中的安全性。“开发”阶段是生命周期的第一个阶段，包括创建工件（例如，基础架构即代码，应用程序和容器清单等），用于部署和配置云原生应用。事实证明，这些工件是许多攻击向量的源头，会在运行时阶段发生漏洞利用。接下来的几节将详细介绍此阶段需要创建的各种安全工具、流程和检查，以显著缩小在运行时中部署的应用的攻击面。开发阶段的安全检查开发阶段中的安全加固是应用部署阶段的一个关键部分。这意味着，必须在软件开发的早期就引入安全需求，并用与其他任何需求相同的方式来处理安全需求。这些安全需求通常是围绕风险和合规进行的。在早期阶段解决这些需求可防止在生命周期的后期重新处理，而重新处理则会延缓DevOps 流程，并增加总体成本6。DevOps 团队还必须利用专门构建的工具在部署应用之前就识别安全配置错误和漏洞。另一个重点在于，这些工具可以无缝集成到 DevOps 团队的现有和熟悉的工具中，以增强敏捷性和安全性，而不是对其造成妨碍。例如，这些工具需要在开发人员 IDE中或发出“拉取请求”时，对基础架构即代码模板以及应用清单进行扫描，并提供丰富的上下文相关的安全信息，根据这些信息在开发阶段的早期快速、轻松地进行安全处理。采取这些措施可确保消除已知漏洞或高风险配置。云原生组件应由 API 驱动，让复杂的调试工具与依赖编排工具的原始工作负载进行交互。各团队应部署专用的开发、测试和生产环境，以便为基础架构和应用的开发人员提供独立的环境来开发、测试和部署各个系统和应用、容器根镜像、VM 黄金镜像以及非功能性测试。一些组织机构可能发现，利用金丝雀部署、蓝绿部署或红黑部署以及其他部署模型可以提高动态和交互式测试和可行性研究的效率。测试开发开发人员、运维人员和安全人员应针对关键业务级、高威胁类型、频繁变更或具有 bug 历史记录6根据 Applied Software Measurement（Capers Jones，1996 年）的研究，并将通货膨胀考虑进来，约 85的缺陷是在编码过程中引入的，每个漏洞的修复成本为 41 美元，而发布后的修复成本为 26,542 美元。10云原生安全白皮书Cloud Native Security Whitepaper的代码和基础架构构建测试。威胁建模可以识别高风险和高影响力的代码热点，对这些热点代码进行测试可以实现高投资回报率（ROI）。测试可能涵盖了部署、操作系统、基础架构和数据库加固、应用程序测试（静态和动态源代码测试、容器配置）、集成或系统测试（应用和基础架构组件的验收及其交互）以及冒烟测试（部署后对实时系统进行检查）。测试编写者应可以访问开发和测试综合环境，以便他们能够快速地开发测试，同时缩短持续集成（CI）反馈循环。应该为测试编写者提供系统测试包，以便在本地运行，也可以在共享测试环境中运行。代码审查对工作负载或已部署了工作负载的基础架构进行的细微变更，也可能会产生深远的安全问题。为了降低产生意外后果的风险，建议各团队先根据“四眼”原则进行代码审查，然后再将先前的变更整合到代码库中（例如，在 git 工作流中实现拉取请求）。分发阶段图 3“分发”阶段的主要任务是使用镜像定义和规范来构建下一个阶段的工件，例如容器镜像、VM 镜像等等。按照现代的持续集成和持续部署范式，“分发”阶段包括系统的应用测试，以识别软件中的bug 和错误。但是，采用开源软件和可重复使用的软件包会导致将漏洞和恶意软件引入到容器镜像中。因此，有必要执行一些安全措施，例如扫描镜像，检查是否存在上述威胁向量，以及验证镜像的完整性，防止篡改。下文将详细介绍安全最佳实践，帮助开发人员和运维人员识别并保护容器镜像免受威胁，并确保有适当的技术和工具可以保护整个 CI/CD 管道和基础架构的安全。此外，如果需要保密，组织机构可能希望对软件工件进行加密。如果软件工件由于入侵或其他事件而变得不可信，相关团队应吊销签名密钥以确保废止。构建管道持续集成（CI）服务器应是独立的，并仅限于具有相似安全性或敏感性的项目使用。基础架构构建若需要提升权限，则应在独立的专用 CI 服务器上运行。构建策略应在 CI 管道中以及编排工具的准入控制器中执行。供应链工具可以收集构建管道元数据并进行签名。然后，后续阶段可以验证签名，以验证管道的必要阶段已经在运行。11云原生安全白皮书Cloud Native Security Whitepaper读者应确保 CI 和持续交付（CD）基础架构尽可能安全。例如，应优先考虑尽快安装安全更新版本，并应通过使用硬件安全模块（HSM）或凭据管理器来保护加密密钥不被泄露。镜像扫描扫描容器镜像是在整个生命周期中保护容器应用的一个重要步骤。很重要的一点是，先在 CI 管道中进行扫描，然后再将镜像部署到生产中去。这一功能可确保开发人员、运维人员和安全专业人员可以详细了解所有已知漏洞以及诸如严重性、CVSS 分数和是否具有缓解措施/修复程序之类的详细信息。将容器镜像的漏洞扫描与管道合规性规则相结合，可确保仅将妥善修补的应用部署到生产环境中，从而减少了潜在的攻击面。扫描容器镜像还有助于识别来自开源镜像仓库的开源软件包或根镜像层中是否存在恶意软件。通过容器镜像扫描，各团队可以了解是否存在漏洞或恶意软件，但并不能预防漏洞或恶意软件。在选择进行镜像扫描、设置机制根据扫描信息采取措施以及执行组织机构的合规性规则时，组织机构应谨慎行事。镜像加固容器镜像是构建管道的一级输出。因此，容器镜像必须进行安全加固，加固时要考虑到缓解威胁，同时允许在运行时阶段进行一些即时配置，以便与生态系统的其他部分相适应。关于安全保证目标，应评估以下问题：执行环境是否应限于特定用户？是否应该限制资源的访问？是否应限制内核级的进程执行？容器应用清单扫描应用清单列出了部署容器化应用所需的配置。如“安全基准”部分中所述，NIST 800-190 等指南和建议推荐了应用容器安全的最佳实践和配置。因此，重要的一点是要使用工具扫描 CI/CD 管道中的这些应用清单，找出可能导致不安全部署状态的配置。容器应用清单加固对于容器镜像，可以在构建阶段以及运行时阶段考虑并执行容器应用清单加固。关于安全保证目标，应评估以下问题：运行时执行生态系统应遵守哪些最小约束？测试云原生应用应遵循与传统应用相同的套件和质量测试标准，包括整洁代码、测试金字塔、通过静态应用安全性测试（SAST）进行应用安全性扫描和 lint 扫描、依赖性分析和扫描、动态应用安全性测试（DAST）（例如模拟试验）、应用工具以及开发人员可以在本地工作流程中全套测试基础设施。自动化测试结果应按照二重证据法（开发人员和工具）的要求进行映射，以向安全和合规团队提供实时安全保证。一旦确定了安全 bug（例如，错误的防火墙或路由规则），如果通过根本原因分析确定了该 bug有可能再次出现，那么开发人员应编写自动测试以防止重现。在测试失败时，团队会收到反馈以12云原生安全白皮书Cloud Native Security Whitepaper对该 bug 进行修复，并且在下一次合并时，通过测试（假定 bug 已修复）。这样做可以防止将来变更代码时回退到最初的代码。基础架构的单元测试是一种预防性控制，其目标是基础架构即代码（IaC）配置中定义的实体和输入。对已构建的基础架构进行安全测试是一种检测性控制，结合了安全保证、历史回归和非预期配置检测（公开的防火墙规则、IAM 特权策略、未认证的端点等）。应有全面的测试套件来支持对基础架构和工作负载进行加固，这可以随着系统的成熟而逐步加固。在构建阶段应该进行测试，确认已经进行了加固，但也应在部署阶段时执行测试，进而评估整个生命周期中可能发生的任何变更或回归。静态分析和安全测试对 IaC、应用清单和软件代码的静态分析可能包括 lint 扫描、识别错误配置和漏洞扫描。IaC 代码应遵循和应用工作负载相同的管道策略。IaC 越来越受到青睐，有越来越多的组织机构在执行 IaC，用于部署云和容器基础架构。因此，这些模板中的不安全配置可能导致攻击向量的暴露。在部署应用和基础架构工件之前，应使用自动化工具对这些模板进行扫描，以查找不安全配置和其他安全控制。需要注意的关键性错误配置包括：应用清单中所述镜像中所包含的缺陷。配置设置，例如，可以提升权限的容器。识别有哪些安全性上下文和系统调用会导致系统入侵。资源限制设置。动态分析对已部署的基础架构进行的动态分析可能包括检测 RBAC 和 IAM 配置漂移，验证预期的网络攻击面以及确保 SOC 可以在专用测试环境中检测异常行为进而为生产环境配置警报信号。动态分析被认为是测试的一部分，但是，也可以在非生产运行时环境中进行。安全测试对应用和基础架构进行自动安全测试是安全团队中应该是不可或缺的重点内容。测试套件应不断更新，按组织威胁模型复制威胁，并可随系统的发展重新用于安全性回归测试。自动化安全测试项消除了手动安全门（例如，在单个检查点进行验证和手动控制操作，既耗时又不充分）来提高安全性和发布速度。自动化安全测试可根据需要明确尝试执行威胁，证明按需控制的有效性，从而实时改善系统的安全性以及对任何嵌入式合规要求的遵从性。工件和镜像镜像仓库暂存由于通常使用从公共资源中获取的开源组件，因此，组织机构应在其管道中创建多个用于暂存的镜像仓库。只有经授权的开发人员才能访问公共镜像仓库并拉取根镜像，然后将其存储在内部镜像仓库中以供组织内部使用。另外，建议组织机构建立单独的私有镜像仓库，用于存储每个团队或每个小组的开发工件，最后，还应建立一个暂存或生产前的镜像仓库，以备生产阶段使用。这13云原生安全白皮书Cloud Native Security Whitepaper样就可以更严格地控制开源组件的来源和安全性，同时可以对 CI/CD 链中的各个阶段进行不同类型的测试。对于任何已使用的镜像仓库，必须通过专用的身份验证和权限模型来实现访问控制。（在架构内的交互中）对所有镜像仓库之间的连接，使用相互认证的 TLS。签名、可信任及完整性在构建阶段对镜像内容进行数字签名，并在使用前对签名数据进行验证，以防止镜像数据在构建阶段和运行时阶段之间被篡改，从而确保工件的完整性和来源。验证应从说明工件已经过审核和批准这一流程开始。可信性验证还包括验证工件具有有效签名。在最简单的情况下，每个工件可以由一位签名者签名，以表明该工件经过了一个测试和验证过程。但是，在大多数情况下，软件供应链更为复杂，创建一个工件需要多个验证步骤，因此这取决于多个实体的可信性。例如：容器镜像签名容器镜像清单的签名过程配置签名配置文件（即应用配置文件）的签名：在 GitOps 方法中最常见，其中可能包括一个验证和检查配置的过程。软件包签名对工件软件包（如应用软件包）进行签名。对于诸如库或 OCI 工件之类的通用软件工件，要对这些工件上进行签名，表明它们已被组织机构批准使用。验证这些工件对于确保仅允许使用授权的工件同样至关重要。强烈建议在对存储库中的镜像进行变更或将代码提交到存储库中时，对存储库进行相互认证。加密容器镜像加密即对容器镜像进行加密，使其内容保持机密。容器镜像内容经过加密后，可确保内容从构建阶段到运行时阶段都可以保持机密性。如果在分发时遭到入侵，镜像仓库的内容仍可以保持机密，这有助于解决诸如保护商业秘密或其他机密材料之类的用例。容器镜像加密的另一个常见用途是强制执行容器镜像授权。当镜像加密与密钥管理认证和/或授权和凭证分发相结合时，可能会要求容器镜像只能在特定平台上运行。容器镜像授权对于合规用例（例如，区域限制或出口控制以及数字版权媒体管理）很有用。部署阶段14云原生安全白皮书Cloud Native Security Whitepaper图 4“部署”阶段的主要任务是整合一系列运行前检查，确保要在运行时环境中部署的应用符合并遵守全组织机构范围内的安全性和合规性策略。运行前部署检查部署之前，组织机构应验证以下各项是否存在、是否使用及其当前状态：镜像签名和完整性镜像运行时策略（例如，不存在恶意软件或严重漏洞）容器运行时策略（例如，不存在多余的特权）主机漏洞和合规性控制工作负载、应用和网络安全策略可观测性和衡量指标将可观测性和衡量指标纳入云原生架构可提供安全见解，这样，相关方就可以解决和减少报告时出现的异常情况；这方面的工具可以有助于收集和可视化此类信息。通过使用行为和启发式分析，团队可以检测并升级异常数据、可疑事件以及对相关方不明原因的调用。鼓励使用人工智能（AI）、机器学习（ML）或统计建模来协助进行行为和启发式分析开发。响应和调查一款应用应提供有关身份验证、授权、操作和失败的日志。开发人员应将此功能纳入计划和设计阶段。当进行调查并需要确定根本原因时，这些要素就提供了可循的证据。取证能力是任何事件响应和缓解活动不可或缺的一个组成部分。该能力为确定事件的根本原因提供了证据，并为要采取的任何缓解措施提供了反馈。容器环境的短暂特性要求使用更敏捷的工具集来捕获和分析任何证据。将取证能力集成到事件响应计划和程序中，将为获取和处理证据提供15云原生安全白皮书Cloud Native Security Whitepaper方法，缩短确定根本原因的时间，并最大程度地降低入侵风险。运行时环境图 5运行时阶段包括三个关键领域：计算、访问和存储。尽管运行时环境取决于开发、分发和部署阶段的成功完成，但是运行时的安全性取决于先前各阶段安全实践的之有效性。下文详细介绍了每个关键组件的安全要求及其意义。计算云原生计算是一个非常复杂且不断发展的结构。若没有核心组件来提高计算利用率，组织机构将无法确保工作负载的安全性。考虑到容器为共享主机上的多租户应用提供了基于软件的虚拟化，因此，使用容器专用的操作系统非常重要。通常，容器专用操作系统是一个只读操作系统（OS），禁用了其他服务。使用这种OS 有助于减少攻击面，还提供了独立性和资源限制，让开发人员能够在共享主机内核上运行独立的应用。为了实现深度防御，还建议不要在相同的 OS 内核上运行不同的数据敏感度的工作负载。为了保障容器平台和服务所有层的安全，可以使用基于可信平台模块（TPM）或 vTPM 的硬件信任根。可以将源于硬件的信任链扩展到 OS 内核及其组件，以对可信启动、系统镜像、容器运行时和容器镜像等进行加密验证。操作系统提供基本的系统组件，例如用于远程连接的加密库以及用于进程启动和管理等的内核功能。这些操作系统可能存在漏洞，并且由于它们为容器提供了底层计算基准，因此可能会影响在主机上运行的所有容器和应用。同时，容器配置不当会影响主机内核的安全性，从而影响在该主机上运行的容器中的所有服务。更多信息，请参阅“分发阶段”了解详情。16云原生安全白皮书Cloud Native Security Whitepaper编排任何编排工具都有多个组件，可以分成不同层，例如控制层和数据层。有时，需要具有一个较高层次的多部署管理结构，负责维护多个彼此独立并存的不同控制层。任何编排系统都面临诸多威胁，影响部署的整体安全性以及运行时的持续安全性。为控制集群、拦截控制层流量而恶意访问编排工具的 API、对键值存储和编排工具仪表板进行未经授权的访问以及更改、滥用 API、拦截应用流量等都是潜在威胁。对于任何编排工具而言，由于存在多种威胁，使用最佳实践和配置加固以防止遭受威胁是很重要的7。监控和检测在运行时阶段对初始配置所做的任何更改对于确保集群的持续安全状态也很重要。其他安全的最佳实践，如最大限度地降低对控制层的管理访问权限、职责划分和最小权限原则，均应予以执行。安全策略必须考虑编排工具的安全特性和各种配置方案，以控制在容器运行时生成容器的安全特权。使用较高级别的策略和治理结构可能会加强这些安全防护。资源请求和限制通过 cgroup 应用不同的对象级别和资源请求及限制，有助于防止由于一个有意（例如，fork 炸弹攻击或加密货币挖矿）或无意的（例如，读取内存中的大文件而没有输入验证，水平自动定量以耗尽计算资源）问题导致工作负载出现问题，耗尽节点和集群资源。审计日志分析审计日志分析是识别和关联系统入侵、滥用或配置错误的最成熟的方法之一。审计日志分析和关联的持续自动化对于安全团队而言至关重要，因为与传统系统相比，云原生架构能够为工作负载生成更细粒度的审计配置和过滤功能。此外，通过云原生日志的互操作性，可以进行高级过滤，防止下游处理中的过载问题。与传统的日志分析一样，此处至关重要的是生成可操作的审计事件，将日志中的数据关联起来/形成上下文，形成驱动决策树/事件响应的“信息”。根据一组预先配置的规则来检测不合规的违规行为，以过滤违反组织机构策略的违规行为。为了能够使用集群来审计实体的操作行为，启用 API 审计功能非常重要，其中要包含安全团队、集群管理人员或其他学科团队感兴趣的针对一组特定 API 组或动词的过滤器。将日志直接转发到通过集群级凭据无法访问的位置，也可以挫败攻击者通过禁用日志或删除其活动日志来掩盖其踪迹的企图。处理警报的系统应定期调整为误报，以避免在系统未检测到安全事件后出现警报洪泛、疲劳和误报。控制平面身份验证和根信任证书除了加固现有控制平面之外，编排工具管理人员还应配置所有编排工具控制平面组件，如控制器管理器、调度器、API 服务器和 kubelet（如适用），以便通过定期轮换的证书完成相互认证和证书验证，进行通信。发出命令的 CA 可以是默认编排工具 CA 或外部 CA。管理人员应特别注意保护 CA 的私钥。有关扩展或建立信任的更多信息，请参阅本文的“身份认证”部分。机密数据加密7CIsecurity.org 维护了用于加固的基准测试清单17云原生安全白皮书Cloud Native Security Whitepaper通过使用外部机密管理工具或在本地使用编排工具的机密数据，可以在容器编排或部署环境中管理机密数据。使用本机机密存储区时，注意有几种不同的保护方法可用：使用外部密钥管理存储（KMS）进行加密使用 KMS 是保护编排工具机密存储区中机密数据的一种安全方法，其中，外部KMS 中的密钥加密将对数据加密密钥（DEK）进行加密，而该 DEK 将对 etcd 中的静态机密数据进行加密。此方法确实可以在内存中缓存 DEK，减少对外部 KMS的依赖，并在 Pod 创建期间更快地解密机密数据。由编排工具管理的加密这种方法会对存储在编排工具中的机密数据进行加密，但是加密密钥也由编排工具管理（例如，编排工具的配置文件）不加密例如，对于某些编排工具，机密数据是 base64 编码的，并且在默认情况下以明文形式存储在键值存储区中使用外部机密数据管理工具可以限制使用未加密机密数据带来的风险，并降低了密钥管理的复杂性。大多数情况下，这些工具是作为控制器或运算器提供的，可以在运行时注入机密数据并透明地进行轮换。容器运行时环境需要从进程、文件和网络的角度监控和保护容器的运行时环境。主机操作系统只应允许在容器中执行或调用经过批准的功能和系统调用（例如 seccomp 过滤器）。应监控并阻止对关键挂载点和文件的变更。必须通过配置防止更改二进制文件、证书和远程访问配置。还必须通过配置阻止容器的出入网络访问，只访问需要操作的内容。此外，应检测并拒绝恶意域名的网络流量。微服务架构和消除绝对信任以微服务架构部署的容器化应用，其边界即微服务本身。因此，有必要定义好策略，限制仅经批准的微服务对之间方可进行通信。在微服务架构中纳入零信任，则可以在微服务架构被入侵时，通过防止横向移动来减小影响范围。运维人员应确保他们正在使用诸如网络策略之类的功能，以确保容器部署内的东西网络通信仅限于授权访问的范围。NIST SP 800-204 文件为微服务安全提供了一些策略，已经做了一些初步工作，并且可以作为实现安全微服务体系结构的指南。镜像信任和内容保护利用策略代理来强制执行或控制已签名授权的容器镜像，这样组织机构便能够保证工作负载的镜像来源。此外，引入加密容器可以保护容器内存在的敏感源、方法或数据。服务网格服务网格将各项服务连接起来，以此实现流量控制、服务发现、负载平衡、弹性、可观测性、安全性等。服务网格能够让微服务架构从应用库中卸载这些功能，并让开发人员能够专注于区分业务逻辑。为了有效地确保云原生环境中各服务之间的安全通信，组织机构应执行服务网格以消除18云原生安全白皮书Cloud Native Security Whitepaper其 Pod 内部和不同工作负载之间通过动态数据加密实现的绝对信任。使用服务网格还解决了身份问题，其中，传统的第 3 层和第 4 层身份（即 IP 地址）不再明确地映射到工作负载。服务网格不仅提供网络级别的独立性和安全性，而且还提供网络级别的弹性功能，例如，重试、超时和实现各种断路功能。流处理平台可以通过使用工作负载级别的授权来设置主题或代理的访问规则，从而从服务网格中受益，并提高安全性。值得注意的是，服务网格的执行可以有助于减少云原生部署的攻击面，并提供用于构建零信任应用网络的关键框架。运行时阶段的检测监控已部署的工作负载应为团队提供验证，以确保真实的操作状态是预期的状态。组织机构不能放弃在其环境中进行定期安全扫描和监控，而不将其工作负载变成攻击者的无监督场所。应该使用用于检测、跟踪、汇总和报告系统调用的组件以及来自容器的网络流量，来查找意外或恶意行为。尽管回归测试和安全测试项有利于防止将已知的预期问题转移到生产环境中，但它们无法阻止这一切的发生。应对工作负载进行动态扫描，以检测尚无已知事件的恶意或阴险行为。在大多数环境中，预计不会发生扩充休眠命令之类事件，在工作负载已运行 X 天后从 etcd 进行数据渗出，因此，这些事件未包含在安全测试中。关于工作负载可能具有时间或事件延迟的特洛伊木马这一方面，只能通过对比基准预期行为与通常在细致的活动和扫描监控期间发现的行为才能检测到。此外，工作负载在部署之时或之后将变得易受攻击。组织机构应不断扫描其环境，以检测哪些工作负载现在易受攻击。了解每个工作负载的组成或构成清单有助于组织机构快速确定漏洞的位置。有关这些漏洞的其他信息，例如，漏洞利用成熟度和使用时易受攻击的路径，对于确定工作负载的实际风险至关重要，并且可以帮助组织机构对有风险的应用进行优先更新。函数无服务器函数易受到各种