SAP Security

Role Build Strategy

05/16/2020
What is T. Marzetti Security Policy?

All access is based on

LEAST PRIVLEDGE
ACCESS
2
Achieving Least Privilege in SAP
• Using Task Based Single Roles
• Grouped by Three Tier Designed Business Roles

3
 SAP Authorization
Job Based:
Concept
Task Based vs. Job Based Security
Design Task Based:
• Security is built based on small,
• Security is built based on
definable tasks, executed by the
positions/jobs within the
user, such as process cash
organization, such as A/R credit
receipts
associate
• Larger number of roles per user
• Provisioning access is based on
– decreased risk of duplicate
job responsibilities
access
• Smaller number of roles per • Transactions in one role with
user – increased risk for
minimal exceptions
granting functionality more than
once • User assignment flexibility –
simple to grant additional
• Transactions and authorizations
access to only the tasks
typically duplicated in many
necessary
roles
• Supports future growth and
• Users may be granted more
sustainability – role modification
access than necessary as a
decreased as a result of
result of “additional job” or
functionality improvements and
backup responsibilities
rollouts
• Appropriate for static • Appropriate for dynamic 4
organizations
organizations
 SAP Authorization
Concept
Task Based Security Design

A task-based design begins by bucketing transactions into one of 3 access

tiers: General, Display and Functional. Task-based roles contain access to
only one of these tiers.

Tier 1: General Access

User Profile General access is provisioned via one role
made up of tasks common to users such as
printing, inbox, SU53, etc.

General User Tier 2: Display Access

Display access is provisioned via a set of
roles defined by functional area that allow
display and reporting across intended to
compliment the functional roles of the users.
AP Common FI Common
Display Display Tier 3: Functional Access
Functional access is provisioned via a
multiple single task-based roles. Role
grouping of activities that are the lowest
Contract Vendor Master common denominator of tasks and
Process Billing
Maintenance Maintenance permission components to suit the needs of
the end users. These groupings are SoD free
and part of a sub process such as Invoice
Processing or Material Master Maintenance.
5
 SAP Authorization
Concept
Task Based Security Design
(continued)

• Security roles are built based on positions/jobs for a group of users (e.g.
Accounts Payable Clerk)
• User assigned the tasks needed to perform his/her job (not a job-based
role)
• User receives multiple single roles
• Flexibility to each individual user’s role assignments

AP Clerk

AP Common
General User Process Billing
Display
6
 Role Build Timeline
Position Explanation
Initial Mapping of Transactions to Persona/Business Roles January
Process Teams Group Transactions by Activity to Determine Task Roles February
Build Task Role Shells with Transactions for Unit Testing March
Additional Requirement Gathering April
Maintain Task Role Authorization Objects May
Confirm Task Role Mapping to Persona/Business Role May
Review Business Requirements to Determine Derived Roles May
Build Derived Roles July and August

7
 Master Role Build
Definition of Done

As a Security Administrator, I know master role build is

complete, when the role can be assigned to a test ID that
represents a business role in a test environment
with configuration and data, so that as a project team
member I can perform functional unit testing.

8
 Security Role Naming
Convention
Business Owners must be able to understand the
access granted to a person when a role is assigned
to their profile.

For example, a role described as giving access to

maintain sales orders, should do exactly that: give
users access to create, change and display sales
orders.

9
 Security Role Naming
Convention
Technical Name

Position Explanation
1–3 Z + System ID
4 Underscore (_)
5 Role Type Indicator (A = All or V = View)
6 Underscore (_)
7 Access Type Indicator
8 Underscore
9 - 12 Module/Sub-Module Indicator
13 Underscore
14 - 25 Business Process Indicator
26 Underscore
27 - 30 Derivation Indicator

Example: AP Invoice Cancel/Release master role = ZS4_M_A_FIAP_APINVREL_MSTR

10
Security Role Naming
Convention
Technical Name (Continued)
Code System/Application
S4 S4HANA
SM Solution Manager
TP Trade Promotions
BW Business Warehouse
Code Role Type
M Master
D Derived
S Single
C Composite
Code Access Type
A ALL
V View

11
Security Role Naming
Convention
Technical Name (Continued)
Code Module/Sub-Module
FIAP Finance Accounts Payable
TECH Technical
SYST System
Code Business Process
APINVREL Invoice Cancel/Release
PRDBASIS Production Basis
DEVSECURITY Non-Production Security
SYSMDM System Master Data (BODS)
Code Access Type
MSTR Null Value (‘ ‘)
ALL Full Org Value Access (*)
3000 Restricted to single Org Value (Plant 3000)
‘ ‘ Single roles are not restricted by organization

