Cloud Security

Fundamentals

We will focus on: IAM, MFA, RBAC, shared responsibility, and

common cloud threats.
What you will be able to do (hands-on)
A simple implementation loop you can follow on any cloud

Learning outcomes Implementation loop (use in labs)

• Explain shared responsibility model 1) Define roles

(AWS/Azure/GCP)
Job functions: Admin / Dev / Auditor / ReadOnly
• Identify common cloud threats &
misconfigurations
• Implement IAM with least privilege 2) Least privilege policy
(AWS/Azure/GCP) Only required actions on only required resources
• Enable MFA and apply RBAC correctly
• Test access (allowed vs denied) and produce
evidence (logs) 3) Strong auth
MFA for admins + short-lived tokens

4) Test + log
Prove it works, and prove it’s auditable

Tip: every lab in this PPT follows the same loop.

Cloud security & privacy challenges
Why cloud security needs a different mindset

Challenges Visual: expanding attack surface

• Dynamic infrastructure (autoscaling, ephemeral

VMs/containers) Users / Devices
• Identity is the new perimeter (IAM misconfig = big risk)
• Shared tenants + internet-facing APIs increase exposure
• Data privacy: PII leakage, residency/compliance, over-
sharing
Cloud Apps / APIs
• Complex configs: networks, storage ACLs, policies, keys
Public endpoints, tokens, auth

Data & Secrets

Storage, DB, keys, configs

Key idea: most cloud breaches start with identity or misconfiguration.

Cloud security & privacy challenges
Cloud attack surface

What changes in the cloud? Attack surface (concept map)

• You manage configuration, identities, and data —
not the physical infrastructure
Identity Control plane
• Everything is API-driven: mistakes can be deployed (IAM) (APIs)
instantly (and globally)
• Identity becomes the “new perimeter” (credentials
are the #1 target) Network Workloads
• Misconfigurations can expose storage, databases, (VPC/VNet) (VM/Container)
and admin endpoints
• Privacy risks: data residency, access to PII, logging
sensitive data
Data plane
(Storage • DB • Secrets)

If identity is weak, everything downstream is exposed.

Shared responsibility model (AWS • Azure • Google Cloud)
Who secures what?

Key idea Responsibility by service model

Provider secures the cloud infrastructure.
You secure everything you configure and Layer IaaS PaaS SaaS
deploy.
Data You You Shared
• IaaS: you manage OS hardening, network controls,
IAM, apps, and data Identity & access You You You
• PaaS: provider manages runtime/OS; you manage
IAM, app logic, data, configuration App / config You You You
• SaaS: provider manages most layers; you still
manage identity, data usage, and configuration Runtime / OS You Provider Provider

Networking Shared Provider Provider

Facilities Provider Provider Provider

Exam tip: Most real-world cloud incidents happen on the “You” side.
Common threats & vulnerabilities in cloud
What actually goes wrong in real projects

Top cloud failure patterns Threat chain (diagram)

• Misconfiguration (public storage, open firewall/security 1) Entry

groups)
Phishing / leaked key / exposed API
• Over-permissioned IAM ("*:*" policies, broad roles)
• Credential leakage (keys in GitHub, logs, CI/CD)
• Insecure APIs (weak auth, missing rate limits) 2) Privilege

• Insufficient monitoring/logging (no alerts, no audit trail) Over-permissioned IAM role

• Vulnerable images/containers (unpatched base images)

3) Data access
Buckets, DBs, secrets

4) Cover tracks
No logs / alerts ⇒ late detection

Key idea: attacks are usually a chain. Break the chain with least privilege + MFA + logging.
IAM fundamentals (works on any cloud)
Principal • Resource • Action • Policy • Condition

Universal IAM model Best practices

Principal (WHO) • Default deny; explicitly allow what is needed

• Use groups/roles (avoid direct user permissions)
User / Group / Role / Service Account
• Prefer short-lived credentials (roles) over long-
term keys
Resource (WHAT)
• Review policies regularly (remove unused
Bucket / VM / DB / Secret / API permissions)

Action (DO WHAT)

read / write / delete / admin

Policy (RULES)
Allow/Deny + least privilege

Condition (EXTRA CHECKS)

MFA present, IP range, tags, time

Think like a compiler: if any part is missing, access should fail.

AWS IAM (practical): roles & policies
Hands-on: least-privilege access to an S3 bucket

How AWS IAM fits the model Mini-lab (console + CLI)

• Users/Groups: people (avoid long-term access keys when Step 1

possible)
Create Role: StudentEC2Role
• Roles: best for workloads (EC2/Lambda) via temporary Trust: EC2
credentials
• Policies: JSON documents (Allow/Deny) attached to users,
Step 2
groups, roles
Attach policy: only List/Get on ONE bucket
• Conditions: enforce MFA, IP restrictions, time-based access

Step 3
Attach role to EC2 instance (Instance Profile)

Step 4
Test: aws s3 ls s3://my-bucket ( )
Try other bucket ( )

Goal: prove least privilege by showing both success and access denied.
Azure: Microsoft Entra ID + Azure RBAC
Identity roles vs resource roles (don’t mix them)

Two different role systems Scope hierarchy (diagram)

Microsoft Entra ID roles (Tenant-level) Management Group

Manage directory objects Highest level
Users, groups, app registrations
Example: User Administrator
Subscription
Billing & access boundary
Azure RBAC roles (Resource-level)
Manage Azure resources via ARM
VMs, Storage, Key Vault Resource Group
Example: Reader / Contributor / Owner Logical container

