Access-Control Theories, Models and Policy Design

Introduction

Access control is the systematic determination and enforcement of who or what may perform which operation on which resource, under specified conditions. In data science environments, access control protects datasets, analytical platforms, model artifacts, notebooks, APIs, feature stores, and administrative functions. It also supports data governance obligations such as confidentiality, integrity, purpose limitation, separation of duties, and accountability.

An access-control decision can be represented conceptually as:

Here, a subject is an active entity such as a user, service, process, or device; an object is a protected resource; an action is an operation such as read, write, delete, or execute; context includes attributes such as time, location, device assurance, or transaction state; and policy contains the rules governing access. The function produces a decision such as permit, deny, or permit with obligations.

No single model is optimal for every organization. Discretionary models provide flexibility, mandatory models provide centrally enforced classification controls, role-based models simplify administration, attribute-based models express rich context, and relationship-based models represent social, organizational, or graph relationships. Sound policy design therefore begins with a clear security objective and selects or combines models deliberately.

Learning Objectives

By the end of this chapter, students should be able to:

• distinguish DAC, MAC, RBAC, ABAC, rule-based, and relationship-based access control;
• apply least privilege, need-to-know, separation of duties, and fail-safe defaults;
• explain and compare Bell–LaPadula, Biba, Clark–Wilson, and Brewer–Nash models;
• design policies using subjects, objects, actions, attributes, obligations, and constraints;
• identify and resolve policy conflicts;
• evaluate access-control designs in data platforms and machine-learning environments.

1. Access-Control Foundations

1.1 Authentication, authorization, and accountability

Authentication establishes identity or provenance. Authorization determines whether an authenticated or otherwise identified subject may perform an action. Accounting records relevant events so that actions can be traced, investigated, and audited. Confusing these functions creates weaknesses: a strong login mechanism does not imply appropriate authorization, and an authorization decision without reliable logging may be impossible to review.

A complete authorization policy normally specifies:

An access matrix is a useful abstract representation. Rows represent subjects and columns represent objects; each cell contains permitted operations. In practice, large systems do not usually store a complete matrix because it is expensive to maintain. Models such as RBAC and ABAC provide more scalable ways to generate decisions.

1.2 Core security principles

Least privilege grants only the permissions required for an authorized task, for only as long as necessary. It applies to people, applications, cloud roles, database accounts, and automated agents. Least privilege reduces the damage caused by error, compromise, or misuse.

Need-to-know is narrower than general organizational membership. A person may be cleared or employed by an organization but still have no business need to view a particular dataset. Need-to-know is especially important for personal, confidential, or commercially sensitive information.

Separation of duties distributes a sensitive process among multiple people or roles. For example, one employee may create a supplier record while another approves payment. It reduces the risk that one compromised or dishonest actor can complete an entire fraudulent operation.

Fail-safe default means that access is denied unless a valid policy explicitly permits it. This principle must be implemented carefully: default denial should not prevent emergency access, safety functions, or legally required operations without an appropriate break-glass process.

Complete mediation requires every relevant access attempt to be checked. Caching or trusting a previous decision can undermine this principle unless cache lifetime, revocation, and policy changes are controlled.

Open design assumes that security should not depend on secrecy of the access-control mechanism. Policies and cryptographic secrets must be protected, but the general design should withstand public scrutiny.

2. Major Access-Control Models

2.1 Discretionary Access Control (DAC)

Under DAC, the owner of an object, or a delegated authority, can determine who may access it. Traditional file permissions and access-control lists are common examples. A data scientist who owns a project folder may grant another colleague read access.

DAC is flexible and convenient, particularly in collaborative environments. However, permissions can spread through uncontrolled sharing, copying, group membership, or delegation. A user who has read access may also be able to pass that access to another user. DAC therefore requires careful ownership rules, review, and revocation.

DAC is appropriate when data owners understand the information and collaboration requirements. It is less suitable as the sole control for highly regulated data, where organizational policy must override individual discretion.

2.2 Mandatory Access Control (MAC)

MAC assigns security labels to subjects and objects. A central policy determines whether a subject’s clearance and the object’s classification allow an operation. Users cannot ordinarily change labels or pass permissions to others.

A simple confidentiality hierarchy may be:

Public < Internal < Confidential < Restricted

MAC is valuable where information classification and organizational authority are more important than individual ownership, including government, defense, healthcare, and regulated research. Its disadvantages include classification effort, administrative rigidity, and the difficulty of representing nuanced business relationships.

MAC should not be confused with encryption. Encryption protects data against unauthorized reading without keys; MAC governs authorized interaction with labeled resources. They are complementary controls.

