General information on permissions
The examination of roles and authorizations will reveal many authorization conflicts (SoD) and risk transactions (cA). In my experience, this is mostly the case with “grown” authorizations and roles.
In order to get the many SoD conflicts – and also the maintenance effort – under control, to comply with the guidelines and compliance within the company vis-à-vis the CIO, compliance officer, etc. or external auditors, there is usually no path to one Restructuring of the SAP authorization system over.
Problems with an existing authorization concept
Reasons:
- “wild growth” with increased roles and authorizations
- Redundant transactions and authorizations in the roles
- Allocation of authorizations via so-called reference users
- Authorizations are not mapped in workplaces, but rather process roles, for example
- No “need2know” principle
- Many non-compliance authorizations and critical transactions
- High maintenance of the authorizations by the authorization administrator
(e.g. withdrawing / recording transactions, displaying process changes)
The approach of the task role concept
Advantages:
- A transaction is in a task role
- No redundant authorizations in the task roles
- Assignment of authorizations via derived task roles in the workplaces
- need2know – i.e. only required transactions (task roles) in the workstations
- Creation of compliant jobs through AP splitting
- Low maintenance of authorizations (e.g. withdrawal / inclusion of a transaction)
- Less manpower when assigning authorizations, e.g. for process changes etc.
