Best Practices to Design and Implement Your GRC …wpc.0b0c.edgecastcdn.net/000B0C/sap_insider/Downloads/...• NWBC User Views Dictated by ABAP-based roles in GRC Back End Controlled

© Copyright 2013Wellesley Information Services, Inc.

All rights reserved.

Best Practices to Design and Implement Your GRC Security Roles Across Three Layers of Your System Landscape

Pawel KozinskiProtiviti

1

In This Session …

• You will learn: How to efficiently and effectively design and build SAP Security

roles in the GRC solution The importance of testing your roles and how to properly

perform testing How to trouble shoot in both the ABAP and NWBC layers of the

GRC solution

2

What We’ll Cover …

• GRC role build and design overview• Designing different types of GRC roles• Testing your roles• Common errors in the NWBC layer• Wrap-up

3

SAP Security Role Principles

• Common terms User Master Record: These enable the user to log onto the SAP

System and allow access to the functions and objects in it within the limits of the authorization profiles specified in the role. The user master record contains all information about the corresponding user, including the authorizations. Changes only take effect when the user next logs on to the system. Users who are logged on when the change takes place are not affected in their current session.

Single Role: Is created with the profile generator and allows the automatic generation of an authorization profile. The role contains the authorization data and the logon menu for the user.

Source: http://help.sap.com/saphelp_nw04/helpdata/en/52/671285439b11d1896f0000e8322d00/frameset.htm

4

SAP Security Role Principles (cont.)

• Common terms (cont.) Authorization: A combination of permissible values in each

authorization field of an authorization object. Enables you to perform a particular activity in the SAP

System, based on a set of authorization object field values. Allow you to specify any number of single values or value

ranges for a field of an authorization object. You can also allow all values, or allow an empty field as a permissible value.


5

SAP Security Role Principle (cont.)

• Common terms (cont.) Authorization Object: Where permitted activity configurations

are checked against specific authorization fields. An authorization object allows complex tests of an

authorization for multiple conditions. Authorizations allow users to execute actions within the system. For an authorization check to be successful, all field values of the authorization object must be appropriately maintained in the user master.


6

SAP Authorization Concept

• The authorizations represent instances of generic authorization objects, and are defined by the activity and responsibilities of the employee.

• Authorizations are combined in an authorization profile, associated with a role.

• The user administrators then assign the corresponding roles using the user master record, so the user can use the appropriate transactions for his or her tasks.

7

SAP Authorization Concept Illustrated

Role Name

Object Class

Authorization Object

8

GRC Authorization Overview

• User’s access in GRC Access Control similar to SAP ECC, determined by: Roles Authorization Objects in the ABAP layer determine front-end

access Authorizations are granted to users based on the

authorizations of specific roles and the authorizations object assigned to those roles

Use PFCG to maintain

9

Roles and Authorization Objects and iViews

• Authorization Objects GRC utilizes a different set of authorization objects not present

in other SAP Systems GRAC_XXXX GRFN_XXXX

• iViews Controlled by authorization object CA_POWL Personal Object Work List

10

Example of Notable Authorization Objects

Object DescriptionGRAC_ALERT The GRAC_ALERT object

allows you to generate, clean up, and create alerts

GRAC_ASIGN Allows you to assign owner types to firefighter IDS

GRAC_MITC Allows you to maintain mitigating controls

GRAC_OWNER Allows you to maintain owners in Access Control

11

Example of Notable Authorization Objects (cont.)

Object DescriptionGRFN_ADMIN Admin User

GRFN_MSMP MSMP Workflow Authorizations

GRFN_USER Authorization Object for GRC Users

GRAC_OWNER Allows you to maintain owners in Access Control

12

GRC Roles

• Out-of-the-Box Roles Commonly used This approach is not used in any other SAP solution Tailor roles to the business Out-of-the-Box roles provide too much/too little access

13

Out-of-the-Box GRC Roles Example

Feature Role Name DescriptionAll AC SAP_GRAC_BASE Gives basic authorizations

required for all AC users. You must assign this role to all AC users.

All AC SAP_GRAC_REPOR Ability to run all AC reports and have the display access for all drilldowns.

All AC SAP_GRAC_NWBC Gives the authorizations to launch NWBC. You must assign this role to all AC users.

