Some Random Notes

5. Zero Trust Architecute v0

4 min read

A Zero Trust Architecture is a system in which no user, device, service, or network location is trusted automatically—even if it is inside the corporate network.

For an architect or engineering manager role, you need to explain

  • the architecture
  • the request flow
  • identity
  • authorization
  • service-to-service security
  • data protection
  • policy enforcement
  • rollout
  • trade-offs and
  • failure scenarios.

Let’s make Zero Trust the central system design topic, with cryptography and the other security concepts supporting it.

1. What Zero Trust actually means

Imagine an e-commerce company with these components:

  • A customer-facing API
  • Order and payment services
  • Kafka
  • A database
  • An admin portal
  • Services deployed across multiple availability zones

In a traditional perimeter-based design, someone might reason:

“The request came from our private network, so it is probably safe.”

Zero Trust changes that assumption:

“The request must establish a trusted identity, satisfy the applicable policy, and be authorized for this particular resource and action. Network location alone grants no trust.”

Zero Trust is not a product you install. It is an architectural approach built around identity, policy, least privilege, and continuous evaluation.

2. The architecture you should draw in the interview

This is the diagram I would start with on a whiteboard. It follows the core components described in NIST SP 800-207

flowchart TB
    U[User / Device] --> G[API Gateway / Enforcement Point]
    G --> APP[Application Services]
    APP --> DB[(Database)]
    APP --> K[Kafka]
    APP --> S[Secrets / KMS]

    IDP[Identity Provider] --> PDP[Policy Decision Point]
    CTX[Device Posture / Risk / Context] --> PDP

    PDP --> PE[Policy Engine]
    PE --> PA[Policy Administrator]
    PA --> G
    PA --> APP

    APP --> LOG[Audit / SIEM]
    DB --> LOG
    K --> LOG

Note - The diagram is a logical architecture, not a requirement that every service communicate directly with a central policy engine on every request. Production systems often use local enforcement points and cached, short-lived authorization decisions for performance and resilience.

Explain the components in this order:

  • Identity provider
    • establishes human identity and supports strong authentication.
  • Policy decision point (PDP)
    • determines whether the requested access should be allowed (makes the access decision); in NIST’s model, it comprises the Policy Engine and Policy Administrator.
  • Policy Engine (PE)
    • evaluates identity, permissions, risk, and context.
  • Policy Administrator (PA)
    • establishes or terminates the access path based on the decision.
  • Policy enforcement point (PEP)
    • actually permits or blocks access at the protected resource.
  • Context sources
    • provide relevant device, workload, risk, and resource information.
  • Protected resources
    • APIs, databases, Kafka, secrets, and cloud services.
  • Monitoring
    • records security decisions and detects suspicious behavior.

The distinction between decision and enforcement is especially important. If your policy engine says “deny” but a service can still be called directly, your architecture has a bypass.

4. What to study first

Don’t try to memorize every security product. Study these five architect-level decisions first.

PriorityQuestion you must be able to answer
1How does the system establish identity for users and workloads?
2Who decides access, and where is that decision enforced?
3How do you prevent lateral movement between microservices?
4What happens when the identity provider, policy engine, or certificate infrastructure fails?
5How do you migrate an existing production system without breaking it?

For implementation guidance, the most useful next reading is NIST SP 800-207A. It goes beyond the general Zero Trust model into application and workload identities, gateways, proxies, and identity-based access policies.

My recommendation: start with the theory file, then answer the mock final-round question aloud without reading the answer. Aim for a clear three-minute explanation, followed by deeper discussion of trade-offs and failure scenarios. That is much closer to the skill tested in a system-design final round than simply knowing the definitions of SHA, MD5, and RSA.

Backlinks