Les rôles Firefighter occupent une position inconfortable dans la sécurité SAP. Ils existent précisément parce que les autorisations normales ne suffisent pas dans certaines situations : incident de production à 2h du matin, clôture financière avec une transaction bloquée, événement métier rare que personne n'avait anticipé. À ces moments-là, quelqu'un doit disposer rapidement d'accès élevés. En même temps, les accès Firefighter accordent exactement le type de privilèges larges que la SoD et le principe du moindre privilège cherchent à éviter.

Un processus Firefighter bien conçu résout cette tension. Un processus mal conçu devient un contournement permanent de vos contrôles de sécurité, et c'est exactement le constat que les auditeurs externes mettront en avant dans leur rapport.

Cet article détaille comment concevoir des rôles Firefighter qui résistent à l'audit, comment les opérer en pratique, et les erreurs les plus fréquentes à éviter.

Ce qu'est réellement un accès Firefighter

SAP Emergency Access Management (EAM), souvent appelé « Firefighter », est un module de SAP GRC Access Control qui permet à un utilisateur d'assumer temporairement un rôle à haut privilège pré-défini, sur une fenêtre de temps bornée. Le flux typique est :

  1. Un utilisateur a besoin d'accès d'urgence au-delà de son rôle habituel.
  2. Il demande (ou s'est vu pré-attribuer) un ID Firefighter.
  3. Il se connecte avec l'ID Firefighter, qui porte les autorisations élevées.
  4. Toute l'activité durant la session Firefighter est journalisée.
  5. Après la session, un reviewer (typiquement l'owner du Firefighter ou un reviewer indépendant) examine le log, l'approuve ou l'escalade.

Firefighter n'est pas un type de rôle SAP en soi. C'est un processus de gouvernance autour d'accès temporairement élevés, avec journalisation et revue intégrées.

Cadrage des rôles Firefighter : étroit plutôt que large

La décision de conception la plus importante est la largeur du périmètre de chaque rôle Firefighter. L'instinct pousse souvent à créer un ou deux rôles Firefighter tout-puissants couvrant toutes les urgences. C'est le mauvais instinct, pour deux raisons : cela affaiblit la piste d'audit (on ne peut pas dire ce que la personne était censée faire), et cela amplifie le risque (un seul ID Firefighter compromis donne à un attaquant un accès quasi total).

Meilleure pratique : cadrer les rôles Firefighter par domaine fonctionnel et type d'incident. Patrons de cadrage courants :

  • FI Production Support Firefighter : accès nécessaires pour résoudre des erreurs de comptabilisation, des documents bloqués, des problèmes de fin de période.
  • MM Emergency Procurement Firefighter : accès pour créer en urgence un fournisseur ou une commande hors workflow normal.
  • HR Incident Firefighter : accès pour corriger des anomalies de données maître employé.
  • Basis / System Administration Firefighter : accès pour incidents techniques, problèmes de transport, arrêts système.
  • Security Incident Firefighter : accès spécifique à la réponse aux incidents de sécurité, en général porté par l'équipe sécurité.

Chaque rôle Firefighter a un owner défini, un cas d'usage défini, et le minimum d'autorisations nécessaires pour ce cas. Ce cadrage donne aux auditeurs une cartographie claire du qui-peut-faire-quoi en urgence, et pourquoi.

Ownership et redevabilité

Chaque rôle Firefighter doit avoir un owner métier nommé, distinct de l'utilisateur qui détient l'ID Firefighter. Cet owner est redevable de :

  • L'approbation (ou pré-approbation) des sessions Firefighter.
  • La revue du log après chaque utilisation.
  • La revue périodique du périmètre du rôle et des attributions d'utilisateurs.
  • L'escalade d'activités suspectes ou de dérive de périmètre.

L'owner doit se trouver dans la ligne métier que le Firefighter sert, et non dans l'IT ou la sécurité. Pour le FI Production Support Firefighter, l'owner est un responsable finance senior ; pour le MM Emergency Procurement Firefighter, c'est un responsable achats ou supply chain senior.

Séparer l'ownership de l'exécution est un contrôle SoD structurel : les personnes qui utilisent Firefighter ne peuvent pas également valider son utilisation.

Journalisation et revue : le contrôle qui fait fonctionner Firefighter

Un accès Firefighter sans revue de log n'est pas un contrôle : c'est un contournement. SAP GRC EAM journalise les transactions exécutées pendant une session Firefighter, y compris les change documents quand c'est applicable. Le processus de revue doit :

  • Avoir lieu dans un SLA défini après chaque session (en général 24 à 48 heures).
  • Comparer l'activité réelle à la justification énoncée.
  • Signaler toute activité hors du périmètre de l'urgence déclarée.
  • Être signé par l'owner du rôle (ou un reviewer distinct de l'utilisateur Firefighter).
  • Conserver les preuves pendant la période d'audit définie par votre cadre de conformité.

La fatigue de revue est le principal risque opérationnel. Si votre processus Firefighter génère de nombreuses sessions par semaine avec des justifications vagues et des revues tamponnées, les auditeurs finiront par le remarquer. Deux remèdes : réduire la fréquence d'usage (souvent en corrigeant en amont des manques dans les rôles habituels), et automatiser le workflow de revue avec des seuils d'escalade clairs.

Firefighter et SoD : comment ils interagissent

Les rôles Firefighter contiennent presque toujours des combinaisons d'accès en conflit SoD. C'est inhérent : l'intérêt du rôle est précisément de permettre des tâches que les règles SoD normales interdisent.

Le risque n'est pas que Firefighter accorde des accès SoD-conflictuels. Le risque est que Firefighter devienne un moyen d'exécuter du travail SoD-conflictuel de manière routinière, transformant l'accès d'urgence en contournement permanent.

Indicateurs que Firefighter est détourné en bypass permanent :

  • Fréquence d'usage élevée par le même utilisateur.
  • Usage sans ticket d'incident ni justification spécifique.
  • Usage pour des activités de fin de période ou de clôture mensuelle (qui devraient être traitées par une bonne conception de rôle, pas par Firefighter).
  • Revues de log approuvées sans vérification de fond.

Une analyse périodique devrait corréler les patterns d'usage Firefighter avec les conflits SoD du catalogue de rôles habituel. Si un utilisateur détient un rôle courant avec un contrôle compensatoire SoD qui suppose « cet utilisateur n'effectue pas l'activité X », mais que les logs Firefighter montrent qu'il exécute l'activité X fréquemment, le contrôle compensatoire est cassé.

MTC Skopos permet de combiner les attributions de rôles habituelles avec les usages Firefighter pour faire apparaître précisément ce type d'incohérence.

Considérations S/4HANA

Sur S/4HANA, la conception Firefighter suit les mêmes principes mais dans un paysage légèrement différent :

  • Les business roles S/4HANA introduisent de nouveaux objets d'autorisation et apps Fiori qu'il faut couvrir en Firefighter.
  • Les déploiements cloud (Rise with SAP, Grow with SAP) peuvent offrir des options Emergency Access différentes selon l'édition.
  • L'intégration avec les fournisseurs d'identité (Azure AD, SAP IAS) change la manière dont les attributions d'ID Firefighter sont provisionnées et journalisées.

Une migration S/4HANA est la meilleure occasion de repenser les rôles Firefighter depuis une feuille blanche, plutôt que de porter les Firefighter ECC existants. Voir notre guide migration S/4HANA pour le playbook complet de refonte des autorisations.

Constats d'audit les plus fréquents sur Firefighter

Les auditeurs externes recherchent un ensemble cohérent de faiblesses. Les plus courantes :

  1. Absence d'owner métier nommé, ou ownership porté par l'IT plutôt que par le métier.
  2. Rôles trop larges, souvent un « super Firefighter » unique couvrant tous les modules.
  3. Absence de revue de log, ou revue réalisée des mois après les sessions.
  4. Absence de SLA sur la revue ou revue effectuée par l'utilisateur ayant demandé l'accès.
  5. Attributions Firefighter permanentes ou à durée illimitée pour certains utilisateurs.
  6. Absence de workflow de pré-approbation pour l'usage Firefighter, ou workflow régulièrement contourné.
  7. Patterns d'usage Firefighter incohérents avec les cas d'usage déclarés (par exemple, Firefighter utilisé chaque semaine pour des tâches routinières).
  8. Absence de rétention des preuves de revue sur la période d'audit.

Chacun devient un constat d'audit spécifique nécessitant une remédiation. Les traiter en prévention, dans la conception et la gouvernance opérationnelle de Firefighter, coûte nettement moins cher que les remédier sous pression d'audit.

Comment MTC aide

Notre intervention sur Firefighter couvre typiquement :

  • Conception du catalogue de rôles Firefighter aligné avec votre paysage SAP et votre appétit au risque.
  • Conception des processus de demande, approbation, journalisation et revue.
  • Définition des owners et formation dans les lignes métier.
  • Intégration avec SAP GRC Access Control, ou configuration de patterns d'accès d'urgence alternatifs pour les organisations sans GRC.
  • Analytics d'usage via MTC Skopos pour corréler les patterns Firefighter avec l'exposition SoD globale.
  • Préparation à l'audit et remédiation des constats Firefighter existants.

Pour les programmes d'implémentation GRC de grande ampleur, nous collaborons avec des cabinets internationaux de premier plan en audit, risque et technologie pour délivrer à l'échelle, tout en maintenant une équipe senior basée en Suisse responsable des enjeux de sécurité et d'autorisations.

À lire également

Basés à Genève, nous aidons les organisations suisses à concevoir des processus Firefighter qui passent l'audit et restent utilisables au quotidien. Contactez-nous pour discuter de votre modèle d'accès d'urgence.

Questions fréquentes

Qu'est-ce qu'un rôle Firefighter SAP ?

Un rôle Firefighter SAP est une attribution d'accès temporaire à privilèges élevés qui permet à un utilisateur d'exécuter des tâches d'urgence au-delà de ses autorisations normales. Le concept fait partie de SAP GRC Emergency Access Management (EAM) et sert à la résolution d'incidents, au support production et autres scénarios ponctuels où les rôles habituels ne suffisent pas.

Comment concevoir correctement les rôles Firefighter SAP ?

Des rôles Firefighter bien conçus sont limités à des cas d'usage précis (par exemple résolution d'incidents FI, création d'urgence d'un fournisseur MM), attribués à un owner métier nommé, bornés dans le temps, entièrement tracés, et revus après chaque utilisation. Les rôles Firefighter génériques et tout-puissants constituent un risque majeur de constat d'audit.

Quelle différence entre Firefighter et SAP_ALL ?

SAP_ALL donne un accès illimité et ne devrait jamais être attribué à des utilisateurs finaux en production. Firefighter attribue un accès élevé mais cadré sur une fenêtre de temps limitée, avec journalisation obligatoire, justification et revue après usage. Firefighter est auditable ; SAP_ALL ne l'est pas.

Les rôles Firefighter créent-ils des conflits SoD ?

Les rôles Firefighter contiennent presque toujours des combinaisons d'accès qui seraient des conflits SoD s'ils étaient permanents. C'est précisément pour cela que les contrôles compensatoires (pré-approbation, journalisation, revue de session, limite temporelle) sont essentiels. Sans eux, Firefighter devient une porte dérobée qui contourne le cadre SoD.