【Azure AKS】PCI-DSS 3.2.1的AKS监管集群中的安全数据（第4部分，共9部分）

本文描述了运行符合支付卡行业数据安全标准（PCI-DSS 3.2.1）的工作负载的Azure Kubernetes Service（AKS）集群的注意事项。

本文是系列文章的一部分。阅读介绍。

这种架构和实现侧重于基础设施，而不是工作负载。本文提供了一般考虑因素和最佳实践，以帮助您做出设计决策。遵循官方PCI-DSS 3.2.1标准的要求，并在适用的情况下将本文用作附加信息。

重要事项

该指南和附带的实现建立在AKS基线架构的基础上。该架构基于中心辐射拓扑。集线器虚拟网络包含控制出口流量的防火墙、来自本地网络的网关流量和用于维护的第三个网络。辐条虚拟网络包含提供持卡人数据环境（CDE）并承载PCI DSS工作负载的AKS集群。

GitHub徽标GitHub：Azure Kubernetes服务（AKS）受监管工作负载的基线集群展示了受监管的基础设施。此实现提供了一个微服务应用程序。它的目的是帮助您体验基础设施，并说明网络和安全控制。该应用程序不代表或实现实际的PCI DSS工作负载。

保护持卡人数据

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

你的责任

 

Requirement	Responsibility
Requirement 3.1	Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all cardholder data (CHD) storage:
Requirement 3.2	Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process.
Requirement 3.3	Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN.
Requirement 3.4	Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:
Requirement 3.5	Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse:
Requirement 3.6	Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data, including the following:
Requirement 3.7	Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.

要求3.1

通过实施数据保留和处置政策、程序和流程，将持卡人数据存储保持在最低限度，其中至少包括以下所有持卡人数据（CHD）存储：

• 将数据存储量和保留时间限制在法律、监管和业务要求所需的范围内
• 不再需要时安全删除数据的过程
• 持卡人数据的具体保留要求
• 用于识别和安全删除超过规定保留期的存储持卡人数据的季度流程。
   

你的责任

不要将状态存储在AKS集群中。如果您选择存储CHD，请探索安全存储选项。选项包括用于文件存储的Azure存储，或Azure SQL数据库或Azure Cosmos DB等数据库。

严格遵守关于可以存储哪种CHD的标准指南。根据您的业务需求和使用的存储类型定义数据保留策略。一些关键考虑因素是：

• 数据是如何以及在哪里存储的？
• 存储的数据是否加密？
• 保留期是多久？
• 在保留期内允许采取哪些行动？
• 在保留期结束后，如何删除存储的数据？

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

查看此策略定义列表，并在适用的情况下将其应用于集群。

您可能需要临时缓存数据。我们建议您在将缓存数据移动到存储解决方案时对其进行保护。考虑在AKS上启用基于主机的加密功能。这将加密存储在节点VM上的数据。有关更多信息，请参阅Azure Kubernetes Service（AKS）上的基于主机的加密。此外，启用内置的Azure策略，该策略要求对节点池的临时磁盘和缓存进行加密。

当您选择存储技术时，请探索保留功能。例如，Azure Blob存储提供基于时间的保留策略。另一种选择是实施根据保留策略删除数据的自定义解决方案。一个例子是数据生命周期管理（DLM），它管理数据生命周期活动。该解决方案是使用Azure数据工厂、Microsoft Entra ID和Azure密钥库等服务设计的。

有关更多信息，请参阅使用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密钥库、Azure托管HSM或第三方密钥管理解决方案。

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

要求3.5

记录并实施程序，以保护用于保护存储的持卡人数据免受泄露和滥用的密钥。

你的责任

这些要点在以下小节中进行了描述：

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

要求3.5.1

仅对服务提供商的附加要求：维护加密架构的文档化描述，包括：

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

你的责任

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

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

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

要求3.5.2

将加密密钥的访问权限限制在必要的最少数量的保管人。

你的责任

尽量减少有权访问密钥的人数。如果您正在使用任何基于组的角色分配，请设置一个定期审核流程来审查有权访问的角色。当项目团队成员更改时，必须从权限中删除不再相关的帐户。只有合适的人才能访问。使用Microsoft Entra ID访问评论定期查看组成员资格。

