Shared responsibilities and shared fate on Google Cloud

Last reviewed 2023-08-21 UTC

This document describes the differences between the shared responsibility modeland shared fate in Google Cloud. It discusses the challenges and nuancesof the shared responsibility model. This document describes what shared fate isand how we partner with our customers to address cloud security challenges.

Understanding the shared responsibility model is important when determining howto best protect your data and workloads on Google Cloud. The sharedresponsibility model describes the tasks that you have when it comes to securityin the cloud and how these tasks are different for cloud providers.

Understanding shared responsibility, however, can be challenging. The modelrequires an in-depth understanding of each service you utilize, theconfiguration options that each service provides, and what Google Clouddoes to secure the service. Every service has a different configuration profile,and it can be difficult to determine the best security configuration. Google believes that the shared responsibility model stops shortof helping cloud customers achieve better security outcomes. Instead of sharedresponsibility, we believe inshared fate.

Shared fate includes us building and operating a trusted cloud platform foryour workloads. We provide best practice guidance and secured, attestedinfrastructure code that you can use to deploy your workloads in a secure way.We release solutions that combine various Google Cloud services to solvecomplex security problems and we offer innovative insurance options to help youmeasure and mitigate the risks that you must accept. Shared fate involves usmore closely interacting with you as you secure your resources onGoogle Cloud.

Shared responsibility

You're the expert in knowing the security and regulatory requirements for yourbusiness, and knowing the requirements for protecting your confidential data andresources. When you run your workloads on Google Cloud, you must identifythe security controls that you need to configure in Google Cloud to helpprotect your confidential data and each workload. To decide which securitycontrols to implement, you must consider the following factors:

  • Your regulatory compliance obligations
  • Your organization's security standards and risk management plan
  • Security requirements of your customers and your vendors

Defined by workloads

Traditionally, responsibilities are defined based on the type of workload thatyou're running and the cloud services that you require. Cloud services includethe following categories:

Cloud serviceDescription
Infrastructure as a service (IaaS)IaaS services includeCompute Engine,Cloud Storage, and networkingservices such asCloud VPN,Cloud Load Balancing, andCloud DNS.

IaaS provides compute, storage, and network services on demand withpay-as-you-go pricing. You can use IaaS if you plan on migrating anexisting on-premises workload to the cloud using lift-and-shift, orif you want to run your application on particular VMs, using specificdatabases or network configurations.

In IaaS, the bulk of the security responsibilities are yours, and ourresponsibilities are focused on the underlying infrastructure andphysical security.

Platform as a service (PaaS)PaaS services includeApp Engine,Google Kubernetes Engine (GKE), andBigQuery.

PaaS provides the runtime environment that you can develop and runyour applications in. You can use PaaS if you're building anapplication (such as a website), and want to focus on developmentnot on the underlying infrastructure.

In PaaS, we're responsible for more controls than in IaaS. Typically, this will vary by the services and features that you use. You share responsibility with us forapplication-level controls and IAM management. Youremain responsible for your data security and client protection.

Software as a service (SaaS)SaaS applications includeGoogle Workspace,Google Security Operations, andthird-party SaaS applications that are available inGoogle Cloud Marketplace.

SaaS provides online applications that you can subscribe to or payfor in some way. You can use SaaS applications when your enterprisedoesn't have the internal expertise or business requirement to buildthe application themselves, but does require the ability to processworkloads.

In SaaS, we own the bulk of the security responsibilities. You remainresponsible for your access controls and the data that you choose tostore in the application.

Function as a service (FaaS) or serverless

FaaS provides the platform for developers to run small,single-purpose code (calledfunctions) that run in responseto particular events. You would use FaaS when you want particularthings to occur based on a particular event. For example, you mightcreate a function that runs whenever data is uploaded toCloud Storage so that it can be classified.

FaaS has a similar shared responsibility list as SaaS.Cloud Run functions is a FaaSapplication.

The following diagram shows the cloud services and defines how responsibilitiesare shared between the cloud provider and customer.

Shared security responsibilities

