We are looking for a comprehensive list of sensitive transactions (e.g. SE38, SE37, LSMW, etc) that should NOT be assign in Production environment. Transactions that will trigger audit violation in PRD environment. Hopefully with documentations or whitepapers to backup this list.
These should be disabled
CA87 Mass Replace Work Center
CAT6 Human Resources
CL04 Delete Class
F.34 Credit Limit Mass Changes
F.80 Mass Reversal of Documents
F044 Vendor Archiving
FI12 Change House Banks/Bank Accounts
IP30 Run Date Monitoring
LN08 Number range maint.: LVS_LENUM
MMPV Close Periods
MMRV Allow Posting to previous Period
PA20 Display HR Master Data
PA30 Maintain HR Master Data
PA70 Fast Entry
PA97 Compensation Administration - Matrix
PFCG Role Maintenance - System integrity, stability at risk
RZ04 Maintain SAP Instances
SA38 ABAP Reporting -Can run programs not protected appropriately
SARA Archiving Management - Should be restricted to Archive Admin
SCC1 Client Copy - Special Selections
SCC4 Client Admin. - System stability & integrity at risk
SCC5 Delete Client - System stability at risk
SCC6 Client Import - System stability & integrity at risk
SCC9 Remote Client Copy - System stability & integrity at risk
SCCL Local Client Copy - System stability & integrity at risk
SE01 Transport Organizer - System stability & integrity at risk
SE11 Data Dictionary Maint. - System stabiltiy & integrity at ris
SE13 Maintain tech tables settings - System stabilitiy at risk.
SE16 Data Browser - Exposure to confidential information
SE37 Function Builder
SE38 ABAP Editor - System stabiltiy & integrity at risk
SM01 Lock Transactions - System stabiltiy at risk
SM02 System Messages - Should be restricted to System Admins only
SM30 Table Maintenance - System integrity & stability at risk
SM49 Execute OS commands - System stability at risk
SM50 Work Process overview - System stability at risk
SU01 User Maintenance - Should be restricted to User Admins only
SU02 Profile Maintenance - System stability and integrity at risk
SU03 Maintain Authorizations
SU05 Maintain Internet user
SU10 User Mass Maint - System stabilty at a very high risk
SU20 Authorization Object fields
SU21 Authorization Objects
SU24 Maintain Assignment of Authorization Objects
SU25 Profile Generator Upgrade and First Installation
They could only access data from SE16 if they have the corresponding s_tabu_dis activity for the authorization group to which that table has been assigned.
If the auth group is not maintained, SE16 will assign the value '&NC&' to it and check it.
If granting s_tabu_dis for other tables sharing the same auth group is inappropriate, then these can be re-assigned in transaction SUCU.
I still don't see where SE16 or SM30 itself are problems if the user has correct authorizations.
Infact, if a user must view / maintain a table, it is much safer and cheaper to use SE16 / Sm30 than re-invent them and hardcode the table name.
*---------------------------------------------------------------------* * FORM AUHTORITY_CHECK_AGAIN * *---------------------------------------------------------------------* * ........ * *---------------------------------------------------------------------* FORM AUTHORITY_CHECK_AGAIN USING ACT. GLOBAL_AUTH = 'SHOW'. SELECT SINGLE * FROM TDDAT WHERE TABNAME = DATABROWSE-TABLENAME. IF SY-SUBRC <> 0 OR TDDAT-CCLASS = SPACE. TDDAT-CCLASS = '&NC&'. " 'non classified table' ENDIF. * Anzeigeberechtigung AUTHORITY-CHECK OBJECT 'S_TABU_DIS' ID 'DICBERCLS' FIELD TDDAT-CCLASS ID 'ACTVT' FIELD '03'. IF SY-SUBRC NE 0. MESSAGE E419 RAISING NO_PERMISSION. ENDIF. * Änderungsberechtigung AUTHORITY-CHECK OBJECT 'S_TABU_DIS' ID 'DICBERCLS' FIELD TDDAT-CCLASS ID 'ACTVT' FIELD '02'. IF SY-SUBRC = 0. GLOBAL_AUTH = 'UPDA'. ELSE. IF ACT = 'ANLE'. MESSAGE E417 RAISING NO_PERMISSION. ENDIF. ENDIF. IF DD02L-CLIDEP EQ SPACE. * Mandnatenunabhängig AUTHORITY-CHECK OBJECT 'S_TABU_CLI' ID 'CLIIDMAINT' FIELD 'X'. IF SY-SUBRC <> 0. * Keine Berechtigung für mandantenunabhängige Änderungen GLOBAL_AUTH = 'SHOW'. IF ACT = 'ANLE'. MESSAGE E417 RAISING NO_PERMISSION. ENDIF. ENDIF. ENDIF. ENDFORM.
Thanks for everybody input. I like to keep this thread open for a bit longer so we can all contribute to the list and build a more complete list. Will be useful if we face an Security Audit one day.
I am with Cristian on SE16 and SM30 or SM31. There are over 35,000 tables in SAP. Most users only need access to handful of them. Since so many tables share the same table authorization group, and a lot of transaction utilize S_TABU_DIS. Setting up custom transaction for each table might sound a lot of work upfront, but if you compare to having users who get hold of all SSN thru PA* tables and you have no way to tell who access those tables. You will sleep better at night knowing you can at least audit who were accessing those tables.
A lot of SE* transactions are easy to give up, very very hard to take it back.
The main purpose is to not have edit access to the Production data, so SE38,SA38, etc need to be put away as do almost all the transactions in the list below. For ex. if someone in the BASIS group has an access key in Prod, then SE38 and SA38 become potential audit violations as the code can be changed if the system is open. The other way to avoid these pitfalls, is to create z transactins for you r tables and programs and assign them to a role. Give that role only to a select few people.
Also, you'll face a problem on the BW side with transaction RSA1. You'll need to figure out a way to make it display only and have a "firefighter" id or the easiest way to put mitigating controls and exceptions around it.
These are some of the thoughts.Hope this helps.
If I am going to be deprived of sleep because of a SAP table, then rather by the devil which I know, than one which I don't.
It is possible to understand SE16 and control the use of it and audit the authorizations for the table & corresponding program auth groups.
It is virtually impossible to understand or control or audit 100s of Z-transactions for tables and programs without auth groups.
Auditing use of SE16 is easy: A TRDIR entry is automatically generated by SAP which includes the name of the accessable table; the record of the user accessing it is SAP standard available in the application monitors and it is very difficult to take either back again.
The same can be said for SE37. On it's own, a perfectly harmless and useless transaction code from a security perspective.
I love open discussion, always learn something new. Hopefully we are not too far off track from the subject.
I know SAP keep track of what transactions a user is running, but I am curious do SAP keep the log at the field level? Do the application monitors log which table was access thru SE16? What data were query/download thru SE16? Do you know how to get these log? I would love to know.
Regarding SE37 & SE38, SAP Security Audit log do keep track of the function modules or programs being execute. But this is not preventive action. I have the experience of an ABAP developer assign himself SAP_ALL by calling PRGN_AUTH_PROFILES_ASSIGN using SE37 in debug mode. We caught in when we run the who has SAP_ALL report. If he is smart enough to delete the profile after he is done. We most probably will missed it, and will be buried in the Aduit & System log.
Yes, you can control access using field levels if you activate it. See the documentation on object S_TABU_LIN (SPRO -> IMG -> Basis -> System Administration -> Users and Authorizations -> Line-oriented Authorizations) and OSS 763269 "Line by line authorization check in SE16".
The application stats log exactly which table was viewed, if you get the user to use SE16 to view it... For other transactions it will not necessarily do this. See OSS 143550 for further capabilities which you can activate if you need them.
Regarding downloading etc data once displayed, there is to my knowledge no possibility for the application server to prevent or detect a screen-shot (or a photo) being made of the front end.
Regarding your (ex-)developer, I am shocked! How silly of him so have created an audit trail. There is a nifty feature in the debugger which is less noisy. Place the break-point ahead of, for example, a check routine being performed. Then place the cursor after it and right-click "Go to Statement". It will skip over the coding between without executing it.
With sy-subrc = 0,
I think you don't miss these ones:
/SAPAPO/ADVM AOMD Define Advanced Macros
/SAPAPO/DM_MAT_MCH AOMD Mass Maintenance of Material
/SAPAPO/MC62 AOMD Maintain Characteristic Combinations
/SAPAPO/MC8R AOMD Definition of Time Bucket Profiles
/SAPAPO/MC8U AOMD Transfer Profile
/SAPAPO/MC90 AOMD Transfer Planned Independent Reqmts
/SAPAPO/MC96B AOMD Maintain Forecast Profile
/SAPAPO/MODEL AOMD Change Model
/SAPAPO/MSDP_ADMIN AOMD S&DP Administration
/SAPAPO/MVM AOMD Planning Version Management
/SAPAPO/RBA04 AOMD Integrated Rule Maintenance
/SAPAPO/RRP2 AOCT Process Order
/SAPAPO/RRP5 AOCT Create Order
/SAPAPO/SDP94 AOMD Supply & Demand Planner: Init.Screen
/SAPAPO/TSCOPY AOMD Copy/Version Management
/SAPAPO/VERDEL AOMD Delete Planning Version