This should be a fun Q&A ... but I'm not (only) doing it for the fun ... 
First, I expect this will offend some sensibilities and stir some emotions (much like when someone says "I use RAID as my backup"). That can easily lead to automatic or knee-jerk answers that I would like to avoid. Let me note that I've been doing SAP Security/Authorizations for 17 years, so, while I don't know everything / there is a lot I still don't know (the trusted RFC area being one of them), there's no need to answer as if I am a newbie who has zero idea of what he's doing.
[I hope that noting such will save a lot of wasted time & text that may try to teach me the basics.]
Second, I am aware of the following (specific to this question):
- the intended function and controls of S_RFCACL: to allow a user to use a trusted RFC into the assigned client (I have both reading and practical-use knowledge in this area, e.g., we've implemented some Fiori here)
- the default restrictions on S_RFCACL (e.g., how hard it is to get a star into some of those fields; the default exclusion from SAP_ALL, obviously)
- that there exists a flag that allows S_RFCACL to be incorporated into SAP_ALL with each regeneration
- that "everyone" says to never activate that flag
Sample Use Case:
- In a non-Prod system, someone needs some quick "emergency" access to get something done that is unusual for them and there is (supposedly) no time to get the authorizations "right," so it is authorized by management and considered acceptable to grant SAP_ALL to that user's ID for a short period of time (and possibly even "open the system", but that's a Basis' task). [I expect this is fairly common and familiar to a lot of us.]
Here's what I don't know that I really want to know (i.e., "The Question"):
- If I'm going to give SAP_ALL to a user, what actual further damage can they do with S_RFCACL being a part of said SAP_ALL?
PLEASE NOTE: I am looking for very practical answers to this question. I am not at all interested in concepts and theories and "best practices" as an answer. Answers that essentially boil down to, "you shouldn't because you shouldn't" will be dismissed. As will scenarios that have little chance of actually occurring. "Everyone" may say "don't do it"; I want to know exactly why, as it pertains to the above Use Case and question. And I suspect there is such a "why" out there. Best practices became so for a reason, and it is the practical sources of said practices that I am seeking. Also, answers that suggest other solutions that skirt around the issue, such as "use a firefighter," will be similarly dismissed. I don't want a "solution" per se, only an answer to this narrow scope of questioning.
Background Architecture:
- Besides SolMan, Trusted RFCs are only created between systems at the same level in the landscape.
- In other words, QA systems only have trusted RFCs to/from other QA systems. Not Dev or Sandbox, and certainly not Prod.
- Even so, the direction of the non-SolMan trusted RFCs (if that matters with trusted), are from non-ECC system into ECC systems. Again, if it matters, trusted RFCs are not overtly created with the intent for ECC to get into any other type of system.
- If a user has an ID in ECC, then he/she has that same ID in every other system at that level in the landscape. At minimum, every user exists in ECC QA, BW QA, and SRM QA, guaranteed.
- Logins occur via SSO. Backend passwords could be setup and used, but are almost never "needed."
The best I can figure (to answer "The Question"), the only thing a user in ECC QA can do with SAP_ALL+S_RFCACL vs. SAP_ALL-S_RFCACL is:
- they could access ECC QA from BW QA or SRM QA, over the trusted RFCs that have to already exist, and do no more than they can do by logging into ECC QA directly ... which they can do .... and my reaction to that is: "big whoop!" (slang for "so what?!" / "who cares?")
- I must be missing something. What is it?
The Benefit (i.e., why I want to do it):
- When I grant SAP_ALL, I want it to be SAP_ALL! When I need it fast in a given client, I don't want to be concerned with having a second role/profile ready there to give "the rest" of SAP_ALL. I don't want myself or my team to forget to add the "extra" thing in a critical situation, and then have it be called, leading to needless troubleshooting and upsetting the customer only to figure out it is this ... especially when the alternative to make this simple & easy is a "big whoop" risk-wise.
So, unless someone knowledgable in this area can articulate a real-world, practical example of a real risk associated with adding S_RFCACL to SAP_ALL under this "Architecture," I aim to misbehave and set that flag to allow S_RFCACL to be generated into SAP_ALL. [Please somebody stop me! ... but only with a good, solid argument.]
Thanks, friends and fellow security peers!
Steve :^{D