Encryption in transit  |  Documentation  |  Google Cloud (2024)

This is the third whitepaper on how Google uses encryption to protect yourdata. In this whitepaper, you will find moredetail on encryption in transit for Google Cloud and Google Workspace.

For all Google products, we strive to keep customer data highly protected andto be as transparent as possible about how we secure it.

This content was last updated in September 2022, and represents the status quoas of the time it was written. Google's security policies and systems may changegoing forward, as we continually improve protection for our customers.

CIO-level summary

• Google employs several security measures to help ensure the authenticity,integrity, and privacy of data in transit.
• For the use cases discussed in this whitepaper, Google encrypts andauthenticates data in transit at one or more networklayers when data moves outside physical boundaries not controlled by Google oron behalf of Google. All VM-to-VM traffic within a VPC networkand peered VPC networks is encrypted.
• Depending on the connection that is being made, Google applies defaultprotections to data in transit. For example, we secure communications betweenthe user and the Google Front End (GFE) using TLS.
• Google Cloud customers with additional requirements for encryption of dataover WAN can choose to implement further protections for data as it movesfrom a user to an application, or virtual machine to virtual machine. Theseprotections include IPSec tunnels, Gmail S/MIME, managed SSL certificates,and Istio.
• Google works actively with the industry to help bring encryption in transit toeveryone, everywhere. We have several open-source projects that encourage theuse of encryption in transit and data security on the Internet at largeincluding Certificate Transparency, Chrome APIs, and secure SMTP.
• Google plans to remain the industry leader in encryption in transit. To thisend, we dedicate resources toward the development and improvement ofencryption technology. Our work in this area includes innovations in the areasof Key Transparency and post-quantum cryptography.

Introduction

Security is often a deciding factor when choosing a public cloud provider.At Google, security is of the utmost importance. We work tirelessly to protectyour data—whether it is traveling over the Internet, moving within Google'sinfrastructure, or stored on our servers.

Central to Google's security strategy are authentication, integrity, andencryption, for both data at rest and in transit. This paper describes ourapproach to encryption in transit for Google Cloud.

For data at rest, see Encryption at Rest in Google Cloud Platform.For an overview across all of Google Security, see Google Infrastructure Security Design Overview.

Audience: this document is aimed at CISOs and security operations teamsusing or considering Google Cloud.

Prerequisites: in addition to this introduction, we assume a basicunderstanding of encryption andcryptographic primitives.

Authentication, Integrity, and Encryption

Google employs several security measures to help ensure the authenticity,integrity, and privacy of data in transit.

• Authentication: we verify the data source, either a human or a process,and destination.
• Integrity: we make sure data you send arrives at its destination unaltered.
• Encryption: we make your data unreadable while in transit to keep itprivate. Encryption is the process through which legibledata (plaintext) is made illegible (ciphertext) with the goal of ensuring theplaintext is only accessible by parties authorized by the owner of the data.The algorithms used in the encryption process are public, but the key requiredfor decrypting the ciphertext is private. Encryption in transit often usesasymmetric key exchange, such as elliptic-curve-based Diffie-Hellman, toestablish a shared symmetric key that is used for data encryption. For moreinformation on encryption, see Introduction to Modern Cryptography.

Encryption can be used to protect data in three states:

• Encryption at rest protects your data from a system compromise or dataexfiltration by encrypting data while stored. The Advanced EncryptionStandard (AES) is often used to encrypt data at rest.
• Encryption in transit: protects your data if communications areintercepted while data moves between your site and the cloud provider orbetween two services. This protection is achieved by encrypting the databefore transmission; authenticating the endpoints; and, on arrival,decrypting and verifying that the data was not modified. For example,Transport Layer Security (TLS) is often used to encrypt data in transit fortransport security, and Secure/Multipurpose Internet Mail Extensions(S/MIME) is used often for email message encryption.
• Encryption in use: protects your data in memory from compromise or dataexfiltration by encrypting data while being processed. For more information,see Confidential Computing.

Encryption is one component of a broader security strategy. Encryption intransit defends your data, after a connection is established and authenticated,against potential attackers by:

• Removing the need to trust the lower layers of the network which are commonlyprovided by third parties
• Reducing the potential attack surface
• Preventing attackers from accessing data if communications are intercepted

