WebSphere Application Server Considerations for GDPR readiness

Consider information about WebSphere® Application Server features that you can configure and aspects of product use so that you can prepare your organization for General Data Protection Regulation (GDPR) readiness.

Applicable PID(s): 5724-J08, 5724-H88, 5655-W65, 5724-I63

The WebSphere Application Server considerations for GDPR apply to the following PIDs:

  • 5724-J08 IBM WebSphere Application Server
  • 5724-H88 IBM WebSphere Application Server Network Deployment
  • 5655-W65 IBM WebSphere Application Server for z/OS
  • 5725-L29 IBM WebSphere Application Server Liberty Core
  • 5724-I63 IBM WebSphere Application Server - Express
  • 5725-A25 IBM WebSphere Application Server Hypervisor Edition for AIX
  • 5725-A11 IBM WebSphere Application Server Hypervisor Edition Novell SLES, System z - Novell Subscription Required
  • 5725-A12 IBM WebSphere Application Server Hypervisor Edition Novell SLES, System z - Novell Subscription Not Required
  • 5725-X89 IBM WebSphere Application Server Hypervisor Edition for Novell SUSE Linux Enterprise Server
  • 5725-A26 IBM WebSphere Application Server Hypervisor Edition for Red Hat Enterprise Linux
  • UT:32AEI WebSphere Configuration Migration Tool for IBM Cloud (WCMT4IC)

Notice:

This document is intended to help you in your preparations for GDPR readiness. It provides information about features that you can configure, and aspects of the product's use that you should consider to help your organization with GDPR requirements. This information is not an exhaustive list, due to the many ways that clients can choose and configure features, and the large variety of ways that the product can be used by itself and with third-party applications and systems.

Clients are responsible for ensuring their own compliance with various laws and regulations, including the European Union General Data Protection Regulation. Clients are solely responsible for obtaining advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulations that may affect the clients' business and any actions the clients may need to take to comply with such laws and regulations.

The products, services, and other capabilities described herein are not suitable for all client situations and may have restricted availability. IBM does not provide legal, accounting, or auditing advice or represent or warrant that its services or products will ensure that clients are in compliance with any law or regulation.

Table of Contents

  1. GDPR Overview
  2. Product Configuration for GDPR
  3. Data Life Cycle
  4. Data Collection
  5. Data Storage
  6. Data Access
  7. Data Processing
  8. Data Deletion
  9. Data Monitoring
  10. Responding to Data Subject Rights

GDPR Overview

The General Data Protection Regulation has been adopted by the European Union ("EU") and applies from May 25, 2018.

Why is GDPR important?

GDPR establishes a stronger data protection regulatory framework for processing of personal data of individuals. GDPR brings:

  • New and enhanced rights for individuals
  • Widened definition of personal data
  • New obligations for companies and organizations handling personal data
  • Potential for significant financial penalties for non-compliance
  • Compulsory data breach notification

Read more about GDPR:

Transform your business with the GDPR on ibm.com.

Product Configuration - Considerations for GDPR Readiness

The following sections provide considerations for configuring WebSphere Application Server to help your organization with GDPR readiness.

The GDPR legislation requires that personal data is strictly controlled and that the integrity of the data is maintained. This requires the data to be secured against loss through system failure and also through unauthorized access or by theft of computer equipment or storage media.

Data Life Cycle

GDPR requires that personal data is:

  • Processed lawfully, fairly and in a transparent manner in relation to individuals.
  • Collected for specified, explicit and legitimate purposes.
  • Adequate, relevant and limited to what is necessary.
  • Accurate and, where necessary, kept up to date. Every reasonable step must be taken to ensure that inaccurate personal data is erased or rectified without delay.
  • Kept in a form that permits identification of the data subject for no longer than necessary.

What are the lawful bases for processing?

