AWS Partner Network (APN) Blog
Enhancing Workload Security on AWS with Zscaler Zero Trust Exchange
By Aaron Rohyans, Principal Technical Product Specialist – Zscaler
By Henning Els, Sr. Solutions Architect – AWS
 |
| Zscaler |
 |
As cloud adoption grows, organizations are increasingly utilizing infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS) solutions. This shift necessitates modernized security measures to sufficiently protect the new environments.
As organizations move to the cloud, they often adopt various products to bolster security. These tools are frequently retrofitted onto existing cloud architectures. While potentially viable for smaller businesses, this piecemeal approach can struggle to scale as business needs evolve. The complexity, cost, and legacy underpinnings of this model make it ill-suited for long-term, enterprise-wide cloud security.
In this post, we discuss the benefits of bringing security under one roof using Zscaler Zero Trust Exchange and provide hands-on tips for configuring the platform.
Zscaler is an AWS Specialization Partner and AWS Marketplace Seller with the Security Competency. Zscaler provides zero trust security for users, data, and workloads, and its Zscaler Zero Trust Exchange is a leading security cloud with over 150 points of presence globally and in most AWS regions, including AWS GovCloud (US).
Securing Workloads, Applications, and Data
The proliferation of distributed networks has opened the door to new opportunities for organizations and people around the world, while increasing the need for enhanced cybersecurity measures.
Although Amazon Web Services (AWS) is responsible for ensuring the security and availability of its cloud infrastructure, organizations are ultimately responsible for the security of their workloads, applications, and data in the cloud.
So, how can you extend zero trust security into these platforms? And how can you secure traffic between private and public clouds?
The Zscaler Zero Trust Exchange brings together several layers of security and verifies users and devices through third-party identity providers. It also validates the context of connection requests and confirms users have rights to access the destination.
Figure 1 – Retrofitting legacy security over cloud architecture.
Furthermore, Zscaler Zero Trust Exchange supports two key functions to enhance cybersecurity: Zscaler Workload Communications and Zscaler Cloud Connector.
Zscaler Workload Communications leverages cloud connectors to intelligently forward traffic to the Zscaler Internet Access (ZIA) and Zscaler Private Access (ZPA) platforms. It doesn’t require any configuration by the administrator and delivers always-on ransomware protection against zero-day threats and unknown malware. Additionally, advanced services like Zscaler Deception and IPS Anomaly Detection can be invoked to ensure traffic conforms to business norms.
The Zscaler Cloud Connector ensures cloud workloads adhere to organizational security policies when accessing both public and private endpoints. It enables multi-cloud connectivity and enforces a security policy for cloud-to-cloud traffic.
Figure 2 – Zscaler Zero Trust Exchange’s approach to cloud security architecture.
Choosing a Design Model
One of Zscaler Workload Communications’ strengths is its flexibility to work within different deployment models. Whether using a distributed approach with Gateway Load Balancer (GWLB) or a centralized approach with AWS Transit Gateway, Zscaler Workload Communications allows customers to customize the solution to fit their needs. This allows you to insert Zscaler security anywhere in the cloud environment to satisfy any security requirement or business demand.
The solution can be deployed directly adjacent to the workloads it services, as demonstrated in Figure 3 below. This brings Zscaler security elements as close to the source of traffic as possible, providing granular control over the workload’s traffic. However, the extra granularity comes at the cost of additional operational overhead in the form of more virtual appliances.
Figure 3 – Zscaler Workload Communications deployed in the workload VPC.
Alternatively, Zscaler Workload Communications can be deployed independently with traffic directed through it via AWS networking constructs like AWS Transit Gateway, as shown in Figure 4. This model saves cost and minimizes operational overhead (since traffic is aggregated through centralized Cloud Connectors), but reduces the granularity of control that customers get when defining traffic policy.
Figure 4 – Zscaler Workload Communications deployed in a centralized VPC.
Zscaler Workload Communications can also be deployed in a distributed approach via Gateway Load Balancer, as seen in Figure 5. Like the Transit Gateway model, this saves cost and minimizes overhead. A distributed GWLB provides an alternative to Transit Gateway, while offering the same traffic forwarding functionality (and in some cases, more granular control).
Note, however, that inter-virtual private cloud (VPC) access results in a sub-optimal traffic flow, since the traffic must flow through GWLB towards the centralized Cloud Connectors, and then back to the destination VPC.
Figure 5 – Zscaler Workload Communications deployed using distributed GWLB.
No single design model fits every environment. In fact, many customers will pull elements from all three of these design models to suit their business goals.
Important Considerations
While reviewing design models, consider the following items as they relate to your environment.
DNS Queries Flow
Zscaler Workload Communications integrates with Zscaler Private Access and allows workloads to seamlessly connect to other resources within your organization.
To proxy this traffic, however, the workload’s domain name system (DNS) queries must pass through the Cloud Connector appliance. This allows Zscaler to intercept and respond to the workload’s DNS request with a synthetic proxy address, bringing traffic toward the appliance.
To that end, consider how DNS is employed within your cloud architecture. If using cloud-hosted DNS servers, it’s possible DNS resolution requests will never be directed across the Cloud Connector. For this reason, automation scripts implement Amazon Route 53 to intercept and redirect DNS traffic. Note that Amazon Route 53 is not required if DNS resolution requests will inherently pass through the Cloud Connector appliance, such as if a public DNS server outside of the cloud is used.
With this caveat in mind, consider how DNS queries will flow when choosing your design model. Depending on the positioning of Cloud Connectors in the environment, influencing DNS queries through them can be quite easy.
VPC-to-VPC Connectivity
If VPC-to-VPC connectivity within an AWS region is a requirement, consider deploying the appliance in the workload VPC, or via a dedicated VPC using the AWS Transit Gateway architectural model.
Though the distributed Gateway Load Balancer design is a popular choice, it will force VPC-to-VPC traffic through the Cloud Connector, which may invoke additional costs from AWS.
Public Resources
As a best practice, Zscaler recommends pointing the workload’s default route at the GWLB that services the Cloud Connector appliances. This can cause asymmetry when traffic originates from outside the cloud towards an Amazon Elastic Compute Cloud (Amazon EC2) instance, however, as the response to this traffic goes back through the Cloud Connector (and the Zero Trust Exchange, where it may be blocked).
Consider implementing a web application firewall (via AWS WAF) inline to this traffic to maintain symmetry.
VPC Deployment
For small environments with only a handful of VPCs (or in a proof of value scenario), Cloud Connectors can be deployed directly within the workload’s VPC. That said, the number of VPCs and Amazon EC2 instances tends to increase as an organization grows larger and invests further in the cloud. Adding new VPCs also requires new appliances.
As you consider where the Cloud Connector appliances are installed, ensure you plan for adequate growth in the number of workloads and VPCs that Cloud Connector will protect.
If the future state of the environment becomes operationally cumbersome, or if the environment already contains several VPCs, it may be best to consider the distributed GWLB or AWS Transit Gateway approach with a dedicated transit/egress/service VPC for Cloud Connector.
Implementing a Baseline Policy
Once you have chosen a design model and run automation scripts to represent a few appliances, it’s time to consider what a baseline policy looks like. Next, we’ll discuss the three most important elements: Secure Sockets Layer (SSL) inspection policy, data loss prevention policy, and URL filtering.
SSL Inspection
Most internet-bound traffic is encrypted; this includes cloud workload traffic, whether it’s cloning a GitHub repository, API call, or simply updating an operating system. You can leverage Zscaler’s Zero Trust Exchange to provide content analysis on this traffic through a few steps.
First, the workload needs to be preconfigured with the root certificate authority (CA) certificates of the organization. Zscaler provides two options for root CA certificates: using your own CA or leveraging Zscaler’s.
From a functional standpoint, the two options are equivalent, but there are differences in the deployment of the root CA. The option you choose depends on your current infrastructure.
If you already have your own CA infrastructure in place, you may prefer to use your own certificates. More than likely, your machines are already preloaded with your organization’s root CA certificate, and they can begin to use the Zscaler Internet Access SSL inspection service immediately without additional certificate installations in the client certificate store.
If you don’t have a robust CA practice in place already—or don’t want to make Zscaler an intermediate CA to your organization—Zscaler’s built-in CA is a good option.
You will need to install the root CA certificate in your workload’s certificate stores. Device management platforms are ideal for installation of the new certificate, and AWS Systems Manager is a great choice to simplify this effort.
Once you have the certificates installed on the workload, the next step is to enable your SSL inspection policy. In the ZIA portal, navigate to Policy > SSL Inspection and either update your existing policy or add a new one. Ensure your cloud workload locations are selected for inclusion in this policy.
Figure 6 – Adding workloads to an SSL inspection policy.
Lastly, be sure to select the minimum transport layer security (TLS) versions you wish to allow your workloads to use when communicating with external resources. Then save and activate your changes.
Data Loss Prevention
With Zscaler, you can find and control any occurrence of specific data. From employee records to customers’ personal data and credit card numbers, Zscaler Data Loss Prevention (DLP) lets you fingerprint sensitive data and improve detection accuracy while reducing false positives.
As more and more sensitive data moves to the cloud, a DLP policy is paramount to protect cloud workloads and prevent data exfiltration.
Start by navigating to the Policy > Data Loss Prevention menu of the ZIA portal. You can add a new policy or update an existing one. Ensure your cloud workload locations are selected, and choose the action you wish to take when an offense occurs, such as blocking the transaction and notifying an auditor.
Figure 7 – Adding workloads to a data loss prevention policy.
URL Filtering
Although URL filtering is typically relegated to end users, it can also be practical in IaaS environments. As an example, consider using URL filtering to control access to specific GitHub repositories, or even specific API endpoints. A more obvious use case is in Amazon WorkSpaces or other virtual desktop environments where users will be accessing cloud resources.
You can create new URL categories for cloud workload resources via the Administration > URL Categories menu.
Figure 8 – Creating an effective cloud workload URL filtering policy.
Finally, attach these categories to a new URL filtering rule from within the Policy > URL Filtering menu.
Conclusion
In this post, you have seen how the Zscaler Zero Trust Exchange provides fast and secure app-to-app and app-to-internet connectivity across multi-cloud environments. With integrated, automated connectivity and security, it reduces cost and complexity and provides a faster, smarter, and more secure alternative to legacy network solutions.
Although this post focused primarily on security the data plane, it’s important to address the management and control plane as well. This can include multi-factor authentication (MFA) for administrators, periodic credential rotation, least-privilege access, and performing regular audits of administrative activity.
If you’re interested in learning more about Zscaler’s solutions, register for a free hands-on lab. You can also learn more about Zscaler in AWS Marketplace.
.
.
Zscaler – AWS Partner Spotlight
Zscaler is an AWS Specialization Partner that provides zero-trust security for users, data, and workloads.