Zero Trust Architecture

Zero Trust is a security model built on the principle: “Never trust, always verify.” It discards the assumption that anything inside a network perimeter is trustworthy - because that perimeter no longer exists in any meaningful sense.

---

The Problem with Perimeter Security

The traditional model assumes a hard network boundary: everything inside the firewall is trusted; everything outside is hostile.

Traditional (Castle & Moat) model:
┌─────────────────────────────────────┐
│  TRUSTED ZONE (Corporate Network)   │
│                                     │
│  [HR Server]  [Finance DB]  [Dev]   │
│       └──────── TRUSTED ────────┘   │
│                                     │
│  No controls between internal hosts │
│  Any inside host can reach any other│
└─────────────────────────────────────┘
          ▲
    [Firewall]  ← the only barrier
          │
    [Internet] ← hostile

This model fails when:

• An employee’s device is compromised (attacker is “inside”)
• A trusted insider turns malicious
• VPN extends the perimeter to any connected device (including home machines)
• SaaS/cloud workloads exist outside the perimeter by definition
• Contractors need access (you’ve extended “trust” to their devices)
• Attacker laterally moves from a compromised DMZ host to internal systems

The perimeter model’s failure mode: one breach = access to everything inside.

---

Zero Trust Core Principles

1. VERIFY EXPLICITLY          - authenticate and authorise every request, every time
                                regardless of source network
                                (don't trust because request came from "inside")

2. USE LEAST PRIVILEGE        - grant minimum access needed for the task
                                time-limited where possible; just-in-time access

3. ASSUME BREACH              - design as if attackers are already inside
                                segment everything; log everything; detect lateral movement
                                minimise blast radius

From Perimeter to Identity-Centric Security

Old:  "Are you on the VPN?" → trust decisions based on network location
New:  "Who are you, from what device, in what context, for what resource?"
       → trust decision made per-request, based on dynamic policy

The control plane (policy engine) decides access; the data plane (PEP - Policy Enforcement Point) executes it.

---

Zero Trust Architecture Components

┌─────────────────────────────────────────────────────────────────────┐
│                         CONTROL PLANE                               │
│                                                                     │
│  [Identity Provider]  [Device Trust]  [Policy Engine/Evaluator]    │
│      (Okta/AAD)        (Intune/Jamf)   (decides: ALLOW or DENY)    │
│                              │                                      │
└──────────────────────────────┼──────────────────────────────────────┘
                               │ policy decision
┌──────────────────────────────┼──────────────────────────────────────┐
│                         DATA PLANE                                  │
│                                                                     │
│  User/Device ──→ [PEP: Proxy / API Gateway / ZTNA Agent]           │
│                       (enforces policy decision)                    │
│                               │                                     │
│                        [Protected Resource]                         │
│                  (app server, database, API, file share)            │
└─────────────────────────────────────────────────────────────────────┘

Each access request flows through the PEP, which consults the Policy Engine. The Policy Engine evaluates signals:

Signal	Examples
Identity	MFA-verified user identity, group membership, role
Device health	OS version, patch level, disk encryption, EDR present, cert valid
Network context	IP/location (informational - not used as trust signal alone)
Application	What resource is being accessed, what action (read/write)
Time	Business hours only; session duration
Behavior	Is this request pattern normal for this user?

---

BeyondCorp - Zero Trust in Practice

Google’s BeyondCorp (2014+) is the canonical real-world Zero Trust implementation. Key insight: Google stopped using VPNs for internal access and made all access go through an internet-accessible proxy.

Before BeyondCorp:            After BeyondCorp:
  Employee → VPN → Internal     Employee → Access Proxy → Resource
  (trusted on VPN)              (verified per-request regardless of location)

Key difference:
  VPN: all traffic tunnelled, host treated as trusted
  BeyondCorp: per-application access; continuous verification

Google’s implementation had 5 components:

1. Device inventory - every device catalogued; health continuously assessed
2. Certificate per device - each managed device gets a unique cert; used for auth
3. Access proxy - all requests go through proxy; internet-accessible
4. Identity-aware policy - policy written as: user X + device Y (in good health) → resource Z
5. Workflow - no VPN; employees work from any network with same experience

---

Micro-Segmentation

Traditional segmentation: large VLANs for broad zones (DMZ, internal, management). Any host in the “internal” VLAN can reach all others.

Micro-segmentation: firewall policy at the workload level - each workload (VM, container, function) has its own policy.

Traditional:
  VLAN: Internal (10.0.0.0/16)
    Web Server  can reach  DB Server  ✅ (both internal)
    HR Workstation can reach DB Server ✅ (both internal)
    → Attacker compromises HR workstation → can reach DB Server directly

Micro-segmented:
  Web Server:    allow [internet:80,443] → [Web], allow [Web] → [DB:5432]
  DB Server:     allow [Web:dynamic] → [DB:5432] only; block everything else
  HR Workstation: allow [HR] → [HR-App only]; block [HR] → [DB]
  → Attacker compromises HR workstation → blocked from DB (policy doesn't permit it)

# Micro-segmentation implementation options:

# 1. Host-based iptables/nftables (see firewall-rules-and-iptables.mdx)
# Each host has tight rules allowing only specific sources/destinations

# 2. Kubernetes NetworkPolicy (pod-level micro-segmentation)
cat << 'EOF' | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web     # only web pods can reach database pods
    ports:
    - protocol: TCP
      port: 5432
EOF

# 3. Cloud security groups (AWS example)
aws ec2 create-security-group --group-name db-sg --description "DB micro-segment"
aws ec2 authorize-security-group-ingress \
  --group-id sg-db \
  --protocol tcp \
  --port 5432 \
  --source-group sg-web   # only web security group can reach DB

---

ZTNA - Zero Trust Network Access

ZTNA replaces VPN for remote access. Instead of granting full network access, it grants access only to specific applications - based on verified identity, device posture, and context.

VPN model:
  User authenticates → full access to corporate network subnet
  Can reach anything on 10.0.0.0/16

ZTNA model:
  User authenticates (MFA, device cert, device health check)
  Policy engine evaluates: alice + managed-laptop + 14:00 UTC + good posture
    → allowed: HR app, email, internal wiki
    → denied: finance database, production servers, admin tools
  User gets access to only those three apps - nothing else

ZTNA Products

Product	Type	Notes
Cloudflare Access	SaaS	Cloudflare reverse proxy fronts internal apps; identity-based access
Zscaler Private Access	SaaS	Replaces VPN; agent on device; app-level access
Google BeyondCorp Enterprise	SaaS	Context-aware access; integrates with Google Workspace
Tailscale	Software	WireGuard-based mesh VPN with identity-aware ACLs; easy self-host
Teleport	Open source	Protocol-aware access for SSH, Kubernetes, databases, web apps; session recording
HashiCorp Boundary	Open source	Identity-based access to hosts and services; credential injection

# Tailscale - zero-config ZTNA with identity-aware ACLs
# Install on any device
curl -fsSL https://tailscale.com/install.sh | sh
tailscale up --authkey <AUTHKEY>

# Tailscale ACL (tailnet policy file) - like a firewall but identity-aware
# https://login.tailscale.com/admin/acls
{
  "acls": [
    // Engineers can SSH to prod servers
    { "action": "accept", "src": ["group:engineers"], "dst": ["tag:prod-server:22"] },
    // Everyone can reach internal wiki
    { "action": "accept", "src": ["*"], "dst": ["tag:wiki:443"] },
    // Nobody else can reach DB
    { "action": "accept", "src": ["tag:web-server"], "dst": ["tag:database:5432"] }
  ],
  "tagOwners": {
    "tag:prod-server": ["group:ops"],
    "tag:database": ["group:ops"],
    "tag:web-server": ["group:ops"]
  }
}

---

Continuous Verification vs One-Time Trust

Traditional: authenticate at login → trusted for the entire session Zero Trust: verify at login AND continuously re-evaluate throughout the session

Continuous verification signals:
  Device posture change:  AV disabled mid-session → force re-auth or disconnect
  IP/location anomaly:    Login in NYC, API call from China 2 min later → block
  Behavior anomaly:       User suddenly accessing 1000 files → alert + step-up auth
  Session timeout:        Idle for 1 hour → require MFA re-authentication

# Conceptual continuous policy evaluation (pseudocode)
def evaluate_access(request, session):
    user_risk = identity_provider.get_user_risk_score(session.user_id)
    device_trust = device_manager.get_trust_level(session.device_id)

    if device_trust < MINIMUM_TRUST:       # device lost compliance
        return DENY, force_reauthentication()

    if user_risk > HIGH_RISK_THRESHOLD:    # anomalous behaviour detected
        return DENY, trigger_step_up_auth()

    if is_sensitive_resource(request.resource):
        if not session.has_recent_mfa(minutes=15):  # require fresh MFA
            return DENY, require_mfa()

    return ALLOW

---

Zero Trust vs VPN Comparison

Dimension	VPN	Zero Trust / ZTNA
Access scope	Full network subnet access	Per-application access only
Trust model	Trusted after VPN handshake	Continuously verified per-request
Device requirement	VPN client; connectivity test	Device posture continuously assessed
User experience	Connect VPN → access everything	Transparent; no or minimal VPN experience
Lateral movement risk	High (full network access once in)	Low (micro-segmented per app)
Implementation complexity	Lower (established technology)	Higher (requires IdP, device management, proxy)
Works with SaaS?	No (SaaS isn’t on the VPN subnet)	Yes (ZTNA wraps SaaS and internal apps)
Scalability	VPN concentrators can bottleneck	Cloud-native ZTNA scales naturally

---

Implementing Zero Trust - Maturity Steps

Zero Trust is a journey, not a single product purchase. The CISA Zero Trust Maturity Model defines five pillars with three stages (Traditional → Advanced → Optimal):

Pillar 1: IDENTITY
  Traditional:  Username + password; basic MFA
  Advanced:     Risk-based MFA; continuous re-evaluation; identity governance
  Optimal:      Real-time AI-driven risk scoring; passwordless auth

Pillar 2: DEVICES
  Traditional:  MDM enrollment; basic compliance checks
  Advanced:     Device trust scoring; compliance required for access
  Optimal:      Real-time posture assessment integrated into access decisions

Pillar 3: NETWORKS
  Traditional:  Macro-segmentation (VLANs)
  Advanced:     Micro-segmentation; encrypted internal traffic
  Optimal:      Software-defined perimeters; encrypted all traffic

Pillar 4: APPLICATIONS
  Traditional:  On-prem app with VPN access
  Advanced:     Proxy-based app access; app-level identity
  Optimal:      App access based on real-time risk; ZTNA for all apps

Pillar 5: DATA
  Traditional:  Data classification policy; basic DLP
  Advanced:     Automated classification; DLP on endpoints and cloud
  Optimal:      Real-time access control on data based on classification + context

Practical first steps (quick wins):

Week 1:   Enable MFA for all accounts (especially admin + external access)
Week 2:   Audit who has access to what - remove stale/excessive access
Week 3:   Inventory devices; enforce MDM enrollment for corporate access
Month 2:  Enable Conditional Access (Azure AD / Okta) based on device compliance
Month 3:  Deploy micro-segmentation on your highest-risk environment
Month 4+: Evaluate ZTNA product to replace VPN for remote access

Tip

You don’t need to buy a “Zero Trust platform” to start. Many organisations already have the building blocks: Azure AD Conditional Access, Intune device compliance, network ACLs, and PAM tools. Zero Trust is a framework for using those tools properly - not a product category.