sap netweaver 2004s sps 4 security guide

SAP NetWeaver 2004s SPS 4

Security Guide

Security Aspects for System Management

Document Version 1.00 – October 24, 2005

© Copyright 2005 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, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation 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. MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, 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. Disclaimer Some components of this product are based on Java™. Any code change in these components may cause unpredictable and severe malfunctions and is therefore expressively prohibited, as is any decompilation of these components. Any Java™ Source Code delivered with this product is only to be used by SAP’s Support Services and may not be modified or altered in any way. Documentation in the SAP Service Marketplace You can find this documentation at the following Internet address: service.sap.com/securityguide

SAP AG Neurottstraße 16 69190 Walldorf Germany T +49/18 05/34 34 24 F +49/18 05/34 34 20 www.sap.com

Typographic Conventions

Type Style Description

Example Text 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 Emphasized words or phrases in body text, graphic titles, and table titles

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

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

Example text Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation.

<Example text>

Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system.

EXAMPLE TEXT Keys on the keyboard, for example, F2 or ENTER.

Icons

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.


4 October 2005

Contents Security Aspects for System Management .........................................5

Security Guide for the Solution Manager Diagnostics.......................6 1.1 Technical System Landscape: Security-Relevant Interfaces ............. 7 1.2 User Authorization and Client Authentication..................................... 8 1.3 Users and Roles ................................................................................... 11 1.4 Trace and Log Files.............................................................................. 11

2 SAP NetWeaver Administrator Security Roles ..............................12 3 Background Processing...................................................................12

3.1 Defining Users for Background Processing ...................................... 13 3.2 Specifying the Execution of External Programs from Job Steps..... 13 3.3 Roles and Authorizations Used in Background Processing ............ 14

4 Print and Output Management.........................................................15 5 Alert Management (ALM)..................................................................16 6 Central Monitoring with CCMS ........................................................16 7 Security Guide for the SAP System Landscape Directory............20

7.1 Network Topology for the SLD Server................................................ 20 7.2 Securing HTTP(S) Connections to the SLD ....................................... 21 7.3 Securing RFC/JCo Connections to the SLD ...................................... 22 7.4 Using Logon Tickets for Single Sign-On............................................ 22 7.5 Application Access Restrictions......................................................... 23 7.6 User Access Restrictions .................................................................... 24

8 SLM Security Roles...........................................................................25 9 Security Guide for ADK-Based Data Archiving..............................26 10 Security Guide for XML-Based Data Archiving............................29 11 Auditing and Logging.....................................................................36

11.1 The Audit Info System (AIS) .............................................................. 36 11.2 The Security Audit Log ...................................................................... 37

11.2.1 Example Filters .........................................................................................................37 11.3 The System Log.................................................................................. 40 11.4 Statistic Records in CCMS ................................................................ 42 11.5 Logging of Specific Activities ........................................................... 42

11.5.1 Application Logging ..................................................................................................43 11.5.2 Logging Workflow Execution ....................................................................................43 11.5.3 Logging Using Change Documents ..........................................................................43 11.5.4 Logging Changes to Table Data ...............................................................................44 11.5.5 Logging Changes Made Using the Change & Transport System.............................44 11.5.6 Logging Changes Made to User and Authorization Information...............................45

11.6 Additional Information on Auditing and Logging............................ 46


1 Security Guide for the Solution Manager Diagnostics

October 2005 5

Security Aspects for System Management There are also security aspects involved with system management and support infrastructure for SAP NetWeaver. The topics we discuss include:

• Security Guide for the Solution Manager Diagnostics [Page 6]

In this section, we provide a summary of the security aspects involved when using the Solution Manager Diagnostics.

• SAP NetWeaver Administrator [Page 12]

In this section, we list the security roles used by the SAP NetWeaver Administrator.

• Computing Center Management System (CCMS)

In this section, we provide a summary of the security aspects associated with CCMS such as:

Background Processing [Page 12]

Print and Output Management [Page 15]

Alert Management (ALM) [Page 16]

Central Monitoring with CCMS [Page 16]

• Security Guide for the SAP System Landscape Directory [Page 20]

In this section, we provide a summary of the security aspects associated with the SAP System Landscape Directory (SLD).

• Software Lifecycle Manager (SLM) [Page 20]

In this topic, we list the security roles used by the SLM.

• Archiving

In the following sections, we describe the security aspects involved when using either the Archiving Development Kit (ADK) or XML-based archiving.

Security Guide for ADK-Based Data Archiving [Page 26]

Security Guide for XML-Based Data Archiving [Page 29]

• Auditing and Logging [Page 36]

In this section, we provide an overview of the reporting tools available with the SAP Web AS so that you can obtain security-relevant information from your system.



6 October 2005

1 Security Guide for the Solution Manager Diagnostics The Solution Manager Diagnostics is a Java-based tool within the SAP Web Application Server 6.40 that provides essential functions to centrally monitor and analyze a complete NetWeaver solution landscape. It especially provides functionality to support Java-based components – therefore it is mandatory that an active Java stack is used within your NetWeaver system. The displayed information is gathered by agents: saposcol, sapccmsr, Introscope Agent, Component Analyzer.

As of NetWeaver 04 Service Package 10, the Solution Manager Diagnostics is part of the standard NetWeaver installation. It is mandatory to install one Solution Manager Diagnostics system within your NetWeaver solution landscape. All functions of the Solution Manager Diagnostics can be used via a standard Web browser.

With SP 10 the Solution Manager Diagnostics is released for use by SAP Support only. As of SP 12, the Solution Manager Diagnostics is released for customers. Before SP12, Solution Manager Diagnostics do not allow any changes to the monitored operational NetWeaver landscape. As of SP 12, the Solution Manager Diagnostics will be extended to administrative functionality.

The security aspects that apply to the Solution Manager Diagnostics are described in the following topics:

• Technical System Landscape: Security-Relevant Interfaces [Page 7]

• User Authorization and Client Authentication [Page 8]

• Users and Roles [Page 11]

• Trace and Log Files [Page 11]



October 2005 7

1.1 Technical System Landscape: Security-Relevant Interfaces The following figure shows the different elements you need for the Solution Manager Diagnostics, and the interfaces that connect these elements.

CCMS

ABAP Stack

Central Monitoring System

Wily IntroscopeServer

Mercury Interactive Load Generator

Web AS ABAP

CCMS

DatabaseMulticonnect

Java Stack

Web AS Java

Solution Manager

Diagnostics

SAP Web AS / J2EE Engine

ABAP Stack

Web AS ABAP

Java Stack

Web AS Javasaposcol

Wily Agent

sapccmsr

comp. analyzer

1

4

2

3

3



8 October 2005

From a security point of view, the interfaces shown in the figure can be described as follows:

• Interface 1: End users accessing the Solution Manager Diagnostics using a Web browser. This interface is based on HTTP(s).

• Interface 2: End users accessing the SAP Web AS ABAP of Solution Manager Diagnostics to call monitoring transactions DB59, DB6COCKPIT, ST04M, ST04_MSS, OS07, RZ20, ST03G via ITS webgui.

• Interface 3: The communication interface between the Solution Manager Diagnostics’ Java functions and the SAP Web AS ABAP where the monitored systems agents have registered. This communication is based on JCo.

• Interface 4: The agents on the monitored systems and the Solution Manager Diagnostics’ CCMS. This communication is based on RFC.

• Interface 5: Communication interface between the Solution Manager Diagnostics and the monitored SAP J2EE Engines. This interface is based on HTTP(s).

1.2 User Authorization and Client Authentication This topic describes the user authorization and client authentication information for each of the interfaces described in Technical System Landscape: Security-Relevant Interfaces [Page 7].

Interface 1: Users Accessing the Solution Manager Diagnostics Using a Web Browser This is an interface where individual users can access the system.

The main task of Solution Manager Diagnostics users is to access technical information (for example, performance data, configuration data) provided by the monitored systems.

Users of the Solution Manager Diagnostics have to be created in the User Management Engine (UME) of the SAP J2EE Engine manually. The roles SAPSUPPPORT (necessary for the Component Analyzer) and INTROSCOPE (necessary for the Wily Introscope Server) have to be created in the UME as well. They do not need to have any content. Solution Manager Diagnostics users have to be added to these roles.

As the users log on using a Web browser, it is not necessary that they have to be located in the network system where the Solution Manager Diagnostics system resides.

