Identities, roles and least privilege

Why this matters

Identity is the control plane of a cloud. There is no perimeter to stand behind: every action is an API call, and every API call is authorised against an identity. Get identity right and a compromised instance is contained; get it wrong and the same compromise reaches everything.

This is also, consistently, where real cloud breaches come from. Not exotic exploits — over-broad permissions, long-lived keys in a repository, a role that anyone could assume, an account without multifactor authentication.

CompTIA's verb is implementing IAM to control resource access, which is a practical instruction. This lesson is the mechanics; the next is federation and authentication.

The lesson

Users, groups, roles and service principals, and which one a workload should use

Four kinds of identity, with different purposes.

• User. A person, with credentials they hold. Should be used only by humans, and ideally only as a federated identity (next lesson) rather than a locally-created account.
• Group. A collection of users, for attaching permissions. Permissions go on groups, never on individual users — that way access is granted by membership, which is reviewable, and it does not have to be reconstructed for each new joiner.
• Role. A set of permissions that an identity assumes temporarily. Assuming a role yields short-lived credentials. This is the central construct in cloud identity, and the answer to most "how should this get access" questions.
• Service principal / service account. A non-human identity for an application or service.

The rule for workloads, repeating objective 2.4 because it matters most: attach a role to the resource. An instance, a container's service account, or a function gets an identity from the platform, receives short-lived credentials automatically, and never stores a key.

The consequence for long-lived access keys is worth stating flatly: they should be rare and exceptional. They do not expire, they end up in repositories, images, laptops and wikis, and leaked keys are one of the most common initial access vectors there is. Where an external system genuinely needs programmatic access, prefer federation from its own identity provider over issuing a key; where a key is unavoidable, rotate it on a schedule and monitor its use.

A related idea worth carrying: the root or global administrator account of an account or subscription should be locked away — strong unique credential, hardware multifactor, no access keys, used essentially never, and alerted on every time it is used.

Policy evaluation: allow, deny and the explicit deny that always wins

Cloud authorisation is evaluated per request, and the logic is consistent enough to learn once.

The general model:

1. Default deny. With no policy, nothing is permitted.
2. An explicit allow in any applicable policy permits the action.
3. An explicit deny anywhere always wins, overriding every allow.

That last rule is the most examined single fact in the objective. If someone has administrator permissions and any applicable policy explicitly denies an action, the action is denied. Explicit deny is therefore the tool for absolute prohibitions — no deletion of audit logs, no use of unapproved regions, no disabling of encryption — that must hold even for administrators.

Policies attach in several places and all applicable ones are evaluated:

• Identity-based, attached to a user, group or role.
• Resource-based, attached to the resource itself (a bucket policy, a queue policy). These also enable cross-account access, granting a principal in another account without anything being created there.
• Organisation-level guardrails — service control policies or management policies — which set the maximum available permissions for whole accounts.
• Permission boundaries, which cap what an identity can have regardless of what is granted to it.

The important subtlety about boundaries and organisation policies: they limit, they do not grant. An action needs an allow and must not be excluded by any boundary. A permission that appears to be granted and does not work is very often being cut off by a guardrail somewhere above it, and knowing to look there is a genuine troubleshooting skill.

Use conditions as well, because they are where the real precision lives: permit an action only from a particular network, only with multifactor authentication present, only on resources with a matching tag, only within a region.

Least privilege in practice, starting from nothing and adding what fails

Least privilege is easy to state and difficult to do, and the difficulty is what the objective is really about.

The method that works:

1. Start with nothing. Grant no permissions and run the workload in a non-production environment.
2. Let it fail, and read the denials. Each authorisation failure names the action and the resource.
3. Grant exactly that, scoped to the specific resources rather than to everything.
4. Repeat until it works.
5. Review against the access logs after a period of real use — the platform records which permissions were actually exercised, and anything never used can usually be removed.

The alternative — grant broadly, intend to narrow later — never narrows, because nothing forces it and narrowing risks breaking something that works.

