Risk Issues with IDOCs in Support Roles

Question

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.

Answer 1

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