Implementing Access Control Models: RBAC, ABAC, and Mandatory Access Control Principles

There is a moment, in almost every organisation that has ever grown beyond a handful of people, when someone realises that not everyone should be able to see everything. Perhaps it is a hospital where a billing clerk accidentally opens a psychiatrist's private case notes. Perhaps it is a technology company where a newly hired intern discovers, with a few clicks, that she can read the salary records of every employee. Perhaps it is a government agency where a low-ranking analyst finds that nothing stops him from browsing files marked for the eyes of generals only. In each case, the problem is the same: the organisation has data, it has people, and it has no sensible system for deciding who among those people should be permitted to touch which piece of that data. This problem is what access control exists to solve, and understanding it properly is one of the most practical and important skills in the entire field of computer security. To make the idea concrete before we build up to the technical details, think about a large hotel. The hotel has many kinds of spaces. There are guest rooms, which only the specific guest assigned to that room should enter. There is a linen closet on each floor, which housekeeping staff can open but guests cannot. There is an office where the accounts are kept, which only the finance manager and the general manager may access. There is a server room in the basement, which only the IT technician is permitted to enter. And then there is the general manager's private safe, which only the general manager herself can open. The hotel has a system, usually a combination of physical keys, key cards, and locked doors, that enforces all of these rules without requiring a person to stand guard at every door. Digital access control works on exactly this principle. The "doors" are files, databases, applications, and network resources. The "keys" are permissions. The challenge is designing the system of locks and keys in a way that is both secure and practical for the people who work there every day. Over the decades, computer scientists and security engineers have developed three major approaches to this challenge. Each one reflects a different philosophy about how to organise the relationship between people, data, and rules. The oldest and strictest is called Mandatory Access Control, which we will abbreviate as MAC. The most commonly used in ordinary businesses today is called Role-Based Access Control, abbreviated RBAC. The newest and most sophisticated is called Attribute-Based Access Control, or ABAC. By the end of this lesson, you will understand not just what each model is, but why each was invented, how each works in practice, and what the real trade-offs are when an organisation chooses between them. Let us begin at the beginning, with the strictest model of all. Mandatory Access Control was born not in a technology company but in the United States Department of Defense in the early 1970s. The problem the military faced was specific and serious. They had computing systems that handled information at several different levels of sensitivity. Some information was labelled Unclassified, meaning anyone could read it. Some was Confidential, meaning only certain cleared personnel should see it. Some was Secret, meaning an even smaller group had access. And some was Top Secret, meaning only a very small number of specially vetted individuals were permitted near it. The danger was not so much that an outsider would break in, but that information would leak downward. A general might accidentally copy a Top Secret analysis into a document that was only classified as Secret, and suddenly information that should have been seen by five people was visible to five hundred. The military needed a system that made this kind of leak technically impossible, not just against the rules. The solution was to attach a label to everything. Every file, every document, every database record received a security label indicating its classification level. Every user, every process, and every program received a corresponding security clearance. Then the operating system, the fundamental software that runs the computer itself, was given a set of rigid rules it had to enforce for every single action on the system. No human administrator had to watch. The computer itself was the enforcer. The most famous set of rules to come out of this era is called the Bell-LaPadula model, named after the two researchers David Bell and Leonard LaPadula who formalised it around 1973. The model was designed with one goal: protect confidentiality. In other words, make sure that sensitive information never flows to someone who is not authorised to see it. The model expressed this through two rules that are beautifully simple to remember. The first rule is called the Simple Security Property, but people who work in security usually describe it with the phrase "no read up." It means that a user can only read information at their own level or below. A person with a Secret clearance can read Secret and Confidential documents, but they absolutely cannot read a Top Secret document. They cannot even look at it. The computer will refuse the request. Think of it like a lift in a building where the floors represent classification levels. You can go to your floor and to any floor below yours, but the lift simply will not take you to a floor above your clearance. The second rule is called the Star Property, written with an asterisk symbol, and people describe it as "no write down." This one is a little less intuitive, but it is arguably more important. It says that a user cannot write information to a lower classification level than their own. If you have a Top Secret clearance and you are working with Top Secret information, you cannot copy that information into a file labelled Confidential. Even if you do this by accident, even if you genuinely believe the information is harmless, the system will not allow it. The reason is that allowing downward writing would be a perfect channel for information to leak. A malicious insider with a high clearance could "launder" Top Secret information by writing it into an Unclassified file and then sharing that file freely. A few years after Bell-LaPadula, a researcher named Kenneth Biba identified a gap. Bell-LaPadula protected confidentiality, but it said nothing about integrity. Integrity, in security terms, means the trustworthiness and accuracy of data. It means ensuring that data has not been tampered with or corrupted. Biba noticed that if you only follow Bell-LaPadula, you create a strange situation: a highly trusted process can read data from a very low-trust source. Imagine a critical piece of software that controls a power station reading instructions from an untrusted, potentially compromised external source. The confidential data is protected, but the integrity of the critical system is at risk. The Biba model, published around 1977, flips the rules. It says "no read down" and "no write up." A trusted process should not read from untrusted sources, because that corrupts the quality and reliability of its inputs. And an untrusted process should not be able to write to a trusted destination, because that corrupts the trusted record. Think of a scientist keeping a meticulous research journal. The scientist should not copy unverified rumours from an unreliable blog into the journal, because that would contaminate the scientific record. And a random member of the public should certainly not be permitted to write entries directly into the journal. Biba's rules enforce exactly this kind of data hygiene at the system level. The most important real-world example of MAC in action today is something called SELinux, which stands for Security-Enhanced Linux. Linux is the operating system that runs an enormous proportion of the world's web servers, phones running Android, and critical infrastructure. SELinux is a set of mandatory access control rules that is built directly into the Linux kernel. In SELinux, every file and every running process is given what is called a security context, which is essentially a detailed label describing what type of thing it is. The system administrator writes a policy, and that policy specifies, with great precision, which types of processes are allowed to interact with which types of files. Here is a concrete example of why this matters. Imagine a web server, like the Apache software that powers millions of websites. An attacker finds a bug in Apache and manages to take control of the Apache process. Normally, once you control a process, you can do nearly anything that process is allowed to do. On a typical Linux system, the Apache process might run as a user with access to many parts of the filesystem, and the attacker could steal database passwords, read user files, or install malicious software. But on a system protected by SELinux, the Apache process has been given a very specific security context. The policy says that a process with the Apache context can only read files that have the web content context. It cannot read the directory where system passwords are stored. It cannot read user home directories. It cannot write to most parts of the filesystem at all. Even though the attacker now controls the Apache process, they find themselves in a very small cage. The damage they can do is radically limited. MAC, in this case, has turned a potentially catastrophic breach into a minor incident. The advantages of MAC are real and significant. It provides the highest level of security available, it cannot be overridden by individual users, and because it is enforced at the kernel level, it is extremely difficult to bypass. The disadvantages are equally real. It is rigid, costly to administer, requires labelling every single object and subject in the system, and is fundamentally unsuited to the kind of dynamic, collaborative work that most businesses do every day. A hospital where doctors cannot share notes with specialists, or a company where teams cannot collaborate across departments, would grind to a halt under a pure MAC system. This is why MAC is mostly found in military systems, intelligence agencies, and critical infrastructure, places where security is so paramount that operational flexibility is genuinely considered a secondary concern. This limitation led to the development of the second model, and by far the most widely used one in everyday business. Role-Based Access Control emerged in a formal academic sense in the early 1990s, though the intuition behind it was older. The key insight was elegant and practical: in most organisations, what matters is not who a specific person is, but what job they do. A hospital does not grant permissions to Dr Alice Smith because she is Alice Smith. It grants permissions because she is a physician. All physicians have the same basic access needs. If the hospital has five hundred physicians, the administrator does not need to manage five hundred individual sets of permissions. She manages one role, called Physician, and assigns all five hundred doctors to it. The architecture of RBAC has three fundamental elements. There are users, which are the individual people who interact with the system. There are roles, which represent job functions or organisational titles, things like Accountant, Sales Manager, Network Engineer, or Nurse. And there are permissions, which are specific approved actions on specific resources, things like Read the financial database, or Execute the payroll application, or Write to the patient records system. The crucial design decision is that permissions are attached to roles, not directly to users. When Alice is appointed as a physician, the administrator adds her to the Physician role. She automatically inherits every permission the Physician role carries. When she is later promoted to Head of Department, the administrator removes her from the Physician role and adds her to the Head of Department role. All her old permissions vanish and all her new ones appear in a single administrative action. This is enormously more efficient than tracking hundreds of individual permissions per person. The process of setting up an RBAC system begins with what practitioners call role engineering. This is, in practice, the hardest part of the whole exercise. Someone has to sit down and carefully map out every distinct job function in the organisation and then determine exactly what permissions each function requires. Done well, this is invaluable, producing a clear picture of who has access to what and why. Done poorly, it produces what the field calls role explosion, which is one of RBAC's most notorious failure modes. Role explosion happens when an organisation tries to handle every edge case and special situation by creating a new, specific role. You start with a clean list of ten roles. Then the Sales team needs a slightly different version of the Sales Representative role for those who also handle international accounts. Then a contractor needs the same permissions as a regular employee except for one specific application. Then a manager needs the permissions of two different roles combined. Before long, you have three hundred roles, many of which differ only in minor details, and the system that was supposed to simplify administration has become its own labyrinth. Avoiding role explosion requires discipline during role engineering, a willingness to accept some imprecision, and a principle of keeping the number of roles as small as the organisation's real needs allow. The hospital example makes RBAC vivid. Consider a hospital with a central database containing patient records, financial information, scheduling data, and supply chain records. The hospital defines a set of roles: Physician, Nurse, Surgeon, Billing Clerk, Pharmacist, and System Administrator. The Physician role carries permissions to read and write patient medical charts, create prescription orders, and view lab results. The Billing Clerk role carries permissions to read insurance information and create invoices, but emphatically does not carry permission to write patient medical charts. The Pharmacist role can view prescription orders and confirm dispensing, but cannot create new prescriptions. When a new doctor joins the hospital, the IT team assigns her to the Physician role, and she immediately has everything she needs to do her job, and nothing she does not need. When she transfers to the research division six months later, they reassign her to the Researcher role, and she now has access to anonymised research data but no longer to individual patient charts she is not treating. This is access control that feels like it matches the real world, because it does. RBAC also makes auditing, which means reviewing who has access to what, much simpler. A compliance officer can look at the Physician role and know exactly what every physician in the hospital can do, rather than reading through five hundred individual permission lists. This is enormously valuable for satisfying the requirements of regulations like HIPAA in healthcare or GDPR in European data protection. RBAC's weaknesses, beyond role explosion, centre on its static nature. A role describes what your job is, not the context in which you are working right now. Suppose a nurse has permission to view patient records as part of the Nurse role. Should she still have that permission at three in the morning when she is not on duty? Should she have it when she is accessing the system from a personal device at home on an unsecured network? Should she have it for every patient in the hospital, or only for the patients in her ward? RBAC has no native way to answer these questions. The role is the role, and if you are in it, you have its permissions, regardless of circumstance. This limitation is precisely what drove the development of the third model. Attribute-Based Access Control is younger than the other two models. The National Institute of Standards and Technology in the United States published a formal definition in a document called Special Publication 800-162, and the model has grown rapidly in importance alongside the rise of cloud computing, the Internet of Things, and the general explosion in complexity of modern digital environments. The word "attribute" is the key to understanding this model. An attribute is simply a piece of information about something. Users have attributes. A user might have attributes like Department equals Finance, SecurityClearance equals Confidential, EmploymentStatus equals Contractor, and TrainingCertification includes DataPrivacyModule. Resources, meaning the files, databases, or services being accessed, also have attributes. A file might have attributes like Sensitivity equals High, ProjectCode equals Alpha, and FileType equals ContractDocument. And crucially, the environment itself has attributes. It is currently two in the morning. The user is connecting from a location flagged as unusual. The network security system has raised a threat alert. An ABAC policy takes all of these attributes and combines them into a logical rule that the system evaluates in real time whenever someone requests access. A policy might say something like this: permit access if the user's Department attribute matches the resource's OwnerDepartment attribute, and the user's SecurityClearance attribute is equal to or higher than the resource's RequiredClearance attribute, and the current time is between nine in the morning and six in the evening, and the user is connecting from a registered corporate device. Every single one of those conditions must be true for access to be granted. If any one of them fails, access is denied. To understand how this is built technically, it helps to know the four components that an ABAC system uses. The first is called the Policy Administration Point, or PAP. This is simply the tool where a security administrator writes and manages the policies. Think of it as the place where the rules are written down. The second is the Policy Decision Point, or PDP, which is the brain of the system. When a user tries to access something, the PDP is the component that gathers all the relevant attributes and evaluates the policies to produce a verdict of either Permit or Deny. The third is the Policy Enforcement Point, or PEP. This is the gatekeeper, sitting between the user and the resource, perhaps as part of a firewall, an API gateway, or an application itself. The PEP sends the request to the PDP, gets the decision back, and then enforces it by either allowing the connection through or blocking it. The fourth is the Policy Information Point, or PIP, which is the source of the attributes. When the PDP needs to know if a user has the right security clearance, it queries the PIP, which might be a human resources database. When it needs to know the sensitivity level of a file, it queries the PIP for that resource's metadata. The PIP is the system's way of staying connected to current, real-world information. An example that brings ABAC to life involves a large technology company with a cloud-based file sharing platform. The company has full-time employees, external contractors, and partner organisations all needing access to various project files. With RBAC alone, this would be a nightmare of overlapping roles and exceptions. With ABAC, the security team writes a set of policies. One policy might say that a full-time employee may read and write files belonging to their assigned project. Another might say that a contractor may only read, not write, files belonging to their assigned project, and only when they are connecting through the company's VPN, which stands for Virtual Private Network, meaning a secure encrypted connection, and only from a device that the company has registered and approved. A third policy might say that all access to files marked as High Sensitivity is denied when the network's threat level attribute is set to Critical, with the single exception of users whose role attribute is IncidentResponder, meaning the team dealing with the emergency. Notice that this third policy could respond automatically to a security incident, tightening access across the entire system the moment the threat level rises, without any human administrator having to manually change anything. This is the power that makes ABAC genuinely transformative. The healthcare world benefits enormously from ABAC's sophistication. Consider the nurse example from before. An ABAC system can include a policy that says a nurse may view a patient's records only if that patient is currently assigned to the nurse's ward, and only during the nurse's registered shift hours, and only from a device located within the hospital building, as determined by the device's network connection. If the nurse is at home, the device is not on the hospital network, and access is denied, regardless of her role. If the patient is transferred to a different ward, the nurse's ward attribute no longer matches the patient's ward attribute, and access is automatically revoked without anyone having to update a role assignment. The system adjusts itself in response to real-world changes. This is something neither MAC nor RBAC can do. The disadvantages of ABAC are real and they deserve honest discussion. The first is complexity. Writing ABAC policies requires careful thought and considerable expertise. A poorly written policy can have unintended consequences that are genuinely hard to trace. If a policy denies access that should be permitted, the security team needs to review potentially many attributes and many policy clauses to find the source of the problem. This is a much harder debugging task than reviewing a role assignment. The second disadvantage is performance. Every time a user requests access, the PDP must potentially query multiple PIPs, gather many attributes, and evaluate complex logical rules, all in a fraction of a second so that the user does not notice any delay. Designing an ABAC system that works this fast at large scale is a significant engineering challenge. The third disadvantage is the upfront investment. Before you can write a single policy, you need to identify every attribute that matters, build systems to store and provide those attributes reliably, and design a coherent policy framework. This is not a weekend project. Because each model has genuine strengths and genuine weaknesses, most real-world security architectures today do not choose one model exclusively. The emerging best practice is to use the models together, each doing what it does best. A common pattern is to use MAC at the operating system level to establish hard boundaries that cannot be crossed regardless of anything else, then use RBAC to handle the broad everyday question of what a user's job function allows them to do, and then use ABAC to handle the fine-grained contextual decisions within those boundaries. The nurse might have the Nurse role in RBAC, giving her broad access to medical records in general. But then ABAC policies narrow that access down to her specific patients, her shift hours, and her approved devices. And MAC ensures that even if somehow both RBAC and ABAC fail, the underlying operating system's rules prevent truly catastrophic damage. There is lively debate in the security community about where all this is heading. Some experts argue that RBAC is becoming obsolete, that the connected, cloud-native, constantly shifting world of modern technology makes its static, job-function-based approach inadequate. Others point out that for the vast majority of organisations, RBAC works perfectly well and the complexity of full ABAC implementation is a genuine barrier that creates its own security risks through misconfiguration. The honest answer is probably that neither model will dominate completely, and that the skill of a good security architect lies not in picking one model and applying it everywhere, but in understanding what each model is good at and combining them intelligently. On the horizon, researchers are exploring the use of machine learning to help manage access control. The idea is that a system could learn the normal pattern of access for each user, notice when behaviour deviates from that pattern, and either flag the anomaly for review or automatically adjust permissions in response to risk. Imagine a system that notices that a user who normally accesses payroll files between nine and five from a London office is suddenly accessing them at two in the morning from a different country, and automatically requires additional verification before allowing the access. This kind of risk-based, adaptive access control is still an area of active research. The challenge is ensuring that such a system is reliable, transparent, and explainable, that security teams can understand why the system made a particular decision, and that the system does not create barriers for legitimate users who simply have unusual circumstances. To tie all of this together and make the comparison clear, return once more to the hotel. MAC is like a system of physical locks where the locksmith, not the hotel manager or the guests, decides which key opens which door, and those decisions are recorded in a central registry that nobody else can change. The rules are absolute. The confidential safe can only be opened by someone with the right combination, and there is no override. RBAC is like a key card system where every employee's card is programmed based on their job title. The housekeeping card opens every linen closet on every floor, the front desk card opens the main office, and the general manager's card opens everything. When a housekeeper is promoted to front desk supervisor, the IT team reprograms her card to reflect her new title. ABAC is like a sophisticated smart access system that does not just look at your card but also checks the time, your current location in the building, whether you are on duty according to the schedule, whether the security system has raised an alarm, and whether the specific room you are trying to enter has been flagged as sensitive. It makes a fresh decision every time, based on all the information available in that moment. Each of these approaches to guarding the hotel is genuinely useful. Each has its place. The art, as in so much of security, lies in knowing which tool to use for which problem, and in understanding clearly why you are making that choice. Let us briefly draw together the key ideas covered in this lesson. Access control is the mechanism that determines who is allowed to see and use resources in a computing system. It is fundamental to security because without it, sensitive data is exposed to anyone with access to the network. Mandatory Access Control is the strictest model, enforced by the operating system itself, using security labels on resources and clearances assigned to users. It is based on two famous models, Bell-LaPadula, which protects confidentiality through rules of no read up and no write down, and Biba, which protects integrity through rules of no read down and no write up. SELinux is a real-world MAC implementation that significantly limits the damage an attacker can do even after compromising a process. MAC is highly secure but rigid and expensive to administer, making it best suited to military and critical infrastructure environments. Role-Based Access Control simplifies administration by assigning permissions to roles rather than individuals. Users inherit permissions by being assigned to roles that reflect their job functions. It is the most widely used model in enterprise environments because it is scalable and easy to audit, but it struggles with role explosion and cannot make contextual decisions based on real-time information. Attribute-Based Access Control is the most dynamic and flexible model, making access decisions by evaluating policies against attributes of the user, the resource, and the environment simultaneously. It is powerful enough to change access decisions in real time as circumstances change, but it is complex to design, can be slow if not engineered carefully, and requires significant upfront investment. In practice, the most effective security architectures combine all three models, using each one for the task it handles best.