Security & Compliance

A contractor can read a production bucket, customer data must never leave the EU, a downloaded service account key has leaked. Each scenario states a risk, and the right answer is rarely a single product. It is the layer that owns that risk, and once you name the layer the service is almost forced. Google Cloud splits security into layers that each answer a different question: IAM (Identity and Access Management) answers who can act; the resource hierarchy and Organization Policy answer what is allowed and where; the network layer (VPC Service Controls, firewall policies, Identity-Aware Proxy) answers what can talk to what; and the data layer (encryption keys, Secret Manager, Sensitive Data Protection) protects the records themselves. The classic trap is reaching for one control, usually IAM, to fix a risk that lives one layer over. A caller with perfectly scoped IAM can still exfiltrate data across a project boundary, which is why VPC Service Controls exists as a separate ceiling. Match the risk to the layer first, and the design follows.

Security Design is the larger half. It walks the four layers in the order you would architect them, under the names that page uses. Start with Governance, the resource hierarchy, because organization, folders, and projects are the unit of governance and both IAM and Organization Policy flow down that tree. Layer Identity (IAM) on top to grant who-can-do-what, remembering that a deny policy always beats an allow. Add the Perimeter & context layer (a VPC Service Controls perimeter to stop exfiltration, IAP for VPN-less app and SSH access) and Data protection (CMEK when you must own the key, Secret Manager for secrets, keyless identity via Workload Identity Federation). Compliance is the second half, and it is a different shape: it starts from a named regulation. Compliance on Google Cloud is a shared responsibility, where Google certifies the platform and you configure the workload, so the framework dictates the data, the geography, and the contract you need. It separates residency (where data sits) from sovereignty (who can reach it), reaches for Assured Workloads when a scenario needs location and access and personnel guarantees together, and proves all of it with Cloud Audit Logs and Google's published reports.

The Well-Architected Framework security pillar is the default tie-breaker across this whole domain. Prefer the design that grants the least standing access and leaves the cleanest audit trail. That means short-lived federated identity over a long-lived service account key, predefined or custom roles over the broad basic roles (Owner, Editor, Viewer), a deny policy or Organization Policy constraint to set a hard ceiling rather than trusting every grant below it, and enabling Data Access audit logs (off by default) when a scenario asks you to prove who read sensitive data. If one answer removes a standing credential or adds provable evidence and the other does not, that is usually the intended choice.