CYBER-01-004-P · Primer — Least Privilege

The idea in one sentence

Least privilege means every identity — user, service, or process — gets only the access it needs to do its job, and only for as long as it needs it.

Why it exists

Think of a house with many doors. If you give every visitor a master key, any one of them can wander into every room, and a burglar who steals that key instantly gains access to the entire house. By handing out a single‑purpose key that opens only the kitchen when a guest is eating, you limit what a thief can do if the key is copied. In the same way, every permission you hand out is a permission an attacker inherits the moment they take over that account. If a leaked key can read one bucket, the blast radius is one bucket; if it can do anything, the blast radius is everything. Least privilege is the difference between a break‑in and a total compromise — it shrinks what a single stolen credential is worth. NIST SP 800-53 makes it control AC-6 for exactly this reason.

How it works

Two moves. First, scope: start from zero access and grant only the specific actions on the specific resources a job requires — deny by default, allow by exception. Second, expire: privileges are time‑bound, so access that was needed for a task goes away when the task is done, rather than accumulating forever. Worked example: A nightly data‑export job runs at 02:00 UTC. Instead of giving the service account s3:* on all buckets, you create a policy that allows s3:GetObject only on arn:aws:s3:::exports-2024-07/* and set a session duration of 2 hours. The job starts, receives a temporary token, copies 3 GB of files, and the token expires at 04:00 UTC. If the account were compromised at 03:00, the attacker could read only the export bucket and only until 04:00, not the rest of your storage. Together these steps keep each identity's power matched to its actual need, not its imagined future need.

See it — A flowchart showing how scope and expiration enforce least privilege.

flowchart LR
A["Zero Access"] --> B["Grant specific actions"]
B --> C["Time-bound revocation"]
C --> E["Matched Access"]
D["Least Privilege"] --> B
D --> C

The one gotcha

The classic failure is the god‑mode service account nobody ever scoped down. Granting a wildcard "allow everything" role on day one feels harmless because it just works — no permission errors, no tickets. So it ships, it's forgotten, and it quietly becomes the single credential that owns the whole system. The hidden danger is that the account’s broad rights are invisible in daily operations; they only surface when an incident occurs, turning a convenience into a catastrophic single point of failure. Least privilege isn't a switch you flip once; it's the boring, ongoing work of removing access that identities stopped needing.

The one-line takeaway

Grant only what's needed, only while it's needed.

Where you'll meet it

AWS IAM policies (Action/Resource, and the tempting *), Kubernetes RBAC Role vs ClusterRole, database GRANT statements, OAuth scopes on a token, and Unix file modes. The war‑story version is Drill 47; the control that operationalizes it — scoping, review, and just‑in‑time access — is Pattern 28.

Named concepts: least privilege, principle of least authority