answers to your top 10 sap access control 10.x design and...
TRANSCRIPT
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
• General Configuration Settings
• Configuration for SOD Rules
• Configuration for MSMP Workflows
• 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
• General Configuration Settings
• Configuration for SOD Rules
• Configuration for MSMP Workflows
• 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
• General Configuration Settings
• Configuration for SOD Rules
• Configuration for MSMP Workflows
• 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
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
Wellesley Information Services, 20 Carematrix Drive, Dedham, MA 02026 Copyright © 2015 Wellesley Information Services. All rights reserved.