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

Question

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 ?!

Answer 1

+"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