SAP Security and Authorizations are controlled by many different elements in the SAP system. We list the most common items and explain how they can assist in achieving a more secure SAP environment.
By Emile Steyn
Master the basics
To ensure that your SAP security solution provides the necessary level of control for your organisation, the SAP security administrator will need to have a good understanding of the basics of SAP security. The following section explains some of the basic concepts of SAP security.
A Transaction code is the term used to describe an action or activity in SAP e.g. ME21N – Create Purchase Order. An SAP user will be assigned various transaction codes in order to perform their job function. Transaction codes have underlying authorization objects and values that allow for a more granular control such as restricting a user to only operate in one Company Code or Plant. In a standard SAP system there are over 140 000 possible transaction codes. Most companies typically use between 2000 – 3000 of these transaction codes. Transaction codes need to be assigned to a role and the role in turn is assigned to the user. From a risk perspective, it is important to only assign access that the SAP users require to perform their job function. Assigning wide access to users increases your organisation’s access risk exposure.
◦ SAP Single Role – A single role is a data container for a group of transaction codes. SAP users are assigned the single roles for them to be able to execute the transaction codes. The different approaches of assigning access is referred to as the role methodology. The various role methodologies are:
- Derived – A derived / parent role methodology is where the parent role acts as a master role containing the transaction codes, and is derived out to cater for the various organisational levels (Company Code, Plant etc).
- Task / Value – A task role is a functional (small) role that contains a group of associated transaction codes to perform a certain task e.g. Purchase Order Maintenance. Users are typically assigned many task roles to make up their complete access/profile. Value roles are secondary roles that work in conjunction with the task role. Value roles only contain SAP authorization objects with specific values to restrict the users to only operate in the Organisation Levels for which they have value roles assigned.
- Profiles – Before SAP introduced the role concept, SAP profiles were mechanisms to provide users with the necessary access to carry out their job function. SAP profiles still exist in the SAP system, but are seldom used. The most common example of this is the SAP_ALL profile.
◦ SAP Composite Role – An SAP Composite role is a container for a group of single roles. The Composite role can then be assigned to the users who then inherit the access (transaction codes) contained in the single roles.
◦ SAP Business Role – The Business Role is similar to an SAP Composite Role but only exist in the IDM or Access Control solution, a virtual role that can be managed through an SAP Access Risk tool. Business roles have the added benefit of being a data container for SAP single roles from multiple SAP systems, simplifying provisioning significantly.
SAP users are the identities for the end-users to access the SAP system. When creating an SAP user, the following fields are available for maintenance:
- SAP Password complexity – SAP allows for many different complexity settings on passwords. Your current password settings (these include minimum password length, special characters, Upper case letter, etc) can be viewed through transaction RSPFPAR.
- User Types – In SAP there are different user types, namely: Dialog, Service, System, Communication and Reference users. The most common types are used for the following:
- Dialog – Your typical user ID will be a dialog user. They are subject to password parameters unless specific security policies have been applied to them.
- Service – A service user’s password does not change. There is a large risk with these IDs if passwords are shared.
- System User – These IDs are used for background jobs, system communication etc. These IDs cannot logon via the SAP GUI, but carry risk because of the wide access typically assigned. These IDs can be used to expose the SAP System to risk through RFCs (Remote Function Calls).
- Validity dates – Certain User IDs are only required to access the system for a certain time. It would be recommended to maintain a validity date for a user to ensure they cannot gain unauthorised access to the system. These dates should also be maintained when a date is known for a user leaving the company.
SAP provisioning is the process of assigning SAP roles to the SAP User ID. SAP Provisioning can be handled in different ways. A user can inherit access directly or indirectly:
- Direct – Assign roles directly to users.
- Indirect – Assign roles to a Position. The HR team will assign a user to a position.
SAP Fiori Security
The transaction code is being replaced by Fiori Applications which are executed through a web browser. These changes add an additional level of complexity and security. Some of these changes include the use of the S_SERVICE authorization objects and catalogs. Although a friendlier user interface, it is a more difficult solution to maintain.
SAP HANA Database Security
Certain users are provided database access to execute reports. It is important that access at database level is restricted to ensure no unauthorised inserts or edits are done at the database level.
SAP Access Risk
- SAP SOD Risk – A segregation of duty risk is where a user has the ability to perform two or more conflicting functions. These conflicting functions expose a company to fraud, user error and misstatements.
- SAP Critical Transaction Risk – Certain transactions can be sensitive all by itself based on the potential impact if misused. These are classified as Critical Transaction or Sensitive Access risks.
Optimise SAP Security to achieve business objectives
Once you’ve optimised and mastered the basics ask yourself, ‘How do I optimise my SAP Security to achieve my business objectives?’.
SAP Role Methodology
The methodology you have applied has a big impact on what you can achieve. Certain methodologies allow for easierremediation and ensuring users are only assigned the access they require for their job function. Decide what you need to achieve and see if the methodology allows for it.
SAP SOD Tool
There are different tools like Soterion and SAP that can help you manage the access risk in your SAP system. It is important to consider the benefits that the tools provide and what you want to get from a tool.
Items to consider:
- User Interface
- Ease of use
- Implementation time
- Process improvements
SAP Access Risk Rule Set
The SOD tools are shipped with a standard rule set. The rule set does not cater for customization or business process changes that have been applied. It is important to ensure the rule set is adjusted to be company specific.
Manage SAP Access Risks
After identifying the relevant risks, you need to clean-up your SAP Access Risks. How can this be done?
- Remediation (role clean-up) – Clean-up can happen in different ways. Roles can be removed from users or transactions can be removed from roles.
- Mitigation Controls – For access risk that cannot be remediated, Mitigation controls need to be defined to ensure the access risk exposure is adequately reduced.
SAP Role Redesign
When your Role methodology does not allow you to reach your business objectives, it could be required to do a complete SAP Role Redesign. This would mean that new roles are built for the entire user base.
The information we have provided is focussed on SAP Access and the risks associated with it. Other items to consider could be the following:
- SAP Security notes
- SAP configuration settings
- SAP Audit logging
Feel free to email us at [email protected] if you would like a discussion with one of our experts around SAP Security.
Back to Latest News list