---
{
  "title": "Access control",
  "summary": "Understand subjects, resources, permissions, and enforcement through a shared-drive example, including how access changes over time.",
  "topic": "foundations",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    4
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: An Introduction to Information Security",
      "url": "https://csrc.nist.gov/pubs/sp/800/12/r1/final"
    },
    {
      "title": "NIST: Access Control, SP 800-53 Rev. 5",
      "url": "https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## Policy, decision, and enforcement

Access control is the system of rules and mechanisms governing use of resources. A subject requests an action on an object: an analyst reads a report, a service updates a database, or a visitor opens a public page. Policy describes what should be allowed; enforcement makes that decision matter in the real system.

This broader view includes how permissions are granted, how requests are checked, and how access is removed when responsibilities change. [[authorization]] describes the decision for a particular request. [[authentication]] can supply evidence about the requesting identity, although some policies deliberately permit anonymous access.

## A shared drive with three responsibilities

Imagine a fictional research team stores draft reports on a shared drive. Contributors need to edit drafts. Reviewers need to comment on the assigned reports. External partners should receive only approved final versions.

The team initially creates one shared link with edit access because it is convenient. That link does not express the three responsibilities. Anyone possessing it may have more power than the task requires, and forwarding it can extend access beyond the intended group.

A revised design separates the working area from published copies, uses named memberships where appropriate, and defines who may invite new participants. The owner also decides how access ends when a partner's engagement finishes. The improvement is a clearer boundary and lifecycle, not merely a different folder color.

## Ownership affects how permissions work

In discretionary access control, an owner can typically grant access within the system's rules. Mandatory models use centrally imposed labels and rules that ordinary owners cannot freely override. Role-based and attribute-based designs express permissions through responsibilities or properties of a request. [[rbac-and-abac]] compares those approaches.

Real services often combine mechanisms. A shared drive may have group membership, per-file sharing, inherited permissions, and organization-wide restrictions. Understanding only the visible group list can miss an older direct grant or a separate public link.

## Review effective access

For the research drive, list the legitimate tasks first. Then examine the actual paths by which a subject can perform them. Include group inheritance, direct permissions, sharing links, service identities, and administrative access. Ask the owner to explain exceptions in terms of current work.

Try a small exercise with invented users: a contributor, a reviewer, and a former contractor. For each, state whether they can read a draft, edit it, share it externally, or delete it. Compare the intended answers with the permissions shown by a training service you control.

## Removal deserves as much attention as granting

An access request usually has an obvious benefit: someone can begin work. Removing access is easier to overlook because the benefit is less visible. Role changes, project closure, and departure should trigger review rather than leaving historical access in place indefinitely.

[[least-privilege]] provides a useful goal for those reviews. Keep enough access for legitimate work and a documented route for exceptional tasks. An access-control system works well when its policy is understandable, its enforcement is testable, and its permissions continue to reflect the work people actually perform.