Answers to Your Top 10 SAP Access Control

10.x Design and Configuration Questions

Ruth Johnson
Customer Advisory Group
Produced by Wellesley Information Services, LLC, publisher of SAPinsider. © 2016 Wellesley Information Services. All rights reserved.
In This Session

• Tackle some of the toughest questions customers have about SAP Access Control
design and configuration
• Learn how to jump the most common stumbling blocks and weigh your options
• Opportunity to get some answers to your own configuration questions

1
What We’ll Cover

• General Configuration Settings

• Configuration for SOD Rules
• Configuration for MSMP Workflows
• Wrap-Up

2
Configuration Parameters

• Many of SAP Access Control’s features are controlled by Configuration Parameters

• Many “SAP-delivered” configuration parameters come in the system with Default values
 If you do not change the parameter settings, they will be processed with the defaults

• New configuration parameters are added with Support Packs

 Therefore, new settings are always being added

 New functionality is being delivered with these parameters

 Functionality may change with the introduction of a new parameter

 Original functionality may now be controllable with a parameter

3
Maintain Configuration Settings
Transaction: SPRO – Customizing – Edit Project
Select: SAP Reference IMG
Menu Path:
Governance, Risk and Compliance  Access
Control

4
Configuration Default Settings

• When you implement Access Control for the first time, this configuration setting table is
blank
 Even though the parameters have the default settings, they are not listed in this table
until they are entered by you

• A good practice would be to enter the parameters even if you are taking the default
 In troubleshooting later, it is so easy to forget that there are more parameters than
what you have set
 Example: As you are testing something that SAP has selected as a default setting, it
may not be what you would expect

5
GRACCONFIG Tables

• GRACCONFIG – Contains the parameters, the default value,

and whether that parameter will allow multiple entries

• GRACCONFIGT – Contains the parameter text description

• GRACCONFIGSET – Lists the parameters your

company has set

6
AC10 Config Settings Guide

• There is a Config_Settings guide listing

all of the parameters
 Explains the parameters

 What they control

 Sometimes how to configure

 Default values

• A new guide is developed every couple

of Support Packs and is available for
download on SAP Support Portal
• Two Config Setting Guide examples:
 AC10_1_Config_Settings_SP11

 AC10_Config_Settings_SP13

7
Param ID 1049: Default Management Report Risk Types

• Param ID 1049 – Controls what risks appear on the dashboards

 Original Access Control Dashboards displayed all risks

 When param ID 1049 was introduced, the control on what risks were displayed on the
graphs was given via a parameter
 If you implement practices
based on the original
controls, you may not
even have known that
this feature is now
configurable

8
Param ID 1052, 1053: Spool File Location

• 1053 – Spool Type

 If set to F (file) – writes all reports to a file folder on the server

 If set to D (database) – writes all reports to the database and GRACSODREPDATA table

 Remember, some reports are very large; saving them to database could cause
performance and database size issues

• 1052 – Spool file location

 If you select file, you need to configure the folder location

 Most Basis users would like to build a folder /usr/sap/<sid>/…

 Remember this folder will be transported, therefore whatever folder needs to exist on

GRC development, QA, and production

 Suggestion: /usr/sap/GRC/SYS/global/Spool/

9
Delete Spool Files

• With users being able to run GRAC reports in the background, the Background Jobs
spool library could get pretty large
 Need to determine how long reports are allowed to stay out on the spool location

 SAP has delivered a program to help manage the spools

 Transaction: GRAC_DELETE_REPORT_SPOOL

 Will delete/clean up the report data from the file system or table

10
Param ID 3009: Allow Role Deletion from Back End

• Parameter 3009 will control the ability to delete the role in the back-end system from GRC

• For both Access Request Management and User Access Reviews, roles need to be
loaded into Business Role Management (BRM) component of Access Control
 Through the Repository Sync jobs, roles between GRC and the back-end system are
synced
 As you load the Roles into GRC, you may want to delete them out of GRC for any
