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: 

SM30/SM31 and SE16 access in Production systems - Confusion

Former Member
0 Kudos

Hi Security Experts,

Could any one give some information why SE16 or Sm30/SM31 access should not be granted directly in production systems even if its for a custom tables which are assigned to authorisation groups?

I have been going through lot of forums where every one says access to tcodes should be restricted or access need to provided in alternate way but i could not see the clear information on why this is should not be granted?

I can think of risk providing to standard table authorisation groups but i don't understand the reason why custom table access via SM30/Sm31/Se16 should be restricted?

Could any one explain the implications of granting the access directly, if possible please provide information from audit point of view.

In our company there are many users who have got access to SM30/Sm31 to maintain z* tables which are assigned to authorisation groups, is this a security risk?

Please shed some light on this. Your information is much helpful in clearing my doubts and is much appreciated.

Thanks,

Sandhya

17 REPLIES 17

Former Member
0 Kudos

Hi Sandhya

Access to these tcodes with in controlled way it is not issue.

What I mean you have to give access to these tcodes by explicitly restricting the table authorizations groups in S_TABU_DIS.

If you maintained * then users must have all table access it is a biggest threat.

And with regards to SM30/SM31 access it is very sensitive tcode which gives access to cross client table changes also, so you must be sure while building the roles maintain explicit values in the authorization objects such as authorization groups to your Z* tables also.

yes, it is a big audit finding any SAP PFCG role having S_TABU_DIS table group = *.

Ragards

Hari

0 Kudos

> yes, it is a big audit finding any SAP PFCG role having S_TABU_DIS table group = *.

> Ragards

> Hari

Hi Hari,

It is not usually a big (High rating) audit finding unless paired with SM30 or similar.

0 Kudos

Yes, but that is the error of the auditor...

