查看“云原生运行时环境安全”的源代码


<div class="figure">

[[文件:Cnswp-v2-security-structural-model-runtime.png|900px]]

</div>


运行时（Runtime）阶段包括三个关键领域：计算、访问和存储。虽然运行时环境取决于开发、分发和部署阶段的成功完成，但运行时的安全性取决于前几个阶段的安全实践的效力。以下段落详细介绍了每个关键组件的安全要求和影响。

== 计算 ==

云原生计算具有高度复杂性和不断发展的特点。如果没有核心组件来实现计算利用，组织就无法确保工作负载的安全性。

考虑到容器为共享主机上的多租户应用程序提供基于软件的虚拟化，因此使用容器特定操作系统非常重要。这是一个只读操作系统，其他服务已被禁用。这有助于减少攻击面，并提供隔离和资源限制，使开发人员能够在共享主机内运行隔离的应用程序。为了实现防御深度，建议不要让不同的数据敏感工作负载运行在同一个操作系统内核上。

为了让安全覆盖容器平台和服务的所有层面，可以使用基于可信平台模块（TPM）或虚拟 TPM 的硬件信任链。基于硬件的信任链可以扩展到操作系统内核及其组件，以实现对受信启动、系统镜像、容器运行时和容器镜像等的加密验证。

安全隔离区（也称为可信执行环境或 TEE）是机密计算的核心。安全隔离区是内置于新型 CPU 中的一组安全相关指令代码。它们保护数据在使用时的安全性，因为隔离区仅在 CPU 内部动态解密，并且仅为运行在隔离区内部的代码和数据服务。基于 TEE 的机密计算确保数据安全性、完整性和机密性。隔离区中的加密数据和代码对其他应用程序、BIOS、操作系统、内核、管理员、云供应商和硬件组件不可用，除了 CPU。基于 TEE 的机密计算与沙箱容器协同工作，以隔离恶意应用程序并保护敏感数据。

操作系统提供基本的系统组件，例如用于远程连接的加密库和用于进程启动、管理等的内核函数。它们可能存在漏洞，因为它们为容器提供了基础计算基线，因此可能会影响运行在这些主机上的所有容器和应用程序。同时，配置不当的容器可能会影响主机内核安全性，从而影响在该主机上运行的所有服务。

== 编排 ==

任何一个编排系统都有多个组件，这些组件被分为控制平面和数据平面。有时需要具有更高层次的多部署管理平面，负责在相互独立的几个控制平面之间维护状态。

任何编排系统都会受到一些攻击，这些攻击会影响部署的整体安全性和运行时的持续安全性。恶意访问编排系统的 API、未经授权访问和更改 key-value 存储、通过仪表板控制集群、拦截控制平面数据、滥用 API、拦截应用程序数据等都是潜在的威胁领域。对于任何编排系统来说，采用最佳实践和配置强化是很重要的方法来防止其成为被攻击的目标。同样重要的是监控和检测在运行时对初始配置的任何更改，以确保集群的持续安全运行。其他安全最佳实践，如尽量减少对控制平面的管理访问、职责分离和最低特权等原则，都应该确保贯彻实施。

=== 安全策略 ===

必须考虑你的编排系统的安全特性和各种配置选项，以控制容器运行时可以用来建立容器的安全权限。使用更高层次的策略和监管可以强制执行这些安全防护措施。

=== 资源请求和限制 ===

通过 cgroups 对不同的对象和资源请求进行限制，这有助于防止有意（如 fork 炸弹攻击或加密货币挖矿）或无意（如在内存中读取大文件而不进行输入验证，水平自动缩放以耗尽计算资源）的导致节点和集群的资源被不当的工作负载耗尽。

=== 审计日志分析 ===

审计日志分析是识别和关联系统被攻击、滥用或配置错误的最成熟方法之一。持续自动化审计日志分析和关联对于安全团队非常重要，因为云原生架构能够为工作负载生成比传统遗留系统更细粒度的审计配置和过滤。此外，云原生日志的互操作性允许进行高级过滤，以防止下游处理的负荷过载。在这里，与传统日志分析一样，关键是生成可操作的审计事件，将日志中的数据相关/上下文化成能够驱动决策树/事件响应的“信息”。

非合规违规行为是基于一组预先配置的规则进行检测的，这些规则过滤组织策略的违规行为。要能够审计使用集群的实体的操作，启用 API 审计并过滤一组特定的 API 组或动词对于安全团队或集群管理员是非常重要的。将日志立即转发到无法通过集群级凭据访问的位置也能够防止攻击者通过禁用日志或删除其活动日志来掩盖其踪迹。这些处理警报的系统应定期进行误报调整，以避免警报泛滥、疲劳和在系统未检测到的安全事件之后发生虚报阴性。

