Google Cloud Data Encryption

• Encryption is a process that takes legible data as input (often called plaintext) and transforms it into an output (often called ciphertext) that reveals little or no information about the plaintext
• Encryption can be used to protect data in three states:
  • Encryption at Rest protects the data from a system compromise or data exfiltration by encrypting data while stored.
  • Encryption in Transit: protects the data if communications are intercepted while data moves between the site and the cloud provider or between two services.
  • Encryption in Use: protects the data when it is being used by servers to run computations, e.g. homomorphic encryption.

Encryption at Rest

• Google uses several layers of encryption to protect customer data at rest.
• All customer content stored at rest is encrypted, without any action required from the customer, using one or more encryption mechanisms.
• All data stored in Google Cloud is encrypted at the storage level using AES256
• Google encrypts data prior to it being written to disk.

Google Cloud Default Encryption

• Data for storage is split into chunks
• Each chunk is encrypted with a unique Data Encryption Key (DEK)
• Two chunks will not have the same encryption key, even if they are part of the same Cloud Storage object, owned by the same customer, or stored on the same machine
• If a chunk of data is updated, it is encrypted with a new key, rather than by reusing the existing key
• Data encryption keys are stored with the data because of the high volume of keys at Google, and the need for low latency and high availability
• Backups are encrypted using a separate DEK
• Data encryption keys are encrypted with (“wrapped” by) Key Encryption Keys (KEK) also referred to as Envelope Encryption
  
• KEKs are stored centrally inside Google’s Key Management Service (KMS)
• Having a smaller number of KEKs than DEKs and using a central KMS makes storing and encrypting data at Google scale manageable, and allows us to track and control data access from a central point.
• KEKs are not exportable from Google’s KMS by design; all encryption and decryption with these keys must be done within KMS
• KMS can automatically rotate KEKs at regular time intervals
• KMS maintains an active key with a set of historical keys for decryption
• Google uses a common cryptographic library, Tink, which incorporates the FIPS 140–2 validated module, BoringCrypto, to implement encryption consistently across almost all Google Cloud products.

Google Cloud Default Decryption

• Service makes a call to the storage system for the data it needs.
• The storage system identifies the chunks in which that data is stored (the chunk IDs) and where they are stored.
• For each chunk, the storage system pulls the wrapped DEK stored with that chunk and sends it to KMS for unwrapping.
• The storage system verifies that the identified job is allowed to access that data chunk based on a job identifier, and using the chunk ID
• KMS verifies that the storage system is authorized both to use the KEK associated with the service and to unwrap that specific DEK.
• KMS passes the unwrapped DEK back to the storage system, which decrypts the data chunk and passes it to the service.

Cloud Key Management Service – KMS

• Cloud KMS help centralized management of encryption keys
• Google’s Key Management Service is redundant and globally distributed.
• Cloud KMS allows the customer to manage the encryption keys  (CMEK)
• A CMEK or Customer Managed Encryption Key can be used in both server-side encryption (SSE) and client-side encryption (CSE).
• CMEK key can be used with KMS encrypt/decrypt and also be attached to a bucket, GCE disk, etc.
• CMEK supports importing your own key material, which is useful for migrations.

Customer Supplied Encryption Keys – CSEKs

• Customer-Supplied Encryption Keys (CSEK) allows you to supply your own encryption keys, Google uses the key to protect the Google-generated keys used to encrypt and decrypt your data.
• CSEK support only Google Cloud Storage and Google Compute Engine.
• CSEK Encryption
  • User provides a raw CSEK as part of an API call.
  • The key is transmitted from the Google front end to the storage system’s memory
  • This key is used as the Key Encryption Key (KEK) in Google Cloud Storage for the data.
• CSEK Decryption
  • Raw CSEK is used to unwrap wrapped chunk keys, to create raw chunk keys in memory.
  • These are used to decrypt data chunks stored in the storage systems.
  • These keys are used as the data encryption keys (DEK) in Google Cloud Storage for your data.
• Raw CSEK, CSEK-derived keys, and raw chunk/disk keys are never stored on disk unencrypted.
• Raw chunk/disk keys are stored wrapped with CSEK-derived keys, and with Google keys where automatic restart is used. Google does not permanently store your keys on its servers.

Encryption in Transit

• Google applies several security measures to help ensure the authenticity, integrity, and privacy of data in transit.
  • Authentication: data source verification, either a human or a process, and destination.
  • Integrity: ensures data sent arrives at its destination unaltered.
  • Encryption: ensures data is unintelligible to keep it private.
• Data in transit inside a physical boundary controlled by or on behalf of Google is generally authenticated but not necessarily encrypted.
• Data is encrypted and authenticated in transit at one or more network layers when it moves outside physical boundaries not controlled by Google or on behalf of Google.
• Depending on the connection that is being made, Google applies default protections to data in transit for e.g, communications are secured between the user and the Google Front End (GFE) using TLS.
• Google Cloud customers with additional requirements for encryption of data over WAN can choose to implement further protections for data as it moves from a user to an application or VM to VM. These protections include IPSec tunnels, Gmail S/MIME, managed SSL certificates, and Istio.

• [Connection A] – User to Google Front End
  • Google accepts requests from around the world using a globally distributed system called the Google Front End (GFE)
  • GFE terminates traffic for incoming HTTP(S), TCP, and TLS proxy traffic, provides DDoS attack countermeasures, and routes and load balances traffic to the Google Cloud services themselves.
  • User requests to customer applications can be routed through a Google Cloud HTTP(S) or TCP/SSL Proxy Load Balancer external load balancer
  • Google automatically encrypts traffic between GFEs and the backends load balancers that reside within VPC networks
• [Connection B] – User to customer application hosted on Google Cloud
  • Cloud VPN or Interconnect can help secure a direct connection to a VM using an external IP or network load balancer IP. As the connection does not go through GFE, it’s not encrypted by default.
• [Connection C] – Virtual Machine to Virtual Machine
  • VM to VM connections is encrypted if they leave a physical boundary, and are authenticated within the physical boundary.
  • VM to VM traffic, using external IP addresses, is not encrypted by default, and its security is provided at the user’s discretion
• [Connection D] – Virtual Machine to Google Cloud Service
  • Connectivity to Google APIs and services can be protected using private google access or private service access
  • From the VM to the GFE, Google Cloud services support protecting these connections with TLS by default
• [Connection E] – Google Cloud Service to Google Cloud Service
  • Routing from one Google service to another takes place on Google Cloud network backbone and may require routing traffic outside of physical boundaries controlled by or on behalf of Google
  • Connections between these services are encrypted if they leave a physical boundary, and authenticated within the physical boundary.

GCP Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

References

• Google_Cloud_Encryption_at_Rest
• Google_Cloud_Encryption_in_Transit