PCI DSS 4.0.1 摘要的 AKS 管控群集

本系列中提供的指南在所有设计选择中都包含了精心构建的原则。 本文总结了这些选择。

本文将结束本系列。 阅读 简介。

即将推出 GitHub 徽标 参考实现：适用于 PCI DSS 4.0.1 的受管制工作负载参考实现的 Azure Kubernetes 服务（AKS）基线群集目前正在更新，即将推出。 此实现将演示一个受监管的基础结构，该基础结构演示了 CDE 中各种网络安全控制的使用。 这包括 Azure 原生的网络控件和 Kubernetes 原生的控件。 它还将包括一个应用程序，用于演示环境与示例工作负荷之间的交互。 本文的重点在于基础结构。 该示例不会指示实际 PCI-DSS 4.0.1 工作负荷。

Reliability

监管环境的可靠性需要可预测，以便可以一致地解释它们以进行审核。 遵循 可靠性原则中提供的基本指南。 以下部分总结了受管制环境的可靠性最佳做法。

恢复目标和灾难恢复

由于受管制工作负荷中处理的数据的敏感性质，恢复目标和恢复点目标（RPO）对于定义至关重要。 CHD 的可接受损耗是多少？ CDE 中的恢复工作仍符合标准要求。 预期失败，并为那些与角色、职责和合理数据访问保持一致的故障制定明确的恢复计划。 现场问题并不是偏离任何法规的理由。 这在完全灾难恢复的情况下尤其重要。 制定清晰的灾难恢复文档，使其符合相关要求，并将对 CDE 或 CHD 的意外访问降至最低。 恢复后，请始终查看恢复过程步骤，以确保不会发生意外的访问。 记录这些实例的业务理由。

Recovery

向体系结构添加复原和恢复策略可以防止需要临时访问 CDE。 系统应该能够在定义的 RPO 上自行恢复，而无需直接人工干预。 这样，你便可以消除对 CHD 的不必要的暴露，即使是那些有权获得紧急访问权限的个人。 恢复过程必须可审核。

查看安全风险，因为它们可能是工作负荷停机和数据丢失的源。 对安全性的投资也对工作负荷可靠性产生影响。

操作流程

可靠性扩展到 CDE 及其相邻的所有操作过程。 对于镜像构建和跳板机管理等方面，定义清晰、实现自动化并经过测试的流程，是良好架构解决方案的重要组成部分。

安全性

遵循 安全设计原则中提供的基本指南。 以下部分总结了受监管环境的安全最佳做法。

Governance

治理实现由 PCI DSS 4.0.1 中的合规性要求驱动。 这会影响维护分段、访问资源、检测漏洞以及最重要的是保护客户数据的技术控制。 PCI DSS 4.0.1 强调在云和容器环境中共同负责、持续监视和使用自动化工具进行清单和配置管理。

持续合规性监视：与以前版本的定期评估方法不同，PCI DSS 4.0.1 需要持续验证安全控制。 这与通过Azure Policy实现云原生监视功能（如Azure Monitor、Microsoft Defender for Cloud和自动化策略实施）保持一致。

基于风险的范围：标准现在允许基于实际数据流和风险评估进行更动态的范围，这尤其适用于容器化工作负荷，其中组件可能临时和动态协调。

企业分段策略

为了保持完全隔离，我们建议在独立订阅中部署受监管的基础结构。 如果您有多个出于合规要求所必需的订阅，请考虑将它们归入某个管理组层次结构中，以便在范围内的订阅中统一应用相关的 Azure 策略。 在订阅中，在订阅级别应用相关的Azure策略，以捕获应应用于持卡人数据环境（CDE）中的所有群集的广泛策略。 在资源组级别应用相关的Azure策略，以捕获应用于特定群集实例的策略。 这些策略构建着陆区域的核心防护措施。

在操作和连接方面，将 PCI 工作负荷（范围内）与其他（范围外）工作负荷隔离开来。 可以通过部署单独的群集或使用分段策略来维护隔离来创建隔离。 例如，群集使用单独的节点池，以便工作负荷永远不会共享节点虚拟机（VM）。

策略执行

通过启用Azure策略来强制实施安全控制。 例如，在此受监管的体系结构中，可以阻止持卡人数据环境的配置错误。 可以应用不允许 VM 节点上公共 IP 分配的Azure策略。 此类分配会被检测到，并被报告或阻止。

有关可以为 AKS 启用的策略的信息，请参阅Azure Policy Azure Kubernetes 服务 (AKS)的内置定义。

