Example: bankruptcy

Google Infrastructure Security Design Overview

Google Infrastructure SecurityDesign OverviewMarch 2022 Table of contentsIntroduction3 Secure low-level infrastructure4 Security of physical premises4 Hardware Design and provenance4 Secure boot stack and machine identity4 Secure service deployment5 Service identity, integrity, and isolation6 Inter-service access management6 Encryption of inter-service communication7 Access management of end-user data in Google Workspace7 Secure data storage9 Encryption at rest9 Deletion of data10 Secure internet communication10 Google Front End service10 DoS protection11 User authentication11 Operational security12 Safe software development12 Source code protections12 Keeping employee devices and credentials safe13 Reducing insider risk13 Threat monitoring13 Intrusion detection14 What s next14 This content was last updated in March 2022, and represents the status quo as of the time it waswritten.

WAN traversal hop of customer VM to VM traffic. As described earlier, all control plane WAN traffic within the infrastructure is already encrypted. In the future we plan to take advantage of the hardware-accelerated network encryption discussed earlier to also encrypt inter-VM LAN traffic within the data center.

Tags:

  Infrastructures, Traversal

Information

Domain:

Source:

Link to this page:

Please notify us if you found a problem with this document:

Other abuse

Transcription of Google Infrastructure Security Design Overview

1 Google Infrastructure SecurityDesign OverviewMarch 2022 Table of contentsIntroduction3 Secure low-level infrastructure4 Security of physical premises4 Hardware Design and provenance4 Secure boot stack and machine identity4 Secure service deployment5 Service identity, integrity, and isolation6 Inter-service access management6 Encryption of inter-service communication7 Access management of end-user data in Google Workspace7 Secure data storage9 Encryption at rest9 Deletion of data10 Secure internet communication10 Google Front End service10 DoS protection11 User authentication11 Operational security12 Safe software development12 Source code protections12 Keeping employee devices and credentials safe13 Reducing insider risk13 Threat monitoring13 Intrusion detection14 What s next14 This content was last updated in March 2022, and represents the status quo as of the time it waswritten.

2 Google 's Security policies and systems may change going forward, as we continually improveprotection for our document provides an Overview of how Security is designed into Google 's technicalinfrastructure. It is intended for Security executives, Security architects, and document describes the following: Google s global technical Infrastructure , which is designed to provide Security throughthe entire information processing lifecycle at Google . This Infrastructure helps providethe following: Secure deployment of services Secure storage of data with end-user privacy safeguards Secure communication between services Secure and private communication with customers over the internet Safe operation by Google engineers How we use this Infrastructure to build internet services, including consumer servicessuch as Google Search, Gmail, and Google Photos, and enterprise services such asGoogle Workspace and Google Cloud.

3 Our investment in securing our Infrastructure and operations. We have many engineerswho are dedicated to Security and privacy across Google , including many who arerecognized industry authorities. The Security products and services that are the result of innovations that weimplemented internally to meet our Security needs. For example,BeyondCorpis thedirect result of our internal implementation of thezero-trust Security model. How the Security of the Infrastructure is designed in progressive layers. These layersinclude the following: Low-level Infrastructure Service deployment Data storage Internet communication OperationsThe remaining sections of this document describe the Security low-level infrastructureThis section describes how we secure the physical premises of our data centers, the hardwarein our data centers, and the software stack running on the of physical premisesWe Design and build our own data centers, which incorporate multiple layers of physicalsecurity.

4 Access to these data centers is tightly controlled. We use multiple physical securitylayers to protect our data center floors. We use biometric identification, metal detection,cameras, vehicle barriers, and laser-based intrusion detection systems. For more information,seeData center also host some servers in third-party data centers. In these data centers, we ensure thatthere are Google -controlled physical Security measures on top of the Security layers that areprovided by the data center operator. For example, we operate biometric identification systems,cameras, and metal detectors that are independent from the Security layers that the data centeroperator Design and provenanceA Google data center consists of thousands of servers connected to a local network.

5 We designthe server boards and the networking equipment. We vet the component vendors that we workwith and choose components with care. We work with vendors to audit and validate the securityproperties that are provided by the components. We also Design custom chips, including ahardware Security chip (calledTitan), that we deployon servers, devices, and chips let us identify and authenticate legitimate Google devices at the hardware level andserve as hardware roots of : Variants of the Titan hardware chip are alsoused inPixel devicesand theTitan boot stack and machine identityGoogle servers use various technologies to ensure that they boot the correct software stack.

6 Weuse cryptographic signatures for low-level components like the baseboard managementcontroller (BMC), BIOS, bootloader, kernel, and base operating system image. These signaturescan be validated during each boot or update cycle. The first integrity check for Google serversuses a hardware root of trust. The components are Google -controlled, built, and hardened withintegrity attestation. With each new generation of hardware, we strive to continually example, depending on the generation of server Design , the boot chain s root of trust is inone of the following: The Titan hardware chip A lockable firmware chip A microcontroller running our own Security codeEach server in the data center has its own unique identity.

7 This identity can be tied to thehardware root of trust and the software with which the machine boots. This identity is used toauthenticate API calls to and from low-level management services on the machine. This identityis also used for mutual server authentication and transport encryption. We developed theApplication Layer Transport Security (ALTS)systemfor securing remote procedure call (RPC)communications within our Infrastructure . These machine identities can be centrally revoked torespond to a Security incident. In addition, their certificates and keys are routinely rotated, andold ones developed automated systems to do the following: Ensure that servers run up-to-date versions of their software stacks (including securitypatches).

8 Detect and diagnose hardware and software problems. Ensure the integrity of the machines and peripherals with verified boot and implicitattestation. Ensure that only machines running the intended software and firmware can accesscredentials that allow them to communicate on the production network. Remove or re-allocate machines from service when they re no longer service deploymentGoogle services are the application binaries that our developers write and run on ourinfrastructure. Examples of Google services are Gmail servers, Spanner databases, CloudStorage servers, YouTube video transcoders, and Compute Engine VMs running customerapplications. To handle the required scale of the workload, thousands of machines might berunning binaries of the same service.

9 A cluster orchestration service, calledBorg, controls theservices that are running directly on the Infrastructure does not assume any trust between the services that are running on theinfrastructure. This trust model is referred to as azero-trust Security model. A zero-trust securitymodel means that no devices or users are trusted by default, whether they are inside or outsideof the the Infrastructure is designed to be multi-tenant, data from our customers (consumers,businesses, and even our own data) is distributed across shared Infrastructure . Thisinfrastructure is composed of tens of thousands of homogeneous machines. The infrastructuredoes not segregate customer data onto a single machine or set of machines, except in specificcircumstances, such as when you are using Google Cloud to provision VMs onsole-tenantnodes for Compute Cloud and Google Workspace support regulatory requirements around data more information about data residency and Google Cloud, seeImplement data residencyand sovereignty requirements.

10 For more informationabout data residency and GoogleWorkspace, seeData regions: Choose a geographic locationfor your identity, integrity, and isolationTo enable inter-service communication, applications use cryptographic authentication andauthorization. Authentication and authorization provide strong access control at an abstractionlevel and granularity that administrators and services can do not rely on internal network segmentation or firewalling as the primary securitymechanism. Ingress and egress filtering at various points in our network helps prevent IPspoofing. This approach also helps us to maximize our network's performance and Google Cloud, you can add additional Security mechanisms such asVPC Service ControlsandCloud service that runs on the Infrastructure has an associated service account identity.


Related search queries