Dans le monde des systèmes ERP tels que SAP, la question des droits des utilisateurs est cruciale, non seulement pour la sécurité, mais aussi pour l’efficacité de l’ensemble de l’organisation. Et pourtant, dans la pratique, on rencontre souvent des situations où les utilisateurs ont accès à un ensemble de fonctions beaucoup plus large que ce dont ils ont réellement besoin. Parfois « au cas où », parfois « parce que c’était plus rapide », et parfois aussi parce que personne n’a pris la peine de vérifier.

En revanche, il existe un principe qui devrait être à la base de toute politique de gestion des accès :Le principe du moindre privilège (LPP). En résumé, un utilisateur doit avoir exactement le nombre de privilèges dont il a besoin pour accomplir ses tâches. Ni moins, ni plus.

Une enquête menée auprès de 225 organisations a révélé que 85 % des autorisations n’avaient pas été utilisées au cours des 90 derniers jours, et qu’un utilisateur sur trois avait accès à des systèmes qu’il n’avait pas du tout utilisés. Ces données ne laissent aucune illusion : l’accès redondant est un problème réel et répandu. La majorité des utilisateurs disposent d’autorisations beaucoup trop larges, ce qui non seulement augmente la surface d’attaque, mais pose également un risque d’audit.

Pourquoi est-ce vraiment important ?

Le principe de la LPP n’est pas seulement une question de bon sens – c’est l’un des piliers de la sécurité de l’information et de la conformité réglementaire. Des pouvoirs trop étendus peuvent en résulter :

• la fraude ou la manipulation de données,
• les erreurs accidentelles qui perturbent les processus ou provoquent des pertes de données,
• la violation du principe de séparation des fonctions (SdF),
• le non-respect de réglementations telles que RODO ou SOX,
• des audits plus difficiles et des possibilités accrues de cyber-attaques.

Des histoires vécues, ou ce qu’il en est dans la pratique.

Examinons quelques exemples de non-application du principe du moindre accès nécessaire :

Exemple 1 : Commis comptable ayant un accès complet au cycle de facturation

La personne du service financier avait accès à toutes les transactions du cycle de facturation : de la saisie des factures entrantes (MIRO) à la comptabilisation des documents (FB60) et à l’approbation des paiements (F110).

Risque : L’employé pourrait exécuter lui-même l’ensemble du processus – de la création du document à l’exécution du transfert. Un tel accès viole le principe de la séparation des tâches et rend beaucoup plus difficile la détermination ultérieure de la responsabilité de chacun.

Solution : restreindre l’accès à un rôle – par exemple, uniquement MIRO ou uniquement FB60 – et confier l’approbation des paiements à un autre utilisateur. Il est utile de mettre en place un flux de travail et de définir clairement les responsables de chaque étape du processus.

Exemple 2 : Employé du service des achats ayant accès aux conditions de vente

Le responsable des achats avait accès non seulement aux bons de commande (ME21N, ME22N), mais aussi aux conditions de prix de vente (VK11). Le problème est qu’il n’a pas besoin de ces données et que leur édition peut avoir des conséquences stratégiques.

Risques : Changement non autorisé de la politique de tarification – accidentel ou délibéré.

Solution : séparer clairement les rôles d’achat et de vente et limiter l’accès aux données aux seules unités concernées.

Exemple 3 : Employé après un changement d’emploi

Après être passé de l’entrepôt au service de contrôle de gestion, l’employé a conservé ses anciens droits et en a reçu de nouveaux. Le résultat ? Un accès simultané aux documents de l’entrepôt et aux données relatives aux coûts.

Risques : Accès redondant à des processus ne relevant pas des responsabilités actuelles, conflits potentiels en matière de défense nationale.

Solution : Tout changement de poste doit donner lieu à une révision complète des autorisations – non seulement en ajoutant de nouveaux rôles, mais aussi en supprimant ceux qui sont inutiles.

Ces exemples montrent à quel point il est facile, dans la pratique, de donner trop d’autorité – souvent en raison de la précipitation, de l’absence d’examen ou de combinaisons de rôles irréfléchies. Chacun des cas décrits montre clairement que même des omissions apparemment mineures peuvent entraîner des risques graves qui peuvent être facilement éliminés en appliquant le principe de la LPP.

Comment agir selon le principe LPP ?

L’application du principe de l’accès le moins nécessaire nécessite non seulement une prise de conscience des risques, mais aussi des mesures organisationnelles et techniques concrètes – de préférence mises en œuvre de manière systématique et dans une optique de sécurité à long terme. Voici quelques suggestions :

• Créer des rôles professionnels adaptés aux responsabilités réelles – pas de transactions inutiles.
• Établir des champs organisationnels et limiter la portée des données (par exemple, à une entreprise ou à un entrepôt spécifique).
• Utilisez des processus d’approbation et d’examen des droits réfléchis, en particulier lorsque vous changez de rôle ou de poste.
• Vérifier les conflits de SoD avant d’accorder l’accès.
• Reconfirmer les droits régulièrement, par exemple tous les 6 ou 12 mois.
• S’appuyer sur des outils SAP tels que GRC Access Control, SUIM, ST03N ou les journaux de transactions.

