Cloud migration with no user OR network changes
Imagine if you could make your legacy internal applications as simple to access as a premier SaaS app, such as SalesForce.com, without sacrificing security. Your users would get the same experience upon login, regardless of where they happened to be, and without having to know anything about where the resource itself is located. The applications would scale to meet your needs with inherent fault tolerance. You would not have to manage the ever-changing network(s) in which the applications reside. And, of course, you would save money. Those goals have been at the heart of enterprise moves from the data center to the cloud, as cloud migration becomes the logical next step at the end of many companies' server hardware lifecycles. In fact, according to 2016 IDG Enterprise Cloud Computing Survey, Cloud technology is becoming a staple to organization’s infrastructure as 70% have at least one application in the cloud, and by 2018 the typical IT department will have the minority of their apps and platforms (40%) residing in on-premise systems.
Unfortunately, the road to realizing this goal has been fraught with pitfalls — unexpected costs or application rework, interoperability or security concerns, and dependencies upon on-premises assets such as directories or databases, among others. And a major challenge has always been performance for the end user.
What’s holding you (and your users) back?
While the move to cloud has been heralded as a performance booster, some companies discover that the end-user experience actually suffers. This result has little to do with the cloud migration itself, and everything to do with how users access resources.
Poor user experience often results from the underlying technology with which remote users access internal or private resources: virtual private networks, or VPNs. VPN tunnels are terminated at the edge of the network in which the application resides — a necessary stop for security reasons, particularly given the sensitive nature of most private applications and assets. As a result, traffic entering the data center via the VPN often encounters latency issues, due to the number of hops it must traverse. Since the VPN gateway must be exposed to the Internet in order to function, it is traditionally front-ended by DDoS appliances, and sandwiched between internal and external firewalls. In addition, internal and external load balancers are usually required for scaling, and global load balancing may also be necessary to connect the user to the appropriate geographic resource.
Moving an application to the cloud would appear to ease this bottleneck, but, in fact, it often makes it worse. Since terminating a VPN tunnel directly in the cloud is not possible, most enterprises force traffic from the Internet through the inbound VPN gateway, then back out onto the Internet again, via a site-to-site VPN tunnel, to the application in the cloud in a process often called “traffic tromboning.” In a case where global load balancing comes into play, for example, a user could be routed to a distant VPN termination point, then back out again, adding tremendous latency and making performance unpredictable.
A better way to connect users and applications
Zscaler Private Access offers simpler, faster, and more secure way to connect users and applications, whether the app is in the data center or the cloud. On the server/application side, the ZEN Connector handles user traffic WITHOUT requiring an open inbound connection. The ZEN Connector is available as a lightweight virtual appliance, a software package that you can install on a Linux system, or a one-click image that you can download from the AWS or Azure marketplace. The Connector calls out to the Zscaler cloud to get its configuration, then waits for instructions.
On the client side, the user installs the Zscaler App, which can be used to connect to the Zscaler Internet Access service, to Zscaler Private Access, or both. When the user enrolls, the device is fingerprinted and a pinned certificate is provisioned. When the user requests access to an internal application, that request is intermediated by the Zscaler cloud: the user is strongly authenticated, access is authorized based on policy, and the device is verified before DNS is even involved. As a result, applications are invisible — "dark" — to all except authorized users.
The Zscaler cloud then determines which Connectors have connectivity to the application and, of that set, which Connector has optimal performance. Once the best-path Connector is discovered, that Connector is instructed to make an outbound connection to the Zscaler cloud, which is stitched together with the user's outbound request for the resource to provide encrypted communications between the Zscaler App and the Connector. Application access is provided via a unique per-user, per-application microtunnel, which can be further secured with optional double encryption, keeping the application traffic private with the customer’s own encryption keys.
Let users be productive with apps and networks protected
With ZPA, your site-to-site VPN to the cloud can be reserved for application-to-server/directory traffic, and your users can go direct. There is no need for the VPN gateway that “listens” for an inbound connection, nor is there a need for load balancers and other complex supporting infrastructure. Each connection will automatically be made to the application instance with the best throughput, wherever it might be. The user is never on the network, nor are the applications exposed to the Internet.
The result is that the network — cloud or on-prem — becomes completely irrelevant. Even better, there is no change to user behavior. Users just work with the application as they would if they were in the office; no need to fire up the VPN, choose a data center, or wait. There are no changes necessary to the network, either. Simply install the Connector near your application — as long as it can reach the app and the Internet, you have what you need.
With Zscaler Private Access, you can embrace the cloud without being grounded by your network.