Securitybasic

Principle of Least Privilege

A security principle requiring that every user, process, and system component be granted only the minimum permissions necessary to perform its function.

Also known as: least privilege, PoLP, minimal access, need-to-know principle

Description

The Principle of Least Privilege (PoLP) is a fundamental security concept that dictates every entity in a system -- whether a user, service, process, or application component -- should operate with the minimum set of permissions required to accomplish its legitimate tasks. By restricting access rights to the bare minimum, the blast radius of any compromise is contained, accidental damage from misconfiguration is reduced, and the attack surface is minimized.

In practice, least privilege applies at every level of the technology stack. At the infrastructure level, it means IAM roles with specific resource-level permissions rather than wildcard (*) policies. At the database level, it means application service accounts with only SELECT/INSERT/UPDATE on specific tables rather than superuser access. At the application level, it means role-based access control (RBAC) or attribute-based access control (ABAC) that restricts users to their authorized operations. At the process level, it means running containers as non-root users and dropping unnecessary Linux capabilities.

Implementing least privilege requires continuous effort. Over time, permissions tend to accumulate (privilege creep) as users change roles or temporary access becomes permanent. Regular access reviews, automated permission auditing, just-in-time (JIT) access provisioning for elevated privileges, and time-bound access grants help maintain least privilege. Cloud providers offer tools like AWS IAM Access Analyzer and Google Cloud IAM Recommender that analyze actual permission usage and suggest reductions.

Prompt Snippet

Apply least privilege at every layer: create dedicated IAM roles per service with resource-specific permissions (avoid Action: '*' or Resource: '*' in AWS policies), use separate database users per microservice with GRANT limited to required tables and operations, run containers as non-root (USER 1001 in Dockerfile) with read-only root filesystems, and drop all Linux capabilities except those explicitly needed (drop ALL, add only NET_BIND_SERVICE if required). Implement RBAC in the application layer with default-deny authorization middleware. Use AWS IAM Access Analyzer or GCP IAM Recommender to identify and remove unused permissions quarterly.