Myth vs fact: cloud storage is private by default so it is safe

Cloud storage is private by default on AWS and Azure, but that does not make it safe. The default describes how a resource starts. People then change policies, ACLs and account settings, and a guardrail is what stops those changes from going public. Defaults help, but they are not a control you can point to.

Myth: private by default means it stays private

Fact: AWS states that new buckets, access points and objects do not allow public access by default. It then adds the key caveat: users can modify bucket policies, access point policies or object permissions to allow public access.

Microsoft says the same for Azure Blob Storage. Anonymous access is prohibited by default, but a user with the right permissions can configure containers for anonymous reads if the account allows it.

The default is a starting position. The question is what stops the next change from undoing it.

Myth: if the bucket is blocked, all the data is protected

Fact: AWS Block Public Access only guards against public access through resource policies and ACLs. AWS tells you to also inspect identity-based policies and KMS key policies, since those can grant access too. Block Public Access settings also do not alter existing policies, so removing the setting makes an old public grant work again.

Google makes a similar point. Public access prevention overrides public grants but does not delete them.

Myth: signed links are the same as public

Fact: On Google Cloud, public access prevention does not affect signed URLs. A signed URL is time limited access given deliberately, not a public grant. That does not make it harmless, because anyone holding the link can use it until it expires, but it is a different risk to manage.

Myth: an account setting is optional, we can set it per container

Fact: On Azure, the account-level setting overrides the container setting. If the account disallows anonymous access, no container can be public. If you manage container by container, one mistake creates exposure. Account level is the stronger place for the control.

Myth: we would notice a public bucket

Fact: Without logging, you may not. Azure recommends analyzing storage logs for anonymous requests before changing settings, and Google's Data Access audit logs are off by default except for BigQuery. Turn on the logs that let you answer who read what.

What to do instead of trusting defaults

1. Enforce at the top. Account or organization level settings: S3 Block Public Access, Azure's AllowBlobPublicAccess set to false, Google's public access prevention policy.
2. Make exceptions explicit. Put intentionally public content in a separate account or project with a named owner.
3. Audit with a policy. Azure Policy can audit or deny. Equivalent controls exist at other providers.
4. Log reads. Enable the logs that record data access for sensitive storage.
5. Review other grant paths. Identity policies, key policies and shared links.

Where Safeguard fits

Safeguard's policies, gates and guardrails apply to the software side of this problem, such as stopping a risky change before it merges, and its compliance and evidence automation can record that storage controls were checked. The storage settings themselves remain in your cloud provider.

Quick check

Sources

• Blocking public access to your Amazon S3 storage
• Remediate anonymous read access to blob data
• Public access prevention
• Cloud Audit Logs overview

Last reviewed: 19 October 2026.