Quand un utilisateur lance une transaction, les conditions suivantes doivent être validées :

1. La table TSTC doit contenir la transaction lancée
2. La transaction ne doit pas être verrouillée (par SM01)
3. L'objet d'Autorisation S_TCODE doit contenir cette transaction
4. Les autres objets d'autorisation correspondants aux « Authority-Check » doivent contenir leurs autorisations correspondantes

La transaction sera alors lancée, sinon, un message d'erreur s'affichera.

Voici la liste des objets d’autorisations sensibles :

1. S_TCODE pour les transactions code
2. S_PROGRAM pour les programmes (P_GROUP)
3. S_TABU_DIS pour les tables (DICBERCLS)
4. S_DEVELOP pour l'ABAP Workbench / debugger

Les tables et les programmes Z doivent contenir respectivement des groupes d’autorisations dans leurs champs DICBERCLS et P_GROUP.

Cette conversion est judicieuse pour dériver un rôle par un champ d’objet d’autorisation standard.

Pour procéder à la conversion, lancer SA38 -> PFCG_ORGFIELD_CREATE « nom du champ à déplacer »

Il serait souhaitable que cette opération soit faite avant la création des rôles. Si cela n’est pas le cas, une analyse d'impact s’impose.

Remarque : Les champs ACTVT et TCD ne peuvent pas être convertis en champ organisationnel.

Pour plus d’information, se référer aux notes 565436, 698401 et 323817.

Vous trouverez ci-dessous un exemple de convention de codification de groupe utilisateur, des rôles maître et dérivé

1. Groupe Utilisateur

BBCDDDDD
BB correspond au pays
C correspond à la compagnie à laquelle l'utilisateur appartient
DDDDD est le département

Exemple
DEKF&A Utilisateur en Allemagne fonctionnant pour la compagnie KAB dans le département de F&A

2. Rôle Maître

AAAXXXXXBCCCD
AAA correspond au système dans lequel le rôle a été développé/ maintenu
XXXXX signifie le rôle maître
B est le module SAP
CCC est une description à trois caractères du rôle
D est le type de rôle : A pour lecture/écriture et D pour affichage

Exemple
R01XXXXXFBANA Rôle Finance Banque en maintenance dans le système R01

3. Rôle Dérivé

AAACCDDDFGGGH
AAA correspond au système dans lequel le rôle a été développé/ maintenu
CC correspond au pays
DDD correspond à la compagnie
F est le module SAP
GGG est une description à trois caractères du rôle
H est le type de rôle : A pour lecture/écriture et D ...

Ce document décrit les 7 tâches périodiques de Risk Analysis and Remediation (RAR) anciennement appelé Virsa Compliance Calibrator

1. Charger le Texte Statique « Static Text »

1. Se loguer sur l’ERP
2. Saisir la transaction SE38
3. Entrer /VIRSA/ZCC_DOWNLOAD_DESC dans le champ Program
4. Cliquer sur le bouton Execute
5. Saisir le chemin et le nom du fichier que vous voulez télécharger dans le champ Application server file et le champ Suggestion
6. Programmer ce travail en tâche de fond quotidienne
7. Retourner à (RAR) et cliquer sur l’onglet Configuration
8. Développer le menu Upload Objects et choisir Text Objects
9. Compléter les champs suivants :
System ID
Application server file
10. Programmer ce travail en tâche de fond une heure après l’exécution de celui de l’ERP (point 6)

2. Charger les Objets d’Autorisations « Authorization Objects » (SU24)

1. Se loguer sur l’ERP
2. Saisir la transaction SE38
3. Entrer /VIRSA/ZCC_DOWNLOAD_SAPOBJ dans le champ Program
4. Cliquer sur le bouton ...

Ce document décrit succinctement les points essentiels de la mise en place d’un concept d’autorisation SAP.

1. Définition des conditions cadre

Il s’agit de définir tous les pré-requis indispensables à la création d’un concept d’autorisation. L’approbation d’un décideur est vivement recommandée. Ces conditions peuvent être sujettes à mise à jour. Cela est dû aux changements techniques et administratifs au sein de l’entreprise.
D’autre part, toutes les procédures internes et externes à l’entreprise qui touchent de près ou de loin à la conception des autorisations doivent être prises en compte.

2. Définition des fonctions « rôles composites »

Pour ce faire, des entrevues et des ateliers seront organisés avec les responsables (comptabilité, achat,…) afin d’établir la liste des fonctions ou rôles composites. Ne pas oublier de tenir compte de la séparation des responsabilités.
Les rôles ne doivent pas être créés pour un utilisateur donné mais pour un groupe d’utilisateurs. Le but est d‘établir un concept ...

