SAPLIB

2 Security and access protection
2.1 Objective
An access protection system and the ability to grant individual authorizations basically serves four purposes:
- To protect confidential data against unauthorized disclosure
- To protect the data against unauthorized, but also against unintentional, changes or deletion
- To facilitate the transparency of the procedures by tracing exactly who did what in the system, and when.
- To guarantee that applications can be audited.

According to commercial law, these measures (i.e. preemptive controls in the internal control system) should prevent violations of any legal restrictions on the erasure of electronically stored data. They should also guarantee legally required audit trail traceability and ensure that no violations against complete and orderly accounting occur. These measures ensure, then, that no data which is unauthorized, incomplete, incorrect, or posted to the wrong period or account is entered into the system.

2.2 Requirements
The access protection system must ensure that only authorized individuals have access to the system and to particular data. It must be possible to key in the corresponding codes (passwords) without others being able to see them. The system should ensure that:
- only passwords of a defined minimum length are accepted,
- certain sequences of characters that could be easily guessed are not accepted,
- the password may be defined and altered by the user only,
- the system automatically demands the password to be changed at defined intervals,
- passwords are protected against being divulged to anyone other than the user him/herself.

The authorization concept must ensure that the user’s rights of access are restricted to those activities in the system that are absolutely imperative for him/her based on their function/responsibility within the firm (principle of minimal authorizations); in other words, the concept must envisage as deep a hierarchical structuring as possible in respect of
- the nature of the data access (reading, creating, changing, deleting),
- programs,
- data or data files,
- functions (menus, menu lines)
in conjunction with as many different combinations of these levels as possible.

2.3 SAP facts
A new process for creating and maintaining user masters, profiles and authorizations, and for protecting access to the system, was introduced with Release 5.0. With the new authorization concept, you can allow and control user access to the R/2 system at a more precise level, and with more flexibility than in earlier versions of the software. You can now assign a user different authorizations for different company codes, i.e. the ability to change data in company code 01 but only to view data in company code 02. The new concept also contains security measures which reduce the chances of unauthorized logons or unauthorized accesses of user masters and system authorizations. Following are some facts on managing user master records and authorizations:

2.3.1 The authorization concept - basics Authorization objects (i.e. data, transactions, tables etc.) are protected by authorizations or collective authorizations which are allocated to the objects like locks to a door. They contain Values (i.e. a concrete company code 01) for fields which you define for an accompanying authorization object (BUK). Authorization Profiles are like keys for the user, and a collective authorization profile is comparable to a set of keys on a key ring. These ‘keys’ are entered in the user’s master record. A check is made to determine whether a user’s authorization profile is appropriate for an authorization, similar to determining if a key fits a lock, when, for example, a program is running and the word AUTHORITY CHECK appears in the ABAP coding.

2.3.2 Collective authorizations and profiles You can build complex authorization structures from simpler ones by combining authorizations to collective authorizations and profiles to collective profiles. With this technology, you can create a collective profile for accounts receivable clerks in company code 01, for example. Each employee with that job description will then have this collective profile in their user master. If the profile needs to be changed, you will only have to do so once, not in each user master.

2.3.3 Separating maintenance and activation Thanks to some new transactions, the maintenance and activation of authorization components and user master records can now be separated, a development which further improves security. Also, you can now restrict a person’s maintenance authorization to specific users, profiles and objects.

2.3.4 User master record The user master record contains a listing of the profiles and/or collective profiles assigned to the user. A reverse inheritance principle applies here, meaning that changes made at a level lower than user master record level will affect all higher levels up to and including the user master record.

2.3.5 Password protection and logon You can assign user-specific initial passwords to improve protection for passwords and logging into the system. New passwords also have to go through multiple checks.

2.3.6 Authority check The key word AUTHORITY CHECK from the ABAP/4 programming language was reworked appropriately for the authorization check. The RAUTX macro replaces the assembler macro RAUTH for new developments.

2.3.7 Upstream security systems In many cases companies that operate SAP systems additionally make use of an upstream security system such as RACF. In such cases it is possible to combine both systems, which as a rule spares the user the need for a double identification in the system.

If a user runs an upstream security system, this takes over the task of verifying the identity of the user (authentication). Further authorization checking takes place within the SAP System.

2.3.8 Table TSTC - SAP transaction codes It should also be noted that authorization checks for transactions can be overridden via Table TSTC.

2.4 Risks
The high flexibility of the SAP user administration concept can lead to considerable security risks if used improperly. For example, using SAP standard transactions it is possible to close down the system, terminate the posting task and change master data without generating a log. A user with programming authorization TM38 can remove the authorization check altogether from existing programs.  because of the complexity of the new authorization concept, many users adopt the standard profiles shipped by SAP, without really checking them, and without carefully adapting them to their own business requirements. These examples highlight the fact that security - and hence also the proper and orderly functioning - of the entire system is directly dependent on the authorizations granted. You must, therefore, be extremely careful when allocating authorizations!

Prior to checking processing results, it is always necessary to check the user authorizations in order to make sure that the processing results are based on authorized routines and entries.

Popularity: 31% [?]