PCI DSS 4.0.1 的 AKS 管控群集的数据保护

本文介绍 Azure Kubernetes 服务（AKS）群集的数据保护注意事项，该群集运行工作负荷符合支付卡行业数据安全标准（PCI-DSS 4.0.1）。

本文是一系列文章的其中一篇。 阅读简介。

此体系结构和实现侧重于基础结构，而不是工作负载。 本文提供一般注意事项和最佳做法，以帮助你进行设计决策。 请遵循官方 PCI-DSS 4.0.1 标准中的要求，并在适用的情况下使用本文作为其他信息。

保护持卡人数据

要求 3：保护存储的持卡人数据

您的职责

要求 3.1

尽量减少持卡人数据存储，方法是实施数据保留和处置策略、过程和流程，其中至少包括以下针对所有持卡人数据 (CHD) 存储的要求：

• 将数据存储量和保留时间限制为法律、法规和业务要求所需的时间。
• 不再需要时安全删除数据的过程。
• 持卡人数据的特定保留要求。
• 按季确定存储的超过所定义保留期的持卡人数据并将其安全地删除。

你的职责（PCI DSS 4.0.1）

不要在 AKS 群集中存储状态。 如果选择存储 CHD，请浏览安全存储选项。 选项包括适用于文件存储的 Azure 存储，或是 Azure SQL 数据库或 Azure Cosmos DB 等数据库。 PCI DSS 4.0.1 允许自定义方法来满足安全目标，但必须记录并证明任何替代控件的合理性。

严格遵循关于可以存储哪种 CHD 的标准指导。 根据业务要求和使用的存储类型定义数据保留策略。 需考虑的关键因素包括：

• 如何以及在何处存储数据？
• 存储的数据是否加密？
• 保留期是多长？
• 在保留期内允许执行哪些操作？
• 如何在保留期到期后删除存储的数据？

围绕其中一些选择制定治理策略。 内置 Azure 策略会强制实施这些选择。 例如，可以限制群集 Pod 上的卷类型，或拒绝对根文件系统进行的写入操作。

查看 策略定义列表 ，并将其应用于群集（如果适用）。

可能需要暂时缓存数据。 建议在将数据移动到存储解决方案时保护缓存的数据。 请考虑在 AKS 上启用基于主机的加密功能。 这会对节点 VM 上存储的数据进行加密。 有关详细信息，请参阅 Azure Kubernetes 服务 (AKS) 中的基于主机的加密。 此外，启用需要对节点池的临时磁盘和缓存进行加密的内置 Azure 策略。

选择存储技术时，探索保留功能。 例如，Azure Blob 存储提供基于时间的保留策略。 另一种选择是实现根据保留策略删除数据的自定义解决方案。 例如数据生命周期管理 （DLM），用于管理数据生命周期活动。 该解决方案使用各种服务进行设计（如 Azure 数据工厂、Microsoft Entra ID 和 Azure Key Vault）。 PCI DSS 4.0.1 强调对所有数据存储和保留过程进行持续监视和定期风险评估。

有关详细信息，请参阅 使用 Azure 数据工厂管理数据生命周期。

要求 3.2

授权后不要存储敏感的身份验证数据（即使已加密）。 如果收到敏感的身份验证数据，则应在完成授权过程后实施安全措施，使得所有数据无法恢复。

您的职责

处理和保护数据是工作负荷问题，并且超出了此体系结构的范围。 下面是一些常规注意事项：

根据标准，敏感身份验证数据包括完整跟踪数据、信用卡验证码或值以及 PIN 数据。 作为 CHD 处理的一部分，请确保身份验证数据不会在日志、异常处理例程、文件名或缓存等源中公开。 PCI DSS 4.0.1 通过扩展监视和日志记录来检测和响应未经授权的访问或存储敏感验证数据，包括：

• 从 Pod 发出的日志。
• 异常处理例程。
• 文件名。
• 缓存。

作为一般指导，商家不应存储此信息。 如果需要，请记录业务理由。

要求 3.3

在显示时屏蔽 PAN（最多显示头六个和后四个数字），只允许存在合法业务需要的人员查看完整 PAN。

您的职责

