Quand les anciens rôles ERP créent de nouveaux risques

Un modèle de rôles ERP propre peut malgré tout accumuler une dette d’autorisation

Un modèle d’autorisation ERP peut être correct au moment du déploiement et devenir dangereux à mesure que l’entreprise évolue. Les accès ERP déterminent ce que les personnes et les agents d’IA peuvent voir et les actions qu’ils peuvent effectuer ; les autorisations doivent donc rester alignées sur l’évolution des responsabilités. Les DSI doivent maintenir dans le temps l’alignement entre les droits de décision métier, le modèle d’autorisation et les contrôles appliqués par l’ERP. Les écarts entre ces couches transforment des accès auparavant appropriés en risques actuels.

Le maintien de cet alignement repose sur trois mécanismes aux rôles distincts. L’authentification vérifie l’identité, la gestion des identités gouverne les identités numériques tout au long de leur cycle de vie, et l’autorisation détermine ce qu’une identité vérifiée peut faire. Ensemble, ils appliquent les responsabilités métier, les workflows et les droits de décision tout en protégeant les données, en soutenant la conformité réglementaire et en empêchant les actions inappropriées ou conflictuelles. À mesure que l’organisation évolue, des rôles obsolètes, des autorisations excessives et des exceptions mal documentées s’accumulent sous forme de dette d’autorisation.

La dette d’autorisation change le critère d’évaluation d’un programme de contrôle d’accès, car le déploiement n’établit que l’état initial. Srinivas Chippagiri, membre senior du personnel technique chez Tableau, souligne la manière dont l’organisation gère le changement inévitable : « La mesure d’un bon programme, ce n’est pas son niveau de propreté au go-live ; c’est la lenteur avec laquelle il se dégrade et la rapidité avec laquelle il s’auto-corrige. Concevez pour la dérive, car la dérive est garantie. » Répondre à cette exigence suppose de définir l’autorité métier correcte, puis de vérifier en continu les deux endroits où l’accès réel peut s’en écarter.

Commencer par les droits de décision métier

L’autorité correcte commence par les décisions et les responsabilités que les personnes ont dans l’entreprise. Les responsabilités de poste, les étapes de processus et les droits de décision doivent être mappés aux autorisations en fonction du mode de fonctionnement de l’organisation. Mudita Khurana, ingénieure sécurité staff chez Airbnb, donne un exemple concret : « Par exemple, un employé spécialiste des comptes fournisseurs peut être autorisé à créer des fiches fournisseurs, mais uniquement pour l’entité juridique américaine. Bien que cela soit appliqué via un contrôle de sécurité, c’est en réalité le modèle de gouvernance sous-jacent qui détermine quel employé, avec quel rôle, peut accéder à quoi. »

La distinction faite par Khurana fixe l’ordre du travail, car un contrôle ERP met en œuvre une décision qui prend sa source dans le métier. Le métier détermine si un spécialiste des comptes fournisseurs a l’autorité de créer des fournisseurs et si cette autorité s’arrête à l’entité juridique américaine ; le contrôle de sécurité applique ensuite ces conditions. L’autorisation est une discipline de gouvernance qui permet d’exprimer qui détient quelle autorité et dans quelles conditions. Une approche proactive donne à l’organisation une base stable pour contrôler les accès à mesure que les responsabilités évoluent.

Cette base de gouvernance peut échouer avant même qu’un rôle soit configuré, lorsque le métier et l’IT ont des hypothèses différentes sur les identités qui doivent exécuter quelles tâches. Arjun Jaggi, chercheur en IA appliquée et dirigeant du secteur, explique que l’échec « commence dès le départ, lorsqu’on traite cela comme une tâche de configuration technique relevant de l’IT plutôt que comme une décision de gouvernance relevant du métier ». L’IT peut traduire les exigences métier en contrôles ERP, tandis que le métier doit déterminer l’autorité que ces exigences représentent. Une propriété claire donne aux équipes techniques un modèle de décision qu’elles peuvent encoder.

Chippagiri explicite davantage le problème de propriété : « Le contrôle d’accès ERP échoue lorsque l’IT en est propriétaire, parce que l’IT connaît le système mais pas le risque. La conception des accès est la codification de qui est jugé digne de confiance pour faire quoi, et c’est une question de gouvernance métier. Si vous traitez cela comme une configuration technique, vous obtenez des rôles qui reflètent les menus du logiciel au lieu de la structure de contrôle de l’entreprise. » Un rôle organisé autour des fonctions ERP disponibles peut être techniquement cohérent tout en ne représentant pas la manière dont la responsabilité et le risque sont répartis au sein de l’entreprise. La propriété métier relie ces rôles techniques aux décisions qu’ils sont censés contrôler.

