Guideline for a healthy information system v.2.0 (EN)

РД.2 Идентификация и многофакторная аутентификация пользователей
3-Н 2-Н 1-Т

РД.4 Идентификация и многофакторная аутентификация эксплуатационного персонала
3-Н 2-Т 1-Т

PR.AC-7: Пользователи, устройства и другие активы проходят аутентификацию (например, однофакторную, многофакторную), соизмеримую с риском транзакции (например, рисками безопасности и конфиденциальности отдельных лиц и другими организационными рисками)

8.4.2
Defined Approach Requirements: 
MFA is implemented for all access into the CDE. 

Customized Approach Objective:
Access into the CDE cannot be obtained by the use of a single authentication factor. 

Applicability Notes:
This requirement does not apply to:

 MFA is required for both types of access specified in Requirements 8.4.2 and 8.4.3. Therefore, applying MFA to one type of access does not replace the need to apply another instance of MFA to the other type of access. If an individual first connects to the entity’s network via remote access, and then later initiates a connection into the CDE from within the network, per this requirement the individual would authenticate using MFA twice, once when connecting via remote access to the entity’s network and once when connecting via non-console administrative access from the entity’s network into the CDE. 
The MFA requirements apply for all types of system components, including cloud, hosted systems, and on-premises applications, network security devices, workstations, servers, and endpoints, and includes access directly to an entity’s networks or systems as well as web-based access to an application or function. 
MFA for remote access into the CDE can be implemented at the network or system/application level; it does not have to be applied at both levels. For example, if MFA is used when a user connects to the CDE network, it does not have to be used when the user logs into each system or application within the CDE. 
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:
Requiring more than one type of authentication factor reduces the probability that an attacker can gain access to a system by masquerading as a legitimate user, because the attacker would need to compromise multiple authentication factors. This is especially true in environments where traditionally the single authentication factor employed was something a user knows such as a password or passphrase. 

Definitions:
Using one factor twice (for example, using two separate passwords) is not considered multifactor authentication. 

8.3.1
Defined Approach Requirements: 
All user access to system components for users and administrators is authenticated via at least one of the following authentication factors:

Customized Approach Objective:
An account cannot be accessed except with a combination of user identity and an authentication factor. 

Applicability Notes:
This requirement is 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 (such as IDs used by cashiers on point-of-sale terminals). 
This requirement does not supersede multi-factor authentication (MFA) requirements but applies to those in-scope systems not otherwise subject to MFA requirements. 
A digital certificate is a valid option for “something you have” if it is unique for a particular user. 

Defined Approach Testing Procedures:

Purpose:
When used in addition to unique IDs, an authentication factor helps protect user IDs from being compromised, since the attacker needs to have the unique ID and compromise the associated authentication factor(s). 

Good Practice:
A common approach for a malicious individual to compromise a system is to exploit weak or nonexistent authentication factors (for example, passwords/passphrases). Requiring strong authentication factors helps protect against this attack. 

Further Information:
See fidoalliance.org for more information about using tokens, smart cards, or biometrics as authentication factors. 

8.4.2
Определенные Требования к Подходу:
MFA реализован для всех видов доступа к CDE.

Цель Индивидуального подхода:
Доступ к CDE не может быть получен с помощью одного фактора аутентификации.

Примечания по применению:
Это требование не распространяется на:

MFA требуется для обоих типов доступа, указанных в Требованиях 8.4.2 и 8.4.3. Следовательно, применение MFA к одному типу доступа не заменяет необходимость применения другого экземпляра MFA к другому типу доступа. Если физическое лицо сначала подключается к сети организации через удаленный доступ, а затем позже инициирует подключение к CDE из сети, в соответствии с этим требованием физическое лицо будет проходить проверку подлинности с использованием MFA дважды, один раз при подключении через удаленный доступ к сети организации и один раз при подключении через неконсольный административный доступ из сети организации в CDE.
Требования MFA применяются ко всем типам системных компонентов, включая облачные, размещенные системы и локальные приложения, устройства сетевой безопасности, рабочие станции, серверы и конечные точки, и включают прямой доступ к сетям или системам организации, а также веб-доступ к приложению или функции.
MFA для удаленного доступа к CDE может быть реализован на сетевом или системном/прикладном уровне; его необязательно применять на обоих уровнях. Например, если MFA используется, когда пользователь подключается к сети CDE, его необязательно использовать, когда пользователь входит в каждую систему или приложение в CDE.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

Цель:
Требование более одного типа фактора аутентификации снижает вероятность того, что злоумышленник сможет получить доступ к системе, выдавая себя за законного пользователя, поскольку злоумышленнику потребуется скомпрометировать несколько факторов аутентификации. Это особенно верно в средах, где традиционно единственным фактором аутентификации было то, что известно пользователю, например пароль или кодовая фраза.

Определения:
Использование одного фактора дважды (например, использование двух отдельных паролей) не считается многофакторной аутентификацией.

8.3.1
Определенные Требования к Подходу:
Весь пользовательский доступ к системным компонентам для пользователей и администраторов проверяется с помощью по крайней мере одного из следующих факторов аутентификации:

Цель Индивидуального подхода:
Доступ к учетной записи возможен только с использованием комбинации идентификатора пользователя и фактора аутентификации.

Примечания по применению:
Это требование не предназначено для применения к учетным записям пользователей в торговых терминалах, которые имеют доступ только к одному номеру карты одновременно для облегчения одной транзакции (например, идентификаторы, используемые кассирами в торговых терминалах).
Это требование не заменяет требования к многофакторной аутентификации (MFA), но применяется к тем системам, которые в других случаях не подпадают под требования MFA.
Цифровой сертификат является допустимым вариантом для “того, что у вас есть”, если он уникален для конкретного пользователя.

Определенные Процедуры Тестирования Подхода:

Цель:
При использовании в дополнение к уникальным идентификаторам фактор аутентификации помогает защитить идентификаторы пользователей от взлома, поскольку злоумышленнику необходимо иметь уникальный идентификатор и скомпрометировать связанные с ним факторы аутентификации.

Надлежащая практика:
Распространенный подход злоумышленника к компрометации системы заключается в использовании слабых или несуществующих факторов аутентификации (например, паролей/парольных фраз). Требование надежных факторов аутентификации помогает защититься от этой атаки.

Дополнительная информация:
См. fidoalliance.org дополнительные сведения об использовании токенов, смарт-карт или биометрических данных в качестве факторов аутентификации см.