Azure为大多数服务提供多个内置策略。 查看Azure Policy内置策略定义，并根据需要应用它们。

合规性监视

必须系统地监视和维护合规性。 执行常规合规性证明。 了解云资源是否符合性将有助于准备证明和审核。

利用Microsoft Defender for Cloud中的法规合规性仪表板。 通过持续监视仪表板，可以跟踪工作负荷的符合性状态。

Azure门户中示例合规性监视仪表板的屏幕截图。

网络安全

在中心-辐射型拓扑中，为每个实体分别设置独立的虚拟网络，可在整个网络架构中实现基本的网络分段。 每个网络进一步细分为子网。

AKS 群集构成了 CDE 的核心。 不能从公共 IP 地址访问它，并且必须保护连接。 CDE 的典型流入和流出可分为如下几类：

  • 进入集群的入站流量。
  • 集群的出站流量。
  • Pod 之间的集群内流量。

为了满足受管制环境的要求，群集将部署为专用群集。 在此模式下，传入和传出公共 Internet 的流量受到限制。 即使是与 AKS 托管的 Kubernetes API 服务器的通信也是专用的。 通过严格的网络控制和 IP 防火墙规则进一步增强安全性：

  • 网络安全组（NSG）可帮助保护网络内资源之间的通信。
  • Azure 防火墙筛选云资源、Internet 和本地之间的任何出站流量。
  • Azure 应用程序网关与 Azure Web 应用程序框架集成，以筛选来自Azure 应用程序网关截获的 Internet 的所有入站流量。
  • Kubernetes NetworkPolicy 只允许群集中的 Pod 之间的某些路径。
  • Azure 专用链接连接到其他Azure平台即服务（PaaS）服务（例如Azure 密钥保管库和Azure 容器注册表），以便执行操作任务。

监视过程已到位，以确保流量按预期流动，并检测到并报告任何异常。

有关网络安全的详细信息，请参阅 网络分段。

数据安全

PCI DSS 4.0.1 要求所有持卡人数据（CHD）无论是在传输过程中还是在存储时，都绝不能以明文形式存在。

由于此体系结构和实现侧重于基础结构，而不是工作负荷，因此不会演示数据管理。 以下部分概述了一些精心构建的建议。

静止的数据

数据必须通过行业标准加密算法进行加密。

  • 不要将数据存储在持卡人环境中。
  • 在存储层之外进行加密。
  • 仅将加密数据写入存储介质。
  • 不要将密钥存储在存储层中。

使用强加密对Azure 存储中的所有数据进行加密和解密。 首选自管理加密密钥。

如果需要暂时存储数据，请将相同的注意事项应用于该数据。 强烈建议启用 AKS 的 主机加密功能 。 可以使用内置Azure策略强制加密临时数据。

选择存储技术时，请浏览保留功能。 请确保在配置的时间过期时安全地删除所有数据。

该标准还要求不存储敏感的身份验证数据（SAD）。 请确保数据不会在日志、文件名、缓存和其他数据中公开。

传输中的数据

与 CDE 交互的实体的所有通信都必须通过加密通道进行。 PCI DSS 4.0.1 通过更新的密码套件和协议标准增强了加密要求。

  • 仅允许 HTTPS 流量流入 CDE。 在此体系结构中，Azure 应用程序网关拒绝端口 80 上的所有流量。
  • 最好不要在 CDE 外部加密和解密数据。 如果这样做，请考虑该实体是 CDE 的一部分。
  • 在 CDE 中，使用 mTLS 在 Pod 之间提供安全通信。 可以选择为此实现服务网格。
  • 仅允许安全密码和 TLS 1.2 或更高版本。 PCI DSS 4.0.1 提供有关可接受的加密协议和密码套件的更新指南。
  • PCI DSS 4.0.1 需要更严格的密钥生命周期管理，包括自动密钥轮换和硬件安全模块（HSM）集成（如果适用）。

Identity

设计访问策略时，请遵循以下安全原则：

  • 从零信任策略开始。 根据需要酌情处理例外情况。
  • 授予最低权限 - 只需足够完成任务即可。
  • 尽量减少常设访问权限。

PCI DSS 4.0.1 显著增强了身份验证要求，要求对持卡人数据环境的所有访问（包括管理访问权限和所有非控制台访问）进行多重身份验证（MFA）。

