Sap security-administration

ABC Corp Corporation SAP R/3 Security

SAP R/3 Security Administration

Standard Operating Procedures

of 61


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................................................................................................................................................... 65.2 DEVELOPMENT ROLE DEFINITIONS............................................................................................................................. 6

Security Administrator................................................................................................................................................. 6Basis Administrator..................................................................................................................................................... 6ABAP/4 Developer....................................................................................................................................................... 7Functional User........................................................................................................................................................... 7Client Independent Configurator.................................................................................................................................. 7Client Dependent Configurator.................................................................................................................................... 7Configurator................................................................................................................................................................ 7

5.3 SYSTEM SECURITY..................................................................................................................................................... 7Sandbox....................................................................................................................................................................... 7Development................................................................................................................................................................ 8Training....................................................................................................................................................................... 8Integration................................................................................................................................................................... 9Production................................................................................................................................................................... 9

5.4 THE TRANSPORT SYSTEM......................................................................................................................................... 10

6. USER GROUP SECURITY........................................................................................................................................ 12

7. NAMING CONVENTIONS....................................................................................................................................... 14

7.1 SAP R/3 PROFILE GENERATOR ACTIVITY GROUPS....................................................................................................147.2 MANUAL -- AUTHORIZATIONS AND PROFILES (WITHOUT PROFILE GENERATOR).........................................................15

Authorizations............................................................................................................................................................ 15Single profiles............................................................................................................................................................ 16Composite Profiles..................................................................................................................................................... 16

8. SAP SECURITY ORGANIZATION.......................................................................................................................... 16

9. SAP ACCESS AUTHORIZATION/PROCESS.........................................................................................................17

9.1 DIRECT E-MAILS TO PSI SECURITY ADMINISTRATORS.............................................................................17

9.2 MANUAL/HARD-COPY ACCESS REQUEST FORMS........................................................................................17

9.3 ADMINISTRATIVE PROCEDURES FOR SAP ACCESS.....................................................................................17

10. ABC CORP SAP R/3 SECURITY ACCESS FORM...............................................................................................19

11. LOG-ON PARAMETER ADMINISTRATION.......................................................................................................20

12. USER MASTER RECORDS.................................................................................................................................... 21

12.1 CREATING A USER MASTER RECORD...................................................................................................................... 2112.2 ADDRESS............................................................................................................................................................... 2112.3 LOGON DATA........................................................................................................................................................ 22

of 61


Initial Password......................................................................................................................................................... 22User Group................................................................................................................................................................ 22Valid From/Valid To.................................................................................................................................................. 22

12.4 DEFAULTS............................................................................................................................................................. 23Output Device............................................................................................................................................................ 23Print Controller Functions......................................................................................................................................... 23Decimal Notation....................................................................................................................................................... 23Date Format.............................................................................................................................................................. 23

12.5 TASK PROFILE..................................................................................................................................................... 2312.6 PROFILES............................................................................................................................................................ 2312.7 USER PARAMETERS................................................................................................................................................ 24

13. PASSWORD ADMINISTRATION........................................................................................................................... 25

13.1 DEFAULT PASSWORD REQUIREMENTS..................................................................................................................... 2513.2 SYSTEM PASSWORD PARAMETERS.......................................................................................................................... 2513.3 PASSWORD CHANGES............................................................................................................................................. 2513.4 IMPERMISSIBLE PASSWORDS................................................................................................................................... 25

14. SAP SYSTEM SUPPLIED SUPER USER(S)..........................................................................................................27

14.1 SAP*..................................................................................................................................................................... 2714.2 DDIC (DATA DICTIONARY).................................................................................................................................... 27

15. HELP DESK PROCEDURES.................................................................................................................................. 28

15.1 RESETTING USER PASSWORDS................................................................................................................................. 2815.2 UNLOCKING USER IDS............................................................................................................................................. 2815.3 RESOLVING ACCESS ISSUES/PROBLEMS................................................................................................................... 28

16. SECURITY CHANGE CONTROL.......................................................................................................................... 30

16.1 CREATING/MAINTAINING ACTIVITY GROUPS..........................................................................................................3016.2 CREATING NEW DEVELOPMENT ROLES................................................................................................................... 30

DETAILED STEPS/INSTRUCTIONS............................................................................................................................ 31

