Chapter 3 — Identity & Access Management (IAM)

PART II — IDENTITY, NETWORK, AND DATA SECURITY

3.1 Identity as the Control Plane

In cloud security, identity serves as the fundamental control plane that governs all access and operations. Unlike traditional network-centric security models, cloud environments treat every interaction—whether human or machine—as an identity-based transaction.

Identity Domains

Human Identities

• Employees, contractors, and temporary workers
• External partners and vendors
• Customer support personnel
• Security and compliance teams

Service Identities

• Application workloads and microservices
• Serverless functions and containers
• Infrastructure components (load balancers, databases)
• Automated processes and CI/CD pipelines

Machine Identities

• Service accounts and API keys
• Virtual machines and containers
• IoT devices and edge computing nodes
• Bot and automation accounts

The Identity-First Security Model

In an identity-first architecture:

1. All access decisions start with authentication
2. Authorization is context-aware and adaptive
3. Every action is attributable to an identity
4. Identity governance is continuous and automated

If identity controls fail, all other security controls become ineffective. An attacker who compromises privileged identities can bypass network controls, disable security tools, and exfiltrate data regardless of other protections in place.

Visualizing the Identity Flow:

graph TD
  %% Classes
  classDef user fill:#f3f4f6,stroke:#374151,stroke-width:2px,color:#1f2937,font-weight:bold
  classDef auth fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e40af
  classDef policy fill:#d1fae5,stroke:#059669,stroke-width:2px,color:#065f46
  classDef resource fill:#fce7f3,stroke:#db2777,stroke-width:2px,color:#9d174d

  User((User / System)):::user

  subgraph AuthN [Authentication]
    direction TB
    IdP[Identity Provider]:::auth
    MFA[MFA Challenge]:::auth
  end

  subgraph AuthZ [Authorization]
    direction TB
    PolicyEng[Policy Engine]:::policy
    Role[RBAC / ABAC]:::policy
  end

  Resource[Target Resource]:::resource

  User -->|1. Credentials| IdP
  IdP -->|2. Validates| MFA
  MFA -->|3. Auth Token| PolicyEng
  PolicyEng -->|4. Evaluates| Role
  Role -->|5. Allow/Deny| Resource

  %% Styling
  style AuthN fill:#1f293b,stroke:#475569,stroke-dasharray: 5 5,rx:5,ry:5
  style AuthZ fill:#1f293b,stroke:#475569,stroke-dasharray: 5 5,rx:5,ry:5

3.2 Centralized Identity Architecture

Recommended Identity Stack

Layer	AWS Example	Azure Example	GCP Example
Identity Provider	AWS SSO + Okta/Azure AD	Azure AD	Google Workspace + Cloud Identity
Authentication	SAML 2.0, OIDC	SAML 2.0, OIDC	SAML 2.0, OIDC
Cloud Access	AWS IAM Identity Center	Azure AD B2B	GCP Cloud IAM
MFA	Authenticator apps, hardware keys	Authenticator apps, hardware keys	Authenticator apps, hardware keys
Directory Services	AWS Managed Microsoft AD	Azure AD DS	Google Cloud Directory

Core Architecture Principles

Single Source of Truth

• Use one enterprise identity provider as the authoritative source
• Synchronize user attributes, groups, and roles automatically
• Maintain consistent identity lifecycle management

Federated Authentication

• Eliminate local cloud accounts whenever possible
• Use SAML or OpenID Connect for web-based access
• Implement OAuth 2.0 for API and service-to-service authentication

Multi-Factor Authentication Everywhere

• Require MFA for all human access
• Implement hardware-based MFA for privileged accounts
• Use certificate-based authentication for service accounts

Just-in-Time Provisioning

• Auto-provision access based on HR system changes
• Implement automatic deprovisioning for terminated employees
• Use role-based provisioning for contractor access

Implementation Patterns

Pattern 1: Enterprise Federation

# Example AWS SSO Configuration
IdentitySource:
  Type: "EXTERNAL_IDP"
  ExternalIdp:
    SamlMetadataUrl: "https://okta.com/app/exk123/metadata"
    Attributes:
      Name: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
      Email: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
      Groups: "http://schemas.xmlsoap.org/claims/Group"

Pattern 2: Service Identity Management

{
  "service_identity": {
    "name": "payment-processor",
    "type": "service-account",
    "authentication": "mTLS",
    "authorization": "OAuth2 scopes",
    "rotation_policy": "90_days",
    "access_control": "least_privilege"
  }
}

3.3 Least Privilege in Practice

