查看“云原生安全保障”的源代码


安全是一个基于风险管理的过程，旨在识别和解决系统面临的风险。对系统的迭代和持续加固将根据组件或组织的风险概况和容忍度来减轻、降低或转移风险。加固的概念虽然在其核心上是传统的，但仍可应用于具有安全意识的团队，通过评估组件及其构成与最小功能的一致性来实施。例如，当团队确定更新基础镜像时，应审查新增端口、权限和软件包，并对其进行接受、修改或限制。

相比之下，合规标准形成了一套控制原则，通过评估系统与这些要求定义相符或创造性地满足这些要求。评估结果是二进制的（合格或不合格），但可能包含第一类错误（假阳性）或第二类错误（假阴性），应将其视为 CI/CD 流水线测试的结果，类似于流水线中的任何其他测试结果。因此，合规和安全保障是相互补充的过程，但它们并不可互换。合规的系统不能保证安全，同样，安全的系统也不能保证合规。

== 威胁建模 ==

对于采用云原生的组织来说，进行威胁建模是识别风险、控制措施和缓解措施的主要方法之一。虽然有许多威胁建模技术，但它们都具有一些共同的特点。首先，需要构建系统架构的范围表示。这从识别所有重要的流程、数据存储和[https://www.oreilly.com/library/view/cissp-certified-information/9780470276884/9780470276884_security_boundaries.html 安全边界]开始。一旦建立了边界，并在其中对系统的相关元素进行了划分，下一步是对这些元素如何进行交互进行建模，特别关注跨越安全边界的任何交互。

以下指南是对[https://owasp.org/www-community/Threat_Modeling OWASP threat modeling] 提供的四步威胁建模方法的增强，适用于云原生能力。

=== 端到端架构 ===

对组织或个人的云原生架构有清晰的理解应该导致数据影响指导和分类。这有助于团队在架构中组织数据分发，并为其提供额外的保护机制。云原生的图表和文档不仅应包括整体系统设计的核心组件，还应包括源代码的位置、使用的存储机制以及软件开发周期的其他方面。这些都是在进行云原生威胁建模时必须考虑的领域。

=== 威胁识别 ===

在考虑与组织的云原生能力相关的威胁时，建议利用成熟且广泛使用的威胁模型，例如 STRIDE 或 OCTAVE。组织可能希望考虑的云原生架构的常见威胁包括但不限于：

* '''冒充'''：通过社交工程攻击窃取认证凭据来冒充集群管理员。
* '''篡改：'''篡改 API 服务器配置文件或证书可能导致 API 服务器重新启动失败或互相 TLS 身份验证失败。
* '''否认'''：由于禁用或配置错误的 API 审计，攻击者的行动可能被否认，导致缺乏潜在攻击的证据。
* '''信息泄露'''：如果攻击者入侵正在运行的工作负载并能将数据外泄到外部实体，可能会导致信息泄露。
* '''DoS'''：由于未对工作负载应用资源限制，可能导致拒绝服务（DoS），从而消耗整个节点级的 CPU 和内存，导致工作节点丢失。
* '''权限提升'''：如果工作负载以无限制或更高权限运行，或者通过修改工作负载或容器的安全上下文，可能会提升权限。

在云原生安全中要考虑的威胁行为与现有的威胁建模实践一致：

* '''恶意内部人员''' - 具有恶意意图并具有在建模系统内执行操作的授权的参与者。
* '''无知内部人员''' - 具有在建模系统内执行操作的授权（假设任何人都可能被欺骗）的参与者。
* '''恶意外部人员''' - 拥有恶意意图且位于系统外部的参与者，能够通过互联网、供应链、物理边界等方式发动攻击，而无需明确授权来执行建模系统内的操作。

还有其他可能与建模系统进行交互的参与者（例如，无知的外部人员），为了完整起见，可以将它们包括在内。对于它们的行为，控制措施很可能是上述主要参与者的子集。

与任何云原生流程一样，迭代和提供反馈是很重要的。在威胁建模的背景下，这意味着重新评估现有的措施、机制和矩阵是否准确反映了由于架构的持续变化而产生的操作状态。

=== 威胁情报 ===

云原生应用是由第一方和第三方代码和工具组成的多个动态组件的集合，这意味着威胁情报必须应用于网络活动和云原生应用组件。网络威胁情报是有关威胁和威胁行为者的信息，有助于减轻有害事件的发生。在云原生系统中，威胁情报利用在网络或主机上观察到的指标，如 IP 地址、域名、URL 和文件哈希，用于辅助识别威胁。行为指标，如威胁行为者的战术、技术和程序，也可用于识别云原生组件中的威胁行为者活动。[https://attack.mitre.org/matrices/enterprise/cloud/ MITRE ATT&amp;CK 框架]可作为建立和验证威胁活动的起点。

=== 容器威胁矩阵 ===

ATT&amp;CK 的容器威胁矩阵是评估和建模系统威胁的绝佳起点。[https://medium.com/mitre-engenuity/att-ck-for-containers-now-available-4c2359654bf1 ATT&amp;CK 的容器威胁矩阵]主要关注攻击者在成功攻击系统时展示的对抗行为。

ATT&amp;CK 的威胁矩阵由行和列组成，行表示技术，列表示战术。了解攻击者可能的最终目标可以帮助我们作为开发人员和平台运营商构建更好的安全性并进行防御。让我们通过这个角度来看待威胁矩阵中的各种技术。

* '''初始访问（Initial Access）'''：这是攻击者成功利用容器环境的第一步。公开面向的应用程序可能存在可以被攻击者利用的漏洞，从而导致对手获得主机访问权限。因此，作为开发人员，实施外部服务的互相认证并尽可能限制共享主机资源（例如挂载主机文件系统）非常重要。
* '''执行和持久化（Execution &amp; Persistence）'''：成功获得初始访问权限的攻击者将继续运行恶意代码，以在系统重新启动后保持对系统的控制。通常情况下，这可以通过攻击者拥有的恶意镜像来实现，该镜像会像其他正常工作负载一样部署，以逃避检测。因此，作为平台运营商，限制集群可访问的注册表、实施安全的镜像推广流程并审计集群中的镜像拉取操作是非常重要的，这样可以及时发现异常事件，例如从未知的注册表拉取镜像。
* '''权限提升（Privilege Escalation）'''：在这个阶段，攻击者将尝试获得根或管理员权限。攻击者可能会逃离容器化环境以访问底层主机。因此，作为开发人员，在为工作负载设置权限时遵循最小权限原则，这样可以增加攻击者突破运行时隔离的难度。
* '''防御规避（Defense Evasion）'''：一旦攻击者在环境中建立了控制权，它将尝试主动规避系统的防御措施。因此，作为平台运营商，审计在主机上执行的 Shell 命令或容器执行调用，可以检测到此类方法。
* '''凭证访问（Credential Access）'''：如果攻击者在攻击中取得了进展，它将使用暴力破解的方式获取容器和容器编排账户的访问权限。因此，作为平台运营商，为开发人员提供临时凭证将限制被攻击凭证的价值，因为一旦凭证过期，它将变得无用。
* '''发现（Discovery）'''：攻击者试图了解容器环境，并发现可用资源，例如集群上部署的容器或组件，并尝试了解其分配的权限。作为平台运营商，为 API 网关/服务器的 GET 调用和未知用户在主机上执行的命令进行审计是一个很好的功能，可以用于检测发现阶段的攻击。
* '''影响（Impact）'''：在这个阶段，攻击者执行其目标，可能包括执行拒绝服务（DoS）攻击，以降低或阻断目标资源的可用性。这旨在利用被攻陷的系统解决资源密集型问题，可能影响系统或托管服务的可用性。因此，作为平台操作员，拥有完善的事件响应手册并默认应用软限制和硬限制，以限制共享主机资源的工作负载非常重要。

静态元数据，例如 IP、域名和哈希值，将在不同环境中发生变化，但很难改变攻击者的想法，这是构建 MITRE ATT＆CK 容器威胁矩阵的核心动机。在本文中，通过云原生应用生命周期中的四个阶段详细解释了威胁矩阵中描述的技术和策略的其他缓解措施。

=== 事件响应 ===

对于已有事件响应和分级工作流程的组织，应特别关注如何将其应用于可能不符合某些基本假设的云原生工作负载。这些假设包括节点隔离（新的工作负载实例可以在不同的服务器上运行）、网络（例如，IP 地址是动态分配的）和不可变性（例如，容器的运行时更改在重新启动后不会保留）。因此，重要的是重新审查这些假设，并根据需要重新应用或更新事件响应手册。可观察性和取证工具需要理解云原生的特定结构，如 Pod 和容器，以便能够维护或重建被入侵系统的状态。在面向意图的编排器中，有时会无意中处理证据不当，因为这些编排器将工作负载视为“牲畜而非宠物”。需要注意的是，从零开始构建事件响应和分级策略虽然可行，但不在本文档讨论的范围之内。

<span id="用例勒索软件"></span>
== 用例：勒索软件 ==

识别、建模和实施威胁缓解措施可能是一项艰巨的任务。为了让它更容易理解，让我们来看看云原生环境中勒索软件威胁的一个具体示例。

勒索软件是一种恶意软件，它采用加密来控制受害者的信息以勒索赎金。对用户或组织的关键数据进行加密，使其无法访问文件、数据库或应用程序。然后要求支付赎金以重新获得对加密数据的访问权限。勒索软件通常被设计为在网络上传播，并以数据库和文件服务器为目标，可以迅速使整个组织瘫痪。这是一个不断增长的威胁，给网络罪犯带来了数十亿美元的报酬，并给企业和政府组织造成了巨大的损失和开支。

尽管存在许多类型的勒索软件，但这些攻击的一些行为是一致的。我们看到这些勒索软件攻击使用恶意软件识别、禁用或删除终端上的多个进程，运营人员可以使用这些进程来检测执行情况，甚至可以帮助在感染后恢复，作为妥协后的第一步。勒索软件攻击通常表现为系统事件日志被禁用和删除，以及卷影副本、恢复分区和任何系统备份在加密阶段发生之前被删除。然后发生的是所谓的加密阶段，即恶意软件通常指向特定文件系统目录的阶段。然后，勒索软件将查找某些文件类型并枚举系统，查找任何远程文件共享或其他共享资源的端点。然后，勒索软件将执行其加密功能，并通过后续通信和支付方式发送勒索信。

''RansomCloud'' 是指针对云中数据的特定类型的勒索软件攻击。随着许多企业将其运营转移到公共云和私有云中，这些数据的价值越来越高。

=== 防范勒索软件攻击 ===

防范勒索软件应从遵循最佳实践和开发成熟的安全能力开始。诸如建立安全基线、为易受攻击的软件打补丁和成熟的配置管理实践等基础能力对于预防至关重要。可观测性平台和经过良好测试的灾难恢复能力对于最小化影响和恢复时间至关重要。

将定期的安全评估、漏洞扫描和渗透测试作为正在进行的策略的一部分，对于主动预防勒索软件攻击至关重要。了解您当前的安全状况，例如适当控制以限制成功的社会工程攻击，并减轻可能被攻破的关键未修补漏洞，这对于避免勒索软件攻击的最坏影响至关重要。

当恶意软件达到加密阶段时，几乎无法阻止你的设备受到影响。为了避免勒索软件事件的发生，需要在 MITRE ATT&amp;CK 框架的早期阶段进行恶意软件检测。要实现这一点，仅依靠基于特征的检测能力和基于指标的威胁情报并不是一个完整的解决方案。企业将需要执行深度防御策略，包括对内部和云网络段以及任何外部相关流量的微观细分和行为分析。

开发安全的软件工厂和部署流水线可以通过控制部署的漏洞数量和强制代码/配置管理来减少攻击面，从而显著降低勒索软件的风险。软件工厂是实现代码扫描、图像扫描、代码审查和验证供应链起源的理想选择。

通过将配置更改视为必须通过安全软件工厂 (包括扫描和代码审查) 的代码，可以进一步降低风险。配置管理可以通过管道进行跟踪，并由外部可观测平台进行审计。

必须识别和跟踪异常情况，包括很少执行的管理操作。处于审计的目的，应该应对预期异常进行跟踪和标记。可观测平台应标记意外异常以进行额外审查。规则引擎和 AI/ML 可能会为可扩展性自动化一些异常检测，但自动化检测还不应该取代能够推理更复杂场景的人类。

部署必须遵循最小特权原则。这一原则对于减少被破坏部署的爆炸半径至关重要。经营人员应该将数据库与工作负载隔离开来，并允许最少的权限。最佳实践包括使用视图、预编译语句、在不需要的时候禁用更新/删除。应该维护备份并定期测试。对于更高级的保护，请启用底层存储和数据库的分类账功能，例如对象版本化。

保护数据加密密钥也至关重要。赎回的加密密钥和赎回的原始数据一样具有破坏性。具有敏感数据的生产系统应该将密钥存储在 KMS 或 HSM 中。云环境提供经过 FIPS 140-2 认证的高质量 KMS 服务。

最后，必须限制系统之间的通信路径。操作符有几种方式可以做到这一点。如果你实行零信任，你可以确保只有具有经过批准和有效加密身份的系统才能通过加密通道 (如相互 TLS) 进行通信。对于不知道加密身份的应用程序，建立加密隧道网络策略和配置下一代防火墙以抵御恶意攻击至关重要。

理想情况下，防止勒索软件攻击的措施会按预期发挥作用，使组织免于成为成功攻击的受害者。然而，这些措施需要时间来实施，虽然它们应该使一个组织更难妥协，更有能力从攻击中恢复，但它不是万无一失的，从来没有任何保证。

=== 勒索软件事件响应 ===

根据NIST 事件响应指南，管理勒索软件事件涉及以下步骤：

==== 准备 ====

制定事件响应计划，该计划已与您的团队进行了多次严格的桌面练习，以了解您的组织将如何应对潜在的勒索软件攻击。如果您的组织是网络攻击的受害者，这将包括与谁联系。如果适用，这将包括您的组织、运营商、Breach Coach、DFIR 公司和 MSP/MSSP 的紧急联系电话。您需要尽快激活团队，以开始生命周期的下一个阶段。

<span id="检测-分析"></span>
==== 检测 &amp; 分析 ====

在此阶段，您将需要快速有效地检测可疑/恶意代码，以遏制和根除它。在此过程中，您需要尽最大努力尽可能多地维护数字取证证据。通过这种方式，您可以调查事件以查找工件，这些工件将提供有关威胁参与者如何危害您的 IT 基础架构/云环境的关键信息。您还需要了解他们是否在整个环境中横向移动，以及威胁参与者访问了哪些数据。

在此阶段，如果您还没有端点检测和响应解决方案，您将需要尽快部署一个。这将为您提供对端点的可见性，以检测、隔离或终止任何可疑或恶意活动。通过这种方式，您可以开始遏制活动威胁。

<span id="遏制根除-恢复"></span>
==== 遏制，根除 &amp; 恢复 ====

遏制工作对于根除活跃威胁至关重要，这样您的团队就可以开始从网络攻击中恢复。遏制措施可以是在不关闭这些系统的情况下，从网络中断开已被确定为受到危害的端点。请记住，我们希望保留数字取证证据。

下一步是消除活跃威胁，并确认威胁参与者不再存在于环境中。这一点至关重要，因为众所周知，当威胁参与者意识到他们仍然控制着环境时，他们会挟持组织，并提出更高的要求。

一旦您确信您已经控制了活跃威胁，并且它似乎已从您的 IT/云环境中根除，您现在就可以开始恢复工作。下一点是应对勒索软件攻击的关键，可以为您节省数百万美元。拥有经过测试的备份程序并保护您的备份是至关重要的。建议您为所有关键系统和数据提供异地备份解决方案。

应对这些备份进行恶意软件扫描，并将其存储在安全位置。这些备份对于恢复业务连续性至关重要，并且可能不必与威胁参与者就您的数据进行付款谈判。

==== 事后复盘 ====

这里是团队在勒索软件攻击后进行汇报的地方，以了解事件中发生的成功和挑战。这是评估事件响应计划、管理和技术控制、灾难恢复计划、备份、端点、变更管理、外部和内部沟通计划的最佳时机。对经历勒索软件攻击的新见解将改变企业对其运营和日常活动的看法。这不应该是短期的，这种新的理解需要落实到现有的业务实践和安全计划中。

== 安全原则 ==

=== 安全默认值 ===

一个强大的安全系统在其默认状态下是可能的，具有成本效益和透明。构建或过渡到这样的系统需要在云原生环境中遵循以下指导方针：

# 将安全性作为设计要求
# 应用安全配置具有最好的用户体验
# 选择不安全的配置是一个有意识的决定
# 从不安全状态转换到安全状态是可能的
# 继承安全的默认值
# 例外列表具有一等支持
# 安全的默认值可以防止普遍的漏洞利用
# 系统的安全限制是可以解释的

有关这些指引的详情，请参阅此网页：[https://github.com/cncf/tag-security/blob/main/security-whitepaper/secure-defaults-cloud-native-8.md Secure Defaults: Cloud Native 8]。

=== 最小特权 ===

最小特权与云原生架构同样重要，或者可能是最重要的方面，必须在做出身份验证或授权决策的堆栈的所有部分考虑。传统上，最小特权是在帐户层考虑的，无论帐户是人还是服务。

在云原生中，最小特权必须应用于堆栈的每一层。在评估负责实现每个层执行的特定工具时，还应该考虑它。在探索各种产品和功能时，组织可能会发现许多容器具有特权——默认部署或需要 root 权限才能操作。因此，可能需要采取额外的措施，将提升的特权与其他工作隔离开来。组织应该考虑在其工作负载和部署中采用隔离和最小特权的所有领域;从运行时环境中的 cgroups 和系统调用到工件管理和无根构建。

为了持续减少潜在的攻击面和相应的爆炸半径，组织需要在其架构的每一层实施最小特权原则。这不仅适用于在其角色中执行各种功能的个人，而且也适用于在给定环境中执行的服务和工作负载。无根服务和容器对于确保攻击者在进入组织环境时，不能轻易地在其访问的容器和底层主机或其他主机上的容器之间遍历至关重要。

强制访问控制 (MAC) 实现 (例如 SELinux 和 AppArmor) 可以限制容器或命名空间之外的权限。此外，它们还提供主机级别的容器隔离，以防止容器断裂或从一个容器转向另一个容器，从而将权限提升到访问控制所允许的权限之外。

=== 角色和职责 ===

在迁移到云原生架构和部署时，组织应期望看到传统安全角色和职责的调整，并创建特定于云的新安全角色。随着现代开发方法的快速发展以及 IT 活动与业务需求的更好结合，安全性必须是自适应的，与实际风险相称地应用，并且是透明的。期望开发人员和运营人员成为安全专家是不合理的。安全从业人员需要与开发人员、运营人员和其他项目生命周期要素合作，以使安全性和法规遵从性实施与流程现代化工作和开发生命周期完全集成。这样做意味着通过开发人员用于习惯性解决的工具来实时报告发现，类似于如何在通知时解决构建失败。

在云原生环境中管理安全时，DevOps 环境中经常出现的模糊界限不应取代明确的职责分离（SOD）。虽然开发人员将更多地参与实施和执行安全措施，但他们不制定策略，不需要了解其角色不需要的领域，等等。这种分离应根据组织的风险承受能力和业务实践在角色之间以及产品和应用程序团队之间实施。可以理解的是，对于较小的组织，当个人履行许多职责以保持业务蓬勃发展时，这就变得很困难。然而，随着组织的不断发展，对权限调整实施不同的角色可以帮助执行 SOD，并在认知上迫使个人在正在执行的活动中进行心理转换。最终，允许将重组角色重新分配给新的个人，而不会增加新分配的访问范围。

随着产品和服务迁移到云，组织将需要重新评估其资产风险。随着正在使用的技术及其部署堆栈的所有权和管理发生变化，管理人员应该预料到风险状况会发生重大变化。供应商和团队之间的共同责任将需要改变风险接受、转移和新的缓解机制的阈值。

=== 供应链安全 ===

系统的安全性取决于其所依赖的供应链。保护供应链需要确保软件和硬件的设计、实施、分发、配置、存储和验证。

有效的供应链战略依赖于成熟的政策和程序，以降低与第一和第三方软件创建者、集成商和分销商相关的风险。各方必须准确有效地传达相关信息。供应链政策应包含不同的供应商，其控制措施旨在限制受损供应链的危害。它为系统、软件和配置的起源提供了追踪来源和验证工件及其生产链的完整性的能力。

软件供应链由源代码、第二或第三方代码、构建管道、工件和部署组成。这些阶段中的每一个阶段都必须由经过认证的可信方执行，以便在可能的情况下进行加密验证和自动化。所有受信任的实体都应具有有限的授权范围，以减少危害的影响。

软件物料清单（SBOM）是发现您所拥有的软件组件的关键第一步，因此您可以将它们与已知漏洞相关联。SBOM 应使用标准化格式（例如但不限于 SPDX、Cyclone DX、SWID）在构建时从源代码生成，并应链接到导入的库和工具的 SBOM。SBOM 中包含的源代码和组件元数据也可由开发人员和操作人员用于识别软件供应链的篡改。CI/CD 系统应使用 SBOM 中复制的签名对应用程序和容器图像进行签名。操作员可以使用来自二进制文件或映像的构建后 SBOM 生成器来验证构建时 SBOM 的准确性。端到端证明可用于验证软件创建者和供应商所使用的流程。这些证明应该添加到软件供应链的每个步骤中。

在某些情况下，识别受 CVE 影响的软件并实施修复可能具有挑战性，因为 SBOM 可能包含数千个依赖项，并且无法识别它们是否具有 CVE（超出 SBOM 的范围）。在这些类型的情况下，在构建过程中生成增量报告并将其与相应的 SBOM 一起存储，可以帮助组织更快地识别实际的易受攻击的软件（及其版本），并减少工作量或潜在错误。增量报告的另一个好处是，它们还可以帮助准确识别无漏洞但受影响的（相关）软件。

安全的CI/CD系统应生成SBOM和证明。证明应包括CI步骤的过程、环境、材料和产品。在可能的情况下，应对证据进行加密验证。软件生产商应使用可信文档（如已签名的元数据文档和已签名的有效载荷）来验证构建环境的真实性和完整性。

在此过程中，跟踪 CI/CD 供应链的依赖性同样重要。供应商应提供对其组件和依赖项进行评估和审查的证据。供应商应及时提供漏洞通知，无论他们是否受到这些漏洞或违规的影响。即将推出的标准（如 VEX）将为交换有关漏洞的信息提供一个通用框架。

运营人员和安全团队应将上述所有信息存储在可查询的库存系统中，以快速发现易受攻击或不合规的系统。

成熟和自动化的 SBOM、CVE 和 VEX 程序可为其他安全和合规控制提供相关信息。例如，基础设施可能会自动向可观察平台报告不符合要求的系统，或拒绝提供必要的加密工作负载身份，从而在零信任环境中有效地将其与符合要求的系统隔离开来。

CNCF 制作了[https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf 软件供应链最佳实践白皮书]，以帮助您设计安全的供应链流程。本白皮书提供了有关保护软件供应链的更多详细信息，并讨论了开发人员和运营商可用于保护供应链各个阶段的相关 CNCF 项目。

<span id="gitops"></span>
=== GitOps ===

GitOps 是一个基于代码的基础设施和操作程序，它依赖于 Git 作为源代码控制系统。它是基础架构即代码（IAC）和 DevOps 最佳实践的演变，利用 Git 作为创建、更新和删除 IT 系统架构的唯一事实来源和集中控制管理。GitOps 允许将部署从开发中分离出来，并充分利用其不可变的声明性基础设施。环境的每个元素都可以根据需要随时部署，结果相同，并且实例可以重新部署，而不是从多个独特的配置和版本中恢复。

传统流程主要依赖于人工操作知识、专业技能和手动执行的操作，但在 GitOps 的情况下，所有更改都是在与 Git 存储库交互时进行的。因此，Git 存储库和 GitOps 进程对于安全性至关重要，并且应该通过设计来确保安全。基础设施的不变性可以防止在主部署过程之外进行更改，并使基于 Git 存储库中的声明性状态检测和反转环境更改变得更加容易。

IAC 和 GITOPS 的使用通过限制手动操作、提供对所有更改的审核、声明性的单一事实来源、通过必要的控制和流程门执行策略来确保满足安全要求，从而提高了基础架构本身的整体安全性。使用 GitOps 工具和技术，组织可以缓解不同的攻击载体，即通过减少访问目标系统的人员和机器的数量。

GitOps 流程负责向生产环境提供更改，如果该流程受到危害，则对手可能会打开基础架构后门或将有害软件引入生产环境。根据最小特权原则和职责分离，应遵循的一些值得注意的准则是：

* 限制对存储库和分支的访问
* 切勿将未加密的凭据或机密存储在 Git 存储库中，并阻止将敏感数据推送到 Git
* 通过 GPG 签名的提交强制执行强身份，以提供可问责性和可追溯性
* 要求线性历史记录，并通过禁止强制推送来维护提交历史记录
* 强制执行分支策略。特别是保护主要分支，并要求在合并前进行代码审查
* 监控漏洞，并使 Git 和 GitOps 工具保持最新
* 轮换 SSH 密钥和个人访问令牌，阻止对 Git 存储库的未经授权的访问
* 利用专用的非用户技术帐户进行访问，其中凭据经常轮换且寿命很短
* 限制可以提升权限以删除安全功能的用户，以通过删除审计跟踪和屏蔽警报来掩盖其踪迹

总之，GitOps 可以在需要时通过质量和安全策略门在任何代码部署到生产环境之前消除漏洞。

=== 零信任架构 ===

零信任体系结构通过细粒度分割、微边界以及使用验证和执行策略消除对数据、资产、应用程序和服务（Daas）的隐式信任来缓解网络内横向移动的威胁。

零信任体系结构的大多数常见实现都依赖于加密概念来创建零信任。这主要是基于在硬件或令牌中保护特定密钥材料的能力，并以一种可以安全地将其传输到平台的方式进行管理。

零信任体系结构的基本构建模块通常由几个方面组成：

* 每个实体可以创建身份的证明
* 实体可以独立验证其他身份（即公钥基础设施）
* 实体之间的通信保持保密和不被篡改

零信任框架通过以下方式创建零信任构建模块利用强大的信任根：将防篡改信任绑定到实体或流程的能力是基础构建块。然后，它需要证明：证明、验证和证明实体身份的能力。对于容器服务的例子，我如何检查这个容器是它声称的那个人。这需要与 Orchestrator 进行验证，但要信任 Orchestrator，我们需要确保其运行未被篡改，这只有在我们运行受信任的操作系统、BIOS 等时才能确保。证明通常也是一个链。

零信任也需要实体之间的安全通信。虽然网络分段为零信任体系结构提供了价值，并应予以考虑，但它并不是零信任实施的最终解决方案。Orchestrator 网络策略以及服务网格的使用都是全面的零信任解决方案的组成部分。有关零信任概念的更多信息可在网上广泛获得。

== 安全栈 ==

在云原生安全地图中深入探讨了跨四个生命周期阶段的这些安全保证的实现，可以在以下位置找到： https://cnsmap.netlify.app 。
通过这些工具跨堆栈实现安全性的一个副作用是，它们有助于满足云原生环境的合规需求。