Authorisation management is among the most audited parts of Basis. Controlling who can do what is basic internal control.
The user master
| Type | Purpose | Can log on? |
|---|---|---|
| Dialog | A human user | Yes |
| System | Background processing and RFC | Not via GUI |
| Communication | System-to-system RFC | Not via GUI |
| Service | Anonymous access | Yes, multiple sessions |
| Reference | Collects shared authorisations | No |
Roles and profiles
| Kind | Content |
|---|---|
| Single role | The basic unit of authorisation |
| Composite role | Several single roles bundled by job function |
| Derived role | Inherits authorisations, varying only organisational values |
Derived roles suit the same job performed at different sites: one parent buyer role, derived per plant, so only the accessible plants differ and changes to the parent propagate.
Authorisation objects
M_BEST_WRK (purchase order / plant)
ACTVT: 01 create, 02 change, 03 display
WERKS: 1000, 2000
-> the user may create, change and display
purchase orders for plants 1000 and 2000| Object | Controls |
|---|---|
| S_TCODE | Which transactions may be started |
| S_PROGRAM | Which programs may be run |
| S_TABU_DIS | Table display and maintenance |
| S_DEVELOP | Access to development objects |
| S_USER_GRP | User administration |
| S_BTCH_JOB | Background job operations |
Investigating authorisation failures
| Code | Purpose |
|---|---|
| SU53 | The last failed authorisation check; quickest |
| ST01 | Authorisation trace with full detail |
| STAUTHTRACE | Longer traces across several users |
| SUIM | Reports on users and roles |
Segregation of duties
| Combination | Risk |
|---|---|
| Create vendors and run payments | Invent a vendor and pay it |
| Create purchase orders and post receipts | Record deliveries that never happened |
| Raise credit memos and release billing blocks | Issue fraudulent refunds |
| Create users and assign roles | Grant yourself unlimited access |
| Develop and transport to production | Put untested code live |