Frustrated. Need Advice on SAP Security Implementation!!!

[Former Member]

I'm very frustrated with my latest project and I would really appreciate your feedback.

I recently joined a company that's implementing SAP. They are already in the realization phase and will soon enter the final preparation stage. I was brought in to implement SAP Security. I was provided with a compiled list of roles and tcodes based on the blueprints from the teams and this was my starting point.

I wanted to do a presentation with the teams so that we all know what my expectations/requirements are from them and vice versa. In preparation for this, I gathered their processes from their blueprints. I wanted them to break each processes into detailed activities/tasks/functions. From there, they can identify the tcodes and then the roles. I also wanted to do this approach because the company is following SOX regulations. I showed this to my team lead and the PM and the PM adviced me not to go with this strategy because there would be too much work involved. I wanted this approach because I also wanted to do the SOD but I was told not to do it because it would only confused them. He just wanted to work on polishing the list of roles and tcodes.

Some teams leads are all experienced people while other teams are not because they are working with an employee from the company. Kinda like a partnership, 1 is a consultant while the other is a team lead from the company. Which I believe is normal practice so that there is knowledge transfer.

So I had my presentation and I found out that most of the team leads have not seen this compilation of roles and tcodes. I also found out that even though they are already in the realization stage, majority of the teams have no idea what roles to give nor do they know who to give it to. I also asked for the org chart from the HR team but I was told that they still don't have it and cannot give it to me. They even asked me why I need it. They also informed me that HR structural authorizations are not going to be implemented and yet nobody can give me a damn good reason why. All they tell me is that because they don't need it.

So as you can see, I'm not getting the cooperation/support I need to be able to do my job properly. How can I when every strategy I wanted to do is being turned down? What should I do? Really need your advice on how to proceed. Your inputs are highly appreciated.

Thanks in advance!

[Former Member]

Liz

To start with, i do feel sorry for you getting so little help, especially form management. But I must admit that were I worked this is normal behavior.

What you should try to point out:

1 roles are to be owned by the functional teams, so THEY must submit to you: Roles to TRX broken up to such roles that the single should be ready to be used across the whole company without having to split it up to a smaller role. The basic goal in this must be that a TRX will not be In more than one single role. Be aware that however good the functional consultants will be, there are always situations possible that the roles need to be split up later and that you will hopefully discover this before having build a lot of derived, but be prepared to change all the affected the singles at that moment, or you will end up with a great mess.

2 SoD is NOT your problem but the companies management problem, so tell them that you are helping management when creating an SoD matrix. But be as happy to end the job without them having one if they do not feel the need for it.

As a general remark it is the functional consultants together with the business experts that have the knowledge to create roles as a collection of TRX and define the restrictions needed in every TRX form a functional point of view, your responsibility lies in the translation of the functional requirement into a technical design, so garbage in -> garbage out.

And it is also the same people that should have the process knowledge to create a company specific SoD matrix, but responsibility for that lies in the finance controlling department. The only thing you can do here is facilitate the design and apply the rules when doing role mapping.

Hope this helps, basically it is just to bring the message across to the right people. As none of mentioned points is your responsibility

[Former Member]

Sorry to hear of your frustration.

On the brighter side, if your project does not have too many self developments, customer enhancements, user exits, then it might be possible to get hold of some process models or industry best practice or the likes which includes the tcodes in the process. Then match then to those which you have been given and pass the difference back to the functional consultants as something to think about (if you think there is sense in that).

Of course, if you notice something which is excessive or can be improved in the choice of transactions (for example, everyone gets FB01), then you should point this out to them and explain the reasons.

Kind regards,

Julius

[Former Member]

Hi Litz,

Lots of good info from Auke and Julius.

Unfortunately this is a very common situation. There are a number of approaches to getting the func teams to do their job but the one Auke has suggested is simple and effective in your situation.

Something which I often find useful is to get Internal Audit or Risk management involved. Application security is a bit thing for them and they can apply useful pressure at the top level of management. If you are putting in SAP, your external auditors will look at it very carefully in the year it goes live. If SOX has to be met then there will be detailed guidelines that you have to meet covering things like change management, application security (passwords etc) and segregation of duties. There is no excuse not to do this prior to golive on a greenfield implementation.

Good luck! Many of us have been there too

[Former Member]

Julius, Auke and Alex,

Im sure everyone would agree that the advice you guys offer is more than valuable. Thank you for that.

