<company_name> Security Design

<company_name> Security Design Document

Page 1

<company_name> Security Design

Document Control Author File Name Version V1 V2

Diane Davis /Ramesh Babu/Barry Roberts/Bill Wade <company_name> Security Design.doc Revision Description st 1 Draft of All Sections Focus on XXX specific decisions Author SI 1 Ramesh B Kommaddi Sign-off N/A

Revision Date 04/27/10 11/28/10

Target Readership This document is intended for anyone who has responsibility for, or has a vested interest in SAP Security & GRC Administration at XXX. This includes: y y y y y y y y y 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

............. 3............ ................. 6.......................................................... Security RACI Chart ....... .......................................... 6 Naming Convention............... ......... 8 User and Role Provisioning Processes .................................... 23 System Profile Parameters .................... 27 Page 3 ............................... 6 General Security Approach.......... ................... ....................... 6....... 4. ........................................................... 4................... ........... ....................4.............. .............5............................................. SAP ECC...2.......... ............................ 3.......... 24 SAP ECC Sensitive Authorization Objects ...... 19 Terminology ________________________________ ________________________________ ___ Tables ________________________________ ________________________________ ________ 6.................... ................................ 8 Other table access ............................................ .................... 5................. . 2.... ....... ...........4............................................... .......... 4....... ................... ............ .. .......................................... ........ Purpose ... ......... .................. ........2................. 4.... ... ........1...1............................. 6....... ......... ..............................<company_name> Security Design 1................... 4 Scope ________________________________ ________________________________ __________ <company_name> Security Practices ________________________________ _______________ 3.....1...................... 22 ECC Security Parameters ........................... ...................... ..........1.............................. 3.................3........... ....... ............6................. Roles and Responsibilities.....................4........ ... 3. ......................... 16 SAP Solution Manager ..................... 3............... Introduction________________________________ ________________________________ _____ 1.....5.... ............................. ............... 4....................2...................3....... 6....................... 9 BW/BOB J .................... 7 Security Testing ... 9 Application Specific Considerations ________________________________________________ 4..... ..... .................... ....................3...... 3...................................... 18 Vertex ............................ 15 SAP GRC ..

Scope This document refers to the Security concept within the <company_name> solution for end users. Specify particular security configuration decisions for the <company_name> solution The purpose of this document is to identify the high level design in order to 2.<company_name> Security Design 1.com systems will be maintained and secured following existing procedures. Both the production and non-production environments are considered within the scope of the security and GRC teams. guidelines and standards. please refer to the standards and guidelines defined within the policies and standard operating procedures as documented on the XXX intranet. The following systems components are considered in scope for 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 XXX practices for their categories. See the Governance Risk and Compliance Strategy Document For non-SAP application security requirements.1. y y y Introduction This document is to describe the overall SAP Security Design that will be adopted for XXX SAP systems. Page 4 . whilst ensuring an adequate level of security and controls. risk assessment and controls recommendation shall be the responsibility of the <company_name> Process Teams and the <company_name> Internal Control and Compliance team. Business Process Controls Strategy. This design supports the configured business processes within the XXX SAP system. 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 SAP systems operate are out of scope of this document Disaster recovery (DR) and business continuity planning (BCP) 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 mySAP. 1. Purpose 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 SAP application environment.

<company_name> Security Design Page 5 .

Each XXX employee will have one and only application userid (if needed).XXX.2. Roles and Responsibilities Security and GRC Administration requires active involvement from XXX throughout the project.1.<company_name> Security Design 3. See the ro le naming convention document at: https://thesource. 3. <company_name> Security Practices While specific applications will have unique security considerations.1. Each business area will have at least one batch-id to run the jobs related to that area. Application userids will model this same convention.2.2. Accountability. 3. 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. Roles Where possible. When custom roles are required a consistent naming convention should be observed across all <company_name> applications as much as possible.docx 3. These accounts will comply with the XXX Information Security Policy requirements. XXX Employees and Contractors user ids will be the same as their XXX network ID (Active Directory (ADID).2. Jobs in production systems should not be scheduled using the individual user ids. A Responsibility. The following areas will be common to all applications. Users Dialog users are assigned an application specific account-user master record that may be assigned one or many application roles. No generic SAP userids will be created and no userids will be allowed to be shared.com/sites/sharedservices/<company_name>/ImplementationTeam/S hared%20Documents/<company_name>%20Program/Realization/ICC/Security/Role%20N aming%20Conventions. Exceptions will be made for testing role functionality and model users in a non -production environment and for service/batch accounts in production. Consult and Inform Chart (RACI) lists the security specific roles and responsibilities for the <company_name> SAP implementation. When service accounts are required to support batch processing and Tier 3 level support. Naming Convention 3. a separate batch-id will be established for each process area. User Groups Page 6 . See the Terminology area for a definition of each role listed. all of the <company_name> components are subject to similar practices to ensure consistency and compliance with the Security Strategy.