=== 控制平面认证和根证书 ===

系统管理员应配置所有控制平面组件之间的通信使用相互认证和证书验证。安全证书也需要定期轮换以强化系统安全。安全证书颁发机构 CA 可以是默认的编排系统 CA，也可以是外部 CA。使用外部 CA 可能涉及到维护证书颁发机构基础设施的大量工作，因此应谨慎选择此选项。管理员应特别注意保护 CA 的私钥。有关扩展或建立信任的更多信息，请参考本文的鉴权和访问管理部分。

<span id="凭证如密钥加密"></span>
=== 凭证（如密钥）加密 ===

在容器编排或部署时可以使用外部密钥管理系统来管理密钥，也可以直接使用编排系统本地的密钥。当使用本地密钥时，关键是要知道有几种不同的保护方法。

# 使用外部密钥管理存储 (KMS) 加密
#* 利用 KMS 是保护编排系统数据秘密一种安全方式，外部的 KMS 将对数据加密密钥（DEK）进行加密，然后使用 DEK 对保存在 etcd 中的数据进行加密。这种方法还可以将 DEK 缓存在内存中，以减少对外部 KMS 的依赖，并可在创建 pod 时加快解密速度。
# 编排系统加密管理
#* 由编排系统用数据加密密钥来加密秘密，同时加密密钥也由编排系统管理（如采用配置文件）。
# 不加密
#* 有些编排系统采用 base64 编码，默认情况下，数据实际以明文保存在 key-value 存储中。

使用外部密钥管理系统可以降低使用明文的风险，并降低密钥管理的复杂性。大多数情况下，这些工具都是作为 controller,driver 或 operator 使用，可以在运行时注入密钥，并定期自动轮换而无需人工干预。

=== 运行时 ===

容器的运行时环境需要从进程、文件和网络的角度被监控和保护。在容器中，只有那些得到许可的功能或系统调用（如 seccomp 过滤器）才能被允许执行或被宿主机操作系统调用。容器运行时应该监控和防止对关键挂载点和文件的改变，且对它的配置必须能够防止更改二进制文件、证书和远程访问配置。这种配置还必须限制容器只能进行为完成操作所必须的入口和出口网络访问。此外，那些访问恶意域名的网络流量应该被检测并阻止。

相反，完整的工作负载或在运行时处理隐私敏感数据的部分工作负载可以在受信任的执行环境中执行。这可以实现保密计算并保护工作负载数据免受外部威胁。

=== 微服务和消除隐性信任 ===

作为微服务部署的容器化应用程序的边界是微服务本身，因此，有必要设定策略，只允许在得到许可的微服务间进行通信。在微服务架构中引入零信任，可以在一个微服务被攻陷时阻止其横向移动，从而缩小影响范围。运维人员应确保他们正在用网络策略等功能，确保一个容器部署内的东西向网络通信只限于授权网络。在 NIST SP 800-204 中初步提供了一些用于微服务的策略，这些之后可能会成为实现安全微服务架构的指南。

=== 对镜像的信任和内容保护 ===

组织可以使用策略代理来强制或控制经过认证和签名的容器镜像，从而能够为运维工作提供映像出处的保证。除此之外，引入加密容器可以保护容器内的敏感源码、方法或数据。

=== 服务网格 ===

服务网格提供服务之间的连通性，并增加了流量控制、服务发现、负载均衡、弹性、可观测性、安全等额外功能。服务网格可以让微服务把这些功能从应用层软件库中剥离，让开发者专注于差异化的业务逻辑。为了有效地确保云原生环境中服务之间的安全通信，组织应该部署服务网格来消除其工作负载内部和不同工作负载之间的隐性信任，这些可以通过数据传输时加密来实现。使用服务网格也可以解决身份问题，传统的静态身份（如 IP 地址）不再与工作负载清晰地对应。服务网格不仅提供服务层的隔离和安全，还提供网络层的弹性功能，例如重试、超时和实施各种断路器功能。流媒体平台可以通过使用工作负载层的授权来设置主题或代理的访问规则来提高安全性，从而从服务网格中获益。

值得注意的是，部署服务网格有助于缩小云原生部署的攻击面，并为构建零信任应用网络提供关键框架。

=== 运行时检测 ===

监控已部署的工作负载能够帮助团队验证当前真实的运行状态达到了预期状态。组织不能放弃在环境中进行定期的安全扫描和监控，否则就会使他们的工作负载变成攻击者不受限制的游乐场。应利用那些可以检测、跟踪、汇总和报告来自容器的系统调用和网络流量的工具，来发现非预期或恶意行为。

