eCATT Security Guide

eCATT Security Guide
SAP Online Help
29.07.2008
Copyright
Copyright 2008 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.
SAP Online Help
29.07.2008
Icons in Body Text

Icon Meaning Caution Example Note Recommendation Syntax
Additional icons are used in SAP Library documentation to help you identify different types of information at a glance. For more information, see Help on Help General Information Classes and Information Classes for Business Information Warehouse on the first page of any version of SAP Library.
Typographic Conventions
Type Style Example text Description Words or characters quoted from the screen. These include field names, screen titles, pushbuttons labels, menu names, menu paths, and menu options. Cross-references to other documentation. Example text EXAMPLE TEXT Emphasized words or phrases in body text, graphic titles, and table titles. Technical names of system objects. These include report names, program names, transaction codes, table names, and key concepts of a programming language when they are surrounded by body text, for example, SELECT and INCLUDE. Output on the screen. This includes file and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools. Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation. Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system. Keys on the keyboard, for example, F2 or ENTER.
Example text
Example text <Example text>
EXAMPLE TEXT
SAP Online Help
29.07.2008
eCATT Security Guide........................................................................................................... 5 Before You Start ................................................................................................................ 6 Technical System Landscape ............................................................................................ 7 Authorizations.................................................................................................................... 8 Authorization Objects Used in eCATT Authorization ....................................................... 9 Test Developer Authorizations...................................................................................... 10 Tester Authorizations.................................................................................................... 12 Setting up authorizations when execution is done locally .............................................. 13 Network and Communication Security.............................................................................. 14 Security for Additional Applications .................................................................................. 15 Other Security-Relevant Information ................................................................................ 15
SAP Online Help
29.07.2008

This guide does not replace the daily operations handbook that we recommend customers to create for their specific productive operations.
Target Audience
Technical consultants System administrators
Why Is Security Necessary?

Your SAP Systems contain a wealth of sensitive data data that is essential for the day-today running of your business, data that you are required by law to protect from unauthorized access, data that you would not want your competitors or a disgruntled employee to see, much less be able to compromise in some way. Security is an issue that SAP takes seriously, providing an extensive authorization concept to protect transactions and data from unwanted access.
About This Document

The security guide provides an overview of the security-relevant information that applies to eCATT. The aim of this guide is to help you make informed choices about your security policy in your testing environment by explaining the authorizations required for different kinds of eCATT users. It also explains the security features implemented to protect your systems from unwanted GUI scripting access. Overview of the Main Sections The Security Guide comprises the following main sections: Before You Start [Page 6] This section contains information about the client settings that you must specify in each client in which you want to run CATT procedures or eCATT test scripts. Technical System Landscape [Page 7] This section provides an overview of the technical components that can be used in eCATT test scenarios. Authorizations [Page 8] This section provides an overview of the authorization concept that applies to eCATT. Network and Communication Security [Page 14] This section provides an overview of the communication paths used by eCATT and how to set up Trusted RFC. Security for Additional Applications [Page 15] This section provides security information that applies to third-party or additional applications that are used with eCATT. Other Security-Relevant Information [Page 15] This section contains information regarding GUI Scripting access.
SAP Online Help
29.07.2008
Before You Start

Fundamental Security Guides
eCATT is built on SAP NetWeaver Application Server ABAP. In eCATT scenarios, several systems are usually involved: The eCATT script is located in a Test Content System. The eCATT code interpretation is also done in this system. The test of the application itself is done in one or more Systems Under Test. Therefore, the corresponding Security Guides also apply to eCATT. Pay particular attention to the most relevant sections or specific restrictions as indicated in the table below. Fundamental Security Guides Scenario, Application or Component Security Guide SAP NetWeaver Application Server ABAP Security Guide RFC/ICF Security Guide For a complete list of the available SAP Security Guides, see the SAP Service Marketplace at service.sap.com/securityguide.
Important SAP Notes