16.3 UPDATING DEVELOPMENT ROLES (EXCEPT GENERAL USER)............................................................33


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..................................................................................................................................... 35


16.5 CREATING/MAINTAINING AUTHORIZATIONS AND PROFILES.....................................................................................37

16.6 TRANSPORTING ACTIVITY GROUPS.............................................................................................................. 38


16.7 MAINTAINING USER TO ACTIVITY GROUP RELATIONSHIPS......................................................................................4116.8 AUTHORIZING /VALIDATING CHANGES................................................................................................................... 41

17. SECURITY FOR NEW ABAP/4 PROGRAMS.......................................................................................................42

17.1 ASSIGNING AUTHORIZATION GROUPS..................................................................................................................... 4217.2 CONFIGURING AUTHORITY CHECKS........................................................................................................................ 42

of 61


18. SECURITY FOR NEW SAP TABLES.................................................................................................................... 43

18.1 EXISTING SAP TABLES.......................................................................................................................................... 4318.2 NEW SAP TABLES................................................................................................................................................. 43

19. SECURITY FOR NEW SAP TRANSACTIONS.....................................................................................................44

19.1 CONFIGURE THE TRANSACTION TO MEET S_TCODE REQUIREMENTS.....................................................................4419.2 IDENTIFY AND CONFIGURE CHECK OBJECT SECURITY (TRANSACTION SE93 AND TABLE TSTCA)............................44

20. SAP R/3 INTERNET SECURITY............................................................................................................................ 45

21. APPLICATION LINK ENABLING (ALE)............................................................................................................. 46

22. BATCH/JOB SCHEDULING SECURITY.............................................................................................................. 47

22.1 ON-LINE/SCHEDULED PROGRAMS........................................................................................................................... 4722.2 BATCH INPUT SESSIONS......................................................................................................................................... 48

23. OUTPUT/SPOOL SECURITY................................................................................................................................. 49

24. SECURITY MONITORING ACTIVITIES............................................................................................................. 50

24.1 ADDITIONAL SECURITY MONITORING REPORTS......................................................................................................5424.2 SENSITIVE SECURITY MONITORING PROGRAMS........................................................................................................54

25. INSTALLING NEW RELEASES............................................................................................................................ 56

APPENDIX A – ALE SYSTEM IDENTIFIERS............................................................................................................. 57

APPENDIX B – THREAD LEADERS............................................................................................................................ 58

APPENDIX C - GLOSSARY.......................................................................................................................................... 59

of 61

ABC Corp Corporation Overview

1. ObjectiveTo 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 StrategyABC 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. ScopeThis 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.

of 61

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 AdministratorThese 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 AdministratorThese 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.

of 61


ABAP/4 DeveloperThese 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.

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 ConfiguratorThis 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 ConfiguratorUsers 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.

ConfiguratorUsers 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

SandboxThe 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

of 61


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 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.

TrainingThe 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.

of 61


IntegrationThis 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.

The Integration system will have three types of users: Basis Administrators Security Administrators Functional Users Help Desk

ProductionThis 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

of 61


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.

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.

of 61

ABC Corp User Group Security

6. User Group SecurityUser 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 User GroupSecurity Administrator Super

Basis Administrator SuperFunctional Super

ABAP/4 Developer SuperConfigurator Super

Client Dependent SuperClient Independent SuperSAP* and DDIC SUPER

Help Desk Help Desk

Integration/QA System


Basis Administrator SuperFunctional User TBDSAP* and DDIC SUPER

Help Desk Help Desk

Training System


Basis Administrator SuperFunctional User/ Class Participants TBD

SAP* and DDIC SUPERHelp Desk Help Desk

Production System


Basis Administrator SuperProduction User/Role TBD*

SAP* and DDIC SUPERHelp Desk Help Desk

of 61

ABC Corp User Group Security

* The structure for the production user groups will be determined in the future.

of 61

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.

of 61

mailto:Z@PFAPCLRK


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 divisionExample: 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.

of 61


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.

of 61

ABC Corp Security Organization

8. SAP Security OrganizationSAP 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.

of 61

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 Access1. 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.

of 61

ABC Corp Access/Administrative Procedures

4. IMPORTANT – The only requests that should be processed are those still listed in the ‘In Box’.

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

of 61

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

of 61

ABC Corp Log-on Parameters

