Designing SAP Security Design

8/12/2019 Designing SAP Security Design

1/27

Security Design

Page 1

SecurityDesign Document


2/27

Security Design

Page 2

Document Control

Author Diane Davis /Ramesh Babu/Barry Roberts/Bill Wade

File Name Security Design.doc

Version Revision Date Revision Description Author Sign-offV1 04/27/10 1

stDraft of All Sections SI 1 N/A

V2 11/28/10 Focus on XXX specificdecisions

Ramesh B Kommaddi

Target Readership

This document is intended for anyone who has responsibility for, or has a vested interest in SAPSecurity & GRC Administration at XXX. This includes:

Business Executives

Information Services management

Technical staff

Application development teams

User Administration teams

Help Desk teams

SAP Security Administrator

Internal Auditor and External Auditors

Training Team and Business owners


3/27

Security Design

Page 3

1. Introduction __________________________________________________________________1.1. Purpose............................................................................................................................... 4

2. Scope _______________________________________________________________________3. Security Practices _____________________________________________

3.1. Roles and Responsibilities............................................................................................... 53.2. Naming Convention .......................................................................................................... 53.3. General Security Approach.............................................................................................. 63.4. Security Testing ................................................................................................................. 73.5. User and Role Provisioning Processes.......................................................................... 73.6. Other table access ............................................................................................................ 8

4. Application Specific Considerations ______________________________________________4.1. SAP ECC ............................................................................................................................ 84.2. BW/BOB J ........................................................................................................................ 144.3. SAP GRC.......................................................................................................................... 154.4. SAP Solution Manager ................................................................................................... 174.5. Vertex ................................................................................................................................ 18

5. Terminology __________________________________________________________________6. Tables _______________________________________________________________________

6.1. Security RACI Chart........................................................................................................ 216.2. ECC Security Parameters .............................................................................................. 226.3. System Profile Parameters ............................................................................................ 236.4. SAP ECC Sensitive Authorization Objects.................................................................. 26


4/27

Security Design

Page 4

1. IntroductionThis document is to describe the overall SAP Security Design that will be adopted for XXX SAP systems.

This design supports the configured business processes within the XXX SAP system, whilst ensuring anadequate level of security and controls.

1.1. PurposeThe purpose of this document is to identify the high level design in order to

Define the build that will provide guidance for the build and run of SAP ECC security and GRC

Provide an overview of the approach for defining the various user roles in a typical SAPapplication environment.

Specify particular security configuration decisions for the solution

2. ScopeThis document refers to the Security concept within the solution for end users.Both the production and non-production environments are considered within the scope of the security andGRC teams.

The following systems components are considered in scope for this document:

SAP ECC

SAP BW & BOBJ

GRC modules implemented

SAP Solution Manager

The following systems components are not in scope for this document and will follow current XXXpractices for their categories, where applicable

Database and operating system security

All peripheral SAP components not specified above

All components associated with the operation of the IT infrastructure upon which the SAPsystems operate are out of scope of this document

Disaster recovery (DR) and business continuity planning (BCP) for SAP and related componentswill fall under the XXXs current IT policies and procedures

All components of systems subsidiary to and interfacing with the mySAP.com systems will bemaintained and secured following existing procedures, guidelines and standards.

Business Process Controls Strategy, risk assessment and controls recommendation shall be theresponsibility of the Process Teams and the InternalControl and Compliance team. See the Governance Risk and Compliance Strategy Document

For non-SAP application security requirements, please refer to the standards and guidelines definedwithin the policies and standard operating procedures as documented on the XXX intranet.


5/27

Security Design

Page 5

3. Security PracticesWhile specific applications will have unique security considerations, all of the

components are subject to similar practices to ensure consistency and compliance with the SecurityStrategy. The following areas will be common to all applications.

3.1. Roles and ResponsibilitiesSecurity and GRC Administration requires active involvement from XXX throughout the project. AResponsibility, Accountability, Consult and Inform Chart (RACI) lists the security specific roles andresponsibilities for the SAP implementation. See the Terminology area for adefinition of each role listed.

3.2. Naming Convention

3.2.1. Roles

Where possible, security roles will be kept to a minimum and XXX will first use the out ofthe box roles provided they sufficiently address access needs and risk managementconcerns. When custom roles are required a consistent naming convention should beobserved across all applications as much as possible. See the rolenaming convention document at:

https://thesource.XXX.com/sites/sharedservices//ImplementationTeam/Shared%20Documents/%20Program/Realization/ICC/Security/Role%20Naming%20Conventions.docx

3.2.2. Users

Dialog users are assigned an application specific account-user master record that may be

