> ## Content Index > Fetch the complete content index at: https://secblog.reedcloudsec.com/llms.txt > Use this file to discover other available public pages before exploring further. # Google Cloud Storage Hardening Cheat Sheet - URL: https://secblog.reedcloudsec.com/google-cloud-storage-hardening-cheat-sheet/ - Published: 2026-09-24T20:10:00.000Z - Updated: 2026-09-24T20:19:05.000Z - Description: The third cheat sheet in the set: a checklist for locking down Google Cloud Storage, from public access prevention and uniform bucket-level access to encryption, recovery, and logging, plus a gotcha where enforcement masks public grants instead of removing them. - Author: Marselis A. Reed - Tags: Cloud Security & Hardening *The third in the set, after AWS S3 and Azure Blob Storage — access, encryption, recovery, and logging for Cloud Storage, mapped to the CIS Google Cloud Platform Foundation Benchmark where a control exists. Baseline as of September 2026.* Cloud Storage fails the way S3 and Blob Storage do: a public grant nobody meant to keep, a permission model nobody can fully reason about, and logs nobody turned on. This is a working checklist pulled from Google's own documentation, not a substitute for reading it. ## What changed recently Three 2026 changes from Google's release notes are worth knowing: - **March 12:** uploads that use a customer-managed encryption key (CMEK) now fail if the Cloud Storage service agent lacks the IAM role to decrypt with that key. Check that the agent still holds the role, or writes will start failing. - **April 2:** administrators can configure which encryption types are permitted when creating objects in a bucket, so a bucket can be restricted to the methods you approve. - **August 17:** when a project is deleted, buckets with soft delete enabled are retained temporarily instead of being removed outright, and return to their previous state if the project is restored. ## Worth flagging: public access prevention masks a public grant instead of deleting it Enforcing public access prevention blocks access granted to `allUsers` and `allAuthenticatedUsers`, but Google's docs note that existing public IAM policies stay in place and are simply overridden. Turn enforcement off later and those old grants are live again. Enforcement can also take up to 10 minutes to apply, and signed URLs bypass it by design. Remove the bindings; don't just mask them. ## Access control - \[ \] **Public access prevention** enforced on every bucket and set through the `storage.publicAccessPrevention` organization policy, so new buckets inherit it — CIS v1.2.0 control 5.1 - \[ \] Existing `allUsers` and `allAuthenticatedUsers` bindings **audited and removed**, not just overridden (see above) - \[ \] **Uniform bucket-level access** enabled, so ACLs are off and IAM is the only permission model, and enforced with the "Require uniform bucket-level access" organization policy. It can no longer be turned off after 90 consecutive days, so confirm before it locks in — CIS v1.2.0 control 5.2 - \[ \] Permissions granted to **groups**, not long lists of individual users - \[ \] No publicly writable buckets — Google warns they get abused to distribute malware and illegal content - \[ \] Time-limited **signed URLs** for sharing instead of public grants; they bypass public access prevention by design, so control who can sign them - \[ \] Bucket names carry a random suffix and no sensitive detail ## Encryption - \[ \] Default Google-managed encryption confirmed — it's always on, with nothing to enable - \[ \] **CMEK** through Cloud KMS where you need control over the key; the key ring must sit in the same location as the bucket, and only symmetric keys qualify - \[ \] Key lifecycle protected like the data: a **destroyed** key version that still protects objects means permanent data loss, and a disabled one blocks reads, copies, and rewrites - \[ \] Nothing sensitive in object or bucket **names and metadata** — they aren't encrypted with your CMEK - \[ \] CMEK service agent still holds its decrypt role, since uploads now fail without it - \[ \] Permitted encryption types restricted where the April 2026 control fits ## Versioning & recovery - \[ \] **Soft delete** kept on (default 7 days, adjustable from 7 to 90) and lengthened for critical buckets. It recovers deleted objects and buckets, though soft-deleted data keeps accruing storage charges - \[ \] **Object versioning** enabled where overwrites matter, with a Lifecycle rule to prune old versions. It doesn't protect against bucket deletion, which soft delete does - \[ \] **Retention policy with Bucket Lock** for regulated data and log buckets. Locking is irreversible and places a lien on the project, so validate the retention period first — CIS v1.2.0 control 2.3 ## Network & perimeter - \[ \] **VPC Service Controls** perimeter around Cloud Storage, so stolen credentials can't be used from outside it and data can't be copied out to external buckets; run it in dry-run mode first ## Logging & monitoring - \[ \] Admin Activity logs are always on, but **Data Access audit logs are off by default**; enable `DATA_READ` and `DATA_WRITE` (and `ADMIN_READ` where needed) for Cloud Storage in projects that hold sensitive data, and watch the volume and cost - \[ \] A log-based metric and alert on Cloud Storage IAM permission changes — CIS v1.2.0 control 2.10 - \[ \] Remember that audit logs don't record access to public objects — another reason to keep buckets private ## A note on the control numbers The CIS numbers above come from the CIS Google Cloud Platform Foundation Benchmark **v1.2.0** (May 2021), verified against the benchmark itself: 5.1 (buckets not anonymously or publicly accessible), 5.2 (uniform bucket-level access), 2.3 (Bucket Lock retention on log buckets), and 2.10 (log metric and alert for Cloud Storage IAM changes). The benchmark has since been revised, and a secondary source lists the current version as 4.0.0 (May 2025), but whether the numbering is unchanged couldn't be confirmed. Check which version an audit cites before assuming a control number lines up. ## Same tool, same job Cloud Custodian, from the OSS & Tooling Spotlight, isn't AWS-only: its GCP provider covers Cloud Storage too. The pattern from the S3 and Azure cheat sheets applies here as well — codify the access-control items above as YAML policies instead of re-auditing them by hand every quarter. --- **Sources:** [Google Cloud: Public access prevention](https://docs.cloud.google.com/storage/docs/public-access-prevention?ref=secblog.reedcloudsec.com) · [Google Cloud: Uniform bucket-level access](https://docs.cloud.google.com/storage/docs/uniform-bucket-level-access?ref=secblog.reedcloudsec.com) · [Google Cloud: Soft delete](https://docs.cloud.google.com/storage/docs/soft-delete?ref=secblog.reedcloudsec.com) · [Google Cloud: Object Versioning](https://docs.cloud.google.com/storage/docs/object-versioning?ref=secblog.reedcloudsec.com) · [Google Cloud: Bucket Lock and retention policies](https://docs.cloud.google.com/storage/docs/bucket-lock?ref=secblog.reedcloudsec.com) · [Google Cloud: Customer-managed encryption keys](https://docs.cloud.google.com/storage/docs/encryption/customer-managed-keys?ref=secblog.reedcloudsec.com) · [Google Cloud: Cloud Storage audit logging](https://docs.cloud.google.com/storage/docs/audit-logging?ref=secblog.reedcloudsec.com) · [Google Cloud: VPC Service Controls overview](https://docs.cloud.google.com/vpc-service-controls/docs/overview?ref=secblog.reedcloudsec.com) · [Google Cloud: Cloud Storage best practices](https://docs.cloud.google.com/storage/docs/best-practices?ref=secblog.reedcloudsec.com) · [Google Cloud: Cloud Storage release notes](https://docs.cloud.google.com/storage/docs/release-notes?ref=secblog.reedcloudsec.com) · [CIS Google Cloud Platform Foundation Benchmark](https://www.cisecurity.org/benchmark/google%5Fcloud%5Fcomputing%5Fplatform?ref=secblog.reedcloudsec.com)