Applying Zero Trust to Multi-Cloud Environments

We read the National Institute of Standards and Technology (NIST)’s SP 800-207A: A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments to summarize it so you don’t have to.

Summary Takeaways

The publication is verbose, but here’s the overall summary you should take home:

• Keep your layers even if you have a perforated perimeter, but assume it’s been breached and don’t implicitly trust anything
• Instead of implicit trust, implement identity and context-based continuous verification for every single request
• How? Have proxies that act as policy administration, decision, and enforcement points for East-West and North-South traffic

Overview

SP 800-207A lays out how organizations can turn zero trust architecture (ZTA) concepts into reality, giving guidance on how to enforce granular application-level policies with ZTA runtime requirements for a multi-cloud or hybrid environment. The overall focus remains on realizing the fundamental ZTA principles:

• Assume breach of perimeter, so don’t implicitly trust based on location, affiliation, or ownership
• Be able to establish trust in identity with other means
• Access decisions should rely on least privilege, per-request, and context-based principles

And how these can be implemented into multi-tier ZTA policies for cloud-native application environments.

While the publication does a great job of covering how East-West traffic should be secured with ZTA principles, it doesn’t do a good job of expanding on how access controls for North-South traffic should be implemented. A holistic ZTA implementation cares about both:

• East-West Traffic to limit lateral movement
• North-South Traffic to control entry

Remember that users are the weakest link in security.

We’ll cover those gaps in our summary, which will be broken down like this:

• Why care about ZTA in the multi-cloud?
• How to implement ZTA into your multi-cloud?
• Summary Commentary

Why care about ZTA in the multi-cloud?

Usually the burning question is: our stuff works, why change it?

NIST answers that in their introduction. Here’s the summary, or you can read the full text below:

• Zero trust (ZT) is accepted best practice, even more critical in the cloud
• Enterprises have distributed multi-cloud environments
• Users are both remote and on-prem
• All forms of access, both external and internal, need to be secured
• Identities need to be authenticated
• The above can only be addressed through a ZTA policy framework.

If you’re not sure why ZTA is considered best practice, that’s fine! Take a look at what NIST says the benefits of ZTA are or enjoy our Children’s Guide to Zero Trust instead because the rest of this summary is not for you yet.

Section 3 of this publication maps zero trust policies to cloud-native application environments — it covers the foundational principles that need to be implemented. The key points to keep in mind are:

We’re skipping ahead to the implementation section, but highly recommend reading this section yourself if the key points don’t make sense.

How to implement ZTA into your multi-cloud?

The key point to keep in mind here is that ZTA boils down to continuous, request-based verification. Implementation is a question of how you can enforce per-request verification between East-West and North-South traffic.

You accomplish this by using proxies (service meshes are just a series of proxies) to check identities and permit traffic flow only if authorized, ensuring that every connection within the system is verified and trusted. These proxies are acting as the:

• Policy administration point
• Policy decision point
• Policy enforcement point

All of this is to enforce identity-based segmentation — effectively microsegmentation — allowing organizations to enforce access control through its proxies.

What are the policies and how do they help identity-based segmentation?

The five (5) identity-based segmentation policies are defined in Section 3.1 as:

• Encrypted connection between service endpoints (East-West)
• Service authentication (East-West)
• Service to service authorization (East-West)
• End user authentication (North-South)
• End user to resource authorization (North-South)

Those should be self-explanatory, but it’s good that they’re clearly defined so organizations now have a zero trust architecture checklist when implementing identity-based segmentation. For a more complete writeup of the journey, check out CISA’s Zero Trust Maturity Model.

Don’t rely on perimeters, but you still want layers

Some people may be annoyed that ZTA keeps talking about how perimeters don’t work. It’s less that perimeters don’t work and more that:

• A lot of perimeters are being tunneled into, providing vectors of breach
• Where does the perimeter even begin or end in a multi-cloud infrastructure?

Still, keep your perimeters. ZTA is intended to address security under the assumption that the perimeter is breached — it’s still a relevant (if often perforated) layer for defense-in-depth.

Additional Commentary

Zero Trust Architecture doesn’t have a “one-size fits all” implementation

There’s a lot of nuance when it comes to implementing ZTA into your tech stack. This special publication focuses on describing the requirements of each component rather than be prescriptive about what you use and how you use it, and for good reason. A lot depends on what cloud(s) you’re on, which components you’re using, what the upstream service or resource even is, and other bells and whistles that one can find in each organization.

If this particular description didn’t quite cover your edge case (of which there must be many), don’t fret — there are two other authoritative pieces that can help you go back to basics:

• NIST’s SP 1800-35 Implementing Zero Trust Architecture focuses on the interplay of each component in their sample implementations.
• CISA’s Zero Trust Maturity Model includes a useful rubric for identifying where you currently are and chart where you want to go

Proxies everywhere you go

One of the components which is critical to ZTA implementations is the use of proxies for North-south and East-west traffic. They’re everywhere because they act as the primary point of contact (and policy enforcement point) for protected services, including service meshes themselves.

Avoid tunneling

Google IAP (and various other solutions) have a tunneling problem. Tunnels should be used as sparingly as possible in any ZTA environment, with strong justification for a tunnel. Remember, we’re trying to limit lateral movement without trusting perimeters to be impervious.

Additionally, this concept of users accessing a cloud to tunnel to another cloud is just silly and introduces unnecessary latency issues.

Instead, DevOps teams should put a reverse proxy in front of each service in each cloud. This enables users to access services directly (without tunneling from one cloud to the next), making for better infrastructure and operational agility. As an example:

If you’re looking to improve your multi-cloud infrastructure and deployments, Pomerium is an open-source context-aware reverse proxy for securing access to internal services and resources.

Whether you’re spinning up a new application or trying to add access control to a legacy service, Pomerium builds secure, clientless connections to internal web apps and services without a corporate VPN. The result 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.

Check out our open-source Github Repository or give Pomerium a try today!