虽然回归测试和安全测试可以帮助防止已知的、预期的问题转移到生产环境中，但它们不能阻止所有问题。我们应该对工作负载进行动态扫描，以检测尚未发生过的恶意行为或非预期行为。在工作负载运行了 X 天之后，延长休眠命令将数据存储中的数据外泄之类的事件，在大多数环境中是不被考虑到的，因此不会包括在安全测试中。对于工作负载中可能存在时间或事件延迟木马的问题，只有通过与基线预期行为进行比较才能检测到，这通常是在彻底的活动监控和扫描中发现的。

此外，工作负载在部署时或之后可能会变得容易受攻击。组织应持续扫描其环境，以检测哪些工作负载现在容易受攻击。了解每个工作负载的组成或材料清单可以帮助组织快速识别漏洞所在。有关这些漏洞的其他信息，如漏洞成熟度和漏洞利用路径，对于确定工作负载的实际风险至关重要，并可帮助组织优先更新有风险的应用程序。

=== 函数 ===

无服务函数容易受到各种攻击，因此需要适当保护。进程必须只执行在允许列表中明确定义的函数。此外，不应允许函数对关键的文件系统挂载点进行修改。

这些函数必须被限制只能访问被认可的服务，这种限制可以通过网络限制或权限模型中的最低权限来实现。此外，出站网络连接必须由管理员监控，以便检测并在可能的情况下阻止其访问 C&amp;C（指令和控制）和其他恶意网络域。还必须考虑监控入站网络，以便检测和删除可能用于数据外泄的恶意负载和命令。例如，可以通过网络监控来检测 SQL 注入攻击。

无服务函数中存在一些安全威胁，但可供租户使用的控制措施是有限的。这些问题包括无效身份认证和与依赖服务之间不安全的 API 集成等。有一些措施有助于解决这类问题，如确保所有无服务函数在基于租户的资源隔离环境中或相似的数据类型的性能隔离环境中运行。然而，由于隔离环境中可用的地址空间有限，这些措施会对性能造成影响。

=== 启动引导 ===

信任需要被引导入计算节点中，以确保工作负载和配置运行在正确的节点上。启动引导确保计算节点处于正确的物理和逻辑位置，并能够进行自我认证。这些步骤通常是云服务提供商服务开通的一部分。但是也有一些方法可以在减少对第三方的依赖情况下进行信任验证。

== 存储 ==

云原生存储涵盖了一系列广泛的技术，可分为提供类存储和访问类存储两类。提供类存储是提供给工作负载使用的存储，例如卷（volumes），包括块存储、文件系统和共享文件系统。访问类存储是通过应用程序接口访问的存储，包括对象存储、键值存储和数据库。

存储系统包含一个数据访问接口，定义了应用程序或工作负载如何存储或使用由存储系统或服务持久化的数据。该接口可以通过访问控制、身份验证、授权以及可能的传输加密来进行保护。

存储系统还包含一个控制面板/管理接口，通常是受身份验证和TLS保护的API，尽管可能提供更精细的访问控制，通常情况下，控制接口仅由编排器或服务代理通过服务账户进行访问。

=== 存储栈 ===

任何存储解决方案都由多个功能层组成，这些功能层定义了数据的存储、检索、保护和与应用程序、编排器或操作系统的交互方式。每个层都有可能影响存储系统的安全性。一个常见的例子是将文件或块持久化到对象存储的文件系统。不仅仅需要保护访问数据的顶层，保护拓扑结构中的每一层同样重要。

<span id="编排-1"></span>
==== 编排 ====

大多数编排系统将实现多种抽象和虚拟化层，其中可能包括文件系统（例如绑定挂载）、卷管理器，并根据编排器策略在用户或组级别应用权限。与容器化和微服务架构的许多组件一样，保护卷和存储始终依赖于集群中其他功能的保护措施。如果用户能够在编排器或容器运行时中提升其特权至 root 级别，他们可能会对环境以及底层存储系统造成严重破坏。在成功保护云原生架构中的存储方面，实施零信任、最小特权、访问控制并强制执行是关键。

==== 系统拓扑和数据保护 ====

理解系统的存储拓扑对于确保数据访问路径和分布式拓扑中的节点内通信的安全至关重要。

常见的拓扑模型包括集中式模型，其中所有计算节点都访问一个中央存储服务；分布式模型，将功能分布在多个节点上；以及超融合模型，将应用程序和存储工作负载合并在同一节点上。根据系统使用的拓扑结构，选择特定的分层安全机制来保护存储中的数据以及存储位置之间的传输数据。

