The GCP Shared Responsibility Model: Everything You Need to Know

Do you know what your organization is accountable for under the Google Cloud Platform shared responsibility model?

The shared responsibility model offered by cloud providers like Amazon Web Services (AWS), Google Cloud Platform (GCP) and Microsoft Azure delineates who is responsible for the security of which architecture components — the client or the cloud provider. In this article, we provide an overview of the GCP shared responsibility model and provide guidance for security teams on how to approach it. 

Transitioning from an on-premises architecture to a hybrid cloud or cloud-native architecture poses some security challenges that need to be addressed. These can include cloud misconfigurations as well as the threats of cloud ransomware, vulnerable supply chains and data breaches related to access management. 

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 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. 

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 the provider is responsible for securing and which are the customer’s responsibility to secure.

Broadly speaking, GCP 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:

Image 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, such as:

• 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 GCP model, as a company takes more ownership of its cloud computing, more components become the company’s responsibility instead of GCP’s:

• In an infrastructure-as-a-service (IaaS) model, the customer is responsible for anything on top of the infrastructure and network level.
• In a platform-as-a-service (PaaS) model, Google is responsible for everything in IaaS as well as data, network security, application security and identities.
• In a software-as-a-service (SaaS) model, the customer is responsible for only application usage, access policies and the content.

Understanding and meeting shared responsibility obligations can be a major challenge for cloud customers. 

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? 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 four recommended next steps: 

1. Research the detailed shared responsibility model and find out which components your security team is responsible for. If you’re not sure, contact GCP to make sure you have a clear picture. 
2. Once you’ve determined the components you are responsible for, identify which of these are currently being governed by your 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. Identify the architecture components your team is not yet governing 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 you overcome some of the challenges security teams encounter with the shared responsibility model, which can include lack of clarity, lack of cloud expertise, lack of tools and lack of cross-cloud security for multi-cloud environments. Effectively handling your share of the model will reduce security risks, and help you own and control cloud security in your organization.