Security Design
Security Design Document
Page
1
Security Design
Document Control Author File Name Version V1 V2
Diane Davis /Ramesh Babu/Barry Roberts/Bill Wade Security Design.doc
Revision Date 04/27/10 11/28/10
Revision Description st 1 Draft of All Sections Focus on XXX specific decisions
Author SI 1 Ramesh B Kommaddi
Sign-off N/A
Target Readership This document is intended for anyone who has responsibility for, or has a vested interest in SA Security & GRC Administration at XXX. This includes: y y y y y y y y y
P
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
Page
2
Security Design
1.
Introduction___________________________________________________________________
1.1.
Purpose ................................ ................................ ................................ .................... 4
2.
Scope ________________________________________________________________________
3.
Security Practices _____________________________________________ 3.1. 3.2. 3.3. 3.4. 3.5. 3.6.
4.
Roles and Responsibilities................................ ................................ ....................... 6 Naming Convention................................ ................................ ................................ .. 6 General Security Approach................................ ................................ ...................... 7 Security Testing ................................ ................................ ................................ ....... 8 User and Role Provisioning Processes ................................ ................................ ... 8 Other table access ................................ ................................ ................................ ... 9
Application Specific Considerations ______________________________________________ 4.1. 4.2. 4.3. 4.4. 4.5.
SAP ECC................................ ................................ ................................ .................. 9 BW/BOB J ................................ ................................ ................................ ............... 15 SAP GRC ................................ ................................ ................................ ................ 16 SAP Solution Manager ................................ ................................ ............................ 18 Vertex ................................ ................................ ................................ ...................... 19
5.
Terminology __________________________________________________________________
6.
Tables _______________________________________________________________________ 6.1. 6.2. 6.3. 6.4.
Security RACI Chart ................................ ................................ ................................ 22 ECC Security Parameters ................................ ................................ ....................... 23 System Profile Parameters ................................ ................................ ..................... 24 SAP ECC Sensitive Authorization Objects ................................ ............................. 27
Page
3
Security Design
1.
Introduction
This document is to describe the overall SA P Security Design that will be adopted for XXX SA P systems. This design supports the configured business processes within the XXX SA P system, whilst ensuring an adequate level of security and controls.
1.1.
Purpose
The purpose of this document is to identify the high level design in order to y y
y
2.
Define the build that will provide guidance for the build and run of SA P ECC security and GRC Provide an overview of the approach for defining the various user roles in a typical SA application environment. Specify particular security configur ation decisions for the solution
P
Scope
This document refers to the Securit y concept within the solution for end users. Both the production and non-production environments are considered within the scope of the security and GRC teams. The following systems components are considered in scope f or this document: y y y y
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 XX X practices for their categories, where applicable y y y
y
y
y
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 SA P systems operate are out of scope of this document Disaster recovery (DR) and business continuity planning (BC P) for SAP and related components will fall under the XXX¶s current IT policies and procedures All components of systems subsidiary to and interfacing with the mySA P.com systems will be maintained and secured following existing procedures, guidelines and standards. Business Process Controls Strategy, risk assessment and controls recommendation shall be the responsibility of the Process Teams and the Internal Control and Compliance team. See the Governance Risk and Compliance Strategy Document
For non-SAP application security requirements, please refer to the standards and guidelines defined within the policies and standard operating procedures as documented on the XXX intranet.
Page
4
Security Design
Page
5
Security Design
3.
Security Practices
While specific applications will have unique security considerations, all of the components are subject to similar practices to ensure c onsistency and compliance with the Security Strategy. The following areas will be common to all applications.
3.1.
Roles and Responsibilities
Security and GRC Administration requires active involvement from XXX throughout the project. A Responsibility, Accountability, Consult and Inform Chart (RACI) lists the security specific roles and responsibilities for the SA P implementation. See the Terminology area for a definition 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 of the box roles provided they sufficiently address access needs and risk management concerns. When custom roles are required a consistent naming convention should be observed across all applications as much as possible. See the role naming convention document at: https://thesource.XXX.com/sites/sharedservices//ImplementationTeam/S hared%20Documents/%20Program/Realization/ICC/Security/Role%20N aming%20Conventions.docx
3.2.2.
Users
Dialog users are assigned an application specific account-user master record that may be assigned one or many applicati on roles. XXX Employees and Contractors user ids will be the same as their XXX network ID (Active Directory (ADID). Application userids will model this same convention. Each XXX employee will have one and only application userid (if needed). No generic SA P userids will be created and no userids will be allowed to be shared. Exceptions will be made for t esting role functionality and model users in a non-production environment and for service/batch accounts in production. When service accounts are required to support batch processing and Tier 3 level support, a separate batch-id will be established for each process area. Jobs in production systems should not be scheduled using the individual user ids. Each business area will have at least one batch-id to run the jobs related to that area. These accounts will comply with the XXX Information Security Policy requirements.
User Groups
Page
6
Security Design
For the SAP solutions in , there are two types of User Groups to consider, Administrative User Gr oups 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 to use administrative user groups during the initial release. The following administrative user groups 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 team The second type of user groups is the authorization user group which is used to assign roles to groups of people at one time. For use of ECC, there is no plan to use this type of group during the initial releases. The preferenc e is to assign to the end user due to the need t o be flexible with assignment of task based roles. y y y y y y y y y y
3.3.
General Security Approach
The security design and build is based on an approach with the goal of reducing risk of access to sensitive areas, content while complying with XXX IT Security Policies and Procedures. To align with the internal control requirements and prevent potential deficiencies that can impact an organization, user functions will be segregated with respect to the user¶s job descriptions and responsibilities. In general, transactions with a very high sensitivity (IT and Business Sensitive Transactions) will not b e combined with other transactions. Unique use of transactions per role is the preferred approach with duplication of transactions within other roles only when no other alternative is present. The role definition process will provide a high level of flexibility, visibility and control to appropriately manage the high-risk transactions and remediate users when necessary. For each of the in-scope systems, transactions, queries, reports and web addresses, etc. will be included into the role menu. The XXX approach to security is to follow standard SDLC methodology that includes ³Design, Build, and Test´. The approach took into account: y y y
y
y
Transactions listed by process and role Role Build Templates Org level security is high maintenance for user provisioning and therefore has been determined 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 necessary authorizations and profiles. If a Security Role contains more than 150 authorizations, the profile generator will automatically create additional profiles. Roles will be directly assigned to a user.
Page
7
Security Design
y
y
3.4.
Training will identify the ³to be´ operational job function for job role mapping. Security will collaborate to map task based roles to the specified function in time for UAT O bserve 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, the use of wildcards can lead t o the granting of unintentional access. Minimize use of child roles to avoid breakage of parent ± child relationship. o Identify sensitive data and restrict access to transactions/reports capable of o accessing that data. Group like functions together into single roles. o o Follow principle of least privilege Ensure correct naming convention is used. o o Add tcode (s) in alphabetical order to the f older in Role Menu. XXX will use the default profile names which start with t, unless a custom profile o 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 requirements o Role descriptions are to be kept current with the latest change o Role Owner approval will be obtained before any role modification.
Security Testing
A security testing strategy will be coordinated with the overall project testing strategy for the appropriate cycle and type of testing. Security testing will consist of: y y y
Unit Testing Integration Testing User Acceptance Testing
During each phase, the Security Team will resolve appropriate authorization f ailures and make the appropriate changes and/or modifications to the levels associated with each Role per the testing feedback. Considerations for job role mapping will be coordinated with the Testing and Training teams to ensure consistency in the testing objectives and efficient use of the resources deployed for all these areas simultaneously. Role owner approval of role definitions and role assignments will be a required output from the testing cycles. See the Testing Strategy document for specific objectives per testing cycle.
3.5.
User and Role Provisioning Processes
Role builds will follow controls defined in the GRC Role Build and Provisioning PDD¶s. will utilize the GRC RAR simulation functionality to prospectively identify potential SOD risks before role or provisionin g 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 the change management controls specified in the GRC Change Management PDD. Security role builds must be transported using the trans port process defined.
Page
8
Security Design
3.6.
Other table access
Access to tables can occur at the database layer. As such, will implement alternative procedures consistent with legacy S O X systems to monitor highly privileged access at the database and server layers. Associated security will follow principle of least privilege and will be reviewed in accordance with IT Global Policy. Access to databases requires approvals as stated in the XXX IT Information Security Policy.
4.
Application Specific Considerations
4.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 and the profile generator includes in the authorization data all of the authorization objects that are checked for these transactions. The authorization objects that are brought in to the Profile Generator are about 90-95 percent of what is needed t o be considered complete.
4.1.1.
Overview
In addition to the general approach for security, the ECC security design and build aims to reduce and potentially eliminate the existence of segregation of duties conflicts within the SAP technical design while adhering to GRC Access Controls best practice O bservance of identified critical sensitive transaction codes ECC will deploy a compliant security build. Authorization object level access control rules based on the data needed to be accessed will be incorporated around these transactions to provide 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 S OD violations Utilization of the GRC RAR for S OD reviews prior to deployment for role and user reviews for SAP ECC security Roles will be defined based on a task. Therefor e, tasks are assigned to a role owner having significant functional knowledge of what is required to perform the task. 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 authorizations widely which causes issues around S OD and excessive access. Single roles containing similar functions/transactions can be more easily added or removed from composite roles. Single roles containing dissimilar functions/transactions will typically require more analysis to determine whether a transaction can added or removed. Limited use derived roles to represent similar job roles. Derived roles are derived from 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 roles warrants this structure for maintenance y y
Comment [DMD1]: Insert hyperlink to role build
y y y y
y
y y y
y
y
y
Page
9
Comment [DMD2]: hyperlink
Security Design
y
y
Use of single roles instead of master roles because derived roles will not be used for 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 unauthorized access. Roles are created and maintained via transaction PFCG. Profiles can be created manually using transaction SU02 and automatically by using SA P Profile Generator. It will be XXX¶s policy to rely on Profile Generator for creation of security profiles whenever possible as per our systems integrator leading practice design. SAP transactions are secured through three methods: 1. System access to execute the transaction 2. Check object for activity to execute the transaction 3. Authority checks within the supporting ABAP/4 program All three of these must be taken into consideration when administering transaction level security.
4.1.2.
Authorizations Objects
An authorization object is a template for testing access privileges. It groups up to 10 fields and tests for execution rights utilizing AND-logic in programs to see if a user has the right to carry out an action. A user's action is approved only if the user passes the access test for each 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 specific transactions. 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 SA P modules. y y
Example: an authorization object for securing accounting documents identifies the type of document that can be 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 f unctional area being executed. There are approximately 22 object classes used to logically group the SAP supplied authorization objects. Refer to the SA P supplied on-line documentation or an actual client for a detailed listing. The objects are maintained in the table T O BJ and can be viewed via transaction SE16. The system access to execute the transaction is controlled by the authorization object S_TCODE. This particular object requires that the transactions needed for a user, position or 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, putting in 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 based upon an authorization object. A user is permitted to perform an action only if he/she Page
10
Security Design
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 assigning values to the fields that are defined for the object create an authorization for an authorization 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 be granted, 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 be assigned 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 s ystem has to be protected so that unauthorized users cannot access it. Therefore, the appropriate authorization is required before a user can carry out certain actions in the system. When you log on to the ECC6 system, the system checks in the user master record to see which transactions you are authorized to use. An authorization 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 routines are required to use appropriate authority checks. Prior to the configuration and security being transported to the Q A system, the Security Team and Functional Team will verify that the authority checks are in place and functioning adequately. ECC performs authority checks to ensure execution of the code with security considerations. During the creation process XXX will perform the following when creating new authority checks: 1. Evaluate the need to create new authorization objects or use existing objects 2. If necessary, create the new authorizati on objects and associate them with an existing object class. All new objects must be transported across the entire system client landscape 3. Identify the values necessary to execute the program 4. Identify the position or role that should have access to execute this program, this may be dependent on each client 5. If necessary, add the transaction code to the SAP ECC Profile Generator using SU24 6. If using the profile generator, generate the new activity group necessary to execute the program 7. If necessary, create the manual authorizations and profiles necessary to execute the 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. When creating 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 go in to affect
4.1.6.
System Security Parameters Page
11
Security Design
The SAP Security Administrator must periodically check the SA P ECC system parameters on each instance. This can be accomplished by using transaction SE38 to execute the ABAP/4 program RS P ARAM on each system. In particular, the SAP Security Administrator must verify that the following system parameters are set appropriately. SA P has specific default parameters in the system that can be tailored for each instance. You can use these system profile parameters to set password characteristics, incorrect logon limits, and the default client. The following parameters are presented for later review. Additional details and recommendation can be found in SA P ECC Security Parameters Table. Note: Parameters apply to both the ECC6 and BW s ystems.
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 Creation PDD. The following are the necessary steps to establish a check object for a new transaction 1. Review the existing authorization objects to determine the ability to use an SA P supplied object 2. If necessary, create the new authorization object 3. Execute transaction SE93 4. Enter the new transaction code and click on the µMaintain¶ icon 5. Enter the authorization object selected to be the check object 6. Enter the field level values required Note, this information can be manually entered int o the table TSTCA via transaction SE16. y y
4.1.8.
Sensitive
Transactions
There are specific transactions contained within SA P that are considered sensitive and powerful in nature. The misuse of these transactions within the system could negatively affect 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 security team will make sure those transactions are accounted for in the SA P GRC RAR rule set. GRC Process Controls will be used for the IT Basis critical areas for Release 1.
4.1.9.
Sensitive IDs & Prof iles
In addition to monitoring sensitive transactions, SA P has a several powerful userids and profiles that should be monitored closely for appropriate use. Powerful ids will not be granted to individuals in production. In the rare circumstance where it is required, GRC SPM controls will be used to allow for a mitigating control of the activity performed. In nonproduction environments, these ID¶s will be highly restricted to technical personnel only and assigned only as needed for the limited time needed to perform mandatory functions not able to be performed under the properly provisioned ID. Segregation of duties and observance of highly confidential information must be taken into consideration in all environments. The following is a list of SA P ID and profiles should be restricted: Type
Detail
Page
12
Security Design
Profile
SAP _ALL SAP _NEW S_A.SYSTEM S_A.ADMIN S_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 SA P, there are some authorization objects that should be closely monitored. These authorization objects are considered sensitive in nature. The misuse of these authorization objects within the system could negatively affect the performance and integrity of the system. Some transaction codes do require authorization to some of these objects. However, careful considerati on should be taken wherever access is granted. See SAP ECC Sensitive Authorization O bjects Table.
4.1.11.
Program Security
Programs
in SA P are written in a standard fourth generation called ABA P/4; this language was created by SA P and is the foundation for all functionality in SA P. Access to create, maintain and execute ABA P/4 programs will be restricted to those individuals properly trained. Use of ABAP/4 will follow SAP development standards. Access to ABA P/4 programs will be granted based on thr ee elements: 1. Type of access being requested (display, maintain, execute) 2. Client where requested 3. User making the request Custom programs will be assigned to custom T-codes which will follow the GRC R ole PDD requiring these to be incorporated into an ECC role. XXX will not utilize additional maintenance/assignments at the object or authorization group levels.
4.1.12.
Table Security
The ability to perform configuration or view raw SA P data requires access to specific tables within SA P. The ability to maintain table level data affects the integrity and accuracy of information maintained by SA P. Changes to tables must take into consideration the XXX Change Management Policy and therefore access at the application layer will be tightly controlled to protect the integrity, reliability and consistency of the results of the underlying transactional system. Considerations for access will take into account the instance and client needed for compliance purposes. At the application Page
13
Security Design
layer, there are two general definitions of tables each having unique security requirements in SAP: client dependent and client independent. When making changes to client dependent tables/data, you only impact the client that you are currently logged into when making 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 is provisioned, the following should be followed (transaction SE16 and SM31).
I.
Development Instance y y
y
y
II.
Integration/QA y y
III.
Allow display access to tables There should be n o configuration allowed based on client settings
Production y y y
4.1.13.
Limited table access to the user allowed to perform configuration Within the ABAP client, grant the ABAP programmer client dependent table access Client independent table access should be limited to the key people within the configuration master client Restrict all users, in every client from having access to Basis and Security related tables, authorization groups starting with an µS¶
Display only No configuration allowed based on the client settings Functionality within the Profile Generator is considered configuration and may require special procedures
Table Query Security
SQVI table queries provide powerful SE16 like access into ECC tables which can result in negative system performance. As a result, will deploy reporting solutions for adhoc query that may involve other tools than ECC where performance can be better 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 SA P supplied authorization object S_TABU_DIS with two fields: activity and authorization group. There are three basic activities ± 01 create, 02 change and 03 display. The authorization group is the key to ensuring that a user only has access to the tables that is required to perform their function or job responsibility. The critical authorization group that should always be restricted is that starting with µS¶. All SAP basis and security related tables are assigned to an authorization group starting with µS¶. The SA P supplied authorization object S_TABU_CLI controls access to client independent (cross client) tables. Granting access to configure/maintain client 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 ability to configure/maintain client independent tables.
4.1.15.
Role Build Sequential Process Page
14
Security Design
In order to develop the detailed role build matrix used as the foundation for develop security roles, the process used included«..
4.2.
BW/BOB J
The 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 primary types of restrictions to secure reports.
4.2.1.
Overview
BW roles can be restricted by the BW structural elements ± InfoAreas and InfoCubes. This type of specification gives access to all of the data housed in the InfoArea(s) or Inf oCube(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 into BW. 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 in BW typically identifies a collection of reports and queries f or a specific business area. Roles often correspond to j ob titles. Roles are associated with tasks and include all activities that are carried out by the respective users. The vast majority of XXX¶s BW end users will never directly logon to the BW system using the SAPGui but will login fr om the BO BJ front end,
4.2.2.
BW Security Strategy
The strategy for ensuring security in the Business Warehouse is based on a two-part approach that distinguishes between different types of users and the various types of queries or reports they are authorized to read/change/create. BW users can be thought of in three broad groups. These groups are aligned with the nature of their required BW usage according to their job responsibilities. The first group consists of those who go into the BO system accessed through B O infoview to display or execute reports that have been created for them (End Users or Report Users). The second group consists of those who will create queries and reports to be used by them or for the general use of others within their organization ( Power Users or Report/Query Creators). The third group consists of those who will administer the BW system. This group generally consists of Basis and Security Administrators. Both End Users and Power Users will be assigned to one or more specific role as required by their XXX responsibilities. When the user logs into the Business Warehouse environment, the user will only see the menu for the access that has been granted via the assigned role.
The first step is to identify the roles that need to be created and what the users will need to access for each role. The simplest way to give access to the End Users is by info pr ovider. For EX: GL Users will have access to GL cubes. O nce the Role has been created and users assigned to that role, authorizations are generated to enable access to the Business Warehouse. .
Page
15
Security Design
Power
User roles will also need to be defined with the ability to create, change and display queries and reports both for themselves and others in their department. BW Authorization O bjects BW Reporting Authorizations will be based on hierarchy of authorizations as defined in the PDDs a spreadsheet will be used to assign the end user roles to individual users as part of the 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 will define the folders that users will see (in addition to their favorites). There are no authorization profiles defined for menu roles. The different security roles may be defined to allow access to an Infoprovider. The idea is to give functional area access to begin with and then build it up by giving appropriate security roles for an individual to perform his/her function. Defining security for BW users becomes a simple exercise of combining the appropriate Menu and Security roles. When developing report queries, developers should be aware of the defined authorization relevant InfoO bjects. All InfoCubes attached to any of these authorization objects require special consideration.
4.2.4.
BW Administrator Roles
The Administrator users will have the same roles as they have in R3 system as the Basis and Security activities are common to both. There will be a BW specific delta role built and assigned to Basis and Security users to cover any access needs arising out of special tcodes unique to BW environment.
4.3.
4.2.5.
SAP
4.2.6.
Authorizations Objects
4.2.7.
Authorization and Field Values
4.2.8.
Authority Check in Custom ABAP
4.2.9.
Activation Concept
4.2.10.
System Security Parameters
BOBJ Security
SAP GRC
will implement the following SA P GRC Modules during Release 1: y y y
SAP GRC Risk Analysis and Remediation (RAR) SAP GRC Super User Privilege Management (S PM) SAP Process Controls ( PC)
Page
16
Security Design
All modules will have a small number of users. Administrator rights for will be restricted to just a few individuals. For business users of each tool, security rights with update capability will be given based on just on the functions that each user actually n eeds to complete his/her job. Subsequent releases of RAR may include Complaint User Provisioning (CU P) and Enterprise Role Management (ERM). See the GRC Strategy & Design Document. CUP may have hundreds of users depending on the configuration since CU P is a tool that helps provide automation for user provisioning process. ERM is typically just used by basis/security users to help build security using pre-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 GRC ± Front-end and Back-End Roles. See the GRC Role Build. y y
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 certain master data update functionality needed to run the tool
GRC is a java based tool that has security administered using the SA P User Management Engine (UME) for the front-end roles. UME provides a portal like security. GRC comes with preconfigured UME roles which contains various UME actions. These UME roles can be assigned to the UME user ids directly or may be copied in to a custom role and then assigned 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 roles to prevent any issues related to GRC upgrades. UME roles will be assigned to users based on need. Where possible, XXX will use out of the box GRC roles. At a minimum the main users for GRC are as follows: Function
4.3.2.
Modules
Level of Access
System Administrator
All
Full
SOX Finance
All
Read
Internal Audit
All
Read
Role Owners
RAR
SOD/CUP
Firefighter Support
S PM
TBD based on function
GRC RAR
XXX¶s GRC Risk Analysis and Remediation is a web- based, fully automated security audit and segregation of duties (SoD) anal ysis application. It provides the largest and most comprehensive database of SoD rules available for SA P. Risk Analysis and R emediation can be used to identify, analyze, and resolve all SoDs and audit issues relating to regulatory compliance. The typical roles and f unctions assigned for RAR include administrator, Security Admin, control monitor and S O D reporting by using standard UME RAR roles including VIRSA_CC_ADMINISTRAT OR, VIRSA_CC_SECURITY_ ADMIN, Page
17
Comment [DMD3]: Diane hyperlink
Security Design
VIRSA_CC_RE PORT and VIRSA_CC_BUSINESS_ OWNER and custom roles will be made (if
required).
4.3.3.
GRC SPM
Super User Privilege Management enables users to perform emergency activities outside their role as a ³privileged User´. S PM provides the solution for systematic handling of all emergency situations in a controlled and auditable environment. The typical roles and functions assigned for S PM include SPM User role, SPM Owner role and SPM Administrator role.
4.3.4.
GRC PC
text
Comment [DMD4]:
Protiviti
to advise
.
4.3.5.
Authorizations Objects
4.3.6.
Authorization and Field Values
4.3.7.
Authority Check in Custom ABAP
4.3.8.
Activation Concept
4.3.9.
System Security Parameters
GRC configuration will follow best practice and minimization of customizations. Default settings will be evaluated to ensure associated risks are being managed in according with Control requirements. See the GRC Configuration Document.
4.4.
SAP Solution Manager
Comment [G5]: Ramesh to hyperlink ± Update : The document is in progress (not yet ready) Comment [DMD6]: Scott Rolfs to do
Text
4.4.1.
Overview
4.4.2.
Authorizations Objects
4.4.3.
Authorization and Field Values
4.4.4.
Authority Check in Custom ABAP
4.4.5.
Activation Concept
4.4.6.
System Security Parameters
Page
18
Security Design
4.5.
Comment [DMD7]: Bill to provide
Vertex
Text
4.6.
4.5.1.
Overview
4.5.2.
Authorizations Objects
4.5.3.
Authorization and Field Values
4.5.4.
Authority Check in Custom ABAP
4.5.5.
Activation Concept
4.5.6.
System Security Parameters
Comment [d8]: Michael wei to fill in something
Process Integration (PI)
Text
5.
4.6.1.
Overview
4.6.2.
Authorizations Objects
4.6.3.
Authorization and Field Values
4.6.4.
Authority Check in Custom ABAP
4.6.5.
Activation Concept
4.6.6.
System Security Parameters
Terminology
Authorization
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 object
Authorization profile
A system template for authorization that relates to a particular system object. Authorization objects consist of fields for specific values relating to certain data or activity with that data. A group of up to 150 authorizations that are automatically generated via the Profile Generator. If a Role contains more than 150 authorizations, more than one profile is generated
Page
19
Security Design
Data Owner
The data owners are responsible for protecting (controlling access to) the transactions, tables, and r eports that they own.
Functional Team
Member of the core development team, with responsibility for a specific functional area and specifying security requirements from a business perspective.
Governance 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 administration processes.
Profiles
A security profile is a collection of Authorization Values.
Role
Single Roles consist of authorization profiles, which are generated using the Profile Generator tool. Roles can be directly assigned to user ids.
Role-Composite
O bjects
and Authorizations
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 task based roles (e.g. Create Vendor) and may be used as a template. If a role is to be used for multiple divisions where each clerk would perform the same functions, but should be restricted to data for their own division, a role will be derived from the Master r ole.
Role-Simple
Single roles consist of one or many authorizations that are required by the SAP system in order to perform transactions (single profile).
Role Owner
A business representative assigned with responsibility for certain roles and the assignments of those roles to end users for a functional area.
Security 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 Profile Generator to generate authorization profiles and usually represent either a task or job role in the company. A particular task or job may consist of one or more profiles
Security Team
Member of the Technical Services team, and is responsible for the security administration process.
System Support
Application support having three primary pieces. y
The Global Service Center (GSC) - first line of support and the focal point for receiving security requests and problems. The GSC handles the initial contact with end users for all support requests and provides ticketing and escalation support.
Page
20
Security Design
y
y
XXX SAP Support (Support) provides technical information or support. Support personnel diagnose and document user access issues, troubleshoot user access issues, route requests to appropriate queues based on escalation process flows and provide assistance regarding Basis Administrators perform critical application functions except configuring users, profiles and authorizations. These users have access to perform ABAP functions and full access to all needed SA P transactions, tables and client independent tables to complete their job function on a day-to-day basis.
company_name> Internal Controls and Compliance (ICC)
Responsible for monitoring that XXX practices are followed and that XXX information 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 XXX¶s organizational structure and environment utilization (i.e., production vs. stage). Access is further restricted based upon segregation of duties restrictions identified by ICC.
User Id
Represents the User Identification in the XXX system. User Id¶s are required to log on to XXX s ystems
User group
User groups facilitate the process for user reporting within the XXX system. User groups enable security administration of users within the specified user group
<
User master record
Each user has a unique user account called a master record. A user master record contains a user¶s personal data such as name, surname, address, and other often used system parameters such as printer preferences, system access rights, etc. The user master record is automatically associated with a userid.
Page
21
Security Design
6. 6.1.
Tables Security RACI Chart
Task C C
I
Establish security review activities Design security builds
m a e T C R G
y t i r u m c a e e S T
A
Configure/Modify security builds A
components and environments. Identify potential compliance issues
I
R
I
R, A
I
C I
R A
A
R
R, A
Security is compliant with XXX policies.
A
R
Define & document SAP Security and GRC Administration processes Obtain approval for the defined processes
Communicate the SAP Security & GRC Administration processes to stakeholders Resolve complex situations
R, A
I
I
A
R
R
Define and document security and GRC architecture
A
R
R
Review the design documents for completeness of Security and GRC requirements Provide system administration knowledge for post release administration Support Security Testing resolution
R,A
C
C
A
I
R
R
R, A
I
I
I
I
I
I
I
I
A
R
R
I
A
I
R
I
C
I
I
I
R
C
Define navigation expectations impacted by s ecurity design Understand security capability to area of responsibility
I
I
R
I
C
I
R
Assign access to user for area of responsibility
Security tests results successful
C C
Role training
Access Reviews
I
C
R
A R
R
C
C
Specify business needs for access to area
t r m o e p t s p y u S S
R
Provision users for
Assist the security team in preparing for an audit.
r e n w O a t a D
R
A
Ensure critical activities are not combined.
r e n w O e l o R
l a n o i t c m n a u e F T
A A
I
A
C
R, A
I A
R, A
R, A
Page
22
I
Security Design
Validate accuracy of content
6.2.
C
I
R, A
ECC Security Parameters
Parameter Description login/min_password_ln This parameter is used to specify the minimum length of a password. The g Default is three characters. You can set it to any value from 3 to 8. The minimum length will be set to 6 characters. SA P also provides a mechanism for additional customization of password restrictions. Using transaction SM30 and maintaining table USR40, password restrictions for acceptable values may be implemented. Table USR40 is used during logon validation procedures and password checking to make sure the password does not violate any of the guidelines. USR40 is a table with impermissible values. There are two wild card characters that may be used (³?´ represents any single character and ³*´ represents a sequence of any combination of characters of any length.) For XXX, the setting will be 8 characters login/password_expira tion_time
This parameter is used to specify the number of days after which a password must be changed. The SA P default is zero, which never requires the user to change their password. Users should be required to periodically change their password every 30 days. For XXX, the setting will be 90 days
login/fails_to_session_ Defines the number of unsuccessful logon attempts before the system does end not allow any more logon attempts. The SA P default is 3 and can be set to any value between 1 and 99. The typical approach is to permit three attempts. For XXX, the setting will be 3 times login/fails_to_user_loc This parameter is used to specify the number of times that a user can enter k an incorrect password before the system locks the user against further logon attempts. The SA P default is 12 and can be set to any value between 1 and 99. For XXX, the setting will be 3 times login/failed_user_auto _unlock login/system_client
login/no_automatic_us er_sap*
Defines whether user locks due to unsuccessful logon attempts should be automatically removed at midnight. For XXX, the setting will be set to no=0 This parameter is used to specify the default client. This client is automatically filled in on the system log on screen. Users can type in a different client. This parameter is used to restrict special default properties for SA P*. If the parameter is reset to 0, it would allow logins with SA P*, password ³P ASS´, and unrestricted system access privileges. The parameter should be set to 1.
Page
23
Security Design
rdisp/gui_auto_logout
auth/no_check_in_som e_cases
login/ext_security auth/no_check_on_tco de
Auth/tcodes_not_chec ked
6.3.
This parameter is used t o specify the number of seconds before automatically disconnecting inactive users from the system. The SA P default for all instances is 0 and each instance may require a higher setting. This time represents the number of seconds. This parameter is used to enable SU24 to activate authorization checks for transactions and to work with the Profile Generator. By default, the function is inactive and the parameter value is N. To activate, the parameter should be set to value Y. External security activated This parameter is used to check on object S_TC ODE. In certain cases, this can be shut off, but this results in a big security risk for the system. By default, the function is inactive, and the parameter value is N. To activate, the parameter should be set to value Y. Transaction codes that can run without the proper authorization. Examples maybe SU53 and SU56 that helps analyze authorization failures when a user can¶t run a transaction
System Profile Parameters
XXX Values PARAMETER
DESCR IPTI ON d o r P
t l u a P f A e S D
V E D
A Q
Login/fails_to_session_end
Number of times a user can enter an incorrect password before the system terminates the logon attempt. Default is 3.
3
4
4
3
Login/fails_to_user_lock
Number of times a user can enter an incorrect 3 password before the system locks the user against further logon attempts. The lock is released at midnight. The default is 12.
6
6
12
Login/system_client
Specifies the default client. This client is automatically filled in on the system logon screen. Users can overwrite this.
100
Login/failed_user_auto_unlock
Enable automatic unlock of locked users at
0
0
0
1
Page
24
Security Design
XXX Values PARAMETER
DESCR IPTI ON d o r P
t l u a P f A e S D
V E D
A Q
midnight. Default is 1 ± allowed
Login/min_password_lng
Minimum length of a password. Default is 3. Any 6 values from 2 - 8. SAP also provides a mechanism for additional customization of password restrictions. See Security Strategy document for details.
6
6
3
Login/password_expiration_time
Number of days after which a password must be changed. 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 allow logins with SAP* using the default delivered password and unrestricted system access privileges. The default is 0 - permitted.
1
1
1
0
Rdisp/gui_auto_logout
Specifies the number of seconds a user session can be idle before being automatically logged off by the system. Default is 0
900
1800
1800
0
auth/no_check_in_some_cases
Used to enable SU24 to activate authorization checks for transactions and to work with the Profile Generator. Default is N.
Y
Y
Y
N
auth/no_check_on_tcode
Checks on object S_TCODE. In certain cases, N this can be shut off, but it results in a big security risk for the system. Default is N. Do not change unless absolutely necessary.
N
N
N
Auth/check_value_write_on
Enables the transaction f or authorization analysis SU53, when this parameter is set to a value greater than zero. This is highly recommended as it is the key to determining and resolving SAP ECC6 authorization issues and is essential for Security Administrators
1
1
DEFAULT.PFL
To make the parameters globally effective in a SAP system, set them in the default profile. To make them instance-specific, you set them in the profiles of each application server in your SAP
1
Page
25
Security Design
XXX Values PARAMETER
DESCR IPTI ON d o r P
t l u a P f A e S D
V E D
A Q
system.
Auth/authorisation_trace
Enables easier diagnosis of security failures since allows running of System Trace (transaction ST01).
Y
Y
Y
login/disable_multi_gui_login
Disable multiple sapgui logons (for same ECC6 account). Default is '0' - off.
0
1
1
Rdisp/gui_cleanup_delay
Hold user session information after session termination. Set to the value of '0' if preventing multiple dialog logons
0
Page
0
26
Security Design
6.4.
SAP ECC Sensitive Authorization Objects SAP Standard Authorization Object S_ADMI_FCD S_BDC_MONI S_BTCH_ADM S_BTCH_ADM
S_CTS_ADMI S_DATASET
S_DEVELOP S_IMG_ACTV S_LOG_COM S_ PRO GRAM
S_QUERY S_TABU_CLI S_TABU_DIS
S_TCODE
S_TRANSPRT S_NUMBER S_USER_AGR S_USER_AUT
S_USER_GRP
Description Allows various system administration functions Allows to manipulate batch jobs Enables control Batch Jobs in all clients This object for Background Administrator ID with value µY¶ should be only given to Basis team and special users that process background processes like cutting checks and mass processing vendors. Access to perform administration functions in transport system Only certain programs should be allowed to access data files. The field 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 perform ed in DEV QA. Permits ABAP developm ent. µActivity¶ field is critical. End users should only have value 03 ± Display Authorization to perform IMG functions Authorization to execute Logical Operating system commands Allows specified programs or reports nodes to be called. When this object is used most roles should have limitation only to the specific program or report node that is necessary to call. This can be achieved by using authorization groups defin ed by developers. Authorization for SAP Queries Ability to maintain client independent tables Ability to display or change tables. If a user has access to transactions SM30, SM31 or SE16, this object should be used with authorization groups for tables. Authorization Administrator can specify authorization groups by using SE54. The value 02 - change access should be granted with special care and authorization from the process owner and system owner, and it should never be used without authorization groups Access rights to start transactions and should never have value µ*¶ All for end users, but instead it should have the definition of transaction that the user needs to perform. Access to transport system Number Range maintenance Ability to maintain and display roles Ability to display profiles and their change history. This object should be only used with display ability. Only Security Administration should have all access rights for this object. Ability to display changes to all user m aster data. This object is only granted with display ability. Only the P A Administration and Security Administration should have the change ability. Help desk should have lock / unlock and password change ability. Page
27
Security Design
SAP Standard Authorization Object S_USER_ O BJ S_USER_ PRO
Description Ability to globally deactivate authorization objects Ability to display profiles and their change history. This object should be only used with display ability. Only Security Administration should have all access rights for this object.
Page
28
