Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

RSUSR002 not giving the full story (from an IT Auditor)

Former Member
0 Kudos

From an IT auditor - old hand at IT - new to SAP

I run RSUSR002 and input S_TCODE as the auth object and SE30 as the program name.

Mu userid appears on the resulting report, as someone who can run SE30. But, when I try SE30 I am blocked and told I'm not authorized (good).

So, where do I look, to get the truth about which transactions our users can REALLY execute? At the moment it looks qwide open, but clearly its not. Do I have to buy Virsa ?!

1 ACCEPTED SOLUTION

Former Member
0 Kudos

SAP security is basically a combination of transaction code and authorization objects. In most

cases, you'll need both to execute a function. But there are some transaction codes

that do not check an authorization object - in this case, you just need the tcode.

For SE30, you probably had the tcode, but not the associated authorization object

access - S_DEVELOP. To determine if users can really execute a function, you will

have to look at both tcode and auth objects. Do you need Virsa ? Not necessarily,

but it would CC would probably help in the reporting.

10 REPLIES 10

Former Member
0 Kudos

SAP security is basically a combination of transaction code and authorization objects. In most

cases, you'll need both to execute a function. But there are some transaction codes

that do not check an authorization object - in this case, you just need the tcode.

For SE30, you probably had the tcode, but not the associated authorization object

access - S_DEVELOP. To determine if users can really execute a function, you will

have to look at both tcode and auth objects. Do you need Virsa ? Not necessarily,

but it would CC would probably help in the reporting.

0 Kudos

Many thanks.

I have various questions I need to ask, such as who can REALLY edit ABAPS. How would I find out that S_DEVELOP is the associated auth code for SE30? (Actually, I was just told that S_PROGRAM was the one...). Same question for all the other transactions out there.

I have lots more transactions that I need to verify are secured, whats my best tactic for this?

0 Kudos

Run the same report except add the associated auth objects in your selection field as well. You can look up the associated auth objects for a tcode in SU24 as already mentioned.

Note that if the client is closed - as it should be in production, then doesn't matter if user has change access with S_DEVELOP.

Former Member
0 Kudos

Hi Chris,

For SE30 you need access for authorization object s_tocde and value SE30 + s_develop (values: activity 03 and object type syst). For all transaction codes you can look for authorization object checks using transaction SU24.

Please award points for useful answer.

Regards.

Ruchit.

0 Kudos

Great, thanks Ruchit -

I checked SU24 - for SE30, S_DEVELOP is the only object with Check/Maintain against it, so I guess that's logical.

So, can I assume that Check/Maintain is the thing to look for?

Is there any clever report/program out there that will tell me that users A + B can successfully run transaction XXXX - i.e. something that will dig a bit deeper and go to the auth objects for these transactions?

0 Kudos

+"Is there any clever report/program out there that will tell me that users A + B can successfully run transaction XXXX - i.e. something that will dig a bit deeper and go to the auth objects for these transactions?"+

RSUSR002 is reasonably clever for this, even more so if you have synchronized the UST* tables with the USR* tables. But reasonably clever does unfortunately not make it reasonably easy nor anywhere near complete. The question is which objects/fields/values to check using rsusr002 to get the correct answer for the risk you are auditing, considering that the user might have many navigation paths available to get there, possibly also from other clients or systems. You get most of this tricky information from the authority-checks in the application coding, the SU24 check indicators, some customizing settings when used, and some system parameters.

In the case of SE30, it has nothing to do with the transaction code, considering the risk. (You are probably blocked because of an S_DEVELOP 03 check at start of SE30 - go to SA38 or some other report starter and run report RSHOWTIM or use the "performance analysis" via the menu of SE38. Same thing... sort of)

These are the obvious risks to audit:

  CALL FUNCTION 'TR_SYS_PARAMS'
       IMPORTING
            SYSTEMEDIT         = SYSTEMLOCK
            SYS_CLIINDDEP_EDIT = SYS_CLIINDDEP_LOCK
       EXCEPTIONS
            NO_SYSTEMNAME      = 1
            NO_SYSTEMTYPE      = 2
            OTHERS             = 3.
  IF SY-SUBRC <> 0.
    MESSAGE ID SY-MSGID TYPE 'S' NUMBER SY-MSGNO
            WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
    EXIT.
  ENDIF.
  IF   SYSTEMLOCK <> 'N' AND
     ( SYS_CLIINDDEP_LOCK = ' ' OR SYS_CLIINDDEP_LOCK = '1' ).
*   system is not locked, component locked ?
    CALL FUNCTION 'TR_GET_DLVUNIT_CHANGEABILITY'
         EXPORTING
              IV_DLVUNIT       = 'LOCAL'
         IMPORTING
              EV_CHANGEABILITY = CHANGEABILITY
         EXCEPTIONS
              INVALID_DLVUNIT  = 1
              OTHERS           = 2.
    IF SY-SUBRC <> 0.
      MESSAGE ID SY-MSGID TYPE 'S' NUMBER SY-MSGNO
              WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
      EXIT.
    ENDIF.
    IF CHANGEABILITY = 'N'.
      MESSAGE S400(S7).
      EXIT.
    ENDIF.
  ELSE.
