Access Control Enforcement¶

Access-control protocol — instantiates Data Integrity Preservation

Restricts who or what may read, write, approve, delete, or restore protected data, so records change only through authorized paths and never through hidden side doors.

Access Control Enforcement protects integrity at the entrance to change. It defines and enforces which identities — people, services, jobs — are permitted to create, update, approve, delete, migrate, or restore a given class of record, and it blocks every other route. Its distinguishing contribution is guarding the mutation path itself: it does not ask whether a proposed change is correct (a valid value can still be entered by the wrong hand, and a wrong value by the right one), only whether it is authorized and arrives through a sanctioned, reviewable path rather than a hidden side door. By closing off unofficial write routes, it makes the far weaker assumption the rest of the machinery relies on — that every change to protected data at least passed through a door someone was allowed to open.

Example¶

A credit union runs its member balances and journal postings in a core banking system. Tellers can post routine deposits and withdrawals; only a branch manager can reverse a posted transaction; only a two-person maker-checker pair can adjust a suspense account; and no one — not even an administrator — can write to the general ledger directly through the database, only through the application's controlled posting path. When a teller attempts a reversal, the system refuses and routes it to a manager; when a well-meaning engineer tries to fix a balance with a direct SQL update, the write is rejected because that path does not exist for ledger tables. The effect is that every change to a balance arrives through a defined, attributable door, and the "quiet database patch" that silently corrupts a ledger simply has nowhere to happen.

How it works¶

The mechanism binds operations on protected data to authorizations, then enforces the binding at every write path. Distinctively, it works by elimination: it does not improve any individual change, it removes whole categories of unauthorized or ungoverned change — direct database edits, shared privileged accounts, deletion by roles that should only read. It typically layers roles or attributes (who), operation rights (read / write / approve / delete / restore), and scope (which records), and it pairs naturally with segregation rules so that no single actor can both make and unilaterally bless a sensitive change. Higher-sensitivity data classes are placed behind stricter paths than low-stakes data, so protection is proportioned rather than uniform.

Tuning parameters¶

Granularity of rights — coarse role buckets versus fine per-field, per-operation permissions. Fine control prevents over-broad access but multiplies rules to maintain and can strangle legitimate work.
Separation of duties — how strictly make and approve (or write and delete) are forced onto different actors for sensitive changes. Stricter separation resists insider error and fraud but needs enough staff to staff both sides.
Protection tiering — how sharply the sensitive data classes are walled off from the routine ones; a steep tier concentrates scrutiny where corruption would cost most.
Break-glass allowance — whether, and how loudly, an emergency override exists. A logged, alarmed override preserves recoverability without leaving a silent bypass.

When it helps, and when it misleads¶

Its strength is that it removes the easiest ways for data to be corrupted or destroyed — unauthorized writes, casual deletes, back-channel edits — and forces change onto paths that can be reviewed and recorded. It is a precondition for trusting any other integrity claim: an audit trail means little if anyone can also edit records outside it. But its guarantee is narrow and often over-read. Access control proves a change was permitted, not that it was right; it cannot catch an authorized user entering a wrong value, and least privilege plus separation of duties^[1] guard against abuse of the path, not error within it. The classic misuse is treating "locked down" as "correct" and skipping validation and reconciliation because access is controlled. The discipline that guards against this is to pair enforcement with content checks and monitoring, and to keep even privileged and emergency access visible and logged.

How it implements the components¶

authorized_mutation_path — its core output: the enforced set of legitimate routes for creating, updating, deleting, migrating, and restoring records, with every other route blocked.
integrity_scope_tier — it proportions protection, placing higher-stakes data classes behind stricter paths and separation than low-stakes data.

It does not check whether a permitted change is valid (that is Data Validation Schema), record what each change was (that is Audit Log), or detect corruption that slips through an authorized path anyway (that is Integrity Anomaly Monitoring).

Instantiates: Data Integrity Preservation — it protects the change path so records mutate only through governed, reviewable routes.
Sibling mechanisms: Audit Log · Transactional Write Control · Data Validation Schema · Integrity Anomaly Monitoring · Reconciliation Workflow · Referential Integrity Constraint · Checksum or Hash Validation · Data Lineage Capture · Backup and Restore Verification · Source-of-Truth Registry

Notes¶

Access control and Audit Log are the two halves of a governed change: one decides whether a mutation may happen, the other records that it did. Enforced without logging, an authorized change is invisible after the fact; logged without enforcement, an unauthorized change is merely well-documented. Integrity wants both.

References¶

[1] Least privilege (grant each actor only the rights its task requires) and separation of duties (split make-and-approve across different actors) are the standard controls behind an authorized mutation path. Both limit the abuse of a change path; neither validates the content of a change made within it — that is a job for validation and reconciliation. ↩