Access to SM30 in Production

[wayne_villon]

Hi,

We've been audited recently to adhere to Sarbanes-Oxly standard and one of the OAG comments is that no one should have access to SM30 in Production. We started looking into this and if we remove SM30 from the security profiles then Function staff responsible for configuration cannot perform a lot of validation reviews in SAP IMG activities via SPRO. We simply only want display access and we ensure this via S_TABU_DIS with activity type 03 only but once SM30 is remove from their profile they can no longer use SPRO to validate configuration. Does anyone else have this same dilemma?

Thanks,

Wayne Villon (Canadian Broadcasting Corporation)

[Former Member]

Hi,

When we started our implementation 3 years back, we consciously avoided giving SM30 access to people in production. The reason why auditors are very stringent about this is that, this has no control over which table you change. So, once you have SM30 access, you can change almost any table that has table maintenance.

How we avoided it is for all the Z tables, we created our own mini SM30, which essentially does the same thing like SM30, taking a table name and allowing the users either to update or display records. But the big difference is that we created a custom authorization object that takes a table name and an activity as its value. Thus we were able to control which user has which table access and to what action. Although our solution works equally good with standard SAP tables, we didn't take that route.

Config/SAP standard tables are different. We took the conservative approach of transports. You do your changes in DEV, do a thorough test in QAS and then move them to PRD. No config change is allowed to be done directly in production system. Yes, display access to SPRO is given to some functional folks but if that in turn calls SM30 with a change access, then it is not allowed. We try to refresh our QAS system with production system, every now and then, so that we can diagnize most of the problems in QA system itself.

Having said that, we left open the exit strategy, which is ok with the auditors is that, if such access is absolutely needed, the access will be given upon proper approval from the BPOs for <b>one time access</b> only. Upon reviewing/changing whatever, the access is immediately removed(actually the role will be assigned with an expiry date).

You can even try transaction variants, wherein, you will prefill the SM30 initial screen and allow users to go directly to the table. So you need to create that many such transactions as you have the tables/views that are needed to be modified. This way you can avoid letting people access tables that they are not supposed to touch.

Hope this helps,

Srinivas

[Former Member]

Hi Wayne,

Even in our organisation we had the same issue. But we've overcome this problem by creating a Transaction Variant for all those tables that are supposed to be maintained in PRD. These Tcodes should then be attached to the respective user ids who must have access to the table maintenance.

The procedure is simple.

Goto SE93 and create a Transaction variant for SM30.

Give the table name and Update = X in the variants part and activate this.

Having done that, you must then attach this Tcode to the corresponding profiles of the users in PFCG.

Revert back for any further clarifications.

Cheers,

Sam

[wayne_villon]

Thanks for the quick responses guys(Srinivas & Sam). Srinivas did respond on how do functional people validate configuration in production(Either temporary access or creation of SM30 variants with associated Z transactions & more frequent refreshes to QA). Sam it sound like your responding in the same manner but can you possible clarify how your company handles validation of configuration in SPRO?

PS: Have any of you's looked @ ensuring S_TABU_DIS value in display mode only and allow Functional configurators access to SM30 in production but due to S_TABU_DIS activity 03 it's only in display mode. Auditors in general we find automatically say SM30 raises concerns but we believe if we indicate in DISPLAY MODE only we suspect that it would be acceptable. Does anyone possible have any additional comment to this concept?

[Former Member]

Hi Wayne,

We did evaluate that display only access option. But the objection to it, is again the same issue that it does not restrict you to specific tables. So if there are sensitive HR data tables that needs to be confidential, you cannot restrict it through giving display only access to SM30. Auditors take an issue with SE16 for the same reason. You cannot control which table contents they display, once you give this access.

So what auditors suggest or open to discuss is some kind of control mechanism, wherein you document how you control it, how you use it and how you trace it. So what I would like to suggest is to create a custom authorization object as I mentioned in my previous comment, assign the customization tables/views with display access only to users using this authorization object. Even variant transactions does achieve practically the same thing, but you have to explicitly remove SM30 transaction access.

Auditors don't like someone giving access to SM30, SE16, SE38 and even SA38 or SE17 or SE80 kind of transactions. They need you to have controls and traceability. But I did see them make some exceptions for <b>support</b> personnel. Unlike end users, those in system support positions need access to such transactions to diagnose the production problems. But, fixing them should be going through proper change control mechanisms that are in your organization.

Some SPRO tasks have their own transactions that also are technically transaction variants. So you may get away with giving display access to those transactions and display access to your functional support personnel and remove SM30 transaction access.

Heop this helps and if you are satisfied with the answers, please close the post by choosing the "Solved Problem" button that appears next to each response or "Solved on my own" that appears next to your initial post.

Regards,

Srinivas

[Former Member]

Hi Wayne,

Addition to above. In our project, we are loading the data into some transaction via CATTS. In this way we can avoid having change access to SM30 in PRD. and for Config purpose, as Srinivas said above, the config will be done in DEV or QA. and transported to PRD. and display access to SPRO for some functional consultants. and for all others we have firefighter id, which will have a log of the screens and the transactions we have accessed in PRD. In this way auditors will have log of all the users which they have accessed(transactions and the purpose).

Thanks,

Lalitha.

[wayne_villon]

Thanks Srinivas,

You've helped clarify things and yes we're locking down the transaction of concerns the Auditors have to all users in general. I believe the answer that SUPPORT STAFF is the exception is what I was hoping to hear as it becomes near to impossible for our SAP Support Staff to diagnose production issues without having this access.

I really have one final question and this is more of whether our approach is better to give temporary access to these support staff (when needed only) rather then permanent? Please note we've already had resistance from our SUPPORT STAFF for the temporary access solution though as they already currently have permanent access to SM30 in production. The answers of course which I'm sure you know and more then likely have heard in the past is the inconvenience, the lack of trust and the lengthening of time in resolving production related issues as some of the reasons for requiring permanent access!!!

Thanks,

Wayne

[Former Member]

Yes, the approach has to be giving temporary access with proper approvals and paper/electronic trail regarding such temporary grants.

We did face this initial resistance(I am one of the support staff, so I can understand how hard it is to let go such access), but as the production system stabilized and became more predictable, we were glad that the access has been removed.

I don't think you need SM30 to display config as I explained previously. You may need to use one of the strategies either the custom Z authorization object approach or the transaction variants approach. I am sure if you have a fire to put off, your approvals will also come equally faster. So there is no need to worry that this will delay your ability to support.

Regards,

Srinivas

[wayne_villon]

Thank you very much Srinivas for you help!

I'll proceed with closing the message now.