3 Security

This section details the ways in which SAP Data Services addresses enterprise security concerns, thereby
providing administrators and system architects with answers to typical questions regarding security.

Data Services relies on the Central Management Server (CMS) for authentication and security features. This
section highlights differences and additional information specific to your Data Services system.

For complete information about the security features provided by the CMS, see the SAP BusinessObjects BI
Platform Administrator Guide or the SAP BusinessObjects Information Platform Services Administrator Guide.

3.1 Data protection and privacy

SAP provides specific features and functions to support compliance with regard to relevant legal requirements,
including data protection and privacy.

Data protection is associated with numerous legal requirements and privacy concerns. In addition to
compliance with applicable data privacy regulations, SAP needs to consider compliance with industry-specific
legislation in different countries. SAP does not give any advice on whether the provided features and functions
are the best method to support company, industry, regional, or country-specific requirements. Furthermore,
SAP-provided information does not give any advice or recommendation in regards to additional features that
are required in particular IT environments. Make your decisions related to data protection on a case-by-case
basis, considering your given system landscape and applicable legal requirements.

 Note

In the majority of cases, SAP compliance with applicable data protection and privacy laws are not covered
by a product feature. SAP software supports data protection compliance by providing security features and
specific data protection-relevant functions, such as simplified blocking and deletion of personal data. SAP
does not provide legal advice in any form. SAP uses definitions and other terms in this document that are
not from any given legal source.

Be aware that SAP software places the data that you provide into trace logs, sample reports, and repositories
(side-effect data), and so on. In other words, your data finds its way into places other than output files. It is your
responsibility to delete this data.

In addition, the Data Services application does not run any virus scan applications on persisted data. To protect
persisted data we strongly recommend running your own virus scan software on any system that runs Data
Services.

Here are some examples of where Data Services uses customer data:

● When you enable the Trace all option, Data Services prints data in some log files.
● If a job using bulk load functionality fails, Data Services saves data files that contain customer data in the
Bulkload directory so you can review and analyze the data. The default bulk load location is
%DS_COMMON_DIR%/log/BulkLoader.

Administrator Guide
24 PUBLIC Security
 ● The smtp_to and mailer functions use mail ID numbers as input parameters. Data Services saves mail ID
numbers in the Data Services repository.
● Data Services places a sampling of customer data in the Data Services repository when the “full” option is
enabled during side-effect data generation for Global Address Cleanse (GAC) and Universal Data Cleanse
(UDC).
● The GAC sample report contains a sample of user address data.

3.2 Securing administrative functions

To ensure security for your Data Services environment, use a firewall to prevent unintended remote access to
administrative functions.

In a distributed installation, you need to configure your firewall so that the Data Services components are able
to communicate with each other as needed.

For information about configuring ports on your firewall, see your firewall documentation. Also see the “Port
assignments” topic in the Installation Guide

Related Information

Host names and port numbers [page 22]

3.3 Message client library

The Message Client libraries (Java and C++) used in real-time services, does not require authorization to
connect. Therefore, it is important to use caution when using these libraries.

For more information about using the Message Client library, see the SAP Data Services Integrator Guide.

3.4 Temporary cache files

In Data Services, temporary cache files are generated for a variety of functions and operations. Profiling, joins,
table comparison, sorting, lookup, and group_by are some examples. Because these files are not encrypted,
by default, care should be taken when working with confidential or other sensitive data. Both pageable and
persistent caches create data files that are not encrypted, by default.

Administrator Guide
Security PUBLIC 25
Temporary file location

The temporary files that Data Services creates are stored in %COMMON_DIR%/log/pCache/
<repository_string>/. These files can be secured using the appropriate permissions at the OS level.

Pageable cache and key data

The pageable cache option in a data flow stores data in temporary files that are removed automatically after a
data flow finishes executing.

Persistent cache

Data Services provides a datastore called Persistent cache. The data in persistent cache is not encrypted, and
it is your responsibility to secure it using OS file/directory permissions.

