Ethical › Module 19 › Lesson 1
Shared Responsibility in One Page
Provider vs you. IAM beats a fancy WAF if keys leak.
Visual · shared_responsibility_split
The provider runs the building. You still own identity, data, and how you share it. A WAF does not save leaked keys. Accounts YOU own only.
Opening
The cloud is a rented building. Shared responsibility is who locks which door — not a vibe that “Amazon handles security.”
Modules 1–18 kept every lab on a box, network, or identity you control. Module 19 is the same permission line in someone else’s data center. In Cyberlium wording, shared responsibility is the split of jobs between a cloud provider and a customer: the provider operates hardware, hypervisor, and (depending on the service) more of the stack; you still operate identity, access keys, data classification, and the sharing switches that make an object public. A web application firewall (WAF) is a useful filter in front of an app. It is not a substitute for Identity and Access Management (IAM). If a long-lived key leaks, the attacker authenticates as you. The WAF never sees a “hack.” It sees a signed request that looks legitimate. This is original Cyberlium teaching mapped to the CEH v13 cloud-computing domain — not official EC-Council training, not a cert, not exam dumps. You will not scan other tenants. You will not hunt public buckets as homework. You will not open a stranger’s console “to see how AWS looks.” Next lesson names misconfig — public storage and over-broad IAM — still on accounts YOU own. Here you write the split, the IAM-beats-WAF sentence, a refuse line, and lock the notes.
1. Shared responsibility is a split of jobs — not “the cloud is secure”
A provider’s marketing page lists cages and compliance logos. Those facts are about their building. They do not patch your IAM, rotate a key you pasted into a gist, or know whether a spreadsheet in object storage was meant for the world. “We moved to the cloud” is not a control. Shared responsibility exists because both sides can fail independently: a provider outage is theirs; a public bucket you created is yours. Naming the split is literacy. Treating it as a hall pass to probe other customers is not this course.
Write the legal sentence before any console click: original Cyberlium teaching mapped to the CEH v13 cloud-computing domain — not official EC-Council training, not a cert, not exam dumps. A cert acronym is not a warrant to enumerate other tenants. If you cannot say why the account is yours (or a labeled hypothetical you would own), it is not in scope. Lesson 4 lets you skip if you have no cloud.
Command guide
Split of jobs — WHAT/WHY (not the cloud is secure)
═══ COMMANDS ═══
Command — copy this
cat >> "$NOTES" << 'EOF' provider: physical / some platform controls (varies by model) you: identity, data, how you configure what they handed you slogan_false: the cloud is secure EOF
2. IaaS, PaaS, SaaS — the line moves; identity and data stay yours
Infrastructure as a Service (IaaS) rents you virtual machines and networks: the provider owns metal, hypervisor, and the facility; you typically own guest OS patches, the apps you install, host firewall rules you set, IAM, and data. Platform as a Service (PaaS) lifts more: the provider also runs the OS and runtime; you still own the application, its secrets, IAM, and data. Software as a Service (SaaS) is an app they operate; you still own which identities can sign in, MFA, sharing links, and what you upload. The line moves up the stack. Identity and data classification rarely leave your side. That is why “the SaaS vendor has a WAF” does not excuse a world-readable share you turned on.
Keep the names useful and recipe-free. You do not need a hypervisor exploit sketch. You need, for a service you use: who patches the OS, who rotates the keys, who decides an object is public. If a sentence would help attack a tenant you do not own, it does not belong in your notes.
3. IAM beats a fancy WAF if keys leak
IAM is the set of identities, groups, roles, and policies that say who may do what. A WAF inspects HTTP to an application. Those are different doors. A leaked access key, a stolen console password without MFA, or a role that can do everything in the account does not look like a SQL injection to a WAF. It looks like a customer. Defenders spend money on edge filters and still lose the account because a human identity was the perimeter and the perimeter was a password in chat. The one-page rule: lock identity first (MFA, no long-lived keys in git, least privilege). Then talk about WAFs. Not the other way around.
A useful failure: “we have a WAF, so the intern key in the repo is fine.” It is not fine. Another: “I will test the WAF by firing exploits at a shop I do not own.” On an account you own, you may read IAM and turn MFA on. On an account you do not own, you do not list their users. Skill does not create consent.
4. What you still own: MFA, keys, buckets, sharing switches, your logs
Even when the provider patches the hypervisor, you still decide: MFA on the owner/root and on console users; whether long-lived keys exist; whether object storage is public; whether a SaaS link is “anyone with the link”; whether audit logs (CloudTrail-style: who did what, when, from where) are on. Those are customer jobs in every popular split diagram. Lesson 3 names keys, roles, and logs. Lesson 2 names public storage and over-broad policies. Lesson 4 is MFA plus listing key metadata on an account you own — or a skip file if you have no cloud. None of those lessons is a hunt across tenants.
If the lesson feels “too small” because you did not scan the internet for open buckets, that feeling is how people graduate into unauthorized cloud recon. Stop at the split and at your own account. No cloud is still a complete Lesson 1 on definitions. Do not borrow a friend’s console. Easy is allowed. Stolen consoles are not.
5. Scope freeze: accounts YOU own — other tenants are not a lab
“The cloud is shared hardware” does not mean “every bucket is in scope.” Other customers are other computers. Scanning their storage, guessing their object URLs, or using a search site of exposed buckets is unauthorized access research against people who did not hire you. This course names that pattern as a common breach class in Lesson 2 so you will check YOUR buckets. It does not assign grayhat hunting. Bug-bounty programs have their own rules; Cyberlium does not enroll you. If you are unsure the account is yours, you stop. Module 1’s RoE still wins.
Public postmortems are literacy. Replaying a breach against a tenant you do not own is not. Notes that list other people’s account IDs or buckets fail ethics even if you “only looked.” chmod 600 under $HOME/cyberlium-lab; world-readable 777 fails hygiene.
6. Wrong vs right: tenant hunting vs a one-page split and locked notes
Worked failure — same curiosity about cloud, opposite blast radius. Right never treats another customer’s account as a classroom.
Wrong
Scan other tenants’ buckets. Open a classmate’s console. Call a WAF a substitute for IAM after a key leaked. Paste grayhat bucket-search URLs as homework. Save world-readable notes with foreign account IDs. Call it CEH. This course is not official CEH training and does not give you that hunt.
Right
Name provider vs you on IaaS/PaaS/SaaS. Write that IAM beats a WAF if keys leak. Refuse other-tenant scanning. File $HOME/cyberlium-lab/shared-responsibility-notes.txt, chmod 600. Next: Public Storage and Over-broad IAM — YOUR buckets, not the internet’s.
7. Hands-on: lock shared-responsibility-notes.txt — split only, no tenant hunt
On a computer you own, create cyberlium-lab if needed. Fill the template in your own words. Do not add a bucket scanner. Do not add a target account that is not yours. chmod 600. The block below writes the file and refuses to become a cloud-recon kit — there is no extra tenant, no grayhat search, no stranger console.
Command guide
IAM beats a fancy WAF — WHAT/WHY then lock
═══ COMMANDS ═══
Command — copy this
cat >> "$NOTES" << 'EOF' leaked_key: often bypasses the pretty WAF priority: IAM hygiene on accounts I own EOF
Mission: shared-responsibility-notes.txt in cyberlium-lab (mode 600)
1) In your own words, split provider vs you on IaaS/PaaS/SaaS and write why IAM beats a WAF if keys leak. 2) Fill $HOME/cyberlium-lab/shared-responsibility-notes.txt with the legal line, ethics refuse line, and your split. chmod 600. 3) Ethics: no other-tenant scanning, no grayhat bucket hunting, no stranger console. Lesson 4 is an account YOU own or an honest skip.
Stuck? Ask Cyberlium AI Mentor
If “I cannot learn cloud without scanning public buckets” still feels true, ask for a hint — not a hunt. Try: "Hint only: why IaaS/PaaS/SaaS move the patch line but identity stays mine, why a WAF does not save leaked keys, and where locked notes live?" You still fill shared-responsibility-notes.txt. No tenant scan. No stranger console.
You now treat cloud as a rented building with a written split: the provider’s job is not automatically your IAM, your buckets, or your MFA. A WAF is not a substitute for keys that stay private. Other tenants are out of scope. Notes are locked in cyberlium-lab. This is original Cyberlium teaching mapped to the CEH v13 cloud-computing domain — not official EC-Council training, not a cert, not exam dumps. Next — Public Storage and Over-broad IAM — misconfig as the usual cloud breach, still YOUR buckets only.
Knowledge Check
APPLY: A teammate says the company WAF makes intern access keys in git “fine CEH cloud.” What is shared responsibility here, and what do you do?
Multiple choice
Knowledge Check
APPLY: True or False: Other tenants’ buckets are ethical homework because the hardware is “shared cloud.”
True or False
Knowledge Check
APPLY: You are filling shared-responsibility-notes.txt. Which pairing matches the allowed artifact and hygiene?
Multiple choice
Knowledge Check
APPLY: curl of http://192.168.0.1/ shows a home router login (TP-Link / Netgear / Huawei / "Router Admin"). Is that DEMO in scope as a hacking target?
Multiple choice