Introduction to Storage Security
Securing data at rest involves more than just encryption. In Google Cloud, Cloud Storage and Secret Manager are the two primary services for storing persistent objects and sensitive configuration data (like API keys and database passwords).
For the PSE, you must understand how to enforce compliance through retention policies, manage access through granular IAM, and protect against data loss or unauthorized disclosure.
白話文解釋（Plain English Explanation）
Bucket Lock 像保險箱的時間鎖
A bank vault with a time-delay lock opens only after the timer expires — even the bank manager cannot crack it open early. Bucket Lock with a 7-year retention policy works the same way: once you commit (gsutil retention lock), neither the Project Owner, the Org Admin, nor even Google Support can shorten or remove the policy. Until every single object in the bucket has aged past its retention timer, the bucket itself cannot be deleted. This is exactly what regulators like SEC Rule 17a-4 and FINRA demand for WORM (Write Once, Read Many) compliance.
Secret Manager 像銀行保管箱（Safe Deposit Box）
A safe deposit box at a bank has three roles: the bank manager can rent out or destroy boxes (Secret Manager Admin), the keyholder can open the box and read its contents (Secret Manager Secret Accessor), and the lobby visitor can see the directory of box numbers but cannot open any (Secret Manager Viewer). A common production mistake is granting roles/secretmanager.admin when the app only needs to read the payload — give the Compute Engine default service account only secretAccessor and scope it to one specific secret resource, not the whole project.
Signed URL 像演唱會電子票
A Signed URL is like an e-ticket for one specific seat at a concert — it works for a few hours, lets one person in, then expires. You generate it with gsutil signurl -d 1h key.json gs://bucket/object or via the V4 signing process backed by a service account. The recipient does not need a Google account, but they also cannot extend the expiry or re-use the URL after it lapses. Signed Policy Documents are the upload equivalent: they let a browser POST a file directly to the bucket with constraints (max size, MIME type) without ever touching your backend.
Cloud Storage: Hardening the Bucket
1. Access Control: Uniform vs. Fine-grained
- Uniform Bucket-Level Access: Disables ACLs and uses only IAM for access control. This is the recommended practice for simplified and consistent security.
- Fine-grained (ACLs): Allows setting permissions on individual objects. This can lead to "confused deputy" problems and is harder to audit.
Use the Organization Policy storage.uniformBucketLevelAccess to enforce uniform access across your entire project or organization.
2. Public Access Prevention
Accidental public exposure is a leading cause of data breaches.
- Public Access Prevention (PAP): A bucket-level setting that blocks all public access, even if ACLs or IAM roles suggest otherwise.
- Org Policy:
storage.publicAccessPreventioncan enforce this globally.
Granting allUsers or allAuthenticatedUsers the roles/storage.objectViewer role does NOT trigger PAP retroactively — PAP only blocks new public bindings after it is enabled. Audit existing bindings with gcloud projects get-iam-policy and remove legacy public ACLs before enabling PAP, or you will have a false sense of security.
3. Signed URLs and Signed Policy Documents
When you need to give temporary access to a user without a Google account:
- Signed URL: Provides time-limited access (e.g., 1 hour) to a specific object.
- Signed Policy Document: Allows a user to upload files to a bucket with specific constraints (size, type) for a limited time.
Data Integrity and Compliance
Bucket Lock and Retention Policies
For regulatory compliance (e.g., SEC Rule 17a-4), you can use Bucket Lock.
- Retention Policy: Specifies a minimum time objects must be kept (e.g., 7 years).
- Bucket Lock: Once locked, the retention policy cannot be reduced or removed, and the bucket cannot be deleted until all objects have met the retention period.
Bucket Lock is irreversible. Even a Project Owner or Organization Admin cannot delete a locked bucket if it contains objects under retention.
Object Versioning and Ransomware Protection
- Object Versioning: Keeps a history of changes. If an object is accidentally deleted or overwritten by ransomware, you can restore a previous version.
- Non-current Version Retention: You can combine versioning with Lifecycle Management to keep old versions for a specific duration.
Secret Manager: Managing Sensitive Data
Secret Manager is the centralized "Source of Truth" for secrets.
1. Versioning and Lifecycle
Secrets are versioned. Applications should ideally point to a specific version or use the latest alias (though latest can be risky in production if not handled carefully).
- Rotation: You can configure Secret Manager to automatically rotate secrets (e.g., updating a database password) using Cloud Functions.
2. IAM for Secret Manager
- Secret Manager Admin: Can manage the secret itself (delete/rotate).
- Secret Manager Secret Accessor: Can read the secret payload.
- Secret Manager Viewer: Can see metadata but not the secret value.
Secret Manager is a secure and convenient storage system for API keys, passwords, certificates, and other sensitive data. It provides a single source of truth for secrets across Google Cloud.
Integration with Compute Services
- Cloud Run / Functions: Can mount secrets as environment variables or volumes. Mounting as a volume is generally more secure than environment variables.
- GKE: Use the External Secrets Operator or Secret Store CSI Driver to sync Secret Manager secrets into Kubernetes Secrets without storing them in
etcd.
Auditing Access
Every access to a secret or a storage object is logged in Cloud Audit Logs (if Data Access logs are enabled).
- Storage:
storage.objects.get,storage.objects.create. - Secret Manager:
secretmanager.versions.access.
Bucket Lock, Retention Policies, and WORM Compliance Deep Dive
Retention Policy vs. Object Hold vs. Bucket Lock
Three independent mechanisms enforce immutability — exam questions hinge on knowing which one applies:
| Mechanism | Scope | Reversible? | Use Case |
|---|---|---|---|
| Retention Policy (unlocked) | Bucket | Yes, can shorten | Internal data hygiene |
| Bucket Lock | Bucket | No | SEC 17a-4, FINRA, MiFID II |
| Event-Based Hold | Per object | Yes (release event) | Litigation pending event |
| Temporary Hold | Per object | Yes | Investigation hold |
Signed URL Internals
A V4 Signed URL is generated by hashing the canonical request (method, headers, expiry) with the signing service account's private key. Two important properties:
- The signer's IAM permissions are what's granted — if the signing SA loses
storage.objects.get, existing URLs continue to work until they expire (the signature is already issued). - For zero-key signing, the caller needs
iam.serviceAccounts.signBlobon the signing SA and callsiamcredentials.googleapis.com/v1/projects/-/serviceAccounts/<sa>:signBlob.
Why Bucket Lock Beats Object Lifecycle for Compliance
Object Lifecycle Management can be edited or disabled at any time — auditors will reject it as a compliance control. Bucket Lock with a locked retention policy is the only Cloud Storage feature certified for SEC Rule 17a-4(f) WORM electronic records, as confirmed by Google's third-party Cohasset Associates assessment.
Once a retention policy is locked with gsutil retention lock gs://my-bucket, the only way to delete the bucket is to wait for every object to age past the retention period. Plan capacity carefully — a 7-year lock on a 100 TB bucket means 7 years of storage cost minimum.
Secret Manager Versions, Replication, and CMEK
Version Lifecycle States
Each secret has a chain of versions, each in one of three states:
- ENABLED: Readable via
secretmanager.versions.access. Default for new versions. - DISABLED: Not readable, but the ciphertext is retained. Reversible — flip back to ENABLED.
- DESTROYED: Underlying material is permanently erased. Irreversible. Metadata remains for audit.
The latest alias resolves to the highest-numbered ENABLED version. If you disable v5, latest falls back to v4 — useful for instant rollback on bad rotations.
Replication: Automatic vs. User-Managed
At secret-creation time you pick a replication policy that cannot be changed later:
- Automatic Replication: Google stores the secret in multiple regions chosen for you. Use for global apps; simplest to operate.
- User-Managed Replication: You list specific regions (e.g.,
us-central1,europe-west4). Required for data residency / sovereignty mandates (GDPR, FedRAMP, data localization laws) where the payload must not leave a defined geography.
Customer-Managed Encryption Keys (CMEK)
By default, Secret Manager encrypts payloads with Google-managed keys. To meet stricter compliance:
- With user-managed replication, you can specify a Cloud KMS key per replica region. The KMS key must live in the same region as the replica, or Secret Manager will reject the binding.
- Grant
roles/cloudkms.cryptoKeyEncrypterDecrypterto the Secret Manager service agent (service-<project-number>@gcp-sa-secretmanager.iam.gserviceaccount.com) on each key. - Disabling or destroying the KMS key renders all dependent secret versions inaccessible — treat KMS key destruction as the equivalent of destroying the secret.
IAM secretAccessor Scope
Apply roles/secretmanager.secretAccessor at the secret resource level, not the project level:
gcloud secrets add-iam-policy-binding db-password \
--member="serviceAccount:[email protected]" \
--role="roles/secretmanager.secretAccessor"
Granting at the project level lets the principal read every secret in the project — a classic least-privilege violation flagged by Security Command Center's IAM_SCANNER detector.
WORM trio for PSE: Retention Policy (the timer) + Bucket Lock (the irreversibility) + Object Versioning (the rollback). Pair all three for ransomware-resistant compliant archives. Without versioning, an attacker who gains write access can still overwrite objects in place during their retention window.
PSE Exam Scenarios
Scenario 1: Preventing Accidental Deletion
"A company needs to ensure that financial records stored in GCS cannot be deleted by anyone, including the administrator, for a period of 5 years to satisfy legal requirements. What should you do?" Answer: Create a Cloud Storage bucket, set a Retention Policy of 5 years, and then Lock the Bucket.
Scenario 2: Secure Secret Delivery to GKE
"How should you provide a database password stored in Secret Manager to a containerized application running on GKE in the most secure way?" Answer: Use the Secret Store CSI Driver. This allows the GKE pod to access the secret directly from Secret Manager as a mounted volume, ensuring the secret is never written to the GKE node's disk or stored insecurely in the Kubernetes API.
Summary Checklist
- Contrast Uniform Bucket-Level Access with ACLs.
- Explain how Bucket Lock enforces WORM (Write Once, Read Many) compliance.
- Describe the use case for Signed URLs.
- Identify the IAM role required to read a secret's value.
- Explain the benefits of secret rotation with Cloud Functions.
- List techniques for protecting GCS against ransomware.