Scope on both axes, and this is the part people do half of:

• Actions: the specific operations, not a wildcard.
• Resources: the specific buckets, tables or instances, not every resource of that type. A policy allowing an action on all resources of a type is a very common over-grant that reads as though it is scoped.

Distinguish the two planes, since they fail differently. Control-plane permissions manage resources — create, delete, modify, change configuration. Data-plane permissions read and write the data inside them. An identity may legitimately need to read objects in a bucket and have no business deleting the bucket, and separating those is exactly what limits the damage of a compromise.

Finally, accept that least privilege is maintained, not achieved. Workloads change and permissions accumulate, which is what the next section is for.

Permission boundaries and service control policies as guardrails above the policy

Guardrails answer a problem least privilege alone cannot: how do you let teams move quickly without letting them grant themselves anything?

Organisation-level policies (service control policies, management group policies) define the maximum permissions available anywhere in an account. They are how an organisation enforces things absolutely:

• Deny use of regions outside an approved list — which is both a data-residency control and a way to shrink the space attackers can hide resources in.
• Deny disabling of audit logging, deleting log destinations, or turning off security services. Even for administrators.
• Deny removing the organisation's own controls.
• Require encryption on resource creation.

Permission boundaries solve delegation. You want a team lead to create roles for their own applications without being able to create a role with administrative rights. A boundary caps what any role they create can have, so delegation becomes safe.

Together these implement a useful separation: a central team sets the limits, and teams work freely within them. That scales far better than a central team approving every permission request, and it is the answer a scenario is usually looking for when it describes many teams and a small platform group.

Account structure is the coarsest guardrail and the most effective: separate accounts per environment and per team. A blast radius bounded by an account boundary is bounded by something the platform enforces absolutely, and it makes both billing (objective 1.8) and quotas (objective 2.4) cleaner at the same time.

Access reviews, unused permissions and the credential nobody has rotated

Identity decays. People change roles and keep old access; applications are retired and their roles remain; permissions granted for a one-off task are never removed. The result is privilege creep, and it is the reason a routine review is a control rather than an administrative chore.

What to review, on a schedule:

• Who has access to what, confirmed by the system owner rather than by the identity team. The owner knows whether the finance analyst should still be able to read the production database; the identity team cannot.
• Unused permissions. Platforms report when a permission was last used; anything unused for months is a candidate for removal, and this is the single highest-yield review because it is evidence-based rather than a judgement.
• Unused identities — users who have not signed in, roles never assumed, keys never called. These are pure attack surface with no benefit.
• Credential age. Any long-lived key beyond its rotation policy.
• Privileged group membership, reviewed most frequently and most sceptically.
• Cross-account trust, which is how access reaches outside the organisation and is the least visible.

Two process points that make reviews real rather than ceremonial:

• Joiners, movers, leavers. The mover case is the one that leaks: someone changes team and gains new access while keeping the old. Access should be re-derived on a move, not added to.
• Automate revocation where you can. A review that produces a list nobody acts on has achieved nothing, and the useful measure is the number of permissions actually removed.

The stronger destination is just-in-time access: nobody holds standing privileged access, and elevation is requested, approved, time-boxed and logged. It removes most of what a review exists to find, because there is no standing privilege to accumulate.

What to take into the exam

• Permissions on groups, never on individual users. Roles for workloads, never long-lived keys. Lock away the root account.
• Default deny; an explicit allow permits; an explicit DENY always wins — including over administrators.
• Boundaries and organisation policies limit, they do not grant. A permission that seems granted but fails is often cut off above.
• Least privilege = start from nothing, add what fails, then prune using last-used data. Scope actions and resources, and separate control plane from data plane.
• Guardrails let a central team set limits while teams work freely — and separate accounts are the strongest guardrail.
• Review unused permissions and identities, handle movers by re-deriving access, and prefer just-in-time elevation over standing privilege.