As the diagram shows, the cloud provider always remains responsible for theunderlying network and infrastructure, and customers always remain responsiblefor their access policies and data.

Defined by industry and regulatory framework

Various industries have regulatory frameworks that define the security controlsthat must be in place. When you move your workloads to the cloud, you mustunderstand the following:

  • Which security controls are your responsibility
  • Which security controls are available as part of the cloud offering
  • Which default security controls are inherited

Inherited security controls (such as ourdefault encryption andinfrastructure controls)are controls that you can provide as part of your evidence of your securityposture to auditors and regulators. For example, the Payment Card Industry DataSecurity Standard (PCI DSS) defines regulations for payment processors. When youmove your business to the cloud, these regulations are shared between you andyour CSP. To understand how PCI DSS responsibilities are shared between you andGoogle Cloud, seeGoogle Cloud: PCI DSS Shared Responsibility Matrix.

As another example, in the United States, the Health Insurance Portability andAccountability Act (HIPAA) has set standards for handling electronic personalhealth information (PHI). These responsibilities are also shared between the CSPand you. For more information on how Google Cloud meets ourresponsibilities under HIPAA, seeHIPAA - Compliance.

Other industries (for example, finance or manufacturing) also have regulationsthat define how data can be gathered, processed, and stored. For moreinformation about shared responsibility related to these, and howGoogle Cloud meets our responsibilities, seeCompliance resource center.

Defined by location

Depending on your business scenario, you might need to consider yourresponsibilities based on the location of your business offices, your customers,and your data. Different countries and regions have created regulations thatinform how you can process and store your customer's data. For example, if yourbusiness has customers who reside in the European Union, your business mightneed to abide by the requirements that are described in theGeneral Data Protection Regulation (GDPR), and you might be obligated to keep your customer data in the EU itself.In this circumstance, you are responsible for ensuring that the data that youcollect remains in theGoogle Cloud regions in the EU.For more information about how we meet our GDPR obligations, seeGDPR and Google Cloud.

For information about the requirements related to your region, seeCompliance offerings.If your scenario is particularly complicated, we recommend speaking with oursales team or one of ourpartners to help you evaluate your security responsibilities.

Challenges for shared responsibility