reason (they were loaded incorrectly, loaded too many for testing, incorrect data on the
role, etc.)
 Wanting to delete role from GRC does not mean you want to remove that role from

the back-end system

• But since BRM is a role management application, it does have the ability to delete roles
from back-end systems
11
Param ID 3009: Allow Role Deletion from Back End (cont.)

• SAP defaults this parameter to Yes – allow roles to be deleted from GRC

• Since roles are master data and are not configured and transported across GRC
Development, QA, and Production
 This parameter does not limit the back-end role deletes to development systems but
also any system where roles are loaded (such as production systems)

If you are not using BRM to manage/maintain your back-end roles and you are
maintaining control of your roles from your back-end systems, you may want to
set this parameter 3009 to No

12
SAP Business Client Launchpad – Custom?

• Custom My Home Page

 Display links that are most used at your company

 Common requests

 Add Copy Request to the

My Home page
 Remove Name Change

13
Customizing SAP Business Client My Home

• Transaction:
 LPD_CUST – Launchpad Customizing

 Allows you change the screen to display

the items most used for your users
 Saves them from jumping between menus to get all the screens they need

 In addition, it may give them the access they need so you don’t need to give them the
other Business Client folders that they don’t need or you don’t want them to have

If SAP provides updates to the content, then such changes update the standard
SAP-delivered repository and Launchpads; the changes do not directly update
any customized versions. To view the changes to the SAP-delivered versions and
to update your customized version go to Extra  Show SAP Version.

14
LPD_CUST Details

• Using LPD_CUST takes a little time to learn

but you could pick it up on your own

• Utilize the “Copy from Other Launchpad”

to use the link items that SAP has already
configured

15
Transporting the Custom Launchpad

• Changes to a launchpad are considered customizing and need to be transport

 But making changes does not automatically write to a transport

 You must manually put the launchpad on a transport when ready

 Top blue menu row

 Launchpad

 Transport

 Save to a Workbench
transport request
 You may need to use SE80 to transport if you have any trouble with the transporting

of the launchpad
16
Configuration Client Lockdown

• Not all Access Control configuration is locked down by system settings (SCC4)
 Although your system may have individually
overrode some of these settings
SCC4 – Client
• Two specific areas: SOD Rules Settings for
and MSMP Workflow locking down
client for config
 These type of activities can
be secured by authorizations
 Policies and Procedures should be written
and enforced to keep your Access Control
application integrity

17
SOD Rules – Best Practice for Maintenance

• SOD Rules should be maintained in the Development area and transported to production
 So they can be fully tested before affecting all SOD reporting

 Maintaining a “trust” or “confidence” in the SOD Rules

 What if someone ran a risk analysis report while you were working on the rules; one

minute they get this result and then next they get another, etc.

• SOD Rules are transported as Risks and Functions

• Generated Rules are not transported
 Therefore after a transport of SOD Rules, they must be generated in the systems they
are transported into

18
SOD Rules – Best Practice for Maintenance (cont.)

• Best Practice
 Maintain SOD Rules in Development

 Test in Development

 When approved – transport through QA to Production

 Generate SOD Rules when they get to QA or Production

• Building Security Roles

• Create a security role for SOD Rule Changes
 Remove this access from all other roles

 Including configuration roles

 Users should only have access to change SOD Rules if they have this one role

19
SOD Rules – Security Roles

• Create SOD Rule Display role or combine into other task roles
• Determine who should be allowed to generate rules as well as download them
• Rules can be generated through Business Client screens or by the following
transaction code
 GRAC_GENERATE_RULES

 Allows administrators the ability to generate the Rules in mass

• There are also some other transaction codes that directly affect SOD rules, so they
should be analyzed appropriately to determine who should have this access in
production
 Transactions such as:

 GRAC_COPY_RULES, GRAC_DOWNLOAD_RULES, GRAC_UPLOAD_RULES,

GRAC_RULE_DELETE
20
SOD Rules Authorizations

• Here are the authorizations that control SOD Rules

21
MSMP Workflow Transport and Generation

• MSMP workflows require transport request at the time of configuration