The most important SAP Notes that apply to the security of eCATT are shown in the table below. SAP Note 496286 Title Security concept extended for CATT and eCATT Missing security checks in eCATT function modules Comment Valid only for releases older than 6.20 SP 40 / 6.40 SP 03 Valid only for releases older than 6.20 SP 01
728979
Configuration
In each client in which you want to run CATT procedures or eCATT test scripts, you must specify in the client settings that this should be allowed.
...
1. Start transaction SCC4. You will see a list of all of the clients that have been set up in the system. 2. Choose Maintain, and acknowledge the warning that the table is cross-client. 3. Double-click the client in for which you want to allow CATT or eCATT. Depending on the release in which you are working, you will see one of two screens. In older releases, in the Restrictions group box, select the check box Allows CATT processes to be started. In newer releases, in the group box Restrictions when Starting CATT and eCATT, select one of the following entries: eCATT and CATT Not Allowed eCATT and CATT Allowed eCATT and CATT Allowed for 'Trusted RFC' Only
SAP Online Help
29.07.2008
eCATT Allowed; FUN/ABAP and CATT Not Allowed eCATT Allowed; FUN/ABAP and CATT for 'Trusted RFC' Only Since one of the main principles of eCATT is to run all test cases from a central test system, RFC communication is required to connect to the target systems. It is possible to restrict this RFC communication to trusted RFC, which prevents passwords from having to be stored in RFC destinations and transmitted over the network. The FUN and ABAP commands in eCATT pose a security problem, since the eCATT environment allows them to bypass normal security mechanisms. With FUN, you can execute function modules remotely, even if they are not designated as remotelyenabled in their attributes. The ABAP command allows you to write and execute ABAP coding with just the authorization to create eCATT scripts (and not the full authorization for creating ABAP programs). Consequently, you may disable these features, or restrict them by allowing them only to run within a trusted RFC relationship. Since eCATT tests frequently make database changes, it is not advisable to allow them to be run in production clients.
Additional Information
For more information about specific topics, see the addresses on the SAP Service Marketplace as shown in the table below. Content Security Security Guides Related SAP Notes Released platforms Network security SAP Solution Manager SAP Service Marketplace Address service.sap.com/security service.sap.com/securityguide service.sap.com/notes service.sap.com/platforms service.sap.com/securityguide service.sap.com/solutionmanager
Technical System Landscape

eCATT is available from Release 6.20 of the SAP Web Application Server. As such, it can be used to test any SAP System based on Web AS 6.20 or higher. However, it is also possible to set up a Web Application Server as a standalone test system. All of the test scripts and associated objects are then created and stored in this system, but the tests themselves can be executed against existing systems, including those with earlier releases (4.6C or higher). The figure below shows an overview of the technical system landscape for eCATT test scenarios: Using the SAP Web AS 6.20 as a Central Test System
SAP Online Help
29.07.2008
Application
eCATT patch
4.6C System Central Test System Application
eCATT
SAP Web AS 6.20
eCATT patch
6.10 System Application
6.20 System
Authorizations
To establish how to protect your systems and the connections between them, there are two kinds of user that must be considered: Test Developer: A test developer must be able to create, change, display, and delete the following items: Test scripts Test data containers System data containers Test configurations Tester: A tester must be able to execute test configurations assigned to him or her using the Test Workbench. It is also necessary to create and maintain RFC destinations pointing to the various target systems. You can either assign the authorizations for this to test developers, or leave the task to the system administrator.
More Information:
Authorization Objects Used in eCATT Authorization [Page 9] Test Developer Authorizations [Page 10] Tester Authorizations [Page 12] Setting up authorizations when execution is done locally [Page 13]
SAP Online Help
29.07.2008
Authorization Objects Used in eCATT Authorization

