Cloud Identity and Access Management

Cloud identity and access management, or IAM, controls access to cloud resources. It answers four linked questions:

Who or what is requesting access?
How does the system verify that identity?
What action may that identity perform on which resource?
What evidence records the decision and resulting activity?

IAM is the control plane between identities and resources. A strong design gives each identity enough access for its work, for only as long as needed. A weak design can turn one stolen credential into broad access across an environment.

The central mental model

Think of an access decision as a sentence:

A principal may perform an action on a resource when the request meets specified conditions.

Principal: a human, workload, device, or external identity making a request
Action: an operation such as reading an object or changing a network policy
Resource: the protected object, service, project, account, or subscription
Condition: context such as time, device state, network, authentication strength, or resource attributes

Authentication establishes confidence in an identity. Authorization decides what that authenticated identity may do. These are separate controls. A successful sign-in does not imply permission to every resource.

Cloud providers express the model with different policy languages and names. The stable questions remain the same: principal, action, resource, and condition.

Identity types

Workforce identities

Employees, contractors, and administrators are workforce identities. They usually authenticate through a central identity provider. Federation lets the cloud trust that provider instead of maintaining a separate password in each cloud account.

Single sign-on reduces repeated sign-ins. Multi-factor authentication requires more than one factor category. Phishing-resistant authenticators offer stronger protection than methods that users can relay or approve by mistake.

Workload identities

Applications, automation, virtual machines, and managed services also need identities. A workload identity should represent the workload itself. It should receive short-lived credentials through the platform when possible.

Do not treat a shared user account as a workload identity. Do not embed long-lived access keys in source code or deployment files. Those practices weaken attribution and make rotation difficult.

External identities

Partners, customers, and identities from another organization may need limited access. Federation can establish trust across an organizational boundary. The relying system still decides which claims it trusts and which permissions it grants.

The identity lifecycle

IAM begins before the first sign-in and continues after access ends.

Join: create or link the identity, establish required attributes, and assign initial access.
Move: change access when duties, projects, or risk change.
Leave: disable access, revoke sessions and credentials, and transfer ownership where required.
Review: inspect current grants, unused access, privileged roles, and exceptions throughout the lifecycle.

Groups and roles make lifecycle work manageable. Assign access to job functions or workload purposes, then manage membership. Direct grants to individual users are harder to review and remove consistently.

Provisioning automation reduces delay, but automation does not choose the correct policy by itself. You still need an authoritative identity source, clear ownership, and tested removal paths.

Permission models

Role-based access control groups permissions into roles. You assign a role such as billing viewer or network operator to a principal. Roles work well when responsibilities are stable and understandable.

Attribute-based access control evaluates attributes about the principal, resource, action, or environment. A condition might allow access only to resources labeled for the principal's team during an approved time window.

Most cloud systems combine roles, resource hierarchy, explicit policy, and conditions. A grant at a high level can affect many descendant resources. That inheritance is convenient, but it can create a large blast radius.

Effective access is the result after all relevant grants, boundaries, conditions, inheritance rules, and explicit denies are evaluated. Reading one policy document may not reveal the full result.

Least privilege in practice

Least privilege means granting only the access required for a defined task. It is a continuing process, not a one-time role selection.

Start with a business task and identify its required actions and resources. Prefer narrow scopes and managed roles when they fit. Use conditions to reduce scope further. Observe actual use, remove unused permissions, and repeat the review.

Privileged work needs additional controls. Separate administrative identities from ordinary work. Require strong authentication. Use temporary elevation where supported. Record approvals and activity. Keep emergency access available, protected, and tested.

Separation of duties prevents one identity from controlling every stage of a sensitive process. For example, the identity that requests production access should not always approve its own request.

Federation and tokens

Federation lets an identity provider communicate an authentication result to a relying party. OpenID Connect provides an authentication layer built on OAuth. Security Assertion Markup Language remains common in enterprise federation.

OAuth is an authorization framework. It lets a client receive an access token for limited access without receiving the resource owner's password. An access token represents authorization for a scope and duration. It is not automatically proof that a human authenticated in a particular way.

Validate tokens for the intended issuer, audience, lifetime, and permitted use. Keep authentication tokens and API access tokens conceptually separate. Similar-looking token formats can serve different purposes.

Context-aware access and zero trust

Identity is necessary, but identity alone may be insufficient. A policy can also evaluate device health, location, authentication strength, resource sensitivity, and observed risk.

Zero trust does not mean trusting nobody. It means avoiding implicit trust based only on network location or a previous decision. Evaluate access against policy, grant the minimum needed access, and reassess when context changes.

Conditional controls can fail closed or lock out legitimate administrators when deployed carelessly. Test policies with observation or report-only modes when available. Exclude and protect emergency access through a deliberate process.

Evidence and review

Audit logs should show authentication events, policy changes, role assignments, token use where available, and access to sensitive resources. Send important logs to a protected location outside the administrator's ordinary control.

Logs support detection and investigation, but they also support design. Access activity can reveal unused permissions, unusual privilege use, and grants that are broader than the work requires.

Review both identity and resource policies. A principal policy may look narrow while a resource policy grants broad external access. Cross-account trust, inherited grants, and service-specific policies can all change effective access.

Where IAM helps and where it stops

IAM is useful for controlling management operations, application access, data access, and machine-to-machine requests. It creates attribution and gives policy engines the information needed to decide.

IAM does not repair vulnerable software. It does not classify data for you. It cannot make an overbroad role safe merely because the user completed multi-factor authentication. It also cannot compensate for missing asset ownership or incomplete offboarding.

Good IAM connects people, process, and technical policy. The goal is not the largest policy library. The goal is explainable access that matches current work and leaves reliable evidence.

A practical study path

Learn authentication, authorization, federation, and the principal-action-resource model.
Map your cloud's resource hierarchy and policy evaluation rules.
Centralize workforce access through federation and strong authentication.
Replace embedded workload secrets with managed, short-lived credentials.
Design roles around tasks, then narrow them with scope and conditions.
Add privileged access workflows, access reviews, and emergency access.
Use logs and access analysis to refine permissions continuously.
Test lifecycle events, policy failures, and incident revocation paths.