This is a continuation of the many different articles on this blog around security around tables. However, the articles till now has concentrated on the different methods provided by SAP to restrict access to tables. Today’s article on the other hand will talk about a common method of accessing tables, the security implications for this form of access and how we react as security consultant when faced with requests for this form of access. Continue reading “SE16N and SAP_EDIT”
Few aspects of SAP Security are as well explored by Security Consultants as security for Tables. SAP already provides a host of objects for controlling access to tables – S_TABU_DIS for security through table authorization groups, S_TABU_CLI for client independent tables, S_TABU_LIN for row level security and S_TABU_NAM for security individual tables. The use of these different authorization objects have been documented elsewhere on this blog and I would not want to discuss any more of them here. However, lets take a different approach and think about a way to secure individual fields for a table or in other words column level security for a table. One of the ways to achieve these is through the use of database views. Please note that creating database view is not the job of a security consultant and in all probablity you would not have access to do it in any system. However its good to know of the option if ever the need arises. Continue reading “Database Views For Tables”
We have already looked at the other SAP authorization objects used to secure tables, S_TABU_DIS, S_TABU_CLI, S_TABU_NAM. We end our discussion on table security with the one remaining object – S_TABU_LIN used for Line Oriented Authorizations. This object can be used to provide row level access control when accessing tables through standard tcodes like SM30 and SM31. I have purposely kept the discussion about this object for the last as its the most complicated to use by far and needs configuration changes in addition to role updates. Also note that S_TABU_LIN is always checked in addition, and not in place of, the check for S_TABU_DIS.
To use S_TABU_LIN in our authorization concept, the first step is to configure a Org Criterion through the SPRO transaction. We can use the org criterions provided by SAP or create our own criteria. The path for configuring org citeria is shown below.
We chose the first of the two options, “Define Org Citeria”. We create a new org citerion called ZMOLGA. The check box, Table-ind should remain unchecked as the new org criteria would only be checked for tables maintained by us and not all tables.
With the new org criteria selected in the screen, we double click the attributes option. This screen allows us to create the attribute for the org criteria. Further we can set the attribute to be the 1st to 8th attribute. The 1st to 8th attribute are actually the authorization fields present in S_TABU_LIN. Though in the present example we will just create a single attribute and set it as the 1st attribute, SAP allows us to create 7 other attributes for the same criterion.
Finally with the attribute created we just need to set the tables/views which will be checked for the org criteria. We use the view V_T510F_B in our example. Currently SAP only allows us to enter one table or view per attribute. The direct result of this limitation is that we need to create a new org criterion for each table we want to secure through S_TABU_LIN.
We can now save our entries. The system will prompt for a transport request to contain the changed objects. We have now successfully created an org criterion. However, we still need to activate it before S_TABU_LIN and the org criterion will be checked during table access. Activating the criterion is simple. We just check the box and save our entries.
Once this preliminary configuration is done, we are free to use S_TABU_LIN in our roles to secure tables based on the Org criterion. Since our criterion ZMOLGA is based on the MOLGA field of the view V_T510F_B, we can actually restrict access to only certain rows of the table depending on the value of the MOLGA field. For example the authorization below will allow the user with this role to change rows for the V_T510F_B view when MOLGA value equals 10.
It is important to remember that S_TABU_LIN will only be checked for the standard SAP table maintenance transactions. Thus if we have some custom code accessing tables, row level security is not going to work for them. Off course nothing is stopping the developer in adding a authority-check statement for S_TABU_LIN in this case.
As security consultants, we are often asked to secure or grant access to SAP tables. So most of us are already aware of the authorization objects used to secure tables, S_TABU_DIS, S_TABU_CLI and S_TABU_LIN. Out of this, S_TABU_DIS is the one that is needed for all tables. S_TABU_DIS secures tables on the basis of activity (02, 03) and authorization group for the table. S_TABU_CLI is needed when a user needs access to maintain client independent tables. S_TABU_LIN is meant for Line Oriented Authorizations which allows us to authorize indivdual rows of a table. However, till now security for tables was based on the authorization groups. The limitation with authorization groups is the lack of granular security on individual tables. Once a user has access a particular table authorization group, the user can access all tables linked to the authorization group. Technically it is has always been possible to create a new authorization group and link the offending table. But this soluation came with its own problems, specially when adopted for standard tables. For example a lot of tables are accessed to by standard tcodes. Changing authorizations groups for such tables can potentially impact the functioning of tcodes calling them. Also, the new authorization groups might be overwritten by SAP service packs so this becomes a recurring check for upcoming upgrades. Fortunately SAP in its latest service packs has come up with a new authorization objects for securinf tables, S_TABU_NAM. S_TABU_NAM promises to overcome the limitation of the current S_TABU_DIS object.
As can be seen above, the object has two authorization fields. The first is activity meant to restrict access to just display (03) or update (02). The other field TABLE takes the actual name of the table and allows us to restrict/provide access to individual tables overridding access for authorization groups.
I am copying the relevant SAP code section from the standard function module VIEW_AUHTORITY_CHECK. This FM is called by all standard table access transactions like SE16, SE16N, SM30, SM31, SM34, etc.
As you can see from the code above, VIEW_AUTHORITY_CHECK has a initial check for S_TABU_DIS. Only when the S_TABU_DIS check fails, is the new object S_TABU_NAM checked. So all the existing checks and the security roles built around them need not be updated as a result of the new object. It just provides us with an additional layer of flexibility for building our checks for tables. An example scenario might be to give display access to all tables with authorization group SC but restrict write access to just the T77UA (which shares the same auth group).
The PRGN_CUST tables contains entries for a number of switches which can affect the default behavior of various security transactions. To move away from the default behavior, we need to create the entries for the switches with the appropriate values. The list of allowed entries keep on changing depending on the version of SAP being used. Hence, the best way to find the allowed list of values for your system is to open up the table in SM30 and try to enter a new entry. A search for the possible entries will display the allowed entries and also the SAP notes which describe their use.
The screen below, gives some of the possible entries for a system on SAP R/3 4.7.
The names of most Security tables begin with USR, AGR or UST. Here are a few of the most common ones
- USR02 – Users with logon data
- USR04 – Users by authorization profile assignment
- USR05 – Users by user parameters
- USR10 – Profiles with authorizations
- ARR_1251 – Authorization data for roles
- AGR_1252 – Organizational data for roles
- AGR_USERS – Roles assigned to users
- AGR_PROF – Profiles defined for roles
- AGR_HIER – Menu for a role
- AGR_TIME – Change date/time for a role
The Data Browser (transaction SE16) allows us to display (or maintain) transparent tables from the ABAP Data Dictionary. Its an invaluable tool for reporting as data from tables can be directly accessed without searching for reports which return this data.
In the example below, we use the table browser to display data from the “AGR_USERS” table which stores role to user assignment information.
The selection screen of the table, allows us to search on the basis of user id, role or/and validity dates. The selection options are basically controlled by the Settings menu.
The list output displays data filtered on the basis of entered selection criteria.
In many productive clients, SE16 is restricted from users as, if not restricted at the table level, it can give access to a lot of sensitive data. I personally believe in a compromise where certain technical users do have access to the t-code but restricted to display of the tables which is needed for their reporting needs.
Like the Data Browser (SE16) reviewed in the last article, Quickviewer (transaction SQVI) is very useful tool for quick and dirty reporting through Adhoc Queries. The advantage of using Quickviewer is it ability to perform table joins enables us to display data from multiple tables.
In the example below, we create a query to return the tcodes executable by an indivdual user. We name the query “Z_USER_TCODE” using table join.
On clicking the check button, we get to the design window shown below. We insert the three tables which we will be using for our report and add graphically add the join conditions as shown below.
Once the data sources and join conditions are set up, we need to check the fields appearing in the selection and list output. We have the option or changing the field order of both the selection and list screens or even the sort order of the resulting data.
We now save our query and click the execute button. In the example, we filter the query to return the tcodes for user “test_user”.
The output returns a list of tcodes that can be executed by the user and also the role which contains the tcode.