Identity and Access Management

In a real cloud account, not everyone — and not every program — should be able to do everything. Someone needs to be able to read the customer database; nobody except the billing system should be able to modify it. The question is: how does the cloud know who is asking, and what they are allowed to do?

The answer is identity and access management, usually shortened to IAM. IAM is the system that controls identity (proving who you are) and permissions (what you are allowed to do once identified). It is the backbone of cloud security — every other security measure depends on it working correctly.

Think of keycards in an office building. Each person's card opens only the doors their job requires. The receptionist's card opens the front door and the meeting rooms. The server room door only opens for the IT team. The finance vault requires the CFO's card. No one card opens every door — and if a card is lost, it can be cancelled without changing the locks on the whole building.

Identity: Who or What Is Making a Request?

Every request made to a cloud service comes from an identity. Most obviously, identities include people: engineers logging into the console, admins running scripts. But identities also include machines and programs. An application that reads from a database has an identity. A background job that resizes uploaded images has an identity. A monitoring service that checks whether other services are running has an identity. IAM covers all of them — not just the humans in your organization.

Permissions: The Explicit List of Allowed Actions

Permissions are the precise list of what a given identity is allowed to do. "Read files from this storage bucket" is a permission. "Start this specific virtual machine" is a permission. "Delete any resource in this account" is also a permission — one you would give very carefully. In well-run cloud accounts, nothing is implicitly allowed; every capability must be explicitly granted. If the permission list does not say an action is allowed, the answer is no.

Least Privilege: Only What Is Needed

The guiding principle of IAM is called least privilege: give each identity only the permissions it needs to do its job, and nothing more. If a photo-processing service only needs to read from one storage bucket, give it read access to that bucket — not write access, not access to other buckets, and certainly not admin rights over the whole account. The benefit is containment: if that service is compromised by an attacker, the attacker can only do what the service was allowed to do. A small permission set means a small blast radius.

Roles and Groups: Managing Access at Scale

Assigning permissions one identity at a time quickly becomes unmanageable. IAM systems deal with this through roles and groups. A role is a bundle of permissions that can be attached to any identity that needs them — an "image-processor" role might bundle the handful of permissions that job requires. A group collects human users who all share the same access needs. When someone joins the ops team, you add them to the ops group; they instantly inherit the right permissions without anyone reviewing them one by one. When they leave, you remove them from the group and all those permissions go with it.