• MSMP workflows often require generate after transport into QA or Production

 You can give a user the ability to generate the workflow without changing the workflow

 Transaction to generate MSMP workflow

 GRFNMW_GEN_VERSION
 Transaction to check to view the MSMP versions
 GRFNMW_CN_VERA
 MSMP versions between Dev, QA, and Production will not equal

 Since MSMP workflows are configured and tested in development, there are usually additional
versions of these workflows in this system

22
BRFplus Rules Transport and Generate

• BRFplus Rules
 BRFplus rules are configured in development and transported through to production

 BRFplus rules do transport generated

 Generally generation of BRFplus rule in Production is not required

23
BRFplus Rules and MSMP Workflows

• BRFplus rules used in Workflows must be changed in Dev and transported to Prod
 When a BRFplus rule is created in a system, a Rule ID (number) is generated by that
system for that BRFplus rule
 If you maintain the rules individually in the systems, the Rule IDs will be different
 Since these Rule IDs are configured in the workflow, you must transport both the

Rule IDs and the MSMP workflows together

 If you choose to maintain BRFplus rules directly in the systems, you will need to

maintain the workflows in the individual systems as well

• Why do some feel this is an issue?
 You have created a BRFplus rule for an agent rule for a stage in the workflow, any
changes to those approvers must be done in Dev and require a transport
 If you have made a BRFplus rule for Business Process owner that changes all the

time, this could mean a lot of transports, as well as a time lag for changes
24
BRFplus and MSMP Workflows SHOULD Be Locked Down in
Production

• WARNING: In your systems you are able change these settings in your
environment so that MSMP workflow configuration and BRFplus rules do not
require transport
 But I will strongly warn against making this change

 Workflows need to work the same way in development, QA, and

production to allow for proper testing

 By allowing changes, your workflows will not work the same in each environment

25
Debug for MSMP Workflow

• SAP Note 1624069 GRC 10.0 – Enabling Debug Logging for MSMP
• Use SAP Document: EnableDebugLoggingforMSMP.pdf to turn on the workflow debug
• SAP Transaction: GRFNMW_DEBUG

• Use SAP Transaction AL11 to analyze the results

 SAP Transaction AL11 – SAP Directory: /tmp

26
Connector Groups

• How should connector groups be implemented, and how many are required?
• Connector groups are a way of grouping systems together for different purposes
 For instance:

 Connector groups for SOD Rules

 Connector groups for BRM and security roles

 The same system can exist in more than one connector group

 For instance with SOD Rules

 Connector group for ECC Rules – will include those systems that use the same ECC Rules,
Finance, Orders-to-Cash, Procure-to-Pay, etc.
 Connector group for HR Rules – includes all systems that use HR application
 Connector group for IT (basis and security) Rules – since all the above systems have IT access
these rules should be applied to all these systems

27
Design of Connector Groups

• A detailed analysis of how your company will be using connectors in Access Control
should happen early on in your design phase
 SAP-delivered connector groups are for the SOD Rules they deliver

 Analyze how you will be using the connectors before you just accept these delivered
connector groups
 Pay attention to the naming convention of these connector groups, including the
descriptions

• But it is never too late to re-design the way connector groups are used
 If you are running into problems with connector groups when you go to implement new
Access Control functionality, consider adding new connector groups for the new
functionality instead of trying to make it fit into your existing connector groups

28
What We’ll Cover

• General Configuration Settings

• Configuration for SOD Rules
• Configuration for MSMP Workflows
• Wrap-Up

29
Should We Use Multiple Rulesets?

• First question to always ask if what would we be doing with our rulesets
• Just because you can have more than one does not mean you should or you shouldn’t

• Many companies have two different lists of Risks that they monitor in different ways
 Those risks that must be monitored and mitigated

 Other risks are less sensitive and can be ignored during monthly SOD analysis or
Access Request approval
 For instance:

 Critical and High risk must be addressed before access is given, they are monitored

and mitigated
 Medium and Lows can be ignored during access request but will be addressed

periodically (annually)
30
Multiple Rulesets?

