Cloud Security — Locking It Down

What you'll learn

• The shared responsibility model (who secures what)
• IAM — controlling who can do what
• Encryption at rest and in transit
• The misconfigurations that cause most cloud breaches

Who locks which door? 🔐

The most misunderstood idea in cloud security is the shared responsibility model. Think of a cloud provider as an apartment building:

• The provider secures the building — the physical hardware, the data center, the foundation, the walls. ("Security of the cloud.")
• You secure your apartment — your data, your passwords, your access rules, your locked doors. ("Security in the cloud.")

Most cloud breaches are NOT the provider being hacked — they're customers leaving their own door unlocked. AWS is extremely secure; the leaks come from a misconfigured S3 bucket left public, or a password left in code. Knowing your half of the responsibility is the whole game.

IAM (Identity and Access Management) is your control panel for "who can do what." It's least privilege (from the security track) at cloud scale:

• Create users and roles.
• Grant each the minimum permissions needed. A backup script needs read-only access to one bucket — not admin over everything.
• Never use the all-powerful root account for daily work.

A too-broad IAM permission is like handing every employee a master key to the entire building. When (not if) one account is phished, the damage is total.

Encryption — two flavors, always use both:

• In transit — data moving over the network is encrypted (HTTPS/TLS), so an eavesdropper gets gibberish. (Remember man-in-the-middle from the security track?)
• At rest — data sitting in storage/databases is encrypted, so a stolen disk is useless.

The breach checklist — nearly all cloud incidents trace to these:

1. Public storage buckets that should be private.
2. Over-permissioned IAM roles.
3. Secrets (passwords, API keys) hardcoded in code or repos.
4. Unpatched software.

Master the shared responsibility model, least-privilege IAM, and encryption, and you avoid the mistakes behind the vast majority of cloud data leaks.

MFA and DDoS protection — the other two locks 🔒

Beyond IAM and encryption, two more defenses close most of the remaining gaps.

Multi-Factor Authentication (MFA) means logging in requires more than just a password — usually a password plus a one-time code from your phone. Even if an attacker phishes or guesses your password, they still can't get in without your phone. Every cloud provider strongly urges (and many now force) MFA on the root/admin account specifically, because that account has unlimited power — it's the one login that must never be a single point of failure.

DDoS (Distributed Denial-of-Service) protection defends against a different kind of attack: instead of trying to break in, an attacker floods your service with fake traffic from thousands of hijacked devices at once, trying to overwhelm it so real users can't get through. Cloud providers run massive-scale protection (AWS Shield, Cloudflare, Google Cloud Armor) that automatically absorbs and filters this junk traffic before it reaches your servers — a scale of defense no single company could build alone.

Put together with IAM, encryption, and the shared responsibility model, a simple mental checklist emerges for any cloud deployment:

1. Is MFA required on every privileged account?
2. Is every IAM permission the minimum needed?
3. Is data encrypted at rest and in transit?
4. Is DDoS protection enabled in front of anything public-facing?

Four questions, and you've covered the defenses behind the overwhelming majority of real cloud security incidents.

Real-world case study: The Capital One breach 🔍

In 2019, Capital One disclosed a breach affecting over 100 million customers, one of the largest breaches in U.S. financial history. The attacker was a former employee of a cloud provider who exploited a misconfigured web application firewall on Capital One's cloud infrastructure to trick a server into fetching sensitive credentials it should never have been able to reach, then used those credentials to access and download data from cloud storage.

This is a direct, real illustration of the shared responsibility model from this lesson: the cloud provider's infrastructure was not "hacked" in the traditional sense — the breach traced to a misconfiguration and overly broad permissions on the customer's side, exactly the kind of issue the "breach checklist" in this lesson warns about.

The case became one of the most-cited examples in cloud security training precisely because it wasn't exotic — no zero-day exploit, no nation-state hacking tools. It was a misconfigured firewall rule and permissions that were broader than they needed to be, letting one compromised credential reach far more than it should have. It's the textbook argument for least-privilege IAM and rigorous configuration review as routine practice, not an afterthought.

Summary

• Shared responsibility: provider secures the cloud, you secure what's in it
• IAM = least-privilege access control; never use root daily
• Encrypt in transit (TLS) and at rest (storage)
• Most breaches = public buckets, broad IAM, leaked secrets, unpatched software
• MFA on privileged accounts and provider-scale DDoS protection close most remaining gaps
• The Capital One breach shows a real-world least-privilege and misconfiguration failure

Next: Serverless & Containers — modern ways to run your code in the cloud.