The lawful bases for processing are set out in Article 6 of the GDPR. At least one of these lawful bases must apply whenever you process personal data:

  1. Consent: The individual has given clear consent for you to process their personal data for a specific purpose.
  2. Contract: The processing is necessary for a contract you have with the individual, or because they have asked you to take specific steps before entering into a contract.
  3. Legal obligation: The processing is necessary for you to comply with the law (not including contractual obligations).
  4. Vital interests: The processing is necessary to protect someone’s life.
  5. Public task: The processing is necessary for you to perform a task in the public interest or for your official functions, and the task or function has a clear basis in law.
  6. Legitimate interests: The processing is necessary for your legitimate interests or the legitimate interests of a third party unless there is a good reason to protect the individual's personal data which overrides those legitimate interests. (This cannot apply if you are a public authority processing data to perform your official tasks.)

Explicit requirements:

  1. Ensure the appropriate consent is in place - contract, service, explicit Data Subject consent
  2. Understand where the data resides in the application/solution
  3. Ensure the data is secured through:
    • Encryption
    • Access control
    • Additional controls
  4. Ensure the retention period of this data is clearly defined
  5. Ensure the data is deleted at the end of the retention period
  6. Ensure all the Data Subject rights can be fulfilled:
    • Higher standards for privacy policies and statements and for obtaining consent
    • Easier access to personal data by a data subject
    • Enhanced right to request the erasure of their personal data
    • Right to transfer personal data to another organization (portability)
    • Right to object to processing now explicitly includes profiling

Product considerations:

There are two types of users who access a WebSphere environment: administrators who manage the WebSphere environment, and users of applications deployed in a WebSphere environment. Administrators generally are configured to log in with their business, not personal accounts. Data collected from administrators may include user ID, password, and audit trail of administration actions that may include IP address, and administrative interfaces, parameters, and results. Data may be persisted in logs files, and audit logs, and are generally required for security audit and forensic analysis.

Users who access applications that are hosted on WebSphere Application Server may be configured to log in with their own personal accounts. Personal data collected by applications is defined by the application, and it is the responsibility of the application to comply with GDPR. However, during the normal course of running the application, personal data may be captured by the WebSphere Application Server infrastructure, and additional configurations may be needed to ensure readiness for GDPR. For example,

  • WebSphere logs and traces may capture personal data as a side effect of writing logs for diagnostic purposes.
  • Java dumps may contain personal data that is stored in memory.
  • Security audit logs may contain user IDs and IP addresses of users.
  • SIBus temporary storage in files or database may contain user data that is stored in messages.
  • Web Services use temporary storage files for large attachments.

Data Collection

WebSphere collects audit logs, operational logs and trace for service purposes which are persisted to disk as described in the Data Life Cycle section. Some communication facilities can also persist messages to disk, such as SIBUS message queues. Java heap dumps can also collect operational state and information about customer applications and WebSphere itself.

Considerations for managing this data are given in the following sections.

Data Storage

User identity data is normally not kept in WebSphere, but in some separate repository such as a database or LDAP server. However it is possible to configure a file-based user registry.

To protect access to this information, consider the following:

  • Prefer an external user registry that enforces password and auditing policies over the WebSphere file-based registry.
  • If a WebSphere file-based registry is used on WebSphere Application Server Liberty, use password encryption.
  • Use password encryption to protect passwords to external resources, such as databases.
  • Do not use a personal account when configuring access to external resources, such as databases.
  • If using the WebSphere Application Server Liberty bluemixUtility tool, the tool can cause Bluemix (IBM Cloud®) account credentials to be stored in the Liberty server configuration.
  • Do not create WebSphere administrative or operational accounts where personal information is stored. Use business accounts that do not contain personal information.

In general, it is recommended that data that may be captured as a side effect of using the WebSphere Application Server infrastructure be configured with a retention period just long enough for the business purpose of capturing such data, such as problem diagnosis, or security audit, such that data is automatically purged beyond the retention period. If necessary, additional efforts may also be undertaken by the application to reduce the amount of personal information that is captured by WebSphere Application Server. These may include:

  • Encryption of logs: file system level, per-file level, or upon archival. (This capability would be provided by the underlying compute resources, not by WebSphere.)
  • Sanitizing captured logs and audit records before they are archived, or sent to WebSphere support.
  • Protecting Java artifacts such as heap dumps. There is no automatic way to rotate or purge old Java dumps. Consider implementing a retention policy for Java dumps.

