Sap Security+ Full+Material
Content
SAP Security in ABAP Applications
Applies to:
SAP R/3 release 4.6 onwards. For more information, visit the Security homepage.
Summary
This document provides an overview of the various processes involved in SAP security. Organizations worldwide are now recognizing the importance of security and are looking for experts who can handle this task for them. Projects today have separate consultants apart from basis consultants who handle SAP security specifically. The contents in this document are the learning from my current role as an SAP security consultant in my current project. Author: Subramaniam Iyer
Company: Infosys Technologies Ltd. Created on: 30 June 2009
Author Bio
Subramaniam Iyer (Infosys Technologies Ltd.) has been working as an security consulant for a Pharma Client. He is primarily an SAP certified MM consultant and trained in QM and WM. In his words: “I enjoy my work in security as my business process knowledge gives me an edge over the other basis consultants in understanding requirements set by clients.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 1
SAP Security in ABAP Applications
Table of Contents
Introduction to SAP Security...............................................................................................................................3 Brief Introduction .............................................................................................................................................3 Introduction to the SAP Authorization Concept ..............................................................................................3 Roles, Authorization object & Authorizations......................................................................................................4 Roles ...............................................................................................................................................................4 Authorization Object........................................................................................................................................4 Fields...............................................................................................................................................................5 Authorizations .................................................................................................................................................5 Profiles ............................................................................................................................................................5 Authorization Checks ......................................................................................................................................5 Composite Role...............................................................................................................................................5 Derived Role ...................................................................................................................................................6
Exercise .......................................................................................................................................................................6
Summary.......................................................................................................................................................11 User Administration ..........................................................................................................................................12 User Type......................................................................................................................................................12 Special Users in the R/3 System ..................................................................................................................13 User Groups..................................................................................................................................................13
Exercise .....................................................................................................................................................................13
User Information System...............................................................................................................................17 Summary.......................................................................................................................................................19 Troubleshooting & Maintenance.......................................................................................................................20 Introduction ...................................................................................................................................................20 Display Authorization Check: SU53 ..............................................................................................................20
Exercise: ....................................................................................................................................................................20
System Trace: ST01 .....................................................................................................................................22
Exercise .....................................................................................................................................................................22
Deactivating Authorization Checks: SU24 ....................................................................................................25 Summary:......................................................................................................................................................27 Sarbanes Oxley (SOX) Compliance – SAP Perspective..................................................................................28 What is the Sarbox Act or Sarbanes-Oxley Act ? .........................................................................................28 Segregation of Duties (SoD) .........................................................................................................................28 References........................................................................................................................................................29 Disclaimer and Liability Notice..........................................................................................................................30
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 2
SAP Security in ABAP Applications
Introduction to SAP Security
Brief Introduction SAP has done nothing less than change the entire systems landscape for enterprises. The benefits it can bring have led to widespread adoption across the globe. One of the key benefits SAP brings to an enterprise is the ability to integrate the data both within the enterprise, and between it and its partners / competitors. In many cases organizations today are both partners and competitors at the same time. Think two oil giants IOCL & IBP who have an upstream joint venture. These companies use SAP to integrate process between themselves for their mutual benefit. This ability to integrate, however, brings with it a particular risk – that of exposing their data to the un-authorized outside world. Entire companies have been built up around highly guarded intellectual property and process secrets ... and could easily fall if this was breached. Therefore, keeping the security of the organization intact is one of the vital aspects of any SAP implementation. SAP addresses all security issues by incorporating a Security module. Security in an integrated system like SAP R/3. Some of the key points that it addresses are listed below: • • • • • Authentication: Only legitimate users should be able to access the system Authorization: Users should only be able to perform their designated tasks Integrity: Privacy: Data integrity needs to be granted at all time Protection of data against unauthorized access
Obligation: Ensuring liability and legal obligation towards stakeholders and shareholders including validation
The scope of this document is SAP Application Security, which can be achieved through the concept of authorization. Introduction to the SAP Authorization Concept The authorizations to access data in SAP are granted and not restricted. This leads to the development of security access on the basis of the least privilege rule. It essentially dictates that a user will get no more access than has been determined necessary to perform a particular job or task that he has been trained for. A user is defined as a person who has access to the SAP R/3 systems, based on his functional roles and location. This includes not only end users in a productive environment, but also project and support users. A balance needs to be struck by the responsible business and technical experts when determining whether access should be restricted or unrestricted with regard to particular data and system functionality. In order to accomplish this, it is important to understand the associated risk attached to data (i.e. financial, operational, legal/regulatory, etc.) as recognized by the business and external controls frameworks, such as SarbanesOxley. The criticality of data should be understood in this context and decisions impacting access to data should reflect this position (i.e. what data should be generally accessible versus what should be restricted to a few authorized users only). The authorization for the execution of a particular transaction code does not necessarily mean that a user can actively maintain all data fields connected to this transaction. The company structure, the technical design of the SAP Security Concept, internal guidelines and external regulatory requirements contribute to the design of system access.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 3
SAP Security in ABAP Applications
Roles, Authorization object & Authorizations
Roles Roles were previously referred to as activity groups. Roles are nothing but a container for authorizations. A role represents a specific part of an employee’s job. The role itself is composed of different functions of the employee, which again is the sum of certain tasks inside these functions. Example: The job of a user Jack Dawson is the Head of the purchase dept. In his job he has different roles, such as being a buyer. One of the functions of the buyer is to create purchase orders. Job: Head of the purchase dept. Role: Buyer Function: Create Purchase Order (Referred to as a Transaction in SAP). A user may have more than one Role, for the above example: Maintain material master for the purchasing view or to create a Vendor master at purchase organization level. A Role is built with the standard SAP security tool called the profile generator (PFCG). Authorization Object The R/3 authorization concept permits the assignment of either general and/or finely detailed user authorizations. These assignments can reach down to transactions, field and field value level. For e.g. If a user wants to create a PO we can restrict him on: • Activity : Create/Change/Display • Org elements like Company Code, Plant, Purchase Organization etc • Document type etc. As stated earlier, the authorization for the execution of a particular transaction code does not necessarily mean that a user can actively maintain all data fields connected to this transaction. The resulting relationships become very complex and hence the R/3 authorization is built on the object – oriented concept with authorization objects. Each authorization object is a combination of authorization fields. 1 An authorization always refers to an authorization object and can contain intervals for the field values.
From the above fig you can see the way authorizations are assigned in roles in SAP R/3. An authorization object works as a template for a to-be defined authorization. Users can perform an activity only if they satisfy the authorization check for each field in the authorization defined for a particular authorization object. Authorization objects are grouped in an object class such as Materials Management: Master Data (MM_G). Each Object Class may have several authorization objects and within each object we can have several authorizations (max. up to 99).
1
The authorization check protects the functions or objects you choose. R/3 has it embedded in the program logic.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 4
SAP Security in ABAP Applications
Fields The permissible values for the fields constitute the authorization. In the above e.g. ACTVT (Activity) is a field with permissible values of 01 (Create), 02 (Change) & (03 Display) for the object M_MATE_CHG (Material Master: Batches/Trading Units). Value * for field BEGRU signifies all possible values. Authorizations An authorization allows you to carry out an R/3 task based on a set of field values in an authorization object. By themselves authorizations do not exist and they only have a meaning inside a profile. Authorizations are used to specify permitted values for the fields in an authorization object (specific values or value ranges). Profiles Authorizations 2 are contained within profiles and these profiles are assigned to users manually or automatically via role assignment. When you assign the field values for all the authorization objects and save system will auto generate a profile name. You may keep the default name or change it as per your needs (only the first 10 characters can be freely assigned).Number of profiles generated depend on the number of authorizations in each role. A maximum of 150 authorizations can fit in a profile, if more than a new profile is generated with same name except the last 2 digits which act as a counter viz. 11, 12 etc. Authorization Checks Authorization 3 check are included in the transactions source code in standard SAP R/3.A user may carry out an action if the authorization check is successful for each field in the object. Authorization checks can be disabled by setting check indicators in transaction SU24 or by deactivating the objects globally. Composite Role Composite roles are collection of single roles. They do not have any authorizations within them; therefore you do not see an authorization tab when displaying the composite roles. Composite roles have authorization from the single contained in them. Although the menu tab is present you cannot add transactions to a composite role. Figure below shows a screen shot of a composite role
Below is a screenshot of a single role (notice the difference in the number of tabs)
2 3
SAP recommended procedure is to generate profiles through PFCG only and not create them manually using SU02. Authorization checks are triggered by ABAP-Authority check statements
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 5
SAP Security in ABAP Applications
Here you may have a question as to what could be the purpose of a composite role. Composite roles can be very handy in a lot of situations. One example is where you have people working in similar job functions say AR clerk in multiple sites say Mumbai, Singapore & Dubai in such cases you create a composite job role with two single roles. Role A will have all the transactions required for performing the job function but without any organization specific objects (i.e. you can inactivate or delete objects which call for org. elements) and Role B will have only these objects without any transactions. This will eliminate the efforts required in maintaining transactions again and again in each job role for each site. All you need to do now is to create a Role B for each site and only have to maintain the site specific data. Derived Role You can use an existing role as a reference when creating a new role. The system transfers the transactions from one role to another (the latter remains dependant on the existing role). You cannot enter transactions directly in a derived role, but you must maintain authorizations separately for each derived role. Authorizations are not passed on. But you can transfer the authorizations of the existing role to the derived role as a copy. Exercise Create a Composite Buyer Role with authorizations to create, change & display purchase order. Solution: We need to create a Composite Buyer Role (Z_Buyer) with single roles (Z_Tcode_Buyer & Z_Org_Buyer). T-codes will be assigned to the role Z_Tcode_Buyer and the org element objects shall be maintained in the role Z_Org_Buyer. Transaction PFCG
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 6
SAP Security in ABAP Applications
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 7
SAP Security in ABAP Applications
Close the organization elements window that pops up next and then in authorizations window go to menu>Utilities->Technical names on
So we have deactivated all org element objects in this role, now we shall copy these objects and manually enter them in the role Z_Org_Buyer.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 8
SAP Security in ABAP Applications
On pressing Save a window pops up with the profile name, we shall accept the default name in this case. Then press the generate button (red & white wheel icon) and the profile gets generated. You can see the message” Profile(s) Created” in the status bar at the bottom left. Give a meaningful description to the role and save it.
Now we create the role Z_Org_Buyer similarly, Go to the authorizations tab directly and click change authorization data. Click “Do not select templates”. Press the manually button and copy paste the deactivated objects from the role Z_Tode_Buyer into the pop up window.
Default values for authorization objects have been predefined in SAP which would have populated when you added the transaction in the role Z_Tcode_Buyer we shall maintain the same default values for the fields in the role Z_Org_Buyer except for the org element fields for which we need to maintain the values. For e.g. the default value for the field ACTVT in the Object F_BKPF_KOA is 03 we need to maintain the same in this object in the role Z_Org_Buyer as this value will not get copied when you add object manually to the role. But, for the field KOART which is an Org element the SAP default value is $KOART we need to change it to our customized org element which can be found by hitting F4 in the selection window.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 9
SAP Security in ABAP Applications
Save and generate the role after maintaining the values for the fields.
Next we create the composite role as below:
Add the single roles in the role tab and save the role.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 10
SAP Security in ABAP Applications
Summary • • • • Transactions are not assigned to users directly; they are assigned to roles which are in turn assigned to users. Standard SAP transactions have authorization checks embedded in the source code which call the related authorization object when the user executes the transaction. These authorization objects can be checked/unchecked via transaction SU24. Authorizations are contained within profiles which are in turn contained in roles.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 11
SAP Security in ABAP Applications
User Administration
R/3 allows you to define and maintain users. The User administration process involves the following activities: • • • • • • Creating & Changing Users Assigning users to the roles Locking and unlocking users & Password resets Maintaining user validity Assigning profiles to users Maintaining user parameters etc.
Users are created and maintained through transaction SU01 (mass creation SU10). Each user is assigned to a user type which controls how the user interacts with the R/3 system. User Type User types include: Dialog Communication System Service Reference • Dialog: This user type applies to most users in the company, they handle the transactions online. They logon and work interactively with R/3 and hence the name “Dialog”. Dialog users should be assigned to a user group. Communication: The users of this type are used for dialog free communication between systems (for RFC or CPIC service users of different applications, for example, ALE, Workflow, TMS ZBV). These users cannot logon or work directly. The users of this type are excluded from standard settings of password validity period. Although, user administrators can change the password using SU01. System: Users of the type System are used for dialog free communication within the same system and also for background processing within the system. These users cannot logon or work directly. The users of this type are excluded from standard settings of password validity period. Although, user administrators can change the password using SU01. Service: A user of type Service is a dialog user available to a large anonymous set of users. It usually has closely-restricted authorizations. E.g. Firefighter ids having critical access to SAP systems are created as service users and then assigned to user ids that need temporary access to these critical transactions as & when required. You can change a session which began as an anonymous session with a service user into a personal session under a dialog user with an individual authentification. There is no check for obsolete/initial passwords at logon. Only the user administrator can change the password. Multiple logon is allowed. Reference: A Reference user is a general impersonal user like the Service user. You cannot logon with a Reference user. The Reference user is to give Internet users identical authorizations.
•
•
•
•
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 12
SAP Security in ABAP Applications
Special Users in the R/3 System • SAP*: In the default clients delivered by SAP 000 & 001 system includes a default R/3 super user SAP*. During installation a User master record is created for SAP* with initial password 06071992. However SAP* is programmed in R/3 and does not require a user master record. Incase the user master record gets deleted the user can login into SAP using SAP* and initial password pass. DDIC: Like SAP* DDIC is also automatically created when the clients 000 & 001 are installed with initial password as 19920706. It maintains the ABAP dictionary and also the software logistics. The system admin should change the default password for the user in both clients. As the is user is used for certain installations, set up tasks and also for login during new SAP release installation it should not be deleted. EarlyWatch: This user is delivered in client 066 with initial password as SUPPORT. Used by SAP’s EarlyWatch experts for monitoring and performance data. This user should also not be deleted and password should be changed.
•
•
User Groups User groups are used for distributing user maintenance amongst several user administrators. Thereby the User administrators can perform their functions to only those users for whom they have authorization. This is controlled by the authorization object S_USER_GRP. Usually User groups are created based on the organizational structure. User groups are created using transaction SUGR. Each user can be assigned to many user groups but the admin tasks for this user will depend only on the user groups which have been assigned to the user in the Logon data tab in transaction SU01.
Exercise Create a dialog user User07, Maintain Logon data, Maintain defaults, Assign Roles, Lock/Unlock the user & Reset the password.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 13
SAP Security in ABAP Applications
Solution:
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 14
SAP Security in ABAP Applications
The password can either be generated using the wizard or can be manually typed. The validity date is very important in terms of users getting locked in the system. The users locked due to validity date are locked as “Locked by system administrator” and users getting locked due to incorrect password are” Locked due to incorrect logons”. This message will be displayed when you try to unlock a user.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 15
SAP Security in ABAP Applications
Notice how composite roles are differentiated from single roles with the symbol for composite and for single role. Also the single roles get added automatically on assigning the composite role and are in blue font. Press Save and the user can logon and perform his desired function. To Lock/Unlock the user press the lock button on the initial screen.
To reset the password press the reset button and type the passwords in both the fields.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 16
SAP Security in ABAP Applications
User Information System Here you have the option to run different reports to obtain information on all related data concerning users. Transaction code is SUIM, single transaction from which you can get a range of reports and is one of the most important tools for a security consultant. There are various reports available, a few of them can be: Users by transaction assignment, Roles by transaction assignment, Users by role assignment, drilled down to users or roles by authorization object field values. The initial screen looks somewhat like this:
As you already know that a user may have several roles and also he may be facing an authorization error from any one transaction. Suppose 4 we wish to find the role in which a user has that particular transaction, since we would insert the missing authorization to that role only. We shall follow the menu path within the transaction as: Roles Roles by Complex Selection Criteria.
4
It is always recommended that the missing object with values be inserted in the role that has the transaction although practically the object may be inserted in any role and the user will be able to execute the transaction.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 17
SAP Security in ABAP Applications
The screen would like the one below where you need to input the values.
And you will get an output as the one given below:
You may also find the list of users assigned, Profile assigned & transactions assigned to this role by clicking any of the highlighted buttons.
Similarly there are several reports that can be drawn and thereby this tool is very handy for a security consultant in his day to day work.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 18
SAP Security in ABAP Applications
Summary • • • • User Administrator does the task of creating, changing, deleting, Locking/Unlocking users and reset of passwords. Users are of the type Dialog, Communication, System, Service & Reference. User Groups help to distribute the user maintenance task. SU01 for user maintenance & SUGR for User Groups.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 19
SAP Security in ABAP Applications
Troubleshooting & Maintenance
Introduction Once your users are set up in the production system and the required roles have been assigned to them as per their job functions there will always be a case where a user is not able to execute a transaction due to some missing objects and/or some value missing in the object. Under these circumstances the user might either receive a not authorized message box or a message displayed in the status bar as “No authorization”. There are two ways of determining the missing authorizations: • • SU53 , Display Authorization check ST01 , System Trace
It is recommended that each user be assigned an enduser role with uncritical basis transaction access like SU53 so that they can execute the same under these circumstances and send a screenshot of the same to the support team who can analyze and insert the missing authorizations. Display Authorization Check: SU53 As mentioned above there can be instances where a user faces an authorization problem when executing a transaction. The Display Authorization Check transaction (SU53) gives a very good picture of the missing authorization and all the support team needs to do is to insert the missing object and/or values into the users role from where the transaction was executed. The user has to type /nSU53 in the command field when the error occurs and the next the screen gives us the missing authorizations at the top and available authorizations if any below it. The screen gives you exactly the role, the authorization object and the value in a very easy to understand format. Exercise: A user is trying to create to a purchase order for a Purchasing Organization which he is not authorized, Display the SU53. Solution: Execute transaction ME21n (Create Purchase Order)
He gets an authorization error at the bottom left on the status bar:
The SU53 screen shot looks as below:
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 20
SAP Security in ABAP Applications
Incase the user is unable to display the SU53 screen or is not trained to do so, you can execute the transaction by logging into the system/client and type SU53 in the command field in the SAP easy access screen. Press the button other user and type the user name in the input field. This would only work if the user does not execute any other transaction in between else the SU53 can get overwritten.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 21
SAP Security in ABAP Applications
On pressing enter you would receive a similar SU53 screen shot as seen before. System Trace: ST01 You can run trace for authorization in your session or other users session. Why Trace? If you are using structural authorizations SU53 may not be the ideal tool to display the missing authorization. SU53 depends on the Authorization-Check command of the ABAP code and since HR transactions or transaction that calls HR objects which use structural authorizations do not always depend on the Authorization-Check command of the ABAP code the resulting screen may not be the correct picture of the missing authorization. In these cases ST01 proves to be very handy. Start the transaction ST01 and simultaneously ask the user to run his transaction which gives him the authorization error, Stop the trace as soon as he faces the error. The system logs the users authorization in a trace file which can be accessed and analyzed to insert the missing authorizations to the users role. Exercise For the previous exercise let’s analyze how the trace results would look like? I shall run the trace from my id for the transaction being executed from the user’s id. I log in from my computer into the same system/client that the user logs into and run transaction ST01: Put the tick on Authorization Check and press the button Trace on.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 22
SAP Security in ABAP Applications
User logs in from his id and runs ME21n and tries to create a Purchase Order and faces an authorization error as shown below:
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 23
SAP Security in ABAP Applications
Switch off the trace and double click on the current trace file.
Scroll down the next screen, the system gives the trace report as below:
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 24
SAP Security in ABAP Applications
The return code for M_BEST_EKO for ACTVT=01 is 0 which means check is ok for this field but there is an missing authorization for various document types as can be seen from the light green shades for the object M_BANF_BSA & M_BEST_BSA. The possible return codes and their meaning are listed below: 0 = Authorization check passed 1 = No authorization 2 = Too many parameters for authorization check 3 = Object not contained in user buffer 4 = No profile contained in user butter 6 = Authorization check incorrect 7/8/9 = Invalid user buffer The major advantage of trace over SU53 is that it not only lists the object for which the authorization is being checked but also lists the associated objects that can be checked in future for which value are not present in the user buffer (i.e. Have not been maintained in the user role). Deactivating Authorization Checks: SU24 Whenever you a transaction in SAP many authorization objects are checked. Authorization objects are specifically checked if it has been written in the source code of the transaction. For the checks to be successful the user must have the required authorizations. Most users receive more authorizations that they require. This leads to an increased maintenance load. Many Authorization objects go unused by most customers. The authorization 5 check can be deactivated for these objects by using transaction SU24 (maintain check indicators for transaction codes). Take the following example:
5
Normally you do not have to make any changes in SU24 for standard SAP transactions
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 25
SAP Security in ABAP Applications
The accounting clerk in a concern maintains accounting information for vendors using transaction FK01. The object L_LFA1_BEK restricts the authorization for this role based on the account group of the vendor. So, the clerk can maintain information for the vendor account group for which he is authorized. But, if the concern does not want the restriction at this level it is better to deactivate the authorization check for this object rather than maintaining * in each role. So you deactivate the authorization check under the following circumstances: • • • Not all authorization objects are used as in the above example. Fields for authorization objects are being maintained as * in all roles. Needless authorization checks hamper the system performance.
You can deactivate the authorization check for the object specifically for the transaction or system wide. Below screen shot shows the check indicators for a transaction SU01: These values are populated from the table USOBX_C
The meaning of various check indicators is as follows: U = Un-maintained No indicator set. Check always executed. Field values are not displayed in the Profile Generator. N = No check Check disabled. Field values are not displayed in the Profile Generator. C = Check Check always executed. Field values are not displayed in the Profile Generator.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 26
SAP Security in ABAP Applications
CM = Check/Maintain Check always executed. Field values are displayed for changing in the Profile Generator. If you select the display values button the following screen gets displayed. The screen displayed only those objects which have been set to CM and with the default SAP values that get populated from table USOBX_C. You may also change the values if the screen is opened in change mode.
SU24 is a tool that can be used to good effect in case of custom transactions where the objects generally are not defined for the transactions. The authorization objects are not called when you add the transactions in the menu tab in PFCG. You can find out the objects by executing the transaction and then take an SU53 screenshot whenever you face an authorization error. Later on you can add these objects for the transaction in SU24 with the values shown in SU53 so that the next time you add this transaction in PFCG, the objects get called automatically in the authorization tab with the default values. Summary: • • Use ST01 & SU53 for checking the missing authorizations in the user’s profile. ST01 has a distinct advantage over SU53 that the former can be used even for checking missing authorizations in structural authorizations and also that if gives you a list of associated objects for which values have not been maintained in the user profile and which may be called for in the future. SU24 is used to activate and deactivate authorization checks for objects within a transaction or system-wide.
•
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 27
SAP Security in ABAP Applications
Sarbanes Oxley (SOX) Compliance – SAP Perspective
What is the Sarbox Act or Sarbanes-Oxley Act ? Sarbanes-Oxley is a US law passed in 2002 to strengthen Corporate governance and restore investor confidence. Act was sponsored by US Senator Paul Sarbanes and US Representative Michael Oxley. The Sarbanes-Oxley Act is legislation enacted in response to the high-profile Enron and WorldCom financial scandals to protect shareholders and the general public from accounting errors and fraudulent practices in the enterprise. Sarbanes-Oxley defines which records are to be stored and for how long. The legislation not only affects the financial side of corporations, but also affects the IT departments whose job it is to store a corporation's electronic records. The Sarbanes-Oxley Act states that all business records, including electronic records and electronic messages, must be saved for "not less than five years." The consequences for non-compliance are fines, imprisonment, or both. IT departments are increasingly faced with the challenge of creating and maintaining a corporate records archive in a cost-effective fashion that satisfies the requirements put forth by the legislation. Organizations should be able to guarantee the integrity of some of their operations like PTP or OTC which can have quiet a significant impact on the way the financial statements are projected if not controlled. Organizations today are thereby moving in direction of automating their softwares for SOX compliance. A key factor towards achieving SOX compliance is to segregate the duties amongst individuals to such an extent that no one person has the authorization to fulfill a complete cycle say procurement or sales. Segregation of Duties (SoD) Segregation of duties is one of the key concepts of internal control and is the most difficult and sometimes the most costly one to achieve. In essence, SOD implements an appropriate level of checks and balances upon the activities of individuals. Segregation of duty, as a security principle, has as its primary objective the prevention of fraud and errors. This objective is achieved by disseminating the tasks and associated privileges for a specific business process among multiple users. This principle is demonstrated in the traditional example of separation of duty found in the requirement of two signatures on a check. The term SOD is already well-known in financial accounting systems. Companies in all sizes understand not to combine roles such as receiving checks (payment on account) and approving write-offs, depositing cash and reconciling bank statements etc. You might also not want to give the authorization of creating a vendor and initiating payments to same person or creating a customer and processing a sales order as in both cases might lead to making fraud payments or inappropriate sales of goods. There is an element of risk involved when two or more transactions that are non-complaint are assigned in the same role or to the same user. There are tools available in the market today which not only check for compliance at transaction level but even at the authorization object level i.e. Combination of authorization objects between transactions that might induce risk. Some of the tools that are available to check the compliance for proper SOD are listed below: • • • • APPROVA VIRSA Compliance Calibrator (now popularly known as SAP GRC) OVERSIGHT Bearing Point
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 28
SAP Security in ABAP Applications
References
Authorizations made easy – SAP labs, Inc., Palo Alto, California help.sap.com For more information, visit the Security homepage.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 29
SAP Security in ABAP Applications
Disclaimer and Liability Notice
This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade. SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk. SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 30
Applies to:
SAP R/3 release 4.6 onwards. For more information, visit the Security homepage.
Summary
This document provides an overview of the various processes involved in SAP security. Organizations worldwide are now recognizing the importance of security and are looking for experts who can handle this task for them. Projects today have separate consultants apart from basis consultants who handle SAP security specifically. The contents in this document are the learning from my current role as an SAP security consultant in my current project. Author: Subramaniam Iyer
Company: Infosys Technologies Ltd. Created on: 30 June 2009
Author Bio
Subramaniam Iyer (Infosys Technologies Ltd.) has been working as an security consulant for a Pharma Client. He is primarily an SAP certified MM consultant and trained in QM and WM. In his words: “I enjoy my work in security as my business process knowledge gives me an edge over the other basis consultants in understanding requirements set by clients.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 1
SAP Security in ABAP Applications
Table of Contents
Introduction to SAP Security...............................................................................................................................3 Brief Introduction .............................................................................................................................................3 Introduction to the SAP Authorization Concept ..............................................................................................3 Roles, Authorization object & Authorizations......................................................................................................4 Roles ...............................................................................................................................................................4 Authorization Object........................................................................................................................................4 Fields...............................................................................................................................................................5 Authorizations .................................................................................................................................................5 Profiles ............................................................................................................................................................5 Authorization Checks ......................................................................................................................................5 Composite Role...............................................................................................................................................5 Derived Role ...................................................................................................................................................6
Exercise .......................................................................................................................................................................6
Summary.......................................................................................................................................................11 User Administration ..........................................................................................................................................12 User Type......................................................................................................................................................12 Special Users in the R/3 System ..................................................................................................................13 User Groups..................................................................................................................................................13
Exercise .....................................................................................................................................................................13
User Information System...............................................................................................................................17 Summary.......................................................................................................................................................19 Troubleshooting & Maintenance.......................................................................................................................20 Introduction ...................................................................................................................................................20 Display Authorization Check: SU53 ..............................................................................................................20
Exercise: ....................................................................................................................................................................20
System Trace: ST01 .....................................................................................................................................22
Exercise .....................................................................................................................................................................22
Deactivating Authorization Checks: SU24 ....................................................................................................25 Summary:......................................................................................................................................................27 Sarbanes Oxley (SOX) Compliance – SAP Perspective..................................................................................28 What is the Sarbox Act or Sarbanes-Oxley Act ? .........................................................................................28 Segregation of Duties (SoD) .........................................................................................................................28 References........................................................................................................................................................29 Disclaimer and Liability Notice..........................................................................................................................30
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 2
SAP Security in ABAP Applications
Introduction to SAP Security
Brief Introduction SAP has done nothing less than change the entire systems landscape for enterprises. The benefits it can bring have led to widespread adoption across the globe. One of the key benefits SAP brings to an enterprise is the ability to integrate the data both within the enterprise, and between it and its partners / competitors. In many cases organizations today are both partners and competitors at the same time. Think two oil giants IOCL & IBP who have an upstream joint venture. These companies use SAP to integrate process between themselves for their mutual benefit. This ability to integrate, however, brings with it a particular risk – that of exposing their data to the un-authorized outside world. Entire companies have been built up around highly guarded intellectual property and process secrets ... and could easily fall if this was breached. Therefore, keeping the security of the organization intact is one of the vital aspects of any SAP implementation. SAP addresses all security issues by incorporating a Security module. Security in an integrated system like SAP R/3. Some of the key points that it addresses are listed below: • • • • • Authentication: Only legitimate users should be able to access the system Authorization: Users should only be able to perform their designated tasks Integrity: Privacy: Data integrity needs to be granted at all time Protection of data against unauthorized access
Obligation: Ensuring liability and legal obligation towards stakeholders and shareholders including validation
The scope of this document is SAP Application Security, which can be achieved through the concept of authorization. Introduction to the SAP Authorization Concept The authorizations to access data in SAP are granted and not restricted. This leads to the development of security access on the basis of the least privilege rule. It essentially dictates that a user will get no more access than has been determined necessary to perform a particular job or task that he has been trained for. A user is defined as a person who has access to the SAP R/3 systems, based on his functional roles and location. This includes not only end users in a productive environment, but also project and support users. A balance needs to be struck by the responsible business and technical experts when determining whether access should be restricted or unrestricted with regard to particular data and system functionality. In order to accomplish this, it is important to understand the associated risk attached to data (i.e. financial, operational, legal/regulatory, etc.) as recognized by the business and external controls frameworks, such as SarbanesOxley. The criticality of data should be understood in this context and decisions impacting access to data should reflect this position (i.e. what data should be generally accessible versus what should be restricted to a few authorized users only). The authorization for the execution of a particular transaction code does not necessarily mean that a user can actively maintain all data fields connected to this transaction. The company structure, the technical design of the SAP Security Concept, internal guidelines and external regulatory requirements contribute to the design of system access.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 3
SAP Security in ABAP Applications
Roles, Authorization object & Authorizations
Roles Roles were previously referred to as activity groups. Roles are nothing but a container for authorizations. A role represents a specific part of an employee’s job. The role itself is composed of different functions of the employee, which again is the sum of certain tasks inside these functions. Example: The job of a user Jack Dawson is the Head of the purchase dept. In his job he has different roles, such as being a buyer. One of the functions of the buyer is to create purchase orders. Job: Head of the purchase dept. Role: Buyer Function: Create Purchase Order (Referred to as a Transaction in SAP). A user may have more than one Role, for the above example: Maintain material master for the purchasing view or to create a Vendor master at purchase organization level. A Role is built with the standard SAP security tool called the profile generator (PFCG). Authorization Object The R/3 authorization concept permits the assignment of either general and/or finely detailed user authorizations. These assignments can reach down to transactions, field and field value level. For e.g. If a user wants to create a PO we can restrict him on: • Activity : Create/Change/Display • Org elements like Company Code, Plant, Purchase Organization etc • Document type etc. As stated earlier, the authorization for the execution of a particular transaction code does not necessarily mean that a user can actively maintain all data fields connected to this transaction. The resulting relationships become very complex and hence the R/3 authorization is built on the object – oriented concept with authorization objects. Each authorization object is a combination of authorization fields. 1 An authorization always refers to an authorization object and can contain intervals for the field values.
From the above fig you can see the way authorizations are assigned in roles in SAP R/3. An authorization object works as a template for a to-be defined authorization. Users can perform an activity only if they satisfy the authorization check for each field in the authorization defined for a particular authorization object. Authorization objects are grouped in an object class such as Materials Management: Master Data (MM_G). Each Object Class may have several authorization objects and within each object we can have several authorizations (max. up to 99).
1
The authorization check protects the functions or objects you choose. R/3 has it embedded in the program logic.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 4
SAP Security in ABAP Applications
Fields The permissible values for the fields constitute the authorization. In the above e.g. ACTVT (Activity) is a field with permissible values of 01 (Create), 02 (Change) & (03 Display) for the object M_MATE_CHG (Material Master: Batches/Trading Units). Value * for field BEGRU signifies all possible values. Authorizations An authorization allows you to carry out an R/3 task based on a set of field values in an authorization object. By themselves authorizations do not exist and they only have a meaning inside a profile. Authorizations are used to specify permitted values for the fields in an authorization object (specific values or value ranges). Profiles Authorizations 2 are contained within profiles and these profiles are assigned to users manually or automatically via role assignment. When you assign the field values for all the authorization objects and save system will auto generate a profile name. You may keep the default name or change it as per your needs (only the first 10 characters can be freely assigned).Number of profiles generated depend on the number of authorizations in each role. A maximum of 150 authorizations can fit in a profile, if more than a new profile is generated with same name except the last 2 digits which act as a counter viz. 11, 12 etc. Authorization Checks Authorization 3 check are included in the transactions source code in standard SAP R/3.A user may carry out an action if the authorization check is successful for each field in the object. Authorization checks can be disabled by setting check indicators in transaction SU24 or by deactivating the objects globally. Composite Role Composite roles are collection of single roles. They do not have any authorizations within them; therefore you do not see an authorization tab when displaying the composite roles. Composite roles have authorization from the single contained in them. Although the menu tab is present you cannot add transactions to a composite role. Figure below shows a screen shot of a composite role
Below is a screenshot of a single role (notice the difference in the number of tabs)
2 3
SAP recommended procedure is to generate profiles through PFCG only and not create them manually using SU02. Authorization checks are triggered by ABAP-Authority check statements
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 5
SAP Security in ABAP Applications
Here you may have a question as to what could be the purpose of a composite role. Composite roles can be very handy in a lot of situations. One example is where you have people working in similar job functions say AR clerk in multiple sites say Mumbai, Singapore & Dubai in such cases you create a composite job role with two single roles. Role A will have all the transactions required for performing the job function but without any organization specific objects (i.e. you can inactivate or delete objects which call for org. elements) and Role B will have only these objects without any transactions. This will eliminate the efforts required in maintaining transactions again and again in each job role for each site. All you need to do now is to create a Role B for each site and only have to maintain the site specific data. Derived Role You can use an existing role as a reference when creating a new role. The system transfers the transactions from one role to another (the latter remains dependant on the existing role). You cannot enter transactions directly in a derived role, but you must maintain authorizations separately for each derived role. Authorizations are not passed on. But you can transfer the authorizations of the existing role to the derived role as a copy. Exercise Create a Composite Buyer Role with authorizations to create, change & display purchase order. Solution: We need to create a Composite Buyer Role (Z_Buyer) with single roles (Z_Tcode_Buyer & Z_Org_Buyer). T-codes will be assigned to the role Z_Tcode_Buyer and the org element objects shall be maintained in the role Z_Org_Buyer. Transaction PFCG
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 6
SAP Security in ABAP Applications
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 7
SAP Security in ABAP Applications
Close the organization elements window that pops up next and then in authorizations window go to menu>Utilities->Technical names on
So we have deactivated all org element objects in this role, now we shall copy these objects and manually enter them in the role Z_Org_Buyer.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 8
SAP Security in ABAP Applications
On pressing Save a window pops up with the profile name, we shall accept the default name in this case. Then press the generate button (red & white wheel icon) and the profile gets generated. You can see the message” Profile(s) Created” in the status bar at the bottom left. Give a meaningful description to the role and save it.
Now we create the role Z_Org_Buyer similarly, Go to the authorizations tab directly and click change authorization data. Click “Do not select templates”. Press the manually button and copy paste the deactivated objects from the role Z_Tode_Buyer into the pop up window.
Default values for authorization objects have been predefined in SAP which would have populated when you added the transaction in the role Z_Tcode_Buyer we shall maintain the same default values for the fields in the role Z_Org_Buyer except for the org element fields for which we need to maintain the values. For e.g. the default value for the field ACTVT in the Object F_BKPF_KOA is 03 we need to maintain the same in this object in the role Z_Org_Buyer as this value will not get copied when you add object manually to the role. But, for the field KOART which is an Org element the SAP default value is $KOART we need to change it to our customized org element which can be found by hitting F4 in the selection window.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 9
SAP Security in ABAP Applications
Save and generate the role after maintaining the values for the fields.
Next we create the composite role as below:
Add the single roles in the role tab and save the role.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 10
SAP Security in ABAP Applications
Summary • • • • Transactions are not assigned to users directly; they are assigned to roles which are in turn assigned to users. Standard SAP transactions have authorization checks embedded in the source code which call the related authorization object when the user executes the transaction. These authorization objects can be checked/unchecked via transaction SU24. Authorizations are contained within profiles which are in turn contained in roles.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 11
SAP Security in ABAP Applications
User Administration
R/3 allows you to define and maintain users. The User administration process involves the following activities: • • • • • • Creating & Changing Users Assigning users to the roles Locking and unlocking users & Password resets Maintaining user validity Assigning profiles to users Maintaining user parameters etc.
Users are created and maintained through transaction SU01 (mass creation SU10). Each user is assigned to a user type which controls how the user interacts with the R/3 system. User Type User types include: Dialog Communication System Service Reference • Dialog: This user type applies to most users in the company, they handle the transactions online. They logon and work interactively with R/3 and hence the name “Dialog”. Dialog users should be assigned to a user group. Communication: The users of this type are used for dialog free communication between systems (for RFC or CPIC service users of different applications, for example, ALE, Workflow, TMS ZBV). These users cannot logon or work directly. The users of this type are excluded from standard settings of password validity period. Although, user administrators can change the password using SU01. System: Users of the type System are used for dialog free communication within the same system and also for background processing within the system. These users cannot logon or work directly. The users of this type are excluded from standard settings of password validity period. Although, user administrators can change the password using SU01. Service: A user of type Service is a dialog user available to a large anonymous set of users. It usually has closely-restricted authorizations. E.g. Firefighter ids having critical access to SAP systems are created as service users and then assigned to user ids that need temporary access to these critical transactions as & when required. You can change a session which began as an anonymous session with a service user into a personal session under a dialog user with an individual authentification. There is no check for obsolete/initial passwords at logon. Only the user administrator can change the password. Multiple logon is allowed. Reference: A Reference user is a general impersonal user like the Service user. You cannot logon with a Reference user. The Reference user is to give Internet users identical authorizations.
•
•
•
•
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 12
SAP Security in ABAP Applications
Special Users in the R/3 System • SAP*: In the default clients delivered by SAP 000 & 001 system includes a default R/3 super user SAP*. During installation a User master record is created for SAP* with initial password 06071992. However SAP* is programmed in R/3 and does not require a user master record. Incase the user master record gets deleted the user can login into SAP using SAP* and initial password pass. DDIC: Like SAP* DDIC is also automatically created when the clients 000 & 001 are installed with initial password as 19920706. It maintains the ABAP dictionary and also the software logistics. The system admin should change the default password for the user in both clients. As the is user is used for certain installations, set up tasks and also for login during new SAP release installation it should not be deleted. EarlyWatch: This user is delivered in client 066 with initial password as SUPPORT. Used by SAP’s EarlyWatch experts for monitoring and performance data. This user should also not be deleted and password should be changed.
•
•
User Groups User groups are used for distributing user maintenance amongst several user administrators. Thereby the User administrators can perform their functions to only those users for whom they have authorization. This is controlled by the authorization object S_USER_GRP. Usually User groups are created based on the organizational structure. User groups are created using transaction SUGR. Each user can be assigned to many user groups but the admin tasks for this user will depend only on the user groups which have been assigned to the user in the Logon data tab in transaction SU01.
Exercise Create a dialog user User07, Maintain Logon data, Maintain defaults, Assign Roles, Lock/Unlock the user & Reset the password.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 13
SAP Security in ABAP Applications
Solution:
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 14
SAP Security in ABAP Applications
The password can either be generated using the wizard or can be manually typed. The validity date is very important in terms of users getting locked in the system. The users locked due to validity date are locked as “Locked by system administrator” and users getting locked due to incorrect password are” Locked due to incorrect logons”. This message will be displayed when you try to unlock a user.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 15
SAP Security in ABAP Applications
Notice how composite roles are differentiated from single roles with the symbol for composite and for single role. Also the single roles get added automatically on assigning the composite role and are in blue font. Press Save and the user can logon and perform his desired function. To Lock/Unlock the user press the lock button on the initial screen.
To reset the password press the reset button and type the passwords in both the fields.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 16
SAP Security in ABAP Applications
User Information System Here you have the option to run different reports to obtain information on all related data concerning users. Transaction code is SUIM, single transaction from which you can get a range of reports and is one of the most important tools for a security consultant. There are various reports available, a few of them can be: Users by transaction assignment, Roles by transaction assignment, Users by role assignment, drilled down to users or roles by authorization object field values. The initial screen looks somewhat like this:
As you already know that a user may have several roles and also he may be facing an authorization error from any one transaction. Suppose 4 we wish to find the role in which a user has that particular transaction, since we would insert the missing authorization to that role only. We shall follow the menu path within the transaction as: Roles Roles by Complex Selection Criteria.
4
It is always recommended that the missing object with values be inserted in the role that has the transaction although practically the object may be inserted in any role and the user will be able to execute the transaction.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 17
SAP Security in ABAP Applications
The screen would like the one below where you need to input the values.
And you will get an output as the one given below:
You may also find the list of users assigned, Profile assigned & transactions assigned to this role by clicking any of the highlighted buttons.
Similarly there are several reports that can be drawn and thereby this tool is very handy for a security consultant in his day to day work.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 18
SAP Security in ABAP Applications
Summary • • • • User Administrator does the task of creating, changing, deleting, Locking/Unlocking users and reset of passwords. Users are of the type Dialog, Communication, System, Service & Reference. User Groups help to distribute the user maintenance task. SU01 for user maintenance & SUGR for User Groups.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 19
SAP Security in ABAP Applications
Troubleshooting & Maintenance
Introduction Once your users are set up in the production system and the required roles have been assigned to them as per their job functions there will always be a case where a user is not able to execute a transaction due to some missing objects and/or some value missing in the object. Under these circumstances the user might either receive a not authorized message box or a message displayed in the status bar as “No authorization”. There are two ways of determining the missing authorizations: • • SU53 , Display Authorization check ST01 , System Trace
It is recommended that each user be assigned an enduser role with uncritical basis transaction access like SU53 so that they can execute the same under these circumstances and send a screenshot of the same to the support team who can analyze and insert the missing authorizations. Display Authorization Check: SU53 As mentioned above there can be instances where a user faces an authorization problem when executing a transaction. The Display Authorization Check transaction (SU53) gives a very good picture of the missing authorization and all the support team needs to do is to insert the missing object and/or values into the users role from where the transaction was executed. The user has to type /nSU53 in the command field when the error occurs and the next the screen gives us the missing authorizations at the top and available authorizations if any below it. The screen gives you exactly the role, the authorization object and the value in a very easy to understand format. Exercise: A user is trying to create to a purchase order for a Purchasing Organization which he is not authorized, Display the SU53. Solution: Execute transaction ME21n (Create Purchase Order)
He gets an authorization error at the bottom left on the status bar:
The SU53 screen shot looks as below:
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 20
SAP Security in ABAP Applications
Incase the user is unable to display the SU53 screen or is not trained to do so, you can execute the transaction by logging into the system/client and type SU53 in the command field in the SAP easy access screen. Press the button other user and type the user name in the input field. This would only work if the user does not execute any other transaction in between else the SU53 can get overwritten.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 21
SAP Security in ABAP Applications
On pressing enter you would receive a similar SU53 screen shot as seen before. System Trace: ST01 You can run trace for authorization in your session or other users session. Why Trace? If you are using structural authorizations SU53 may not be the ideal tool to display the missing authorization. SU53 depends on the Authorization-Check command of the ABAP code and since HR transactions or transaction that calls HR objects which use structural authorizations do not always depend on the Authorization-Check command of the ABAP code the resulting screen may not be the correct picture of the missing authorization. In these cases ST01 proves to be very handy. Start the transaction ST01 and simultaneously ask the user to run his transaction which gives him the authorization error, Stop the trace as soon as he faces the error. The system logs the users authorization in a trace file which can be accessed and analyzed to insert the missing authorizations to the users role. Exercise For the previous exercise let’s analyze how the trace results would look like? I shall run the trace from my id for the transaction being executed from the user’s id. I log in from my computer into the same system/client that the user logs into and run transaction ST01: Put the tick on Authorization Check and press the button Trace on.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 22
SAP Security in ABAP Applications
User logs in from his id and runs ME21n and tries to create a Purchase Order and faces an authorization error as shown below:
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 23
SAP Security in ABAP Applications
Switch off the trace and double click on the current trace file.
Scroll down the next screen, the system gives the trace report as below:
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 24
SAP Security in ABAP Applications
The return code for M_BEST_EKO for ACTVT=01 is 0 which means check is ok for this field but there is an missing authorization for various document types as can be seen from the light green shades for the object M_BANF_BSA & M_BEST_BSA. The possible return codes and their meaning are listed below: 0 = Authorization check passed 1 = No authorization 2 = Too many parameters for authorization check 3 = Object not contained in user buffer 4 = No profile contained in user butter 6 = Authorization check incorrect 7/8/9 = Invalid user buffer The major advantage of trace over SU53 is that it not only lists the object for which the authorization is being checked but also lists the associated objects that can be checked in future for which value are not present in the user buffer (i.e. Have not been maintained in the user role). Deactivating Authorization Checks: SU24 Whenever you a transaction in SAP many authorization objects are checked. Authorization objects are specifically checked if it has been written in the source code of the transaction. For the checks to be successful the user must have the required authorizations. Most users receive more authorizations that they require. This leads to an increased maintenance load. Many Authorization objects go unused by most customers. The authorization 5 check can be deactivated for these objects by using transaction SU24 (maintain check indicators for transaction codes). Take the following example:
5
Normally you do not have to make any changes in SU24 for standard SAP transactions
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 25
SAP Security in ABAP Applications
The accounting clerk in a concern maintains accounting information for vendors using transaction FK01. The object L_LFA1_BEK restricts the authorization for this role based on the account group of the vendor. So, the clerk can maintain information for the vendor account group for which he is authorized. But, if the concern does not want the restriction at this level it is better to deactivate the authorization check for this object rather than maintaining * in each role. So you deactivate the authorization check under the following circumstances: • • • Not all authorization objects are used as in the above example. Fields for authorization objects are being maintained as * in all roles. Needless authorization checks hamper the system performance.
You can deactivate the authorization check for the object specifically for the transaction or system wide. Below screen shot shows the check indicators for a transaction SU01: These values are populated from the table USOBX_C
The meaning of various check indicators is as follows: U = Un-maintained No indicator set. Check always executed. Field values are not displayed in the Profile Generator. N = No check Check disabled. Field values are not displayed in the Profile Generator. C = Check Check always executed. Field values are not displayed in the Profile Generator.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 26
SAP Security in ABAP Applications
CM = Check/Maintain Check always executed. Field values are displayed for changing in the Profile Generator. If you select the display values button the following screen gets displayed. The screen displayed only those objects which have been set to CM and with the default SAP values that get populated from table USOBX_C. You may also change the values if the screen is opened in change mode.
SU24 is a tool that can be used to good effect in case of custom transactions where the objects generally are not defined for the transactions. The authorization objects are not called when you add the transactions in the menu tab in PFCG. You can find out the objects by executing the transaction and then take an SU53 screenshot whenever you face an authorization error. Later on you can add these objects for the transaction in SU24 with the values shown in SU53 so that the next time you add this transaction in PFCG, the objects get called automatically in the authorization tab with the default values. Summary: • • Use ST01 & SU53 for checking the missing authorizations in the user’s profile. ST01 has a distinct advantage over SU53 that the former can be used even for checking missing authorizations in structural authorizations and also that if gives you a list of associated objects for which values have not been maintained in the user profile and which may be called for in the future. SU24 is used to activate and deactivate authorization checks for objects within a transaction or system-wide.
•
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 27
SAP Security in ABAP Applications
Sarbanes Oxley (SOX) Compliance – SAP Perspective
What is the Sarbox Act or Sarbanes-Oxley Act ? Sarbanes-Oxley is a US law passed in 2002 to strengthen Corporate governance and restore investor confidence. Act was sponsored by US Senator Paul Sarbanes and US Representative Michael Oxley. The Sarbanes-Oxley Act is legislation enacted in response to the high-profile Enron and WorldCom financial scandals to protect shareholders and the general public from accounting errors and fraudulent practices in the enterprise. Sarbanes-Oxley defines which records are to be stored and for how long. The legislation not only affects the financial side of corporations, but also affects the IT departments whose job it is to store a corporation's electronic records. The Sarbanes-Oxley Act states that all business records, including electronic records and electronic messages, must be saved for "not less than five years." The consequences for non-compliance are fines, imprisonment, or both. IT departments are increasingly faced with the challenge of creating and maintaining a corporate records archive in a cost-effective fashion that satisfies the requirements put forth by the legislation. Organizations should be able to guarantee the integrity of some of their operations like PTP or OTC which can have quiet a significant impact on the way the financial statements are projected if not controlled. Organizations today are thereby moving in direction of automating their softwares for SOX compliance. A key factor towards achieving SOX compliance is to segregate the duties amongst individuals to such an extent that no one person has the authorization to fulfill a complete cycle say procurement or sales. Segregation of Duties (SoD) Segregation of duties is one of the key concepts of internal control and is the most difficult and sometimes the most costly one to achieve. In essence, SOD implements an appropriate level of checks and balances upon the activities of individuals. Segregation of duty, as a security principle, has as its primary objective the prevention of fraud and errors. This objective is achieved by disseminating the tasks and associated privileges for a specific business process among multiple users. This principle is demonstrated in the traditional example of separation of duty found in the requirement of two signatures on a check. The term SOD is already well-known in financial accounting systems. Companies in all sizes understand not to combine roles such as receiving checks (payment on account) and approving write-offs, depositing cash and reconciling bank statements etc. You might also not want to give the authorization of creating a vendor and initiating payments to same person or creating a customer and processing a sales order as in both cases might lead to making fraud payments or inappropriate sales of goods. There is an element of risk involved when two or more transactions that are non-complaint are assigned in the same role or to the same user. There are tools available in the market today which not only check for compliance at transaction level but even at the authorization object level i.e. Combination of authorization objects between transactions that might induce risk. Some of the tools that are available to check the compliance for proper SOD are listed below: • • • • APPROVA VIRSA Compliance Calibrator (now popularly known as SAP GRC) OVERSIGHT Bearing Point
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 28
SAP Security in ABAP Applications
References
Authorizations made easy – SAP labs, Inc., Palo Alto, California help.sap.com For more information, visit the Security homepage.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 29
SAP Security in ABAP Applications
Disclaimer and Liability Notice
This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade. SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk. SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document.
SAP COMMUNITY NETWORK © 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 30
