1. Should we generate a Role Matrix or inform functional people to get it done for us in an Excel Sheet?

Can any one please share this document? Ans: In an implementation project, Security team creates a role matrix for all the development / implementation consultants for the project like ABAP developer, Functional Consultant, Configuration Consultant, Security Consultant, Basis Consultant, Development leads, Functional Leads. In this matrix all the necessary development/configuration/display roles are identified and listed. All the dev/config/change roles are for DEV/QA systems but not for PROD system. The consultant should have display roles only in PROD systems. All the consultants can give you the list of t-codes required for their roles. Initially all dev/config roles have wider access. After getting the list of t-codes, you need to create all these roles for the dev/config/ABAP/basis/security teams, so that they can start their activities. For creating these roles, you can create a security user ID with SAP_ALL profile assignment. Later, once the roles are create, Security user ID can be assigned the security role you just created. In most of the projects, the workshops are done with the Key Business End_Users and Functional Leads to identify the t-codes required for creating the task based roles. Security team also plays a big role in these workshops in security roles requirement gathering. All these t-codes are listed in spread sheet with their end_user/task/job name, which will be used later for roles creation. 2. After installation of SAP ECC system, do we {SAP Security team members] need to change any of the Clients [000, 001, 066] or User Id's [SAP*, DDIC, EARLYWATCH] ? Ans: Basically this activity is done by the basis team, and the Basis team only creates a development client in the ECC system. And after that Security team starts working in the development client. 3. How to decide the creation of single, composite and derived roles > Also the naming conventions for any of these roles? [Would Business inform us ?] Ans: Initially all the business role are created as template single roles with the identifiable naming conventions like ZE_MM_XXXX_YYY_MM_Display Material Management Display where, _ (1-char) [under score] spacer for separation Z (1-char) identifies customized role (e.g. Z transportable, Y non-transportable) E (1-char) identifies system (e.g. E for ECC, B for BE, H for HRM, S for SRM) MM (2-char) identifies the functional area/module (e.g. MM/SD/FI/CO/BC/PP) XXXX (4-char) identifies the company codes (for company code specific roles) YYY (2/3-char) identifies the divisions (for division /company code specific roles) MM_Display (variable char, 15/16-char max) for role name/description Note: the max length of role is 30 Characters only. The role text description you can give as per overall role task/activities. Once the template roles are created for the 4. Should we make use of SU24 and SU25 settings or copy USOBX and USOBT tables to customer tables USOBX_ C and USOBT_C ? Ans: SU24 is used to update the Authority Check status for the objects in the transactions. If while executing some t-code, the SU53 says any object value is missing, and if the object is not available in the role, then we have to add/update the object for authority check as Y using SU24. All the t-codes and the objects checked/assessed in those t-codes are available in the USOBX/T tables. Using SU25, we copy the USOBX/T into the customer tables

USOBX/T_C table and also all the newly created customized t-codes/objects are added to the customer table. 5. Who will provide us with authorization objects and its values [if needed to be added manually] ? Ans: The table USOBX/T and USOBX/T_C gives the t-code and authorization objects listing. There are generally 2 fields associated with each authorization objects, one is activity and another one is the actual restricting assess field on which the ACTVT (activity) will be applied which may be orglevel field or any other business object. The values depends upon the requirements of that role. If this role is for display the ACTVT (Activity) fields should be given the Display 03 only, if it is for create/generate then ACTVT -01, and if it is for change then ACTVT -02 should be given. Note: initially you can keep the unknown values as empty fields, and generate profiles. All these values will be identified in the Unite Testing of each role subsequently, by the function testers. They will provide the SU53 screen to identify the value required for this object. 6. Any changes to profiles [default / instance] using RZ10 or RZ11 ? Ans: The basis team does this task of setting the security profile parameters, but you can always give your suggestions if you need some changes in any of the parameter values. 7. Do we need to analyze users with critical authorizations [if there is no SAP GRC tool] ? Ans: yes, but not at the time of development, we do this at testing or before golive, because at that time only you will be creating the users and doing the roles assignment. Note: The roles with change authorizations should not be given into the PROD system to any of the dev/config/ABAP/Security/Basis consultants. That is why all display roles are created for these consultants for PROD system. 8. Make use of Security logs [SM20] ? Ans: SM19 and SM20 is used for audit purposes for tracking the changes directly in the production system after the golive. Yes, basis/security team does this tasks. 9. Responsibilities and Their Corresponding Authorizations : for eg changes to PRD systems should not be the responsibility of one single person ? Ans: For direct changes to production system, there is always a CCB (Change Control Board) for reviewing the change requirements from client side. Upon approval only these changes are done. Otherwise all the changes are carried out from development system, tested in quality system and on approval only these are promoted to productions system. 10. Protect the tables for maintaining clients ? Ans: The changes can be done to the system, if the system is open for the changes. This task is done by the Basis team. All the tables are restricted at object S_TABU_DIS Authorization Group level for user of SM30 for table maintenance. 11. Background Processing Security [S_BTCH_JOB, S_BTCH_NAM, S_BTCH_ADM, S_RZL_ADM] ; Print / Spool Security [S_APO_ACT, S_SPO_DEV, S_ADMI_FCD] ; Access to OS; Desktop Downloads [S_DATASET]; RFC Communications [S_RFC].

Ans: There is generally a General Role for all End User is created. This role gives the nonrestrictive general basis t-codes authorizations, which are required for printing, normal workflows, batch jobs etc. Identify such t-codes which are needed by every one, put them together and create a general role. Specific objects values are identified in SU53 for values/restrictions. Once you have SU53, you can add/update the required objects with values in roles.