long data

When long data (BLOB or CLOB) data is large, the data is stored in temporary cache files.

If long data is cached (for a join, sort, or table comparison, for example), the cache file is deleted when the
data flow finishes executing.

A long data cache file is also deleted when the data is out of scope. For example:

● The data is loaded into a target.

● The data is filtered out by a Query transform.
● A long datatype is converted to a varchar.

3.4.1 Encrypting certain temporary cache files

There are types of temporary cache files that can be encrypted, if necessary. These include:

● Persistent cache datastore files

● Pageable cache data flow files
● Functions such as lookup, search_replace, distinct, group_by, and so on.
● Transforms such as Data Quality transforms and Table Comparison

To enrypt these files:

1. Open the DSConfig.txt file, located in %DS_COMMON_DIR%\conf.

2. Set the pageable_cache_encrypt_data parameter, in the String section, to yes.

Administrator Guide
26 PUBLIC Security
 3. Save and close the file.

 Note

Encrypting these files can have a significant negative impact on performance. Remember that these files
are deleted immediately after the data flow finishes executing.

3.5 Configuring SSL or TLS for Data Services components

Secure Sockets Layer (SSL), and its newer version, Transport Layer Security (TLS), are cryptographic
protocols that provide security and data integrity for network communications.

Transport Layer Security (TLS) is the standard specification published by the IETF that is based on earlier SSL
specifications. Use TLS for Windows version 10 and higher.

The TLS protocol allows client/server applications to communicate across a network in a way designed to
prevent eavesdropping, tampering, and message forgery. TLS provides endpoint authentication and
communications confidentially over the network using cryptography.

3.5.1 Protected communication paths

Within the SAP Data Services platform, SSL is supported for all communication paths between components
that communicate over a network.

The following diagram illustrates the communication channels within the Data Services architecture that
support SSL.

Administrator Guide
Security PUBLIC 27
  Note

All TCP/IP communication paths support SSL/TLS. Depending on your web application server
communication, clients using HTTP may switch to the HTTPS protocol.

For information about how to use SSL with Data Services 12.x Admin Console and 4.x Management
Console, see SAP Note 1423991 .

Additionally, when you use a server group and set the distribution level to “Sub data flow”, the TCP/IP
communication path between sub data flows on different job servers within the server group is also protected
by SSL.

Administrator Guide
28 PUBLIC Security
3.5.2 Default certificates

By default, a set of SSL certificates is created during installation for secure communication between Data
Services components.

You can choose to use your own certificates by configuring them after installation has finished. The default
certificates use 1024-bit RSA keys and are valid for 30 years.

Related Information

Using custom certificates [page 32]

Copying certificates in a distributed installation [page 29]

3.5.3 Copying certificates in a distributed installation

When different Data Services components are installed on different machines and each installation has its own
root and intermediate certificate authority (CA) configuration, you must manually copy the trusted certificates
from one machine to all other machines.

 Note

Trusted certificate files refers to root and intermediate CA certificate files. These files have a .crt
extension, and can be located in the <LINK_DIR>/ssl/trusted_certs folder.

 Remember

When you copy trusted certificates from one host machine to another, you must always copy the files to
and from the <LINK_DIR>/ssl/trusted_certs folder on each respective machine.

1. If the Job Server and Access Server are installed on different machines, configure the hosts with the new
certificates.
a. Copy the trusted certificates from the Access Server to the Job Server host.
b. On the Job Server host machine, run the following script to refresh the <LINK_DIR>/ssl/
trusted_certs/jssecacerts keystore file:
○ On Windows: <LINK_DIR>/bin/SetupJavaKeystore.bat
○ On UNIX: <LINK_DIR>/bin/SetupJavaKeystore.sh
This allows adapters that communicate with the Access Server to use the new certificates.
c. Copy the trusted certificates from the Job Server to the Access Server host.
d. Restart the job service on both the Job Server and Access Server host machines.
2. If the Access Server and Management Console are installed on different machines, configure the
Management Console host with the new certificates.
a. Copy the trusted certificates from the Access Server to the Management Console host.
b. On the Management Console host machine, run the following script to refresh the <LINK_DIR>/ssl/
trusted_certs/jssecacerts keystore file:

