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.
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:
Page 7 of NIST SP 800-207A
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:
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:
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
Page 16 of NIST SP 800-207A
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:
How Pomerium is deployed in any multi-cloud / hybrid environment
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.
