The Background: SAP Security Best Practice
SAP Best Practices for SAP Security encourage the PRODUCTION systems to keep only Security roles that are used for executing job duties in that system. SAP Roles that are provided during an ‘Upgrade’ or a new installation are to be copied and re-named with the customer’s naming convention.
“SAP's recommendation is to copy the standard roles into your own name space and make modifications to the copies as needed”
The standard roles need only exist in the DEV system. This would be the ‘BASE’ to copy the Standard roles needed by the Business, and re-name those roles and modify them to the business needs. This also would be a ‘START’ since later on customized roles can be created based on the usage for a group of users over a period of time.
An SAP upgrade could change the SAP BASE roles and overwrite them if they are used directly for access.
For our client, all of the SAP BASE roles were in both Production and TST as well as DEV. For compliance reasons, the client requested to see all roles that did not have a user assignment. The way to retrieve all roles without user assignments is to use the transaction code SUIM as follows:
Do not enter a role name, but select the option "without user assignment”
The result is a report that looks like this, which can be EXPORTED to an Excel file. There are 2,444 roles in this client that do NOT have a user assigned. Most of the roles consist of a “/” to start or “SAP_”
After the client reviewed the list of ‘unassigned roles’, they made the determination of which roles they wanted to keep in PRODUCTION, and which they wanted removed. The Compliance team officially requests to remove the ‘unassigned’ roles which brings us to the next step in this process.
Using the same SUIM transaction in DEV, we downloaded the unassigned roles in DEV to a new spreadsheet. MS ACCESS helped compare the two excel downloads and we exported the resulting table to a spreadsheet ensuring that all the roles in PRD to be removed did exist in DEV. Please keep in mind to copy the DEV client to another client so if there is a refresh of DEV, the roles are not lost altogether. In the possibility that DEV is ever refreshed, you can also do a client copy of the security roles and restore them to the refreshed client, or, export the user masters and Roles etc. using the SCC9 transaction for Security and users.
The resulting spreadsheet looked like this exporting out of MSACCESS to an EXCEL file:
The next task was to remove the roles. SAP recommends that you create a transport with the role in it, then after the transport with the role is created, delete the role and move the deleted role in the transport up the landscape – however, we need to keep the roles in DEV and also in TST so the roles can be used if needed.
After some research it appeared that an OSS note or SAP Incident was created by SAP to remove a large amount of roles in a system. We applied the note #313587 in the DEV environment and tested it using the TEST selection box to show what roles would be removed:
The test scenario produced a list of roles that were to be removed, which would give us a record and audit trail of what was actually removed. The screen shots were evidence of what was removed in PRD.
In summation, a task that would have taken someone going into PFCG and manually deleting each role 2,444 times in this instance, took a few hours to remove and document.
The client also requested a new raw data load of the table AGR_DEFINE which contains all roles in the PRD system. That was provided with screen shots to show how the table was accessed and the raw data downloaded to show the reduction in records.
All in all, the client and compliance team were delighted and this was a win- win situation for their team and our team here at TriCore Solutions. We were able to quickly save the client time and produce actionable, documented results quickly.