least-privilege-and-mediation

Least Privilege and Complete Mediation

These two principles work together: least privilege limits what an entity can do, and complete mediation ensures that every access attempt is checked against those limits.

Least Privilege

Principle: Individuals and entities should only be given sufficient access and permissions to complete their assigned duties, no more.

Key Aspects

• Least privilege by default: Start with zero access and grant permissions incrementally as justified
• Minimal access permissions: Limit scope to reduce impact of fraud, compromise, or user error
• Reduced attack surface: Fewer permissions mean fewer opportunities for exploitation
• User accountability: When permissions are specific and narrow, audit trails are meaningful and anomalous activity is detectable

Application

Context	Least-Privilege Practice
Database	Application accounts use the lowest privilege level; separate accounts per trust level
Kubernetes	No wildcards in RBAC; no cluster-admin; explicit verbs and resources
Cloud IAM	Individual accounts; IAM groups; no root credentials for daily operations
OS/containers	Non-root users; readOnlyRootFilesystem; no-new-privileges
API access	Scoped tokens; short-lived credentials; per-operation authorization

Complete Mediation

Principle: Every request by a subject to access an object must undergo a valid and effective authorization process that the subject cannot bypass or disable.

This is a pillar of Zero Trust Architecture: never assume a request is authorized because it came from inside the network or from a previously authenticated session.

Key Aspects

• Access verification: Validate every access attempt, including internal service-to-service calls
• Fine-grained access control: Define precisely what actions each user or process is authorized to perform
• Enhanced accountability: Comprehensive access logs enable forensic analysis and incident response
• Systematic testing: Maintain an access-control test matrix that maps user roles to resources and validates that controls deny unauthorized access and permit only authorized access

Application

• Enforce authorization on every request, including AJAX calls, background jobs, and internal APIs
• Do not rely on referrer headers, client-side state, or session age as authorization factors
• Re-validate privileges on long-lived sessions
• Implement a single site-wide authorization component to ensure consistency
• Fail secure: If the authorization service is unreachable, deny access

Implementation Checklist

• All accounts and service identities start with zero access (default deny)
• Permissions are granted per duty, not per convenience
• Every request passes through the authorization layer (no bypass paths)
• Authorization is enforced server-side, not client-side
• A single centralized authorization component handles all access decisions
• Authorization fails closed (deny on error or unreachable service)
• Privileges are re-validated on long-lived sessions
• An access-control test matrix exists and is executed regularly
• Audit logs capture all access attempts (success and failure)

References

• Saltzer & Schroeder: The Protection of Information in Computer Systems (1975)
• NIST SP 800-53 AC-6: Least Privilege
• OWASP Authorization Cheat Sheet
• NIST Zero Trust Architecture (SP 800-207)