There is no plan to use administrative user groups during the initial release. 3. reports and web addresses. The XXX <company_name> approach to security is to follow standard SDLC methodology that includes ³Design. The Administrative user group is used to distribute the administration of user maintenance. For <company_name> use of ECC. Administrative User Groups and Authorization User Groups. and Test´. etc. General Security Approach The security design and build is based on an approach with the goal of reducing risk of access to sensitive areas.3. transactions. Once activities have been saved in a role. User administrators can be authorized to maintain specific administrative user groups. will be included into the role menu. content while complying with XXX IT Security Policies and Procedures. the profile generator will automatically create additional profiles. The preference is to assign to the end user due to the need to be flexible with assignment of task based roles. visibility and control to appropriately manage the high-risk transactions and remediate users when necessary. For each of the in-scope systems. The approach took into account: 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. Build. Administrative user groups do not provide the ability to grant transactional access to users. In general. there are two types of User Groups to consider. If a Security Role contains more than 150 authorizations. there is no plan to use this type of group during the initial releases. the profile generator is used to generate the necessary authorizations and profiles. transactions with a very high sensitivity (IT and Business Sensitive Transactions) will not be combined with other transactions. It just allows for ease of maintenance within security administration. y Page 7 . XXX will use the Profile Generator as a tool to develop authorization profiles. user functions will be segregated with respect to the user¶s job descriptions and responsibilities. The following administrative user groups are examples of what may be created and used to assign access for these groups: y DEVELOPMENT Application Developers (ABAP) team y BASIS Basis Support Team y CONFIGURE Configuration Development Team y HELPDESK1 Helpdesk Support Team y HELPDESK2 Helpdesk Support Team y SECURITY1 Security Design team y SECURITY2 Security Design team y TEST IDs y USER All end-users y 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. The role definition process will provide a high level of flexibility. Unique use of transactions per role is the preferred approach with duplication of transactions within other roles only when no other alternative is present.<company_name> Security Design For the SAP solutions in <company_name>. queries. Roles will be directly assigned to a user. To align with the internal control requirements and prevent potential deficiencies that can impact an organization.

Page 8 . o Group like functions together into single roles. 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 the appropriate changes and/or modifications to the levels associated with each Role per the testing feedback. Security will collaborate to map task based roles to the specified function in time for UAT Observe best practices where possible: o Limited use of * wildcards for administering roles. 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. the use of wildcards can lead to the granting of unintentional access. Unless there is a thorough understanding of the scope of transactions or field values a wildcard represents.5. Security role builds will utilize the change management controls specified in the GRC Change Management PDD. Security role builds must be transported using the transport process defined. See the Testing Strategy document for specific objectives per testing cycle. o Minimize use of child roles to avoid breakage of parent ± child relationship. o Follow principle of least privilege o Ensure correct naming convention is used. Role owner approval of role definitions and role assignments will be a required output from the testing cycles. 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 Add tcode (s) in alphabetical order to the folder in Role Menu. 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. <company_name> will utilize the GRC RAR simulation functionality to prospectively identify potential SOD risks before role or provisioning efforts are made for ECC. y y y Security Testing A security testing strategy will be coordinated with the overall project testing strategy for the appropriate cycle and type of testing.4. o Identify sensitive data and restrict access to transactions/reports capable of accessing that data. This is a new capability to XXX that will increase role owner visibility and improve work efficiency. User and Role Provisioning Processes Role builds will follow controls defined in the GRC Role Build and Provisioning PDD¶s. 3.<company_name> Security Design y y <company_name> Training will identify the ³to be´ operational job function for job role mapping. 3.

For ECC. y Composite roles reduces visibility within roles. y Limited use derived roles to represent similar job roles. y Single roles containing similar functions/transactions can be more easily added or removed from composite roles. thus simplifying role maintenance. Avoid inserting objects manually. Overview In addition to the general approach for security. 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. Associated security will follow principle of least privilege and will be reviewed in accordance with IT Global Policy.1. tasks are assigned to a role owner having significant functional knowledge of what is required to perform the task.1. 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 y GRC Access Controls best practice y Observance of identified critical sensitive transaction codes ECC will deploy a compliant security build. Access to databases requires approvals as stated in the XXX IT Information Security Policy. therefore limit their use y SOD tools interpret the use of * wildcards for administering roles or authorizations widely which causes issues around SOD and excessive access. Other table access Access to tables can occur at the database layer. As such. y Creation of small task-based roles that are free of SOD violations y Utilization of the GRC RAR for SOD reviews prior to deployment for role and user reviews for SAP ECC security y Roles will be defined based on a task. Single roles containing dissimilar functions/transactions will typically require more analysis to determine whether a transaction can added or removed. The authorization objects that are brought in to the Profile Generator are about 90-95 percent of what is needed to be considered complete. Therefore. Application Specific Considerations SAP ECC ECC is a transactional processing system and most of the action is based on the use of transactions.1. 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. 4. y Use of composite roles will be used where consistency in the combination of roles warrants this structure for maintenance Page 9 Comment [DMD1]: Insert hyperlink to role build Comment [DMD2]: hyperlink . See the detailed security role build. Derived roles are derived from parent roles. y Use SU24 Maintenance process. <company_name> will implement alternative procedures consistent with legacy SOX systems to monitor highly privileged access at the database and server layers.<company_name> Security Design 3. Changes to parent roles automatically transfer to derived roles. 4.6. The ECC build consists of: y Transactions listed within the PDDs or BPPs y RICEF Object and sensitive transaction areas identified by best practice resources. 4.

A user's action is approved only if the user passes the access test for each field listed in an object. roles. transaction codes and authorization objects protect the system from unauthorized access. FB02.1. display. Profiles can be created manually using transaction SU02 and automatically by using SAP Profile Generator.) and what type of processing can be performed with the document (create. The system access to execute the transaction is controlled by the authorization object S_TCODE.). customer payment. User ids. There are approximately 22 object classes used to logically group the SAP supplied authorization objects. putting in the value of FB* can provide the same access but is not recommended anywhere but in the development environment 4.3.2. Roles are created and maintained via transaction PFCG. profiles. All reports or programs for end users to run will be assigned to a transaction. The authorization objects used to secure transactions are dependent on the functional area being executed.<company_name> Security Design y y Use of single roles instead of master roles because derived roles will not be used for org level. Authorization and Field Values An authorization is a set of permissible values that grant system access privileges based upon an authorization object. Fields identify an element of the system that is to be protected by an access test. This means. then these transactions must be specifically stated. Only those people with active user master records can access the system. credit memo. and FB03. 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. that if a user needs access to transactions FB01. System access to execute the transaction 2. The objects are maintained in the table TOBJ and can be viewed via transaction SE16. A user is permitted to perform an action only if he/she Page 10 . Authorization objects can be described as: y Entities defined by SAP which secure or protect transactions. delete. etc.1. 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. y Consists of fields whose values determine the type of access granted for specific transactions. Authority checks within the supporting ABAP/4 program All three of these must be taken into consideration when administering transaction level security. 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 can be processed (invoice. position or role be explicitly defined. Refer to the SAP supplied on-line documentation or an actual client for a detailed listing. Authorizations Objects An authorization object is a template for testing access privileges. 4. Check object for activity to execute the transaction 3. change. This particular object requires that the transactions needed for a user. SAP transactions are secured through three methods: 1. Alternatively. etc.

Values determine the actions that are permissible. generate the new activity group necessary to execute the program 7. When you log on to the ECC6 system. Identify the values necessary to execute the program 4. Therefore. Authority Check in Custom ABAP Much of the data in an ECC6 system has to be protected so that unauthorized users cannot access it. If necessary. objects allow complex. ECC performs authority checks to ensure execution of the code with security considerations. Authorizations must be assigned to simple profiles. etc. 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. Evaluate the need to create new authorization objects or use existing objects 2. SAP scripts. the appropriate authorization is required before a user can carry out certain actions in the system. An authorization check is implemented for every transaction.). to restrict access to specific parts of the organizations data (Company Code.5. Transport the profile and/or activity group across the system client landscape 4. the Security Team and Functional Team will verify that the authority checks are in place and functioning adequately. During the creation process XXX will perform the following when creating new authority checks: 1. the maintenance version is being used. this may be dependent on each client 5. create the new authorization objects and associate them with an existing object class.<company_name> Security Design passes the test for each field in an authorization object. If necessary. Plant. Creating a unique name and assigning values to the fields that are defined for the object create an authorization for an authorization object. Changes to profiles and authorizations have to be ³activated´ or generated before they go in to affect 4. In addition to transaction code. modify. All new objects must be transported across the entire system client landscape 3.4. multi-conditional testing of user access privileges. Example: A G/L account authorization object has two fields to which varying degrees of access can be granted. etc. When creating or editing a profile or authorization. display.1. If using the profile generator.6. In this way. add the transaction code to the SAP ECC Profile Generator using SU24 6.1. If necessary. System Security Parameters Page 11 .) All custom programs. 4. This concept helps prevent errors in defining or editing authorizations from affecting the system. Identify the position or role that should have access to execute this program. the ECC authorization concept includes other authorization objects to secure activities (create. the system checks in the user master record to see which transactions you are authorized to use. and interface routines are required to use appropriate authority checks. Activity and Company Code.1. delete. This authorization would be assigned to a single profile along with the other authorizations required to access G/L accounts. Activation Concept Profiles and authorizations exist in maintenance and active versions in the system. Prior to the configuration and security being transported to the QA system. create the manual authorizations and profiles necessary to execute the program 8.

4. This can be accomplished by using transaction SE38 to execute the ABAP/4 program RSPARAM on each system.<company_name> Security Design The SAP Security Administrator must periodically check the SAP ECC system parameters on each instance. and the default client. SAP has specific default parameters in the system that can be tailored for each instance.1. Review the existing authorization objects to determine the ability to use an SAP supplied object 2. Execute transaction SE93 4. the SAP Security Administrator must verify that the following system parameters are set appropriately. incorrect logon limits. The following is a list of SAP ID and profiles should be restricted: Type Detail Page 12 . You can use these system profile parameters to set password characteristics. create the new authorization object 3. Enter the field level values required Note.8. this information can be manually entered into the table TSTCA via transaction SE16. In the rare circumstance where it is required. The following are the necessary steps to establish a check object for a new transaction 1. The misuse of these transactions within the system could negatively affect the performance and integrity of the system by providing users with powerful rights.9. The following parameters are presented for later review. In nonproduction environments. Powerful ids will not be granted to individuals in production. Enter the authorization object selected to be the check object 6. Segregation of duties and observance of highly confidential information must be taken into consideration in all environments. It is important to understand the risks associated with sensitive transactions. Note: Parameters apply to both the ECC6 and BW systems.1. In particular. Custom Transactions There are two minimum requirements for all new custom transactions: y S_TCODE must be activated y 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. If necessary. SAP has a several powerful userids and profiles that should be monitored closely for appropriate use. Sensitive Transactions There are specific transactions contained within SAP that are considered sensitive and powerful in nature. 4. The security team will make sure those transactions are accounted for in the SAP GRC RAR rule set. 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. GRC SPM controls will be used to allow for a mitigating control of the activity performed. Additional details and recommendation can be found in SAP ECC Security Parameters Table. GRC Process Controls will be used for the IT Basis critical areas for Release 1.7. Sensitive IDs & Profiles In addition to monitoring sensitive transactions.1. 4. Enter the new transaction code and click on the µMaintain¶ icon 5.

See SAP ECC Sensitive Authorization Objects Table.CUSTOMIZ S_A. Some transaction codes do require authorization to some of these objects.USER S_A. At the application Page 13 . 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. XXX will not utilize additional maintenance/assignments at the object or authorization group levels. this language was created by SAP and is the foundation for all functionality in SAP. User making the request Custom programs will be assigned to custom T-codes which will follow the GRC Role PDD requiring these to be incorporated into an ECC role. Access to create.10. Table Security The ability to perform configuration or view raw SAP data requires access to specific tables within SAP. Client where requested Program Security Programs in SAP are written in a standard fourth generation called ABAP/4. maintain and execute ABAP/4 programs will be restricted to those individuals properly trained.TMSCFG S_A. The misuse of these authorization objects within the system could negatively affect the performance and integrity of the system. there are some authorization objects that should be closely monitored. However. The ability to maintain table level data affects the integrity and accuracy of information maintained by SAP. Type of access being requested (display. 4.11. execute) 2. Use of ABAP/4 will follow SAP development standards.<company_name> Security Design Profile SAP_ALL SAP_NEW S_A. Considerations for access will take into account the instance and client needed for compliance purposes.TMSADM S_A.ADMIN S_A. reliability and consistency of the results of the underlying transactional system. These authorization objects are considered sensitive in nature.1. careful consideration should be taken wherever access is granted. 4. maintain.SYSTEM S_A. Restricted Authorization Objects In addition to powerful IDs and profiles with SAP.CPIC S_A. Access to ABAP/4 programs will be granted based on three elements: 1.TMSWF SAPCPIC SAP* DDIC EARLYWATCH ID 4.

14. When the GUI level access is provisioned. 4.1. I.1.<company_name> Security Design layer. As a result. there are two general definitions of tables each having unique security requirements in SAP: client dependent and client independent. authorization groups starting with an µS¶ II. <company_name> 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.15. All SAP basis and security related tables are assigned to an authorization group starting with µS¶. in every client from having access to Basis and Security related tables. 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.13. the following should be followed (transaction SE16 and SM31). This particular object consists of a single field. 02 change and 03 display. There are three basic activities ± 01 create. y y Integration/QA Allow display access to tables There should be no configuration allowed based on client settings III. The critical authorization group that should always be restricted is that starting with µS¶. which a value of ³X´ grants a user the ability to configure/maintain client independent tables. When making changes to client dependent tables/data. When making a change to a client independent table (T000). Role Build Sequential Process Page 14 . you only impact the client that you are currently logged into when making the changes. 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. y y y y Development Instance Limited table access to the user allowed to perform configuration Within the ABAP client. Table Query Security SQVI table queries provide powerful SE16 like access into ECC tables which can result in negative system performance. 4. y y y Production Display only No configuration allowed based on the client settings Functionality within the Profile Generator is considered configuration and may require special procedures 4. Table Authorization Object Security Client dependent table access is controlled through the SAP supplied authorization object S_TABU_DIS with two fields: activity and authorization group.1. The SAP 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. you impact every client within that particular instance.

the user will only see the menu for the access that has been granted via the assigned role. etc) will not be integrated into the design and therefore will also not be built into BW.1. As a data warehouse. 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). BW users can be thought of in three broad groups. 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. company.e. but not to restrict similar content. 4. These groups are aligned with the nature of their required BW usage according to their job responsibilities. Once the Role has been created and users assigned to that role. The security structure for BW is intended to restrict normal functionality where it is important to protect the integrity of the results. The first group consists of those who go into the BO system accessed through BO infoview to display or execute reports that have been created for them (End Users or Report Users).. Roles often correspond to job titles. 4. This group generally consists of Basis and Security Administrators.2. A role in BW typically identifies a collection of reports and queries for a specific business area. the process used included«. This type of specification gives access to all of the data housed in the InfoArea(s) or InfoCube(s) specified.<company_name> Security Design In order to develop the detailed role build matrix used as the foundation for develop security roles. it does not use transactions the way that ECC does but instead uses three primary types of restrictions to secure reports.. For EX: GL Users will have access to GL cubes. authorizations are generated to enable access to the Business Warehouse. 4. When the user logs into the Business Warehouse environment. The simplest way to give access to the End Users is by info provider. Roles are associated with tasks and include all activities that are carried out by the respective users.2. BW/BOB J The BW system is an analytical processing system that performs complex calculations on data stored in it.2.2. . Overview BW roles can be restricted by the BW structural elements ± InfoAreas and InfoCubes. The vast majority of XXX¶s BW end users will never directly logon to the BW system using the SAPGui but will login from the BOBJ front end. 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 third group consists of those who will administer the BW system. plant. Page 15 . Both End Users and Power Users will be assigned to one or more specific role as required by their XXX responsibilities. organization level (i. To be consistent with the overall Security Strategy.

4.2.3. All InfoCubes attached to any of these authorization objects require special consideration. 4.5. change and display queries and reports both for themselves and others in their department. SAP GRC <company_name> will implement the following SAP GRC Modules during Release 1: y SAP GRC Risk Analysis and Remediation (RAR) y SAP GRC Super User Privilege Management (SPM) y SAP Process Controls (PC) Page 16 .6. SAP BOBJ Security Authorizations Objects Authorization and Field Values Authority Check in Custom ABAP Activation Concept System Security Parameters 4. 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. developers should be aware of the defined authorization relevant InfoObjects. BW Authorization Objects 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.9. 4.2. BW Reporting Roles The 2 main groupings will be called Menu Roles and Security Roles. There are no authorization profiles defined for menu roles.2. 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.2.4. 4. 4. 4.<company_name> Security Design Power User roles will also need to be defined with the ability to create. The menu roles will define the folders that users will see (in addition to their favorites). The different security roles may be defined to allow access to an Infoprovider. Defining security for BW users becomes a simple exercise of combining the appropriate Menu and Security roles. When developing report queries. 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.

Risk Analysis and Remediation can be used to identify. UME roles will be assigned to users based on need. See the GRC Role Build.1.3. y Front-end Roles .Front-end roles grant application rights to configure and run the tool y Back-end Roles .<company_name> Security Design All modules will have a small number of users. it is leading practice to copy the standard GRC UME roles into custom UME roles to prevent any issues related to GRC upgrades. Subsequent releases of RAR may include Complaint User Provisioning (CUP) and Enterprise Role Management (ERM). 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. The typical roles and functions assigned for RAR include administrator. analyze.3. control monitor and SOD reporting by using standard UME RAR roles including VIRSA_CC_ADMINISTRATOR.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 SAP User Management Engine (UME) for the front-end roles. and resolve all SoDs and audit issues relating to regulatory compliance. See the GRC Strategy & Design Document. For Release 1.2. Administrator rights for will be restricted to just a few individuals. fully automated security audit and segregation of duties (SoD) analysis application. Overview There are 2 different types of roles needed for GRC ± Front-end and Back-End Roles. For business users of each tool. ERM is typically just used by basis/security users to help build security using pre-defined leading practices. At a minimum the main users for GRC are as follows: Function System Administrator SOX Finance Internal Audit Role Owners Firefighter Support Modules All All All RAR SPM Level of Access Full Read Read SOD/CUP TBD based on function 4. XXX will not deploy these features of RAR. It provides the largest and most comprehensive database of SoD rules available for SAP. GRC comes with preconfigured UME roles which contains various UME actions. XXX will use out of the box GRC roles. Customization of these roles is typically not needed. VIRSA_CC_SECURITY_ ADMIN. GRC RAR XXX¶s GRC Risk Analysis and Remediation is a web-based. Page 17 . UME provides a portal like security. Security Admin. However. Comment [DMD3]: Diane hyperlink 4. CUP may have hundreds of users depending on the configuration since CUP is a tool that helps provide automation for user provisioning process. security rights with update capability will be given based on just on the functions that each user actually needs to complete his/her job. Where possible.

2.3.8. The typical roles and functions assigned for SPM include SPM User role. 4. 4.4.7. See the GRC Configuration Document. 4. SPM provides the solution for systematic handling of all emergency situations in a controlled and auditable environment. 4. Text SAP Solution Manager Comment [G5]: Ramesh to hyperlink ± Update : The document is in progress (not yet ready) Comment [DMD6]: Scott Rolfs to do 4. GRC SPM Super User Privilege Management enables users to perform emergency activities outside their role as a ³privileged User´.4.1.4.<company_name> Security Design VIRSA_CC_REPORT and VIRSA_CC_BUSINESS_OWNER and custom roles will be made (if required). 4. Authorizations Objects Authorization and Field Values Authority Check in Custom ABAP Activation Concept System Security Parameters GRC configuration will follow best practice and minimization of customizations. 4.5. 4.4.3. Default settings will be evaluated to ensure associated risks are being managed in according with <company_name> Control requirements. 4. Overview Authorizations Objects Authorization and Field Values Authority Check in Custom ABAP Activation Concept System Security Parameters Page 18 .4.6. GRC PC Comment [DMD4]: Protiviti to advise 4. text . SPM Owner role and SPM Administrator role. 4. 4.

If a Role contains more than 150 authorizations. Overview Authorizations Objects Authorization and Field Values Authority Check in Custom ABAP Activation Concept System Security Parameters 4.6. 4.5. Text Vertex Comment [DMD7]: Bill to provide 4. A group of up to 150 authorizations that are automatically generated via the Profile Generator.1. 4. Text Process Integration (PI) 4.5. Terminology A set of authorization object specific values that allow a user to perform certain functions within the XXX system.5. Values used to define an authorization for an authorization object A system template for authorization that relates to a particular system object. 4.3.2. 4. more than one profile is generated Authorization Authorization fields Authorization object Authorization profile Page 19 .<company_name> Security Design 4.6. 4.4.5. Authorization objects consist of fields for specific values relating to certain data or activity with that data.5. 4. 4. Overview Authorizations Objects Authorization and Field Values Authority Check in Custom ABAP Activation Concept System Security Parameters Comment [d8]: Michael wei to fill in something 4.1.6. 4.

Composite Roles may be directly assigned to user ids. and is responsible for the security administration process. but should be restricted to data for their own division. and reports that they own. A security profile is a collection of Authorization Objects and Authorizations Values. y The Global Service Center (GSC) . 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. If a role is to be used for multiple divisions where each clerk would perform the same functions. a role will be derived from the Master role. reports. and transactions. Create Vendor) and may be used as a template.first line of support and the focal point for receiving security requests and problems. A particular task or job may consist of one or more profiles Member of the Technical Services team. Single Roles consist of authorization profiles. these do not have authorizations or profiles directly assigned to them.g. which are generated using the Profile Generator tool. May be created for a generic job role (e.g. A member of the ICC is responsible for establishing the security strategy. Application support having three primary pieces. Roles can be directly assigned to user ids. Functional Team Governance Risk and Compliance (GRC) Team Profiles Role Role-Composite Role-Master Role-Simple Role Owner Security Roles Security Team System Support Page 20 . related designs and establishing the associated administration processes. As such. Consists of a collection of single/individual roles grouped together. A business representative assigned with responsibility for certain roles and the assignments of those roles to end users for a functional area. Member of the core development team. tables. with responsibility for a specific functional area and specifying security requirements from a business perspective. such as tasks.<company_name> Security Design Data Owner The data owners are responsible for protecting (controlling access to) the transactions. The GSC handles the initial contact with end users for all support requests and provides ticketing and escalation support. Accounts Payable Clerk) or task based roles (e. A security role is a collection of linked or associated activities. GRC strategy. Single roles consist of one or many authorizations that are required by the SAP system in order to perform transactions (single profile).

Access is defined based on job responsibilities. route requests to appropriate queues based on escalation process flows and provide assistance regarding Basis Administrators perform critical application functions except configuring users. Access is further restricted based upon segregation of duties restrictions identified by ICC.. These users have access to perform ABAP functions and full access to all needed SAP transactions. User groups enable security administration of users within the specified user group Each user has a unique user account called a master record. Support personnel diagnose and document user access issues. User Id User group Represents the User Identification in the XXX system. and other often used system parameters such as printer preferences. address. surname.<company_name> Security Design y XXX SAP Support (Support) provides technical information or support. Application users that can log on to specific application Have functional access based on transactions and hierarchy. profiles and authorizations. stage). tables and client independent tables to complete their job function on a day-to-day basis. User Id¶s are required to log on to XXX systems User groups facilitate the process for user reporting within the XXX system. The user master record is automatically associated with a userid. User master record Page 21 . positions within XXX¶s organizational structure and environment utilization (i. A user master record contains a user¶s personal data such as name. production vs. y <company_name> Internal Controls and Compliance (ICC) User-Dialog User-End Responsible for monitoring that XXX practices are followed and that XXX information resources are properly protected.e. system access rights. troubleshoot user access issues. etc.

6. A A A R. Tables Security RACI Chart Role Owner Data Owner GRC Team Functional Team Security Team Task ICC Establish security review activities Design security builds Configure/Modify security builds Ensure critical activities are not combined.<company_name> Security Design 6. Provision users for <company_name> components and environments. A R.A A A I I C R R R R I I I R R C R I I I R R C R R I I I C C R R R I C I R R C C I A A A R. A R. A R R A I I C I I 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 Define and document security and GRC architecture Review the design documents for completeness of Security and GRC requirements Provide system administration knowledge for post release administration Support Security Testing resolution Specify business needs for access to area Define navigation expectations impacted by security design Understand security capability to area of responsibility Assign access to user for area of responsibility Security tests results successful Role training Access Reviews A A A R R R. A I A A I R C I I I I I I C I I I C Page 22 System Support . A A A R. Security is compliant with XXX policies.1. Identify potential compliance issues Assist the security team in preparing for an audit. A R.

The typical approach is to permit three attempts. The parameter should be set to 1. For XXX. The SAP default is zero. the setting will be 3 times Defines whether user locks due to unsuccessful logon attempts should be automatically removed at midnight. You can set it to any value from 3 to 8. The minimum length will be set to 6 characters. password ³PASS´. The SAP default is 12 and can be set to any value between 1 and 99. If the parameter is reset to 0. This client is automatically filled in on the system log on screen. Using transaction SM30 and maintaining table USR40.) For XXX. and unrestricted system access privileges. the setting will be 3 times This parameter is used to specify the number of times that a user can enter an incorrect password before the system locks the user against further logon attempts. 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. ECC Security Parameters Description This parameter is used to specify the minimum length of a password. The SAP default is 3 and can be set to any value between 1 and 99. the setting will be 8 characters This parameter is used to specify the number of days after which a password must be changed. For XXX. it would allow logins with SAP*. Users should be required to periodically change their password every 30 days. which never requires the user to change their password. USR40 is a table with impermissible values. The Default is three characters. For XXX.2. the setting will be set to no=0 This parameter is used to specify the default client. This parameter is used to restrict special default properties for SAP*. SAP also provides a mechanism for additional customization of password restrictions. For XXX. Table USR40 is used during logon validation procedures and password checking to make sure the password does not violate any of the guidelines. A 6. Users can type in a different client. Parameter login/min_password_ln g login/password_expira tion_time login/fails_to_session_ end login/fails_to_user_loc k login/failed_user_auto _unlock login/system_client login/no_automatic_us er_sap* Page 23 . the setting will be 90 days Defines the number of unsuccessful logon attempts before the system does not allow any more logon attempts. password restrictions for acceptable values may be implemented.<company_name> Security Design Validate accuracy of content C I R.

