answers to your top 10 sap access control 10.x design and...

Produced by Wellesley Information Services, LLC, publisher of SAPinsider. © 2016 Wellesley Information Services. All rights reserved.

Answers to Your Top 10 SAP Access Control 10.x Design and Configuration Questions

Ruth Johnson Customer Advisory Group

1

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

2

What We’ll Cover

• General Configuration Settings

• Configuration for SOD Rules

• Configuration for MSMP Workflows

• Wrap-Up

3

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

4

Maintain Configuration Settings

Transaction: SPRO – Customizing – Edit Project

Select: SAP Reference IMG

Menu Path:

Governance, Risk and Compliance Access

Control

5

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

6

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

7

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

8

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

9

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/

10

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

11

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

12

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

13

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

14

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.

15

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

16

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

17

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

• Two specific areas: SOD Rules

and MSMP Workflow

These type of activities can

be secured by authorizations

Policies and Procedures should be written

and enforced to keep your Access Control

application integrity

SCC4 – Client

Settings for

locking down

client for config

18

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

19

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

20

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

21

SOD Rules Authorizations

• Here are the authorizations that control SOD Rules

22

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

23

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

24

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

25

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

26

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

27

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

28

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

29

What We’ll Cover




• Wrap-Up

30

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)

31

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

32

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

33

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

34

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.

35

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

36

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

37

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

38

What We’ll Cover




• Wrap-Up

39

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

40

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

41

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

42

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

43

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

44

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

45

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

46

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

47

What We’ll Cover




• Wrap-Up

48

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

https://service.sap.com/

https://service.sap.com/

https://scn.sap.com/

https://scn.sap.com/

49

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.

50

Your Turn!

Please remember to complete your session evaluation

51

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.

Disclaimer

answers to your top 10 sap access control 10.x design and...

Documents