11. Log-on Parameter AdministrationAs 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 System Profile Parameter Description

SAP Supplied Default Value

ABC Corp Value

login/min_password_lng Minimum password length for user password 3 3login/password_expiration_time Number of days between forced password change. 0 90Login/fails_to_session_end Number of invalid logon attempts allowed before

the SAP GUI is disconnected. 3 3Login/fails_to_user_lock Number of invalid logon attempts within a day

before the user id is automatically locked by the system.

12 5

rdisp/gui_auto_logout Time, in seconds, that SAPGUI is automatically disconnected because of in-activity. 0 30

minutesAuth/test_mode Switch to report RSUSR400 for authority check N NAuth/system_access_check_off Switch off automatic authority check N NAuth/no_check_in_some_cases Special authorization checks turned off by customer N YLogin/ext_security Security access controlled by external software. N NAuth/rfc_authority_check Permission for remote function calls from within

ABAP programs0 1

Login/failed_user_auto_unlock Disable system function for automatic unlock of users at midnight.

0 1

Login/no_automatic_user_sapstar Disable ability to logon as SAP* with PASS of password when SAP* deleted.

0 1

Auth/no_check_on_tcode Disable check of S_TCODE on non-basis transactions.

N N

Auth/auth_number_in_userbuffer Number of authorizations allowed in the user buffer.

800 1000

Auth/authorization_trace Every trace will be logged once in table USOBX N NAuth/check_value_write_on Write value for SU53 security

checking/authorization failure.Y Y

HAVE YET TO MODIFY ALL PARAMETERS IN ALL INSTANCES

of 61

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. Address2. 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.

of 61


The following fields within the Address tab is required for ABC Corp.

Required Fields Information RequiredForm of Address Mr. or MsLast Name User’s Full Name –

Last Name, First NameFirst Name Complete phone number, including area code

or country code.Country for Format Country of user’s ABC Corp location.Department User’s sub-department (e.g. Accounts

Payable, Order Management, etc.)Building ABC Corp’s building identifier (e.g. INSERT

B&D EXAMPLES, etc.)Telephone No. Complete phone number, including area code

or country code.

12.3 Logon Data

Initial PasswordEach 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 GroupAll 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 ToThese 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.

of 61


User TypeSAP 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 DescriptionDialog Default user type used for functional system

users.BDC Enables the user to process batch input sessions.Background Allows users to process background jobs.CPIC(CPI-S Interface)

Allows users to make external CPI-C calls from within SAP to external programs.

12.4 Defaults

Output DeviceThis 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 FunctionsThe “Print Immediately” and “Delete After Output” buttons should be enabled.

Decimal NotationThe decimal notation for ABC Corp should be set to “point” to conform with the US monetary formats.

Date FormatThe 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.

of 61


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.

.

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.)

of 61

ABC Corp Password Administration

13. Password AdministrationSAP 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* PARA* NY* NETS* MONEYDTCG* Delo* DTLL* GIANTS GODJan* Feb* Marc* April* May*June* July* Augus* Sept* Oct*

of 61

ABC Corp Password Administration

Nov* Dec* Abc* 123* JETSYANK* NewY* Knick* Aspir* NEED*CASH

Note: Each system should be analyzed and the list expanded as deemed necessary.

of 61

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 login-

no_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.

of 61

ABC Corp Help Desk Procedures

15. Help Desk ProceduresThe 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.

of 61

ABC Corp Help Desk Procedures

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.

5) The Help Desk will then forward the call to the appropriate Security Administrator for resolution.

of 61

ABC Corp Security Change Control

16. Security Change ControlAs 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.

of 61


3. Transport the new activity group across the DV2 client landscape.4. Re-generate the activity group.

Detailed Steps/InstructionsThe following detailed steps identify the specific actions to be completed, personsresponsible 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.

of 61


Using the Profile Generator, create a transport for the new activity group. The following steps should be followed when transporting an activity group:

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 groupOnce 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

of 61


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.

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. Record the change in the ‘Development Role Update Log’ (TBD)2. Add the appropriate transaction(s) or authorization object(s) to the affected activity groups3. Re-generate the activity group(s)4. Reset user buffers5. Discuss change(s) with other PSI Security Administrators6. 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/InstructionsThe 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)