12
 Security Role Naming
Convention
Description or Long Name

The long description should explain the technical name of a security role

Example: AP Invoice Cancel/Release Master Role

ZS4_M_A_FIAP_APINVREL_MSTR

S/4 - Finance AP - AP Invoice Cancel/Release - Master

13
 Security Role Design

CPG Path Map to Group

Roles as Marzetti Transactions
Base Line Persona by Tasks

• Transactions to CPG Path Standard Roles by Business Process used as a baseline

• Process Teams mapped CPG Path roles to Marzetti Persona and asked to identify out of
scope transactions
• Process Teams grouped transactions by activity to help define Task Roles by Business
Process

Marzetti Persona = Business Role and Task Grouping = Single Task Role

14
Security Role Design
Sample Mapping File

15
 Creating Master Roles

Implementing Security Best Practices:

• Include Date, User ID Defect Reference on Description Tab for role
modifications
• Adding Fiori Catalogs and SAP Standard Transactions in Alphabetical
Order to Menu Tab
16
 Creating Master Roles
Maintaining Authorizations –
Organizational Levels

Company
Code

Purchasing
Group

Plant

Organizational Levels are centrally managed in security roles:

• Master roles use null (‘ ‘) values for organizational values, which will be
maintained in derived roles
17
 Creating Master Roles
Maintaining Authorizations – Updating
Field Values

SAP
Standard

Deactivated

Authorization Object Field Values are maintained Individually:

• SAP Standard values are reviewed and used unless restrictions are
required by the business
• Sensitive or critical objects are deactivated or left open to force a
defect until adequate information is available to maintain the values
18
 Derived Role Build
Definition of Done

As a Security Administrator, I know derived role build is

complete, when the role can be assigned to a test ID that
represents a business role in a test environment
with configuration and data, so that as a project team
member I can perform positive/negative functional unit
testing by specific organizational values.

19
 Creating Derived Roles

• Every role has a global role with all org values (ALL)
• Additional derived role(s) created based on the most appropriate value
representing each operation location
• Third Party functionality is mostly centralized all access included in the
same role (3PL)

20
 Role Build Process
Gather requirement Gather Organization Build Derived Role
Restriction and based on Master Unit Test / SIT 2 &
(Persona / Role / Build Master roles Unit Test / SIT 1
Functional Role & Org beyond
Tcode) Restriction restriction

• Approval from ITSO • Authorization Values are • Persona Test IDs (Master role, • Workshops with Process team / • Org. values: company code, • Test with Personas/ functional
maintained in master role no func or org restriction) ITSO plant, sales organization etc. are & org restriction
(refined as we get defects/ • Requirements gathered in maintained in derived roles • Negative testing should be
requirements) templates (Functional included (TMZ)
• Functional restrictions like restriction) • No changes are made directly
Movement types, Doc Types are • Approval from ITSO to Derived roles
addressed at master role level
• Changes made to Master Roles • Link to Functional Requirement
get pushed down to Derived Tracker
roles
• Any updates/ deletion/
additions to Master role is
controlled with Bug card and Role ID Org. level Description Comments
ITSO approval ZS4_M_A_PROP_MATPUR_MSTR
ZS4_M_A_PROP_MATPUR_MSTR
ARBPL
BUKRS
Work Center
Company Code
• Link to Consolidated Tracker ZS4_M_A_PROP_MATPUR_MSTR EKGRP Purchasing Group
(Persona > Master Role > ZS4_M_A_PROP_MATPUR_MSTR EKORG Purchasing organization Yes each Purchase Org
ZS4_M_A_PROP_MATPUR_MSTR FIKRS #N/A
Tcode/ Fiori) ZS4_M_A_PROP_MATPUR_MSTR GSBER Business Area
ZS4_M_A_PROP_MATPUR_MSTR IWERK Maintenance Planning Plant
ZS4_M_A_PROP_MATPUR_MSTR KOKRS Controlling Area
ZS4_M_A_PROP_MATPUR_MSTR PRCTR Profit Center
Master Role ZS4_M_A_PROP_MATPUR_MSTR
ZS4_M_A_PROP_MATPUR_MSTR
SPART
VKORG
Division
Sales Organization
ZS4_M_A_PROP_MATPUR_MSTR VTWEG Distribution Channel
ZS4_M_A_PROP_MATPUR_MSTR WERKS Plant Yes all Plants @3000s
Purchase Org 1
ZS4_M_A_PROP_MATPUR_MSTR
Plant 3001
Purchase org 2

Plant 3002 Purchase Org 1

Purchase org 2
… …
Presentation Title | Author | Date © 2017 Capgemini. All rights reserved. 21
 Derived Roles