The default is 12. but this results in a big security risk for the system. the parameter should be set to value Y. the function is inactive and the parameter value is N. the parameter should be set to value Y. System Profile Parameters XXX Values PARAMETER DESCRIPTION SAP Default 3 12 1 Prod DEV 4 6 0 QA 4 6 0 Login/fails_to_session_end Number of times a user can enter an incorrect password before the system terminates the logon attempt. the function is inactive. By default. Specifies the default client. This parameter is used to enable SU24 to activate authorization checks for transactions and to work with the Profile Generator.<company_name> Security Design rdisp/gui_auto_logout This parameter is used to specify the number of seconds before automatically disconnecting inactive users from the system. External security activated This parameter is used to check on object S_TCODE. In certain cases. and the parameter value is N. Users can overwrite this. To activate. this can be shut off. By default. Transaction codes that can run without the proper authorization. This time represents the number of seconds. To activate.3. Number of times a user can enter an incorrect password before the system locks the user against further logon attempts. The SAP default for all instances is 0 and each instance may require a higher setting. Examples maybe SU53 and SU56 that helps analyze authorization failures when a user can¶t run a transaction auth/no_check_in_som e_cases login/ext_security auth/no_check_on_tco de Auth/tcodes_not_chec ked 6. Default is 3. Enable automatic unlock of locked users at 3 Login/fails_to_user_lock 3 Login/system_client 100 Login/failed_user_auto_unlock 0 Page 24 . The lock is released at midnight. This client is automatically filled in on the system logon screen.

