Stop outgoing RFC-calls from SE37

[Former Member]

Hi SDN.

We have a need of preventing certain users to not be able to call certain RFC-destinations. We cannot find any object that helps us prevent the usage of SE37-> External RFC-Destination.

Giving no S_RFC is not the solution, users need the RFC to some systems, but not to other systems.

Reason we want to prevent SE37 for RFC for some users is that we have discovered a quite large security threat which we would like to prevent,

(Julius and other moderators, for details PM me and I will show you the threat).

Maybe the entire problem is solved with "current user" instead of a communication user, but until we can enforce that, we gladly would like an authorization object + check for which RFC-destinations I am allowed to use.

[Former Member]

There are several options available, most notably s_develop and S_icf (you only see this if you activate it in SM59...) or making the connection "current user".

There is an "execute in sequence" with test case data option. Are you refering to that?

FMs should be called from program contexts, not executed arbitrarily in or against PROD type systems. You can also forget about S_TCODE in this case.

Cheers,

Julius

[Former Member]

Julius, thanks for the reply.

There are always so many backdoors to getting access to SE37 or similar tools. Therefore I find it strange that it is impossible to create "authorization group"-like funktionality on the RFC-destinations giving the security administrator the possibility to restrict some RFC-destinations to some users.

I will send you the information about the security threat separately.

Edited by: Fredrik Pettersson on May 17, 2011 9:31 AM

[Former Member]

You can create "security zones" for destinations on the calling client communication partner using optional object S_ICF (read the docs) or restrict the single test mode via S_DEVELOP in your own access (see SAP note 587410).

The ability to arbitrarily single test FMs (in sequences) is the same as having SAP_ALL to the program interfaces outside of the tested calling contexts.

You need to restrict your own access and / or the acceess of the user defined in the inferface destination.

The sky is not falling down...

Cheers,

Julius