The SAP R/3 authorisation concept permits the assignment of general and/or finely detailed user authorisations. These assignments can reach down to the transaction, field and field value level. These authorisations are centrally administered in user master records. Actions by a user may require several authorisations.

For example, to change a material master record, authorisations are required for the:

Transaction 'change'
Specific material type
Views of the material master record
General authorisation to work with the company code

The resulting relationships can become very complex. The SAP R/3 authorisation concept is based on authorisation objects. Each authorisation object is a combination of authorisation fields. An authorisation always refers to an authorisation object and can contain intervals for the authorisation field values. Authorisation checks protect the functions or objects a user chooses. Standard-delivered SAP R/3 functions or objects have these checks embedded in the program logic.

Authorisation administrators create authorisations that are assigned to users in collections called profiles. The Profile Generator (PG), a standard tool in SAP R/3, usually generates authorisations and authorisation profiles, although authorisations can also be manually inserted into a profile.

Authorisation Object Class

Authorisation objects are grouped in logical groupings of authorisation object class.

Authorisation Object

Authorisation objects allow complex user authorisation checks. An authorisation object groups up to 10 authorisation fields in an 'AND' relationship. All the fields are checked simultaneously to check whether a user is allowed to perform a certain action. Users may only conduct an activity if they satisfy the authorisation check for each of the authorisation field in the authorisation object.

Authorisation Field

This is the smallest unit against which the authorisation check is done. The fields in an authorisation object are linked to data elements in the SAP ABAP Dictionary. The permissible values constitute an authorisation. When an authorisation check takes place, the system checks the values that you have specified in an authorisation against those required to carrying out the action. Users may only carry out the action if they satisfy the conditions for every field defined for a specific authorisation object.

Authorisation

An authorisation is the authority to perform a particular action in the SAP R/3 system based on a set of authorisation field values in an authorisation object. Each authorisation refers to exactly one authorisation object and one or more possible values for each authorisation field listed for that authorisation object. Authorisations are utilised in the user master record as roles. By themselves, authorisations do not exist. They only have meaning inside a role.

Authorisation Profile

Authorisation profile contains authorisations for different authorisation objects. User authorisations are assigned using authorisation profiles. Once a profile is changed, the changes will affect all users to whom this profile is assigned and take effect only when the user logs on. Users who are logged on when the change takes place remain unaffected during their current session, but when they log on again, their profile will change accordingly. A user's authorisations are loaded into the user buffer only when they logon on. To automatically generate an authorisation profile, you must first create a role.

Role

A role is a set of functions/transactions describing activities or a specific work area. The Account Receivable Accountant role, for example, contains authorisations to transactions and Reports needed by the accountants for their daily work. A role can be assigned to any number of users. Besides the normal SAP R/3 logon users, you can also assign roles to object types such as jobs, organisation units or positions. Besides the predefined SAP roles available in the system, you can also create your own custom roles.

Composite Role & Single Role

A composite role (also known as collective role) is a group of several different (single) roles. It is not possible to group composite roles into composite roles.  Composite roles do not contain authorisation data. If you want to change the authorisation in a composite role, you must maintain the authorisation data in the (single) roles. Users assigned to a composite role are automatically assigned to the corresponding (single) roles. The menu tree of a composite role is a combination of the menus of all the (single) roles it contained. Merging of menu trees from (single) roles may lead to certain menu items being listed more than once.

If Authorisation A allows the user to perform create, change and display activities in company codes 1000 and 2000.

And Authorisation B allows the user to perform only display activity in company codes 1000, 2000 and 3000.

Then a user who has authorisation A and authorisation B, can perform create, change and display activities in company codes 1000 and 2000, and can only perform display activity in company code 3000.

Authorisation Check

This check decides whether a user is authorised to execute a particular action. Processes, functions and data access in SAP R/3 system can only be performed when user authorisations have been checked successfully in the respective system and application programs.

User Master Record

User master record enables the user to log on to the SAP R/3 system and allow limited access to functions and objects based on authorisation profiles. User master records are client-specific. You must maintain user master records for each client in an SAP system.

All users should have a unique identifier (user ID) for their personal and sole use to ensure that activities can be traced to the responsible individual. In exceptional circumstances where there is a clear business benefit the use of a shared user ID for a group of users or a specific job can be used. Approval by management should be documented for such cases. Additional controls may be required to maintain accountability.

SAP*

The standard SAP user SAP* presents a particularly high risk because it contains full access rights to the SAP system and has standard passwords which are widely known. SAP* should never be used in any system and shall be controlled via the following measures:

Lock the user id SAP*
Remove all profiles from user SAP*
The ABAP report RSUSR003 should be run on a regular basis to check the security of the standard SAP users in all systems.
Background batch user

Background jobs are not to be dependent on an individual's user ID. Instead all jobs should be scheduled to run under a specific background job user ID. This user should be a system user secured to an appropriate user group and will usually have wide access such as SAP_ALL. The ability to schedule a job under such a user ID will be tightly controlled.

Setting up Remote Communications

There are minimum acceptable settings that must be followed when setting up an RFC for dial up connection (transaction code SM59).

