S_RFC Function Groups

[Former Member]

Hello experts:

I am currently using S_RFC with full authorization ( * ) for RFC users in satellite systems. Can anyone clarify what this implies in terms of security? Can I restrict the "Name of RFC to be protected" field only to the function groups requiered for each user?

Particulary, I am using an RFC connection for the test workbench through SolMan using trx STWB_WORK? Do the function groups requiered depend on the transaction or program I am testing through my assigned test package? If so, how can I find out which function groups a particular transaction or program requieres? If not, does it depend on the program or transaction from which I am making the RFC connection, in this case STWB_WORK?

Can someone shed some light on how to determine the strictly necessary function groups to be assigned in S_RFC?

Thank you all,

Henry

[Former Member]

Hello Henry,

Can I move this thread to the security forum, although I assume your answer is in a Solution Manager context?

Cheers,

Julius

[Former Member]

I guess so, no one has answered here anyways

[Former Member]

Hello Henry,

While we wait for somebody more knowledgable than myself to answer, some comments from me:

My understanding is that this tool uses eCATT (to retrieve the results of test cases) from remote systems.

Always usefull => Activate the security audit log (transaction SM19) using the dynamic tab to log all successfull RFC calls to find out which calls are made in those systems, and in your SolMan.

Also take a look at the function groups of transaction SECATT in transaction SU24 which might have a "Proposal" (previously "Check/Maintain" value), as they may appear in the audit log in your remote systems... (I am not sure what the default values are).

There is also a SAP note "Minimum authorizations for Workplace users" (Note 215927) which might be usefull for you.

I also think the access required (not only S_RFC) will be dependent on your test cases (begging the question: How can SAP deliver a correct default or role...). You can also mitigate this risk by not saving the logon data permanently in the connections...

Of course, the application authorizations (e.g. S_DEVELOP, S_USER_GRP, and many others...) are also important for security, and the user type for the connection (type SYSTEM is the recommended type, if the logon data is going to be saved) as well. You might also want the user to logon when the connection is opened, if they are running the test themselves..?

Another aspect is how your target system is setup? If an invoced RFC call leaves it's RFC group (and is able to!), do you want to be able determine which RFC_NAME groups it can call? Or do you want to prevent it using client settings (see tha CATT / eCATT restrictions in SCC4 for your release) and system settings for the RFC check?

Some alternate strategies are to accept the risk, use dedicated user IDs for the test cases and secure the access to this transaction (not only limited to STWB_WORK) in the source system (your SolMan). Though some security folks I know prefer securing the target, as a general security principle, you can make a "quick-win" by securing your SolMan security...

Tricky topic. Good question!

Cheers,

Julius