Le contrôle d’accès basé sur les rôles, ou RBAC, offre un moyen courant d’encoder ce lien. Le RBAC regroupe les autorisations en rôles correspondant à de véritables fonctions métier, ce qui permet aux managers de raisonner sur les accès dans des termes qu’ils comprennent. Ces rôles doivent comporter suffisamment de limites de périmètre pour éviter une autorité excessive, tout en restant assez simples pour que les managers métier puissent les comprendre et les maintenir. Une complexité excessive rend le catalogue de rôles difficile à gouverner, même lorsque chaque autorisation sous-jacente avait autrefois une justification technique.

Certaines responsabilités dépassent les limites d’un rôle standard ; des contrôles contextuels et des exceptions peuvent donc prendre en charge des missions inhabituelles, des affectations temporaires, des localisations ou des montants de transaction sans créer un grand nombre de rôles ponctuels. Cette flexibilité ajoute une charge de gouvernance, car le RBAC peut être mal utilisé, tandis qu’une personnalisation excessive et des exceptions non gérées peuvent produire une prolifération des autorisations. Les pouvoirs privilégiés, comme modifier des configurations, administrer des utilisateurs ou contourner des contrôles, ont des conséquences plus importantes, car ils peuvent altérer les contrôles qui gouvernent d’autres identités. Ces pouvoirs nécessitent donc des approbations, une surveillance et des limites de durée plus strictes.

Une fois ces limites établies, la conception des rôles peut suivre une séquence claire : définir le poste, identifier les contraintes de séparation des tâches, puis mapper les autorisations requises. La séparation des tâches, ou SoD, empêche une identité d’accumuler une autorité incompatible au sein d’un processus métier. Chippagiri résume ainsi le test de conception : « Construisez les rôles à partir des fonctions métier, pas des codes de transaction. Définissez le poste, définissez les contraintes de séparation des tâches qu’il doit respecter, puis mappez les autorisations. Si vous ne pouvez pas expliquer un rôle en une phrase sans citer un code de transaction, c’est qu’il est mal conçu. » Un rôle conçu selon cette séquence exprime une décision métier qui pourra ensuite être vérifiée à mesure que l’organisation évolue.

Premier écart : le métier évolue plus vite que le modèle d’autorisation

Cette vérification ultérieure est importante, car même un modèle de rôles solide commence à vieillir à mesure que l’organisation qui l’entoure évolue. Des employés arrivent, changent de poste et partent ; des prestataires entrent et sortent ; les processus métier sont révisés ; et les identités non humaines évoluent au fil de leur cycle de vie. Les agents d’IA peuvent échouer, changer ou être remplacés ; leur autorité doit donc elle aussi être révisée lorsque leur finalité ou leur statut change. Un accès qui subsiste après l’une de ces transitions transforme une décision initialement correcte en dérive des droits.

Jaggi décrit la rapidité avec laquelle ce décalage peut apparaître dans une mise en œuvre classique : « Quelqu’un dans l’IT reçoit une liste de rôles à configurer, construit un modèle basé sur les rôles qui correspond raisonnablement bien à l’organigramme à cet instant, puis le livre. Ce modèle est correct le premier jour. Il devient faux en environ 18 mois. » La période « en environ 18 mois » est l’estimation de Jaggi, et sa portée opérationnelle réside dans la transition entre des états organisationnels. Un modèle représentant un état donné a besoin d’une maintenance active pour représenter l’état suivant.

Les changements de poste des employés montrent comment une telle transition crée de la dette. Une personne peut acquérir des autorisations pour un nouveau poste tout en conservant les accès de son rôle précédent, accumulant progressivement une autorité au-delà de ses responsabilités actuelles. La même accumulation peut aussi compromettre la SoD jusqu’à permettre à une seule personne d’initier, d’approuver et d’exécuter des parties incompatibles d’une transaction. Chaque droit peut avoir eu une origine légitime, même si leur combinaison ultérieure viole le modèle de gouvernance actuel de l’entreprise.

Parce que les transitions créent ce décalage, elles deviennent des points de contrôle importants. Yulia Plugatyreva, auditrice IT senior chez la société de services financiers Chime, identifie plusieurs états concrets à détecter : un compte ERP peut rester actif après que Workday a enregistré le départ de la personne, ou un employé peut changer de poste tout en conservant les accès de son ancien rôle. Une autorisation directe peut également apparaître en dehors d’un rôle approuvé, et un compte privilégié temporaire peut rester actif au-delà de la période prévue. La délégation de workflow crée une autre voie lorsqu’elle permet à une identité d’approuver sa propre activité.

