Concepts d’utilisateurs d’urgence SAP : faut-il attribuer SAP_ALL ?

Cet article traite de la conception des autorisations au sein des concepts d’utilisateurs d’urgence SAP. Concrètement : faut-il attribuer le profil SAP_ALL, ou des rôles d’utilisateur d’urgence différenciés sont-ils la meilleure voie ?

Pourquoi les commissaires aux comptes regardent de plus près

Le sujet des utilisateurs d’urgence est arrivé dans les entreprises de taille moyenne. Les commissaires aux comptes attachent de plus en plus d’importance à une conception technique des interventions qui résiste à l’audit, surtout au regard d’une comptabilité intègre et traçable. La raison saute aux yeux : des interventions directes dans le système de production avec des autorisations étendues enfreignent la séparation des tâches entre l’informatique et le processus métier ainsi que le principe de l’attribution minimale des droits (need-to-know), même si ce n’est que pour une courte durée.

Ce qui fait partie d’un concept d’utilisateurs d’urgence

Pour Maxim Chuprunov, une gestion conforme des utilisateurs d’urgence commence par un concept documenté et appliqué. Selon lui, il comprend :

• un accès restreint aux identifiants, pas d’accès partagé (shared access),
• des conditions préalables définies à l’avance pour une intervention,
• un processus d’approbation et de notification,
• une journalisation sans lacune des interventions et
• une exploitation régulière des journaux. [1]

Jusque-là, tout le monde est d’accord. Les chemins se séparent sur la question des autorisations que reçoit l’utilisateur d’urgence.

Rôles différenciés : le souhait qui vient naturellement

Chuprunov considère comme souhaitable une restriction technique des autorisations des utilisateurs d’urgence selon différents scénarios d’intervention et groupes d’utilisateurs. Nous entendons aussi ce souhait régulièrement chez nos clients : un rôle pour la comptabilité financière, un pour la logistique, un pour la Basis, un pour les développeurs avec des droits d’affichage.

L’idée se comprend. Mais elle a un prix : à côté du concept d’autorisations proprement dit, il en naît un second, qu’il faut maintenir, contrôler et documenter, et qui peut devenir un obstacle en cas d’urgence lorsque le rôle sur mesure ne suffit justement pas.

Notre position : peu d’urgences, autorisation complète, révision complète

Nous défendons le point de vue que les interventions d’utilisateurs d’urgence doivent se limiter aux urgences réelles. Un grand nombre d’interventions indique, selon notre expérience, des faiblesses dans les processus et intégrations système sous-jacents, et celles-ci devraient être corrigées rapidement et en priorité, au lieu de rendre les utilisateurs d’urgence plus confortables.

Si le nombre d’urgences reste faible, nous ne voyons pas le besoin d’autorisations d’urgence graduées. Nous voyons plutôt le risque qu’un concept d’autorisations parallèle s’établisse par ce biais. Notre solution ISPICIO_E attribue donc tout simplement SAP_ALL.

Elle assure l’intégrité des données et la traçabilité des interventions ailleurs : par une révision obligatoire de toutes les activités dans le Security Audit Log. Immédiatement après chaque intervention, le journal individuel est attribué à un réviseur pour commentaire et décision, approuver ou rejeter. Toutes les interventions se trouvent ainsi, avec la justification (par exemple la référence à un ticket), le fichier journal et le résultat de la révision, dans une base de données qui s’exploite aisément lors de l’audit.

Conclusion

La question « SAP_ALL ou non ? » est à notre avis la mauvaise question. L’essentiel est la rareté du recours à l’utilisateur d’urgence et l’exhaustivité du contrôle de chaque intervention. Qui maîtrise les deux peut accorder l’autorisation complète en cas d’urgence, et l’auditeur obtient ce qu’il veut voir : chaque intervention, chaque justification, chaque résultat.

---

[1] Cf. Chuprunov, Maxim : Handbuch SAP-Revision. Internes Kontrollsystem und GRC. Rheinwerk, Bonn 2012, p. 242 sq. (en allemand).