Cloud Storage Security Checklist — UprootSecurity Bootcamp

Keep this bookmarked

This is a reference you'll come back to whenever you review, harden, or collect evidence on cloud object storage. It is built for scanning, not reading end to end. Use it as a lookup when you need the control, its equivalent across S3 / GCS / Azure Blob, the evidence that proves it, and the framework it maps to. It distills Modules 4.1 and 4.3 into a working audit checklist.

The cross-cloud control map

The same control under three names. When you audit any bucket, walk this list top to bottom.

Control	AWS S3	GCP Cloud Storage	Azure Blob
Block public access	S3 Block Public Access (account + bucket)	Public Access Prevention (org policy + bucket)	Disable "allow blob public access" + network rules
Access model	Bucket policy + IAM; disable ACLs	IAM + Uniform bucket-level access	Azure RBAC; scoped SAS tokens
Default encryption	SSE-S3, or SSE-KMS with a CMK	Google-managed, or CMEK	Microsoft-managed, or customer-managed key
Enforce encryption on write	Bucket policy `Deny` if `s3:x-amz-server-side-encryption` absent	Org policy / constraints	Storage policy
Enforce TLS-only	Bucket policy `Deny` if `aws:SecureTransport` false	`Deny` via IAM condition / org policy	"Secure transfer required" setting
Versioning	S3 Versioning	Object Versioning	Blob versioning + soft delete
Immutability (WORM)	S3 Object Lock	Bucket Lock / retention policy	Immutable blob storage
Access logging	Server access logging + CloudTrail data events	Cloud Audit Logs (data access)	Storage logs / Azure Monitor
Lifecycle / retention	S3 Lifecycle rules	Object Lifecycle Management	Blob lifecycle management
Config monitoring	AWS Config / Security Hub	Security Command Center	Azure Policy / Defender for Cloud

The per-bucket review checklist

For every bucket holding or capable of holding sensitive data, confirm each line — and capture the named evidence.

ACCESS
[ ] Public access blocked at account/org level (preventive guardrail)
[ ] Bucket not public — or public is intentional, documented, no sensitive data
[ ] ACLs disabled; access expressed as IAM/bucket policy
[ ] Access is least-privilege (specific actions, specific principals)
[ ] External sharing via scoped roles or time-limited signed URLs, not public

ENCRYPTION
[ ] Default encryption enabled (every new object encrypted)
[ ] Sensitive data uses a customer-managed key (CMK/CMEK)
[ ] No unencrypted existing objects (remediated)
[ ] Encryption enforced on write via policy
[ ] TLS-only access enforced via policy

RESILIENCE
[ ] Versioning enabled on critical/customer/backup data
[ ] Immutability (Object Lock / WORM) on backups + critical data
[ ] Lifecycle rules manage retention and cost
[ ] Replication destinations meet the SAME bar (encryption, access, logging)

VISIBILITY
[ ] Access logging / data-access audit logs enabled
[ ] Logs flow to a monitored, retained location
[ ] Config monitoring rule alerts on public access / missing encryption / missing logging

Per-bucket security review — check each, capture the evidence

Evidence map — what proves each control

When an auditor asks, these are the artifacts that demonstrate the control operates, not just that it's configured once.

Control area	Evidence to collect
No public exposure	Config-scan inventory showing zero unintended public buckets + account block-public-access enabled
Least-privilege access	Bucket/IAM policies for each sensitive bucket; ACLs-disabled setting
Encryption coverage	Default-encryption config + key (CMK) per bucket; coverage report incl. backups/replicas
Key control	KMS key policy (admin vs decrypt separation) + key-access log sample
Recoverability	Versioning + Object Lock settings; restore test result
Logging	Access-logging enabled config + a sample of access-log entries (who/what/when)
Continuous monitoring	Config rule ARNs/IDs + a sample alert from a test violation

Framework mapping

The same storage evidence is reusable across frameworks — collect it once.

Framework	Relevant controls
SOC 2	CC6.1 (logical access to data), CC6.7 (protecting data at rest and in transit)
ISO 27001:2022	A.5.33 (protection of records), A.8.24 (use of cryptography), A.8.3/A.8.4 (information & source-code access), A.8.12 (data leakage context)
PCI DSS	Requirement 3 (protect stored data), Requirement 4 (encrypt transmission), key-management requirements
NIST 800-53	SC-12/SC-13 (key management, cryptographic protection), SC-28 (protection at rest), AU-2/AU-12 (audit logging)

Top failure modes (memorize these)

The recurring object-storage findings, in rough order of how often they cause real exposure:

Bucket made public for a test, never reverted — block public access at the account level to make this impossible.
Over-broad IAM (s3:* on everything) — scope to least privilege; one compromise shouldn't reach all data.
Default encryption off — objects land in plaintext depending on the writer.
No access logging — exposure goes unnoticed and can't be investigated.
No versioning — an overwrite/delete or ransomware is unrecoverable.
Backups/replicas held to a weaker standard — the soft copy attackers target.
"Authenticated Users" ACL — often means everyone, not just your users.
TLS not enforced — data can be read in transit to/from the bucket.

GRC Engineer's lens

Storage security is the rare domain where one report — a config-scan inventory of public-access, encryption, logging, and versioning status across every bucket — answers most of the audit. Build that inventory, turn it into a continuous config rule that alerts on drift, and you've converted a recurring scramble into a standing control. The whole checklist above reduces to one habit: for every bucket, know whether it's exposed, who can read it, whether it's encrypted and logged, and whether you'd recover from a bad day — and have the artifact that proves each answer.