Kubernetes 基于角色的访问控制 （RBAC） 管理对 Kubernetes API 的权限。 AKS 支持这些 Kubernetes 角色。 AKS 与Microsoft Entra ID完全集成。 可以将Microsoft Entra标识分配给角色，并利用其他功能。

零信任访问

Kubernetes RBAC、Azure RBAC 和 Azure 服务默认实现全部拒绝。 请谨慎覆盖该设置，仅允许确有需要访问权限的实体进行访问。 实现零信任的另一个区域是禁用对群集节点的 SSH 访问。

最低特权

可以为 Azure 资源和 pod 使用托管标识，并将其权限范围限定为预期任务所需。 例如，Azure 应用程序网关必须具有从 Azure 密钥保管库 获取机密（TLS 证书）的权限。 它不得具有修改机密的权限。

尽量减少常设访问权限

使用即时 Microsoft Entra 组成员资格，最大限度减少长期访问权限。 使用Microsoft Entra ID中的条件访问策略强化控制。 此选项支持许多用例，例如多重身份验证、将身份验证限制为由Microsoft Entra租户管理的设备，或阻止非典型登录尝试。

机密管理

将机密、证书、密钥和密码存储在 CDE 外部。 您可以使用 Kubernetes 原生 Secret 对象或托管式密钥存储，例如 Azure 密钥保管库。 使用托管存储有助于执行机密管理任务，例如密钥轮换和证书续订。

确保对密钥存储的访问具有网络和访问控制的组合。 启用托管标识时，群集必须针对密钥保管库进行身份验证才能获取访问权限。 此外，与密钥存储的连接不得通过公共 Internet 进行。 使用专用网络，例如专用链接。

成本优化

遵循 成本优化原则中提供的基本指南。

由于合规性要求和严格的安全控制，明显的权衡是成本。 建议使用 定价计算器建立初始估算值。

下图提供了此体系结构使用的主要资源的成本影响的高级表示形式：

体系结构中成本管理的关系图。

主要驱动程序是构成节点池和Azure 防火墙的虚拟机规模集。 另一个参与者是Log Analytics。 还存在与Microsoft Defender for Cloud相关的增量成本，具体取决于所选的计划。

清楚地了解什么是服务价格。 Azure跟踪按流量计费的使用情况。 下图详细介绍了此体系结构的Azure 防火墙：

说明 Azure 防火墙 示例中成本管理的图示。

与某些资源（如Azure 防火墙）相关的成本可以分散在多个业务部门或应用程序中。 优化成本的另一种方法可能是在组织内托管多租户群集，从而最大程度地提高工作负荷多样性的密度。 但是，我们不建议对受监管工作负载采用这种方法。 始终将合规性和分段优先于成本优势。

为了保持在预算限制范围内，控制成本的一些方法是调整Azure 应用程序网关基础结构、设置自动缩放的实例计数，并降低日志输出，只要它们仍符合 PCI DSS 4.0.1 所需的审核线索。 始终根据设计的其他方面做出的权衡来评估这些选择，以便满足 SLA 要求。 例如，你是否仍然能够进行适当扩展，以应对流量高峰？

创建一组Azure资源时，应用标记，以便跟踪这些资源的成本。 使用成本管理工具（如Azure 顾问和Microsoft 成本管理）来跟踪和分析成本。

请考虑启用 AKS 成本分析 ，以便通过 Kubernetes 特定构造进行精细的群集基础结构成本分配。

卓越运营

遵循 卓越运营原则中提供的基本指导。 以下部分总结了针对受监管环境的卓越运营最佳做法。

角色分离

对受管制环境执行明确的职责分离是关键。 根据工作负荷的需求以及与 CDE 的交互，定义角色和职责。 例如，对于与群集和依赖服务相关的操作，可能需要基础结构操作员或站点可靠性工程师（SRE）角色。 该角色负责维护安全性、隔离、部署和可观测性。 对这些定义进行正式化，并确定这些角色所需的权限。 例如，SRE 对于群集访问具有很高的特权，但需要对工作负荷命名空间具有读取访问权限。

工作负荷隔离

PCI DSS 4.0.1 需要在操作方面将 PCI 工作负荷与其他工作负荷隔离。 在此实现中，作用域内和作用域外工作负荷在两个单独的用户节点池中分段。 适用于作用域内的应用程序开发人员和范围外工作负荷的开发人员可能具有不同的权限集。 此外，将有单独的质量大门。 例如，范围内代码受制于维护符合性和证明，而范围外代码则不受约束。 还需要有单独的生成管道和发布管理过程。

