text:
More Topics
Creator's Hub
Collect Leads
Get Started
Tips & Tricks
For Business
Sap security-administration
Upcoming SlideShare
Loading in...
Like this document? Why not share!
by techgurusuresh
5366 views
SAP Security important Questions
by Ragu M
14541 views
Introduction to SAP Security
by Symmetry
80056 views
Practical guide for sap security
by Siva Pradeep
8843 views
sap security interview_questions
by sumitmsn2
9791 views
Introduction to SAP Security
by Nasir Gondal
6145 views
Share SlideShare
Email sent successfully!
Size (px)
Start on
Show related SlideShares at end
WordPress Shortcode
Sap security-administration
surya nanda
Published on
Dec 06, 2013
Published in:
1 Comment
Full Name
Comment goes here.
12 hours ago
Are you sure you want to
Your message goes here
rajesh rajesh
Hi Sir, you provided great info on SAP it is interesting and useful for the starters, i feel it is right place to get info, thanks for the info and keep posting more. sap sd online training
6 months ago
Are you sure you want to
Your message goes here
Biv Ramlukan
PeopleSoft Security Consultant
Codec Lab Inc.
3 weeks ago
Avinash Yeddanapalli
2 months ago
3 months ago
5 months ago
Fun Go
1 year ago
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
No embeds
No notes for slide
Transcript of "Sap security-administration"
1. ABC Corp Corporation SAP R/3 Security SAP R/3 Security Administration Standard Operating Procedures Page 1 of 59
ABC Corp Corporation SAP R/3 Security 1. OBJECTIVE...........................................................................................................................................................................5 2. ABC CORP SAP R/3 SECURITY STRATEGY................................................................................................................5 3. SCOPE.....................................................................................................................................................................................5 4. APPROVAL PROCESS........................................................................................................................................................5 5. SECURING SAP CLIENTS AND SYSTEMS....................................................................................................................6 5.1 CLIENT OWNERSHIP.................................................................................................................................................... 6 5.2 DEVELOPMENT ROLE DEFINITIONS............................................................................................................................. 6 Security Administrator..........................................................................................................................................................6 Basis Administrator..............................................................................................................................................................6 ABAP/4 Developer................................................................................................................................................................6 Functional User ...................................................................................................................................................................7 Client Independent Configurator.........................................................................................................................................7 Client Dependent Configurator............................................................................................................................................7 Configurator.........................................................................................................................................................................7 5.3 SYSTEM SECURITY..................................................................................................................................................... 7 Sandbox.................................................................................................................................................................................7 Development (Dev2 010, 100)..............................................................................................................................................7 Training.................................................................................................................................................................................8 Integration............................................................................................................................................................................8 Production.............................................................................................................................................................................9 5.4 THE TRANSPORT SYSTEM........................................................................................................................................... 9 6. USER GROUP SECURITY...............................................................................................................................................11 7. NAMING CONVENTIONS................................................................................................................................................12 7.1 SAP R/3 PROFILE GENERATOR ACTIVITY GROUPS....................................................................................................12 7.2 -.............................................................................................................................................................................. 13 Authorizations.....................................................................................................................................................................13 Single profiles.....................................................................................................................................................................13 Composite Profiles..............................................................................................................................................................14 8. SAP SECURITY ORGANIZATION.................................................................................................................................15 9. SAP ACCESS AUTHORIZATION/PROCESS (UNDER DEVELOPMENT).............................................................16 9.1 ..............................................................................................................................................................................................16 9.2 ...............................................................................................................................................................................................16 9.3 ADMINISTRATIVE PROCEDURES FOR SAP ACCESS..........................................................................................16 THIS ITEM IS ON THE SECURITY TEAMS TO DO LIST.............................................................................................17 10. ABC CORP SAP R/3 SECURITY ACCESS FORM ....................................................................................................18 11. LOG-ON PARAMETER ADMINISTRATION.............................................................................................................19 12. USER MASTER RECORDS............................................................................................................................................20 12.1 CREATING A USER MASTER RECORD...................................................................................................................... 20 12.2 ADDRESS............................................................................................................................................................... 20 12.3 LOGON DATA......................................................................................................................................................... 21 Page 2 of 59
ABC Corp Corporation SAP R/3 Security Initial Password..................................................................................................................................................................21 User Group.........................................................................................................................................................................21 Valid From/Valid To...........................................................................................................................................................21 12.4 DEFAULTS.............................................................................................................................................................. 22 Output Device.....................................................................................................................................................................22 Print Controller Functions.................................................................................................................................................22 Decimal Notation................................................................................................................................................................22 Date Format........................................................................................................................................................................22 12.5TASK PROFILE.......................................................................................................................................................... 22 12.6PROFILES................................................................................................................................................................. 22 12.7 USER PARAMETERS................................................................................................................................................ 23 13. PASSWORD ADMINISTRATION...................................................................................................................................24 13.1 13.2 13.3 13.4 DEFAULT PASSWORD REQUIREMENTS..................................................................................................................... 24 SYSTEM PASSWORD PARAMETERS........................................................................................................................... 24 PASSWORD CHANGES............................................................................................................................................. 24 IMPERMISSIBLE PASSWORDS................................................................................................................................... 24 14. SAP SYSTEM SUPPLIED SUPER USER(S).................................................................................................................26 14.1 SAP*...................................................................................................................................................................... 26 14.2 DDIC (DATA DICTIONARY)..................................................................................................................................... 26 15. HELP DESK PROCEDURES..........................................................................................................................................27 15.1 RESETTING USER PASSWORDS................................................................................................................................. 27 15.2 UNLOCKING USER IDS............................................................................................................................................. 27 15.3 RESOLVING ACCESS ISSUES/PROBLEMS................................................................................................................... 27 16. SECURITY CHANGE CONTROL.................................................................................................................................29 16.1 CREATING/MAINTAINING ACTIVITY GROUPS........................................................................................................... 29 16.2 CREATING NEW DEVELOPMENT ROLES................................................................................................................... 29 DETAILED STEPS/INSTRUCTIONS...................................................................................................................................30 16.3UPDATING DEVELOPMENT ROLES (EXCEPT GENERAL USER).....................................................................32 DETAILED STEPS/INSTRUCTIONS...................................................................................................................................32 IMPORTANT – THE NUMBER OF CLIENTS WHERE THE TRANSPORT NEEDS TO BE APPLIED MAY HAVE CHANGED SINCE THE CREATION OF THESE PROCEDURES. REVIEW THE SYSTEM/CLIENT LANDSCAPE TO ENSURE THAT ALL CLIENTS ARE PROPERLY UPDATED. 16.4 UPDATING GENERAL USER DEVELOPMENT ROLE.............................................................................................................................................34 DETAILED STEPS/INSTRUCTIONS...................................................................................................................................34 16.5 CREATING/MAINTAINING AUTHORIZATIONS AND PROFILES.....................................................................................36 16.6 TRANSPORTING ACTIVITY GROUPS ....................................................................................................................36 DETAILED STEPS/INSTRUCTIONS...................................................................................................................................37 16.7 MAINTAINING USER TO ACTIVITY GROUP RELATIONSHIPS......................................................................................39 16.8 AUTHORIZING /VALIDATING CHANGES................................................................................................................... 39 17. SECURITY FOR NEW ABAP/4 PROGRAMS ............................................................................................................40 17.1 ASSIGNING AUTHORIZATION GROUPS..................................................................................................................... 40 17.2 CONFIGURING AUTHORITY CHECKS........................................................................................................................ 40 18. SECURITY FOR NEW SAP TABLES ..........................................................................................................................41 18.1 EXISTING SAP TABLES........................................................................................................................................... 41 Page 3 of 59
ABC Corp Corporation SAP R/3 Security 18.2 NEW SAP TABLES.................................................................................................................................................. 41 19. SECURITY FOR NEW SAP TRANSACTIONS .........................................................................................................42 19.1 CONFIGURE THE TRANSACTION TO MEET S_TCODE REQUIREMENTS.....................................................................42 19.2 IDENTIFY AND CONFIGURE CHECK OBJECT SECURITY (TRANSACTION SE93 AND TABLE TSTCA)............................42 20. SAP R/3 INTERNET SECURITY....................................................................................................................................43 21. APPLICATION LINK ENABLING (ALE) ...................................................................................................................44 22. BATCH/JOB SCHEDULING SECURITY.....................................................................................................................45 22.1 ON-LINE/SCHEDULED PROGRAMS............................................................................................................................ 45 22.2 BATCH INPUT SESSIONS.......................................................................................................................................... 46 23. OUTPUT/SPOOL SECURITY.........................................................................................................................................47 24. SECURITY MONITORING ACTIVITIES....................................................................................................................48 24.1 ADDITIONAL SECURITY MONITORING REPORTS....................................................................................................... 52 24.2 SENSITIVE SECURITY MONITORING PROGRAMS........................................................................................................ 52 25. INSTALLING NEW RELEASES....................................................................................................................................54 APPENDIX A – ALE SYSTEM IDENTIFIERS....................................................................................................................55 APPENDIX B – THREAD LEADERS...................................................................................................................................56 APPENDIX C - GLOSSARY...................................................................................................................................................57 Page 4 of 59
ABC Corp Corporation Overview 1. Objective To ensure that SAP R/3 security provides an efficient and effective structure for ensuring the integrity, accuracy, and availability of the information within SAP. 2. ABC Corp SAP R/3 Security Strategy ABC Corp SAP R/3 security will be implemented through the definition of security roles. Security roles will represent jobs/positions. Each job/position will represent a logical grouping of SAP R/3 transactions required for that job/position to carry out defined business activities and responsibilities. User access will be controlled through the assignment of roles to users. Additionally, responsibilities will be assigned to restrict organizational access. For example, the position 'Material Manager' will be restricted to each plant, preventing users from creating/maintaining inventory outside of their plant location. 3. Scope This document contains SAP R/3 Security Development and Administration procedures. As the SAP R/3 projects are executed, this document will require review and enhancement. The document includes the following topics: • • • • • • • • • • • • • • • • • Objectives SAP R/3 Security Strategy Definitions System and Client Security User Group Strategy Naming conventions SAP Security Organization Requesting SAP access Security Parameter Administration User administration Password administration Security administration structure Manual security administration Help Desk Procedures Security Change Control Security Monitoring Release Impact on Security 4. Approval Process Standard operating procedures must be properly reviewed and approved prior to production implementation. SAP R/3 Security Administration procedures require a two-level approval process: SAP IT Infrastructure team and Business Process Team or Business partner . At this point, the Director responsible for SAP Infrastructure will conduct the first level of approval. IT management includes two positions, the Director and Vice President of Information Technology. Page 5 of 59
ABC Corp Client and System Security Strategy 5. Securing SAP Clients and Systems Security administration for SAP will be based on the client and system structure for ABC Corp. There are five basic systems used to support SAP: Sandbox, Development, Training, Integration/QA and Production. While this system landscape may grow over time, SAP application security will use this baseline model. Clients are defined within each system and the number of clients defined to a system can vary. The client and system structure requires security administration to not only consider the security requirements for the system, but also include client specific security requirements. And, the requirements at the client level can vary within the same system. The primary concern for securing clients and systems is restricting ABAP/4, Basis, Configuration, Functional, Security and Table access based on the definition and use of each client and system. This access will be administered through the definition of development roles and production Job roles. The design and administration of these roles will be controlled using the SAP R/3 Profile Generator. 5.1 Client Ownership As each client is created, an 'owner' is appointed by the Basis team. The owner will have the final authorization or rejection capability for all access requests. Any questions or potential security risks regarding a request or modification of user access will be directed to the client owner. The Basis team will be responsible for administering and maintaining client ownership assignments. Periodically, the Security Administrator will meet with the Basis Administrator to review and update client ownership. 5.2 Development Role Definitions The purpose of the development roles to restrict SAP_ALL and provide the Administrators and Development Teams only with the access needed to completed their job responsibilities. Security Administrator These users have the ability to design and configure authorizations, profiles, and users within the SAP systems and clients. These users will also have full access to client dependent and independent tables and with limited access to basis and security administration transactions. Basis Administrator These users have the ability to support all Basis Administration functions except functional configuration and security administration. Additionally, Basis Administrators require and will have access to ABAP/4 programming, database management system, operating system, tables and all Basis Administration related transactions. ABAP/4 Developer These users will have the ability to develop and maintain ABAP/4 programs, screens, menus and transactions. Additionally, they will have access to the Workbench Organizer and ABAP/4 Data Dictionary, which is required in order to execute development activities. Page 6 of 59
ABC Corp Client and System Security Strategy Functional User These users have full functional access except for the following: Basis Administration Security Administration Oracle Database Client Independent Tables Corrections and Transport System Client Independent Configurator This specific user will have access to configure client independent tables. This access, when granted for a client in a system, will allow the user to make changes that impact all clients for that particular system. The authorization object S_TABU_CLI grants the specific security for this role. This access should be limited to key project team members. Client Dependent Configurator Users with this access will be able to change SAP data via the transaction SM31. The role will require a combination of S_TCODE for SM31 and access to the authorization object S_TABU_DIS. Granting table access should be limited to the proper authorization group. Granting '*' access to the table authorization group will allow users to maintain all tables defined in SAP, including Basis and Security related tables. Configurator Users will be able to access SAP's Implementation Management Guide (IMG). Access to the IMG is required in order to configure SAP functionality. Configuration access will require a combination of access to the IMG and client dependent table configuration. 5.3 System Security Sandbox The Sandbox system is primarily used for self-training and user exploration. Typically, the Sandbox system and clients will contain these types of users: Security Administrator Basis Administrator Functional User ABAP/4 Developer Client Independent Configurator (if necessary) Client Dependent Configurator Configurator The Correction and Transport (CTS) function will be turned off in the Sandbox system. Client independent configuration access will be allowed if there are no other clients that will be impacted by the change. Table access will be granted but should be limited in the event that additional controlled clients are installed on the Sandbox system. Development (Dev2 010, 100) The Development system is used to develop and configure an operational version of the SAP R/3 system. The Development system is the first area where functional configuration and ABAP/4 Page 7 of 59
ABC Corp Client and System Security Strategy development takes place. The use of change control and detailed security roles in client 100 will be required to ensure that all changes are properly authorized and the development process is properly controlled. The Development system will have the following types of users: • Basis Administrator • Security Administrator • ABAP/4 Developer • Configurator • Client Dependent Configurator • Client Independent Configurator (As required) • Functional User • Help Desk Additionally, corrections and transport (CTS) will be turned on and users, based on their role within the project, will be given specific CTS permissions. Permissions will be segregated into the following categories: • • • • Maintain and Release Tasks Create and Delete Tasks Create, Maintain and Release Requests Release Requests Users may be assigned one or more of the aforementioned permissions. To ensure proper change control, the ability to create a task and release requests should be segregated. IMPORTANT: The establishment of CTS security and how it is administered will be dependent on how the system landscape is setup. Training The SAP R/3 InfoDB Training system is used at ABC Corp. The system will be used in a classroom setting that will consist of ABC Corp class participants and instructors from ABC Corp and SAP. The Training client is a pre-configured client from SAP. SAP has customized the system objects including creating user master records and profiles. For security purposes, the pre-configured user master records will be used for granting class participant access. User master records will need to be configured for the instructors, security administrators, and system administrators. In addition, a profile for changing passwords and unlocking users will be created. Integration This system is a controlled environment for process and integration testing. Configuration access, including both client dependent and independent table access should be prohibited. While there may be multiple clients within this system, each client should adhere to the same limitations and restrictions. Page 8 of 59
ABC Corp Client and System Security Strategy The Integration system will have three types of users: • Basis Administrators • Security Administrators • Functional Users • Help Desk Production This system will be the production environment for all SAP R/3 production clients. While the production system landscape for ABC Corp will change over time, the security strategy will remain constant for all production clients. The production system will have three types of users: • Basis Administrators • Security Administrators • Production Users • Help Desk The Security Administrators will only perform the following security related activities in the Production environment. • • • • • Create/Change/Delete Users Re-generate Activity Groups Assign/Change/Remove Activity Groups Re-set Password Lock/Unlock Users Changes to activity groups, authorizations and profiles will be processed in the Development system and migrated to Production using the Transport System. 5.4 The Transport System SAP has its own self-contained change control mechanism, Transport system. This mechanism controls the changing and updating of information that includes: tables, process configuration, ABAP/4 programs, screens, menus and SAP Security. The structure of the Transport System (CTS) is critical when addressing how SAP security will be developed and administered. CTS is used to migrate changes within a controlled and secured manner, across the entire system landscape. CTS controls the flow of changes between Development, Integration/QA and Production systems. It ensures that all changes are properly authorized and tested prior to being implemented in Production. To facilitate the use of the transport system and ensure the integrity of SAP application security, the following procedures should be followed when designing and administering SAP security with the SAP R/3 Profile Generator. Page 9 of 59
ABC Corp Client and System Security Strategy 1. Design all activity groups centrally. It is recommended that a 'Security' client be used as a central repository for security configuration. 2. Production Security Administration should originate in the 'Security Configuration' client (150) and be transported into Production. Security Administration includes the creation or enhancement of activity groups. 3. When the Basis team is creating new clients or systems, coordinate the copying of user master data and activity groups. SAP categorizes activity groups as configuration within the HR module while user master data and manual security are considered general table data. To ensure that all security information is copied, the Basis Administrator must copy the user master data and configuration data from the originating client. 4. Setup a new development class for all Security Administration activities, including both manual and SAP R/3 Profile Generator initiated work. 5. Use the same change request number from the initial creation of the activity group through to the point of the initial generation. 6. When changing existing activity groups, use the same change request number throughout the modification process. 7. Coordinate transports of activity groups with the Basis Administrators, these particular transports can affect system response time. 8. Setup a transport layer that allows complete migration from the 'Security Configuration' client to all other systems and clients. 9. 10. Do not create and generate activity groups outside of the central security client. SAP uses a standard numbering scheme that can conflict when transporting activity groups between multiple clients. Page 10 of 59
ABC Corp User Group Security 6. User Group Security User and security administration can be segregated and decentralized through the use of user groups. User groups are logical groupings of users that provide a mechanism for allowing sub- or remote Security Administrators access to maintain a limited group of users. For example, users for the AGFA are defined to the user group AGFA. Then, we grant the Local Security Administrator (LSA) access to create, change and delete users in the user group AGFA. The following are guidelines for the use of 'User Groups' for the aforementioned baseline SAP system landscape. Sandbox/Development System(s) Role Security Administrator Basis Administrator Functional ABAP/4 Developer Configurator Client Dependent Client Independent SAP* and DDIC Help Desk User Group Super Super Super Super Super Super Super SUPER Help Desk Integration/QA System Role Security Administrator Basis Administrator Functional User SAP* and DDIC Help Desk User Group Super Super TBD SUPER Help Desk Training System Role Security Administrator Basis Administrator Functional User/ Class Participants SAP* and DDIC Help Desk User Group Super Super TBD SUPER Help Desk Production System Role Security Administrator Basis Administrator Production User/Role SAP* and DDIC Help Desk User Group Super Super TBD* SUPER Help Desk * The structure for the production user groups will be determined in the future. Page 11 of 59
ABC Corp Naming Conventions 7. Naming Conventions A standard naming convention is used to develop security activity groups, authorizations and profiles. This standard facilitates the process of identifying access privileges. SAP uses a standard naming convention for its own system objects and has reserved name ranges for customer objects (i.e. customized profiles, authorizations and authorization objects). SAP requires the first character of a custom security activity group, authorization, profile and object, start with a "Y" or "Z". In addition, an underscore "_" is not allowed to be used in the second character position. Following the SAP recommended naming conventions helps to ensure that customized objects are independent of the SAP supplied objects and will not be overwritten during the import of a new SAP releases/upgrades. 7.1 SAP R/3 Profile Generator Activity Groups The naming standards for the SAP R/3 Profile Generator will allow you to identify if it is a development or production activity group, the module, the ABC Corp division it was designed for, and the business role it pertains to. NOTE: The names used for the activity group technical name and text description will be identical to the names used for the corresponding generated profile's technical name and text description. Detemine Activity Group Naming Standards (Site Location) • • • 1st character – - "Z" to represent a custom developed activity group only to be used in development systems. - "Y" to represent a custom developed activity group used in production only. Detail and master activity groups will start with "Y". 2nd & 3rd character – Alpha numeric to represent the module the activity group was designed for. See appendix A for a list of modules character – Represents the division for which this role/ activity group will exist in. • • 4th to 7th characters - A four digit random number generated by the Role Definition form. Each role will be uniquely identified and tracked using this random number. For example, if when creating the Role Definition form for the Cell Culture Accounts Payable Clerk the form randomly generated the number 0001, then the name would be "ZOC0001__. • May not be necessary with the implementation of responsibilities IMPORTANT: All ten characters must be used in the name. If all characters are not used, the SAP R/3 Profile Generator will automatically fill the remaining spaces with underscores "_". This automated process of filling in missing characters could make it very difficult to administer and audit security. Page 12 of 59
ABC Corp Naming Conventions Text Description: The description is to be used to further identify profiles. The first eight characters are restricted to the convention described below. How to use the description to further define the profiles: • 1st to 4th Characters – Hierarchical identifier (Company Code, Plant, Sales Org, Warehouse, etc.). Note: Use "_ALL" for Master Role. • 5th Character – Dash Separator • 6th Character – Space (before beginning the free form text) • Remainder – Free form text to be used for the Role description. Note: The free form text should begin with the ABC Corp division Example: For a "Warehouse Receiving" role in the Consumer Care division the following roles could be created: (assume that the random number from the Role Definition form is "0049") May be replaced by responsibilities 7.2 In general, the naming standards for manual authorizations will not be used for security at ABC Corp. However, these standards will allow you to identify whether it is a composite profile (job role), a simple profile (transaction in a role), or an authorization assigned to a profile. In addition, the naming standard includes the job role and which division the authorizations is for, the SAP application area of the profile, and whether the privileges granted by the profile include read or write access. Authorizations • 1st character - "Z" to represent an in-house customized authorization. • 2nd character - Single character representing the application type (i.e. "S" for system, "F" for Financial, "V" for Sales & Distribution, and "M" for Manufacturing [see Technical Name of the object for standards]). • 3rd character - "/" to represent an authorization. • 4th to 12th characters - These 9 digits should be customized to represent the function being given access to. Underscores can be used to separate the characters in two strings. For example, the authorization "YF/CRT_CO_01" represents the authorization for access to post customer invoices. • Short Text - The short text of an authorization should start with the object name, and then a description of the type of authorization represented. For example, an authorization for object F_BKPF_BLA that has assigned activity values of 01, 02, 03, 08 (create, change, display, display change documents) and an authorization group DR (authorization group for document type DR - Customer Invoices) should have the following short text: "F_BKPF_BLA: Auth. to maintain customer invoices". Single profiles • 1st character - "Z" to represent an in-house designed profile. • 2nd character - Single character representing the application type (i.e. "S" for system, "F" for Financial, "V" for Sales & Distribution, and "M" for Manufacturing [see Technical Name of the object for standards]). • 3rd character - "_" to represent a single profile. Page 13 of 59
ABC Corp Naming Conventions • • • • 4th to 7th characters - These 4 characters should represent the transaction being given access. For example, the profile ZF_FB01_999 will represent complete access to the transaction FB01. 8th character - "_" to show a break between the transaction and type of access. 9th to 12th characters - These 4 characters should be used to document the organizational access being granted for that transaction. This access should follow the specific naming conventions documents for the ABC Corp division. Single profile text - The text of a profile should start with the transaction being granted access and then contain text describing the type of access (i.e. Maintain Accntg Doc's for Company Code xxx) "FB01: Access to maintain A/R documents for company xx". Composite Profiles • 1st character - "Z" to represent an in-house customized profiles. • 2nd and 3rd characters - Two characters representing the module for the role. Human Resources composite profiles will start with "HR", and Basis will start with "BS". Each business group will have a unique two-character identifier. Please note that the only naming convention constraint for SAP security implementation is an "_" in the second character position. • 3rd character - ":" to represent a composite profile. 4th to 12th characters - These 9 digits should be customized to represent the role being defined. Underscores should be used to separate versions of the role. Page 14 of 59
ABC Corp Security Organization 8. SAP Security Organization SAP security administration will be segregated into threetwo functions: development,user administration,Help Desk. Development functions consist of maintaining activity groups, establishing system parameters, monitoring clients and systems and basis security. User administration functions include maintaining users, assigning or changing user access, unlocking users and resetting passwords. Help Desk Functions will include unlocking users and resetting passwords. Development activities will be centrally handled. Additionally, user administration for Basis and Security administrators will be processed through the central SAP security administration function. Page 15 of 59
ABC Corp Access/Administrative Procedures 9. SAP Access Authorization/Process (Under Development) A generic drop down form in the SEA DB has been setup. The SEA DB will be used as the central point for sending/processing 'SAP Access . All SEA Security Administrators have access to the SEA DB should follow these procedures. 9.1 If e-mails are directly sent to the PSI Security Administrators, please follow these steps: 1. Process the approved access request form as intended. 2. After completing the request, forward the original e-mail including the attached request form to SAP Access. 3. Go into SAP Access, open the e-mail message, enter the date completed, completed by information and a brief description of actions completed. 4. File the completed and updated message in the appropriate folder. 9.2 After receiving the approved request form, process the request as intended. Upon completion of the request, send an e-mail to SAP Access with the following information: User name Project/Thread Process Team Date Received Date Completed Completed By Brief Description of Actions Taken User Type Requested Approver's Name System Name Client Number After sending the e-mail to SAP Access, open the e-mail and file it in the appropriate folder. 9.3 Administrative Procedures for SAP Access 1. Add the SEA DBo your Lotus Notes Desktop – you will only need to do this once. 2. Each morning, open the SEA DBand leave it open. This will allow everyone to be notified when new requests are received. 3. For requests that you process (i.e. those for your Project/Thread), once the request is processed move the request to the respective FOLDER. Folders are listed in the SAP Access desktop. 4. IMPORTANT – The only requests that should be processed are those still listed in the 'In Box'. Page 16 of 59
ABC Corp Access/Administrative Procedures 5. IMPORTANT – Under no circumstance should any message be deleted. All messages must be retained and stored in the appropriate folder. PLEASE REFER TO LOTUS NOTES EPN FOR THE CURRENT PROCEDURES FOR REQUESTING ACCESS TO SAP SYSTEMS. EPN > Engagement Library > Reference Documents > Program Level > Process and Systems Integrity > Forms/Templates: SAP Access Form THIS ITEM IS ON THE SECURITY TEAMS TO DO LIST Page 17 of 59
ABC Corp SAP Access Form 10. ABC Corp SAP R/3 Security Access Form Please refer to Lotus Notes EPN for the current SAP Security Access Form. Select Engagement Library > Reference Documents > Program Level > Process and Systems Integrity > Forms/Templates: SAP Access Form Page 18 of 59
ABC Corp Log-on Parameters 11. Log-on Parameter Administration As the Basis team creates new systems and clients, there are specific system profile parameters that must be set in order to facilitate a controlled SAP environment. The system profile parameters should be properly established for all SAP systems. SAP Supplied Default Value SAP System Profile Parameter Description login/min_password_lng login/password_expiration_time Login/fails_to_session_end Minimum password length for user password Number of days between forced password change. Number of invalid logon attempts allowed before the SAP GUI is disconnected. Login/fails_to_user_lock Number of invalid logon attempts within a day before the user id is automatically locked by the system. Time, in seconds, that SAPGUI is automatically disconnected because of in-activity. rdisp/gui_auto_logout Auth/test_mode Auth/system_access_check_off Auth/no_check_in_some_cases Login/ext_security Auth/rfc_authority_check Login/failed_user_auto_unlock Login/no_automatic_user_sapstar Auth/no_check_on_tcode Auth/auth_number_in_userbuffer Auth/authorization_trace Auth/check_value_write_on Switch to report RSUSR400 for authority check Switch off automatic authority check Special authorization checks turned off by customer Security access controlled by external software. Permission for remote function calls from within ABAP programs Disable system function for automatic unlock of users at midnight. Disable ability to logon as SAP* with PASS of password when SAP* deleted. Disable check of S_TCODE on non-basis transactions. Number of authorizations allowed in the user buffer. Every trace will be logged once in table USOBX Write value for SU53 security checking/authorization failure. HAVE YET TO MODIFY ALL PARAMETERS IN ALL INSTANCES Page 19 of 59 ABC Corp Value 3 0 3 90 3 3 12 5 0 N N N N 0 30 minutes N N Y N 1 0 1 0 1 N N 800 N Y 1000 N Y
ABC Corp User Master Standards 12. User Master Records The user master record contains all master data for the user in the R/3 System. This includes user address, logon data, defaults, task profiles, profiles, and parameters. User master records are client specific; therefore, you need to maintain individual user master records for each of the clients in the R/3 Systems. Additionally, the user address, defaults, and parameters can be updated when the user master record is created or by the user. The Security Administrator can add the information as the user master records are created, since SAP automatically displays the screens to format this information. Or users can update the information as SAP automatically provides users with access to change their own address, defaults, and parameters. "Maintaining users" is protected by authorization object S_USER_GRP. 12.1 Creating a User Master Record ABC Corp uses a version of SAP that utilizes the profile generator; therefore, creating user accounts is accomplished via the SU01 and PFCG transaction screens ("User Maintenance: Initial Screen" and "Edit Activity Group," respectively). The "User Maintenance Initial Screen" is comprised of six tabs, or subscreens: 1. Address 2. Logon Data 3. Defaults 4. Task Profile 5. Profiles 6. Parameters Presented in order of which tab the field appears, the following list of fields are required to be populated when creating a user master record on any client or system. While some of the fields are not set-up as required fields by SAP, the following are ABC Corp guidelines for which fields should be completed and with what type of information they should be populated. 12.2 Address This information is used by the Security Administrator to identify the location and name of the person attached to the concern wide identifier. This information is also used to authenticate user password resets. Page 20 of 59
ABC Corp User Master Standards The following fields within the Address tab is required for ABC Corp. Required Fields Form of Address Last Name Information Required Mr. or Ms User's Full Name – Last Name, First Name Complete phone number, including area code or country code. Country of user's ABC Corp location. User's sub-department (e.g. Accounts Payable, Order Management, etc.) ABC Corp's building identifier (e.g. INSERT B&D EXAMPLES, etc.) Complete phone number, including area code or country code. First Name Country for Format Department Building Telephone No. 12.3 Logon Data Initial Password Each user must have an initial password in order for them to log into the system. This password is assigned here. The system prompts the administrator to type it in twice in order to minimize typing errors. User Group All users must be assigned to a pre-defined user group (reference Section 6, User Group Security). This field allows the administrator to categorize the users within groups. This categorization allows the administration functions to have separation of duties. For example, if the user is in the "SUPER" group, the only security administrator capable of maintenance must have access to that specific user group. Valid From/Valid To These two fields are used to define the timeframe an SAP account should be active. The "valid to" field must be used for temporary and contract employees. Additionally, when an employee is terminated or no longer needs SAP access, the "valid to" field should be used. In order to maintain accurate historical data, user accounts should never be deleted – they should be inactivated via the "valid to" field. Page 21 of 59
ABC Corp User Master Standards User Type SAP uses the user type field to determine what type of processing the user will need. There are four types of users and each type will define if the user needs interactive, batch, background, or external processing. User Type Dialog BDC Background CPIC (CPI-S Interface) Description Default user type used for functional system users. Enables the user to process batch input sessions. Allows users to process background jobs. Allows users to make external CPI-C calls from within SAP to external programs. 12.4 Defaults Output Device This area will display all printers that are available to that particular user. All users should be given a default printer based on their location and naming convention. Access to printers is controlled by S_SPO_DEV and all users require access to this authorization object in order to print SAP documents and reports. Print Controller Functions The "Print Immediately" and "Delete After Output" buttons should be enabled. Decimal Notation The decimal notation for ABC Corp should be set to "point" to conform with the US monetary formats. Date Format The standard date format for ABC Corp should be set to MM/DD/YYYY. 12.5 Task Profile Information for these fields should not be added from this screen. The profile generator (Transaction PFCG) should be used to assign access. Once the PFCG is used to assign access to users, fields within this screen are populated with the user's profile information. 12.6 Profiles Information for these fields should not be added from this screen. The profile generator (Transaction PFCG) should be used to assign access. Once the PFCG is used to assign access to users, fields within this screen are populated with the user's profile information. In the event that manual security is used, which should be limited to the sandbox and development systems, this is where the manual profile are added/deleted for a user. Page 22 of 59
ABC Corp User Master Standards . 12.7 User Parameters This tab does not contain any required fields. Users may choose to update these fields at their own discretion. The user parameter tab allows users to manage certain key fields by automatically defaulting information into those fields. Therefore, any time a user encounters these fields in other transactions throughout the SAP client, the field will automatically have a default value equal to what has been assigned in this parameter default screen. The "parameters" column contains any parameter identifications (PIDs) selected for this user. (A list of PIDs can be viewed by clicking on a box to the left of the parameters column and subsequently clicking on the down arrow.) Page 23 of 59
ABC Corp Password Administration 13. Password Administration SAP provides two ways to administer user passwords for an R/3 system and client. SAP has specific default procedures that cannot be changed and parameters in the system DEFAULT.PFL file that can be tailored for each system. The setting of parameters in the DEFAULT.PFL file will affect all clients in that particular system. 13.1 Default Password Requirements The following are default requirements within SAP that cannot be changed: • First character may not be ! or ? • First 3 characters may not appear in the same sequence in the user ID • First 3 characters may not be identical • Space character not allowed within first 3 characters • Password may not be PASS or SAP* (* meaning any string of character(s)) • Passwords are not case sensitive • A user can change their password only once a day • Passwords may not be changed to any of the user's last five passwords 13.2 System Password Parameters Please refer to Section 11 – Log-on Parameter Administration. 13.3 Password Changes If a user forgets their password, the user must call the Help Desktor to request a password reset. The security Administrator will reset the password and forward it to the user's voicemail. When the user logs on, SAP immediately prompts the user to change the password. A user who is logged on when you change the password is not affected by the change until they log off and then on again. Users are also allowed to change their own passwords. Most users are only allowed to change their passwords once per day. However, Security and Basis Administrators can change passwords as often as they desire. 13.4 Impermissible Passwords SAP provides a standard mechanism that allows the establishment of invalid passwords for a particular instance. USR40 is a client independent table that is used to log all prohibited passwords. The table is manually maintained and should be consistently maintained across all projects and systems. It is recommended that this table be used for all projects and systems. The following is a list of recommended values for the table USR40. BD* DTCG* Jan* June* PARA* Delo* Feb* July* NY* DTLL* Marc* Augus* Page 24 of 59 NETS* GIANTS April* Sept* MONEY GOD May* Oct*
ABC Corp Password Administration Nov* YANK* CASH Dec* NewY* Abc* Knick* 123* Aspir* JETS NEED* Note: Each system should be analyzed and the list expanded as deemed necessary. Page 25 of 59
ABC Corp SAP Supplied User Standards 14. SAP System Supplied Super User(s) The SAP R/3 system has two users that come with every SAP system. The two standard super users are SAP* and DDIC. The SAP Security Administrator should strictly secure these two users. The Basis and Security Administrators will be the only users who know and have access to these two users. 14.1 SAP* SAP* is the user that is setup in every client install or copy. Because this user is written into the SAP code, it is also the only user that does not have a user master record. It comes standard in every system, and has a predefined password of 06071992. This user also has complete access to the entire SAP R/3 system. The unlimited access of SAP* should be immediately secured by the SAP Security Administrator. SAP* access should be eliminated and reassigned to a secured user. The following are a list of steps to mitigate the risk of SAP*: 1. Change the password. 2. Create a user master record for SAP*. 3. Turn off the special privileges of SAP* by changing the parameter loginno_automatic_user_sap* to a value greater than 0. This is changed in the common default profile, DEFAULT.PFL. 4. Create a separate user named SAP_ALL to replace SAP* and limit access to only those who need it. 5. Delete all profiles from the SAP* profile list so it has no authorizations. 6. Ensure SAP* and SAP_ALL are assigned to the user group SUPER. 14.2 DDIC (data dictionary) User DDIC is a SAP supplied identifier that comes standard with every system. Unlike SAP*, this user has a defined user master record. The default password for logging into DDIC is 19920706. DDIC has special privileges relating to the data dictionary in SAP and it's the only user allowed to log in during a system upgrade. Therefore, this user must be secured against misuse or unauthorized access. The following are a list of steps to mitigate the risk of user DDIC: 1. Change the password. (It is recommended that it be changed bi-weekly). 2. Ensure DDIC is assigned to the user group SUPER. Page 26 of 59
ABC Corp Help Desk Procedures 15. Help Desk Procedures The ABC Corp SAP Help Desk will assist in performing three key activities: • • • Resetting User Passwords Unlocking Users Due to Invalid Password Attempts Resolving Access Issues/Problems The Help Desk users will not be authorized to change any security configuration or assignment of security to users. 15.1 Resetting User Passwords Help Desk personnel will be given access to all SAP clients and systems. The individuals will have access to reset passwords for all users, except those attached to the groups SUPER, Basis and Security. IMPORTANT: Only the Security Administrators and SAP* will have the ability to reset passwords for users in-groups SUPER, Basis and Security. 15.2 Unlocking User Ids Help Desk personnel will be given access to all SAP clients and systems to unlock users. They will be limited to those users not assigned to the user groups SUPER, Basis and Security. Additionally, procedures will state that Help Desk should only unlock users that have been locked due to invalid logon attempts. Only the Security Administrator can unlock users that have been locked by administrators. And, the SAP system profile parameter that automatically unlocks users at mid-night will be disabled. IMPORTANT: Only the Security Administrator and SAP* will be allowed to unlock users assigned to user groups SUPER, Basis and Security. 15.3 Resolving Access Issues/Problems In the event that a user contacts the Help Desk for a security issue, the Help Desk personnel will follow these steps in order to efficiently and effectively process the users request. 1) Have the users execute transaction SU53 (type this in the command box). 2) Have the user print the screen as it appears, selecting the print icon on the screen. The user has the option of printing at their location or printing it directly to the Help Desk. 3) If printed at their location, fax the printout to the Help Desk or to the Security Administrator. The Help Desk should have the fax number for the Security Administrator. 4) The Help Desk will also record the user id , user name, system and client where the processing error occurred. The system and client information can be obtained at the bottom of the users SAP screen or by executing SYSTEM > STATUS. Page 27 of 59
ABC Corp Help Desk Procedures 5) The Help Desk will then forward the call to the appropriate Security Administrator for resolution. Page 28 of 59
ABC Corp Security Change Control 16. Security Change Control As theproject goes through the process of designing and administering SAP security, changes to activity groups, profiles and authorizations should follow a standard change control process. 16.1 Creating/Maintaining Activity Groups All activity groups should be created and maintained in the central security client for each project. Centralized processing and administration of activity groups ensure that all activity groups are synchronized across the entire system landscape for a project. Several key activities must be completed when creating/changing an activity group • For new activity groups, identify an owner to establish authorization and approval. • Identify the transaction(s) to be added, changed or removed. • Create the master activity group and identify the potential hierarchy elements. • When necessary, work with the activity group owner to determine the hierarchy segregation. • Identify which users should have this activity group. • Generate the master and detailed activity group in the security configuration master client. • Release and transport the associated requests to all systems and clients. • Go to the clients and create the necessary relationships between the users and new activity group. For production activity groups, the activity group must be tested in the integration test system and approved by the role owner. Roles will not be migrated into the production system without proper testing and authorization by the role owner. IMPORTANT: When using a security configuration master client, all transports related to activity groups should be applied to all clients within that system and transported to all subsequent systems and clients. 16.2 Creating New Development Roles Activity groups used for granting access to the Development system and clients is centrally designed and configured in client 150. In the situation where new development activity groups/roles (e.g. General User, ABAP Developer, etc.) need to be created, all security configuration for new activity groups must originate in client 150. New activity groups will be properly documented using the 'Role Definition' forms. The Security Administrator receiving the inquiry will process new activity group configuration. The following summarizes the steps to be followed for creating a new activity group: 1. Create a Role Definition form for the new activity group, documenting the transactions and/or authorization objects. 2. Create the new activity group in DV2 Thread Development, client 150. 3. Transport the new activity group across the DV2 client landscape. Page 29 of 59
ABC Corp Security Change Control 4. Re-generate the activity group. Detailed Steps/Instructions The following detailed steps identify the specific actions to be completed, persons responsible for the activities, clients affected and timing when creating a new activity group. 1. Create a Role Definition form for the new activity group, documenting the transactions and/or authorization objects. All activity groups, both development and production, must be properly documented. Work the person making the inquiry/request to define the new activity group. At a minimum, the definition must identify the transactions. Additionally, a role owner must be identified for the new activity group. The role owner is responsible for validating any changes to the activity group once it has been configured and implemented. IMPORTANT – The Role Definition form is an attachment to the FastTrack Task 'Design Application Security'. UNABLE TO FIND THIS FORM IN FASTTRACK, WILL CONTINUE RESEARCHING 2. Create the new activity group in DV2, client 150. Using the Role Definition form, configure the new activity group in client 150. IMPORTANT – All new activity groups must be configured in client 150 and transported to other clients, ensuring that the object number used by SAP is identical across all clients. Follow these standard steps for creating and generating an activity group: 1. Create the activity group. 2. Document the name properly. 3. Select the transactions from the company menu. 4. Complete the authorization profile. 5. Generate the activity group using the proper naming convention (See SAP Security Administration Standard Operating Procedures). 6. Update the tracking and testing information on the Role Definition form. Additionally, refer to R/3 Authorizations Made Easy for assistance in using the Profile Generator. 3. Transport the new activity group across the DV2 client landscape. The new activity group(s) must be copied to the other clients in the Development system. Using the Profile Generator, create a transport for the new activity group. The following steps should be followed when transporting an activity group: Page 30 of 59
ABC Corp Security Change Control 1. From within the Profile Generator, click on the 'Transport' icon. SAP will automatically create the transport task and request number. 2. Execute transaction SE10 – Customizing Workbench. 3. View the 'Customizing Requests' for your User Id. 4. Drill down into the Transport Request until the subsequent task numbers are all displayed. 5. Single click on the appropriate task. With the cursor positioned on the desired task, click the 'Release' button on the menu bar. 6. Complete the proper documentation requirements for new security transports. 7. If more than one underlying task exist for the request, repeat Steps 5 & 6 until all tasks have been released. 8. Once all tasks have been released, single click on the request number and then click on the 'Release' button on the menu bar. 9. Select the 'Release and Transport' option, this will take the existing request and create a transport file. 10. After SAP releasing the request, review the transport log to validate that the transport processed successfully. 11. For valid, successful transport, prepare an E-Mail to "EMAIL ACCOUNT NAME TBD" in Lotus Notes. This message will be used to notify the Basis Team of the need to transport the activity group to other clients in the DV2 system. The message should include the transport number, clients to be impacted, timing requirements and brief description of the transport request. Additionally, refer to Chapter 11 in 'R/3 Authorizations Made Easy' for assistance in creating and releasing transports. 4. Regenerate the activity group Once the Basis Team has successfully applied to transport to the other clients in the Development system, the new activity group must be re-generated. IMPORTANT – The activity group is client dependent, it must be re-generated in all of the clients where the transport was applied. After regenerating the new activity group(s), the user buffers must be reset to activate the changes. From the SAP Main Menu: Tools > Administration > User Maintenance > Users Following this menu path takes you to the Sub-Menu for user administration. Select Environment > Mass Changes > Reset All User Buffers IMPORTANT – Check the message at the bottom of the screen after resetting the user buffers. If an error occurs, contact the Basis Administrators. Page 31 of 59
ABC Corp Security Change Control 16.3 Updating Development Roles (except General User) The PSI Security Administrator will process changes to the development roles, including the Configuration, CTS and ABAP/4 Developer. IMPORTANT - Changes to the Basis Administrator and Security Administrator roles will be processes by the SAP Central Security Administrator Changes to the development roles will follow these five steps: 1. 2. 3. 4. 5. 6. Record the change in the 'Development Role Update Log' (TBD) Add the appropriate transaction(s) or authorization object(s) to the affected activity groups Re-generate the activity group(s) Reset user buffers Discuss change(s) with other PSI Security Administrators Update the activity group in client 150 IMPORTANT – If time permits, changes to development roles should originate in DV2 client 150 and be transported to the appropriate systems and clients. Detailed Steps/Instructions The following detailed steps identify the specific actions to be completed, persons responsible for the activities, affected clients and timing. 1. Record the change in the 'Development Role Update Log' (Excel Spreadsheet) All changes, additions or deletions, must be logged. The log is used to validate and coordinate the over update and re-generation of the configuration activity groups. Update the log with the following information Date of Change Role Changed Team/Person Requesting Changes Description of Change Transaction (added or deleted) Authorization Object (added or deleted) PSI Security Administrator Processing Change Date Applied to Client 150 Transport Number (optional) 2. Add the appropriate transaction(s) or authorization object(s) Page 32 of 59
ABC Corp Security Change Control The affected development roles should be updated in all clients. At the time of creating these procedures, changes should be applied to the Pre-configuration Sandbox and 010 Configuration Master. Using the Profile Generator (transaction PFCG), perform the necessary updates to the appropriate configuration activity group(s). IMPORTANT – Review the System/Client landscape to ensure that all clients are being properly updated. 3. Re-generate the affected activity group The activity group(s) must be regenerated in all-appropriate clients. 4. Reset User Buffers After re-generating the modified activity group(s), the user buffers must be reset to activate the changes. From the SAP Main Menu: Tools > Administration > User Maintenance > Users Following this menu path takes you to the Sub-Menu for user administration. Select Environment > Mass Changes > Reset All User Buffers IMPORTANT – Check the message at the bottom of the screen after resetting the user buffers. If an error occurs, contact the Basis Administrators. 5. Update the affected activity group in client 150 Once the changes to the development roles have been applied to all other clients, the modifications must be applied to client 150. IMPORTANT – Client 150 is the security configuration master. Changes not applied to client 150 may be overwritten in other clients with subsequent transports. Final updates to the development role(s) should follow these steps. Steps 3 through 5 are optional, these steps are only required if the activity group needs to be applied to other clients. 1. Open the 'TBD Log.XLS' and add the appropriate information for logging that the change was applied to client 150. 2. Re-generate the activity group. 3. If necessary, create a transport for the modified activity group, releasing the request to a transport. Also, record the transport number on the 'Development Role Update Log'. 4. If necessary, contact the CTS Administrator to have the transport applied to clients 003 and 010. 5. If necessary, after the transport has been applied, log on to each client (003 and 010) and re-generate the activity group(s). Page 33 of 59
ABC Corp Security Change Control IMPORTANT – The number of clients where the transport needs to be applied may have changed since the creation of these procedures. Review the System/Client landscape to ensure that all clients are properly updated. 16.4 Updating General User Development Role There are four separate configuration teams using the P3 Thread Development System (DV2). The General User role is being used and assigned by/to all four teams. Changes to all development roles must originate in the 'Security Configuration Client (client 150). The size of the General User role, including number of transaction, authorizations and profiles requires that changes be handled in a manner to ensure that changes are easily applied to clients and users. All changes to the General User role will follow five steps: 1. Record the change in the 'General User Update Log' (Excel Spreadsheet) 2. Add the appropriate transaction(s) or authorization object(s) to the SAMPLETBD activity group 3. Re-generate SAMPLETBD 4. Reset User Buffers 5. Coordinate scheduling of TBD update and re-generation IMPORTANT – If time permits, changes to development roles should originate in client 150 and be transported to subsequent systems and clients. Detailed Steps/Instructions The following detailed steps identify the specific actions to be completed, persons responsible for the activities, affected clients and timing. 1. Record the change in the 'General User Update Log' (Excel Spreadsheet) All changes, additions or deletions must be logged. The log is used to validate and coordinate the over update and re-generation of the General User role. An Excel spreadsheet is stored on TBD Update the log with the following information: Date of Change Role Changed Team/Person Requesting Changes Description of Change Transaction (added or deleted) Authorization Object (added or deleted) PSI Security Administrator Processing Change Date Applied to Client 150 Transport Number Page 34 of 59
ABC Corp Security Change Control 2. Add the appropriate transaction(s) or authorization object(s) to the SAMPLE activity group SAMPLE must be updated in two clients: DV1 010 and DV2 010 Configuration Master. Using the Profile Generator (transaction PFCG), perform the necessary updates to the SAMPLE activity group. IMPORTANT – At the time of creating these procedures, only DV1 010 and DV2 010 required use and updating of SAMPLE. Review the System/Client landscape to ensure that all clients are being properly updated. 3. Regenerate SAMPLE The activity group must be re-generated in all appropriate clients. IMPORTANT – Only the activity group SAMPLE should be re-generated. This is the only modified activity group. 4. Rest User Buffers After re-generating the SAMPLE activity group, the user buffers must be reset to activate the changes. From the SAP Main Menu: Tools > Administration > User Maintenance > Users Following this menu path takes you to the Sub-Menu for user administration. Select Environment > Mass Changes > Reset All User Buffers IMPORTANT – Check the message at the bottom of the screen after resetting the user buffers. If an error occurs, contact the Basis Administrators. 5. Coordinate scheduling of YDXXGENUSR update and re-generation Changes logged in the 'General User Update Log' will be processed at the end of each day in client 150. The Chemical PSI Security Administrator will process all changes to General User activity group in client 150. Final updates to the YDXXGENUSR activity group will follow these 7 steps: 1. Open the 'General User Update Log.XLS' and make the changes to YDXXGENUSR 2. Update the log to reflect the date of processing the change and who completed the change. 3. Regenerate the activity group. 4. Create a transport for YDXXGENUSR, releasing the request to a transport. Also, record the transport number on the 'General User Update Log'. (See Procedures for Transports and Documentation). 5. Contact the CTS Administrator to have the transport applied to clients 003 and 010. 6. After the transport has been applied, log on to each client (003 and 010) and re-generate the YDXXGENUSR activity group. 7. Finally, removed the transaction(s) and/or authorization object(s) from the SAMPLE activity group in clients 003 and 010. And, re-generate SAMPLE in each client. Page 35 of 59
ABC Corp Security Change Control IMPORTANT – The number of clients where the transport needs to be applied may have changed since the creation of these procedures. Review the System/Client landscape to ensure that all clients are properly updated. 16.5 Creating/Maintaining Authorizations and Profiles In general, manual authorizations and profiles will not be used at ABC Corp. Security development and administration will be handled through the use of the SAP R/3 Profile Generator. The following guidelines should be followed for manual SAP security development. • • • • • • • • Identify an owner to establish authorization and approval levels. Identify the authorization object or profile that requires change or creation. Create or change the necessary authorizations or the profile. When necessary, work with the role owner to determine the hierarchy segregation. Identify which users or profiles should have the new access. Review the users that may already have the profile name attached to their user. When the necessary changes have been made to the profiles, (e.g. adding new authorizations or creating a new profile to support the request) transport the profile. Release and transport the associated requests to all clients. Go to the clients and create the necessary relationships between the users and new profile, if necessary. Note: If adding or changing an authorization that is incorporated in an existing profile, the user must log-off and log-on after the new access has been assigned for the update to be applied. 16.6 Transporting Activity Groups Each activity group must first be created in the DV2 Development system, client 150. The activity groups will be propagated to other systems and clients using the Transport Management System (TMS). In version 4.0B, TMS has replaced the Correction and Transport System (CTS). The terms CTS and TMS are synonymous. As activity groups are created and setup for transporting, each transport should be properly documented and the Basis Team notified. The following summarizes the steps to be followed for transporting activity groups from client 150 to other systems and clients: 1. 2. 3. 4. 5. 6. Identify the activity group(s) to be transported. Identify the systems and clients to be updated. Create and document the transport for the activity group(s). Release the transport in SAP. Contact the Basis Team. Re-generate the activity group(s). Page 36 of 59
ABC Corp Security Change Control IMPORTANT – Prior to creating and applying the transport, verify the settings for table T77TR in all destination clients. Two entries should exist, T 1001 A007 and T 100 B007. These entries will prohibit the transporting of relationships. Detailed Steps/Instructions The following detailed steps identify the specific actions to be completed when transporting activity groups. IMPORTANT – Additional information regarding the screens and transactions used to transport activity groups is available in Chapter 11 of "R/3 System Authorizations Made Easy". 1. Identify the activity group(s) to be transported. Based on your recent activity group modifications or configurations, identify the activity groups that need to be transported. It is recommended that you group the activity groups into a single transport. But, be aware of the size of the activity groups. DO NOT TRANSPORT GENERAL USER WITH ANY OTHER ACTIVITY GROUPS. Additionally, please consider the number of users, systems and clients affected by the transport. All of this information should be considered when determining the grouping structure of activity group(s) to transport. 2. Identify the systems and clients to be updated. Identify the systems and clients where the transport should be applied. All security related transports should originate from DV2 Development system, client 150. At a minimum, transports should be applied to DV2 client 010 (development), U3Q client 010 (Integration) and U3P client 010 (Production). IMPORTANT – At the time of creating these procedures, U3Q and U3P have not been installed. These systems represent the Integration System and Production system. Client 010 is the number for the Development Configuration Master client. This number may change based on the system/client landscape. 3. Create and document the transport for the activity group(s). Using the Profile Generator, create the transport for the identified activity groups. If transporting more than one activity group, use the same transport number created for the first activity group. For example, if transporting activity groups YDXXTEST1 and YDXXTEST2. SAP will create a transport number DV2K9000011 for the first activity group. When transporting the Page 37 of 59
ABC Corp Security Change Control second activity group, either select or type the transport number assigned to the first activity group. Additionally, refer to Chapter 11 in 'R/3 Authorizations Made Easy' for assistance in creating and releasing transports for multiple activity groups. IMPORTANT – All security related transport must be properly logged in document. ?????????????? Update the log with the following information Date Transport Created Transport Number Description of Transport Activity Group Affected Originating System and Client Destination System and Client Processed by (PSI) Transport Validated Working in Destination 4. Release the transport in SAP. Once the transport has been successfully created, the transport must go through the proper release through the Transport Management System (TMS). SAP categorizes activity groups as Customizing, execute transaction SE10 – Customizing Organizer. Display the transports listed under your /User Name. SAP groups the transport information into a task and request. In order to transport the activity group, all tasks associated with the request must be properly released. Once all tasks have been released, the request can be released. When the request is released, the activity groups have been transported. Contact the Basis Team. 5. Contact the Basis Team. The Basis Team will perform the actual application of the transport to the destination system(s) and client(s). Prepare an e-mail, addressed to "P3 SAP Basis Team". The e-mail should contain the following information: Transport Number Systems where the transport should be applied (e.g. DV2) Clients that the transport should be applied to (e.g. 003, 010) Description of the change Timing requirements: Urgent, please apply immediately, end-of-day, etc Your phone number Additionally, copy (CC:) the other PSI Security Administrator to make them aware of the transport. Page 38 of 59
ABC Corp Security Change Control 6. Re-generate the activity group(s). For each client identified in Step 2, log on to the client and re-generate the activity group(s) applied by the transport. Additionally, if there are any users logged on during the re-generation, the User Buffers should be reset. IMPORTANT – Each PSI Security Administrator is responsible for re-generating the activity groups that they have transported. 16.7 Maintaining User to Activity Group Relationships When using the SAP R/3 Profile Generator, all access permissions should be assigned using either the PFCG transaction or the SU01 transaction. The process of creating relationships should be handled within each client. When the relationship is created within PFCG there is a possibility that a 'Change Request' will be created. In the event that a change request is generated, once the relationship has been created, the request should be deleted from the Customizing Organizer. The System, Client or Role owner must properly authorize all changes to user relationships. 16.8 Authorizing /Validating Changes All changes to security should be properly authorized. The following table indicates the necessary level of authorization for SAP Security Administration activities: Type of Activity Creating New User Creating New Activity Group Changing Existing User Access Changing Existing Activity Group Migration to Other Clients/Instances Page 39 Required Level of Authorization Thread Leader/Client Owner Thread Leader/Client Owner/Role Owner Thread Leader/Client Owner Thread Leader/Client Owner/Role Owner Destination Client/System Owners of 59
ABC Corp SAP Table Security 17. Security for New ABAP/4 Programs As stated in the ABAP Development Guidelines, all new ABAP/4 programs will be attached to a transaction code. And, access to transaction SA38 and SE38 will be restricted to ABAP Development team members only. New programs will follow the same guidelines for securing new SAP transactions (see prior section for requirements). In the event that a program is created for batch processing only, the following security requirements must be configured. Consult with the SAP Security Administrator when configuring ABAP/4 program security. For all batch programs which will not be secured by a transaction, there are two security requirements: assigning authorization groups and configuring authority checks. 17.1 Assigning Authorization Groups 1. Identify the group of people or area that should have access to this program. 2. Determine if there is an existing authorization group that meets the criteria. If not, create that authorization group in table TBRG. 3. Enter the ABAP program 'attributes' in edit mode (SE38). 4. Type in the authorization group name in the field 'Auth Group'. 5. Create and release the transport request and migrate the program change across the entire system. 6. Work with the SAP Security Administrator to identify the role or position that should be able to execute the program. The Security Administrator will develop the necessary activity group to enable the identified users to submit/execute the program. 7. If this program should be scheduled for over-night batch processing, contact the Basis and Security Administrator. Both parties should be involved in defining the batch security requirements. 17.2 Configuring Authority Checks 1. Evaluate the need to create new authorization objects or use existing objects. 2. If necessary, work with the Security Administrator to create new authorization objects and associate them with an existing object class. 3. Identify the values necessary to execute the program and configure the appropriate authority checks in the ABAP/4 program. 4. Identify the position or role that should have access to execute this program. The Security Administrator will develop the necessary activity group to enable the identified users to submit/execute the program. 5. Review the authority check, authorization object and required values with the SAP Security Administrator. IMPORTANT: All ABAP/4 programs defined for batch execution must be assigned to an authorization group and contain at a minimum, one authority check. All programs should be subject to a program walkthrough to ensure program security has been properly configured before migrating to Integration Testing or Production. Page 40 of 59
ABC Corp SAP Table Security 18. Security for New SAP Tables The ability to display and maintain table level data should be closely managed and granted on exception basis. There are three SAP transactions that provide primary access to view and maintain SAP table data: SE16, SE17 and SM31. Transactions SE16 and SE17 provide display only access while transaction SM31 provides direct table update capabilities. IMPORTANT: Update access to transaction SM31 will only be granted in the Development system and master configuration client. The following are guidelines for securing table access. The SAP Security Administrator should be consulted when configuring and granting table level access. 18.1 Existing SAP Tables Display access will be granted based on configuration and functional requirements. Authorization Groups control table access and all table access will be explicitly granted based on authorization groups using the authorization object S_TABU_DIS. 18.2 New SAP Tables All new tables must be secured with an authorization group. A table that does not have an authorization group assigned to it can be modified by any user with access to S_TABU_DIS with values of '02' and 'blank/spaces' in fields activity or authorization group. The SAP Security Administrator should be consulted when securing new SAP tables. The following are steps that must be completed to properly secure a new SAP table: 1. Identify the table or view name to be secured. 2. Determine if there is an existing authorization group attached to similar tables that the new table should be grouped with? 3. For new authorization groups, first create the authorization group name in table TDDAT. 4. Once the authorization group name is created, assign the authorization group to the table name using transaction SM31 and maintain the table TDDAT. 5. When maintaining the table TDDAT, be careful, this is a client independent table. 6. Once the authorization group has been applied, transport the change request to all subsequent clients and systems. IMPORTANT: While granting access to tables is controlled by the two objects S_TABU_DIS and S_TABU_CLI, the users must also be granted access to the necessary transactions using the object S_TCODE. Page 41 of 59
ABC Corp Transaction Security 19. Security for New SAP Transactions Transactions developed to support the SAP implementation must be secured. There are two security requirements for all customized SAP transactions: 19.1 Configure the Transaction to Meet S_TCODE Requirements The following steps should be followed when creating a new transaction: • • • Define the transaction code in SAP using transaction SE93. Contact the SAP Security Administrator and let them know the new transaction code. The SAP Security Administrator will secure the new transaction. 19.2 Identify and Configure Check Object Security (transaction SE93 and table TSTCA). The following steps should be followed when defining a check object: • Review the existing authorization objects to determine the ability to use an SAP supplied authorization object. • If necessary, create the new authorization object. New objects must be defined in table TOBJ. Work with the SAP Security Administrator to create new authorization objects. • Define the authorization values required to execute the transaction. Each authorization object can have up to ten fields. In defining the check object, a value must be specified for at least one field. • Execute transaction SE93 to create the check object. • Enter the new transaction code and click on the 'Maintain' icon. SAP will display a screen that shows the transaction code, program name, screen number and check object. The check object field may be blank for new transactions. • Enter the authorization object selected to be the check object. • Enter the authorization values for the check object. Click on the value button for the check object, SAP will display a pop-up screen with the fields defined to the selected authorization object. Enter the values in the required fields. Values can be entered in one or all of the fields. IMPORTANT: In defining and configuring custom transaction security requirements, the ABAP/4 Developer should work with the SAP Security Administrator to properly define and configure the security requirements. Page 42 of 59
ABC Corp Internet Security 20. SAP R/3 Internet Security Internet functionality within SAP is processed through the Internet Transaction Server (ITS). SAP has implemented specific security requirements for Internet users and functionality. The following are guidelines for administering and configuring Internet access. 1. The object S_USER_WWW should only be assigned to the Security Administrator responsible for creating Internet users. 2. The functional and system owner should properly approve Internet user access. 3. The BAPI name should be explicitly defined on the Internet Transaction Server and within the destination client. IMPORTANT: The Competency Center and Basis Administration teams should be consulted when configuring Internet access and users. How the Internet functionality is enabled at the HTML level will impact the security requirements. Page 43 of 59
ABC Corp ALE Security 21. Application Link Enabling (ALE) ALE security can be broken down into three areas: development, administration and execution. The project's functional teams and the Competency Center conduct the development of the ALE functionality. The Basis Administration and Communications team will handle the administration of ALE and the underlying EDI functionality. The execution of ALE functionality is dependent on how SAP has been configured. The Process Teams will be responsible for working with the Competency Center and IT Team to properly configure and test ALE processing. Access to ALE functionality will be dependent on the development role and project. The following are guidelines for the type of access and which role will have it. 1. The Competency Center and project teams will be responsible for developing and testing ALE functionality. Their roles as configurators will provide them with the necessary access to configure and test ALE processing. 2. The Basis Administration, Competency Center and Communications teams will setup and verify the execution of ALE functions. These roles will provide them with the necessary access to process the technical configuration and execution of ALE processing. 3. User access will be controlled by the production role assigned to that user. ALE functionality is enabled at the SAP transaction/process level. Production roles will grant access to transactions/processes and ALE processing will be controlled through the configuration of the transactions/processes. IMPORTANT: The Competency Center and Basis Administration team should be consulted when gathering ALE security requirements. Page 44 of 59
ABC Corp Batch/Job Scheduling Security 22. Batch/Job Scheduling Security SAP provides several options for submitting and administering batch processing. Programs can be scheduled, submitted on-line or interactively executed in batch mode. Each method has distinct security requirements that must be implemented. The following are guidelines and standard operating procedures that must be implemented for new batch programs. 22.1 On-line/Scheduled Programs These programs are defined as ABAP/4 programs that are submitted for batch processing. Scheduled programs are submitted to be executed in background, based on specific criteria (e.g. time, predecessor, and date). On-line programs are immediately executed when submitted by the user or programmer. There are three transactions needed to submit programs: SE38, SA38 and SM36. There are similar security requirements for each transaction, including: 1. An authorization for the object S_TCODE that explicitly defines the transaction value. 2. An authorization for the object S_PROGRAM with the activity of submit, btcsubmit or variant and the authorization group assigned to the program. IMPORTANT: Access to SE38 and SA38 should be restricted to the ABAP Development Team only. Requests for these transactions should be directed to the Client Owner. Additionally, all users should have access to transaction SM36; this is the generic screen for defining jobs for batch processing. SAP treats users as administrators for batch jobs that they submit. The following are security guidelines for submitting batch programs. 1. Users must be explicitly granted submit or btcsubmit privilege. 2. The value of '*' will not be used for the authorization group in the object S_PROGRAM. 3. The Basis Administration team are the only users with batch administration access (S_BTCH_ADM). 4. If the program requires additional authorizations, which are not assigned to the user, a background user must be used. 5. When necessary, users are explicitly given access to background users (S_BTCH_NAM). 6. For all scheduled jobs, a background user must be assigned to the program for submission. Page 45 of 59
ABC Corp Batch/Job Scheduling Security 22.2 Batch Input Sessions Batch input sessions are similar to on-line batch programs but provide interactive capabilities. Programs submitted through batch input processing allow the submitter/user to view the screens being executed by the batch input session. Users must be given explicit access to the session name and actions to be executed. The following are security guidelines for batch input processing: 1. Users should only be given access to session names that begin with their (e.g. MOAXC*). 2. Actions should be restricted to the sessions submitted by that particular user. 3. The values '*' should not be used for either the session name or action. The establishment and administration of batch input security should be coordinated with the ABAP/4 Development and Functional Teams, as they are typical users of the batch input processing functionality. Page 46 of 59
ABC Corp Output/Spool Security 23. Output/Spool Security SAP requires that users be given explicit access to printers and spools. The authorization object S_SPO_DEV controls access to these resources. Both printers and output spools are defined to the SAP client by the Basis Administration team. The following are security guidelines for output/spool access: 1. The ability to create, maintain and delete spool and printer information will be limited to the Basis Administration team only. 2. User access will be restricted to specific device names. 3. Access to protected spool requests, which are secured by the object S_SPO_ACT, will require explicit definition of the action and spool request name. IMPORTANT: The security requirements for printers and spool requests should be coordinated with the Basis Administration and Functional Teams. Users may be permitted unrestricted access in the Sandbox and Development systems, but print and spool access will be restricted in the Integration and Production systems. Page 47 of 59
ABC Corp Security Monitoring 24. Security Monitoring Activities SAP supplies a series of reporting tools and ABAP/4 programs that provide detailed analysis and monitoring of SAP security at the client and system level. The monitoring reports can be accessed via the following transaction codes: Transaction Code SA38 SE38 SUIM Screen Name ABAP: Execute Program ABAP Editor: Initial Screen Display Report Tree Transactions SA38 and SE38 require use of the report name (as listed on the following table). Transaction SUIM leads the user through the repository information report tree. The following procedures are standard security monitoring activities. In addition to performing these tasks, the results of the monitoring procedure should be documented and retained in order to provide a useful audit trail. Page 48 of 59
ABC Corp No. 1 Objective Ensure invalid login attempts are properly reviewed. 2 Ensure changes to passwords are properly authorized. 3 Ensure SAP System Profile Parameters are properly configured based on ABC Corp Standard Operating Procedures. 4 Ensure changes to SAP security are properly approved. 5 Ensure security access is properly restricted. 6 Ensure SAP supplied SAP* and DDIC are properly secured. 7 Ensure access to security Security Monitoring Monitoring Procedure The report lists for each client within the system, all users with invalid login attempts and those users locked either by Security Administrators or too many invalid password attempts. Review the report to identify any inconsistencies or patterns. Review password change documents for key users, including SAP*, DDIC, Basis and Security Administrators. The ability to reset passwords should be limited to Basis and Security Administrators, and Help Desk users. (Choose header data and passwords for desired userids.) For each system, review the key security related system profile parameters. The parameter values should be configured according to the recommended values in Section 11 – Logon Parameter Administration in the SAP R/3 Security Administration Standard Operating Procedures. Additionally, these parameters should be consistently set for all SAP systems. Refer to Section 11 Log-on Parameter Administration. For selected key users, including Basis and Security Administrators, execute the report and review change history. Review the date of changes and who made the changes. Changes should be limited to other Basis or Security Administrators. Review the users that have access to "change" within the authorization objects S_USER_GRP, S_USER_AUT and S_USER_PRO. Access to "change" within these objects should be limited to Security Administration team members. The Basis team should have the ability to reset passwords for all user groups except SUPER and Security. The ability to display can be given to any user. Review the report and verify that the passwords for SAP* and DDIC have been changed for all clients. The report shows all of the clients defined to the system. SAP* and DDIC passwords should be consistently maintained on all clients. (Choose header data and passwords for desired userids.) Check for transactional access to security administration. Page 49 of 59 Report or Transaction RSUSR006 Recommended Frequency Daily RSUSR100 Weekly RSPARAM Bi-weekly RSUSR100 RSUSR101 RSUSR102 Bi-weekly RSUSR040 How to efficiently accomplish this task is questionable . Bi-weekly RSUSR100 RSUSR002 Monthly Monthly System Client Completed By (Who/Date)