Least privilege

The smallest useful permission

Least privilege means giving an identity the permissions necessary for a legitimate task, within an appropriate scope and duration. The identity might belong to a person, an application, a cloud workload, or a scheduled job. The principle reduces the damage that a mistake or compromised account can cause. It does not promise that the identity cannot be compromised.

Think in three dimensions: the action, the resource, and the time. A reporting job may need to read a sales table each morning. That requirement does not imply permission to delete the table, read employee medical records, or administer the database server. A role named “reader” is only useful if its actual permissions match the job.

A reporting service example

Imagine an academy generates a weekly enrollment report. The first implementation uses a database administrator credential because it makes development easy. The report works, but its credential can also modify unrelated tables. If the reporting service is exploited, the attacker inherits those capabilities.

A better design uses a dedicated service identity allowed to read the required reporting view. The view contains the necessary fields, and its permissions exclude unrelated records. The team tests both sides: generating the report must succeed, while attempts to modify data or read another department's tables must fail.

Least privilege narrows access by permitted action, resource scope, and duration. Open full-size diagram ↗

Notice the distinction between intended access and demonstrated access. A policy document saying “read-only” is not sufficient evidence when the account still belongs to an administrative group. Check the effective permissions, including inherited memberships and alternate credentials.

Temporary elevation for exceptional work

Some tasks genuinely require more access. A production engineer might need to change a configuration during a maintenance window. Instead of using a permanent shared administrator account, the organization can provide named, approved elevation for that task, record its use, and remove it afterward. This connects least privilege with Privileged access.

Temporary access also needs a reliable expiry mechanism. An approval ticket does not remove a permission by itself. If an automated workflow grants access, test whether the workflow revokes it and what happens when a task overruns its window. Emergency access needs a documented recovery route and subsequent review.

Why permissions grow over time

People change jobs, services acquire features, and temporary exceptions become permanent. This accumulation is often called privilege creep. A useful review starts with current responsibilities and asks whether each entitlement still has a reason to exist. Reviewing a copied list without checking the job can preserve the original problem.

Identity and access management provides the broader processes for onboarding, role changes, and departure. Least privilege supplies a design goal for those processes. Zero trust adds the wider idea that access decisions should not depend solely on being inside a trusted network.

A small exercise

Write down the permissions needed by a fictional backup operator. Separate creating a backup, restoring one, deleting historical copies, and changing retention. Decide which actions belong together and which deserve additional approval. Explain the consequence of a stolen operator account under your design.

The exercise has no universal role name as its answer. The useful result is a defensible permission boundary that supports real work, limits unnecessary power, and can be tested.