How to Securely Access Amazon Virtual Private Clouds Using Zscaler Private Access

Editor’s note: This post was updated by Zscaler and AWS in November 2021.

By Paul Whittenburg, Solution Architect – Zscaler
By Nathan Howe, Vice President Emerging Technologies – Zscaler
By Josh Dean, Sr. Partner Solutions Architect, Networking – AWS
By Rupert Morris, Solution Architect at AWS

Zscaler

When you are migrating private applications to Amazon Web Services (AWS), how your users and administrators will access them needs to be considered.

Making them publicly accessible from the internet is generally not desirable as it opens them up to potential attack and requires additional infrastructure to protect them.

To avoid that exposure, the first impulse may be to utilize the same approach we have followed for years for on-premises private applications–a virtual private network (VPN).

While this does allow for the desired access (SSH for administrators or HTTPS for users, for example) it also brings along the same issues that traditional VPNs have.

Inbound access is required which necessitates additional components to provide security and availability, and it also means additional complexity and cost.

VPNs do not provide the granular control desired by a Zero Trust approach, as users have access to any resource on the network and not just specific resources they are granted access to.

In this post, we’ll discuss how you can implement a Zero Trust approach to access applications hosted on AWS using Zscaler Private Access (ZPA). You can subscribe to ZPA directly from AWS Marketplace.

Zscaler is an AWS Security Competency Partner and has been working with customers for several years to redefine secure access to private applications, either on-premises or as they move to AWS.

What is Zscaler Private Access?

Zscaler Private Access is a cloud service that provides Zero Trust access to applications running on the public cloud, or within the data center. With ZPA, your applications are never exposed to the internet, making them completely invisible to unauthorized users.

The service enables the applications to be connected to users via inside-out connectivity, rather than extending the network to them. Users are never placed on the network. This Zero Trust Network Access (ZTNA) approach supports both managed and unmanaged devices and any private application (not just web applications).

What is Zero Trust?

The industry became familiar with the term Zero Trust in 2010 through a Forrester Research report called No More Chewy Centers: The Zero Trust Model of Information Security by John Kindervag, who at the time was a principal analyst there. In the report, he proposed that all network traffic should be untrusted (versus the accepted model at the time of a trusted and an untrusted network), and a Least Privilege strategy should be used for access control.

In the years since, this concept continues to be refined; for example, the National Institute of Standards and Technologies (NIST) Zero Trust Architecture (NIST Special Publication 800-207) was published in August 2020.

What is Zero Trust Network Access?

In April 2019, Gartner published a Market Guide for Zero Trust Network Access that talks in more specifics about how access to an application should be restricted based on identity or context, and as access is granularly controlled it is hidden from public visibility, reducing its attack surface.

It introduced the concepts of a trusted broker that controls access to an application, a connector which facilitates the connection, and a Service Initiated approach where a connector is on the same network as the application, and only requires an outbound connection to the broker in the cloud.

Zero Trust Realized with ZPA

In today’s world, resources can be anywhere, including the cloud and/or private data centers, as can users of those resources can also be everywhere. ZPA’s cloud-based architecture means that wherever users are in the world these resources are accessible to them.

In addition to users, there may be other consumers of those resources such as Internet of Things (IoT) devices, and applications talking to other applications.

It starts with authentication and authorization; ZPA supports identity federation with Security Assertion Markup Language (SAML). It can utilize the same identity management solution customers currently use for single sign-on (SSO) when authenticating the user, and provide attributes that can be used to create granular policies.

ZPA also supports System for Cross-domain Identity Management (SCIM) to dynamically update those attributes when there are changes in the directory.

Users may be accessing an application from a corporate managed asset or a non-managed/bring your own device (BYOD) option. Devices utilizing Zscaler Client Connector (ZCC) can also use posture assessment to determine the level of access that should be allowed. If access to an application is granted, a per-session TLS connection will be made to the ZPA Service Edge which will broker the connection, but only after policy verification occurs.

Keeping with the Service Initiated approach, Zscaler App Connectors sitting next to the applications report the availability of the application to the Zscaler Zero Trust Exchange cloud and, when required (such as when a user is granted access), will initiate an outbound TLS connection to the ZPA Service Edge.

When used to access an application on AWS, such as in an Amazon Virtual Private Cloud (VPC), security controls only need to allow outbound connectivity using a NAT Gateway, making them inaccessible from the public internet.

The ZPA Service Edge, part of the Secure Access Service Edge (SASE) framework definition, is the central point of policy enforcement in the cloud. It acts as a broker between the secure connection from the user, and the secure inside-out connection from the App Connector, stitching those connections together and then getting out of the way.

It also allows granular policies to be defined based on SAML attributes or device posture assessments, and its role is to connect users to applications and not allow users onto the network directly.

Lastly, detailed information about these connections is collected and available for querying in the admin portal or in a company’s own Security Information and Event Management (SIEM) system, where logs can be streamed to from the Zero Trust Exchange.

How ZPA works

As a cloud service, ZPA’s centralized policy is enforced globally. Users don’t have to think about whether an application is private or not (or even where it is). If they are allowed by policy, they access it transparently (just like any publicly accessible application). If not allowed, the application is invisible to them.

Users are transparently connected to a private application via the most performant path as determined by the Zero Trust Exchange through a combination of geographic awareness and application availability monitoring.

There are three main components to ZPA:

Figure 1 – ZPA brokers a connection between an authenticated user and application. 

ZPA Service Edge (Broker)

This is the heart of the Zero Trust Exchange where policy is defined and enforced and where connections are terminated using either Zscaler’s or a customer’s own certificate authority. Applications can be granularly defined by FQDN/IP and port, or can be “discovered” allowing administrators to learn which applications are being used, and by whom, so that granular policy can then be applied to them.