With adequate authentication, integrity, and encryption, data that travelsbetween users, devices, or processes can be protected in a hostile environment.The remainder of this paper explains Google's approach to the encryption of datain transit and where it is applied.

Google's Network Infrastructure

Physical boundaries

A physicalboundary is the barrier to a physical space that is controlled by or on behalfof Google, where we can ensure that rigorous security measures are in place.Physical access to these locations is restricted and heavily monitored. Only asmall set of Google employees have access to hardware. Data in transit withinthese physical boundaries is generally authenticated, but may not be encryptedby default.

Due to the scale of the global Internet, we cannot put the same physicalsecurity controls in place for the fiber links in our WAN, or anywhere outsideof physical boundaries controlled by or on behalf of Google. For this reason, weautomatically enforce additional protections outside of our physical trustboundary. These protections include encryption of data in transit for alltraffic outside of our physical boundaries.

How traffic gets routed

To fully understand how encryption in transit works at Google, it isalso necessary to explain how traffic gets routed through the Internet. Thissection describes how requests get from an end user to the appropriateGoogle Cloud service or customer application, and how traffic is routedbetween services.

A Google Cloud service is a modular cloud service that we offer to ourcustomers. These services include compute, data storage, data analytics andmachine learning. For example, Cloud Storage is a Google Cloudservice. A customer application is an application hosted onGoogle Cloud that you, as a Google customer, can build and deploy usingGoogle Cloud services. Customer applications or partner solutions that arehosted on Google Cloud are not considered Google Cloudservices¹. For example, an application you build usingGoogle App Engine, Google Kubernetes Engine, or a VM in GoogleCompute Engine is a customer application.

The five kinds of routing requests discussed below are shown in Figure 1.This figure shows the interactions between the various network components andthe security in place for each connection.

End user (Internet) to a Google Cloud Service

Google Cloud services accept requests from around the world using a globallydistributed system called the Google Front End (GFE). GFE terminates traffic forincoming HTTP(S), TCP and TLS proxy traffic,provides DDoS attackcountermeasures, and routes and load balances traffic to the Google Cloudservices themselves. There are GFE points of presence around the globe withroutes advertised via unicast or Anycast.

GFEs proxy traffic to Google Cloud services. GFEs route the user's request overour network backbone to a Google Cloud service. This connection is authenticatedand encrypted from GFE to the front-end of the Google Cloud service or customerapplication, when those communications leave a physical boundary controlled byGoogle or on behalf of Google. Figure 1 shows this interaction(labeled connection A).

End user (Internet) to a customer application hosted on Google Cloud

There are several ways traffic from the Internet can be routed to a customerapplication you host on Google Cloud. The way your traffic is routed depends onyour configuration, as explained below. Figure 1 shows this interaction(labeled connection B).

If you are using an external Application Load Balancer or an external proxy Network Load Balancer (with an SSL proxy), seeEncryption from the load balancer to the backends.

Virtual Machine to Virtual Machine

VM-to-VM connections within VPC networks and peeredVPC networks inside of Google's production network areauthenticated and encrypted. This includes connections between customer VMs andbetween customer and Google-managed VMs such as Cloud SQL. Figure 1 showsthis interaction (labeled connection C). Note that VM-to-VM connections thatuse external IP addresses are not encrypted.

Connectivity to Google APIs and services

Traffic handling differs depending on the location of the Google Cloud service:

• Most Google APIs and services are hosted on Google Front Ends (GFEs); however,some services are hosted on Google-managed instances. For example, privateservices access and GKEmasters for privateclusters are hostedon Google-managed instances.

  With Private Google Access, VMsthat don't have external IP addresses can access supported Google APIs andservices, including customerapplications hosted on App Engine. For more information about access toGoogle APIs and services, see Private access options forservices.

• If a Compute Engine VM instance connects to the external IP address ofanother Compute Engine VM instance, traffic remains in Google'sproduction network but isn’t encrypted because of the use of the external IP address.Systems that are outside of Google's production networkthat connect to an external IP address of a Compute Engine VM instancehave traffic routed over the internet.

  See Also

  InfoSec Glossary: Transport Layer Security (TLS)HTTP vs HTTPS vs TCP vs TLS vs UDP - Protocol Comparison - AWS Certification Cheat SheetWhat Is a TLS/SSL Handshake and How It Works - SematextWhat is transport layer? – TechTarget Definition

  Figure 1 shows an external path (labeled connection D). Typical cases of thiskind of routing request are:

  • From a Compute Engine VM to Google Cloud Storage
  • From a Compute Engine VM to a Machine Learning API