• Since there are two different purposes and these risks are handled two different ways,
they should be in two different rulesets
 Critical and High ruleset should be used during Access Request and they must be
mitigated
 Medium and Low ruleset will be used to run quarterly SOD reports for their business
owners to give acknowledgment approvals

• Dashboards
 Since the Dashboards will be used to view the overall SOD analysis, the decision to
include both rulesets in the graphs or only the Critical and High SOD violations
 Batch Risk Analysis jobs can be run by ruleset

31
Ruleset Augmentation Projects

• When performing a Ruleset augmentation

 New rules can be created and kept in another ruleset so that implementation of these
new SOD rules do not cause large amounts of “new/unknown” violations
 Put the new rules in the new ruleset

 As the rules are analyzed and users remediated, move them to the existing ruleset

 You can choose when these new rules are moved to the Access Request simulations

and the dashboards

32
Maintaining Multiple Rulesets

• All Risks are maintained in the same Access Control system regardless of the ruleset
 In Business Client, when maintaining Risks
there is a tab for Rulesets
 Maintain a Risk in one or more rulesets
is simply to list which ruleset the risk
belongs to
 All other Risk and Function maintenance
will be the same

33
Activate BC Sets for Rules

• Activate the BC Sets for the SOD Rules to get the delivered SAP Rules
• With the delivered SAP Rules are the delivered connector groups
• If you are creating your own connector groups, moving the SAP-delivered rules to your
connector groups is simple
 Activate BC Sets for Rules

 Download the SOD Rules

 Upload them back into the Connector Groups that you would like to use

Remember you can always re-activate the BC Sets to get the delivered SAP
Rules back. If you are performing this on your existing system, make sure you
take extra backups and an extra download of the SOD rules so they could be
loaded back in.

34
Where Should Rulesets Be Maintained?

• SOD Rules should be maintained in development and transport through to production

 This will ensure proper testing, approval, and data integrity are maintained

 Users should be locked out of rule maintenance by security authorizations

• Access Control offers Risk and Function approval workflows

 These workflows should be used in the development environment

 The risk and function approvers will log into the GRC development system to approve
or reject the rule change request

35
Risk and Function Change Workflows

• Risk and Function approval workflows are configured in MSMP and turned via the Access
Control configuration settings
 When a change to the Risk or Function occurs, the Business Client screen will show a
button for “Submit” instead of “Save”
 The change is recorded and preserved in draft form

 The workflow (with email) is sent to the Risk and/or Function approver

 MSMP Workflow request is in the same Business Client Work Inbox and other GRC requests
 The approver can log in and approve or reject the change
 When they approve, the change is applied to the Risk or Function and the rule is
generated
 Once the rules are generated, they will need to be tested and transported through to
production

36
New (Additional) Access Risk Levels

• SAP delivered four access risk levels

 Critical, High, Medium, Low

• Now you have the ability to create

your own risk levels

• Example: Critical Action Risk Level

37
What We’ll Cover

• General Configuration Settings

• Configuration for SOD Rules
• Configuration for MSMP Workflows
• Wrap-Up

38
Best Practice for Access Request Workflows

• Access Request should be approved by a minimum of two people

 One person who knows the user (such as manager)

 One person who knows the role being requested (such as role approver)

• For larger companies, role approvers just don’t know everyone in the company to know
or understand who needs the access in the roles they own
 By having the manager, the manager can approve that user needs access and the role
approver can take that into account when approving access

39
How Many Workflow Paths?

• There is no magic number

• SAP delivers one workflow path for each Process ID

• MSMP workflows are very flexible

• With MSMP workflow configuration, BRFplus rules, there is an opportunity for any
number of workflows
• Analyze the different ways the path, stages, agents, BRFplus rules can be combined to
deliver your required functionality

• Determine what your process should be

 Don’t over-complicate your design

 But don’t limit your design either

40
Security Part of the Access Request Workflow?

• Does security still need to be part of the access request workflow?

