Lesson 2.3: Cloud Security Architecture

Introduction: The Cloud Paradox

"There is no cloud. It's just someone else's computer." — Internet meme, circa 2015

This cynical quip contains a kernel of truth—but misses the point. Yes, cloud computing runs on physical servers. But those servers exist in data centers with better physical security, redundancy, and expertise than most organizations could afford independently.

The paradox? Cloud infrastructure is often more secure than on-premises—but cloud deployments are often less secure. Why? Because customers misunderstand their responsibilities. The 2019 Capital One breach didn't happen because AWS was insecure. It happened because Capital One misconfigured their Web Application Firewall.

🎯 Lesson Objectives

By the end of this lesson, you will be able to:

Distinguish between IaaS, PaaS, and SaaS security responsibilities
Apply the shared responsibility model correctly for each cloud service type
Identify and remediate common cloud misconfigurations
Implement CASB, container security, and cloud-native security controls

1. Cloud Service Models: IaaS, PaaS, SaaS

Understanding cloud service models is essential because security responsibilities vary dramatically between them.

1.1 The Three Service Models

☁️ IaaS (Infrastructure as a Service)

Rent virtual machines, storage, and networks. You manage everything above the hypervisor.

Examples: AWS EC2, Azure Virtual Machines, Google Compute Engine

Your Responsibility: OS patches, applications, data, access control, firewalls

Analogy: Renting an empty apartment—you bring the furniture and handle security.

🛠️ PaaS (Platform as a Service)

Deploy applications without managing underlying infrastructure. Provider handles OS and runtime.

Examples: AWS Elastic Beanstalk, Azure App Service, Google App Engine, Heroku

Your Responsibility: Application code, data, user access, API security

Analogy: Renting a furnished apartment—just bring your clothes.

📧 SaaS (Software as a Service)

Use complete applications over the internet. Provider manages everything.

Examples: Microsoft 365, Salesforce, Google Workspace, Zoho

Your Responsibility: User access, data classification, configuration settings

Analogy: Staying at a hotel—just show up with your ID.

1.2 The Shared Responsibility Model

This is the most important concept in cloud security. Misunderstanding it causes most cloud breaches.

Layer	IaaS	PaaS	SaaS
Data	Customer	Customer	Customer
User Access Management	Customer	Customer	Customer
Application	Customer	Customer	Provider
Runtime/Middleware	Customer	Provider	Provider
Operating System	Customer	Provider	Provider
Virtualization	Provider	Provider	Provider
Servers/Storage/Network	Provider	Provider	Provider
Physical Data Center	Provider	Provider	Provider

Customer Responsibility Provider Responsibility

⚠️ The Capital One Breach: Shared Responsibility Failure

Date: March 2019 (discovered July 2019)

Impact: 100 million customers' data exposed

Root Cause: Misconfigured Web Application Firewall (WAF) allowed Server-Side Request Forgery (SSRF) attack to access AWS metadata service and steal IAM credentials.

Legal Case: United States v. Paige A. Thompson, Case No. 2:19-cr-00159 (W.D. Wash.)

Key Lesson: AWS infrastructure was secure. Capital One's configuration was not. The WAF, IAM policies, and data protection were customer responsibilities under the shared model.

2. Common Cloud Misconfigurations: The Root of Most Evil

According to Gartner, through 2025, 99% of cloud security failures will be the customer's fault. Here are the most common mistakes:

2.1 The "Dirty Dozen" Cloud Misconfigurations

#	Misconfiguration	Risk	Real-World Example
1	Public S3 Buckets	Data exposed to internet	Twitch (2021): 125GB source code leaked from misconfigured server
2	Overly Permissive IAM Policies	Privilege escalation	Capital One: SSRF → metadata → IAM credentials → data
3	Exposed Management Consoles	Full infrastructure compromise	Tesla (2018): Kubernetes console exposed, cryptominers deployed
4	Disabled Logging/Monitoring	No breach detection	Many breaches go undetected for months without CloudTrail/CloudWatch
5	Default Credentials	Trivial unauthorized access	MongoDB instances with default config exposed millions of records
6	Unencrypted Data at Rest	Data theft from snapshots/backups	Stolen EBS snapshots expose sensitive data
7	Missing MFA on Root Accounts	Account takeover	Credential stuffing → full cloud infrastructure compromise
8	Security Groups with 0.0.0.0/0	Exposed services to internet	Databases, Redis, Elasticsearch directly accessible
9	Hardcoded Secrets in Code	Credential exposure	AWS keys in GitHub repos → cryptocurrency mining bills
10	Outdated AMIs/Container Images	Known vulnerabilities	Unpatched Log4j in container images exploited
11	Cross-Account Access Misconfig	Unauthorized resource access	Assume-role policies too permissive
12	Disabled Bucket Versioning	No ransomware recovery	Attackers delete data with no way to recover

2.2 AWS Security Best Practices Checklist

3. Cloud Access Security Broker (CASB)

As organizations adopt multiple SaaS applications (often 100+), how do you enforce consistent security policies? Enter CASB—the security checkpoint between users and cloud services.

3.1 What CASB Does

"CASB is like a customs checkpoint for cloud traffic—inspecting what's going in and out, enforcing policies, and preventing smuggling of sensitive data."

👁️ Visibility

Discover all cloud services in use (including shadow IT). Answer: "What cloud apps are our employees using?"

📋 Compliance

Enforce regulatory requirements across cloud services. Ensure DPDPA compliance for data stored in SaaS apps.

🔒 Data Security

