Designing for security and compliance

Identity and Access Management

The model

An allow policy binds principals (Google accounts, groups, service accounts, workforce and workload identity pool identities, domains) to roles on a resource. Policies are inherited down the hierarchy and are additive: access is the union of grants from organization, folders, project and resource. A lower level cannot remove an inherited allow; use deny policies (which win over allow) or IAM conditions instead.

Other IAM features:

• IAM Conditions: grant a role only if a condition holds (time window, resource name or tag, request attributes). Tags bound to resources let conditions and organization policies target subsets such as env=prod.
• Deny policies: block specific permissions for principals regardless of allows; use for guardrails (“nobody except the security group may delete log buckets”).
• Principal access boundary policies limit which resources a principal can access.
• Privileged Access Manager (PAM): time-bound, just-in-time, approved elevation instead of standing admin roles.
• IAM Recommender (right-sizing excess permissions) and Policy Analyzer / Policy Troubleshooter answer “who can access this” and “why was this denied”.
• Grant roles to groups, not individuals. Manage groups through Cloud Identity or Google Workspace, synced from Active Directory with Google Cloud Directory Sync (the EHR scenario), with federated single sign-on through SAML or OIDC to the corporate identity provider.

Service accounts

• A service account is an identity for a workload. Prefer attached service accounts (VMs, GKE through Workload Identity, Cloud Run) which use short-lived tokens from the metadata server, with no downloadable keys. Organization policy iam.disableServiceAccountKeyCreation enforces this.
• Create a dedicated service account per workload with minimal roles; never use the default Compute Engine or App Engine service accounts for production.
• Service account impersonation (roles/iam.serviceAccountTokenCreator) lets a person or another account act as a service account using short-lived credentials, so no keys are shared and actions are audited. roles/iam.serviceAccountUser lets a principal attach a service account to a resource. Both are powerful: treat them as admin-like.
• Workload Identity Federation lets external workloads (AWS, Azure, GitHub Actions, GitLab, on-premises OIDC or SAML) obtain Google credentials by exchanging their own tokens; no service account keys at all. Workforce Identity Federation does the same for employees from an external IdP without Cloud Identity accounts. Workload Identity Federation for GKE maps Kubernetes service accounts to Google identities.
• If a key must exist, rotate it, restrict it and watch for leaks. Prefer to remove the need.

Separation of duties

No single person should be able to both create and approve, or to administer and audit. Examples: separate organization administrator, network administrator (owns Shared VPC), security administrator, billing and log viewer/auditor groups; developers get project-level roles only; the group that manages keys (Cloud KMS Admin) is not the group that uses them (Encrypter/Decrypter); logging sinks in a dedicated project the app teams cannot alter.

Resource hierarchy and organization policy

The hierarchy is organization, folders, projects, resources. Use folders to mirror environments or business units so you can apply IAM, organization policy and hierarchical firewall policy once. Typical layout: folders for prod, non-prod, shared services, security; a separate network host project and a logging project. Projects are the unit of billing, quota and API enablement, and a boundary for blast radius.

Organization Policy Service sets constraints inherited by descendants (it controls what can be configured, where IAM controls who can configure). Frequently used constraints:

Hierarchical firewall policies applied at organization or folder level take precedence over VPC rules and can delegate (goto_next) decisions to lower levels. Use them for mandatory rules such as blocking known-bad ranges or permitting IAP and health-check ranges everywhere.

Cloud Asset Inventory, Security Command Center (SCC) (misconfiguration, vulnerability and threat findings; Premium and Enterprise tiers add compliance monitoring against CIS and others, and Event Threat Detection) and Security Health Analytics tell you whether the guardrails hold. Assured Workloads creates folders configured for a compliance regime (FedRAMP, CJIS, IL, EU sovereign controls) with matching organization policies and support personnel limits.

Data security: encryption, keys and secrets

Encryption options

Cloud KMS

• Hierarchy: key ring (location, cannot be deleted) contains keys that have versions. The key and its location should match the data location (a regional key for regional data; key ring location must be compatible with the resource).
• Automatic rotation schedule creates new primary versions; old versions stay available to decrypt old data. Rotation does not re-encrypt existing data by itself. Destroying a key version is scheduled (default 24 hours) and then irreversible: data becomes unreadable.
• Permissions: cloudkms.admin manages keys; cloudkms.cryptoKeyEncrypterDecrypter uses them. Grant the service agent of the service (for example the Cloud Storage or Compute service agent) the encrypter/decrypter role on the key.
• Autokey automates creation of CMEK keys on demand under policy. Key Access Justifications (with EKM) states why Google requested key access. Organization policy constraints/gcp.restrictNonCmekServices and constraints/gcp.restrictCmekCryptoKeyProjects require CMEK usage and where keys come from.
• Keep keys in a separate project administered by security staff, not by the project owners whose data they protect.

Secrets and sensitive data