To log in within the SAP Support infrastructure, the remote connection type ‘HTTP Connect URL Access’ has to be configured. The remote connection can be opened by the customer only.



October 2005 9

Interface 2: Users Accessing the SAP Web AS ABAP This is an interface where individual users can access the system.

From the Solution Manager Diagnostics, it is possible to call ABAP transactions for monitoring (for example, OS07 or RZ20) within the ABAP stack of the Solution Manager Diagnostics, For this access, using a manual logon has to be performed and a user/password has to be provided to the end user.

The user needed to logon can be located in any client and needs a role with the following authorization objects/authorizations:

Authorization Fields with Field Values

S_ADMI_FCD ACTVT: ST0R

S_RZL_ADM ACTVT: 01, 03

S_RFC RFC_TYPE: FUGR

RFC_NAME: RFC1, SYST

ACTVT: 16

S_TCODE TCD: DB59, DB6COCKPIT, ST04M, ST04_MSS, OS07, RZ20, ST03G

Interface 3: Solution Manager Diagnostics accessing SAP Web AS ABAP This interface is used for technical communication only.

The communication between the gateway of the ABAP stack and Solution Manager Diagnostics Java programs is enabled by the Java connect interface (JCo).

Interface 4: Solution Manager Diagnostics Accessing SAP Web AS ABAP This interface is used for technical communication only.

The systems to be monitored can be:

• SAP Web AS with both ABAP and Java: SAP agents (saposcol, sapccmsr, Component Analyzer) and Introscope agent have to be installed.

• SAP Web AS ABAP only: SAP agents (saposcol, sapccmsr, Component Analyzer) have to be installed.

• SAP Web AS Java only: SAP agents (saposcol, sapccmsr, Component Analyzer) and Introscope agent have to be installed.

• Others (for example, SAP Web AS < 6.40, TREX, DB systems). SAP agents (saposcol, sapccmsr, Component Analyzer) have to be installed.



10 October 2005

Interface 5: Solution Manager Diagnostics Accessing a J2EE Engine This interface is used for technical communication only.

For each 6.40 J2EE Engine in the landscape to be monitored, the Solution Manager Diagnostics calls a Java servlet using HTTP(s). The URL to this servlet has to be entered within the Solution Manager Diagnostics during setup as well as a J2EE user/password to use for authentication to access the remote J2EE Engine. This data is stored within the secure storage of the Solution Manager Diagnostics J2EE Engine.

The connection is used internally to regularly retrieve configuration and performance information of the monitored J2EE Engine and to build up a history of this data to be stored within the Solution Manager Diagnostics.

Technical connection of the monitored component:

• Web Application Server ABAP user access:

Access to the specific monitoring transaction (for example, RZ20) of the Web AS requires the setup of SAP Internet Transaction Server (ITS). The user of the Solution Manager Diagnostics is prompted for user authentication when logging into the WAS via ITS. A valid user with the required authorization profile has to be provided by the customer. Alternatively, the logon can be automated via logon tickets (Single Sign-On).

• Database connection to monitored portal system DB:

For reading and writing information from the database of the monitored system, a DataSource has to be created manually within the JDBC Connector service by using the Visual Administrator.

Therefore, a valid database user/password is required.

• RFC connection for sapccmsr:

For every monitored system, the CCMS agent (sapccmsr) has to be installed and registered. The Solution Manager Diagnostics communicates with the CCMS agents of the monitored systems. This communication uses the RFC protocol.

To register sapccmsr, a valid RFC user (for data communication) and a valid human user (for administration purposes) for the Solution Manger Diagnostics are required.

• J2EE user for configuration data retrieval:

For every monitored J2EE Engine (standalone or within an ABAP system), an administrative J2EE user is needed to read the J2EE configuration settings. The Solution Manager Diagnostics calls a Java servlet on the monitored J2EE engine via HTTP (or HTTPS) – this servlet requires authentication. The retrieved configuration data will be stored with change history within the Solution Manager Diagnostics.



October 2005 11

1.3 Users and Roles

Users The following table is a summary of the standard users:

Standard Users

System User Delivered Type

Solution Manager Diagnostics

SAP J2EE user for starting the Solution Manager Diagnotics

no J2EE user

SAP Web AS running the ITS

User for accessing transactions DB59, DB6COCKPIT, ST04M, ST04_MSS, OS07, RZ20, ST03G

no ABAP user

SAP Web AS running the CCMS, CCMS agents are registered.

User for registering and administrating the RFC connection of sapccmsr

no Communication user

Monitored database system

Database user for creating DataSources

no Database user

Monitored 6.40 J2EE Engines

J2EE user used to collect configuration data

no J2EE user

Roles The following table is a summary of the standard roles:

Roles

System Role Delivered Type

Solution Manager Diagnostics SAPSUPPORT no J2EE role

Solution Manager Diagnostics INTROSCOPE no J2EE role

For detailed descriptions of these users and roles, see User Authorization and Client Authentication [Page 8].

1.4 Trace and Log Files Trace and log information are written in standard log format into the Solution Manager Diagnostics’ log directory, location: <J2EE home>/cluster/server<n>/log:

• applications.<n>.log:

Consists of error and startup information of Solution Manager Diagnostics applications.

• defaultTrace.<n>.trc:

Contains detailed information of Solution Manager Diagnostics applications.


2 SAP NetWeaver Administrator Security Roles

12 October 2005

2 SAP NetWeaver Administrator Security Roles For authorization, the SAP NetWeaver Administrator uses the User Management Engine (UME) and the Java Management Extension™ (JMX) security features. The following security roles are defined that are distinguished by the plug-ins from the authorization point of view:

• SAP_JAVA_NWADMIN_LOCAL

• SAP_JAVA_NWADMIN_LOCAL_READONLY

• SAP_JAVA_NWADMIN_CENTRAL

• SAP_JAVA_NWADMIN_CENTRAL_READONLY

The roles include the permissions that enable/disable certain elements in the UI as well as permissions to access the data in the managed system, that is, they can be used in the central system and the managed system as well.

The local roles enable the management of the local system where the NWA runs. The central roles enable the management of the entire landscape that is available from SLD. The read-only roles do not allow any changes in the managed system such as start/stop, changing configuration, whereas the other roles allow full control.

The mapping between users and roles is done using the UME that is available as a plug-in named User & Access inside the NWA. For more information about how you can configure the above security roles, see Configuring User Administration [SAP Library].

3 Background Processing Background processing automates routine tasks and helps you optimize your organization’s SAP System computing resources. Using background processing, you can execute programs that are time-consuming or resource-intensive when the system load is low. It also lets you delegate the task of running reports or programs to the system. Your dialog sessions are not used, and reports that run in the background are not subject to the dialog-step run-time limit that applies to interactive sessions.

More information about background processing and the security measures to take are described in the following topics:

• Defining Users for Background Processing [Page 13]

• Specifying the Execution of External Programs from Job Steps [Page 13]

• Roles and Authorizations Used in Background Processing [Page 14]

For more information, see Background Processing [SAP Library] or Programming with the Background Processing System (BC-CCM-BTC) [SAP Library].


3 Background Processing

October 2005 13

3.1 Defining Users for Background Processing When defining users for background processing, note the following:

• Define specific users to use for background processing. Define them as system users (non-dialog) and give them only the necessary authorizations that are needed for the executed programs.

• Separate the authorizations needed for job definition and job execution.

The end user can define the job steps, but the administrator executes the job.

To define job steps that run under a different user, you need an authorization for the authorization object S_BTCH_NAM. S_BTCH_NAM determines which users you can choose when scheduling a job. You should give this authorization to the batch administrator only.

• Restrict the batch administrators to run job steps using only the previously defined batch users.

• Make sure that job steps cannot be executed using any of the super users (for example SAP*, DDIC).

3.2 Specifying the Execution of External Programs from Job Steps When you want to run an external program as a job step that is executed in a background process, the following steps are executed: ...

1. A request for the execution is sent from the background process via the dispatcher to the local instance gateway.

2. The gateway calls the program sapxpg with the requested external program as an argument. Depending on the location specified in the job step, the gateway starts sapxpg locally (using fork/exec) or remotely (using remote shell/remote execute mechanisms, offered by the operating system).

3. The program sapxpg starts the execution of the external program.

4. The external program is executed.

5. When the external program finishes control is given back to the program sapxpg.

