Designing Zero Trust Architectures using Google Cloud Services

Photo by Med Badr Chemmaoui on Unsplash

Zero Trust Strategy

Zero Trust should be thought of as a strategy, or a guidance framework.

It requires organizations to rethink their core security philosophy and approach to trusted identities, human or otherwise.

Zero Trust is not a product (although Zero Trust-based security infrastructures can be implemented utilizing many different products), nor does Zero Trust require organizations to rip and replace existing security infrastructure — rather, it leverages existing technology to support the Zero Trust mindset, with new tools added only as needed.

The key hallmark of Zero Trust is its elegance and simplicity. Architects should keep this at the forefront of their thinking when designing for Zero Trust. Complexity is a great way to achieve ‘expense in depth,’ without any additional security benefit.

When every user, packet, network interface, and device is untrusted, protecting assets becomes simple. To reduce the complexity of cybersecurity environments, organizations can prioritize security technologies and tools that support simplicity by automating repetitive and manual tasks, integrating and managing multiple security tools and systems, and auto-remediating known vulnerabilities.

Like any other significant transformation, Zero Trust is a journey best taken one step at a time.

John Kindervag, who conceptualized Zero Trust in 2008, advises prioritizing the smallest possible protect surfaces — a single dataset, asset, application, or service (DAAS) — depending on the level of sensitivity or business criticality. Then, create micro-perimeters around each protect surface and granularly control the traffic allowed into the perimeter.

We design for Zero Trust at the DAAS (Data, Asset, Application, Service) elements of our architecture.

A Zero Trust architecture combines the tactical approaches used to deploy and build your Zero Trust environment.

Those tactical approaches depend on the Protect Surface. This is because Zero Trust is designed from the inside out, starting at the Protect Surface and moving outwards. Typically, the protect surface will be protected by a nearby Layer 7 segmentation gateway that creates a microperimeter to enforce Layer 7 controls with the Kipling Method policy.

Every Zero Trust architecture is tailor-made for an individual protect surface.

Google Cloud Services

There are five Google Cloud services that are absolutely essential for designing and implementing a Zero Trust Architecture on Google Cloud Platform. These are:

1. BeyondCorp Enterprise (BCE)
2. Identity-Aware Proxy (IAP)
3. Access Context Manager (ACM)
4. Cloud Load Balancing
5. Network Endpoint Groups (NEGs)

BeyondCorp Enterprise is a zero trust platform that allows your employees and extended workforce to access applications in the cloud or on-premises and work from anywhere without a traditional remote-access VPN. It is a modern zero trust platform which builds upon Google’s decade of experience in zero trust security.

Identity-Aware Proxy (IAP) is a Google Cloud service that provides a secure way to access your applications running on Google Cloud Platform (GCP). IAP is a powerful way to improve the security of your applications running on GCP. By using IAP, you can help to protect your applications from unauthorized access and malicious attacks.

Access Context Manager (ACM) is a Google Cloud service that allows you to define and enforce fine-grained access control policies for your resources. ACM uses a variety of attributes to determine whether a user or service is authorized to access a resource, such as:

• The user’s identity: This includes the user’s Google account ID, email address, and role in your organization.
• The user’s device: This includes the device’s type, operating system, and location.
• The resource’s sensitivity: This includes the resource’s classification and the data it contains.

Cloud Load Balancing is a Google Cloud service that distributes traffic across multiple servers. This helps to improve the performance, availability, and security of your applications.

A network endpoint group (NEG) is s a logical grouping of backend endpoints or services. NEGs can be used with Cloud Load Balancing to distribute traffic across a group of backend servers. NEGs are a powerful way to improve the performance, availability, and security of your applications. By using NEGs, you can distribute traffic across multiple servers, which can help to improve performance and availability. NEGs can also help to protect your applications from a variety of threats, such as denial-of-service attacks and data breaches.

Zero Trust Architectures (ZTA)

In this section we will take a look at Zero Trust Architectures for the following use cases:

1. Single Cloud
2. Multi Cloud or On Premise

We will also understand how the above mentioned Google Cloud services work with each other to form a Zero Trust compliant solution.

Single Cloud use case

Figure 1: Single Cloud ZTA use case

Lets take a look at the Zero Trust Architecture: Single Cloud use case. Following is the detailed explanation for the architecture diagram shown above:

1. Users first need to install the “Endpoint Verification” chrome extension on their chrome browsers. The Endpoint Verification Chrome extension is a tool that can be used to gather information about the devices that are used to access your Google Workspace resources. This information can be used to help you to improve the security of your organization’s data.
   The extension collects information like: Device type (laptop, desktop, tablet, or mobile phone), Operating system (version of the operating system that is running on the device), Device location (country and city where the device is located), Device security status (whether the device is encrypted and up to date with the latest security patches).
2. The users then try to access the IAP protected application using its external facing LB domain. In this diagram a Global External HTTPs load balancer is being used. The load balancer relays this request to IAP for authentication.
   Here are the steps involved in IAP authentication: A user tries to access your application -> IAP intercepts the request and redirects the user to the Google Identity Service for authentication -> The user logs in to the Google Identity Service using their Google account credentials -> The Google Identity Service authenticates the user and returns a token to IAP -> IAP validates the token and grants access to the user only if they have the correct IAM role. For an IAP protected application the required IAM role is “IAP-Secured Web App User”.