Administrator Guide
Security PUBLIC 29
 ○ On Windows: <LINK_DIR>/bin/SetupJavaKeystore.bat
○ On UNIX: <LINK_DIR>/bin/SetupJavaKeystore.sh
c. Restart the web application server that is hosting the Management Console.
3. If the Access Server and message client are installed on different machines, configure the message client
host with the new certificates.
a. Copy the trusted certificates from the Access Server to the message client host.
b. If the message client uses Java, import the trusted certificates into the keystore used by the message
client application.
For information about creating keystores, see the JDK help for the keytool command.
4. If the Job Server and job launcher or external scheduler are installed on different machines, configure the
job launcher or external scheduler host with the new certificates.
Copy the trusted certificates from the Job Server to the job launcher or external scheduler host.

 Note

If the scheduled job connects to multiple Job Servers through a server group, copy the trusted
certificates from all Job Servers within the group.

3.5.4 Enabling or disabling SSL on communication paths

Because Data Services uses multiple communication paths, there are different ways to enable or disable SSL
for any given path.

You may choose to enable or disable SSL for certain paths, depending on your security and performance
requirements.

Communication path Description

For adapter management You can configure SSL for adapter management by enabling
SSL support on your Job Servers. Enabling SSL for adapter
management protects the communication path used be­
tween your Job Servers and adapters, and message broker
clients.

To configure SSL on a Job Server, use the Server Manager.

Administrator Guide
30 PUBLIC Security
 Communication path Description

For real-time messaging You can configure SSL for real-time messaging by enabling
SSL support on your Access Servers. Enabling SSL for real-
time messaging protects the communication path used be­
tween your Access Servers and their real-time clients.

 Note
By default, SSL is enabled for real-time messaging. If
you disable it on an Access Server, be sure to disable it
on any message clients or adapters that communicate
with that Access Server.

 Note
SSL can be enabled or disabled on a per-server basis.
You are not required to configure it the same way for all
Access Servers.

To configure SSL on an Access Server, use the Server

Manager.

For peer-to-peer communication You can configure SSL for peer-to-peer communication by
configuring SSL for run-time resources. Enabling SSL for
run-time resources protects the communication path used
between different sub data flows running on different Job
Servers.

 Note
If you run multiple Job Servers within a server group,
configure SSL the same way on each Job Server.

To configure SSL for run-time resources, use the Server

Manager.

Administrator Guide
Security PUBLIC 31
Communication path Description

For other communication paths SSL is mandatory for some communication paths within the
Data Services architecture.

For example, SSL is always enabled on the communication

paths between a Job Server and the following clients:

● The Administrator application in the Management

Console
● Designers
● The job launcher
● Access Servers
● The job execution engine
● Other Job Servers within a server group
● The job service used for monitoring

You must ensure that each client has the correct certificates
in these situations, but there is no additional configuration to
perform.

 Note
You need to copy the certificates from the Job Server to
the Access Server, Management Console, and external
job launcher hosts. In all other cases, the certificates are
exchanged automatically.

Related Information

Using the Server Manager on Windows [page 89]

Using the Server Manager on UNIX systems [page 95]

3.5.5 Using custom certificates

While SAP Data Services includes a set of SSL certificates by default, you can also choose to use your own
certificates. Depending on the nature of your Data Services deployment, not all steps below may be required.

1. Generate certificates as needed, and have them signed by a trusted certificate authority (CA).
For more information, see the “Generating keys and sign certificates” section.
2. Copy all required certificates to the Data Services client machines.

 Note

Each Data Services client requires the certificates for all CAs in the certificate chain when validating the
certificate of the Data Services server. The certificates within a certificate chain are called trusted