2.3 Role-Based Access Control (RBAC)

RBAC assigns permissions to roles and assigns users or services to roles. A basic RBAC system contains:

• users or subjects;
• roles;
• permissions, each representing an operation on an object;
• user-role assignments;
• permission-role assignments;
• optional constraints.

For example, the role Model Reviewer might permit reading model metadata and approving a validation report, but not changing training data or deploying a model. RBAC reduces direct user-permission administration and aligns access with job functions.

Important RBAC extensions include:

• role hierarchies, in which senior roles inherit permissions from junior roles;
• static separation of duties, which prevents conflicting roles from being assigned together;
• dynamic separation of duties, which prevents conflicting roles from being activated in the same session;
• cardinality constraints, which limit how many users may occupy a role;
• temporal constraints, which restrict role activation by time or circumstance.

RBAC can become difficult to manage when roles are created for every combination of department, project, location, and data sensitivity. This is known as role explosion. Attributes can often express such dimensions more economically.

2.4 Attribute-Based Access Control (ABAC)

ABAC evaluates attributes of the subject, object, action, and environment. A policy might state:

Permit a researcher to read de-identified clinical data when the researcher is assigned to the approved study, the device is managed, the request occurs within the study period, and the purpose is research.

Typical attributes include:

ABAC is expressive and supports fine-grained, context-aware decisions. It is useful in cloud, zero-trust, data-sharing, and API environments. Its risks include attribute quality, policy complexity, inconsistent attribute sources, and difficulty explaining decisions to users. Attributes must be authoritative, current, protected from tampering, and governed through ownership and lifecycle processes.

2.5 Rule-based access control

Rule-based control uses explicit conditions, often written as if–then rules. Rules may be applied to any of the models above. Examples include:

• deny exports containing direct identifiers;
• permit administrative access only through a managed jump host;
• block access after a high-confidence compromise signal;
• require a second approval for production deployment.

Rule-based control is particularly useful for global constraints and environmental conditions. It can, however, become opaque when many rules interact. A well-designed rule system defines precedence, conflict handling, testing, versioning, and audit explanations.

2.6 Relationship-Based Access Control (ReBAC)

ReBAC makes access depend on relationships in a graph. A policy might permit a user to edit a dataset if the user is an analyst on the project that owns the dataset, or permit a clinician to view a record if the clinician has an active care relationship with the patient.

The model is natural for multi-tenant systems, social platforms, collaborative research, organizational hierarchies, and delegated administration. It can represent relationships such as member-of, reports-to, owns, assigned-to, and shares-project-with.

ReBAC requires trustworthy relationship data and careful handling of relationship changes. A relationship graph may also reveal sensitive organizational information. Relationship depth must be bounded or evaluated efficiently to avoid unpredictable decisions.

2.7 Comparative evaluation

Hybrid systems are common. For example, RBAC can establish a baseline, ABAC can restrict access by data sensitivity and device state, and rule-based controls can impose a universal export prohibition.

3. Formal Security Models

Formal models provide precise security properties. They do not automatically produce complete real-world policies; rather, they clarify what a system is designed to protect.

3.1 Bell–LaPadula model

Bell–LaPadula is primarily a confidentiality model. Its two famous properties are:

• Simple security property (“no read up”): a subject may not read an object at a higher security level.
• Star property (“no write down”): a subject may not write information to a lower security level.

If security levels are ordered from low to high, a subject at level L may read an object at level O only when L dominates O. The model helps prevent information from flowing from a highly classified level to a less classified level.

Bell–LaPadula does not primarily address integrity, availability, usability, or whether a user has a legitimate business purpose. A subject cleared for a level may still lack need-to-know. Thus, classification controls should be combined with discretionary, role, or attribute policies.

3.2 Biba model

Biba addresses integrity rather than confidentiality. Its classic properties are:

• No read down: a subject should not read data at a lower integrity level, because untrusted input could contaminate a trusted process.
• No write up: a subject should not write to a higher integrity level, because untrusted data could corrupt trusted data.

Integrity levels are not the same as confidentiality levels. A public source may be confidentially harmless but have low integrity. Conversely, a highly confidential dataset may have uncertain integrity if its provenance is poor.

Biba is useful for protecting authoritative datasets, production configurations, and validated model artifacts. Practical systems often supplement it with provenance, validation, checksums, approval workflows, and monitoring.

3.3 Clark–Wilson model

Clark–Wilson focuses on commercial integrity through well-formed transactions and separation of duties. Its central concepts include:

• Constrained Data Items (CDIs): data that must maintain integrity;
• Unconstrained Data Items (UDIs): data not yet validated or controlled;
• Transformation Procedures (TPs): approved operations that manipulate CDIs;
• Integrity Verification Procedures (IVPs): procedures that verify system state and enforce integrity constraints.