of 61


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) 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 groupThe activity group(s) must be regenerated in all-appropriate clients.

4. Reset User BuffersAfter re-generating the modified activity group(s), the user buffers must be reset to activate the changes.




5. Update the affected activity group in client 150Once 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.

of 61


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).

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

group3. Re-generate SAMPLETBD4. Reset User Buffers5. 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/InstructionsThe 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

of 61


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

2. Add the appropriate transaction(s) or authorization object(s) to the SAMPLE activity groupSAMPLE 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 SAMPLEThe 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 BuffersAfter re-generating the SAMPLE activity group, the user buffers must be reset to activate the changes.




5. Coordinate scheduling of YDXXGENUSR update and re-generationChanges 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:

of 61


1. Open the ‘General User Update Log.XLS’ and make the changes to YDXXGENUSR2. 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.

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

of 61


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. Identify the activity group(s) to be transported.2. Identify the systems and clients to be updated.3. Create and document the transport for the activity group(s).4. Release the transport in SAP.5. Contact the Basis Team.6. Re-generate the activity group(s).

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/InstructionsThe 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.

of 61


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 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.

of 61


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.

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:

of 61


Type of Activity Required Level of AuthorizationCreating New User Thread Leader/Client OwnerCreating New Activity Group Thread Leader/Client Owner/Role OwnerChanging Existing User Access Thread Leader/Client OwnerChanging Existing Activity Group Thread Leader/Client Owner/Role OwnerMigration to Other Clients/Instances Destination Client/System Owners

of 61

ABC Corp SAP Table Security

17. Security for New ABAP/4 ProgramsAs 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.

of 61

ABC Corp SAP Table Security

18. Security for New SAP TablesThe 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.

of 61

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.

of 61

ABC Corp Internet Security

20. SAP R/3 Internet SecurityInternet 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.

of 61

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.

of 61

ABC Corp Batch/Job Scheduling Security

22. Batch/Job Scheduling SecuritySAP 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.

of 61

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.

of 61

ABC Corp Output/Spool Security

23. Output/Spool SecuritySAP 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.

of 61

ABC Corp Security Monitoring

24. Security Monitoring ActivitiesSAP 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 Screen NameSA38 ABAP: Execute ProgramSE38 ABAP Editor: Initial ScreenSUIM 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.

of 61


No. Objective Monitoring ProcedureReport or

Transaction Recommended

Frequency System ClientCompleted By

(Who/Date)1 Ensure invalid login

attempts are properly reviewed.

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.

RSUSR006 Daily

2 Ensure changes to passwords are properly authorized.

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.)

RSUSR100 Weekly

3 Ensure SAP System Profile Parameters are properly configured based on ABC Corp Standard Operating Procedures.

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.

RSPARAM Bi-weekly

4 Ensure changes to SAP security are properly approved.

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.

RSUSR100RSUSR101RSUSR102

Bi-weekly

5 Ensure security access is properly restricted.

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.

RSUSR040How to

efficiently accomplish this task is

questionable.

Bi-weekly

6 Ensure SAP supplied SAP* and DDIC are properly secured.

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

RSUSR100Monthly

of 61





(Who/Date)userids.)

7 Ensure access to security transactions is properly secured.

Check for transactional access to security administration. Execute report RSUSR010 and check for transactions PFCG, SU01, SU02, SU03 and SU05. They control access to the profile generator, user administration, profile administration, authorization maintenance and internet user administration.

RSUSR002 Monthly

8 Ensure S_TABU_CLI and S_TABU_DIS are properly configured and access to them is appropriately restricted.

Review the users that have table access for both client independent and dependent table access (S_TABU_CLI and S_TABU_DIS). Access to maintain tables should be coordinated with the Basis Team. Table access needs to coincide with the ability to perform configuration. Client independent table access should be restricted to key process team members and to Basis team members. Client independent table access should be limited to the Sandbox and to the Configuration Master clients within the Development box.

RSUSR040 Monthly

9 Ensure that all users are properly assigned to the correct user group.

Review the users defined for all clients and systems. Each user should be assigned to a valid pre-approved user group. Refer to Section 6 User Group Security for approved user groups.

RSUSR002 Monthly

10 Ensure master addresses are populated according to standard operating procedures.

