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