suppress field value

[Former Member]

Hi all,

is the possible to suppress select statment on base level for some tables, for developers .

If developer select table,

he must have empty return !!!

situation is in payroll .

[christine_evans]

>

> Hi all, 
> is the possible to suppress select statment on base level for some tables, for developers . 
> If developer select table, 
> he must  have empty return !!! 
> situation is in payroll .

Are you talking about using SE11 / SE16 to query a database table or stopping a SELECT statement in a program from bringing any data back? If the former, if a user has authority to use SE11 I don't think that you can stop them from querying any table. If the latter, restrictions would have to be built into the program.

In the database itself, you can restrict table access by the use of grants. But SAP doesn't use these for security. As far as I can see, in a SAP database select, insert, update, delete grants are given to everyone on all the SAP tables (except for system tables) and access is controlled entirely at the application level. But I don't do BASIS so I could be wrong about this.....

[former_member156446]

Developer generally have SAP_ALL authorizations... to cannot think of restricting in SAP... check with DBA of the back end... may be he can find a work around.

[Former Member]

The standard data browsers will check authorization object S_TABU_DIS when the user uses the transaction - see [SAP note 26909|https://service.sap.com/sap/support/notes/26909] .

But that is largely irrelevant for developers because they can create their own data browsers, or even their own development workbenches... which make other checks or none at all... - see [SAP note 13202|https://service.sap.com/sap/support/notes/13202] .

In higher releases, there are stricter syntax checks when accessing tables - and I suspect that some future release those checks might throw errors and be extended to the program runtime, and not just the SLIN and code inspector checks as we know it.

So your options are to restrict authority and to do code reviews (QA steps) before being released into systems with production data in them.

Cheers,

Julius

[Former Member]

Brilliant Julius Bussche !!!

ye we can check all programs before production in dev system they don have valid data,

interesting stuff is code inspector checks , I am not sure is it a possible to create syntax error on specify tables, because it is in kernel and sycheck is .exe

Best regards.

[Former Member]

> situation is in payroll .

HR is tricky and it is not just table security...

Some tips:

- Use SE54 to isolate critical infotypes (14, 15, 08, etc...) into a more exclusive table group.

- Ensure the application authorizations P_* are correctly restricted.

- For structural authorizations, ensure that SAP* has a dummy PD profile.

- Restrict S_RFC authorizations, as these can expose the PERNR locally or read a table without the checks.

- Ensure no RFC connections from non-production to production systems, and that the RFC users are restricted in their authority.

- Restrict developer rights (including also display authority for S_DEVELOP in production!)

- No debugging in production - not even display.

- Restrict the ability to schedule jobsteps in foreign user names, and the authority which those SYSTEM users have.

- Restrict the ability to create transport requests in production, and SCC4 client settings to block client copies.

- Review code and queries coming into production.

- Apply regular support packs, as released corrections document where the missing checks are...

- Protect spool files, application server directories and printer devices.

That should keep you busy for a while and cover the most obvious risks.

For the development checks, what you can do is force the code inspector before before the transport is released (there is a BADI for this) and also include certain critical objects in a black-list which will block the release of the transport as well. I am not logged on, but you should be able to find them with a search.

Of course a QA step with a qualified human code review by a different person is always the most secure way, but can cause bottle-necks (particularly during the project phase).

Cheers and good luck,

Julius

Edited by: Julius Bussche on Mar 20, 2009 1:19 PM