Skip to content
sec/atlas
back to the map
technique
stage: proteger
4 min read

IAM - identity and access

Identity is the new perimeter: cloud security starts with knowing who every workload, every human and every service is, and limiting exactly what each one can touch.

AWS IAMOktaMicrosoft Entra IDPalo Alto Prisma Cloud

What it is

IAM () is the system that decides who exists in your cloud environment, what each one can do and under which conditions. Instead of a firewall at the edge, control is distributed across every API call: each request carries an identity, and that identity is evaluated against policies before touching any resource.

Three pieces hold everything up: the principal (human, service, workload), the action it wants to perform (s3:GetObject, ec2:TerminateInstance) and the target resource (bucket, instance, function). The answer is always yes or no, and the engine records who asked for what, when and how.

Users, roles and policies

Users are persistent identities tied to a person (or to a static secret). Roles are assumable identities: instead of a password, someone switches roles via AssumeRole and gets temporary credentials for minutes or hours. For workloads, this is almost always the way: no fixed users, everything through roles.

Policies are JSON documents that describe permissions. There are three types you run into all the time: identity policies (attached to the principal), resource policies (attached to the resource, like a bucket policy) and session policies (additional limits during AssumeRole). Evaluation combines all of them, and a single explicit deny is enough to block the action.

When everything is a policy, you can review, version and test access as code. When half of it is a click in the console and the other half is a JSON pasted in Slack, chaos shows up at the first incident.

Wildcard versus least privilege

The policy below is the classic anti-pattern: admin with everything on any resource. It shows up every week in some workshop and in half of the public bucket incidents on the internet.

policy.json - permissive (DO NOT use)json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "FullAccessForDev",
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

The policy that should exist

Even a simple job rarely needs everything. This policy grants only read access to the right bucket, in the right region, with a condition that limits the source to a specific role:

policy.json - least privilegejson
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadSiteAssets",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::appsec-kb-static",
        "arn:aws:s3:::appsec-kb-static/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/Team": "frontend"
        }
      }
    }
  ]
}

Trust policy: who can assume the role

Every role has two sides. The first is the trust policy, which defines who can call sts:AssumeRole. The second is the permission policy, which defines what the assumer gains. Mixing the two is where incidents are born: the role allows s3:* everywhere, and the trust accepts Principal: "*", so any authenticated account gets in.

A good trust policy names accounts, services and even external conditions (MFA, time of day, federated provider). When you see "Principal": "*" without an explicit Condition, it is worth stopping to ask why.

Permission boundaries: the seat belt

Permission boundaries work like a ceiling: a principal's effective permission is the intersection between what the boundary allows and what the identity policy allows. It is the standard tool for giving teams autonomy without giving up central control.

In practice, you define one boundary per team or environment (production, staging) and let the team write identity policies inside that envelope. The developer can widen the range as much as they like, but never goes past the ceiling.

Where it fits in day-to-day work

  • onboarding a new person: the identity provider (SAML/OIDC) issues short-lived tokens, the cloud never sees a password
  • application deploy: the workload receives a role via OIDC/IRSA and exchanges a token for credentials, with no secret in the repository
  • immediate revocation: remove the role, end the STS session and access dies the next minute, without rotating a secret
  • auditing: every call becomes an event in CloudTrail/equivalent, with principal ARN, source IP and user agent

Strengths

  • granular control by action, resource, tag and condition, with no need for a private network
  • central revocation: take down the role and everyone loses access at the same time
  • auditable model: every decision goes through versioned policies that can be reviewed in a PR

Limitations

  • policies turn into spaghetti: without visualization and lint tooling, it is easy to keep 4,000 contradictory statements
  • demands continuous discovery: what the team needs changes every sprint, and the policy falls behind
  • the model confuses human and workload: treating a workload like a human (with a fixed user + static Access Key) is the entry point for almost every leak
IAMidentity and access managementThe set of policies, roles and credentials that says who every human, service or workload is, and what each one can do. In the cloud, IAM became the new perimeter: the network edge got porous, so identity carries the authorization.see in glossary →Privilege escalationGaining more rights than initially granted, through a flaw, a misconfiguration or a stolen credential.see in glossary →Least privilegeleast privilegeThe principle of giving each identity only the permissions strictly needed for its function, and nothing more. It is the opposite of 'admin user by default': every extra role is one more path an attacker can use after a compromise.see in glossary →

connections on the map

updated on 14/10/2026 · sources to go deeper · report an error

in other domains

Unlocks

test what you learned

Loading questions…