容器和 Kubernetes 合规性考量

如果您正在运行容器，那么您肯定对潜在的安全风险有所考虑。当然，您可能只是在工作流中采用 DevOps 方法，或者是已拥有完善的 CI/CD 管道，但您还想保护自己的敏感数据。

基于角色的访问权限控制（RBAC）提供了用于管理 Kubernetes API 端点授权的标准方法。Kubernetes 集群的 RBAC 配置控制着哪些主体可以在哪些命名空间中的哪些资源类型上执行哪些动作，但 RBAC 并没有规定您应该如何配置自己的角色。这就是合规性框架的用武之地。

对于许多行业而言，满足合规性要求是开展业务的必要组成部分。虽然在开始时合规性问题可能会成为构建和运行容器化、云原生应用的障碍，但框架和相关技术正在迅猛发展，以力求在云原生环境中实现全面的合规性。与容器化应用相关的主要合规性框架包括：

• Kubernetes 和 Docker 的 CIS 基准
• NIST SP 800-190
• PCI
• HIPAA

合规性最终是为了确保您的应用是安全的。但是，由于它们还要求组织能够向第三方证明应用是持续安全的，因此满足合规性要求可能比简单地保护应用更具挑战性。此外，它还涉及跟踪和保存相关的记录，以证明其持续合规性。

合规性可能会给您带来一定的挑战，但未能满足合规性标准的代价可能更高——与合规性违规相关的罚款，其平均成本几乎是满足合规性要求时的三倍。

合规性标准也可以成为组织制定安全治理策略的一个重要组成部分。无需从头开始创建相关准则，组织（即使是那些不需要满足特定框架准则的组织）可以将合规性框架作为制定自己内部政策的起点。

框架

CIS 基准：由互联网安全中心制定的 CIS 基准可提供容器的最佳实践，尤其是那些使用 Docker 运行时和 Kubernetes 的容器，但它们却不对任何行业形成约束。

NIST 800-190：美国国家标准与技术研究院的容器安全性框架是美国国家标准与技术研究院发布的众多网络安全合规性框架之一。所有美国联邦政府机构和政府承包商都必须满足 NIST 800-190 的要求。

PCI：支付卡行业（PCI）框架由五家主要信用卡公司合作开发，其范围涵盖了存储、处理或传输支付信息的相关组织。

HIPAA：HIPAA 法案的技术保护措施涉及到组织如何收集、处理或传输个人可识别的受保护电子健康信息。

美国国家标准与技术研究院特别出版物 800-190（NIST 800-190）提供了一个框架，用于了解与保护容器化应用相关的一些特定挑战，以及组织需要采取哪些措施来改进应用的安全配置文件。

NIST 准则针对的是美国政府机构以及政府承包商，但任何公司都可能希望遵循 NIST 800-190 准则，这既是为了提高整体安全性，也是因为这样可以更容易满足其他合规性框架，如 PCI 和 HIPAA。

风险

NIST 800-190 强调的是容器化应用中安全漏洞的常见来源，其中包括：

• 受损害的镜像
• 容器镜像中的错误配置
• 不可信的容器镜像
• 管理不善的秘密
• 错误配置的访问权限控制
• 操作系统漏洞
• 不必要的大攻击面

同样重要的是，NIST 800-190 还强调了组织需要以不同于传统应用的方式来处理容器化应用的安全性。容器化应用具有与虚拟机不同的风险因素，因此需要一整套不同的安全防护实践。

NIST 800-190 要求组织做到：

• 使用专用工具在整个镜像生命周期内（从构建到部署再到运行时）管理镜像漏洞。
• 确保镜像符合配置最佳实践。
• 通过将秘密存储在镜像之外并使用 Kubernetes 管理秘密，以此来保护秘密；将对秘密的访问限制在那些需要它们的容器中；对静态和传输中的秘密进行加密。
• 从注册表中推送和提取镜像时使用安全连接。
• 确保容器始终使用最新的镜像版本。
• 对网络流量进行分段，至少将敏感网络与非敏感网络隔离开来。
• 使用 Kubernetes 安全地引入节点并保留节点及其连接状态的清单。
• 控制来自容器的出站流量。
• 确保针对容器运行时配置标准（例如 CIS 基准）的持续合规性。
• 使用安全控制来检测容器和基础架构级别的威胁和潜在入侵。
• 使用强化的、特定于容器的操作系统，且攻击面要尽可能小。
• 通过确保容器具有尽可能少的权限，以防主机文件系统被篡改，从而令功能符合设计意图。