主帐号 (PAN) 被视为敏感数据，必须阻止公开此数据。 一种方法是通过掩码减少显示的数字。 PCI DSS 4.0.1 阐明了掩码要求，并允许在合理和记录的情况下使用自定义方法。

不要在工作负荷中实现数据掩码。 而是改用数据库级别构造。 Azure SQL 服务线（包括 Azure Synapse Analytics）支持动态数据掩码，这可减少应用层上的公开。 它是基于策略的安全功能，定义可以查看未掩码数据的人员，以及通过掩码公开的数据量。 内置信用卡掩码方法公开指定字段的最后四位数，并添加一个信用卡格式的常量字符串作为前缀。

有关详细信息，请参阅动态数据掩码。

如果需要将未屏蔽的数据引入群集，请尽快屏蔽。

要求 3.4

使用以下任一方法将 PAN 在任何位置呈现为不可读（包括在可移植数字媒体、备份媒体和日志中）：

• 使用基于强加密的一种单向哈希方法（必须对整个 PAN 进行哈希）。
• 截断（哈希不能用于替换 PAN 的截断段）。
• 索引令牌和垫（必须安全地存储 pad）。
• 使用关联的密钥管理流程和过程进行的强加密。

您的职责

对于此要求，可能需要在工作负载中使用直接加密。 PCI DSS 4.0.1 更新加密要求，以符合不断发展的行业标准。 仅使用经过行业测试和批准的算法（如 AES、RSA 等），并避免使用自定义加密算法。 确保持续监视和测试加密控制。

适当的数据掩码技术也可满足此要求。 你负责对所有主帐号 (PAN) 数据进行掩码。 Azure SQL 服务线（包括 Azure Synapse Analytics）支持动态数据掩码。 请参阅要求 3.3。 PCI DSS 4.0.1 要求记录掩码和加密控制，并接受持续审查。

请确保未在工作流过程中公开 PAN。 下面是一些注意事项：

• 将 PAN 排除在日志之外，包括工作流日志和（预期或意外）异常处理日志。 此外，诊断数据流（如 HTTP 标头）不得公开此数据。
• 请勿将 PAN 用作缓存查找键或此过程生成的任何文件名的一部分。
• 你的客户可能会以无提示的自由格式文本字段提供 PAN。 请确保对任何自由格式文本字段实施内容验证和检测过程，从而清理类似于 PAN 数据的所有内容。

要求 3.4.1

如果使用磁盘加密（而不是文件或列级别的数据库加密），则必须单独管理逻辑访问，使之独立于本机操作系统身份验证和访问控制机制（例如，不使用本地用户帐户数据库或通用网络登录凭据）。 加密密钥不得与用户帐户相关联。 PCI DSS 4.0.1 进一步阐明了密钥管理和访问分离要求。

您的职责

一般情况下，不要将状态存储在 AKS 群集中。 使用支持存储引擎级别加密的外部数据存储。

Azure 存储中存储的所有数据都使用强加密进行加密和解密。 Microsoft 会管理关联密钥。 首选自我管理的加密密钥。 始终在存储层外部加密，并且只将加密数据写入存储介质，从而确保密钥从不会与存储层相邻。

借助 Azure 存储，还可以使用自我管理的密钥。 有关详细信息，请参阅用于 Azure 存储加密的客户管理的密钥。

类似的功能可用于数据库。 对于 Azure SQL 选项，请参阅使用客户管理的密钥进行 Azure SQL 透明数据加密。

请确保将密钥存储在托管密钥存储中，例如 Azure Key Vault、Azure 托管 HSM 或第三方密钥管理解决方案。

如果需要暂时存储数据，请启用 AKS 的主机加密功能，以确保 VM 节点上存储的数据进行加密。

要求 3.5

记录和实施所使用的密钥保护过程，防止存储的持卡人数据泄漏和滥用。

您的职责

以下责任适用：

• 对加密密钥维护最低特权访问做法。
• Azure Key Vault 和 Microsoft Entra ID 旨在支持授权和审核日志记录要求。 有关详细信息，请参阅 Azure Key Vault 的请求身份验证。
• 使用存储在加密设备中的密钥加密密钥保护所有数据加密密钥。
• 如果使用自我管理的密钥（而不是 Microsoft 管理的密钥），请采用一个过程和文档来维护与密钥管理相关的任务。