6. The program sapxpg gives the control back to the gateway.

7. The gateway returns the results of the execution via the dispatcher to the batch work process.


3 Background Processing

14 October 2005

Since external commands called from background jobs have to pass through the gateway, the secinfo file can be used to disallow their execution. However, if you have specified a secinfo file and you want to allow the execution of external programs, you have to make an entry for the program sapxpg in the secinfo file. (See also Authorizations [SAP Library] in the RFC/ICF Security Guide.)

For the execution of external commands within background processing jobs, the user needs to have the appropriate authorization for the object S_LOG_COM.

3.3 Roles and Authorizations Used in Background Processing The roles provided contain authorizations.

The following predefined user roles are available: SAP_BC_BATCH_ADMIN

This role contains all authorizations for background processing administration, including the creation of background jobs and general administrations functions (SMxx transaction codes, in particular SM36, SM37, SM50, and SM51) Note that the administrator role includes operating system access due to the fact that the administrator can define operating system commands. For more information, see Logical Operating System Commands in this Guide.

SAP_BC_ENDUSER

This role contains non-critical basis authorizations for all users, including job creation and job release.

The table below shows the authorizations used in background processing:

Authorizations for Background Processing

Authorization Object

Fields Value Meaning

S_BTCH_JOB JOBACTION DELE Delete other users jobs

LIST (not used)

PROT Display job logs belonging to other users

RELE Release own jobs automatically

SHOW Display other users job definitions

JOBGROUP * Reserved, set to *

S_BTCH_NAM BTCUNAME <name> Authorized user when scheduling

S_BTCH_ADM BTCADMIN Y User is batch administrator

N or empty Restricted to jobs in current client


4 Print and Output Management

October 2005 15

In addition, note the following:

• A user with batch administrator privileges can do anything with jobs in all clients (authorization object S_BTCH_ADM, field “batch administrator” set to “Y”). Without this authorization, users can only work on jobs in the client in which they are logged on.

• All users can schedule, cancel, delete, and check the status of their own jobs with no additional special authorizations. However, additional authorizations are needed for:

Releasing one’s own batch jobs (S_BTCH_JOB: Action=RELE)

Showing logs of all jobs (S_BTCH_JOB: Action=PROT)

Assigning ABAP programs to a job step (S_PROGRAM)

Assigning a different user to a job step (S_BTCH_NAM).

A user without batch administrator privileges is restricted to working with class C (low priority) jobs and to his or her own jobs in the client that he or she is logged on to.

• Authorizations that allow a user to delete jobs or display information belonging to other users are:

Deleting the jobs belonging to other users (S_BTCH_JOB: Action=DELE)

Display job definitions and spool lists belonging to other users (S_BTCH_JOB: Action=SHOW)

• For the execution of external commands within jobs, the user needs an authorization for the object S_LOG_COM.

For more information, see SAP Notes 28162 and 101146.

4 Print and Output Management SAP provides its own print and output management component so that users do not have to deal with operating system-specific issues. SAP’s Spool component is used for outputting SAPscript texts and ABAP lists.

Roles Used in Print and Output Management

The following predefined user roles are available for customizing and administration:

• SAP_BC_SPOOL_ADMIN

This role contains full authorizations for the Spool administrator, who can define printers and administer TemSe , the temporary sequential data store. Note that spool administrators have operating system access due to the fact that they can define print control commands. For more information, see Logical Operating System Commands in this Guide.

• SAP_BC_ENDUSER

This role contains non-critical basis authorizations for all users, including spool request display and printout authorizations.

For more information, see OSS note 119147 and the SAP Printing Guide.


5 Alert Management (ALM)

16 October 2005

5 Alert Management (ALM) Alert Management (ALM) is an ideal solution if you can identify specific business or technical situations that are critical and could jeopardize efficient operation, and you want specific parties to be informed if these situations arise.

Defining Users in ALM

A communication user has to be created on the central alert server and assigned the role SAP_BC_ALM_ALERT_USER. For more information, see User Types.

Roles Used in ALM

The following predefined user roles are available for customizing and administration:

• SAP_BC_ALM_CUST

This role contains authorizations for alert management configuration.

• SAP_ALM_ADMINISTRATOR

This role contains authorizations for all configuration and administration activities. An administrator who has been assigned this role can also read and confirm alerts for other users. In addition, the administrator is authorized to delete, escalate, and deliver alerts as well as to delete logs.

• SAP_BC_ALM_ALERT_USER

This role contains authorizations for the sending of alerts via external communication methods (e-mail, sms, fax) and for inbound processing.

For more information, see the Authorization Concept section in the Alert Management documentation.

6 Central Monitoring with CCMS SAP’s CCMS monitoring infrastructure, part of any SAP NetWeaver installation, lets you centrally monitor any IT environments – from individual systems through networked SAP solutions to complex IT landscapes incorporating several hundred systems. It can be used immediately after installation. You can easily extend the infrastructure to include SAP and non-SAP components.

Defining CCMS Communication Users

Users with particular, restricted authorizations are required in all ABAP systems in your system landscape for communication between the central monitoring system (CEN), the monitored systems, and CCMS agents. RFC calls are triggered from CEN to monitored ABAP systems to pull monitoring data. If agents are used in monitored ABAP systems, data is pushed to the central system. Data from non-ABAB systems and non-SAP components is exclusively pushed to CEN by local agents. Agents require a communication user in CEN to be able to log on to it.

SAP recommends that you create and use the user CSMREG for this purpose in all relevant components. This user must be assigned the role SAP_BC_CSMREG. The user CSMREG is also used to register The CCMS System Component [SAP Library](SCR) with a central repository.

For more details on the CSMREG user and its authorizations, see Creating the CSMREG User [SAP Library].

For more information on users, see User Types.


6 Central Monitoring with CCMS

October 2005 17

Roles Used in Central Monitoring

The following predefined user roles are available for displaying, setting up and performing central monitoring functions and for communication:

• SAP_BC_BASIS_MONITORING

This role contains authorizations for displaying data for the central monitoring of an SAP system landscape using the CCMS monitoring infrastructure. Various SAP tools are used to do this (SMxx, RZxx, and STxx transaction codes).

• SAP_BC_BASIS_ADMIN

This role contains all authorizations for setting up and performing the central monitoring of an SAP system landscape using the CCMS monitoring infrastructure. Various SAP tools are used to do this (SMxx, RZxx, and STxx transaction codes).

• SAP_BC_CSMREG

This role must be assigned to a communication user required by agents reporting to the central monitoring system. It provides specific, greatly restricted logon authorizations for CCMS agents in the central monitoring system.

For more information, see the documentation Monitoring in the CCMS.

Authorizations Used in Central Monitoring

The role SAP_BC_BASIS_MONITORING contains the following authorizations:


Field Value

S_RFC RFC_FUGR FUGR

RFC_NAME SALC, SALF, SALF, SALH, SALP, SALS, SAL_CACHE_RECEIVE, SYST, SCSM*, SCCMSBI_UTIL_FUNCTIONS, RFC1, SPIS, SU53, SU56

ACTVT 16

S_SPI_AUTH ACTVT 03

S_TCODE AL08, AL11, OS07, RSPFPAR, RZ10, RZ20, RZ21, SICF, SM12, SM13, SM21, SICF, SM51, SM58, SM66, SMGW, SMICM, SMMS, ST02, ST03G, ST04, ST05, ST07, ST10, ST11, STAD, STATTRACE, TU02

S_CCM_RECV ACTVT P0, P1, P2

TABLE *

S_ADMI_FCD S_ADMI_FCD NADM, PADM, SM21, ST0M, ST0R

S_BTCH_JOB JOBACTION RELE

JOBGROUP *



18 October 2005


Field Value

S_CCMS_CMC ACTVT 03

CMCAREA BASIS

CMCFUNC APPSERV, CONFIG, HOST, SPIPROC, SYSTEM, WORKLOAD

S_CTS_ADMI

S_C_FUNCT ACTVT 16

CFUNCNAME *

PROGRAM *

S_DATASET ACTVT 33, A6

FILENAME *dev_*

PROGRAM *

S_ENQUE S_ENQ_ACT *

S_RZL_ADM ACTVT 03

S_TOOLS_EX AUTH

S_TRANSLAT ACTVT

TLANGUAGE

TRANSOBJ

S_ALV_LAYO ACTVT 23

