Authorization and access control models

Authentication tells a system who is asking; authorization decides what that subject may do. Every operating system, database, application and cloud platform makes thousands of authorization decisions a second, and the model behind those decisions determines how manageable, auditable and secure access will be. This lesson covers the access control matrix and its two implementations, then the classic models the exam expects you to distinguish: discretionary, mandatory, role-based, rule-based, attribute-based and risk-based access control, along with content- and context-dependent controls. The formal security models that underpin mandatory access control, such as Bell-LaPadula, Biba, Clark-Wilson and Brewer-Nash, are covered in depth in CISSP-112; here we focus on how organizations choose and apply access control models.

The access control matrix

Conceptually, every authorization system can be described by an access control matrix: a table with a row for each subject, a column for each object and, in each cell, the rights that subject holds over that object. Real systems never store the full matrix, because it would be enormous and mostly empty. Instead they store it by column or by row. An access control list, ACL, stores a column: attached to each object is the list of subjects and their rights, as with file system permissions or a firewall rule base. A capability list stores a row: attached to each subject is the list of objects it may use and how, as with Kerberos tickets, OAuth tokens or a cloud role's policy. ACLs make it easy to answer who can access this object; capability lists make it easy to answer what this subject can access, and to revoke or delegate a subject's rights as a whole.

matrix = {
    'priya':   {'payroll.xlsx': 'r',  'budget.xlsx': 'rw', 'hr-db': ''},
    'marco':   {'payroll.xlsx': 'rw', 'budget.xlsx': 'r',  'hr-db': 'r'},
    'svc-etl': {'payroll.xlsx': '',   'budget.xlsx': '',   'hr-db': 'rw'},
}
print('ACLs (stored with each object):')
for obj in ['payroll.xlsx', 'budget.xlsx', 'hr-db']:
    acl = [f'{s}:{rights[obj]}' for s, rights in matrix.items() if rights[obj]]
    print(f'  {obj:13s} {acl}')
print('Capability lists (stored with each subject):')
for subj, rights in matrix.items():
    caps = [f'{o}:{r}' for o, r in rights.items() if r]
    print(f'  {subj:8s} {caps}')
cells = sum(len(r) for r in matrix.values())
filled = sum(1 for r in matrix.values() for v in r.values() if v)
print(f'Matrix cells: {cells}, non-empty: {filled}')
print(f'At 20,000 users and 2 million objects the full matrix would have {20_000 * 2_000_000:,} cells')

ACLs (stored with each object):
  payroll.xlsx  ['priya:r', 'marco:rw']
  budget.xlsx   ['priya:rw', 'marco:r']
  hr-db         ['marco:r', 'svc-etl:rw']
Capability lists (stored with each subject):
  priya    ['payroll.xlsx:r', 'budget.xlsx:rw']
  marco    ['payroll.xlsx:rw', 'budget.xlsx:r', 'hr-db:r']
  svc-etl  ['hr-db:rw']
Matrix cells: 9, non-empty: 6
At 20,000 users and 2 million objects the full matrix would have 40,000,000,000 cells

Discretionary access control

In discretionary access control, DAC, the owner of an object decides who may access it. The creator of a file is usually its owner and can grant read or write rights to colleagues, and those colleagues may in turn be able to pass the access on. File sharing in Windows, Unix permissions and most collaboration tools are discretionary. DAC is flexible and familiar, and it suits environments where users are trusted to manage their own information. Its weaknesses are that access spreads in ways the organization cannot see or control, that users make mistakes such as sharing a folder with everyone, and that malicious software running as a user inherits that user's ability to change permissions. Identity-based access control and user-directed access control are closely related terms.

Mandatory access control

In mandatory access control, MAC, the system enforces access based on security labels, and users cannot change the rules even for objects they create. Each subject has a clearance and each object has a classification, typically a hierarchical level such as Confidential, Secret or Top Secret plus non-hierarchical compartments or categories, such as a project name. A subject may read an object only if its clearance dominates the object's label: its level is at least as high and it holds every compartment on the object. The set of labels forms a lattice, which is why MAC is sometimes called lattice-based access control. MAC enforces need to know through compartments as well as clearance through levels.

LEVELS = {'Unclassified': 0, 'Confidential': 1, 'Secret': 2, 'Top Secret': 3}
def dominates(subject, obj):
    (slevel, scomp), (olevel, ocomp) = subject, obj
    return LEVELS[slevel] >= LEVELS[olevel] and set(ocomp) <= set(scomp)
analyst = ('Secret', {'ARCTIC', 'COASTAL'})
docs = {
    'patrol schedule':   ('Secret', {'ARCTIC'}),
    'port assessment':   ('Confidential', {'COASTAL'}),
    'satellite imagery': ('Top Secret', {'ARCTIC'}),
    'budget annex':      ('Secret', {'ARCTIC', 'FINANCE'}),
}
for name, label in docs.items():
    verdict = 'read permitted' if dominates(analyst, label) else 'denied'
    print(f'{name:18s} {label[0]:12s} {sorted(label[1])!s:22s} -> {verdict}')

