1.2.2. The Principle of Least Privilege
💡 First Principle: Every identity—human or machine—should have exactly the permissions needed to perform its function, no more and no less. Excess permissions create attack surface; insufficient permissions block legitimate work.
This sounds simple but is deceptively difficult. Developers request broad permissions "just in case." Administrators grant Owner roles because it's faster than figuring out specific needs. Over time, permissions accumulate and nobody knows who actually needs what—a phenomenon called "permissions creep."
Least Privilege in Practice:
| Bad Practice | Least Privilege Approach |
|---|---|
| Grant Owner to developers | Grant Contributor to specific resource groups |
| Permanent admin access | Just-in-Time access via PIM |
| Service accounts with Contributor | Managed identities with custom roles |
| Shared credentials | Individual accounts with auditing |
Scenario: A developer needs to deploy code to a web app. The lazy approach grants Contributor on the entire subscription. The least-privilege approach grants Website Contributor on just the App Service resource group—plus Reader on the associated Key Vault for secrets. If this developer's credentials are compromised, the blast radius is one application, not the entire subscription.
