Security Design

[Former Member]

Dear Gurus,

I am looking for some inputs or suggestions regarding Security Design Approach. What kind of security strategy to follow with Just One Company Code and two Business areas. There is no SOX or SOD requirements at out place (being a small company). I am following the role based approach but was wondering if I should take in consideration the Master/Derived roles or hierarchial approach.

Thanks

[Former Member]

i would say go for master and derived role concept it will always help you in the furture along with the compnay growth where more plants/sales org etc come up

Hier is for HR structural authorization you cannot use then in SD/WM etc

[Former Member]

If you are planning some major acquisitions and diversity in your production locations and sales organizations, then derived roles <i>might</i> be an option for a <i> currently</i> "Just One Company Code" system... but your business areas and other org elements will be forced to some extent to have the same business processes /or your roles will provide too much access for the others when one of them wants something special. You will become unflexible and over time the differences will destroy your concept very easily.

Derived roles are only helpfull initially for small roles (or individual tasks) which truely are exactly the same (except for the org or other element of a common object).

I would create a common set of roles which contains the required ....._BUK authorizations etc for the various roles.

Then create a second set of roles for the functions in the different business areas and add the differenciated org elements to them. Make sure that the transaction you select actually also use these authorizations...

Also, just because FB03 (for example) checks something, this does not mean that you have to give that something to the user. You can turn the checks OFF for the common transactions and leave them ON (or turn them ON) for the differentiated transactions. When the user then navigates via the menu to display (or change) the original document or back to the finance document, then they have already previously been limited to that which they could have selected in the first place. Search for SU24 in the forum for more information. There is a good contribution by Frank Buchholz about ease of navigation.

You can also merge the common role into the differentiated roles if you want and let them evolve as your business processes and acquisitions do (something you would not be able to do with derived roles).

"<i>There is no SOX or SOD requirements at our place</i>

Consider yourself blessed.

[Former Member]

Julius,

I was wondering if you can elaborate more on your approach regarding

"I would create a common set of roles which contains the required ....._BUK authorizations etc for the various roles.

Then create a second set of roles for the functions in the different business areas and add the differenciated org elements to them. Make sure that the transaction you select actually also use these authorizations..."

I understand your point regarding the Master and derived roles are really benenificial when the process are the same across org levels........

It could be helpful if anybody can provide some links regarding different Security Design Strategies for ECC modules.

[Former Member]

Hello Raj,

The point was that using derived roles for a One Company Code client, does not make sense for the BUKRS (company code field).

For the others (e.g. Business Area, etc), it depends, as you state, on how consistent your business processes are between the different org levels.

If they are different, or will grow appart over time, then derived roles can make you inflexible.

At least, that is what I have observed.

Looking back on the statement "one role for BUKRS and one role for the rest", I must confess that I do not necessarily agree with that. Perhaps the intention was to make the derived role smaller and easier to manage, but on the other hand a role should be able to survive on it's own.

Kind regards,

Julius

[Former Member]

Raj,

This build method referred to by Julius is often known as value, controlling or enabler role method. What you have is 1 main transactional role containing all the transactions & auth objects etc as you would per a standard build.

You then create a separate role with manually added auth objects that contain all the auth objects that are relevant for restriction. You then disable those objects in the transactional role.

This way you have 2 roles, one providing transactional content & the other providing all your restrictions.

One of the perceived benefits is that you only have 1 role containing restriction data and this can be applied to to all users. You then give them different transactional roles depending on what transactions they need etc.

I feel it's fair to comment that this method features in a disproportionate number of terrible security builds!

so far so good.....

Downsides to this are:

Increased complexity: This method fails the "hit by bus" test. If you got hit by a bus and a security admin had to come in off the street & work with it, there would be a steep learning curve.

Reduced security: Security is based on 2 levels, S_TCODE & object level. If you are creating a single value role (or even a few of them) they are going to contain more auth objects than are needed for the respective transactional roles. Given that it is reasonably easy to move around within some transactions without invoking extra S_TCODE checks, this does, in some cases, reduce your security from a 2 level setup to 1 level at best.

SOD analysis: Doesn't appear to be the case for you but it makes analysis and reporting at role level more complex. Even if you are not reporting for SoD's, you still need to take this into account when you want to report on roles that have access to tcode & auth object combinations.

Breaking SAP security setup: When you take this approach you <i>may</i> be breaking the link between PFCG and SU24. It all depends on how you do it.

This approach requires a lot of discipline and a high level of documentation to avoid getting it into a mess. If I recall correctly the securinfo tool works in this way but automates the process and therefore provides a high level of control.

