Identity and Access Management pour PCI DSS

Identity and Access Management pour PCI DSS

L’IAM – pour Identity and Access Management – désigne l’ensemble des processus et technologies permettant de contrôler l’authentification et l’autorisation d’utilisateurs et d’applications. L’IAM a donc une influence sur le niveau de sécurité d’un système d’information.

Il semble donc logique que, dans le cadre de la conformité au référentiel PCI DSS, l’IAM soit inclus dans le périmètre audité et soit naturellement soumis aux exigences qui lui sont applicables : mise en œuvre des correctifs de sécurité, durcissement de la configuration des différents composants techniques, filtrage des communications réseau, etc.

Outre ces exigences qui s’appliquent au composant d’IAM, celui-ci permet d’apporter une réponse à de nombreuses exigences pour le compte d’autres composants du périmètre PCI DSS. Les plus évidentes concernent la robustesse des mots de passe ou leur expiration, mais, pour être utilisable dans un environnement conforme, l’IAM doit en réalité proposer des réponses techniques ou organisationnelles à l’ensemble des exigences répertoriées dans le tableau ci-dessous.

Exigences PCI DSS

Ce que devrait apporter la solution d’IAM


Requirement 1: Install and maintain a firewall configuration to protect cardholder data

1.1.5 Description of groups, roles, and responsibilities for management of network components Documentation des rôles et responsabilités relatives à la gestion des composants réseau

Requirement 6: Develop and maintain secure systems and applications

6.4.1 Separate development/test environments from production environments, and enforce the separation with access controls Séparation des comptes de développement et de production pour les composants gérés par l’IAM

6.4.4 Removal of test data and accounts from system components before the system becomes active/goes into production Extraction de la liste des privilèges dont disposent les comptes de tests gérés par l’IAM et les composants associés

6.4.5 Change control procedures must include the following:
6.4.5.1 Documentation of impact.
6.4.5.2 Documented change approval by authorized parties.
Documentation de l’approbation des changements liés à la gestion des comptes (attribution, suppression, modification)

Cette gestion devrait entrer dans la gestion des changements globale, ne pas être spécifique à l’IAM, et n’a pas besoin d’être incluse dans la solution technique d’IAM.

Requirement 7: Restrict access to cardholder data by business need to know

7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.
7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.
7.1.3 Assign access based on individual personnel’s job classification and function.
7.2.2 Assignment of privileges to individuals based on job classification and function.
Implémentation du moindre privilège selon les utilisateurs et les ressources accessibles du périmètre PCI DSS

7.1.1 Define access needs for each role, including:

  • System components and data resources that each role needs to access for their job function
  • Level of privilege required (for example, user, administrator, etc.) for accessing resources.
Documentation des rôles et responsabilités en précisant, pour chacun, les ressources (données et composants) nécessaires et les privilèges requis

Il s’agit de documenter les rôles implémentés sur le principe du moindre privilège.

7.1.4 Require documented approval by authorized parties specifying required privileges. Documentation des autorisations et de l’approbation de l’octroi d’autorisations

Cette gestion devrait entrer dans la gestion des changements globale, ne pas être spécifique à l’IAM, et n’a pas besoin d’être incluse dans la solution technique d’IAM.

7.2 Establish an access control system(s) for systems components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.
This access control system(s) must include the following:
7.2.1 Coverage of all system components
Liste des composants qui reposent sur l’IAM (pour l’identification, l’authentification et/ou l’autorisation)

7.2.3 Default “deny-all” setting. Implémentation d’un « deny » par défaut pour l’authentification et l’autorisation

Cette fonctionnalité devrait être formellement documentée.

7.3 Ensure that security policies and operational procedures for restricting access to cardholder data are documented, in use, and known to all affected parties. Documentation des procédures de l’IAM (matrices d’utilisateurs, comptes et privilèges ; procédures d’attribution, modification, révocation des comptes et autorisations, etc.)

Requirement 8: Identify and authenticate access to system components

8.1 Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators on all system components as follows:
8.1.1 Assign all users a unique ID before allowing them to access system components or cardholder data.
Assignation de comptes nominatifs aux utilisateurs

8.1.2 Control addition, deletion, and modification of user IDs, credentials, and other identifier objects. Contrôle de la modification des identifiants et secrets d’authentification, soit par des processus automatiques de l’IAM, soit par des processus manuels