任何存储系统的关键功能之一是对持久化在系统或服务中的数据进行保护。首先，这种保护通过确保数据对授权用户的可用性来实现，并且应作为系统中的透明层存在。这可能包括奇偶校验或镜像、纠删码或副本等技术。其次，保护数据的完整性，存储系统会对块、对象或文件添加哈希和校验和。哈希主要用于检测和恢复损坏的数据，同时也可以提供一层保护，防止数据篡改的发生。

==== 缓存 ====

缓存层，通常是完全独立的系统，被实施用来提升存储系统（尤其是文件系统、对象和数据库）的性能。对于缓存层，需要应用适当的访问控制和安全策略，因为缓存将作为实际存储后端的访问前端。

==== 数据服务 ====

存储系统通常实现多个数据服务 (Data Services)，这些服务在核心存储功能的基础上提供额外的功能，可以在不同的层次上实现，包括复制和快照 (数据的时间点副本)。这些服务通常用于将数据副本移动到远程位置，因此需要确保在远程位置应用相同的访问控制和安全策略来保护数据。

==== 物理层或非易失性层 ====

云原生存储安全性不仅限于虚拟云原生架构，因为云原生能力可以在本地部署，甚至虚拟化解决方案也具有物理存在。重要的是要记住，存储系统最终会将数据保存在某种形式的物理存储介质上，通常是非易失性存储。现代物理存储介质（如固态硬盘）通常支持安全功能，如自加密，遵循OPAL标准，并提供快速和安全的擦除功能。安全擦除在包含数据的设备需要离开安全的物理位置时非常重要，例如设备出现故障需要退还给供应商。

=== 存储加密 ===

存储系统可以通过数据加密提供数据的机密性保护。数据加密可以应用于数据传输过程中的数据或静态存储的数据，在实施时存储系统可以确保独立于应用程序进行加密。加密功能通常依赖于与密钥管理系统的集成。

加密会对性能产生影响，因为它涉及计算开销，但许多系统提供了加速选项，可以减少开销。在选择数据加密类型时，需要考虑数据路径、大小和访问频率，以及法规、合规性或其他需要使用更安全加密算法的附加安全保护措施。此外，在考虑体系结构的加密要求时，团队不应忽视缓存的使用。

加密服务可用于数据传输过程中的数据（保护数据在网络中传输时）和静态存储的数据（保护数据在磁盘上）。加密可以在存储客户端或存储服务器中实现，加密的粒度会因系统而异（例如，按卷、按组或全局密钥）。在许多系统中，传输过程中的数据会使用 TLS 进行保护通过证书提供身份验证层。较旧的协议（如 iSCSI）在传输过程中可能较难进行安全保护（虽然可以使用更复杂的解决方案，如 IPsec 或加密 VPN）。静态存储的数据通常使用标准对称加密算法（如 AES）进行保护，并且可以使用特定的加密模式（例如，面向块设备的 XTS 模式）进行部署。

包括块存储、共享文件系统和对象存储在内的公共云存储可能原生支持使用 CMK 和 BYOK 进行数据加密。

=== 持久卷保护 ===

保护对卷的访问是确保只有经授权的容器和工作负载能够使用提供的卷的关键。定义命名空间的信任边界，以限制对卷的访问至关重要。利用现有的或创建新的安全策略，防止一组容器在工作节点上访问卷挂载点，并确保只有适当的工作节点能够访问卷。这一点尤其重要，因为特权容器可以在不同命名空间中访问已挂载的卷，因此需要采取额外的预防措施。

指定卷的 UID 或 GID 仍然允许同一命名空间中的容器访问该卷，并不能提供数据保护。V3 版本的网络文件系统（NFSv3）假设客户端已经执行了身份验证和授权，并不进行验证。在实施保护措施时，需要考虑身份验证和授权发生的位置以及是否存在对该操作的验证。

<span id="组件注册表仓库"></span>
=== 组件注册表（仓库） ===

注册表应该适应用于签名和验证 OCI（Open Container Initiative）制品的技术。同时，确保缓存和分发工具提供签名、加密和校验和的功能，以确保缓存层能够检测到篡改或试图破坏数据集的行为。

可以通过访问CNCF 存储白皮书获取有关云原生存储的概念、术语、使用模式和技术类别的额外背景信息。

== 访问 ==

<span id="身份和访问管理iam"></span>
=== 身份和访问管理（IAM） ===

云原生架构中，一个全面的身份和访问管理 (IAM) 解决方案至少需要服务身份。维护或操作本地或混合云的组织需要用户和设备身份管理。对于分布在多云环境中的应用程序和工作负载，身份联合对于成功实现至关重要。