即便是那些不需要遵守 NIST 800-190 要求的组织，也应将其视为一个改善组织安全状况的有用框架。它们可以确保组织在整个构建、部署和运行时阶段都充分考虑到安全性问题，从而解决每个阶段的独特安全要求。

支付卡行业数据安全标准（PCI DSS）由 Visa、万事达卡、美国运通、Discover 和 JCP 于 2004 年制定，旨在为安全和数据保护建立一套全行业标准。为了跟上技术变革的步伐，这些标准自首次发布以来已进行了多次更新。这些标准适用于持卡人数据环境中的所有相关对象，即存储、处理或传输持卡人数据的人员、流程和技术。在技术方面，它同时涵盖了硬件和软件。

符合 PCI 要求并不容易，公司每年平均要花费 550 万美元。但是，违规的代价要高得多，平均每年要承担 1,480 万美元的罚款。借助正确的流程和工具，PCI 合规性就不会成为一项重大挑战。

PCI DSS 有 12 项要求，分别对应 6 个更普遍的目标。具体包括：

构建和维护安全的网络系统

1. 安装和维护防火墙配置，以保护持卡人数据
2. 对于系统密码及其他安全参数，不要使用供应商提供的默认值

保护持卡人数据

1. 保护已存储的持卡人数据
2. 对通过开放式公共网络进行传输的持卡人数据进行加密

确保维护好漏洞管理程序

1. 保护所有系统免受恶意软件和漏洞攻击，并定期更新防病毒软件
2. 开发并维护安全的系统和应用
3. 采取强大的访问权限控制措施

根据业务须知要求，限制对持卡人数据的访问

1. 识别和验证系统组件的访问权限
2. 限制对持卡人数据的物理访问

定期监控和测试网络

1. 跟踪和监控对网络资源及持卡人数据的所有访问
2. 定期测试安全系统和流程

确保维护信息安全策略

1. 维护旨在处理所有人员信息安全事务的策略

容器化应用的 PCI 合规性

在 PCI 所述的上述六个目标中，每一个都有相应的若干项要求，这些要求与容器和 Kubernetes 环境直接相关。请评估您的容器和 Kubernetes 安全工具，以确保它们能够满足以下要求：

1.12 标识持卡人数据环境（CDE）与其他网络（包括任何无线网络）之间的所有连接的当前网络图

1.1.4 每个互联网连接以及任何隔离区（DMZ）与内部网络区域之间的防火墙要求。

1.2 构建防火墙和路由器配置，以限制不可信网络与持卡人数据环境中的任何系统组件之间的连接。

1.2.1 将入站和出站流量限制为持卡人数据环境所需的流量，并明确拒绝所有其他流量。

1.3.2 使入站互联网流量仅限于 DMZ 内的 IP 地址。

1.3.4 不允许从持卡人数据环境向互联网传输未经授权的出站流量。

1.3.5 只允许"已建立"的连接进入网络。

2.1 在网络上安装系统之前，始终更改供应商提供的默认值并删除或禁用不必要的默认帐户。

2.2 为所有系统组件制定配置标准。确保这些标准能解决所有已知的安全漏洞问题，并与行业公认的系统强化标准保持一致。

2.2.1 每台服务器仅实现一个主要功能，以防那些需要不同安全级别的功能在同一台服务器上共存。（例如，Web 服务器、数据库服务器和 DNS 应在单独的服务器上实现。）

2.2.2 仅启用系统功能所需的必要服务、协议、守护进程等。

