> ## Content Index
> Fetch the complete content index at: https://www.diogomoleta.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Zero Trust Application Access (ZTNA) & Identity-Aware Proxy (IAP)
- URL: https://www.diogomoleta.com/zero-trust-application-access-ztna-identity-aware-proxy-iap/
- Published: 2026-10-04T10:56:39.000Z
- Updated: 2026-10-04T10:56:39.000Z
- Author: Diogo Moleta
- Tags: Cloudflare, Incident Response, SecOps, WAF, Technology, Zero Trust, Identity Aware Proxy

## 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 (V*Host*) 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)

| **Test Vector**             | **Response Obtained** | **Active Defense Layer**            | **Security State**                                     |
| --------------------------- | --------------------- | ----------------------------------- | ------------------------------------------------------ |
| **Malicious Request / Bot** | HTTP 403              | Layer 1: Edge WAF                   | Blocked at the Edge due to header anomalies            |
| **Unauthenticated Access**  | HTTP 302              | Layer 2: Identity-Aware Proxy       | Intercepted and redirected for identity authentication |
| **Authenticated Access**    | HTTP 200              | Layer 3: Outbound Tunnel & Loopback | Access granted to internal application                 |
| **Direct IP Access**        | *Refused / Timeout*   | Origin Hardening (Zero Inbound)     | Impossible (No open public listening ports)            |

## 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.