Using Software-as-a-Service in closed networks, or “walled gardens”, is a challenge both to SaaS vendors and the IT organization that wants to use a new software solution while not opening their closed networks to the risks of the internet. In this blog post, we present how Hysolate, as a SaaS vendor, provides a solution to address such network security restrictions while still enjoying the benefits of using a cloud-based SaaS, as well as providing technical details for implementing such a solution for controlling access to other cloud services.
Hysolate’s Isolated-Workspace-as-a-Service solution requires connectivity of our software on endpoint devices to our cloud SaaS platform in order to provide policies, updates, analytics, etc. In some scenarios, such as closed or heavily-governed networks, this becomes impossible due to the lack of direct access to the SaaS platform from the internal network.
Hysolate Isolated-Workspace-as-a-Service provides its management service in the cloud, and we have good reasons to do so. To keep our management services always up-to-date we do not offer our service on private on-premise data centers. However, we would still like to provide value for customers that cannot connect to our service directly, due to regulation or security concerns.
To understand the solution, let’s take a look at reverse proxies.
A common practice to separate web servers from their users is to use a reverse proxy. In most scenarios, the real web server is inside an internal network, the reverse proxy is in a DMZ, and the end users are in an external network, such as the Internet. This separation allows the reverse proxy to off-load and decouple some of the web server work, including:
- Integrate a web-application firewall to detect malicious requests;
- TLS termination and server certificate management;
- Caching to reduce load on the web server; and –
- External hostname of the service, so the web server does not need to be aware of it.
When an HTTP request arrives at a reverse proxy, it will forward the request to the web server while changing the Host header to the internal hostname of the web server.
For example, a typical nginx http block for a reverse proxy will include:
This configuration assumes that the sole web server is internally reachable at the webserver hostname over HTTP, TCP port 8080, and its IP address is static.
How can we use the same principles for accessing SaaS in a private network?
Reversing a Reverse Proxy
In our case, the Hysolate service is hosted in the public cloud, and the users are inside the closed network. To connect between the two, it is possible to deploy a reverse proxy in the DMZ of the closed network. But there are some differences to consider:
- The communication between the reverse proxy and the SaaS must be encrypted, as it goes through the public internet networks;
- The SaaS is usually served on multiple external hostnames, e.g. *.hysolate.com in our case (multiple domains for the various services, such as: API service, authentication service, etc);
- The SaaS IP address(es) are not static, and usually shared with other CDN customers;
- The SaaS is not aware of the internal network and its “internal” hostnames.
By deploying such a reverse proxy configuration in the DMZ of the closed network, the local IT organization gains the following benefits to meet regulatory requirements:
- The users are not exposed to the Internet;
- It is possible to monitor and inspect the traffic.
It is possible to implement such a reverse proxy with nginx, using the following http block configuration:
Let’s break this configuration down:
The reverse proxy will be served over TLS, and only one server certificate needs to be used: a wild-card certificate for the internal domain mimicking the SaaS. It is also possible to use multiple certificates, but one certificate is easier to manage.
This is the reverse proxy HTTPS client configuration: TLSv1.2 at minimum and use Server Name Indication.
Nginx needs to be explicitly configured with a list of DNS servers to dynamically resolve the SaaS hostnames.
When the SaaS includes Location and Referer HTTP headers, the SaaS will include URLs with the external hostnames, and they need to be fixed.
When the SaaS includes URL references to itself in the response bodies, they need to be fixed as well using the nginx module ngx_http_sub_module.
The server blocks are similar to the simple case, except 2 major differences:
- Set the proxy_pass argument via a set variable, to force nginx to resolve the SaaS hostname dynamically.
- Explicitly state HTTPS protocol and TCP port 443.
Now with a specially deployed reverse proxy, it is possible to access Hysolate’s Workspace solution without opening closed networks to the internet, and provide our customers with our services without compromising regulations and security of the closed networks.
Ready for your team to work more securely and more productively? Would you like a demo to understand how Hysolate can isolate your workspaces, even in a private network? Sign up here.
*** This is a Security Bloggers Network syndicated blog from Blog – Hysolate authored by Boris Figovsky. Read the original post at: https://www.hysolate.com/blog/hysolate-in-a-closed-network-with-nginx/