UprootSecurityUprootSecurity

Phase 5 · Zero Trust Networking (ZTNA vs VPN) · Lesson 3 of 3

Configure ZTNA for a 50-Person Company

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.

The company

Northwind Labs has three employee groups and one contractor group, and three internal applications:

  • Groups: Engineering (20), Sales (15), Finance (8), plus external Contractors (a handful, on unmanaged personal devices).
  • Applications: an internal wiki (general docs, low sensitivity), a git server (source code), and a finance app (financial records, regulated data).
  • Identity is in Okta; all employees have MFA. Devices for employees are managed and reporting posture via MDM/EDR (Phase 3). Contractors are on personal, unmanaged devices.

Decision 1: How should the finance app be gated?

Quick check

The finance app holds regulated financial records. Which access policy best fits Zero Trust least privilege?

Decision 2: What should contractors on unmanaged devices reach?

Quick check

Contractors work on personal, unmanaged devices and need the internal wiki to do their work. How should their access be scoped?

Build it: the ZTNA access policy

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.

Loading editor…

What to carry forward

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?

Configure ZTNA for a 50-Person Company — UprootSecurity Bootcamp