3. For additional security, each user can be assigned an access level using the Access Context Manager service. An access level is basically a set of conditions that the user’s device needs to satisfy in order to access the IAP protected application.
   For e.g. in this case the user’s device needs to be present in the India region, their device needs to be connected to the Corp network, their device needs to be Corp managed and it should have encryption enabled on it. You can even restrict which OS the user’s device should use and also what version exactly.
   IAP check’s the access level associated with this user and compare the access level conditions with the device information provided by the Endpoint Verification extension tool.
4. If the user’s device obeys all the conditions mentioned in the access level, IAP allows the user to access the IAP protected application. If the user’s device does not obey all the conditions, IAP shows the user a 403 forbidden error screen. The user should make sure they have the correct IAM role and their device satisfies all the conditions mentioned as per the access level assigned to them
5. In order to serve load balanced traffic to your serverless application, it needs to be attached to the Global External HTTPs load balancer as a load balancer backend. GCP load balancers do not support direct connection of serverless apps to themselves. GCP load balancers do support NEGs as load balancer backends. Serverless NEGs are the obvious choice here. For more information on SNEGs please refer this link: https://cloud.google.com/load-balancing/docs/negs/serverless-neg-concepts
6. Applications can also be hosted on VMs that are part of Managed Instance Groups. GCP load balancer support MIGs as load balancer backends which means IAP can be enabled on them as well!

NOTE: In order to enable IAP on any application it first needs to be attached to a load balancer as a load balancer backend. This is the most important criteria for deciding whether an application can be made Zero Trust compliant using Google Cloud services!

Multi Cloud/On premise use case

Figure 2: Zero Trust Architecture for a Multi Cloud use case (works for on-prem too!)

Now lets take a look at the Zero Trust Architecture: Multi Cloud.

In this diagram we can see that there is an application hosted on an EC2 server in AWS. There are also applications hosted on Google App Engine and Google Compute Engine in Google Cloud. Users can access these multi cloud application using the Host and Path rules feature provided by the GCP Application load balancers. For e.g. If a user wants to access the application hosted on Google Cloud they can make a request to this URL: https://[LB-DOMAIN-NAME].com/gae (/gae points to the SNEG which in turn points to Google App Engine). If they want to access the application hosted on AWS they can make a request to this URL: https://[LB-DOMAIN-NAME].com/hneg (/hneg points to the Hybrid NEG which in turn points to the AWS EC2 server).

In order to make the application hosted on EC2 server compliant with Zero Trust model, we need to integrate it with the process flow explored in the Single Cloud use case section. To do this we first need to enable IAP on this application. To enable IAP on this application we need to find a way to convert the EC2 server into a GCP load balancer backend. This is the perfect scenario for using Hybrid Network Endpoint Groups.

A hybrid network endpoint group (HNEG) is a type of network endpoint group that can be used to load balance traffic to endpoints that extend beyond Google Cloud, such as on-premises data centers and other public clouds that you can use hybrid connectivity to reach. A hybrid NEG is of type NON_GCP_PRIVATE_IP_PORT, which means that it can contain endpoints that have IP addresses that are not in the Google Cloud public IP space. These endpoints must be reachable by your load balancer through hybrid connectivity products such as Cloud VPN or Cloud Interconnect.

The above diagram shows the implementation of a VPN connection between AWS and GCP using the High Availability (HA) VPN service in Google Cloud and Site to Site VPN service in AWS. Once the VPN tunnels are up and running, the Hybrid NEG health checks will send tcp network requests to the EC2 server to check AWS to GCP connectivity and EC2 server health status. If the server is healthy, Hybrid NEG will start sending GCP load balancer traffic to the EC2 server thus allowing authenticated users to access the application hosted within.

Now IAP can be enabled on this Hybrid NEG GCP Load balancer backend that points to the EC2 server essentially enabling Zero Trust security model for an externally hosted application as well.

Same exact approach can be applied for applications hosted on-premise. To make sure Hybrid NEGs are able to ping the servers hosted on-premise, a working VPN connection should be created between Google Cloud and the on-premise environment.

Hybrid NEGs provide a very secure solution for integrating applications hosted on other cloud and on-premise environments. HNEGs use private IP address and port combination to reach the required servers. These private IPs are only accessible if there is a working VPN connection between VPCs present in multiple clouds or on-prem.

Additional Security

Following are some tips to strengthen your Zero Trust security model on Google Cloud even more:

1. Add code logic in your application to verify if incoming requests are coming only from IAP for added security. These are the request headers you should look for while verifying incoming requests:
   assertion = request.headers.get(‘X-Goog-IAP-JWT-Assertion’),
   user_email = request.headers.get(‘X-Goog-Authenticated-User-Email’), user_id = request.headers.get(‘X-Goog-Authenticated-User-ID’)
2. Enable DNSSEC for your GCP load balancer domain

Conclusion

Google Cloud has all the tools required to make any application Zero Trust compliant. Its services provide a lot of flexibility to include web applications hosted on wide variety of environments.

Thank you for reading! 😃