SAP Security Role Redesigning[Edition 2/2]- (FGT-KBA)

4th January 2023

256

This is an article from our KBA (Knowledge Based Article) series.

Edition 2- SAP Security Role Redesigning

Problem Statement
SoD (Segregation of Duties) Violation has been raised for many roles and that need to be remediated.

Proposed Solution- SAP Security Role Redesign

DUPLICATE Roles and their User assignments need to be revisited.
Roles Design and Assignment must be aligned with understanding of user/tasks/transaction based design and its Utilization
Rationalize SAP role design based on business process flow and logical grouping of related tasks to replace user/transaction based role design
SAP Security Architecture design that can be used as model for baseline roles and scalable for future strategic business expansions in terms of Company codes, Plants, Storage Locations, Profit centers, Warehouse Numbers
Identify and restrict critical access based on Authorization Object, Cost Center, Document types, Authorization groups 🡪 Tables, programs
Elimination of Segregation of Duty conflicts within SAP roles

Benefits of SAP Security Role Redesign

Cleaner SAP Roles– Removal of Duplicate Roles and removing unnecessary and unutilized roles/tasks/permissions shall provide a clean Authorization environment with minimised SoD Risk Violations.
Fewer role change requests– Well designed security roles lead to fewer number of security role change requests. A robustly designed and tested security model can reduce role change requirements considerably. Optimized role ownership reduces the administrative and operational overhead and ensures that role design continues to be in place even after the redesign effort.
Faster security administration– Removal of redundant and unnecessary transaction codes from security roles leads to faster and easier user role administration. Consistent and well defined naming convention supplemented by text descriptions that are intuitive and are attuned to the role contents will facilitate faster and more accurate user access provisioning.
Increased flexibility and scalability– A good security role design is flexible and can easily scale to support future growth and merger and acquisition activities. As Customer continues to roll SAP out to other locations, a scalable solution can be leveraged to reduce time spent on Security and ensure access and SoD controls are maintained.

Guiding Principles
Some of the basic principles that will guide the role redesign process are:

Use a task based approach to develop simple roles that reflect the task performed. This requires less maintenance effort, and minimizes SOD conflicts within roles. (Example: Maintain PO, Display PO)
Develop master and derived roles so that organizational level restrictions can be utilized. Derived roles also allow for simplified role maintenance.
Future maintenance should consist of minimal additions/removals of transaction codes to SAP roles. Instead, if changes are necessary, the SAP to Business role mappings should be updated.

New Roles: Criteria & Methodology

Criteria

There should be no SOD conflict within a Task role. Activities that can cause SOD conflicts when grouped together will be split into separate task-based roles.
Each transaction code should be in as few roles as possible. For example, instead of putting FK10N (Vendor Balance Display) in multiple roles, this should be put into a separate task-based SAP role, such as Display Vendor Documents. This SAP role can then be mapped to multiple Business roles/composite roles.

Methodology

Identify all transactions executed in past
Eliminate all transactions that have not been executed in past 2 years from scope
Break down the existing roles into task based roles (in order to break down SOD conflicts)
Work with Business Analysts to identify the user to task based role mapping. Example- Jack will need: Maintain PO, Maintain SA, Display Vendor

Regards,

Team FuGenTimes