1. Introduction de la loi SOX « Sarbanes-Oxley »

Cette loi a été introduite suite à une série de scandales financiers importants : Enron et Worldcom. La loi SOX a pour objectif de protéger les investisseurs en améliorant la précision et la fiabilité de l’état de santé des entreprises. Celle-ci met en place des contrôles internes des activités comptables et financières.

2. Qui a instauré cette loi ?

Le sénateur Paul SARBANES et le député Michael OXLEY ont rédigés le projet de cette loi en 2002.

3. A qui s’applique cette loi ?

- Aux entreprises dont le siège social est aux Etats-Unis.
- Aux filiales d'entreprises américaines à l'étranger.
- Aux entreprises cotées au NASDAQ.

4. Date de mise en conformité

La plupart des entreprises publiques « américaines » devaient se mettre en conformité par rapport à cette loi à compter du 15 juin 2004.

5. Organisation de cette loi

La loi SOX (Sarbanes-Oxley) est devenue la référence pour la transparence financière, la confiance et la responsabilité ...

FireFighter est un outil qui permet de créer des comptes avec des droits d’accès larges afin d’exécuter en production des opérations urgentes dans un environnement de production.

Pour vérifier que ces droits larges n’ont pas été utilisés frauduleusement, les transactions lancées via les comptes FireFighter sont tracées.

Les contrôleurs doivent vérifier dans les journaux que les transactions exécutés correspondent bien aux tâches à effectuer.

Les journaux doivent être conservés par l’administrateur FireFighter pour une durée donnée et mis à disposition des auditeurs.

1. Comptes FireFighter

Dans SAP, et à l’aide de la transaction SU01 :

Créer les comptes FireFighter pour chaque processus métier exemple FF_PROCURE (éviter d’assigner SAP_ALL)
Assigner les rôles FireFighter :
Administrateur -> /VIRSA/Z_VFAT_ADMINISTRATOR
FireFighter -> /VIRSA/Z_VFAT_FIREFIGHTER
Propriétaire -> /VIRSA/Z_VFAT_ID_OWNER

Dans FireFighter, et à l’aide de la transaction /VIRSA/VFAT :

Effectuer la correspondance ...

Vous trouverez ci-dessous le processus de gestion de la séparation des tâches :

1. Identification des risques :
Identifier les conflits et approuver les exceptions
Clarifier et classer les risques : grand, moyen, petit
Identifier les nouveaux risques et les conditions de surveillance

2. Création et validation des règles :
Référencer les meilleures règles pour votre environnement
Valider les règles
Adapter les règles et les tester

3. Analyse :
Exécuter les rapports analytiques
Estimer l’effort d’élimination des risques
Analyser les rôles et les autorisations des utilisateurs
Modifier les règles en se basant sur l’analyse
Mettre en place des indicateurs pour identifier les risques

4. Résolution des conflits :
Déterminer comment éliminer les risques
Présenter les analyses et choisir les actions correctives
Présenter le document d’approbation des actions correctives
Modifier ou créer les rôles ou les comptes utilisateurs

5. Contrôle compensatoire :
Déterminer comment compenser les risques
Former ...

Fournit un rapport en temps réel sur la gestion des rôles et des utilisateurs. Il interagit avec Virsa Compliance Calibrator et utilise les « Actions = Transactions » et les « Permissions = Autorisations » pour déterminer si un conflit de séparation des tâches SoD a été introduit au niveau des rôles et des utilisateurs.

Activation de Risk Terminator

Risk Terminator est activé dans les cas suivants :
1. Ajout d’une transaction à un rôle puis génération du profil correspondant à l’aide de PFCG
2. Affectation d’un rôle à un utilisateur via PFCG
3. Affectation d’un rôle à un utilisateur via SU01
4. Affectation d’un rôle à un utilisateur via SU10
Un rapport d’analyse de risque est affiché avec un message d’alerte comprenant le risque SoD s’il y en a un.

Configuration de Risk Terminator

Lancer /n/VIRSA/ZRTCNFG et choisir les options souhaitées :
Génération arrêtée en cas de violation (Yes / No)
Commentaires requis en cas de violation (Yes / No)
Envoi d’alerte en cas de violation (Yes / No)
Niveau ...

