Public Storage and Over-broad IAM

Attack blogs love zero-days. Incident reports about cloud more often look boring: a bucket ACL or policy granted public read; a backup prefix was world-listable; a role used by a build job had administrator on the whole account; a SaaS share was set to “anyone.” Those are customer switches. The provider did not secretly decide your payroll CSV should be on the internet. You (or a teammate) did, or a default was never tightened. Naming misconfig keeps you from treating Module 19 as a movie hack. It also keeps you from “practicing” by finding strangers’ files. Finding strangers’ files is not analysis of your RoE. It is their confidentiality incident caused by you.

Legal sentence: original Cyberlium teaching mapped to the CEH v13 cloud-computing domain — not official EC-Council training, not a cert, not exam dumps. Internet-aimed “public bucket labs” are not this course. If you cannot name the account as yours, you do not list its objects. Lesson 4 is MFA and key metadata — or a skip — not a hunt.

cat >> "$NOTES" << 'EOF'
usual_breach: misconfig (public storage, * IAM)
refuse: tenant-scan kits, other people buckets
EOF

Object storage (and many SaaS file products) has a switch that means “this object or this container is readable without being a signed-in customer.” Providers also offer a blunt control often named block public access: a default no that stops accidental public ACLs. On an account you own, opening the storage console and recording whether each bucket you created is private, and whether the account-level block is on, is hygiene. That is the check this lesson wants. Reading a provider’s current click-path in their docs is fine; those UIs move. Pasting a recipe to enumerate someone else’s bucket is not fine.

If you own no cloud storage, write a hypothetical: “one private bucket, block public access on.” That is a complete row. Do not borrow a friend’s project. Do not fetch a leak-site URL “to see if it is still open.” Tightening block-public-access on a bucket YOU own is maintenance. Opening a stranger’s object is not.

Over-broad IAM means an identity can do far more than its job: a daily human with full administrator; a CI role that can delete every resource; a policy whose actions and resources are unbounded wildcards “so it works.” Least privilege is the opposite sentence: only the actions and resources that job needs. You do not need a privilege-escalation cookbook to use that sentence. On an account you own, you may read which of YOUR users and roles are administrators and write “too broad” or “fits the job.” You may not assume a role in someone else’s account. You may not spray permissions across a campus org you do not administer.

“I will find over-broad roles by scanning every account in the region” is a hunt. Attaching administrator to a homework user trains the wrong muscle — Lesson 4 wants MFA and fewer standing keys. A single console user you own, with MFA and no standing keys, beats a wild-card policy from a forum.

Search sites, maps, and dorks that advertise “open buckets on the internet” exist. They are not a Cyberlium lab. Using them to browse other organizations’ objects is unauthorized access research against tenants who did not consent. Calling it “OSINT,” “CEH cloud,” or “responsible disclosure later” does not create RoE. If you ever work a program that explicitly allows cloud recon, that program’s written rules win — and this course still does not assign that program. Here the ethical move is refusal plus checking storage you already know is yours.

Same refusal for guessing a shop’s object URLs or posting foreign bucket names in class. A public postmortem that says “the bucket was public” is literacy. Recreating the victim list is not. Notes with other people’s bucket names fail ethics even if you never downloaded the objects. chmod 600 is not extra credit.

Three verbs you may write for a labeled service you own or would own: (1) block public access or the SaaS equivalent of “not anyone with the link”; (2) least privilege on humans and on jobs — no standing administrator for daily work; (3) inventory — a list of buckets/containers/shares you created, with intended audience. Inventory is how you notice the forgotten backup prefix. It is not a scanner pointed at the rest of the cloud. Owners and dates belong on the note the same way Module 5 put owners on treatment tickets.

Do not “help” a café by listing their storage. Do not make YOUR bucket public “for a screenshot.” Leave it private; intended audience is identities you name. Next lesson adds: no long-lived keys in git, prefer roles, CloudTrail-style logs on.

On a computer you own, create cyberlium-lab if needed. Fill the template for buckets or shares you own, or mark hypothetical. chmod 600. The block writes notes only — no storage API against strangers, no extra tenant.

cat >> "$NOTES" << 'EOF'
over_broad: human users as admin; Action=* Resource=*
fix_direction: roles + least privilege (next lesson)
EOF

You now treat the usual cloud breach as a customer switch: public storage or IAM that can do everything — checked on accounts you own, never hunted across tenants. Block public access, least privilege, and inventory are the verbs. 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 — Keys, Roles, and Logging — no long-lived keys in git, CloudTrail-style logs as a concept, still not a stranger’s trail.