> ZERO-TRUST // zt-arch-02
Context-Aware Identity-Aware Proxy (ZTNA)
Zero Trust Network Access (ZTNA) model replacing corporate VPNs with a context-aware reverse proxy evaluating user identity, device posture, and geolocation per request.
Adversary Threat Model
Stolen employee password used from an unauthorized personal machine or hostile geographical IP range.
Architecture Specs
NIST SP 800-207 Tenets Enforced
- ✓Access to resources is determined by dynamic policy including the observable state of client identity, device, and environmental attributes.
- ✓The enterprise monitors and measures the integrity and security posture of all owned and associated assets.
MITRE ATT&CK Techniques Blocked
3 Maturity Tier Configurations
Evolutionary engineering configurations from baseline Initial up to CISA Optimal zero-compromise fortress.
SaaS identity proxy deployed in front of internal admin tools.
Single Sign-On (SSO) with standard TOTP multi-factor auth.
Public internet endpoints hidden behind cloud proxy IP allowlists.
Proxy access logs forwarded to cloud storage.
Global Edge ZTNA network covering all internal web applications and SSH bastions.
Mandatory FIDO2 WebAuthn passkeys with device OS version checks.
Outbound-only secure tunnels (e.g. Cloudflare Tunnel / WireGuard) with zero open inbound ports.
Real-time SIEM ingestion of device posture anomalies and impossible travel alerts.
Unified micro-perimeter encompassing web, SSH, database proxies, and Kubernetes APIs.
Continuous per-request risk score recalculation using UEBA and TPM hardware attestation.
Total elimination of internal flat corporate subnets; all endpoints air-gapped from each other.
Automated cryptographic revocation of active sessions on device posture degradation.
Infrastructure as Code: Terraform & Kubernetes
Production-ready declarative manifests for immediate automated deployment.
resource "cloudflare_zero_trust_access_application" "internal_console" {
zone_id = var.cloudflare_zone_id
name = "TinyCTO Production Console"
domain = "console.internal.tinycto.tv"
type = "self_hosted"
session_duration = "1h"
auto_redirect_to_identity = true
}apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: internal-console-ingress
annotations:
ingress.kubernetes.io/auth-url: "https://auth.tinycto.tv/oauth2/auth"
ingress.kubernetes.io/auth-signin: "https://auth.tinycto.tv/oauth2/start"
spec:
rules:
- host: console.internal.tinycto.tv
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: console-svc
port:
number: 8080Zero Trust Network Access (ZTNA) model replacing corporate VPNs with a context-aware reverse proxy evaluating user identity, device posture, and geolocation per request.
Architecture Blueprint FAQs
How does the Context-Aware Identity-Aware Proxy (ZTNA) blueprint mitigate adversary threats and MITRE ATT&CK techniques?
Context-Aware Identity-Aware Proxy (ZTNA) addresses the following adversary profile: Stolen employee password used from an unauthorized personal machine or hostile geographical IP range. It actively eliminates lateral movement and privilege escalation by mitigating: T1078, T1133, T1539, T1056 via hardware-rooted identity, kernel-level enforcement, or continuous attestation.
Which NIST SP 800-207 Zero-Trust tenets does this architecture enforce?
This blueprint strictly operationalizes the following NIST SP 800-207 tenets: Access to resources is determined by dynamic policy including the observable state of client identity, device, and environmental attributes.; The enterprise monitors and measures the integrity and security posture of all owned and associated assets.. Implicit trust based on network location is replaced with per-session dynamic cryptographic verification.
What are the technical differences between the Initial and Optimal maturity tiers?
The Initial tier focuses on baseline policy and identity enforcement (SaaS identity proxy deployed in front of internal admin tools.), while the Optimal tier delivers CISA ZTMM 2.0 zero-compromise fortress defense (Unified micro-perimeter encompassing web, SSH, database proxies, and Kubernetes APIs.) using: teleport-enterprise, yubikey-fido2, tpm2-attest, cilium-ztna.
What is the primary failure mode risk and how is high availability guaranteed?
The primary failure risk is identified as: Edge proxy transit latency exceeding interactive terminal thresholds.. Resilience is maintained through active-active control planes, local cached attestations, and graceful degradation playbooks.
How can engineering teams automate this architecture using Terraform and Kubernetes?
The provided declarative Terraform HCL (main.tf) and Kubernetes policy manifests (policy.yaml) can be immediately integrated into automated GitOps CI/CD pipelines (e.g., ArgoCD, Flux) for reproducible, drift-detected infrastructure provisioning.