Ces cas expliquent pourquoi les rôles approuvés et les certifications planifiées ne fournissent qu’une partie du contrôle. Les autorisations directes et les accès temporaires peuvent modifier l’autorité effective entre deux cycles de revue, tandis qu’un événement d’emploi dans Workday peut laisser le compte ERP correspondant actif jusqu’à ce qu’un autre processus détecte et résolve le décalage. La délégation de workflow peut de la même manière modifier un résultat de contrôle tout en laissant inchangé le catalogue de rôles sous-jacent. La surveillance des transitions doit observer l’accès effectif à mesure qu’il évolue.

La surveillance de l’accès effectif modifie aussi ce qu’une organisation doit mesurer. Plugatyreva déclare : « Un programme mature d’accès ERP ne se mesure pas au nombre de politiques publiées ou de revues d’accès réalisées. Il se mesure à la rapidité avec laquelle il détecte qu’un accès approprié est devenu inapproprié et à la capacité de l’organisation à prouver qu’elle a agi. » Les revues réalisées établissent qu’un processus de gouvernance a bien eu lieu, tandis que la vitesse de détection établit à quelle rapidité ce processus identifie un nouvel état risqué. La seconde mesure compte particulièrement lorsqu’une transition crée une exposition immédiate.

La revue périodique des accès reste utile dans ce modèle opérationnel, mais des transitions peuvent survenir entre deux revues. Une fin de contrat, un changement de poste, une attribution directe, une finalité temporaire expirée ou une nouvelle délégation peuvent modifier immédiatement le risque ; attendre une certification ultérieure permet donc à la dette d’autorisation de persister pendant cet intervalle. La gouvernance continue couvre cet intervalle en surveillant les changements parallèlement à l’inspection périodique de l’état d’accès qui en résulte. La revue et la détection des transitions opèrent donc à des échelles de temps différentes.

Le premier écart se situe entre l’évolution des droits de décision métier et le modèle d’autorisation conçu pour les exprimer. Des rôles obsolètes, des autorisations excessives et des exceptions mal documentées s’accumulent lorsque le modèle prend du retard sur le métier. Combler cet écart permet de maintenir à jour l’autorité voulue. Les DSI sont alors confrontés à une seconde question : l’ERP se comporte-t-il réellement conformément à ce modèle à jour ?

Deuxième écart : l’ERP peut ne pas appliquer le modèle sur le papier

Une conception d’autorisation à jour établit l’autorité voulue, tandis qu’un contrôle effectif dépend de son application par l’ERP. Juan Perez-Etchegoyen, CTO et expert en sécurité ERP SAP et Oracle chez Onapsis, énonce directement le problème : « un DSI peut disposer d’une conception d’autorisation impeccable et d’un système qui ne la respecte pas. » Onapsis vend des technologies et des services de sécurité ERP ; l’entreprise bénéficie donc commercialement lorsque les organisations investissent dans l’identification et la correction des faiblesses de sécurité ERP. Cet intérêt commercial rend une attribution claire importante lorsqu’on évalue l’analyse de Perez-Etchegoyen sur le problème d’application.

Perez-Etchegoyen divise ce problème en deux enjeux de gouvernance : « La gouvernance du contrôle d’accès a deux moitiés. La première est le modèle, y compris le catalogue de rôles, le jeu de règles SoD [séparation des tâches] et sa cadence de revue, pour ne citer que quelques éléments, et la plupart des organisations ne gouvernent que cette moitié. La seconde consiste à savoir si le modèle est réellement appliqué par le système sous-jacent : le code, la configuration, les interfaces et le niveau de patch. » Les revues des rôles et de la SoD établissent ce que l’organisation entend faire appliquer par le système. La vérification du code, de la configuration, des interfaces et des niveaux de patch établit la manière dont le système met en œuvre cette intention.

Ces éléments d’implémentation créent une autre source de dérive, car chacun peut modifier le fonctionnement réel des restrictions. Une équipe de gouvernance peut maintenir son catalogue de rôles à jour, conserver un jeu de règles SoD approprié et exécuter sa cadence de revue, tandis que le système sous-jacent autorise autre chose. Des changements limités au catalogue de rôles ne peuvent pas corriger un écart d’application dans le code, la configuration, une interface ou l’état des patchs. Le deuxième écart nécessite des preuves provenant du système lui-même.

