Access control models and policy engines

Once identity is settled, something has to decide what that identity may do. Three models dominate, and they layer rather than compete.

• ACL: a list attached to a resource saying who may touch it. Simple, and it sprawls badly.
• RBAC: permissions attach to roles, identities get roles. Scales with people; struggles with context.
• ABAC: decisions consider attributes of the principal, the resource, the action, and the environment. Expressive enough for 'only during business hours, from this network, on non-production data'.

Policy-as-code is the natural end point: rules live in a declarative language, are version-controlled, reviewed, and tested like any other code. Cedar and Rego are two widely used examples.

Real engines need a conflict rule, because policies overlap. Two common designs:

• Deny always wins: simple and predictable, but you cannot carve an exception out of a deny.
• Explicit priority: each rule carries a number and the highest wins, which is more flexible and demands more care.

Finally, separate the decision from the enforcement. A policy decision point evaluates the rules; a policy enforcement point sits in the request path and applies the answer. Keeping them apart is what lets you test policy in isolation, and run it in shadow mode before it can break anything.