要求 3.5.1

仅对服务提供商的其他要求： 维护加密体系结构的记录说明，其中包括：

• 用于保护持卡人数据的所有算法、协议和密钥的详细信息，包括密钥强度和到期日期。
• 每个密钥的密钥用法说明。
• 用于密钥管理的 HSM 和其他 SCD 的清单。

您的职责

存储敏感信息（密钥、连接字符串等）的一种方法是使用本机 Kubernetes Secret 资源。 必须显式启用静态加密。 或者，将它们存储在托管存储（例如Azure Key Vault）中。 在这两种方法中，建议使用托管存储服务。 一个优点是可减少与密钥管理相关的任务（例如密钥轮换）的开销。

默认情况下，Azure 对所有加密数据使用每个客户的Microsoft托管密钥。 但是，某些服务还支持将自我管理的密钥用于加密。 如果使用自我的管理密钥进行静态加密，请确保考虑处理密钥管理任务的过程和策略。

作为文档的一部分，包括与密钥管理相关的信息，例如到期、位置和维护计划详细信息。

要求 3.5.2

仅限最少数量的必要管理员访问加密密钥。

您的职责

最大限度地减少有权访问密钥的人数。 如果使用任何基于组的角色分配，请设置定期审核过程来评审具有访问权限的角色。 当项目团队成员更改时，必须从权限中移除不再相关的帐户。 只有正确的人员才应具有访问权限。 使用 Microsoft Entra ID 访问评审定期评审组成员身份。

请考虑移除长期权限，以支持实时 (JIT) 角色分配、基于时间的角色激活和基于审批的角色激活。 例如，请考虑使用 Privileged Identity Management。

要求 3.5.3

始终使用下面的一种（或多种）格式存储用来加密/解密持卡人数据的机密和私钥：

• 使用密钥加密密钥进行加密，该密钥至少与数据加密密钥一样强，并且与数据加密密钥分开存储。
• 在安全加密设备（如硬件主机安全模块（HSM）或 PTS 批准的交互终端设备）中。
• 根据行业认可的方法，至少有两个全长关键组件或密钥份额。

您的职责

PCI-DSS 4.0.1 工作负荷需要使用多个加密密钥作为静态数据保护策略的一部分。 数据加密密钥 (DEK) 用于对 CHD 进行加密和解密，但你负责附加的密钥加密密钥 (KEK) 来保护该 DEK。 你还负责确保 KEK 存储在加密设备中。 PCI DSS 4.0.1 需要持续监视和记录所有关键管理活动。

可以使用 Azure Key Vault 存储 DEK，并使用 Azure 专用 HSM 存储 KEK。 有关 HSM 密钥管理的信息，请参阅 什么是 Azure 专用 HSM？

要求 3.6

对于用于加密持卡人数据的加密密钥，完整地记录和实施包括以下内容在内的所有密钥管理流程和过程：

您的职责

如果使用 Azure Key Vault 存储机密（如密钥、证书和连接字符串），请保护机密免受未经授权的访问。 Microsoft Defender for Key Vault 会检测可疑的访问尝试并生成警报。 可以在 Microsoft Defender for Cloud 中查看这些警报。 有关详细信息，请参阅 Microsoft Defender for Key Vault。 PCI DSS 4.0.1 需要为所有密钥管理系统扩展监视和警报。

遵循有关密钥管理的 NIST 指导。 有关详细信息，请参阅：

• 加密密钥管理
• SP 800-133 修订版 2，加密密钥生成建议
• SP 800-57 第 1 部分修订版 5，密钥管理建议

另请参阅 Microsoft Defender for Key Vault。

要求 3.6.7

防止未经授权就替换加密密钥。

您的职责

• 在所有密钥存储上启用诊断。 使用 Azure Monitor for Key Vault。 它会收集日志和指标并将其发送到 Azure Monitor。 有关详细信息，请参阅使用 Azure Monitor for Key Vault 监视密钥保管库服务。
• 向所有使用者授予只读权限。
• 管理用户或主体没有默认权限。 而是改用即时 (JIT) 角色分配、基于时间的角色激活和基于审批的角色激活。
• 通过将日志和警报集成到安全信息和事件管理 (SIEM) 解决方案（如 Microsoft Sentinel）中来创建集中式视图。
• 对警报和通知执行操作，尤其是对意外更改。

