Accessing Public Cloud Applications (aka SaaS) …Privately

Software as a Service (SaaS) offerings are becoming increasingly prevalent across all industries as organizations look for ever more dynamic and flexible ways to leverage software while ensuring operational stability, cost transparency, dynamic scale and agility.

Before we get to the third-party provided application, however, there are several components we need to have in place to enable our users to gain access, such as: network connectivity, storage, compute (in the infra Layer), virtualization, operating system, middleware, runtime and all that’s required to allow the application to run within the services layer. Only then are you into the realm of RBAC configuration, user management and distributing of the application to your end users.

It’s also important to note that while many of the above layers are seeing a consolidation and overlap in underlying technology within the function, organizations usually have different teams with unique processes that own their specific layer. More often than not, there are multiple teams operating at each layer.

This article lays out the ideas and innovations that Thad Széll (Distinguished Engineer at UBS) and Nuno Ferreira (Field CTO at Volterra) have to allow organisations to adopt SaaS applications in a real time, secure and private way without compromising and tainting the existing environment. Their focus started with Microsoft Office 365.a

As we all know, SaaS applications are generally accessed via the public Internet and it is here that the first set of problems arise. The first infrastructure issue is derived from the fact that previously the application was on controlled, mainly static infrastructure and now it is going to be accessed through the Internet, which is extremely dynamic and not under the control of one specific entity.

Some SaaS providers have the ability to provide dedicated circuits (e.g. Azure offers ExpressRoute) or VPNs for organizations to connect privately to them. To adopt such mechanisms, organizations will need to at least:

Peer (at the network level) with the SaaS Provider and maintain routing relationships Inject / advertise the SaaS provider’s public IP addresses into the corporate network Treat the service as an extranet or DMZ and overlay levels of segmentation and security In cases where the SaaS provider offers only a VPN service to the customer, then a device is required to build and maintain this VPN. Note that these technologies don’t solve the latency issue.

Having a forward proxy/NAT device can solve some security concerns but it will NOT solve the routing problem and the need to inject third-party public IP addresses into the corporate network.

Furthermore, SaaS providers are often extremely dynamic and their advertised addresses, DNS names and published end points change very regularly, and therefore operational mechanisms need to be in place to maintain peering/injection/advertising and security controls.

A solution that allows for forward proxy / NAT without the need of routing is therefore more elegant and necessary.

Let’s take Office 365 for example. Microsoft is expanding its cloud footprint with Azure and Microsoft Application Services are expanding every day. This platform allows large enterprises to have private, dedicated and high-speed physical links to Azure called ExpressRoute.

Microsoft therefore could address the above-mentioned problems (around privacy and latency) by allowing enterprise employees to access Office 365 via this dedicated private ExpressRoute circuit.

ExpressRoute for Office 365 provides an alternate routing path to many Internet-facing Office 365 services. The architecture of ExpressRoute for Office 365 is based on advertising the public IP prefixes of Office 365 services that are already accessible over the Internet into your provisioned ExpressRoute circuits for subsequent redistribution of those IP prefixes into your network. With ExpressRoute, you effectively enable several different routing paths for Office 365 services -- the Internet and ExpressRoute. This state of routing on your network may represent a significant change to how your internal network topology is designed and secured.

Ok, so maybe not that private.

The below picture represents this scenario:

This approach presents three distinct challenges for network and security teams:

Network Routing and NAT The enterprise network Infrastructure team will be required to inject publicly routable IP space into their corporate network to allow users to follow the preferred path (via ExpressRoute). In addition, in order to prevent any exposure of the corporate network to Microsoft, the network team will also be required to implement NAT towards this Microsoft network. This not only brings operational complexity of maintaining BGP peering (along with NAT) with Microsoft but also requires careful planning to accommodate for network complexities of having routing available via both a dedicated circuit with routes injected into your core network and the Internet. Security Change Management Addresses from Office 365 change from time to time, and as such these changes need to be reflected in internal security and proxy infrastructure of the enterprise. Failing to do this can result in intermittent or total loss of connectivity to Office 365 services when the ExpressRoute circuit is enabled. Microsoft provides a comprehensive and regularly updated document (and REST API) that provides a list of domains, IP addresses and TCP/UDP ports that need to be configured and continuously updated on the enterprise security and routing appliances to enforce corporate security and governance policies Operational and Security Visibility There is little to no visibility with NAT devices into the application. So how did we approach this scenario when nothing appeared to be good enough?

We worked out an elegant solution that removes the need for managing complex network infrastructure and security policies while providing employees with the benefits of ExpressRoute connectivity to access Office 365 and related application services.

Volterra’s integrated network and security stack includes an application router with programmable proxy and load balancing capabilities to address this need. Apart from these features, Volterra provides a simple pathway for enterprises to evolve to zero trust security.

At a high level, the Enterprise will have a Volterra Application Gateway cluster peering with the ExpressRoute router where Microsoft presents the Office 365 routes/services. The Volterra Application Gateway performs the automated discovery of the Office 365 endpoints via this router, allowing enterprises to access Office 365 services from there. This innovation allows the operators to remove the need to manage yet another process to translate dynamic configuration to rules on their infrastructure. The Volterra Gateway Auto-Discovery innovation permits the clients to change the destination of their requests constantly and the gateway will trigger auto discovery and TLS integrity for any request coming.

The second part of the solution is to expose these services to corporate users without advertising the Microsoft public routes within the enterprise network. This can be achieved in two ways:

The first method is to perform this directly from the Volterra Application Gateway cluster in Azure over the ExpressRoute circuit. Note that the only IP injection into the enterprise network will be the IP address of the Volterra Application Gateway cluster in Azure. For illustration purposes we are saying that the gateway is in Azure but it can be located aAnywhere as long as these 2 conditions are met: a. Users can access the gateway to send traffic to it (or the gateway intercepts it) b. The gateway is connected to an Express Route circuit where Office 365 endpoints are located / discoverable. The second method is to add one (or many) Volterra Application Gateway clusters within the corporate premises (and private DCs). We will then configure policies to expose discovered Office365 endpoint services on the on-premises Application Gateway cluster. These endpoints are discovered via the Volterra Application Gateway that sits in Azure Cloud (as explained in the first part). In addition, the enterprise operations team can configure additional security and authentication policies while encrypting all traffic. The below pictures represent these scenarios:

The Volterra Application Gateway cluster also implements auto-scaling features, meaning that when one gateway crosses a specific threshold it will spin another one and add it to the cluster.

Other features of the Volterra solution that provide significant benefits to the enterprise network, security and operations teams are:

Operational simplicity with centralized policy and SaaS-based management Integrated/unified proxy, security and routing with programmable data plane Granular and rich visibility, logging, and metrics of application usage and access By achieving simplicity and operational excellence, we believe this solution is the real answer to organizations trying to achieve similar goals as UBS, where we can ensure that private access to SaaS services, such as Office 365, are used without the need to make your corporate network “available to, or even part of, public networks.”