Module 1 · Cloud Security Mental Models 🔒

Cloud security is often taught as a taxonomy — “AWS IAM works like this, GCP IAM works like this, Azure is different.” That’s how you end up memorising 300 service-specific checkboxes without ever understanding what matters. This module inverts the usual approach: we give you the mental models that apply across AWS, Azure, GCP, and Kubernetes, so the service-specific details become easy to pick up in context.

By the end of this module you will understand:

• The shared responsibility model — what the cloud provider secures vs what you must secure
• The four core cloud security pillars: identity, network, data, and detection
• Why most cloud breaches are misconfiguration, not vendor flaws
• The mental model of “assume the perimeter is porous” — a prerequisite for safe cloud architecture
• How the three big providers differ, and when that difference matters

The shared responsibility model

Every cloud provider publishes some version of this diagram. The common theme:

• Provider always secures: physical data centres, host hardware, hypervisor, provider-managed services’ underlying infrastructure
• Customer always secures: identity (who can do what), their own data (classification, encryption keys, retention), their application code, their network configuration
• Shared: OS patching (customer for IaaS, provider for PaaS and SaaS), encryption (provider offers, customer chooses)

Most cloud breaches happen in the customer-responsibility zone. A provider almost never “gets hacked” in a way that exposes your data. What happens: customer leaves an S3 bucket public, customer grants overbroad IAM, customer exposes a database to the internet, customer commits an access key to GitHub.

The first mental shift for a cloud security practitioner: stop worrying about the provider’s security posture (they spend billions on it, it’s genuinely strong). Start worrying about yours.

Pillar 1 — Identity

In cloud, identity is the new perimeter. The firewall matters less than who can do what.

Core concepts (terminology varies, concepts don’t):

• Principal — the actor (user, service, role)
• Permissions / Policies — what the principal can do
• Resource — the thing being acted on
• Role / Managed Identity — a principal meant to be assumed by another principal (typically a workload)
• Trust policy — who is allowed to assume a role

Provider mappings:

The rules that matter (all providers):

1. Never use the root/admin account for daily operations. Set up a break-glass process with MFA-protected access, store credentials offline, use only for things that genuinely require it (deleting the account, etc.)
2. Enable MFA everywhere. Especially on any account with elevated privileges. Hardware tokens (YubiKey) are significantly better than TOTP apps for privileged accounts
3. Least privilege. Grant specific actions on specific resources. "Action": "*" is a finding
4. Use workload identities, not long-lived keys. A container on EKS doesn’t need an access key — it uses an IAM role via IRSA. A VM on GCE uses its service account. Long-lived keys are the single largest source of cloud breaches (GitHub-committed keys)
5. Audit frequently. Access-Advisor (AWS), IAM Recommender (GCP), PIM (Azure) — all surface stale permissions. Review quarterly

Pillar 2 — Network

Cloud networking mostly mirrors on-prem concepts (see Networking Module 4). The cloud-specific principles:

• Default-deny everywhere. Start with no inbound rules; add only what’s needed
• Segment by trust level. Public subnets for load balancers only; private subnets for app and DB tiers; a dedicated management subnet with strict access
• No direct internet for databases. Never. Databases in private subnets, accessed via application tier, never directly from the internet
• Use private endpoints for managed services. AWS VPC Endpoints, Azure Private Link, GCP Private Service Connect — keep traffic to managed services (S3, Cosmos DB, Cloud Storage) off the public internet
• Egress control matters as much as ingress. Default VPC egress is “all outbound allowed.” Compromised workloads need outbound to C2 — restrict egress to known destinations
• Cross-VPC / Cross-VNet — peering, VPN, or PrivateLink depending on needs. Peering is cheap but propagates routes; PrivateLink is granular but has per-connection cost

Pillar 3 — Data

Cloud storage comes in many forms: object storage (S3, Blob, GCS), block storage (EBS, Managed Disks, Persistent Disks), databases (RDS, Cosmos, Cloud SQL, managed NoSQL), data warehouses (Redshift, Synapse, BigQuery), and data lakes.

Universal rules:

• Encryption at rest — always on. All providers support customer-managed keys (CMK) via KMS / Key Vault / Cloud KMS. Choose CMK over provider-managed keys for any sensitive data
• Encryption in transit — TLS 1.2+. Enforce at the service level; all major providers support this
• Object-storage public access — block at the top. AWS S3 Block Public Access at account level, Azure Storage “Allow blob public access = false” at account, GCP org policy constraint. Prevents individual-bucket misconfig
• Backups encrypted and immutable. Ransomware can encrypt your live data; if your backups are also writable by the same principal, you have no recovery
• Key rotation. KMS keys rotate annually by default (provider-managed); for CMK, rotate on a schedule tied to compliance framework
• Data classification. Know what’s sensitive (PII, PHI, PAN, financial). Tag it. Apply stricter controls at each tier

Under DPDP, your cloud storage choices have legal implications:

• Data-residency decisions (keep Indian data in India region where possible)
• Encryption = reasonable security safeguard (Section 8(5))
• Access controls + logging = audit trail
• Retention policy in storage = complies with erasure rights (Module 2 of DPDP path)

Pillar 4 — Detection

You cannot respond to what you cannot see. Cloud detection has three layers:

Audit logs

