Sensitive Transactions List for Production System

[Former Member]

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.

Thanks,

Lye

[Former Member]

Just remove all S_DEVELOP authorizations (all!) from the users. It will bring 100's of inappropriate for production system transactions (e.g. SE37, SE15, S...) and navigation paths (.ys) to an abrupt halt.

[Former Member]

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

[Former Member]

What is wrong with SE16?

[Former Member]

well w/ SE16 someone could try to extract data.

For ex. may be used to view email logs

It's better to filter that one too.

[Former Member]

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.

[Former Member]

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.

jbussche,

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.

Thanks,

Lye

[Former Member]

Hi,

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.

Cheers,

Kedar

[Former Member]

Hi Lye,

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.

Kind regards,

Julius

[Former Member]

Julius,

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.

Thanks,

Lye

[Former Member]

Hi Lye,

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,

Julius

[Frank_Buchholz]

Another important area to be secured is around remote connections, mainly transaction SM59

[Former Member]

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

Regards,

Surpreet Bal

[Former Member]

Please ensure restricting the following auth.objects with right values, which ensures more security on your production system.

S_ADMI_FCD

S_USER_AUT

S_TABU_DIS

S_TABU_CLI

S_DEVELOP

S_TRANSPRT

Regards,

Bala

[arpan_paik]

Hi Bala,

Thanks for bringing it up from dead (is it really?)... Lot to learn

Regards,

Arpan Paik