Stop 07 · Identity & SecurityTopics · 2/10

Principle of Least Privilege

In short

Most cloud breaches don't need clever hacking. Someone finds a leaked key that had far more power than it needed. Least privilege makes sure a stolen key can only do a little damage.

Granting only the minimum permissions needed for a task, never broad access 'just in case' — a foundational security principle that limits the damage of a compromised credential or a mistake.

The blob character holds a small drawer key at a bank counter, with a closed vault door behind.

Think of it like this

The cashier's drawer key

A bank cashier gets the key to their own cash drawer, not the main vault. If that key is lost, the bank loses a drawer, not the building. Give every person and program the drawer key for their job, nothing more.

Watch it happen

Same leaked key, different damage

AdministratorAccess

Attacker can read every bucket
Can launch costly servers for mining
Can delete backups and logs

Scoped to one job

Can only write to uploads/ prefix
Cannot list or read other data
Cannot create or delete anything

Keys leak eventually. Least privilege decides whether that day is a small fix or a disaster.

The big ideas

What you need to know

Start from zero

Begin with no permissions and add only the actions a task actually fails without. Never start from admin and trim.

Scope resources too

Allowing s3:PutObject on one bucket is far safer than on every bucket. Narrow the Resource, not just the Action.

Short-lived wins

Temporary credentials from roles expire on their own, so a leak has a short shelf life.

Review what's unused

Tools like IAM Access Analyzer and last-accessed data show permissions nobody has used in months. Remove them.

See it in code

Walk through the code

json

1{2  "Version": "2012-10-17",3  "Statement": [4    {5      "Effect": "Allow",6      "Action": "s3:PutObject",7      "Resource": "arn:aws:s3:::campus-app/uploads/*"8    }9  ]10}

1/2One action only: write an object. No read, no delete, no list.

An upload service only needs to write new files under one folder. That's the whole policy.

Save yourself the pain

Common mistakes

Oops

Granting broad access "for now" and planning to tighten it later.

Do this instead

Later rarely comes. Start narrow; widening a policy takes two minutes when something actually breaks.

Oops

One shared IAM user for the whole team and all scripts.

Do this instead

Give each person and each service its own identity, so you can scope it and revoke it alone.

Your mission

Trim a fat policy

~25 min

Quick check

Why is least privilege still useful even if you never leak a key?

Go deeper

1Audit a hypothetical IAM policy and identify any overly broad permissions.
2Practice writing a least-privilege policy scoped to a specific task, not a whole service.
3Learn why 'admin access for everyone' is a common but serious security anti-pattern.