Administrator Guide
32 PUBLIC Security
 certificates and must be present on the local machine. In most cases, the certificate chain is the same
for all clients, and therefore the same certificates must be present on all client machines.

3. If you are using Java-based clients, use the JDK keytool utility to generate a keystore containing the
trusted certificates.
4. Configure server certificate and keyfile paths with the Server Manager.
5. Configure certificates for the Designer.

a. Choose Tools Options within the Designer.

b. Navigate to the SSL category under Designer.
c. Specify the locations of the certificate file, the private key file, and the trusted certificates folder.
If you change any SSL options other than Use SSL protocol for profiler, you must restart both the Designer
and any Data Services servers.

Related Information

Configuring SSL paths [page 94]

Generating keys and signing certificates [page 33]

3.5.6 Generating keys and signing certificates

To use your own custom certificates for SSL security in Data Services, you must generate the certificates and
have them signed by a trusted certificate authority (CA), such as VeriSign.

1. Generate the RSA key and certificate using the openssl tool.

openssl req -config <DS_COMMON_DIR>\ssl\conf\openssl.conf -new -newkey rsa:

1024 -nodes -keyout <mykey.pem> -out <myreq.pem>

where <mykey.pem> is the name of the key file to generate, and <myreq.pem> is the name of the
certificate file to generate.

 Note

By default, openssl is installed to <DS_COMMON_DIR>\bin. For more information about available

options and commands, see the openssl documentation.

2. Send the RSA private key and certificate files to your external CA.
3. After you receive the signed certificate from your CA, use the Server Manager to specify the path to the
new certificate and private key file.

 Note

Trusted certificates from an external CA must be in PEM format. The signed certificates should be
copied to the <DS_COMMON_DIR>\ssl\trusted_certs directory.

Administrator Guide
Security PUBLIC 33
Related Information

Configuring SSL paths [page 101]

3.6 Configuring SSL for the CMS connection

You can use the Secure Sockets Layer (SSL) protocol for all network communications between SAP Data
Services clients and the Central Management Server (CMS).

To set up SSL for all CMS communication, you need to perform the following steps:

● Deploy the SAP BusinessObjects BI platform or Information platform services with SSL enabled.
● Create key and certificate files for each machine in your deployment.
● Configure the location of these files in the Central Configuration Manager (CCM) and your web application
server.

For Data Services, you also need to use the sslconfig utility to configure all components that log into the
CMS for SSL, including:

● Designer
● Job Servers
● External schedulers and the job launcher
● Management Console (if deployed to a different web application server than the SAP BusinessObjects BI
platform or Information platform services web tier)

 Note

For J2EE web application servers, configure SSL by modifying the startup script.

By default, the utility is installed in the following location:

● For Windows:
<INSTALL_DIR>\SAP BusinessObjects Enterprise XI 4.0\win32_x86\sslconfig.exe
● For UNIX:
<INSTALL_DIR>/sap_bobj/enterprise_xi40/<platform>/boe_sslconfig
Where <platform> matches your UNIX platform.

For more information about using sslconfig and configuring the CMS and its clients for SSL, see
“Configuring the SSL protocol” in the SAP BusinessObjects BI Platform Administrator Guide or the SAP
BusinessObjects Information Platform Services Administrator Guide.

3.7 SSL for Metadata Browsing and View Data Services

Use Secure Sockets Layer (SSL) protocol for all network communications between SAP Data Services, back
end engines, and EIM Adaptive Processing Server services.

The following EIM Adaptive Processing Server services use SSL:

Administrator Guide
34 PUBLIC Security
 ● Metadata Browsing Service
● View Data Service

Data Services provides the EIM Adaptive Processing Server services, but they are used by other SAP software
products, such as the Data Insight module of SAP Information Steward.

Data Services provides the keystore file and the trusted certificates file by default. The following table describes
each file.

File Description

