[VIDEO] ZIA Workflow

With Cloud Connector, cloud locations are automatically added based on the Cloud Service Provider networks that they serve - such as AWS VPCs and Microsoft Azure VNets. When the Zscaler Zero Trust Exchange receives traffic from these Locations, the service processes it based on that Location’s settings… such as whether the Location has Authentication, Firewall, or Bandwidth Control enabled.

Knowing this, it’s important to highlight that Locations represent one of the primary match criteria used in Zscaler Internet Access to define a cloud VPC or VNet’s security policy. For more information on how Cloud Connector dynamically registers cloud locations, and the features that are enabled when doing so, be sure to check out the Location Template and Provisioning Template Creation video.

Zscaler Internet Access has a multitude of tools that can be leveraged to secure an organization - from Data Loss Prevention engines, URL filtering, SSL Inspection, Firewall, IPS, and Sandboxing - these same tools can now be used to secure cloud workloads. Keep in mind that Cloud Connector is not limited to only web traffic. In fact, all ports and protocols can and, by default are, forwarded to ZIA for inspection.

Furthermore, enabling these tools against cloud workload traffic is as easy as including cloud Locations as part of the match criteria in your ZIA rule definitions.

In this video, we’ll explore:

[0:00 to 1:45] Overview of ZIA with Cloud Connector
[1:45 to 4:45] Configuring a simple policy
[4:45 to 5:08] Logging
[5:08 to 6:02] Key Takeaways

Transcript

Hello, my name is Aaron and I’m one of the Principal Technical Product Specialists for Zscaler Cloud Workload Protection.

In this video, we’ll discuss how Zscaler Internet Access can be leveraged to secure cloud workloads.

If you’ve been around Zscaler long enough, you already know about how Locations are used to identify the various networks from which your organization sends its traffic. Cloud workload locations are no different. In fact, historically, an organization may have used IPsec or GRE tunnels to define where the traffic originated from. With Cloud Connector, cloud locations are now automatically added based on the Cloud Service Provider networks that they serve - such as AWS VPCs and Microsoft Azure VNets. When the Zscaler Zero Trust Exchange receives traffic from these Locations, the service processes it based on that Location’s settings… such as whether the Location has Authentication, Firewall, or Bandwidth Control enabled.

Knowing this, it’s important to highlight that Locations represent one of the primary match criteria used in Zscaler Internet Access to define a cloud VPC or VNet’s security policy. For more information on how Cloud Connector dynamically registers cloud locations, and the features that are enabled when doing so, be sure to check out the Location Template and Provisioning Template Creation video linked in the description.

Zscaler Internet Access has a multitude of tools that can be leveraged to secure an organization - from Data Loss Prevention engines, URL filtering, SSL Inspection, Firewall, IPS, and Sandboxing - these same tools can now be used to secure cloud workloads. Keep in mind that Cloud Connector is not limited to only web traffic. In fact, all ports and protocols can and, by default are, forwarded to ZIA for inspection.

Furthermore, enabling these tools against cloud workload traffic is as easy as including cloud Locations as part of the match criteria in your ZIA rule definitions.

To expand on this, let’s take a look at a demonstration. In our environment, we have 3 cloud Locations: one in AWS USWest, one in AWS USEast, and one in Azure EastUS. All three were dynamically learned when the Cloud Connector appliances registered. Each location has various attributes that were enabled via the Cloud Connector Location Template. As a side note, if you’d like to have more granular control over which features are enabled or disabled for individual subnets within a cloud VPC or VNet, you can do so using the Sub-Locations workflow.

Some organizations also choose to leverage Dynamic Location Groups for cloud locations as well. Particularly when multiple cloud locations may be provisioned and decommissioned on an ongoing basis. Here, a Dynamic Location Group is set up to automatically place newly learned AWS locations into a macro group called AWS. Hence, when defining policy, instead of having to select individual AWS VPCs, we can select the Dynamic Group - thus ensuring new Locations that come online will also be subjected to our security policy.

