Encryption and data protection

Given the sensitive financial data involved, securing data both in transit and at rest is recommended in an FTM deployment.

Configuring TLS for intra-cluster traffic in Red Hat OpenShift

Encrypt intra-cluster traffic among FTM components. By default, FTM supports TLS for communication between its internal services.

To enable TLS, complete the following steps. The operator automatically configures each microservice to use keystores and truststores for encryption.
  1. Provide the required certificates and keys.
    1. Supply the keystore and truststore passwords in the custom resource (CR).
    2. If you do not supply passwords, the operator generates random 15-character passwords by default.
    Note: The keystore typically contains an SSL certificate (and private key) used by FTM’s HTTPS endpoints, and the truststore contains the CA certificates that FTM trusts.
  2. Verify that all the REST or SOAP calls, UI access within the cluster, and inter-component communication now use HTTPS on the configured port.
  3. Enable mutual TLS (mTLS) for internal calls to provide additional security. This step is optional.
    • Set spec.config.security.mtls.label to the label of the certificate in the keystore that is used for client-certificate authentication.
    • After mTLS is configured, FTM components authenticate each other’s certificates. This step hardens inter-service communication, preventing unauthorized services from impersonating FTM components.
    Note: When you enable TLS in FTM, make sure that the load balancers and Red Hat® OpenShift® routes are configured. For more information about enabling TLS and mTLS, see Configuration parameters for the FTM offerings.

Encrypting database connection

FTM uses Db2® as its datastore for transaction and configuration data. By default, the connection from FTM to Db2 can be unencrypted unless TLS support is enabled.

To enforce encryption for the database connection, complete the following steps:
  1. Configure FTM with the database server’s TLS certificate by creating a secret that contains the Db2 server’s CA certificate by using the ca.crt key to hold the Base64-encoded certificate. For more information, see IBM Db2 certificates.
  2. Reference the secret that contains the Db2 server’s CA certificate in the FTM CR by setting spec.config.database.certificate.valueFrom.secretKeyRef to the secret that holds the ca.crt key with the Base64-encoded certificate.
  3. Configure the FTM deployment with the database certificate to allow the operator to set the Db2 client configuration for TLS. This configuration can ensure that JDBC traffic to Db2 is encrypted with TLS.
  4. Enable TLS in production environments to avoid Db2 traffic in plain text. Without TLS, Db2 traffic remains unencrypted and can be intercepted within the cluster.
  5. Configure Db2 for data-at-rest encryption separately to enhance security. For example, use Db2 Transparent Data Encryption for storage. This configuration is handled at the database level and is outside of FTM’s scope, but it provides defense in depth. Secure the transport to Db2 by using TLS and use strong credentials for the database user. These are the primary measures from FTM's perspective to protect data in transit and access.
  6. Enable Db2 client hostname validation for the SSL certificate in the production environment by setting spec.config.database.clientSslHostnameValidation to true. If the Db2 client hostname validation is enabled, ensure that the Db2 certificate contains the same hostname as the Db2 instance that you are using.
For more information, see Configuration parameters for the databases.

Encrypting IBM MQ

Many FTM deployments use IBM® MQ for messaging. If your FTM offering is configured to use an IBM MQ Queue Manager (either internal or external), secure the channel with TLS to encrypt all traffic in transit. Configure the FTM custom resource (CR) to help ensure that IBM MQ JMS and MQI connections use TLS. For more information, see Configuration parameters for IBM MQ.

Provide the IBM MQ server certificate details to FTM so it can trust the IBM MQ broker and, optionally, present a client certificate. The CR supports specifying a certificate authority (CA) or referencing a secret. Typically,
  1. Import the IBM MQ Queue Manager’s public CA cert would be imported into FTM’s truststore (so FTM trusts IBM MQ).
  2. Provide a client certificate and key if IBM MQ requires client auth. By default, the IBM MQ TLS setting is enabled. A secure deployment encrypts IBM MQ by using TLS encryption.
For more information, see IBM MQ configurations with TLS and LDAP authentication.

Encrypting RMI Transport

To secure RMI traffic between Common Services and WebSphere® Application Server, follow instructions in Set up SSL connection for RMI between Common Services and IBM WebSphere Liberty.

NFS data in transit not encrypted by default

Most NFS data flows are not encrypted by default.
NFSv3 and earlier versions
These versions do not support data encryption in transit. All data, including file contents and metadata, is transmitted in plain text, making it vulnerable to interception. Transmitting data in plain text is not recommended except in highly secure locked down environments with other compensating controls.
NFSv4.x
Supports stronger authentication and integrity through Kerberos (RPCSEC_GSS). Consult your NFS solution documentation for details on how to enable TLS or other methods to secure data in transit for compliance.

TLS for external traffic by using additional certificates

FTM often integrates with external systems such as SFTP servers, web services, or partner APIs. When FTM communicates with these external endpoints over TLS, ensure that the endpoint certificates are trusted by FTM. You can provide additional certificate authority (CA) or self-signed certificates to FTM to establish trust. To do this, use the additionalCertificates configuration. If you use the Vault integration, you can also provide these certificates through the vault file. For more information, see User-supplied certificates for external applications.

For more information, see Configuration parameters for the SFTP server instance and Configuration parameters for security.

WebSphere Liberty Security

Liberty security provides protection for web resources in accordance with the Servlet 3.0 specification and EJB resources in accordance with the ejbLite 3.1 specification. The Liberty security also provides protection for the JMX connections when you are using the REST connector. For more information about WebSphere security, see Common Services security - Setting up security for WebSphere.

Encrypting data at Rest

Db2 database
Use Db2 native encryption or disk-level encryption on storage.
For persistent volumes (PVs) used by FTM, ensure that the underlying storage class supports encryption or encrypted storage.
For Red Hat OpenShift,
  • Red Hat OpenShift secrets are stored in etcd. By default, these secrets are stored in plain text.
  • FTM allows enabling etcd encryption.
Verify that etcd encryption is turned on for your cluster so that secrets are encrypted at rest in the cluster store.
If using an external Vault, secrets are stored there and can be encrypted by Vault. In summary, protect data at rest at all layers: database, filesystem, and cluster store.
NFS Volumes
NFS does not natively support encryption of data at rest.
To secure data stored on NFS volumes, implement encryption at the underlying storage or file system level. Use block-level encryption technologies such as Linux Unified Key Setup (LUKS), or file system-level encryption mechanisms such as fscrypt, eCryptfs, or native encryption features in file systems such as ZFS.
These tools encrypt data before it is written to disk, protecting the data even if the storage media is compromised.
Integration with centralized key management systems, such as HashiCorp Vault, can further enhance data protection and compliance with regulatory requirements.
FTM applications
FTM does not provide application-level encryption. The underlying storage systems manages the encryption at rest.

For more information about Db2 native encryption, see Db2 native encryption.