Authorizations Used in Central Monitoring

The role SAP_BC_BASIS_ADMIN contains the following authorizations:


Field Value

S_ICFREC ACTVT 02, 03, 06, 16, 63, 70, D1, DL, UL

CLIENT *

SYSTEM *

USER *

ACTVT 16

S_SPI_AUTH ACTVT 03, 23

APPL_GROUP *



October 2005 19


Field Value

S_TCODE AL11, OS07, RZ03, RZ04, RZ10, RZ20, RZ21, SICF, SM01, SM02, SM04, SM12, SM13, SM21, SM21, SM28, SM35, SICFRECORDER, SM51, SM56, SM58, SM66, SMGW, SMGW, SMLG, SNL1, LST01, ST02, ST03, ST03N, ST03G, ST04, ST05, ST07, ST10, ST11, ST22, STAT, STAD, TU02, USMM

S_CCM_RECV ACTVT P0, P1, P2

TABLE *

S_ADMI_FCD S_ADMI_FCD *

S_BTCH_JOB JOBACTION RELE

JOBGROUP *

S_CCMS_CMC ACTVT 02, 03

CMCAREA BASIS

CMCFUNC APPSERV, CONFIG, HOST, DATABASE, SPIPROC, SYSTEM, WORKLOAD

S_CTS_ADMI CTS_ADMFCT *

S_DCC SDCC_DEV *

SDCC_RUN

S_DATASET ACTVT *

FILENAME *

PROGRAM *

S_ENQUE S_ENQ_ACT *

S_RZL_ADM ACTVT *

S_TOOLS_EX AUTH *

S_USER_GRP ACTVT *

CLASS *

S_TRANSLAT ACTVT *

TLANGUAGE *

TRANSOBJ *

S_ALV_LAYO ACTVT *


7 Security Guide for the SAP System Landscape Directory

20 October 2005

7 Security Guide for the SAP System Landscape Directory Purpose The SAP System Landscape Directory (SLD) is a J2EE application component that runs on the SAP Web Application Server. The SLD acts as the central information provider for all installed system components in your system landscape. For more information, see the SLD documentation [SAP Library].

Security Considerations The SLD contains specific data about each individual system landscape. This data must be protected from unauthorized access. This security guide contains recommendations for protecting your data and covers the following areas:

• Network topology []

• Use of Single Sign-On for the SLD [Page 22]

• Securing Connections to the SLD:

HTTP(S) Connections [Page 21]

RFC/JCo Connections [Page 22]

• Access Restrictions:

Application Access [Page 23]

User Access [Page 24]

7.1 Network Topology for the SLD Server The SLD contains information about your system landscape that is relevant for system management, business processes, and various application areas. In certain situations, systems that are accessible externally form business scenarios with internal back-end systems. These scenarios can involve the SLD. In this case, the SLD contains information about both external and internal systems.

You use e-business in systems that are in front of the firewall. These e-business systems communicate with back-end systems that are behind the firewall.

For security reasons, place the SLD server behind the firewall, and configure the firewall for RFC and HTTP connections. We recommend that you secure these connections by means of VPN or SNC.



October 2005 21

The figure below illustrates the recommended network topology for the SLD server.

Internal System Landscape

Internal SLD

SLD Bridge

InternalSystems

Public System(J2EE)

Public System (ABAP)

Public System

RFC

VPN / SNCHTTP

For more information, see Technical Infrastructure available in SAP Service Marketplace at service.sap.com/sld.

7.2 Securing HTTP(S) Connections to the SLD HTTP is the primary communication protocol that is used for exchanging data with the SLD. This applies to communication routes between the following:

• Web-based UI and the SLD server (see Configuring the Use of SSL on the SAP J2EE Engine [SAP Library])

• Clients that use the Java API for SLD [SAP Library] and the SLD server

• J2EE data suppliers [SAP Library] and the SLD bridge

• SLD bridge [SAP Library] that distributes system data and the remote SLD server

To secure these communication routes, we recommend that you use HTTPS.



22 October 2005

SLD Data Supplier for generic data sources (sldreg) To supply data to the SLD that originates from a system other than a J2EE or ABAP system, the executable sldreg is used. The sldreg sends data in XML format using a predefined DTD. For this purpose it uses an HTTP connection, as shown in the figure below:

HTTP

SAP

Gatew

ay

SLD B

ridge

SAP J2EE Engine

RFC

Server

HTTP

Servlet

sldreg

SLD

TREX

SAPOSCOL

…

XML

HTTP

SAP

Gatew

ay

SLD B

ridge

SAP J2EE Engine

RFC

Server

HTTP

Servlet

sldreg

SLDSLD

TREX

SAPOSCOL

…

XML

For example TREX, SAPOSCOL, etc. generate such an XML and register themselves at SLD via sldreg.

For more information on sldreg, see SAP Note 733476.

7.3 Securing RFC/JCo Connections to the SLD ABAP-based systems use RFC/JCo connections for communication with the SLD server. This applies to the following communication routes:

• Between an ABAP client [SAP Library] that uses the ABAP API for the SLD and the intermediary J2EE Engine

• Between data suppliers [SAP Library] for ABAP-based systems and the SLD server

In both cases, you can secure the RFC connections by using Secure Network Communication [SAP Library] (SNC). In addition, you can install the intermediary J2EE Engine on the same SAP Web AS instance so that the communication between the ABAP stack und the J2EE stack takes place locally.

7.4 Using Logon Tickets for Single Sign-On

Use The SLD supports the use of logon tickets for Single Sign-On.

Prerequisites • The J2EE Engine of the SLD is configured to accept logon tickets from all ticket-issuing

servers.

• The J2EE Engine of the SLD must have a public and private key pair and a public-key certificate, if the SLD acts as a ticket-issuing application.



October 2005 23

Activities Adjust the login module stack for the application component sap.com/com.sap.lcr*sld to enable the SLD to accept logon tickets (and issue them, if necessary).

Login Modules Flag

EvaluateTicketLoginModule SUFFICIENT

BasicPasswordLoginModule REQUISITE

CreateTicketLoginModule OPTIONAL

The login module stack in the table above enables the SLD to evaluate the user’s logon ticket first. If the user presents a valid logon ticket, the SLD accepts the logon and stops further processing. If there is no valid logon ticket, the SLD authenticates the user by using Basic Authentication and issues a logon ticket for the user, if the authentication succeeds. The login module CreateTicketLoginModule is only required, if the SLD has to issue logon tickets itself.

For more information about the configuration of Single Sign-On for the J2EE Engine, see Using Logon Tickets for Single Sign-On [SAP Library].

7.5 Application Access Restrictions Via the SLD Data Supplier Service the SLD provides a default HTTP(S) destination for applications deployed on a J2EE engine that wants to communicate with the central SLD system. Data sent via this destination should be protected using HTTPS. Additionally, in the configuration of the SLD Data Supplier Service you have to specify which applications are allowed to use this default destination.

For more information on configuring your user management, see on SAP Sevice Marketplace →sld → Media Library → SLD Post Installation-Guide.



24 October 2005

7.6 User Access Restrictions The SLD functions are protected from unauthorized access. There are several J2EE security roles (and corresponding UME actions) assigned to different SLD functions. UME actions are prefixed by com.sap.lcr.. For example, the UME action corresponding to J2EE role LcrUser is called com.sap.lcr.LcrUser.

There is no corresponding UME action for J2EE security role Data SupplierLD.

J2EE Security Role Permission

LcrUser Read Access to SLD data

Lcr Suopport Read-only access to all SLD data and UIs, including Administration pages

LcrClassWriter Create, modify and delete CIM classes (includes LcrUser)

LcrInstanceWriterLD Create, modify and delete CIM instances of the subset Landscape Description (includes LcrUser)

DataSupplierLD Create, modify and delete CIM instances of the subset Landscape Description as a data supplier without access to the SLD UI.

LcrInstanceWriterCR Create, modify and delete CIM instances of the subset Component Information (includes LcrUser)

LcrInstanceWriterNR Create, modify and delete CIM instances of the subset Name Reservation (includes LcrUser)

LcrInstanceWriterAll Create, modify and delete all types of CIM instances (includes LcrUser, LcrInstanceWriterCR, LcrInstanceWriterLD, LcrInstanceWriterNR)

LcrAdministrator Administrative tasks for both system and application (includes all other roles)

