6.2 Access Control Models: RBAC, MAC, DAC, ABAC, and Risk-Based Access

Choosing an Access Control Model

An access control model is a way to express and enforce who can access an object and what operation is allowed. The object may be a file, database row, SaaS function, network segment, API method, lab room, or cloud resource. The subject may be a person, process, device, service account, or federated identity. The model should make policy repeatable, understandable, and auditable.

Role-based access control assigns permissions to roles, then assigns subjects to those roles. It is useful when job functions are stable and repeatable, such as nurse, teller, payroll analyst, developer, or database administrator. RBAC reduces one-off permissions and makes reviews easier because the reviewer can ask whether the person still performs that role. RBAC becomes risky when roles grow too broad or exceptions accumulate without cleanup.

Mandatory access control uses centrally managed labels and clearances. The subject has a clearance or category, the object has a classification or label, and the system enforces the access rule. MAC is common in highly regulated, military, intelligence, or sensitive compartmented environments where the owner of a file should not casually grant access. MAC provides strong control, but it can be expensive to administer and may slow collaboration if classification discipline is poor.

Discretionary access control lets an object owner decide who receives access. It is common in file shares, collaboration platforms, and project workspaces. DAC supports flexibility because the owner can share with a colleague quickly. Its weakness is that users may overshare, grant access to groups they do not understand, or fail to remove access after the business need ends. DAC needs education, default restrictions, monitoring, and periodic review.

Attribute-based access control uses attributes about the subject, object, action, and environment. A policy might allow a doctor assigned to a patient to view records from a managed device during an active treatment relationship. Attributes can include department, location, sensitivity, device posture, data owner, transaction amount, time, or risk score. ABAC is powerful, but it depends on accurate attribute sources and disciplined policy design.

Risk-based access evaluates context at decision time. A normal login from a managed laptop may be allowed with existing authentication, while a login from a new country may require step-up MFA or be blocked. Risk-based access is especially useful for cloud, remote work, and consumer-facing services because risk changes constantly. It should supplement least privilege, not replace it. A high-risk signal should tighten access; a low-risk signal should not grant access that policy never allowed.

The access model also shapes separation of duties. A role that allows vendor creation should not automatically include vendor payment approval. A risk-based policy that allows emergency access should require monitoring and later review. An ABAC rule that checks department must also consider transaction authority. Access control is not only about entry; it is about preventing a single subject from completing a harmful action without oversight.

CISSP-level design starts with business classification and data ownership. Highly sensitive intellectual property may require labels, explicit approval, strong logging, and limited export paths. Routine project files may use DAC with guardrails. Enterprise applications may use RBAC for standard work and ABAC for exceptions such as region, customer assignment, or data sensitivity. Administrative access should usually be separate, more strongly authenticated, and time limited.

A common mistake is treating RBAC as a one-time setup project. Roles must be engineered, tested, reviewed, and retired. If every exception becomes a new role, the organization suffers role explosion. If exceptions are added directly to users, the organization loses visibility. The better approach is to define baseline roles, document controlled exception paths, set expiration dates, and run access reviews that challenge accumulated entitlements.

Another mistake is adopting ABAC before the organization can trust its attributes. If department codes are stale, manager records are wrong, device posture is spoofable, or data labels are incomplete, the policy engine will make precise decisions from bad inputs. Attribute governance includes authoritative sources, change ownership, validation, monitoring, and failure behavior. If an attribute is missing, the policy should usually fail closed for sensitive access.

Model Selection Workflow

1. Classify the asset and identify the owner.
2. Define allowed actions and business roles.
3. Identify duty conflicts, sensitivity labels, and regulatory requirements.
4. Choose the simplest model that enforces the required control.
5. Add contextual or risk-based conditions only where they reduce real risk.
6. Test access paths, logging, exception handling, and deprovisioning.
7. Review assignments and policies on a schedule based on criticality.

Least privilege should remain the anchor regardless of model. The organization should be able to explain why a subject has access, what condition allows it, who owns the decision, how misuse would be detected, and when the access will be removed. A model that cannot answer those questions may be technically functional, but it is not strong governance.