• Assign Azure RBAC at a SCOPE: Subscription → RG → Resource

Resource
• Prefer groups; avoid direct assignments for many users
VM / Storage / KeyVault

Mini-lab: assign “Contributor” at RG scope

Test: restart VM , delete RG

Rule: Entra ID roles = manage identity; Azure RBAC = manage resources.

Google Cloud IAM (practical)
Roles + policy bindings + (optional) conditions

How GCP IAM is structured Visual: policy binding

• Policy = a set of bindings Principal

• Binding = principals → role (+ optional condition)
user:alice@[Link]
• Roles can be predefined or custom serviceAccount:app@[Link]
• Hierarchy: Organization → Folder → Project → Resource

Role
roles/[Link]
(or custom role)

Condition (optional)
[Link]("projects/_/buckets/student-")
[Link] < 2026-12-31T00:00:00Z

Mini-lab: create bucket + service account

Grant objectViewer on ONE bucket; test gsutil ls

GCP keyword: “binding” (principal → role → resource).

Multi-Factor Authentication (MFA)
Prevent account takeover: passwords alone are not enough

What MFA gives you Auth flow (diagram)

• Blocks most credential-stuffing and password reuse attacks 1) Login

• Adds “step-up” security for sensitive actions
username + password
• Best practice: enforce MFA for admins + production access
• Prefer phishing-resistant MFA (FIDO2 / passkeys) when 2) MFA challenge
possible OTP / push / FIDO2 key

3) Session token
short-lived, auditable

4) Authorization
RBAC/IAM policy checks

Where to enforce
• Root / Global Admin
• Billing + IAM admins
• Production deploy roles

MFA answers: “Are you really the account owner?”

Role-Based Access Control (RBAC) implementation
Design roles like software components

RBAC design rules RBAC wiring (diagram)

• Start from job functions (Admin / Dev / ReadOnly / Auditor) Users

• Assign permissions to roles; assign users to roles via groups
Alice, Bob, Team-Students
• Use least privilege and iterate based on logs
• Separate duties: deploy ≠ approve ≠ audit
• Document every role (what it can/can’t do)
Groups / Roles
DevRole / AuditorRole / AdminRole

Permissions
read logs, deploy app, manage IAM
(scoped to project/resources)

Test method:
• Allowed actions
• Denied actions
• Capture logs/screenshots

RBAC is an engineering design task: keep it simple, testable, and auditable.

Case study: Capital One (2019) — what went wrong?
Real incident mapping to IAM + misconfiguration + monitoring

Simplified incident chain (conceptual) Lessons you can apply in labs

• Least privilege IAM roles (no broad S3/ListAll

1) Entry via web layer
buckets etc.)
A web-facing component was exploited (reported as SSRF / misconfigured
• Restrict metadata/credential exposure to workloads
firewall/WAF).
• Network controls: block SSRF paths; validate
outbound
2) Access to cloud credentials
• Enable audit logs + alerts for unusual data access
Attacker obtained credentials available to the workload (temporary creds).
• Practice incident response: identify → contain →
rotate keys
3) Over-broad permissions
Permissions allowed listing/copying data beyond what should be
necessary.

4) Data exfiltration + detection

Large data set was accessed; discovery happened later after a report/tip.
Key lessons: least privilege + segmentation + alerts.

Sources (for reading): Capital One incident page; academic analysis (ACM)
(Details simplified for teaching.)
Practical blueprint: secure a student cloud project
A minimal reference architecture you can copy

Reference architecture (diagram) Checklist

App/API • Storage is private by default

Users
• IAM policies scoped to a project/bucket
Students / Admins Auth + rate limit
Input validation • MFA for privileged users
• Secrets stored in vault/manager
• Audit logs enabled + alerts set
• Test allowed and denied actions
Data layer
IAM/RBAC
DB + Object storage
Groups + roles
least privilege

MFA
Admins
step-up auth

Logs
audit + alerts

Use this blueprint for your mini-project / lab report.

Mini-project (assessment): Secure a “Notes App” on cloud
Students submit screenshots + logs as evidence

Project requirements Deliverables (what to submit)

• Create 4 roles: Admin, Developer, ReadOnly, Auditor

1) Architecture diagram
• Implement RBAC using groups (no direct user permissions)
Draw the blueprint (users/app/data/IAM/logs)
• Enable MFA for Admin + Developer roles
• Lock storage: only the app role can write; ReadOnly can only read
• Turn on audit logging; create 1 simple alert rule 2) RBAC table
• Demonstrate allowed and denied actions for each role
Role → permissions → scope

3) Evidence
Screenshots of role assignments + MFA

4) Tests
Allowed and denied outputs + logs

Grading rubric can be: correctness (40) + least privilege (30) + evidence/logs (30).
Wrap-up & quick revision
5 takeaways to remember for exams + real projects

• Shared responsibility: provider secures OF the cloud; you secure IN the cloud.
• IAM model: Principal + Resource + Action + Policy + Condition.
• Least privilege + MFA are your default posture for cloud accounts.
• RBAC: use groups/roles; keep scopes tight; test allowed/denied.
• Logging & alerts: if you can’t see it, you can’t secure it.

Next practice: implement one lab on AWS IAM + one on Azure RBAC + one on GCP IAM.