Find and Fix 8 Storage Misconfigurations

The job is not memorizing a checklist — it's looking at a real environment and spotting which buckets are misconfigured, why each one matters, and what fixes it. In this exercise you'll walk a cloud-config scan of Meridian Data, a SaaS company whose storage has accumulated the usual drift. Eight findings are seeded across its buckets. For each, you decide the fix and the evidence; the explanations are the reasoning you'll reuse on a real environment. Then you'll write up the highest-severity finding as a full remediation plan.

Opening the storage config-scan results for the first time

The environment

Meridian's scan covers six buckets: meridian-uploads (customer files), meridian-exports (data exports), meridian-backups (database backups), meridian-logs (app logs), meridian-static (public website assets), and meridian-analytics (de-identified data). Work each finding below.

Finding 1: A public bucket holding customer data

Quick check

The scan flags meridian-uploads as publicly readable ('AllUsers: READ'). It holds customer-uploaded files. What is the fix and the evidence?

Leave it — customers need to access their own files

Remove public access immediately, enable account- and bucket-level block-public-access, serve customer files through the application via scoped/short-lived signed URLs, and confirm with a config report showing the bucket is no longer public; review access logs for prior exposure

Rename the bucket so the old public URL stops working

Restrict it to "Authenticated Users" instead of "All Users"

Finding 2: No default encryption

Quick check

meridian-backups has no default encryption configured; some objects are encrypted, some are not. Why does this matter and what is the fix?

It is fine as long as at least some objects are encrypted

Enable default (bucket-level) encryption with a customer-managed key so every new object is encrypted automatically, and re-encrypt or rewrite existing unencrypted objects; backups are full copies of production data and must not land in plaintext

Encryption is unnecessary for backups since they are not actively used

Just encrypt the bucket name

Finding 3: Over-broad IAM grant

Quick check

The application role has 's3:*' on all buckets ('to avoid permission errors'). What is the right correction?

Keep it — broad permissions prevent outages

Scope the role to least privilege: only the specific actions (e.g., GetObject/PutObject) on only the specific buckets the app actually uses, validated against access logs / an access analyzer, so a compromise of the app role cannot reach unrelated data

Reduce it to s3:* but only on five of the six buckets

Leave the permissions but add a comment explaining they are broad

Finding 4: No access logging

Quick check

meridian-exports has no access logging enabled. Why is this a finding even though the bucket is private?

It is not a finding — private buckets do not need logging

Without access logging you cannot investigate an incident or prove who accessed export data; enable access logging / data-access audit logs so reads and writes are recorded, and confirm logs flow to a monitored, retained location

Logging is only needed for public buckets

Add logging only if the security team specifically asks

Finding 5: No versioning on critical data

Quick check

meridian-uploads and meridian-backups have versioning disabled. What risk does this create and what is the fix?

No risk — versioning just wastes storage

An accidental or malicious overwrite/delete is unrecoverable, and ransomware that encrypts objects in place leaves no clean copy; enable versioning (and consider Object Lock/immutability for backups) so prior versions are recoverable, with lifecycle rules to control cost

Versioning is only useful for source code, not data

Enable versioning only on the logs bucket

Finding 6: Public-access-block not enabled account-wide

Quick check

Individual buckets were fixed, but the account-level block-public-access guardrail is off, so a future bucket could be made public again. What is the durable fix?

Nothing more is needed once each current bucket is private

Enable block-public-access (or public-access-prevention org policy) at the account/organization level so no bucket can be made public without an explicit, governed exception — a preventive control, not just per-bucket cleanup

Send an email reminding engineers not to make buckets public

Audit buckets manually once a year to catch any that went public

Finding 7: World-readable static assets — is it actually a problem?

Quick check

meridian-static (public website CSS/JS/images) is publicly readable. The scan flags it. How should you assess this one?

It is a critical finding — make it private immediately like the others

Public read is appropriate for genuinely public website assets, but document it as a deliberate, reviewed exception, confirm no sensitive data is mixed into the bucket, and ideally serve it via CDN with write access locked down — public-read is intentional here, not a leak

All public buckets are equally bad regardless of contents

Ignore the scan entirely since static assets are harmless

Finding 8: Unencrypted cross-region replication

Quick check

meridian-backups replicates to a second region for resilience, but the replication destination has no encryption configured and is in a less-controlled account. Why does this matter?

It does not matter — the source bucket is encrypted, so the data is protected

Replication copies the data into a new location that must meet the same protection standard; an unencrypted destination in a weakly-controlled account is a second, softer copy of the backups — enforce encryption (with an appropriate key) and equivalent access controls and logging on the destination

Just stop replicating to avoid the problem

Encryption on the destination is optional since it is only a replica

Write it up: the highest-severity finding

Now translate the most urgent finding — the public bucket of customer data — into a remediation plan an engineering team can execute.

Exercise

~30 min

Translate this audit finding into a technical remediation plan

SOC 2 Type II Finding

Customer data bucket publicly accessible; storage guardrails missing

ID:

CC6.1-2026-022

Criterion:

CC6.1 — Logical access controls / protecting data

Severity:

Critical

A cloud-config scan found the bucket meridian-uploads, containing customer-uploaded files, configured with public read access (AllUsers: READ). Account-level block-public-access is not enabled, so other buckets could also be exposed. The bucket has no access logging, and default encryption is not configured (objects are inconsistently encrypted). Access logs for the exposure window are not available because logging was never enabled.

Auditor Notes

Management could not determine whether the data was accessed by unauthorized parties because access logging was not enabled. The bucket was reportedly made public during a feature test 14 months ago and never reverted. Customer files include documents that may contain PII.

Write your remediation plan in YAML below. Fill in every field — replace all placeholder comments.

Loading editor…

How to use this in practice

A storage review is a hunt with a fixed quarry: for every bucket, ask the same questions — public or private (and is that intentional and documented), who can access it as policy, encrypted with which key, logged, versioned, and is there an account-level guardrail preventing future public exposure. The two judgment calls that separate a strong reviewer from a checklist-runner are distinguishing a deliberate public bucket (static assets) from an accidental one (customer data), and remembering that copies — backups, replicas, exports — must meet the same bar as the original. Capture the answers as evidence, and the next lesson's checklist makes that repeatable.