Specifies the number of seconds a user session can be idle before being automatically logged off by the system.PFL Page 25 . it would allow logins with SAP* using the default delivered password and unrestricted system access privileges. Default is N. you set them in the profiles of each application server in your SAP 1 Auth/check_value_write_on DEFAULT. Disables special properties for user SAP* when this parameter is set to a value greater than zero. Default is 1 ± allowed Login/min_password_lng Minimum length of a password. 6 Login/password_expiration_time 60 Login/no_automatic_user_sap* 1 Rdisp/gui_auto_logout 900 auth/no_check_in_some_cases Y auth/no_check_on_tcode Checks on object S_TCODE.8. Default is 0 Used to enable SU24 to activate authorization checks for transactions and to work with the Profile Generator. N this can be shut off. the user is asked to enter a new password. To make them instance-specific. The default is 0 . Do not change unless absolutely necessary. when this parameter is set to a value greater than zero. Default is 3. When the expiration time is reached. Enables the transaction for authorization analysis SU53. This is highly recommended as it is the key to determining and resolving SAP ECC6 authorization issues and is essential for Security Administrators To make the parameters globally effective in a SAP system. When the parameter is reset to 0. Default is N. Default is '0' . See Security Strategy document for details. set them in the default profile. SAP also provides a mechanism for additional customization of password restrictions. Any values from 2 .permitted. In certain cases. but it results in a big security risk for the system.<company_name> Security Design XXX Values PARAMETER DESCRIPTION SAP Default 3 0 0 0 N N Prod DEV 6 90 1 1800 Y N 1 QA 6 90 1 1800 Y N 1 midnight. Number of days after which a password must be changed.no time limit.