Though shared responsibility helps define the security roles that you or thecloud provider has, relying on shared responsibility can still createchallenges. Consider the following scenarios:

  • Most cloud security breaches are the direct result of misconfiguration(listed asnumber 3 in the Cloud Security Alliance's Pandemic 11 Report)and this trend is expected to increase. Cloud products are constantlychanging, and new ones are constantly being launched. Keeping up withconstant change can seem overwhelming. Customers need cloud providers toprovide them with opinionated best practices to help keep up with thechange, starting with best practices by default and having a baselinesecure configuration.
  • Though dividing items by cloud services is helpful, many enterpriseshave workloads that require multiple cloud services types. In thiscircumstance, you must consider how various security controls for theseservices interact, including whether they overlap between and acrossservices. For example, you might have an on-premises application thatyou're migrating to Compute Engine, use Google Workspacefor corporate email, and also run BigQuery to analyze datato improve your products.
  • Your business and markets are constantly changing; as regulationschange, as you enter new markets, or as you acquire other companies. Yournew markets might have different requirements, and your new acquisitionmight host their workloads on another cloud. To manage the constantchanges, you must constantly re-assess your risk profile and be able toimplement new controls quickly.
  • How and where to manage your data encryption keys is an importantdecision that ties with your responsibilities to protect your data. Theoption that you choose depends on your regulatory requirements, whetheryou're running a hybrid cloud environment or still have an on-premisesenvironment, and the sensitivity of the data that you're processing andstoring.
  • Incident management is an important, and often overlooked, area whereyour responsibilities and the cloud provider responsibilities aren't easilydefined. Many incidents require close collaboration and support from thecloud provider to help investigate and mitigate them. Other incidents canresult from poorly configured cloud resources or stolen credentials, andensuring that you meet the best practices for securing your resources andaccounts can be quite challenging.
  • Advanced persistent threats (APTs) and new vulnerabilities can impactyour workloads in ways that you might not consider when you start yourcloud transformation. Ensuring that you remain up-to-date on the changinglandscape, and who is responsible for threat mitigation is difficult,particularly if your business doesn't have a large security team.

Shared fate

We developed shared fate in Google Cloud to start addressing thechallenges that the shared responsibility model doesn't address. Shared fatefocuses on how all parties can better interact to continuously improve security.Shared fate builds on the shared responsibility model because it views therelationship between cloud provider and customer as an ongoing partnership toimprove security.

Shared fate is about us taking responsibility for making Google Cloudmore secure. Shared fate includes helping you get started with a securedlanding zone and being clear, opinionated, and transparent about recommended securitycontrols, settings, and associated best practices. It includes helping youbetter quantify and manage your risk with cyber-insurance, using our RiskProtection Program. Using shared fate, we want to evolve from the standardshared responsibility framework to a better model that helps you secure yourbusiness and build trust in Google Cloud.

The following sections describe various components of shared fate.

Help getting started

A key component of shared fate is the resources that we provide to help you getstarted, in a secure configuration in Google Cloud. Starting with a secureconfiguration helps reduce the issue of misconfigurations which is the rootcause of most security breaches.

Our resources include the following:

  • Enterprise foundations blueprint that discuss top security concerns and our top recommendations.
  • Secure blueprints that let you deploy and maintain secure solutions usinginfrastructure ascode (IaC). Blueprints have our security recommendations enabled bydefault. Many blueprints are created by Google security teams and managedas products. This support means that they're updated regularly, go througha rigorous testing process, and receive attestations from third-partytesting groups. Blueprints include theenterprise foundations blueprint and thesecured data warehouse blueprint.

  • Google Cloud Well-Architected Framework recommendations for building security into your designs.

  • Landing zone navigation guides that step you through the top decisions that you need to make to build asecure foundation for your workloads, including resource hierarchy,identity onboarding, security and key management, and network structure.

Risk Protection Program

Shared fate also includes theRisk Protection Program (currently in preview), which helps you use the power of Google Cloud as aplatform to manage risk, rather than just seeing cloud workloads as anothersource of risk that you need to manage. The Risk Protection Program is acollaboration between Google Cloud and two leading cyber insurancecompanies, Munich Re and Allianz Global & Corporate Speciality.

The Risk Protection Program includesCyber Insurance Hub,which provides data-driven insights that you can use to better understand yourcloud security posture. If you're looking for cyber insurance coverage, you canshare these insights from Cyber Insurance Hub directly with our insurancepartners to obtain a quote. For more information, seeGoogle Cloud Risk Protection Program now in Preview.

Help with deployment and governance

Shared fate also helps with your continued governance of your environment. Forexample, we focus efforts on products such as the following:

Putting shared responsibility and shared fate into practice

As part of your planning process, consider the following actions to help youunderstand and implement appropriate security controls:

  • Create a list of the type of workloads that you will host inGoogle Cloud, and whether they require IaaS, PaaS, and SaaS services.You can use theshared responsibility diagram as a checklist to ensure that you know the security controls that you needto consider.
  • Create a list of regulatory requirements that you must comply with, andaccess resources in theCompliance resource center that relate to those requirements.
  • Review the list of available blueprints and architectures in theArchitecture Center for the security controls that you require for your particular workloads.The blueprints provide a list of recommended controls and the IaC code thatyou require to deploy that architecture.
  • Use thelanding zone documentation and the recommendations in theenterprise foundations guide to design a resource hierarchy and network architecture that meets yourrequirements. You can use the opinionated workload blueprints, like thesecured data warehouse, to accelerate your development process.
  • After you deploy your workloads, verify that you're meeting yoursecurity responsibilities using services such as theCyber Insurance Hub, Assured Workloads,Policy Intelligence tools, and Security Command Center Premium.

For more information, see theCISO's Guide to Cloud Transformation paper.

What's next

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2023-08-21 UTC.