Zero Trust Security: A Modern Approach to Securing Your Applications🔒 .

Pillars — Zero Trust Security Model

The traditional approach (VPNs) to network security is based on the concept of a “trust boundary”. This boundary is typically the corporate network, and all users and devices inside the boundary are considered to be trusted. However, this approach is no longer effective in the modern world. VPNs may have limitations in providing secure access as they typically provide access to the entire network making them susceptible to lateral movement attacks if the user’s credentials are compromised.

The zero trust model is a new network security approach that assumes no user or device can be trusted by default. This means no one outside or inside of the network is to be trusted unless identification has been thoroughly checked. All users and devices must be authenticated and authorized before they are granted access to any resources. So users regardless of location are to be verified and given only the minimum amount of access that they need. this means that a user request to Application-A will be verified and authorized only for that specific application, Access to other Applications will not be granted. So each Application is verified independently.

Remember, Verification is accomplished in different ways depending on the following three pillars:

Identity: Identity involved user authentication plus authorization. In other words, who are you and who do you claim to be? It typically included second or multi-factor authentication.

Context: Context is about how the user is trying to access the resources. This pillar is based on the least privileged security model where users are only granted the least possible amount of access that need.

Security: Security posture is the third pillar which focuses on the device the user is connecting. Basically, this will check whether the machine that users are connecting to is compliant or not. This could be as simple as verifying that software like antivirus is running or several different conditions are met before granting access

An Important thing to note is that zero trust never stops on just the verification. Once the user has been granted access, zero trust required continuous monitoring and validation. Any changes to Identity, context, or security posture will be re-evaluated and revoked access as necessary. Zero Trust security is a model and a mindset about how to approach network security however it’s not a technology. Zero trust network access is technology by which the principle of zero trust can be used to secure access to applications and resources. Zero trust network access can be a network or a cloud provider depending on where the Application sits. Examples are Pomerium, Z-scaler, Google IAP, and a lot more vendors out there in the market. I recently explored Pomerium which is an open-source solution and zero trust vendor. I find this tool highly customizable and can be integrated into different applications. Will talk about more in the end. if you want to explore, you can check it out here.

Zero trust network access — ZTNA

if you understand this architecture, your concept of the zero trust model will be clarified. So here in this diagram, users from different teams access their intranet applications from their secure devices. They do not have access to other applications except the ones they are allowed to. So you have more control over the access part. You can also set context-based conditions like company device, Geo-location, IP ranges, antivirus, Specific version of browser, etc according to your need and security compliances. This would not stop here, the model continues to monitor and validate the trust. let’s say you set the context company devices with specific versions of antivirus, so in this case, even if your credentials get comprised, the hacker won’t be able to access your application from their devices. Zero-trust networks treat those requests as not legitimate or untrusted and immediately block them.. that’s how it works. will cover this context further in this article in the Google IAP section.

Let’s understand the architecture’s Terminology as follows:

1. The user attempts to access the intranet application.
2. Trust Broker authenticates the user and checks their context. This includes the user’s location, device, IP address, and browser.
3. If the user is authenticated and their context is trusted, Trust Broker grants them access to the intranet application.
4. The user can then access the intranet application.

What is Google IAP (Identity and Aware Proxy)?

Google IAP is a zero-trust network access (ZTNA) cloud-native solution and is an example of a zero-trust security model. IAP can be used to protect web sites running on many platforms, including App Engine, Compute Engine, and other services behind a Google Cloud Load Balancer. But it isn’t restricted to Google Cloud: you can use it with IAP Connector to protect your own on-premises applications, too.

Here are some of the benefits of using Google IAP:

• It is a cloud-based solution, so you can deploy it quickly and easily.
• It is scalable, so you can easily add or remove users as needed.
• It is secure, using a variety of factors to determine if a user should be granted access.
• It is easy to use, with a simple API that you can integrate with your existing applications.

How IAP Solves the Problems of Zero Trust Without VPN

Example1: Securing a web application with Google IAP

Accessing Applications using Google IAP

1. Set up a web application hosted on Google Cloud, like a web server or an application running on Google Kubernetes Engine (GKE).
2. Enable IAP for the application. This is done through the Google Cloud Console, where you specify which users or groups should have access to the application.
3. When a user tries to access the web application, they are redirected to the Google sign-in page and prompted to authenticate themselves.
4. Once the user provides valid credentials, Google IAP checks their identity and grants access only if they are authorized to access the application.
5. The user is then directed to the application, and IAP continues to enforce access controls based on the user’s identity and role, continuously verifying their authorization.

