How Google Encrypts Data in the Cloud

SHARE
Share it on Twitter  
Share it on Facebook  
Share it on Google+
Share it on Linked in  
Email  

Google operates one of the largest cloud networks on the planet and uses multiple techniques to keep the data that moves across the network as secure as possible. Google is now providing some insight into how it secures data connections with encryption both to and within its cloud infrastructure.

Google, like everyone else, uses Transport Layer Security (TLS) to encrypt connections for data in motion from external hosts to the Google Cloud. Unlike everyone else, Google has its own approach for encrypting data connections within its own data centers called Application Layer Transport Security (ALTS). Google has provided details on both its TLS and ALTS usage in a pair of whitepapers released on Dec. 13.

"We get a lot of customer questions about encryption, so we're trying to build trust through transparency," Maya Kaczorowski, Security and Privacy Product Manager at Google, told eSecurityPlanet.

Kaczorowski said that when a user connects to the Google Cloud, by default the connection is encrypted with TLS. She added that by default Google Cloud authenticates all data in transit as one or more network layers. When data moves outside of the physical boundary of Google, Kaczorowski said that Google takes additional steps to help protect data.

Of note, Google is making use of TLS 1.3, which is not yet an official IETF standard. Kaczorowski said that Google has implemented a draft version of TLS 1.3, which provides improved cryptographic protection over prior iterations of both TLS and its predecessor SSL.

ALTS

The idea of doing an application layer of transport security is not unique to Google. Container vendor Docker has a model for its Swarm orchestration technology called mutually authenticated TLS (mTLS), which provides encryption for data in motion across a container cluster.

Kaczorowski said that Google has been using ALTS for many years at full production scale. She explained that Google developed ALTS prior to the development of mTLS and was purpose-built for Google's own infrastructure.

There are several differences between TLS for data in motion encryption and ALTS for encryption of data in motion within Google.

"TLS uses X.509 certificates, while ALTS uses protocol buffers," Kaczorowski said.

Protocol buffers are extensively used within Google's infrastructure and were first introduced a decade ago. Kaczorowski explained that Protocol Buffers are a language-neutral technology for serializing data.

"It's not based in hardware, Protocol Buffers are just a way for storing and transmitting information," Kaczorowski said.

ALTS is un-related to Google's own BeyondCorp zero-trust model that operates within the Google infrastructure. Kaczorowski explained that BeyondCorp is all about how Google employees access internal applications and resources.

"With ALTS, what we're talking about is how every service at Google can authenticate with each other," Kaczorowski said.

ISTIO

Google is now also working on the open-source Istio service mesh project for Kubernetes, which has some similarities to Google's own ALTS approach.

"Istio authentication automatically aims to encrypt data transit between services," she said. "The concept is similiar to ALTS."

ALTS is however configured just for Google's own infrastructure and is not visible to end-users. In contrast, Istio can be implemented by users and is initially focused on container workloads.

Encryption at Rest

Beyond encrypting data in motion with TLS and ALTS, Google also encrypts data when it is at rest and not moving.

"For encryption in transit we have encryption at the network layer (Layer 3) and at the application layer (Layer 7)," Kaczorowski said. "With encryption at rest we're encrypting both at the storage device layer and at the storage system layer."

"We want to have multiple layers that we can fall back on," she said.

Sean Michael Kerner is a senior editor at eSecurityPlanet and InternetNews.com. Follow him on Twitter @TechJournalist.

JOIN THE DISCUSSION

Loading Comments...