Connect Securely to your Cloud services from your Organization’s Internal Network

No one can deny that we are in the Cloud era. Most organizations are planning or in progress to move their workloads to Cloud. Not just moving the workloads but also, they are trying to move their data to Cloud. When it comes to storing data, the organizations want to ensure the data is stored in a safe location, traveled through the network securely, and disclosed only to authorized users. Securing the databases on Cloud become one of the most critical aspects that the different enterprises and governments are working hard to address.

Many organizations prefer to isolate their databases and avoid public access from the internet to their databases. Disabling the public access to the databases is perfectly fine if they would be able to connect from their applications to the databases using the Cloud provider private network but this would add many hurdles to the on-premises systems or the developers who need to connect to the databases from their laptops regardless their locations.

In this blog, I will take you through one of the solutions that could be used to disable public access to your database on the Cloud and securely access it only from your on-premises network.

For illustration purposes, I will use IBM Cloud services such as Db2 on Cloud, IBM Kubernetes Service, and Direct Link as examples for the explanation. If you wish, you could use the equivalent products and services in your Cloud provider to implement a similar solution.

Db2 on Cloud is one of the most important databases that I currently use in my solutions that required relational databases but all that I will explain here can be applied to any data service on Cloud.

When users provision Db2 on Cloud, they have 3 options to access the database.

1) Enabling the private endpoint.

2) Enabling the public endpoint.

3) Enabling both the private and the public endpoints.

The private endpoint would make the service only accessible to the systems that are hosted on IBM Cloud. let’s assume we have System “A” that is hosted on one of IBM Cloud services like Code Engine, OpenShift, or Kubernetes. if you configure your Db2 instance on Cloud to use the private endpoint connectivity, the traffic between your Db2 and System “A” will not traverse any public networks which ensure the data will not be exposed outside of the IBM Cloud secure network. This is perfectly fine from the security point of view.

Now Let’s look at the sense from another angle.

Assume you have system “B” that is running on the organization’s “X” on-premises data center and assume you have users and developers who have business needs to access the database.

You might end up enabling the public endpoint and exposing the data to the internet. In this case, your developers can connect to the database from their laptops wherever they are located without any problem. Using the public endpoint, System “B” can also connect smoothly to the database without any restrictions.

The main risk is the strangers that might come in between and sniff to compromise the username and the password then gain access to the data. I wouldn’t tell you what the consequences are if this happens, I’m sure all of us know that.

As Enterprise Architect, I do not recommend enabling the public endpoint of a database that contains confidential data. It would be identified clearly as a risk by your CISO team.

Many Cloud providers could provide their customers with different methods to manage the network security by creating VPN or whitelisting IPs to accept the traffic from the recognized severs. This would work well with system “B” to the database communication, but it will be hard to manage in the case of the developers that might use different networks and do not have static IPs to be whitelisted to connect to the data service.

Now the big question is, how do you make the Data services securely accessible only from your organization internal network through your Cloud provider private network instead of exposing it to the public internet.

To mitigate this risk, I built a proxy that works as a broker between my on-prem network and my data service private endpoints which is Db2 on Cloud in my case. I built this proxy using TCP nginx that I hosted on Kubernetes on IBM Cloud. You need to make sure your nginx image is built with “- - with-stream” included to support TCP. Using the power of Direct Link and private TCP ingress, I securely enabled access to this proxy inside my organization’s internal network. You would need to work with your network team and the IBM Direct Link team to enable and install your connection.

Once you established your Direct Link connection, you could use prenatted ips inside your organization network to connect to the proxy. This prenatted ip would be accessible only inside your on-prem network. Once the Kubernetes Ingress receives the request, It would forward the request to the nginx proxy, then the proxy forwards the traffic to the db2 private endpoint.

Also, System “B” (As illustrated in the above diagram) could use the internal proxy ip to connect to the Db2 service. Now, you can disable the public endpoint and mitigate the data exposure risk.

In this solution, I choose to host the current version of this proxy on the IBM Kubernetes service but this proxy can be hosted on Openshift or any other container orchestration service. The only constrain to having this solution work is to have a static IP assigned to the private TCP ingress.

Also, if you would like to add more security to the cluster. You could use calico to isolate the cluster from any other workload running in the same Vlan. Using Calico, you could disable any inbound internet traffic and only enable the private traffic like the traffic that comes from your internal network and traffic that are needed by IBM Cloud to apply upgrades and security batches.

The proxy does not terminate the TLS. I configured the proxy to use TLS pass-through. So, The SSL/TLS will be terminated by the data service itself.

As I mentioned earlier, this proxy could be used not just for Db2. It could be used for other services on Cloud that use TCP.

In the end, I would like to mention that this is not the only solution that you could use to address this problem. Also, this solution could work with any other cloud provider.

Thank you so much for reading this blog. I will be more than happy to help answer in questions that you may have about this solution.