PCI DSS 4.0.1 引入了安全软件开发的综合要求，包括：

  • 集成到 CI/CD 流水线中的自动化安全测试。
  • 静态和动态应用程序安全测试（SAST/DAST）。
  • 部署前的容器映像漏洞扫描。
  • 第三方组件依赖关系扫描
  • 具有安全重点的代码评审过程。
  • 针对开发团队的安全编码培训。

操作元数据

PCI DSS 4.0.1 标准的要求 12 要求你维护有关工作负荷清单和人员访问文档的信息。 强烈建议使用Azure标记，因为可以使用Azure资源、资源组和订阅对环境信息进行排序。

维护有关属于基础结构和工作负荷的已批准解决方案的信息。 这包括您带入 CDE 的 VM 映像、数据库和您选择的第三方解决方案的列表。 甚至可以通过生成服务目录来自动执行该过程。 它通过在特定的配置中使用那些批准的解决方案来提供自助服务部署，该解决方案遵循正在进行的平台操作。

Observability

为了满足要求 10，CDE 中的可观测性对于符合性至关重要。 活动日志提供有关与帐户和机密管理、诊断设置管理、服务器管理以及其他资源访问操作相关的信息。 所有日志都记录有日期、时间、标识和其他详细信息。 通过在Azure Monitor日志中配置数据保留和存档策略，将日志保留最多一年。

确保日志只能由需要日志的角色访问。 Log Analytics 和 Microsoft Sentinel 支持各种基于角色的访问控制来管理审核线索访问。

响应和修正

Azure 监视服务、Azure Monitor 和 Microsoft Defender for Cloud 可以在检测到异常活动时生成通知或警报。 这些警报包括上下文信息，例如严重性、状态和活动时间。 生成警报时，制定修正策略并查看进度。 建议在安全信息和事件管理（SIEM）解决方案中集中数据，因为集成数据可以提供丰富的警报上下文。

在Microsoft Defender for Cloud的安全警报视图中，可以访问Microsoft Defender for Cloud在资源上检测到的所有警报。 建立分诊流程来处理该问题。 请与安全团队协作，了解向工作负荷所有者提供相关警报的方式。

性能效率

遵循 性能效率原则中提供的基本指南。 以下部分汇总了受监管环境的性能效率最佳做法。

Scaling

观察环境如何适应不断变化的需求，将指示环境在高负载下的预期运行时行为。 工作负荷中的自动缩放资源将最大程度地减少 CDE 中的人工交互。 增加的安全优势是随时减少攻击面。 借助支持缩减为零方法的资源，您可以最大化收益。 例如，AKS 支持将用户节点池缩减为 0。 有关详细信息，请参阅 将用户节点池缩放为 0。

Partitioning

分区是受监管工作负荷性能效率的关键因素。 使用离散组件可以明确定义责任，并帮助进行精确的控制，例如网络策略。 与任何分段策略类似，分区隔离组件并控制爆炸半径对意外故障或系统泄露的影响。

无共享体系结构

无共享体系结构旨在删除共置工作负载之间的争用。 此外，这是删除单一故障点的策略。 在受管制的环境中，组件需要通过逻辑或物理边界进行隔离。 这与无共享体系结构保持一致，从而带来可伸缩性优势。 它能够针对各个组件实施相关的安全控制措施，并提供更严格的审计能力。

轻型工作负载

工作负荷的复杂性很难记录和审核。 应追求简洁，因为这样既有性能优势，也便于审核监管要求。 重新考虑那些范围超过实际所需的选择，因为这会增加攻击面，并提高被滥用或配置错误的可能性。

整合一切

在Azure Kubernetes 服务上实现 PCI DSS 4.0.1 符合性需要一种全面的方法，可解决架构良好的框架的各个方面，同时满足标准的特定要求。 本系列提供了跨多个域的详细指导，从网络安全和数据保护到标识管理和持续监视。

关键结论

在 AKS 上符合 PCI DSS 4.0.1 的过程涉及几个关键注意事项：

  • 基础结构即基础：安全、合规的 AKS 基础结构至关重要，但不够。 体系结构必须支持标准所需的安全控制、监视功能和操作过程。
  • 持续符合性：与以前的版本不同，PCI DSS 4.0.1 强调持续验证和监视，而不是时间点评估。 这需要自动化工具、实时警报和主动安全措施。
  • 共同责任：虽然Azure提供安全平台，但组织仍负责正确配置和维护安全控制、实施适当的访问策略，并确保持续合规。
  • 精心构建的原则：安全性、可靠性、成本优化、卓越运营和性能效率必须一起考虑在一起，才能创建可持续的合规解决方案。

