SAP GRC est un de ces noms de produit qui signifient des choses différentes selon les personnes. Pour un auditeur, c'est le rapport qui montre qui a des conflits de séparation des tâches. Pour une équipe sécurité, c'est le workflow qui provisionne les accès. Pour un chef de projet qui a vécu une implémentation, c'est dix-huit mois et un ruleset que personne ne veut maintenir. Tous parlent de morceaux de la même suite.

Ce guide est la version du consultant : ce que contient réellement SAP GRC, comment s'articulent les composants d'Access Control, et la réponse honnête à la question que la plupart devraient se poser en premier, à savoir s'ils ont besoin du produit complet.

Qu'est-ce que SAP GRC ?

SAP GRC (Governance, Risk and Compliance) est une suite d'applications pour gérer le risque et la conformité sur un paysage SAP. La suite comprend plusieurs produits :

  • Access Control: risque d'accès, séparation des tâches, provisioning et accès d'urgence. C'est la partie que la plupart des gens désignent en disant « GRC ».
  • Process Control: surveillance et test des contrôles internes sur les processus métier.
  • Risk Management: identification, évaluation et traitement du risque d'entreprise.
  • Audit Management et outils adjacents pour la fonction d'audit interne.

La suite de ce guide se concentre sur Access Control, car c'est là que vivent réellement la sécurité SAP et les risques d'accès.

Les quatre composants de SAP GRC Access Control

Access Control n'est pas une seule chose. Ce sont quatre composants qui résolvent des problèmes différents, et l'essentiel de la confusion autour du GRC vient du fait de les traiter comme interchangeables.

Access Risk Analysis (ARA)

ARA trouve le risque. Il exécute votre ruleset de séparation des tâches contre les utilisateurs, rôles et profils et remonte les conflits et expositions aux accès critiques. C'est le moteur derrière le rapport d'audit. Sa sortie ne vaut que ce que vaut le ruleset qui la sous-tend, et c'est la partie que les organisations négligent le plus souvent. Un ruleset générique prêt à l'emploi vous noiera dans les faux positifs ou manquera les conflits qui comptent pour votre métier.

Tout aussi important est ce qu'ARA ne fait pas. Il identifie et remonte le risque, puis s'arrête. Il n'y a aucune recommandation de remédiation, et sa simulation fonctionne au niveau du rôle ou de l'action (que se passe-t-il si vous attribuez ce rôle), pas au niveau de l'objet d'autorisation, là où un rôle propre se façonne réellement. Déterminer quelle autorisation retirer, scinder ou redessiner pour lever un conflit sans casser une fonction métier est un travail d'expert manuel, et c'est là que se concentre l'essentiel de l'effort réel d'un programme SoD.

C'est aussi le terrain que couvre notre propre outil, MTC Skopos : analyse SoD et des accès critiques au niveau autorisation, plus les recommandations de remédiation et la simulation au niveau objet pour le façonnage des rôles qu'ARA ne fournit pas, sur systèmes SAP et non-SAP. Il correspond à ARA, pas aux composants ARM, BRM ou EAM.

Access Request Management (ARM)

ARM automatise la demande, l'approbation et le provisioning des accès. Un utilisateur (ou son responsable) émet une demande, elle passe par les approbateurs via un workflow, ARA la vérifie pour tout nouveau conflit SoD avant l'octroi, et le provisioning se fait automatiquement. C'est le composant qui transforme la gestion des accès, de l'e-mail-et-tableur en un processus contrôlé.

Business Role Management (BRM)

BRM est l'endroit où les rôles sont conçus, documentés et maintenus, avec une méthodologie et un chemin d'approbation définis. Il relie les rôles techniques aux business roles et garde le catalogue gouverné plutôt que tentaculaire.

Emergency Access Management (EAM)

EAM, universellement appelé Firefighter, gouverne l'accès élevé temporaire pour les urgences : un utilisateur assume un ID Firefighter à haut privilège sur une fenêtre bornée, chaque action est journalisée, et le log est revu ensuite. Nous le détaillons dans notre guide de conception des rôles Firefighter SAP, et le versant technique d'un changement de support package récent dans notre guide d'implémentation de la note 3318927.

Comment les composants fonctionnent ensemble

Les composants se renforcent mutuellement quand ils sont tous en jeu. ARM vérifie chaque nouvelle demande contre le ruleset ARA, de sorte que les conflits sont évités à la porte plutôt que trouvés un an plus tard en audit. BRM garde les rôles propres pour qu'ARA ait moins à signaler. EAM traite les exceptions qu'une conception de rôle propre ne peut pas couvrir. Un programme GRC qui n'implémente qu'ARA, en laissant le provisioning manuel, obtient le rapport d'audit mais aucune prévention.

Sous tout cela se trouve la configuration technique : workflows MSMP, règles BRF+, connecteurs vers chaque système managé, et le plugin GRCPINW sur ces systèmes. Cette mécanique est puissante et réellement complexe, ce qui amène la question qui mérite d'être posée tôt.

