Risk Issues with IDOCs in Support Roles

[Former Member]

I am managing a security architecture project and need to create some IT support roles.

Are there any IDOC-related transactions that can create, change or modify data? If so they would be innapropriate for any IT access.

[koehntopp]

(Moved to the Netweaver Security Forum)

[arpan_paik]

You can look at BD* transaction..Like BD55, BD66 etc many more..

Regards,

Arpan Paik

[Former Member]

What I mean is, of the many BD and WE transactions, which should not be assigned to an IT support desk because they can be used to create or modify data? The principle being, IT should not be able to create or modify data in the production system.

[Former Member]

I can recommend forgetting about S_TCODE when it gets to IDOCS.

Several S_IDOC* authorization objects even have TCD (transaction code) as a field, in an attempt to create a second level of security control. This looks good on a PowerPoint presentation, but is unrealistic "in the wild".

You can gain a quick start by first reading the documentation on the S_IDOC* objects in tcode SU21, then read the ALE and RFC Security Guides on service.sap.com and then (important) talk to the people who actually use these transactions about their business processes.

Changing IDOCS is very often a symptom of bad master data quality or the sequence of some process flows.

You cannot tackle this without an understanding of the business processes which you might disrupt, but can add a lot of value by isolating the authorizations for it (the S_IDOC objects have many fields... and S_IDOCMONI is the one you should try to understand most) and then looking into the processes.

When you get that far, then you will also want to look into the development systems for the distribution of the ALE models via RFC instead of transporting them. This is a bigger can of worms than changing an IDOC...

Unfortunately some audit recommenations "blacklist" the ability to recieve an IDOC, In my books this is silly, because batch processing anyway does what it is told. Other scenarios make is usefull to be able to receive messages via IDOC for what happened on the other side.

The weapon of choice here is to understand the interfaces and use Su24 to document them to create secure roles for them or upgrade to newer technologies where these are supported.

My 2 cents,

Julius

[Former Member]

Hi Frank,

T-codes like WE20, WE21, BD87 are some that can change or modify data. T-codes like WE02, We05 etc will not. How about looking at the SAP templates roles related to IDOCs that can give you some idea ..

SAP_BC_MID_ALE_IDOC_ADMIN

SAP_BC_MID_ALE_IDOC_DEVELOPER

SAP_IDOC_ADMINISTRATOR

SAP_IDOC_EVERYONE

SAP_IDOC_IMPLEMENTATION

SAP_LE_AID_IDOC_ADMIN