Et si vous voulez vraiment régler la question de l’accès, il vaut la peine d’opter pour des solutions dédiées telles que smartGRC (https://smartgrc.eu/). Celles-ci vous permettent, entre autres, de

• procéder à des examens périodiques des droits,
• mettre en œuvre un flux de travail pour l’octroi et l’approbation de l’accès,
• gérer la base de risques de la SdD, ce qui facilite grandement le contrôle et améliore la sécurité du système.

LPP et expérience utilisateur

Un mythe courant consiste à croire que limiter l’autorité rend les gens moins à l’aise. En fait, c’est exactement le contraire qui est vrai.

Des rôles bien conçus, en adéquation avec les responsabilités et débarrassés des opérations redondantes, font les utilisateurs :

• trouver plus rapidement les fonctions dont ils ont besoin,
• ne sont pas submergés par des options inutiles dans l’interface,
• sont moins susceptibles de commettre des erreurs en cliquant accidentellement sur la « mauvaise chose ».

Le principe du moindre accès requis améliore donc non seulement la sécurité, mais aussi la convivialité du système SAP. Il s’agit d’une interface plus propre et plus claire, et donc d’une meilleure expérience pour l’utilisateur final.

LPP et réglementations et normes de sécurité

Il convient également de rappeler que le principe de l’accès le moins nécessaire n’est pas seulement une bonne pratique – c’est l’une des exigences formelles de nombreuses normes et réglementations internationales en matière de sécurité de l’information et de protection des données.

Voici quelques exemples :

• ISO/IEC 27001 – exige que l’accès aux ressources soit contrôlé en fonction des besoins de l’entreprise.
• NIST SP 800-53 – identifie le principe du moindre privilège comme le mécanisme principal de protection des systèmes d’information.
• RODO/GDPR – impose l’obligation de limiter l’accès aux données à caractère personnel aux seules personnes qui en ont réellement besoin (principe de minimisation).
• SOX (Sarbanes-Oxley Act) – exige des contrôles d’accès dans le contexte de l’intégrité des états financiers.

Le respect du principe LPP contribue donc non seulement à minimiser les risques opérationnels, mais aussi à maintenir la conformité avec les réglementations et les normes applicables, ce qui peut s’avérer crucial lors des audits et des inspections externes.

Quels sont les avantages de l’utilisation de la LPP ?

La mise en œuvre du principe de l’accès le moins requis n’est pas seulement une question de conformité et de sécurité. Il s’agit également d’une série d’avantages tangibles :

• Moins de problèmes lors des audits – grâce à un meilleur contrôle de l’accès.
• Des contrôles plus rapides et plus clairs – des rôles structurés signifient moins d’exceptions à traduire.
• Réduction des coûts de gestion des accès – moins de rôles à gérer, moins de demandes auprès des services informatiques.
• Une plus grande transparence de l’obligation de rendre des comptes – il est clair qui est responsable de quoi.
• Moins d’erreurs de la part des utilisateurs – parce qu’ils n’ont accès qu’à ce dont ils ont réellement besoin.
• « Un système SAP plus propre – sans rôles surchargés et sans droits historiques.

Enfin, le bon sens comme norme

Le principe de l’accès le moins nécessaire n’est pas une précaution exagérée, mais une approche professionnelle de la sécurité chez SAP. Il protège non seulement les données et les processus, mais aussi la réputation de l’entreprise.

Il convient donc de se poser la question suivante : cet accès est-il vraiment nécessaire ? Si ce n’est pas le cas, c’est précisément le moment idéal pour le limiter.

Sources :

1. Cloud Security Alliance. (2024). Maîtriser le moindre privilège : réduire les accès inutilisés sans couper les coins. Extrait de https://cloudsecurityalliance.org/blog/2024/05/30/mastering-least-privilege-cutting-unused-access
2. (n.d.). Qu’est-ce que le moindre privilège ? Téléchargé sur https://www.cyberark.com/what-is/least-privilege/
3. Edwards, M. (2025). Annexe A.5.3 : Séparation des tâches. En ligne. Extrait de https://www.isms.online/iso-27001/annex-a/5-3-segregation-of-duties-2022/
4. Institut national des normes et de la technologie (NIST). (n.d.). Least privilege. Téléchargé à partir de https://csrc.nist.gov/glossary/term/least_privilege
5. (2024). Sécuriser SAP avec une gouvernance d’accès efficace. Extrait de https://www.safepaas.com/articles/secure-sap-with-effective-access-governance/
6. (2025). Certification d’accès : un guide ultime. Zluri. Tiré de https://www.zluri.com/blog/access-certification
7. (2024). Page officielle du produit smartGRC. Téléchargé à partir de https://smartgrc.eu/