Scenario Advanced Aws AWS Governance

Design an IAM Strategy for a 500-Engineer Organization With SOC2 & PCI-DSS Compliance

Build an enterprise IAM framework covering multi-account structure, SSO federation, permission boundaries, break-glass access, and SCPs for SOC2 and PCI-DSS compliance.

January 20, 2025 5 min read ~40 min to complete DB
awsiamgovernancesoc2pci-dssorganizationsssoidentity-centercompliance
The Situation

You've just joined as Principal Cloud Security Architect. The company has 500 engineers, 20 AWS accounts, and an audit in 3 months. Current state: everyone shares admin credentials in a spreadsheet. The CISO hands you a mandate: SOC2 Type II and PCI-DSS compliant IAM by the audit date. Where do you start?

6 Steps
6 Services Used
~40 min Duration
Advanced Difficulty

The Problem

Shared admin credentials violate the most fundamental security principle: least privilege. With shared credentials, you can’t answer “who did what” in an audit (no attribution), you can’t revoke access for one person without affecting everyone, and any breach gives attackers full admin rights across all accounts.

Current Risk
  • Shared admin credentials → No audit trail attribution (instant SOC2 fail)
  • No MFA enforcement → Any credential leak = full account compromise
  • Single AWS account → No blast radius isolation between prod and dev
  • No access reviews → Engineers who left the company still have access

Step 1: Multi-Account Structure via AWS Organizations

Separate accounts create security boundaries — a compromised dev account can’t touch production:

Management Account (billing & organizational control only)
├── Security OU
│   ├── Log Archive Account     ← CloudTrail, Config, VPC Flow Logs (write-once)
│   └── Security Tooling Account ← GuardDuty, Security Hub, Macie
├── Infrastructure OU
│   ├── Network Account         ← Transit Gateway, VPCs, DNS
│   └── Shared Services Account ← ECR, artifact repos, internal tools
├── Production OU  (strictest SCPs)
│   ├── Prod-App-1 Account
│   └── Prod-App-2 Account
├── Non-Production OU  (relaxed SCPs)
│   ├── Dev Account
│   └── Staging Account
└── Sandbox OU  (open — time-limited)
    └── Engineer Sandbox Accounts (auto-expire 30 days)

The Management Account is billing and organizational control only — no workloads, minimal permissions, hardware MFA required.

Step 2: SSO Federation — Eliminate Long-Lived Credentials

AWS IAM Identity Center (formerly SSO) connects your Identity Provider (Okta, Azure AD, Google Workspace) to AWS accounts. Engineers get short-lived tokens, never long-lived keys.

# Enable IAM Identity Center
aws sso-admin create-instance

# Connect your IdP (example: Okta SAML)
aws sso-admin create-trusted-token-issuer \
  --instance-arn arn:aws:sso:::instance/... \
  --name "Okta" \
  --trusted-token-issuer-type OIDC_JWT \
  --trusted-token-issuer-configuration '{
    "OidcJwtConfiguration": {
      "IssuerUrl": "https://your-company.okta.com",
      "ClaimAttributePath": "sub",
      "IdentityStoreAttributePath": "userName"
    }
  }'

Result:

  • Engineers log into AWS via their company SSO (no passwords stored in AWS)
  • Session tokens expire after 1-8 hours depending on role sensitivity
  • Offboarding is instant — disable in Okta, access revoked everywhere in AWS

Step 3: Role Structure With Permission Boundaries

Define roles by job function + least privilege. Use permission boundaries to cap what any role can do even if misconfigured:

RoleAccess LevelMFA RequiredMax SessionAccount Scope
ReadOnlyCloudWatch, S3 (read)No8 hoursAll accounts
DeveloperDeploy to non-prod onlyYes4 hoursDev/Staging
DBARDS management (no delete)Yes2 hoursPer-app accounts
OpsEC2, ECS managementYes4 hoursProd accounts
AdminAll (within boundary)Yes1 hourSpecific account
BreakGlassFull adminHardware MFA1 hourAny account

Permission boundary example — even the Admin role can’t exceed this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:DeleteUser",
        "organizations:*",
        "account:*"
      ],
      "Resource": "*"
    }
  ]
}

Attach the boundary to every role created by developers:

aws iam create-role \
  --role-name developer-created-role \
  --assume-role-policy-document file://trust-policy.json \
  --permissions-boundary arn:aws:iam::123456789012:policy/EngineerPermissionBoundary

