Zero trust security

Doctrine

• Every request path requires fresh proof: subject, context, and channel authorization.
• Least privilege is enforced with explicit deny first, allow lists second.
• Segmentation boundaries are explicit at both network and workload layers.
• Telemetry and policy are co-designed so every enforcement change emits an audit event.

Decision tree

1. Is user/service identity verified?
   • Yes → validate device posture and session risk before allowing state write.
   • No → fail closed and return challenge/re-auth flow.
2. Can this request cross segment boundaries?
   • Yes → require explicit service-to-service policy exception and token binding.
   • No → allow only if data path is classified as internal-read and audited.
3. Is path encrypted end-to-end?
   • Yes → proceed with scoped authorization.
   • No → block until transport and trust settings are corrected.

Diagnostics pathway

1. Verify policy evaluation logs for denied/allowed decisions:

   rg "policy.denied|policy.allowed" /var/log/security/ -n

2. Inspect identity and session claims:

   jwt=$(cat /tmp/sample.jwt); echo "$jwt" | awk -F. '{print $2}' | base64 -d | jq .

3. Confirm service-token binding and audience constraints:

   curl -sS https://identity.internal/.well-known/openid-configuration

4. Trace risky traffic from one user to backend:

   rg "user_id|remote_addr" /var/log/security/requests.log

Operational checks

• Run periodic cross-segment drill where internal identity is denied unless exception policy exists.
• Test one revoked-user and one compromised-device scenario monthly.
• Track incident response runbook entry for trust boundary breaches; include owner and rollback path.

Related routes