Hi GRC/ Security Experts,
To brief you quickly, we have an SAP GRC AC 10 SP13 about to be deployed with ARA & EAM Modules as a first phase deployment.
All of the functionality is almost setup, just refining few things before going live.
About the GRC Authorizations, I observed few anomalies in the standard delivered SAP Roles for EAM.
I am aware that processes & compliance's, can vary from organization to organization. I am trying to redesign some of the EAM related authorizations, especially for Firefighter Owner/Controller.
In the standard delivered EAM roles, there are few things missing and few unnecessarily attached.
I am already aware of the provided information in the following resources:
- 1730649 - Firefighter owner can assign ANY Firefighter ID to Firefighter User
- 1663949 - EAM: Authorization Fixes for Central Owners and Reason Codes and have referred to EAM Authorization
- EAM Authorization Concepts & Guide
- GRC AC Latest Security Guide.
I am wondering, many of GRC AC 10 implementations must have gone live by now, and how can be the following authorization hardening concerns be addressed.
I observed the following anomalies, and used ST01 tracing to refine and address few of them still some of them I cant seem to get hold of:
1) [SOLVED] EAM Owners should technically not be allowed to Create/Maintain Reason Codes, that should be EAM Administrator's task. This was addressed by adjusting the auth objects from Owner's Role and only Reason Codes Display was provisioned to the owner's, hence this is addressed.
2) [SOLVED] EAM Owners should not be allowed to Create/Maintain EAM Controllers. This is a grey controversy I believe, as in my organization EAM Controller is treated on even Higher Scale than Owner and thus EAM Controller maintenance should only be done by the EAM admin rather than EAM Owner. This also I have addressed by adjusting few auth objects, which leaves the EAM Owners with Display only access of EAM Controllers.
3) [UNSOLVED] EAM Owner is able to assign any Firefighter ID to End-User: This is anomaly as per me, and is also specified in notes 1730649 & 1663949, but I find it hard to figure out the real solution of that specific issue. The notes just point to EAM Authorization Guide, which explain the GRC Authorization concept in general, which I of course get it. The GRC SP13 is already higher than the one applicable for the issue.
Technically EAM Owner should only be able ASSIGN the FF IDs that are Owned by him, this I cant seem to figure out how exactly.
I have gone through the Authorization Guide, Security Guide, Played too much with System Trace ST01 trying to redesign the authorizations. How would you have done it? This wasn't there in Virsa earlier, it used to bug you back saying that FF ID is not owned by you.
4) [UNSOLVED] Similarly like above, EAM Owner is able to modify assignments/delete assignments of any FF ID. This is of course cascaded from the above issue. I believe it doesn't has to be like this, EAM Owner should only be able to access/modify/maintain the FF IDs owned. Maintenance of the FF IDs not owned by EAM Owner should be truly abstained.
5) EAM Owners should not be able to Add/Delete the Assignments of Owner with FF ID. This is the starting point of the Firefighter Structure and must be restricted to EAM Administrator. In the Standard EAM Owner role, an EAM Owner can created another OWner, assign a FF ID to another Owner, Delete a Owner-FF ID assignment. EAM Owner should have display only access as far as it is concerned about the EAM Owners access Area. This one I have yet to test, which I think would be possible. Can't get hold of points 3 & 4.
I have already studied/implemented the suggestions/recommendations/corrections from Authorization Guide.
But i still feel that these are few loopholes and must be closed before I conclude the implementation.
What do you think?
Would truly appreciate, if you can point out the objects and values that can help to address the open issues.
Apologies, for such a lengthy post, but the authorization goes deep here I guess and ST01 isn't helping me anymore to get over this.
Regards,
Akshay