Framework № PCI DSS 4.0 от 01.03.2022

7.2.1
Defined Approach Requirements: 
An access control model is defined and includes granting access as follows: 

Customized Approach Objective:
Access requirements are established according to job functions following least-privilege and need-toknow principles 

Defined Approach Testing Procedures:

Purpose:
Defining an access control model that is appropriate for the entity’s technology and access control philosophy supports a consistent and uniform way of allocating access and reduces the possibility of errors such as the granting of excessive rights. 

Good Practice:
A factor to consider when defining access needs is the separation of duties principle. This principle is intended to prevent fraud and misuse or theft of resources. For example, 1) dividing missioncritical functions and information system support functions among different individuals and/or functions, 2) establishing roles such that information system support activities are performed by different functions/individuals (for example, system management, programming, configuration management, quality assurance and testing, and network security), and 3) ensuring security personnel administering access control functions do not also administer audit functions. 
In environments where one individual performs multiple functions, such as administration and security operations, duties may be assigned so that no single individual has end-to-end control of a process without an independent checkpoint. For example, responsibility for configuration and responsibility for approving changes could be assigned to separate individuals. 

Definitions:
Key elements of an access control model include:

Once job functions, resources, and activities per job functions are defined, individuals can be granted access accordingly. 

Examples:
Access control models that entities can consider include role-based access control (RBAC) and attribute-based access control (ABAC). The access control model used by a given entity depends on their business and access needs. 

7.2.2
Defined Approach Requirements: 
Access is assigned to users, including privileged users, based on: 

Customized Approach Objective:
Access to systems and data is limited to only the access needed to perform job functions, as defined in the related access roles. 

Defined Approach Testing Procedures:

Purpose:
Assigning least privileges helps prevent users without sufficient knowledge about the application from incorrectly or accidentally changing application configuration or altering its security settings. Enforcing least privilege also helps to minimize the scope of damage if an unauthorized person gains access to a user ID. 

Good Practice:
Access rights are granted to a user by assignment to one or several functions. Assess is assigned depending on the specific user functions and with the minimum scope required for the job. 
When assigning privileged access, it is important to assign individuals only the privileges they need to perform their job (the “least privileges”). For example, the database administrator or backup administrator should not be assigned the same privileges as the overall systems administrator. 
Once needs are defined for user functions (per PCI DSS requirement 7.2.1), it is easy to grant individuals access according to their job classification and function by using the alreadycreated roles. 
Entities may wish to consider use of Privileged Access Management (PAM), which is a method to grant access to privileged accounts only when those privileges are required, immediately revoking that access once they are no longer needed. 

7.2.3
Defined Approach Requirements: 
Required privileges are approved by authorized personnel 

Customized Approach Objective:
Access privileges cannot be granted to users without appropriate, documented authorization. 

Defined Approach Testing Procedures:

Purpose:
Documented approval (for example, in writing or electronically) assures that those with access and privileges are known and authorized by management, and that their access is necessary for their job function. 

7.2.4
Defined Approach Requirements: 
All user accounts and related access privileges, including third-party/vendor accounts, are reviewed as follows:

Customized Approach Objective:
Account privilege assignments are verified periodically by management as correct, and nonconformities are remediated. 

Applicability Notes:
This requirement applies to all user accounts and related access privileges, including those used by personnel and third parties/vendors, and accounts used to access third-party cloud services. 
See Requirements 7.2.5 and 7.2.5.1 and 8.6.1 through 8.6.3 for controls for application and system accounts. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Regular review of access rights helps to detect excessive access rights remaining after user job responsibilities change, system functions change, or other modifications. If excessive user rights are not revoked in due time, they may be used by malicious users for unauthorized access. 
This review provides another opportunity to ensure that accounts for all terminated users have been removed (if any were missed at the time of termination), as well as to ensure that any third parties that no longer need access have had their access terminated. 

Good Practice:
When a user transfers into a new role or a new department, typically the privileges and access associated with their former role are no longer required. Continued access to privileges or functions that are no longer required may introduce the risk of misuse or errors. Therefore, when responsibilities change, processes that revalidate access help to ensure user access is appropriate for the user’s new responsibilities. 
Entities can consider implementing a regular, repeatable process for conducting reviews of access rights, and assigning “data owners” that are responsible for managing and monitoring access to data related to their job function and that also ensure user access remains current and appropriate. As an example, a direct manager could review team access monthly, while the senior manager reviews their groups’ access quarterly, both making updates to access as needed. The intent of these best practices is to support and facilitate conducting the reviews at least once every 6 months. 

7.2.5
Defined Approach Requirements: 
All application and system accounts and related access privileges are assigned and managed as follows:

Customized Approach Objective:
Access rights granted to application and system accounts are limited to only the access needed for the operability of that application or system. 

Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 
Defined Approach Testing Procedures:

Purpose:
It is important to establish the appropriate access level for application or system accounts. If such accounts are compromised, malicious users will receive the same access level as that granted to the application or system. Therefore, it is important to ensure limited access is granted to system and application accounts on the same basis as to user accounts. 

Good Practice:
Entities may want to consider establishing a baseline when setting up these application and system accounts including the following as applicable to the organization:

7.2.5.1
Defined Approach Requirements: 
All access by application and system accounts and related access privileges are reviewed as follows:

Customized Approach Objective:
Application and system account privilege assignments are verified periodically by management as correct, and nonconformities are remediated. 

Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Regular review of access rights helps to detect excessive access rights remaining after system functions change, or other application or system modifications occur. If excessive rights are not removed when no longer needed, they may be used by malicious users for unauthorized access. 

7.2.6
Defined Approach Requirements: 
All user access to query repositories of stored cardholder data is restricted as follows:

Customized Approach Objective:
Direct unfiltered (ad hoc) query access to cardholder data repositories is prohibited, unless performed by an authorized administrator. 

Applicability Notes:
This requirement applies to controls for user access to query repositories of stored cardholder data. 
See Requirements 7.2.5 and 7.2.5.1 and 8.6.1 through 8.6.3 for controls for application and system accounts. 

Defined Approach Testing Procedures:

Purpose:
The misuse of query access to repositories of cardholder data has been a regular cause of data breaches. Limiting such access to administrators reduces the risk of such access being abused by unauthorized users. 

Definitions:
“Programmatic methods” means granting access through means such as database stored procedures that allow users to perform controlled actions to data in a table, rather than via direct, unfiltered access to the data repository by end users (except for the responsible administrator(s), who need direct access to the database for their administrative duties). 

Good Practice:
Typical user actions include moving, copying, and deleting data. Also consider the scope of privilege needed when granting access. For example, access can be granted to specific objects such as data elements, files, tables, indexes, views, and stored routines. Granting access to repositories of cardholder data should follow the same process as all other granted access, meaning that it is based on roles, with only the privileges assigned to each user that are needed to perform their job functions.