S_RFC Risks and Remediations

[Former Member]

Hello experts,

In our current landscape SU24 was not maintained for custom tcodes, RFCs and webservices. The backgoud of our systems is unit testing has been completed for all the cusotm developed roles without maintaining of SU24 for any custom work.

When it comes to the S_RFC usage, below are the values given in a role and assigned to the 150+ end test users in a system:

S_RFC

Activity: 16

RFC_Name: *

RFC_TYPE: FUGR, FUNC

I would like to summarize the risk of this practice and remediation approach in less time. If I would be the one has to work on this RFC security in the beginning then I follow the best practice RFC wiki page steps.

Your suggestions and comments will greatly help us ( my management) to deal this in better way. My voice alone not making much progress on this for a while.

Thanks,

Himadama

[Former Member]

Thanks for refering to the wiki. I plan to still enhance it further for other scenarios.

>When it comes to the S_RFC usage, below are the values given in a role and assigned to the 150+ end test users in a system:

>S_RFC

>Activity: 16

>RFC_Name: *

>RFC_TYPE: FUGR, FUNC

It may be that this is for tracing purposes?

In an ideal world, the developers would however know the name of the FM, and maintain SU24 for it when developing the scenario. Role building is also "development work", even if done by the security admin.

If you get that part right, then securing RFC is sustainable and your approach is "state of the art". Actually, the same applies to transactions, queries, web services, batchjobs, etc as well.

Cheers,

Julius

[Former Member]

Thanks Julius for your reply.

It may be that this is for tracing purposes?

NO - It is not. A role created with these values and assigned to more than 300+ test end users in multiple systems and completed the unit testing for roles.

I do not know how good is pointing this on developers( or lead) or security lead. The important consideration is re testing time and effort of all roles by making changes in SU24 for custom tcodes, FMs, webservices etc...

Thanks,

Himadama

[Former Member]

Himadama,

I think that the Wiki mentioned is a great way to approach the clean up. Below are just a few thoughts around the questions of

Risks whereas your Remediation is to identify/configure/test/deploy security around these RFCs per the Wiki.

Risks:

If access to Web URLs / Web Dynpros / Services are know and only S_RFC checks are coded then functionality could be executed by an unwanted audience. This could be limited to custom functionality that was coded without additional authorization checks into the business application's area. If you contrast that to standard ESS functionality you will have P_PERNR auth checks in addition to the S_RFC access, standard SAP functions.

A user also might be able to jump off into other systems from the RFC connection setup in the system, depending on transactional access that is in addition to S_RFC access.

Thanks,

Matt