Data retrieval is normal in a management system. But what are the tools available in a SAP ERP system? Is it correct reporting in a transactional system? 

What are the security impacts in doing corporate data reporting in SAP and how can they be mitigated? What is the SAP query survival manual? 

What are the ways to report in SAP ERP?

There are several, depending on the needs, among the main there are the following:

• SAP Query (Transactions SQ00, SQ01, SQVI), attention, in SAP HR module there are additional specific reporting transactions
• Transactions running programs to extract SAP business reports

Is the SAP management system the right reporting tool?

We often clash with the question above. There are two distinct database modes:

• OLAP On-Line Analysis Processing
• OLTP On-Line Transaction Processing

The first designed to perform reporting, while the latest for data processing (not just for reading)

In the SAP product family there are many reporting solutions, for example SAP BW/BI Business Warehouse/Business Intelligence, SAP Business Objects and many others. Obviously, there are also third party software.

The conclusion is that if you need to analyze many data and produce many views (for each department), maybe you need to have a tool designed to do that job and you can’t use the company ERP. The latter has tools for reporting but is not designed to do this work. 

Reporting security in SAP ERP

Beyond the above said, and taking up the title, one of the most critical security aspects is represented from the queries SAP. There are actually no display-only transactions in this area. 

Everything is controlled by an authorization object called S_QUERY.

This object, when present in user's permissions, determine whether SAP query transactions (SQ00 ed SQ01, see the following image), are display-only or allow you to change the queries' content.

Not only. The SAP queries' module has inside a small authorization concept in addition to that normally handled through roles (then through the use of the SAP generated profile, PFCG transaction).

This authorization model allows to manage query user groups (through SQ03 transactions).

Let's make an example

1. I want to enable a user to display only queries, what can I do?
   • Authorize transactions by deactivating the S_QUERY object. This allows to authorize transaction in read-only mode. 

However, this is not enough.        

Because if I disable the S_QUERY object I must include the user in one or more defined user query groups (this allows the user to see and execute queries in that/those groups). Usually query groups are structured by SAP module or corporate function.  

Not so convenient as management! But this isn't over! 

Once the user has been enabled to transaction, disabled the authorized object S_QUERY and included the user in the appropriate group, you will then assign the correct authorizations on the tables that the queries call. 

This occurs through the authorization object S_TABU_DIS/S_TABU_NAM (where a group of tables or individual SAP tables can be authorized).

Therefore the tables to be authorized won't have a dedicated transaction, this authorization must be issued user by user or released by assigning it to the SQ00 transaction (granting users more permissions than expected).

Further consideration, read the note OSS 24578 - SAP Query: Authorizations.

What are the solutions to secure ERP SAP reporting?

The most effective solution we have seen over the years is:

1. If possible, equip yourself with a system to carry out corporate/directional reporting (avoiding doing so in the SAP ERP system). In addition to the design and performance aspects of the system, there are additional authorization specificities to better segment and segregate data, in the reporting context. Not present in a transactional system.
2. In the event that, as above, won't be possible, define for each query a custom transaction that executes the program generated by the query itself: 
1. Yes, it seems expensive. But actually, it isn't in terms of management and governance as it allows you to:

• Avoid managing query user groups (it isn't a small thing)
• Assigning correct table reading authorizations to individual transactions that require it
• Having better governance related to who sees what (in GDPR optic this could be important)
• Simplify the issue of query-related authorizations so they become transactions like all the others and therefore can be inserted in the relative job role
• Yes, you have to define an extra custom transaction, but it is only a call for a program (which is actually a query) 

How to handle queries in SAP then?

• Create a custom transaction via SE93 transaction (remember to give a naming to custom transactions, especially to understand the scope and the operability)

• Identify the program name (query), through SQ00  Identifica il nome del programma (query), tramite SQ00 following the path shown below (Query -> More functions -> Display report name)

• Assign the identified program in the SAP transaction definition
• Remember to assign all permissions on used tables, from query to newly created custom transaction 
• Also remember that queries must be transported from development to production  

Do you have to secure a system? There are not only queries, but many other SAP security aspects to manage and deal with. 

Blog post originally translated from: https://www.aglea.com/blog/sap-query-security