Learning outcomes
- Replace implicit trust zones with explicit subject-to-resource policy.
- Place policy administration, decision, information, and enforcement components.
- Combine identity-aware access with network, endpoint, workload, and application controls.
- Test direct paths, stale context, control failure, movement, and recovery.
Scenario
A contractor needs one administration application for two weeks. The design must grant the named route, deny the rest of the private network, check current identity and device context, and remove access on schedule.
Ordered learning units
Zero Trust
Zero trust does not assume that every user or device is malicious.
Asset and Protected Resource
Identify what has value, what needs protection, and which resource an access decision controls.
Implicit Trust Zone
An implicit trust zone grants authority from location, membership, or prior access without a resource-specific decision.
Continuous Verification
Continuous verification means that a system continues to evaluate authorization during a session instead of treating the initial login as permanent trust.
Principle of Least Privilege
Limit authority by resource, action, context, and time, then remove access when the assigned function ends.
Control Plane and Data Plane
Separate the systems that define and distribute access policy from the request path that enforces it on live traffic.
Place zero trust policy components
Place policy administration, decision, information, and enforcement components across control and data planes.
Threat-model an identity-aware access path
Trace one protected request, find trust boundaries and bypass paths, and test which access decisions belong at the gateway and application.
Choose the access enforcement layer
Place access enforcement across identity-aware proxies, API gateways, service meshes, load balancers, and network tunnels.
Compare zero trust deployment models
Compare device agent and gateway, enclave gateway, resource portal, and application sandbox deployment boundaries.
Separate zero trust from ZTNA
Distinguish a resource-centered security architecture from a product pattern that brokers selected remote access.
Use network controls in zero trust
Keep routing, segmentation, firewalls, naming, transport protection, and availability controls without using location as trust.
Apply zero trust to cloud-native systems
Apply user and workload identity across APIs, gateways, meshes, sidecars, clusters, clouds, and application resources.
Combine segmentation with identity policy
Use network segmentation to limit reachability and identity policy to decide access to named services, resources, and actions.
Design access for resilience and recovery
Keep access controls safe through dependency failures, limit damage, recover service, and prove the restored state.
Migrate one application to zero trust
Replace implicit network access with a named, identity-aware route and verify identity, policy, bypass, evidence, and recovery.
Evaluation questions
- Which named resources and actions need protection, and which facts justify each decision?
- Can any public, private, administrative, recovery, or service path bypass mediation?
- What remains trusted, how can it fail, and how does the design limit movement and impact?
Completion conditions
- Produce a zero trust architecture for one service with policy components, data flows, and trust assumptions.
- Demonstrate explicit verification, least privilege, bypass resistance, failure behavior, revocation, and recovery.
