For the complete documentation index, see llms.txt. This page is also available as Markdown.

ABAC Model

Purpose

Attribute-Based Access Control uses attributes about the subject, object, action, environment and risk context to make access decisions.

ABAC is useful where access depends on dynamic factors such as classification, clearance, project membership, device health, location, data ownership, customer constraints or time-bound need.

Attribute Categories

Attribute type
Examples

Subject

identity, employer, contract, role, clearance, BPSS status, nationality constraint where lawful and required, training status.

Object

data classification, record owner, project, system, environment, export marking, retention category.

Action

read, write, approve, export, delete, deploy, administer, share.

Environment

device health, network, location, time, session risk, MFA status.

Relationship

project member, case owner, system owner, supplier on approved SoW.

Policy Example

A user may access an OFFICIAL-SENSITIVE project repository only when:

  • the user is an approved member of the project;

  • the user has completed required screening;

  • the user's organisation is covered by contract and confidentiality obligations;

  • MFA is satisfied;

  • the device is compliant;

  • the access occurs through an approved network or conditional access route;

  • the repository owner has approved the access;

  • access is logged.

ABAC Governance

ABAC requires strong governance because policy decisions are only as reliable as the attributes used.

Attribute governance must define:

  • authoritative source;

  • attribute owner;

  • update process;

  • review cadence;

  • audit requirement;

  • retention period;

  • lawful basis where personal data is used;

  • test cases and expected decisions.

Quality Gate

No ABAC policy should be deployed until positive tests, negative tests, logging, review ownership and exception handling are complete.

Last updated

Was this helpful?