Avez-vous réellement besoin de SAP GRC complet ?

Le GRC Access Control complet est le bon choix quand vous avez besoin de provisioning automatisé par workflow à l'échelle, d'une intégration étroite avec la gestion des identités, et d'une gouvernance continue sur de nombreux systèmes et des milliers d'utilisateurs. Pour une grande entreprise réglementée, il justifie son coût.

Il est surdimensionné pour beaucoup d'organisations. Si votre besoin réel est de trouver et remédier les conflits de séparation des tâches, produire une preuve d'audit propre et revoir les accès périodiquement, une implémentation GRC complète est un moyen coûteux d'y parvenir. Le moteur de workflow, la configuration MSMP et la maintenance continue sont un coût dont vous n'avez peut-être pas besoin.

C'est là qu'une approche plus légère basée sur un outil trouve sa place. Notre propre outil, MTC Skopos, réalise l'analyse des risques d'accès et de la SoD au niveau autorisation sans la charge du workflow de provisioning, sur systèmes SAP et non-SAP. Pour la méthodologie et une comparaison directe, voir SAP GRC face à un outil SoD dédié. Le propos n'est pas que le GRC est mauvais ; c'est que la suite complète est un engagement lourd, et que beaucoup d'organisations obtiennent le résultat de conformité dont elles ont besoin pour bien moins cher.

Là où les implémentations GRC échouent

Les schémas d'échec sont constants, et aucun ne concerne vraiment le logiciel :

  • Le ruleset n'est jamais approprié. ARA est activé avec un ruleset générique que personne n'adapte, donc les rapports sont ignorés.
  • Les workflows sont sur-conçus. MSMP est configuré avec plus d'étapes d'approbation que le métier ne tolérera, et les gens le contournent.
  • La revue des logs Firefighter se délite. Les sessions s'accumulent, les revues deviennent des tampons, et le contrôle qui rendait l'accès d'urgence défendable cesse de fonctionner.
  • Les rôles continuent de proliférer. BRM est sauté, donc le catalogue de rôles grossit plus vite que quiconque ne peut le gouverner et ARA a plus à signaler chaque trimestre.

Chacun est un problème d'operating model déguisé en problème technologique. Les corriger relève surtout de l'ownership, de la discipline de périmètre et d'une conception de processus réaliste, là où le conseil trouve sa place.

Comment MTC aide

Nous intervenons sur tout le cycle de vie : conception et implémentation de GRC Access Control, benchmarking et remédiation de ruleset, conception des processus Firefighter, et le travail technique ingrat de maintenir le plugin et les workflows sains après les upgrades. Nous vous donnons aussi la réponse honnête sur le périmètre, y compris quand une alternative plus légère vous sert mieux. Sur les grands programmes GRC, nous collaborons avec des cabinets internationaux de premier plan en audit, risque et technologie, tout en gardant une équipe senior basée en Suisse responsable du résultat de sécurité.

À lire également

Questions fréquentes

Qu'est-ce que SAP GRC ?

SAP GRC (Governance, Risk and Compliance) est une suite d'applications SAP pour gérer les risques d'accès, les contrôles de processus, le risque d'entreprise et l'audit. Son composant le plus connu est SAP GRC Access Control, qui gère l'analyse de la séparation des tâches, les workflows de demande d'accès, la gestion des rôles et l'accès d'urgence. Les autres composants incluent Process Control, Risk Management et Audit Management.

Quels sont les composants de SAP GRC Access Control ?

SAP GRC Access Control comporte quatre composants principaux : Access Risk Analysis (ARA) pour l'analyse de la séparation des tâches et des accès critiques ; Access Request Management (ARM) pour les workflows automatisés de demande et de provisioning ; Business Role Management (BRM) pour concevoir et maintenir les rôles ; et Emergency Access Management (EAM), aussi appelé Firefighter, pour l'accès élevé temporaire et contrôlé.

Quelle différence entre ARA et EAM dans SAP GRC ?

Access Risk Analysis (ARA) détecte les conflits de séparation des tâches et les accès critiques sur les utilisateurs et les rôles, pour trouver et remédier au risque. Emergency Access Management (EAM, ou Firefighter) accorde un accès élevé contrôlé, journalisé et limité dans le temps pour les urgences. ARA sert à trouver le risque permanent ; EAM sert à gouverner l'accès temporaire quand les rôles habituels ne suffisent pas.

Ai-je besoin de SAP GRC ou existe-t-il une alternative ?

SAP GRC Access Control complet se justifie quand vous avez besoin de workflows de provisioning automatisés, d'une intégration continue avec la gestion des identités SAP et d'une gouvernance à l'échelle de l'entreprise. Pour les organisations plus petites, ou celles qui ont surtout besoin d'analyse et de remédiation de la séparation des tâches sans le moteur de workflow, une approche plus légère basée sur un outil comme MTC Skopos, notre propre outil d'analyse des risques d'accès, couvre l'analyse sans déploiement GRC complet.