Zero Trust Architecture
What is Zero Trust?
Zero Trust is a security model based on the principle “never trust, always verify.” Unlike traditional perimeter-based security (castle-and-moat), Zero Trust assumes no user, device, or network is inherently trustworthy.
Core Principles
| Principle | Description |
|---|---|
| Verify Explicitly | Always authenticate and authorize based on all available data points |
| Least Privilege Access | Limit user access with just-in-time and just-enough-access (JIT/JEA) |
| Assume Breach | Minimize blast radius and segment access; verify end-to-end encryption |
Our Implementation
This documentation site uses Cloudflare Access to enforce Zero Trust at the edge.
Architecture Diagram
┌─────────────────────────────────────────────────────────────────────────┐│ CLOUDFLARE EDGE (280+ cities) ││ ││ ┌──────────────────────────┐ ┌────────────────────────────────┐ ││ │ Cloudflare Access │ │ Cloudflare Pages │ ││ │ (Authentication) │ │ (Static Hosting) │ ││ │ │ │ │ ││ │ ┌────────────────────┐ │ │ ┌──────────────────────────┐ │ ││ │ │ Identity Provider │ │ │ │ Static HTML/CSS/JS │ │ ││ │ │ (One-Time PIN) │ │ │ │ (Astro Starlight) │ │ ││ │ └────────────────────┘ │ │ └──────────────────────────┘ │ ││ │ │ │ │ ││ │ ┌────────────────────┐ │ │ ┌──────────────────────────┐ │ ││ │ │ Access Policy │ │───▶│ │ CDN Cache │ │ ││ │ │ (Email Allowlist) │ │ │ │ (Global Distribution) │ │ ││ │ └────────────────────┘ │ │ └──────────────────────────┘ │ ││ └──────────────────────────┘ └────────────────────────────────┘ ││ ▲ │└──────────────┼──────────────────────────────────────────────────────────┘ │ │ HTTPS + TLS 1.3 │ ┌───────┴───────┐ │ User │ │ │ │ 1. Request │ │ 2. Challenge │ │ 3. OTP Email │ │ 4. Verified │ │ 5. Access │ └───────────────┘Authentication Flow
- User requests
docs.sarafoleanu.com - Cloudflare Access intercepts the request at the edge
- User is challenged to authenticate (One-Time PIN sent to email)
- User enters OTP received via email
- Access validates the email against the policy allowlist
- JWT issued and stored in browser cookie (
CF_Authorization) - Content served from Cloudflare Pages
Security Controls
| Layer | Control | Implementation |
|---|---|---|
| Edge | Authentication | Cloudflare Access |
| Edge | Authorization | Email allowlist policy |
| Edge | Rate Limiting | Cloudflare built-in |
| Edge | DDoS Protection | Cloudflare automatic |
| Transport | Encryption | TLS 1.3 (Cloudflare-managed) |
| Application | Attack Surface | Zero (static files only) |
| Headers | XSS Prevention | X-Content-Type-Options: nosniff |
| Headers | Clickjacking | X-Frame-Options: DENY |
Cloudflare Access Components
Access Application
The Access Application defines what is being protected:
- Type: Self-hosted
- Domain:
docs.sarafoleanu.com - Session Duration: 24 hours (configurable)
- Cookie Settings: HttpOnly, SameSite=Lax
Access Policy
The Access Policy defines who can access:
- Decision: Allow
- Include: Specific email addresses
- Identity Provider: One-Time PIN (email-based)
How Policies Work
Request → Access Application → Policy Evaluation → Allow/Deny │ ▼ ┌───────────────┐ │ Include Rules │ ← Must match at least one │ (email list) │ └───────────────┘ │ ▼ ┌───────────────┐ │ Require Rules │ ← Must match ALL (if set) │ (optional) │ └───────────────┘ │ ▼ ┌───────────────┐ │ Exclude Rules │ ← Deny if matches (if set) │ (optional) │ └───────────────┘Why Static + Zero Trust?
Attack Surface Comparison
| Architecture | Attack Vectors |
|---|---|
| Traditional CMS | SQL injection, XSS, CSRF, RCE, auth bypass, session hijacking, plugin vulnerabilities |
| Server-rendered | SSRF, template injection, dependency vulnerabilities, server misconfig |
| Static + Zero Trust | None at application layer; auth handled at edge before content delivery |
Benefits
- No server to compromise - Static files only
- No database - No SQL injection possible
- No runtime - No code execution vulnerabilities
- Edge authentication - Attackers never reach content
- Global performance - CDN-cached worldwide
- Automatic HTTPS - TLS managed by Cloudflare
Session Management
JWT Token
After authentication, Cloudflare issues a JWT stored as CF_Authorization cookie:
- HttpOnly: JavaScript cannot access (XSS protection)
- Secure: Only sent over HTTPS
- SameSite=Lax: CSRF protection
- Expiry: Matches session duration (24h default)
Token Validation
Every request is validated at the edge:
- Cookie present and valid signature?
- Token not expired?
- User still in policy allowlist?
If any check fails → re-authentication required.
Audit & Logging
Cloudflare Access provides:
- Access Audit Logs: Who accessed what, when
- Login Events: Successful and failed attempts
- Policy Changes: Who modified access rules
Access logs in: Zero Trust Dashboard → Logs → Access
Comparison: VPN vs Zero Trust
| Aspect | VPN | Zero Trust (Cloudflare Access) |
|---|---|---|
| Network access | Full network after connect | Per-application only |
| Authentication | Once at connection | Every request validated |
| Lateral movement | Possible | Impossible |
| User experience | VPN client required | Browser-native |
| Performance | Backhauled traffic | Edge-served globally |
| Management | Complex infrastructure | SaaS, no servers |
Best Practices
- Principle of Least Privilege: Only add necessary emails to allowlist
- Regular Access Reviews: Periodically audit who has access
- Session Duration: Balance security (shorter) vs convenience (longer)
- Audit Logs: Monitor for unusual access patterns
- Multiple Identity Providers: Consider adding SSO for team access