要求7、8、9组成目标4实施强访问控制措施，旨在实施和监控作为 PCI DSS 合规性环境一部分的系统组件中识别、身份验证、授权和权限管理的物理和逻辑控制，以防止未经授权的访问。 控制资产的机密性、完整性和可用性，并启用主体（人员或计算机系统）与客体在环境中执行的操作之间的关系。
PCI DSS v3.2.1 | PCI DSS v4.0 |
Implement Strong Access Control Measures | Implement Strong Access Control Measures |
R7. Restrict access to cardholder data by business need to know | R7. Restrict Access to System Components and Cardholder Data by Business Need to Know |
R8. Identify and authenticate access to system components | R8. Identify Users and Authenticate Access to System Components |
R9. Restrict physical access to cardholder data | R9. Restrict Physical Access to Cardholder Data |
在继续分析适用于这些要求的更改之前，重要的是要记住整个标准中使用的一些术语的定义：
- 识别是将唯一身份归因于个人或系统。
- 身份验证是验证用户/系统身份的过程。通过请求访问并显示唯一的用户/系统 ID，用户/系统提供了一组只有他们才能访问或知道的私有数据。此过程使用以下一个或多个因素的验证：
- 您知道的东西 （SYK），例如密码，
- 您拥有的东西 （SYH），例如令牌或智能卡，
- 你是 （SYA），比如生物识别检查。
- 授权是定义用户/系统需要的特定资源（访问）并确定对这些资源的权限的过程。授权的管理必须基于以下标准：
- “需要知道”是指仅提供对执行作业所需的最少数据量的访问。
- “最低权限”是指仅提供执行作业所需的最低级别权限。
- “职责分离”允许在不同的个人和/或职能之间划分关键任务职能，为每个人或每个角色定义角色和责任，并确保管理访问控制功能的安全人员不会同时管理审计功能，以避免使用双重控制和知识拆分的利益冲突：
- 双重控制：使用两个或多个独立实体（通常是人）协同工作来保护敏感功能或信息的过程。任何实体都不得访问或使用该材料。
- 知识拆分 (Split knowledge)：将数据或信息分成两个或多个部分，每个部分都始终处于单独授权的个人或团队的控制之下，因此没有一个人或团队知道所有数据。
这三个重要概念之间的关系很简单：
- 识别提供唯一性
- 身份验证提供有效性
- 授权提供控制
要求 7：根据业务需要限制对系统组件和持卡人数据的访问
要求 7 定义了授权和权限管理的标准。 传统上，此要求是 PCI DSS 标准中控制最少的要求，并在该标准的 4.0 版中继续如此。
此版本中实现的更改很小，主要集中在澄清和扩展其适用性上。
- 明确说明，此要求适用于交互式帐户（与特定用户关联）以及员工、承包商、内部和外部供应商以及其他第三方的访问。某些控件也适用于实体使用的应用程序和系统帐户（也称为“服务帐户”，用于应用程序之间的连接，而无需与人员直接交互）。
- 需要澄清的是，此要求的控制不适用于消费者（持卡人）。
- 需要每半年对所有用户帐户及其权限进行一次审查，以验证和确认这些要素是否仍然适合根据定义的角色和职责，以识别帐户生命周期内注册、取消或更改过程中的变化。管理层必须承认访问权限已足够（要求 7.2.4）。此控制将于 2025 年 3 月 31 日起生效。
- 此要求的适用范围扩大到不仅包括交互式用户帐户，还包括应用程序和系统帐户。为此，请执行以下操作：
- 向这些帐户分配权限必须基于最低权限，并且其访问权限必须仅限于特别要求使用它们的系统、应用程序或进程（要求 7.2.5）。此控制自 2025 年 3 月 31 日起有效。
- 需要定期审查应用程序和系统帐户，以纠正任何不适当的访问。管理层必须承认访问权限已足够（要求 7.2.5.1）。 此控制将从 2025 年 3 月 31 日起生效。
- 对支付卡数据存储库的访问应通过基于角色和最低权限的应用程序或编程方法完成，其中只有负责的管理员才能对此类存储库执行直接查询（要求 7.2.6）。此控件取代了 PCI DSS v3.2.1 的控件 8.7，阐明了不仅可以访问数据库，还可以访问任何卡数据存储库。
默认情况下，与配置为“全部拒绝”的环境的访问控制系统的存在相关的控制将继续存在，而不会在此新版本的标准中发生重大更改。
要求 8：识别用户并验证对系统组件的访问
作为对要求 7 中描述的授权过程管理的补充，要求 8 建立了用户、系统和/或应用程序的识别和身份验证标准。
与此要求最相关的更改包括：
- 在 PCI DSS 的 4.0 版中，将允许使用组、共享、通用帐户或其他共享身份验证凭据，只要它们的使用是例外的、合理的、经管理层批准的，在保证访问之前识别使用该帐户的个人，并且每个活动都可以与执行它的用户相关。此更改使得管理某些技术限制（例如在 Unix 操作系统中使用 root 帐户）成为可能，而以前需要使用补偿性控制作为合规性替代方案。
- 对密码策略进行了几项更改：
- 无效身份验证尝试次数从 6 次增加到 10 次（要求 8.3.4）
- 密码长度已从 7 个字符扩展到 12 个字符（如果系统不支持 10 个字符，则扩展到 8 个字符）（要求 8.3.6）
- 如果密码被用作唯一的访问因素，则这些密码必须每 90 天更改一次，或者必须动态分析帐户的安全状况，自动实时确定对资源的访问（要求 8.3.9）。此要求也适用于截至 2025 年 3 月 31 日的服务提供商的客户帐户（要求 8.3.10.1）
关于多因素身份验证 （MFA） 的使用，版本 4.0 中包含的更改如下：
- 具有管理访问权限的人员对 CDE 的所有非控制台访问（使用网络接口而不是直接物理连接访问）都需要 MFA（要求 8.4.1）
- 所有 CDE 访问都需要 MFA（无法使用单个身份验证因子获得 CDE 访问）（要求 8.4.2）– 自 2025 年 3 月 31 日起适用。
- 对于源自企业网络外部的所有可能访问或影响 CDE 的远程网络访问（包括用户和管理员以及第三方和供应商的访问），都需要 MFA（要求 8.4.3）
- 描述了应在 MFA 中实现的技术配置，包括防止重放攻击的控制、使用至少两个不同的身份验证因素、在授予对资源/网络的访问权限之前正确验证所有身份验证因素，以及在获得管理层授权的情况下“绕过”MFA 控制的限制、 它被记录在案，并且只允许在有限的时间范围内（要求 8.5.1）——自 2025 年 3 月 31 日起适用。
从这个意义上说，根据连接的开始和结束位置，强调“MFA 链”或使用 MFA 的多个身份验证的概念非常重要。在某些情况下，管理员可能会从公司网络外部连接到可能影响 CDE 的网络（首次使用 MFA），一旦连接到该网络，就需要与 CDE 建立网络连接（第二次使用 MFA）。在这些情况下，需要使用 MFA 两次。
最后，描述了须应用于任何系统或应用程序帐户的控制：
- 当这些帐户用作交互式帐户（由个人使用）时，必须将其作为例外处理，必须在规定的时限内使用，必须得到管理层的批准，并且必须确认用户的身份，并跟踪用户的行为（要求 8.6.1）——自 3 月 31 日起适用， 2025.
- 另一方面，扩展了控制措施，以防止这些帐户使用的密码被不安全地集成到脚本、配置文件或应用程序源代码中（要求 8.6.2）。
- 这些帐户使用的密码应定期更改，并根据定义的更改期限具有适当的复杂性。
要求 9：限制对持卡人数据的物理访问
与 PCI DSS v4.0 标准的其他要求不同，这是自 3.2.1 版以来名称未更改的唯一要求。但是，为了便于实施控制措施，增加了多项说明，包括：
- 定义适用 PCI DSS 控制的三个物理区域：
- 敏感区域
- CDE（持卡人数据环境）
- 设施
- 适用于员工（要求 9.3.1）和访客（要求 9.3.2）对 CDE 进行物理访问管理的生命周期的程序是有区别的。
- 访客日志不仅必须包括访客及其公司的姓名以及授权实际访问的人的姓名，还必须包括访问的日期和时间（要求 9.3.4）。
关于交互点 （POI） 的安全性，添加了以下说明：
- POI 的物理安全控制不适用于商用现成 （COTS） 设备（因为它们是专为大众市场分销而设计的专有设备）或允许手动输入 PAN 数据的组件，例如计算机键盘。
- 对 POI 进行物理检查的频率应由组织根据风险分析（要求 9.5.1.2.1）定义——自 2025 年 3 月 31 日起适用。