Authorizations for the following authorization objects are required to enable users to work with eCATT:
S_TCODE
Authorizations based on the object S_TCODE regulate the transactions that users are allowed to start. Hence it is possible to restrict a users authorization to the extent that he or she can start no transactions in the system other than SECATT. This authorization is always checked by the SAP kernel. Field TCD Description Permitted transaction code or codes
S_DEVELOP
S_DEVELOP is the authorization object used to regulate access to all development objects in an SAP system. While this potentially gives a user extremely wide-ranging rights, the granularity of the object allows you to create authorizations that restrict access to a particular kind of object (for example, you can stipulate that a user may only work with eCATT objects), particular packages, and particular activities (for example, execute, but not create, change, or delete). Field DEVCLASS OBJTYPE OBJNAME P_GROUP ACTVT Description Package(s) whose objects the user may change Object types that the user may change Object names that the user may change Program group (applies only to programs) Permitted activities (create, change, )
S_RFC
This is a system-side authorization object that is called upon when users try to execute functions in remote systems. It allows you to restrict the function modules that can be called to those in specified function groups. Field RFC_TYPE RFC_NAME ACTVT Description Type of RFC object that the user can work with. Can only take the value FUGR (function group) Name of the function group or groups whose function modules the user may execute Activity. Can only take the value 16 (execute)
S_ADMI_FCD
This is a system administration authorization object. The system checks it when a user tries to create an RFC destination. Field S_ADMI_FCD Description The different system administration functions that the user may perform
SAP Online Help
29.07.2008
S_RFCACL
This is a system administration authorization object. The system checks it when a user tries to log onto a target system using trusted RFC. Field RFC_SYSID RFC_CLIENT RFC_USER RFC_EQUSER RFC_TCODE RFC_INFO ACTVT Activity (only supports 16 Execute) Description The system ID of the originating system The client of the originating system The user in the originating system Flag: Must the user in the target system be the same as the user in the originating system? Transaction code of the application that executed the call
Test Developer Authorizations

In addition to the authorizations listed below, test developers will also require authorization to run the transactions that they need to record in order to create a test script.
eCATT Authorizations in the Test Development System

In order to develop eCATT objects, users will require authorizations containing the following values: Authorization Object S_TCODE Field TCD Value SECATT Description This allows the user to start transaction eCATT. Script System data container Test configuration Test data container Create Change Display Delete Execute
S_DEVELOP
OBJTYPE
ECSC ECSD ECTC ECTD
ACTVT
01 02 03 06 16
DEVCLASS
Any values, for example, Y*, Z* for any package in the
10
SAP Online Help customer namespace OBJNAME Any values, for example Y*, Z* for any package in the customer namespace
29.07.2008
If you have separate systems for developing test objects and the actual testing, your developers will also need authorization for the object S_TRANSPORT. Refer to the documentation of this object for full details.
Execution Control (New in Release 6.40)

Release 6.40 contains an execution control function, which allows you to pause, debug, or terminate a running test case. While any user can exercise this control over his or her own test cases, the following authorizations are required to take control of other users running tests: Authorization Object S_DEVELOP Field OBJTYPE ACTVT DEVCLASS Value ECSC 70 Any values, for example, Y*, Z* for any package in the customer namespace Any values, for example Y*, Z* for any package in the customer namespace Description Script Administer
OBJNAME
Creating RFC Destinations

If a developer is to be able to create RFC destinations, he or she will require the following additional authorizations: Authorization Object S_TCODE S_ADMI_FCD Field TCD S_ADMI_FCD Value SM59 NADM This S_ADMI_FCD authorization gives access to all RFC administration functions. Description
eCATT Authorizations in a Remote System

If developers are creating test scripts that record in remote systems, they will require additional authorizations in that system. The communication between systems uses Remote Function Call, which contains its own authorization checks. Whenever a user tries to execute an RFC call, the system checks his or her authorization for the object S_RFC. The user must have authorization for the function group to which the function module belongs. Consequently, the following authorization is required:
11
SAP Online Help
29.07.2008
Authorization Object S_RFC
Field RFC_TYPE ACTVT RFC_NAME
Value FUGR 16 SCAT STTM STTF SBDR
Description Function group Execute
All eCATT function groups A Batch Input function group necessary to record TCD commands A function group from screen processing required for the screen simulation function in the eCATT Script Editor
SDYN
eCATT Authorizations and External Tools

Normally when you work with an external tool, you will start it from eCATT. In this case, eCATT generates the user required for the RFC connection used to exchange script data (see Using Trusted RFC [Page 14]). If, however, you want to upload scripts from an external tool to eCATT without having started it through eCATT, you must log onto the SAP System yourself. In this case, you need the following authorizations for S_RFC (which are contained in role SAP_ECET): Authorization Object S_RFC Field RFC_TYPE ACTVT RFC_NAME Value FUGR 16 SYST ECATT_EXTERNAL_TOOL Description Function group Execute
Tester Authorizations
In addition to the authorizations listed below, testers will also require authorization to run the transactions included in the test scripts.
eCATT Authorizations in the Test System

