Overview of SAP Authorisations

This document is intended as an introduction to auditing SAP Security

Subscribe to our tutorials

1. The SAP R/3 authorisation concept

[Edit]

New Launch X431 Master

Ne w Launch X431 Maste r -1,690 e uros Fre e 3 Day Shipping To Europe
www.diagnostics4u.com

The SAP R/3 authorisation concept permits the assignment of general and/or f inely detailed user authorisations. These assignments can reach down to the transaction, f ield and f ield v alue lev el. These authorisations are centrally administered in user master records. Actions by a user may require sev eral authorisations. For example, to change a material master record, authorisations are required f or the: Transaction 'change' Specif ic material ty pe Views of the material master record General authorisation to work with the company code The resulting relationships can become v ery complex. The SAP R/3 authorisation concept is based on authorisation objects. Each authorisation object is a combination of authorisation f ields. An authorisation alway s ref ers to an authorisation object and can contain interv als f or the authorisation f ield v alues. Authorisation checks protect the f unctions or objects a user chooses. Standard-deliv ered SAP R/3 f unctions or objects hav e these checks embedded in the program logic. Authorisation administrators create authorisations that are assigned to users in collections called prof iles. The Prof ile Generator (PG), a standard tool in SAP R/3, usually generates authorisations and authorisation prof iles, although authorisations can also be manually inserted into a prof ile.

Top BI Software 2011

Ge t Fre e BI Evaluation Re ports for Software Se le ctions & C om parisons.

TechnologyEvaluation.com

Management & Informatics

www.mmi.usi.ch

MSc in Switze rland Unive rsity of Lugano

SAP Staffing Specialists

2. Terminology

[Edit]

Focuse d e xclusive ly on the place m e nt of SAP profe ssionals

www.gmatters.com

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 f ields in an 'AND' relationship. All the f ields are checked simultaneously to check whether a user is allowed to perf orm a certain action. Users may only conduct an activ ity if they satisf y the authorisation check f or each of the authorisation f ield in the authorisation object. Authorisation Field This is the smallest unit against which the authorisation check is done. The f ields in an authorisation object are linked to data elements in the SAP ABAP Dictionary. The permissible v alues constitute an authorisation. When an authorisation check takes place, the sy stem checks the v alues that y ou hav e specif ied in an authorisation against those required to carry ing out the action. Users may only carry out the action if they satisf y the conditions f or ev ery f ield def ined f or a specif ic authorisation object. Authorisation An authorisation is the authority to perf orm a particular action in the SAP R/3 sy stem based on a set of authorisation f ield v alues in an authorisation object. Each authorisation ref ers to exactly one authorisation object and one or more possible v alues f or each authorisation f ield listed f or that authorisation object. Authorisations are utilised in the user master record as roles. By themselv es, authorisations do not exist. They only hav e meaning inside a role. Authorisation Profile Authorisation prof ile contains authorisations f or dif f erent authorisation objects. User authorisations are assigned using authorisation prof iles. Once a prof ile is changed, the changes will af f ect all users to whom this prof ile is assigned and take ef f ect only when the user logs on. Users who are logged on when the change takes place remain unaf f ected during their current session, but when they log on again, their prof ile will change accordingly. A user's authorisations are loaded into the user buf f er only when they logon on. To automatically generate an authorisation prof ile, y ou must f irst create a role. Role A role is a set of f unctions/transactions describing activ ities or a specif ic work area. The Account Receiv able Accountant role, f or example, contains authorisations to transactions and Reports needed by the accountants f or their daily work. A role can be assigned

MES Availability

Le arn how to achie ve 99,999% uptim e for your MES e nvironm e nt

www.stratus.com/sap

inappropriate authorisation groups. Any programs required by the user and not present on a reporting tree (releases prior to 4.5) must be indiv idually assigned to customer transactions. These transactions are then protected by S_TCODE.

8. Custom Table Maintenance Security

[Edit]

Tables within the SAP env ironment are critical to the reliable and ef f icient processing of applications. Controls surrounding the maintenance of tables will be determined by the ty pe of inf ormation contained within the table and the potential impact of a change. Direct customer table maintenance SHOULD NOT be allowed in the production sy stem v ia 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 v ia a parameter or v ariant 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 deliv ered, assigned authorisation group &nc& or spaces should be modif ied and assigned a Z authorisation group. Direct table maintenance v ia this method allows maintenance or display f or ALL records of the table and does not prov ide record lev el security. If record or f ield lev el security is required, an application program must be written to update the table. Exceptions to the abov e approach must go through a v ery rigorous approv al process.

Custom ABAP Queries Customer ABAP queries should be transported f rom a dev elopment sy stem, tested in a quality and assurance sy stem, 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 (pref erred). 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.

10. Dev elopment Security Rev iew Process

[Edit]

Any custom dev elopment work must f low through a security approv al process to ensure that the necessary security requirements hav e been implemented prior to promotion to the Quality and Assurance (QA) sy stem f or testing. Theref ore, program security, used in conjunction with reporting tree security or transaction code security, is v ery important in the design process. Dev elopment requests f or new programs, transaction codes, report tree, or tables should include a security rev iew to ensure that: 1) security needs are met and 2) appropriate security roles hav e been updated to ref lect business requirements. Generally, it should f ollow the process outlined below: A request is approv ed f or the ABAP team to perf orm 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 modif ied. 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 dev elopment team structure, will create a transaction code (release 4.5 and later). Security team member will make appropriate prof ile changes.

11. Weaknesses in SAP Security

[Edit]

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.

Home | Terms | About | Site Map