SM30/SM31 and SE16 access in Production systems - Confusion

Question

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

Answer 1

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