SAP Security implementation approach

[#1]

Need your help / guidance to know the correct way to implement security for SAP ECC 6.0 .

Approach in brief for security implementation for SAP ECC

As a first step service provider has to do workshop to make client understand the role concepts. Once SOD matrix is decided then templates will be filled with job descriptions. After that authorization matrix will be build.

Then in build phase roles need to be created in development system and unit testing has to be done by service provider team Test documents need to show to the client and after sign off have to be moved in QA system. Here business core team has to do integration testing and positive and negative testing. Testing scripts and test cases for this need to be provided by implementation partner. Once things are fine the need to take sign off and roles should be moved to pre-production or production.

Finally in UAT some level of testing done by end users and final sign off will be given.

Also need your guidance for role creation approach and assignment to end users.

First master roles to be created and then derived roles as per organizational values. Then composite roles to be created as per SOD matrix.

Now what approach we need to take to assign roles to end users. We also have a GRC Access Control 10.1 is in our landscape.

1. Composite roles should be created sap module wise and then attached to uses..

2. Composite role created by adding all derived roles of different modules required by user in one single composite role and then attached to user.

3 Direct derived roles to be attached to the users

Our Assumptions:

1. If we go with first approach we have a scope to remove the SOD conflicts at role level and make composite role as much as possible risk free and attached to the user. Secondly, if we go with this approach, we can have a scope of removing risk also at user level to fine tune the SOD conflicts and do risk mitigation at user level in exceptional cases.

2.If we go with second approach then we can only remove risk at user level. Secondly number of risk will be too high and confusing. So over all risks would be almost unmanageable. Ultimate result is higher overall risk. Due to this situation there would be no positive use of GRC is possible

3. If we go with third approach then no use of GRC and SOD concept.

As we have a GRC 10.1 access control. As per our assumption if we go with second approach then overall risk is much higher than first approach. More to this risk remediation at will be unmanageable practically.

If we go with third approach it will be practically impossible to manage SOD conflicts and mitigation of risk. Even when user will require an access he has to select himself the role how he will know the technical name of the role .So this approach is also not correct when GRC tool in place.