Cloud IAM Design Best Practices: Comparing AWS, Azure, and GCP

Why Cloud IAM Matters

According to Gartner, by 2025, 99% of cloud security incidents will result from customer mistakes, and 75% of those will be due to excessive permissions.

AWS IAM Best Practices

Least-Privilege Policies

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::my-specific-bucket",
        "arn:aws:s3:::my-specific-bucket/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "ap-northeast-2"
        }
      }
    }
  ]
}

EC2 Role-Based Access

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "ec2.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

Never hardcode Access Keys or Secret Keys in source code or environment variables.

Azure AD Conditional Access Policies

{
  "displayName": "Require MFA for Admins",
  "state": "enabled",
  "conditions": {
    "users": {
      "includeRoles": ["GlobalAdministrator"]
    }
  },
  "grantControls": {
    "operator": "AND",
    "builtInControls": ["mfa", "compliantDevice"]
  }
}

PIM (Privileged Identity Management): Instead of standing administrator privileges, activate access only when it is needed, and only for a limited time.

GCP IAM — Resource Hierarchy

Organization
  └── Folder (per department)
        └── Project (per service)
              └── Resource

# 임시 권한 부여 (만료 조건 포함)
gcloud projects add-iam-policy-binding my-project \
  --member="user:dev@company.com" \
  --role="roles/viewer" \
  --condition='expression=request.time < timestamp("2025-12-31T00:00:00Z"),title=Temp'

Shared Best-Practices Checklist

□ MFA required on root / global administrator accounts
□ Use roles for service accounts
□ Review permissions regularly (at least quarterly)
□ Enable CloudTrail / Activity Log
□ Alert on anomalous permission use
□ Prefer temporary credentials (STS / short-lived tokens)

Cloud IAM is not a one-time setup. You have to keep reviewing and pruning it as the organization changes and new services come online.

Automation to Stop Permission Creep

With IAM, ongoing cleanup is harder than the initial setup. Use tooling to manage permission creep.

Multi-Account and Organization Governance

Once accounts multiply, per-account IAM is no longer enough to stay in control.

• AWS Organizations + SCP: Enforce organization-wide guardrails such as “this region or service is forbidden entirely.”
• Federation / SSO: Instead of proliferating IAM users, centralize identity through an IdP (OIDC/SAML). Handle onboarding and offboarding in one place.
• Temporary credentials: Eliminate long-lived Access Keys and replace them with STS/OIDC short-lived tokens (removing key-leak risk).

FAQ

Q. How do I get started with least privilege? You will not get it perfect on day one. Do not start wide. A realistic approach is to tighten policies based on logs of permissions that were actually used, using Access Analyzer.

Q. Should I create an IAM user for every person? Not recommended. Manage identity centrally via SSO/federation with an IdP, and map people to roles in the cloud. That is better for both security and operations.