M7: Cloud Architecture — Threat Modeling Guide

1The Shared Responsibility Model

The most fundamental concept in cloud security. The cloud provider secures the cloud itself. You are responsible for security in the cloud — your data, your identities, your configurations.

⚠️

The #1 Cloud Breach Cause

The vast majority of cloud security breaches are customer-side misconfigurations — not vulnerabilities in the cloud provider's infrastructure. Open S3 buckets, over-privileged IAM roles, and leaked credentials are overwhelmingly common.

☁️ Cloud Provider Owns

Physical datacentre security
Network infrastructure
Hardware (servers, disks)
Hypervisor / virtualization
Managed service availability
Provider's own IAM controls

🏢 YOU Own (Your Responsibility)

Your data and encryption choices
Your IAM policies and roles
Your application code
Operating system & container config
Network/security group rules
Monitoring & incident response

Shared Responsibility — IaaS vs PaaS vs SaaS

As you move from IaaS → PaaS → SaaS, the provider takes on more responsibility — but you still own your data and identity management

2Identity & Access Management (IAM) Threats

In cloud environments, identity is the new perimeter. With IAM credentials, an attacker can do everything your application can do — without touching any of your code. IAM threats are the most critical cloud threats.

🔑

T-01 — Over-Privileged IAM Roles [STRIDE: Elevation of Privilege]

Developer attaches AdministratorAccess to an EC2 instance or Lambda function "to get it working quickly." If that resource is compromised (via SSRF, RCE, etc.), the attacker inherits full AWS admin access — they can create new users, exfiltrate all data, or destroy all infrastructure.

CriticalElevation

🛡️

Mitigations

Principle of Least Privilege — grant only the specific actions needed. Use IAM Access Analyzer to detect over-privilege. Review and tighten IAM policies before production launch. Use Service Control Policies (SCPs) in AWS Organizations as guard rails.

🔓

T-02 — Long-Lived Access Keys [STRIDE: Spoofing + Information Disclosure]

AWS access keys checked into GitHub (even briefly) are scraped by bots within seconds. Long-lived static credentials (access keys) that never expire are high-value targets. One leaked key = full account compromise if the key is over-privileged.

CriticalSpoofing

🛡️

Mitigations

Use IAM roles (temporary credentials) instead of long-lived access keys wherever possible. For EC2/Lambda: use instance profiles/execution roles. For local dev: use AWS SSO. Rotate any existing long-lived keys. Enable GuardDuty to detect anomalous credential usage.

😕

T-03 — Confused Deputy Attack [STRIDE: Elevation of Privilege]

A cloud service (the "deputy") has permissions your account doesn't. An attacker tricks the service into performing actions on your account by supplying your ARN. Classic example: S3 cross-account access where the bucket policy doesn't require the caller to specify their own account ID.

HighElevation

🛡️

Mitigations

Use aws:SourceArn and aws:SourceAccount condition keys in IAM policies for cross-service permissions. This ensures the action is initiated from the expected source.

3Object Storage Threats (S3, GCS, Azure Blob)

🪣

T-04 — Public S3 Bucket [STRIDE: Information Disclosure]

Developer creates an S3 bucket for static assets and accidentally enables public access, or sets a bucket policy with "Principal": "*". Data exposure: customer PII, database backups, environment files with secrets. Happens constantly — automated scanners find these within hours.

CriticalInfo Disclosure

