Google Cloud Security Best Practices for Enterprise

Coordinate Security Controls Across the Platform

The first security problem in Google Cloud rarely looks dramatic. It usually looks ordinary: a broad IAM role, a default network nobody removed, a service-account key copied into CI, or a storage bucket that became public because “we’ll fix it later.”

Individually, each decision can look manageable. Across dozens of projects and teams, the same decisions turn into drift. One project uses groups for access, another grants roles directly to users. One workload uses keyless identity, another still carries a JSON key. One team has private networking, another exposes a public IP because it was faster.

That is why cloud security is not a checklist problem. It is an architecture problem. The controls have to reinforce one another and they have to arrive in the right order.

A useful way to think about the stack is simple: build the foundation, control identities, prevent unsafe configurations, contain network and data movement, harden workloads, secure the delivery path, and then continuously watch what the environment is doing.

Build the foundation before workloads arrive

Everything in Google Cloud lives inside the resource hierarchy: Organization → Folders → Projects → Resources. That hierarchy is more than administration. It determines where IAM, organization policies, logging, and governance can be applied once and inherited many times.

A flat estate is expensive to secure because every project becomes its own exception. A landing zone gives new workloads a safe place to land before teams start improvising.

For most enterprises, the Google Cloud Enterprise Foundations Blueprint is a better starting point than inventing the hierarchy, logging model, network pattern, and guardrails from scratch.

Organization
├── Shared Infrastructure
│   ├── Networking
│   └── Logging and Monitoring
├── Security
│   └── SCC, KMS, security tooling
├── Production
│   ├── Business Unit A
│   └── Business Unit B
├── Non-Production
│   ├── Staging
│   └── Development
└── Regulated Workloads

The practical payoff is inheritance. A policy placed at the organization or folder level becomes a default for everything below it. That is much easier to operate than asking every project owner to remember the same rule.

Limit Access With Separate Identities

If credentials are compromised, the attacker can usually do what that identity was allowed to do. That makes IAM design one of the clearest predictors of blast radius.

Human users: reduce standing privilege

Human access should come through Cloud Identity, Google Workspace, or Workforce Identity Federation where an existing corporate identity provider is used. MFA should be enforced, and access should be granted through groups rather than one-off user bindings wherever possible.

Broad basic roles such as Owner and Editor should not be normal production access. Use narrower predefined roles, and use Privileged Access Manager when someone occasionally needs elevated rights.

PAM changes the model from “you are always an admin” to “you can become an admin for a short, auditable window when there is a reason.” That is a much healthier default.

Workloads: stop creating credentials you then have to protect

Service-account JSON keys are easy to copy and hard to govern. If a workload can authenticate without a downloadable key, it should.

• Google Cloud workloads should use attached service accounts and platform-native identity.
• External CI/CD systems should use Workload Identity Federation for short-lived Google credentials.
• GKE workloads should use Workload Identity Federation for GKE rather than static keys in pods.

Putting a long-lived JSON key into Secret Manager is better than putting it in Git, but the key still exists. The strongest control is eliminating the key where keyless authentication is available.

Agents: treat them like software actors with real power

AI agents need identities too. If an agent can query data, call APIs, invoke tools, or change infrastructure, its permissions deserve the same scrutiny as a privileged workload—plus extra care for autonomous actions.

Prevent bad configurations before they exist

IAM answers “who is allowed to do this?” Organization Policy answers “should this configuration be allowed at all?” Those are different questions.

A person may have permission to create a VM. Organization Policy can still prevent that VM from receiving an external IP. A team may be allowed to create service accounts. Organization Policy can still block downloadable key creation.

Useful enterprise guardrails often include:

• blocking service-account key creation and upload;
• restricting IAM members to approved domains;
• requiring Shielded VM features where appropriate;
• preventing default network creation;
• enforcing uniform Cloud Storage access;
• restricting which VMs can receive external IP addresses.

Google applies a baseline set of policies automatically to newer organizations, but older estates should not assume the same protections exist. Audit what is actually configured.

Build boundaries, not just firewall rules

Network security is strongest when different controls solve different problems. Shared VPC centralizes network administration. Private connectivity reduces unnecessary exposure. Cloud Armor protects public entry points. VPC Service Controls constrains data movement around supported Google services.

Shared VPC separates network ownership from application ownership

A host project can own subnets, routing, and firewall policy while service projects consume the shared network. That lets network teams enforce consistent patterns without forcing application teams to become network administrators.

