Guide des éléments probants d’audit du contrôle d’accès ISO 27001
Il est 09 h 10 le jour de l’audit. Maria, RSSI d’une FinTech et plateforme cloud en forte croissance, a ouvert sa politique de contrôle d’accès. Le responsable informatique exporte les paramètres d’accès conditionnel depuis le fournisseur d’identité. Les ressources humaines recherchent le ticket de sortie d’un analyste financier parti six semaines plus tôt. L’auditeur interne lève les yeux et pose la question que tout le monde attendait :
« Montrez-moi comment l’accès est demandé, approuvé, appliqué, revu et retiré pour un utilisateur disposant d’un accès à privilèges à des données à caractère personnel. »
Cette seule phrase peut révéler si un dispositif de contrôle d’accès est réellement prêt pour l’audit ou seulement prêt sur le papier.
L’équipe de Maria disposait d’un système de management de la sécurité de l’information (SMSI) mature, d’un cycle annuel de recertification ISO/IEC 27001:2022, d’une authentification multifacteur en place, de contrôles d’accès fondés sur les rôles dans les principaux systèmes et de feuilles de calcul trimestrielles de revue des accès. Mais cet audit était différent. La liste des demandes de l’auditeur incluait la préparation aux exigences réglementaires émergentes. Pour l’organisation de Maria, cela signifiait NIS2, DORA et GDPR, tous examinés sous le même angle opérationnel : identité, accès, authentification, privilèges et éléments probants.
Le problème auquel de nombreux RSSI sont confrontés n’est pas l’absence de contrôle d’accès. Le problème est que les éléments probants sont fragmentés. Les approbations d’onboarding se trouvent dans Jira ou ServiceNow. Les paramètres MFA se trouvent dans Microsoft Entra ID, Okta ou un autre fournisseur d’identité. Les autorisations AWS, Azure et Google Cloud résident dans des consoles distinctes. Les actions privilégiées peuvent être journalisées dans un outil PAM, ou ne pas l’être du tout. Le statut RH se trouve dans BambooHR, Workday ou des feuilles de calcul. Les revues d’accès peuvent être validées par courrier électronique.
Lorsqu’un auditeur relie IAM, MFA, PAM, les événements d’entrées, de mobilités et de sorties, les données à caractère personnel, l’administration cloud et les attentes réglementaires, les éléments probants fragmentés se désagrègent rapidement.
Les audits de contrôle d’accès ISO/IEC 27001:2022 ne sont pas de simples revues de configuration technique. Ce sont des tests du système de management. Ils examinent si les risques liés aux identités et aux accès sont compris, traités, mis en œuvre, surveillés et améliorés. Lorsque NIS2, DORA et GDPR sont également applicables, les mêmes éléments probants doivent démontrer une gouvernance des accès fondée sur les risques, une authentification forte, des approbations traçables, une révocation en temps utile, une restriction des privilèges, la protection des données à caractère personnel et la responsabilité de la direction.
La réponse opérationnelle n’est pas un classeur plus volumineux. C’est un modèle unique d’éléments probants de contrôle d’accès qui part du domaine d’application et des risques du SMSI, traverse la politique et la conception des contrôles, se matérialise dans les outils IAM et PAM, puis se cartographie clairement avec ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST et COBIT.
Pourquoi le contrôle d’accès est le pivot réglementaire
Le contrôle d’accès est devenu un sujet de niveau conseil d’administration et exposé aux autorités de régulation, car la compromission d’identité est désormais une voie courante vers l’interruption opérationnelle, la violation de données, la fraude et l’exposition aux risques liés à la chaîne d’approvisionnement.
Au titre de NIS2, les Articles 2 et 3, lus avec l’Annexe I et l’Annexe II, font entrer dans le champ d’application de nombreuses entités moyennes et grandes appartenant aux secteurs listés, en tant qu’entités essentielles ou importantes. Cela inclut les fournisseurs d’infrastructures numériques et de gestion de services TIC, tels que les fournisseurs de services d’informatique en nuage, les fournisseurs de services de centres de données, les fournisseurs de services gérés et les fournisseurs de services de sécurité gérés. Les États membres devaient transposer NIS2 d’ici octobre 2024 et appliquer les mesures nationales à partir d’octobre 2024, avec des listes d’entités attendues en avril 2025. L’Article 20 rend les organes de direction responsables de l’approbation des mesures de gestion des risques de cybersécurité et de la supervision de leur mise en œuvre. L’Article 21 exige des mesures techniques, opérationnelles et organisationnelles, notamment des politiques de contrôle d’accès, la gestion des actifs, l’hygiène cyber, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement et la MFA ou l’authentification continue lorsque cela est approprié.
DORA ajoute une couche de résilience opérationnelle sectorielle pour les entités financières et les prestataires tiers de services TIC pertinents. Les Articles 1, 2 et 64 établissent DORA comme un cadre uniforme applicable à partir du 17 janvier 2025. Les Articles 5 et 6 exigent une gouvernance et un cadre documenté de gestion des risques liés aux TIC. L’Article 9 traite de la protection et de la prévention, notamment des politiques, procédures, protocoles et outils de sécurité TIC. Les Articles 24 à 30 ajoutent les tests de résilience opérationnelle numérique et la gestion des risques liés aux prestataires tiers de services TIC. Pour les entités financières, les éléments probants de contrôle d’accès deviennent des éléments probants de résilience, et non de simples preuves d’administration informatique.
GDPR apporte l’angle des données à caractère personnel. Les Articles 2 et 3 définissent une applicabilité large aux traitements dans l’UE et à l’accès au marché de l’UE. L’Article 5 exige l’intégrité, la confidentialité et une responsabilité démontrable. L’Article 25 exige la protection des données dès la conception et par défaut. L’Article 32 exige des mesures techniques et organisationnelles appropriées. En pratique, cela signifie des accès contrôlés, une authentification sécurisée, la journalisation, la revue et la suppression en temps utile des accès aux systèmes traitant des données à caractère personnel.
ISO/IEC 27001:2022 fournit aux organisations le moteur de système de management permettant d’unifier ces obligations. Les Clauses 4.1 à 4.3 exigent que l’organisation comprenne son contexte, les parties intéressées, les exigences légales et contractuelles, les interfaces, les dépendances et le domaine d’application du SMSI. Les Clauses 6.1.1 à 6.1.3 exigent une appréciation des risques de sécurité de l’information, le traitement des risques, la comparaison avec l’Annexe A, une Déclaration d’applicabilité et l’approbation des plans de traitement des risques et du risque résiduel. La Clause 8.1 exige la maîtrise opérationnelle, des informations documentées montrant que les processus se sont déroulés comme prévu, la gestion des changements et la maîtrise des processus fournis par des tiers.
La question d’audit n’est donc pas : « Avez-vous la MFA ? » Elle est : « Pouvez-vous prouver, pour les identités et les systèmes inclus dans le périmètre, que le risque d’accès est gouverné, traité, mis en œuvre, surveillé et amélioré ? »
Construire l’ossature probante du domaine d’application du SMSI aux éléments probants IAM
Clarysec commence la préparation des audits de contrôle d’accès en rendant les éléments probants traçables depuis le contexte métier. ISO/IEC 27001:2022 attend que le SMSI soit intégré aux processus de l’organisation et dimensionné selon ses besoins. Un éditeur SaaS de 30 personnes et une banque multinationale n’auront pas la même architecture d’accès, mais tous deux doivent disposer d’une chaîne d’éléments probants cohérente.
| Couche d’éléments probants | Ce qu’elle démontre | Systèmes sources typiques | Valeur de conformité croisée |
|---|---|---|---|
| Domaine d’application du SMSI et exigences des parties intéressées | Quels systèmes, données, réglementations et dépendances vis-à-vis de tiers sont dans le périmètre | Domaine d’application du SMSI, registre de conformité, inventaire des données, registre des fournisseurs | Soutient les Clauses 4.2 et 4.3 d’ISO/IEC 27001:2022, la détermination du périmètre NIS2, la cartographie des dépendances TIC DORA et la responsabilité au titre de GDPR |
| Appréciation des risques d’accès | Pourquoi IAM, MFA, PAM et les revues sont nécessaires au regard du risque | Registre des risques, scénarios de menaces, plan de traitement des risques | Soutient la Clause 6.1 d’ISO/IEC 27001:2022, ISO/IEC 27005:2022, le cadre de risque TIC DORA et les mesures de risque NIS2 |
| Politiques et normes internes | Ce que l’organisation exige | Politique de contrôle d’accès, politique de gestion des privilèges, politique d’entrée et de sortie | Convertit les attentes réglementaires en règles internes opposables |
| Configuration IAM et PAM | Si les contrôles sont techniquement mis en œuvre | IdP, SIRH, ITSM, PAM, IAM cloud, consoles d’administration SaaS | Démontre le moindre privilège, la MFA, RBAC, les workflows d’approbation et les contrôles de sessions privilégiées |
| Enregistrements de revue et de surveillance | Si les accès restent appropriés dans le temps | Campagnes de revue des accès, SIEM, journaux PAM, attestations des responsables | Démontre le fonctionnement continu des contrôles, la surveillance DORA, l’hygiène cyber NIS2 et la minimisation GDPR |
| Enregistrements de sortie et d’exceptions | Si les accès sont supprimés et les exceptions maîtrisées | Liste RH des départs, journaux de désactivation, registre des exceptions | Démontre la révocation en temps utile, l’acceptation du risque résiduel et la prévention des violations |
ISO/IEC 27005:2022 est utile car la norme recommande de consolider les exigences légales, réglementaires, contractuelles, sectorielles et internes dans un contexte de risque commun. Les Clauses 6.4 et 6.5 mettent l’accent sur des critères de risque tenant compte des objectifs de l’organisation, des lois, des relations fournisseurs et des contraintes. Les Clauses 7.1 et 7.2 permettent des scénarios fondés sur les événements et sur les actifs. Pour le contrôle d’accès, cela signifie apprécier des scénarios stratégiques tels que « un administrateur SaaS à privilèges exporte des données clients de l’UE » parallèlement à des scénarios d’actifs tels que « une clé IAM AWS orpheline attachée au stockage de production ».
Dans le Zenith Blueprint : feuille de route en 30 étapes pour auditeurs de Clarysec, cette ossature probante est construite pendant la phase Contrôles en action. L’étape 19 porte sur les contrôles technologiques de protection des terminaux et de gestion des accès, tandis que l’étape 22 formalise le cycle de vie organisationnel des accès.
Le Zenith Blueprint demande aux équipes de vérifier que le provisionnement et la suppression des accès sont structurés, intégrés aux RH lorsque cela est possible, appuyés par des workflows de demande d’accès et revus trimestriellement. Il demande également aux organisations de documenter les types d’identités, d’appliquer des contrôles aux identités individuelles, partagées et de service, d’appliquer des politiques robustes de mots de passe et la MFA, d’éliminer les comptes dormants, et de maintenir un coffre-fort sécurisé ou une documentation sécurisée pour les identifiants de service.
C’est exactement ainsi que les auditeurs testent le contrôle d’accès : une identité, un système, une approbation, un privilège, une revue et une révocation à la fois.
Que collecter pour des éléments probants de contrôle d’accès prêts pour l’audit
Votre dossier d’éléments probants de contrôle d’accès doit permettre à un auditeur d’échantillonner n’importe quel utilisateur et de retracer le cycle de vie : demande, approbation, affectation, authentification, élévation de privilèges, surveillance, revue et révocation.
Un dossier probant solide inclut :
- Politique de contrôle d’accès et politique des comptes utilisateurs
- Procédure d’entrées, de mobilités et de sorties
- Matrice de rôles ou matrice de contrôle d’accès
- Liste des applications, plateformes et référentiels de données inclus dans le périmètre
- Configuration MFA du fournisseur d’identité
- Politiques d’accès conditionnel et liste des exceptions
- Inventaire des comptes à privilèges
- Éléments probants des workflows PAM, incluant les approbations et les journaux de session
- Résultat récent d’une campagne de revue des accès
- Échantillons d’attestations de responsables et d’actions de remédiation
- Rapport RH de sortie rapproché des journaux de désactivation
- Inventaire des comptes de service, propriétaires, enregistrements de rotation et éléments probants du coffre-fort
- Procédure de compte d’accès d’urgence et journal de test
- Éléments probants d’incident ou d’alerte liés à des échecs de connexion, à une élévation de privilèges ou à des comptes dormants
- Entrées de la Déclaration d’applicabilité pour les mesures de l’Annexe A liées aux accès
Les politiques Clarysec rendent cette attente explicite. Dans la Politique de contrôle d’accès pour PME, l’exigence est simple et orientée audit :
« Un enregistrement sécurisé doit être conservé pour tout provisionnement, toute modification et toute suppression d’accès. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause 6.1.1.
La même politique PME relie également RBAC et MFA directement aux responsabilités liées aux rôles :
« Met en œuvre des contrôles d’accès fondés sur les rôles (RBAC) et applique une authentification forte, par exemple l’authentification multifacteur (MFA). »
Extrait de la section « Rôles et responsabilités », clause 4.2.3.
Pour les organisations plus grandes, la Politique d’intégration et de départ d’entreprise exige que le système IAM journalise la création de comptes, les affectations de rôles et d’autorisations ainsi que les événements de désactivation, prenne en charge les modèles d’accès basés sur les rôles et s’intègre aux systèmes RH pour les déclencheurs d’entrées, de mobilités et de sorties. Cette clause permet de raconter l’histoire d’audit en un seul endroit : onboarding standardisé, cycle de vie des identités déclenché par les RH et événements IAM traçables.
Cartographier IAM, MFA, PAM et les revues avec les mesures ISO/IEC 27001:2022
Le Zenith Controls : guide de conformité croisée de Clarysec traite le contrôle d’accès comme une famille de contrôles connectés, et non comme un élément de liste de vérification. Pour ISO/IEC 27001:2022, les mesures les plus pertinentes sont notamment :
- Mesure 5.15, contrôle d’accès
- Mesure 5.16, gestion des identités
- Mesure 5.17, informations d’authentification
- Mesure 5.18, droits d’accès
- Mesure 8.2, droits d’accès à privilèges
- Mesure 8.3, restriction d’accès à l’information
- Mesure 8.5, authentification sécurisée
- Mesure 8.15, journalisation
- Mesure 8.16, activités de surveillance
Pour les informations d’authentification, Zenith Controls cartographie la mesure 5.17 comme un contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité, avec la capacité opérationnelle de gestion des identités et des accès. Elle est directement liée à la gestion des identités, à l’authentification sécurisée, aux rôles et responsabilités, à l’utilisation acceptable et à la conformité aux politiques. La sécurité des identifiants couvre le cycle de vie des authentificateurs, leur émission sécurisée, leur stockage, leur réinitialisation, leur révocation, les jetons MFA, les clés privées et les identifiants de service.
Pour les droits d’accès, Zenith Controls cartographie la mesure 5.18 avec l’octroi, la revue, la modification et la révocation formels. Elle est liée au contrôle d’accès, à la gestion des identités, à la séparation des tâches, aux droits d’accès à privilèges et à la surveillance de la conformité. C’est la mesure qui transforme le moindre privilège en éléments probants.
Pour les droits d’accès à privilèges, Zenith Controls cartographie la mesure 8.2 avec le risque spécifique des comptes élevés, notamment les administrateurs de domaine, les utilisateurs root, les administrateurs de tenant cloud, les superutilisateurs de bases de données et les contrôleurs CI/CD. Le guide relie les accès à privilèges à la gestion des identités, aux droits d’accès, à la restriction d’accès à l’information, à l’authentification sécurisée, au télétravail, à la journalisation et à la surveillance.
| Sujet d’audit | Éléments probants d’accès ISO/IEC 27001:2022 | Cartographie NIS2 | Cartographie DORA | Cartographie GDPR |
|---|---|---|---|---|
| Cycle de vie IAM | Workflow d’entrées, de mobilités et de sorties, demandes d’accès, approbations, modèles de rôles, journaux de désactivation | Mesures de gestion des risques de l’Article 21, politiques de contrôle d’accès et gestion des actifs | Articles 5, 6 et 9 sur la gouvernance, le cadre de risque TIC, la sécurité logique et le contrôle d’accès | Articles 5, 25 et 32 sur la responsabilité, la minimisation et la sécurité |
| MFA | Politique IdP, captures d’écran d’accès conditionnel, statistiques d’enrôlement MFA, approbations d’exceptions | Article 21(2)(j) MFA ou authentification continue lorsque cela est approprié | Accès sécurisé aux systèmes TIC critiques et contrôles des risques TIC | Mesures techniques appropriées contre l’accès non autorisé |
| PAM | Inventaire des comptes à privilèges, approbations, élévation JIT, journaux de session, rotation en coffre-fort | Article 21(2)(i) contrôle d’accès fondé sur les risques et gestion des actifs | Protection des systèmes TIC, résilience opérationnelle et surveillance | Restriction et audit des accès élevés aux données à caractère personnel |
| Revues d’accès | Enregistrements de revues trimestrielles ou semestrielles, attestations des responsables, tickets de remédiation | Hygiène cyber, politiques de contrôle d’accès et gestion des actifs | Surveillance continue, accès fondé sur les rôles et processus de révocation | Protection des données par défaut et responsabilité démontrable |
| Sortie | Liste RH des départs, éléments probants de verrouillage ou de suppression de compte, révocation des jetons | Suppression en temps utile des accès inutiles | Maîtrise des accès TIC tout au long du cycle de vie | Prévention de l’accès non autorisé aux données à caractère personnel |
Un seul rapport de revue d’accès bien conçu peut soutenir ISO/IEC 27001:2022, NIS2, DORA et GDPR s’il inclut le périmètre, le propriétaire du système, le réviseur, la liste des comptes, la justification des rôles, l’indicateur de privilège, l’indicateur de sensibilité des données, les décisions, les suppressions, les exceptions et la date d’achèvement.
Les éléments probants MFA ne se limitent pas à une capture d’écran
Une erreur d’audit fréquente consiste à présenter une capture d’écran indiquant « MFA activée ». Les auditeurs ont besoin de plus que cela. Ils doivent savoir où la MFA s’applique, qui en est exclu, comment les exceptions sont approuvées, si les comptes à privilèges sont couverts et si la configuration technique correspond à la politique.
Dans le Zenith Blueprint, phase Contrôles en action, étape 19, les auditeurs demanderont comment les politiques de mots de passe et de MFA sont appliquées, quels systèmes sont protégés, à qui la MFA s’applique et si les applications critiques peuvent être testées avec un compte échantillon. Les éléments probants peuvent inclure la configuration de l’IdP, les politiques d’accès conditionnel, les statistiques d’enrôlement MFA et les procédures de réinitialisation des mots de passe.
Pour les environnements d’entreprise, la Politique de gestion des comptes utilisateurs et des privilèges de Clarysec indique :
« Lorsque cela est techniquement possible, l’authentification multifacteur (MFA) est obligatoire pour : 6.3.2.1 Les comptes administratifs et les comptes de niveau root 6.3.2.2 L’accès à distance (VPN, plateformes cloud) 6.3.2.3 L’accès aux données sensibles ou réglementées »
Extrait de la section « Exigences de mise en œuvre de la politique », clause 6.3.2.
Cela crée un pont direct avec l’audit. Si la MFA est obligatoire pour les comptes administrateur, l’accès à distance et les données réglementées, le dossier d’éléments probants doit inclure les listes de comptes administratifs et de niveau root, la configuration de l’accès à distance, les politiques d’accès conditionnel des plateformes cloud, les listes d’applications traitant des données sensibles, les rapports d’enrôlement MFA, les approbations d’exceptions, les contrôles compensatoires et les éléments probants récents de revue d’alertes relatives aux échecs de connexion ou aux tentatives de contournement de la MFA.
Pour NIST SP 800-53 Rev. 5, cela s’aligne sur IA-2 Identification and Authentication, IA-5 Authenticator Management, AC-17 Remote Access et AU-2 Event Logging. Pour COBIT 2019, cela soutient DSS05.04 Manage user identity and logical access ainsi que les pratiques associées de surveillance de la sécurité.
Les normes ISO de soutien élargissent la perspective. ISO/IEC 27018:2020 étend les attentes d’authentification pour le cloud public traitant des données à caractère personnel. ISO/IEC 24760-1:2019 soutient l’association des authentificateurs et la gestion de leur cycle de vie. ISO/IEC 29115:2013 introduit des niveaux d’assurance d’authentification, utiles pour décider où des clés matérielles ou une MFA résistante au phishing sont nécessaires. ISO/IEC 27033-1:2015 soutient l’authentification réseau forte pour les accès distants ou inter-réseaux.
Les éléments probants PAM sont la voie la plus rapide vers un constat majeur ou un audit sans réserve
L’accès à privilèges est le point sur lequel les auditeurs deviennent sceptiques, car les comptes à privilèges peuvent contourner les contrôles, extraire des données, créer de la persistance et modifier les journaux. Dans le Zenith Blueprint, l’étape 19 indique :
« Dans tout système d’information, l’accès à privilèges est un pouvoir ; ce pouvoir s’accompagne d’un risque. »
Les lignes directrices portent sur les personnes disposant d’un accès à privilèges, ce que cet accès permet, la façon dont il est géré et la manière dont il est surveillé dans le temps. Elles recommandent un inventaire à jour, le moindre privilège, RBAC, l’élévation fondée sur le temps ou juste-à-temps, les workflows d’approbation, les comptes nominatifs uniques, l’évitement des comptes partagés, la journalisation des accès d’urgence, les systèmes PAM, la rotation des identifiants, la mise en coffre-fort, l’enregistrement des sessions, l’élévation temporaire, la surveillance et la revue régulière.
La Politique de contrôle d’accès d’entreprise de Clarysec transforme cela en exigence de contrôle :
« L’accès administratif doit être strictement contrôlé au moyen de : 5.4.1.1 Comptes à privilèges distincts 5.4.1.2 Surveillance et enregistrement des sessions 5.4.1.3 Authentification multifacteur 5.4.1.4 Élévation limitée dans le temps ou déclenchée par workflow »
Extrait de la section « Exigences de gouvernance », clause 5.4.1.
Cette citation constitue presque un script de test d’audit. Si la politique prévoit des comptes administrateur distincts, montrez la liste des comptes à privilèges et prouvez que chacun correspond à une personne nommée. Si elle prévoit la surveillance des sessions, montrez les sessions enregistrées ou les journaux PAM. Si elle prévoit la MFA, démontrez son application sur chaque chemin d’accès à privilèges. Si elle prévoit une élévation limitée dans le temps, montrez les horodatages d’expiration et les tickets d’approbation.
La version PME est tout aussi directe. La Politique de gestion des comptes utilisateurs et des privilèges pour PME indique :
« Les privilèges élevés ou administratifs exigent une approbation supplémentaire par le Directeur général ou le responsable informatique et doivent être documentés, limités dans le temps et soumis à une revue périodique. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause 6.2.2.
Pour les organisations plus petites, c’est souvent ce qui distingue « nous faisons confiance à notre administrateur » de « nous maîtrisons le risque lié aux privilèges ». L’auditeur n’exige pas un outillage d’entreprise dans chaque PME, mais il exige des éléments probants proportionnés au risque. Un ticket, une approbation, une affectation temporaire à un groupe, l’application de la MFA et un enregistrement de revue peuvent suffire lorsque le périmètre est limité et le risque plus faible.
Les revues d’accès prouvent que le moindre privilège fonctionne
Les revues d’accès montrent si les autorisations s’accumulent silencieusement. Elles montrent également si les responsables comprennent réellement les accès détenus par leurs équipes.
La Politique de gestion des comptes utilisateurs et des privilèges d’entreprise exige :
« Des revues trimestrielles de tous les comptes utilisateurs et privilèges associés doivent être menées par la sécurité informatique en collaboration avec les responsables de département. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause 6.5.1.
Pour les PME, la Politique de gestion des comptes utilisateurs et des privilèges pour PME fixe une périodicité proportionnée :
« Une revue de tous les comptes utilisateurs et privilèges doit être réalisée tous les six mois. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause 6.4.1.
Une revue d’accès crédible inclut le nom du système, le périmètre, le nom du réviseur, la date d’export, la date de revue, le propriétaire de l’identité, le service, le responsable, le statut d’emploi, le rôle ou l’habilitation, l’indicateur de privilège, l’indicateur de sensibilité des données, la décision, le ticket de remédiation, la date de clôture, le propriétaire de l’exception et la date d’expiration de l’exception.
Dans Zenith Controls, les droits d’accès 5.18 sont le point où cela devient un élément probant de conformité croisée. Le guide cartographie les droits d’accès avec GDPR Article 25, car l’accès doit être limité dès la conception et par défaut. Il les cartographie avec NIS2 Article 21(2)(i), car les politiques de contrôle d’accès et la gestion des actifs exigent une affectation fondée sur les risques, la suppression en temps utile des accès inutiles et une révocation formelle. Il les cartographie avec DORA, car les systèmes TIC financiers nécessitent des processus d’accès fondé sur les rôles, de surveillance et de révocation.
Les auditeurs orientés NIST testent souvent cela via AC-2 Account Management, AC-5 Separation of Duties et AC-6 Least Privilege. Les auditeurs COBIT 2019 examinent DSS05.04 Manage user identity and logical access et DSS06.03 Manage roles, responsibilities, access privileges and levels of authority. Les auditeurs ISACA ITAF se concentrent sur le caractère suffisant, fiable et complet des éléments probants.
Le départ et la révocation des jetons sont faciles à échantillonner
Les départs sont l’un des points les plus simples pour prouver que le cycle de vie fonctionne. Les auditeurs sélectionnent souvent un salarié récemment parti et demandent l’enregistrement RH de départ, le ticket, le journal de désactivation du compte, l’élément probant de désactivation SaaS, la suppression VPN, la révocation MFA, la suppression des jetons API et la restitution des actifs.
Dans la Politique d’intégration et de départ pour PME, Clarysec indique :
« Les comptes résiliés doivent être verrouillés ou supprimés, et les jetons d’accès associés doivent être révoqués, y compris l’accès à distance (VPN), les associations d’applications MFA et les jetons API. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause 6.3.3.
Ce point est important, car l’accès moderne ne se limite pas à un identifiant utilisateur et à un mot de passe. L’accès peut persister au moyen de jetons de rafraîchissement, de clés API, de clés SSH, d’autorisations OAuth, de comptes de service, de droits d’administrateur local, de sessions mobiles et de portails tiers. Un enregistrement RH désactivé sans révocation des jetons constitue un élément probant incomplet.
Le Zenith Blueprint, phase Contrôles en action, étape 16, demande aux organisations d’être prêtes avec une liste de contrôle de fin de contrat documentée, des éléments probants issus d’un départ récent, un journal de désactivation de compte utilisateur provenant d’AD ou de MDM, un formulaire signé de restitution des actifs et une documentation de départ incluant les obligations de confidentialité.
L’auditeur de Maria a demandé le dossier d’un développeur senior sortant qui disposait d’un accès à privilèges aux bases de données de production. Son équipe a présenté la Politique d’intégration et de départ pour PME, la liste de contrôle de départ construite à partir de l’étape 16 du Zenith Blueprint, le ticket ITSM déclenché par les RH, le journal de désactivation de l’annuaire, la révocation du certificat VPN, la suppression de l’organisation GitHub, la suppression de la clé IAM AWS et le ticket de vérification clôturé signé par le responsable informatique. Les éléments probants étaient complets, produits en temps utile et directement rattachés à la politique.
Exécuter un sprint probant sur trois échantillons avant l’auditeur
Un exercice pratique de préparation consiste à choisir trois échantillons avant l’audit :
- Un nouvel employé arrivé au cours des 90 derniers jours
- Un utilisateur à privilèges disposant d’un accès administrateur au cloud, à une base de données, à la production ou à IAM
- Un employé parti ou ayant changé de rôle au cours des 90 derniers jours
| Échantillon | Éléments probants à collecter | Condition de réussite | Constat fréquent |
|---|---|---|---|
| Nouvel employé | Enregistrement RH d’arrivée, demande d’accès, approbation, affectation de rôle, enrôlement MFA, première connexion | Accès accordé uniquement après approbation et aligné sur le rôle | Accès accordé avant approbation ou rôle trop large |
| Utilisateur à privilèges | Justification métier, compte administrateur distinct, preuve MFA, approbation PAM, journal de session, revue trimestrielle | Le privilège est nominatif, justifié, limité dans le temps lorsque cela est possible, surveillé et revu | Compte administrateur partagé, MFA manquante, absence d’élément probant de session |
| Départ ou mobilité | Événement RH, ticket de départ ou de changement de rôle, journaux de désactivation, suppression VPN, révocation de jeton MFA ou API, clôture de revue | Accès supprimé rapidement et complètement | Compte SaaS toujours actif, jeton API non révoqué, ancienne appartenance à un groupe conservée |
Reliez ensuite chaque échantillon aux enregistrements du SMSI : scénario de risque, décision de traitement, sélection des mesures dans la Déclaration d’applicabilité, clause de politique, configuration technique, enregistrement de revue et action corrective en cas d’écart.
Cela transforme la préparation à l’audit : il ne s’agit plus de collecter des documents, mais de vérifier les contrôles.
Se préparer à différents angles d’audit
Les différents profils d’audit conduisent à des questions différentes, même lorsque les éléments probants sont les mêmes.
| Angle de l’auditeur | Point d’attention principal | Éléments probants attendus |
|---|---|---|
| Auditeur ISO/IEC 27001:2022 | Processus SMSI, traitement des risques et fonctionnement des contrôles | Appréciation des risques, Déclaration d’applicabilité, politiques approuvées, demandes d’accès, enregistrements de revue, journaux de désactivation |
| Pratique d’audit ISO/IEC 19011:2018 | Échantillonnage, corroboration et cohérence | Paramètres de mots de passe, seuils de verrouillage, horodatages d’approbation, enregistrements d’exécution, entretiens |
| Auditeur SMSI ISO/IEC 27007:2020 | Conduite de l’audit SMSI et efficacité | Définitions de rôles comparées aux autorisations réelles, pistes d’approbation des privilèges, journaux de révocation |
| Évaluateur orienté NIST | Mise en œuvre technique et tests des contrôles | Éléments probants AC-2, AC-5, AC-6, AC-17, IA-2, IA-5 et AU-2 issus des outils IAM, PAM et SIEM |
| Auditeur COBIT 2019 ou ISACA | Gouvernance, propriété et fiabilité des éléments probants | Éléments probants de processus DSS05.04 et DSS06.03, indicateurs, exceptions, suivi de la remédiation |
| Évaluateur DORA | Risque TIC, résilience et criticité | Listes d’accès aux systèmes critiques, surveillance des privilèges, contrôles des administrateurs tiers, liens avec les tests de résilience |
| Évaluateur NIS2 | Responsabilité de la direction et mesures de risque | Supervision par le conseil d’administration, mesures de contrôle d’accès de l’Article 21, couverture MFA, préparation à la gestion des incidents |
| Évaluateur GDPR | Confidentialité des données à caractère personnel et responsabilité | Restrictions d’accès aux données à caractère personnel, éléments probants de protection de la vie privée par défaut au titre de l’Article 25, mesures de sécurité de l’Article 32 |
Préparer des éléments probants répondant à toutes ces perspectives démontre la maturité du programme de conformité et réduit le travail en double.
Constats fréquents et actions préventives
Les constats relatifs au contrôle d’accès sont prévisibles. Les actions préventives le sont aussi.
| Constat | Pourquoi c’est important | Prévention |
|---|---|---|
| Les revues d’accès existent, mais les comptes à privilèges en sont exclus | Les droits d’administration créent le risque d’impact le plus élevé | Inclure l’indicateur de privilège, les enregistrements PAM et les groupes administrateur dans chaque revue |
| La MFA est activée pour les employés, mais pas pour les centres de services, les prestataires ou les administrateurs cloud | Les attaquants ciblent les exceptions | Maintenir un rapport de couverture MFA et un registre des exceptions avec dates d’expiration |
| Le processus d’arrivée est documenté, mais les mobilités ne sont pas gérées | La dérive des privilèges s’accumule après les changements de rôle | Déclencher une revue d’accès à chaque changement de département ou de rôle |
| Des comptes administrateur partagés existent sans contrôles compensatoires | La responsabilité est faible | Remplacer par des comptes administrateur nominatifs ou imposer le retrait depuis le coffre-fort et la journalisation des sessions |
| Les départs sont désactivés dans l’annuaire, mais restent actifs dans les plateformes SaaS | L’accès persiste hors de l’IdP central | Maintenir un inventaire applicatif et une liste de contrôle de départ pour chaque système |
| Les mots de passe des comptes de service sont inconnus ou ne sont jamais renouvelés | Les identités non humaines deviennent des portes dérobées cachées | Désigner des propriétaires, placer les secrets en coffre-fort, effectuer la rotation des identifiants et revoir les journaux d’utilisation |
| La politique prévoit une revue trimestrielle, mais les éléments probants montrent une revue annuelle | La politique et la pratique divergent | Ajuster la périodicité selon les risques ou appliquer l’exigence documentée |
| Les approbations d’accès sont dans les courriels sans règle de conservation | La piste d’audit est fragile | Utiliser des workflows ITSM et une conservation alignée sur la politique |
La Politique de contrôle d’accès d’entreprise ajoute une exigence de conservation qui prévient l’un des échecs probants les plus fréquents :
« Les décisions d’approbation doivent être journalisées et conservées à des fins d’audit pendant au moins 2 ans. »
Extrait de la section « Exigences de gouvernance », clause 5.3.2.
Si les approbations disparaissent après le nettoyage des courriels, le contrôle a peut-être fonctionné, mais l’audit ne peut pas s’y fier. La conservation fait partie de la conception du contrôle.
La responsabilité de la direction exige des indicateurs d’accès
NIS2 Article 20 et DORA Articles 5 et 6 font du contrôle d’accès un sujet de direction, car une compromission d’identité peut se transformer en interruption opérationnelle, notification réglementaire, violation de données et préjudice client. Les Clauses 5.1 à 5.3 d’ISO/IEC 27001:2022 exigent également que la haute direction aligne le SMSI sur la stratégie métier, fournisse les ressources, communique l’importance du sujet, attribue les responsabilités et promeuve l’amélioration continue.
Les indicateurs utiles de contrôle d’accès incluent :
- Pourcentage de systèmes critiques couverts par SSO
- Pourcentage de comptes à privilèges avec MFA
- Nombre de comptes à privilèges permanents par rapport aux comptes JIT
- Taux d’achèvement des revues d’accès
- Nombre d’autorisations excessives révoquées
- Respect du SLA de désactivation des départs
- Nombre de comptes dormants
- Couverture des propriétaires de comptes de service
- Couverture de l’enregistrement des sessions PAM
- Nombre et ancienneté des exceptions MFA
Ces indicateurs aident la direction à approuver le traitement des risques et à démontrer sa supervision. Ils rendent également les audits plus crédibles, car l’organisation peut montrer que le contrôle d’accès est surveillé comme un risque vivant, et non redécouvert avant chaque audit.
Transformer des éléments probants dispersés en confiance d’audit
Si les éléments probants de contrôle d’accès ISO/IEC 27001:2022 sont dispersés entre les RH, ITSM, IAM, PAM, consoles cloud et feuilles de calcul, l’étape suivante n’est pas une nouvelle réécriture de politique. L’étape suivante est l’architecture des éléments probants.
Commencez par cette séquence :
- Définir les systèmes, identités et données inclus dans le périmètre.
- Cartographier NIS2, DORA, GDPR et les exigences contractuelles dans le contexte du SMSI.
- Utiliser des scénarios de risque de type ISO/IEC 27005:2022 pour prioriser IAM, MFA, PAM et les revues d’accès.
- Mettre à jour la Déclaration d’applicabilité et le plan de traitement des risques.
- Aligner les clauses de politique sur les workflows IAM et PAM réels.
- Exécuter le sprint probant sur trois échantillons.
- Corriger les lacunes avant que l’auditeur ne les identifie.
- Maintenir un dossier probant réutilisable pour la certification, les diligences raisonnables clients et les revues réglementaires.
Clarysec peut vous aider à mettre cela en œuvre avec Zenith Blueprint : feuille de route en 30 étapes pour auditeurs, à cartographier les exigences avec Zenith Controls : guide de conformité croisée et à opérationnaliser les exigences avec le bon ensemble de politiques Clarysec, notamment la Politique de contrôle d’accès, la Politique de gestion des comptes utilisateurs et des privilèges et la Politique d’intégration et de départ.
La préparation à l’audit du contrôle d’accès ne consiste pas à prouver que vous avez acheté un outil IAM. Elle consiste à prouver que les processus d’identité, d’authentification, de privilèges et de revue réduisent les risques métier réels et satisfont les normes et réglementations pertinentes pour votre organisation.
Téléchargez les kits d’outils Clarysec, exécutez le sprint probant sur trois échantillons et transformez vos éléments probants de contrôle d’accès, aujourd’hui dispersés, en un dossier d’audit clair, reproductible et défendable.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
