Cloud IAM Security Best Practices: AWS, Azure, and GCP
Cloud Identity and Access Management is where the majority of cloud security incidents originate. Unlike traditional network security where perimeter controls provided broad protection, cloud security is fundamentally identity-first: every action in AWS, Azure, or GCP is an API call authenticated by an identity and authorized by an IAM policy. Overprivileged identities, misconfigured trust relationships, and poorly secured service accounts create the attack paths that adversaries exploit after initial access. This guide covers cloud IAM hardening practices across AWS, Azure, and GCP.
The Least Privilege Problem in Cloud IAM
Least privilege is universally endorsed and universally violated in cloud environments. The cause is not malice but the complexity of cloud IAM.
AWS IAM complexity
AWS has over 2,500 individual IAM actions across 300+ services. Writing a least-privilege IAM policy that grants exactly the permissions a workload needs — no more — requires understanding which API calls the workload makes and constructing policies at the action level rather than using managed policies. AWS managed policies like AdministratorAccess and PowerUserAccess are operationally convenient and significantly over-permissioned.
The arn:aws:iam::*:policy/AdministratorAccess problem
AWS's AdministratorAccess managed policy grants full access to all AWS services and resources — it is equivalent to root for IAM principals. It is routinely attached to CI/CD service accounts, developer IAM users, and application roles for convenience. An attacker who compromises any principal with AdministratorAccess has full account control.
Wildcard action policies
Policies using Action: '*' (all actions) or Action: 's3:*' (all S3 actions) are over-permissioned relative to actual need. Wildcards are the path of least resistance during development and rarely get tightened after the workload is running.
Cloud infrastructure entitlement management (CIEM)
CIEM tools (Wiz, Ermetic/Tenable, Sonrai Security) analyze cloud IAM configurations to identify over-permissioned identities, unused permissions, and privilege escalation paths. CIEM provides the visibility layer needed to systematically reduce cloud IAM permissions at scale — a task too complex to do manually across large cloud estates.
AWS IAM Hardening
AWS IAM hardening focuses on eliminating root account usage, removing permanent IAM users, and implementing workload-specific least-privilege roles.
Root account protection
The AWS root account has unrestricted access to all services and cannot be restricted by IAM policies. Never use root for routine operations. Enable hardware MFA on root. Generate and immediately delete root access keys. Use root only for account-level tasks that cannot be done by other means (changing support plan, enabling specific services). Root access should be audited via CloudTrail.
Eliminate IAM users, use SSO
IAM users with access keys are a persistent credential risk — long-lived keys that can be exfiltrated and used indefinitely. Replace IAM users with AWS IAM Identity Center (SSO) for human access. Humans authenticate to SSO with corporate IdP credentials (SAML federation), receive short-lived temporary credentials, and have no long-lived access keys. Eliminate all IAM users with long-lived access keys where SSO is feasible.
OIDC for CI/CD pipelines
CI/CD pipelines (GitHub Actions, GitLab CI, CircleCI) traditionally use IAM access keys stored as secrets. OIDC federation eliminates access keys: the CI/CD platform presents an OIDC token to AWS, which issues short-lived credentials scoped to the specific pipeline and role. No long-lived credentials stored in the pipeline configuration.
Permission boundaries
Permission boundaries are IAM policies attached to IAM entities that define the maximum permissions the entity can have, regardless of what permission policies are attached. Use permission boundaries on IAM roles created by automation or developers to prevent privilege escalation via role creation — a developer can create a role, but only with permissions within the defined boundary.
Service Control Policies (SCPs)
SCPs applied at the AWS Organizations level define guardrails that restrict what any IAM principal in the account can do — even the account root. Common SCPs: prevent disabling CloudTrail, prevent leaving the organization, require IMDSv2 for all EC2 instances, prevent creating IAM users with long-lived credentials. SCPs are the most scalable IAM control for multi-account environments.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Azure RBAC Hardening
Azure access control uses Role-Based Access Control (RBAC) at the management plane and resource policies for data plane access. Azure Entra ID provides the identity layer.
Limit Owner and Contributor assignments
Owner role provides full management control of a resource including the ability to grant access to others. Contributor provides full resource management without access control. Both are frequently over-assigned. Audit all Owner and Contributor role assignments at the subscription and resource group level; replace with more specific built-in roles or custom roles.
Custom roles over broad built-in roles
Azure's built-in roles are convenient but often too broad. A security analyst who needs to read security alerts does not need the Security Admin role (which can also modify security policies). Create custom roles scoped to specific actions and resources required.
Managed identities over service principals with secrets
Service principals with client secrets are long-lived credentials that must be rotated and can be stolen. Managed identities (system-assigned or user-assigned) provide Azure-managed credentials that rotate automatically and are tied to the resource — no credentials to store or manage. Use managed identities for all Azure resource-to-resource authentication where possible.
Privileged Identity Management (PIM) for Azure roles
Entra ID PIM provides JIT elevation for Azure RBAC roles alongside Entra ID directory roles. Eligible role assignments allow administrators to activate the Owner or Contributor role for a time-bounded window with approval and justification, rather than having standing assignment.
Deny assignments
Azure deny assignments block specified principals from performing specific actions, even if a role assignment allows it. Deny assignments take precedence over role assignments and cannot be overridden except by the deny assignment creator. Use deny assignments to protect critical resources from modification even by subscription Owners.
GCP IAM Hardening
GCP IAM uses a hierarchical model (Organization, Folder, Project, Resource) where permissions can be inherited down the hierarchy. The principle of least privilege is harder to enforce when broad project-level roles cascade to all resources within a project.
Avoid primitive roles
GCP's primitive roles (Owner, Editor, Viewer) predate the modern IAM system and are coarse-grained. Owner grants full control including IAM management; Editor grants full resource modification. Replace primitive role assignments with predefined service-specific roles or custom roles. Never grant Editor at the project level to service accounts.
Workload Identity Federation for external workloads
Like AWS OIDC, GCP Workload Identity Federation allows external workloads (GitHub Actions, on-premises applications) to authenticate to GCP using short-lived OIDC tokens instead of service account keys. Service account keys are long-lived credentials with all associated risks; Workload Identity eliminates them.
Service account key management
When service account keys cannot be eliminated, enforce: key rotation every 90 days, download monitoring via Cloud Audit Logs (CreateServiceAccountKey events), and minimum-scope key permissions. Audit for service account keys that have not been used in 90+ days — dormant keys represent unmonitored attack surface.
Organization policies
GCP Organization Policies (like AWS SCPs) define constraints that apply across the organization regardless of individual project IAM. Common policies: restrict service account key creation, disable public IP on compute instances, require OS Login for SSH access, restrict which regions resources can be created in.
Cross-Account and Cross-Cloud Access Security
Cross-account access patterns are common sources of privilege escalation and lateral movement in cloud environments.
AWS cross-account role assumption
Cross-account access uses sts:AssumeRole to access resources in another AWS account. The trust policy on the target role defines who can assume it. Overly permissive trust policies (allowing assumption by any principal in a trusted account) are privilege escalation vectors. Trust policies should specify the exact IAM ARN (not wildcard principal) and require ExternalId for third-party access.
Confused deputy prevention
The confused deputy problem occurs when a service with privileges is tricked into performing actions on behalf of a less-privileged caller. In AWS: use the aws:SourceAccount and aws:SourceArn condition keys in trust policies to prevent a service in Account A from assuming a role intended only for actions originating from Account B's specific workload.
External ID for third-party access
When granting cross-account access to third-party vendors (security tools, SaaS integrations), require an ExternalId condition in the trust policy. The ExternalId is a shared secret between your organization and the vendor that prevents other customers of the same vendor from assuming your role.
Detecting IAM Misconfigurations and Privilege Escalation Paths
IAM misconfigurations accumulate over time and require continuous detection, not just point-in-time assessment.
AWS IAM Access Analyzer
Native AWS tool that identifies resources accessible from outside the account (S3 buckets, KMS keys, IAM roles with external trust policies). Also generates least-privilege policy recommendations based on CloudTrail access history. Free, always-on, and integrated with Security Hub.
Privilege escalation path detection
Tools like PMapper (AWS) and Stormspotter (Azure) model IAM configurations as graphs and identify privilege escalation paths — combinations of permissions that together allow a lower-privileged principal to obtain higher privileges. Example: a principal with iam:PassRole + ec2:RunInstances can escalate to any role it can pass. These paths are invisible without graph-based analysis.
CIEM platforms
Wiz, Ermetic (Tenable), Sonrai Security, and Orca Security provide continuous CIEM across multi-cloud environments. They identify over-permissioned identities, unused permissions, privilege escalation paths, and cross-account access risks with remediation guidance. Essential for organizations with large cloud IAM estates that cannot be managed manually.
The bottom line
Cloud IAM security requires moving from the convenience-driven default of broad managed policies and long-lived credentials toward least-privilege custom roles, short-lived federated credentials, and continuous misconfiguration monitoring. The specific mechanisms differ between AWS, Azure, and GCP, but the principles are consistent: eliminate root/super-admin standing access, replace long-lived credentials with short-lived federation, scope permissions to what workloads actually need, and use organization-level policy guardrails to prevent misconfiguration from propagating.
Frequently asked questions
What is the most common cloud IAM misconfiguration?
Over-permissioned service accounts and IAM roles are the most common misconfiguration. This typically manifests as CI/CD pipelines or application workloads running with Administrator/Owner/Editor-equivalent permissions when read-only or narrowly scoped permissions would suffice. AWS AdministratorAccess, Azure Contributor, and GCP Editor attached to non-human identities are the most impactful permissions to audit and reduce.
Why should IAM users with access keys be eliminated?
IAM users with long-lived access keys are persistent credentials that accumulate risk over time: keys may be hardcoded in code repositories, leaked in configuration files, exfiltrated through compromised developer workstations, or simply never rotated. Short-lived credentials from AWS IAM Identity Center (SSO), Azure Managed Identities, GCP Workload Identity Federation, or OIDC federation expire automatically and cannot be used after expiration — limiting the window of exposure from any credential compromise.
What is a privilege escalation path in cloud IAM?
A privilege escalation path is a combination of permissions that together allow a principal to obtain higher privileges than they were explicitly granted. Example in AWS: a principal with iam:PassRole and ec2:RunInstances can launch an EC2 instance with a more privileged IAM role attached, then access the instance metadata to retrieve that role's credentials — effectively inheriting the more privileged role's permissions. These paths are not obvious from reading individual permissions but are discoverable with graph-based IAM analysis tools.
What are Service Control Policies (SCPs) in AWS?
SCPs are organization-level IAM policies that set maximum permission guardrails for all principals in an AWS account or organizational unit, including the account root. SCPs cannot grant permissions (they only restrict); any action denied by an SCP cannot be performed regardless of what IAM policies allow. Common SCPs: prevent disabling CloudTrail, prevent root account API calls, require MFA for specific actions, prevent creating long-lived IAM user credentials. SCPs are the most scalable preventive control for multi-account AWS environments.
What is the difference between Azure RBAC and Entra ID roles?
Azure RBAC controls access to Azure resources (virtual machines, storage accounts, databases) and is assigned at management scopes (Management Group, Subscription, Resource Group, Resource). Entra ID (formerly Azure AD) roles control access to Entra ID itself and Microsoft 365 services (Global Administrator, Security Administrator, Exchange Administrator). Both are needed for comprehensive access control: Entra ID roles for identity management and M365; Azure RBAC for infrastructure and platform resources. PIM supports JIT elevation for both role types.
What is CIEM and why is it needed?
Cloud Infrastructure Entitlement Management (CIEM) is a category of tools that analyze and manage cloud IAM configurations at scale. CIEM platforms discover all cloud identities (human users, service accounts, roles, managed identities) across multi-cloud environments, calculate their effective permissions, identify over-permissioning and unused permissions, map privilege escalation paths, and generate remediation recommendations. CIEM is needed because manual IAM analysis does not scale — large cloud environments have thousands of identities with complex permission combinations that cannot be assessed without automated tooling.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.