本文介绍 Azure Kubernetes 服务（AKS）群集的数据保护注意事项，该群集运行工作负荷符合支付卡行业数据安全标准（PCI-DSS 4.0.1）。
本文是一系列文章的其中一篇。 阅读 简介。
此体系结构和实现侧重于基础结构，而不是工作负荷。 本文提供了一般注意事项和最佳做法，可帮助你做出设计决策。 请遵循官方 PCI-DSS 4.0.1 标准中的要求，并在适用的情况下使用本文作为其他信息。
重要
该指南和随附的实现基于中心辐射型网络拓扑的 AKS 基线体系结构为基础。 中心虚拟网络包含用于控制出口流量的防火墙、来自本地网络的网关流量，以及用于维护的第三个网络。 辐射虚拟网络包含 AKS 群集，该群集提供卡持有者环境（CDE），并托管 PCI DSS 工作负荷。
参考实现：适用于 PCI DSS 4.0.1 的受管制工作负载参考实现的 Azure Kubernetes 服务（AKS）基线群集目前正在更新，即将推出。 此实现将演示一个受监管的基础结构，该基础结构演示了 CDE 中各种网络安全控制的使用。 这包括本机到 Azure 的网络控件，以及 Kubernetes 的本机控制。 它还将包括一个应用程序，用于演示环境与示例工作负荷之间的交互。 本文的重点在于基础结构。 该示例不会指示实际 PCI-DSS 4.0.1 工作负荷。
保护持卡人数据
注释
本文已针对 PCI DSS 4.0.1 进行了更新。 主要更改包括对自定义控制方法的支持、增强的多重身份验证（MFA）、更新的加密要求、扩展的监视和日志记录，以及专注于持续安全性和风险管理。 确保查看官方 PCI DSS 4.0.1 文档 ，了解完整详细信息和未来日期的要求。
要求 3：保护存储的持卡人数据
你的责任
| Requirement | 职责 |
|---|---|
| 要求 3.1 | 通过对所有持卡人数据（CHD）存储实施数据保留和处置策略、过程和流程，将持卡人数据存储保持在最低水平。 |
| 要求 3.2 | 授权后不要存储敏感的身份验证数据（即使已加密）。 如果收到敏感的身份验证数据，则完成授权过程后，呈现所有数据不可恢复。 |
| 要求 3.3 | 显示时屏蔽 PAN（前六位和最后四位数字是要显示的最大位数），这样只有具有合法业务需求的人员才能看到完整的 PAN。 |
| 要求 3.4 | 使用强加密和密钥管理过程，将 PAN 呈现在存储的任何位置（包括便携式数字媒体、备份媒体和日志中）。 |
| 要求 3.5 | 记录和实施用于保护存储持卡人数据的密钥免受泄露和滥用的威胁的过程。 |
| 要求 3.6 | 完全记录并实施用于加密持卡人数据的加密密钥的所有密钥管理过程和过程。 |
| 要求 3.7 | 确保记录了保护存储持卡人数据的安全策略和作过程，并对所有受影响的各方都了解这些数据。 |
要求 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 的请求身份验证。
- 使用存储在加密设备中的密钥加密密钥保护所有数据加密密钥。
- 如果使用自管理密钥（而不是 Azure 管理的密钥），请提供一个过程和文档来维护与密钥管理相关的任务。
要求 3.5.1
仅对服务提供商的其他要求： 维护加密体系结构的记录说明，其中包括：
- 用于保护持卡人数据的所有算法、协议和密钥的详细信息，包括密钥强度和到期日期。
- 每个密钥的密钥用法说明。
- 清单用于密钥管理的任何 HSM 和其他 SCD。
你的责任
存储敏感信息（密钥、连接字符串和其他信息）的一种方法是使用本机 Kubernetes Secret 资源。 必须显式启用静态加密。 或者，将它们存储在 Azure Key Vault 等托管存储中。 在两种方法中，我们建议使用托管的商店服务。 一个优点是减少与密钥管理相关的任务（例如密钥轮换）的开销。
默认情况下，Azure 对所有加密数据使用每个客户的 Azure 托管密钥。 但是，某些服务还支持用于加密的自管理密钥。 如果使用自管理密钥进行静态加密，请确保考虑处理密钥管理任务的过程和策略。
作为文档的一部分，包括与密钥管理相关的信息，例如过期、位置和维护计划详细信息。
要求 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。
要求 3.6
全面记录并实施用于加密持卡人数据的加密密钥的所有密钥管理过程和过程，包括：
你的责任
如果使用 Azure Key Vault 来存储密钥、证书和连接字符串等机密，请保护它免受未经授权的访问。 Microsoft Defender for Key Vault 检测到可疑的访问尝试并生成警报。 可以在 Microsoft Defender for Cloud 中查看这些警报。 PCI DSS 4.0.1 需要为所有密钥管理系统扩展监视和警报。
遵循有关密钥管理的 NIST 指南。 有关详细信息，请参阅：
要求 3.6.7
防止未经授权的加密密钥替换。
你的责任
- 对所有密钥存储启用诊断。 使用用于 Key Vault 的 Azure Monitor。 它收集日志和指标并将其发送到 Azure Monitor。 有关详细信息，请参阅 使用用于 Key Vault 的 Azure Monitor 监视密钥保管库服务。
- 向所有使用者授予只读权限。
- 没有管理用户或主体的站立权限。 请改用实时（JIT）角色分配、基于时间的角色激活和基于审批的角色激活。
- 通过将日志和警报集成到安全信息和事件管理（SIEM）解决方案（如 Microsoft Sentinel）来创建集中式视图。
- 对警报和通知执行作 ，尤其是在意外更改时。
要求 3.6.8
要求加密密钥保管人正式承认他们理解并接受其密钥保管人的责任。
你的责任
维护文档，描述参与密钥管理作的各方的责任。
要求 3.7
确保记录了保护存储持卡人数据的安全策略和作过程，并对所有受影响的各方都了解这些数据。
你的责任
以常规语句形式创建文档，并为所有角色创建一系列 up-to日期角色指南。 执行新员工培训和正在进行的培训。
维护有关流程和策略的彻底文档至关重要。 多个团队参与确保数据在静态和传输过程中受到保护。 在文档中，为所有角色提供角色指导。 这些角色应包括 SRE、客户支持、销售、网络作、安全作、软件工程师、数据库管理员等。 人员应接受 NIST 指导和静态数据策略培训，以保持其技能设置最新。 要求 6.5 和 要求 12.6 中解决了培训要求。
要求 4：加密跨开放、公用网络传输持卡人数据的传输
你的责任
| Requirement | 职责 |
|---|---|
| 要求 4.1 | 使用强加密和安全协议（例如 TLS 1.2 或更高版本、IPSEC、SSH 等）在通过开放、公用网络传输期间保护敏感持卡人数据，包括以下内容： |
| 要求 4.2 | 从不通过最终用户消息传递技术（例如电子邮件、即时消息、短信、聊天等）发送未受保护的 PAN。 |
| 要求 4.3 | 确保对持卡人数据的传输进行加密的安全策略和作过程记录在使用中，并向所有受影响的方已知。 |
要求 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 入口点。 例如，Azure 应用程序网关对 TLS 密码的支持。
- 外围网络和工作负荷 Pod 之间的网络跃点。
- Pod 到 Pod 加密（如果已实现）。 这可以包括有关服务网格配置的详细信息。
- Pod 到存储（如果体系结构的一部分）。
- Pod 到外部服务、使用 TLS、支付网关或欺诈检测系统的 Azure PaaS 服务。
运营受监管环境的人员必须接受教育、通知和激励，以支持安全保证。 对于从政策角度而言，属于审批流程的人员尤其重要。
后续步骤
实施全面的加密和密钥管理控制，以保护持卡人静态和传输中的数据。