Without knowing the exact requirements of your company it's hard to make a recommendation, however based on what you have said I would likely go for a completely standard build, ignoring any composite or derived roles (assuming that you are going to stick with 1 comp code & 2 business areas). Add your transactions in the role menu and maintain the auths in the auths tab. Update SU24 to ensure that all transactions are linked to the objects that are required to run that transaction.

As you only have 1 comp code and 2 business areas, at most you are going to have 2 variants of a role. If you think you will get more or you need to restrict at another level then derived roles may be a good answer.

Build at the highest level that is possible. In that, I mean what is the point in building 20 tasks that make up an Accountant role if you can build 2 that will do the job e.g. 1 display role & 1 functional role. Standardise access based on a risk based approach to reduce job variants.

Get your display roles sorted, again based on risk. Is there any problem assigning a display role per function? e.g. Finance, Manufacturing, Purchasing etc. It all depends on your companies attitude to risk.

If you have a small company, benefits of being able to re-use the tasks for several different roles are reduced. This (build at a higher level) does take more effort in setting up as most implementation methodologies are geared towards providing info at task or sub-process level.

Once in place & stable, this sort of build (in my opinion) will be easier to maintain and easier to assign to users.

All of the above are my opinions only & there are many ways of doing things. If you do it in a controlled manner you can use pretty much any method and it will work well if you spend time considering the impact on meeting control requirements, future changes, user management, reporting etc.

Message was edited by:

Alex Ayers

(Message took so long to type that I saw Julius' revised opinion)

[Former Member]

Hi Alex,

I think what I was referring to way back when was that a smaller derived role has a better chance of surviving than a big one, hence the lure of having a bigger first role to make the second derived one smaller.

Looks as if I took the bait

Fair comments.

Cheers,

Julius

[Former Member]

Hi Julius,

I know exactly what you mean & have been very tempted to do it a few times myself!

I like the concept but unfortunately have seen it go wrong so many times.

Interestingly where (in my opinion) it works really well is when you can automate the user provisioning. I've been to a few audit clients where they have done this & it's a really elegant solution. So many others have been complete disasters though & rebuilding them has been challenging

Cheers

Alex

[Former Member]

Thanks Julius and Alex...............

I happen to be working on a Solution which would not only involve different Company Codes and Business Areas but Different Org levels based on different countries will be involved. Added to the complexity would be SOX Compliance............As far as Risk are concerned that is still needs to be determined along with how the processes would differ in different countries.

I believe that Master or Derived role be a fair way to go provided the processes will be the same...............I believe Value, Controlling method might get too complicated as Alex pointed out

“. Is there any problem assigning a display role per function? e.g. Finance, Manufacturing, Purchasing etc. It all depends on your company’s attitude to risk.”

As of now I am not sure about the requirements about the display roles; however there will be separate Org levels involve for manufacturing and Purchasing for each country.

[Former Member]

Hi Raj,

You may get lucky and the company decides that users can see data across companies. If, however they want to restrict it to their own company then no problem in using parent/derived concept as you would do with the other roles.

p.s. if you need to have different restrictions at object level for a set of roles then derived concept will not work unless you convert them to org levels. This is the main drawback with this method. It would be nice to see the concept extended so during definition of the parent role, you could select what fields shouldn't inherit any data from a parent role.

[Former Member]

Another bugger is the "Universal Role for all users".

[Former Member]

>> Is there any problem assigning a display role per function?

Not necessarily. But the problem is that display transactions are also change capable if the user is getting authorizations for change from a different role.

Because they are in different roles (perhaps many... - e.g. roles defined at a task level), the available admin analysis and audit tools will often not spot the combination of the roles for an individual user.

A simple example is FB03 (display G/L line item). If the user has strong F_BKPF* authorizations in another role, then the system will let them reverse your G/L entries.

You won't see that in RSUSR070 when looking for S_TCODE = FB02, F_BKPF_KOA = S / 02 etc.

You might see it in RSUSR002 and will get the user as a result, but when you find 10+ profiles for roles from which each (or all) of the authorizations could be originating, then you will get tired of trying to figure out what is going on, and what can be done to prevent it, or who has which combination.

Cheers,

Julius

[Former Member]

was the topic I refered to.

[Former Member]

I like to stick to the "KISS" principle in security design - "keep it simple ...". I would not recommend the master / derived approach since you indicated that it is a small company and you are unlikely to need to create derived roles. Maintaining them will be more effort than they are worth if your requirements do not warrant it. If you mean "hierarchial" to mean "organizational" in the sense that the roles will map to the business organization then I would recommend this approach. For example, accounts payable department could be one role.

Regards,

JC

[Former Member]

Sorry, I meant Organizational Security not Hierarchy. Managemeent still doesn't have any idea whether to go for Org. Security or not. I think the final decision will be pushed on me.