Private connectivity is not one thing

Private Google Access helps VMs without external IPs reach Google APIs. Private Service Connect exposes Google or producer services through internal endpoints. Private Service Access is still used by many managed database services such as Cloud SQL and Memorystore. Cloud NAT gives private VMs controlled outbound internet access.

These mechanisms solve different connectivity problems. Treating them as interchangeable is a common source of architectural confusion.

VPC Service Controls adds a data boundary

VPC Service Controls is especially useful when “valid credentials” should still not be enough to move sensitive data wherever the caller wants.

Imagine a compromised credential that legitimately has access to a production storage bucket. IAM may allow the read. A correctly designed service perimeter can still prevent the data from being copied to an untrusted resource outside the perimeter.

For internet-facing applications, Cloud Armor provides DDoS protection, WAF capabilities, and traffic filtering. For environments that need deep inspection, Cloud NGFW Enterprise can add Layer 7 threat inspection. Those are targeted controls, not mandatory components for every workload.

Protect data, keys, and secrets deliberately

Google encrypts customer data at rest by default. That is the baseline. The security work begins when the organization needs stronger control over keys, sensitive-data discovery, secret access, or data exfiltration.

CMEK when there is a reason—not because it sounds more secure

Customer-managed encryption keys make sense when you need independent control over key rotation, revocation, separation of duties, contractual requirements, or regulatory obligations. They also add operational complexity.

Cloud KMS centralizes key lifecycle and audit. Autokey can reduce the friction of using CMEK consistently where CMEK is actually required.

Secrets belong in a secrets system

API keys, passwords, certificates, and third-party credentials should live in Secret Manager rather than source code, container images, or unmanaged pipeline variables. Access should be explicit and auditable.

Know where sensitive data actually lives

Sensitive Data Protection can discover and classify PII, financial information, health data, credentials, and other sensitive content. That matters because not every bucket or dataset deserves the same security response.

A misconfigured storage bucket containing public marketing assets and one containing raw customer PII are not the same risk. Classification helps security teams prioritize accordingly.

Different runtimes fail in different ways

“Compute security” is too broad to be useful. A VM, a Kubernetes workload, and a Cloud Run service expose different control surfaces.

Compute Engine: you still own the operating system

Use Shielded VM, consider Confidential VM for data-in-use requirements, remove unnecessary external IPs, use IAP for SSH/RDP, and use OS Login rather than unmanaged SSH keys. Patching remains your responsibility.

GKE: managed Kubernetes is still Kubernetes

GKE Autopilot reduces node-management burden and applies stronger defaults, but it does not fix application vulnerabilities, bad RBAC, or missing network policy.

Use Workload Identity Federation for GKE, keep RBAC narrow, use network policies where pod-to-pod controls matter, reduce control-plane exposure, and scan images before production.

Cloud Run: infrastructure gets simpler, identity matters more

Cloud Run shifts attention toward who can invoke the service, which service account it runs as, and where its traffic can go. Use IAM invocation controls, deliberate ingress settings, a least-privilege runtime identity, and Direct VPC egress where private VPC access is needed.

Move security into the delivery path

Finding a vulnerability after deployment is useful. Preventing an untrusted artifact from reaching production is better.

A practical software-supply-chain flow looks like this:

Infrastructure as Code makes changes reviewable and repeatable. Artifact Registry should become the trusted home for build artifacts. Provenance and attestations create a record of where the artifact came from. Binary Authorization closes the loop by preventing GKE or Cloud Run from running images that did not meet policy.

Know what is wrong before an incident does

Security Command Center is useful because it changes the question from “Which scanner produced this finding?” to “Which finding creates the most real risk in our cloud estate?”

SCC brings together misconfigurations, vulnerability findings, threat detections, data risk, attack paths, and other posture signals. The value is not another dashboard. The value is context.

A public VM, an over-privileged identity, and access to sensitive data may each look like separate problems. Together they can form an attack path worth fixing before lower-risk findings.

Plan around SCC Premium, not the deprecated Enterprise tier

The source material for this article notes that Security Command Center Enterprise was deprecated in May 2026 with shutdown planned in 2027. New architecture should not depend on Enterprise as the long-term tier.

Some advanced SCC capabilities mentioned in the source—including parts of vulnerability assessment, graph search, and AI-related capabilities—carry Preview status. Treat those as evolving features and verify current availability before production design.

Centralize evidence, detection, and governance