For more information on configuring your user management, see on SAP Sevice Marketplace →sld → Media Library → SLD Post Installation-Guide.


8 SLM Security Roles

October 2005 25

8 SLM Security Roles Use To protect the SLM from unauthorized access, as well as to provide a way of tracking the changes made in the system landscape, three security roles are defined. The SLM security roles are based on the User Management Engine (UME) role concept. The security roles in the SLM are analogical to the security roles in the SLD.

Features SLM Security Roles, Actions and Permissions

SLM Security Role

SLD and SLM Actions SLD and SLM Permissions

com.sap.lcr.LcrUser Read access to data in the SLD server and data in the local database

SlmViewer

tc~slm~permissions. View

• View system landscape data

• View plan data (not allowed to create, confirm and delete plans)

• View realized scenario data

• View plan and realized scenario data in a graphical mode (not allowed to make changes to a model)

• View solution data (not allowed to add and delete third-party solution data)

com.sap.lcr. LcrInstanceWriterAll

In addition, write access to data in the SLD server and data in the local database

SlmCreator

tc~slm~permissions. Create

In addition:

• Create, confirm and delete plans

• Make and save changes to a plan and realized scenario graphical model

• Add, save and delete third-party solutions data

com.sap.lcr. LcrAdministrator

Includes all other roles SlmAdministrator

tc~slm~permissions. Configure

Includes all other roles


9 Security Guide for ADK-Based Data Archiving

26 October 2005

Activities To create SLM security roles: ...

1. Create SLM users.

2. Create SLM roles and assign the corresponding SLD and SLM actions to the SLM roles.

The SLD and SLM actions are defined in the UME.

3. Assign the SLM users to the SLM roles.

For more information about managing security roles, see User Management Administration Console [SAP Library] and Role Management [SAP Library].

9 Security Guide for ADK-Based Data Archiving ADK (Archive Development Kit) is an established ABAP technology used for data archiving. It is employed to extract dormant data from growing databases and provide long-term access to this archived data. For data archiving for JAVA applications and XML-oriented ABAP applications, SAP has developed a new technology. For more information on security aspects related to XML-based archiving see Security Guide for XML-Based Data Archiving [Page 29].

ADK-based archiving relies on two main elements, which are used for the development and administration of archiving solutions: Archive Development Kit (ADK) and Archive Administration (transaction SARA). ADK and SARA are part of the standard SAP Web Application Server. ADK is the Application Programming Interface used by the applications to develop archiving solutions, while Archive Administration (transaction SARA) is used mainly by data archiving administrators to manage all tasks related to data archiving, including job scheduling and management, writing, reading and deletion of data, as well as Customizing.



October 2005 27

Technical System Landscape: Security-Relevant Interfaces The following figure shows the different elements involved in ADK-based data archiving, and the interfaces that connect these elements.

File system ArchiveLink system3

2

ADKArchivingPrograms

SAP WebAS

ADK

Archive Admin.(SARA)

11

SAP AS(SARI)

1


• Interfaces 1: End user and data archiving administrator accessing the ABAP application system, Archive Administration (transaction SARA), and the Archive Information System (SAP AS).

• Interfaces 2: File system interface for ABAP applications.

• Interface 3: ArchiveLink interfaces.



28 October 2005

Interface 1 Here end users and data archiving administrators access the ABAP application system and use Archive Administration (transaction SARA) and the Archive Information System (SAP AS).

• Archive Administration

There are two levels of security checks involved for end users and administrators trying to execute archiving programs. Within Archive Administration (transaction SARA) and on the ADK side authorization object S_ARCHIVE checks what kind of authorization the user or administrator has, when ADK detects that a write, delete, read or reload action is being started. It is possible to make S_ARCHIVE more application specific by using an archiving object as one of its parameters.

On the application side it is possible to restrict authorization further, to certain fields, for example. This is mainly valid for display functions and depends on the application.

For more information about S_ARCHIVE, see User Authorization Checks [SAP Library] under the ADK documentation.

• Archive Information System

A specific authorization object does not exist for the Archive Information System, because it is a generic tool used by different applications. The following authorizations are needed as part of SAP AS:

Transaction SARI: for transaction SARI you need the authorization

S_ARCHIVE[ACTVT -> 3; APPLIC -> applic; ARCH_OBJ -> object]

object is the archiving object to which the infostructure belongs. applic is the application area belonging to the archiving object, which can be found in the field of transaction AOBJ.

Creating or changing infostructures: authorizations

S_TABU_DIS[ACTVT->02; DICBERCLS-> BS] S_TABU_CLI[CLIIDMAINT->X]

For the transport of the changes

S_TRANSPRT[TTYPE->UPGR; ACTVT->70]

Activating an infostructure, filling or deleting infostructures: authorizations

S_ARCHIVE[ACTVT-> 02; APPLIC-> applic; ARCH_OBJ-> object,]

Display of data in Archive Explorer: As mentioned, SAP AS is a generic tool and it is therefore not possible to deliver application-specific authorization checks for the display of data from the archive information structure, either. It is, however, possible to implement user exits to run application-specific authorization checks (see SAP Notes listed below).

For the technical view the system runs the same authorization check for displaying data, as the Data Browser (transaction SE16).

For business views, also called application-specific views, the authorization check of the corresponding application is run, before data can be displayed.

For more detailed information on the above-named points see the following SAP Notes:

175901 – Insufficient authorization checks in the Archive Information System

156336 - Authorization object S_ARCHIVE for status management


10 Security Guide for XML-Based Data Archiving

October 2005 29

Interface 2 This is the interface between the ABAP application system and the file system. During ADK-based data archiving archive files are written to a file system. Here the relevant security aspects focus on the following issues:

• Protection against exchange and corruption of archive files

During the write session ADK creates and saves the name of the archive file, under which it is written to the file system. Later this name is used for read accesses to the archive file.

To ensure that the file being accessed is the original file under the correct name, ADK creates an additional file key that is saved within the archive file. This then ensures that the file you are accessing is the file that was originally written to the file system.

To ensure that the file being accessed has not been modified in any way, you can use check sums. These are used during the write phase and should be switched on for the read, delete and reload programs, as well. You can switch on these checks in Cross-Archiving-Object Customizing [SAP Library] under Check Access for Archive Selection.

• Protection against unauthorized read accesses to archive files

There are three levels where unauthorized accesses to archive files are prevented:

Operating System – access to archive files created by ADK is only granted to the technical SAP system user known to the Operating System.

For more information see Operating System Security [SAP Library].

Authorization object S_DATASET – this authorization object checks that the SAP user has the necessary authorizations to be able to read files from an SAP system.

SAP-specific file format – ADK creates archive files in an SAP-specific compressed file format, which can only be read within an SAP system.

Interface 3 The ArchiveLink interfaces are used as a communication interface between SAP Web AS and storage systems. It facilitates the transfer of archive files to storage systems. For more information on this topic see ArchiveLink [SAP Library] or Content Management System.

10 Security Guide for XML-Based Data Archiving The XML-based data archiving technology complements ADK, an established technology used for data archiving. Both are employed to extract dormant data from growing databases and provide long-term access to this archived data. However, as the name states, XML-based archiving was designed for new XML-oriented ABAP and all JAVA applications.

XML-based archiving relies on the XML Data Archiving Service (XML DAS), which is part of a standard J2EE system installation of the SAP Web Application Server. If an application wants to use XML DAS it can do so with the help of an XML DAS Connector for either ABAP or JAVA, depending on its requirements. This documentation deals with the security aspects for new XML-based ABAP archiving objects and JAVA-implemented archiving sets that communicate with the SAP J2EE Engine’s XML DAS.



30 October 2005

Technical System Landscape: Security-Relevant Interfaces The following figure shows the different elements you need for XML-based data archiving, and the interfaces that connect these elements.

service XML Data

Archiving

Service

(XML DAS)service

J2EE Engine of SAP WebAS

XML DAS Adminis-

tration

XML Archive API

ABAP XMLArchivingPrograms

WebAS / ABAP

XML DAS Conn for ABAP

LocalArchive Admin.

XML Archive API

JAVA XML ArchivingPrograms

WebAS / JAVA

LocalArchive Admin.

XML DAS Conn for JAVA

1

WebDAV system File system

2

1 J

3

2 J

54

UME