The following guidelines are to be adhered to:

Access to transaction SM59 should be limited to only Basis Administration personnel.
User accounts used, as interface accounts between two systems must be a non-dialog user type and assigned to the user group NON-DIALOG.
SAP account setup for OSS connections

Periodically, SAP will need to be able to log on to a client SAP system in order to look into OSS problems that have been submitted.  Such requests will require three things be implemented:

1. Open service connection.

SAP user account and password.
Basis team to open appropriate service connection.
Generally, requests are submitted for the non-production environments. However, from time to time, a request for production is submitted. Access to the production environment must only be for display and approval must be received from the customer system owner. If the error can be duplicated in a non-production system, access should be granted in a non-production system FIRST. Access to a production system should be the last resort.

The Basis team is responsible for opening and closing service connections. The Security team is responsible for managing and setting up of user accounts needed by SAP. To facilitate the set up of an SAP user account and to more easily identify such accounts later on, standardisation is necessary.

The following standards should be applied:

User ID - Should be in the format SAP-xx, where xx is the application that is being researched (e.g.: SAP-BC, SAP-JV, and SAP-FI).  This will allow for identification (if anything is updated in the system) of the appropriate module.  It also allows for multiple SAP users to use the system at the same time and have a unique id for each.

Valid Until - have an end validity date

OSS service connections can only be opened for a maximum of 10 days.

Profiles - In the non-production clients, it is recommended that the account be assigned the same access as the person making the request, assuming that ZZ roles are assigned and SAP_ALL and SAP_NEW are not assigned. This will allow all user transactional access and support access.

In addition to the standard R/3 authentication mechanism of each user requiring an individual user id and password the following system parameters should be set:

In addition to the standard R/3 authentication mechanism of each user requiring an individual user id and password the following system parameters should be set:

Parameter
 Setting
 
Number of times user can attempt log on

login/fails_to_user_lock = 4
 4 times thereafter user locked
 
Users locked due to incorrect logons

login/failed_user_auto_unlock = 0
 Users are not unlocked automatically
 
Number of failed logins before a session is ended

login/fails_to_session_end = 3
 3 times thereafter session is ended
 
Minimum length of password

login/min_password_lng = 8
 8 characters
 
Password change enforced

login/password_expiration_time = 35
 Every 35 days
 
Default client for a system

login/system_client = nnn
 Main client
 
User SAP* automatically created after deletion

login/no_automatic_user_sapstar = 1
 Switched off
 
Authorisations in user buffer

auth/auth_number_in_userbuffer = 3000
 Set to Maximum (3000)
 
Profile Generator active in Production

auth/no_check_in_some_cases = Y
 Profile Generator activated in Production
 
RFC's called from ABAP programs perform authority check

auth/rfc_authority_check = 1
 Switched on
 
Length of inactivity before user is logged out

rdisp/gui_auto_logout = 7800
 2 hour

There are many basis or development type functions that should not be available for end users in Production, such as programming, debug with replace, or transport.   These should be carefully evaluated and access restricted from business end users.  Most of these transactions are in Basis (beginning with S*), therefore, system-wide impact if used carelessly.  Also, they will be flagged by audits as a high-level risk factor.

It is important to note that some of these transactions are still needed by application support, basis, or security administrators.  Access to them should be carefully evaluated and granted where appropriate.

There should also be an emergency exception policy in place to accommodate an emergency request for access to these transactions in production.

It is important that security is considered during the initial stages of development design and build.  The following areas need to be reviewed and communicated to the proper application team members and developers.

Report Security

Release 4.5 and later

For systems implementing in SAP releases 4.6 or later, every report or program must be assigned a transaction code and then assigned to a role.   Once the changes have been transported to production, the user will immediately have access to the new functionality.

Customer ABAP Security

During the gathering and creation of ABAP specifications, serious consideration must be given to data security.  Depending on the data level requirements, there are two options for securing ABAP reports or programs.

1.    Transaction Level

The first level of security that is checked is at the transaction code level.  All transaction codes are checked against authorisation object S_TCODE.  If no data-level security is required, at a minimum, the execution of reports and programs can be controlled at this level.

This assumes that the following are true:

No restrictions are required for the data.  Users who can run the report or program using this transaction code can see data or update all records without regards to organisation specific data.

The value '*' or ranges of transaction codes are not assigned in any role for authorisation object S_TCODE.

2.    Data Level

Reports or application programs that require read-only or update at the data level must have an AUTHORITY-CHECK statement included in the ABAP code.  ABAP specs should indicate the authorisation objects that are included in the AUTHORITY-CHECK.  If data security is not required, the specs should state the reasons why it was not required.

It is the responsibility of the ABAP developer to ensure that the security team is contacted for the appropriate security authorisation object to use.  Once all required security checks have been incorporated in the ABAP program, they must be tested and signed off by an authorised business approver(s).  ABAP specs should be reviewed as part of the transport change control process.

Thousands of repository objects are delivered by SAP and the majority of these are either unsecured or are assigned to inappropriate authorisation groups.  Any programs required by the user and not present on a reporting tree (releases prior to 4.5) must be individually assigned to customer transactions.  These transactions are then protected by S_TCODE.