Although they are not involved with test development, testers still require authorizations for the object S_DEVELOP that allow them to execute and display test objects. They also need authorization to start the Test Workbench so that they can open their worklist. This results in the following authorizations: Authorization Field Value Description
12
SAP Online Help object S_TCODE TCD STWB_WORK
29.07.2008
This allows the user to start the Test Workbench. Test configuration Display Execute
S_DEVELOP
OBJTYPE ACTVT
ECTC 03 16
DEVCLASS
Any values, for example, Y*, Z* for any package in the customer namespace Any values, for example Y*, Z* for any package in the customer namespace
OBJNAME
eCATT Authorizations in a Remote System

If the test configurations being used by testers require access to remote systems, the tester must have the following RFC authorization in the remote system: Authorization object S_RFC Field RFC_TYPE ACTVT RFC_NAME Value FUGR 16 STTF Description Function group Execute eCATT auxiliary functions
Setting up authorizations when execution is done locally

Regarding eCATT authorizations, you have to distinguish between two parts: the eCATT execution itself and the part in which the application is tested. Normally this is done on two different systems: The eCATT script is located in system TCS (Test Content System). The eCATT code interpretation is also done in the TCS. The test of the application itself is done in system SUT (System Under Test). When the TCS and the SUT are the same, the authorizations in TCS and in SUT could contradict each other. There are two ways to overcome this:
Option 1
Allow activity 16 with SCAT and *. This enables the execution in the target system. The reason is that if SCAT is allowed, also SECATT is allowed (and will not be checked separately). Restrict activity 16 with ECAT, ECSC, ECTC to the allowed objects.
13
SAP Online Help
29.07.2008
Option 2
Allow activity 16 with *. This enables the execution in the target system for all eCATT objects. As you also want to restrict the execution to certain eCATT objects, instead of restricting the execution of these objects (activity 16), you can simply restrict to display these objects (activity 03). Activity 03 is checked before the execution as well, as nobody should be allowed to execute when he is not allowed to display a certain eCATT object.
Disadvantage of option 2: Users will not be able to display the eCATT objects which are not included in the authority of the second step.
Network and Communication Security

The network topology for eCATT is based on the topology used by the SAP NetWeaver platform. Therefore, the security guidelines and recommendations described in the SAP NetWeaver Security Guide also apply to eCATT. Details that specifically apply to eCATT are described below. Normally an RFC destination will contain a specific user name, and often a password. This means that every connection to the target system that is made using this destination will log on under the same user name, and any user with the appropriate authorization in the originating system can log onto the target system irrespective of whether they have authorization to work in that system or not. Hence the destinations are both inflexible and potentially insecure! To get around this problem, you can use trusted RFC.
Using Trusted RFC

Trusted RFC is a contract between two systems in which the target system agrees to trust connections coming from a particular system. In this case, the logon is permitted without a password. Since this is a particularly sensitive feature, trusted RFC is protected by an additional authorization check. In order to log onto a trusted system, the user in question must possess the following: A user in the target system Authorizations for the applications he or she needs to use in the target system Authorization for the object S_RFCACL This authorization object regulates a users right to log onto a system via a trusted connection.
Setting Up the Trusted Relationship

...
1. Log onto the target system and set up an RFC destination that points to your central test system. 2. Start transaction SMT1 and choose (Create).
3. In the next dialog box, enter the name of the RFC destination that you created in step 1. 4. On the next screen, you can use the following settings to restrict the use of the trusted relationship:
14
SAP Online Help
29.07.2008
You can set the entry to inactive. You can restrict the validity of the relationship. 5. Create RFC destinations in the central test system that use trusted RFC to log onto the system in which you just established the trusted relationship.
Using the Trusted Relationship

Once you have set up the trusted relationship, you can create RFC destinations that log onto the target system without requiring a password.
...
1. Start transaction SM59, and open an RFC destination for editing. 2. On the Logon tab, select the Yes radio button for the Trusted System option.
Additional Authorizations
In the target system, each user who wants to log on using trusted RFC requires an authorization containing appropriate values for the authorization object S_RFCACL.
Security for Additional Applications

