Secure Data in Transit

Oracle GoldenGate protects data in transit or data in motion using the following features:

Streaming protocols with native HTTP authorization is supported. It includes a header in the initial WebSocket establishment request, which is the secure web socket (WSS) protocol. The Oracle GoldenGate server checks the authorization header to approve or deny the request based on whether the role associated with the requesting user is equal to or greater than the role assigned for Web Sockets establishment requests. Oracle GoldenGate supports TLS 1.2 and TLS 1.3 authentication. You can choose between different TLS encryption options and apply the relevant cipher suites.
Target-initiated Paths support data transition when working in Demilitarized Zones (DMZ).

Also see Distribution Path Streaming Protocols.

Secure Communication Using TLS and mTLS Support

The Transport Layer Security (TLS) protocol provides secure communication over a network by ensuring secure data transmission. Data exchange between the server (GoldenGate instance) and the clients including GoldenGate web interface, AdminClient, and other applications, is authenticated and encrypted. It uses cryptographic algorithms to encrypt data, preventing unauthorized parties from accessing or modifying the information being transmitted.

TLS verifies the server's identity to ensure the communication is with the intended party and not a malicious actor. HTTPS and WSS use the TLS protocol. HTTPS requests are made through REST-API calls and WSS is used for the secure routing of trail files by the Distribution Path.

Mutual TLS (mTLS) is an extension of the TLS protocol that adds an extra layer of security by authenticating both the client and the server in a communication session. It is an enhancement to traditional TLS, providing a two-way trust, and is an additional defense against impersonated attacks. During the client-server handshake, the server presents its digital certificate to prove its identity to the client so that the client verifies the server's identity. The client also presents its digital certificate to prove its identity to the server so that the server verifies the client's identity.

In a secure deployment, mTLS is used by the Distribution Path process to send trail files using the WSS protocol in either one of the following cases:

Sending trail data from the Distribution Service to the Receiver Service
Sending trail data using the Target Initiated Distribution Path, where the Receiver Service requests the Distribution Service to send trail files over the network.

Using the Distribution Client (DistClient) authentication by presenting the DistClient digital certificate, enables secure network communication using mTLS.

A secure deployment is recommended for Oracle GoldenGate. It requires the server's certificate, private key, and the signing Certificate from the Certificate Authority (CA certificate). The DistClient certificate, private key, and the signing certificate from the Certificate Authority (CA certificate) can be applied at any time.

However, NGINX could be used with unsecure deployment to still provide TLS support for distribution path. The TLS will be terminated at NGINX. The NGINX certificate will be verified by the client. However, the client certificate is optional by Oracle GoldenGate default NGINX configuration.

See Target-initiated Path and Oracle GoldenGate Reverse Proxy Support for details.

How Transport Layer Security Works in an Oracle Environment: The TLS Handshake

When a network connection over Transport Layer Security is initiated, the client and server perform a TLS handshake before authentication.

The handshake process is as follows:

The client and Oracle GoldenGate instance establish the cipher suites and the encryption algorithms used for data transfers.
The Oracle GoldenGate instance sends its certificate to the client, and the client verifies that the Oracle GoldenGate instance's certificate was signed by a trusted CA. This step verifies the identity of the Oracle GoldenGate instance.
Similarly, if client authentication is required, then the client sends its certificate to the Oracle GoldenGate instance. The Oracle GoldenGate instance verifies that the client's certificate was signed by a trusted CA.
The client and Oracle GoldenGate instance exchange key information using public key cryptography. Based on this information, each generates a session key. A key is shared by at least two parties (usually a client and an Oracle GoldenGate instance) that is used for data encryption for the duration of a single communication session. Session keys are typically used to encrypt network traffic. A client and an Oracle GoldenGate instance can negotiate a session key at the beginning of a session, and that key is used to encrypt all network traffic between the parties for that session. If the client and Oracle GoldenGate instance communicate again in a new session, then they negotiate a new session key. All subsequent communication between the client and the Oracle GoldenGate instance is encrypted and decrypted using this session key and the negotiated cipher suite.

The authentication process is as follows:

On a client, the user initiates a network connection to Oracle GoldenGate by using TLS.
TLS performs the handshake between the client and Oracle GoldenGate.
If the handshake is successful, then the GoldenGate instance verifies that the user has the appropriate authorization to access the Oracle GoldenGate instance.

