Can you limit or log the download functionality (authorization check)?
Security requirement
Preface
Basically you cannot prevent a user from saving data from the display to a file. On the PC, the user has the option to execute this as a screen capture (cut-and-paste), without informing the R/3 System.
Therefore, there is currently no authorization check up to Release 3.0B. There is also no logging.
The first technical preconditions for the executing of an authorization check for a download from the R/3 System were developed on customer request in Release 3.0C. This prevents a fast download of large datasets. However, an authorization check in the applications is not yet contained in the 3.0C Standard System.
Basically, you can call the download in two different ways:
- a) programmed in the application, that is, the download is executed by calling the function modules 'DOWNLOAD' or 'WS_DOWNLOAD'
- b) as a list download via the menu path System -> List -> Save -> Local file
Here, the authorization check is always contained in the application, as the corresponding authorization objects are known there. From 3.0C, you can also (as an alternative) use function module SET_DOWNLOAD_AUTHORITY to register a form routine, which executes some kind of check to see if the download may be carried out and, if necessary, logs the download.
You can use this to protect the list download (b), but a modification in function module 'DOWNLOAD_LIST' (2.x) or 'LIST_DOWNLOAD' (3.x) is to be preferred. A customer-specific check and logging can be implemented in the modification (from Release 3.0C), or the check routine, which could also execute a logging, can be registered. You can also completely prevent the download this way.
...
CALL FUNCTION 'SET_DOWNLOAD_AUTHORITY'
EXPORTING
FORM =
PROG =
FORM
...
ENDFORM.
In the function modules, check whether FORM and PROG are set. If the answer is yes, execute a dynamic perform on the entered routine which is provided by the application and returns 0 or 1. In the case of 'NE 0', the error message PC013 is displayed and function module is exited with EXIT. A check and additional message handling is contained in the form routine.
The effect of the check is limited to the transaction that executes the call.
In addition to the behavior maintained for reasons of compatibility, a CUSTOMER FUNCTION 'EXIT_SAPLGRAP_001' (enhancement 'SGRPDL00') is implemented, that is called for every download - both business application-defined as well as with which general list download.
The function knows the following parameter:
IS_LIST_DL : is set if you are dealing with a list download
NO_AUTH_CHECK: is set if the application does not require a check.
You can use the following fields to find which list should be exported:
SY-TCODE transaction
SY-CPROG report
SY-SLSET variant
SY-TITLE title of the list
Make sure that a list can be protected elsewhere from the download (for example as a spool request, in a report tree or as an office document). If you call the download function afterwards, the fields SY-TCODE, SY-CPROG and SY-SLSET do not contain the values, which were valid during creation of the list.
If a download is rejected, the exception 'NO_AUTHORITY', which is intercepted in function module 'WS_DOWNLOAD' and results in the error message PC013, must be triggered.
This means that you can ensure that certain user groups can be excluded from the option of a download by activating and programming the customer function. You can either execute this by explicit programming or by a separate authorization object. In addition you can implement a TRACE mechanism.
Install the check against the authorization object S_GUI (or Z_GUI) as follows:
authority-check object 'S_GUI'
id 'ACTVT' field '61'.
if sy-subrc ne 0.
raise no_authority.
endif.
Creation of the authorization object S_GUI (or Z_GUI respectively):
Transaction SU21 -> Create
Object S_GUI
Object Class BC_A Basis: Administration
Text Authorization for GUI Activities
Fields ACTVT
Enter the authorized activity 61 for this object afterwards:
Transaction SM31 for table TACTZ
Generate entry S_GUI
Alternative 1) Create authorization object Z_GUI using field ACTVT. This is no modification.After the upgrade to 4.x you should set the profiles to default (S_GUI instead of Z_GUI). The user exit can be deactivitated after the upgrade.
Alternative 2) Create authorization object S_GUI using field ACTVT. This is a modification and results in a message during the upgrade to 4.x. However, you do not need to adjust the authorization profiles after an upgrade to 4.x. The user exit can be deactivated after the upgrade.
In addition to the solution as of 3.1I, the authorization S_GUI is implemented again, which checks the GUI activities and thus the list download (menu System -> List -> ...). Thus, this authorization object is generally not used for the business application-defined download function.
No comments:
Post a Comment