Least privilege on AWS: give every program only what it needs

What does least privilege mean in practice?

It means handing each user and each program a key that opens only the doors it needs. The bookkeeper can see invoices but cannot delete the server. The program that sends emails reads the mailing list but never touches payments. Anything the job does not need is simply not allowed.

NIST, the US public body for standards, describes it the same way: each entity is granted the minimum resources and authorisations it needs to perform its function. The idea is not new, and it is not specific to the cloud. It is the same logic as the keys to an office, applied to software.

What changes in the cloud is that the keys are many and invisible. Every server, every function and every employee has a set of permissions written as rules. If nobody looks at them, they grow over time, because adding a permission is always easier than working out exactly which one is needed.

Why are broad permissions a risk for a business?

Because the damage from any incident is as large as the permissions of the key that was lost. If someone steals the credentials of a program that can do everything, the attacker can do everything too. If that program could only read one folder, only that folder is exposed.

The same goes for honest mistakes. A contractor tidying up old files could delete the production database by accident, if their permissions allow it. With least privilege, the command is simply refused and the mistake stays harmless.

For a small business this matters more than for a large one. There is rarely a security team watching the account day and night. So the cheapest protection is to make large-scale damage impossible from the start. That is where cloud security begins, before any tool that costs money.

It is the same thinking behind my system that recognises scanners by their behaviour and blocks them: fewer open doors, fewer places to attack.

How does least privilege work on AWS?

On AWS, permissions live in AWS IAM as rules called policies. Each policy states which actions are allowed, on which resources and under which conditions. Programs do not get permanent passwords; they get IAM roles, which hand out temporary credentials only for as long as they are needed.

A simple example: a website’s contact form stores messages in a table. The form’s IAM role allows one thing only, adding a row to that table. It cannot read earlier messages, delete the table, or touch any other resource in the account.

AWS also recommends temporary credentials for people, multi-factor authentication (MFA), and conditions inside policies, such as allowing an action only through a specific service. All of this is set out in the AWS IAM security best practices.

On a platform with many customers, the same thinking goes one step further: each customer’s data is kept apart, so a problem with one never reaches the others. I explain that in the article on a database per tenant.

How do you apply least privilege step by step?

Start from the work, not from the permissions. Write down what each person and each program has to do, grant exactly that, test it, and then remove whatever goes unused. The process is never finished for good; you repeat it every time the application or the team changes.

The steps, in order:

1. Lock away the root user. The account’s root user is not used for daily work; it has MFA and stays out of the way.
2. List the jobs. For each person and program, write in plain words what it does: “uploads photos”, “sends invoices”, “reads orders”.
3. Give one role per job. Each program gets its own IAM role. Two programs never share a role, so a problem in one does not spread to the other.
4. Write rules for specific resources. Not “all buckets” but “this bucket”. Not “every action” but “read” or “write”.
5. Test before going live. If something is missing, the program fails with a clear access-denied message. You then add only what is missing.
6. Review usage regularly. With IAM Access Analyzer and last-accessed information you see which permissions were never used, and you remove them.

The order is what matters. If you start with “give it everything and we’ll see”, you rarely come back, because nobody remembers what is really needed. If you start from the list of jobs, every permission has a reason you can explain.

How do you find permissions nobody uses?

AWS shows when each service was last used by a user or a role. On top of that, IAM Access Analyzer finds resources shared outside your account and can generate a policy based on the activity actually recorded. Anything that has gone unused for a long time is a candidate for removal.

Picture a program allowed to read and write across many services that, for months, has touched only a few of them. The remaining permissions help nobody; they only widen the damage if something goes wrong. You remove them, check that everything still works, and the account is safer without a single change to the code.

The same tool also checks the policies you write before you apply them and warns you about common mistakes. And the review is not a one-off: the AWS IAM best practices recommend regularly reviewing and removing unused users, roles, permissions and credentials. A recurring reminder in the calendar is enough to stop permissions from quietly growing back.

Which permission mistakes should you avoid?

The first mistake is convenience: a rule with a wildcard that allows every action on every resource, because something was not working and had to ship fast. Next come permanent keys written into the code, and shared accounts that several people use with the same password.

Each of these solves a problem today and opens a bigger one tomorrow:

• Wildcards everywhere. A rule that says “everything on everything” turns least privilege into most privilege. If you truly need it for a while, give it a removal date.
• Keys in the code. An access key written into code can end up in a backup, an email or a public repository. IAM roles hand out temporary credentials, so the problem does not exist.
• One login for everyone. When several people sign in with the same password, you cannot tell who did what, and you cannot cut off one person alone.
• Old users that linger. A contractor who left long ago still has access if nobody removes it.

None of this needs an expensive tool. It needs a decision that every permission has a reason to exist, and someone who checks it. If you have a question about how permissions are set up in your own AWS account, write to me through the contact form.