Framework № PCI DSS 4.0.1 от 11.06.2024

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know 

Overview:
Unauthorized individuals may gain access to critical data or systems due to ineffective access control rules and definitions. To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities. 
“Access” or “access rights” are created by rules that provide users access to systems, applications, and data, while “privileges” allow a user to perform a specific action or function in relation to that system, application, or data. For example, a user may have access rights to specific data, but whether they can only read that data, or can also change or delete the data is determined by the user’s assigned privileges. 
“Need to know” refers to providing access to only the least amount of data needed to perform a job. 
“Least privileges” refers to providing only the minimum level of privileges needed to perform a job. 
These requirements apply to user accounts and access for employees, contractors, consultants, and internal and external vendors and other third parties (for example, for providing support or maintenance services). Certain requirements also apply to application and system accounts used by the entity (also called “service accounts”). 

 7.1 Processes and mechanisms for restricting access to system components and cardholder data by business need to know are defined and understood. 

7.2 Access to system components and data is appropriately defined and assigned. 

7.3 Access to system components and data is managed via an access control system(s). 

Requirement 8: Identify Users and Authenticate Access to System Components 

Overview:
Two fundamental principles of identifying and authenticating users are to 1) establish the identity of an individual or process on a computer system, and 2) prove or verify the user associated with the identity is who the user claims to be. 
Identification of an individual or process on a computer system is conducted by associating an identity with a person or process through an identifier, such as a user, system, or application ID. These IDs (also referred to as “accounts”) fundamentally establish the identity of an individual or process by assigning unique identification to each person or process to distinguish one user or process from another. When each user or process can be uniquely identified, it ensures there is accountability for actions performed by that identity. When such accountability is in place, actions taken can be traced to known and authorized users and processes. 
The element used to prove or verify the identity is known as the authentication factor. Authentication factors are 1) something you know, such as a password or passphrase, 2) something you have, such as a token device or smart card, or 3) something you are, such as a biometric element. 
The ID and the authentication factor together are considered authentication credentials and are used to gain access to the rights and privileges associated with a user, application, system, or service accounts. 
These requirements for identity and authentication are based on industry-accepted security principles and best practices to support the payment ecosystem. NIST Special Publication 800-63, Digital Identity Guidelines provides additional information on acceptable frameworks for digital identity and authentication factors. It is important to note that the NIST Digital Identity Guidelines is intended for US Federal Agencies and should be viewed in its entirety. Many of the concepts and approaches defined in these guidelines are expected to work with each other and not as standalone parameters. 
Note: Unless otherwise stated in the requirement, these requirements apply to all accounts on all system components, unless specifically called out in an individual requirement, including but not limited to:

This includes accounts used by employees, contractors, consultants, internal and external vendors, and other third parties (for example, for providing support or maintenance services). 
Certain requirements are not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction. When items do not apply, they are noted directly within the specific requirement. 

8.1 Processes and mechanisms for identifying users and authenticating access to system components are defined and understood. 

8.2 User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle. 

8.3 Strong authentication for users and administrators is established and managed 

8.4 Multi-factor authentication (MFA) is implemented to secure access into the CDE. 

8.5 Multi-factor authentication (MFA) systems are configured to prevent misuse. 

8.6 Use of application and system accounts and associated authentication factors is strictly managed 

Requirement 9: Restrict Physical Access to Cardholder Data 

Overview: Any physical access to cardholder data or systems that store, process, or transmit cardholder data provides the opportunity for individuals to access and/or remove systems or hardcopies containing cardholder data; therefore, physical access should be appropriately restricted. There are three different areas mentioned in Requirement 9: 

9.1 Processes and mechanisms for restricting physical access to cardholder data are defined and understood. 

9.2 Physical access controls manage entry into facilities and systems containing cardholder data.

9.3 Physical access for personnel and visitors is authorized and managed. 

9.4 Media with cardholder data is securely stored, accessed, distributed, and destroyed 

9.5 Point-of-interaction (POI) devices are protected from tampering and unauthorized substitution