Access Control Explained: From DAC and MAC to RBAC and ABAC

What Is Access Control, Really?

Access control is the set of methods and mechanisms that decide who gets to touch what in a system. It’s not just about passwords or permissions—it’s the whole process of authorizing, monitoring, and limiting what users, applications, and processes can do with files, services, and data.

Think of it this way: the person or thing trying to access a resource is the subject—could be a human, an app, or a background process. The resource itself—a document, a database, a printer—is the object. The authorization part defines what actions the subject can perform (read, write, delete, send email). The control part is the enforcement: it checks whether to allow or deny each attempt, and it can log or alert on suspicious behavior.

There are two main goals. First, keep unauthorized users out. Second, stop even legitimate users from doing things they shouldn’t. That means every access attempt goes through identity verification first, then gets checked against a set of rules. And if something weird happens, the system should be able to record it for later review.

The Standard Access Control Model

Most access control systems follow a common blueprint with five pieces:

• Subject – the active party (user, process, device).
• Object – the passive resource being accessed.
• Reference monitor – the decision-making and enforcement engine. It sits between subject and object, checks every operation, and logs important events.
• Access control database – stores the rules: what each subject is allowed to do to each object.
• Audit trail – records all access attempts, both successful and failed, for security review.

This model is the backbone for everything from simple file permissions to enterprise-level security platforms.

Four Major Access Control Models

Discretionary Access Control (DAC)

In DAC, the owner of an object gets to decide who else can access it. It’s flexible but can be risky if users make poor choices. Two common implementations are row-based and column-based.

Row-based attaches a list to each subject. That list might be a capability list (what objects can this subject access and how), a prefix table (permissions for protected objects), or simply a password for each object. Linux file permissions are a classic example of DAC, using read, write, and execute bits for the owner, group, and everyone else.

Column-based attaches a list to each object. The most common is the Access Control List (ACL), which spells out exactly which subjects can access that object and with what permissions. Another older method is protection bits, like the rwx bits in Unix.

Mandatory Access Control (MAC)

MAC flips the power dynamic: the system, not the object owner, decides access based on security labels. Every subject and object gets a security level and category. A process can only access a file if its level is high enough and its categories include the file’s categories.

This is much stricter than DAC, and it’s what you see in military or government systems. If you’ve studied the BLP model for confidentiality, it’s the same idea: no reading up, no writing down.

Role-Based Access Control (RBAC)

RBAC is probably the most widely used model in business today. Instead of assigning permissions to every individual, you define roles (like “manager”, “analyst”, “auditor”) and then assign users to those roles. Users and roles can have many-to-many relationships.

The system administrator manages the role definitions and permission sets. For example, an HR specialist might have access to payroll, while a developer only gets code repositories. Windows NT and many modern systems use RBAC in some form.

Attribute-Based Access Control (ABAC)

ABAC is the most flexible and dynamic. It evaluates access requests based on attributes of the subject, the object, and the environment—like time of day, location, or device type. If someone tries to log in from a foreign country at 3 AM on a new phone, the policy might deny access even if the credentials are correct.

ABAC is great for complex, distributed environments where static roles aren’t enough.

Designing Access Control Policies

When you sit down to write access control policies, you need to think beyond just “who can read what.” Here are some things to consider:

• What are the security needs of different applications? Internal users might have different access than external partners.
• What information is relevant to the request? IP addresses, port numbers, device IDs.
• How will you handle data classification and information spread? Some data might be restricted by law or contract.
• How often will you review and update permissions? Access needs change as people change roles.

Access control rules themselves can be based on:

• User identity – classic username/password.
• Role – what job function the user has.
• Address – physical location or network range (e.g., block remote access).
• Time – only allow access during business hours.
• Anomaly detection – lock an account after three failed logins.
• Service limits – prevent denial-of-service by rejecting new connections when capacity gets tight.

Putting It All Together: Process and Management

Actually implementing access control isn’t a one-time task. It’s a cycle:

1. Identify the assets you’re protecting (routers, web servers, databases).
2. Analyze their security needs (confidentiality, integrity, availability).
3. Develop policies and assign permissions accordingly.
4. Deploy the system, set up authentication, and grant initial access.
5. Monitor, review, and adjust policies as things change.

Two principles are crucial here. Least privilege means giving each user only the permissions they absolutely need to do their job—no more. It reduces the blast radius if an account is compromised. User access management covers the full lifecycle: registering new users, assigning permissions, tracking what they do, and revoking access when they leave or change roles.

And don’t forget passwords. Enforce complexity (at least 8 characters, mix of upper/lowercase, numbers, symbols), forbid reusing the same password as the username, change default passwords immediately, limit login attempts, and store password files encrypted. Also, never transmit passwords in plain text, and have a policy for regular password changes. Running a password-cracking tool against your own accounts is a smart way to find weak ones.

Products and Real-World Applications

In the market, you’ll find several types of access control products. 4A platforms (Authentication, Authorization, Account, Audit) provide centralized management for all four functions—often called unified security management platforms. Security gateways like firewalls and UTM devices control access based on network packet information and threat signatures. System hardening tools, such as SELinux, use mandatory access control to lock down Linux systems.

When evaluating these products, look at the variety of rule types they support, the maximum number of rules, how fast they can check a rule, and their own security certifications.

On the practical side, you see access control everywhere:

• Linux file permissions with rwx bits for owner, group, and others.
• FTP servers that allow anonymous access but restrict uploads or downloads.
• VLANs that segment a network into isolated subnets to limit broadcast storms and unauthorized access.

Access control isn’t just a checkbox—it’s a fundamental layer of security that requires thought, maintenance, and the right tools. Get it right, and your systems stay safe. Get it wrong, and even the best encryption won’t save you.