assigned one or many application roles. XXX Employees and Contractors user ids will bethe same as their XXX network ID (Active Directory (ADID). Application userids will modelthis same convention. Each XXX employee will have one and only application userid (ifneeded). No generic SAP userids will be created and no userids will be allowed to beshared.Exceptions will be made for testing role functionality and model users in a non-productionenvironment and for service/batch accounts in production. When service accounts arerequired to support batch processing and Tier 3 level support, a separate batch-id will beestablished for each process area. Jobs in production systems should not be scheduledusing the individual user ids. Each business area will have at least one batch-id to run thejobs related to that area. These accounts will comply with the XXX Information SecurityPolicy requirements.

User Groups
https://thesource.ihs.com/sites/sharedservices/vanguard/ImplementationTeam/Shared%20Documents/Vanguard%20Program/Realization/ICC/Security/Role%20Naming%20Conventions.docxhttps://thesource.ihs.com/sites/sharedservices/vanguard/ImplementationTeam/Shared%20Documents/Vanguard%20Program/Realization/ICC/Security/Role%20Naming%20Conventions.docxhttps://thesource.ihs.com/sites/sharedservices/vanguard/ImplementationTeam/Shared%20Documents/Vanguard%20Program/Realization/ICC/Security/Role%20Naming%20Conventions.docxhttps://thesource.ihs.com/sites/sharedservices/vanguard/ImplementationTeam/Shared%20Documents/Vanguard%20Program/Realization/ICC/Security/Role%20Naming%20Conventions.docxhttps://thesource.ihs.com/sites/sharedservices/vanguard/ImplementationTeam/Shared%20Documents/Vanguard%20Program/Realization/ICC/Security/Role%20Naming%20Conventions.docxhttps://thesource.ihs.com/sites/sharedservices/vanguard/ImplementationTeam/Shared%20Documents/Vanguard%20Program/Realization/ICC/Security/Role%20Naming%20Conventions.docxhttps://thesource.ihs.com/sites/sharedservices/vanguard/ImplementationTeam/Shared%20Documents/Vanguard%20Program/Realization/ICC/Security/Role%20Naming%20Conventions.docx


6/27

Security Design

Page 6

For the SAP solutions in , there are two types of User Groups toconsider, Administrative User Groups and Authorization User Groups.The Administrative user group is used to distribute the administration of user maintenance.User administrators can be authorized to maintain specific administrative user groups.

Administrative user groups do not provide the ability to grant transactional access to users.It just allows for ease of maintenance within security administration. There is no plan touse administrative user groups during the initial release. The following administrative usergroups are examples of what may be created and used to assign access for these groups:

DEVELOPMENT Application Developers (ABAP) team

BASIS Basis Support Team

CONFIGURE Configuration Development Team

HELPDESK1 Helpdesk Support Team

HELPDESK2 Helpdesk Support Team

SECURITY1 Security Design team

SECURITY2 Security Design team

TEST IDs

USER All end-users

DESKTOP IT Desktop Support Technical teamThe second type of user groups is the authorization user group which is used to assignroles to groups of people at one time. For use of ECC, there is no planto use this type of group during the initial releases. The preference is to assign to the enduser due to the need to be flexible with assignment of task based roles.

3.3. General Security ApproachThe security design and build is based on an approach with the goal of reducing risk of access tosensitive areas, content while complying with XXX IT Security Policies and Procedures. To align withthe internal control requirements and prevent potential deficiencies that can impact an organization,user functions will be segregated with respect to the users job descriptions and responsibilities. Ingeneral, transactions with a very high sensitivity (IT and Business Sensitive Transactions) will not be

combined with other transactions. Unique use of transactions per role is the preferred approach withduplication of transactions within other roles only when no other alternative is present. The roledefinition process will provide a high level of flexibility, visibility and control to appropriately managethe high-risk transactions and remediate users when necessary.

For each of the in-scope systems, transactions, queries, reports and web addresses, etc. will beincluded into the role menu. The XXX approach to security is to follow standardSDLC methodology that includes Design, Build, and Test. The approach took into account:

Transactions listed by process and role

Role Build Templates

Org level security is high maintenance for user provisioning and therefore has beendetermined within XXX that the benefits do not outweigh the costs.

XXX will use the Profile Generator as a tool to develop authorization profiles. Once activities

have been saved in a role, the profile generator is used to generate the necessaryauthorizations and profiles. If a Security Role contains more than 150 authorizations, theprofile generator will automatically create additional profiles.

Roles will be directly assigned to a user.


7/27

Security Design

Page 7

Training will identify the to be operational job function for job rolemapping. Security will collaborate to map task based roles to the specified function in timefor UAT

Observe best practices where possible:o Limited use of * wildcards for administering roles. Unless there is a thorough

understanding of the scope of transactions or field values a wildcard represents, theuse of wildcards can lead to the granting of unintentional access.

o Minimize use of child roles to avoid breakage of parentchild relationship.o Identify sensitive data and restrict access to transactions/reports capable of

accessing that data.o Group like functions together into single roles.o Follow principle of least privilegeo Ensure correct naming convention is used.o Add tcode (s) in alphabetical order to the folder in Role Menu.o XXX will use the default profile names which start with t, unless a custom profile

name has already been assigned to a role/o Do not maintain/update authorization field values that would result in Changed

objects (as opposed to standard or Maintained) without assessing the situation.o Do not manually insert authorization objects without assessing the situation/change

requirementso Role descriptions are to be kept current with the latest changeo Role Owner approval will be obtained before any role modification.

3.4. Security TestingA security testing strategy will be coordinated with the overall project testing strategy for theappropriate cycle and type of testing. Security testing will consist of:

Unit Testing

Integration Testing

User Acceptance Testing

During each phase, the Security Team will resolve appropriate authorization failures and make theappropriate changes and/or modifications to the levels associated with each Role per the testingfeedback. Considerations for job role mapping will be coordinated with the Testing and Trainingteams to ensure consistency in the testing objectives and efficient use of the resources deployed forall these areas simultaneously. Role owner approval of role definitions and role assignments will bea required output from the testing cycles. See theTesting Strategydocument for specific objectivesper testing cycle.

3.5. User and Role Provisioning ProcessesRole builds will follow controls defined in the GRC Role Build and Provisioning PDDs. will utilize the GRC RAR simulation functionality to prospectively identify potentialSOD risks before role or provisioning efforts are made for ECC. This is a new capability to XXX that

will increase role owner visibility and improve work efficiency. Security role builds will utilize thechange management controls specified in the GRC Change Management PDD. Security role buildsmust be transported using the transport process defined.
https://thesource.ihs.com/sites/sharedservices/vanguard/ImplementationTeam/Shared%20Documents/Vanguard%20Program/Realization/ICC/Security/Security%20Test%20Insert.docxhttps://thesource.ihs.com/sites/sharedservices/vanguard/ImplementationTeam/Shared%20Documents/Vanguard%20Program/Realization/ICC/Security/Security%20Test%20Insert.docxhttps://thesource.ihs.com/sites/sharedservices/vanguard/ImplementationTeam/Shared%20Documents/Vanguard%20Program/Realization/ICC/Security/Security%20Test%20Insert.docxhttps://thesource.ihs.com/sites/sharedservices/vanguard/ImplementationTeam/Shared%20Documents/Vanguard%20Program/Realization/ICC/Security/Security%20Test%20Insert.docx


8/27

Security Design

Page 8

3.6. Other table accessAccess to tables can occur at the database layer. As such, will implementalternative procedures consistent with legacy SOX systems to monitor highly privileged access at

the database and server layers. Associated security will follow principle of least privilege and will bereviewed in accordance with IT Global Policy. Access to databases requires approvals as stated inthe XXX IT Information Security Policy.

4. Application Specific Considerations4.1. SAP ECC

ECC is a transactional processing system and most of the action is based on the use of transactions.For ECC, the transactions that have been selected for a role are entered in the menu of the role andthe profile generator includes in the authorization data all of the authorization objects that arechecked for these transactions. The authorization objects that are brought in to the Profile Generatorare about 90-95 percent of what is needed to be considered complete.

4.1.1. Overview

In addition to the general approach for security, the ECC security design and build aims toreduce and potentially eliminate the existence of segregation of duties conflicts within theSAP technical design while adhering to

GRC Access Controls best practice

Observance of identified critical sensitive transaction codesECC will deploy a compliant security build. Authorization object level access control rulesbased on the data needed to be accessed will be incorporated around these transactions toprovide more granular protection. The ECC build consists of:

Transactions listed within the PDDs or BPPs

RICEF Object and sensitive transaction areas identified by best practice resources.

Creation of small task-based roles that are free of SOD violations

Utilization of the GRC RAR for SOD reviews prior to deployment for role and userreviews for SAP ECC security

Roles will be defined based on a task. Therefore, tasks are assigned to a roleowner having significant functional knowledge of what is required to perform thetask. See the detailed security role build.

Use SU24 Maintenance process. Avoid inserting objects manually.

Composite roles reduces visibility within roles, therefore limit their use

SOD tools interpret the use of * wildcards for administering roles or authorizationswidely which causes issues around SOD and excessive access.

Single roles containing similar functions/transactions can be more easily added orremoved from composite roles. Single roles containing dissimilarfunctions/transactions will typically require more analysis to determine whether atransaction can added or removed.

Limited use derived roles to represent similar job roles. Derived roles are derivedfrom parent roles. Changes to parent roles automatically transfer to derived roles,thus simplifying role maintenance.

Use of composite roles will be used where consistency in the combination of roleswarrants this structure for maintenance


9/27

Security Design

Page 9

Use of single roles instead of master roles because derived roles will not be usedfor org level.

All reports or programs for end users to run will be assigned to a transaction.

Only those people with active user master records can access the system. User ids, roles,profiles, transaction codes and authorization objects protect the system from unauthorizedaccess. Roles are created and maintained via transaction PFCG. Profiles can be createdmanually using transaction SU02 and automatically by using SAP Profile Generator. It willbe XXXs policy to rely on Profile Generator for creation of security profiles wheneverpossible as per our systems integrator leading practice design.

SAP transactions are secured through three methods:1. System access to execute the transaction2. Check object for activity to execute the transaction3. Authority checks within the supporting ABAP/4 program

All three of these must be taken into consideration when administering transaction levelsecurity.

4.1.2. Authorizations Objects

An authorization object is a template for testing access privileges. It groups up to 10 fieldsand tests for execution rights utilizing AND-logic in programs to see if a user has the right tocarry out an action. A user's action is approved only if the user passes the access test foreach field listed in an object. Authorization objects can be described as:

Entities defined by SAP which secure or protect transactions.

Consists of fields whose values determine the type of access granted for specifictransactions.

Fields identify an element of the system that is to be protected by an access test.SAP has pre-defined sets of authorization objects for each of the SAP modules.

Example: an authorization object for securing accounting documents identifies the type of document that canbe processed (invoice, customer payment, credit memo, etc.) and what type of processing can be performed

with the document (create, change, display, delete, etc.).

The authorization objects used to secure transactions are dependent on the functional areabeing executed. There are approximately 22 object classes used to logically group theSAP supplied authorization objects. Refer to the SAP supplied on-line documentation or anactual client for a detailed listing. The objects are maintained in the table TOBJ and can beviewed via transaction SE16.

The system access to execute the transaction is controlled by the authorization objectS_TCODE. This particular object requires that the transactions needed for a user, positionor role be explicitly defined. This means, that if a user needs access to transactions FB01,FB02, and FB03, then these transactions must be specifically stated. Alternatively, puttingin the value of FB* can provide the same access but is not recommended anywhere but in

the development environment

4.1.3. Authorization and Field Values

An authorization is a set of permissible values that grant system access privileges basedupon an authorization object. A user is permitted to perform an action only if he/she


10/27

Security Design

Page 10

passes the test for each field in an authorization object. In this way, objects allow complex,multi-conditional testing of user access privileges. Creating a unique name and assigningvalues to the fields that are defined for the object create an authorization for anauthorization object. Values determine the actions that are permissible. Authorizations

must be assigned to simple profiles.Example: A G/L account authorization object has two fields to which varying degrees of access can begranted, Activity and Company Code. An authorization could be created with a value of 03 (display)assigned to the Activity field and a value assigned to the Company Code field. This authorization would beassigned to a single profile along with the other authorizations required to access G/L accounts.

4.1.4. Authority Check in Custom ABAP

Much of the data in an ECC6 system has to be protected so that unauthorized users cannotaccess it. Therefore, the appropriate authorization is required before a user can carry outcertain actions in the system. When you log on to the ECC6 system, the system checks inthe user master record to see which transactions you are authorized to use. Anauthorization check is implemented for every transaction. In addition to transaction code,the ECC authorization concept includes other authorization objects to secure activities(create, display, delete, modify, etc.), to restrict access to specific parts of the organizations

data (Company Code, Plant, etc.) All custom programs, SAP scripts, and interface routinesare required to use appropriate authority checks. Prior to the configuration and securitybeing transported to the QA system, the Security Team and Functional Team will verify thatthe authority checks are in place and functioning adequately.

ECC performs authority checks to ensure execution of the code with securityconsiderations. During the creation process XXX will perform the following when creatingnew authority checks:

1. Evaluate the need to create new authorization objects or use existing objects2. If necessary, create the new authorization objects and associate them with an

existing object class. All new objects must be transported across the entire systemclient landscape

3. Identify the values necessary to execute the program

4. Identify the position or role that should have access to execute this program, thismay be dependent on each client

5. If necessary, add the transaction code to the SAP ECC Profile Generator usingSU24

6. If using the profile generator, generate the new activity group necessary to executethe program

7. If necessary, create the manual authorizations and profiles necessary to executethe program

8. Transport the profile and/or activity group across the system client landscape

4.1.5. Activation Concept

Profiles and authorizations exist in maintenance and active versions in the system. Whencreating or editing a profile or authorization, the maintenance version is being used. This

concept helps prevent errors in defining or editing authorizations from affecting the system.Changes to profiles and authorizations have to be activated or generated before they goin to affect

4.1.6. System Security Parameters


11/27

Security Design

Page 11

The SAP Security Administrator must periodically check the SAP ECC system parameterson each instance. This can be accomplished by using transaction SE38 to execute theABAP/4 program RSPARAM on each system. In particular, the SAP Security Administratormust verify that the following system parameters are set appropriately. SAP has specific

default parameters in the system that can be tailored for each instance. You can use thesesystem profile parameters to set password characteristics, incorrect logon limits, and thedefault client. The following parameters are presented for later review. Additional detailsand recommendation can be found in SAP ECC Security Parameters Table.Note: Parameters apply to both the ECC6 and BW systems.

4.1.7. Custom Transactions

There are two minimum requirements for all new custom transactions:

S_TCODE must be activated

All new transaction must have a check object assigned to them (Table TSTCA)Creation of custom transactions will follow the process defined in the GRC Role CreationPDD. The following are the necessary steps to establish a check object for a newtransaction

1. Review the existing authorization objects to determine the ability to use an SAPsupplied object

2. If necessary, create the new authorization object3. Execute transaction SE934. Enter the new transaction code and click on the Maintain icon 5. Enter the authorization object selected to be the check object6. Enter the field level values required

Note, this information can be manually entered into the table TSTCA via transaction SE16.

4.1.8. Sensitive Transactions

There are specific transactions contained within SAP that are considered sensitive andpowerful in nature. The misuse of these transactions within the system could negativelyaffect the performance and integrity of the system by providing users with powerful rights.It is important to understand the risks associated with sensitive transactions. The securityteam will make sure those transactions are accounted for in the SAP GRC RAR rule set.GRC Process Controls will be used for the IT Basis critical areas for Release 1.

4.1.9. Sensitive IDs & Profiles

In addition to monitoring sensitive transactions, SAP has a several powerful userids andprofiles that should be monitored closely for appropriate use. Powerful ids will not begranted to individuals in production. In the rare circumstance where it is required, GRCSPM controls will be used to allow for a mitigating control of the activity performed. In non-production environments, these IDs will be highly restricted to technical personnel only andassigned only as needed for the limited time needed to perform mandatory functions notable to be performed under the properly provisioned ID. Segregation of duties andobservance of highly confidential information must be taken into consideration in allenvironments. The following is a list of SAP ID and profiles should be restricted:

Type Detail


12/27

Security Design

Page 12

Profile SAP_ALL

SAP_NEW

S_A.SYSTEM

S_A.ADMINS_A.USER

S_A.CPIC

S_A.CUSTOMIZ

S_A.TMSADM

S_A.TMSCFG

S_A.TMSWF

ID SAPCPIC

SAP*

DDIC

EARLYWATCH

4.1.10. Restricted Authorization Objects

In addition to powerful IDs and profiles with SAP, there are some authorization objects thatshould be closely monitored. These authorization objects are considered sensitive innature. The misuse of these authorization objects within the system could negatively affectthe performance and integrity of the system. Some transaction codes do requireauthorization to some of these objects. However, careful consideration should be takenwherever access is granted. See SAP ECC Sensitive Authorization Objects Table.

4.1.11. Program Security

Programs in SAP are written in a standard fourth generation called ABAP/4; this languagewas created by SAP and is the foundation for all functionality in SAP. Access to create,maintain and execute ABAP/4 programs will be restricted to those individuals properlytrained. Use of ABAP/4 will follow SAP development standards. Access to ABAP/4programs will be granted based on three elements:

1. Type of access being requested (display, maintain, execute)2. Client where requested3. User making the request

Custom programs will be assigned to custom T-codes which will follow the GRC Role PDDrequiring these to be incorporated into an ECC role. XXX will not utilize additionalmaintenance/assignments at the object or authorization group levels.

4.1.12. Table Security

The ability to perform configuration or view raw SAP data requires access to specific

tables within SAP. The ability to maintain table level data affects the integrity andaccuracy of information maintained by SAP. Changes to tables must take intoconsideration the XXX Change Management Policy and therefore access at theapplication layer will be tightly controlled to protect the integrity, reliability and consistencyof the results of the underlying transactional system. Considerations for access will takeinto account the instance and client needed for compliance purposes. At the application


13/27

Security Design

Page 13

layer, there are two general definitions of tables each having unique security requirementsin SAP: client dependent and client independent. When making changes to clientdependent tables/data, you only impact the client that you are currently logged into whenmaking the changes. When making a change to a client independent table (T000), you

impact every client within that particular instance. When the GUI level access isprovisioned, the following should be followed (transaction SE16 and SM31).

I. Development Instance

Limited table access to the user allowed to perform configuration

Within the ABAP client, grant the ABAP programmer client dependent tableaccess

Client independent table access should be limited to the key people within theconfiguration master client

Restrict all users, in every client from having access to Basis and Security relatedtables, authorization groups starting with an S

II. Integration/QA

Allow display access to tables

There should be no configuration allowed based on client settings

III. Production

Display only

No configuration allowed based on the client settings

Functionality within the Profile Generator is considered configuration and mayrequire special procedures

4.1.13. Table Query Security

SQVI table queries provide powerful SE16 like access into ECC tables which can result innegative system performance. As a result, will deploy reporting

solutions for adhoc query that may involve other tools than ECC where performance can bebetter controlled. Access to ECC queries will be limited based on critical business need.

4.1.14. Table Authorization Object Security

Client dependent table access is controlled through the SAP supplied authorization objectS_TABU_DIS with two fields: activity and authorization group. There are three basicactivities 01 create, 02 change and 03 display. The authorization group is the key toensuring that a user only has access to the tables that is required to perform their functionor job responsibility. The critical authorization group that should always be restricted is thatstarting with S. All SAP basis and security related tables are assigned to an authorizationgroup starting with S. The SAP supplied authorization object S_TABU_CLI controlsaccess to client independent (cross client) tables. Granting access to configure/maintainclient independent cross client should be properly approved and review by the Basis team.

This particular object consists of a single field, which a value of X grants a user the abilityto configure/maintain client independent tables.

4.1.15. Role Build Sequential Process


14/27

Security Design

Page 14

In order to develop the detailed role build matrix used as the foundation for develop securityroles, the process used included..

4.2. BW/BOB JThe BW system is an analytical processing system that performs complex calculations on data stored in it.As a data warehouse, it does not use transactions the way that ECC does but instead uses three primarytypes of restrictions to secure reports.

4.2.1. Overview

BW roles can be restricted by the BW structural elements InfoAreas and InfoCubes. Thistype of specification gives access to all of the data housed in the InfoArea(s) or InfoCube(s)specified. To be consistent with the overall Security Strategy, organization level (i.e., plant,company, etc) will not be integrated into the design and therefore will also not be built intoBW. The security structure for BW is intended to restrict normal functionality where it is

important to protect the integrity of the results, but not to restrict similar content. A role inBW typically identifies a collection of reports and queries for a specific business area. Rolesoften correspond to job titles. Roles are associated with tasks and include all activities thatare carried out by the respective users.

The vast majority of XXXs BW end users will never directly logon to the BW system usingthe SAPGui but will login from the BOBJ front end,

4.2.2. BW Security Strategy

The strategy for ensuring security in the Business Warehouse is based on a two-partapproach that distinguishes between different types of users and the various types ofqueries or reports they are authorized to read/change/create. BW users can be thought ofin three broad groups. These groups are aligned with the nature of their required BWusage according to their job responsibilities. The first group consists of those who go intothe BO system accessed through BO infoview to display or execute reports that have beencreated for them (End Users or Report Users). The second group consists of those whowill create queries and reports to be used by them or for the general use of others withintheir organization (Power Users or Report/Query Creators). The third group consists ofthose who will administer the BW system. This group generally consists of Basis andSecurity Administrators. Both End Users and Power Users will be assigned to one or morespecific role as required by their XXX responsibilities. When the user logs into theBusiness Warehouse environment, the user will only see the menu for the access that hasbeen granted via the assigned role.

The first step is to identify the roles that need to be created and what the users will need toaccess for each role. The simplest way to give access to the End Users is by info provider.

For EX: GL Users will have access to GL cubes. Once the Role has been created andusers assigned to that role, authorizations are generated to enable access to the BusinessWarehouse. .


15/27

Security Design

Page 15

Power User roles will also need to be defined with the ability to create, change and displayqueries and reports both for themselves and others in their department. BW AuthorizationObjects

BW Reporting Authorizations will be based on hierarchy of authorizations as defined in thePDDs a spreadsheet will be used to assign the end user roles to individual users as part ofthe overall role to job position matrix.

4.2.3. BW Reporting Roles

The 2 main groupings will be called Menu Roles and Security Roles. The menu roles willdefine the folders that users will see (in addition to their favorites). There are noauthorization profiles defined for menu roles. The different security roles may be defined toallow access to an Infoprovider. The idea is to give functional area access to begin withand then build it up by giving appropriate security roles for an individual to perform his/herfunction. Defining security for BW users becomes a simple exercise of combining theappropriate Menu and Security roles.

When developing report queries, developers should be aware of the defined authorization

relevant InfoObjects. All InfoCubes attached to any of these authorization objects requirespecial consideration.

4.2.4. BW Administrator Roles

The Administrator users will have the same roles as they have in R3 system as the Basisand Security activities are common to both. There will be a BW specific delta role built andassigned to Basis and Security users to cover any access needs arising out of special t-codes unique to BW environment.

4.2.5. SAP BOBJ Security


4.2.7. Authorization and Field Values4.2.8. Authority Check in Custom ABAP



4.3. SAP GRC will implement the following SAP GRC Modules during Release 1:

SAP GRC Risk Analysis and Remediation (RAR)

SAP GRC Super User Privilege Management (SPM) SAP Process Controls (PC)


16/27

Security Design

Page 16

All modules will have a small number of users. Administrator rights for will be restricted to just a fewindividuals. For business users of each tool, security rights with update capability will be given basedon just on the functions that each user actually needs to complete his/her job.

Subsequent releases of RAR may include Complaint User Provisioning (CUP) and Enterprise RoleManagement (ERM). See the GRC Strategy & Design Document. CUP may have hundreds of usersdepending on the configuration since CUP is a tool that helps provide automation for userprovisioning process. ERM is typically just used by basis/security users to help build security usingpre-defined leading practices. For Release 1, XXX will not deploy these features of RAR.

4.3.1. Overview

There are 2 different types of roles needed for GRCFront-end and Back-End Roles. SeetheGRC Role Build.

Front-end Roles - Front-end roles grant application rights to configure and run the tool

Back-end Roles - Back End roles are used with ECC for SPM to provide certainmaster data update functionality needed to run the tool

GRC is a java based tool that has security administered using the SAP User ManagementEngine (UME) for the front-end roles. UME provides a portal like security. GRC comes withpreconfigured UME roles which contains various UME actions. These UME roles can beassigned to the UME user ids directly or may be copied in to a custom role and thenassigned to the UME users. Customization of these roles is typically not needed.However, it is leading practice to copy the standard GRC UME roles into custom UME rolesto prevent any issues related to GRC upgrades. UME roles will be assigned to users basedon need. Where possible, XXX will use out of the box GRC roles. At a minimum the mainusers for GRC are as follows:

Function Modules Level of Access

System Administrator All Full

SOX Finance All Read

Internal Audit All Read

Role Owners RAR SOD/CUP

Firefighter Support SPM TBD based on function

4.3.2. GRC RAR

XXXs GRC Risk Analysis and Remediation is a web-based, fully automated security auditand segregation of duties (SoD) analysis application. It provides the largest and most

comprehensive database of SoD rules available for SAP. Risk Analysis and Remediationcan be used to identify, analyze, and resolve all SoDs and audit issues relating toregulatory compliance. The typical roles and functions assigned for RAR includeadministrator, Security Admin, control monitor and SOD reporting by using standard UMERAR roles including VIRSA_CC_ADMINISTRATOR, VIRSA_CC_SECURITY_ ADMIN,
https://thesource.ihs.com/sites/sharedservices/vanguard/ImplementationTeam/Shared%20Documents/Vanguard%20Program/Realization/ICC/GRC/GRC%20Delivered%20roles%20.xlsxhttps://thesource.ihs.com/sites/sharedservices/vanguard/ImplementationTeam/Shared%20Documents/Vanguard%20Program/Realization/ICC/GRC/GRC%20Delivered%20roles%20.xlsxhttps://thesource.ihs.com/sites/sharedservices/vanguard/ImplementationTeam/Shared%20Documents/Vanguard%20Program/Realization/ICC/GRC/GRC%20Delivered%20roles%20.xlsxhttps://thesource.ihs.com/sites/sharedservices/vanguard/ImplementationTeam/Shared%20Documents/Vanguard%20Program/Realization/ICC/GRC/GRC%20Delivered%20roles%20.xlsx


17/27

Security Design

Page 17

VIRSA_CC_REPORT and VIRSA_CC_BUSINESS_OWNERand custom roles will be made (ifrequired).

4.3.3. GRC SPM

Super User Privilege Management enables users to perform emergency activities outsidetheir role as a privileged User. SPM provides the solution for systematic handling of allemergency situations in a controlled and auditable environment. The typical roles andfunctions assigned for SPM include SPM User role, SPM Owner role and SPMAdministrator role.

4.3.4. GRC PC

text

.






GRC configuration will follow best practice and minimization of customizations. Defaultsettings will be evaluated to ensure associated risks are being managed in according with Control requirements. See the GRC Configuration Document.

4.4. SAP Solution ManagerText

4.4.1. Overview







18/27

Security Design

Page 18

4.5. VertexText

4.5.1. Overview






4.6. Process Integration (PI)Text

4.6.1. Overview






5. TerminologyAuthorization A set of authorization object specific values that allow a user to perform

certain functions within the XXX system.

Authorization fields Values used to define an authorization for an authorization object

Authorization objectA system template for authorization that relates to a particular system object.Authorization objects consist of fields for specific values relating to certaindata or activity with that data.

Authorization profile A group of up to 150 authorizations that are automatically generated via theProfile Generator. If a Role contains more than 150 authorizations, more thanone profile is generated


19/27

Security Design

Page 19

Data Owner The data owners are responsible for protecting (controlling access to) thetransactions, tables, and reports that they own.

Funct ional Team Member of the core development team, with responsibility for a specificfunctional area and specifying security requirements from a businessperspective.

Governanc e Risk and

Compliance (GRC)

Team

A member of the ICC is responsible for establishing the security strategy,GRC strategy, related designs and establishing the associated administrationprocesses.

Profi les A security profile is a collection of Authorization Objects and AuthorizationsValues.

Role Single Roles consist of authorization profiles, which are generated using theProfile Generator tool. Roles can be directly assigned to user ids.

Role-Composite Consists of a collection of single/individual roles grouped together. As such,these do not have authorizations or profiles directly assigned to them.Composite Roles may be directly assigned to user ids.

Role-Master May be created for a generic job role (e.g. Accounts Payable Clerk) or taskbased roles (e.g. Create Vendor) and may be used as a template. If a role isto be used for multiple divisions where each clerk would perform the samefunctions, but should be restricted to data for their own division, a role will bederived from the Master role.

Role-Simple Single roles consist of one or many authorizations that are required by theSAP system in order to perform transactions (single profile).

Role Owner A business representative assigned with responsibility for certain roles andthe assignments of those roles to end users for a functional area.

Securi ty Roles A security role is a collection of linked or associated activities, such as tasks,reports, and transactions. A role is a data container for the SAP ProfileGenerator to generate authorization profiles and usually represent either atask or job role in the company. A particular task or job may consist of one ormore profiles

Securi ty Team Member of the Technical Services team, and is responsible for the securityadministration process.

System Support Application support having three primary pieces.

The Global Service Center (GSC) - first line of support and the focalpoint for receiving security requests and problems. The GSC handlesthe initial contact with end users for all support requests and providesticketing and escalation support.

XXX SAP Support (Support) provides technical information or


20/27

Security Design

Page 20

support. Support personnel diagnose and document user accessissues, troubleshoot user access issues, route requests toappropriate queues based on escalation process flows and provideassistance regarding

Basis Administrators perform critical application functions exceptconfiguring users, profiles and authorizations. These users haveaccess to perform ABAP functions and full access to all needed SAPtransactions, tables and client independent tables to complete theirjob function on a day-to-day basis.

Internal Contro ls and

Compliance (ICC)

Responsible for monitoring that XXX practices are followed and that XXXinformation resources are properly protected.

User-Dialog Application users that can log on to specific application

User-End Have functional access based on transactions and hierarchy. Access is

defined based on job responsibilities, positions within XXXs organizationalstructure and environment utilization (i.e., production vs. stage). Access isfurther restricted based upon segregation of duties restrictions identified byICC.

User Id Represents the User Identification in the XXX system. User Ids are requiredto log on to XXX systems

User group User groups facilitate the process for user reporting within the XXX system.User groups enable security administration of users within the specified usergroup

User master record Each user has a unique user account called a master record. A user masterrecord contains a users personal data such as name, surname, address, andother often used system parameters such as printer preferences, systemaccess rights, etc. The user master record is automatically associated with auserid.


21/27

Security Design

Page 21

6. Tables

6.1.Security RACI Chart

Task

ICC

GRCTeam

Security

Team

Functional

Team

RoleOwner

DataOwner

System

Support

Establish security review activities A R I

Design security builds A R I C

Configure/Modify security builds R, A I

Ensure critical activities are not combined. A R I

Provision users for componentsand environments.

R A

Identify potential compliance issues A R

Assist the security team in preparing for an audit. R, A

Security is compliant with XXX policies. A R I

Define & document SAP Security and GRCAdministration processes

A R R I I C

Obtain approval for the defined processes R, A I I I

Communicate the SAP Security & GRC Administrationprocesses to stakeholders

R, A I I I I I

Resolve complex situations A R R

Define and document security and GRC architecture A R R

Review the design documents for completeness ofSecurity and GRC requirements

R,A C C C

Provide system administration knowledge for postrelease administration

A R R I

Support Security Testing resolution A I R I C

Specify business needs for access to area I I I R C R

Define navigation expectations impacted by securitydesign

I I R I

Understand security capability to area of responsibility C I R A A I

Assign access to user for area of responsibility C R A A

Security tests results successful C R I A

Role training C R, A

Access Reviews I C R, A R, A I

Validate accuracy of content C I R, A


22/27

Security Design

Page 22

6.2. ECC Security ParametersParameter Description

login/min_password_ln

g This parameter is used to specify the minimum length of a password. TheDefault is three characters. You can set it to any value from 3 to 8. Theminimum length will be set to 6 characters. SAP also provides a mechanismfor additional customization of password restrictions. Using transaction SM30and maintaining table USR40, password restrictions for acceptable valuesmay be implemented. Table USR40 is used during logon validationprocedures and password checking to make sure the password does notviolate any of the guidelines. USR40 is a table with impermissible values.There are two wild card characters that may be used (? represents anysingle character and * represents a sequence of any combination ofcharacters of any length.) For XXX, the setting will be 8 characters

login/password_expiration_time

This parameter is used to specify the number of days after which a password

must be changed. The SAP default is zero, which never requires the user tochange their password. Users should be required to periodically change theirpassword every 30 days. For XXX, the setting will be 90 days

login/fails_to_session_end

Defines the number of unsuccessful logon attempts before the system doesnot allow any more logon attempts. The SAP default is 3 and can be set toany value between 1 and 99. The typical approach is to permit threeattempts. For XXX, the setting will be 3 times

login/fails_to_user_lock

This parameter is used to specify the number of times that a user can enteran incorrect password before the system locks the user against further logonattempts. The SAP default is 12 and can be set to any value between 1 and99. For XXX, the setting will be 3 times

login/failed_user_auto

_unlock Defines whether user locks due to unsuccessful logon attempts should beautomatically removed at midnight. For XXX, the setting will be set to no=0

login/system_clientThis parameter is used to specify the default client. This client isautomatically filled in on the system log on screen. Users can type in adifferent client.

login/no_automatic_user_sap*

This parameter is used to restrict special default properties for SAP*. If theparameter is reset to 0, it would allow logins with SAP*, password PASS,and unrestricted system access privileges. The parameter should be set to 1.

rdisp/gui_auto_logoutThis parameter is used to specify the number of seconds before automaticallydisconnecting inactive users from the system. The SAP default for all

instances is 0 and each instance may require a higher setting. This timerepresents the number of seconds.


23/27

Security Design

Page 23

auth/no_check_in_some_cases

This parameter is used to enable SU24 to activate authorization checks fortransactions and to work with the Profile Generator. By default, the function isinactive and the parameter value is N. To activate, the parameter should be

set to value Y.login/ext_security

External security activated

auth/no_check_on_tcode

This parameter is used to check on object S_TCODE. In certain cases, thiscan be shut off, but this results in a big security risk for the system. Bydefault, the function is inactive, and the parameter value is N. To activate, theparameter should be set to value Y.

Auth/tcodes_not_checked

Transaction codes that can run without the proper authorization. Examplesmaybe SU53 and SU56 that helps analyze authorization failures when a usercant run a transaction

6.3. System Profile Parameters

XXX Values

PARAMETER DESCRIPTION

Prod

QA

DEV

SAP

Default

Login/fails_to_session_end Number of times a user can enter an incorrect

password before the system terminates thelogon attempt. Default is 3.

3 4 4 3

Login/fails_to_user_lock Number of times a user can enter an incorrectpassword before the system locks the useragainst further logon attempts. The lock isreleased at midnight. The default is 12.

3 6 6 12

Login/system_client Specifies the default client. This client isautomatically filled in on the system logonscreen. Users can overwrite this.

100

Login/failed_user_auto_unlock Enable automatic unlock of locked users atmidnight. Default is 1allowed

0 0 0 1

Login/min_password_lng Minimum length of a password. Default is 3. Anyvalues from 2 - 8. SAP also provides amechanism for additional customization ofpassword restrictions. See Security Strategy

6 6 6 3


24/27

Security Design

Page 24

XXX Values


Prod

QA

DEV

SAP

Defau

lt

document for details.

Login/password_expiration_time Number of days after which a password must bechanged. When the expiration time is reached,the user is asked to enter a new password.Default is '0' - no time limit.

60 90 90 0

Login/no_automatic_user_sap* Disables special properties for user SAP* when

this parameter is set to a value greater than zero.When the parameter is reset to 0, it would allowlogins with SAP* using the default deliveredpassword and unrestricted system accessprivileges. The default is 0 - permitted.

1 1 1 0

Rdisp/gui_auto_logout Specifies the number of seconds a user sessioncan be idle before being automatically logged offby the system. Default is 0

900 1800 1800 0

auth/no_check_in_some_cases Used to enable SU24 to activate authorizationchecks for transactions and to work with theProfile Generator. Default is N.

Y Y Y N

auth/no_check_on_tcode Checks on object S_TCODE. In certain cases,this can be shut off, but it results in a big securityrisk for the system. Default is N. Do not changeunless absolutely necessary.

N N N N

Auth/check_value_write_on Enables the transaction for authorization analysisSU53, when this parameter is set to a valuegreater than zero. This is highly recommendedas it is the key to determining and resolving SAPECC6 authorization issues and is essential forSecurity Administrators

1 1 1

DEFAULT.PFL To make the parameters globally effective in aSAP system, set them in the default profile. To

make them instance-specific, you set them in theprofiles of each application server in your SAPsystem.

Auth/authorisation_trace Enables easier diagnosis of security failuressince allows running of System Trace

Y Y Y


25/27

Security Design

Page 25

XXX Values


Prod

QA

DEV

SAP

Defau

lt

(transaction ST01).

login/disable_multi_gui_login Disable multiple sapgui logons (for same ECC6account). Default is '0' - off.

0 1 1 0

Rdisp/gui_cleanup_delay Hold user session information after sessiontermination. Set to the value of '0' if preventingmultiple dialog logons

0


26/27

Security Design

Page 26

6.4. SAP ECC Sensitive Authorization Objects

SAP Standard

Authorization Object

Description

S_ADMI_FCD Allows various system administration functions

S_BDC_MONI Allows to manipulate batch jobs

S_BTCH_ADM Enables control Batch Jobs in all clients

S_BTCH_ADM This object for Background Administrator ID with value Y should beonly given to Basis team and special users that process backgroundprocesses like cutting checks and mass processing vendors.

S_CTS_ADMI Access to perform administration functions in transport system

S_DATASET Only certain programs should be allowed to access data files. Thefield ABAP: program name should be limited to the program name.Often this object is used in custom transactions (starting with Z).For those a system trace ST01 has to be performed in DEV QA.

S_DEVELOP Permits ABAP development. Activity field is critical. End usersshould only have value 03Display

S_IMG_ACTV Authorization to perform IMG functions

S_LOG_COM Authorization to execute Logical Operating system commands

S_PROGRAM Allows specified programs or reports nodes to be called. When thisobject is used most roles should have limitation only to the specificprogram or report node that is necessary to call. This can beachieved by using authorization groups defined by developers.

S_QUERY Authorization for SAP Queries

S_TABU_CLI Ability to maintain client independent tables

S_TABU_DIS Ability to display or change tables. If a user has access totransactions SM30, SM31 or SE16, this object should be used withauthorization groups for tables. Authorization Administrator can

specify authorization groups by using SE54. The value 02 - changeaccess should be granted with special care and authorization fromthe process owner and system owner, and it should never be usedwithout authorization groups

S_TCODE Access rights to start transactions and should never have value * -All for end users, but instead it should have the definition oftransaction that the user needs to perform.

S_TRANSPRTS_NUMBER

Access to transport systemNumber Range maintenance

S_USER_AGR Ability to maintain and display roles

S_USER_AUT Ability to display profiles and their change history. This objectshould be only used with display ability. Only SecurityAdministration should have all access rights for this object.

S_USER_GRP Ability to display changes to all user master data. This object is onlygranted with display ability. Only the PA Administration and SecurityAdministration should have the change ability. Help desk shouldhave lock / unlock and password change ability.

S_USER_OBJ Ability to globally deactivate authorization objects


27/27

Security Design

Page 27

SAP StandardAuthorization Object

Description

S_USER_PRO Ability to display profiles and their change history. This objectshould be only used with display ability. Only Security

Administration should have all access rights for this object.

Date post:	03-Jun-2018
Category:	Documents
Upload:	sureva65
View:	227 times
Download:	0 times