Principals and Privilege

## Principal and privilege, defined A **principal** is the identity that a running piece of software or a human actor presents when it acts: a service account, a machine identity, a database login, an operating-system user, a scheduled-job account, a signed-in person. A **privilege** is what that principal is actually permitted to do. A **data-flow diagram** (DFD) - the processes, data stores, data flows and external entities that describe how data moves through a system - shows neither by default. A plain DFD says a nightly job reads a source table and writes the ledger. It does not say the job holds administrator rights on the ledger database and could rewrite any row in it. That missing half is what the annotation supplies, and it is the reason this step exists as its own discipline rather than as a footnote on the drawing. ## Write the granted privilege, not the intended role The annotation has two halves and both carry weight. The identity half names the account concretely - `etl_runner`, `console-svc`, `meter-ops` - because a label like *the application* covers a dozen components that may be one account or twelve, and you cannot tell which without asking. The privilege half records what that account can actually do today. Granted privilege routinely exceeds designed need: a job that must append to two tables is very often running under a login that can write all of them, drop them, or read every other schema on the instance. If nobody in the room can say what the account holds, that uncertainty is itself the first finding of the session, and it is worth stopping to resolve. ## What to write on each element type Process runtime identity + the privilege it effectively holds Data store which principals read it, which write it, at what privilege Data flow the identity presented on the wire for this call External entity the human or system role, and whether it is authenticated at all The data-flow line matters more than people expect: the identity a process presents on an outbound call is frequently not the identity of whoever caused the call, and a diagram that only annotates boxes will never show that. ## Worked example A nightly ETL job pulls transactions from an operational database and writes summarised rows into the production ledger. Unannotated, it is a box between two cylinders and looks like plumbing. Annotated, the box reads `etl_runner`, and the store it writes reads *ledger - `etl_runner` has write on all tables, `reporting_ro` has read*. Two things immediately change. First, the flow into the ledger crosses a privilege change, so a trust boundary belongs there. Second, the population of adversaries widens beyond the obvious: whoever controls the job's runtime controls a ledger-writing identity, which puts a compromised transitive dependency baked into the job's image, and the analyst with commit rights to the job's SQL, on the same footing as an intruder. The assets at stake are money and the truthfulness of the financial record, not merely a data leak. ## Why boundary placement depends on it A trust boundary belongs where trust or privilege changes. You cannot honestly place one without the labels, because the thing you are looking for *is* a difference between two labels. With annotations present, placement becomes close to mechanical: wherever adjacent elements carry different principals, or the same principal at materially different privilege, something crosses a boundary. Without them, teams fall back on drawing boundaries around network segments, which answers a different question entirely. ## What it does to enumeration and priority Per-element threat enumeration reads differently once each element is labelled: a threat against a process is evaluated in light of everything that process's principal can reach, which is the difference between *someone corrupts a report* and *someone rewrites the ledger*. The annotations also give you an ordering for limited review time - start with the elements whose principal holds the widest privilege over the most valuable asset, because any threat that lands there inherits all of it. ## Common annotation mistakes - Naming the owning team or the engineer instead of the runtime identity. - Recording the role the design document assigns rather than the grant that exists. - Collapsing many components into one label such as *the service* without checking. - Treating *runs as an administrator* as deployment trivia outside the model. - Skipping scheduled jobs and batch processes because no human is present, which is exactly where the widest standing privilege tends to live. ## Keeping the labels honest Annotations rot faster than the diagram does, because grants change without the architecture changing. Treat each principal label as a claim to re-verify when the model is refreshed, and note when it was last checked. A model whose principals were accurate a year ago places its boundaries where they used to be.