Data Storage Security for the Enterprise Services Repository

Data Storage

You use the ES Repository to maintain all aspects of an integration scenario that can already be specified at design time. ES Repository data is structured according to different object types, such as, service interfaces, data types, or process integration scenarios.

These objects are referred to as design objects .

In particular, the ES Repository contains design objects for the following areas:

• Process models (for example, process integration scenarios)

• Service definitions (for example, service interfaces and data types)

• Mapping objects (for example, message mappings)

• Other objects relevant for SAP Process Integration, for example, adapter metadata

More information: Managing Services in the Enterprise Services Repository

Type of sensitive data which can be can be contained in design objects, depends on the business processes that are modeled and specified in the ES Repository. In the following, we list those design object types where sensitive data can be stored.

• Subscriptions to interface objects

  User can subscribe to an interface object if they want to receive e-mail notifications of changes made to the object. E-mail addresses contained in these subscriptions can be considered as sensitive and are visible to all users who have access authorization for the corresponding interface object. This data is not encrypted on the database.

  More information: Managing Subscriptions

• Mappings

  Mapping programs can contain sensitive data in because they might contain expressions based on payload content. In particular, be aware of the fact that sensitive data may be “hard-coded” in mapping programs and stored un-encrypted in the ES Repository. Be also aware of the fact that external mapping programs can be imported into the ES Repository.

  Therefore, we recommend that to define particularly strict authorizations for the following tasks:

  • Import of mapping programs into the ES Repository

  • Access to mapping objects

  For more information on how to define these authorizations, see below.

  More information: Mapping Messages to Each Other Using Mapping Objects

Data Protection

There are a number of measures in order to increase data security.

Encrypting Data

Data stored in the ES Repository database is not encrypted.

Reducing Storage Duration of Data

There is no automatism to clean up the ES Repository database regularly. Design objects must be deleted manually.

Deleting Data

Users with the corresponding authorizations can delete design objects.

However, make sure that deleted objects are activated after deletion. Otherwise, the data remains in the ES Repository database.

Access and Change Protection

You can prevent unauthorized users from accessing and changing sensitive data by assigning suitable authorizations.

There are the following options:

• Object type-dependent authorizations

  You can define authorizations for a specific set of design objects.

  Example

  For example, you can define a role and assign to this role full access to all interface objects and only read access to mapping objects.

  More information: Role-Based Authorizations in ES Repository and Integration Direc

• ACL-dependent authorizations

  You can define authorizations based on access control lists (ACLs).

  An ACL is a list of permissions that can be attached to an object or a set of objects.

  More information: ACL-Based Authorizations

Usage profiles as a special kind of filter allow to restrict the set of objects in ES Repository to the requirements of the user.

More information: Usage Profile

Logging Data Access

There are the following options to log access to data:

In the object editor of a design object, choose  <name of object type>  History . The versions of the object are displayed as well as information about when the version was created and by which user. You can also open individual versions of an object from the version history.