IAM (Identity and Access Management) is the layer that decides who can do what in a cloud environment. Market research and incident response reports converge: misconfigured IAM is the number 1 compromise vector in AWS, Azure and GCP. Understanding least privilege, RBAC and the identity lifecycle is not optional - it is the foundation of any cloud security posture.

What cloud IAM is

In public cloud providers, IAM is the centralized service that authenticates identities and authorizes actions on resources. In AWS, IAM defines who can call which APIs and on which resources; in Azure, Entra ID (formerly Azure AD) manages authentication while Azure RBAC controls authorization; in GCP, Cloud IAM unifies the two into a single model of bindings per project, folder or organization.

Every action in the cloud - spinning up an instance, reading an object in storage, invoking a serverless function - passes through the IAM evaluation mechanism. The provider verifies the request's identity, locates the applicable policies and decides Allow or Deny. This flow happens in milliseconds, but the quality of the policies that guide the decision determines whether your infrastructure is resilient or fragile.

Identities in cloud environments

There are four classes of identity that must be managed differently:

  • Human users - employees who access consoles and CLIs. They should use federated SSO (SAML/OIDC) tied to the corporate directory, without long-lived local cloud credentials.
  • Assumed roles - temporary identities generated by AWS STS, Azure Managed Identity or GCP Service Account impersonation. They issue short-lived tokens and are the recommended standard for programmatic access.
  • Service accounts - workload identities used by applications, CI/CD pipelines and serverless functions. They should have the smallest possible set of permissions and never share credentials across distinct services.
  • Workload Identity - a modern mechanism that associates workload identities with verifiable attributes of the execution environment (Kubernetes cluster, GitHub Actions pipeline, GitLab runner), eliminating the use of static keys in pipelines.

Least privilege: the principle and the blast radius

Least privilege means granting each identity only the permissions strictly necessary to perform its tasks, for the minimum time required. The most important technical reason to adopt the principle is the concept of the blast radius: how much damage a compromised identity can cause.

A role with a compromised AdministratorAccess can delete the entire infrastructure, exfiltrate secrets from Secrets Manager, create backdoors via new IAM users and modify audit logs. A role restricted to s3:GetObject on a single specific bucket, if compromised, exposes only that set of objects. The difference between the two scenarios is the difference between a catastrophic incident and a containable one.

In practice, least privilege is hard to implement from the start because teams prefer to grant broad permissions to avoid operational friction. The recommended strategy is to start with permissive policies and use analysis tools - AWS IAM Access Analyzer, GCP Recommender, Azure Advisor - to identify permissions that were granted but never exercised over a 90-day observation period, then remove them.

RBAC, ABAC and PBAC: access control models

Three models dominate access control in the cloud. The following table compares their core characteristics:

Criterion RBAC ABAC PBAC
Based on Roles assigned to the user Attributes of user, resource and context Declarative policies with composite conditions
Granularity Medium High High to very high
Management complexity Low High Medium to high
Auditability High (roles visible) Medium (dynamic evaluation) High (versioned policies)
Native cloud support Azure RBAC, GCP basic roles AWS IAM conditions, GCP IAM conditions AWS IAM policies, Cedar (AWS Verified Access)
Ideal use case Stable organizational structures Context-sensitive control (time, IP, tag) Multi-account environments with organization-wide policies

In practice, the three models coexist. A company may use RBAC to define functional roles (Developer, SRE, Auditor), ABAC to add context conditions (access to production only from corporate IPs) and PBAC through SCPs (Service Control Policies) to enforce inviolable limits at the organization level.

Critical risks of misconfigured IAM

The Verizon DBIR and Cloud Security Alliance reports point to IAM misconfiguration as the root cause of most cloud incidents. The most frequent risks are:

Exposed long-lived credentials

AWS access keys, GCP service account keys and Azure client secrets stored in code repositories, CI/CD environment variables or configuration files are the most direct path to compromise. Scanning tools such as truffleHog, GitGuardian and Gitleaks detect this type of leak, but the real prevention is to eliminate the use of static credentials by replacing them with roles and workload identity.

Overly permissive roles

Policies with wildcards - "Action": "*" or "Resource": "*" - are equivalent to handing over a master key. Even when motivated by temporary development convenience, they tend to remain in production indefinitely. The principle of least privilege requires that every action and every resource be specified explicitly.

Privilege escalation via indirect paths

An attacker with iam:PassRole and ec2:RunInstances permission can create an instance with a role more privileged than their own and use that instance to escalate privileges. There are dozens of documented privilege escalation paths in AWS, Azure and GCP environments. Tools such as Cloudsplaining (AWS) and Praetorian Graph analyze these paths automatically.

Absence of MFA on critical accounts

An AWS root account without MFA, an Azure Global Admin account without MFA, or a GCP project Owner without MFA are ticking time bombs. NIST SP 800-63B classifies MFA as a mandatory control for accounts with access to high-impact systems. In the cloud, every account with permission to modify IAM or delete resources falls into this category.

Misconfigured IAM as a persistence vector

After the initial compromise, attackers frequently create new IAM users, add permissive policies to existing roles or set up malicious trust relationships to maintain access even after credential rotation. Monitoring IAM modification events in real time - via CloudTrail, Azure Monitor or Cloud Audit Logs - is the only way to detect this behavior.

IAM best practices by provider

AWS IAM

AWS recommends never using the root account for operational tasks. Every human identity should be managed via AWS IAM Identity Center (SSO), federated with the corporate directory via SAML 2.0 or OIDC. EC2 instance roles and Lambda functions should use execution roles with customer-managed policies (not the AWS managed policies, which tend to be overly permissive). SCPs applied via AWS Organizations create inviolable guardrails - for example, preventing any member account from disabling CloudTrail. AWS IAM Access Analyzer identifies excessive access and resource exposure to external entities.