Users should not directly modify CDIs. They invoke authorized TPs, and IVPs verify that the system remains in a valid state. For example, a payment amount should be changed through an approved transaction rather than by direct database editing. In a model-governance platform, a production model could be a CDI, while promotion from staging to production occurs through an approved deployment procedure requiring independent review.

Clark–Wilson is especially relevant to databases, financial systems, scientific pipelines, and model operations because it connects technical permissions with business processes.

3.4 Brewer–Nash model

The Brewer–Nash, or Chinese Wall, model addresses conflicts of interest. Access to one company’s sensitive information may change whether access to a competing company’s information is permitted. The policy is dynamic: a subject’s previous access history influences future decisions.

For example, a consultant who has accessed confidential information from Company A may be prevented from accessing confidential information from Company B in the same conflict-of-interest class. Public information or information outside the relevant class may remain accessible.

The model protects against inappropriate cross-client information flow, but it can reduce flexibility and complicate access reviews. Organizations must define conflict classes, track history reliably, and provide legitimate procedures for reassignment or exceptional access.

3.5 Model selection

The models address different properties:

A production system may use all four ideas in different layers. For example, a healthcare analytics platform may use confidentiality labels, data-quality controls, approved transformation procedures, and conflict-of-interest restrictions for external consultants.

4. Policy Design and Conflict Resolution

4.1 From requirements to enforceable policy

Policy design should begin with assets, actors, operations, risks, and obligations rather than with a product’s configuration screen. A practical workflow is:

1. identify data owners, custodians, users, services, and external parties;
2. classify objects by sensitivity, integrity, retention, and regulatory status;
3. list business actions and distinguish read, create, modify, approve, export, and delete;
4. identify legitimate purposes and need-to-know conditions;
5. choose a baseline model such as RBAC, MAC, ABAC, or a hybrid;
6. define exceptional, emergency, and delegated-access procedures;
7. define deny behavior, obligations, logging, review, and revocation;
8. test normal, boundary, adversarial, and failure cases;
9. monitor decisions and revise policy as systems and risks change.

Policies should be expressed at the right level of abstraction. “Analysts can access data” is inadequate. A useful statement identifies which analysts, which data, which operation, under which purpose, for what duration, and with what restrictions.

4.2 Policy combination and conflicts

Conflicts occur when one policy permits an action and another denies it, or when obligations cannot all be satisfied. Common combination strategies include:

• deny-overrides: any applicable deny produces a deny;
• permit-overrides: any applicable permit produces a permit;
• first-applicable: policies are evaluated in a defined order;
• only-one-applicable: a decision is valid only when exactly one policy applies;
• consensus or quorum: multiple approvals are required;
• obligation-aware combination: a permit is valid only if required obligations can be fulfilled.

For security-sensitive systems, deny-overrides is often the safest default, especially for confidentiality, export, deletion, and regulatory constraints. However, combining policies mechanically is not enough. Policy authors must identify semantic conflicts, such as a permit to export a dataset and an obligation to remove identifiers when the masking service is unavailable.

A mature policy engine should provide:

• deterministic precedence;
• policy versioning and effective dates;
• explanation of the decision path;
• conflict and unreachable-rule detection;
• simulation before deployment;
• emergency override with approval and auditing;
• rollback and change-management controls.

4.3 Least privilege in practice

Least privilege is not achieved merely by creating many roles. It requires identifying the minimum action set and limiting scope. Useful techniques include just-in-time elevation, time-bound permissions, project-scoped roles, read-only defaults, separate service identities, privileged-access workstations, and periodic recertification.

A permission review should ask:

• Is the permission still required?
• Is it broader than the task?
• Is it inherited from an obsolete role?
• Can the operation be replaced with a safer approved procedure?
• Is access being used, and is the use legitimate?
• What is the consequence if the identity is compromised?

Service accounts deserve particular attention. Long-lived credentials, shared accounts, unrestricted database administrators, and pipelines running with owner privileges are frequent violations of least privilege.

5. Applied Case: University Clinical-Data Research Platform

The following is an illustrative case.

Background

A university hosts clinical datasets for approved research projects. Data include identifiable patient records, de-identified extracts, laboratory results, and model artifacts. Researchers belong to multiple projects, external collaborators require limited access, and a data-protection office must demonstrate that access is purposeful and auditable.

Problem

The initial system uses shared folders and DAC. Researchers can copy files into personal workspaces, project membership is not synchronized reliably, and an analyst who changes projects may retain access to the previous project. Direct identifiers are available to too many users. The institution also needs to prevent one external consultant from viewing confidential information belonging to competing sponsors.

