09-11-2014 12:13 PM
Dear security gurus.
I have 2 business roles in company and 2 subsidiaries under HQ.
Each company have
- Accout clerk
- Account manager
HQ's clerk&manager: be able to check all company's data.
Subsidiary's clerk&manager: be able to check ONLY their own company's data
In this case, I have to create these 6 roles, because
company code restriction can be controled only by role, not user.
Am I correct?
1.HQ's manager(Company code: *)
2.HQ's clerk(Company code: *)
3.Subsidiary1's clerk(Company code: 1)
4.Subsidiary1's manager(Company code: 1)
5.Subsidiary2's clerk(Company code: 2)
6.Subsidiary2's manager(Company code: 2)
Yoshi
10-15-2014 1:48 PM
There is another approach you can consider, Enabler Role based.
1. Create roles including only transactions and all associated authorizations. Keep org levels blank (comp code in your case). So you need to create 2 roles: CLERK and MANAEGR.
2. Create enabler roles for each company codes. These roles will not have any tcode. Only authorization objects related to org levels (company code) would be added to this role. So you need to create 2 enabler roles: COMPCODE1 and COMPCODE2.
Now you can assign appropriate combinations to any user. Ex, clerk of company 1 would be assigned CLERK and COMPCODE1 roles.
HQ managers and clerk would get their respective tcode basd role and multiple enabler roles.
This approach would be much easier to handle. As if there is any new position, you would just have to create a tcode based role. If there is a new company code, you would just need to create enabler role.
In enabler roles, you can also consider other finance related org levels apart from company code.
Regards,
Nitesh.
09-12-2014 9:45 AM
Hi, your assumption and solution is correct. You restrict at role level and assign those roles as appropriate to grant the access.
09-12-2014 10:15 AM
Hi,
I'd never give business access to all companies.
My proposal:
1.HQ's manager(Company code: 1, 2)
2.HQ's clerk(Company code: 1, 2)
3.Subsidiary1's clerk(Company code: 1)
4.Subsidiary1's manager(Company code: 1)
5.Subsidiary2's clerk(Company code: 2)
6.Subsidiary2's manager(Company code: 2)
You could also assign HQ both roles of subsidiaries:
1.HQ's manager (MGR-01, MGR-02)
2.HQ's clerk (CL-01, CL-02)
3.Subsidiary1's clerk (CL-01
4.Subsidiary1's manager (MGR-01)
5.Subsidiary2's clerk (CL-02)
6.Subsidiary2's manager (MGR-02)
That way, you need only four roles
MGR-01
MGR-02
CL-01
CL-02
- more effort with assigning the roles
- saves a little effort on the roles management side
- works only if needed transactions are exactly the same (Subsidiary vs HQ).
greetings
Alexander Walkenhorst
09-12-2014 10:50 AM
I agree. Also remember to turn SSM_CUST-DELETE_DOUBLE_TCODES to 'YES' so that the end users notices not that there are multiple role menus with duplicates being condensed into one.
Cheers,
Julius
10-15-2014 1:48 PM
There is another approach you can consider, Enabler Role based.
1. Create roles including only transactions and all associated authorizations. Keep org levels blank (comp code in your case). So you need to create 2 roles: CLERK and MANAEGR.
2. Create enabler roles for each company codes. These roles will not have any tcode. Only authorization objects related to org levels (company code) would be added to this role. So you need to create 2 enabler roles: COMPCODE1 and COMPCODE2.
Now you can assign appropriate combinations to any user. Ex, clerk of company 1 would be assigned CLERK and COMPCODE1 roles.
HQ managers and clerk would get their respective tcode basd role and multiple enabler roles.
This approach would be much easier to handle. As if there is any new position, you would just have to create a tcode based role. If there is a new company code, you would just need to create enabler role.
In enabler roles, you can also consider other finance related org levels apart from company code.
Regards,
Nitesh.
10-15-2014 2:44 PM
Hi Nitesh,
How do you deal with the challenge of COMPCODE1 role containing much more access than the user requires?
Cheers
10-15-2014 6:43 PM
Do not do this!
Alex already raised one point. Goodluck with SU25
if you search this space you will find quite a detailed discussion on the use of theae roles.
10-16-2014 5:58 AM
Hi Alex,
The role COMPCODE1 or 2 would provide only org level access. You can further create 2 roles: Display and Edit for each company codes.
I agree these roles would contains much more objects then required for one activity. But if you carefully create roles CLERK and MANAGER, users will have limited access only.
We have used this enabler role approach for 2 clients and both clients were 100% SOX compliant from roles perspective. Even I have seen feedback from some forums that business prefers enabler roles concept.
Regards,
Nitesh
10-16-2014 8:36 AM
Hi Nitesh,
Herein lies the problem for me. Putting aside technical challenges of this approach it violates one of the most basic principles of infosec which is the principle of least privilege. Adding in a load of extra auth objects that are not required violates that. I'll freely admit that some companies do like it, some of them even make it work but I venture that they are in a minority judging by the number of historical projects to fix the mess caused by these approaches.
It's also worth considering that typical controls for SOX 404 are subjective and are geared towards what can measured rather than providing a full coverage of risk. Currently most organisation's ITGC's are missing some pretty important stuff!
Cheers