Database Views For Tables

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. 

Most of us with an exposure to database concepts with remember the concept of views for tables. I am copying over the definition from Wikipedia below “In database theory, a view consists of a stored query accessible as a virtual table in a relational database or a set of documents in a document-oriented database composed of the result set of a query or map and reduce functions. Unlike ordinary tables (base tables) in a relational database, a view does not form part of the physical schema: it is a dynamic, virtual table computed or collated from data in the database.” Following this definition, it should be possible to create a view of a SAP table to include a subset of fields from a table leaving out sensitive columns. The transaction to create a view in SAP is SE11 (ABAP Data Dictionary). Screen below shows the start screen of the transaction. In the example below we would be trying to create a database view of the PA0002 table to blank out the personal data fields.

Since the new view is a development object, its name should begin with Z or Y. We choose the name YPA0002 and click the create button. A pop-up screen comes up asking us to choose the view the type of view. The options are Database View, Projection View, Maintenance View and Help View. Since our view is simply a subset of an existing SAP table with a few fields blanked, we choose the option of creating a database view. The screen opens up where we input the view description and table from which the view derives its data (PA0002).

Next step is the most important of all as here we would need to add all the fields from the original table which would form part of our view. In the example below I have chosen some random fields without selecting any of the sensitive fields like SSN or Birth Day from PA0002.

In the maintenance status tab, we select the option read only as the view would only be used to display data. At this point we save our changes. We would get a prompt to add the changes to a transport for final import to the production system. Before we can use the view however, we would need to activate it (menu option View> Activate). Assuming that there were no errors in our development till now, SAP activates the view. If there are errors we get warning/errors which we need to correct before the object can be successfully activated.

Once activated, the contents of the view can be displayed by standard transactions like SE16 as shown below. As you will notice only a subset of the complete fields in PA0002 table are displayed. In comparison, the original table (as given in the second screenshot) display many more columns.

Our view is now created and tested to display only non sensitive columns. However, the job as yet is only half done. The last step of the process would be to create a variant transaction for SE16 which calls the view that we have just created. You can refer to the post on SE93 for the setps needed to create a new tcode.