Introduction
Once a system has authenticated a user, it must decide what that user is allowed to do — this is access control. Different organizations and systems use different models to structure these decisions, and choosing the right model has a major impact on both security and manageability. The three foundational models every security practitioner should know are DAC, MAC, and RBAC.
Cricket analogy: Just as Mumbai Indians must decide which coaches, physios, and support staff can enter the dressing room, IT systems need models like DAC, MAC, and RBAC to decide who gets access.
Explanation
Discretionary Access Control (DAC) puts permission decisions in the hands of the resource's owner. Whoever creates or owns a file, folder, or object can decide who else gets to read, write, or execute it, and can change those permissions at will. This is the model used by most everyday operating system file systems — for example, when you create a document on your computer and choose to share it with a specific colleague, you are exercising discretionary control. DAC is flexible and easy to use, but because permission decisions are decentralized among many individual owners, it is harder to enforce consistent organization-wide policy and easier for permissions to sprawl or be granted too generously.
Cricket analogy: DAC is like a team captain personally deciding which teammates can borrow his personal bat, granting or revoking permission on a whim rather than following a fixed club-wide policy.
Mandatory Access Control (MAC) removes that discretion from individual users. Instead, the system itself enforces access decisions based on fixed labels and clearances defined by a central authority, and ordinary users — including resource owners — cannot override them. A classic example is a government or military classification system: a document might be labeled 'Secret,' and a user can only access it if their assigned clearance level is 'Secret' or higher, regardless of who created the document or whether they personally want to share it. MAC is used where strict, centrally enforced confidentiality is critical, because it eliminates the risk of an individual user misconfiguring or loosening permissions.
Cricket analogy: MAC is like ICC match officials enforcing a fixed accreditation level: even the team captain cannot let an unaccredited person onto the field, regardless of personal wishes.
Role-Based Access Control (RBAC) ties permissions to roles rather than to individual users or rigid classification labels. Administrators define roles (such as 'HR Manager,' 'Billing Clerk,' or 'System Administrator'), assign specific permissions to each role, and then assign users to one or more roles. A new employee gains the correct access simply by being assigned the appropriate role, and access changes automatically when their role changes, without an administrator having to hunt down and adjust dozens of individual permission entries. RBAC is extremely common in business applications and cloud platforms because it scales well and closely mirrors how organizations already think about jobs and responsibilities.
Cricket analogy: RBAC is like a franchise assigning permissions by role, 'Captain,' 'Coach,' 'Physio', so a new signing automatically gets the right dressing-room and strategy-meeting access the moment they're assigned that role.
Example
DAC: Alice creates 'budget.xlsx' and personally grants Bob read access.
Alice, the owner, decides -- not a central policy.
MAC: A file is labeled CLASSIFIED: SECRET.
Only users with a SECRET or higher clearance, as assigned by
a central security authority, can open it -- not even the
file's creator can grant access to an uncleared user.
RBAC: The role 'Payroll Admin' includes permission to edit salary
records. Carol is assigned the 'Payroll Admin' role, so she
automatically gains that access. When Carol changes teams,
removing the role instantly removes the access.Analysis
The choice of access control model reflects a tradeoff between flexibility and central control. DAC is simple and user-friendly but scales poorly for security-sensitive organizations, since any owner can accidentally or intentionally over-share a resource. MAC provides the strongest, most consistent enforcement of confidentiality because no individual user can weaken it, but it is rigid, administratively heavy, and impractical outside high-security environments like defense and government systems. RBAC strikes a practical middle ground for most businesses: it centralizes policy (permissions are defined per role, not per person) while still scaling efficiently as employees join, move between teams, or leave, since administrators manage a manageable number of roles rather than an ever-growing web of individual grants. Many real-world systems combine elements of these models — for instance, using RBAC as the primary structure while layering MAC-like mandatory rules for especially sensitive data.
Cricket analogy: Choosing DAC, MAC, or RBAC is like a cricket board choosing between letting individual clubs set their own entry rules, a rigid national policy, or role-based accreditation, balancing flexibility against consistent control.
Key Takeaways
- DAC (Discretionary Access Control): the resource owner decides who gets access, as seen in typical file system sharing.
- MAC (Mandatory Access Control): access is enforced by the system based on centrally assigned labels/clearances, and individual users cannot override it — common in military/government systems.
- RBAC (Role-Based Access Control): permissions are tied to roles, and users inherit access by being assigned to a role, making it scalable for most organizations.
Practice what you learned
1. In Discretionary Access Control (DAC), who typically decides who can access a resource?
2. Which access control model is best exemplified by a military document labeled 'Secret' that only users with the matching clearance can open, regardless of who created it?
3. In Role-Based Access Control (RBAC), how does a new employee typically gain the correct system access?
4. Why is MAC considered stronger for enforcing confidentiality than DAC?
Was this page helpful?
You May Also Like
Authentication Basics
Learn how systems verify identity through authentication, how it differs from authorization, and the three factor categories used to prove who you are.
Security Policies and Governance
Learn how policies, standards, procedures, and guidelines work together to govern an organization's security program.
Session Management Security
How to protect user sessions with secure cookie attributes and defenses against fixation and hijacking.
Risk Assessment Basics
Understand how to calculate risk as likelihood times impact and choose between accepting, mitigating, transferring, or avoiding it.