应用程序和工作负载应使用相互认证明确授权彼此通信。由于云计算的短暂特性，密钥的轮换和生命周期需要频繁且短暂，以维护高速能力的要求，并在凭据泄露时控制和限制影响范围。

从云提供商获取身份管理服务的利用，取决于特定于行业的用例。用户应该为敏感工作负载（如健康或财务信息）生成和管理凭据和密钥，与云提供商无关。

为了使客户端和服务器通过密码学双向验证身份，所有工作负载必须利用相互/双向传输身份验证。身份验证和授权必须在环境内部和跨环境独立确定（决策点）并执行（执行点）。理想情况下，所有工作负载的安全操作都应在实时中得到确认，并在可能的情况下验证更新的访问控制和文件权限，因为缓存可能允许未经授权的访问（如果访问被撤销并且从未得到验证）。工作负载的授权是基于其被分配的属性和角色/权限授予的。强烈建议组织在所有环境中和整个工作负载生命周期中使用基于属性的访问控制（ABAC）和基于角色的访问控制（RBAC），以提供粒度授权强制执行。这种姿态可以实现深度防御，在此姿态下，所有工作负载都能接受、消费和转发终端用户的身份，以获得上下文或动态授权。这可以通过使用身份文件和令牌来实现。如果未强制执行此限制，组织将无法真正执行系统对系统和服务对服务调用的最小特权访问控制。

需要注意的是，应用程序或服务身份在微服务的背景下也是至关重要的，因为应用程序的身份很可能会受到恶意服务的欺骗和冒充。使用强大的身份框架和服务网格可以帮助解决这些问题。

所有的人类和非人类的群集和工作负载操作者都必须进行身份验证，并且他们的所有操作都必须根据访问控制策略进行评估，这些策略将评估每个请求的上下文，目的和输出。为了简化身份验证过程，可以配置身份联合以允许使用企业能力，如 MFA 多因素身份验证。然后必须使用本节提到的访问控制机制强制执行授权。

=== 凭据管理 ===

<span id="硬件安全模块-hsm"></span>
==== 硬件安全模块 (HSM) ====

凭证管理解决方案赋予组织有效管理访问数字和物理资源的硬件和软件凭证的能力。部署安全的凭证管理系统是确保系统和信息安全的关键步骤。

==== 凭据管理周期 ====

加密密钥应该在 HSM（Hardware Security Module）或基于软件的密钥管理系统中安全地生成。

密钥（Secrets）应尽可能具有较短的过期时间或生命周期，超过该时间后密钥将失效。密钥管理应具备高可用性和高易用性，这些特征是短期密钥的先决条件。如果组织不得不使用长期密钥，应建立适当的流程和指导，定期进行密钥轮换或撤销，特别是当出现意外泄露密钥的时候。所有密钥在传输过程中必须通过安全的通信渠道进行分发，并应根据所保护的访问级别或数据的重要性相应地进行保护。

无论如何，密钥（Secrets）应该通过非持久性机制在工作负载的运行时注入，以免通过日志、审计或系统转储泄露。这意味着可以使用非持久性的机制，如内存中的共享卷，来存储密钥，而不是使用环境变量。这样可以确保密钥不会在日志、审计或系统转储中被泄露出去。

== 可用性 ==

<span id="拒绝服务dos和分布式拒绝服务ddos"></span>
=== 拒绝服务（DoS）和分布式拒绝服务（DDoS） ===

云原生应用中的拒绝服务攻击（DoS 攻击）是一类网络攻击。攻击者试图通过暂时或长时间让云原生应用对其原本正常用户不可用，包括人类用户和自动化系统。攻击者可能通过干扰关键的云原生应用组件（如微服务），干扰负责保持微服务运行的编排层，或干扰负责应用扩展的健康监控系统来实施攻击。拒绝服务通常是通过向关键微服务或资源发送大量无用请求，以超载系统并阻止部分或全部合法请求得到满足。分布式拒绝服务攻击（DDoS 攻击）通常涉及大量的流量涌入云原生应用服务或其所依赖的上游网络。攻击通常来自多个源头。在攻击达到云原生应用之前，可以通过检测和遏制这些攻击来减轻其影响。

为了应对拒绝服务攻击和分布式拒绝服务攻击，通常需要采取多种防御措施。这包括使用网络防火墙、入侵检测系统、负载均衡器等技术来识别和阻止恶意流量，以及实施合适的访问控制策略和限制资源使用。此外，定期进行安全审计和漏洞修复也是重要的措施，以确保云原生应用的安全和可用性。