After reviewing our Location output, let’s navigate to SSL Inspection and ensure we are inspecting outbound encrypted web traffic from these locations. Here, we have a policy pre-created, that inspects HTTPS traffic to Disney and Yahoo, to which we will simply add our AWS and Azure cloud Locations to.

Next, we’ll head to the URL Filtering menu to perform a sample block against Yahoo to prevent our users from accessing it. Here, you can see our pre-created policy that identifies the Yahoo website. Again, we’ll simply add our cloud Locations to this policy to enforce this rule.

Navigating to our test host in AWS, we can see how both Disney and Yahoo traffic is indeed subjected to SSL Inspection, as evidenced by the Zscaler Root CA certificate that was presented to our web browser. Furthermore, when browsing Yahoo.com, we can see that our traffic is denied.

Since many of the Crown Jewels of an organization are now stored within cloud workloads, one may also consider enforcing a Data Loss Prevention policy against outbound cloud workload traffic. For this, we’ll head to the Data Loss Prevention workflow.

Again, we have a pre-configured rule that triggers PCI, HIPAA, or GLBA transactions. Inspecting our cloud workload traffic is as simple as adding these locations to the rule match criteria.

As a quick test, uploading sensitive data from our test workstation, we can see where the transaction is blocked and an e-mail is received highlighting the offense.

Pivoting to non-web traffic for a moment, let’s assume that we want to block all outbound Telnet from our cloud workloads since it represents a security risk. In our pre-configured rule, we’ll set the action to deny and select our cloud workloads as the match criteria.

And just like that, we’ve enabled SSL inspection, URL filtering, Data Loss Prevention, and basic Firewall on our cloud workloads - simply by adjusting our existing policy to include new cloud Locations.

As a final item, let’s visit the Analytics tab to take a look at the logging that is present with these transactions. Cloud Connector appliances log these transactions from a network level within the Cloud Connector portal. However, since outbound Internet traffic flows through ZIA, much of this traffic is also logged within the ZIA portal itself. Here, we can see our blocked attempts at Yahoo.com as well as our traffic to Disney and our failed DLP test. Note that both the cloud Location (as in, VPC or VNet) is logged as well as, potentially, even the user - which is particularly powerful in the case of Virtual Desktop environments.

– Cloud Connector appliances automatically register the cloud Locations (VPC and VNet) that they serve within the Cloud Connector and ZIA dashboards

– Locations are one of the primary match criteria used to enforce ZIA security policy on cloud VPCs and VNets

– Sub-Locations can be created beneath the Cloud Connector-installed Location to provide the granularity of feature enablement

– Dynamic Locations can be leveraged to automatically group similar cloud Locations together and ensure consistent security policy enforcement

– Zscaler Internet Access has many tools to help secure an organization (DLP, IPS, SSL Inspection, Firewall, etc.). These same tools can be leveraged by cloud workloads by simply including cloud Locations within ZIA rule definitions

– Though Cloud Connector logs traffic transiting the appliances, Zscaler Internet Access also provides rich logging on the disposition of cloud workload traffic

5 Likes

@Aaron_Rohyans can you have check and confirm if sub location creation is supported ? I had test and there were no option to create sub location in location for Cloud connectors.

@ramesh.mani1 this is a current limitation in the ZIA UI due to changes made a few months ago. The good news is sublocations CAN be created for Cloud Connector locations using the normal ZIA location CSV import capability and the ZIA location APIs. These are all tested/validated to work for ZIA policies.

Please note that currently there is one limitation if using sublocations with Cloud Connector locations. You will not be able to apply Cloud Connector traffic forwarding or DNS policies to these sublocations. In many deployments this is not a limiting factor as many traffic forwarding policies are global, but it’s something we want to check with customers of course for awareness.

I can’t specify timelines but this is a priority item for us and we do have plans to support sublocations for Cloud Connector policies long term. Hope this helps as far as what you can do today!

Hi @zoltan thank you. One of my customer looking for sublocation based policies with cloud connector. Let me have a quick check using csv or APIs and get back to you.