Step 4: SCPs for Compliance Guardrails

SCPs apply to all accounts in an OU regardless of local IAM policies — they’re the ultimate safety net:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonCompliantRegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["us-east-1", "us-west-2"]
        },
        "ArnNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/OrganizationAccountAccessRole"
        }
      }
    },
    {
      "Sid": "DenyRootAccountUsage",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalType": "Root"
        }
      }
    },
    {
      "Sid": "RequireMFAForSensitiveActions",
      "Effect": "Deny",
      "Action": [
        "iam:DeleteRolePolicy",
        "iam:DeletePolicy",
        "ec2:DeleteVpc",
        "s3:DeleteBucket"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}
      }
    },
    {
      "Sid": "DenyDisablingCloudTrail",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "cloudtrail:UpdateTrail"
      ],
      "Resource": "*"
    }
  ]
}

Step 5: Break-Glass Access

Even with SSO, you need emergency admin access when SSO is unavailable (AWS outage, IdP outage):

# Create break-glass role — hardware MFA required
aws iam create-role \
  --role-name BreakGlassAdmin \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Service": "ec2.amazonaws.com"},
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {"aws:MultiFactorAuthPresent": "true"},
        "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"}
      }
    }]
  }'

# CloudTrail alarm — alert if break-glass is used
aws cloudwatch put-metric-alarm \
  --alarm-name "BreakGlassAccessUsed" \
  --metric-name "BreakGlassAccessCount" \
  --namespace "SecurityMetrics" \
  --statistic Sum \
  --period 300 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:...:security-critical

Store break-glass credentials in a physical safe. Usage is automatically alerted to the CISO.

Step 6: Quarterly Access Reviews With IAM Access Analyzer

# Enable Access Analyzer to find over-permissive policies
aws accessanalyzer create-analyzer \
  --analyzer-name prod-access-analyzer \
  --type ORGANIZATION \
  --archive-rules '[{
    "ruleName": "allow-known-cross-account",
    "filter": {
      "principal.AWS": {
        "contains": ["arn:aws:iam::123456789012:role/allowed-role"]
      }
    }
  }]'

# Generate IAM credentials report for quarterly review
aws iam generate-credential-report
aws iam get-credential-report | \
  python3 -c "import sys,json,base64; data=json.load(sys.stdin); print(base64.b64decode(data['Content']).decode())"

Schedule quarterly access reviews in Jira/ServiceNow: each team manager reviews and certifies their engineers’ permissions. Revoke any uncertified access automatically.

Audit Checklist (SOC2 + PCI-DSS)

ControlImplementationEvidence
No shared credentialsIAM Identity Center SSOCloudTrail shows individual attribution
MFA enforcedSCP denies sensitive actions without MFAAWS Config conformance pack
Least privilegePermission boundaries + quarterly reviewIAM Access Analyzer reports
Audit trailCloudTrail in Log Archive (write-once)CloudTrail log integrity validation
No root usageSCP denies root; alert on any root usageCloudWatch metric filter + SNS
Access revocation < 24hOkta deprovisioning → SSO syncSCIM provisioning logs
Interview Angle
Compliance auditors ask three questions: Can you tell me who made a change? Can you prove they were authorized? Can you prove access is promptly revoked when someone leaves? Your IAM strategy must answer all three with evidence — not just policy documents, but CloudTrail logs, IAM reports, and automated revocation proof.
Services Used
AWS OrganizationsIAM Identity Center (SSO)Service Control PoliciesIAM Access AnalyzerCloudTrailAWS Config
Prerequisites
  • Understanding of AWS Organizations and multi-account structure
  • Familiarity with IAM roles, policies, and permission boundaries
What You Learned
  • How to design a multi-account OU structure for compliance
  • Why SSO federation eliminates long-lived credential risk
  • How permission boundaries contain over-privileged roles
  • The role-based access model for a 500-engineer org
  • How SCPs enforce compliance guardrails across all accounts

Have a similar scenario to share?

Production incidents are the best teachers. Submit your real-world scenario and help others learn.

Open Google Form

Related Scenarios

Learning Paths beginner

AWS Cloud Engineer Learning Path

Who Is This Path For? This path is designed for complete beginners who want to break into cloud computing as an AWS engineer. If you know …

Jan 20, 2025 Read more