Secure Gateway is a hybrid-cloud software solution that connects cloud and on-premise resources withoutthe need for complex security configurations. Many enterprises still haven’t made the leap to a fully distributed cloud computing model, and house their data on premises for financial or security reasons. Application developers need access to protected resources and re-configuring security policies and firewalls is often a costly and time-consuming exercise. Secure Gateway offers a simple client-server solution to get developers and enterprises up and running, usually in a matter of minutes. With Secure Gateway, developers can focus on building cool things, and enterprises can have peace of mind that their resources stay secure.
If you’re a developer trying to build an application that needs to access something behind a firewall, or if you’re trapped inside that firewall with limited external access, Secure Gateway gets you connected. Secure Gateway is designed to give the user the power to connect many different parts of their application, across multiple protocols and security configurations, without having to compromise or navigate the security policies of their various networks.
Developers in 2017 are moving more and more to a distributed model of application development, especially microservices. Applications are no longer monolithic—they’re broken down into many smaller, more manageable parts. These parts need to communicate and are often in different locations and environments. It’s not uncommon to find that your microservice needs a database or API blocked by the network firewall—and that’s where Secure Gateway comes in. Hybrid cloud technologies allow for a cloud model built with existing on-premises artifacts. Secure Gateway is what makes the union between the cloud and on premises possible—and simple!
Secure Gateway removes a lot of the headaches and bureaucracy surrounding the different security policies in multiple networks that developers often have to deal with when building an application. We save developers time so they can get back to building cool applications.
Secure Gateway also gives enterprises peace of mind. Enterprises don’t have to compromise their firewalls with specific policies to expose their data. They can deploy Secure Gateway and grant secure access to specific resources within minutes. And if there is a potential security concern, it’s also very simple to shut down Secure Gateway or quickly revoke access to the compromised resources. You can enforce new policies or revoke existing security policies with zero network downtime.
When designing your solution, Secure Gateway makes is quick and easy to use existing secured resources within your overall product architecture. It might not be feasible to move part of your application to the cloud, but that doesn’t mean you can’t access it and integrate it into your solution.
Solutions based in controlled environments and behind strict firewall rules can also use Secure Gateway to leverage external cloud technologies securely.
A typical Secure Gateway has three parts, the gateway, the client and the destination.
Most developers start with the destination. The destination answers the question ‘What am I trying to access?’ A destination is the network location of the specific resource that you’re trying to access, expressed as if you were accessing it from inside your network. In the most secure scenario this is likely going to be a local address. For example, a database on localhost:27017.
The gateway and the client represent the two sides of the connection between on-premises and the cloud. In my example I want to access my on-premises database.
I deploy the client in my local network, making sure that I have local access to that database.
On the cloud side, I create a new gateway to connect to by simply providing a memorable name.
Now all it takes to connect the client to the gateway is to provide the gateway ID and optional security token to the client on startup or at runtime. Once these two sides connect, I’ve got access from the cloud into my secured network. (Don’t worry though, nothing is exposed yet!)
I know that my destination can be reached locally using the host and port localhost:27017, but the only way for the client to receive this information is through its connection to the Gateway. For this to be possible, I have to define the destination by creating it within my newly created Gateway. Once this is done, any client connected to my gateway will know how to establish a connection to localhost:27017.
A fully functional Secure Gateway can be deployed in just a few steps:
Deploy the client in your network behind your firewall (ensure this network has external access through port 443 and 9000).
Create a gateway.
Define a destination within that gateway (as if you were accessing it within the resource’s own network).
Connect the client. (As one final level of security we enforce an access control list by default. This can be disabled or configured at will from the client side).
As long as you’re clear on what security you want and have the connection information of the resources that you want to access, these steps can be executed in a matter of minutes. No need to email your security administrator to add new firewall rules, no need to take down the network for changes.
With the new popularity of microservice architectures, it’s now more likely than ever that you’ll need access to multiple resources across multiple networks. With Secure Gateway you can create and manage multiple gateways (typically one per network) and multiple destinations per gateway. As your needs grow, Secure Gateway grows with you. Secure Gateway’s tiered plans are designed so that when you need to use more gateways or to flow more data, you can simply upgrade to a higher plan, or purchase additional gateways. If you find that you’re not using all of the gateways that you pay for, downgrading is just as simple.
We offer three plans, each with varying limits on usage:
Are there any situations where Secure Gateway should not be used?
Secure Gateway is a great solution for securely exposing resources in controlled networks. Secure Gateway makes it quick and painless to get access to the resources you need so that you can get on with development. But if Secure Gateway is used without the appropriate networking knowledge it is entirely possible to expose parts of your network that you want to keep private! Users should discuss their setup with their network administrators before connecting the client to a gateway. Fortunately, it’s incredibly easy to turn off Secure Gateway—just kill the client.
If you want to set up or bridge a network, sure, use a VPN—but that’s not what Secure Gateway does. VPNs expose everything within a network by default, so there will likely be considerable administration efforts to effectively secure and manage only the devices you want to expose. Secure Gateway provides access to resources between the cloud and on-premises: the true hybrid cloud use case. Our access scope is limited by default. Secure Gateway is the only offering in IBM that does that.
On the server side we offer the Secure Gateway Dashboard, a bluemix embedded UI that displays usage information for the past 24 hrs at a Gateway and Destination level. You can also get client speed tests and error logs from this UI.
On the client side we offer client logs at various levels (trace,debug,error,info). These logs can be dumped to a file or left to run on the command line. We frequently request client logs to help debug customer requests. All of the connection information between the client and destinations can be found in these logs so they are a great resource to help solve some of the trickier implementations.
It’s important to remember that the Secure Gateway connection isn’t actually one solid tunnel. We maintain a connection between the client and the gateway, but at either end further connections are made to reach out to the resources. For this reason, just because your client is connected and says everything is okay, it doesn’t mean you can connect to your destinations. You need to ensure the security between the client and the resource is correct. More complex configurations such as TLS mutual-auth can be tricky, especially when you’re playing with multiple certificates.
Because the connection is in two parts (Request to Secure Gateway and Client to Resource) make sure you know what protocols you want to use. If you want a HTTPS connection all the way through from initial request to the destination, make sure you have TLS security configured between the client and the resource. It’s not enough to just select ‘HTTPS’ on the server-side.
I love the whole concept of easily exposing resources because it helps speed the advancement of cloud technology. A lot of time is lost to monolithic and out-of-date applications that were developed without the cloud in mind. With Secure Gateway we can give those applications a role as microservices or as building blocks for modern cloud apps.
Traditional network security was not designed to be cloud-friendly, but it does a great job of protecting valuable and sensitive enterprise data. I don’t think we want to tear everything down just to speed up development! Secure Gateway is the middle path between the new and the old. We’re looking to the future with these cool cloud technologies, but we’re not getting rid of vital parts of existing infrastructure.
When I explain people what I do, I like to use a prison analogy. Imagine a maximum-security prison where there is only one way in and out through the main gate. Your friend is inside the prison and you want to communicate with him. You have a pair of walkie-talkies and you give one to a friendly guard. The guard walks into the prison and hands your friend the walkie-talkie. You can now communicate with your friend without compromising the security of the prison walls. That’s what Secure Gateway does; it allows data communication without the need to compromise existing infrastructure.
When Tom isn’t making Secure Gateway even better, he enjoys good food, fast cars and travel.
…