2.2.3 针对任何被认为不安全的必要服务、协议或守护进程，实施额外的安全功能。

2.2.5 删除所有不必要的功能（例如脚本、驱动程序、功能、子系统、文件系统）和不必要的 Web 服务器。

2.3 使用强加密技术对所有非控制台管理访问进行加密。

2.4 维护 PCI DSS 范围内的系统组件清单。

3.6.2 安全的加密密钥分发。

6.1 制定识别安全漏洞的流程，使用信誉良好的外部安全漏洞信息来源，并为新发现的安全漏洞分配风险等级（例如"高"、"中"或"低"）。

6.2 通过安装由供应商提供的相应安全补丁，确保所有系统组件和软件免受已知漏洞的影响。在发布后的一个月内安装重要安全补丁。

6.4.1 将开发/测试环境与生产环境分开，并利用访问工具进行强制分离。

6.4.2 开发/测试和生产环境之间的职责分离。

6.5.1 注入缺陷，尤其是 SQL 注入。还要考虑操作系统命令注入、LDAP 和 XPath 注入缺陷，以及其他注入缺陷。

6.5.3 不安全的加密存储。

6.5.4 不安全的通信。

6.5.6 在漏洞识别过程中识别出的所有"高风险"漏洞（如 PCI DSS 要求 6.1 中所定义）。

10.2.5 针对所有系统组件实施自动化审查跟踪，以重建对识别和身份验证机制的使用和更改（包括但不限于创建新帐户和提升权限）以及对具有 root 或管理权限的帐户的所有更改、添加或删除。

11.2.1 每季度执行一次内部漏洞扫描。消除漏洞并执行重新扫描，以验证所有"高风险"漏洞均已根据实体的漏洞排名（依据要求 6.1）得到解决。扫描必须由合格人员来执行。

11.5 部署变更检测机制（例如文件完整性监控工具），以提醒相关人员存在对关键系统文件、配置文件或内容文件未经授权的修改（包括更改、添加和删除）；同时，将软件配置为至少每周执行一次关键文件比较。

11.5.1 实施相应流程，以对变更检测解决方案所生成的任何提醒做出响应。

1996 年的《健康信息可携性与责任法案》构建起了 HIPAA 合规性框架，以监管与任何健康记录有关的患者隐私。2003 年新增的"安全规则"则用于管理数字健康记录。任何处理个人可识别的受保护电子健康信息（ePHI）的组织都必须遵守 HIPAA 要求。这其中包括医疗保健提供商直接用于护理、通信或计费的应用。

HIPAA 合规性所面对的主要挑战是安全框架仅提供了高级指导，而未提供组织应如何满足容器和 Kubernetes 中的这些准则的具体细节。此外，相比依据 PCI 合规性来确定哪些是、哪些不是要保护的信用卡信息（举例而言），受保护的健康信息和不受保护的健康信息之间的区别通常并不明显。

除了医疗保健提供商本身外，对于任何向医疗保健提供商提供诸如存放或计费等服务的组织，如果所提供的服务涉及处理个人电子健康信息（ePHI），则必须满足 HIPAA 要求。

HIPAA 安全规则标准被分为管理保障、物理保障和技术保障等多个方面。与 IT 基础架构息息相关的技术保障包括以下标准：

• 访问控制
• 审核控制
• 完整性
• 身份验证
• 传输安全

HIPAA 安全规则并未提供有关组织应如何保护 ePHI 的具体细节，也并非专门针对容器化应用。通常，实现 HIPAA 合规性的最佳起点是应用 NIST SP 800-190 框架，该框架为容器安全提供了相关的准则和最佳实践。与 HIPAA 不同，NIST SP 800-190 提供了一个特定于容器的框架，因此可以更容易证明合规性。不过，满足 HIPAA 要求会涉及实施额外的数据隔离控制，以保护 ePHI 并将其与其他类型的数据分隔开。

此外，HIPAA 还要求组织不仅要备份数据，还要备份配置文件，以便可以完全恢复应用，从而证明持续合规性。