SAP Query Security – A Simple Case Study

The SAP Query component in R/3 provides a way of generating simple reports without any actual coding. From this standpoint, it is similar to the Quickviewer (transaction – SQVI) but more powerful and correspondingly a little more difficult to master. A full description of this great tool is beyond the scope of this article. Instead, my intention is to concentrate almost entirely on the security features for SAP Query and demonstrate how we can use the basic concepts of security to segregate a process chain into clear roles and responsibilities. This is the basic job of an security analyst during the all important phase of security design.

Queries are reports which can be configured by mostly drag and drop operations though a graphical editor to retrieve data from the data dictionary tables. The SAP Query component consists of three main transaction – SQ01, SQ02 and SQ03. SQ01 is the transaction for Query maintenance. It allows us to create, update, delete, display or execute queries.

Queries are not directly defined on tables but use an intermediate object called an Infoset. An infoset can be defined to be a table join or as a logical database and contains the sum total of data which the query defined on it can potentially access. SQ02 is the transaction for infoset maintenance (and display).

The final link in the chain is SQ03 – the transaction for maintenance of query user groups. Unlike many other SAP components ( and like many other ones), security for SAP Queries is not entirely controlled through roles and authorizations. To access a query, an user and and the infoset for the query must be assigned to the same query user group. Please note that the user group for queries is in no way related to the user groups maintained as part of the user master record.

So now, that we have had a brief introduction to the SAP Query transactions, lets turn to the problem of securing this application. Security for the SAP Query application is controlled through the authorization object S_QUERY. The object as the single field Activity (ACTVT) with only three possible values, 2 (change), 23 (maintain) and 67 (translate). Of these activity 2 is needed to change queries, infosets, user groups while 23 is needed for maintaining user group assignment. Also access to SQ02 or SQ03 is not possible without access to 23. Finally, a person with 23 can actually access queries belonging to other user groups without having use SQ03. Its important to note that unlike most other authorization objects, S_QUERY doesn’t have activity 03 ( display) as S_QUERY is not checked during display or execution of queries. Other than S_QUERY a user would also require some form of basic access like S_TABU_DIS for checking access to the actual data retrieved from the tables, access to change layouts (S_ALV_LAYO), exporting retrieved data to excel (S_GUI), etc. In a typical enterprise we might want to segregate access to SAP query to three distinct business roles

• Query Executor – These are the reporting users who will be responsible for actually running the queries and interpreting the results. These are normally business users and are not expected to update/change queries.
• Query Creator – These are the power users who have the business knowledge to actually design/create queries and subsequently change them depending on user requirements. They might also need to maintain Infosets.They should also be able to execute the queries to check that the designed queries output correct data. However, since the query executor is still a business user, as security administrator we would not want to give them the responsibility of assigning user groups and control who gets what!
• Query Administrators – These are the support personnel who are responsible for maintaining the user group mapping. These users would not be maintaining query design even executing queries.

With the above requirements in mind, let us design three roles for the three separate classes of people.

• Query Executor – Need access to SQ01 but not S_QUERY. Also should have access to data they are trying to retrieve (S_TABU_DIS).
• Query Creator – Access to SQ01 and SQ02 as well as S_QUERY (both activities 02 and 23). Should also have access to table data through S_TABU_DIS. Should not have access to SQ03.
• Query Administrator – Access to SQ03 as well as S_QUERY(both activities 02 and 23). No need for access to table data.

Thus we have successfully mapped business roles to SAP roles. This is the final goal for all security analysts. The only problem is instead of a single authorization object and three tcodes we are working on thousands!