Approbation des interventions d’utilisateurs d’urgence SAP : ex ante ou ex post ?

Faut-il approuver chaque intervention d’urgence à l’avance, ou une révision obligatoire après coup suffit-elle ? Les deux voies ont de bonnes raisons. Pourquoi nous avons choisi la révision après l’intervention.

Deux chronologies d’une intervention d’utilisateur d’urgence comparées. En haut, ex ante avec approbation avant l’intervention ; en bas, ex post avec intervention immédiate, journal issu du Security Audit Log et révision ensuite. Le point de contrôle est mis en évidence dans chaque cas.

La gestion des super users, les utilisateurs d’urgence dans SAP, est un sujet récurrent de l’audit des comptes annuels. Un concept d’utilisateurs d’urgence doit donc répondre à deux questions : qu’est-ce qu’une urgence, au juste ? Et qui approuve l’intervention, et quand, avant ou après ? Sur la deuxième question, il existe deux écoles.

Définir d’abord l’urgence

La première question lors de l’élaboration d’un concept d’utilisateurs d’urgence est la définition de l’urgence elle-même. Pour nous, une urgence se caractérise par deux critères :

  1. Des processus métier critiques dans le temps ne peuvent pas être exécutés. L’accent est mis sur « critiques dans le temps ». Tout ce qui peut attendre relève du processus standard avec demande de modification et transport, pas d’une intervention d’utilisateur d’urgence.
  2. Des administrateurs ou des développeurs ont besoin d’un accès direct aux tables du système de production, en contournant le système de transport.

Une fois l’urgence définie et la définition documentée, se pose la question du processus d’approbation.

Deux modèles d’approbation

Ex ante : approbation avant l’intervention

Dans la première approche, chaque intervention d’utilisateur d’urgence doit être approuvée au préalable par un approbateur, dans le respect de la séparation des tâches. Cette approche est souvent combinée à des autorisations graduées pour les utilisateurs d’urgence, et il y a de bonnes raisons à cela. Par exemple, la première intervention reçoit un rôle d’utilisateur d’urgence dans lequel l’objet d’autorisation S_DEVELOP ne contient que des droits d’affichage, afin de cerner l’erreur et, si possible, de la corriger déjà.

L’argument : un développeur pourrait contourner tous les mécanismes de contrôle du système avec « Debugging & Replace ». Un journal ne sert alors pas à grand-chose si le dommage est survenu depuis longtemps au moment de la révision.

Ex post : accès immédiat, révision obligatoire

Nous défendons l’autre approche et l’avons mise en œuvre dans notre suite utilisateur d’urgence ISPICIO_E. Comme décrit au début, nous plaidons pour une pratique très restrictive : des interventions d’utilisateur d’urgence uniquement en cas d’urgence réelle. Mais lorsque des processus métier critiques dans le temps mettent en péril les objectifs de l’entreprise, il ne faut pas perdre de temps à obtenir d’abord une approbation.

C’est pourquoi, dans ce modèle, un collaborateur habilité reçoit immédiatement un accès étendu au système de production (SAP_ALL). ISPICIO_E crée pour chaque intervention un identifiant utilisateur à usage unique dans le système et le relie au Security Audit Log. Une fois l’intervention terminée, l’identifiant est supprimé et les entrées SAL correspondantes sont extraites.

Comment l’intégrité reste assurée

Que l’accès soit immédiat et étendu ne signifie pas qu’il est incontrôlé. Le contrôle se situe ailleurs :

  • En fonctionnement normal, il n’existe aucun utilisateur d’urgence dans le système de production. Il n’y a pas d’identifiant qui pourrait être utilisé à l’insu de tous.
  • Chaque intervention est contrôlée à 100 pour cent. Après chaque intervention, l’extrait concerné du Security Audit Log est automatiquement soumis à un réviseur, par notification e-mail et dans le respect de la séparation des tâches. Le réviseur doit passer en revue les entrées SAL et clore le ticket : approuver ou rejeter.
  • Toute la chaîne est exploitable. Demande, justification, journal, réviseur, horodatage et résultat se trouvent dans une base de données consultable et sur un tableau de bord : qui a demandé ? Quelle était la justification ? Qu’a-t-on fait ? Qui a contrôlé, quand, avec quel résultat ?

Ce qu’en retire l’audit

Ce dispositif est particulièrement bien accueilli par les auditeurs, internes comme externes. Ils peuvent prélever des échantillons ciblés et, pour les interventions rejetées, demander quelles mesures correctives ont été prises. Pour nous, la réponse à « ex ante ou ex post ? » est donc : ex post, mais pour chaque intervention et sans exception.

Pour en savoir plus sur le modèle et sa mise en œuvre : ISPICIO_E : accès d’urgence aux systèmes SAP.

Autres articles

Prochaine étape

Quatre semaines d’essai, dans votre réseau, avec vos systèmes : des accès d’urgence maîtrisés, en local et prêts pour l’audit.

Demander une clé de licence pour quatre semaines

Votre demande devient chez nous un ticket numéroté. Nous vous répondons personnellement.