From the VM to the GFE, Google Cloud services support protecting theseconnections with TLS by default². The connection isauthenticated from the GFE to the service and encrypted if the connection leavesa physical boundary. In addition to these default protections, you can applyenvelope encryption. For more information, seeEncrypt your data.

Google Cloud service to Google Cloud service

Routing from one production service to another takes place on our networkbackbone and may require routing traffic outside of physical boundariescontrolled by or on behalf of Google. Figure 1 shows this interaction(labeled connection E). An example of this kind of traffic is a Google CloudStorage event triggering Google Cloud Functions. Connections between productionservices are encrypted if they leave a physical boundary, and authenticatedwithin the physical boundary.

Figure 1: Protection by default and options overlaid on a VPC network

Encryption in Transit by Default

Google uses various methods of encryption, both default and user configurable,for data in transit. The type of encryption used depends on the OSI layer, thetype of service, and the physical component of the infrastructure. Figures 2 and3 below illustrate the optional and default protections Google Cloud has inplace for layers 3, 4, and 7.

Figure 2: Protection by Default and Options at Layers 3 and 4 across Google Cloud

Figure 3: Protection by Default and Options at Layer 7 across Google Cloud³

The remainder of this section describes the default protections that Google usesto protect data in transit.

User to Google Front End encryption

Today, many systems use HTTPS to communicate over the Internet.HTTPS provides security by using a TLS connection, which ensures theauthenticity, integrity, and privacy of requests and responses.To accept HTTPS requests, the receiver requires a public–private key pair and anX.509 certificate for server authentication from a Certificate Authority (CA).The key pair and certificate help protect a user's requests at the applicationlayer (layer 7) by proving that the receiver owns the domain name for whichrequests are intended. The following subsections discuss the components of userto GFE encryption, namely: TLS, BoringSSL, and Google's Certificate Authority.Recall that not all customer paths route via the GFE; notably, the GFE is usedfor traffic from a user to a Google Cloud service, and from a user to acustomer application hosted on Google Cloud that uses Google CloudLoad Balancing.

Transport Layer Security (TLS)

When a user sends a request to a Google Cloud service, we secure the data intransit; providing authentication, integrity, and encryption, using HTTPSwith a certificate from a web (public) certificate authority. Any datathe user sends to the GFE is encrypted in transit with Transport Layer Security(TLS) or QUIC. GFE negotiates a particular encryption protocol with the clientdepending on what the client is able to support. GFE negotiates more modernencryption protocols when possible.

GFE's scaled TLS encryption applies not only to end-user interactions withGoogle, it also facilitates API interactions with Google over TLS, includingGoogle Cloud. Additionally, our TLS encryption is used in Gmail to exchangeemail with external mail servers (more detail inRequire TLS in Gmail).

Google is an industry leader in both the adoption of TLS and the strengtheningof its implementation. To this end, we have enabled, by default, many of thesecurity features of TLS. For example, since2011we have been using forward secrecy in our TLS implementation. Forward secrecymakes sure the key that protects a connection is not persisted, so an attackerthat intercepts and reads one message cannot read previous messages.

BoringSSL

BoringSSL is a Google-maintained,open-source implementation of the TLS protocol, forked from OpenSSL, that ismostly interface-compatible with OpenSSL. Google forked BoringSSL fromOpenSSL to simplifyOpenSSL, both for internal use and to better support the Chromiumand Android Open Source Projects. BoringCrypto, the core of BoringSSL, has beenvalidated to FIPS 140-2 level 1.

TLS in the GFE is implemented with BoringSSL. Table 1 shows the encryptionprotocols that GFE supports when communicating with clients.

Table 1: Encryption Implemented in the Google Front End for Google CloudServices and Implemented in the BoringSSL Cryptographic Library

Google's Certificate Authority

As part of TLS, a server must prove its identity to the user when it receives aconnection request. This identity verification is achieved in the TLS protocolby having the server present a certificate containing its claimed identity. Thecertificate contains both the server's DNS hostname and its public key. Oncepresented, the certificate is signed by an issuing Certificate Authority (CA)that is trusted by the user requesting the connection⁹.As a result, users who request connections to the server only need to trust theroot CA. If the server wants to be accessed ubiquitously, the root CA needs tobe known to the client devices worldwide. Today, most browsers, and other TLSclient implementations, each have their own set of root CAs that are configuredas trusted in their “root store”.

