This website is not affiliated with, sponsored by, or approved by SAP AG.

Truth about Table Maintenance / DEBUG

SAP Security

Moderators: Snowy, thx4allthefish, jurjen

Truth about Table Maintenance / DEBUG

Postby bbdude » Thu Apr 10, 2014 6:16 pm

I am working in a production environment and noticed there are 100's (yes 100's, not a typo) of individuals with table maintenance. As I understand, table maintenance access can be used to modify transaction data when the client is closed and can be used to modify configuration/master data when the client is open. Is this true? If so, is there ever any bonafide reason one person (much less 100+) should have persistent access to table maintenance?

Could someone really use this access to create a vendor, modify an invoice, modify a journal entry, etc? I looked at the tables that can be modified and it doesn't appear many of the primary financial tables can be modified ... so I'm confused why so many would need this access. To me, it wreaks of an environment not being utilized appropriately ... maybe even a bad implementation and this access is in place as a workaround?

On the other hand, there are several people (although less than 100) with access to DEBUG. I understand DEBUG can be used the same way table maintenance is used, but without the requirement that the production client is open. So I understand people could use this access to chance document number ranges, invoice tolerances, change invoices, etc. if they knew the proper database table? Wouldn't these changes impact the referential integrity of the data?

I guess I'm really trying to understand the risk of the aforementioned access. It's my understanding no one should have this access permanently and any changes should be logged (not the case in the scenario above).

Any thoughts / opinions are welcome! Thank you.

EDIT: This is SAP ECC 6.0
bbdude
 
Posts: 21
Joined: Wed Nov 03, 2010 8:16 am

Re: Truth about Table Maintenance / DEBUG

Postby waltersen » Fri Apr 11, 2014 7:07 am

Hello,

standard SAP tables you cannot change (with SM30) you must use the proper transaction (e.g to change RESB use TX MB22).

Of course you can change Z tables.

If you have debugging with a change mode, you can edit nearly everything: tables via SE16 (also standard ones), the RCs in the program (which allows you to skip authority checks)...

In our company for the prod system only special user have table maintenance. You can get such a user only if you have an incident.

Bye
waltersen
 
Posts: 251
Joined: Wed Oct 13, 2004 7:03 am
Location: Hamburg, Germany

Re: Truth about Table Maintenance / DEBUG

Postby Gary Morris » Fri Apr 11, 2014 10:02 am

If table maintenance is needed restrict with a parameterized transaction that access only that table. Restrict by table groups. You can also restrict by S_TABU_NAM and grant access only to one table.

You did not say whether people are using SM30 / SM31, SE11, etc. So I am not sure if you are saying they have 02 in S_TABU_DIS plus these tcodes? Or are you just seeing 02 in S_TABU_DIS? This would be normal PROVIDED that it is restricted to specific groups that make sense (not S* groups) and provided a business SAP transaction or a Ztransaction is being used and not a System or Basis transaction (S* tcodes)

DEBUG with replace is not necessary for anyone but a Firefighter ID. If you are finding S_DEVELOP with DEBUG in many security roles it is probably because a past administrator saw it in an SU53 and added it to a role, not understanding that it was not the problem. Then when they finally figure out the problem and add the missing authorization they never took out the DEBUG auth.

You will find the same thing with S_BTCH_ADM with value Y, or S_TABU_CLI with value X. Because these sometimes show up in SU53 some inexperienced administrators will add them to roles because they don't know what else to do to try and solve the problem.

You should immediately train users to replace any table edit access using S* transactions with Z* tcodes.
You should not allow developers in Production, make them use Firefighter IDS.
You should not cripple your support users by removing SE16N but protect by table groups and this should not include very many users. Sounds like you have a mess on your hands, but as long as you first clean up S_TABU_DIS and the group names it will be somewhat secure while you are replacing SM30 with Ztcodes.
You have to look at your SM20 Security logs or ST03N and review who is using SM30 or other such tcodes. Hopefully only support type people are using it and you can go ask why and get them a few Ztcodes that go directly to the tables they need access to. I will bet that all your users with this access do not even use it.

