The GCP Shared Responsibility Model: Everything You Need to Know

What the GCP Shared Responsibility Model is and how security teams can get started

Ermetic Team By Ermetic Team
The GCP Shared Responsibility Model: Everything You Need to Know

Securing cloud infrastructure requires a mindset shift - from firewalls, VPNs and servers to workloads, buckets and collaborating with an external cloud security provider. Cloud providers like GCP and AWS offer a shared responsibility model, which determines who is responsible for the security of which architecture components. In this article, we cover the GCP shared responsibility model and explain how to approach it.

Cloud Infrastructure Security and Why It Matters

Cloud migration is helping businesses stay competitive and offer modern services to their customers. However, transforming from an on-premises architecture to a hybrid cloud or cloud-native architecture poses some security challenges that need to be addressed.

These include cloud misconfigurations, cloud ransomware, vulnerable supply chains and data breaches related to access management. A recent report found that 75% of the cloud instances analyzed were improperly misconfigured, practiced poor customer security or implemented vulnerable third-party software (Source: Google “Threat Horizon Report”).

Cloud environments are vulnerable because they require organizational – and extra-organizational – traffic to continuously travel through the public internet to reach servers, hosts, applications and data. This is unlike on-premises architecture, which hosts servers and applications locally, and often has a minimal number of external access points. On-prem, these organizational access points are secured through means like firewalls. In cloud architectures, there is no physical perimeter, which requires a different security approach.

In addition, “the cloud” is actually an enormous set of constantly evolving technologies (and potential vulnerabilities) that require security teams to learn and stay-up-to-date at all times. For example, with tens of thousands of workloads, services and configurations, IT and security teams need new solutions for determining permissions policies and for managing access risk.

Finally, the fact that “the cloud” is hosted by an external party (the cloud provider) creates confusion regarding who is responsible for securing the cloud and the diverse components on the cloud (infrastructure, databases, clusters, applications, workloads, access management, etc.). To answer this last challenge, cloud providers came up with a framework called “the shared responsibility model.”

What is the GCP Shared Responsibility Model?

The GCP shared responsibility model determines which cloud architecture components Google Cloud Platform (GCP) is responsible for as the cloud security provider (CSP) and which are the GCP customer’s responsibility to secure.

Broadly speaking, Google is responsible for the cloud, i.e the infrastructure, and the customer is responsible for anything in the cloud, i.e anything she/he can configure.

Here’s how it breaks down:

GCP Shared Responsibility Model

Source: Google

GCP’s model holds the cloud customer responsible for securing a substantial scope of cloud infrastructure components, including cloud configurations and data stored in the cloud:

  • Content
  • Access policies
  • Usage
  • Deployment
  • Web application security
  • Identity
  • Operations
  • Access and authentication
  • Network security
  • Guest OS, data and content

In short, if you can configure or store it, you are responsible for securing it.

Per the model, as a company takes more ownership of its cloud computing, more components become the company’s responsibility:

  • In the IaaS model, the customer is responsible for anything on top of the infrastructure and network level.
  • In a PaaS model, Google is responsible for everything in IaaS + data, network security, application security and identities.
  • Finally, in the SaaS model, the customer is responsible for only application usage, access policies and the content.

While cloud providers seem to have a clear understanding of the model they have put forth, implementing shared responsibility obligations is a major challenge for the CSP customer.

How to Approach the GCP Shared Responsibility Model

It is important to study this model and ensure no component is left in security limbo. For example, given, as mentioned, the many points of entry to an organization's cloud infrastructure, the network is a particularly weak link. What are you doing to secure your cloud network -- for example, are you monitoring or analyzing network configurations for risk?

Attackers can exploit vulnerabilities, so make sure you know which department and role is securing which piece of the architecture. If this seems overwhelming, here are the recommended next steps: Research, Identify, Process Automation and Coverage.

  1. Research the detailed shared responsibility model and find which components your security team is responsible for. If you’re not sure, contact GCP to make sure you have a clear picture. To deepen your understanding of securing access, identity and network, sign up for this webinar on best practices for managing resources and access in GCP.
  2. Identify which, of the components you are responsible for, are currently being governed by the team and which aren’t. For those that are, list the security measures in place and what results they are bringing in.
  3. Create Process Automation and dashboards for existing measures that are in place. These will help you monitor and track your security governance, and identify any coverage gaps in the future.
  4. Map Coverage -- Take the list of not yet governed architecture components and map out the gaps you have for attaining coverage of them. Then, find cloud security solutions and vendors that will help you reduce your cloud attack surface and blast radius.

Following these steps can help overcome challenges many security teams have with shared responsibility models, including lack of clarity, lack of cloud expertise, lack of tools and lack of cross-cloud security for multicloud environments. Effectively handling your share of the model will reduce security risks, and help you own and control cloud security in your organization.