In WebSphere Application Server full profile:

In WebSphere Application Server Liberty:

Data Access

WebSphere operational data might contain some personal information such as user names or network addresses. WebSphere operational data can be accessed through a defined set of product interfaces, some of which are designed for access through a remote connection, and others for access through a local connection. Access can also be obtained by direct access to the compute resources on which WebSphere is running.

The interfaces should be secured, such that a user must first be authenticated and then checked for authorized roles before obtaining access to data.

Network communication for remote connections can be encrypted by using HTTPS.

Operational logs and trace might be read by product support personnel.

Consider the roles of operational and support staff. Limit their access to data so they do not have wider access than their roles require.

If transmitting log and trace files to IBM or other product supporters, consider sanitizing them for sensitive data prior to transmission.

Customer applications might write data into WebSphere logs. If this is the case, protect the logs as appropriate for the type of data being written.

At the operating system level, consider restricting access to the system and permissions to WebSphere files. Consider using operating system level logging and auditing capabilities to track security events that occur on the operating system, since WebSphere logs and data can be accessed directly from the operating system.

The following topics provide additional details on setting up security event auditing, and setting up WebSphere administrative users with restricted visibility to logs.

Configuring WebSphere for security event auditing:

  • In WebSphere Application Server full profile, security event auditing configuration: Auditing the security infrastructure
  • In WebSphere Application Server Liberty, as of April 2018, auditing is under development.

Configuring WebSphere administrative roles:

  • In WebSphere Application Server full profile, security roles for various actions are documented in a table in Fine-grained administrative security.

    Even the lowest level role (monitor) can view the system logs. The trace log cannot be accessed remotely through the administrative console.

  • In WebSphere Application Server Liberty, users that are mapped to the administrator role can manage Liberty remotely using the adminCenter-1.0 feature. As of April 2018, this does not include remote viewing of the logs. See Setting up Admin Center.

Data Processing

  • It is the responsibility of applications running on WebSphere to provide the ability for clients to control how their personal data is processed.
  • In addition to application capabilities, consider use of encryption and access controls to protect personal data in motion and at rest.
  • Encryption in motion
    • Encrypted communication protocols (HTTPS) can be used to encrypt communication between WebSphere and support staff or end users.
    • Access to private encryption keys should be tightly controlled.
  • Encryption at rest
    • Log and trace files can be kept on an encrypted volume or directory. (This capability would be provided by the underlying compute resources, not by WebSphere.)
    • Access to private encryption keys should be tightly controlled.
Securing communications using SSL:
Protecting messages transmitted between buses:

Data Deletion

WebSphere Application Server runs customer applications. The data these applications collect and how it is deleted are determined by the applications themselves.

Some personal data might be recorded in the operational logs that are produced by WebSphere, as well as any heap dumps. Limit retention of such data to just long enough for the business purpose of capturing such data, such as problem diagnosis, or security audit, such that data is automatically purged beyond the retention period. If it becomes necessary to delete logs and dumps before the retention period, additional administrative actions may be required.

Data Monitoring

WebSphere Application Server runs customer applications. The data these applications collect and how application users can monitor its use are the responsibility of the applications. The WebSphere Application Server audit infrastructure may be used in conjunction with application monitoring to provide coverage for audit data at the infrastructure level, such as login or logout events.

Responding to Data Subject Rights

WebSphere Application Server runs customer applications. The data these applications collect and how to respond to data subject rights are the responsibility of the applications.

The following rights should be considered when developing applications that run on WebSphere. It is recommended that the user IDs used to administer WebSphere be business IDs not containing any personal information.

  • Right to Access
    • Can the client provide individuals access to their data?
    • Can the client provide individuals information about what data the client has about the individual?
  • Right to Modify
    • Can the client allow an individual to modify or correct their data?
    • Can the client correct an individual's data for them?
  • Right to Restrict Processing
    • Can the client stop processing an individual's data?