Google Cloud Security: What’s Really On Your Shoulders

When you use Google Cloud, the line between what Google secures and what you must secure isn’t always obvious - but getting it wrong could leave you exposed. This guide explains exactly where your responsibility begins, what risks to be aware for, and how to protect your environment without adding complexity.

The Google Cloud Shared Responsibility Model

Like all major cloud providers, Google Cloud has its own Shared Responsibility Model that details ownership of security responsibility. This responsibility is divided between the customer (you) and cloud provider (Google), and this division depends upon the services you’re using, and in which context. The table below shows the security responsibilities split out between Google and the customer, categorized by service type:

You’ll notice that in Google’s shared responsibility article, ‘Shared fate’ is touted as an addition to this model. It may seem like it’s an addition to the usual cloud provider model, but it is just an assertion that they intend to take security seriously, and make efforts to implement services that are secure by default. Google describes ‘Shared fate’ as being “about us taking responsibility for making Google Cloud more secure,” which is a responsibility all cloud providers have (though they don’t all have an alluring term for it!). 

SaaS

For SaaS services, Google bears the most responsibility for security. An example of this type of service would be using Google Workspace. In this scenario, Google is responsible for securing the applications it includes, such as Gmail and Google Drive - but you are still responsible for securing the content and managing access controls. If for example you add sensitive data to a Google sheet, then make it publicly shareable with anyone and share that link - that’s your responsibility. 

PaaS

An example of one of Google Cloud’s Platform-as-a-Service (PaaS) services is App Engine. App Engine lets you build web applications without having to manage the infrastructure. Notice that for PaaS services, the security of the operating system (OS) is Google’s responsibility. App Engine abstracts away from the user the need to build, scale and maintain servers that are running applications. Since Google manages all of this for you, they also must be the ones who are responsible for operational elements, like fixing vulnerabilities in the OS of the infrastructure that’s running your application.

IaaS

In contrast, an Infrastructure-as-a-Service (IaaS) product like Compute Engine is a service where you manage your own virtual machines in the cloud. This requires the end user to coordinate the build and perform ongoing maintenance of all software on the server. For this type of service, the responsibility of the OS instead lies with the customer, so it’s up to you to keep the packages and software up to date.

On-prem

On-prem (on premises deployment) speaks for itself. Since you are hosting your own servers in your own data centers or offices, Google clearly has no responsibility for security here!

Vulnerabilities Which Are Your Responsibility in Google Cloud

Let’s look at some vulnerabilities and misconfigurations that are your responsibility and what you can do to mitigate them.

The following examples focus on a few key elements of Google Cloud’s Shared Responsibility Model:

• Access policy
• Access and authentication
• Network security
• Guest OS

Access Policy - Overly Permissive Service Account

Google Cloud provides Identity and Access Management (IAM) functionality that allows you to define different types of accounts and users and choose their access levels. It’s Google’s responsibility to ensure that this functionality is secure and cannot be bypassed, but that is where their responsibility ends, and it certainly doesn’t stop you from shooting yourself in the foot!

The classic and well-known security rule that should be followed for access management is the principle of least privilege. This principle states that each account should only have the very minimal roles and privileges that are required to carry out their essential role. Ensuring this principle is followed drastically slows down attacks, and limits them in ways that greatly reduce your risk. 

Ensuring this principle is carried out is not something Google Cloud can help you with. How could they possibly know what a user’s minimum permissions should be when they don’t understand your business use case? A classic example and common mistake that we see in Google Cloud is service accounts which have administrative privileges. Whilst convenient, it is highly unlikely that the programmatic user for the service account actually needs to be an administrator with access to edit or delete all resources in the project. This introduces a risk, because if the system upon which the service account credentials are stored or used gets compromised - the attacker not only gains a foothold in your cloud environment, they do so as an administrator without having to pivot any further or discover additional weaknesses.

Access and Authentication - Exposed Storage Buckets

Managing which users can access resources within a Google project and which resources should be public is also your responsibility. Google’s Cloud Storage service is a prime example, where certain resources may be intended to be public and allow anonymous access (like a bucket containing media files for a web front-end), whereas others contain sensitive files which should only be accessible to specific internal users. Google provides the capability to lock down storage buckets, add authentication, and choose whether or not they are internet accessible.

However, a public access use case is legitimate, and Google Cloud doesn't know the context of what you’re storing. There’s nothing stopping you from storing sensitive data in a bucket, and configuring it to be fully publicly readable and writable from the internet. Ask any pentester worth their salt, and they’ll say “trust me, it happens!”.

Network Security - Firewalls and Attack Surface

In Google Cloud, managing your attack surface is in your hands. Google is responsible for ensuring their network controls can’t be bypassed, but the decision on which ports and services to expose to the internet is yours. 

For example, you can choose to assign a public IP to your Compute resource with a wide-open firewall. Or you could lock it down to limit access by nestling it inside its own VPC that can only be accessed from a trusted on-premises network using Cloud Interconnect. It all depends on your use case for Compute resource, but in general your attack surface should be minimized whenever possible.

Intruder’s Enterprise plan helps you uncover and reduce what’s exposed to the internet by:

• Providing full visibility of your external ports and services
• Highlighting panels that shouldn’t be exposed
• Detecting overly permissive firewall rules in Google Cloud

By scanning from both an internal and external perspective, you arm yourself with the ability to reduce your attack surface and avoid getting exploited when the next zero-day drops, because you already took that sensitive system off the internet. 

Guest OS - Patch Management

IaaS features like Compute Cloud put patching the OS and its software in your hands. If you deploy Virtual Machines yourself using Compute, the system and software it is running will develop vulnerabilities over time. Google handles patching the firmware and keeps the hardware that your server is running on up to date, but the OS and software layers are your responsibility. This responsibility is termed ‘Guest OS’ by Google on the responsibility diagram.

For example, if you deploy a machine running RHEL 10 that’s hosting your MongoDB server, you are responsible for ensuring that Red Hat software is up to date, and for keeping your MongoDB instance secured against the latest known weaknesses. To do this, you’ll want an automated solution to scan your machines and notify you when patches are due. For example, with Intruder’s agent-based vulnerability scanning you can find missing patches on internal systems and see them alongside cloud misconfigurations and external exposures - unifying what would otherwise require multiple tools.

Google Cloud Security: What It All Comes Down To

These are just a few examples of the common security issues teams face in Google Cloud. These issues highlight that although Google Cloud makes your life easier by taking some of the security burden off your plate, the overall security of your cloud environment is up to you.

That’s why having continuous visibility into your Google Cloud security posture is so important - and exactly where Intruder can help.

Always On Google Cloud Security

Intruder makes it easy to bridge the gaps in Google’s Shared Responsibility Model by unifying cloud security, vulnerability management, and attack surface discovery in one platform.

• Catch risks with daily, automated scans for misconfigurations, insecure permissions, and exposed secrets
• Cut through the noise by focusing on issues that put you most at risk
• Fix faster with clear, actionable guidance your team can follow easily

Intruder doesn’t stop at Google Cloud - with AWS and Azure support too, you get a single view of risk across all your cloud environments.

Cloud Security is included in Cloud, Pro, and Enterprise plans. Check your Google Cloud security posture today by starting a free trial.