All AC SAP_GRAC_SETUP Gives authorizations to set up and customize AC.

14

Out-of-the-Box GRC Roles Example (cont.)Feature Role Name DescriptionAccess Risk Analysis SAP_GRAC_RULE_SETUP This role has the

authorization to define access rules

Access risk analysis SAP_GRAC_RISK_ANALYSIS This role has the authorization to perform access risk analysis

Access risk analysis SAP_GRAC_ALERTS This role has the authorization to generate, clear and delete access risk alerts

Access risk analysis SAP_GRAC_CONTROL_OWNER This role has the authorization to create mitigating controls.

15

Out-of-the-Box GRC Roles Example (cont.)

Feature Role Name DescriptionSuperuser Management SAP_GRAC_SUPER_USER

_MGMT_ADMINSuperuser management administrator

Superuser Management SAP_GRAC_SUPER_USER_MGMT_OWNER

Superuser management owner

Superuser Management SAP_GRAC_SUPER_USER_MGMT_CNTLR

Superuser management controller

Superuser Management SAP_GRAC_SUPER_USER_MGMT_USER

Superuser management firefighter

16

System Development Lifecycle

Process Optimization & Solution Design

Realization Testing Knowledge Transfer Go-LiveBlueprint

Focus of this presentation will be on Blueprint and Testing

17



18

Role Design Basics

• Treat GRC like any other system Common mistake is to use default functionality Out-of-the-Box roles Default workflows

• Why is GRC different than any other system? User provisioning in other systems Reporting in other systems

19

Role Design Basics (cont.)

• Design Documents Review design documents to establish initial role design Role owner responsibilities Approval for user-level SoD violations

• Meet with GRC Team To obtain input and sign-off Start build

• Follow same process as other systems

20

Design of GRC Access Control Roles

• Normal SAP Authorization Concept Normal Role Design PFCG SU01

• Different Authorization Objects Object Class GRAC GRC

21

PFCG View

GRC Authorization Classes

22

Access Control and NWBC

• NWBC User Views Dictated by ABAP-based roles in GRC Back End Controlled by Authorization Object CA_POWL (authorizations for Personal Object Work List

[POWL] iViews)

23

PFCG iView

Authorization object that controls NWBC views

24

iView Options

Allows for complete customization for user NWBC views

25

NWBC

26

Design of GRC Process Control and Risk Management Roles• Entity-Level Authorization Application entities are structured in hierarchy providing top-

down authorizations Roles and entities at a higher entity level have greater

authorizations to perform tasks and great access to the application than roles at a lower entity level

27

Entity-Level Authorization

Corporate

Organization

Process Activity

Sub process Not Applicable

Control Risk

Process Control

RiskManagement

28

Maintaining Authorizations: Risk Management

• Define roles E.g., Risk owner

• Define role to GRC entity mapping Risk management only allows role assignment to organizations,

activities and risks• Users Assign users to the entity-assigned roles

• Maintain Agent Determination rules Necessary for workflow or notifications

29

Design of GRC Risk Management Roles Illustrated

30

Maintaining Authorizations: Process Control

1. Create PFCG Roles Decide if you are developing roles or using Out of the Box

2. Maintain first- and second-level authorizations3. Assign relevant PFCG roles to Process Control entities Map PFCG roles to specific Process Control entities

4. Define Regulations You can create your own regulations or use the sample

regulations provided

31

Maintaining Authorizations: Process Control (cont.)5. Assign PFCG roles to Process Control regulation entities using

the Customizing activity Maintain the Entity ID, Role, and assignments as needed

6. Configure the agent of a workflow task in the customizing activity7. Maintain the portal configuration Delivered portal roles vs. developed portal roles

8. Assign users to PFCG roles

32

Maintaining Authorizations: Process Control Illustrated

33

First- and Second-Level Authorizations

• First-Level Authorizations The pool of users assigned to the Business User role is the set

of users available for ANY entity-user-role assignment• Second-Level Authorizations The pool of users for a given entity-user-role assignment is

restricted to only those users who have that specific application role assigned to their user profile This allows the pool of users to be segmented into different

entity role groups

34

Differences in PC and RM Roles

