Cloud Security Fundamentals
Learn the shared responsibility model, IAM basics, and why misconfiguration — not provider infrastructure — causes most cloud breaches, before attacking AWS and Azure.
Learning Objectives
- → Explain the cloud shared responsibility model and how it shifts by service model (IaaS/PaaS/SaaS)
- → Distinguish IaaS, PaaS, and SaaS by what the provider vs customer manages
- → Describe core IAM concepts: principals, roles, policies, and least privilege in a cloud context
- → Explain why misconfiguration is the leading cause of cloud breaches
- → Build the conceptual foundation for attacking and defending AWS and Azure
Why "The Cloud Is Someone Else's Computer" Isn't the Whole Story
Moving to the cloud doesn't remove security responsibility — it redistributes it. Understanding exactly where that line falls is the single most important concept in cloud security, and it's the prerequisite for understanding cloud-specific attacks (see "Cloud Security: AWS & Azure Attacks," the next lesson).
The Shared Responsibility Model
| Layer | IaaS example (EC2) | PaaS example (App Service) | SaaS example (Office 365) |
|---|---|---|---|
| Physical/hardware | Provider | Provider | Provider |
| Hypervisor/network | Provider | Provider | Provider |
| OS patching | Customer | Provider | Provider |
| Application code | Customer | Customer | Provider |
| Data & access config | Customer | Customer | Customer |
The pattern that matters: data and access configuration is always the customer's job, no matter which service model you use. This is exactly why the leading cause of cloud breaches is customer-side misconfiguration (public S3 buckets, over-permissioned IAM roles), not the cloud provider's own infrastructure being hacked.
Cloud Service Models
- IaaS (Infrastructure as a Service) — raw compute/storage/network (EC2, Azure VMs); you own the OS up
- PaaS (Platform as a Service) — you deploy code, the provider manages the runtime (App Service, Elastic Beanstalk)
- SaaS (Software as a Service) — a finished application (Office 365, Salesforce); you only control data and user access
IAM: Identity and Access Management
Every major cloud provider centers security around IAM:
- Principal — a user, group, service account, or role that can be granted permissions
- Policy — a document defining what actions a principal can perform on what resources
- Role — a set of permissions that can be assumed temporarily, rather than tied permanently to one identity
Least Privilege in the Cloud
The same principle from the earlier GRC lesson applies here, at a much larger and more automatable scale: a principal should have exactly the permissions its job requires, no more. An over-permissioned IAM policy (Action: "*", Resource: "*") is the cloud equivalent of sudoers ALL=(ALL) ALL from the Linux hardening lesson — and just as dangerous.
Regions and Availability Zones
- A region is a geographic area (e.g. us-east-1); an availability zone (AZ) is one or more physically separate data centers within a region
- Spreading resources across AZs protects against a single data-center failure; spreading across regions protects against a regional outage or addresses data-residency requirements (relevant to the earlier GDPR lesson's data-location concerns)
Why Misconfiguration Dominates Cloud Breach Statistics
Because the customer always owns data and access configuration (see the table above), and cloud consoles make it trivially easy to expose a storage bucket or over-grant a role with a single checkbox, misconfiguration — not a provider zero-day — is responsible for the overwhelming majority of publicly reported cloud breaches.
Common Pitfalls
- Assuming "the provider is responsible for security" without checking which layer that actually covers
- Granting broad IAM permissions "temporarily" during development and never revisiting them
- Treating multi-region deployment purely as a performance decision, ignoring its data-residency/compliance implications
One row of the shared responsibility table never moves to the provider's side, no matter which service model you pick.
In the shared responsibility model, who is always responsible for data and access configuration, regardless of service model?
In SaaS, the provider manages everything below the data layer — including the application itself.
Which cloud service model has the customer managing only data and user access, with the provider managing everything else including the application itself?
A wildcard IAM policy grants unrestricted access to every action on every resource — the same failure mode as an earlier Linux misconfiguration.
An IAM policy granting Action:'*' and Resource:'*' to a service account is the cloud equivalent of which risky Linux configuration from an earlier lesson?
💪 Exercises & Challenges
Cloud Security Fundamentals MCQ
Test your understanding of Cloud Security Fundamentals.
Design a Least-Privilege IAM Policy
A CI/CD pipeline service account needs to upload build artifacts to exactly one S3 bucket (my-app-builds) and nothing else. Write the IAM policy (in plain language or JSON-like pseudocode) that grants
Diagnose the Real Failure
A startup's breach post-mortem reads: 'Our EC2 instance had a fully patched OS and no known vulnerabilities. The breach happened because a developer's IAM user had s3:* on Resource: "*", and that user