Execute the ABAP/4 program and select the address fields: first name, name field 1, building name, street, city, location, department, phone, extension and country key. Review the user master records to ensure all users have the required address information properly formatted. This activity should be completed for each system, the report analyzes all of the clients within a system.

USR03 Monthly

11 Ensure that impermissible passwords are consistently implemented and meet standard operating procedures.

Verify the data contained in table USR40. This table contains ABC Corp specific impermissible password settings.

SE16 Semi-annually

12 Ensure SAP R/3 Profile Generator is properly configured.

Review the configuration and activation of the SAP R/3 Profile Generator. Review the documentation in the Enterprise IMG to ensure all configuration steps have been successfully completed. This activity should focus on new systems.

SPRO Semi-annually

of 61





(Who/Date)13 Ensure that access to

transactions SU10 (delete/add a profile for all users) and SU12 (delete all users) are appropriately restricted.

? ? ?

of 61


24.1 Additional Security Monitoring Reports

The following are additional reports, which may be executed as needed, to monitor security. Reports should be executed using transaction SE38.

Program Name DescriptionRSUSR000 Lists the active users logged on to the entire system (transaction

SM04)RSUSR005 Analyzes all users defined to the system for critical authorizationsRSUSR008 Provides analysis of critical transaction combinations (transaction

SU98)RSUSR009 Allows analysis of critical combinations of authorizations

(transaction SU96)RSUSR020 Complex selection criteria based on profileRSUSR030 Complex selection criteria based on authorizationRSUSR150 Compare tool. Compares two users to see difference and

similarities in which transactions can be executedRSUSR060 Where-used selection , profiles onlyRSUSR070 Complex search on activity group onlyRSUSR406 Re-generate SAP_ALL profilesRSUSR998 Information System Reporting TreeRSM04000 List of active users logged on to all clients in the systemRSM51000 List of R/3 Servers defined to the current system

RHAUTH00 List by User, all the objects that user has assigned to them based on Object Classes

24.2 Sensitive Security Monitoring Programs

The following are programs can be used for additional security administration activities but with extreme caution. These programs will directly impact the SAP R/3 Profile Generator and could cause security integrity problems between clients. Extreme caution should be used when executing any of these programs.

Program Name Description

RSUSR303 Copies table TSTCA to TSTCA_C and populate TSTCA with S_TCODE.

RSUSR304 Copies the data in table TSTCA_C back into TSTCA and replaces S_TCODE

RSUSR400 Tests the environment checks for SAP systemsRSUSR402 Write special user data to sequential file. RSUSR403 Assigns the profile S_A.CPIC to the user SAPCPIC

of 61