DLP policies, encryption, access controls applied to cloud data. Prevent sensitive data upload to unauthorized services.

🛡️ Threat Protection

Detect malware in cloud storage, identify compromised accounts, block risky activities.

3.2 CASB Deployment Modes

Mode	How It Works	Pros	Cons
Forward Proxy	All traffic routed through CASB proxy	Full visibility and control, works for any app	Requires traffic redirection, latency
Reverse Proxy	CASB sits in front of specific cloud apps	No endpoint agent needed	Only works for sanctioned apps
API-Based	Connects to cloud services via APIs	Non-inline, no latency, deep visibility	Limited to API capabilities, not real-time

💡 CASB Example: Preventing Shadow IT Data Leakage

Scenario: Employees upload customer data to personal Dropbox accounts for convenience.

CASB Solution:

Forward proxy detects Dropbox traffic
DLP engine scans for PII (Aadhaar numbers, PAN, etc.)
Policy blocks upload and alerts security team
User sees message explaining why action was blocked

This prevents DPDPA violations before they happen—not after.

4. Container Security: Securing the New Infrastructure

Containers (Docker, Kubernetes) have revolutionized application deployment. But they've also introduced new security challenges—and most security professionals are still catching up.

4.1 Container Security Challenges

🐛 Vulnerable Base Images

Container images pulled from Docker Hub often contain vulnerabilities. A 2020 study found 51% of images had critical vulnerabilities.

Solution: Scan images before deployment, use minimal base images (Alpine), maintain private registries.

🔓 Privileged Containers

Running containers as root or with excessive privileges allows container escape attacks.

Solution: Run as non-root, drop unnecessary capabilities, use seccomp profiles.

🌐 Network Exposure

Kubernetes dashboard, etcd, and API server exposed to internet enable cluster takeover.

Solution: Network policies, service mesh, private clusters.

🔑 Secrets Management

Hardcoded passwords in container images or environment variables easily extracted.

Solution: Use Kubernetes Secrets, HashiCorp Vault, AWS Secrets Manager.

4.2 Container Security Best Practices

# Dockerfile Security Best Practices

# 1. Use minimal base image
FROM alpine:3.18 AS base

# 2. Don't run as root
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

# 3. Specify exact versions, not "latest"
FROM python:3.11.4-slim

# 4. Multi-stage builds to minimize attack surface
FROM golang:1.20 AS builder
# ... build steps ...
FROM alpine:3.18
COPY --from=builder /app/binary /app/binary

# 5. Remove unnecessary packages
RUN apk del --purge wget curl

# 6. Don't store secrets in image
# BAD: ENV API_KEY=supersecret123
# GOOD: Use runtime secrets injection

4.3 Kubernetes Security

1

Enable RBAC (Role-Based Access Control)

Never run with ABAC or unauthenticated API access. Define granular roles and bindings.

2

Implement Network Policies

By default, all pods can communicate. Use NetworkPolicy to restrict pod-to-pod traffic.

3

Use Pod Security Standards

Enforce restricted, baseline, or privileged policies using Pod Security Admission.

4

Enable Audit Logging

Capture all API requests for forensic analysis. Send to SIEM for monitoring.

⚖️ Case Study: Tesla Kubernetes Breach (2018)

Attackers discovered Tesla's Kubernetes dashboard exposed to the internet without authentication. They deployed cryptocurrency miners using Tesla's AWS resources.

Root Cause: Default Kubernetes dashboard configuration doesn't require authentication. Tesla failed to configure access controls.

Lesson: Always authenticate management interfaces. Use network policies to restrict access. Monitor for unusual resource consumption.

5. DPDPA Implications for Cloud Deployments

The Digital Personal Data Protection Act 2023 has significant implications for cloud security:

⚖️ Section 8: Obligations of Data Fiduciary

Data Fiduciaries must implement "appropriate technical and organisational measures" to protect personal data. Cloud deployments must demonstrate:

Encryption at rest and in transit
Access controls and audit logging
Data residency compliance (if required by rules)
Security incident detection and response capabilities

⚖️ Section 17: Transfer of Personal Data Outside India

Personal data may be transferred to countries notified by Central Government. For non-notified countries, additional safeguards may be required.

Practical Impact: Know where your cloud provider stores and processes data. AWS, Azure, and GCP all have India regions—use them for sensitive data.

5.1 Cloud Provider Compliance

Provider	India Region	Key Certifications	Data Residency Options
AWS	Mumbai (ap-south-1), Hyderabad (ap-south-2)	ISO 27001, SOC 2, PCI DSS	Data residency guardrails via SCPs
Azure	Central India (Pune), South India (Chennai), West India (Mumbai)	ISO 27001, SOC 2, MeitY Empanelment	Azure Policy for data residency
Google Cloud	Mumbai (asia-south1), Delhi (asia-south2)	ISO 27001, SOC 2	Organization policies for location

⚠️ MeitY Cloud Guidelines for Government

If your organization works with government data, note that MeitY's Government Cloud (GI Cloud/Meghraj) requires empanelled cloud service providers. Check the MeitY empanelment list before selecting providers.

📝 Key Takeaways

1

The shared responsibility model defines who secures what—customer always owns data security

2

Cloud misconfigurations (public S3, overly permissive IAM) cause most breaches, not provider failures

3

CASB provides visibility, compliance, data security, and threat protection for cloud services

4

Container security requires image scanning, non-root execution, network policies, and secrets management

5

DPDPA requires appropriate security measures and may restrict cross-border data transfers