IAM Architecture at Enterprise Scale

IAM is the security foundation everything else depends on. Bad IAM means attackers who get one credential can access everything. Good IAM means a compromised credential limits blast radius to the minimum required permissions. At enterprise scale, IAM becomes its own engineering discipline — managing thousands of roles, hundreds of policies, and continuous access reviews.

Access Control Models

Model	How It Works	Best For
RBAC (Role-Based)	Users get roles, roles have permissions	Simple organizations, well-defined roles
ABAC (Attribute-Based)	Access based on attributes (department, project, time, location)	Dynamic, context-aware decisions
ReBAC (Relationship-Based)	Access based on data relationships (owner, editor, viewer)	Collaborative apps (Google Docs model)
PBAC (Policy-Based)	Policies written in code (OPA, Cedar)	Complex, auditable authorization

Cloud IAM Design

Least Privilege Pattern

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::data-bucket/team-a/*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/team": "team-a"
        },
        "IpAddress": {
          "aws:SourceIp": "10.0.0.0/8"
        }
      }
    }
  ]
}

Service Account Design

Principle	Implementation
One service account per service	Never share credentials between services
No long-lived keys	Use workload identity, IRSA, or workload federation
Least privilege	Only permissions the service actively uses
Key rotation	Automated rotation every 90 days maximum
Monitoring	Alert on unused/anomalous service account activity

Just-in-Time (JIT) Access

Developer needs production access
            │
            ▼
    ┌── Request Access ──┐
    │  Reason: "Debug     │
    │  incident INC-123"  │
    │  Duration: 2 hours  │
    │  Role: read-only    │
    └────────┬────────────┘
             │
    ┌────────▼────────────┐
    │  Approval Workflow   │
    │  Auto-approve: known │
    │  incident? Yes → ✅  │
    │  Manual approval     │
    │  otherwise → manager │
    └────────┬────────────┘
             │
    ┌────────▼────────────┐
    │  Grant Access        │
    │  Temporary role      │
    │  Session recorded    │
    │  Auto-revoke at TTL  │
    └─────────────────────┘

Federation Architecture

Identity Provider (Okta/Azure AD/Google)
              │
    SAML/OIDC │ Federation
              ▼
┌─── AWS ────────────────────────┐
│  IAM Identity Center           │
│  ├── Permission Set: Admin     │
│  ├── Permission Set: Developer │
│  └── Permission Set: ReadOnly  │
│                                │
│  Mapped to Accounts:           │
│  ├── Production (restrict)     │
│  ├── Staging (moderate)        │
│  └── Development (permissive)  │
└────────────────────────────────┘

Anti-Patterns

Anti-Pattern	Problem	Fix
Shared service accounts	Can’t attribute actions to individuals	One service account per service
Long-lived access keys	Keys leak, get committed to Git	Short-lived tokens, workload identity
Overly broad policies	`:` permissions, admin for everyone	Least privilege, regular access reviews
No access reviews	Permissions accumulate, never removed	Quarterly reviews, automated alerting
Admin accounts without MFA	Single factor = single point of compromise	Mandatory phishing-resistant MFA

Checklist

Identity provider: centralized (Okta, Azure AD, Google) with MFA
Federation: cloud accounts federated to identity provider
RBAC: roles defined with least privilege permissions
JIT access: temporary elevated access with approval workflow
Service accounts: one per service, no long-lived keys
Access reviews: quarterly review of all permissions
Break-glass: emergency access procedure documented and tested
Monitoring: unusual access patterns, dormant accounts
Offboarding: automated access removal when employees leave

:::note[Source] This guide is derived from operational intelligence at Garnet Grid Consulting. For IAM consulting, visit garnetgrid.com. :::