The main problem with table browsing is that you have almost no org. level control within the table (group) and if you forget it once in the view then &NC& is out with change and display and you will never be able to reign it in again (at least not without pain...

Latest when you want to perform table / view comparisons then it is open.

Transaction code access for SAPGUI end users is only cosmetics.

More important is the correct transaction in the menu which proposes the correct authorization IF a table is to be accessed directly.

To find and / or authorize them all you need to control the front end.

SE16, Sm30 etc.. as front end means you want lots of help desk calls and cannot control the proposals.

Cheers,

Julius

0 Kudos

Hi Alex

if you dont have control over the S_TABU_DIS then any user can access HR tables or any tables of highly confidential data and pass it to ...

as per my experience it is a threat

Regards

Hari

0 Kudos

Hi Hari,

I don't disagree that this is not desirable for many reasons. S_TABU_DIS with * on it's own in a role will typically not be rated as a high risk by an auditor. What it should do is prompt further investigation, however that will depend on lots of factors like audit scope, whether they are over-running on their audit plans. If you are lucky they may rate it as a

"merits attention" but that will depend on the individual.

Cheers

0 Kudos

S_TABU_DIS with * on it's own in a role

Most of them will run RSUSR002 and not care about the origin of the role, only about the user access.

Some of them will look for any entries in AGR1251-HIGH for S_TABU_DIS (also a good move).

The problem with SE16 (much the same as FM RFC_READ_TABLE) is that the user input can generically request the table. So they will bug you with access requests and want S_DEVELOP and SE80 as well to be able to navigate to find more of them, to make more requests. They will show it to their colleagues and they will want it as well. You will not have a transaction context to maintain SU24 though --> they will end up with something similar to SAP_ALL reading obsolete tables and misinterpreting single fields of complex tables / structures.

In contrast, most users just want a few transactions which work well and are user friendly and easily accessible via a user menu (ideally) so that they can get their work done efficiently.

It is not that hard, but once the cat is out of the bag then there is lots of confusion. The famous example is table USR03.

Cheers,

Julius

0 Kudos

What you should also consider is that S_TABU_RFC lets you remotely turn the S_TABU_DIS checks off for specific tables if you create a view to them.

It means that the calling application has taken care of the security before the call and the application user authorizations are correct and the view is correctly designed.

Normally display activity in the debuger (s_develop actvt 03 object type DEBUG) is sufficient in the remote system to see everything in the target system - depending on the authorizations of the technical SYSTEM or COMMUNICATION user. These should ideally not access tables directly.

For table / view comparisons you can use a "current user" destination (or use trusted RFC).

It is unrealistic to restrict users to trouble shoot local problems, so you should ideally implement only the business scenarios for the RFC steps and those should be BAPI application type and not direct table access or generic interfaces to run programs, perform subroutines, install programs, etc.

It is quite easy (with lots of time) to build a catalog of access from the (remote) application to datavia APIs, but you must first get away from the direct table access and control the client access to the generic functions and transactions.

SE16 / Sm30 and many reports and function modules which can very easily be started by adventurous users which offer exactly that.

If the users are doing axactly that then from a security administrator perspective you can only try to restrict it and process "tickets" all day long...

Cheers,

Julius

Edited by: Julius Bussche on Oct 2, 2011 9:12 PM

0 Kudos

S_TABU_DIS with * on it's own in a role

> Most of them will run RSUSR002 and not care about the origin of the role, only about the user access.

>

> Some of them will look for any entries in AGR1251-HIGH for S_TABU_DIS (also a good move).

I think I mis-phrased the "on it's own in a role", the point is that the majority of external auditors will not rate the existence of full S_TABU_DIS access as being a high risk unless combined with obvious methods of accessing that functionality (even basic ones like rfc access not being obvious to most of them....). This is why it is a dangerous and often misguided game to say that things are high audit risk etc, etc.

There is a big difference between what external auditors are looking for and what many of us consider to be risky. This is demonstrated by disproportionate time spent doing "easy" reviews of security rather than functional configuration and associated process.

Cheers

0 Kudos

The best move is still to keep the users off the tables and give them reporting which works without bugs.

Might even use it myself

Cheers,

Julius

0 Kudos

Amen to that. Sounds like a novel step, you mean you won't use SQ01 for everything?

0 Kudos

If users loose confidence in reporting (for example Z-programs which are copies of SAP reports from release 2.1...) then SE16 and SQ01 on DB tables is for them as command line editors are for basis folks.

The quality of reporting can be measured against not using such tools, much like the quality of role (Menu) building can be measured against abstinence from favourites.

Interesting KPIs which I try to use (and ween (SP?) them of).

Cheers,

Julius

0 Kudos

HI,

There are scenarios many a times that earlier for users the S_TABU_DIS have * values and after high risks raised by the business/auditors the security consultants remove those access. There are many customs tables created and end users use to post the data there. One should be fully aware the exact table access an user want.

Thanks.

Former Member
0 Kudos

Hi,

There are a couple of reasons why you should be careful (never say never). These are the usual audit findings in this area.

1. Users will have access to large volumes of data i.e. the who contents of the table. Access to a single table group is all well and good but what about inheriting access to S_TABU_DIS from other other roles / access that a user has.

Additionally (and this depends on the circumstances) you get into the same issues as you have with SAP Query - users may start to report using "different versions of the truth" which can cause operational issues.

You can provide more granular restriction using S_TABU_LIN and S_TABU_NAM - search the forum for more info

2. SM30 etc can in some situations allow users to update data. If you have good control over S_TABU_DIS then this isn't usually a large number of tables (client settings, table settings also have influence), however avoid it altogether by using SE93 to parameterise SM30, allowing update only to a specific table.

m_coenjaerts
Explorer
0 Kudos

Hello,

Also you have to take the 'Magical Merger' into account: as soon as the user has in some other role S_TABU_DIS with ACTVT=02 for a certain table group (- some standard SAP transactions require this). SM30/SM31 access potentially opens more direct change ability on tables unintended.

We do not grant SM30 access in production, but create SM30 transaction variants to maintain Z-tables. (for example we create a custom tcode Z1234, that is a SM30 variant with the maintenance view to maintain table Z1234). It allows users to maintain tables without assigning SM30

0 Kudos

Agree w/ M. Coenjaerts and Julian. An option for you may be proposing the creation of custom tcodes to view/update specific tables.

0 Kudos

Creating Transaction variant for the table changes is the best methodology when we allow users to do direct changes to the tables

0 Kudos

All the data is stored in the table and by SE16 we can view those data quite easily. the auth object S_TABU_DIS should never have "*" for the authorization DICBERCLS. Always the access for the particular Auth group should be given.