Perez-Etchegoyen décrit le problème de mesure qui en résulte : « Le modèle d’accès sur le papier et le modèle d’accès réellement appliqué par le système sont deux choses différentes, et presque personne ne mesure l’écart entre les deux. » Mesurer les autorisations voulues peut établir la conception gouvernée, tandis qu’un DSI a aussi besoin de preuves que l’implémentation continue de produire les restrictions exigées par cette conception. La vérification de l’application relie la gouvernance des autorisations au comportement réel de l’ERP.

Parce que les deux écarts apparaissent à des endroits différents, ils exigent des actions correctives différentes. La dérive entre le métier et le modèle demande si les rôles, exceptions et droits actuels représentent encore les responsabilités et droits de décision présents. La dérive entre le modèle et l’application système demande si le code, la configuration, les interfaces et l’état des patchs de l’ERP imposent réellement ces règles. Le RBAC peut traiter le premier problème lorsque ses rôles capturent fidèlement le métier ; les tests d’application traitent le second.

Ensemble, ces écarts expliquent pourquoi la conception initiale des rôles et les revues périodiques des accès sont des composants d’un système de contrôle plus large. Les changements d’identités et de responsabilités peuvent créer une autorité risquée entre deux revues, tandis que des changements d’implémentation peuvent dissocier l’accès effectif du modèle en cours de revue. La gouvernance continue doit observer ces deux types de changement. Elle doit ensuite transformer chaque écart détecté en travail correctif avec un responsable clairement désigné.

La gouvernance continue signifie détecter, corriger et prouver la réponse

Une fois les deux écarts traités comme des conditions évolutives, l’objectif opérationnel devient de maintenir l’autorisation sous contrôle à mesure que les rôles, les processus, les technologies et les structures organisationnelles évoluent. La détection doit identifier le moment où un droit auparavant légitime devient risqué ou lorsque l’ERP cesse d’appliquer une restriction voulue. La correction doit ensuite suivre en fonction de la gravité de l’événement. La preuve complète la réponse en montrant ce que l’organisation a fait.

Plugatyreva relie ces étapes à une responsabilité explicite : « Chaque risque doit avoir un propriétaire défini, un délai de réponse et une preuve de résolution. Les événements à haut risque, comme un utilisateur parti qui conserve un accès au système financier ou une nouvelle combinaison toxique de tâches, doivent déclencher des alertes immédiates. Les exceptions à plus faible risque peuvent être examinées via une file quotidienne ou une certification trimestrielle. » La file quotidienne et la certification trimestrielle sont les cadences qu’elle recommande pour les exceptions à plus faible risque. La vitesse de réponse appropriée dépend du niveau de risque.

Cette hiérarchisation du risque transforme la surveillance des transitions en processus opérationnel. Un compte ERP toujours actif après un départ ou une nouvelle combinaison toxique de tâches exige une attention immédiate, car l’autorité effective est déjà inappropriée. Les exceptions à plus faible risque peuvent entrer dans des processus de revue gérés avec des délais de réponse différents. L’attribution d’un responsable et la conservation de preuves bouclent la boucle en montrant que la détection a conduit à une décision et à une résolution.

La preuve est particulièrement importante lorsque l’organisation doit ensuite reconstituer qui détenait l’autorité à un moment donné. Thiago Vieira, avocat en cybersécurité, expert en criminalistique numérique et PDG de Cybertech Acceleration, formule l’exigence ainsi : « Le test de gouvernance ne consiste pas à savoir si nous pouvons empêcher la mauvaise personne de faire cela ; il s’agit de savoir si nous pouvons prouver, 12 mois plus tard et selon un standard [qu’]un juge acceptera, qui l’a fait exactement et sous quelle autorité. » La période de 12 mois est l’horizon probatoire illustratif de Vieira, qui souligne la nécessité de conserver un historique défendable des actions et de l’autorité. Cybertech Acceleration opère dans la cybersécurité, ce qui donne à Vieira et à l’entreprise un intérêt commercial à ce que les organisations investissent dans des contrôles de cybersécurité, de criminalistique et de preuve.

L’expérience de Vieira illustre la conséquence de la perte de cet historique : « J‘ai vu des entreprises perdre des affaires de fraude pourtant gagnables parce que les journaux de modification n’existaient pas, [ce qui a entraîné] un manque de preuves. » Une enquête ultérieure dépend de registres établissant qui détenait l’autorité, ce qui a changé et ce qui s’est passé. Ces registres relient l’état de l’autorisation au moment d’un événement aux personnes ou systèmes qui ont agi en vertu de celle-ci. La conservation des preuves fait donc partie intégrante de l’architecture d’autorisation elle-même.