When a user attempts to access an application, the Service Edge verifies the user’s identity and role, and policy is consulted to determine if access should be granted. Only then the optimal path to the application is determined—applications can span multiple AWS regions and may even be present in a physical data center as well.

If access is allowed, the Service Edge will stitch together the TLS connections from the Client Connector and the App Connector and tunnel the client-initiated connection to the application. The Service Edge can even take care of load balancing across multiple App Connectors, and multiple instances of the application, and will log detailed information about the transaction and can stream that info to a SIEM.

Publicly accessible ZPA Service Edges on AWS are operated by Zscaler globally, and in some use cases private Service Edges can be deployed in a customer’s premises or cloud to provide more local access.

Zscaler Client Connector (Initiator)

When access to a private application is requested by the client (either explicitly from the command line, a client, web browser, or even a background process), Zscaler Client Connector (ZCC) will intercept the request, verify with the cloud if access should be allowed. Only then will it respond to the request by providing a synthetic IP to use to establish the connection.

If not allowed, the connection will fail as if the application did not exist. Since ZCC is always on, access to private applications is as easy as access to internet applications.

ZCC supports many device types including laptops, smartphones, tablets, and platforms such as iOS, Android, Windows, MacOS, CentOS, and Ubuntu 20.04. ZCC can easily be installed via an MDM for corporate controlled devices, and in cases where access is required only to private web applications (such as for third-party or partner access) ZPA supports Browser Access that only requires an HTML5-compatible browser.

ZPA App Connector (Facilitator)

For access to the private application to be facilitated, an App Connector must be able to resolve the FQDN (requested by ZCC) and route to it. Since it does not require inbound access at all, it is protected from malicious targeting from the Internet. The application itself may only require inbound access from the App Connector.

Since the App Connectors inform the cloud of the location and availability of the applications, users don’t have to be aware of their location. This can simplify the task of migrating an application to AWS, as users will be unaware when the application is fully migrated from the physical data center to the cloud.

ZPA Benefits

• Better access experience: Users have seamless access across all apps and devices. Uses the same Zscaler Client Connector app as ZIA, and browser access is available for web apps.
• The internet becomes the new corporate network: Cloud adoption extends the perimeter to the internet. Use TLS-based encrypted per-session micro-tunnels and custom PKI to ensure private apps remain secure.
• Segment by application, not network: Micro-tunnels enable network admins to segment by application with no need to segment networks or manage ACLs or FW policies.
• Security simplified through automation: ZPA API and machine learning (ML) enhancements simplify zero trust for IT by automatically creating access policies for discovered apps and generating auto-segmentation of app workloads.
• Never place users on-network: Authorized users have access to specific private apps without the need to access the network, reducing the risk of lateral movement and the spread of ransomware.
• Inside-out connectivity means app invisibility: Service-initiated ZTNA architecture ensures apps connect outbound to authorized users. IP addresses are never exposed, and DDoS is impossible.
• 100% cloud delivered ZTNA service: ZTNA as a service allows for simple management, high availability, greater scale, and strong protection against DDoS attacks.
• Built for all users, remote and on-premises: Bring the power of Zero Trust to remote and on-premises users with ZPA’s cloud-delivered public and private service edge.

Figure 2 – OZPA provides users access to applications, regardless of location.

Get Started Using ZPA with Applications on AWS

In Figure 2 above, you can see an application can be available in multiple AWS regions as well as the legacy data center. When a user attempts to access the application, the best path will be dynamically determined by the cloud for that session.

Users are unaware where the application physically is, so when the application is no longer available in the legacy datacenter (perhaps as it’s phased out) the end user need not be aware as the Zero Trust Exchange automatically accounts for it and connects them to the nearest VPC.

There are ZPA Public Service Edges located within AWS regions as well as in Zscaler’s private cloud. At a minimum, two ZPA App Connectors should be installed in a VPC with access to the applications, but you can add more as throughput requirements necessitate it. App Connectors will require access to the internet to connect to the Zscaler cloud and for updates, and access to the private applications they will serve. No inbound access is required.

Assuming ZPA is already available, here are the steps required to securely access your application in a VPC:

• Refer to the App Connector Deployment Guide for AWS to make sure you have met all of the prerequisites.
• Deploy the App Connector—the guide details how tp do this using the Instance Wizard or a Launch Template. The location should be as close to your application as possible, and they must be able to resolve and route to it.
• Configure your security group to:
  • Allow the App Connector to connect to the application on the required ports.
  • Allow the App Connector to access the internet (for HTTP and HTTPS at a minimum).
  • Block all inbound access from the internet, except for SSH when required to manage them.
• Configure ZPA to allow access to the application and test.

Try Zscaler Private Access for Free

ZPA Interactive is a free interactive demo of the Zscaler Private Access (ZPA) service that secures access to private applications. Sign up and get a seven-day test drive to get a sense of how the zero trust service works, view all of the features, and =experience ZPA from both an administrator and end user perspective.

To learn more about Zscaler Private Access for AWS, visit zscaler.com/AWS or check out AWS Marketplace.

To sign up for the ZPA Interactive test drive, visit the ZPA Interactive page.
.

.

Zscaler – AWS Partner Spotlight

Zscaler is an AWS Security Competency Partner whose cloud services create fast, secure connections between users and applications, regardless of device, location, or network.

Contact Zscaler | Partner Overview | AWS Marketplace

*Already worked with Zscaler? Rate this Partner

*To review an AWS Partner, you must be a customer that has worked with them directly on a project.