集成点

本系列中讨论的各种组件协同工作，以创建全面的合规性框架：

  • 网络安全 为隔离持卡人数据环境奠定了基础。
  • 数据保护 可确保 CHD 在其整个生命周期内正确加密和管理。
  • 加密和密钥管理 可实现敏感数据的安全存储和传输。
  • 借助增强型 MFA 的身份和访问管理可控制谁能够访问 CDE。
  • 恶意软件防护 可抵御可能破坏环境的威胁。
  • 监视和日志记录 可查看 CDE 中的所有活动。
  • 持续安全监视 支持实时威胁检测和响应。
  • 安全策略 为持续合规奠定治理框架。

后续步骤

若要开始在 AKS 上实现 PCI DSS 4.0.1 符合性，请执行以下步骤：

第 1 阶段：基础和规划（第 1-4 周）

  1. 评估当前状态：根据 PCI DSS 4.0.1 要求评估现有 AKS 基础结构。
  2. 定义范围：明确确定哪些组件在 PCI DSS 符合性范围内。
  3. 查看实施指南：研究本系列每篇文章中提供的详细指南。
  4. 规划体系结构：设计中心辐射型网络拓扑和安全控制。
  5. 建立治理：定义角色、职责和审批流程。

阶段 2：基础结构实施（第 5-12 周）

  1. 部署参考体系结构：从 AKS 基线体系结构开始，并应用 PCI DSS 增强功能。
  2. 实现网络安全：配置专用群集、防火墙和网络策略。
  3. 设置标识管理：配置Azure AD 集成和 MFA 要求。
  4. 部署监视基础结构：设置Azure Monitor、Log Analytics和Microsoft Defender for Cloud。
  5. 实现数据保护：配置静态加密和传输中加密。

第 3 阶段：安全性和合规性（第 13-20 周）

  1. 配置安全策略：应用 Azure Policy 和 Kubernetes 策略以满足合规要求。
  2. 实现密钥管理：设置Azure 密钥保管库和加密控制。
  3. 部署恶意软件防护：配置安全扫描和威胁检测。
  4. 建立监视：实现持续的安全监视和警报。
  5. 测试安全控制：验证所有安全措施是否正常工作。

阶段 4：验证和维护（第 21-24 周）

  1. 执行安全测试：执行渗透测试和漏洞评估。
  2. 验证符合性：确保满足所有 PCI DSS 4.0.1 要求。
  3. 记录所有内容：创建用于审核目的的综合文档。
  4. 培训员工：确保所有人员都了解其角色和职责。
  5. 建立持续性流程：实施持续监控和维护程序。

正在进行的操作

初始实施后，通过以下方式保持合规性：

  • 定期安全评估：进行季度安全评审和年度合规性评估。
  • 持续监视：监视所有安全控制并及时响应警报。
  • 更新管理：使所有系统和安全控制保持最新。
  • 事件响应：维护和测试事件响应过程。
  • 文档维护：使所有文档保持最新且可访问。

获取帮助

有关在 AKS 上实现 PCI DSS 4.0.1 合规的更多支持：

  • Microsoft FastTrack：联系面向 Azure 的 Microsoft FastTrack，以获取实施指导。
  • Microsoft合作伙伴：与专门从事合规性的认证Microsoft合作伙伴合作。
  • 专业服务：考虑为复杂的实现提供专业服务。
  • 社区资源：利用 Azure 和 Kubernetes 社区实现最佳做法。

保持更新

PCI DSS 标准随着时间推移而演变。 随时了解更新和更改：

  • 订阅 PCI SSC 资讯：关注 PCI 安全标准委员会，获取最新动态。
  • 监视Azure更新：随时了解新的Azure安全功能和功能。
  • 与社区互动：参与安全性和合规性论坛。
  • 定期培训：确保团队随时了解安全最佳做法。

本系列提供有关在 AKS 上实现 PCI DSS 4.0.1 符合性的综合指南。 了解更多信息：

PCI DSS 4.0.1 系列文章：

Azure文档：

合规性资源：

请记住，实现和维护 PCI DSS 4.0.1 符合性是一个持续的过程，需要持续关注安全、监视和卓越运营。 本系列中的指南提供了基础，但具体实现可能需要根据独特的要求和环境进行其他注意事项。

  • Last updated on