Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

SAP Security - create 2 completely separate companies on 1 instance

Former Member
0 Kudos

I am consulting with a privately held company and they want to spin off part of the business to create a public company.  Will we need to set up a separate client to house the public company data/processing  or is there any way at all to secure each company in SAP so they cannot see the other companies data?  To complicate this, they want to share master data.  I've been researching and cannot find a way to secure the data so that I am positive there is a 'brick wall' between the 2 entities.  Any help/directions/suggestions are greatly appreciated.  THANKS!

1 ACCEPTED SOLUTION

martin_voros
Active Contributor

Hi Cheryl,

I've seen something like this before but my memory is hazy. It was a time of un-bundling utility companies. My understanding is that you would like to re-use as much as possible. You could try to keep using one client and try to use standard authorization objects to separate users. The success of this approach depends on how much separate data should be. Unfortunately, the enabler roles are not going to improve your situation. For example we can agree that it won't be a big task to separate GL between two companies. This is easily supported by authorization model of FI module. But how are you going to protect against users with more powerful authorizations such as SE16?  I think the biggest issue will be power users. You will realize that there are many spots where you will have leaks of data between two companies (e.g. search helps). Sometimes these leaks can be resolved with standard authorizations, sometimes you will have to add additional checks.So it depends on level of separation between those 2 companies. But it's possible that cost of properly separating these 2 companies will be higher than loss by not sharing data.

Other approach of having a separate client for each company will give you much better separation but you will lose on sharing side. You will just share code and some basic stuff.

Cheers

7 REPLIES 7

Former Member
0 Kudos

There is a org level authorization object BUKRS which control the company code access.

0 Kudos

I am under the impression BUKRS is enough to completely separate the 2 entities to guarantee the data will not somehow be shared. (or some prying users does not see data they should not) I should also add that the security design is the 'enabler'  roles so a bit more complicated.  This new set up will need to pass outside audits by stock exchange.......

0 Kudos

There is no doubt in my mind that enabler roles and expecting $BUKRS to keep the two entities with common master data etc apart is going to backfire on you beyond all imaginable boundaries...

Cheers,

Julius

0 Kudos

meant to say that BUKRS is NOT enough

0 Kudos

Julius -- any idea how to make this work or will we need 2 clients? 

martin_voros
Active Contributor

Hi Cheryl,

I've seen something like this before but my memory is hazy. It was a time of un-bundling utility companies. My understanding is that you would like to re-use as much as possible. You could try to keep using one client and try to use standard authorization objects to separate users. The success of this approach depends on how much separate data should be. Unfortunately, the enabler roles are not going to improve your situation. For example we can agree that it won't be a big task to separate GL between two companies. This is easily supported by authorization model of FI module. But how are you going to protect against users with more powerful authorizations such as SE16?  I think the biggest issue will be power users. You will realize that there are many spots where you will have leaks of data between two companies (e.g. search helps). Sometimes these leaks can be resolved with standard authorizations, sometimes you will have to add additional checks.So it depends on level of separation between those 2 companies. But it's possible that cost of properly separating these 2 companies will be higher than loss by not sharing data.

Other approach of having a separate client for each company will give you much better separation but you will lose on sharing side. You will just share code and some basic stuff.

Cheers

Former Member
0 Kudos

Hi Cheryl,

In general the standard organisational data model will allow adequate legal separation of data.

There are plenty of companies operating European Principle Company/Tolling models where each company code & subset of organisational data belongs to a different legal entity and various states tax law mandates that the data is completely separated.

There are some areas (queries, quick viewer, table display, access to various function modules, various manufacturing transactions) where additional work is required but it is achievable.

I don't want to open up the topic of enabler role design but due to the "big bucket" nature of this approach, it is, in my experience of doing exactly these sorts of projects, more likely to cause you grief than a very tight & focussed design based on principles of least privilege and only granting the specific access required to support the transaction codes that users require.

Good luck!

p.s. I think the service that Martin is talking about is SAP SLO (System Landscape Optimisation) where they do all kinds of neat carve outs, separations etc.  I have yet to work with an SLO team that is anything other than excellent, even if they have said previously that sorting the security stuff is "too hard".