Historically, Google operated its own issuing CA, which we used to signcertificates for Google domains. We did not, however, operate our own root CA.Today, our CA certificates are cross-signed by multiple root CAs which areubiquitously distributed, including DigiCert and roots previouslyoperated by GlobalSign (“GS Root R2” and “GS Root R4”).

In June 2017, we announceda transition to using Google-owned root CAs. Over time, we plan to operate aubiquitously distributed root CA which will issue certificates for Googledomains and for our customers.

Root key migration and key rotation

Root CA keys are not changed often, as migrating to a new root CA requires allbrowsers and devices to embed trust of that certificate, which takes a longtime. As a result, even though Google now operates its own root CAs, we willcontinue to rely on multiple third-party root CAs for a transitional period toaccount for legacy devices while we migrate to our own.

Creating a new root CA key requires a key ceremony. At Google, the ceremonymandates that a minimum 3 of the 6 possible authorized individuals physicallygather to use hardware keys that are stored in a safe. These individuals meet ina dedicated room, shielded from electromagnetic interference, with an air-gappedHardware Security Module (HSM), to generate a set of keys and certificates. Thededicated room is in a secure location in Google data centers. Additionalcontrols, such as physical security measures, cameras, and other humanobservers, ensure that the process goes as planned. If the ceremony issuccessful the generated certificate is identical to a sample certificate,except for the issuer name, public key and signature. The resulting root CAcertificate is then submitted to browser and device root programs for inclusion.This process is designed to ensure that the privacy and security of theassociated private keys are well understood so the keys can be relied upon for adecade or more.

As described earlier, CAs use their private keys to sign certificates, and thesecertificates verify identities when initiating a TLS handshake as part of a usersession. Server certificates are signed with intermediate CAs, the creation ofwhich is similar to the creation of a root CA. The intermediate CA'scertificates are distributed as part of the TLS session so it's easier tomigrate to a new intermediate CA. This method of distribution also enables theCA operator to keep the root CA key material in an offline state.

The security of a TLS session is dependent on how well the server's key isprotected. To further mitigate the risk of key compromise, Google's TLScertificate lifetimes are limited to approximately three months and thecertificates are rotated approximately every two weeks.

A client that has previously connected to a server can use a private ticket key¹⁰to resume a prior session with an abbreviated TLS handshake, making thesetickets very valuable to an attacker. Google rotates ticket keys at least once aday and expires the keys across all properties every 3 days. To learn more aboutsession key ticket rotation, see Measuring the Security Harm of TLS CryptoShortcuts.

Google Front End to Application Front Ends

In some cases, as discussed in How traffic getsrouted, the user connects to a GFE inside ofa different physical boundary than the desired service and the associatedApplication Front End. When this occurs, the user's request and any other layer7 protocol, such as HTTP, is either protected by TLS, or encapsulated in an RPCwhich is protected using Application Layer Transport Security (ALTS), discussedin Service-to-service authentication, integrity, andencryption. These RPCs are authenticated andencrypted.

For Google Cloud services, RPCs are protected using ALTS. Forcustomer applications hosted on Google Cloud, if traffic is routed via theGoogle Front End, for example if they are using the Google Cloud Load Balancer,traffic to the VM is protected using Google Cloud's virtual network encryption,described in the next section.

Google Cloud's virtual network encryption and authentication

Encryption of private IP traffic within the same VPC or acrosspeered VPC networks within Google Cloud's virtual networkis performed at the network layer.

We use the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) witha 128-bit key (AES-128-GCM) to implement encryption at the network layer. Eachpair of communicating hosts establishes a session key via a control channelprotected by ALTS for authenticated andencrypted communications. The session key is used toencrypt all VM-to-VM communication between those hosts, and session keys arerotated periodically.

At the network layer (layer 3), Google Cloud's virtual network authenticates alltraffic between VMs. This authentication, achieved via security tokens, protectsa compromised host from spoofing packets on the network.

