Phase 5 · Zero Trust Networking (ZTNA vs VPN) · Lesson 3 of 3
Exercise
·
15 min
·
+20 pts
A ZTNA policy is where the Zero Trust principles stop being abstract: you decide, group by group and app by app, who can reach what, on which devices, and under what conditions. In this exercise you'll author the access policy for Northwind Labs, a 50-person company replacing its flat VPN. First work through two policy-design decisions, then write the full configuration as YAML — the same shape a ZTNA broker's policy takes.
Northwind Labs has three employee groups and one contractor group, and three internal applications:
Quick check
The finance app holds regulated financial records. Which access policy best fits Zero Trust least privilege?
Quick check
Contractors work on personal, unmanaged devices and need the internal wiki to do their work. How should their access be scoped?
Now write the full configuration. Define the identity provider and MFA, the device-posture checks, and a per-application access policy for each app — naming the groups allowed, and whether each requires a compliant device and MFA. Fill in every field; replace the placeholder comments.
Exercise
~15 min
Configure the ZTNA access policy for Northwind Labs
Zero Trust Finding
Replace the flat VPN with per-application ZTNA access policies
ID:
ZTNA-5.2.3
Criterion:
Per-application, identity- and device-aware access (no flat network access)
Severity:
Design task
Northwind Labs (50 people) is retiring its flat VPN. Define the identity provider and MFA, device-posture requirements, and per-application access policies for three apps — internal wiki (low sensitivity), git server (source code), finance app (regulated records) — across Engineering, Sales, Finance, and external Contractors (unmanaged devices). Access must be per-application and least privilege, with no implicit network reach.
Auditor Notes
Least privilege per group. Finance app requires a managed + compliant device and MFA, Finance group only. Git server requires a managed + compliant device, Engineering only. Contractors get the wiki only (MFA, no managed-device requirement for that low-sensitivity app) and no path to git or finance. The legacy flat VPN must be decommissioned, not left running in parallel.
Write your remediation plan in YAML below. Fill in every field — replace all placeholder comments.
A ZTNA policy encodes Zero Trust as concrete grants: an identity source with MFA, device-posture checks, and one rule per (group → application) pair you deliberately allow — everything else is denied by default. The judgment calls are the ones you made here: gate regulated apps on both group membership and a compliant device, scope unmanaged contractors to only the low-sensitivity resources their work needs, and — the step teams forget — actually decommission the old flat VPN so the lateral-movement path is closed. When you review a ZTNA deployment, you read exactly this artifact and ask: is access per-app, is it conditioned on identity and device, is it least privilege, and is the legacy bypass really gone?