# ❌ Dangerous bucket policy
{
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-company-data/*"
}

# ✅ Lock down + enable Block Public Access
aws s3api put-public-access-block \
  --bucket my-bucket \
  --public-access-block-configuration \
    "BlockPublicAcls=true,IgnorePublicAcls=true,\
     BlockPublicPolicy=true,RestrictPublicBuckets=true"

💾

T-05 — Unencrypted Backups at Rest [STRIDE: Information Disclosure]

Database snapshots or file backups stored in S3 without server-side encryption. A compromised AWS account or insider threat can download and read all data without any cryptographic barrier.

HighInfo Disclosure

🛡️

Mitigations

Enable S3 default encryption (SSE-S3 minimum, SSE-KMS for sensitive data). Enforce encryption in bucket policy using condition: "s3:x-amz-server-side-encryption": "aws:kms". Enable S3 Object Lock for immutable backups.

4Compute Threats: Containers & Serverless

Container Attack Surface

Container threats span from base image supply chain to runtime privilege to host escape

Container Threat	STRIDE	Mitigation
Running as root in container	E	Set `USER nonroot` in Dockerfile; use `runAsNonRoot: true` in Kubernetes pod spec
Container escape via privileged mode	E	Never use `--privileged`; use seccomp and AppArmor profiles; read-only filesystem
Vulnerable base image (CVEs)	T · E	Scan images with Trivy/Snyk; use minimal base images (distroless, alpine); auto-rebuild on CVE alerts
Secrets in environment variables	I	Use Kubernetes Secrets (encrypted at rest); prefer Vault sidecar injection or CSI secrets driver
Unrestricted inter-pod communication	E	Apply Kubernetes Network Policies; default-deny all ingress/egress; allow only necessary paths

⚡

Serverless Threat Model Shifts

Serverless (AWS Lambda, GCP Cloud Functions) eliminates OS and server management threats — but introduces new ones unique to the execution model: short-lived functions, event-driven inputs, and per-function IAM roles.

Serverless Threat	STRIDE	Mitigation
Event injection — malicious data in triggering event (SNS message, S3 key, API GW body) processed as trusted input	T	Validate and sanitize all event sources, even "internal" ones. Treat every event as untrusted input.
Over-privileged Lambda execution role — function has `s3:` and `dynamodb:` but only needs one table	E	Scope IAM policies to specific resources (not wildcards). One function = one minimal role.
Function timeout exhaustion (billable DoS) — attacker triggers expensive functions	D	Rate limiting at API Gateway; concurrency limits per function; cost anomaly detection alerts
Dependency confusion / supply chain — malicious npm/PyPI package in function's dependencies	T	Pin dependency versions; scan with Snyk; use private npm registry; sign and verify artifacts
Secrets in environment variables — Lambda env vars visible to anyone with `lambda:GetFunctionConfiguration`	I	Store secrets in AWS Secrets Manager or SSM Parameter Store; fetch at runtime with limited IAM

5Full Cloud Architecture DFD

Let's model a typical cloud-native deployment — serverless API + managed database + CDN + CI/CD:

Cloud-Native Architecture — Threat Model View

Cloud-native architecture with key threat injection points highlighted — CI/CD compromise, storage misconfiguration, and WAF bypass are the top concerns

6CI/CD Pipeline & Supply Chain Threats

The build pipeline is one of the highest-value attack targets. Compromise the CI/CD system and you can ship malicious code to production with valid signatures from a trusted process.

1

Source Code Compromise

Attacker commits malicious code via stolen developer credentials, a compromised GitHub account, or a malicious pull request merged without review.

2

Dependency Confusion / Typosquatting

Attacker publishes a malicious package to npm/PyPI with the same name as an internal package or a common typo (lodahs vs lodash). Package manager resolves to the public malicious version.

3

Build System Compromise

GitHub Actions workflow has write access to production. Compromised runner or malicious action injects backdoor into the build artifact before it's signed and deployed.

4

Secrets Leakage in Logs

Build logs printed to public GitHub Actions logs contain API keys, database URLs, or access tokens — visible to anyone with read access to the repo.

🛡️

Supply Chain Security Controls

Pin dependency versions AND verify checksums (use package-lock.json or poetry.lock)
Use GitHub's OIDC for CI/CD credentials — no long-lived secrets in environment
Sign container images and verify signatures before deploy (cosign/Sigstore)
Require 2-reviewer approval on all merges to main
Scan dependencies on every commit (Dependabot, Snyk, Socket)
Use SLSA framework (Supply chain Levels for Software Artifacts) as a maturity model

7Knowledge Check

✏️ Exercise 7.1

Cloud SSRF Impact

Your Lambda function has an "import data from URL" feature. An attacker sends the URL http://169.254.169.254/latest/meta-data/iam/security-credentials/. The Lambda fetches it. What is the worst-case impact?

8Module Summary

✅

Key Takeaways

Shared Responsibility: the cloud provider secures the cloud; you secure what's in it — your data, IAM, and configs
IAM = the new perimeter: over-privileged roles and leaked credentials are the top cloud breach vectors
Object storage: default to private; enable Block Public Access; encrypt everything
Containers: run as non-root; scan images; never use privileged mode; apply network policies
Serverless: treat all event inputs as untrusted; one minimal IAM role per function; fetch secrets at runtime
CI/CD: the pipeline is an attack target — protect it like production; pin and scan dependencies

Cloud Architecture Threat Modeling

🎯 Learning Objectives

1The Shared Responsibility Model

☁️ Cloud Provider Owns

🏢 YOU Own (Your Responsibility)

2Identity & Access Management (IAM) Threats

3Object Storage Threats (S3, GCS, Azure Blob)

4Compute Threats: Containers & Serverless

5Full Cloud Architecture DFD

6CI/CD Pipeline & Supply Chain Threats

7Knowledge Check

8Module Summary