If you are looking for best-practices about creating an authorization concept for RFC you will find here an overview about some well-known pieces of information as well as a brand new approach how to get trace data on RFC authorizations for free.
As of basis release 7.02 respective 7.10 you can provide authorizations for individual function modules in addition to the well-known option to provide authorizations for function groups. See Note 931251 for details.
Here you get the overall plan: Step 1: Analyze and document the communication relationships within the system landscape. Step 2: Trace the authorizations used by each user. Step 3: Create an authorization concept for two user groups: service users and regular users. Step 4: Fine-tune the concept for further user groups. Step 5: Monitor the assigned authorizations at regular intervals.
New: Standard transaction STRFCTRACE replaces the Z-report described in this blog (see note 2080378).
By the way: Do you know the authorization object S_ICF and that it can be used to secure the usage of RFC destinations? Using it you can restrict who is allowed to call RFC function modules using a RFC destination.
a) You run several productive clients in one system. There exist many RFC destinations pointing to other systems. You know that RFC destinations are client independent but you like to restrict the usage for some critical RFC destinations to a specific client. Using authorization object S_ICF you only assign authorizations for using these critical RFC destinations within this client.
b) The Central User Management (CUA) owns very powerful RFC destinations which should only be used by your user administrators. Using authorization object S_ICF you only assign authorizations for using these critical RFC destinations of the CUA master system to the user administrators.
You find the documentation about authorization object S_ICF in the RFC/ICF Security Guide (Well, it is located in the ICF part which is a little bit misleading): Controlling Access to RFC Destinations
Security Audit Log
You can use the Security Audit Log to trace incoming RFC calls. Then you can use the result to prepare lists of called RFC function modules and function groups. However, in this case you have to enable logging not only for critical events but also for sucessful events in the Security Audit Log. Because of the increased size of the resulting audit log files you may not want to do this.
You can use the System Trace to log incoming RFC calls. This is a very fast and easy way to trace specific actions but you never switch it on for a long time. That means you can use it to analyze a specific application which you are currently testing but you cannot use it to build a complete authorization concept.
Nowadays you can use transaction STAUTHTRACE instead (actually I never call ST01 again). Here's the Online Help about transaction STAUTHTRACE.
<!--If transaction STAUTHTRACE is not available in your (quite old) system you can use report ZSHOWAUTHTRACE from SDN instead.-->
Let's go back to the plan described earlier: Step 1: Analyze and document the communication relationships within the system landscape. Step 2: Trace the authorizations used by each user.
The first step deals with the question which of the defined RFC destinations are really used and the second is about the list of RFC function modules or function groups which are called via RFC.
The analysis options of the Workload Statistic, transaction ST03N, show a lot information about these questions for free.
Here are the main hints how to use ST03N to view RFC statistics:
Select Workload for a server or for TOTAL and optionally a date.
To analyze incoming RFC calls choose profile "RFC Server Profile" and show the tab "Function Module". Use this view to build authorizations for authorization object S_RFC.
To analyze incoming RFC destinations choose profile "RFC Server Profile Destination" and show the tab "Remote Destinations". Select task type 'RFC'.
To analyze outgoing calls choose profile "RFC Client Profile" and show the tab "Function Module". Select task type 'All' or a specific task type.
To analyze outgoing RFC destinations choose profile "RFC Client Profile Destination" and show the tab "Remote Destinations". Select task type 'All' or a specific task type. Use this view to build authorizations for authorization object S_ICF.
It's useful to extend the data retention period for the monthly aggregates about RFC calls. Use can set a long time like 6 or 12 month.
Transaction ST03N -> Collector and Performance DB -> Performance Database -> Workload Collector Database reorganization -> Control
Transaction SM30 for table SWNCCOLLPARREO
Maintain settings “Month.Aggrs Ret.Per. “ and “TOTAL MnthAggrRetPer” for these areas:
WO RFC Client Profil
WP RFC Client Destination Profil
WQ RFC Server Profil
WR RFC Server Destination Profil
ST03N RFC Server Profile showing incoming RFC function calls
Transaction ST03N is not bad but it's a little bit tricky to retrieve the relevant information from the workload analysis data. Therefore I've developed a small report which retrieves all information about RFC calls easily: Report ZRFC_STATRECS_SUMMARY on GitHub shows you the daily, weekly and monthly aggregations about RFC calls including information about function groups, user types or user groups. You can directly use the result to build authorizations for authorization object S_RFC.
New feature (March 2013): Show authorizations of remote users concerning authorization object S_RFC and compare them with the data from the workload statistics.
Limitation: This report works as of SAP_BASIS release 7.00.
New: Standard transaction STRFCTRACE replaces this Z-report (see note 2080378).