Les règles d'accès sont la fondation de toute analyse de risque d'accès efficace. Elles définissent quelles combinaisons de droits d'accès constituent un risque et permettent à MTC Skopos d'identifier les conflits de Séparation des Tâches et les accès critiques au sein de votre organisation.
MTC Skopos inclut un modèle de règles d'accès (plus de 350 risques SoD, plus de 700 contrôles d'accès critiques et plus de 100 contrôles de qualité des autorisations) comme point de départ, et non comme une réponse définitive. Les règles d'accès doivent correspondre à l'organisation qu'elles décrivent : elles vous appartiennent. Vous les revoyez, les adaptez à vos processus et à vos systèmes, et les maintenez à mesure qu'ils évoluent. Nous ne livrons pas de mises à jour des règles d'accès. Notre équipe de conseil peut adapter le modèle ou construire les règles avec vous si vous le préférez.
Comprendre les règles d'accès
En tant que consultants en sécurité, nous savons que la mise en œuvre des règles de Séparation des Tâches (SoD) et d'accès critiques (CA) dépasse la simple configuration technique. Les contrôles système et la mise en œuvre technique des autorisations sont essentiels, mais ils ne représentent que la moitié de l'équation. L'efficacité d'un cadre SoD/CA dépend d'une compréhension approfondie des processus métier, de la structure organisationnelle et de la configuration système de l'organisation.
Pour identifier les risques, il faut aligner les rôles et autorisations techniques avec les fonctions métier. Cela implique d'échanger avec les acteurs métier, de cartographier les processus et de s'assurer que les règles d'accès reflètent la manière dont l'organisation fonctionne réellement, et pas seulement la manière dont le système est configuré. Cette approche garantit la conformité, l'efficacité opérationnelle et l'adhésion des utilisateurs.
Types de règles
Règles de Séparation des Tâches (SoD) Les règles SoD définissent les combinaisons de fonctions qui ne doivent pas être exercées par la même personne. Par exemple :
- Créer un fournisseur ET traiter les paiements à ce fournisseur
- Saisir des commandes d'achat ET les approuver
- Maintenir les comptes utilisateurs ET attribuer les rôles d'autorisation
Règles d'accès critiques Les règles d'accès critiques identifient les fonctions sensibles qui nécessitent un suivi indépendamment des autres accès. Exemples :
- Accès direct à la base de données ou capacités de débogage
- Modifications de la configuration système
- Transactions de modification de données en masse
Structure des règles d'accès
Comment maintenir les règles d'accès ?
Le fichier de règles d'accès peut être ouvert et maintenu directement dans Microsoft Excel. La structure est complète et facile à maintenir.
Le fichier de règles d'accès contient les composants clés suivants :
| Composant | Description |
|---|---|
| ID du risque | Identifiant unique de chaque règle de risque |
| Description du risque | Description compréhensible du conflit pour le métier |
| Niveau de risque | Classification (élevé, moyen, faible) selon l'impact potentiel |
| Fonction 1 | Première fonction du conflit SoD |
| Fonction 2 | Seconde fonction du conflit SoD |
| Actions | Transactions techniques, objets d'autorisation ou permissions |
| Système | Système cible pour l'analyse cross-system |
Bonnes pratiques pour développer les règles d'accès
- Partir des processus métier – Cartographiez vos processus métier critiques avant de définir les règles techniques
- Impliquer les parties prenantes – Faites valider par les responsables de processus que les règles reflètent les risques réels
- Prioriser par impact – Concentrez-vous d'abord sur les zones à fort risque (transactions financières, données de référence)
- Documenter le rationnel – Notez la raison d'être de chaque règle pour répondre aux questions d'audit
- Revue régulière – Mettez à jour les règles d'accès lorsque les processus métier ou les systèmes évoluent
À quelle fréquence revoir les règles d'accès SoD ?
Au moins tous les six mois, et à chaque évolution du périmètre : nouveau module, nouvelles applications Fiori, transactions spécifiques, extension BTP, réorganisation. Beaucoup d'organisations en font moins. Dans l'enquête SoD 2026, 37 % des répondants revoient leurs règles une fois par an et 19 % ne les revoient jamais (contre 6 % en 2021), et seuls 30 % disposent d'une procédure de revue documentée et appliquée. Des règles d'accès qui ne sont pas revues cessent peu à peu de décrire le système qu'elles doivent couvrir, et leurs résultats « propres » deviennent des faux négatifs.
Que doit vérifier une revue ?
- La couverture de ce qui est réellement déployé. Nouvelles transactions, applications Fiori et leurs services OData (
S_SERVICE), transactions Z, et en S/4HANA le modèle Business Partner qui remplace les transactions fournisseur et client - Les deux chemins d'accès aux tables. Une règle construite sur
S_TABU_DIS(accès par groupe d'autorisation) doit avoir son équivalentS_TABU_NAM(accès par nom de table), sinon un utilisateur atteint la même table sans la déclencher. Dans MTC Skopos, une action est un groupe de permissions en texte libre et non un code transaction : une même fonction peut porter les deux variantes pour une seule transaction (SM30_DISetSM30_NAM, par exemple), et chacune déclenche le risque. Les outils qui identifient les actions par code transaction, comme SAP GRC, ne peuvent pas porter deux variantes de la même transaction dans une fonction - Les règles qui ne se déclenchent jamais. Un risque sans aucun résultat depuis un an est soit bien maîtrisé, soit mal défini : vérifiez lequel
- La criticité et les responsables. Des niveaux de risque et des propriétaires toujours conformes à l'organisation
- Chaque système du périmètre. Un tenant S/4HANA Public Cloud a besoin de ses propres règles d'accès, écrites sur les applications IAM
Comment mener une revue vérifiable par un auditeur ?
- Versionner le fichier. Conservez les règles d'accès dans Excel avec la version dans le nom (par exemple
SoD 2026 T4) et utilisez la colonneStatuspour désactiver une règle plutôt que la supprimer - Analyser avant et après. Comparez les deux analyses dans la vue de comparaison : chaque conflit ajouté ou supprimé par la modification apparaît, avec la fonction et l'action en cause. Une analyse complète de 10 000 utilisateurs prend moins de 2 minutes sur un ordinateur portable standard : l'impact de chaque modification est visible avant validation
- Conserver les journaux signés. Chaque analyse produit un journal signé (Ed25519) qui enregistre l'empreinte de la version des règles d'accès utilisée et de chaque table analysée
- Formaliser la validation. Le responsable métier approuve la liste des modifications et la comparaison avant/après, ce qu'aucun outil ne peut faire à sa place
Règles d'accès cross-system
Comment fonctionnent les règles d'accès cross-system ?
Renseignez le champ « Système » pour indiquer le système où la fonction est censée être déclenchée. Cela permet à MTC Skopos d'identifier des risques s'étendant sur plusieurs systèmes ERP.
Note : les fichiers de règles d'accès contenant plusieurs systèmes ne peuvent être utilisés que dans des scénarios d'analyse de risques cross-system.
Exemple de risque cross-system : Un utilisateur capable de créer des fournisseurs dans SAP et d'approuver des paiements dans un système de trésorerie distinct présente un conflit SoD cross-system qui ne serait pas détecté en analysant chaque système isolément.
Besoin d'aide ?
Construire des règles d'accès efficaces exige à la fois des connaissances techniques et une bonne compréhension des processus métier. Notre équipe de conseil peut vous accompagner pour :
- Construction des règles d'accès – Créer un jeu de règles sur mesure adapté à votre organisation
- Personnalisation du modèle – Adapter notre modèle de règles d'accès à votre environnement spécifique
- Validation et tests – Vérifier que les règles identifient bien les risques réels
- Formation – Permettre à votre équipe de maintenir et faire évoluer les règles d'accès en autonomie