Dans les deux cas, ces processus doivent être documentés.

8.1.3 Immediately revoke access for any terminated users. Révocation de comptes utilisateurs

8.1.4 Remove/disable inactive user accounts within 90 days. Désactivation des comptes inactifs au bout de 90 jours

Idéalement, cette désactivation est automatique et donne lieu à une notification des administrateurs de l’IAM.
Le délai d’inactivité devrait pouvoir être configuré pour différentes populations d’utilisateurs de l’IAM.

8.1.5 Manage IDs used by third parties to access, support, or maintain system components via remote access as follows:

  • Enabled only during the time period needed and disabled when not in use.
  • Monitored when in use.
Activation/désactivation temporaire de comptes, par exemple via la détermination d’une date ou d’un délai d’expiration

8.1.6 Limit repeated access attempts by locking out the user ID after not more than six attempts.
8.1.7 Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.
Blocage automatique des comptes pendant au moins 30 minutes après 6 tentatives d’authentification échouées

La durée de blocage et le nombre d’authentifications échouées devraient être configurables et différents selon des populations d’utilisateurs.

8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users:

  • Something you know, such as a password or passphrase
  • Something you have, such as a token device or smart card
  • Something you are, such as a biometric.
Support de multiples méthodes d’authentification (mots de passe, certificats, jetons de mots de passe à usage unique (OTP – One-Time Password), etc.

8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components. – Support de mécanismes de chiffrement des communications avec les applications (faisant transiter des secrets) tels que LDAP avec StartTLS, LDAPS, HTTPS, SSH, etc.
– Stockage des mots de passe des utilisateurs de manière sécurisée (par l’utilisation de fonctions cryptographiques non réversibles)
– Stockage des secrets d’authentification à l’aide de mécanismes de dérivation de mots de passe robustes (sha512crypt, Argon2, PBKDF2, etc.)

8.2.2 Verify user identity before modifying any authentication credential—for example, performing password resets, provisioning new tokens, or generating new keys. Vérification de l’identité de l’utilisateur (automatiquement ou manuellement) avant un renouvellement de mot de passe ou l’association d’un nouveau facteur d’authentification

8.2.3 Passwords/passphrases must meet the following:

  • Require a minimum length of at least seven characters.
  • Contain both numeric and alphabetic characters.
Support de règles de robustesse des mots de passe (nombre de caractères, types de caractères nécessaires, autres règles de robustesse – répétition d’un même caractère, dictionnaire de mots de passe connus, etc.)

Cette configuration devrait pouvoir être différente selon des populations d’utilisateurs.

8.2.4 Change user passwords/passphrases at least once every 90 days. Support de l’expiration des mots de passe et de la modification des mots de passe par les utilisateurs (« self-service »)

8.2.5 Do not allow an individual to submit a new password/passphrase that is the same as any of the last four passwords/passphrases he or she has used. Interdiction de la réutilisation d’anciens mots de passe

Le nombre d’anciens mots de passe qui ne peuvent être réutilisés devrait être configurable et différent selon des populations d’utilisateurs.

8.2.6 Set passwords/passphrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use. – Support de la fonctionnalité de modification obligatoire d’un mot de passe lors de son premier usage
– Interdiction de l’utilisation d’un mot de passe avant qu’il soit modifié par l’utilisateur lors de la création ou d’une réinitialisation

8.3 Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication. Support de mécanismes d’authentification multifacteurs

Plus d’informations sur ce qui constitue une authentification multifacteurs acceptable dans le guide du PCI SSC :
https://www.pcisecuritystandards.org/pdfs/Multi-Factor-Authentication-Guidance-v1.pdf.

8.4 Document and communicate authentication policies and procedures to all users including:

  • Guidance on selecting strong authentication credentials
  • Guidance for how users should protect their authentication credentials
  • Instructions not to reuse previously used passwords
  • Instructions to change passwords if there is any suspicion the password could be compromised.
Documentation des règles de sélection, de protection et de gestion des secrets d’authentification à destination des utilisateurs de l’IAM

8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows:

  • Generic user IDs are disabled or removed.
  • Shared user IDs do not exist for system administration and other critical functions.
  • Shared and generic user IDs are not used to administer any system components.
– Interdiction de création de comptes génériques, particulièrement de comptes ayant des privilèges d’administration
ou
– Obligation de liaison d’un compte avec une personne physique lors de sa création
Éventuellement, si des comptes génériques de secours sont utilisés et font l’objet de mesures compensatoires :

  • permettre la détection de l’utilisation d’un compte générique (par exemple via des journaux particuliers qui permettraient ensuite de lever une alerte de sécurité) ;
  • automatiser le renouvellement des mots de passe après utilisation.

8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned as follows:

  • Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.
  • Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.
Détection et interdiction du partage d’un facteur d’authentification entre plusieurs comptes (même mot de passe, certificat, jeton OTP, etc.) avec vérification lors de l’enregistrement du facteur d’authentification

Requirement 10: Track and monitor all access to network resources and cardholder data

10.2 Implement automated audit trails for all system components to reconstruct the following events:
10.2.4 Invalid logical access attempts
10.2.5 Use of and changes to identification and authentication mechanisms—including but not limited to creation of new accounts and elevation of privileges—and all changes, additions, or deletions to accounts with root or administrative privileges
Support de la journalisation des succès et des échecs d’identification et d’authentification des utilisateurs ainsi que toutes les opérations liées à des comptes et autorisations (attribution, modification, révocation)

10.3 Record at least the following audit trail entries for all system components for each event:
10.3.1 User identification
10.3.2 Type of event
10.3.3 Date and time
10.3.4 Success or failure indication
10.3.5 Origination of event
10.3.6 Identity or name of affected data, system component, or resource.
Inclusion de toutes les informations nécessaires dans les journaux générés

Les journaux doivent notamment identifier le composant sur lequel l’authentification a été réalisée, en plus du composant source du journal (qui devrait être un composant de l’IAM).

10.5 Secure audit trails so they cannot be altered.
10.5.1 Limit viewing of audit trails to those with a job-related need.
10.5.2 Protect audit trail files from unauthorized modifications.
Support du contrôle d’accès et de la protection de l’intégrité des journaux générés

10.5.3 Promptly back up audit trail files to a centralized log server or media that is difficult to alter. Support de la centralisation des journaux à l’aide de protocoles standards (syslog, par exemple)

Comme indiqué en introduction, la réponse de l’IAM à ces exigences permet de s’assurer que la solution peut être utilisée de manière à assurer la conformité PCI DSS. Il ne reste ensuite plus qu’à s’assurer que les composants techniques respectent eux-mêmes les exigences du référentiel.

En prenant l’illustration de la partie « transmission » de l’exigence 8.2.1, cela revient à se poser les questions suivantes :

    • d’une part, les secrets utilisés pour s’authentifier sur les composants de l’IAM (serveurs, interfaces d’administration, etc.) sont-ils protégés lors de leur transmission ?
Cela concerne principalement les communications entre les utilisateurs/administrateurs et l’IAM directement (administration via SSH, interface Web de renouvellement de mots de passe en HTTPS, etc.).
    • d’autre part, les secrets des comptes gérés par la solution IAM pour s’authentifier sur d’autres applications le sont-ils également ?
Cela concerne les communications entre les utilisateurs et les applications (ce qui n’a aucun lien avec l’IAM), mais également celles entre les applications et l’IAM. Dans ce second cas, l’IAM doit donc proposer des mécanismes sécurisés (LDAPS, LDAP avec StartTLS ou Kerberos, par exemple).

De la même façon, avec l’exigence 8.2.3 :

  • d’une part, les mots de passe pour s’authentifier sur les composants de l’IAM sont-ils robustes ?
  • d’autre part, les mots de passe des comptes gérés par la solution IAM le sont-ils également ?

En réalité, cette dualité existe systématiquement dès lors qu’un composant assurant une fonction de sécurité ou répondant à une exigence est utilisé dans le cadre d’un environnement PCI DSS, et reviendra toujours à se poser ces deux questions :

  1. le composant est-il conforme ?
  2. les fonctionnalités du composant peuvent-elles êtres configurées ou utilisées de manière conforme ?

Une réponse négative à l’une de ces deux questions pour un composant met alors en péril la conformité de l’ensemble de l’environnement.


Jordan Hordé