Question:
Hi all,
Development team are building many custom maintaenance transactions to replace some standard SAP transactions, but most of them just have the object for S_TCODE.
From security point of view, some of the custom transactions should be restricted on some authorization value (e.g. cost center, etc.). If there is only the object like S_TCODE, how can we restrict? In addition, is there the way to look at the SU24 to tick the check/maintain to let authorization check runs for some specific authorization? If there is really no other objects to restrict, can we return to Development team to ask them re-do?
Thanks
Steven
Answer:
The development team need to put AUTHORITY-CHECK statements into the code and the code logic needs to respond appropriately to the auth check.
Adding stuff in SU24 for custom code will not bring in authorisation checks - they have to be in the code.
Your developers will have to do their job properly & re-do it.
Answer:
In your development process an essential step should be that during the design stage op any program the security team should be consulted about what security to build in the ABAP.
Answer:
Got you. Thanks.
Answer:
To help you in the process of getting this installed in your project i added the document
In general security should be an integrated part of building new reports/programs.
In an ideal situation the process should be somehow like described below.
1. Normally the request for a program comes from business end users.
2. This request will be translated, by a functional consultant, into a design description which serves as the input for the developer.
3. An integral part of this design description should be:
a. The request to add the new program to a custom transaction.
b. The functional security considerations being:
i. Should there be restrictions on who in the business is allowed to run the program ( which business function is allowed or denied access)
ii. Are there any Organizational restrictions required.
c. The request to assign the new transaction to a (new or existing) role.
d. A test description, with the role(s).
i. Positive testing with the aforementioned roles, (program runs and only on the OrgLevels assigned)
ii. Negative testing : It is not possible to run on other OrgLevels, no other users (to whom the aforementioned roles are not assigned) can start the program .
e. The process as described can be made easier to follow by have the security step in a template design document that all should use.
4. The security team should translate the functional spec as described in 3 into technical specs.
5. Point 3d should be part of the sign off of the program.
Usually the above is hard to get started as most developers do not like to be restricted this way. But remember that the security team is in the driving seat here as they usually also control access to the test environment. So forcing the above on developers can be easily done by restricting anyone in the test client in such a way that they will not be able to start new transactions/programs without being assigned the new role(s). Allowing wide access such as SAP_ALL in a test client is deadly for trying to build the right security into new programs.
Auke Visser, 25-10-2006