How to Prevent Data Breaches in Public Cloud Storage

Major cloud storage services like Amazon S3, Azure Blob Storage, and Google Cloud Storage are highly secure by design. However, they operate under the Shared Responsibility Model. If a customer configures a bucket to be publicly readable, the cloud provider will dutifully serve that data to anyone on the internet.

Misconfigured object storage is consistently ranked as one of the leading causes of massive data leaks. Here is how to lock down public cloud storage and prevent breaches.

1. Block Public Access at the Account Level

Developers often make individual buckets public temporarily for testing, then forget to revert the settings. Relying on bucket-by-bucket configurations is a recipe for a breach.

• AWS: Enable S3 Block Public Access at the account or organization level. This acts as a master override, ensuring that even if a developer sets a bucket policy to public, the account-level block will prevent the exposure.

• Azure: Set the Allow Blob public access property to False at the storage account level.

• GCP: Enforce the Enforce Public Access Prevention organization policy constraint.

2. Enforce Strict IAM and Resource Policies

Storage security relies on a combination of identity-based policies (what a user can do) and resource-based policies (who can access the bucket).

• Deny by Default: Start with a zero-trust approach. Deny all access and explicitly grant permissions only to the roles or service accounts that require it.

• Use VPC Endpoints: Prevent storage traffic from traversing the public internet. Configure Virtual Private Cloud (VPC) endpoints (e.g., AWS S3 Gateway Endpoints, Azure Private Link) so that only traffic originating from within your private network can reach the storage bucket.

• Avoid Wildcards: Never use Principal: "*" in a bucket policy unless hosting public, non-sensitive website assets.

3. Encrypt Everything (At Rest and In Transit)

If a bucket is somehow compromised or a disk is physically stolen, encryption ensures the data remains unreadable.

• At Rest: Enforce Server-Side Encryption (SSE). Use Customer Managed Keys (CMK) via your provider’s Key Management Service (KMS) so you can audit exactly who and what is attempting to decrypt your data.

• In Transit: Enforce aws:SecureTransport (or provider equivalent) in your bucket policies to reject any HTTP requests, mandating TLS 1.2 or 1.3 for all data transfers.

4. Enable Versioning and Object Lock

A data breach isn’t just about theft; ransomware and accidental deletion are equally destructive.

• Versioning: Automatically keeps multiple variants of an object in the same bucket. If a malicious actor overwrites your data, you can simply restore the previous version.

• Object Lock (WORM): Write-Once-Read-Many (WORM) policies make data completely immutable for a specified retention period. Even a user with root administrator privileges cannot delete or alter the data until the lock expires.

5. Continuously Monitor and Audit

You cannot secure what you cannot see. Automated monitoring is essential for catching misconfigurations before attackers do.

• Data Loss Prevention (DLP): Use native tools like Amazon Macie, Google Cloud DLP, or Microsoft Purview to continuously scan your buckets for sensitive data (PII, credit cards, credentials) and alert you if they are stored in inappropriate locations.

• Access Logging: Enable server access logging and CloudTrail/Audit logs to track every GET, PUT, and DELETE request. Pipe these logs to your SIEM for anomaly detection (e.g., a sudden spike in data egress to an unknown IP).

Cloud Storage Security Checklist