RSUSR404 Converts the Basis developmentRSUSR408 Converts the data in USOBX-OKFLAG for upgrade tools (SU260RHPROFL0 Program to generate user authorizations and activity groups.

RHAUTHUP1 Performs user master comparison for activity groups. SAP recommends using transaction PFUD

RHAUTHUPD Actual master data comparison used within the HR moduleRHCECK0 Performs system check

NOTE: The information pertaining to monitoring activities and additional programs will be periodically updated to reflect new releases of SAP and new functionality per OSS notes.

of 61

ABC Corp New SAP Releases

25. Installing New ReleasesAs each new release or version of SAP is installed, there should be a detailed analysis of the impacts the new release may have on SAP application security.

SAP provides two forms of supporting release documentation, an On-line Help CD and OSS notes. Both of these resources should be reviewed in detail as new releases are being considered. The following are guidelines for understanding how new releases may impact existing SAP security configuration.

1. Review the on-line CD release notes. Typically, SAP categorizes changes by the module and security changes are usually contained with Basis documentation.

2. Review the OSS upgrade installation procedures. These procedures may provide information on new security components or the potential impact on security.

3. Analyze which objects SAP may have moved to obsolete. There is an object class that SAP uses to list all obsolete authorization objects. These objects should be reviewed to see how they may impact defined activity groups.

4. Analyze new authorization objects. SAP uses the composite profile SAP_NEW to document new authorization objects. SAP_NEW contains a series of single profiles that are named according to the release. Review the new authorization objects to determine how they may need to be incorporated into existing activity groups. Additionally, review the new objects to determine if they replace any existing objects or obsolete objects. For example, release 3.0A had a new object S_DEVELOP that replaced S_EDITOR.

5. For the new objects, review the documentation and structure of the objects to determine how they are to be used.

6. For objects impacting security, analyze which activity groups may be impacted. The number of activity groups impacted will indicate the potential time required to incorporate security changes.

7. Meet with the Basis Team and Competency Center to discuss the impact the new SAP release may have on security. Consider recommending that the new release be installed in a Sandbox client, this will provide an environment for testing security without impacting existing security.

8. Review the listing of security programs supplied by SAP. Typically, these programs start with RSUSR followed by three digits. These reports may assist in handling upgrades or security monitoring activities.

It is imperative that each new upgrade or release to be implemented be extensively reviewed and tested. And, as new security features are implemented, standard operating procedures should be updated in a timely manner.

of 61

ABC Corp Appendix A – Business Group Acronyms

Appendix A – ALE System Identifiers

ALE System IdentifierMaster Data System “M”Operations System “O”All ALE Systems “X”

of 61

ABC Corp Appendix B - Thread Leaders

Appendix B – Thread Leaders

Threads Thread LeadersProgram OfficeHuman ResourcesCustomer FacingManufacturingChange & LearningCompetency CenterInformation TechnologyProcess & Systems IntegrityFinance & ControllingReq. To Pay.

Integration

of 61

ABC Corp Appendix C - Glossary

Appendix C - Glossary

Authorization Objects - A template utilized by SAP transactions/programs for testing access privileges. The object may contain a group of 1 to 10 fields. The objects are checked using AND logic to determine if the user has been permitted through authorizations, to carry out the desired action.

Authorizations - A set of permissible values (value set) for an authorization object. The values are assigned based on the fields defined in that authorization object and the required access capabilities (i.e. a value of 03 in the activity field will assign display access and value of 11 in the company code field will assign access to company 11).

Authorization Group - An assignment of customized values to groups of similar information. The authorization groups are used in conjunction with authorizations associated with specific authorization objects. The field can contain an alphanumeric value up to 4 characters/digits.

Single Profile - A mechanism for grouping either similar or dissimilar authorizations into a logical group. The profile provides an efficient method for administering user access to similar functionality through the assigning of a single profile to a user. The single profile can only contain authorizations.

Composite Profile - A mechanism for grouping either similar or dissimilar access into a logical group. The composite profile provides an efficient method for administering user access to complex functionality spanning several modules. The profile may contain single profiles, authorizations, or other composite profiles.

User Group - A mechanism for grouping SAP users into similar categories for administrative procedures. The basis administrators and R/3 security administrators are generally included in the ‘SUPER’ group. The user group is a security administration attribute that can be used to decentralize user administration. A security administrator must be given explicit access to a user group.

Activation - An action of making an authorization or profile ‘activate’. Activating an authorization or profile will replace the current ‘active’ version with the maintenance version. All authorizations and profiles must be ‘activated’ for the access to be applied to users.

Activity Group – Activity groups are used in conjunction with creating authorization profiles using the Profile Generator. An activity group is a collection of activities (tasks, reports and transactions) for which you can then use Profile generator to generate an authorization profile automatically. You then assign the profile to the user via the activity group.

Profile Generator – The profile generator is an automated security development and administration tool developed by SAP AG. This functionality was integrated into the SAP R/3 software for release 3.1G. It automates the creation of activity groups, generating authorizations, creating single/simple

of 61


profiles and assigning activity groups to users. The profile generator is a transaction based security administration tool.

Transaction – A four-character code used to SAP to identify a screen used within the SAP R/3 system. The transaction code (e.g. FB01, SU03) is the foundation for developing and administering SAP application security.

Role –A role is the first level for defining user access to the SAP R/3 system. For example, a role defined for ABC Corp is A/P Clerk. In defining a role, scripts and/or transactions are assigned to a role based on the required functionality necessary to complete the job responsibilities for a given role. A role is the lowest level of security that can be granted to a user. A user may be granted/assigned to more than one role.

Position – A position is a logical grouping of roles that relate to a defined organizational position within ABC Corp. For example, the position of the corporate A/P Clerk may consist of the roles A/P Clerk, Monthly Payables Review, and Corporate PO Review. The position provides a logical grouping for assigning all of the necessary roles that a user requires for their job responsibilities. A user should only be assigned one position.

of 61


of 61

Sap security-administration

Technology

Transcript of Sap security-administration