• Access Request Management has given you all the tools to put the approval steps into
the hands of the business
 Security can become a bottleneck if they need to review and approve every request

 Now there are several requirements where Security needs to get involved in the
request process but with the use of BRFplus Initiators and Routing Rules, only send
those requests to security that require security’s attention

41
Access Request Initiator

• What’s the best way to build the Access Request workflow initiator?

• Access Control delivers the ability to analyze each request by request or by line to
determine how those items on the request should be processed
 You could send the entire request down the same path

 Or you could analyze each request row and determine which path each should
go down

• Now this can get very complicated but it is very flexible

42
Access Requestor Initiator vs. Routing Rules

• Both the Initiator and Routing Rules are built basically the same way in BRFplus
• Difference between an Initiator or Routing Rules is when in the workflow is it called

• Initiator – is triggered when the request is submitted

 The initiator will analyze the request and determine what path the request and/or
request line items should go down

• Routing Rule – is triggered at the end of a stage to determine if that request should go to
another path or stay on the existing path
 SOD Detour is a Routing Rule

 A routing rule could be created for specific roles if they need more approvals after
following the “normal” approval stages
43
SOD Detour

• Do we need an SOD detour?

• Well that depends on how you will address SOD violations

 Who assigns mitigation controls?

 Do mitigation control assignments need to be reviewed, therefore go to another

approver, before they are assigned?

• There is no reason to have an SOD Detour on your workflow unless you need the SOD
violations on the request to go to another approver after they are addressed

44
Who Assigns Mitigation Controls?

• Who should be assigning the mitigation controls?

 Managers, business owners, mitigation owners, or security

• Best Practice suggests the Mitigation Assignment approver is the one who understands
the risk, understands the control, and agrees that this user should have this risk and its
mitigation

• At some companies that is the role approver

 If it is the role approver and the role approver is a stage in the workflow, an SOD detour
may not be needed
• At other companies, the compliance team needs to review the control assignment
 In this case an SOD detour would be required

 Next question would be do they want to see all roles or only those in SOD violation

45
Access Request Workflows for Production vs. Non-Production?

• How do we perform SOD analysis during our workflow when it’s only required in
production?

• There are several differences between approval process for production and non-
production
 SOD Analysis is required in Production

 Often times Role Approvers for production are not the same approvers for non-prod

• Create different workflow paths, one for production and one for non-production
 Production path has a stage that requires SOD simulation

 Non-Production path does not require SOD simulation and maybe a BRFplus rule will
be created to determine who will do the role approving
46
What We’ll Cover

• General Configuration Settings

• Configuration for SOD Rules
• Configuration for MSMP Workflows
• Wrap-Up

47
Where to Find More Information

• SAP Service Marketplace

 https://service.sap.com *
 SAP Release Guides  Access Control Configuration Settings
 Most recent release: AC10_1_Config_Settings_SP11

 SAP Support Portal  Search for SAP Notes

 SAP Note 1624069 – GRC 10.0 Enabling Debug Logging for MSMP (Document:

EnableDebugLoggingforMSMP.pdf)
• SAP Community Network (SCN)
 https://scn.sap.com

* Requires login credentials to the SAP Service Marketplace

48
7 Key Points to Take Home

• Review Configuration Parameters during initial configuration and the implementation of

support packs, new parameters are being introduced all the time
• New Configuration Parameters are applied in Support Packs. Implementing a support
pack could offer a change to the way your release has been working.
• Make sure your configuration is locked down appropriately. If not by client configuration
settings, then by security authorizations.
• SOD Rules should be maintained in development and transported through to production,
even when using the Risk and Function workflows
• Configure the SOD Rules into what your company needs
• Remember Access Control workflow configuration is very flexible. There are so many
options in configuration, there is no reason to limit your design scope.
• Do not over-complicate your configuration. Design and implement what is required.
49
Your Turn!

Please remember to complete your session evaluation

50
Disclaimer
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by SAP SE.

51
Wellesley Information Services, 20 Carematrix Drive, Dedham, MA 02026
Copyright © 2015 Wellesley Information Services. All rights reserved.