SM30, SE16

[Former Member]

What is the basic difference in using SM30 and SE16 to get the data from the tables.

Also, Is there any use in preventing the users the use of SM30 from the security point of view.

Thanks, DVRK

[former_member190272]

Hi

In SE16 only display activity and SM30 you can change.

<removed-by_moderator>

Thanks

Pankaj Kumar

[Former Member]

Hello,

Using SE16.

we can view the table data , using different options.

we can also make entries.

we can use more user specific settings.

Using SM30

we can view, maintain, and transport.

we have also cluster maintenance.

Yes, you are correct. In point of security , we can restrict this tx.

SM30 is very powerful.

<removed-by_moderator>

[Former Member]

This message was moderated.

[Former Member]

Hi Ram,

SM30 is a critical transaction, instead you can give access to SE16. SM30 can be restricted by the following onject:

S_TABU_DIS:

The object contains the following fields:

Authorization group for DD objects: Authorization for tables by authorization class according to table TDDAT.

Enter the name of the allowed classes. Table classes are defined in table TDDAT.

Activity: Allowed operations.

Hope it helps.

<removed-by_moderator>

Thanks & Regards,

santosh

[manohar_kappala2]

Hi,

SE16 and SM30 essentially give direct access to tables information.

But SM30 is restricted in a way that you cannot use the SM30 interface to view all the tables. Only tables with a maintaince dialog defined can be accessed through SM30. But there is no restriction on the access to tables in SE16 as long as u have access to the authorization group pertaining to the table u will be able to access the information through SE16.

Hope this helps

Manohar

[Former Member]

Hi,

Please help me how to restrict user from deleting the entry ..

he shud not be able to delete teh entries which are having data in date field.

I mean user shud not be able to delete the entries from Initail screen itself.where we will see all entries.

thanks,

Varun

[RainerKunert]

Hi,

as already mentioned SM30 and SE16 is restricted with object S_TABU_DIS. If the user is not allowed to delete or change any data, activity 02 (Change) in S_TABU_DIS must not be allowed.

In my projects I do not allow both transactions for any user, because they can specify the table. Alternatively create a parameter transaction for each individual table.

Regards

Rainer

[Former Member]

HI people, in the whole debate i see no mentioning of the risks in SE16 and SM30.

For se16 one should create a parameter/custom transaction only allowing access to the requested table.

SM30 should NEVER been given in roles! that is far to dangeorus. If there is no other option than to update a table directly one should create a copy of SM30 in an ABAP and the same as the custom transaction the abap should limit the user to a specific table (sometimes you need the user to be NOT able to see certain fields or NOT be able to update them).

S_TABU_DIS is needed in so many roles for differeny reasons that it can not be used safely to restrict users in SE16/Sm30 etc.

[Former Member]

To be honest, I don't see where you have mentioned any risks either, if the user has the correct authorizations to use these transactions.

Although copying a SAP standard transaction into an ABAP could possibly be considered a risk, if SAP patches a bug in the standard transaction and you forget to do the same in yours, or there are sy-tcode contexts in the code, or sy-cprog...

Cheers,

Julius

[Former Member]

Julius

the risk is in the S_TABU_DIS object that how ever secure the role itself was build, can be overruled by the value in an other role the user has thus granting rights to other Tables without knowing by teh security people. I have even come acorss a company where they assigned S_TABU_DIS with Activity Star and Auth group star in their genral user role, So in real live NOT even one user was resticted. The real risk was that they also gave everybody debug in the same general user role!!!!!!

The risk in the ABAP is rather limited as when SAP changes something the only effect I have seen untill now is the custom ABAP no longer working leading to the BEEP alarm of the user.

[Former Member]

Hi Auke,

>

> the risk is in the S_TABU_DIS object that how ever secure the role itself was build, can be overruled by the value in an other role the user has thus granting rights to other Tables without knowing by teh security people. I have even come acorss a company where they assigned S_TABU_DIS with Activity Star and Auth group star in their genral user role, So in real live NOT even one user was resticted. The real risk was that they also gave everybody debug in the same general user role!!!!!!

Yes, but that is clearly a risk related to S_TABU_DIS access and S_DEVELOP (which is of increasing importance and there are many important improvements to this object). I don't see how it relates to SE16 and SM30.

I checked with one of our systems yesterday: The users have limited specific values for S_TABU_DIS and in selected Z tables S_TABU_LIN. There is no * nor range required, and certainly no '&NC&'. For ease of use, they would have parameter transactions in their menues (or perhaps favourites sometimes, that is up to them).

If they had SM30 or even SE16 (which they dont), then it would be more difficult for them to use as they would need to know the name of the table or view, but I don't see the security risk... if the user is equiped with the correct authorizations.

>

> The risk in the ABAP is rather limited as when SAP changes something the only effect I have seen untill now is the custom ABAP no longer working leading to the BEEP alarm of the user.

What happens if SAP adds a missing authority-check in the standard code? Does it go BEEP in a Z* program? If it does (which according to the "do not use external performs" should not occur), do you add more access? Have any of your custom copies or other ABAPs gone BEEP in the past 6 months?

Being scared of SE16 and SM30 for security reasons, is in my opinion a symptom of badly implemented security design.

Of course I am not advocating granting SE16 to all users just to prove a point about S_TABU_DIS and tables, but I consider the hype around SE16 as a tcode to be misplaced and a bad security and development practice.

Cheers,

Julius

[Former Member]

Julius

actually you say in your answer that you agree in not giving SE16??

What happens after you have gone, do thy keep on not giving wide access to S_TABU_DIS.