• Placer le curseur sur le champ souhaité. Nous prendrons comme exemple le champ fax de l'écran SU01
• Appuyer sur la touche F1
• Cliquer sur l’icône symbolisé par un marteau et une clé à molette
• Double-cliquer sur le champ correspondant à « Struct » il s’agit de «SZA5_D0700»
• Double-cliquer sur le champ souhaité dans la colonne « Component type »
• Dans notre exemple, double-cliquer sur le champ « AD_FXNMBR1 »
• Cliquer sur l'icône symbolisé par trois flèches
• Choisir « Table fields » et « Table types » et valider
• Ainsi, vous obtiendrez les tables relatives au champ fax : ADCP, ADCPS, ADRC, ADRCS et ADRCS2

Vous trouverez ci-dessous la liste des rapports standards d’audit de la sécurité SAP :

RSUSR003
Ce rapport permet de vérifier la consistance des mots de passe des comptes utilisateur comme DDIC et SAP* contenus dans chaque système et qui sont créés pendant l’installation de SAP.

RSUSR005
Ce rapport fournit la liste des autorisations critiques par utilisateurs dans un système SAP donné.

RSUSR006
Ce rapport fournit des informations concernant les tentatives non réussies ou non autorisées d'ouverture de sessions sur un système SAP donné. SAP recommande de le lancer tous les jours. En analysant ce rapport, nous pourront constater, par exemple, qu’un utilisateur ne s’est pas connecté sur un système pendant une période donné.

RSUSR008_009_NEW
Ce rapport est une version améliorée des rapports RSUSR008 et RSUSR009. Il fournit la liste des utilisateurs qui ont des autorisations critiques ainsi que ceux qui possèdent des combinaisons critiques des autorisations. Cela peut vous aider à évaluer votre niveau ...

Chaque concept d’autorisation SAP doit satisfaire à onze règles de base énumérées ci-dessous :

1. Concept d’autorisation basé sur le rôle
Les rôles seront créés par rapport aux tâches et aux postes existants dans l’entreprise. Ainsi, ces rôles pourront être utilisés plusieurs fois et ne dépendront pas des utilisateurs.

2. Autorisations nécessaires et suffisantes
Chaque utilisateur doit avoir les autorisations nécessaires et suffisantes pour mener à bien son travail. Pas d’excès d’autorisations en matière de droit d’accès.

3. Profondeur et complexité du détail
Etant donné, que SAP fournit un nombre non limité d’autorisations pour sécuriser l’accès à l’application et aux données, toute demande de recherches approfondies sur les autorisations doit être justifiée.

4. Autorisations critiques
Les transactions définies comme critiques au sein d’un service doivent être allouées uniquement à un nombre limité d’utilisateurs qualifiés. Les rangés de transactions ne doivent être accordées qu’en cas d’urge ...

La maintenance des autorisations et la gestion des utilisateurs doivent être organisées à travers une séparation claire des responsabilités de
l’administrateur des rôles et du gestionnaire des utilisateurs.

L’administrateur utilisateur est responsable de la création des utilisateurs et l’assignation des rôles correspondants.

Le gestionnaire des autorisations s’occupe de la maintenance des rôles et de la génération des profils.

En séparant ces 2 fonctions, nous atteindrons les objectifs suivants : séparation fonctionnelle et sécurité du système.

Remarque : plusieurs petites entités ne peuvent pas atteindre ce niveau de séparation des responsabilités. En effet, un ou deux employés sont tenus d’effectuer plusieurs tâches.

Voici la liste des objets d’autorisation qui relève de la séparation des responsabilités pour la gestion des utilisateurs et la maintenance des rôles :

S_USER_GRP maintenance des groupes d’utilisateurs
S_USER_AUT maintenance des autorisations
S_USER_PRO maintenance des profils ...

Les tables de SAP qui contiennent les informations relatives aux autorisations et aux rôles sont listées ci-dessous :

AGR_1016 nom de profil de rôle
AGR_1250 données d’autorisation des rôles
AGR_1251 données d’autorisation des rôles
AGR_1252 niveaux organisationnels
AGR_PROF nom de profil des rôles
AGR_SELECT assignation de transactions aux rôles
AGR_TCDTXT assignation de transactions aux rôles
AGR_TCODES assignation de transactions aux rôles
AGR_USERS assignation de rôles aux utilisateurs
TOBJ objets
TOBJC classification des objets d’autorisation
TOBJT description des objets TOBJ
TSTC code des transactions SAP
TSTCA valeur d’autorisation des transactions
TSTCP paramètre pour les transactions
TSTCT description des transactions
USH04 historique de changement des valeurs
USH10 historique de changement des profils
USH12 historique de changement des valeurs d’autorisation
USKRIA combinaisons critiques de TCODE
SUKRI combinaisons critiques de transactions
USOBT relation transaction-objet d’autorisation ...