考虑删除长期权限，转而支持即时（JIT）角色分配、基于时间的角色激活和基于审批的角色激活。例如，考虑使用特权身份管理。

要求3.5.3

始终以以下一种（或多种）形式存储用于加密/解密持卡人数据的密钥和私钥：

使用至少与数据加密密钥一样强的密钥加密密钥进行加密，并且该密钥与数据加密加密密钥分开存储
在安全的加密设备内（如硬件（主机）安全模块（HSM）或PTS批准的交互点设备）
根据行业公认的方法，至少有两个完整的关键组成部分或关键股份
 

你的责任

PCI-DSS 3.2.1工作负载需要使用多个加密密钥作为静态数据保护策略的一部分。数据加密密钥（DEK）用于加密和解密CHD，但您需要负责额外的密钥加密密钥（KEK）来保护该DEK。您还负责确保KEK存储在加密设备中。

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

要求3.6

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

你的责任

（适用于：要求3.6.1、要求3.6.2、要求3.6.3、要求3.2.4）

如果您使用Azure密钥库存储密钥、证书和连接字符串等机密，请保护其免受未经授权的访问。Microsoft Defender for Key Vault检测到可疑的访问尝试并生成警报。您可以在Microsoft Defender for Cloud中查看这些警报。有关详细信息，请参阅Microsoft Defender For Key Vault。

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

• Cryptographic Key Management.
• SP 800-133 Rev. 2, Recommendation for Cryptographic Key Generation
• SP 800-57 Part 1 Rev. 5, Recommendation for Key Management

另请参见Microsoft Defender for Key Vault。

要求3.6.7

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

你的责任

对所有密钥存储启用诊断。将Azure Monitor用于密钥库。它收集日志和指标并将其发送到Azure Monitor。有关详细信息，请参阅使用Azure Monitor For key vault监控密钥保管库服务。
为所有消费者授予只读权限。
没有管理用户或主体的长期权限。相反，使用即时（JIT）角色分配、基于时间的角色激活和基于审批的角色激活。
通过将日志和警报集成到安全信息和事件管理（SIEM）解决方案（如Microsoft Sentinel）中来创建集中视图。
对警报和通知采取行动，特别是对意外更改。
 

要求3.6.8

要求加密密钥保管人正式承认他们理解并接受其密钥保管人的责任。

你的责任

维护描述关键管理运营中负责方责任的文件。

要求3.7

确保保护存储的持卡人数据的安全政策和操作程序得到记录、使用，并为所有受影响方所知。

你的责任

创建文档作为一般声明，并为所有角色提供一系列最新的角色指南。进行新员工培训和持续培训。

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

要求4——在开放的公共网络上加密持卡人数据的传输

你的责任

 

Requirement	Responsibility
Requirement 4.1	Use strong cryptography and security protocols (for example, TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including the following:
Requirement 4.2	Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, SMS, chat, etc.).
Requirement 4.3	Ensure that security policies and operational procedures for encrypting transmissions of cardholder data are documented, in use, and known to all affected parties.

 

要求4.1

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

你的责任
通过公共互联网传输的持卡人数据（CHD）必须加密。数据必须使用TLS 1.2（或更高版本）进行加密，并减少对所有传输的密码支持。不支持任何数据传输服务上的非TLS到TLS重定向。

你的设计应该有一个TLS终结点的战略链。当数据通过网络跳时，在需要数据包检查的跳处维护TLS。至少，在集群的入口资源处有最终的TLS终止点。考虑在集群资源中更进一步。

说明数据加密的图表。

使用Azure策略管理资源的创建：

• 拒绝创建任何非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）的策略时尤其如此。以下是一些领域：

• 公共互联网入口点。一个例子是Azure应用程序网关对TLS密码的支持。
• 网络在外围网络和工作负载吊舱之间跳转。
• Pod到Pod加密（如果实现）。这可能包括有关服务网格配置的详细信息。
• Pod到存储（如果是架构的一部分）。
• Pod到外部服务、使用TLS的Azure PaaS服务、支付网关或欺诈检测系统。

必须对在受监管环境中工作的人进行教育、告知和激励，以支持安全保证。从政策角度来看，这对于参与审批流程的人来说尤其重要。

下一步

保护所有系统免受恶意软件的侵害，并定期更新防病毒软件或程序。开发和维护安全的系统和应用程序。