How Does Oracle GoldenGate Use Transport Layer Security for Authentication

Using Oracle GoldenGate TLS functionality to secure communications between Oracle GoldenGate instances and clients, you can do the following:

Use TLS to encrypt the connection between Oracle GoldenGate instances and clients
Authenticate any client or any other Oracle GoldenGate instance, to any other Oracle GoldenGate instance that is configured to communicate over TLS.

After TLS is established, the Oracle GoldenGate instance will need to authenticate the client to make sure it has correct privileges to send trail. The following authentication modes are used:

The Oracle GoldenGate Instance will authenticate the client using the user ID and password that has at least the Operator role on the target side. The user ID and password is stored as alias in the client side. The alias is used when creating the distribution path.

See Connecting Two Deployments Using External RootCA Certificate to learn about setting up an Operator role user and then use this user ID, password alias when creating a distribution path connection between remote deployments.
The Oracle GoldenGate instance will use the client certificate to authenticate the client request, assuming that there is a corresponding certificate user created on the target side. To steps to create certificates for the client and server sides, see Create Certificates for a Secure Deployments.
The Oracle GoldenGate instance will authenticate the client using OAuth, when it uses external identification provider (IdP) such as IAM. See Delegate User Authentication to an External ID Provider.

TLS Cipher Suites

A cipher suite specifies one algorithm for each of the following tasks:

Key exchange
Bulk encryption
Message authentication code (MAC)

The default cipher suites for TLS 1.2 and 1.3 are supported except for the weak ciphers.

Oracle strongly recommends that you use TLS 1.3 to meet your security requirements.

Target-initiated Path

Target-initiated paths for microservices enable the Receiver Service to initiate a path to the Distribution Service on the target deployment and pull trail files. This feature allows the Receiver Service to create a target initiated path for environments such as Demilitarized Zone Paths (DMZ) or Cloud to on-premise, where the Distribution Service in the source Oracle GoldenGate deployment cannot open network connections in the target environment to the Receiver Service due to network security policies.

If the Distribution Service cannot initiate connections to the Receiver Service, but Receiver Service can initiate a connection to the host running the Distribution Service, then the Receiver Service establishes a secure or non-secure target-initiated path to the Distribution Service through a firewall or Demilitarized (DMZ) zone using Oracle GoldenGate to pull the requested trail files. The Receiver Service endpoints display that the retrieval of the trail files was initiated by the Receiver Service.

A path (read-only) is created from the Receiver Service of the target deployment and has the property TARGET_INITIATED. This path is accessible from the Distribution Service also. The path information is stored on the target system. If the communication is lost, then the Receiver Service on the target host needs the path definition to restart the connection. This information is shared with the Distribution Service when the path is running. The path is ephemeral on the source deployment. Ephemeral paths help with consolidation of path configuration and with reinforcement of target-to-source connection initiation.

When the path is stopped or disconnected, the Distribution Service removes all the path information including the path definition. However, the checkpoint file is retained because the checkpoint is used to decide whether old trails can be purged or not. It is recommended that old trails are not purged unless the path is intentionally deleted.

Oracle GoldenGate Reverse Proxy Support

Reverse proxy enables accessing microservices using one single port (443) in a deployment. This enables encapsulation of the URL for microservices over an unsecure deployment.

Note:

Reverse proxy is optional, however, Oracle recommends that you ensure easy access to microservices and provide enhanced security.

You can run microservices in an unsecure deployment on loopback address and front it with an HTTP reverse proxy using the Nginx installation.

Oracle GoldenGate MA includes a script called ReverseProxySettings that generates configuration file for only the Nginx reverse proxy server.

For example, the Administration Service is available on http://goldengate.example.com:9001 and the Distribution Service is on http://goldengate.example.com:9002. With reverse proxy, each of the microservices can simply be accessed from the single address. For example, http://goldengate.example.com/distsrvr for the Distribution Service. The URL is different for each service and is by name instead of by port.

These values are used when connecting to the Service Manager and are required when authentication is enabled.

See Configure Oracle GoldenGate Reverse Proxy with NGINX for implementing NGINX reverse proxy with Oracle GoldenGate.