要求 3.6.8

要求加密密钥管理员正式确认自己了解并接受密钥管理员责任。

您的职责

维护描述参与密钥管理操作各方责任的文档。

要求 3.7

确保记录在保护存储的持卡人数据时使用过哪些安全策略和操作过程，并将其告知受影响的各方。

您的职责

创建文档作为常规声明，以及适用于所有角色的一系列最新角色指南。 执行新员工培训和正在进行的培训。

维护关于流程和策略的完整文档至关重要。 多个团队参与，确保静态和传输中的数据受到保护。 在文档中，为所有角色提供角色指导。 角色应包括 SRE、客户支持、销售、网络运营、安全运营、软件工程师、数据库管理员等。 人员应接受 NIST 指导和静态数据策略培训，以保持其技能设置最新。 培训要求在要求 6.5 和要求 12.6 中进行了说明。

要求 4：加密通过开放、公用网络传输持卡人数据

您的职责

要求 4.1

使用强加密和安全协议（例如，TLS、IPSEC、SSH 等）在通过开放的公共网络进行传输的过程中保护敏感的持卡人数据，包括以下方面：

您的职责

必须加密通过公共 Internet 传输的持卡人数据（CHD）。 数据必须使用 TLS 1.2 或更高版本进行加密，且支持所有传输的强密码。 不支持任何数据传输服务上的非 TLS 到 TLS 重定向。 PCI DSS 4.0.1 需要持续监视加密协议和定期风险评估，以确保加密控制保持有效。

设计应具有 TLS 终止点策略链。 当数据通过网络跃点传输时，在需要数据包检查的跃点上维护 TLS。 至少，在群集的入口资源上具有最终 TLS 终止点。 请考虑在群集资源中更进一步。

使用 Azure Policy 管理资源的创建：

• 拒绝创建任何非 HTTPS 入口资源。
• 拒绝在群集中创建任何公共 IP 或任何公共负载均衡器，以确保 Web 流量通过网关进行隧道传输。

有关详细信息，请参阅 Azure 加密概述。 PCI DSS 4.0.1 允许在合理证明并记录的情况下使用自定义方法来加密控制。

要求 4.1.1

确保传输持卡人数据或连接到持卡人数据环境的无线网络使用行业最佳做法（例如，IEEE 802.11i）实现身份验证和传输的强加密。

您的职责

此体系结构和实现并非旨在通过无线连接进行本地或公司网络到云的交易。 有关注意事项，请参阅官方 PCI-DSS 4.0.1 标准中的指南。

要求 4.2

永远不使用最终用户消息传送技术（例如，电子邮件、即时消息、短信、聊天，等等）发送未受保护的 PAN。

您的职责

如果工作负载需要发送电子邮件，请考虑构建电子邮件隔离入口。 此验证使你能够扫描所有出站消息的合规性并检查是否不包含敏感数据。 理想情况下，还应对客户支持消息考虑此方法。

应在工作负载级别和变更控制过程中进行验证。 审批入口应了解要求。

有关注意事项，请参阅官方 PCI-DSS 4.0.1 标准中的指南。

要求 4.3

确保用于加密传输持卡人数据的安全策略和操作过程都已记录在案、在使用中并对所有受影响方已知。

您的职责

维护关于流程和策略的完整文档至关重要。 当管理有关传输层安全性 (TLS) 的策略时，尤其如此。 文档应包含有关方面的信息，例如：

• 公共 Internet 入口点。 一个示例是针对 TLS 密码的 Azure 应用程序网关支持。
• 外围网络与工作负载 Pod 之间的网络跃点。
• Pod 到 Pod 加密（如果实现）。 这可以包括有关服务网格配置的详细信息。
• Pod 到存储（如果是体系结构的一部分）。
• Pod 到外部服务、使用 TLS 的 Azure PaaS 服务、支付网关或欺诈检测系统。

必须教育、告知和激励操作受管制环境的人员，以支持安全保证。 从策略角度来看，这对于参与审批过程的人员尤其重要。

后续步骤

实施全面的加密和密钥管理控制，以保护持卡人静态和传输中的数据。