Welcome to SAP- Security Tutorials. The objective of these tutorials is to gain an understanding of SAP- Security concepts. In addition to the free SAS tutorials, we will cover common interview questions and issues in SAS.
Introduction to SAP
This site basically deals with SAP security. But before we get into the details of security it would be probably beneficial for the absolute newbies among us to first get a basic idea of ERP software in general and SAP in particular. This beginning article tries to do just that. So experienced ones........please feel free to skip ahead to the next posts.
SAP (Systems, Applications, and Products in Data Processing) is an example of ERP (Enterprise Resources Planning) software. An ERP system a computer-based system to manage the internal and external resources for an enterprise. It might have various components to help in business processes like procurement, sales, accounting, human resources. Some of the major vendors for ERP software are SAP, Oracle, PeopleSoft, JD Edwards. Since these pages deal with SAP security, let us consider a business process implemented in SAP. A user typically uses the SAP GUI/Login pad to launch the login screen for a particular SAP instance.
SAP Logon Pad
At the next screen, the user logs in to the SAP system using his unique user id and password
Each business process in SAP is typically started using a transaction code (code) or by following a menu path. We consider the HR transaction PA40 (Personnel Actions) which is used to hire a person into a position into the enterprise.
Starting a transaction through its tcode
On the initial PA40 screen we enter the date from which we want to hire our new employee, select the hiring action, and click the clock icon (execute).
PA40 Initial Screen
On each subsequent screen, we enter the relevant information, like personal data, organizational data, address, tax information, basic salary, bank details and click the save button.
Create Hiring Action
PA40 Create Hiring Action
Create Personal Data
PA40 - Create Personal Data Create Organizational Data
PA40 - Create Organizational Data Create Address
PA40 - Create Address Data Create Bank Details0
PA40 - Create Bank Details Final screen showing successful hiring of Mr. Abap Developer with a personnel number of 2
PA40 - Final screen showing successful hire.
User Master Record
A valid user master record must exist for all users accessing the SAP system. The user master is accessed through the transaction SU01 (there is a separate version of the tcode, SU01D for display).
SU01 - User Maintenance There are a number of tabs for maintaining different data for the users. Some of the more important tabs with the data they contain are given below. • Address – First, Last Names, Department, Email, Telephone, Language
User Maintenance - Address Data • Logon Data – Password, User Group, User Type, Validity
User Maintenance - Logon Data • Parameters – User Parameters
User Maintenance - Parameters • Roles – These give access to the differenet function with the SAP system
User Maintenance - Roles • Profiles – Lists the profiles corresponding to the role entries
User Maintenance - Profiles • License Data – License type for user. This field is evaluated as part of license audits.
Roles & Authorizations:
Access to SAP system is assigned to users through roles maintained in their user master. In this article, we explore how access to the SAP system is extended to users through roles. We also talk about the related concepts of authorization objects and authorizations.
The transaction to create/maintain roles is PFCG. Let's create a role in PFCG and try to understand the various options available to us therein. We name the new role “ZTEST_HR_ACCESS” and click the “Single Role” button. (Note that you can follow any naming convention for your roles as long as they do not begin with SAP or /).
Role Maintenance (PFCG) – initial screen:
Inside, PFCG, there are again a number of tabs that need to be filled with data as part of the role creation process. We start with maintaining role name and description. There is also the option of specifying a parent role as shown in the diagram below. A child role inherits all tcodes and authorizations from its parent except the organizational levels (we will discuss org levels in a later article). The Long text field might be used as an audit log to track the background behind creating a new role.
PFCG – Role Description In the menu tab, we maintain the tcodes that the role will have access to. In addition to tcodes, we can also add reports, queries and URL. There are lots of options to build the menu of a role. You can copy from an existing area menu defined in SAP, copy from another role or import from a text file.
PFCG – Menu Once we have maintained the menu for the role, we go into the Authorization tab. We have an option of generating a profile name or following our own naming convention. I would suggest following a naming conventions of our own (even though I have used the generated profile name in the example) as the profile name can help in subsequent reporting on authorizations. We save the new profile and click either of the two highlighted buttons, Change Authorization Data & Expert mode for profile generation to get into authorization data maintenance.
The next screen is for maintenance of authorization data. The different color codes define distinct security specific objects/concepts. Lets discuss these below
- Blue Line: Role – In our case its the new role which we have just created “ZTEST_HR_ACCESS”.
- Pink Line: Authorization Class – These group Authorization Objects which protect similar application components.
- Green Line: Authorization Object – Though called an object, an authorization object is more akin to an OOP class. Its a template or structure with a number of fields each of which needs to filled up with appropriate data to allow access.
- Yellow Line: Authorization – This is an unique instance of an authorization object with values specified for its different fields. Carrying the OOP analogy forward, an authorization is actually similar to an object.
Off-white Line: Authorization Field – These are the unique fields within each authorization object.Different authorization objects will have different sets of authorization fields.
To understand how security works at the application level, we take the example of the S_TCODE object. To start a transaction, a user needs this authorization object in his user buffer with the the transaction maintained as a field value. In the example below, a user with the new role would be able to start transactions PA30, PA40 and SU53. However, starting a transaction is only the first level of check, any number of different authorization objects can be checked at each step of the transaction. These checks are for presence of individual authorizations in the user buffer.
During role maintenance, we maintain all the open field values (marked by yellow triangles) so all authorizations become green. Once finished we generate the role, by clicking the button with the a circle and red and white quadrants. This final step is the most important step in the entire process as this creates one or more authorization profiles for the role. It is actually the authorization profiles present the user buffer that give access to SAP applications. The role is just helps in easier maintenance of authorization profile. Even now, its technically feasible to directly modify authorization profiles but is strongly discouraged from SAP. Once generated, the role can be assigned through PFCG itself or through SU01.
We discuss the link between transactions and authorization objects. This will in turn help us to understand how the authorization objects are pulled into the role during maintenance.
Organizational Levels” (Org Levels) as opposed to authorization fields is another of the core concepts that we come across while creating roles in PFCG. We can access the organizational level values defined for a role by clicking the “org level” button in the main toolbar within PFCG. In the role below, we see Org Levels like Company Code, Purchasing Org, Purchasing Group, Sales Org, Division, Plant, etc.
SPRO - E Its possible executing all roles w impacted Enterprise StAtable to change the program which Conrad roles. Also Ematructuree an authorized in m PFCG_O ain the org fie certain auth ail:‐ Srinivasa zation field t ORGFIELD_eld it should fields like A26 Narravula@to an org lev_CREATE.d only be run Activity canN.S@gmail.comvel for the pu. However, sn after a thorn never be chRINIVASULUurpose of sec since this prorogue analysand to anCHOUDARYcurity program impacts sis of all n org level.
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 a security analyst during the all-important phase of security design. Queries are reports which can be configured by mostly drag and drop operations through a graphical editor to retrieve data from the data dictionary tables. The SAP Query component consists of three main transactions – SQ01, SQ02, and SQ03. SQ01 is the transaction for Query maintenance. It allows us to create, update, delete, display, or execute queries.
The final link in the chain is SQ03-the transaction for the 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 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, let turn to the problem of securing the application. Security for the SAP Query application is controlled through the authorization objects S_QUERY. The object as the single field Activity(ACTVT) with only three possible values, 2(change),23(maintain) and 67(translate).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 chang layouts (S_ALV_LAYO), exporting retrived 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 Info sets.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.