DAC, MAC, RBAC, ABAC and RuBAC: who decides, what the decision is based on, and where you meet each one.
Last updated
Free, no signup · 1 page · all 5 models compared · 222 KB
One question answers most of these: who holds the power to grant access?
| The scenario | Model | Why |
|---|---|---|
| A user shares a document with a colleague they choose | DAC | The owner decides. Discretion sitting with the owner is the definition. |
| Files labelled Secret; only Secret-cleared staff can open them | MAC | Labels and clearances enforced centrally. Nobody can grant an exception. |
| All nurses can view patient records; all billing staff cannot | RBAC | Permission follows the job function, not the individual. |
| The firewall blocks all inbound traffic except port 443 | RuBAC | One rule, applied to everyone. Identity is irrelevant. |
| Nobody can log in outside 07:00 to 19:00 | RuBAC | A blanket condition, not tied to who you are. |
| Access if department = finance AND device is managed AND user is on-network | ABAC | Multiple attributes evaluated together at request time. |
| A contractor gets the same rights as any other project engineer | RBAC | Assigned to a role and inherits its permissions. |
| A user is denied a file they own because policy forbids it | MAC | Ownership does not override central policy. That is the giveaway. |
Three distinctions that decide most questions on this topic.
RBAC is role-based: permissions attach to a job function and users inherit them by holding that role, so access depends on who you are in the organisation. RuBAC is rule-based: a condition applies to everyone alike, regardless of identity, such as a firewall rule or a time-of-day restriction. The abbreviations are almost identical, which is exactly why exams use them. "All managers can approve invoices" is RBAC; "nobody can log in outside business hours" is RuBAC.
It comes down to who has the authority to grant access. Under discretionary access control the data owner decides and can share at will, which is how file permissions and shared drives work. Under mandatory access control a central policy of labels and clearances decides, and no user can override it, not even the owner of the data. MAC is the stricter model and is associated with military and government classification systems.
MAC is the strictest, because enforcement never depends on user judgement and access cannot be delegated. That does not make it the best choice in every setting: it is rigid, administratively expensive and a poor fit where access needs change frequently. Most organisations run RBAC because it balances control against practicality, and increasingly layer ABAC on top for context-sensitive decisions.
Extending rather than replacing it, in most cases. A role is effectively a single attribute, so ABAC is a generalisation of the same idea to many attributes at once — device posture, location, time of day, data sensitivity. Zero-trust architectures lean on ABAC because decisions must account for context, not just identity. In practice most organisations run RBAC as the backbone with attribute-based conditions layered over it.
Every user, process and system gets the minimum access needed to do its job, and nothing more. It is not a model in its own right but a principle you apply within whichever model you use: minimal roles under RBAC, tight labels under MAC, narrow policies under ABAC. Related principles that often appear alongside it are separation of duties, which splits sensitive tasks between people, and need to know, which limits access to information rather than systems.