Restriction of configuration and data migration transactions

[Former Member]

Dear Forum,

I'm currently reviewing SAP profiles in a Retail company and I've found many end-users who have access to the following transactions: SPRO, SCAT, LSMW, SQVI, etc. ¿How can I restrict it? ¿Is it possible to use authorizations? ¿Which objects should I use?

Best regards,

Javier

[Former Member]

Javier,

The easiest thing to do is remove the t-codes. But for each t-code there are relevant auth objects that control the functionality of each transaction. I would look in SU24 for each t-code and see with auth objects are proposed and restrict each object accordingly.

[HuseyinBilgen]

Hi,

First of all, you've to check the users Roles and Profiles. You can use SUIM TCODE for analysis. There , you've to find from which roles/profiles are these TCODES comes? Then you've 2 options:

1. Remove the TCODES (the ones you mentioned) from the roles/profiles they exist.

2. Create new roles (via PFCG) and give tcodes/area menus but remove the above TCODES. Then remove the users roles and give the newly created ones.

[Former Member]

Hi Javier,

Malcolm's advice is sound. 

Before you do anything establish why users have access to the transaction codes.  It may be that they are misguidedly using them to support a business process which may grind to a halt if these are removed without providing an alternative to ensure that the process operates.  It could be that they have all been assigned an admin or data migration role and the answer is to remove this role rather than individual transactions.

Classifying the transactions can help focus your efforts. 

SQVI has a data leakage and inappropriate reporting risk but will not allow mass changes to data.  SPRO is only any use if users have access to change the tables behind it and the system is open to config changes (or the table settings permit).  I assume that if you haven't already then you will review tcode and auth object combinations to focus on what is executable & highest priority. 

SECATT and LSMW may be restricted to certain cases and be used to only upload certain bits of data (like pricing).  That is not to say that they aren't without risk but they only allow automation of what users already have been granted access to.

If in doubt it is worth enlisting the help of someone within your team (or client) who has role and user management experience who can advise of the implications of the actions which will be performed.

Good luck