patrol schedule    Secret       ['ARCTIC']             -> read permitted
port assessment    Confidential ['COASTAL']            -> read permitted
satellite imagery  Top Secret   ['ARCTIC']             -> denied
budget annex       Secret       ['ARCTIC', 'FINANCE']  -> denied

MAC is used where confidentiality is paramount and central control is required: military and intelligence systems, and operating systems with mandatory controls such as SELinux, which labels every process and file and enforces policy even against root. Its strengths are consistency and resistance to user error and malware; its weaknesses are rigidity, administrative cost and difficulty supporting collaboration. Bell-LaPadula formalizes MAC for confidentiality, with no read up and no write down; Biba formalizes it for integrity, with no read down and no write up. Remember that labels describe the information, not the container: a document's classification travels with it.

Role-based access control

Role-based access control, RBAC, assigns permissions to roles that reflect job functions, and assigns users to roles. Accounts payable clerk, nurse, help desk analyst and database administrator are typical roles. When a person joins, moves or leaves, administrators change role membership rather than individual permissions, which is far easier to manage and audit. The NIST model, standardized as ANSI INCITS 359, defines core RBAC, where users get permissions only through roles; hierarchical RBAC, where senior roles inherit the permissions of junior ones; and constrained RBAC, which adds separation of duties. Static separation of duties prevents a user from being assigned to two conflicting roles at all, such as payment requester and payment approver; dynamic separation of duties allows both role assignments but prevents the user from activating both in the same session or transaction.

RBAC's main difficulty is role design. Too few roles, and users get more access than they need; too many, and the model becomes as complex as individual permissions, a problem called role explosion. Organizations often start with role mining, analyzing existing permissions to find natural clusters, and then refine roles with business owners. A sensible rule is that roles should describe stable job functions, while temporary or exceptional needs are handled with time-limited grants or attributes.

Rule-based access control

Rule-based access control applies global rules to all subjects, regardless of who they are. A firewall that permits HTTPS from any address and denies everything else, a system that allows logins only between 07:00 and 19:00, or a mail gateway that blocks attachments of certain types are rule-based. The abbreviation RBAC is ambiguous, so the exam usually spells out role-based or rule-based; read carefully. Rule-based controls are simple and effective for uniform policies, but they cannot easily express exceptions for individuals without becoming long and fragile.

Attribute-based access control

Attribute-based access control, ABAC, described in NIST SP 800-162, makes decisions by evaluating policies over attributes of the subject, the object, the action and the environment. Subject attributes include department, clearance, role and training status; object attributes include classification, owner and data type; action attributes identify what is attempted; environment attributes include time, location, device health and current threat level. A policy might say that an employee may read a customer record if the employee's region equals the customer's region, the employee completed privacy training in the past year and the request comes from a managed device. ABAC is very expressive and handles context naturally, which is why it underpins zero trust and modern cloud authorization, but policies can become hard to understand and test, and the decision depends on accurate attributes.

Risk-based, content-dependent and context-dependent control

Risk-based or adaptive access control calculates a risk score for each request from signals such as device posture, location, network reputation, impossible travel, time of day and user behavior, and then allows the request, requires step-up authentication or denies it. Conditional access policies in cloud identity platforms are a common implementation. Its benefit is that low-risk requests flow smoothly while unusual ones get more scrutiny; its risk is that scoring models can be opaque or wrong, so decisions need logging and periodic review.

Content-dependent access control decides based on the data itself: a database view that shows a manager only the salaries of their own department, or a data loss prevention rule that blocks documents containing credit card numbers. Context-dependent access control decides based on the circumstances of the request or the sequence of actions, such as allowing a purchase approval only after a purchase order exists, or allowing access only from a particular terminal. Both are often implemented with ABAC policies today.

Implementing authorization well

Whatever the model, a few principles make authorization effective. Default deny means that anything not explicitly allowed is refused. Complete mediation means that every access is checked, not only the first; caching a decision for too long, or checking only on the login page, leaves gaps. Centralize policy where possible, but enforce it close to the resource, so that a compromised front end cannot bypass checks by calling the back end directly. Broken access control, where applications fail to enforce authorization on every request, has topped the OWASP Top 10 list of web application risks since 2021, typically through insecure direct object references such as changing an account number in a URL. Log authorization decisions, especially denials and privileged actions, and review them.

Thinking like a manager

Expect questions that describe a situation and ask which model fits, or which model is in use. Clues help: owner decides is DAC; labels and clearances are MAC; job functions are role-based; global conditions are rule-based; attributes and policies are ABAC; real-time scoring is risk-based. Expect also questions about separation of duties within RBAC and about broken access control in applications. The manager's answer combines a model that suits the data with least privilege, default deny, complete mediation and review.