Data protection in SAP also passes through the control of the transactions.
How does SAP control their execution? What should you pay attention to when defining custom transactions in SAP?
SAP authorization flow
What happens when you initiate a SAP transaction? Quanto avvii una transazione in SAP cosa accade? What controls does SAP execute at the start of a transaction? Not all the activities carried out concern SAP security.
- The existence of the transaction is checked, in the TSTC table, where all SAP transactions are defined (more than one hundred thousand exist since the ECC 6 release)
- The blocking state of the transaction is checked, through SM01 transaction or in the most recent releases via SM01_CUS o SM01_DEV, read here what SAP Security transactions to have in favorites.
- Authorization checks begin. It is checked if the user has the transaction and its authorizations. Technically it is verified if the authorized object S_TCODE, TCD field contains the transaction that the user is trying to execute. This check is exceeded if the result is positive.
- There’s no guarantee you can execute the transaction. An additional "header transaction check" takes place as a result of the above check. Each transaction can contain an authorization object in its definition, necessary to execute that transaction. This parameterization is visible in transaction SE93.
- This isn't over. Following the execution of the transaction, if there are authorization controls in the ABAP code developed and linked to the transaction, or statement ABAP AUTHORITY-CHECK, then those must also be exceeded. Each SAP transaction can contain from one to several dozen authorization objects. There are more than 3000 authorization objects in the latest releases.
Here below is the graphic representation of the above. See also here for more details.
How to manage new SAP transactions?
The definition or release of a transaction, especially custom ones, should follow a specific process. Consists of different documents (or a single document made up of different sections). What could these sections be and what should those contain?
Issues Paper
- Issues Paper, the document that describes the functionality required starting from the requirement of the business. What are the focus points?
- Do you always check there is something in the standard that can meet the requirement before starting head down on custom? Are you sure this audit is in place?
- Is it the right tool? It may happen that SAP is misused for example by developing very heavy queries or reports. Systems designed to handle a lot of data should be used. Read here how SAP reports should be managed.
The Security and Compliance Process
- Security evaluation process, in this case there are several aspects to consider
- What is developed is checked before being imported into production? In this case not only the security aspects are important but also:
- Performance
- Code's robustness
- Maintainability over time
- SOD Process. Does the transaction concern SoD relevant processes? Then it must be identified where to insert it into the matrix. Who carries out this audit in your organization?
- GDPR Process. Does the transaction act or show personal data, what and how are they managed? The data minimization principle is applied (art. 5 del GDPR)? SAP Data Masking should be performed?
- Functional security requirement description. What controls should be included in the transaction? Does the transaction modify budget data? Then the standard or custom authorization objects to be managed must be defined. No authorization object to insert, also this choice must be documented.
- Developed code control
Where do you store your custom transactions documentation?
- Excel o Word Sheet?
- Solution Manager?
- Other?
According to our statistics 40% of custom transactions developed, after 5 years is no longer used, click here to find more about custom SAP.
What should be verified?
The are some features that final users should not have. Each performed activity from final users should "pass by" a specific transaction. What could be critical and bypass SAP transactional controls?
- Issuing transactions to end users for the arbitrary execution of programmers, for example transactions SA38, SE38 or similar.
- Issuing transactions to end users for direct display of the SAP database, for example SE16 o SE16n, SE11, SE17 or similar. This could also be a problem for GDPR.
- Issuing transactions to end users as SM30 o SM31 to amend SAP tables.
- DEBUG System functionality, especially in modification mode
Blog post originally translated from: https://www.aglea.com/blog/la-protezione-dei-dati-in-sap