Rememeber the big gorup of "security Consultants " who's knowlegde goes no further than giving access when an Su53 report is presented. In tose companies there will be a wide number of roles with &NC&.

So avoid giving access to SE16 and this will never happen!

[Former Member]

Hi Auke,

> actually you say in your answer that you agree in not giving SE16??

No. I am saying that we did it anyway, but not for the reasons above.

> What happens after you have gone, do thy keep on not giving wide access to S_TABU_DIS.

> Rememeber the big gorup of "security Consultants " who's knowlegde goes no further than giving access when an Su53 report is presented. In tose companies there will be a wide number of roles with &NC&.

That is true, but what about all the other transactions and navigation paths which lead to tables which end users and external consultants know?

> So avoid giving access to SE16 and this will never happen!

Yes it can happen. I do not believe that I know them all, and I know many other ways. Infact I seldom use SE16.

Cheers,

Julius

[Former Member]

There are plenty ways of getting this data but SE16/N/7 etc are the best known, followed by SQ01 & SQVI. Remove these and the majority of users will be put off which is a valid consideration for restricting the widespread use of these transactions.

As a mechanism for extracting large volumes of data very quickly it's a great tool & there lies it's risk, though building security properly will reduce much of this. Unfortunately most security implementations are not built to take these things in mind and basic user roles contain such delights as * in DICBERCLS and full authorisation for S_RFC.........

[Former Member]

Okay, so we all agree that SE16 is unnecessary , for what ever the reason may be...

The majority of the users are in my opinion not the problem. It is a minority of the users with change authority to tables or display access to sensitive ones who are the risk. Considering that change authority is in no way only limited by tcode, restricting S_TABU_DIS does make sense to me... so is it such a hassle to add the display restrictions at the same time as well?

One source of problems would be custom coding and parameter transactions which add coding to view or change custom tables which do not have authorization groups on them, and therefore request such values as mentioned above by Auke. But that should be tackled with the developer, and not with SAP to add more strange S_TCODE checks to muck up the authorization concepts of those who did "follow the rules".

If displaying data directly in tables is the risk, then surely one would not want to rely only on a tcode restriction to protect it? Considering that sensitive data is often available in large numbers of records, the "SAPGUI tcode concept" (started from a menu or directly from the ok-code field) is surely a very inefficient way of downloading large datasets. You also cannot add a t-code value into background jobs or job-step definitions... and checking S_TCODE in background jobs and RFC's is a questionable practice... reports and RFCs use S_TABU_DIS => see [this old thread|; as well for a related discussion.

Cheers,

Julius

[Former Member]

> The majority of the users are in my opinion not the problem. It is a minority of the users with change authority to tables or display access to sensitive ones who are the risk. Considering that change authority is in no way only limited by tcode, restricting S_TABU_DIS does make sense to me... so is it such a hassle to add the display restrictions at the same time as well?

Those who know "enough" are always a pain, but there are also "low hanging fruit" which we can take care of. In one go, we deter the casual user from using table data for various innocent and not so innocent purposes. S_TABU_DIS is obviously key to control irrespective of tx but where we have a lack of granular restriction (without invoking S_TABU_LIN) the restricting points of entry is quite useful in my opinion

> One source of problems would be custom coding and parameter transactions which add coding to view or change custom tables which do not have authorization groups on them, and therefore request such values as mentioned above by Auke. But that should be tackled with the developer, and not with SAP to add more strange S_TCODE checks to muck up the authorization concepts of those who did "follow the rules".

I agree

> If displaying data directly in tables is the risk, then surely one would not want to rely only on a tcode restriction to protect it? Considering that sensitive data is often available in large numbers of records, the "SAPGUI tcode concept" (started from a menu or directly from the ok-code field) is surely a very inefficient way of downloading large datasets. You also cannot add a t-code value into background jobs or job-step definitions... and checking S_TCODE in background jobs and RFC's is a questionable practice... reports and RFCs use S_TABU_DIS => see [this old thread|; as well for a related discussion.

Inefficient - yes, well known - yes again. SE16 & those of it's ilk are not really intended for end users (so SAP give them the lovely SQ tx instead) and as with many of those functions, granular restriction takes us just that little bit longer

Cheers

Alex

[Former Member]

> SE16 & those of it's ilk are not really intended for end users (so SAP give them the lovely SQ tx instead) and as with many of those functions, granular restriction takes us just that little bit longer 🙂

SAP also gave us BusinessWarehouse and now BusinessObjects (in a more integrated way) where end users can run and even create queries on data (aggregated if required, and not including system tables and other sensitive transparent data tables from the transactional system...).

As this thread is old and Rama has already "left the building" since 1 year ago, I take the liberty of closing this thread and assigning full points to Manohar for answering the original question.

But it is not locked

Cheers,

Julius

[Former Member]

I'm glad it's still open

Take BI for example, we have the ability to create a detailed authorisation concept and apply it to allow users to create & publish their own ad-hoc queries in a more controlled manner. While we have some of this with SE16, it is a whole load of extra work to give a reasonable amount of granularity. Business Objects I can't comment on as I've not had a play yet.....

[Former Member]

>

> Business Objects I can't comment on as I've not had a play yet.....

According to comments in the coding, it is conform with the package concept now and the old notes have been removed...

Here is another innteresting article ( http://www.channelregister.co.uk/2008/06/12/data_breach_verizon/ ) with a detailed report and (so far) one comment about data breaches. The real problems are the "pains", not the end users, it seems.

I dont think that SE16/7/N (or locking them) is of much use, though the argument of preventing folks from getting used to using tables directly is valid - so I agree with you and Auke on that score.

Cheers,

Julius