Zero Trust Application Access (ZTNA) & Identity-Aware Proxy (IAP)

1. The Technical Problem: The Vulnerability of Management Interfaces

Exposing administrative interfaces (such as /admin, monitoring dashboards, or internal tools) directly to the public Internet is one of the most critical attack vectors in web infrastructure. Traditional perimeter defenses suffer from major structural flaws:

1. Brute-Force and Credential Stuffing Attacks: Publicly exposed login forms receive thousands of automated requests daily, consuming bandwidth and compute resources on the origin server.
2. Web Vulnerability Exploitation (Zero-Days): If the application contains a vulnerability (e.g., SQL Injection or Authentication Bypass), an unauthenticated attacker can exploit it directly.
3. Legacy VPN Networks: Perimeter VPNs grant broad internal network access once authenticated, enabling lateral movement if a single endpoint is compromised.

To eliminate these risks, this third laboratory implemented a Zero Trust Network Access (ZTNA) architecture using Cloudflare Access (Identity-Aware Proxy), shifting identity verification entirely to the Edge before any network packet reaches the web server.

2. Solution Architecture

By decoupling authentication from the application code and pairing it with an encrypted outbound tunnel (cloudflared), no unauthorized user can establish a TCP/HTTP connection with the origin application.

[ Client / Browser ]
         │
         ▼
┌────────────────────────────────────────────────────────┐
│ Cloudflare Edge (Identity-Aware Proxy)                 │
│ 1. Intercept Unauthenticated Requests                  │
│ 2. Authenticate via Identity Provider (SSO / OTP)      │
│ 3. Evaluate Access Policy (Allow-SecOps-Admins)        │
│ 4. Issue Signed Cryptographic JWT                      │
└────────────────────────┬───────────────────────────────┘
                         │ (Encrypted QUIC/TLS Tunnel - Outbound Only)
                         ▼
┌────────────────────────────────────────────────────────┐
│ Origin Server (Google Cloud Shell / Linux)             │
│ - `cloudflared` Daemon (Zero open inbound ports)       │
│ - Local Nginx Admin vHost Listening on 127.0.0.1:8080│
└────────────────────────────────────────────────────────┘

3. Step-by-Step Implementation

Step 1: Isolating the Application on the Origin Server

An administrative virtual host (VHost) was created in Nginx listening strictly on the local loopback interface on port 8080, preventing any direct access from external networks.

# /etc/nginx/sites-available/admin
server {
    listen 127.0.0.1:8080;
    server_name admin.experiement.xyz;

    root /var/www/admin;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Step 2: Mapping in Cloudflare Tunnel (config.yml)

The cloudflared daemon configuration file was updated with a new ingress rule directing traffic for admin.experiement.xyz to the local service on 127.0.0.1:8080:

tunnel: a1f15763-baad-4140-9913-993919b1602c
credentials-file: /home/diogo_moleta/.cloudflared/a1f15763-baad-4140-9913-993919b1602c.json

ingress:
  - hostname: tunnel.experiement.xyz
    service: http://127.0.0.1:80
  - hostname: admin.experiement.xyz
    service: http://127.0.0.1:8080
  - service: http_status:404

Step 3: Configuring Access Policy in Cloudflare Zero Trust

In the Cloudflare Access portal, the protected self-hosted application was registered and governed by a Least Privilege access policy:

• Application Domain: admin.experiement.xyz
• Policy Name: Allow-SecOps-Admins
• Action: Allow
• Include Rule: Emails -> diogo.ispa.ferreira@gmail.com

4. Practical Validation & Security Telemetry

The effectiveness of this architecture was validated across multiple test scenarios via the command line and browser, validating all three layers of Defense-in-Depth implemented throughout the project series.

Scenario A: Unauthenticated Request without Client Hints (Standard curl)

Attempting access via standard command-line curl without Chromium User-Agent Client Hints:

curl -I https://admin.experiement.xyz

Result:

HTTP/2 403
cf-mitigated: challenge
server: cloudflare
cf-ray: a45354976c04d665-LIS

• Analysis: The request was blocked immediately at Layer 1 (Edge WAF) due to missing User-Agent Client Hints validation headers.

Scenario B: Unauthenticated Request with Real Client Hints

Simulating a structured request with complete Sec-CH-UA headers:

curl -I \
   -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/122.0.0.0' \
   -H 'Sec-CH-UA: "Chromium";v="122", "Google Chrome";v="122"' \
   -H 'Sec-CH-UA-Mobile: ?0' \
   -H 'Sec-CH-UA-Platform: "Windows"' \
   https://admin.experiement.xyz

Result:

HTTP/2 302
location: https://aged-mode-3891.cloudflareaccess.com/cdn-cgi/access/login/admin.experiement.xyz?...
www-authenticate: Cloudflare-Access
server: cloudflare
cf-ray: a45371c7fe132f61-LIS

• Analysis: The Edge WAF allowed the request, but Layer 2 (Identity-Aware Proxy) intercepted the traffic at the Lisbon PoP (LIS). Detecting the absence of a valid JWT token, it issued an HTTP 302 redirect to the corporate login portal.

Scenario C: Authenticated User Access (Browser)

After completing identity verification via SSO/OTP using the authorized email:

• Cloudflare issued a cryptographically signed JSON Web Token (JWT) (Cf-Access-Jwt-Assertion).
• Traffic was routed securely through the tunnel to the local Nginx instance (127.0.0.1:8080).
• Result: HTTP/2 200 OK response rendering the restricted panel "Zero Trust Access Granted".

Comprehensive Security Matrix (SecOps Trilogy)

5. Key Laboratory Takeaways

1. Total Attack Surface Elimination: Automated scanning tools (Shodan, Nmap, Censys) find no open ports and cannot interact with Nginx login forms.
2. Centralized Access Management: Authentication and authorization logic are entirely removed from application code, managed declaratively and centrally at the Edge.
3. Seamless VPN Replacement: Provides secure access to internal applications from anywhere without the operational overhead or security risks of legacy VPN solutions.