Business
Derived Role Approved? Build Status Primary restriction
Process Master Role
PTP ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3001 Not Started Plant
PTP ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3002 Not Started Plant
PTP ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3003 Not Started Plant
PTP ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3004 Not Started Plant
PTP ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3005 Not Started Plant
PTP ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3010 Not Started Plant
PTP ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3011 Not Started Plant
PTP ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3012 Not Started Plant
PTP ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3013 Not Started Plant
PTP ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3014 Not Started Plant
PTP ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3015 Not Started Plant
PTP ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3016 Not Started Plant
PTP ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3017 Not Started Plant
PTP ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3018 Not Started Plant

In some cases there will be only 1 derived role per master role. Eg: FTM – centralized , no restrictions by org
units/ company code

For master roles which do not need to be restricted by org unit, default derived role <Master Role>_ALL is
generated

Role Description will list primary restriction mentioning org unit (Plant 3001), naming convention <Master
Role>_<Org> (30 char limit Role name)
Presentation Title | Author | Date © 2017 Capgemini. All rights reserved. 22
 User Role mapping/ assignment
Identify Persona (OCM)

Identify Persona mapping to Master Roles (OCM)

User Role
Identify the derived role based on Organization unit/ site user belongs to (OCM)
assignment
Request roles for user (user id) (Security / GRC)

On approval, derived roles get assigned to user id (Role approvers / GRC)

Business Process
Marzetti Persona Master Role Name
PTP Contract Approver ZS4_M_A_PRCM_CNTAPPR_MSTR
PTP Corporate procurement ZS4_M_V_PRMD_CRPSPEC_MSTR
PTP Material Planners ZS4_M_A_MFMM_MROMATPLN_MSTR
PTP Material Planners ZS4_M_A_PROP_MATPUR_MSTR
PTP PO Approver ZS4_M_A_PROP_POAPPR_MSTR Master Role Derived Role
PTP PTP Display Role ZS4_M_V_PRPA_PROCDIS_MSTR ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3001
PTP PTP Master Data Specialist ZS4_M_V_PRMD_PREC_MSTR ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3002
PTP Requisition Approver ZS4_M_A_PROP_REQAPPR_MSTR
PTP Requisitioner ZS4_M_A_PROP_REQ_MSTR ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3003
PTP Scheduling Agreement Approver ZS4_M_A_PROP_SCHAGRAPPR_MSTR ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3004
ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3005
ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3010
ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3011
ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3012
ZS4_M_A_MFMM_MROMATPLN_MSTR ZS4_D_A_MFMM_MROMATPLN_3013

Presentation Title | Author | Date © 2017 Capgemini. All rights reserved. 23

 Org. Level Restriction by Process Area
Org. Level Restriction by Process Area
FTM No Restriction
• In Addition to the Restrictions mentioned,
PTP Plant & Purchase Org
Super derived role with ALL (*) org level
OTC Sales Org
access will be created i.e., there wouldn’t
DTS Plant Level
be any restriction on org level for super
MTS Plant / Maintenance Plant
derived roles.
QM Plant Level
LE Plant Level / Warehouse

Presentation Title | Author | Date © 2017 Capgemini. All rights reserved. 24

Creating Derived Roles
Derivation Matrix

25
 Security Testing

• Test IDs provided by Business Role in Sprints 7 and 8

for Functional Unit Testing
• Test IDs provided by Business Role at the Global Level
in SIT 1 for E2E Testing
• Test IDs provided by Business Role at the Derived Level
in SIT 2 for E2E Testing
• Defects must be reported through Jira

26
 Security Testing
Defect Resolution

• Security Defects Reported in Jira Including:

• User ID experiencing the defect
• Transaction or program executed when error occurred
• SU53/screen shot of error
• Steps to replicate error if applicable
• Test evidence provided during formal testing to
confirm resolution
• When in doubt, raise a defect

27
 Role Requirement
Documentation
• Initial Mapping to Persona (Business Role
Design) – SOW1 deliverable
• Approved Files and Approval Emails archived for:
• Transaction Groupings (Task Role Design)
• Additional Requirement Tracker (Changes to Task Role
Design)
• Functional/Organizational Requirements
• Changes to Business Role Design
• Modifications to Functional Restrictions will be
documented through Defect Resolution Process

28
 Security Role
Risk Analysis

• SAP Standard Ruleset used as baseline due to fit

to standard implementation
• Performing analysis of transactions in scope to
identify gaps from standard
• Risk analysis performed at permissions level, not
only transaction level
• Includes SoD conflicts and critical/sensitive
access reviews
• Security roles should not include SoD conflicts

29