Zero Trust Security Model

The Zero Trust Security Model has one simple principle: consider any request to any resource in your system as untrusted unless proven otherwise.

Take for example a service-based architecture for an online store.

We might draw the trust boundary around our whole infrastructure, and consider that any call between two components is safe. That would violate the Zero Trust Security Model.

Instead, when following Zero Trust we think of every component and data store as being in its own trust boundary, and therefore will not trust by default any request coming from another component.

This means that we need to verify the access, all the time, to all the resources, a practice called “continuous verification”.

One way to do that for our services is the following:

• use an API Gateway in front of each service
• verify the identity of the caller service through one of the mechanisms available: mutual TLS (certificate-based authentication), JSON Web Tokens (JWT) etc.
• enforce specific permissions per caller service, with a deny-by-default policy
• the caller should also verify the identity of the called service, to avoid vulnerabilities such as Man in the Middle (MitM) attacks

While this approach increases the time necessary for deploying a new service or new features in a service, it helps limit the blast radius of any vulnerability. In our diagram, if for example the Product Catalog service is compromised, an attacker would still be unable to immediately gain access to the order database that contains customer data, since the product service has no permissions to call the order service or the order database.

Specialized tools for defining this type of access are very useful for simplifying the management of services. They are called service mesh, and examples include Istio or Linkerd.