Mettre en œuvre les revues d’accès IGA et la SoD
Mettre en œuvre les revues d’accès IGA et la SoD
Section intitulée « Mettre en œuvre les revues d’accès IGA et la SoD »L’IGA (Identity Governance and Administration) relie les droits techniques à une réalité métier : une personne, une fonction, un contrat, une date de départ. Le compromis central est brutal : plus le contrôle est fin, plus il exige des données fiables et des responsables disponibles. La recommandation est donc de commencer par automatiser les événements de cycle de vie et les droits à risque, pas par lancer une grande campagne de certification qui finira validée en bloc.
→ Lire l’explication complète de la marmotte
Cycle de vie des identités et comptes orphelins
Section intitulée « Cycle de vie des identités et comptes orphelins »Une identité ne doit pas naître dans l’annuaire parce qu’un ticket le demande. Elle doit provenir d’une source d’autorité identifiée : ressources humaines pour un salarié, gestion fournisseur pour un prestataire, registre de services pour un compte applicatif. Cette source porte au minimum un identifiant immuable, le statut d’emploi, la date de début, la date de fin et le responsable. Sans identifiant immuable, un changement de nom ou une réembauche produit des collisions ou, pire, ressuscite des droits anciens.
Le cycle Joiner, Mover, Leaver, souvent traduit par arrivée, changement, départ, doit être événementiel. À l’arrivée, on crée l’identité et les accès de base. Lors d’un changement de rôle, on retire les droits hérités de l’ancienne fonction avant d’ajouter ceux de la nouvelle. Au départ, on bloque la capacité d’authentification, révoque les sessions, supprime les jetons, les clés et les facteurs d’authentification, puis traite les boîtes partagées et les délégations. Désactiver le compte central sans désactiver les comptes locaux, les clés d’accès cloud et les comptes de service associés laisse un cadavre administratif parfaitement capable de se connecter.
La règle exploitable est la suivante : aucun compte humain actif ne peut exister sans source d’autorité, sans responsable nominatif et sans date de dernière synchronisation. Les comptes sans correspondance depuis une durée définie doivent être suspendus automatiquement, puis supprimés après une période de rétention validée. L’exception doit être documentée et expirante. Une exception sans date de fin n’est pas une exception, c’est une dette avec un badge.
Les comptes techniques méritent un traitement séparé. Ils n’ont pas de manager humain fictif, ne doivent pas être partagés entre applications, et doivent avoir un propriétaire de service. Leur secret doit être stocké dans un coffre, roté automatiquement lorsque le protocole le permet, et leur activité journalisée. Un compte de service doté de droits d’administration permanents est un compte orphelin qui attend seulement son départ officiel.
Les fondations d’authentification, notamment la résistance au vol de session et la récupération de compte, restent décrites dans la section identités. L’IGA ne rend pas un mécanisme d’authentification faible plus courageux.
Revues d’accès et recertification périodique
Section intitulée « Revues d’accès et recertification périodique »Une revue d’accès vérifie qu’un droit existant a encore une justification. Elle ne prouve pas que le système est bien conçu, ni qu’un approbateur a réellement lu une liste. Le mécanisme échoue dès que la campagne demande à un responsable de valider plusieurs centaines de lignes opaques avec des intitulés techniques. La validation en masse est alors rationnelle : le coût cognitif dépasse le bénéfice perçu. Les plateformes appellent cela une attestation ; le résultat ressemble souvent à un bouton vert avec une date d’échéance.
Une recertification utile se limite aux droits qui changent réellement le risque : administration, accès aux données sensibles, paiement, export massif, délégation d’identité, contournement de journalisation et capacité de créer de nouveaux privilèges. Les droits de base, attribués par une fonction stable et contrôlés à la source, doivent être revus par le contrôle de conception du rôle, pas individuellement chaque trimestre.
Chaque ligne de revue doit répondre à quatre questions sans ouvrir un tableur supplémentaire : qui détient le droit, quel système est concerné, quelle action est rendue possible, et pourquoi ce droit existe encore. Afficher seulement un nom de groupe annuaire transfère le travail d’interprétation à l’approbateur. C’est une mauvaise économie : le coût revient, avec intérêts, pendant l’incident.
Le responsable qui certifie doit être capable de juger le besoin métier. Le propriétaire d’application confirme que le droit correspond à une capacité technique. L’équipe sécurité définit les règles de risque et vérifie les écarts. Mélanger ces responsabilités produit des approbations décoratives. Une approbation de sécurité ne remplace pas la connaissance du travail réel, pas plus qu’un responsable hiérarchique ne peut valider seul une permission de modifier les journaux d’audit.
Mesurer la qualité de campagne compte davantage que son taux de clôture : proportion de validations sans modification, droits retirés, décisions déléguées, approbations tardives, identités sans approbateur et exceptions expirées. Un taux de validation de 99,8 % sur un périmètre mouvant est un détecteur de fatigue, pas une médaille.
RBAC, ABAC et ReBAC : choisir le modèle de contrôle
Section intitulée « RBAC, ABAC et ReBAC : choisir le modèle de contrôle »Le RBAC (Role-Based Access Control) associe des permissions à des rôles, puis des rôles aux identités. Il convient aux fonctions stables et répétables : comptable fournisseur, administrateur de sauvegarde, opérateur de production. Son avantage est l’auditabilité : on sait expliquer pourquoi un droit existe. Son coût est l’explosion des rôles si chaque exception devient un rôle. Un catalogue de 4 000 rôles n’est pas une gouvernance fine, c’est un cimetière de groupes avec une police de caractères plus moderne.
L’ABAC (Attribute-Based Access Control) décide selon des attributs : département, niveau de sensibilité d’une donnée, pays de rattachement, heure, niveau de confiance du poste. Il convient aux règles contextuelles et aux grands périmètres de données. Il exige une gouvernance stricte des attributs : une donnée métier erronée devient directement une autorisation erronée. Les attributs doivent donc avoir une source d’autorité, un propriétaire, une fraîcheur mesurée et des règles de propagation connues.
Le ReBAC (Relationship-Based Access Control) décide selon des relations entre sujets et ressources : propriétaire, membre d’équipe, parent d’un dossier, délégué, lecteur partagé. Le modèle popularisé par Zanzibar de Google rend ces relations explicites et permet des vérifications cohérentes sur des graphes de ressources. Il est adapté aux plateformes collaboratives, aux espaces clients et aux structures hiérarchiques complexes. Il devient dangereux quand les relations transitives ne sont pas bornées : une délégation de délégation peut transformer une arborescence métier en tunnel de privilèges.
Le choix n’est pas idéologique. Utiliser RBAC pour les permissions métier stables, ABAC pour les contraintes de contexte et de classification, ReBAC pour les partages entre ressources est généralement le bon découpage. Empiler les trois dans chaque décision d’accès produit une politique impossible à tester. Le contrôle d’accès doit rester explicable à partir des journaux, sinon il devient une séance de spiritisme devant un moteur de règles.
Séparation des tâches et conflits de droits
Section intitulée « Séparation des tâches et conflits de droits »La SoD (Segregation of Duties), ou séparation des tâches, interdit qu’une même identité réalise seule une chaîne d’action frauduleuse ou irréversible. Créer un fournisseur et valider son paiement constitue le cas classique : la première permission prépare la fraude, la seconde la consomme. La séparation doit couvrir les droits directs, les rôles, les groupes imbriqués, les délégations et les élévations temporaires. Contrôler uniquement les rôles affichés dans l’outil IGA laisse passer les chemins indirects, qui sont précisément ceux qu’un attaquant cherchera.
Il faut modéliser les conflits sous forme de permissions atomiques, pas sous forme de noms de postes. Par exemple : fournisseur.creer, fournisseur.modifier_coordonnees_bancaires, paiement.approuver et paiement.executer. Les règles détectent alors les combinaisons interdites, quel que soit le chemin d’attribution. Une matrice de conflits doit préciser la gravité, le propriétaire du risque, la mesure compensatoire admise et la date d’expiration de l’exception.
La prévention à la demande d’accès est préférable à la détection après attribution. Une détection reste indispensable pour les droits existants, les changements de modèle et les erreurs de synchronisation. Lorsqu’une exception est nécessaire, attribuer un accès temporaire, journaliser l’approbation et déclencher une revue à échéance. Un conflit SoD permanent avec une note disant « besoin opérationnel » est une permission dangereuse emballée dans du papier administratif.
Exemple de détection de conflit SoD
Section intitulée « Exemple de détection de conflit SoD »La détection compare les permissions effectives de chaque identité à la liste des combinaisons interdites. Ces permissions doivent provenir du moteur d’autorisation réel, y compris les groupes et délégations, pas d’un export manuel optimiste.
Cette détection doit alimenter un workflow de remédiation : retrait d’un droit, accès temporaire encadré, ou exception formellement acceptée. Elle ne doit pas seulement alimenter un tableau de bord. Les tableaux de bord sont très bons pour afficher des incendies, nettement moins pour les éteindre.
Surface d’attaque, exploitation et reprise
Section intitulée « Surface d’attaque, exploitation et reprise »L’IGA expose des interfaces à haute valeur : connecteurs de synchronisation, comptes d’administration, jetons d’interface de programmation, règles de provisioning, boîtes de délégation et journaux d’audit. Compromettre un connecteur disposant du droit de créer des comptes ou d’affecter des rôles permet une persistance discrète. Une revue d’accès ne détectera pas forcément l’attaque si l’identité compromise est légitime et si la campagne est validée sans examen.
Protéger les connecteurs avec des identités dédiées, des droits minimaux, une authentification forte et des secrets stockés dans un coffre. Rotater les secrets et certificats, surveiller les créations de rôles, les affectations administratives, les changements de règles et les échecs de désactivation. Les journaux doivent inclure l’auteur, la source, la décision de politique, la permission finale et la corrélation avec la demande d’accès. Sans ces éléments, une enquête reconstruit une politique à partir de miettes, sport peu recommandé hors période de famine.
Sauvegarder la configuration des règles, la matrice SoD, les définitions de rôles, les mappings de sources et les approbations d’exception. Tester la restauration dans un environnement isolé : restaurer une base IGA sans contrôler les connecteurs peut reprovisionner des comptes supprimés. La reprise doit d’abord rétablir la capacité de bloquer les accès, puis la synchronisation, puis les demandes. La gouvernance cybersécurité apporte le cadre de responsabilité, mais ne remplace pas les contrôles techniques.
🐝 Ce qui arrive si on s’en passe
Section intitulée « 🐝 Ce qui arrive si on s’en passe »Sans gouvernance des identités ni séparation des tâches, les droits s’accumulent au fil des mutations successives, et personne ne peut plus reconstituer l’état des habilitations à une date donnée. L’analyse d’un incident devient une estimation : impossible de dire quelles ressources étaient accessibles au moment des faits, ni de borner le périmètre à notifier. Un accès utilisé par un ancien titulaire ou partagé entre plusieurs personnes n’est plus imputable, ce qui affaiblit la valeur probante des journaux. La réponse à incident perd aussi son levier le plus rapide : en l’absence de lien entre une identité et l’ensemble de ses comptes, la coupure doit être cherchée système par système. Enfin, l’absence de matrice de conflits prive les contrôles financiers de toute démonstration d’efficacité lors d’un audit ou d’une déclaration d’assurance.
🦫 Explication de la marmotte 🍫
Section intitulée « 🦫 Explication de la marmotte 🍫 »La gestion des identités et des accès sert à décider qui peut utiliser un système, voir une information ou effectuer une action. Elle commence par une source reconnue, par exemple le service qui sait qu’une personne arrive, change de poste ou quitte l’organisation. Cette information crée, modifie ou désactive les comptes liés à cette personne.
Les droits sont ensuite attribués selon trois méthodes. La première donne des droits selon une fonction, comme comptable ou administrateur. La deuxième regarde des caractéristiques, comme le service de rattachement ou la sensibilité d’un document. La troisième regarde les liens entre personnes et ressources, par exemple le fait d’être propriétaire d’un dossier ou membre d’une équipe.
À intervalles définis, les responsables doivent vérifier que les droits existent encore pour une bonne raison. Cette vérification échoue si la liste est trop longue, trop technique ou si personne ne sait ce que permet chaque droit. Il faut donc concentrer l’examen sur les actions dangereuses.
Certaines combinaisons de droits sont interdites. Une même personne ne doit pas pouvoir créer un fournisseur puis autoriser son paiement, car elle pourrait contourner un contrôle financier. Le système doit bloquer cette combinaison avant l’attribution et rechercher les conflits déjà présents.
Quand une personne part, tous ses accès doivent disparaître, y compris les comptes secondaires, les clés et les accès temporaires. Si cette étape échoue, un ancien compte peut rester utilisable. Les journaux, la surveillance, la rotation des secrets et les sauvegardes permettent de détecter les erreurs et de restaurer les règles après un incident.
À lire aussi
- DAC, MAC, RBAC, ABAC ou ReBAC : quel modèle choisirComparer les modèles de contrôle d'accès DAC, MAC, RBAC, ABAC et ReBAC selon la question à laquelle l'autorisation doit répondre, puis choisir et combiner.
- Gouverner les comptes de service et agents autonomesInventorier, attribuer et revoir les identités machines, organiser la rotation de leurs secrets et encadrer les agents logiciels autonomes.
- Auditer l'héritage des permissions et le droit effectifComment un droit descend par héritage sur NTFS, Active Directory, SharePoint et dans l'IAM cloud, où cet héritage se rompt ou se contourne, et comment auditer le droit effectif plutôt que les listes d'accès.
- Pourquoi supprimer les comptes de service partagésLe compte de service partagé est une dette organisationnelle qui détruit la traçabilité, bloque la révocation individuelle et rend la rotation du secret coûteuse.
Pages voisines
La citent
- DAC, MAC, RBAC, ABAC ou ReBAC : quel modèle choisir
- Kerberos et KDC dans Active Directory, attaques et durcissement
- Modèles Bell-LaPadula, Biba et Clark-Wilson
Mettre en œuvre les revues d’accès IGA et la SoD
Elle cite