In this scenario, even if the user is on a different network or an untrusted device, Google IAP ensures that access is granted only after thorough verification. It does so by integrating with Google’s Identity and Access Management (IAM) service, which controls permissions and access to resources within Google Cloud.

Example 2: Let us understand with one more example of context-based. It is the way to control access to your applications based on the context of the user, such as their location 📍, device 📱, Browser 🖱️, Software, Antivirus, IP address 🌐, and many more

1. Assume you have a web application hosted on Google Cloud, and you want to allow access to specific users based on their browser type.
2. Set up IAP for the web application and configure it to use context-based access controls.
3. Define a policy that specifies which browsers are allowed to access the application. For example, you may want to allow access only to users using specific versions of Google Chrome or Mozilla Firefox.
4. When a user tries to access the web application, IAP checks their identity as usual and then examines the context of the user’s request, including the browser information.
5. If the user’s browser matches the allowed list (e.g., Google Chrome or Mozilla Firefox), IAP grants access to the application. Otherwise, access is denied.

Example Scenario:

• User A tries to access the web application using Google Chrome.
• IAP verifies User A’s identity and checks the context information (browser type).
• Since User A is using Google Chrome, which is allowed, IAP grants access to the web application.
• User B attempts to access the same web application using Safari.
• IAP verifies User B’s identity and checks the context information (browser type).
• Since Safari is not on the allowed list, IAP denies access to the web application for User B.

By implementing the zero trust model with IAP, organizations can add an extra layer of security, reducing the risk of unauthorized access and potential data breaches. Users need to authenticate and authorize themselves at every access attempt, ensuring a more robust and secure environment.

Are VPNs Going Away?

VPNs are not going away anytime soon, but they are evolving to meet the needs of a more mobile and remote workforce. This model is still effective, but it can be slow and cumbersome, especially for users who are connecting from multiple devices or locations. Newer VPN technologies, such as zero-trust network access (ZTNA) are more scalable and flexible.

Hidden Facts About Zero Trust Model

ZTNA does provide a secure tunnel, but it’s not the same as the type of secure tunnel that a VPN provides. In a VPN, all traffic is routed through the VPN server, which encrypts it before sending it to the corporate network. In a ZTNA architecture, traffic is only encrypted between the user’s device and the ZTNA gateway.

In a VPN, all traffic is encrypted, which means that even if an attacker is able to intercept the traffic, they will not be able to read it. In a ZTNA architecture, only the traffic between the user’s device and the ZTNA gateway is encrypted. This means that if an attacker is able to intercept the traffic between the ZTNA gateway and the application, they will be able to read it. However, ZTNA architectures typically implement other security controls to mitigate this risk.

Combination of ZTNA and VPNs

For better Security ( Depending on the use case), You can use ZTNA and VPNs together. This is called a hybrid ZTNA approach. In this approach, ZTNA is used to provide granular access control to applications, while VPNs are used to provide a secure tunnel for traffic that needs to be encrypted.

For example, you could use ZTNA to allow users to access specific applications, such as email or the file server, without having to connect to the entire corporate network. You could then use a VPN to allow users to connect to the corporate network for other purposes, such as accessing shared drives or printers.

What is Pomerium? Pomerium is a cloud-agnostic tool just like any vendor. This means that it can be deployed on any cloud provider, such as Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP). This makes it a good choice for organizations that want to implement ZTNA across multiple clouds. Pomerium builds secure, clientless connections to internal web apps and services without a corporate VPN.

Pomerium is:

• Easier because you don’t have to maintain a client or software.
• Faster because it’s deployed directly where your apps and services are. No more expensive data backhauling.
• Safer because every single action is verified for trusted identity, device, and context.

It’s not a VPN alternative — it’s the trusted, full-proof way to protect your business. If you are looking for a cloud-agnostic ZTNA tool, Pomerium is a good option to consider.

Conclusion

The zero trust model is a new approach to network security that is more secure than the traditional approach. ZTNA can provide a secure way to access applications, but it’s important to understand the limitations of the technology. If you need to ensure that all traffic is encrypted, then a VPN may be a better option. We also covered a very popular cloud-native tool IAP is a Google Cloud service that can help organizations implement the zero trust model without the need for a VPN. I also talked about the best available cloud-agnostic tools in the market that provide provides a secure way to access Cloud resources without the need for a VPN.

Thank you for reading! I hope you found this article informative and helpful. If you enjoyed it, please share it with others. Together, we can help to spread knowledge and security. If you have any comments, suggestions, or questions, please feel free to share. I will be happy to assist.