Transcript
Professional Services, Customer Success Division. And here I welcome you all to our new series, ZPA Unpacked, where we break down the power of ZPA. In the previous video, we introduced and learned about how ZPA's advanced FQDN to IP solution helps the customers. We looked at the overview of the solution. In this video, let's continue to understand more on how does the solution actually works, its mechanics. So let's dive in. How does the solution actually work? First and foremost, this advanced feature FQDN to IP policy evaluation is enabled at the individual customer's ZPA tenant environment. Once this solution is enabled and applied with segmentation accordingly, and a user attempts to access an application, there are two levels of checks introduced. The primary as standard, we still go ahead and check the FQDNs, the broader wildcard app segments, enforcing allow or block decisions. But this is where it changes the game. If the FQDNs are unknown, if the wildcards are too broad to segment, customers have the ability to apply a secondary level of policy rule base in their segmentation strategy. What ZPA does is, if the primary level access is allowed using FQDNs or wildcard domains, which may be broader, quite large in nature, ZPA will still go ahead and perform a secondary evaluation using the resolved IP address from the FQDN and wildcard domains, working with the DNS. Once the FQDN is resolved with an IP address, it gets matched against the IP or subnet based app segments that are also now present in the application segmentation rule based order to apply more granular access controls. This is where it changes the game altogether. The customers who do not have defined FQDN day one, they can still take their time and pace to identify, to structurize those elements, but bring in the IP based, the subnet based segmentation policies into ZPA and ZPA will then still continue to transition their journey towards zero trust mechanism. Controls by enforcing a secondary level of advanced check in combination with the primary level, as I explained, by checking the policies against the resolved IP addresses. Now note, this secondary mechanism, this secondary level of check is only triggered when the traffic from the first primary evaluation is allowed. If the traffic is blocked, naturally the secondary evaluation won't kick in, it won't trigger, right? Now to ensure the correct enforcement, the IP and subnet based policies must be placed above broader FQDN or wildcard domain based policies, or even if there are broader RFC1918 subnets defined by the customer, they must be placed lower in the rule base. So note that specific IP or specific subnet based policies must be placed above in the rule base than the FQDNs or broader wildcard domains or even wider RFC1918 IP address ranges. So let's take a look at this analogy, right? An easy way to think about this solution is an airport security style check. The first checkpoint verifies the identity and your travel destination, that being the FQDN, wildcard domain based check. And the secondary checkpoint where the traffic gets validated with additional checks, your security baggage, the boarding zone checks, right? That being the resolved IP based checks. Only when both checks pass, only then the access is allowed, ensuring stronger security and zero trust access. Hope that helped understanding using this analogy, the solution bit more. Now that you know how the solution works, coming up next, you'll see how customers are actually using this in real world. So don't miss the customer case study coming up in the next session. Stay tuned. Transcribed by https://otter.ai