off. Hold user session information after session termination.<company_name> Security Design XXX Values PARAMETER DESCRIPTION SAP Default 0 Prod DEV Y 1 QA Y 1 system. Auth/authorisation_trace Enables easier diagnosis of security failures since allows running of System Trace (transaction ST01). Default is '0' . Set to the value of '0' if preventing multiple dialog logons Y login/disable_multi_gui_login 0 Rdisp/gui_cleanup_delay 0 Page 26 . Disable multiple sapgui logons (for same ECC6 account).

Permits ABAP development. SM31 or SE16.<company_name> Security Design 6. Help desk should have lock / unlock and password change ability. µActivity¶ field is critical. Page 27 S_CTS_ADMI S_DATASET S_DEVELOP S_IMG_ACTV S_LOG_COM S_PROGRAM S_QUERY S_TABU_CLI S_TABU_DIS S_TCODE S_TRANSPRT S_NUMBER S_USER_AGR S_USER_AUT S_USER_GRP . Only Security Administration should have all access rights for this object. SAP ECC Sensitive Authorization Objects SAP Standard Authorization Object S_ADMI_FCD S_BDC_MONI S_BTCH_ADM S_BTCH_ADM 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. The value 02 . this object should be used with authorization groups for tables. Access to perform administration functions in transport system Only certain programs should be allowed to access data files. 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. Authorization Administrator can specify authorization groups by using SE54. This can be achieved by using authorization groups defined by developers. This object is only granted with display ability. This object should be only used with display ability. If a user has access to transactions SM30.4. Access to transport system Number Range maintenance Ability to maintain and display roles Ability to display profiles and their change history.change access should be granted with special care and authorization from the process owner and system owner. but instead it should have the definition of transaction that the user needs to perform. Authorization for SAP Queries Ability to maintain client independent tables Ability to display or change tables. For those a system trace ST01 has to be performed in DEV QA. When this object is used most roles should have limitation only to the specific program or report node that is necessary to call. and it should never be used without authorization groups Access rights to start transactions and should never have value µ*¶ All for end users. Ability to display changes to all user master data. Often this object is used in custom transactions (starting with µZ¶). Only the PA Administration and Security Administration should have the change ability. The field ABAP: program name should be limited to the program name.

Only Security Administration should have all access rights for this object.<company_name> Security Design SAP Standard Authorization Object S_USER_OBJ S_USER_PRO Description Ability to globally deactivate authorization objects Ability to display profiles and their change history. Page 28 . This object should be only used with display ability.

Sign up to vote on this title
UsefulNot useful