So this approach is also not correct when GRC tool in place. Even when user will require an access he has to select himself the role how he will know the technical name of the role. If we go with third approach it will be practically impossible to manage SOD conflicts and mitigation of risk. More to this risk remediation at will be unmanageable practically. As per our assumption if we go with second approach then overall risk is much higher than first approach. If we go with third approach then no use of GRC and SOD concept.Īs we have a GRC 10.1 access control. Due to this situation there would be no positive use of GRC is possibleģ. Unify enterprise risk and control activities on a common technology platform, leveraging continuous monitoring for agile decision-making. So over all risks would be almost unmanageable. Automate and manage risks, controls, identities, cyber threats, and international trade across the enterprise with embedded analytics and artificial intelligence. Secondly number of risk will be too high and confusing. 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.Ģ.If we go with second approach then we can only remove risk at user level.
#Sap ecc security free
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. Composite role created by adding all derived roles of different modules required by user in one single composite role and then attached to user.ģ Direct derived roles to be attached to the usersġ. Composite roles should be created sap module wise and then attached to uses.Ģ. We also have a GRC Access Control 10.1 is in our landscape.ġ. Now what approach we need to take to assign roles to end users. Then composite roles to be created as per SOD matrix. Once things are fine the need to take sign off and roles should be moved to pre-production or production.įinally in UAT some level of testing done by end users and final sign off will be given.Īlso need your guidance for role creation approach and assignment to end users.įirst master roles to be created and then derived roles as per organizational values.
![sap ecc security sap ecc security](https://www.ibm.com/blogs/security-identity-access/wp-content/uploads/2018/08/SAP-Authzns-for-a-Role.png)
Testing scripts and test cases for this need to be provided by implementation partner.
![sap ecc security sap ecc security](https://images.squarespace-cdn.com/content/v1/5ce68bf822118d0001c01939/1558651680269-8FW3D52L4WEJDGEHN1NO/scc_overview_910709.png)
Here business core team has to do integration testing and positive and negative testing. 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. After that authorization matrix will be build. Once SOD matrix is decided then templates will be filled with job descriptions.
![sap ecc security sap ecc security](https://nttdata-solutions.com/wp-content/usermedia/Hana-Security-Part-2.jpg)
Īpproach in brief for security implementation for SAP ECCĪs a first step service provider has to do workshop to make client understand the role concepts. Experience includes analysis, development, and maintenance of SAP Security in SAP R/3 (4.7), ECC (6.0/5.0), SAP BW(3.0, 3.5),BI 7.0,SCM ,CRM Experienced in 3. Need your help / guidance to know the correct way to implement security for SAP ECC 6.0.