The divisions shown in the figure are conceptual and are meant to clarify the different elements involved in XML-based archiving. In a realistic scenario it is entirely possible that the ABAP and the JAVA elements run within one SAP Web AS system, or even that the SAP J2EE Engine of which the XML DAS is a part, is also installed on the same SAP Web AS system. Likewise, the figure does not mean to imply that a WebDAV system and a file system both have to be installed for XML-based archiving. It is possible to be using only one of the two to store archive files.


• Interfaces 1 and 1J: End users and data archiving administrator(s) accessing the ABAP or JAVA application systems.

• Interfaces 2 and 2J: Communication interface between the ABAP or JAVA application system and the J2EE system hosting XML DAS.

• Interface 3: User interface for XML DAS administrator(s).

• Interface 4: WebDAV interface between XML DAS and the external WebDAV-enabled storage system (WebDAV system).

• Interface 5: File system interface.



October 2005 31

User Authorization and Client Authentication

Interfaces 1, 1J and 3 These are interfaces where individual users can access the system. These users can be any of the following:

• The end user and the data archiving administrator of the local application system (interfaces 1 and 1J).

End user security is handled application-specifically, meaning that access to archived data is restricted according to archiving-object-specific or archiving-set-specific authorizations. The main task of the data archiving administrator is to configure, schedule and monitor the archiving process. However, if enabled by applications, administrators can also be allowed to display archived data in a technical form. The user names are not predefined.

For the ABAP data archiving administrator, the system checks the following:

Does the logged-in user have the authorizations required by authorization object S_ARCHIVE to start Archive Administration (transaction SARA) and to work with the chosen archiving object? For more information about S_ARCHIVE, see User Authorization Checks [SAP Library] under the ADK documentation.

Is the logged-in user allowed to display archived resources from archive management in transaction SARA, according to the application-specific authorizations documented by the corresponding XML archiving object? These authorizations are checked using the BAdI XML_DAS_AUTH_CHECK.

The S_ARCHIVE authorization object is also used by the XML archive API to check that the user has the correct authorization to perform an action. This means that even if the XML archiving programs are scheduled externally (outside of transaction SARA) the same S_ARCHIVE checks take place.

For current JAVA archiving sets, an application-independent local archive administration has not yet been released. Consult the documentation of the archiving sets you are using.

• The XML Data Archiving Service administrator (interface 3)

The XML DAS Administration is a browser application started via the following http address:

http://<Host of SAP J2EE Engine>:<HTTP port>/DataArchivingService/DAS

For example: http://localhost:50000/DataArchivingService/DAS

The data archiving administrator can be any user that is known to the SAP J2EE Engine. In order for the user to be valid, it must be assigned to the security role XMLDASSecurityRole. The security role is assigned in the Security Provider for the component sap.com/tc~TechSrv~XML_DAS*DataArchivingService using the Visual Administrator of the SAP J2EE Engine. In the Security Provider choose the tab strip Policy Configurations and then Security Roles. The assignment to the security role can be done either directly or via a group. For information on how to do this see J2EE Engine User Management Using the Visual Administrator [SAP Library].

Note: The procedure for creating a user and assigning it to a security role depends on the SAP Web Application Server installation option. For more information see Installation Options [SAP Library].



32 October 2005

Add-in installation

a. Create a user via the ABAP transaction SU01. We recommend that you create a dialog user (type A).

For more information see Creating and Maintaining User Master Records [SAP Library].

b. Assign the user you created to a role of your choosing. You could create a new role for this purpose, called for example Z_XMLDAS_ADMIN, using transaction PFCG.

c. Assign this role, which appears under “Groups” in the Security Provider of the Visual Administrator (see above), to the security role XMLDASSecurityRole.

Standalone J2EE Engine installation (assuming the users are stored in the database of the J2EE Engine)

d. Create a user using the Visual Administrator. In the Security Provider choose the tab strip User Management then Create User.

e. Assign the user you created to the Security Role XMLDASSecurityRole. In the Security Provider for the component sap.com/tc~TechSrv~XML_DAS*DataArchivingService choose the tab strip Policy Configuration then Security Roles.

Interfaces 2, 2J, 4 and 5 These interfaces are used for technical communication only:

• Interface 2 and 2J: You can use any of the HTTP authentication methods supported by the participating client system (the system hosting the XML DAS Connector) and the SAP J2EE Engine, such as Basic Authentication, Basic Authentication with SSL (HTTPS), or Client Certification.

The technical communication users must be known to the SAP J2EE Engine and must have been assigned to the security role XMLDASSecurityRole (see above). If you are using an add-in installation, we recommend you choose a system user (type B) instead of the dialog user we recommend for the administration. Assign this user to a specific role that you can create; an appropriate role name would be for example Z_XMLDAS_CLIENT.

If HTTPS is used, the HTTP SSL port must be specified in the destination instead of the HTTP port. For more information see Configuring the Use of SSL on the SAP J2EE Engine [SAP Library].



October 2005 33

The places to set up the connection depend on whether archiving objects (ABAP) or archiving sets (JAVA) are used in the application system:

Creating an HTTP destination for XML DAS using transaction SM59 (applicable for XML archiving objects in the ABAP environment):

RFC destination: <new name> (for example: XML_DAS)

Connection type: G (HTTP connection to an external server)

Description: <description> (for example: J2EE Engine running XML DAS)

Technical settings:

Target host: <address of J2EE Engine host>

Service No.: <HTTP Port or HTTP SSL Port>

PathPrefix: /DataArchivingService/DAS

Logon/Security

Security Options: for example Basic Authentication, SSL inactive

Logon: User: <UME user assigned to security role XMLDASSecurityRole>

Password: <corresponding UME password>

If you want to use HTTPS refer to Types of Destinations (Connection Type G) [SAP Library] and Using the Trust Manager [SAP Library].

Creating an HTTP Destination for XML DAS using the destination service of the SAP J2EE Engine (applicable for archiving sets [SAP Library] in the JAVA environment):

...

...

...

1. Open the J2EE Engine Visual Administrator for the SAP J2EE Engine.

2. For every server that has to send requests to the XML DAS, choose services → Destinations.

3. Create a new HTTP destination.

4. Choose DASdefault as the name for the destination.

5. Specify the URL such as http://<name of host running the DAS>:<HTTP-Port>/DataArchivingService/DAS,

(for example http://mainarchive.mycompany.corp:50000/DataArchivingService/DAS).

6. Choose “BASIC” as Authentication method.

7. Enter a username and password.

8. Save the settings.



34 October 2005

If you want to use HTTPS instead of Basic Authentication, proceed as follows: ...

1. Create a new destination as described above. Make sure that you enter the SSL-Port in the URL (for example 50001 instead of 50000).

2. For the authentication method enter X.509 Client Certificate.

3. Under Client Certificate Authentication, choose service-ssl as keystore view and select the appropriate credentials.

4. Save the settings and update the customizing of the XML DAS Connector for Java with the new destination name.

• Interface 4: The WebDAV protocol is used to store resources, that is, their actual content, on long-term storage systems or archive systems. The SAP J2EE Engine authenticates against a WebDAV system only using Basic Authentication without SSL. To enter or change the user name and password, use the J2EE Engine Visual Administrator. From the Cluster tab strip, choose

<System ID> → <Server> → Services → configuration Adapter

then choose

Configurations → apps → sap.com → tc~TechSrv~XML_DAS → appcfg → Propertysheet application.global.properties

Under the following entries enter a user name and password of your choice:

WEBDAVCLIENTUSR = <for example xmldas>

WEBDAVCLIENTPWD = <for example sap630>

• Interface 5: If you decide to store your resources in a file system that is accessible from the SAP J2EE Engine, you can do so by specifying the directory using the XML DAS administration (function Define Archive Stores).

Users The following table is a summary of users needed for XML Archiving:

System User(s) Delivered Type Default Password

XML Data Archiving Service Administrator(s) (SAP J2EE Engine)

(has to be defined in SAP NW Web AS and assigned to security role XMLDASSecurityRole)

No Individual administrator(s)

(has to be defined in SAP NW Web AS)

XML Data Archiving Service Communication (SAP J2EE Engine)

(has to be defined in SAP NW Web AS and assigned to security role XMLDASSecurityRole)

No Technical user(s)

(has to be defined in SAP NW Web AS)

WebDAV System connected to a SAP J2EE Engine

(has to be defined in configuration property)

No Technical user (has to be defined in configuration property)



October 2005 35

Data Storage Security The XML DAS collection hierarchy, properties and other meta data are stored in the J2EE database. The XML DAS uses the database pool alias SAP/BC_XMLA. For further details see Security Aspects for the Database Connection [SAP Library].

The collections and resources are stored in a WebDAV system or in a file system (see above). If a file system is used, directories and files are created by the SAP J2EE Engine. More specifically, the user employed for a Windows systems in this case is SAPService<sid> and for UNIX systems <sid>adm. Therefore, the directory needs to have the appropriate access privileges. See also: Operating System Security [SAP Library].

To prevent unauthorized access or harmful alteration or deletion of resources or directories in the file system, give the appropriate access privileges only to SAPService<sid> or <sid>adm, respectively. Do not manually create or delete directories or files once the archive store root directory is fixed.

In order to verify (on read request) that the content of archived resource has not changed, SAP recommends that you use the check sum option.

In ABAP you can find this function in Archive Administration (transaction SARA) by choosing Customizing → Configuration of the XML DAS: Check Sum

Trace and Log Files Trace and log files are written for the XML DAS and the XML DAS Connector for Java by the SAP J2EE Engine:

• The log file for the XML DAS is located in the log directory of the server running the XML DAS in the applications.log file under the category /Applications/Common/Archiving/XML_DAS.

• Traces for the XML DAS are written in the default trace file using the location com.sap.archtech.daservice.

• The log file for the XML DAS Connector for Java is located in the log directory of the server running an archiving application in the applications.log file under the category /Applications/Common/Archiving/Connector.

• Traces for the XML DAS Connector for Java are written in the default trace file using the location com.sap.archtech.archconn.

For XML archiving objects, the usual job logs are written by the XML DAS Connector for ABAP. In addition, for every explicit deletion of a resource or a collection, a system log entry (syslog) is created with message ID DA1 and problem class S (operation trace), which documents the deletion of the resource or the collection.


11 Auditing and Logging

36 October 2005

11 Auditing and Logging SAP Systems keep a variety of logs for system administration, monitoring, problem solving, and auditing purposes. Audits and logs are important for monitoring the security of your system and to track events in case of problems.

In the following topics, we discuss the importance and uses of the following auditing tools and logs. Sources of additional information are also included.

The Audit Info System (AIS) []

The Security Audit Log [Page 37]

Example Filters [Page 37]

The System Log [Page 40]

Statistic Records in CCMS [Page 42]

Logging of Specific Activities [Page 42]

Application Logging [Page 43]

Logging Workflow Execution [Page 43]

Logging Using Change Documents [Page 43]

Logging Changes to Table Data [Page 44]

Logging Changes Made Using the Change & Transport System [Page 44]

Logging Changes Made to User and Authorization Information [Page 45]

Additional Information on Auditing and Logging [Page 46]

11.1 The Audit Info System (AIS) The Audit Info System (AIS) is an auditing tool that you can use to analyze security aspects of your SAP System in detail. AIS presents its information in the Audit Info Structure (similar to IMG) so that you can easily determine which activities you need to perform and which you have accomplished. The following functions are available:

• Auditing procedures and documentation

• Auditing evaluations

• Audit data downloads

AIS is designed for business audits and systems audits. The Audit Info Structure is designed with these types of audits in mind and we deliver pre-defined views based on these auditing types. You can modify these views or develop your own, as you wish.

You access AIS with the transaction SECR.

AIS is available as a standard component as of Releases 3.1I and 4.6A. We do support the import of AIS into earlier releases. For more information on AIS and its availability, see the AIS information on the SAP Service Marketplace (http://service.sap.com/ais), the Audit User's Group (http://www.sap.com/germany/aboutSAP/revis/infomaterial.asp), and the SAP Notes 77503 and 100609.



October 2005 37

11.2 The Security Audit Log As of Release 4.0, you can use the Security Audit Log to record security-related system information such as changes to user master records or unsuccessful logon attempts. This log is a tool designed for auditors who need to take a detailed look at what occurs in the SAP System. By activating the audit log, you keep a record of those activities that you specify for your audit. You can then access this information for evaluation in the form of an audit analysis report.

The Security Audit Log provides for long-term data access. The audit files are retained until you explicitly delete them. Currently, the Security Audit Log does not support the automatic archiving of the log files; however, you can manually archive them at any time.

You can record the following information in the Security Audit Log:

• Successful and unsuccessful dialog logon attempts

• Successful and unsuccessful RFC logon attempts

• RFC calls to function modules

• Changes to user master records

• Successful and unsuccessful transaction starts

• Changes to the audit configuration

The audit files are located on the individual application servers. You specify the location of the files and their maximum size in the following profile parameters:

Profile Parameters for the Security Audit Log

Profile Parameter Definition Standard or Default Value

rsau/enable Activates the audit log on an application server.

0 (audit log is not activated)

rsau/local/file Specifies the location of the audit log on the application server.

/usr/sap/<SID>/<instno>/log/audit_<SAP_instance_number>

rsau/max_diskspace_ local

Specifies the maximum length of the audit log.

1,000,000 bytes

rsau/selection_ slots

Specifies the number of selection slots for the audit.

2

You specify the activities that you want to log in filters using the transaction SM19. You can read the log using the transaction SM20. You can delete old logs with the transaction SM18.

For examples of typical filters used, see Example Filters [].

For more information on the Security Audit Log, see Security Audit Log [SAP Library].

11.2.1 Example Filters Typical scenarios for using the Security Audit Log include:

• Recording specific security-critical events, for example, to monitor logon attempts using the standard user SAP*.

• Recording the activities that a specific user executes, for example, to monitor the activities performed by a remote support user.



38 October 2005

Filter for Recording All Security-Critical Events To set up a filter for recording all security-critical events, define a static filter with the following criteria defined:

Field or Group Entry

Client *

User *

Audit classes Activate all classes

Events Select Only critical

All critical events will be recorded for all users in all clients.

See the graphic below.

You can define the filter more specifically by choosing individual audit classes or entering more detailed data (for example, by entering SAP* as the User name.) Choose Detailed display to even more specifically define the various events to audit.



October 2005 39

Filter for Recording Activities Performed by a Specific User To set up a filter for recording security-critical events, define a dynamic filter with the following criteria defined:

Field or Group Entry

Client <client>

User <user_ID>

Audit classes Activate all classes

Events All

By defining the filter as dynamic, you can activate the filter for the time frame that the user works in the system and deactivate it when the user is finished (for example, for a remote support user).

The graphic below shows a filter that is activated to monitor the activities performed by the user SUPPORT in client 450.



40 October 2005

11.3 The System Log The SAP System logs all system errors, warnings, user locks due to failed logon attempts from known users, and process messages in the system log. There are to two different types of logs created by the system log:

• Local Logs

• Central Logs

Use transaction SM21 to access the system log output screen. With this transaction, you can read any of the messages that are contained in the system logs. You can modify the view to meet your needs.

Local Logs Each SAP System application server has a local log that receives all the messages output by this server. The system log records these messages in a circular file on the server. When this log file reaches the maximum permissible length, the system log overwrites it, starting over from the beginning. (The location of the local log is specified in the rslg/local/file profile parameter.)

Central Logs We recommend that you also maintain a central log file on a selected application server. Each individual application server then sends its local log messages to this server. The server that you designate to maintain the central log collects the messages from the other application servers and writes these messages to the central log.

The central log consists of two files: the active file and the old file. (The location of the active file is specified in the rslg/central/file profile parameter; the location of the old file is specified in the rslg/central/old_file.)

The active file contains the current log. When it reaches the maximum size, the system performs a "log file switch". It deletes the old log file, makes the previously active file the “old” file, and creates a new active file. The switch occurs when the size of the active log file is half the value as specified in the rslg/max_diskspace/central parameter. (Note: the SAP System does not support the saving of old system log files. If you want to save old logs, then you must archive them yourself.)

If you use Windows NT or AS/400, then note the following: − Central logging is not available on the Windows NT and AS/400 platforms. − Per default, the profile parameter rslg/collect_daemon/host should be

set correctly. However, if you receive warnings, then make sure that this parameter is set to NONE.

− For these platforms, you can use the All remote syslogs function from transaction SM21 to read the data of all the instances in your SAP System. In the alert monitor, if you receive an alert, you can use the Remote syslog function to analyze the affected instance.



October 2005 41

Profile Parameters and File Locations The table below shows some of the profile parameters for the system log along with their standard values:

Profile Parameters and File Locations for the System Log

rslg/local/file Specifies the location of the local log on the application server.

/usr/sap/<SID>/D20/ log/SLOG<SAP-instance_number>

rslg/collect_daemon/host

Specifies the application server that maintains the central log.

<hostname of main instance>

rslg/central/file Specifies the location of the active file for the central log on the application server.

/usr/sap/<SID>/SYS/ global/SLOGJ

rslg/central/ old_file

Specifies the location of the old file for the central log on the application server.

/usr/sap/<SID>/SYS/ global/SLOGJO

rslg/max_diskspace_ local

Specifies the maximum length of the local log.

500,000 bytes

rslg/max_diskspace_ central

Specifies the maximum length of the central log.

2,000,000 bytes

This is not a complete list. There are additional profile parameters that refer to the system logs; they all begin with rslg*. However, we do not discuss them all here. You can use the transaction RZ11 to access the rest of the parameters.

For more information, see System log [SAP Library].



42 October 2005

11.4 Statistic Records in CCMS SAP Systems also log activities categorized by transaction and user in statistical records. You can access these records with the transaction STAT.

Statistic records logging is controlled by the following profile parameters:

Profile Parameters for Statistic Records in CCMS

Parameter Description Default Permitted Value

stat/level Sets statistic record on or off

1 0: off

1: on

stat/version Version of statistic record

2 1: as in Release 2.2

2: additional RFC statistics and memory usage statistics

stat/file Location of the statistic records file

\usr\sap\<SID>\ <instance>\data\ stat.DAT

path name

Users who access global statistic records need an authorization based on the object S_TOOLS_EX in their profiles. Without this authorization, a user can only access his or her own statistic records.

For more information, see R/3 Accounting Interface [SAP Library].

11.5 Logging of Specific Activities SAP Systems log other specific activities in various logs. We discuss the following specific logs in the topics:

• Application Logging [Page 43]

• Logging Workflow Execution [Page 43]

• Logging Using Change Documents [Page 43]

• Logging Changes to Table Data [Page 44]

• Logging Changes Made Using the Change & Transport System [Page 44]

• Logging Changes Made to User and Authorization Information [Page 45]

A user with programming or debugging authorizations can evade these logs. Do not assign these authorizations in your productive system!



October 2005 43

11.5.1 Application Logging Application logging records the progress of the execution of an application so that you can reconstruct it later if necessary. Whereas the system log records system events, you can use the application log to record application-specific events. Use the transaction SLG0 to define entries for your own applications in the application log. Use the transaction SLG1 to analyze the application log.

The application log is a table structure consisting of several tables. Applications write their entries to these tables using SAP function modules. (These modules conform to the SAP authorization concept.)

You can also find out who accessed these function modules over a where-used list by using the report RSFKT100 (function group: SLG0).

For more information, see Create application log [SAP Library].

11.5.2 Logging Workflow Execution SAP Business Workflow is a cross-application tool that integrates transactions that span various applications.

The technology and tools needed to automate the control and processing of cross-application processes are included in the SAP Business Workflow functions, to include logging and analysis functions. These activities are not included in application logging.

The SAP Business Workflow analysis functions (such as the transactions SWI2 or SWI5) are also protected by the SAP authorization concept.

For more information, see WebFlow Engine (BC-BMT-WFM) [SAP Library].

11.5.3 Logging Using Change Documents Business data objects are changed frequently. We recommend that you log these changes for objects that are critical or susceptible to audits. You may find it helpful, and sometimes necessary, to be able to trace or reconstruct such changes later, for example for investigating or auditing purposes. SAP Systems log changes to business data objects in change documents.

SAP Systems do not automatically use change documents for business objects. You must activate the process yourself.

To activate a change document for an object, perform the following steps: ...

1. Create the change document. (Use the transaction SCD0.)

2. Activate the change document for the object. (Use data element maintenance: transaction SE11.)

3. Generate an update for the object. (Use the transaction SCD0.)

4. Insert the appropriate calls in the corresponding programs.

To view change documents for an object, also use the transaction SCD0.

For more information, see BC - ABAP Dictionary [SAP Library] and Change documents [SAP Library].



44 October 2005

11.5.4 Logging Changes to Table Data As with business objects, we recommend that you activate the logging of changes to table data for those tables that are critical or susceptible to audits. (See the SAP – Audit Guidelines R/3 FI, in Section 4.3.5, for examples of important tables. This document is available at http://www.sap.com/germany/aboutSAP/revis/infomaterial.asp.) You must also explicitly activate this logging. Note the following:

• You must start the SAP System with the rec/client profile parameter set. This parameter specifies whether the SAP System logs changes to table data in all clients or only in specific clients. We recommend setting this parameter to log all clients in your productive system.

• In the technical settings (use transaction SE13), set the Log data changes flag for those tables that you want to have logged.

If both of these conditions are met, the database logs table changes in the table DBTABPRT. (Setting the Log data changes flag only does not suffice in recording table changes; you must also set the rec/client parameter.)

You can view these logs using the transaction SCU3.

Although we do deliver pre-defined settings, you generally have to modify them to meet your own requirements. Use the report RSTBHIST to obtain a list of those tables that are currently set to be logged. Use transaction SE13 to change the Log data changes flag for these or other tables.

For more information, also see SAP Notes 1916 and 112388.

11.5.5 Logging Changes Made Using the Change & Transport System It is important to keep track of all changes made to your productive system. In addition to application logging, change documents, and table recording, all changes that you make to your productive system using the Change & Transport System are documented in the CTS and TMS logs.

The table below shows the logs created by the Change & Transport System.

Change & Transport System Logs

Log (File or SAP System Table) Description

<transport_directory>/data Data files containing the contents of the transport

<transport_directory>/cofiles Status files containing a list of the transport steps

<transport_directory>/log Logs containing the keys of the transported objects

Table E070 in the SAP System Header information for the transport request

Tables E071 and E071K in the SAP System

Object list and keys from table entries



October 2005 45

Because the transport directory is a central location that contains most of the transport information, we recommend you regularly archive its contents and keep the archives for auditing purposes.

In addition, the SAP System version management records a history of changes made to repository objects (programs and Data Dictionary objects). Changes to table data can be logged using the table recording mentioned in Logging Changes to Table Data [Page 44].

11.5.6 Logging Changes Made to User and Authorization Information SAP Systems log changes made by a user administrator in non-transparent tables in the database. Access to these tables is protected by the SAP authorization concept. Once these logs have been archived, they are deleted. (Use SAP archiving tools to archive these logs.)

Depending on your release, use either the Authorization Infosystem or transaction SU01 to access these logs. You can view the following changes:

• Changes made directly to a user's authorization.

These are changes made to the profile list in the user's master record. This does not include indirect changes that occur when authorizations or profiles are changed. View the change documents for the profiles and authorizations to check those changes.

• Changes to:

The user password (hashed representation only)

The user type

The user group

The validity period

The account number

• Changes made directly to profiles or authorizations.

For more information, see User Maintenance Functions [SAP Library].



46 October 2005

11.6 Additional Information on Auditing and Logging Type / Number Title

Audit Info System

SAP Note 77503 Audit Information System (AIS)

SAP Note 100609 Audit Information System (AIS) - installation

SAP Internet SAP Arbeitskreis Wirtschaftsprüfung und Revision (SAP Auditors User's Group) http://www.sap.com/germany/discsap/revis/index.htm

SAP Service Marketplace SAP Audit Information System http://service.sap.com/ais

Security Audit Log

SAP Library Security Audit Log [SAP Library]

System Log

SAP Library System log [SAP Library]

Statistical Records

SAP Library R/3 Accounting Interface [SAP Library]

Application Logging

SAP Library Create application log [SAP Library]

Logging Workflow Execution

SAP Library WebFlow Engine (BC-BMT-WFM) [SAP Library]

Logging Using Change Documents

SAP Library BC - ABAP Dictionary [SAP Library]

Change documents [SAP Library]

Logging Changes to Table Data

SAP Note 1916 Logging table changes in R/3

SAP Note 112388 Tables are subject to logging

SAP documentation SAP – Audit Guidelines R/3 FI / MM

Logging Changes to User and Authorization Information

SAP Library User Maintenance Functions [SAP Library]