What matters first
- Review the effective access decision rather than a single console setting.
- A signed link should follow an application authorization decision.
- Include older buckets, exports, and temporary processing locations.
Inventory storage by business purpose
List buckets and access points used for customer uploads, public assets, exports, backups, logs, and temporary processing. Record the intended audience and the application identity using each location. Different purposes can justify different policies, but those policies should be explicit.
Include older environments and automatically created locations. A temporary export bucket can become long-lived after its original owner leaves. Connect stored data to retention and deletion requirements so the review covers the object’s lifecycle, not only the current application feature.
Review public access controls and policies
AWS documents Block Public Access controls across several levels, including buckets and accounts. Review how the relevant settings interact with resource policies and access paths in your configuration. A template’s default does not prove that an existing bucket has the same effective protection.
Separate intentionally public assets from private customer data. Where public delivery is required, define the specific content and mechanism. Avoid broadly granting public access to solve a private-download problem that the application should handle through a narrower authorization and delivery workflow.
References: [1] AWS
Inspect application-issued access
Review the identity that writes and reads objects and any workflow generating signed links. Before issuing a private download link, the application should establish that the caller may access the requested object. A signed link can grant access to its holder even if the underlying bucket is otherwise private.
Check object identifiers, tenant context, link lifetime, and what happens when ownership or account membership changes. Include export workers and administrative tools that may create links outside the normal customer request path. A correct storage policy does not repair missing ownership checks in the application.
Verify from the relevant access contexts
Use synthetic objects and authorized test accounts to confirm intended public, private, and cross-tenant behavior. Review access from the application identity and any delivery mechanism. Avoid placing real sensitive data into a public test just to prove that a permission is broad.
Record the observed access result, policy context, and affected location. After changes, confirm legitimate uploads and downloads still work and that older export or temporary paths are covered. Preserve the configuration in the normal deployment process so a later release does not restore the previous exposure.
Your next steps
- Map storage locations to intended audiences and application owners.
- Review effective public access controls and resource policies.
- Verify private-link issuance and tenant ownership with synthetic objects.
- Scope an application and storage-access review before expanding file workflows.
Questions teams ask
Does a private bucket guarantee tenant isolation?
No. The application can still issue a valid link or perform a read for the wrong customer. Review storage permissions and application ownership decisions separately.
Should every bucket be public for a website to work?
No. Public assets and private customer data have different purposes. Choose a delivery model appropriate to each instead of using broad public access as a default.
Sources and editorial notes
Public-source facts are cited above. The review questions and action plans are Cyphen’s guidance for applying those lessons to your own systems. Sources checked on .