Data security is a huge part of an organization’s security posture. Encryption is a core control for data security, and Google Cloud offers multiple encryption options for data at-rest, in-transit, and even in-use. Let’s shed some light on each of these.
Encryption
Encryption at rest by default
To help protect your data, Google encrypts data at rest, ensuring that it can only be accessed by authorized roles and services, with audited access to the encryption keys. Data is encrypted prior to it being written to disk. here is how:
-
Data is first “chunked” – broken up into pieces, and each chunk is encrypted with its own data encryption key.
-
Each data encryption key is wrapped using a key encryption key. The encrypted chunks and wrapped encryption keys are then distributed across Google’s storage infrastructure.
-
If a chunk of data is updated, it is encrypted with a new key, rather than by reusing the existing key.
When data needs to be retrieved, the process repeats in reverse. As a result, if an attacker were to compromise an individual key or gain physical access to storage, they would still be unable to read customer data – as they need to identify all the data chunks in an object, retrieve them, and retrieve the associated encryption keys.
Encryption in transit by default
All communications over the Internet to Google Cloud require properly terminated TLS connections. Encryption in transit protects your data if communications are intercepted while data moves between your site and the cloud provider or between two services. This protection is achieved by encrypting the data before transmission; authenticating the endpoints; and decrypting and verifying the data on arrival. For example, Transport Layer Security (TLS) is often used to encrypt data in transit for transport security, and Secure/Multipurpose Internet Mail Extensions (S/MIME) is used often for email message security.
Encryption in use: Confidential computing
Confidential Computing adds a “third pillar” which protects your data in memory from compromise or exfiltration by encrypting data while it is being processed. You can encrypt your data in-use with Confidential VMs and Confidential GKE Nodes. This builds on the protections Shielded VMs offer against rootkit and bootkits.
Main memory encryption is performed using dedicated hardware within on-die memory controllers. Each controller includes a high-performance AES engine. The AES engine encrypts data as it is written toDRAM or shared between sockets, and decrypts it when data is read. Google does not have access to the encryption key.
At-rest Encryption options
While in some cases the encryption by default might be all you need, Google Cloud provides other options for customers based on their trust level and business needs.
Customer Supplied Encryption Keys (CSEK)
If you need to operate with minimal trust, you can use Customer Supplied Encryption Keys (CSEK) which enable you to maintain your own separate root of trust and push keys at time of use to Google Cloud via an API. Those keys are stored in RAM during the time required to perform the specific operation.
With CSEK, the burden and responsibility of protecting and not losing keys falls with you. Google has no way to recover your data if your keys are inadvertently deleted or lost. It is very easy to get this wrong. So, if you use CSEK then you need to be exceedingly careful and must also invest in your own key distribution system to push keys to Google to match the rate of use in your applications.
Key Management Service (Cloud KMS)
Another option is Cloud Key Management Service which enables you to leverage our globally scalable key management system while maintaining control of key operations including full audit logging of your keys. This solution alleviates the need for you to create your own key distribution system while still enabling you to control the visibility of your keys.
With KMS, keys created and maintained in Cloud KMS are used as the key-encryption keys in place of Google’s default key-encryption keys.
Hardware security modules (HSM)
You can also optionally store keys in a cloud-hosted hardware security module. service that allows you to host encryption keys and perform cryptographic operations in a cluster of FIPS 140-2 Level 3 certified HSMs. Google manages the HSM cluster for you, so you don’t need to worry about clustering, scaling, or patching. Because Cloud HSM uses Cloud KMS as its front end, you can leverage all the conveniences and features that Cloud KMS provides.
Cloud External Key Manager (Cloud EKM)
With Cloud EKM you can use encryption keys that you manage within a supported external key management partner to protect data within Google Cloud. Here is how it works:
-
First, you create or use an existing key in a supported external key management partner system. This key has a unique URI.
-
Next, you grant your Google Cloud project access to use the key, in the external key management partner system.
-
In your Google Cloud project, you create a Cloud EKM key, using the URI for the externally-managed key.
The Cloud EKM key and the external key management partner key work together to protect your data. The external key is never exposed to Google.
Other data security services
Apart from data encryption some other services that come in handy for data security in Google Cloud are:
-
VPC Service Controls which mitigate data exfiltration risks by isolating multi-tenant services
-
Data Loss Prevention which helps discover, classify, and protect sensitive data. Let’s cover this in the next blog.
For a more in-depth look into how encryption at rest and in transit works across our various services checkout the whitepapers.
For more #GCPSketchnote, follow the GitHub repo. For similar cloud content follow me on Twitter @pvergadia and keep an eye out on thecloudgirl.dev