Java Server keystore Contains a single key and all the certificates that are part of
the certificate chain involved in signing the key on the server
side. Password files for the Java Server keystore file and the
key are also required.

Data Services places the default keystore file and password

files in <LINK_DIR>\ssl\mds.

Trusted certificate Used for signing the key that is stored in the Java keystore
on the server side. The client side, the Data Services back
end engine, uses the trusted certificates to communicate
with the server.

Data Services places the trusted certificates in

<LINK_DIR>\ssl\mds\trusted_certs .

3.7.1 Configuring SSL for Metadata Browsing and View Data

Services
To enable and configure SSL communications for Metadata Browsing and View Data Services:

1. Log into the Central Management Console (CMC) as a user with administrative rights to the Data Services
application.
2. Go to the “Applications” management area of the CMC.
The “Applications” dialog box appears.
3. Right-click the Data Services application and select Settings.
The “Settings” dialog box appears.
4. In the drop-down list for Enable SSL communication for Metadata Browsing and View Data Services, select
“Yes”.
5. If you want to use the default keystore and certificates (that Data Services provides or that you generate
using the Data Services tool), take the following steps:
a. In the drop-down list for Use Default SSL Settings, select “Yes”.
b. Click Save.
6. If you do not want to use the default keystore and certificates and generated your own outside of Data
Services, take the following steps:
a. Ensure that your keystore is a Java keystore file that contains a single key with all the certificates that
are part of the certificate chain involved in signing the key. You must provide a password for the key
and a password for the keystore file.

Administrator Guide
Security PUBLIC 35
 b. Ensure that your keystore file exists in the <LINK_DIR>\ssl\mds folder and the corresponding
certificate files are placed under <LINK_DIR>\ssl\mds\trusted_certs folder.
c. If you have multiple Metadata Browsing Service or View Data Service instances associated with the
same CMS server, you must copy the keystore and certificate files to all the machines where these
instances are installed.
d. In the drop-down list for Use Default SSL Settings, select “No”.
e. In the KeyStore File box, enter the name of the KeyStore file that you want to use.
f. Enter the KeyStore password.
g. Enter the Key password.
h. Click Save.
7. Restart the EIM.AdaptiveProcessingServer as follows:
a. Go to the “Servers” management area of the CMC
b. Expand the “Service Categories” node and select “Enterprise Information Management Services”.
c. Select “EIMAdaptiveProcessingServer” in the right pane.
d. Click Action Restart Server .

3.7.2 Creating a keystore file and certificates using the Data

Services tool

While SAP Data Services provides a keystore file and set of SSL certificates for the Metadata Browsing Service
and View Data Service, you can also create a new key and certificates using the Data Services tool.

To create a new keystore file and SSL certificates to be used as the default SSL settings for the Metadata
Browsing Service and View Data Service:

1. Run the MDSSetupJavaKeyStore tool.

a. In a command-line window, change directory to <LINK_DIR>\bin.

cd <LINK_DIR>\bin

b. Run "MDSSetupJavaKeyStore.bat "

MDSSetupJavaKeyStore

The MDSSetupJavaKeyStore tool creates the following files:

○ Keystore file DSJavaKeyStore.keystore in <LINK_DIR>\ssl\mds containing a single key and all
the certificates that are part of the certificate chain involved in signing the key
○ File sslks.key in <LINK_DIR>\ssl\mds containing the key password
○ File sslstore.key in <LINK_DIR>\ssl\mds containing the keystore password
2. If you already configured and enabled SSL for Metadata Browsing Service and View Data Service, restart
the EIM.AdaptiveProcessingServer.
The restart picks up the new keystore and certificate files as the default ones if you selected “Yes” for the
option Use Default SSL Settings.
3. If you have not yet configured SSL for these services, see Configuring SSL for Metadata Browsing and View
Data Services [page 35].

Administrator Guide
36 PUBLIC Security
3.8 Password encryption