I myself have been encountering the same situation that Litz is facing except for that in my case the Management is very co-operative (and trust me, this helps a lot). My problem is that neither me nor my Management know what access needs to be given to Consultants or IT Staff after GoLive or even now.The Functional Consultants "don't have the time" to tell me what Tcodes they need access to, and they insist that they should have sap_all, and I have no idea what access they SHOULD have.

I was going to post another thread for my questions but I guess there are already too many which address the same issue. These threads did give me a good insight on how SAP Security should be managed, and I was able to get some of it chalked out. I have a few questions though, which I wasn't too sure about even after reading through the countless threads.

Most consultants in my company had sap_all in QA since no one knew what they should be have and often had we noticed that they would be playing with the Basis Tcodes. Now knowing what they have been doing in QA, I do not want to give them sap_all in Prod (although they insisted) at any cost. So, I made a role (z:sap_all), copied sap_all, disabled Basis Tcodes and assigned it to them. Then I kept adding Tcodes one by one on request basis.

We haven't gone Live (they say that we are still in testing phase since the final cutover is due in the next few weeks) yet and I know that this cannot work after Go-Live since z:sap_all has Tcodes like SE38, AL11, SM50 etc in Prod. They say that they need these to do processing and it is okay to give it to them since we haven't gone live. I would also like to mention that my company is trying to get SOX compliant and needs these things in place.

I have been entrusted a BIG responsiblity and am trying my best to live up to the expectations and I am relying yon you guys to help me out.All the Business Roles are in place, and its just the IT roles that I'm worried about.

So, my questions are

1. Until how long is it okay for Functional Consultants to have this kind of access in Prod ?

2. After we Go-Live, would a display only role for all functional Tcodes suffice for them ? Or should they have Basis Tcodes too ? If yes, which ones (Im asking this because I know that it should be minimal)

3. I have been to told to create an "IT-Support role" by the Manager of the Implementation Partner for after GoLive. But he has no idea what T-codes it should have or what it does. Any ideas on this ?

4. I have read about the "firefighting role". Im guessing that the IT Support Role is the same as this. But what exactly does the firefighting role have? And in what situations is it assigned?

5. How important is the period before the final Cutover important as far as SOX compliance goes?

A little enlightenment on the common issues encountered after Go Live would also help me assess the situation a lot better.

I hope Im not asking too much of your time here. Thank you again guys !! Appreciate it !

Kunal

[jurjen_heeck]

A quicky for you:

Consultants officially have no business at all in PRD. Its harsh but often true. Mostly they should be able to help the endusers in their field of speciality if they have the same authorizations as these endusers. (and I even consider that risky as a consultant shouldn't touch any data in a production system unless they're hired to do so, at which point they become...... end users!)

Best try to work out a procedure to give stuff like SAP_ALL or your firefighter role on a very temporary basis, like no more than two hours. Building special consultant roles for PRD is overkill in my opinion. You may challenge the consultants by telling them they'll end up with enduser roles unless they tell you what they need.

As for the techies, walk through the sap standard roles with them. Those will give a sound basis. Opposed to the modules, in SAP basis the delivered roles are very usable. Copy the ones you need to your own naming convention and your fine.

Same SAP_ALL/firefighter procedure applies here.

Jurjen

[Former Member]

>

> 1. Until how long is it okay for Functional Consultants to have this kind of access in Prod ?

It stops when cutover finishes (even then there is a risk)

> 2. After we Go-Live, would a display only role for all functional Tcodes suffice for them ? Or should they have Basis Tcodes too ? If yes, which ones (Im asking this because I know that it should be minimal)

They don't need Basis tcodes, maybe SE16 but certainly not SE/SA38. Better still follow Jurjens advice

> 3. I have been to told to create an "IT-Support role" by the Manager of the Implementation Partner for after GoLive. But he has no idea what T-codes it should have or what it does. Any ideas on this ?

This could be many things, get him to narrow it down. If he or the func team say they don't have time then tell them they won't have the access. They will find time, it is part of their job.

> 4. I have read about the "firefighting role". Im guessing that the IT Support Role is the same as this. But what exactly does the firefighting role have? And in what situations is it assigned?

Firefighting roles are generally extended access roles which can be assigned to users in an emergency situation such as some config needed is prod (not all config is transportable, often known as red book entry). Often an role with all functional access is used for this, though if you can break it down further then that is great