* system locked
    MESSAGE S840(TR).
    EXIT.
  ENDIF.
  AUTHORITY-CHECK OBJECT 'S_DEVELOP'
                  ID     'OBJTYPE'   FIELD 'PROG'
                  ID     'DEVCLASS'         DUMMY
                  ID     'P_GROUP'          DUMMY
                  ID     'OBJNAME'          DUMMY
                  ID     'ACTVT'     FIELD '02'.

(check that the system is not modifiable in SE06, check SCU3 for table T000 that the clients are not open (and ask for documentation when they were) and use rsusr002 for S_DEVELOP actvt 02 object type PROG)

or

FORM in_authority_check.
* ec Dez. 2002 auf ACTVT 16 explizit prüfen!!
*  authority-check object 'S_DEVELOP'
*           id 'DEVCLASS' dummy
*           id 'OBJTYPE' field 'FUGR'
*           id 'OBJNAME' field rs38l-area
*           id 'P_GROUP' dummy
*           id 'ACTVT' field '03'.
  AUTHORITY-CHECK OBJECT 'S_DEVELOP'
           ID 'DEVCLASS' DUMMY
           ID 'OBJTYPE' FIELD 'FUGR'
           ID 'OBJNAME' FIELD rs38l-area
           ID 'P_GROUP' DUMMY
           ID 'ACTVT' FIELD '16'.
  IF sy-subrc NE 0.
    MESSAGE e099.
  ENDIF.
  IF trdir-name = g_testprog.
* Authority-Check, Ausführberechtigung
    CALL FUNCTION 'RS_ABAPSUBMIT_AUTH'
      EXPORTING
        program_header   = trdir
        variant          = ' '
      EXCEPTIONS
        just_via_variant = 01
        no_submit_auth   = 02.
    IF sy-subrc NE 0.
      MESSAGE e099.
      LEAVE.
    ENDIF.
  ENDIF.

(rsusr002 for s_develop actvt 16 object type FUGR -> nothing else, unless you are on a release lower than 6.40 and have not manually implemented OSS 587410, in which case check s_develop 03 FUGR only)

This is the easiest way I can think of auditing most of "SE30".

Also note that once someone gets their hands on authorizations such as these the chances of finding them via RSUSR002 or such tools will decrease rapidly.

Cheers,

Julius

Former Member
0 Kudos

hello Chris,

Basically RSUSR002 is the report we have to use for this purpose but the method has to be different.

There are however a few short cuts to this.

Infact we also have a similar SOX audit from authorization perspective and based on my experience I can advise you.

basically our audit does not check for each and every transaction but for really important ones. This may include functional,technical as well as basis authorizations. So first i will suggest that you jot down a list of transactions for which you want to do the audit.

Then you put all these authorizations in SU24 and get allrequired authorization objects for them. Down load the list in a file and set filter for check/maintain though in certain cases the only check involved will be for s_tcode. You need to be careful with this. Now you can create variants in RSUSr002 for required transactions and execute them to get the data. For example the variant for SE30 should have check for both s_tcode as well as s_develop.

Also check if report RSUSR008 can be of any use to you.

regards.

Ruchit.

Former Member
0 Kudos

<i>"Do I have to buy [a tool]?!"</i>

To audit SE30 -> No.

<i>"where do I look, to get the truth"</i>

Authorization tools are generally only as good as their assumptions about which tables they are getting the information from (almost exclusively different ones from those which authorization checks use) and are ignorant to the application coding, much of the system parameters and most of customizing. The same applies to rsusr002.

This principle applies without exception in my experience, unless you have lots of cash, lots of time, want to impress the auditors, fool your management and beat the Jones's at the same time -> then it is almost mandatory to buy a tool to help you achieve this.

If you have a realy bad feeling about things, then as a start try SAPs Security Optimization Services (SOS) which covers many of the important risks in a very short space of time (about 1 day). For the rest you are better off doing a clever day's work and trying to understand the SAP system, as you should not try to get around doing that anyway.

Just my 2 cents worth to hopefully help you.

Cheers and good luck,

Julius

koehntopp
Product and Topic Expert
Product and Topic Expert
0 Kudos

"A fool with a tool is still a fool", as they say

I'm with Julius on this one for the first part - without a proper understanding of the concepts, the best tool won't get you anywhere.

On the other hand, a tool like Compliance Calibrator can do two things for you:

- structure your efforts - it's much less about the tcodes and the objects, it's about mapping them to the risks and defining mitigating controls

- automate discovery. Once you've defined the issues, it's still hard to find them in the system, as they can appear in many disguises.

Frank.

Former Member
0 Kudos

Hello Chris,

I understand you problem at the time auditing SAP. Some time you need to repeat the audit for few transactions to 100's of transactions. And not using any tool for such repetitive work will take long time to audit. And its very difficult to repeat the steps for all transaction code on RSUSR002 table and audit them if you have to work on 1000's of transactions and SOD. I am not user but USOBT_C may help u upto certain extend I guess....but I am repeating I am not sure. And I think Virsa is a costly issue. I work on eQSmart tool of deloitte which almost doesn't need any training and is designed specially for such audit requirements. It will help you to get report as you want and its very cheap as well. I am not sure of the price etc...u can contact help desk referring me. Good Luck.