Course Preview

Zero Trust Architecture

Zero trust architecture protects each resource by checking the identity and context of every access request instead of treating a network location as trusted. It combines policy decisions, enforcement points, identity systems, device information, and monitoring to grant only the access needed for one session.

itCybersecurity fundamentals and governance | OpenSkills.info

Course pathWalk it in order

Look it upDip in anytime

Go furtherLeaves this page

Don't Panic: Zero Trust Architecture

Zero trust architecture is the habit of asking a specific question before opening a specific door: may this subject perform this action on this resource, under these conditions, right now? The old perimeter model was more like issuing everyone inside the building a map to the whole building. It was convenient until the map escaped, which maps are prone to doing when nobody is looking.

The important unit is the resource: an application, service, data store, device, or workload. A request reaches a policy enforcement point, which asks the policy decision point to consider identity, device or workload posture, the requested action, resource sensitivity, and other current evidence. A previous approval is useful history, not a lifetime membership card.

This divides the machinery into a control plane and a data plane. The policy engine decides. The policy administrator establishes or ends the path. The policy enforcement point applies the result to traffic. Those names sound like a committee that needed another committee, but the split helps locate a failure. A bad decision, a broken path, and a bypass are different problems.

Identity matters, but it is not the whole answer. A valid account on an unhealthy device may need a different result. A healthy device does not give its user permission to administer every application. That is why a useful policy names a subject, action, resource, conditions, and duration. The grant should fit the request, not the network it came from.

There is no single zero trust topology waiting behind a tasteful dashboard. A gateway can protect a group of legacy systems. An identity-aware portal can front a web application. A workload proxy can protect one service calling another. Each placement changes the evidence available, the failure concentration, and the size of the blast radius. Buying a broker supplies neither an inventory nor a correct policy, alas.

Migration starts with one bounded path. Inventory its subjects, assets, resources, and flows. State what happens when identity, posture, policy distribution, or the decision point fails. Observe the path where possible, enforce it for a limited population, and expand when it is operable. The Field Notes tab covers the awkward operational details that turn neat diagrams into support work.

Read the intro for the full decision path and the limits of the model. Use the slides for the component relationships and migration loop. Keep the cheatsheet nearby when reviewing policy inputs, failures, and signals. Then use the practice reference and exercise to turn one small access request into an executable decision. The aim is not to distrust everything. It is to stop trusting location as an answer to a question it never knew how to ask.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources