cancel
Showing results for 
Search instead for 
Did you mean: 

Access Control - Assessment of users, roles and their restrictions

RafaMarj
Explorer
0 Kudos
180

Hello there!

Seeking your insights and suggestions please. Currently our client who has 2 businesses, 1 will be sold for the next 3 months temporarily, SAP architecture will be the same. What would be the requirements, restrictions, compliance to ensure that the sold business cannot access the other. In terms of the organizational level, all of the areas are restricted except for the business area, will this cause of risks? or can we stay it the same?

Accepted Solutions (0)

Answers (2)

Answers (2)

olgavlachova
Explorer

Hello @RafaMarj 

I take care about SAP GRC and also SAP Authorizations about 20 years, so I guess I can give you the answer.

Based on info provided - 2 Companies, 1 SAP architecture including SAP GRC Access Control - I would ask:

- Are mentioned businesses separated by organizational values (Company Code, etc.)?

- Does exist SAP Authorization Concept describing SAP roles, their content and who is responsible for?

- Which version of SAP GRC AC are you running?

- Do you have implemented BRM including Access Control Owners and are Role Owners defined?

- And do you have implemented Access Risk Analysis and adjusted SoD matrix?

In general, the base is SAP Authorization Concept designed in right way and followed in SAP roles, then SAP GRC AC set properly to cover SAP roles assignment strictly by approval of GRC Role Approver, UAR is implemented and also SoD matrix is set and reviewed periodically. Also 4-eyes principle is followed by related admins - SAP roles admin/s, SAP GRC admin/s.

If I take the base as set and working smoothly, then SAP roles for "gonna sold" and for "kept" are separated by organizational values and each SAP role has different GRC Role Approver. Then SAP roles for access to "kept" company data can be requested to be assigned to "gonna sold" users but if not approved by defined GRC Role Approver, no access is given. So the responsibility is on GRC Role Approver, this person is recommended to be business user for business roles. I found life saving when is GRC Role Approver a bit experienced business user - familiar with SAP role related process/es, with the content (on t-code level), also understands critical combinations of authorizations, impact of giving access rights and own responsibility for.

You can make the life of GRC Role Approvers easier - for example by creating special Access Risk that contains critical combination of "gonna sold" organizational values and of "kept" ones, moving "gonna sold" users to dedicated User Group and make this field visible in GRC request, disabling "gonna sold" users to be found on Data Source (like CUA, IdM), etc.

There are a lot of possibilities to be used via SAP GRC AC, so only depends on effort you want to spend on and also on your environment. If you are running CUA/IdM, it is easier to manage "gonna sold" users, etc.

In case of any questions don't hesitate to ask.

Have a nice day.

BR, Olga

 

 

RafaMarj
Explorer
0 Kudos

Hi olgavlachova,

I appreciate your prompt detailed response. It really helps me to cope up getting familiarized and in-depth with security concept.
 
- Are mentioned businesses separated by organizational values (Company Code, etc.)? 
  
   This is the one I need to figure out first. But don't know how to. Can you guide me on this?
 
- Does exist SAP Authorization Concept describing SAP roles, their content and who is responsible for?
 
I believe there's one Administrator who handles the Security roles, etc.
 
- Which version of SAP GRC AC are you running?
 
Since I'm new to the project, I don't think their system has GRC. (ECC system)
 
- Do you have implemented BRM including Access Control Owners and are Role Owners defined?
 
      I'm not familiar with BRM, sorry.
 
- And do you have implemented Access Risk Analysis and adjusted SoD matrix?
 
Is it something feasible with ECC system? How does it work?

Thank you.

olgavlachova
Explorer
0 Kudos

Hi RafaMarj,

you're welcome.

To separate existing Legal Units, Locations, etc. by organizational values is best practise and standard because it allows to keep track & control over costs, materials, invoices, salaries, business plans and forecasts, etc. If is something like organizational structure implemented in your ERP, is easy to check. You mentioned ECC SAP system, so if you run t-code SE16 and choose table T001, you'll see all Company Codes created including Company Name/s, address data and other FI values like VAT, Credit Control Area, Fiscal Year variant, Currency, and much more. If is accounting activate, can be seen in table T001B containing Permitted Posting Periods per Company Code. If there is a warehouse with storage location/s defined (virtual, physical, or both), is displayed in table T001L. To check if there are employees at least using HR Organizational Management, choose the table T001P. Plants including details like Sales Organization/s, Purchase Organization/s, shipping point/s are shown in table T001W.

SE16 tables walking conclusion: if these tables are filled by consistent data, is highly possible that same values are used in SAP roles to control an access to these company data. The applied reality is stored in tables AGR_1251, AGR_1252 and other ones.

As the content confuses anyone who is not experienced in SAP Authorizations or pure table data lover, I recommend rather to avoid frustration caused by AGR_* tables and directly ask admin responsible for SAP roles. You mentioned that there should be one, so this is the best way. I can say that if newcomer asks me for an introduction to SAP Authorization Concept and/or SAP roles, I'm pleased to can show off my work and share the knowledge. I think I'm not the only one who loves own job :-))

I can also say that SAP Authorizations admin knows well who is involved in SAP GRC, if GRC installed. And these experts should be able to answer your questions and doubts about compliance and access restrictions for "gonna sold". As SAP roles admins cooperate in most SAP related projects, it would be good for you to meet them and ask. It may help you not only only with this topic but also with future ones.

I wish you the good and success in your new job.

Best regards, Olga

 

Ra32
Discoverer
0 Kudos

Hello RafaMarj,

in my opinion there is a significant risk involved in having another company on the same system.

For example it ist probably still possible to create an access request involving a role of the other company which would grant authorizations to a system they shouldn't have access to. Even if the normal user isn't able to request these roles there certainly has to be at least one administrator who has this option.

Furthermore this constellation imposes that the different systems are sharing the same IT-environment which leads to more risks regarding hacking, mistakes, firewall problems and so on.

I would not recommend this approach. If you still chose to use it I would at least speak with your SAP Basis team, IT-infrastructe team and legal department.

Regards

RafaMarj
Explorer
0 Kudos

Hi Ra32,

Thank you for your inputs.

I believe that there is only 1 SAP Security Person who manages the users and roles, etc. And supposed to be that once the transition of the other company is commenced, the users will retain (unless the resource will resign).

On the second part, what I currently evaluating is to see the Organizational Structure of the roles/users. If this will suffice the access security on both businesses. Is this something feasible? Or any suggestions will much appreciate

Ra32
Discoverer
0 Kudos

Hello RafaMarj,

unfortunately I have no experience with such a constellation. Therefore I can't really recommend anything to you.
I only mentioned some risks I came up with.

Regards