Access Control Models (RBAC, ABAC, PBAC)

Access control models are systematic frameworks used to regulate who can view or modify resources in an information system. For technology leaders, choosing and implementing the right access control model—Role-Based (RBAC), Attribute-Based (ABAC), or Policy-Based (PBAC)—is a critical architectural decision that directly impacts security posture, system maintainability, and development velocity.

As organisations scale from monolithic structures to distributed, cloud-native architectures, managing access control becomes increasingly complex. Moving from hardcoded rules to decoupled, policy-as-code models is a key milestone in engineering maturity.

Evolution of Access Control Models

1. Role-Based Access Control (RBAC)

RBAC is the traditional approach to access control. Permissions are associated with specific roles (e.g., Billing Administrator, Support Engineer), and users are assigned to one or more of these roles.

• How it works: A user requests access. The system checks if the user's role has the required permission in a static role-permission matrix.
• Pragmatic Pros:
  • Simple to design, implement, and audit for early-stage or small organisations.
  • Fits natural organisational hierarchies (e.g., Finance, Engineering, HR).
  • Highly performant, as it only requires simple database lookups.
• Strategic Cons:
  • Role Explosion: As requirements become more granular (e.g., "only allow Billing Administrators in the UK to view accounts with under £10k in ARR"), organisations end up creating hundreds of hyper-specific roles, making the system unmanageable.
  • Context Ignorance: RBAC cannot evaluate dynamic environmental variables (such as time of day, IP address, or active threat levels).

2. Attribute-Based Access Control (ABAC)

ABAC replaces static roles with dynamic rules based on attributes. It evaluates four categories of attributes in real time to grant or deny access:

1. Subject: Attributes of the user (e.g., department, clearance level, role).
2. Resource: Attributes of the object being accessed (e.g., file type, creation date, project tag).
3. Action: The operation being performed (e.g., read, write, export).
4. Environment: Contextual variables (e.g., request time, network location, device security health).

• How it works: When a user requests access, an evaluation engine runs the request attributes through a set of logic rules.
• Pragmatic Pros:
  • Extremely granular and flexible control.
  • Solves role explosion; a single policy can govern thousands of scenarios dynamically.
  • Enables context-aware security (e.g., "only access database from corporate VPN during working hours").
• Strategic Cons:
  • Implementation Complexity: Writing and maintaining complex boolean rules can easily lead to conflicts or security loopholes.
  • Performance Overhead: Dynamically querying databases for resource and environment attributes during every API request introduces latency.
  • Auditability Challenges: It is difficult to query the system to find out exactly what resources a specific user can access, as permissions are calculated dynamically.

3. Policy-Based Access Control (PBAC) & Policy-as-Code

PBAC represents the modern architectural evolution of access control, merging the fine-grained flexibility of ABAC with software engineering best practices. It explicitly decouples authorisation logic from application business logic, treating policies as code.

Instead of writing inline if/else security checks inside your application code, applications query a dedicated, externalised policy engine.

Open Policy Agent (OPA) and Rego

The de facto standard for implementing Policy-as-Code is Open Policy Agent (OPA), a CNCF graduated project.

• Rego: OPA policies are written in Rego, a declarative, query-focused policy language designed to express complex rules over hierarchical JSON data structures.

• Decoupled Architecture: Your microservice receives an HTTP request, packages the transaction details (user, action, resource attributes) as JSON, and posts it to OPA (often running as a sidecar). OPA evaluates the JSON against loaded Rego policies and returns a simple allow: true/false decision.

• Pragmatic Pros:

  • Unified Security: Enforce consistent access policies across the entire stack—APIs, microservices, Kubernetes clusters, database layers, and CI/CD pipelines.
  • Software Engineering Workflow: Security policies are stored in Git repositories, allowing for code reviews, automated unit testing, version control, and continuous integration (GitOps).
  • High Performance: OPA stores policy rules and data in-memory, ensuring sub-millisecond evaluation times.

• Strategic Cons:

  • Infrastructure Overhead: Requires running and monitoring OPA sidecars or centralised policy daemons.
  • Learning Curve: Engineers must learn Rego, which uses a logic-programming paradigm (similar to Datalog) different from traditional imperative languages.

Strategic Utility: The CTO's Playbook

For a technology leader, the choice of authorisation architecture is not just a security concern; it is a scalability and velocity driver.

1. Stop Hardcoding Authorisation Logic

Hardcoding permission checks inside application services is a massive form of technical debt. It prevents security teams from modifying access policies without redeploying code. Centralise and abstract your authorisation early.

2. Standardise on Policy-as-Code (PBAC) for Microservices

If you are running a distributed or microservice architecture, RBAC is insufficient. Adopt OPA or similar engines to keep authorisation rules centralised and easily auditable.

3. Embrace GitOps for Policy Changes

When policies are managed as code, changes undergo the standard pull request flow. This allows you to run automated tests checking for permission leaks and gives auditors a complete, cryptographic history of every policy change.

4. Solve the "Data Filtering" Challenge

While PBAC is excellent for single-request decisions ("Is Alice allowed to view this document?"), it is harder to use for listing items ("Show Alice all documents she is allowed to view"). Ensure your architecture solves this by either using query-generation techniques (e.g., OPA compile API) or combining PBAC with database-level row filters.

Explore Next

• Principle of Least Privilege — Ensuring users and systems have only the minimum access necessary.
• Threat Modelling — Identifying security risks and access-control flaws early in the design phase.

References

• Open Policy Agent (OPA) — Open source, general-purpose policy engine that decouples policy decision-making from application logic.
• Rego Policy Language — OPA's declarative policy language designed for querying complex hierarchical data structures.
• NIST Guide to Attribute Based Access Control — NIST's official guidelines and definitions for implementing ABAC systems.