Within the SAP Data Services system, all passwords are encrypted using the AES algorithm with 128-bit keys.

3.8.1 Encryption key storage locations

Because passwords can be stored in multiple places within the Data Services system, an individual key is
associated with each storage location.

Password location Associated key location

Local repository REPOKEY column in the AL_VERSION table

Central repository REPOKEY column in the AL_VERSION table

Management Console admin.key located in the same directory as admin.xml

Access Server AS.key located in the same directory as AS.xml

Adapter SDK <DS_COMMON_DIR>/adapters/adapter.key

DSConfig.txt <DS_COMMON_DIR>/conf/DSConfig.key

Data Services-managed schedules If the schedule uses a password file, the password is stored in the password file.

If the schedule does not use a password file, the password is located in the job
command line.

External scheduler command lines If the schedule uses a password file, the password is stored in the password file.

If the schedule does not use a password file, the password is located in the job
command line.

 Caution

For encryption keys that are stored in files, Data Services protects the security of the key file with strong OS
permissions. For example, the software sets owner-only read & write access to the file (chmod 600 on
UNIX systems). You should also protect the key file by restricting user access to the server host machine
when possible.

3.8.2 Encrypting passwords manually

In most instances, password encryption is handled automatically by the various Data Services applications and
utilities. However, for some tasks, you may need to manually encrypt a password. For example, you may want
to generate a data flow on the fly for use with the object creation XML toolkit. If your data flow contains a
datastore that requires a password, it needs to be encrypted before you can import and run it successfully.

When you need to manually encrypt a password, you can use the al_encrypt command-line utility installed
with the software.

Administrator Guide
Security PUBLIC 37
Related Information

Password encryption [page 174]

3.9 Password protection for a Data Services repository

When you log in to the Data Services Designer or open a Data Quality report in the Management Console, by
default, you are prompted to enter the user name and password for the Data Services repository you are
accessing. You can turn off this default behavior by granting permissions in the BI Platform or Information
platform services Central Management Console.

In the CMC, when you grant the Allow user to retrieve repository password right, the Data Services' repository
password will be sent from the CMS to the client (Designer or Management Console: DQ reports). Although
this password is encrypted, and the communication channel can be secured through SSL, sending passwords
could pose a risk, and malicious users could obtain access to the password. You can selectively grant this right
for repositories. For example, you may want to grant the right for development repositories but not for
production repositories.

Related Information

Repository management [page 45]

Designer Guide: Logging into the Designer
Management Console Guide: Data Quality reports

3.9.1 Setting Data Services repository permissions in the

CMC

Use the following steps to add permissions for users to automatically retrieve the Data Services repository
password when logging on to the Designer and for accessing Data Quality reports.

1. On the Home page of the CMC, click Data Services.

2. On the left side of the CMC, select Repositories.

3. Choose Manage Security User Security .

4. Select the Data Services Designer Users group (for Designer access) or the Data Services Monitor Users
group (for Data Quality reports access), and then click the Assign Security button.
5. In the Assign Security window, click the Advanced tab.
6. Click Add/Remove Rights.
7. On the left of the Add/Remove Rights window, click Application, and select Data Services Repository.
8. Under Specific Rights for Data Services Repository, select Granted for either or both of the following
options:

Administrator Guide
38 PUBLIC Security
 ○ Allow user to retrieve repository password
○ Allow user to retrieve repository password that user owns
9. Click OK.

By following the preceding steps, you have given all users in the Data Services Designer Users group (or the
Data Services Monitor Users group) permissions for all Data Services repositories.

 Note

If you have a Data Services development or test repository, for example, to which you would like to restrict
access, you can do this on a case-by-case basis. To do this, access the Add/Remove Rights window using
the following steps:

1. On the Home page of the CMC, click Data Services.

2. On the left side of the CMC, select Repositories, and then select the repository that you want edit rights
for.
3. Continue with step 3 above to complete your task.

Administrator Guide
Security PUBLIC 39