• Entity Mapping Risk management only allows role assignment to organizations,

activities, and risks• First- and Second-Level Authorizations• Portal• Workflows

35



36

Testing Cycle

Project Prep Blueprint Realization Final Prep Go-Live

Testing Cycles

37

Testing Overview

• Testing can decide how successful a project will be• Testing timeline Testing timeline typically gets reduced as testing starts later

than planned Project Delays

Testing fits time rather than desired risk profile Testing suffers to meet Go-Live Date

Manual Process that takes time

38

Testing Concerns

• Lack of comprehensive testing is a big concern for many companies Effectiveness What needs to be tested? How much is enough for a successful test phase?

Risk No assurance on testing all elements

Efficiency The user base required to perform successful testing has to

have special skills

39

Testing Recommendations

• Review testing model to identify, reduce, and understand gaps Blueprint document should include test scripts and

approach/effort of scripts to be built• Prioritize scenarios and scripts in test model Critical, medium, and low priority functionality

• Involve business users early and often Users should be involved before User Acceptance Testing

40

Testing Steps

Create Test IDs

Test Complete Process

Resolve Authorization

Errors

41

Test IDs

• Model User Approach Create test IDs to resemble actual users in your system before

UAT Allows testing of actual scenarios

Benefits Testing real user access Comprehensive

Disadvantages More time intensive approach

42

Side-by-Side Comparison

43

Authorization Errors

• Communication Very important to communicate to users exactly what you

expect to receive from them Timeline for solution

• Documentation Needs to be thorough and informative Standard template to be provided to users

44

Documentation

• Scripts Need to be comprehensive and cover the entire scope of the

system Should cover every possible scenario Should cover all configuration work Workflows

Include expected results Provides requirements for a successful test

45



46

Error Example #1

47

Error #1 Explanation

• Error Message Typically a Web Dynpro error Role menus not properly created

• Out-of-the-Box Roles Make sure user has access to proper roles SAP_GRC_NWBC SAP_GRAC_NWBC

48

Improper Role Menu

49

Proper Role Menu

50

User Error Illustrated

Use NWBC Cockpit

Many users click a role link that describes their function

51

Error Example #2

52

Error Example #2 Explanation

• User has access to NWBC but can not see any reports User does not have the proper permissions in authorization

object CA_POWL iViews

53

Wrong iViews

CA_POWL object provides view authorization

54

Wrong iViews (cont.)

Proper iViews maintained in CA_POWL

55

SAP_ALL

• SAP_ALL Does not have GRC authorization objects GRAC Object Class GRC Object Class

• Roles SAP_GRAC_ALL Super user access for Access Control

56

SAP_GRAC_ALL

57

Remaining Stages in System Development Lifecycle

Process Optimization & Solution Design

Realization Testing Knowledge Transfer Go-LiveBlueprint

58



59

Where to Find More Information

• Governance, Risk, and Compliance How-To Guides GRC Regional Implementation Group, “How-to Configure SAP

BusinessObjects Access Control 5.3 for SAP NetWeaver® Portal 7.0” (SAP BusinessObjects, 2009). www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/502

a14db-6261-2c10-22b5-95117ab0e5ed?QuickLink=index&overridelayout=true&45891726115475

• http://service.sap.com/instguides SAP BusinessObjects GRC Security Guide Master Guide SAP Access Control 10.0

• Best Practices and Testing Strategies for Your SAP Projects www.sap.com/community/showdetail.epx?ItemID=10072

60

7 Key Points to Take Home

• GRC roles are treated differently than roles in any other system• Out-of-the-box roles provide too much/too little authorization• GRC Access Control roles are designed using normal ABAP

principles• GRC Risk Management roles are designed using Entity-Level

authorizations• GRC Process Control roles are designed using both PFCG and

Entity-Level Authorizations• NWBC authorizations are controlled by iViews in the back end of

the system• The testing phase of a project needs to be given the appropriate

amount of time to allow it to be successful

61

Your Turn!

How to contact me:Pawel Kozinski

[email protected]

Please remember to complete your session evaluation

62

Disclaimer

SAP, R/3, mySAP, mySAP.com, SAP NetWeaver®, Duet®, PartnerEdge, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by SAP.

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