Tables within the SAP environment are critical to the reliable and efficient processing of applications.  Controls surrounding the maintenance of tables will be determined by the type of information contained within the table and the potential impact of a change.

Direct customer table maintenance SHOULD NOT be allowed in the production system via transaction SM30 or SM31.  Generally, customer tables begin with Z* and must be protected by a Z authorisation group.  Depending on business security needs, access should be controlled via a parameter or variant transaction, which may call SM30 or SM31 and skip the initial screen, or an application program.

To maintain a customer table, a customer transaction must be created and a customer authorisation group assigned to the customer table.  Then, the customer transaction must be included in the appropriate role.  Tables, customer created or SAP delivered, assigned authorisation group &nc& or spaces should be modified and assigned a Z authorisation group.

Direct table maintenance via this method allows maintenance or display for ALL records of the table and does not provide record level security.  If record or field level security is required, an application program must be written to update the table.

Exceptions to the above approach must go through a very rigorous approval process.

1.    Table Authorisation Group Naming Standard

Many tables delivered from SAP or customer tables created and not assigned an authorisation group default to &nc&.  Allowing users to access tables assigned authorisation group &nc& will allow update or display access to a myriad of tables.  Therefore, to minimize risk and based upon best practices from SAP, tables which require that a user be able to either display or update should be assigned an authorisation group and not left with the default value.

      Table display or maintenance is controlled by authorisation object S_TABU_DIS.
      An authorisation group can be assigned to one or more tables.
      Transaction code SE54 is used to create/maintain authorisation groups and to assign the authorisation group to the table.
The following naming standard should be applied when creating table authorisation groups:

ZABB, where

Z - Custom (required for all authorisation groups)

A - Closest related SAP module abbreviations

BB - Freely definable

All ABAP programs, reports, or table maintenance screens must be tied to a transaction code.  This ensures that transaction based security (authorisation object S_TCODE) is utilised and can be incorporated in the appropriate security roles.

The security team should handle the creation or maintenance of customer transactions.  This ensures that appropriate controls are in place and that the appropriate security roles are updated with the necessary access.

Custom Authorisation Objects

Customer authorisation objects are sometimes needed in order to provide data level security to customer ABAP programs that are specific to a customer's business need.  In such cases, a customer authorisation object must be created.

All customer authorisation objects should be placed in a customer authorisation class 

Naming standards for customer authorisation objects should follow the guidelines below:

Z_xxxx_aaa, where

xxxx = data type / function (such as customer master, vendor master, business specific data, etc).  Use SAP delivered authorisation objects as a guideline.

aaa = organisation level requirement (such as BUK, WRK, etc)

Documentation for the authorisation object must be completed with the following information and included in the object documentation in SAP:

Definition - Explains the purpose of this authorisation object.

Fields - Lists out each field contained in the authorisation object and possible valid values for each field.

Examples - Provide examples of use where necessary.

Ensure that the customer transaction code and required customer authorisation objects are updated in USOBT_C/USOBX_C tables (transaction SU24).

Custom ABAP Queries

Customer ABAP queries should be transported from a development system, tested in a quality and assurance system, and then promoted to production.

Queries should be assigned to a reporting tree (up to release 4.5) and applied appropriate authorisation group security as necessary, or attached to a transaction code (preferred).  A member of the Security team should complete the report tree or create the transaction code to ensure that the appropriate security role is updated as well.

Any custom development work must flow through a security approval process to ensure that the necessary security requirements have been implemented prior to promotion to the Quality and Assurance (QA) system for testing.  Therefore, program security, used in conjunction with reporting tree security or transaction code security, is very important in the design process.

Development requests for new programs, transaction codes, report tree, or tables should include a security review to ensure that:

1) security needs are met and 2) appropriate security roles have been updated to reflect business requirements.

Generally, it should follow the process outlined below:

A request is approved for the ABAP team to perform work.
ABAP member will contact security team to discuss proper control requirements as required by the business.
Security team will work with the business requestor  to determine security role to be modified.
ABAP member will include proper controls, such as AUTHORITY-CHECK, as needed, in the program code.
Security team member or ABAP team member, depending on customer's development team structure, will create a transaction code (release 4.5 and later).
Security team member will make appropriate profile changes.

Most SAP installations develop huge amounts of custom code. This leads to security problems: 

The code usually contains security weaknesses so an attacker can use weakness at the code level to bypass role concepts; call critical transactions and impersonate other users; change or delete critical business data 

SAP GRC tools are reporting only mechanisms and do not detect such errors - they allow you to input an authorisation concept and but do not act on the implementation at code level. 

Also, the sheer complexity of the SAP system often overwhelms the average SAP support team and this complexity is increasing by the count of tables, transactions and security objects in each upgraded version of SAP. The business processes are multi-dimensional and the main control of subjugation is difficult to achieve. 

Information is commonly stored in different places with master data, (usually subject to intense scrutiny and monitoring) ineffective because you can modify data coming from master data and configuration tables at several points in a standard business process - so not much of a control environment.

This weakness with master data is a major control challenge when implementing effective SAP security.