• Secret Manager stores API keys, passwords and certificates with versions, IAM per secret, automatic rotation notifications, replication policy (automatic or user-chosen regions), and audit logging. Never put secrets in code, environment files in repositories, or container images. Mount or reference secrets from Cloud Run, GKE (Secret Manager add-on or CSI driver) or Cloud Build.
• Sensitive Data Protection (formerly Cloud DLP) inspects for over 150 built-in infotypes (credit card numbers, national IDs, emails), then de-identifies by masking, tokenisation, format-preserving encryption or bucketing, and can re-identify with the key. Use it on Cloud Storage, BigQuery and Datastore, in streaming pipelines before data lands, and with discovery scans that profile data across the organization. It is the answer for “find and mask PII/PHI/card data before analysts see it”.
• Certificate Authority Service for private CAs; Certificate Manager for public TLS certificates at load balancers.

Security controls

Audit logging

• Cloud Audit Logs: Admin Activity (always on, free, cannot be disabled), System Event (always on), Data Access (off by default except BigQuery; enable per service for reads and writes of user data; can be large and costly), and Policy Denied. Access Transparency logs actions by Google staff; Access Approval lets you approve them first.
• Route logs with log sinks to Cloud Storage (cheap archive, with retention lock), BigQuery (analysis), Pub/Sub (streaming to a SIEM such as Splunk or Google SecOps), or another log bucket. An aggregated sink at organization or folder level captures every project including new ones, and is the answer for “central, tamper-resistant logs for all projects”. Store them in a dedicated project with restricted access.

VPC Service Controls

VPC Service Controls draws a service perimeter around projects and Google-managed services (BigQuery, Cloud Storage, and many more). Requests that would copy data across the perimeter, from the internet, or from outside allowed networks are blocked even if IAM would allow them, which stops data exfiltration by a compromised or malicious identity. Know:

• Access levels (from Access Context Manager) allow requests by IP range, device state, or identity; ingress and egress rules allow specified flows; bridges and perimeters share between projects; dry run mode logs violations before enforcing.
• It protects Google APIs, not VM-to-VM traffic. Use with restricted.googleapis.com and Private Google Access.
• Typical use: healthcare data in BigQuery must not be copied to a project outside the perimeter or read from outside the corporate network.

Context-aware access

Context-Aware Access grants access to applications and APIs based on who, device posture (managed, encrypted, patched, OS) and where from, evaluated per request through access levels and IAP or Google Workspace and Cloud Console access. Chrome Enterprise Premium (formerly BeyondCorp Enterprise) packages this zero-trust approach: device trust, threat and data protection in the Chrome browser, DLP controls, and agentless access to web apps through IAP.

Secure remote access

Network and platform hardening

Use private IPs, Private Service Connect, Cloud NAT, firewall by service account, Cloud Armor on every public endpoint, Shielded VMs, Confidential VMs where needed, Container-Optimized OS, and patch through VM Manager. Detect threats with SCC Event Threat Detection, Cloud IDS and Chronicle / Google SecOps for SIEM and SOAR.

Software supply chain security

• Artifact Registry stores container images and language packages, with vulnerability scanning (Artifact Analysis) on push, remote and virtual repositories to cache and control upstream sources, and cleanup policies.
• Cloud Build builds with provenance: SLSA build provenance attestations, build in a private pool, least-privilege build service account, dependencies pinned.
• Binary Authorization is a deploy-time control for GKE and Cloud Run: only images attested (signed) by trusted builders or after passing vulnerability checks are admitted; continuous validation rechecks running workloads. Use break-glass with audit for emergencies.
• Cloud Deploy gives controlled promotion across environments with approvals. Assured Open Source Software offers vetted, Google-built open source packages. Use SBOMs, and scan base images, and have developers sign commits and require code review.
• Secrets scanning in repositories and Secure Source Manager for hosted Git. Keep Terraform state and CI credentials locked down; use Workload Identity Federation for CI.

Securing AI

• Model Armor screens prompts and responses for prompt injection and jailbreaks, harmful content, malicious URLs, and sensitive data leakage (integrated with Sensitive Data Protection), for any model including those outside Google. This is the answer for “filter harmful content and protect against prompt injection” (the Altostrat case).
• Sensitive Data Protection de-identifies training data and prompts. Keep customer data out of tuning sets unless allowed; Google does not use customer data to train its foundation models without permission.
• Secure model deployment: private endpoints (Private Service Connect), IAM on endpoints, VPC Service Controls around the Agent Platform, CMEK on models and datasets, model registry with versioning and access control, Binary Authorization for serving containers, and audit logging of model access. Use Gemini safety settings and grounding, and keep humans in the loop for risky decisions.
• Auditability and explainability (Altostrat requires explainable decisions): Explainable AI feature attribution, model cards, evaluation, and logging of prompts and responses (with redaction) so decisions can be reviewed. Responsible AI controls: fairness checks, human review.

Designing for compliance

Legislation and regulation

Google Cloud provides compliance reports and certifications (SOC 1/2/3, ISO 27001/27017/27018, PCI DSS, HIPAA support, FedRAMP) in the Compliance Reports Manager. A certified platform does not make your application compliant; you must configure and operate yours properly.

Audits and logs

• Keep Admin Activity and Data Access logs for as long as regulation says. Route to locked Cloud Storage buckets (retention policy plus Bucket Lock) or a log bucket with a set retention. Use Log Analytics and BigQuery to query. Restrict who can read or delete them.
• Security Command Center compliance dashboards, Audit Manager for evidence generation, and Assured Workloads monitoring show deviation. Use Cloud Asset Inventory to prove configuration at a point in time.