Role-Based Access Control (RBAC) Implementation

Tiered Role Structure

Role	Permissions	Use Case	Duration
ReadOnly	View resources only	Auditors, new hires	Permanent
Developer	Deploy to non-prod	Software engineers	Project-based
Operator	Production operations	SRE, DevOps	Just-in-time
Administrator	Full administrative	Security team	Emergency only

Permission Boundary Design

{
  "PermissionBoundary": {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Deny",
        "Action": [
          "iam:*User*",
          "iam:*Role*",
          "iam:*Group*"
        ],
        "Resource": "*"
      },
      {
        "Effect": "Allow",
        "Action": [
          "s3:GetObject",
          "s3:PutObject"
        ],
        "Resource": "arn:aws:s3:::app-data-${environment}/*",
        "Condition": {
          "StringEquals": {
            "aws:RequestedRegion": ["us-east-1", "us-west-2"]
          }
        }
      }
    ]
  }
}

Just-in-Time (JIT) Access

Access Request Workflow

1. Request - User requests temporary elevated access
2. Approval - Manager or automated approval based on policy
3. Grant - Time-limited permissions are automatically assigned
4. Audit - All actions are logged and reviewed
5. Revoke - Permissions are automatically revoked after timeout

JIT Implementation Example

def grant_jit_access(user_id, role_name, duration_hours, justification):
    """Grant just-in-time access with automatic expiration"""

    # Validate request
    if not validate_access_request(user_id, role_name):
        raise ValueError("Access request denied")

    # Create temporary role assumption
    temporary_creds = sts_client.assume_role(
        RoleArn=f"arn:aws:iam::{account_id}:role/{role_name}",
        RoleSessionName=f"jit-{user_id}-{int(time.time())}",
        DurationSeconds=duration_hours * 3600,
        Policy=json.dumps({
            "Version": "2012-10-17",
            "Statement": [{
                "Effect": "Allow",
                "Action": ["*"],
                "Resource": "*",
                "Condition": {
                    "DateLessThan": {
                        "aws:CurrentTime":
                        f"{datetime.now() + timedelta(hours=duration_hours)}"
                    }
                }
            }]
        })
    )

    # Log the access grant
    audit_log.info(
        "JIT access granted",
        user=user_id,
        role=role_name,
        duration=duration_hours,
        justification=justification,
        session_id=temporary_creds['Credentials']['SessionToken'][:16]
    )

    return temporary_creds

Automated Permission Reviews

Continuous Access Certification

# Automated review schedule
AccessReviewSchedule:
  Frequency: "quarterly"
  Scope: "all_iam_entities"
  Rules:
    - name: "unused_access_check"
      condition: "last_used > 90_days"
      action: "flag_for_review"

    - name: "over_privileged_check"
      condition: "permission_count > required_baseline"
      action: "recommend_restriction"

    - name: "orphaned_service_account_check"
      condition: "last_used > 30_days AND no_attached_resources"
      action: "schedule_deletion"

3.4 Break-Glass Accounts

Emergency Access Design

Account Characteristics

• Air-gapped storage: Credentials stored offline (hardware security modules, sealed envelopes)
• Multi-person approval: Requires consensus from multiple designated approvers
• Comprehensive logging: All actions captured in immutable audit trails
• Automatic rotation: Credentials must be rotated after each use
• Limited scope: Minimal necessary permissions for emergency operations

Implementation Framework

Storage Architecture

BreakGlassStorage:
  Primary:
    Type: "Hardware Security Module"
    Location: "Physical safe, dual custody"
    Access: "Biometric + smart card required"

  Backup:
    Type: "Paper envelopes in bank vault"
    Contents: "Encrypted private keys"
    Access: "Two corporate officers required"

  Digital:
    Type: "Split-key encryption"
    Storage: "Multiple cloud providers"
    Recovery: "M-of-N shamir secret sharing"

Activation Protocol

1. Declaration - Emergency declared by designated authority
2. Verification - Multiple independent verifications required
3. Access - Credentials retrieved and documented
4. Operation - Emergency actions performed
5. Documentation - All actions recorded with timestamps
6. Rotation - New credentials generated immediately after use
7. Review - Post-incident analysis within 24 hours

Usage Scenarios

Appropriate Use Cases

• Complete loss of administrative access
• Widespread account compromise
• Critical security incident requiring immediate response
• Disaster recovery scenarios

Prohibited Use Cases

• Routine administrative tasks
• Convenience shortcuts
• Testing or development activities
• Avoiding proper approval processes