Azure RBAC

Azure uses Entra ID as the identity plane and Azure RBAC as the authorization plane. Custom roles allow granularity beyond the built-in roles (Owner, Contributor, Reader). Managed Identities - system-assigned or user-assigned - eliminate credentials in Azure applications. Privileged Identity Management (PIM) implements just-in-time access: users request temporary elevation to privileged roles, which is granted for a limited time with approval and auditing. Azure Policy enforces compliance at the subscription and management group level.

GCP IAM

GCP IAM operates with bindings that associate members (identities) with roles on resources. Google recommends using Cloud Identity groups instead of binding roles directly to individual users. Workload Identity Federation allows external workloads - GitHub Actions, GitLab CI, AWS - to obtain temporary GCP credentials without using service account keys. GCP Recommender analyzes usage patterns and suggests replacing broad roles with more specific ones. Org-level policies block sensitive actions regardless of project permissions.

CIEM: managing entitlements at scale

In environments with hundreds of cloud accounts and thousands of roles, manual permission review is infeasible. CIEM (Cloud Infrastructure Entitlement Management) is the category of tools that automates this analysis: it maps all effective permissions (not just those granted, but those that can actually be exercised after evaluating policies, SCPs and permission boundaries), detects privilege escalation paths, identifies unused entitlements and generates compliance reports against CIS Benchmarks and regulatory frameworks.

Reference tools include AWS IAM Access Analyzer (native, free), Wiz CIEM, Ermetic, Sonrai Security and Tenable Cloud Security. Adopting CIEM is one of the main differences between organizations with a mature cloud security posture and those that discover misconfigurations only after incidents.

Periodic access review

Permissions accumulated over time - through role changes, rushed onboarding or closed projects - are a silent risk. The CIS Benchmark for AWS recommends a quarterly review of IAM users, roles and policies. In practice, the process should include: removing users inactive for more than 90 days; revoking un-rotated access keys; reviewing trust policies of cross-account roles; and auditing inline policies, which frequently escape automated reviews.

Frequently asked questions

The questions below reflect the most common doubts of security, engineering and management teams when implementing IAM in corporate cloud environments.

What is cloud IAM and why is it considered the number 1 attack vector?

IAM (Identity and Access Management) is the set of policies, roles and mechanisms that controls who can do what in a cloud environment. It is the number 1 incident vector because excessive permissions or poorly protected credentials allow an attacker to exploit the entire account without needing vulnerability exploits - all they need is legitimate (but improper) access to the compromised identity.

What is the practical difference between RBAC, ABAC and PBAC?

RBAC (Role-Based) ties permissions to fixed roles assigned to users; it is simple and auditable, ideal for stable organizational structures. ABAC (Attribute-Based) decides access dynamically based on attributes of the user, the resource and the context; it offers greater granularity but increases administration complexity. PBAC (Policy-Based) is the most expressive approach, where declarative policies combine action, resource and conditions in versionable documents, capable of emulating both RBAC and ABAC.

What is the blast radius and how does least privilege reduce it?

The blast radius is the extent of the damage a compromised identity can cause. By applying least privilege - granting only the permissions needed for the specific task - the blast radius of any credential is contained to the operational minimum, limiting the impact of phishing, token theft or insider threat.

When should I use a role instead of static credentials?

Whenever possible. Static credentials are the primary target for leaks in repositories and logs. Roles assumed via STS (AWS), Workload Identity Federation (GCP) or Managed Identity (Azure) issue short-lived tokens - usually 1 hour - that expire automatically, eliminating the need for manual rotation.

What is CIEM and why do mature companies adopt it?

CIEM (Cloud Infrastructure Entitlement Management) is a category of tools that continuously analyzes all permissions granted in cloud environments and identifies deviations from least privilege: roles never used, permissions assigned but not exercised in the last 90 days, privilege escalation paths and configurations that violate internal policies or frameworks such as CIS. Mature companies adopt CIEM because the volume of permissions in multi-cloud environments makes manual review infeasible.

What are the most common IAM mistakes that lead to real incidents?

The five most frequent mistakes are: using the root account for day-to-day tasks; access keys hardcoded in versioned source code; roles with wildcard permissions in Action or Resource; absence of MFA on privileged accounts; and lack of periodic entitlement review - users who changed roles but kept their old access.

References

  • AWS. Security best practices in IAM. AWS Documentation. Available at: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
  • Microsoft. Azure role-based access control (Azure RBAC) documentation. Microsoft Learn. Available at: https://learn.microsoft.com/en-us/azure/role-based-access-control/
  • Google Cloud. IAM overview. Google Cloud Documentation. Available at: https://cloud.google.com/iam/docs/overview
  • NIST. SP 800-207: Zero Trust Architecture. National Institute of Standards and Technology, 2020.
  • NIST. SP 800-63B: Digital Identity Guidelines - Authentication and Lifecycle Management. NIST, 2017 (rev. 2022).
  • CIS. CIS Amazon Web Services Foundations Benchmark v2.0. Center for Internet Security, 2023.
  • Cloud Security Alliance. Cloud Controls Matrix v4.0. CSA, 2021.

IAM hardening with Decripte

Decripte performs IAM hardening and cloud posture review for companies of all sizes - from sole proprietors running applications in the cloud to organizations with more than 100,000 employees and multi-account environments across AWS, Azure and GCP. The process includes a complete inventory of identities, analysis of privilege escalation paths, implementation of CIEM, review of SCPs and organization policies, and delivery of a technical report with a prioritized remediation roadmap.

To start with a free cloud posture assessment or explore the continuous security management plans, visit decripte.com.br/planos or start a free assessment.