Having said that many people still do not comprehend the risk of allowing DISPLAY only for ALL tables. Even display only to security, financial, HR, tables are dangerous. The challenge of every good SAP Security Administrator is to secure a companies security sensitive tables from unauthorized access but not overreact by removing one of the key features of SAP, real time information for business decision making. That is why the use of SQVI or SE16N should be allowed for the right people and it can be restricted. Auditors say remove it because no one ever seems to know what table groups to protect. But that is for another poster. Anyone have a good list of common SAP table groups to be concerned about protecting when allowing SE16N please share.
Gary Morris
SAP Security Consultant
garydavidmorris@gmail.com
Gary Morris
 
Posts: 399
Joined: Sun Oct 20, 2002 10:42 pm
Location: San Antonio, Texas

Re: Truth about Table Maintenance / DEBUG

Postby bbdude » Sat Apr 12, 2014 5:00 am

Thanks all for the replies.

Gary Morris wrote:If table maintenance is needed restrict with a parameterized transaction that access only that table. Restrict by table groups. You can also restrict by S_TABU_NAM and grant access only to one table.

You did not say whether people are using SM30 / SM31, SE11, etc. So I am not sure if you are saying they have 02 in S_TABU_DIS plus these tcodes? Or are you just seeing 02 in S_TABU_DIS? This would be normal PROVIDED that it is restricted to specific groups that make sense (not S* groups) and provided a business SAP transaction or a Ztransaction is being used and not a System or Basis transaction (S* tcodes)


A large percentage have access to SM30, 31, etc. along with S_TABU_DIS 01, 02, etc. along with &NC&. There is another group which have access to select tables through Z transactions, but I'm still not sure why this access would be needed or a permanent basis?

Gary Morris wrote:DEBUG with replace is not necessary for anyone but a Firefighter ID. If you are finding S_DEVELOP with DEBUG in many security roles it is probably because a past administrator saw it in an SU53 and added it to a role, not understanding that it was not the problem. Then when they finally figure out the problem and add the missing authorization they never took out the DEBUG auth.

You will find the same thing with S_BTCH_ADM with value Y, or S_TABU_CLI with value X. Because these sometimes show up in SU53 some inexperienced administrators will add them to roles because they don't know what else to do to try and solve the problem.


This is what I thought - thank you - I agree.

Gary Morris wrote:You should immediately train users to replace any table edit access using S* transactions with Z* tcodes.
You should not allow developers in Production, make them use Firefighter IDS.
You should not cripple your support users by removing SE16N but protect by table groups and this should not include very many users. Sounds like you have a mess on your hands, but as long as you first clean up S_TABU_DIS and the group names it will be somewhat secure while you are replacing SM30 with Ztcodes.
You have to look at your SM20 Security logs or ST03N and review who is using SM30 or other such tcodes. Hopefully only support type people are using it and you can go ask why and get them a few Ztcodes that go directly to the tables they need access to. I will bet that all your users with this access do not even use it.


Thank you for the advice and thoughtful reply. You're right in that there's a lot of work to do. The business process side folks are actually pushing for table maintenance (via Z transactions), but given the number (~100+) that have this access it makes me think there's something else at play here. I can't understand why someone would need this access permanently. Most changes can be done through the normal interface, transports, or through our opening of production process. In the rare circumstance table maintenance is required, I'd suspect the business comes to IT for the change and it's controlled/documented.

Gary Morris wrote:Having said that many people still do not comprehend the risk of allowing DISPLAY only for ALL tables. Even display only to security, financial, HR, tables are dangerous. The challenge of every good SAP Security Administrator is to secure a companies security sensitive tables from unauthorized access but not overreact by removing one of the key features of SAP, real time information for business decision making. That is why the use of SQVI or SE16N should be allowed for the right people and it can be restricted. Auditors say remove it because no one ever seems to know what table groups to protect. But that is for another poster. Anyone have a good list of common SAP table groups to be concerned about protecting when allowing SE16N please share.


Thank you and great points. I wish I had said list of SAP table groups! Thank you again for your response, very helpful.
bbdude
 
Posts: 21
Joined: Wed Nov 03, 2010 8:16 am


Return to SAP Security

Who is online

Users browsing this forum: No registered users and 1 guest





loading...


This website is not affiliated with, sponsored by, or approved by SAP AG.