Download pdf version
This content was last updated in December 2022, and represents the status quo as of the time it was written. Google's security policies and systems may change going forward, as we continually improve protection for our customers.
This document presents an opinionated view of Google Cloud security best practices, organized to allow you to adopt or adapt them and then automatically deploy them for your estates on Google Cloud. This document can be useful to you if you are a CISO, security practitioner, or risk or compliance officer.
This document is part of a series that provides our opinionated security foundations blueprint for a landing zone and captures a step-by-step view of how to configure and deploy your Google Cloud estate. This series can provide a good reference and starting point because it highlights key topics to consider. Each topic provides background and discussion of why we made each of our choices. In addition to the step-by-step guide, this security foundations blueprint has an accompanying Terraform automation repository and an example demonstration Google organization so you can learn from and experiment with an environment configured according to the blueprint.
This series on the security foundations blueprint covers the following:
- Security foundations blueprint overview (this document)
- Using the Terraform example
- Resource deployment
- Authentication and authorization
- Networking (segmentation and security)
- Key and secret management
- Billing
- Logging and monitoring
- Detective controls
- Integrating with monitoring tools
- Creating and deploying secured applications
- Summary
To read about the latest updates, see What's new.
Introduction
Cloud adoption continues to accelerate across enterprises, with more businesses moving from investigating the use of public cloud infrastructure to actually delivering production services to their customers through public clouds. Conventionally, security in public clouds differs intrinsically from customer-owned infrastructure because there is a delineation of shared responsibility for security between the customer and the cloud provider. The diagram below shows a matrix of the conventional shared security responsibility for workloads in the cloud.
Google Cloud product and service offerings range from classic platform as a service (PaaS), to infrastructure as a service (IaaS), to software as a service (SaaS). As shown in the diagram above, the conventional boundaries of responsibility between you and the cloud provider change based on the services you've selected. At a minimum, as a part of their shared responsibility for security, public cloud providers should enable you to start with a solid, secured foundation. Providers should then empower and make it easy for you to understand and execute your part of the shared responsibility model.
The catalog of Google Cloud offerings continues to grow rapidly. Each Google Cloud service exposes a wide range of configurations and controls so that you can customize it to match your business and security needs. In creating and setting up your core infrastructure, our goal is to get you started faster and more securely by encoding key Google Cloud security best practices by default in this opinionated security foundations blueprint. You can then build on top of a reliable, secured foundation and landing zone and either optimize the controls or take advantage of additional service-specific security guidance from our posture blueprints.
At Google, with our previous announcement for the Risk Protection Program, we seek to do even more and move from a traditional model of shared responsibility between customers and their cloud providers to shared fate. In this approach, we are active partners with you to deploy securely on our platform and not just delineators of where our responsibility ends. Now, with the addition of Mandiant products and solutions, we can further support you with a suite of security advisory, threat intelligence, testing, validation, incident response, and managed defense services.
Starting off with security in mind
Cloud security is different from on-premises security because of the combination of the following:
- Differences in security primitives, visibility, and control points within the infrastructure, products and services.
- New cloud-native development methodologies like containerization and DevSecOps.
- The continued velocity and variety of new cloud products and services and how they can be consumed.
- Cultural shifts in how organizations deploy, manage, and operate systems.
- Understanding and distribution of risk between customers and cloud providers
You have many decisions to make when setting up your cloud deployment. You might need help deploying workloads with secure defaults simply, quickly, and effectively in order to accelerate your ability to deliver business impact and value to your customers. But you might not have the time to build the new skills necessary to cope with the differences and new challenges of a cloud transition. Therefore, you can often benefit from curated and opinionated guidance for both a secured foundational starting point and for customization to match your specific needs.
Here's good news: you can build on Google Cloud more quickly, effectively, and securely by using these security blueprints, which add an important new set of layers in the hierarchy of security on Google Cloud. There are five main parts, starting with core Google Cloud infrastructure as the base. The four subsequent layers are Google Cloud products and services; security foundations blueprints; blueprints for security posture, workloads, and applications; and solutions that bundle the products, services, and blueprints with use case examples, with customer references, and with a commercial offering to simplify your understanding, adoption, and consumption. Each layer builds on top of the previous layers as discussed below.
Core Google Cloud infrastructure
Google has a global-scale technical infrastructure that's designed to provide security through the entire information processing lifecycle. This infrastructure provides secure deployment of services, secure storage of data with end-user privacy safeguards, secure communications between services, secure and private communication with customers over the internet, and safe operation by administrators.
Google products and services
Google Cloud products and services are built on top of the core infrastructure and are designed and operated consistently in accordance with the cloud-native security principles that are shared in our BeyondProd whitepaper. They include built-in security features to enable access control, segmentation, and data protection. In addition, Google Cloud builds specific security products to help you meet your policy requirements and help protect your critical assets with our security products and capabilities.
Security foundations blueprint
The goal of this security foundations blueprint is to provide you with curated, opinionated guidance and accompanying automation that helps you optimize the native controls and services to build a secured starting point and landing zone for your Google Cloud deployment.
Security posture, workload, and applications blueprints
On top of this strong security foundation, we provide additional blueprints for security posture, workload, and applications to give you curated, opinionated guidance to help design, build, and operate workloads and applications. Examples include our secured data warehouse for confidential data, secured serverless blueprint, and PCI on GKE blueprint.
Solutions
A combination of products and blueprints that incorporate Google Cloud security best practices provides you with the capabilities, architecture, and guidance for configuring, deploying, and operating specific sets of services. Solutions package these products together with vertical and use-case specific customization, additional examples, customer references, and a bundled commercial offering. Our goal is to simplify and accelerate your ability to adopt and apply the solutions for your organization's business needs. You can find our current solution portfolio on the Google Cloud solutions page.
The following table shows the layers of security that you can build on when you use Google Cloud and follow the guidance and templates provided by the security blueprints.
| Layer | Benefits | Examples |
|---|---|---|
| Security solutions | The security solutions layer addresses the following:
|
|
| Workload security posture blueprints and per-service blueprints | The workload blueprint layer helps ensure appropriate security
posture for specific workloads, applications, processes, or
services. Service-specific blueprints provide guidance for configuration, direct security, and compensating controls for a specific service. |
|
| Security foundations blueprint | The security foundation blueprint provides a secure baseline landing zone for infrastructure, resources, organization policies, identity and access, networking, logging, and detection. This Google opinionated blueprint enables customers to build their use cases on top of a secured foundation. |
|
| Secure-by-default products | This security layer is preconfigured and ready to use. It is designed to be secure and compliant with various regulations. | |
| Google core infrastructure security | This security layer is preconfigured and ready to use. It is designed to be secure and compliant with various regulations. |
How you can use the security foundations blueprint
This series can be useful to you as you take on one or more of the following roles in your organization:
- Security leader who needs to understand Google's key principles for Cloud Security and how they can be applied and implemented to secure your own organization's deployment.
- Security practitioner who needs detailed instructions on how to apply security best practices to set up, configure, deploy, and operate a security-centric infrastructure landing zone that's ready for you to deploy your workloads and applications to.
- Security engineer who needs to understand how to configure and operate multiple different security controls so that they correctly interact with one another.
- Business leader who needs your teams to accelerate their learning and understanding of the advanced skills they need on Google Cloud to meet your advanced needs. In this role, you also need to be able to share Google security reference documentation with your risk and compliance teams.
- Risk and compliance officer who needs to understand the controls available on Google Cloud to meet their business requirements and how those controls can be automatically deployed. You also need to have visibility into controls drift and areas that need additional attention to meet the regulatory needs of your business.
In each of these cases, you can use this series as a reference guide. You can also use the provided Terraform scripts to automate, experiment, test, and accelerate your own live deployments. You can modify the provided scripts to customize them for your needs.
Create a better starting point for compliance
For the compliance and regulatory frameworks that are required for your business, you need a clear understanding of and evidence for the following:
- Whether the Google Cloud services you choose meet the requirements.
- Whether your configuration and use of these Google Cloud services continue to meet requirements.
For the first case, Google Cloud provides the Compliance resource center. This site enables you to search by framework, region, or industry to find which Google Cloud services are approved and help support your compliance.
For the second case, after you've deployed the security foundations blueprint, Security Command Center Premium tier provides you a dashboard overview and downloadable compliance reports of your starting posture for the CIS 1.0, CIS 1.1, CIS 1.2. PCI-DSS 3.2.1, NIST 800-53, ISO 27001, OWSAP 2017, and OWASP 2021 frameworks at the organization, folder, or project level.
The screenshot below shows the default compliance report for a sample project deployed in the security foundations blueprint compared against various frameworks. As the figure shows, a majority of the assessed compliance controls are available as part of the blueprint. The missing controls are logging configuration controls that require user input before they can be set up correctly.
Implement key security principles
Beyond implementing compliance and regulatory requirements, you need to protect your infrastructure and applications.
The security foundations blueprint and the associated automation scripts help you adopt three Google Cloud security principles that are core to Google's own security. These are:
- Executing defense in depth, at scale, by default.
- Adopting the BeyondProd approach to infrastructure and application security.
- De-risking cloud adoption by moving toward a shared fate relationship.
Defense in depth, at scale, by default
A core principle for how Google secures its own infrastructure is defense in depth—there should never be just one barrier between an attacker and a target of interest. Adding to this core principle, security should be scalable, and security should be enabled by default.
The security foundations blueprint embodies these principles in multiple ways. Data is protected by default through multiple layered defenses using policy and controls that are configured across networking, encryption, IAM, detection, logging, and monitoring services.
As an example, the data in a production project by default has three levels of network protections: VPC segmentation, VPC service perimeters, and firewall rules and policies. Data is further protected by multiple levels of access protection using IAM, access context levels, and multi-factor validation of user identities.
The blueprint provides an example of a secured CI/CD pipeline to build applications that have access to the data; the security features of the pipeline include both build-time vulnerability assessments and deploy-time policy checks. In addition, the data itself is protected through customer-managed encryption keys (CMEKs). All admin access and data access can be logged using default audit logging. Security Command Center Premium tier provides ongoing security monitoring and detection. In addition, you can supplement this with custom detection through BigQuery.
BeyondProd
In 2019, we published BeyondProd, Google's new approach to native cloud security. This was motivated by the same insights that drove our BeyondCorp effort in 2014, because it had become clear to us that a perimeter-based security model wasn't secure enough. BeyondProd does for workloads and service identities what BeyondCorp did for workstations and users. In the conventional network-centric model, after an attacker breaches the perimeter, they have free movement within the system. Instead, the BeyondProd approach uses a zero-trust model by default. It decomposes historically large monolithic applications into microservices, thus increasing segmentation and isolation and limiting the impacted area, while also creating operational efficiencies and scalability.
A core concept in BeyondProd is that developers should be able to write and deploy secured applications without needing to have deep expertise in security, and without having to implement security features themselves. Therefore, the key tenets of BeyondProd are the following:
- Security is holistic and built in, not bolted on.
- Protection of the network at the edge, while still required, is not the primary and not the only defense point.
- No inherent mutual trust exists between services.
- Trusted machines run code with known provenance.
- Logical choke points are used for consistent policy enforcement across services—for example, to ensure authorized data access.
- Change rollout is simple, automated, and standardized.
- Isolation is enforced and monitored between workloads.
The security foundations blueprint jumpstarts your ability to adopt BeyondProd. Security controls are designed into and integrated throughout each step of the blueprint architecture and deployment. The different layers of security controls are designed to work together and are not an afterthought. No inherent mutual trust exists between services in the system. Predefined IAM roles create default separation of duties. The resource hierarchy design creates clear IAM and network boundaries between projects by default. VPC service perimeters enable you to enforce segmentation and isolation by service and by workload. Logical control choke points like organization policies provide you with consistent, default preventive policy enforcement at create time and deploy time. Centralized and unified visibility through Security Command Center Premium tier provides unified monitoring and detection across all the resources and projects in your organization.
You can learn more about how Google Cloud capabilities map to BeyondProd principles in the table in Mapping BeyondProd security principles to the secured application.
Shared fate
To move you from shared responsibility to shared fate, we believe that it's our responsibility to be active partners with you in deploying and running securely on our platform. This means providing holistic integrated capabilities throughout your Day 0 to Day N journey, as in the following:
- Design and build time: Supported security foundations and posture blueprints that encode best practices by default for your infrastructure and applications.
- Deploy time: Guard rails though services like organization policies and assured workloads that enforce your declarative security constraints.
- Run time: Visibility, monitoring, alerting, and corrective-action features through services like Security Command Center Premium.
Together, these integrated services reduce your risk by starting and keeping you in a more trusted posture with better quantified and understood risks. As shown in the diagram below, this improved risk posture can then allow you to take advantage of risk protection services, thus de-risking and ultimately accelerating your ability to migrate and transform in the cloud.
As the diagram above demonstrates, shared fate provides an opportunity for a cycle of improvement that is designed to accelerate your digital transformation: - You can use Risk Manager to reduce your risk. - Reduced risk helps you potentially procure specialized coverage at reduced cost with the Risk Protection Program. - The Risk Protection Program provides potentially reduced cost and tailored coverage. These benefits help free resources so that your organization can further drive digital transformation.
Shared fate helps us to partner with you to set up and operate your deployments more securely. With the acquisition of Mandiant, we can help you test and validate your posture, provide threat intelligence that's relevant to you, and be there with you during incident response and recovery. The following diagram shows how our partnership spans penetration testing, threat intelligence, security designs, managed defense, and incident response.
Landing zone options on Google Cloud
Google has invested in two key frameworks to help you start with best practices for your landing zones: security foundations blueprint and Fabric FAST. The framework that you use depends on how much you want to use pre-built examples versus how much you want to customize, maintain, and test on an ongoing basis.
Use the security foundations blueprint if you want to start with a pre-built landing zone that is embedded with Google guidance and maintained on an ongoing basis by the Google security team. The security foundations blueprint is part of a framework of Google's opinionated blueprints that incorporate Google security best practices and architectures across landing zones, workloads, and services. The portfolio of security blueprints based on this framework are tested end-to-end for interoperability. The blueprints are tailored primarily towards architects and practitioners who emphasize security out of the box as they provide off-the-shelf deployment with tested secured defaults. However, you can modify blueprints to meet specific requirements. The security foundations blueprint and the other security blueprints are all built on top of the Cloud Foundation Toolkit Terraform modules.
Fabric FAST is a landing zone based on Fabric. You can use this framework if you are interested in forking, maintaining, and customizing your own Terraform modules. It is less opinionated out-of-the-box, which provides with higher flexibility to customize the modules. Fabric is built with extensibility in mind, catering to fork-and-use patterns. Built-in testing is limited to unit tests on modules and examples.
What's next
- Read about how to use the Terraform example (next document in this series).