Analysis

DAC provides useful collaboration but does not adequately enforce central classification or prevent permission accumulation. A single RBAC role such as Researcher is too broad. The platform needs:

• confidentiality and need-to-know controls;
• project and purpose restrictions;
• device and time conditions;
• approved data transformations;
• conflict-of-interest enforcement;
• independent approval for production model deployment;
• complete audit records.

Approach and solution

The institution adopts a hybrid design:

1. MAC-like labels classify data as public, internal, confidential, or restricted. Restricted identifiable data require stronger controls.
2. RBAC provides roles such as Principal Investigator, Data Steward, Research Analyst, Privacy Officer, Model Reviewer, and Platform Administrator.
3. ABAC checks project assignment, approved purpose, training status, device posture, location, study dates, and data sensitivity.
4. Rule-based restrictions deny bulk export of direct identifiers and require masking obligations for approved extracts.
5. Clark–Wilson controls require approved transformation procedures to create de-identified datasets and require independent review before model promotion.
6. Brewer–Nash restrictions block an external consultant from accessing confidential datasets of competing sponsors after the consultant has accessed one sponsor’s confidential data.
7. ReBAC represents researcher–project, project–dataset, and reviewer–model relationships.
8. Just-in-time access limits privileged administrative access to an approved time window.

A representative decision is: permit a researcher to read a de-identified dataset only if the researcher is an active member of the owning project, has completed required training, is using a managed device, the request purpose matches the approved study, and the dataset has not expired. Export is a separate action and is denied by default unless a steward approves it and masking succeeds.

Outcome

The design reduces broad standing privileges, makes project changes effective through relationship updates, and creates an auditable distinction between reading, transforming, exporting, and deploying. It also makes policy decisions explainable: a denied request can identify the failed condition, such as “project membership expired” or “device not managed.”

Learning points

The case illustrates that no one model solves every requirement. Classification addresses information flow; roles simplify administration; attributes express context; relationships represent collaboration; transaction controls protect integrity; and history-sensitive rules address conflicts of interest. Effective governance depends on authoritative identity, project, training, classification, and device data.

6. Challenges, Ethics, and Contemporary Practice

Access control can produce unfair or harmful outcomes when attributes are inaccurate, proxies for protected characteristics, or applied without due process. Automated systems should not silently deny access to essential services based on an opaque risk score. Organizations should provide explainability appropriate to the risk, appeal routes, human review for consequential decisions, and evidence that policies are not discriminatory.

Privacy also requires restraint. Collecting location, behavior, or device telemetry to support ABAC creates additional personal-data responsibilities. Contextual attributes should be minimized, retained only as necessary, protected against manipulation, and governed by a legitimate purpose.

AI systems introduce new access-control concerns. A model may infer sensitive information from apparently harmless inputs; retrieval-augmented systems may expose documents through prompts; and autonomous agents may combine permissions in unexpected ways. Agent identities should be distinct, tool permissions should be narrowly scoped, data retrieval should be authorized at request time, and prompts or outputs should not be treated as a substitute for policy enforcement.

Contemporary best practice increasingly combines zero-trust principles, policy-as-code, continuous evaluation, workload identity, data-centric controls, and automated access reviews. Nevertheless, automation does not remove the need for accountable owners. Policy code must be tested like software, and changes should pass peer review, security testing, and controlled deployment.

Chapter Summary

Access control determines whether a subject may perform an action on an object under defined conditions. DAC emphasizes ownership and flexibility; MAC emphasizes centrally controlled labels; RBAC emphasizes job functions; ABAC evaluates subject, object, action, and environmental attributes; rule-based control expresses explicit constraints; and ReBAC evaluates graph relationships. Hybrid designs are often most practical.

Least privilege, need-to-know, separation of duties, complete mediation, and fail-safe defaults are foundational principles. Bell–LaPadula protects confidentiality, Biba protects integrity through information-flow restrictions, Clark–Wilson protects commercial integrity through approved procedures and verification, and Brewer–Nash limits conflicts of interest using access history. Policy design must define precedence, obligations, explanations, auditing, revocation, and emergency procedures. In data-science environments, access control must cover datasets, pipelines, models, APIs, notebooks, services, and human decisions while respecting privacy, fairness, and accountability.

Key Terms

Access control: The process of granting or denying operations on protected resources.

Authentication: Establishing the identity or provenance of a subject.

Authorization: Determining whether an action is permitted.

Discretionary Access Control (DAC): Control in which owners can grant access to their objects.

Mandatory Access Control (MAC): Centrally enforced access based on labels and clearances.

