本文介绍了根据支付卡行业数据安全标准 (PCI-DSS 3.2.1) 运行工作负载的 Azure Kubernetes 服务 (AKS) 群集的注意事项。
本文是一系列文章的其中一篇。 阅读简介。
此体系结构和实现侧重于基础结构，而不是工作负载。 本文提供一般注意事项和最佳做法，以帮助你进行设计决策。 请遵循官方 PCI-DSS 3.2.1 标准中的要求，并在适用的情况下将本文用作附加信息。
重要
本指南和随附的实现建立在 AKS 基线体系结构之上。 该体系结构基于中心和分支拓扑。 中心虚拟网络包含用于控制出口流量的防火墙、来自本地网络的网关流量以及用于维护的第三个网络。 分支虚拟网络包含 AKS 群集，该群集提供持卡人数据环境 (CDE)，并托管 PCI DSS 工作负载。
GitHub：适用于受管制工作负载的 Azure Kubernetes 服务 (AKS) 基线群集展示了受管制的基础结构。 此实现方案提供了一个微服务应用程序。 目的是帮助你体验基础结构并阐释网络和安全控制。 应用程序不表示或实现实际 PCI DSS 工作负载。
保护持卡人数据
要求 3 — 保护存储的持卡人数据
您的职责
| 需求 | 责任方 |
|---|---|
| 要求 3.1 | 尽量减少持卡人数据存储，方法是实施数据保留和处置策略、过程和流程，其中至少包括以下针对所有持卡人数据 (CHD) 存储的要求： |
| 要求 3.2 | 不在授权后存储敏感的身份验证数据（即使是在加密的情况下）。 如果收到敏感的身份验证数据，则应在完成授权过程后实施安全措施，使得所有数据无法恢复。 |
| 要求 3.3 | 在显示时屏蔽 PAN（最多显示头六个和后四个数字），只允许存在合法业务需要的人员查看完整 PAN。 |
| 要求 3.4 | 使用下述任一方法，使得 PAN 在其任何存储位置（包括便携数字媒体、备份媒体和日志）均不可读： |
| 要求 3.5 | 记录和实施所使用的密钥保护过程，防止存储的持卡人数据泄漏和滥用： |
| 要求 3.6 | 对于用于加密持卡人数据的加密密钥，完整地记录和实施包括以下内容在内的所有密钥管理流程和过程： |
| 要求 3.7 | 确保记录在保护存储的持卡人数据时使用过哪些安全策略和操作过程，并将其告知受影响的各方。 |
要求 4 — 跨开放的公用网络加密传输持卡人数据。
您的职责
| 需求 | 责任方 |
|---|---|
| 要求 4.1 | 使用强加密和安全协议（例如，TLS、IPSEC、SSH 等）在通过开放的公共网络进行传输的过程中保护敏感的持卡人数据，包括以下方面： |
| 要求 4.2 | 永远不使用最终用户消息传送技术（例如，电子邮件、即时消息、短信、聊天，等等）发送未受保护的 PAN。 |
| 要求 4.3 | 确保用于加密传输持卡人数据的安全策略和操作过程都已记录在案、在使用中并对所有受影响方已知。 |
要求 3.1
尽量减少持卡人数据存储，方法是实施数据保留和处置策略、过程和流程，其中至少包括以下针对所有持卡人数据 (CHD) 存储的要求：
- 在符合法律、法规和业务要求的情况下，尽量降低数据存储量和缩短保留时间
- 制定安全删除不再需要的数据的流程
- 针对持卡人数据制定特定的保留要求
- 按季确定存储的超过所定义保留期的持卡人数据并将其安全地删除。
您的职责
请勿将状态存储在 AKS 群集中。 如果选择存储 CHD，请浏览安全存储选项。 选项包括适用于文件存储的 Azure 存储，或是 Azure SQL 数据库或 Azure Cosmos DB 等数据库。
严格遵循关于可以存储哪种 CHD 的标准指导。 根据业务要求和使用的存储类型定义数据保留策略。 一些关键注意事项包括：
- 如何以及在何处存储数据？
- 存储的数据是否加密？
- 保留期是多长？
- 在保留期内允许执行哪些操作？
- 如何在保留期到期后删除存储的数据？
围绕其中一些选择制定治理策略。 内置 Azure 策略会强制实施这些选择。 例如，可以限制群集 Pod 上的卷类型，或拒绝对根文件系统进行的写入操作。
查看此策略定义列表，并将它们应用于群集（如果适用）。
可能需要暂时缓存数据。 建议在将数据移动到存储解决方案时保护缓存的数据。 请考虑在 AKS 上启用基于主机的加密功能。 这会对节点 VM 上存储的数据进行加密。 有关详细信息，请参阅 Azure Kubernetes 服务 (AKS) 中的基于主机的加密。 此外，启用需要对节点池的临时磁盘和缓存进行加密的内置 Azure 策略。
选择存储技术时，探索保留功能。 例如，Azure Blob 存储提供基于时间的保留策略。 另一种选择是实现根据保留策略删除数据的自定义解决方案。 一个示例是管理数据生命周期活动的数据生命周期管理 (DLM)。 该解决方案使用各种服务进行设计（如 Azure 数据工厂、Microsoft Entra ID 和 Azure Key Vault）。
有关详细信息，请参阅使用 Azure 数据工厂管理数据生命周期。
要求 3.2
不在授权后存储敏感的身份验证数据（即使是在加密的情况下）。 如果收到敏感的身份验证数据，则应在完成授权过程后实施安全措施，使得所有数据无法恢复。
您的职责
（适用于：要求 3.2.1、要求 3.2.2、要求 3.2.3）
处理和保护数据超出了此体系结构的范围。 以下是一些一般注意事项。
根据标准，敏感身份验证数据包括完整跟踪数据、信用卡验证码或值以及 PIN 数据。 作为 CHD 处理的一部分，请确保身份验证数据不会在源中公开，例如：
- 从 Pod 发出的日志。
- 异常处理例程。
- 文件名。
- “缓存”。
作为一般指导，商家不应存储此信息。 如果需要，请记录业务理由。
要求 3.3
在显示时屏蔽 PAN（最多显示头六个和后四个数字），只允许存在合法业务需要的人员查看完整 PAN。
您的职责
主帐号 (PAN) 被视为敏感数据，必须阻止公开此数据。 一种方法是通过掩码减少显示的数字。
请勿在工作负载中实现数据掩码。 而是改用数据库级别构造。 Azure SQL 服务线（包括 Azure Synapse Analytics）支持动态数据掩码，这可减少应用层上的公开。 它是基于策略的安全功能，定义可以查看未掩码数据的人员，以及通过掩码公开的数据量。 内置信用卡掩码方法公开指定字段的最后四位数，并添加一个信用卡格式的常量字符串作为前缀。
有关详细信息，请参阅动态数据掩码。
如果需要将未掩码数据引入群集，请尽快进行掩码。
要求 3.4
使用下述任一方法，使得 PAN 在其任何存储位置（包括便携数字媒体、备份媒体和日志）均不可读：
- 基于强加密的单向哈希（必须是整个 PAN 的哈希）
- 截断（哈希不能用于替换截断的 PAN 段）
- 索引令牌和填充（填充必须安全地进行存储）
- 使用关联的密钥管理流程和过程进行的强加密。
您的职责
对于此要求，可能需要在工作负载中使用直接加密。 PCI DSS 指导建议使用经过行业测试的算法，以便它们能够承受实际攻击。 避免使用自定义加密算法。
适当的数据掩码技术也可满足此要求。 你负责对所有主帐号 (PAN) 数据进行掩码。 Azure SQL 服务线（包括 Azure Synapse Analytics）支持动态数据掩码。 请参阅要求 3.3。
请确保 PAN 未作为工作流过程的一部分进行公开。 下面是一些注意事项：
将 PAN 排除在日志之外，包括工作流日志和（预期或意外）异常处理日志。 此外，诊断数据流（如 HTTP 标头）不得公开此数据。
请勿将 PAN 用作缓存查找键或是此过程生成的任何文件名的一部分。
你的客户可能会以无提示的自由格式文本字段提供 PAN。 请确保对任何自由格式文本字段实施内容验证和检测过程，从而清理类似于 PAN 数据的所有内容。
要求 3.4.1
如果使用磁盘加密（而不是文件或列级别的数据库加密），则必须单独管理逻辑访问，使之独立于本机操作系统身份验证和访问控制机制（例如，不使用本地用户帐户数据库或通用网络登录凭据）。 加密密钥不得与用户帐户相关联。
您的职责
作为一般规则，请勿将状态存储在 AKS 群集中。 使用支持存储引擎级别加密的外部数据存储。
Azure 存储中存储的所有数据都使用强加密进行加密和解密。 Microsoft 会管理关联密钥。 首选自我管理的加密密钥。 始终在存储层外部加密，并且只将加密数据写入存储介质，从而确保密钥从不会与存储层相邻。
借助 Azure 存储，还可以使用自我管理的密钥。 有关详细信息，请参阅用于 Azure 存储加密的客户管理的密钥。
类似的功能可用于数据库。 对于 Azure SQL 选项，请参阅使用客户管理的密钥进行 Azure SQL 透明数据加密。
请确保将密钥存储在托管密钥存储（Azure Key Vault、Azure Key Vault 托管硬件安全模块 (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
仅限最少数量的必要管理员访问加密密钥。
您的职责
最大限度地减少有权访问密钥的人数。 如果使用任何基于组的角色分配，请设置定期审核过程来评审具有访问权限的角色。 当项目团队成员更改时，必须从权限中移除不再相关的帐户。 只有正确的人员才应具有访问权限。 请考虑移除长期权限，以支持实时 (JIT) 角色分配、基于时间的角色激活和基于审批的角色激活。
要求 3.5.3
始终使用下面的一种（或多种）格式存储用来加密/解密持卡人数据的机密和私钥：
- 使用密钥加密密钥来加密，该密钥在强度上至少与数据加密密钥一样，与数据加密密钥分开存储
- 位于安全的加密设备（例如硬件（主机）安全模块 (HSM) 或 PTS 审批的交互点设备）内
- 充当至少两个完整的密钥组件或密钥共享，采用行业接受的方法
您的职责
作为静态数据保护策略的一部分，PCI-DSS 3.2.1 工作负载需要使用多个加密密钥。 数据加密密钥 (DEK) 用于对 CHD 进行加密和解密，但你负责附加的密钥加密密钥 (KEK) 来保护该 DEK。 你还负责确保 KEK 存储在加密设备中。
可以使用 Azure Key Vault 存储 DEK，并使用 Azure 专用 HSM 存储 KEK。 有关 HSM 密钥管理的信息，请参阅什么是 Azure 专用 HSM？。
要求 3.6
对于用于加密持卡人数据的加密密钥，完整地记录和实施包括以下内容在内的所有密钥管理流程和过程：
您的职责
（适用于：要求 3.6.1、要求 3.6.2、要求 3.6.3、要求 3.2.4）
如果使用 Azure Key Vault 存储机密（如密钥、证书和连接字符串），请保护机密免受未经授权的访问。 Microsoft Defender for Key Vault 会检测可疑的访问尝试并生成警报。 可以在 Microsoft Defender for Cloud 中查看这些警报。 有关详细信息，请参阅 Microsoft Defender for Key Vault。
遵循有关密钥管理的 NIST 指导。 有关详细信息，请参阅：
另请参阅 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.1
使用强加密和安全协议（例如，TLS、IPSEC、SSH 等）在通过开放的公共网络进行传输的过程中保护敏感的持卡人数据，包括以下方面：
您的职责
必须对通过公共 Internet 传输的卡持有者数据 (CHD) 进行加密。 必须使用 TLS 1.2（或更高版本）对数据进行加密，减少针对所有传输的密码支持。 不支持在任何数据传输服务上进行 TLS 到 TLS 重定向。
设计应具有 TLS 终止点策略链。 当数据通过网络跃点传输时，在需要数据包检查的跃点上维护 TLS。 至少，在群集的入口资源上具有最终 TLS 终止点。 请考虑在群集资源中更进一步。
使用 Azure Policy 管理资源的创建：
- 拒绝创建任何非 HTTPS 入口资源。
- 拒绝在群集中创建任何公共 IP 或任何公共负载均衡器，以确保 Web 流量通过网关进行隧道传输。
有关详细信息，请参阅 Azure 加密概述。
要求 4.1.1
确保传输持卡人数据或连接到持卡人数据环境的无线网络使用行业最佳做法（例如，IEEE 802.11i）实现身份验证和传输的强加密。
您的职责
此体系结构和实现并非旨在通过无线连接进行本地或公司网络到云的交易。 有关注意事项，请参阅官方 PCI-DSS 3.2.1 标准中的指南。
要求 4.2
永远不使用最终用户消息传送技术（例如，电子邮件、即时消息、短信、聊天，等等）发送未受保护的 PAN。
您的职责
如果工作负载需要发送电子邮件，请考虑构建电子邮件隔离入口。 此验证使你能够扫描所有出站消息的合规性并检查是否不包含敏感数据。 理想情况下，还应对客户支持消息考虑此方法。
应在工作负载级别和变更控制过程中进行验证。 审批入口应了解要求。
有关注意事项，请参阅官方 PCI-DSS 3.2.1 标准中的指南。
要求 4.3
确保用于加密传输持卡人数据的安全策略和操作过程都已记录在案、在使用中并对所有受影响方已知。
您的职责
维护关于流程和策略的完整文档至关重要。 当管理有关传输层安全性 (TLS) 的策略时，尤其如此。 下面是一些领域：
- 公共 Internet 入口点。 一个示例是针对 TLS 密码的 Azure 应用程序网关支持。
- 外围网络与工作负载 Pod 之间的网络跃点。
- Pod 到 Pod 加密（如果实现）。 这可以包括有关服务网格配置的详细信息。
- Pod 到存储（如果是体系结构的一部分）。
- Pod 到外部服务、使用 TLS 的 Azure PaaS 服务、支付网关或欺诈检测系统。
必须教育、告知和激励操作受管制环境的人员，以支持安全保证。 从策略角度来看，这对于参与审批过程的人员尤其重要。
后续步骤
保护所有系统免受恶意软件威胁，并定期更新防病毒软件或程序。 开发并维护安全系统和应用程序。