> 5. How important is the period before the final Cutover important as far as SOX compliance goes?

This depends on who you talk to. The majority of projects with SOX which I have worked at have only fallen under the remit of SOX at the point of golive. It can be argued that any data which is converted prior to golive and has a SOX impact should be controlled adequately.

> A little enlightenment on the common issues encountered after Go Live would also help me assess the situation a lot better.

Usual issues are users having problems with printers and not being mapped to correct roles. If you go live on a Monday then expect problems to become worse on Thursday/Friday. Set expectations that security will have a higher volume of tickets than the other areas.

Hope that helps!

[Former Member]

Thank you again. I guess accruing points doesn't mean anything to you guys !! But I wish I could award them here

Guess I should have had opened a new thread

[Former Member]

>

> Guess I should have had opened a new thread

No, please! (and use the search)

[Former Member]

Hi,

U r right Kunal.Its quite interesting to see ALEX answers for ur questions.Few of my doubts also cleared for me.

Liz, thanks for starting this thread.Hope ur frustration will come to an end.Godd luck..

Rgds,

Gadde.

[Former Member]

Although said before: NO ONE can claim they have no time for developing a role for themselves, This is a part of everyones job. And your position should be clear to everyone: if they cannot tell you what TRX they need, they will probably also not know how to use them so that just not assign these TRX!

Sounds like a pretty inexperiencd team you have to work with, it sometimes helps if you tell them to contact collueges with experience to come up with a list of TRX, especially when you do it in a meeting where every one is present!!!!!!

And finally YES only people that were assigned business tasks in the process design may have Business TRX , normally that is none of the consultants so they should ONLY be allowed view access.

If they claim that they do need BUSINESS TRX ask them to present a document in which they are assigend enduser tasks and/or positions!!!

Experienced consultants will Never ask this, as they know that they should only guide the endusers in using SAP and not take over the enduser tasks,

[Former Member]

>

> Although said before: NO ONE can claim they have no time for developing a role for themselves, This is a part of everyones job. And your position should be clear to everyone: if they cannot tell you what TRX they need, they will probably also not know how to use them so that just not assign these TRX!

> Sounds like a pretty inexperiencd team you have to work with, it sometimes helps if you tell them to contact collueges with experience to come up with a list of TRX, especially when you do it in a meeting where every one is present!!!!!!

> And finally YES only people that were assigned business tasks in the process design may have Business TRX , normally that is none of the consultants so they should ONLY be allowed view access.

> If they claim that they do need BUSINESS TRX ask them to present a document in which they are assigend enduser tasks and/or positions!!!

> Experienced consultants will Never ask this, as they know that they should only guide the endusers in using SAP and not take over the enduser tasks,

spot on.

[Former Member]

Hello Lits

in reply to your problme with SAP_ALL and those questions, Kunal had asked earlier, here a small summary of our companies expericends dating already from the StoneAge of R.2:

Already then, we had analyzed and evaluated necessary objects and transaction codes and created some 40 different single roles.

e.g.

IDoc: Control, Monitoring, Partner profile, Port description

Calendar maintenance: all authorizations

Customizing: all modules incl. Debug

Depending on identified IT user types:

- Business Application Analyst (BAA)

- Business Application Manager (BAM)

- Business Customizing

- Development

- User Administration

- User Helpdesk

- Consultants

- Security administration

a functional composite role with several applicable single roles had been created.

By Standard, a consultant receives three roles:

1. consultant role

Basis: Standard authorizations for all IT users

Customizing: all modules

LSMW: Transaction and Activity

SAPoffice: all authorizations

Authorisation for Transport Request generation

2. Business Application Analyst role

AS:BA0:00000 Basis: ext. auth. for IT users (background jobs, batch input)

Basis: Standard authorizations for all IT users

LSMW: Transaction and Activity

SAPoffice: all authorizations

SAP Queries: all authorizations

Basis : Standard search tools for authorizations - Repository

WorkFlow Development

*3. Summary of all authorisation given to our end users in one so-called Expert role.

However, with SOX compliance to be up and running soon, we shall use their normal userid with Overall Display role and - per every single consultant - a FireFighterID with the Consultant, BAA role and the Expert role.

• SAP_ALL*

is still allowed and necessary - but currently only for SAPOSS and some Communication users. For SOX, we shall create a FireFighterID.

hope this can put some light into the discussion

Best regards

Kurt