• AWS CloudTrail — records every API call. Enable across all regions; send to a separate security account; enable log file integrity validation
• Azure Activity Log + Azure Monitor — subscription-level audit
• GCP Cloud Audit Logs — Admin Activity (free, always on), Data Access (paid, opt-in, high volume)

Network logs

• VPC Flow Logs (AWS/GCP) / NSG Flow Logs (Azure) — who talked to whom when, at packet-metadata level
• Enable at subnet or VPC level. Don’t capture everywhere (cost), but definitely at security-critical boundaries

Workload / runtime

• GuardDuty (AWS), Defender for Cloud (Azure), Security Command Center (GCP) — managed threat detection
• These aggregate multiple signal sources and flag suspicious patterns (Tor logins, crypto mining, unusual API calls, compromised credential usage)
• Relatively low-noise, high-value. Every cloud account should have one enabled

Configuration drift

• AWS Config, Azure Policy, GCP Organisation Policy — enforce baseline configurations and alert on drift
• Example rules: no public S3 buckets, encryption required on EBS volumes, no SSH from 0.0.0.0/0 in security groups

The three failure modes

95% of cloud breaches fall into one of three patterns:

Mode 1 — Credentials leaked

AWS access keys committed to GitHub. A developer’s laptop compromised. An exposed .env file in a container image. An overly-broad API token posted in a support ticket.

Prevention:

• Don’t use long-lived credentials for workloads — use instance / pod identities
• Pre-commit hooks + secret-scanning (git-secrets, gitleaks, GitHub secret scanning)
• Rotate any human user’s long-lived keys every 90 days
• Monitor for credential leakage (AWS Health events, HaveIBeenPwned-style services for leaked tokens)

Mode 2 — Public exposure by misconfiguration

S3 bucket configured public. Security group allows 0.0.0.0/0 on database port. RDS instance with “Publicly Accessible = yes.” ElasticSearch cluster on internet-routed subnet. Redis without password on EC2.

Prevention:

• Org-level policies that block the most dangerous settings
• Account-level defaults (S3 Block Public Access at account)
• Config rules that alert on creation of non-compliant resources
• IaC review gates (every Terraform / CloudFormation PR reviewed for exposure patterns)

Mode 3 — Over-permissive IAM

A service account with *:* (full admin). A cross-account role trust that’s wider than needed. A user with AdministratorAccess when they needed PowerUserAccess. An old Lambda function whose role has never been reviewed since 2019.

Prevention:

• IAM policies start from template-minimal and expand only as needed
• Access Advisor / IAM Recommender quarterly review (remove unused permissions)
• Condition-based policies — restrict by source IP, by session tag, by MFA requirement
• Privileged Access Management for elevated roles (JIT / PIM patterns)

The “assume porous perimeter” mental model

Traditional on-prem: hard perimeter, soft centre. Cloud breaks this. Principles for cloud-native thinking:

• Every service is internet-reachable by default. Turning things off requires explicit action
• Every credential has a blast radius. A leaked access key = whatever permissions that key has, from wherever in the world
• Every workload can be compromised. Design the rest of the system to limit damage — isolate blast radius with per-workload identities, per-service encryption keys, scoped networking
• Reconnaissance is fast. An attacker with a credential can enumerate what they have access to in minutes via automated tools (Pacu, ScoutSuite, stormspotter, etc.)

Corollary: detection speed matters. An attacker with a leaked key starts exfiltration within minutes. Detection that fires at T+24 hours is already too late; detection at T+30 minutes lets you rotate and contain.

Provider differences that matter

• AWS: service-sprawl champion. Hundreds of services, deep feature sets, most mature IAM model. Heavy on manual configuration. Complexity is the biggest enemy
• Azure: enterprise-familiar (AD integration, Windows tooling). RBAC feels closer to AD-style than IAM policy. Good for orgs already in Microsoft 365. Historical weakness: default settings often less secure than AWS equivalents
• GCP: strongest defaults, cleanest IAM model, excellent built-in tooling (Security Command Center, VPC Service Controls). Fewer native services than AWS. Often the best choice for new green-field builds

Multi-cloud is common in India (fintech often runs AWS + GCP, enterprises often AWS + Azure). Security programmes must abstract cloud-specific into common principles to stay sane.

Quick reference summary

• Shared responsibility: provider secures infrastructure, you secure identity + data + config
• Four pillars: Identity, Network, Data, Detection
• Identity = new perimeter; never use root; MFA everywhere; least privilege; workload identities over long-lived keys
• Network: default-deny, segment by trust, no public databases, private endpoints for managed services, control egress
• Data: encrypt at rest (CMK preferred), TLS in transit, block public access at account level, immutable backups
• Detection: audit logs (CloudTrail/Activity/Audit), flow logs, threat detection (GuardDuty/Defender/SCC), config drift alerts
• Three failure modes: leaked credentials, public-misconfig exposure, over-permissive IAM
• “Assume porous perimeter” — every service internet-reachable by default, every credential has blast radius, every workload can be compromised
• AWS = complex + mature; Azure = MS-familiar; GCP = clean defaults + best built-in tools

Take the quiz. Next: AWS IAM Deep Dive — where we turn the mental models into concrete IAM policies, with worked examples and the specific patterns that catch Indian fintech auditors’ attention.