Organigramme du processus de demande d’accès
Organigramme du processus de demande d’accès : demande basée sur un rôle, approbation du responsable hiérarchique et du propriétaire du système, contrôle de séparation des tâches, attribution et recertification.
Qu'est-ce que le processus organigramme du processus de demande d’accès ?
Un processus de demande d’accès permet à une personne d’obtenir l’accès dont elle a besoin pour son travail sans que l’organisation ne perde la trace de qui peut faire quoi. Il commence par une demande portant sur un rôle défini plutôt qu’une liste de permissions individuelles, passe par l’approbation de la personne responsable du demandeur et de celle responsable du système, et se termine par un droit d’accès enregistré dans un registre portant une date de prochaine revue.
Les étapes le plus souvent sautées sont celles qui deviennent plus tard des constats d’audit. Un contrôle de séparation des tâches empêche qu’une seule personne détienne deux rôles qui n’étaient jamais censés coexister, comme créer un fournisseur et le payer. Une revue de sécurité distincte maintient l’accès administrateur et aux données sensibles hors du même circuit d’approbation qu’un rapport en lecture seule. Et la recertification est la seule raison pour laquelle le registre reste fidèle à la réalité : sans revue planifiée, les accès s’accumulent à chaque changement d’équipe, et rien n’est jamais retiré.
Ce modèle cartographie le flux complet, de la demande à la recertification, sur cinq couloirs : Demandeur, Responsable hiérarchique, Propriétaire du système ou des données, Service d’assistance informatique et Sécurité. Il inclut les deux points de branchement sur lesquels les équipes s’opposent le plus, à savoir ce qui se passe lorsqu’un rôle demandé entre en conflit avec un accès déjà détenu par la personne, et quelles demandes nécessitent une revue de sécurité avant l’attribution. Il boucle le processus avec une revue planifiée qui reconfirme l’accès ou le révoque. La structure suit le schéma fixé par les contrôles de l’Annexe A d’ISO/IEC 27001:2022 sur le contrôle d’accès (A.5.15), la gestion des identités (A.5.16) et les droits d’accès (A.5.18).
Ce que couvre cet organigramme
Dans ce modèle
- Demande dans le couloir Demandeur : soumettre une demande d’accès, puis sélectionner un rôle défini dans le catalogue d’accès avec une justification métier et une date de fin lorsque l’accès est temporaire.
- Deux points d’approbation avant tout contrôle technique : le responsable hiérarchique approuve ou rejette, puis le propriétaire du système ou des données examine les droits que le rôle accorde réellement et approuve ou rejette. Les deux branches de rejet aboutissent à un seul nœud « Demande refusée et clôturée ».
- Une décision « Séparation des tâches en conflit ? » dans le couloir du service d’assistance informatique, avec une branche de conflit qui renvoie la demande au propriétaire du système pour modifier le périmètre ou ajouter un contrôle compensatoire, puis revérifie plutôt que de laisser passer.
- Une décision « Accès privilégié ou sensible ? » qui achemine les demandes d’administrateur et à haut risque vers une approbation de sécurité distincte, tandis que les demandes ordinaires poursuivent directement vers l’attribution.
- Attribution et tenue des registres : attribuer l’accès selon le principe du moindre privilège, confirmer l’accès au demandeur, faire accepter au demandeur les conditions d’utilisation acceptable, et enregistrer le droit dans le registre des accès.
- La boucle de recertification dans la dernière colonne : la sécurité déclenche une revue planifiée, le propriétaire du système décide si l’accès est toujours nécessaire, et la branche « Non » révoque l’accès dans le système cible et met à jour le registre.
Quand utiliser ce modèle
- Rédiger ou revoir une procédure de contrôle d’accès pour ISO 27001, SOC 2 ou un audit interne, lorsque vous avez besoin d’une image commune de qui approuve quoi et de ce qui est enregistré.
- Configurer un flux de demande dans un service d’assistance ou un outil de gouvernance des identités, afin que l’outil encode un processus déjà convenu plutôt que d’en inventer un pendant l’implémentation.
- Répondre à un auditeur ou à un questionnaire de sécurité client demandant comment les accès sont demandés, approuvés, attribués et revus.
- Former les nouveaux approbateurs, en particulier les responsables hiérarchiques et les propriétaires de système, qui doivent savoir ce qu’ils signent réellement et ce qui se passe s’ils tardent à répondre.
- Traiter la dérive des accès après qu’une revue a révélé des comptes détenant des droits que personne ne pouvait expliquer ni rattacher à une approbation.
Comment cela fonctionne
Nommer vos véritables approbateurs
Renommez les cinq couloirs selon les rôles que vous avez réellement. Dans les organisations plus petites, le propriétaire du système et le relecteur sécurité sont souvent la même personne ; fusionnez ces couloirs plutôt que de dessiner une approbation qui n’a jamais lieu. Gardez un couloir par décideur, pas par individu, afin que le schéma survive à un changement de poste.
Définir ce qui compte comme privilégié ou sensible
La décision « Accès privilégié ou sensible ? » ne fonctionne que si les critères sont écrits à côté. Les déclencheurs typiques sont les comptes administrateur et root, les comptes de service, l’accès aux données personnelles ou financières, et tout ce qui peut modifier la production. Fixez le seuil de sorte que la branche sécurité ne se déclenche que pour une minorité de demandes, sinon elle devient un simple tampon.
Consigner vos règles de séparation des tâches
Listez les combinaisons qu’aucune personne ne peut détenir, par exemple créer un fournisseur et approuver son paiement, ou écrire du code et le déployer en production. Sans cette matrice, le contrôle de conflit n’est qu’une mise en scène. Décidez aussi qui valide un contrôle compensatoire lorsque le conflit est inévitable, et enregistrez-le en regard du droit d’accès.
Décider où vit le registre des accès
Faites pointer l’étape de registre vers le système que vous allez réellement maintenir, qu’il s’agisse d’un outil de gouvernance des identités, de votre plateforme ITSM ou d’un tableur contrôlé. Assurez-vous que la branche de révocation met à jour le même enregistrement, sinon le registre devient peu à peu une liste d’accès accordés plutôt que d’accès existants.
Fixer la cadence de recertification et son responsable
Remplacez la revue planifiée générique par votre propre fréquence et votre propre déclencheur, par exemple trimestrielle pour les comptes privilégiés et annuelle pour les rôles standards, plus une revue hors cycle en cas de changement de rôle. Nommez qui relance les relecteurs et ce qui se passe quand une échéance de revue est dépassée, car une revue sans responsable est l’étape qui cesse discrètement de fonctionner.
Faire approuver le schéma et en garder une version unique à jour
Partagez le schéma avec les approbateurs qui y sont nommés, recueillez leur validation, et liez la version approuvée depuis votre politique de contrôle d’accès. Garder le diagramme sous contrôle de version avec une approbation enregistrée signifie que le processus suivi par les équipes et celui montré à un auditeur sont un seul et même processus.
Questions fréquentes
Qu’est-ce qu’un processus de demande d’accès ?
C’est le parcours défini qu’une demande d’accès système suit depuis le moment où quelqu’un la formule jusqu’au moment où elle est accordée, enregistrée puis revue. Un processus complet comporte quatre parties : une demande nommant un rôle défini et une raison métier, l’approbation par une personne responsable du demandeur et une personne responsable du système, l’attribution par celui qui détient les droits administratifs, et un enregistrement du droit avec une date de revue. La demande et l’attribution sont délibérément des étapes distinctes réalisées par des personnes différentes, afin que personne ne s’accorde d’accès à soi-même.
Qui doit approuver une demande d’accès ?
Deux approbateurs couvrent la plupart des situations. Le responsable hiérarchique confirme que la personne a besoin de cet accès pour son travail, une question qui porte sur le demandeur. Le propriétaire du système ou des données confirme ce que le rôle accorde réellement et si cette personne devrait le détenir, une question qui porte sur le système. Une troisième approbation de la sécurité ne vaut la peine d’être ajoutée que pour un accès privilégié ou sensible, ce que ce modèle achemine ainsi. Ajouter davantage d’approbateurs améliore rarement la décision et allonge de façon fiable le temps d’attente, ce qui alimente des contournements informels comme le partage de mots de passe.
Qu’est-ce qu’un contrôle de séparation des tâches en gestion des accès ?
Il vérifie si le rôle demandé, combiné aux accès déjà détenus par la personne, lui permettrait de réaliser seule une transaction sensible de bout en bout sans aucune étape indépendante. Les exemples courants sont créer un fournisseur et approuver ses paiements, ou écrire du code et le déployer en production. Le contrôle nécessite une liste convenue de combinaisons conflictuelles à tester. Lorsqu’un conflit ne peut être évité, par exemple dans une petite équipe, la réponse habituelle est un contrôle compensatoire documenté, comme une revue a posteriori par une autre personne, enregistré en regard du droit d’accès.
À quelle fréquence les accès utilisateurs doivent-ils être recertifiés ?
C’est le risque qui doit fixer la fréquence. Un schéma courant est trimestriel pour les comptes privilégiés et administrateurs, annuel pour les rôles métier standards, et une revue immédiate hors cycle dès qu’une personne change de rôle ou d’équipe. Le contrôle A.5.18 d’ISO/IEC 27001:2022 exige que les droits d’accès soient revus régulièrement mais ne prescrit pas d’intervalle, la fréquence reste donc à justifier par vous-même. Notez qu’un organigramme documente une intention plutôt qu’il ne prouve la conformité : la preuve qu’un auditeur demande, ce sont les approbations et le registre que le processus produit.
Où ce processus s'inscrit
Dans la plupart des opérations, ce processus suit Organigramme du processus d'assistance informatique (incidents et demandes) et passe le relais à Organigramme du processus de demande d'accès des employés (menuisier et….
C'est une étape de Gouvernance d’accès.
Étape 1: Organigramme du processus de provisionnement des utilisateurs (rejoindre,…
Organigramme du processus de provisionnement des utilisateurs : événement RH, identité créée dans l'annuaire, informations d'identification et MFA, ensemble de droits de rôle, approbation du propriétaire pour l'accès privilégié, comptes…
Étape 2: Organigramme du processus de demande d’accès Vous êtes ici
Organigramme du processus de demande d’accès : demande basée sur un rôle, approbation du responsable hiérarchique et du propriétaire du système, contrôle de séparation des tâches, attribution et recertification.
Étape 3: Organigramme du processus de demande d'accès des employés (menuisier et…
Organigramme du processus de demande d'accès des employés pour les nouveaux arrivants et les déménageurs : demande déclenchée par les RH, profil d'accès au rôle, approbation du responsable et du propriétaire, suppression de l'ancien rôle.
Étape 4: Organigramme du processus de suppression de l'accès des utilisateurs…