Why HTTPS isn’t enough once your data starts moving.

In Part 2, we looked at the administration layer of Oracle GoldenGate. We talked about Secure Deployments, why they were introduced with the Microservices Architecture, and how they protect the Web UI, REST APIs, and AdminClient using HTTPS and TLS.

But as I mentioned in the first article of this series, Secure Deployment is only one layer of the overall security architecture.

The next layer begins the moment GoldenGate starts doing what it was designed to do, move data.

Every time an Extract writes trail records that are sent to another deployment, information begins traveling across a network. Sometimes that network is a private data center. Increasingly, it’s a hybrid cloud connection, communication between OCI and Azure, replication to AWS, or even synchronization between geographically separated regions.

At that point, protecting the administration interface is no longer enough.

We also need to protect the data itself.

Data Doesn’t Stay in One Place

One of the biggest changes I’ve seen over the last several years is how customers deploy GoldenGate.

Years ago, most environments were relatively simple. The source database, the target database, and GoldenGate often lived inside the same corporate network. Network traffic rarely crossed organizational boundaries.

Today, that’s rarely the case.

Many organizations replicate data from on-premises databases into cloud platforms for analytics. Others synchronize operational systems between multiple cloud providers or maintain disaster recovery environments in different regions. It’s also common to see GoldenGate moving data between separate business units connected through enterprise networks.

As architectures become more distributed, the network becomes part of the security conversation.

That’s where Secure Distribution Paths come in.

Following the Data

Whenever I explain Distribution Paths, I like to ignore the protocols for a moment and simply follow the journey of a transaction.

Imagine a customer places an order.

The application commits the transaction.

Extract captures the change.

The transaction is written into a trail file.

That trail is then transmitted to another GoldenGate deployment before Replicat applies the changes to the target database.

A simplified view looks like this:

The interesting part isn’t the Extract or the Replicat.

It’s everything happening in the middle.

That’s where sensitive business information is moving across the network.

Why Not Just Use HTTPS?

This is a question I hear occasionally.

“If Secure Deployment already uses HTTPS, why doesn’t GoldenGate simply use HTTPS for replication as well?”

It’s a reasonable question, but administration traffic and replication traffic have very different characteristics.

Administrative communication is interactive. A user logs in, issues commands, retrieves status information, and disconnects.

Replication is different.

It’s a continuous stream of transactional data moving between deployments, often twenty-four hours a day, seven days a week.

Instead of optimizing for user interaction, it needs to optimize for reliable, long-running, high-throughput communication.

That’s why GoldenGate uses Secure WebSockets (WSS) for Distribution Paths.

You can think of WSS as taking the security provided by TLS and applying it to a persistent communication channel that’s designed for continuous data streaming.

For GoldenGate, it’s a natural fit.

Encryption Is Only Half the Story

Whenever security comes up, most people immediately think about encryption.

Encryption is certainly important.

If someone captures packets traveling across the network, TLS prevents them from reading the contents.

But encryption alone doesn’t answer another equally important question.

Who am I actually talking to?

Imagine you’re replicating from your production environment to a disaster recovery site.

How do you know the system receiving your trail records is really your disaster recovery environment?

How does the receiving deployment know the sender is actually your production system?

That’s a trust problem.

Not an encryption problem.

Understanding Mutual TLS

Traditional TLS works much like visiting a secure website.

Your browser verifies the identity of the server before establishing an encrypted connection.

The server proves who it is.

Your browser trusts the certificate.

Communication begins.

Mutual TLS, or mTLS, takes this one step further.

Instead of only the server proving its identity, both sides authenticate each other.

I like using a simple analogy.

Imagine arriving at a secure office building.

With traditional TLS, you ask the receptionist for identification before entering.

Once you’re satisfied the building is legitimate, you walk in.

With Mutual TLS, the process works both ways.

You verify the receptionist’s identity, and the receptionist verifies yours before granting access.

Only after both sides trust each other does the conversation begin.

That’s exactly what happens between GoldenGate deployments.

Why This Matters More Than Ever

When GoldenGate was primarily deployed inside a single corporate network, trust was often implied.

Today’s architectures are very different.

Replication may cross cloud providers.

It may traverse enterprise WANs.

It may connect multiple geographic regions.

It may even synchronize data between organizations.

In these environments, assuming that every system on the network is trustworthy simply isn’t realistic.

I think this is one of the reasons Oracle chose to build Secure Distribution Paths around modern security standards instead of relying solely on encrypted network connections.

The goal isn’t only to encrypt the conversation.

The goal is to establish trust before the conversation even begins.

Common Misconceptions

As I’ve talked with customers over the years, I’ve noticed a few misconceptions come up repeatedly.

“We’re already using a VPN, so we don’t need TLS.”

A VPN certainly adds another layer of protection, but it doesn’t replace end-to-end encryption between GoldenGate deployments.

“If the traffic is encrypted, identity doesn’t matter.”

Encryption protects the data.

Certificates establish trust.

They’re solving two different problems.

“Mutual TLS is only for highly regulated industries.”

Not anymore.

As hybrid and multi-cloud architectures become the norm, verifying the identity of both deployments is becoming a best practice regardless of industry.

Alex’s Take

One thing I’ve learned from customer deployments is that security isn’t just about preventing someone from reading your data.

It’s also about making sure you’re sending that data to the right place.

Encryption protects the conversation.

Trust determines who you’re having that conversation with.

Those are two completely different problems, and both deserve equal attention.

Whenever I review a GoldenGate architecture, I don’t just ask whether the communication is encrypted.

I also ask whether each deployment can confidently verify the identity of the other.

That’s the difference between a secure connection and a trusted connection.

Coming Up Next

So far we’ve looked at protecting the administration layer and securing communication between GoldenGate deployments.

In Part 4, we’ll move one step closer to the database itself and explore another common misconception:

Does a Secure Deployment automatically secure the connection between GoldenGate and Oracle Database?

We’ll look at Oracle Net, TCPS, wallets, certificates, and why securing database connectivity is an entirely separate layer of the GoldenGate security architecture.