During authentication, security tokens are encapsulated in a tunnel header whichcontains authentication information about the sender and receiver. The controlplane¹¹ on the sending side sets the token, and thereceiving hostvalidates the token. Security tokens are pre-generated for every flow, andconsist of a token key (containing the sender's information) and the hostsecret. One secret exists for every source-receiver pair of physical boundariescontrolled by or on behalf of Google.

Figure 4 shows how token keys, host secrets, and security tokens are created.

Figure 4: Security Tokens

The physical boundary secret is a 128-bit pseudorandom number, from which hostsecrets are derived by taking an HMAC-SHA1. The physical boundary secret isnegotiated by a handshake between the network control planes of a pair ofphysical boundaries and renegotiated every few hours. The security tokens usedfor individual VM-to-VM authentication, derived from these and other inputs, areHMACs, negotiated for a given sender and receiver pair.

Virtual machine to Google Front End encryption

VM to GFE traffic uses external IPs to reach Google services, but you canconfigurePrivate access to use Google-only IP addresses for the requests.

By default, we support TLS traffic from a VM to the GFE. The connection happensin the same way as any other external connection. For more information on TLS,seeTransport Layer Security (TLS).

Service-to-service authentication, integrity, and encryption

Within Google's infrastructure, at the application layer (layer 7), we use ourApplication Layer Transport Security(ALTS)for the authentication, integrity, and encryption of Google RPC calls from theGFE to a service, and from service to service.

ALTS uses service accounts for authentication. Each service that runs inGoogle's infrastructure runs as a service account identity with associatedcryptographic credentials. When making or receiving RPCs from other services,a service uses its credentials to authenticate. ALTS verifies these credentialsusing an internal certificate authority.

Within a physical boundary controlled by or on behalf of Google, ALTS providesboth authentication and integrity for RPCs in “authentication and integrity”mode. For traffic over the WAN outside of physical boundaries controlled by oron behalf of Google, ALTS enforces encryption for infrastructure RPC trafficautomatically in “authentication, integrity, and privacy” mode. Currently, alltraffic to Google services, including Google Cloud services, benefits from thesesame protections.

ALTS is also used to encapsulate other layer 7 protocols, such as HTTP, ininfrastructure RPC mechanisms for traffic moving from the Google Front End tothe Application Front End. This protection isolates the application layer andremoves any dependency on the network path's security.

Security infrastructure services accept and send ALTS communications only in“authentication, integrity and privacy” mode, even within physical boundariescontrolled by or on behalf of Google. One example isKeystore, whichstores and manages the encryption keys used to protect data stored at rest inGoogle's infrastructure.

Network encryption using PSP

The PSP Security Protocol (PSP) is transport-independent, enablesper-connection security, and supports offloading of encryption to smart networkinterface card (SmartNIC) hardware. Whenever SmartNICs are available, we use PSPto encrypt data in transit across our network.

PSP is designed to meet the requirements of large-scale data-center traffic. Weuse PSP to encrypt traffic in and between our data centers. PSP supports non-TCPprotocols such as UDP and uses an encryption key for each Layer 4 connection.

For more information about how we use PSP, seeAnnouncing PSP's cryptographic hardware offload at scale is now open source.

ALTS Protocol

ALTS has a secure handshake protocol similar to mutual TLS. Two services wishingto communicate using ALTS employ this handshake protocol to authenticate andnegotiate communication parameters before sending any sensitive information.The protocol is a two-step process:

• Step 1:HandshakeThe client initiates an elliptic curve-Diffie Hellman (ECDH) handshake withthe server using Curve25519. The client and server each have certified ECDHpublic parameters as part of their certificate, which is used during a DiffieHellman key exchange. The handshake results in a common traffic key that isavailable on the client and the server. The peer identities from thecertificates are surfaced to the application layer to use in authorizationdecisions.
• Step 2: Record encryptionUsing the common traffic key from Step 1, data is transmitted from the clientto the server securely. Encryption in ALTS is implemented using BoringSSL andother encryption libraries. Encryption is most commonly AES-128-GCM whileintegrity is provided by AES-GCM's GMAC.

The following diagram shows the ALTS handshake in detail. In newerimplementations, a process helper does the handshake; there are still some caseswhere this is done directly by the applications.

Figure 5: ALTS handshake

As described at the start of section Service-to-service authentication,integrity, and encryption, ALTS uses serviceaccounts forauthentication, with each service that runs on Google's infrastructure runningas a service identity with associated cryptographic credentials. During the ALTShandshake, the process helper accesses the private keys and correspondingcertificates that each client-server pair uses in their communications. Theprivate key and corresponding certificate (signed protocolbuffer)have been provisioned for the service account identity of the service.

ALTS CertificatesThere are multiple kinds of ALTS certificate:

• Machine certificates: provide an identity to core services on a specificmachine. These are rotated approximately every 6 hours.
• User certificates: provide an end user identity for a Google engineerdeveloping code. These are rotated approximately every 20 hours.
• Borg job certificates:provide an identity to jobs running within Google's infrastructure. These arerotated approximately every 48 hours.

The root certification signing key is stored in Google's internal certificateauthority (CA), which is unrelated and independent of our externalCA.

Encryption in ALTS

Encryption in ALTS can be implemented using a variety of algorithms, dependingon the machines that are used. For example, most services use AES-128-GCM¹².More information on ALTS encryption can be found in Table 2.

Table 2: Encryption in ALTS

Most Google services use ALTS, or RPC encapsulation that uses ALTS. In caseswhere ALTS is not used, other protections are employed. For example:

• Some low-level machine management and bootstrapping services use SSH
• Some low-level infrastructure logging services TLS or Datagram TLS (DTLS)¹³
• Some services that use non-TCP transports use other cryptographic protocols ornetwork level protections when inside physical boundaries controlled by or onbehalf of Google

Communications between VMs and Google Cloud Platform services use TLS tocommunicate with the Google Front End, not ALTS. We describe thesecommunications in Virtual machine to Google Front Endencryption.

Configuring other encryption in transit options

You can configure protections for your data when it is in transit betweenGoogle Cloud and your data centers, or in transit between your applications thatare hosted on Google Cloud and user devices.

If you are connecting your data center to Google Cloud, consider thefollowing:

• Use TLS with either theexternal Application Load Balancer or the external proxy Network Load Balancer to connect to your cloud service. GFE terminates the TLS connections fromyour users using SSL certificates that you provision and control. For moreinformation about customizing your certificate, seeSSL certificates overview.
• Create an IPSec tunnel usingCloud VPN or useCloud Interconnect tosecurely connect your on-premises network to your Virtual Private Cloud network. Formore information, seeChoosing a Network Connectivity product.
• Use MACsec for Cloud Interconnect to help secure traffic between youron-premises router and Google's edge routers. For more information, seeMACsec for Cloud Interconnectoverview.

If you are connecting your user devices to applications running inGoogle Cloud, consider the following:

• Use GFE's support of TLS by configuring the SSL certificate that youuse. For example, you can have the TLS session terminate in your application.
• Consider our free and automated SSL certificates, that are available forboth theFirebase Hosting andApp Engine custom domains. With App Engine custom domains, you can alsoprovide your own SSL certificates and use an HTTP Strict Transport Security (HSTS) header.
• For workloads on GKE and Compute Engine, considerGKE Enterprise service mesh so that you can use mTLS for authentication, which ensures that all TCPcommunications are encrypted in transit.

If you are using Google Workspace,configure Gmail to enable S/MIME for outgoing emails,set up policies for content and attachment compliance, and create routing rules for incoming andoutgoing emails.

Research and innovation in encryption in transit

Over the years, we have been involved in several open-source projects and otherefforts that encourage the use of encryption in transit on the internet.

These efforts include:

• Certificate Transparency (CT) is an effort that we launched to provide a way for site operators anddomain holders to detect if a CA has issued any unauthorized or incorrectcertificates.
• Our annualHTTPS Transparency Report tracks our progress towards our goal of 100% encryption in transit for allour properties, including Google Cloud.
• The development of thecombined elliptic-curve and post-quantum (CECPQ2) algorithm, whichhelps protect TLS connections against quantum computer attacks.

For more information about our recent contributions, seeCollaboration with the security research community.

What's next

• For general information on Google Cloud security, includingsecurity best practices, see theSecurity section of the Google Cloud website.
• For information on Google Cloud compliance and compliancecertifications, see theCompliance section of the Google Cloud website,which includes Google'spublic SOC3 audit report.
• For best practices on how to secure your data in transit, see theenterprise foundations blueprint andGoogle Cloud Architecture Framework: Security, privacy, and compliance,andDecide how to meet regulatory requirements for encryption in transit.