When something goes wrong, the first question is often painfully basic: “Do we have the logs?”

Admin Activity audit logs provide a baseline. Data Access logs are more expensive and should be enabled where the data and risk justify them, not indiscriminately across every high-volume service.

Aggregated log sinks can centralize telemetry so incident response does not become a project-by-project collection exercise. VPC Flow Logs, firewall logs, GKE audit logs, application logs, and SCC detections add context.

SCC and Google Security Operations solve different problems

SCC is focused on Google Cloud posture, vulnerabilities, and cloud-native threat findings. Google Security Operations is the broader SIEM/SOAR layer for detection, investigation, case management, and response across a wider telemetry set.

Compliance tools help with evidence; they do not create compliance

Compliance Manager can map controls to frameworks and help generate evidence. Assured Workloads can help with specific regulated or sovereignty requirements. Neither removes the need for ownership, exception handling, review cycles, and actual implementation.

AI agents change the security model

A chatbot that only answers questions is one thing. An agent that can read data, call tools, send messages, create resources, or change production systems is a different security problem.

The threat model now includes prompt injection, poisoned context, over-privileged agent identities, unsafe tool calls, and sensitive data leaving through model output.

Use the Secure AI Framework as a way to think

Google’s Secure AI Framework extends normal security principles into AI systems: protect the ecosystem, detect AI-specific threats, automate defenses, keep controls consistent, and continuously learn from what happens.

AI Protection in Security Command Center

AI Protection in Security Command Center adds visibility into AI assets and risks, including models, endpoints, data sources, agents, and agent-related findings. Some capabilities continue to evolve, so check the current documentation before relying on a Preview feature in production.

Model Armor adds runtime screening

Model Armor can inspect prompts, responses, and agent interactions for prompt injection, jailbreak attempts, sensitive-data exposure, malicious URLs, and harmful content. It can operate in inspect-only or active blocking modes.

That is useful, but it is not the whole architecture. An agent still needs least-privilege identity, network and data boundaries, tool authorization, audit logging, and human approval for high-impact actions.

MCP increases the value of tool-level authorization

Model Context Protocol servers expose tools that agents can call. The more powerful the tool, the more important it becomes to authorize at the tool level instead of giving the agent blanket access.

Destructive actions, external communication, and high-impact changes should have explicit approval or policy gates. Untrusted documents, websites, and third-party data should be treated as potential prompt-injection sources.

Common mistakes that still create real risk

1. Owner or Editor as normal human access. Broad permissions make every account compromise more damaging.
2. Long-lived service-account JSON keys. Use keyless authentication where possible.
3. Flat project structure and default networking. Security becomes inconsistent because there is nowhere to inherit policy from.
4. Thinking firewall rules are the whole network model. IAM, private connectivity, Cloud Armor, VPC Service Controls, and other controls solve different problems.
5. Secrets in source code or container images. Use Secret Manager and keep secret access auditable.
6. Applying security after deployment. Preventive policy and delivery-time enforcement are cheaper than retrofitting.
7. Turning on every Data Access log without a cost model. Log what the risk justifies.
8. Monitoring project by project. Organization-level visibility is where cross-project risk becomes visible.
9. Alert overload. A thousand low-context findings are not a security strategy.
10. Assuming managed services remove customer responsibility. IAM, network access, logging, and data handling still belong to you.
11. Treating VPC Service Controls as a replacement for IAM. Authorization and data containment are different layers.
12. Treating AI security as content moderation. Agent identity, tool access, and data exfiltration matter just as much.

A practical 30/60/90-day sequence

This is a prioritization sequence, not a promise that every organization can finish every item on the same calendar.

Put the layers together

The controls in this guide are useful because they overlap. If one fails, another should reduce the damage.

Make Secure Defaults Part of Daily Work

Good cloud security should feel less dramatic than bad cloud security.

A developer creates a new project and the safe network pattern is already there. A workload needs Google APIs and never asks for a JSON key. A production admin needs temporary access and gets it for one hour. A container fails policy and simply does not deploy. A sensitive-data project already sits behind the right boundaries. A new AI agent gets a dedicated identity instead of borrowing one from another service.

Build these controls into project templates, access workflows, and delivery pipelines so teams use them as part of their normal work.

The technologies will keep changing—especially around AI security. The architecture principles are more stable: reduce standing privilege, prevent unsafe configurations, contain data movement, make every important action observable, and design for failure before failure arrives.