Role-Based Access Control (RBAC): Control based on permissions assigned to organizational roles.

Attribute-Based Access Control (ABAC): Control based on attributes of subjects, objects, actions, and context.

Rule-based control: Control implemented through explicit conditional rules.

Relationship-Based Access Control (ReBAC): Control based on relationships represented in a graph.

Least privilege: Granting only the permissions necessary for an authorized task.

Need-to-know: Restricting access to information required for a legitimate purpose.

Separation of duties: Dividing sensitive responsibilities among multiple actors.

Bell–LaPadula: A confidentiality model characterized by no read up and no write down.

Biba: An integrity model characterized by no read down and no write up.

Clark–Wilson: An integrity model based on constrained data, approved procedures, and verification.

Brewer–Nash: A conflict-of-interest model using access history.

Policy obligation: An action that must accompany an authorization decision.

Fail-safe default: Denying access unless a valid policy permits it.

Policy conflict: A situation in which applicable rules produce incompatible decisions or obligations.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization.
2. What is the difference between least privilege and need-to-know?
3. Identify two advantages and two limitations of RBAC.
4. State the principal confidentiality properties of Bell–LaPadula.
5. What problem does Brewer–Nash address?

Long Answer Questions

1. Compare DAC, MAC, RBAC, ABAC, rule-based, and relationship-based access control in terms of administration, flexibility, and risk.
2. Explain how Clark–Wilson protects integrity in a data-processing or model-deployment workflow.
3. Discuss why a hybrid access-control architecture may be preferable to a single model.
4. Explain policy conflict-resolution strategies and argue when deny-overrides is appropriate.
5. Design an access-control policy for a multi-tenant analytics platform, including roles, attributes, obligations, and audit requirements.

Analytical / Application Questions

1. A researcher belongs to a project but uses an unmanaged laptop and requests an export containing direct identifiers. Analyze the request using least privilege, ABAC, and rule-based controls.
2. An external consultant has accessed confidential data from one of two competing companies. Apply Brewer–Nash reasoning to determine what future access should be restricted.
3. A production model can be edited directly by developers and deployed without independent review. Diagnose the integrity weaknesses and redesign the workflow using Clark–Wilson, separation of duties, and RBAC.

Multiple Choice Questions with Answers

Question 1

Which access-control model primarily bases decisions on job functions?

A. Discretionary Access Control

B. Mandatory Access Control

C. Role-Based Access Control

D. Relationship-Based Access Control

Correct Answer: C. Role-Based Access Control

Question 2

Which Bell–LaPadula property prevents a subject from writing information to a lower security level?

A. No read up

B. No write down

C. No read down

D. No write up

Correct Answer: B. No write down

Question 3

A policy permits access only when a user is assigned to a project, uses a managed device, and requests data for an approved purpose. Which model most directly expresses these conditions?

A. ABAC

B. DAC

C. Biba

D. Brewer–Nash

Correct Answer: A. ABAC

Question 4

What is the main purpose of separation of duties?

A. To maximize the number of permissions per user

B. To ensure all users share one account

C. To prevent one actor from completing a sensitive process alone

D. To eliminate the need for audit logs

Correct Answer: C. To prevent one actor from completing a sensitive process alone

Question 5

Which model uses approved transformation procedures and verification procedures to protect integrity?

A. Bell–LaPadula

B. Clark–Wilson

C. Brewer–Nash

D. DAC

Correct Answer: B. Clark–Wilson

Question 6

What does need-to-know require?

A. Every employee receives access after authentication

B. Access is limited to information required for a legitimate purpose

C. Users may delegate all permissions freely

D. Only administrators may read data

Correct Answer: B. Access is limited to information required for a legitimate purpose

Question 7

Which policy-combination strategy normally denies a request when any applicable policy produces a deny?

A. Permit-overrides

B. First-applicable

C. Deny-overrides

D. Only-one-applicable

Correct Answer: C. Deny-overrides

Question 8

Which model is designed to address conflicts of interest that depend on a subject’s previous access?

A. Biba

B. Brewer–Nash

C. Clark–Wilson

D. RBAC

Correct Answer: B. Brewer–Nash

Question 9

A user can read a low-integrity data source but cannot write to a high-integrity repository. Which Biba principle is being applied?

A. No read down

B. No write down

C. No read up

D. No write up

Correct Answer: D. No write up

Question 10

Which statement best describes least privilege?

A. Grant every permission initially and review later

B. Grant only the permissions necessary for the authorized task

C. Allow users to change security labels

D. Permit access whenever a user belongs to the organization

Correct Answer: B. Grant only the permissions necessary for the authorized task