Cette exigence probatoire renforce aussi l’intérêt des contrôles de cycle de vie, car des transitions claires réduisent l’ambiguïté sur l’autorité. Vieira recommande de révoquer les autorisations précédentes d’un employé avant d’en accorder de nouvelles lors d’un changement de rôle, ce qui traite directement l’accumulation d’anciennes et de nouvelles autorités. Chaque identité non salariée devrait avoir une date de fin obligatoire, tandis que les accès privilégiés devraient être limités dans le temps par défaut et leurs sessions enregistrées. Ces contrôles limitent les états de transition que Plugatyreva identifie comme des points fréquents où un accès approprié devient risqué.

Une fois que les contrôles de transition couvrent les employés et les travailleurs externes, la même discipline de cycle de vie doit aussi couvrir explicitement les identités non humaines. Vieira cite les identités d’agents d’IA comme une catégorie qui peut être négligée ; leurs accès doivent donc faire l’objet d’un traitement de cycle de vie au même titre que ceux des employés, des prestataires et des autres identités. Un agent d’IA qui change ou est remplacé crée un événement d’autorisation, car son autorité antérieure doit être révisée. Un dossier RH humain ne peut pas déclencher cette transition d’identité machine.

Le processus qui en résulte fait de la gouvernance continue un système de réponse à plusieurs vitesses. Les transitions à haut risque, comme l’accès d’un utilisateur parti ou une nouvelle combinaison toxique de tâches, déclenchent des alertes immédiates, tandis que les cas à plus faible risque peuvent passer par la file quotidienne ou la certification trimestrielle de Plugatyreva. Les responsables et les attentes de réponse établissent la responsabilité de la correction, et les enregistrements de changement ainsi que les preuves de résolution établissent ce qui a suivi. Ensemble, ces registres conservent à la fois la correction de l’état risqué et l’autorité au titre de laquelle les actions pertinentes ont eu lieu.

Étendre la gouvernance du cycle de vie aux agents d’IA

Le besoin de déclencheurs liés aux identités machine devient plus important à mesure que les agents d’IA élargissent la population disposant d’un accès ERP au-delà des employés et des prestataires. Ces agents peuvent échouer, changer ou être remplacés, et l’avertissement de Vieira selon lequel les identités non humaines sont souvent négligées rend nécessaires des contrôles explicites de cycle de vie. L’autorité métier reste la règle de gouvernance : les autorisations de chaque agent doivent correspondre à ce que cette identité peut actuellement faire au regard des responsabilités et conditions qui lui sont assignées. Les changements de finalité ou de statut de l’agent deviennent des événements de gouvernance.

Ces événements obligent les organisations à gérer un agent d’IA comme une identité dont le cycle de vie évolue. Lorsqu’un agent change ou est remplacé, son autorité existante doit être révisée, et tout accès risqué qui en résulte doit être détecté et corrigé. L’ERP doit aussi continuer à appliquer l’autorisation voulue, tandis que les preuves conservées doivent montrer comment l’organisation a réagi. L’application de ces contrôles aux identités humaines et non humaines permet de garder une unité de gouvernance cohérente, même lorsque la population d’identités s’élargit.

Points clés à retenir pour les dirigeants

• Ancrer l’accès ERP dans les droits de décision métier : Les responsables métier définissent qui a l’autorité d’effectuer des actions spécifiques et dans quelles conditions, tandis que l’IT traduit ces décisions en rôles et en contrôles. Construisez les rôles autour des fonctions métier et des contraintes de séparation des tâches.
• Surveiller la dérive entre le métier et l’autorisation : Les changements de poste, les départs, les attributions directes, les accès temporaires et la délégation de workflow peuvent rendre risquées des autorisations auparavant appropriées. Suivez ces transitions en continu et utilisez des certifications périodiques pour examiner l’état d’accès qui en résulte.
• Vérifier l’application par l’ERP : Un catalogue de rôles à jour ne garantit pas que l’ERP l’applique correctement. Les DSI ont besoin de preuves que le code, la configuration, les interfaces et les niveaux de patch continuent de mettre en œuvre le modèle d’autorisation voulu.
• Relier la détection à la correction et à la preuve : Attribuez à chaque risque d’accès un responsable, un délai de réponse et un enregistrement de résolution. Faites immédiatement remonter les événements à haut risque, tout en orientant les exceptions à plus faible risque vers des cycles de revue appropriés et en conservant les preuves de l’autorité et de la remédiation.
• Appliquer la gouvernance du cycle de vie aux agents d’IA : Les agents d’IA ont besoin de cycles de vie d’identité explicites, car leur finalité, leur configuration et leur statut peuvent changer. Réévaluez les autorisations lorsque les agents changent ou sont remplacés, vérifiez l’application et conservez les preuves des décisions d’accès qui en résultent.