Transcript Authorizations Overview - Orley House Consulting

Authorizations
in SAP
Agenda
•
Governance, Risk and Compliance
•
SAP Authorization Concept
•
User Management
•
Role documentation
•
Troubleshooting Tools
•
SAP Standard Compliance Tools
Governance, Risk and
Compliance
“The relevance of data, or the risk group to which the data belongs, is often
unknown. That is why data remains unprotected.“
(SAP Security and Authorizations - SAP Press)
Key Risk Areas
•
Insufficient functional separation of tasks
•
Missing or partially completed documentation
•
Risks not identified, or inadequately identified
•
Authorization design does not meet requirements
•
User Management incomplete
•
No integrated system dedicated to the management of users and
authorizations
Key Consideration for GRC
• Risk strategy
– Identification of activities that could lead to harm, danger, or loss
• Governance strategy
– "In simple terms Governance is the Set of Processes that keeps the organization alive,
and regulating the internal information flows and decision processes that ensure that its
responses are timely and appropriate“ (Vikas Chauhan, SAP)
• Compliance strategy
– “Compliance is the mechanism that makes governance work. It is compliance with the
organizations own required procedures that enables management of the risks that
endanger the entity. Monitoring and supporting compliance is not just a matter of
keeping the regulators happy; it is the way that the organization monitors and maintains
its health. “(Vikas Chauhan, SAP)
Risk Governance and Compliance
• Recognise and analyse vulnerabilities
• Evaluate data, processes, and systems and need for protection
• Address differences between actual state and target objectives
• Definite user authorizations for data, transactions, and systems with
segregation of responsibilities
• Define administrative processes for managing users and authorisations
• Implement effective change management to provide controlled management of
users and authorizations
• Define monitoring, quality assurance processes and internal controls
Defining Authorizations
• Establish a reliable authorization plan
• Define the user roles that allow you to perform specific tasks in the SAP
System.
• Develop a stable and reliable authorization plan.
• Define procedures for creating and assigning authorizations
Ongoing Definition
• Regularly review the authorization plan to make sure that it continually
applies to your needs.
SAP authorization Concept
Authorization Checks
• All access in SAP is based on the authorization objects that are assigned to the
User who logs on to the system
• Transactions, reports, data tables, programs and activities are protected by
means of authorization checks
• In many SAP modules, transactions are the fundamental building blocks of the
authorization concept.
• SAP HCM is slightly different, as although transaction provide access to the user
interface, data access is controlled via ‘infotypes’
• As well as protecting transactions and their data, transactional authorizations
also restrict organizational and functional elements
Transaction:
Create Material
Transaction code:
MM01
Organizational Restriction:
Company Code
Technical Information
• There is an ABAP program behind every transaction
• Authorization checks are built into the program code
• Programmers commonly use the AUTHORITY-CHECK statement which checks
a specific authorization object at a specific point in the program.
• Authorization objects are used to assign authorizations or restrict access to
transaction codes, activities and data
• To successfully run the program a positive result has to be achieved when the
program is in use
• SAP Systems only allow users to execute transactions or programs if they have
explicitly defined authorizations for the activity.
HR Authorizations
• HR authorizations are built largely around the ‘infotype’ data concept
• Infotypes are data storage areas for HR data
• One transaction potentially gives access to all HR master data (PA30). Unlike
other modules, however, access to the transaction does not grant access to
the database
◦
◦
◦
◦
◦
P_ORGIN – authorizations for HR Master Data in PA
P_ORGINCON – context sensitive authorizations for PA data
PLOG – authorizations for HR Master Data in PD
P_PCLX – authorizations for data stored in clusters
P_PERNR – Personnel Number Check
Structural Authorisations
•
•
Structural Authorizations
–
Assigned to Users in addition to their Role
–
Restrict Users to parts of the Organisation Structure
–
Optional
Structural Authorization with Context
Required where a user has several roles with the Organisation
Example:
–
Time Administrator – updates absence details for own team
–
Training Administrator – updates training records for whole company
SAP Role Concept
Role Concept
The Purpose of Roles
– Allow groups of users with similar access rights to be assigned to the same role,
– Contains screens / transactions and reports in a User Menu
– Contains authorization objects that relate to data that users are permitted to access
The number of Roles defined in an Organisation will depend on:
– Functionality implemented
– Segregation of duties requirements
– Other Governance, Risk and Compliance considerations
Examples
– Payroll Control
– HR Administrator
– Financial Controller
– Audit
Combining Roles
When creating composite roles, SAP will always give the user the highest
authorisation available
• Example:
– Role 1: Read only access to Salary
– Role 2: Maintain access to Salary
– Result: User has Maintain access to Salary
Combining roles can lead to Segregation of Duties issues.
Before adding a role to a user, be sure to understand the implications of the
combination.
Composite Roles
• Composite roles allow you to group together ‘approved’ role combinations.
• Administrators can therefore assign role combinations without having to worry
about whether this will violate the Organisation’s security policy
• Assignment of a number of individual roles also results in the user having
multiple role menu.
• Composite Roles can have their own role menus, allowing consolidation /
removal of duplicates.
Derived Roles
• The concept of ‘Derived Roles’ allows you to have several variations of the same
role
• A ‘parent’ role is created and ‘child’ roles can then be ‘derived’ from that role with
slight variations for ‘Organization level’ objects
• A common example is for a finance role to be created with several variations at
the Company Code Organization level
– Or
• An HR role created with several variations at the Personnel Area Organizational
level
• Changed to the parent role are inherited by the child roles, except for
Organizational level objects, or objects that have been directly changed in the
child role
Role Description
The description tab
should provide a
summary of what the
Role is used for, and a
summary of what
access is granted
Role Menu
The Menu tab shows
the transactions that
have been allocated to
the Role.
CAUTION: Adding a
transaction here will
affect values in the
‘Authorizations’ tab.
Role Authorizations
The Authorizations tab
shows a summary of the
Authorization detail for the
role, including the Profile
Name allocated to the
role.
Clicking on the icons in
the ‘Maintain’ area give
access to the
authorization detail
Authorization Profile
The values in this area are what
control access to transactions
and data.
Authorization objects are
divided into Application areas
Restrictions are set according to
objects and activities
User
The ‘User’ tab shows all
users that have been
allocated this role.
Note: If users are shown
in this tab, and the traffic
light shows ‘red’, you
must conduct a ‘User
Comparison’
User Comparison
• This function runs program PFCG_TIME_DEPENDENCY which ensures that
authorization profiles are in alignment with user master records
• Profiles that are no longer current are removed from the user master records,
and the current profiles are entered.
• User comparison should be carried out If the traffic light on the ‘User
Comparison’ button is red. To carry out user comparison, click on the button.
• You can compare the user master records automatically when you save the role.
To do this, choose Utilities -> Settings and choose the option to compare the
user master records automatically when you save the role.
Structural Authorisations
•
Structural Authorisations
–
Assigned to Users in addition to their Role
–
Restrict Users to parts of the Organisation Structure
–
Optional
Structural Profile Set-up (Transaction OOSP)
Use of Function Modules
Function modules dynamically determines a root object at runtime. No entry needs
to be made in the Object ID field in this case.
Standard Function Modules:
RH_GET_MANAGER_ASSIGNMENT
This function module determines as the root object the organizational unit to which
the user is assigned as manager via relationship A012 (is manager of).
RH_GET_ORG_ASSIGNMENT
This function module determines as the root object the organizational unit to which
the user is assigned organizationally.
Customers can define their own function modules which can dynamically
determine the root object.
Structural Authorization Profile Maintenance
• In the example above, the root object ID is specified as 50000587
• Commonly used objects in Structural Authorisations:
– O – Organization Unit
– S – Position
– P – Person
Structural authorizations can be used to control any PD hierarchy i.e. training and
events, appraisals etc.
Assigning Structural Authorizations (transaction OOSB)
User Management
User Master Record
• User Master Record
–
Required to logon to SAP
• Contains
–
–
–
–
–
–
–
–
Password
Validity
Default settings for date formats, etc.
User Parameters
Roles
Profiles
Groups
Personalization
User Parameters
• User Parameters
– Parameters can be set for users which control default values, screen layout, and
sometimes even access in some transactions
– UGR: HR User Group
◦ Controls screen layout, Menu layout, Personnel Actions list
– CRT: Currency
◦ Default currency
– CAC: Controlling Area
◦ Default Controlling Area
– BUK: Company Code
◦ Default Company Code
Logon and Password Parameters
• All of the following are controlled using system settings:
– Minimum password length (e.g. minimum 8 characters)
– Minimum number of digits/letters/special characters in password (e.g. password must
contain at least one digit)
– Password expiry time (e.g. 30 days)
– Rules for unsuccessful logon attempts (e.g. lock-out after 3 failed attempts)
– Impermissible passwords (e.g. ‘password’)
– Password re-use (e.g. cannot re-use the last five passwords)
– Validity of new passwords
– Validity of reset passwords
Rules for Users
Logging off Inactive Users
• There are logout settings against each SAP system e.g.
– SAP R/3
– Portal
– Solution Manager
• There area also logout settings for individual services
Special Users in SAP
What are Special Users?
– Special users are used to allow a greater level of system
– This may be due to a specific trouble-shooting requirement that requires more access
that would normally be granted
– May be needed to suspend normal segregation of duties under exceptional
circumstances
Why use Special Users?
– Allocation of Special users can be closely time controlled
– Easier to track / audit use of special users than to track the addition of authorisation
rights to an existing user
SAP_ALL
• SAP_ALL is not a role, it is a Authorization Profile
• No ‘normal’ user should have SAP_ALL in a Production environment.
• Roles with similar access to ‘SAP_ALL’ are commonly created for ‘special’ users
that can be allocated in emergencies
SAP_NEW
• SAP_NEW, like SAP_ALL, is an Authorization Profile rather than a role
• A new SAP_NEW profile is provided for each release
• Contains full authorization for any new authorisation check introduced by SAP in
the upgrade
• Commonly assigned to all users after upgrade to ensure that new functionality
can be accessed
• Ideally, however, the authorisations contained in the SAP_NEW single profile
should be distributed to roles and profiles that are used productively
• Once new authorization objects have been distributed, the profile assignment for
SAP_NEW and the SAP_NEW profile can be deleted
Role Assignment
– Direct Assignment
◦ Role assigned to User ID
◦ Changes are manual
Organisation Unit
– Indirect Assignment
Position
◦ Role assigned to position, job or
organisation unit
Role
◦ Changes are automatic
Person
User ID
Indirect Role Assignment I
• Roles are assigned to positions or ‘Jobs’ using infotype 1001 relationship:
– Position / Job > is described by > Role (object type AG)
• Structural Authorisations are assigned to positions or ‘Jobs’ using the ‘PD
Profiles’ infotype (infotype 1017)
• Program RHPROFL0 assigns roles to individuals according to the position that a
user occupies (scheduled background job).
• Result: The user receives authorisations according to the position they occupy.
Indirect Role Assignment II
New Hire / Org
Reassignment
User Name
(infotype 0105)
Position / Job
Assignment
Details
Role
Structural
Authorisation
Person
Program
RHPROFL0
User name
Position / job and
role assignments
RHPROFL0
Role Documentation
Role Definition
The first step in the process is to define the different business roles within the
Organisation.
• These business roles will help define the system access required
• Examples:
– Financial Controller
– HR Administrator
– Payroll Manager
• Each of these roles will have different system access and segregation of duties
requirements
Roles will also be required for implementation and for support
• Examples:
– SAP System Administrator
– User/Role Administrator
– Emergency Access
Role Definition Document (RDD)
Each role requires a written description of
the activities & functions that users with
this role will perform.
This should contain:
– Owners
– Purpose and business processes
– Included access and specific exclusions
– Sign-off
The document should be non-technical to allow end users to understand the
purpose of the role and the access that it grants.
The document should give the information necessary for the technical build, role
testing and role assignment
Documents should be version controlled to allow role changes to be tracked
Role Definition – Technical Detail
Authorisation Object Access e.g. spool list, batch input
Role Menu / Transaction Access
Infotype Access e.g. read only, maintain
Organization Object Access e.g. Company Code, Personnel Area, Employee Group
SAP Troubleshooting tools
SU53
• Standard mechanism for investigating authorization failures
– An administrator can run the transaction for any user
– Output will usually show which authorization object caused the failure
• Limitations:
– Shows the most recent authorization check, so must be run immediately after the
authorization failure
– Only shows the authorization object that caused the failure. Does not show all the
authorizations that would have failed, so it can be laborious working through failures one
by one
– Can give misleading results, depending on the type of failure
ST01 Trace
Setting the Trace
• Restrict the trace to ‘Authorization
Check’
• Add a filter to restrict the trace to
a specific user
• Click on the ‘Trace On’ button
• Click on ‘Trace off’ when the trace
is completed (the system trace
affects system performance)
Trace Analysis
• Ensure that the ‘From’ and ‘To’
fields encompass the time that the
activity was carried out
Trace Display Detail
• In the example, authorization object S_CTS_ADMI was checked.
• RC=0 indicates that the return code was 0 i.e. the authorization check was
successful
• If the RC value is any value other than 0, the authorization check was
unsuccessful i.e. the user did not have the necessary authorizations to carry out
the activity
Transaction SUIM
Role Comparison (RSRUSR050)
SAP Standard Compliance tools
Critical Authorizations
Maintaining Rules
• Maintain critical authorizations
– If you enter a transaction name, the values of the authorization object entered in
transaction maintenance are automatically transferred to the authorization data of the
selected ID
• Maintain Critical Combinations
– Enter critical combinations of the authorizations you have defined in the ‘critical
authorizations’ area
Running the Report
The result lists differ depending on the type of the selection variant:
• For Critical Authorizations
– The selected users are grouped by the IDs of critical authorizations. To check which
critical data is represented by an ID, click on the name of the ID. To analyze the
authorization data of a user master record, select the user by double-clicking it.
– You can use the Profiles and Roles buttons to display lists of profiles and roles assigned
to the selected users.
• For Critical Combinations
– The selected users are grouped by critical combinations. If you select a combination
name, the corresponding critical data is displayed.
– The other functions correspond to those for critical authorizations.