Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

PrincipleChapter III · Security · Building block 3 of 7

Least Privilege

Least Privilege assigns an identity only the rights that a task requires. Separate roles and short scopes limit the impact of compromised access data.

By Michael Meierhoff · Meierhoff Systems

  1. RelevanceOnly rights for the work order.
  2. Rim of actionLimits the damage in case of abuse.
  3. TestabilityA lack of rights proves to be mistakes.

Context

Why this is important

If an access is taken over or used incorrectly, it does just as much as its rights allow. Broad rights make a small incident a big one. Authentication, secrets and the threat model help in depth.

This building block deals with the scope of rights and roles. Authentication verifies identity; Secrets protects credentials throughout their life cycle.

At a glance · Only the necessary rights

An identity gets only the rights for its task; further rights stay unused and otherwise increase the damage.
Shop example · Rights and radius of damage

What rights does the worker need?

The invoice worker reads order data and writes invoice files. He does not need permission to change prices or accounts in the shop.

This is how you read the picture

  1. Relevance Marked as “necessary”: Read orders and write your own invoices.
  2. Rim of action List “possible if a worker is taken over” grows with each set right.
  3. Testability Message “Task fails” appears as soon as a necessary right is switched off.
Worker's rights · Invoice worker

Possible with adopted worker

  • Read all order and customer data
  • Overwrite or fake billing files
  • Orders such as B-1042 Rewriting or cancelling
  • Prices such as 49,90 € Manipulated
  • Create, modify and export accounts
  • Read and delete foreign files

Additional rights increase the damage that an adopted worker can do.

Switch rights on and off; on the right is what an attacker could do with the adopted worker.

Benefits & limitations

Helps if:

  • Defined workload and human tasks need permissions scoped to their resources.
  • Small, separate scopes limit the consequences of compromised access or misuse.

Boundaries

  • Overly granular permissions are error-prone and hard to maintain; group them around stable tasks.
  • Shared or permanently privileged accounts complicate attribution and revocation; traceable identities and time-limited exceptions help.
  • Narrow permissions limit damage but do not prevent compromise; Authentication verifies identity, while Secrets protects credentials.

In practice

  1. Inventory tasks and required access. List resources and operations for each identity and environment. Distinguish necessary permissions from historical grants. This provides a traceable basis for a narrowly scoped role.
  2. Limit and assign permissions. Link a human or workload identity to necessary actions and bound their scope and duration. Record exceptional grants with an owner and expiry time. This distinguishes regular from elevated access.
  3. Identify excessive permissions. Regularly review access logs, negative tests and role changes. Revoke unused permissions through a defined process and verify the effect. This yields a documented permission set matching the actual task.
Read the detailed explanation

Least Privilege derives permissions from a specific task. Identities receive only the resource actions they need; read, write and administrative permissions are considered separately. Workloads and people need attributable identities. The principle complements Authentication & Authorisation by limiting available permissions and is closely linked to handling Secrets.

Permissions can be bound to roles, resources, environments and time periods. Short-lived grants reduce the duration of elevated access. Overly fine-grained policies are hard to maintain and can introduce errors; ambiguous shared accounts make attribution and revocation harder. Usage data, negative tests and regular access recertification help identify excessive or unused permissions.

Jerome Saltzer and Michael Schroeder described the principle in 1975.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    Turn on all rights. Which rights are marked as “not necessary”?

    View the solution with justification

    Change orders, change prices, manage users and manage any files. They only increase the list of possible damages.

  2. ApplyingTransferred to a new situation

    The worker should also the shipping address of B-1042 Print on the invoice. What rights do you need for this?

    View the solution with justification

    No new: Read orders covers the address. Writing rights to orders remain off.

  3. EvaluateWeighing an alternative

    Broad rights save the maintenance of roles. How do you rate this against narrow rights?

    View the solution with justification

    Advantage wide: less care. Disadvantage: An adopted worker could change prices, accounts and files. Recommendation: narrow rights, tests that a missing right immediately stands out.

Explore further

These building blocks continue the thoughts of this page.

SecurityAuthentication & authorisationAuthentication establishes identity; authorization checks whether an action is permitted.Opening SecuritySecretsHere you find rules for protecting credentials through creation, use, rotation and revocation.Opening SecurityTrust BoundariesTrust Boundaries mark transitions between trust levels that require protection and validation.Opening

References

Continue on the learning path

Next in Security & risks: Authentication & authorisation.

7 Building blocks

Continue withAuthentication & authorisation