Zero-trust network access: identity, mTLS, micro-segmentation
You build an access architecture that checks every request by identity and device state instead of trusting the network, with VPN-less app access, mTLS and fine-grained segmentation.
Level 501 · 17 lessons · 15 practice labs
Lessons
Principles
- Zero-trust principles and the reference architecture (NIST SP 800-207)
- The problems with implicit trust: flat networks and broad VPNs
- Maturity assessment and roadmap
- Short task: list the implicit trust points of an existing network
Identity-aware access
- Identity-aware proxies and OIDC
- Device posture checks
- mTLS between services
- Short-lived certificates and SSH certificates
- Short task: open an internal app without a VPN but with verification
Segmentation
- Segmentation at the host: nftables and identity labels
- WireGuard-based mesh networks
- Writing access policy as code
- Short task: cut server-to-server traffic down to what is needed
Monitoring and migration
- Continuous verification: logs and anomalies
- A migration plan from a flat network to zero trust
- Short task: run a pilot migration in one department
Wrap-up
- Capstone: build and test a zero-trust access architecture for an organisation
Practice labs
- How far can one laptop reach?: With an authorised scan of your own flat lab network, map the servers and management services reachable from an ordinary staff machine, and list those its job does not need.
- Whoever enters the VPN enters everything: Measure in the lab what Copperleaf Insurance’s VPN users can really reach, draw up a role-based access matrix, close the excess access and confirm by measuring again.
- A zero-trust maturity scorecard: From the configuration and logs of Silverwater Municipality’s lab environment, produce an evidence-based maturity scorecard for identity, device, network and workload, and rank the five steps with the biggest gain.
- Anyone signed in sees the HR app: Limit access to the HR app on the identity-aware proxy to the HR group only, and show the allow and the deny with two test users from different groups.
- The sign-in page keeps looping: Find from the logs the redirect-URI and client-setting mismatch between the proxy and the identity provider, fix it and prove it by signing in and reaching the app.
- Around the proxy, straight to the app: Show in your own lab that the internal app can be reached directly, bypassing the proxy, with a forged identity header; lock the backend to verified requests from the proxy only and prove the same attempts fail.
- The order service cannot reach the stock service: Use openssl to find why the mTLS connection between two services fails (no client certificate presented, wrong CA), fix it and show a request without a certificate is still refused.
- Eight-hour certificates instead of permanent SSH keys: Replace permanent authorized_keys entries on the servers with short-lived certificates signed by an SSH CA, and show a login with an expired certificate being refused.
- No downtime while certificates rotate: Set up short-lived service certificates that renew automatically and reload the service without interruption, and show by measurement that a running request stream has no errors across a renewal.
- Everyone can connect to the database: Use nftables on the database server to allow connections only from the app server, and show it by testing from one allowed and one disallowed source.
- Generate access policy from code: Write a small tool that generates nftables rules from Brightfield Labs’s service access policy in YAML and automatically tests every allow and deny, and show it working on a policy change.
- An encrypted mesh between servers: Build a WireGuard-based mesh between three servers, pass service traffic only over the mesh with per-peer permissions, and prove with a capture that the unencrypted direct path is closed.
- An odd identity in the access logs: Find the identity arriving at unusual hours and from an unusual source in the proxy’s access logs, list the apps it reached and end its session.
- No entry for an out-of-date device: Write a rule tying access to Harborview Hospital’s patient-records app to device posture, and show the same user getting in from a compliant device and not from a non-compliant one.
- Back paths forgotten after the migration: In a department already moved to zero trust, find from logs and tests the old paths still open (a broad VPN rule, an allow-all firewall line, a permanent SSH key), close them and prove the app is reachable only through the proxy.
About this course
You build an access architecture that checks every request by identity and device state instead of trusting the network, with VPN-less app access, mTLS and fine-grained segmentation.
What you will learn
- Principles
- Identity-aware access
- Segmentation
- Monitoring and migration
- Wrap-up
Prerequisites
You should be experienced in the topics of the same path up to level 401.
Lab environment
Lessons run in your own Kali Linux terminal in the browser, connected to a private lab network. Nothing to install.
Frequently asked questions
- Is this course right for my level?
- The course is at level 501; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.