Skip to main content

Case Study Walkthrough: Secure Multi-Cloud SaaS

Premium

Multi-cloud SaaS security case studies test your ability to design secure, compliant, and scalable architectures across heterogeneous environments.

This walkthrough applies the 7-Step Framework (see How to Tackle Take-home Case Studies lesson) and integrates SALT and STRIDE to help you build and communicate a professional-grade response suitable for take-home or live interview scenarios.

Case prompt

“Design a secure architecture for a multi-cloud SaaS platform that stores customer data and supports global users. The company hosts services in AWS and GCP, uses a shared authentication system, and must comply with GDPR and SOC 2.”

This type of case tests your ability to reason through:

  • Identity federation and cross-cloud access control.
  • Data protection and compliance.
  • Detection, automation, and operational visibility.

Step 1: Understand the scenario

The company provides a multi-tenant SaaS product offering analytics and dashboards.

  • Customers upload data through APIs or web UI.
  • Data is processed in both AWS and GCP regions.
  • Teams include developers, SREs, and data analysts with varying permissions.
  • Compliance requirements mandate data residency, auditability, and incident response readiness.

Step 2: Define assumptions

Clarify boundaries to keep the case manageable:

  • AWS handles frontend and application workloads.
  • GCP manages storage and analytics pipelines.
  • All services communicate over secure APIs.
  • Customers’ data must stay within their regional jurisdiction (e.g., EU vs. US).
  • Company uses a centralized IdP (Okta or Azure AD) for employees and service accounts.

Step 3: Identify assets

List assets to protect across environments:

  • Customer data (PII, analytics results).
  • API keys, service accounts, and tokens.
  • Encryption keys and certificates.
  • Audit logs and monitoring data.
  • Source code and CI/CD credentials.

Step 4: Assess threats using STRIDE

CategoryExample ThreatMitigation
SpoofingUnauthorized client or service access.mTLS between services and short-lived tokens via OIDC.
TamperingModification of data in storage or transit.Use checksum validation and signed transactions.
RepudiationUsers deny specific data actions.Signed, immutable logs and timestamped audit trails.
Information DisclosureCross-tenant data leakage.Per-tenant encryption keys and strict IAM isolation.
Denial of ServiceAttackers flood APIs or overload regions.Rate limiting, WAFs, and auto-scaling.
Elevation of PrivilegeCompromised admin or developer credentials.JIT (Just-in-Time) access and strong MFA.

STRIDE ensures full threat coverage for both cloud environments and shared services.

Step 5: Design layered mitigations (SALT)

Scope

Multi-cloud SaaS with shared identity, customer data storage, and analytics pipelines.

Assets

PII, customer data, IAM credentials, and audit logs.

Layers

Identity and access management

  • Use a single identity provider (IdP) for workforce users and services.
  • Apply federated SSO using OIDC/SAML between AWS and GCP.
  • Enforce MFA and conditional access policies for all privileged accounts.
  • Use service accounts with scoped permissions and short-lived credentials.

Network security

  • Isolate workloads by environment (dev, staging, prod).
  • Restrict cross-cloud communication to trusted endpoints with mTLS.
  • Use private peering (AWS Direct Connect, GCP Interconnect) for internal traffic.

Data protection

  • Apply envelope encryption with separate KMS keys per region and tenant.
  • Enforce data residency by region-based storage (S3/GCS with location constraints).
  • Tokenize or pseudonymize sensitive data used in analytics.
  • Log all key usage and enable rotation policies.

Application security

  • Validate all API input and sanitize user-uploaded content.
  • Use WAFs and input schema enforcement at gateways.
  • Apply RBAC in backend services to prevent privilege escalation.

Monitoring and detection

  • Collect CloudTrail, Stackdriver, and audit logs in a central SIEM.
  • Correlate identity events across clouds for unified visibility.
  • Set alerts for new IAM roles, failed MFA, or data movement anomalies.

Automation and governance

  • Enforce guardrails via IaC (Terraform with policy-as-code).
  • Automate drift detection and compliance reporting.
  • Schedule regular access reviews for accounts and roles.

Step 6: Prioritize & justify controls

PriorityControlReason
HighCentralized IdP and MFAPrevents the majority of unauthorized access attempts.
HighPer-tenant encryption with KMSMitigates cross-tenant data exposure.
MediumAutomated drift detectionEnsures long-term configuration integrity.
MediumUnified SIEM integrationImproves detection but adds operational cost.
LowTokenization for analyticsEnhances privacy but adds processing overhead.

Interviewers value clarity on why certain defenses take precedence.

Step 7: Communicate tradeoffs

Discuss the realistic challenges of this architecture:

  • Latency: Cross-cloud communication adds network overhead.
  • Complexity: Maintaining two KMS systems requires automation and synchronization.
  • Cost: Centralized SIEM and replication increase operational expenses.
  • Resilience: Redundancy improves uptime but multiplies maintenance tasks.

“Managing per-tenant keys across multiple clouds increases complexity but ensures compliance and strong isolation. I’d automate key management and logging to minimize operational friction.”

“This design enforces strong data isolation through per-tenant keys, unified identity management, and cross-cloud encryption.

Logging and automation provide continuous compliance visibility, balancing security depth with operational scalability.”

Next Lesson