You are on page 1of 28

<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

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

guidelines and standards. 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.1. Both the production and non-production environments are considered within the scope of the security and GRC teams. 1. 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 systems will be maintained and secured following existing procedures. 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. 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. Scope This document refers to the Security concept within the <company_name> solution for end users. y y y Introduction This document is to describe the overall SAP Security Design that will be adopted for XXX SAP systems. 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. Business Process Controls Strategy. 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. Page 4 .<company_name> Security Design 1. This design supports the configured business processes within the XXX SAP system.

<company_name> Security Design Page 5 .

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

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

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. 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. 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. This is a new capability to XXX that will increase role owner visibility and improve work efficiency. Security testing will consist of: Unit Testing Integration Testing User Acceptance Testing During each phase. 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. o Identify sensitive data and restrict access to transactions/reports capable of accessing that data. 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. 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.4. 3. o XXX will use the default profile names which start with t. o Add tcode (s) in alphabetical order to the folder in Role Menu. Page 8 . Unless there is a thorough understanding of the scope of transactions or field values a wildcard represents. User and Role Provisioning Processes Role builds will follow controls defined in the GRC Role Build and Provisioning PDD¶s.5. 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. 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. 3. o Group like functions together into single roles. the use of wildcards can lead to the granting of unintentional access. o Follow principle of least privilege o Ensure correct naming convention is used. o Minimize use of child roles to avoid breakage of parent ± child relationship. <company_name> will utilize the GRC RAR simulation functionality to prospectively identify potential SOD risks before role or provisioning efforts are made for ECC.<company_name> Security Design y y <company_name> Training will identify the ³to be´ operational job function for job role mapping.

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. 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. Single roles containing dissimilar functions/transactions will typically require more analysis to determine whether a transaction can added or removed. Changes to parent roles automatically transfer to derived roles. 4. Avoid inserting objects manually.1.1. y Limited use derived roles to represent similar job roles. y Composite roles reduces visibility within roles. Therefore. tasks are assigned to a role owner having significant functional knowledge of what is required to perform the task. thus simplifying role maintenance. Overview In addition to the general approach for security. Associated security will follow principle of least privilege and will be reviewed in accordance with IT Global Policy.<company_name> Security Design 3. As such. y Single roles containing similar functions/transactions can be more easily added or removed from composite 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. See the detailed security role build. 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. Derived roles are derived from parent roles. 4. 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. 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 .6. The authorization objects that are brought in to the Profile Generator are about 90-95 percent of what is needed to be considered complete. 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. Application Specific Considerations SAP ECC ECC is a transactional processing system and most of the action is based on the use of transactions. 4. Other table access Access to tables can occur at the database layer. For ECC.1. 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 system access to execute the transaction is controlled by the authorization object S_TCODE. etc. position or role be explicitly defined.3. putting in the value of FB* can provide the same access but is not recommended anywhere but in the development environment 4. Check object for activity to execute the transaction 3. Roles are created and maintained via transaction PFCG.). FB02.) and what type of processing can be performed with the document (create. roles.2. display. profiles. 4. Example: an authorization object for securing accounting documents identifies the type of document that can be processed (invoice. Fields identify an element of the system that is to be protected by an access test. A user's action is approved only if the user passes the access test for each field listed in an object. credit memo. and FB03. Profiles can be created manually using transaction SU02 and automatically by using SAP Profile Generator. etc. The objects are maintained in the table TOBJ and can be viewed via transaction SE16. System access to execute the transaction 2.1. User ids. There are approximately 22 object classes used to logically group the SAP supplied authorization objects. y Consists of fields whose values determine the type of access granted for specific transactions. then these transactions must be specifically stated. 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. SAP has pre-defined sets of authorization objects for each of the SAP modules. transaction codes and authorization objects protect the system from unauthorized access. 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. A user is permitted to perform an action only if he/she Page 10 . SAP transactions are secured through three methods: 1. The authorization objects used to secure transactions are dependent on the functional area being executed. customer payment. Authorizations Objects An authorization object is a template for testing access privileges. Authorization objects can be described as: y Entities defined by SAP which secure or protect transactions. This means.<company_name> Security Design y y Use of single roles instead of master roles because derived roles will not be used for org level. Alternatively. Authority checks within the supporting ABAP/4 program All three of these must be taken into consideration when administering transaction level security. change.1. Refer to the SAP supplied on-line documentation or an actual client for a detailed listing. Authorization and Field Values An authorization is a set of permissible values that grant system access privileges based upon an authorization object. that if a user needs access to transactions FB01. 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. This particular object requires that the transactions needed for a user. delete.

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

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

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

1. When making a change to a client independent table (T000). 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. 4.1. you impact every client within that particular instance. There are three basic activities ± 01 create. in every client from having access to Basis and Security related tables. 02 change and 03 display. y y Integration/QA Allow display access to tables There should be no configuration allowed based on client settings III. Table Query Security SQVI table queries provide powerful SE16 like access into ECC tables which can result in negative system performance. 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. 4. As a result.15. Granting access to configure/maintain client independent cross client should be properly approved and review by the Basis team. Access to ECC queries will be limited based on critical business need. <company_name> will deploy reporting solutions for adhoc query that may involve other tools than ECC where performance can be better controlled. I. Role Build Sequential Process Page 14 . authorization groups starting with an µS¶ II.<company_name> Security Design layer. This particular object consists of a single field. 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. All SAP basis and security related tables are assigned to an authorization group starting with µS¶. there are two general definitions of tables each having unique security requirements in SAP: client dependent and client independent. y y y y Development Instance Limited table access to the user allowed to perform configuration Within the ABAP client. the following should be followed (transaction SE16 and SM31). When making changes to client dependent tables/data. you only impact the client that you are currently logged into when making the changes. The SAP supplied authorization object S_TABU_CLI controls access to client independent (cross client) tables. 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. When the GUI level access is provisioned. which a value of ³X´ grants a user the ability to configure/maintain client independent tables.1.14. The critical authorization group that should always be restricted is that starting with µS¶.13.

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

3.10. Defining security for BW users becomes a simple exercise of combining the appropriate Menu and Security roles.2.2. BW Reporting Roles The 2 main groupings will be called Menu Roles and Security Roles.<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).2.2.5. SAP BOBJ Security Authorizations Objects Authorization and Field Values Authority Check in Custom ABAP Activation Concept System Security Parameters 4.7. 4. 4. 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. 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. 4.2. 4.4.2. 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 .2.8. 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. 4.3. 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. When developing report queries. 4. 4.6. There are no authorization profiles defined for menu roles. The different security roles may be defined to allow access to an Infoprovider.2. developers should be aware of the defined authorization relevant InfoObjects. All InfoCubes attached to any of these authorization objects require special consideration.9. change and display queries and reports both for themselves and others in their department.

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

3.2. Default settings will be evaluated to ensure associated risks are being managed in according with <company_name> Control requirements. 4. 4.4. 4. 4. 4.8. SPM provides the solution for systematic handling of all emergency situations in a controlled and auditable environment. SPM Owner role and SPM Administrator role. See the GRC Configuration Document. 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 GRC SPM Super User Privilege Management enables users to perform emergency activities outside their role as a ³privileged User´.4.<company_name> Security Design VIRSA_CC_REPORT and VIRSA_CC_BUSINESS_OWNER and custom roles will be made (if required). 4. 4. Overview Authorizations Objects Authorization and Field Values Authority Check in Custom ABAP Activation Concept System Security Parameters Page 18 . GRC PC Comment [DMD4]: Protiviti to advise 4.7. 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. text .5.3.9. 4.3.3. The typical roles and functions assigned for SPM include SPM User role.

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

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

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

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. 6. Identify potential compliance issues Assist the security team in preparing for an audit. Provision users for <company_name> components and environments. A R. 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 A A R. A R R A I I C I I 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. A A A R. A R. Security is compliant with XXX policies. A I A A I R C I I I I I I C I I I C Page 22 System Support .1.

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

and the parameter value is N. 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 default is 12. 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 lock is released at midnight. the function is inactive. This client is automatically filled in on the system logon screen. This parameter is used to enable SU24 to activate authorization checks for transactions and to work with the Profile Generator. The SAP default for all instances is 0 and each instance may require a higher setting. the parameter should be set to value Y.<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. To activate. the parameter should be set to value Y. External security activated This parameter is used to check on object S_TCODE. Number of times a user can enter an incorrect password before the system locks the user against further logon attempts.3. Users can overwrite this. This time represents the number of seconds. By default. Transaction codes that can run without the proper authorization. To activate. 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. By default. the function is inactive and the parameter value is N. but this results in a big security risk for the system. In certain cases. Specifies the default client. this can be shut off.

SAP also provides a mechanism for additional customization of password restrictions. but it results in a big security risk for the system. Default is N. In certain cases. Specifies the number of seconds a user session can be idle before being automatically logged off by the system. Default is N. The default is 0 . the user is asked to enter a new password. Default is 1 ± allowed Login/min_password_lng Minimum length of a password. When the parameter is reset to 0.PFL Page 25 .8. you set them in the profiles of each application server in your SAP 1 Auth/check_value_write_on DEFAULT. Default is '0' . N this can be shut off. When the expiration time is reached. Default is 3. Enables the transaction for authorization analysis SU53.permitted. when this parameter is set to a value greater than zero. it would allow logins with SAP* using the default delivered password and unrestricted system access privileges. Do not change unless absolutely necessary. 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.<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 time limit. Default is 0 Used to enable SU24 to activate authorization checks for transactions and to work with the Profile Generator. Number of days after which a password must be changed. To make them instance-specific. 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. Disables special properties for user SAP* when this parameter is set to a value greater than zero. set them in the default profile. See Security Strategy document for details. Any values from 2 .

off. 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 . Auth/authorisation_trace Enables easier diagnosis of security failures since allows running of System Trace (transaction ST01).<company_name> Security Design XXX Values PARAMETER DESCRIPTION SAP Default 0 Prod DEV Y 1 QA Y 1 system. Default is '0' . Hold user session information after session termination. Disable multiple sapgui logons (for same ECC6 account).

but instead it should have the definition of transaction that the user needs to perform. this object should be used with authorization groups for tables. Only Security Administration should have all access rights for this object. Help desk should have lock / unlock and password change ability. When this object is used most roles should have limitation only to the specific program or report node that is necessary to call. 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. Authorization Administrator can specify authorization groups by using SE54. µ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. Only the PA Administration and Security Administration should have the change ability. Often this object is used in custom transactions (starting with µZ¶). SM31 or SE16. This object is only granted with display ability. This can be achieved by using authorization groups defined by developers. The value 02 . Access to transport system Number Range maintenance Ability to maintain and display roles Ability to display profiles and their change history. 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. The field ABAP: program name should be limited to the program name.<company_name> Security Design 6. 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 . 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. Permits ABAP development. This object should be only used with display ability. If a user has access to transactions SM30. Access to perform administration functions in transport system Only certain programs should be allowed to access data files.4.change access should be granted with special care and authorization from the process owner and system owner.

<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. Only Security Administration should have all access rights for this object. Page 28 . This object should be only used with display ability.