The integration of external tools with eCATT is implemented using COM to start and stop the external tool, and RFC to exchange script data. The COM communication is initiated by eCATT, but the RFC connection is established by the external tool. When eCATT starts the external tool, it generates a user and password that the tool can use to log back onto the SAP System to exchange data. This user is assigned the role SAP_ECET, which contains two authorizations for object S_RFC (see section S_RFC in Authorization Objects Used in eCATT Authorization [Page 9]). When the external tool is closed, eCATT destroys the user. The generated users have no authorization to start any transactions.
If you start the external tool yourself and want to upload scripts to eCATT, there is no generated user, and you must log onto the SAP System yourself. In this case, you will require the authorizations contained in role SAP_ECET.
Other Security-Relevant Information

eCATT and GUI Scripting
One of the features of eCATT is its capability to record and replay the activity of controls in the SAP GUI. This function is based on the GUI Scripting extension within SAP GUI Version 6.20 and higher. SAP is, of course, aware that scripting can be abused, and has therefore taken care to ensure that scripts cannot be executed unless the system administrator has explicitly opened the necessary channels.
Security Features in GUI Scripting

GUI Scripting contains the following security mechanisms: On the server:
15
SAP Online Help
29.07.2008
Profile parameters whose setting determines whether GUI Scripting should be allowed on the current application server On the client: Options in the SAP GUI setup program that make it possible to install SAP GUI without the scripting components Registry keys that allow scripting to be disabled on the client.
Enabling and Disabling GUI Scripting

GUI Scripting can be switched on and off for a particular application server using the profile parameter sapgui/user_scripting. By default, scripting is not enabled. To enable scripting, set the value of this profile parameter to TRUE. You do not have to restart the server, but you must log off and back on again, since the change does not affect sessions that are currently running. This setting overrides any client settings.
Additional Profile Parameters in Release 6.40 and higher

As well as sapgui/user_scripting, you can use the following profile parameters for more refined access control in Release 6.40. They are also included in Release 6.20 from support package 37, and in Release 4.6C from support package 47. SAPGUI Release 6.20 patch level 42 or higher is also required. Profile Parameter sapgui/user_scripting_disable_recording Description If this parameter is set to TRUE, script playback is possible, but recording is not permitted. If this parameter is set to TRUE, a notification is always displayed at the frontend, regardless of the client options described in section 5.2.4. If this parameter is set to TRUE, scripts may only act on read-only user interface elements.
sapgui/user_scripting_force_notification
sapgui/user_scripting_set_readonly
Installation of Client Components

As well as the server setting, GUI Scripting requires certain components to be installed on the front end. System administrators can prevent the components from being installed by creating installation packages that do not contain the GUI Scripting elements. If users are allowed to configure their own SAP GUI installation using the front end setup platform, they can choose not to install the scripting components.
Warning Options
Current User If GUI Scripting is enabled, the Settings dialog box of the SAP GUI contains the following options for GUI Scripting: Enable scripting: The user can enable and disable scripting for their own use Notify when a script attaches to a running GUI: A message appears whenever a script attaches to the SAP GUI Notify when a script opens a connection: A message appears whenever a script opens a new GUI connection.
16
SAP Online Help
29.07.2008
These options set Registry keys under HKCU\SOFTWARE\SAP\SAPGUI Front\SAP Frontend Server\Security\UserScripting. If you are using scripting for the SAPGUI command in eCATT, we recommend that you leave the Notify when a script opens a connection option selected, since eCATT itself never opens a new connection. Local Machine (All Users) Users with administrator rights on a particular PC can enable and disable scripting using the Registry key HKLM\SOFTWARE\SAP\SAPGUI Front\SAP Frontend Server\Security\UserScripting. This can have the values 0 (disabled) or 1 (enabled). The default setting is enabled.
VB Script and Windows Scripting Host

eCATT GUI Scripting does not use VB Script and hence does not require Windows Scripting Host. Not having WSH installed reduces the risk of virus attacks using scripts.
Logon Screens
The eCATT SAPGUI command never records logon screens. Instead, it creates RFC destinations pointing to the system in question. You are free to adjust these destinations later to allow an unattended logon.
GUI Scripting in Remote Systems Which Settings Apply?

When you are running eCATT from a central test system, you will often need to record SAPGUI commands in remote systems. In order for this to work, scripting must be enabled in both the eCATT system and the target system.
17

eCATT Security Guide

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

eCATT Security Guide

Hochgeladen von

Copyright:

Verfügbare Formate

eCATT Security Guide

SAP Online Help