The Principle of Least Privilege

The principle of least privilege is one of the most important concepts in information security. In AWS, it means granting each identity — whether a user, role, or service — only the permissions it needs to perform its specific task, and nothing more.

---

What is Least Privilege?

Least privilege states that every identity should have the minimum set of permissions required to do its job. No more, no less.

This is not about making things difficult — it is about reducing risk. If a user only needs to read objects from one S3 bucket, giving them full administrator access creates unnecessary exposure. If their credentials are compromised, the attacker inherits all of those excessive permissions.

---

Why Least Privilege Matters

Reduce Blast Radius

If a set of credentials is compromised, the damage is limited to what those credentials can do. Least privilege minimises the blast radius.

Scenario	Permissions	Blast Radius
Developer with admin access is compromised	Full account access	Entire AWS account
Developer with S3-read-only is compromised	Can read one S3 bucket	One bucket's data

Prevent Accidental Damage

Even without malicious intent, excessive permissions lead to accidents. A developer with permissions to delete production databases might accidentally run the wrong command.

Meet Compliance Requirements

Regulatory frameworks — including PCI DSS, HIPAA, SOC 2, ISO 27001, and GDPR — require organisations to implement access controls based on least privilege.

Simplify Auditing

When permissions are tightly scoped, it is much easier to understand who can do what. Broad permissions make security audits difficult and time-consuming.

---

Implementing Least Privilege in AWS

Step 1: Start with Zero Permissions

When you create a new IAM user or role, it has no permissions by default (except for the ability to sign in, if it has a password). This is the correct starting point — you add permissions as needed rather than removing them from a broad starting point.

Step 2: Use Specific Actions

Avoid wildcard actions when possible:

Too broad:

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

Better:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:ListBucket"
  ],
  "Resource": [
    "arn:aws:s3:::my-app-data",
    "arn:aws:s3:::my-app-data/*"
  ]
}

Step 3: Scope Resources

Always specify the exact resources whenever possible. Using "Resource": "*" means the permission applies to every resource of that type in your account (and sometimes across accounts).

Step 4: Use Conditions

Add conditions to further restrict when permissions apply:

{
  "Effect": "Allow",
  "Action": "ec2:RunInstances",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:RequestedRegion": "eu-west-2"
    },
    "ForAllValues:StringEquals": {
      "ec2:InstanceType": ["t3.micro", "t3.small"]
    }
  }
}

This allows launching EC2 instances only in the London region and only using small instance types.

Step 5: Use Permission Boundaries

For delegated administration — where you allow others to create IAM users or roles — set permission boundaries to cap the maximum permissions they can grant.

---

Tools for Achieving Least Privilege

AWS provides several tools to help you implement and maintain least privilege:

IAM Access Analyzer