Google Distributed Cloud (GDC) air-gapped provides a comprehensive security strategy that includes encryption at rest, which helps to protect your content from attackers. GDC encrypts your content at rest, without any action from you, using one or more encryption mechanisms. This document describes the approach to default encryption at rest for GDC, and how to use it to keep your information more secure.
This document is for security architects and security teams who use or consider GDC. This document assumes a basic understanding of encryption and cryptographic primitives.
Encryption at rest
GDC encrypts all customer content stored at rest, without any action from you, using one or more encryption mechanisms. Encryption at rest is encryption that protects data stored on a disk, including solid-state drives, or backup media.
The following sections describe the mechanisms to encrypt customer data at rest.
GDC Block Storage Data is Encrypted at hardware level with leveraging FIPS Compliant 140-2 Self-Encrypting Drives. Encryption Keys for Self Encrypting Drives are stored in an external HSM, providing FIPS 140-3 compliant encryption at rest storage. In addition, Block Storage also implements additional software-level encryption solution, Volume Encryption (VE), that encrypts each underlying block storage data volume with a unique XTS-AES-256 key, with each volume specific key stored in an external HSM.
Key management systems
Key management systems (KMS) lets you create your own encryption and signing keys. Using KMS, you can create, and delete keys. KMS is not involved with encryption at rest as described in this page.
A root key wraps the keys, which is encrypted at rest. You use the keys to encrypt or sign your workloads.
Customer-managed encryption keys
To protect your data at rest, use customer-managed encryption keys (CMEK). CMEK gives you control over the keys that protect your data at rest in GDC.
All data stored within GDC is encrypted at rest with FIPS 140-2 validated cryptographic modules by keys that Hardware Security Modules (HSM) protect in your GDC deployment. No setup or configuration is required.
CMEKs offer the following advantages:
- Control: You have control over the CMEK, including the ability to delete keys.
- Transparency: You can audit the encryption process to ensure that your data is well-protected.
- Compliance: CMEKs can help you meet compliance requirements.
Another advantage for CMEK adoption is cryptographic erasure, a high-assurance data destruction method for data spill remediation and off-boarding. You can delete keys out-of-band of the data they protect. A set of CMEKs protects all of the data in your organization that your Platform Administrator can monitor, audit, and delete as needed. CMEK keys are encryption keys that you can manage using HSM APIs.
CMEK supported services
Whenever a user creates a CMEK supported datastore in GDC, such as block storage, a CMEK is automatically created on behalf of the user and becomes available to the Platform Administrator to manage. Services that support CMEK rotation provide service specific instructions for rotating CMEK keys. This process might require copying the data to a new instance.
The following GDC services support CMEK:
- Block storage: Encrypts each block storage device with a key the Platform Administrator manages.
- Virtual machine (VM) disks.
- Database Service: Your database instance primarily stores its data with a key the Platform Administrator manages. Backups for your database are out of scope for CMEK and encrypt with the encryption settings of your backup's storage system.
- User container workloads: Encrypts the Kubernetes metadata, the
ETCDcluster with a key the Platform Administrator manages. - Storage: Encrypts each object with a unique AES-256-GCM data encryption key wrapped by a bucket-level KMS AEAD key.
Encryption at rest to secure data
Encryption has the following benefits:
- Ensures that if data falls into an attacker's hands, the attacker cannot read the data without also having access to the encryption keys. Even if attackers get the storage devices that contain customer data, they won't be able to understand or decrypt the data.
- Reduces the surface of attack by cutting out the lower layers of the hardware and software stack.
- Acts as a chokepoint as centrally managed encryption keys create a single place where it enforces access to data and prevents auditing.
- Reduces the attack surface. For example: instead of protecting all data, businesses can focus their protection strategies on the encryption keys.
- Provides an important privacy mechanism for you. When GDC encrypts data at rest, it limits the access that systems and engineers have to the data.
Customer data
Customer data is data that customers or end users provide to GDC through the services under their account. Customer data includes customer content and metadata.
Customer content is data that you generate yourself or provide to us, such as stored data, disk snapshots, and Identity and Access Management (IAM) policies. This document focuses on default encryption at rest for your content.
Customer metadata makes up the rest of your data. Customer metadata could include auto-generated project numbers, timestamps, IP addresses, the byte size of an object, or the virtual machine type. GDC protects metadata to a degree that is reasonable for ongoing performance and operations.