本文介绍根据支付卡行业数据安全标准（PCI-DSS 4.0.1）配置的 Azure Kubernetes 服务（AKS）群集的标识和访问管理注意事项。
本文是一系列文章的其中一篇。 阅读 简介。
Kubernetes 具有本机基于角色的访问控制（RBAC），用于管理对 Kubernetes API 的权限。 有几个内置角色具有 Kubernetes 资源的特定权限或作。 Azure Kubernetes 服务（AKS）支持这些内置角色和自定义角色进行精细控制。 这些作可以通过 Kubernetes RBAC 授权或拒绝给用户。
此体系结构和实现不旨在提供对本地资源或数据中心的物理访问的控制。 在 Azure 中托管 CDE 的一个好处，而不是在边缘或数据中心托管平台，即限制物理访问主要通过 Azure 数据中心安全性进行处理。 组织在管理物理硬件方面没有任何责任。
注释
本文已针对 PCI DSS 4.0.1 进行了更新。 主要更改包括对自定义控制方法的支持、增强的多重身份验证（MFA）、更新的加密要求、扩展的监视和日志记录，以及专注于持续安全性和风险管理。 确保查看官方 PCI DSS 4.0.1 文档 ，了解完整详细信息和未来日期的要求。
重要
该指南和随附的实现基于中心辐射型网络拓扑的 AKS 基线体系结构为基础。 中心虚拟网络包含用于控制出口流量的防火墙、来自本地网络的网关流量，以及用于维护的第三个网络。 辐射虚拟网络包含 AKS 群集，该群集提供卡持有者环境（CDE），并托管 PCI DSS 工作负荷。
参考实现：适用于 PCI DSS 4.0.1 的受管制工作负载参考实现的 Azure Kubernetes 服务（AKS）基线群集目前正在更新，即将推出。 此实现将演示具有标识和访问控制的受监管基础结构，并提供一个Microsoft支持实时（JIT）访问和条件访问模型的条目 ID 支持的专用群集，以便说明目的。 它还将包括一个应用程序，用于演示环境与示例工作负荷之间的交互。 本文的重点在于基础结构。 该示例不会指示实际 PCI-DSS 4.0.1 工作负荷。
实施强访问控制措施
要求 7：根据业务需求限制对持卡人数据的访问
AKS 功能支持
AKS 与作为标识提供者的 Microsoft Entra ID 完全集成。
无需管理 Kubernetes 的单独用户标识和凭据。 可以为 Kubernetes RBAC 添加Microsoft Entra 用户。 通过此集成，可以将角色分配给 Microsoft Entra 用户。 通过使用 Microsoft Entra 标识，可以使用各种内置角色，例如查看器、编写者、服务管理员和群集管理员。 还可以创建自定义角色，以便进行更精细的控制。
默认情况下，Azure RBAC 设置为拒绝所有访问权限，因此在未授予权限的情况下无法访问资源。 AKS 限制对 AKS 工作节点的 SSH 访问，并使用 AKS 网络策略来控制对 Pod 中工作负荷的访问。
有关详细信息，请参阅 使用 Azure RBAC 进行 Kubernetes 授权。
你的责任
| Requirement | 职责 |
|---|---|
| 要求 7.1 | 将系统组件和持卡人数据的访问权限限制为只有那些工作需要此类访问的个人。 |
| 要求 7.2 | 为系统组件建立访问控制系统，该系统组件根据用户需要知道来限制访问，并设置为“全部拒绝”，除非特别允许。 |
| 要求 7.3 | 确保记录用于限制持卡人数据访问的安全策略和作过程，以供所有受影响的方记录、使用和已知。 |
要求 7.1
PCI DSS 4.0.1 允许自定义的访问控制方法，前提是满足安全目标并充分记录并证明该方法合理。 如果组织能够演示等效或更好的安全结果，则组织可以实施替代控制。
将系统组件和持卡人数据的访问权限限制为只有那些工作需要此类访问的个人。
你的责任
请考虑采用以下最佳做法：
- 确保实现符合组织的要求，以及有关标识管理的合规性要求。
- 最大程度地减少长期权限，尤其是对于关键影响帐户。
- 遵循最低特权访问原则。 提供足够的访问权限来完成任务。
要求 7.1.1
PCI DSS 4.0.1 阐明了对每个角色持续评审和访问需求文档的需求，并要求在工作职能发生变化时定期评审和更新访问权限。
定义每个角色的访问需求，包括：
- 每个角色都需要访问其作业功能的系统组件和数据资源。
- 访问资源所需的权限级别（例如用户、管理员等）。
你的责任
根据作用域内组件及其与 Azure 资源的交互所需的任务和职责定义角色。 可以从广泛的类别开始，例如：
- 按 Azure 管理组、订阅或资源组的范围。
- 适用于工作负荷或订阅的 Azure Policy。
- 容器作。
- 机密管理。
- 生成和部署管道。
虽然围绕这些领域的角色和职责的定义可能与团队结构相关联，但请专注于工作负荷的要求。 例如，确定负责维护安全、隔离、部署和可观测性的人员。 下面是一些责任示例：
- 确定应用程序安全性、Kubernetes RBAC、网络策略、Azure 策略和其他服务的通信配置。
- 配置和维护 Azure 防火墙、Web 应用程序防火墙（WAF）、网络安全组（NSG）和 DNS。
- 监视和修正服务器安全性、修补、配置和终结点安全性。
- 设置使用 RBAC 的方向，Microsoft Defender for Cloud、管理员保护策略和 Azure Policy 来管理 Azure 资源。
- 确定事件监视和响应团队。 使用安全信息和事件管理（SIEM）系统（如 Microsoft Sentinel 或 Microsoft Defender for Cloud）调查和修正安全事件。
然后，通过确定角色在工作负荷和基础结构方面所需的访问级别来正式化定义。 下表提供了几个角色、其职责和可能需要的访问级别的示例：
| 角色 | 职责 | 访问级别 |
|---|---|---|
| 应用程序所有者 | • 定义和确定与业务成果相符的功能的优先级。 • 了解功能如何影响工作负载的合规性范围，并平衡客户数据保护和所有权与业务目标。 |
读取对应用程序发出的日志和指标的访问权限。 他们不需要访问工作负荷或群集的权限。 |
| 应用程序开发人员 | • 开发应用程序。 所有应用程序代码都受培训和质量入口的约束，并遵循合规性、证明和发布管理流程。 • 可以管理生成管道，但通常不管理部署管道。 |
读取对工作负荷范围内的 Kubernetes 命名空间和 Azure 资源的访问权限。 不对部署或修改系统的任何状态进行写入访问。 |
| 应用程序操作员（或 SRE） | • 深入了解代码库、可观测性和作。 • 执行实时站点会审和故障排除。 • 与应用程序开发人员一起，提高应用程序的可用性、可伸缩性和性能。 • 管理“最后一英里”部署管道，并帮助管理生成管道。 |
应用程序范围内的高特权，其中包括相关的 Kubernetes 命名空间和 Azure 资源。 可能有权访问 Kubernetes 群集的一部分。 |
| 基础结构所有者 | • 设计经济高效的体系结构，包括其连接和组件的功能。 范围可以包括云和本地服务。 • 确定功能数据保留、业务连续性功能和其他功能。 |
访问平台日志和成本中心数据。 群集中不需要任何访问权限。 |
| 基础结构操作员（或 SRE） | • 与群集和依赖服务相关的作。 • 为部署工作负荷的群集生成、部署和启动管道。 • 设置目标节点池，以及预期的大小调整和缩放要求。 • 监视容器托管基础结构和依赖服务的运行状况。 |
读取对工作负荷命名空间的访问权限。 群集的高度特权访问。 |
| 策略、安全所有者 | • 具有安全或法规合规性专业知识。 • 定义保护公司员工、其资产和公司客户的安全性和法规合规性的策略。 • 与所有其他角色协作，确保策略在每一个阶段都应用和审核。 |
对工作负荷和群集的读取访问权限。 此外，还可以访问日志和审核数据。 |
| 网络运营商 | • 分配企业范围的虚拟网络和子网。 • 配置和维护 Azure 防火墙、WAF、NSG 和 DNS 配置。 |
网络层中的高特权。 群集中没有写入权限。 |
要求 7.1.2
PCI DSS 4.0.1 强调尽量减少站立特权，并鼓励使用实时（JIT）访问和条件访问策略。 需要增强对特权访问的监视和警报。
将特权用户 ID 的访问权限限制为执行作业职责所需的最低权限。
你的责任
根据作业功能，尽量尽量减少访问，而不会造成中断。 请考虑采用以下最佳做法：
- 减少每个标识所需的访问。 标识应有足够的访问权限来完成其任务。
- 尽量减少站立权限，尤其是对有权访问作用域内组件的严重影响标识。
- 尽可能添加额外的限制。 一种方法是基于访问条件提供条件访问。
- 定期审查和审核订阅中具有访问权限的用户和组，甚至进行读取访问。 避免邀请外部标识。
要求 7.1.3
必须持续审查和更新访问分配，以反映人员或工作职能的变化。 PCI DSS 4.0.1 要求记录和对齐所有访问分配。
根据个人人员的工作分类和职能分配访问权限。
你的责任
根据个人明确分配的作业职责确定权限。 避免参数，如系统或员工的任期。 向单个用户或组授予访问权限。
下面是一些示例作业分类及其关联的角色：
| 角色 | 作业分类 |
|---|---|
| 应用程序所有者 | 产品所有者定义工作负荷的范围并确定功能的优先级。 平衡客户数据保护和所有权与业务目标。 需要访问报表、成本中心或 Azure 仪表板。 群集内或群集级权限无需访问。 |
| 应用程序开发人员 | 软件工程师设计、开发和容器化应用程序代码。 一个组，在 Azure 中定义的作用域（例如 Application Insights）和工作负荷命名空间内具有永久读取权限。 预生产环境和生产环境之间的这些范围和权限可能有所不同。 需要访问应用程序代码、开发工具和 CI/CD 管道。 生产环境无需访问。 |
| 应用程序运算符 | 站点可靠性工程师执行实时站点会审、管理管道和设置应用程序基础结构。 组 A 在其分配的命名空间中具有完全控制权。 不需要站立权限。 组 B 对工作负荷执行日常作，并且可以在其分配的命名空间内具有站立权限，但不具有高度特权。 |
| 基础结构操作员 | 群集操作员设计和将可靠且安全的 AKS 群集部署到平台。 负责维护群集的上空时间。 组 A 在其分配的命名空间中具有完全控制权。 不需要站立权限。 组 B 对工作负荷执行日常作，并且可以在其分配的命名空间内具有站立权限，但不具有高度特权。 |
| 基础结构操作员 | 网络工程师分配企业范围的虚拟网络和子网、本地到云连接和网络安全。 |
要求 7.1.4
PCI DSS 4.0.1 要求经授权方批准和记录所有特权分配和更改，并且审批过程是可审核的。
要求经授权方批准，指定所需权限。
你的责任
有一个封闭的过程，用于批准角色和权限的更改，包括初始分配特权。 确保记录这些审批并可供检查。
要求 7.2
PCI DSS 4.0.1 要求访问控制系统支持持续监视和提醒未经授权的访问尝试，并定期审查和更新所有访问控制策略。
为系统组件建立访问控制系统，该系统组件根据用户需要知道来限制访问，并设置为“全部拒绝”，除非特别允许。
你的责任
遵循 要求 7.1 后，应已评估适用于组织和工作负荷的角色和职责。 范围内体系结构中的所有组件都必须具有受限的访问权限。 这包括运行工作负荷、数据存储、网络访问的 AKS 节点，以及参与处理卡持有者数据的其他所有服务（CHD）。
根据角色和职责，将角色分配给基础结构的基于角色的访问控制（RBAC）机制，例如：
- Kubernetes RBAC：一种本机 Kubernetes 授权模型，用于控制对 Kubernetes 控制平面的访问，通过 Kubernetes API 服务器公开。 此权限集定义可以使用 API 服务器执行的作。 例如，可以拒绝用户创建甚至列表 Pod 的权限。
- Azure RBAC：Microsoft基于 Entra ID 的授权模型，用于控制对 Azure 控制平面的访问。 这是Microsoft Entra 租户与 Azure 订阅的关联。 使用 Azure RBAC，可以授予创建 Azure 资源的权限，例如网络、AKS 群集和托管标识。
假设需要向群集操作员授予权限（映射到基础结构操作员角色）。 分配基础结构操作员职责的所有人员都属于Microsoft Entra 组。 在 7.1.1 中建立时，此角色需要群集中的最高特权。 Kubernetes 具有满足这些要求的内置 RBAC 角色，例如 cluster-admin。 需要通过选择内置角色来创建角色绑定，将基础结构操作员 cluster-admin 的 Microsoft Entra 组绑定到该组。 如果内置角色不满足你的要求（例如，它们可能过于宽松），则可以为绑定创建自定义角色。
参考实现使用本机 Kubernetes RBAC 演示前面的示例。 可以使用 Azure RBAC 实现相同的关联。 有关详细信息，请参阅 使用 Kubernetes 基于角色的访问控制来控制对群集资源的访问，并在 Azure Kubernetes 服务（AKS）中Microsoft Entra 标识。
可以在群集级别或命名空间级别选择权限范围。 对于具有作用域内职责的角色（例如应用程序操作员），在工作负荷的命名空间级别分配权限。
此外，角色还需要 Azure RBAC 权限，以便他们能够执行其任务。 例如，群集操作员需要通过门户访问 Azure Monitor。 因此，基础结构操作员角色必须具有适当的 RBAC 分配。
除了人员及其角色之外，Azure 资源，甚至群集中的 Pod 也具有托管标识。 这些标识需要一组通过 Azure RBAC 的权限，并且必须根据预期的任务严格限定范围。 例如，Azure 应用程序网关必须有权从 Azure Key Vault 获取机密（TLS 证书）。 它不得具有修改机密的权限。
下面是维护访问控制措施的一些最佳做法：
- 维护有关每个角色和分配的权限以及理由的细致文档。 明确区分哪些权限是 JIT，哪些权限是站立的。
- 监视角色以获取更改，例如在分配更改或角色定义中。 创建有关更改（即使预期）的警报，以深入了解更改背后的意图。
要求 7.2.1
PCI DSS 4.0.1 要求访问控制措施涵盖所有系统组件，包括云和混合环境，以及持续监视控件的有效性。
你的责任
请考虑采用以下最佳做法：
没有站立访问权限。 请考虑使用 Just-In-Time AD 组成员身份。 此功能需要Microsoft Entra Privileged Identity Management。
在群集的 Microsoft Entra ID 中设置条件访问策略。 这会进一步限制对 Kubernetes 控制平面的访问。 使用条件访问策略，可以要求多重身份验证、将身份验证限制为由 Microsoft Entra 租户管理的设备，或阻止非典型登录尝试。 将这些策略应用到映射到具有高特权的 Kubernetes 角色的 entra 组Microsoft。
注释
JIT 和条件访问技术选项都需要Microsoft Entra ID P1 或 P2 许可证。
理想情况下，请禁用对群集节点的 SSH 访问。 此参考实现不会为此生成 SSH 连接详细信息。
授权用户必须访问任何其他计算（如跳转框）。 不要创建可用于整个团队的通用登录名。
要求 7.2.2
必须根据作业分类和功能分配和评审访问权限，并且必须随着角色更改而更新访问权限。 PCI DSS 4.0.1 要求记录并审核此过程。
基于作业分类和职能向个人分配特权。
你的责任
根据 7.1.3，群集作中将涉及许多角色。 除了标准 Azure 资源角色之外，还需要定义访问的范围和过程。
例如，请考虑群集操作员角色。 它们应该有一个明确的 playbook 用于群集会审活动。 与工作负荷团队的访问有何不同？ 根据组织的不同，它们可能相同。 以下是需要考虑的一些要点：
- 他们应如何访问群集？
- 允许哪些源进行访问？
- 他们在群集上应具有哪些权限？
- 何时分配了这些权限？
请确保在治理文档、策略和培训材料中记录了有关工作负荷操作员和群集操作员的定义。
要求 7.2.3
PCI DSS 4.0.1 要求通过自动测试和监视强制实施并定期验证默认的“拒绝全部”设置。
你的责任
启动配置时，从零信任策略开始。 根据需要进行异常，并详细记录它们。
- 默认情况下，Kubernetes RBAC 会实现 全部拒绝 。 不要通过添加高度宽松的群集角色绑定来替代拒绝所有设置。
- 默认情况下，Azure RBAC 还会实现 全部拒绝 。 不要通过添加反转拒绝所有设置的 RBAC 分配来替代。
- 默认情况下，所有 Azure 服务（包括 Azure Key Vault 和 Azure 容器注册表）都会拒绝所有权限。
- 任何管理访问点（如跳转框）都应拒绝初始配置中的所有访问。 必须显式定义所有提升的权限以覆盖拒绝所有规则。
注释
请记住，对于网络访问，NSG 默认允许所有通信。 更改以将所有 拒绝 设置为起始规则，并具有高优先级值。 然后，根据需要添加将在 拒绝所有 规则之前应用的异常。 在命名上保持一致，以便更轻松地进行审核。
默认情况下，Azure 防火墙会 实现全部拒绝 。
要求 7.3
PCI DSS 4.0.1 要求对限制持卡人数据访问的安全策略和作过程进行持续审查、更新和传达给所有受影响的方。
确保记录用于限制持卡人数据访问的安全策略和作过程，以供所有受影响的方记录、使用和已知。
你的责任
维护有关流程和策略的彻底文档至关重要。 这包括 Azure 和 Kubernetes RBAC 策略和组织治理策略。 必须对运营监管环境的人员进行教育、通知和激励，以支持安全保证。 对于从政策角度而言，属于审批流程的人员尤其重要。
要求 8：识别并验证对系统组件的访问
AKS 功能支持
由于 AKS 和 Microsoft Entra 集成，可以利用标识管理和授权功能，包括访问管理、标识符对象管理和其他功能。 有关详细信息，请参阅 AKS 托管的 Microsoft Entra 集成。
你的责任
| Requirement | 职责 |
|---|---|
| 要求 8.1 | 定义并实施策略和过程，以确保对所有系统组件上的非使用者用户和管理员进行适当的用户标识管理，如下所示： |
| 要求 8.2 | 除了分配唯一 ID 之外，还至少使用以下方法之一对所有系统组件的非使用者用户和管理员进行适当的用户身份验证管理： |
| 要求 8.3 | 使用多重身份验证保护所有单独的非控制台管理访问权限和对 CDE 的所有远程访问。 |
| 要求 8.4 | 记录身份验证过程，并向所有用户传达身份验证过程和策略和过程，包括： |
| 要求 8.5 | 请勿使用组、共享或通用 ID、密码或其他身份验证方法，如下所示： |
| 要求 8.6 | 如果使用其他身份验证机制（例如物理或逻辑安全令牌、智能卡、证书等），则必须按如下所示分配这些机制： |
| 要求 8.7 | 对包含持卡人数据的任何数据库（包括应用程序、管理员和所有其他用户的访问）的所有访问权限都受到限制，如下所示： |
| 要求 8.8 | 确保记录了标识和身份验证的安全策略和作过程，供所有受影响的各方使用和已知。 |
要求 8.1
PCI DSS 4.0.1 扩展了对唯一标识和身份验证的要求，包括持续监视用户帐户和针对可疑活动的自动警报。 组织必须实施定期审查和删除不必要的帐户的过程。
定义并实施策略和过程，以确保对所有系统组件上的非使用者用户和管理员进行适当的用户标识管理，如下所示：
| 子要求 | Description |
|---|---|
| 8.1.1 | 在允许用户访问系统组件或持卡人数据之前，为所有用户分配唯一 ID。 |
| 8.1.2 | 控制用户 ID、凭据和其他标识符对象的添加、删除和修改。 |
| 8.1.3 | 立即撤销任何已终止用户的访问权限。 |
| 8.1.4 | 在 90 天内删除/禁用非活动用户帐户。 |
| 8.1.5 | 管理第三方用于通过远程访问访问、支持或维护系统组件的 ID，如下所示： • 仅在使用时需要且禁用的时间段内启用。 • 在使用时受到监视。 |
| 8.1.6 | 通过在不超过六次尝试后锁定用户 ID 来限制重复访问尝试。 |
| 8.1.7 | 将锁定持续时间设置为至少 30 分钟，或直到管理员启用用户 ID 为止。 |
| 8.1.8 | 如果会话已空闲超过 15 分钟，则要求用户重新进行身份验证以重新激活终端或会话。 |
你的责任
下面是此要求的总体注意事项：
适用于：8.1.1、8.1.2、8.1.3
不要共享或重复使用 CDE 功能上不同部分的标识。 例如，不要使用团队帐户访问数据或群集资源。 请确保标识文档清楚说明未使用共享帐户。
将此标识主体扩展到 Azure 中的托管标识分配。 不要跨 Azure 资源共享用户托管标识。 为每个 Azure 资源分配自己的托管标识。 同样，在 AKS 群集中使用 Microsoft Entra 工作负荷 ID 时，请确保工作负荷中的每个组件都会收到自己的标识，而不是使用范围很广的标识。 切勿在生产环境和非生产环境之间共享相同的托管标识。
有关详细信息，请参阅 Azure Kubernetes 服务（AKS）的访问和标识选项。
适用于：8.1.2、8.1.3、8.1.4
使用 Microsoft Entra ID 作为标识存储。 由于群集和所有 Azure 资源都使用 Microsoft Entra ID，因此禁用或撤销主体的访问权限将自动应用于所有资源。 如果有任何组件没有直接由 Microsoft Entra ID 提供支持，请确保有一个删除访问权限的过程。 例如，如果用户不再有效，可能需要显式删除用于访问跳转框的 SSH 凭据。
适用于：8.1.5
利用 Microsoft设计为托管第三方企业对企业（B2B）帐户（如供应商和合作伙伴）的 entra 外部 ID，作为来宾用户。 使用条件策略保护公司数据，授予适当的访问权限级别。 这些帐户必须具有最少的永久权限和强制到期日期。 有关详细信息，请参阅 B2B 与外部来宾的协作，供员工使用。
你的组织应具有明确且记录的供应商模式和类似的访问权限。
适用于：8.1.6、8.1.7、8.1.8
Microsoft Entra ID 提供 智能锁定功能 ，用于在登录尝试失败后锁定用户。 实现锁定的建议方法是使用 Microsoft Entra 条件访问策略。
为支持类似功能的组件实现锁定，但不受Microsoft Entra ID 的支持（例如启用了 SSH 的计算机（如跳转盒）支持）。 这可确保启用锁定以防止或减缓访问尝试滥用。
AKS 节点不设计为定期访问。 阻止直接 SSH 或远程桌面访问群集节点。 SSH 访问应被视为高级故障排除工作的一部分。 访问应受到密切监视，并在完成特定事件后立即还原。 如果这样做，请注意，任何节点级更改都可能导致群集不受支持。
要求 8.2
PCI DSS 4.0.1 更新密码和身份验证要求，以符合新式安全最佳做法，包括更长的密码长度、复杂性要求和支持无密码身份验证方法。 需要对身份验证事件进行增强监视。
除了分配唯一 ID 之外，还至少使用以下方法之一对所有系统组件的非使用者用户和管理员进行适当的用户身份验证管理：
- 你知道的内容，例如密码或通行短语。
- 你拥有的内容，例如令牌设备或智能卡。
- 你就是这样，比如生物识别。
| 子要求 | Description |
|---|---|
| 8.2.1 | 使用强加密，在所有系统组件上传输和存储期间无法读取所有身份验证凭据（如密码/短语）。 |
| 8.2.2 | 在修改任何身份验证凭据之前验证用户标识，例如：执行密码重置、预配新令牌或生成新密钥。 |
| 8.2.3 | 密码/短语必须满足以下条件：• 需要至少七个字符的长度。 • 包含数字字符和字母字符。 |
| 8.2.4 | 每 90 天至少更改一次用户密码/密码。 |
| 8.2.5 | 不允许个人提交与最近四个密码/短语中的任何一个相同的新密码/短语。 |
| 8.2.6 | 为首次使用设置密码/短语，并重置为每个用户的唯一值，并在首次使用后立即更改。 |
你的责任
在群集的 Microsoft Entra ID 中设置条件访问策略。 这会进一步限制对 Kubernetes 控制平面的访问。
上述几个要求集由 Microsoft Entra ID 自动处理。 下面是一些示例：
密码安全性
Microsoft Entra ID 提供强制使用强密码的功能。 例如，阻止属于全局禁止密码列表的弱密码。 这不足以保护。 若要创建特定于组织的禁止列表，请考虑添加Microsoft Entra Password Protection 功能。 默认应用密码策略。 某些策略无法修改并涵盖上述一组要求。 其中包括密码过期和允许的字符。 有关完整列表，请参阅 Microsoft Entra 密码策略。 请考虑使用条件访问策略（例如基于用户风险的条件访问策略），这些策略检测到泄露的用户名和密码对。
注释
强烈建议考虑无密码选项。
用户标识验证
可以应用登录风险条件访问策略来检测身份验证请求是否由请求标识发出。 针对威胁情报源验证请求。 其中包括密码喷射和 IP 地址异常。
你可能具有不使用Microsoft Entra ID 的组件，例如使用 SSH 访问跳转框。 在这种情况下，请使用至少 RSA 2048 密钥大小的公钥加密。 始终指定通行短语。 具有跟踪已知已批准的公钥的验证过程。 使用公钥访问的系统不得向 Internet 公开。 相反，所有 SSH 访问都应仅允许通过中介（例如 Azure Bastion）来减少私钥泄漏的影响。 禁用直接密码访问并使用替代无密码解决方案。
要求 8.3
PCI DSS 4.0.1 要求对持卡人数据环境（CDE）（包括内部用户）进行所有访问的多重身份验证（MFA）。 必须持续监视和测试 MFA 控件的有效性。
使用多重身份验证保护所有单独的非控制台管理访问权限和对 CDE 的所有远程访问。 注意：多重身份验证要求至少使用三种身份验证方法中的两种（请参阅要求 8.2 了解身份验证方法的说明）用于身份验证。 使用一个因素两次（例如，使用两个单独的密码）不被视为多重身份验证。
你的责任
使用条件访问策略来强制实施多重身份验证，特别是在管理帐户上。 建议对多个内置角色使用这些策略。 将这些策略应用到映射到具有高特权的 Kubernetes 角色的 entra 组Microsoft。
可以使用其他策略进一步强化此策略，例如：
- 可以将身份验证限制为由 Microsoft Entra 租户管理的设备。
- 如果访问源自群集网络外部的网络，则可以强制实施多重身份验证。
有关详细信息，请参见:
要求 8.4
PCI DSS 4.0.1 要求定期审查、更新和传达所有用户的身份验证过程和策略。 安全意识培训必须包括有关身份验证最佳做法和新兴威胁的指导。
记录身份验证过程，并向所有用户传达身份验证过程和策略和过程，包括：
- 有关选择强身份验证凭据的指导。
- 有关用户如何保护其身份验证凭据的指导。
- 说明不重复使用以前使用的密码。
- 如果有任何怀疑密码可能被泄露，则更改密码的说明。
你的责任
维护有关强制策略的文档。 作为标识载入培训的一部分，请提供有关密码重置过程和组织保护资产的最佳做法的指导。
要求 8.5
PCI DSS 4.0.1 禁止对任何管理或关键功能使用组、共享或通用 ID，并要求持续监视违规行为。
请勿使用组、共享或通用 ID、密码或其他身份验证方法，如下所示：
- 禁用或删除通用用户 ID。
- 系统管理和其他关键功能不存在共享用户 ID。
- 共享和通用用户 ID 不用于管理任何系统组件。
你的责任
不要共享或重复使用群集或 Pod 的功能不同部分的标识。 例如，不要使用团队帐户访问数据或群集资源。 请确保标识文档清楚说明未使用共享帐户。
禁用 CDE 中的根用户。 禁用 Kubernetes 本地帐户的使用，以便用户无法使用对 CDE 中的群集的内置 --admin 访问。
要求 8.6
PCI DSS 4.0.1 要求将所有身份验证机制（如令牌、智能卡、证书）分配给单个帐户，并且不会共享。 物理和逻辑控制必须到位，以确保只有预期帐户可以使用该机制。
如果使用其他身份验证机制（例如物理或逻辑安全令牌、智能卡、证书等），则必须按如下所示分配这些机制：
- 必须将身份验证机制分配给单个帐户，而不是在多个帐户之间共享。
- 必须设置物理和/或逻辑控制，以确保只有预期帐户可以使用该机制来获取访问权限。
你的责任
确保按用户标识提供对 CDE 的所有访问，并将其扩展到任何物理或虚拟令牌中。 这包括对 CDE 网络的任何 VPN 访问，确保企业点到站点访问（如果有）将按用户证书用作该身份验证流的一部分。
要求 8.7
PCI DSS 4.0.1 要求限制和监视对包含持卡人数据的数据库的所有访问，并且持续审查应用程序和用户访问是否合适。
对包含持卡人数据的任何数据库（包括应用程序、管理员和所有其他用户的访问）的所有访问权限都受到限制，如下所示：
- 对数据库的所有用户访问权限、用户查询和用户作都通过编程方法。
- 只有数据库管理员能够直接访问或查询数据库。
- 数据库应用程序的应用程序 ID 只能由应用程序使用（而不是由单个用户或其他非应用程序进程使用）。
你的责任
根据角色和职责提供访问权限。 用户可以使用其身份，但必须根据需要限制访问，且具有最少的站立权限。 用户绝不应使用应用程序标识，并且不得共享数据库访问标识。
如果可能，请通过托管标识从应用程序访问数据库。 否则，限制对连接字符串和凭据的公开。 使用 Kubernetes 机密来存储敏感信息，而不是将它们保存在可以轻松发现的位置，例如 Pod 定义。 另一种方法是存储和从托管存储（例如 Azure Key Vault）存储和加载机密。 在 AKS 群集上启用托管标识后，它必须针对 Key Vault 自行进行身份验证才能获取访问权限。
要求 8.8
PCI DSS 4.0.1 要求持续审查、更新和传达给所有受影响的各方的安全策略和身份验证作过程。
确保记录了标识和身份验证的安全策略和作过程，供所有受影响的各方使用和已知。
你的责任
维护有关流程和策略的彻底文档至关重要。 维护有关强制策略的文档。 作为标识载入培训的一部分，请提供有关密码重置过程和组织保护资产的最佳做法的指导。 必须对运营监管环境的人员进行教育、通知和激励，以支持安全保证。 对于从政策角度而言，属于审批流程的人员尤其重要。
要求 9：限制对持卡人数据的物理访问
AKS 功能支持
此要求没有任何适用的 AKS 功能。
你的责任
此体系结构和实现不旨在提供对本地资源或数据中心的物理访问的控制。 有关注意事项，请参阅官方 PCI-DSS 4.0.1 标准中的指南。
下面是应用技术控件的一些建议：
优化任何管理控制台访问中的会话超时，例如 CDE 中的跳转框，以最大程度地减少访问。
优化条件访问策略，以最大程度地减少来自访问点（例如 Azure 门户）的 Azure 访问令牌上的 TTL。 有关信息，请参阅以下文章：
对于云托管的 CDE，管理物理访问和硬件没有任何责任。 依赖于公司网络物理和逻辑控制。
尽量减少将 CHD 备份导出到本地目标。 使用 Azure 中托管的解决方案来限制对备份的物理访问。
最大程度地减少到本地的备份。 如果需要，请注意，本地目标将位于审核范围内。
后续步骤
实现增强的多重身份验证（MFA）要求，以确保对持卡人数据环境的安全访问。