Object storage is the default data dump for most cloud workloads. It's also consistently the source of the most severe data breaches I see in audit logs. The defaults are terrible across all three providers.
Here is a methodical approach to lock down buckets in AWS S3, Google Cloud Storage, and Azure Blob Storage. This is the baseline configuration I look for during a SOC 2 audit. Anything less is a finding.
**First, the universal principles (non-negotiable):**
* Block all public access at the account/tenant level. This is the single most important control.
* Enforce bucket-level IAM policies that explicitly deny actions not originating from your VPC or authorized identities. Principle of least privilege is not a suggestion.
* Enable comprehensive, immutable logging and monitoring. All management and data events must go to a separate, secured logging bucket.
* Default encryption must be enabled with customer-managed keys (CMK). Provider-managed keys are insufficient for any regulated data.
**Provider-specific critical configurations:**
**AWS S3:**
* Use the `aws:SecureTransport` condition in your bucket policy to deny non-HTTPS requests.
* Apply the `s3:ResourceAccount` condition to restrict access to resources owned by your specific AWS account.
* Enable S3 Block Public Access (all four settings) and ensure no bucket policy overrides it.
* Disable S3 ACLs unless you have a documented legacy requirement.
**Google Cloud Storage:**
* Enforce Uniform Bucket-Level Access. Disable legacy ACLs entirely.
* Use VPC Service Controls to create a perimeter and prevent data exfiltration.
* Configure retention policies and object holds for data immutability where required.
* Leverage the `conditions` in IAM policies with attributes like `resource.name` for granular control.
**Azure Blob Storage:**
* Enable the "Allow storage account key access" firewall setting to "Disabled". Rely on Azure AD, SAS, or managed identities only.
* Configure the network rules to allow access only from specific VNets or IP addresses.
* Enable soft delete and blob versioning. The immutability policies (legal holds/time-based retention) are non-negotiable for sensitive archives.
* Require the `AllowSharedKeyAccess` parameter to be set to `false` on the storage account.
The common failure pattern is treating the bucket like a filesystem. It is not. Every object is a potential endpoint. Your logging must be capable of detecting `GetObject` anomalies, not just bucket configuration changes.
Where is your SOC 2?