Storage
Mobility
Protection
Analysis and control
TOPICShare
The current landscape of distributed infrastructure, cloud services, and increasingly sophisticated security attacks means organizations are more dependent than ever on maintaining a strong security posture.
In this blog we’ll take a look at using Cloud KMS for Server Side Encryption in Google Cloud. Click the links below to read about:
- The Encryption Challenge
- Customer-Supplied Keys (CSEK)
- Customer-Managed Keys (CMEK)
- Go Beyond the Defaults to Improve Default Security
The Encryption Challenge
Encryption is a foundational pillar in security, ensuring critical data is protected both at rest and in transit. Encryption is even more critical in distributed environments like the cloud. Most modern cloud platform providers, like GCP, offer customers encryption at rest by default. Adding further complexity to the mix; architecture such as Kubernetes demands effective encryption across its entire mesh.
What about when the default isn't good enough? GCP customers have several options to choose from when it comes to encryption. What are the implications of each choice? What are the pros and cons of choosing Customer-Supplied Encryption Keys (CSEK) versus Customer-Managed Encryption Keys (CMEK)? Before evaluating each choice, a quick primer on Server Side Encryption (SSE) to start off.
What Is SSE?
The crucial difference between SSE and client-side encryption is a question of when the data was encrypted. In a client-side scenario, the data is encrypted prior to transmission, whereas in the case of SSE, the data is encrypted after it is sent to the server.
Client-side encryption is generally considered more secure, as data is encrypted before it transits other networks and nodes. The destination recipient is the only entity that will be able to decrypt the actual data and access it. However, client-side encryption is more technically complex to set up, and typically involves configuring individual applications and/or their underlying code to make use of it.
In the case of SSE, data is encrypted after it is received by the server. While it does not offer the level of security that client-side does, it is much easier to configure and utilize. Most cloud storage providers generally offer a basic level of SSE that is activated by default. In the case of Google Cloud, Google Managed Encryption Keys (GMEK) are offered as a default option to customers, ensuring all data is automatically encrypted before being written to storage.
For teams that need additional features and security beyond defaults, Google offers Customer-supplied Keys (CSEK) and Customer-managed Keys (CMEK).
Customer-Supplied Keys (CSEK)
Google Cloud CSEK allows Google Cloud customers to supply and manage their own encryption keys. In name alone, CSEK and CMEK would appear at first glance to be similar. However, closer examination reveals some key differences.
In a CSEK, a customer manually uploads a "raw" CSEK, which is an AES-256 key encoded in Base64. The key can be supplied via the gsutil command line tool, API call, or through a supported third-party service. It is critical to note that at no point is the supplied key ever permanently stored on Google’s servers. Keys themselves are stored ephemerally and encrypted by CSEK-derived keys via an additional cryptographic nonce that is supplied by Google. Customers can opt for additional security by wrapping their Base64-encoded key in an RSA public key certificate, further protecting the key from being unwrapped outside of desired destinations.
CSEKs are used with Google Cloud Storage and Google Compute Engine. In the case of Cloud Storage, the keys are applied during calls to the storage API, encrypting uploaded objects as well as decrypting downloaded ones. For Compute Engine, customers can use their keys to encrypt the persistent storage disks for a given compute node.
Circling back to the fact that the keys themselves are never stored with Google: this conveys an explicit burden on the customer to provide their own infrastructure for provisioning and managing their keys.
What does that look like? Improving security posture through automatic key rotation requires in-house development of a secure, reliable rotation mechanism (if not paying a 3rd-party vendor to handle such management). In a security event, it is up to that system to be able to identify and adequately respond to the potential of a compromised key.
In a tier-1 organization with wide infrastructure that multiple teams depend on, an engineering organization will have to provide at minimum these steps to operationalize their key management:
- Valuable development/planning resources.
- Detailed administrative and operational processes.
- Monitoring and alerting infrastructure.
- Disaster recovery procedures.
- Operational resources to maintain and monitor the entire infrastructure.
All of this can quickly add up to a significant operational and administrative burden, requiring the development, deployment, and maintenance of non-product infrastructure.
With a CSEK, customers have more granular control over their encryption system. This can be of particular importance in scenarios where a customer has to adhere to data security controls that require encryption beyond what is offered by default, or that the keys remain in first-party control. However, this means the customer also has to invest in in-house or third-party resources to provide management infrastructure. Customers seeking a more managed experience might turn to a CMEK-based solution instead.
Customer-Managed Keys (CMEK)
Google Cloud CMEK provides Google Cloud customers with a managed experience, handling the underlying infrastructure and providing an API for functions like key rotation, disablement, and storage. Leaning on Google's Cloud KMS, CMEK offers centralized management of encryption keys for a number of different use cases.
With a CMEK, a customer can utilize the Cloud KMS API, UI, or the Google Cloud command line utility to create and manage keys, as well as use them in active encryption or decryption operations. Unlike a CSEK, the key is permanently stored and managed via Google Cloud. Customers also have the option to import their own keys, offering a "best of both worlds" approach between a completely self-managed CSEK, and a Google-generated CMEK. Customers can also opt for stricter encryption algorithms beyond the standard AES-256 offered by a CSEK, including RSA-4096 and OAEP.
The benefits of using CMEK include:
- CMEKs can be used with a variety of services.
- Customers that go all-in on Cloud KMS with managed keys can centrally manage the majority of their cloud encryption and data protection from a single API.
- Key rotation and configuration for multiple, independent services can all be handled through the same interface.
- The operational overhead of managing key provisioning and management infrastructure is outsourced to the provider, in this case Google.
- Unlike CSEK, key rotation can be configured to be automatic, offloading the operational burden of key rotation and eliminating the need for customer-provided key infrastructure.
One potential downside to depending on Cloud KMS and customer-managed keys is the added cost incurred by using Google infrastructure exclusively. Organizations with thousands of keys or a broad selection of services requiring encryption controls may need to dedicate some time to evaluate the potential costs of managed versus unmanaged encryption infrastructure.
Go Beyond the Defaults to Improve Default Security
Like most cloud service providers, Google Cloud offers default encryption for nearly all data at rest within its cloud. However, some organizations may need to go beyond the default options for encryption.
With customer-supplied and customer-managed keys, an organization can have far more granular control over management and application of its encryption infrastructure, and ultimately improved data security. For organizations willing to endure the added costs, customer-managed keys offer stricter encryption standards, customer control via a standard API, and a wealth of existing GCP service integrations.
Cloud Volumes ONTAP is NetApp’s leading cloud-based data management platform built on Google Cloud, AWS, or Azure storage.
Some of the features that keep your storage secure with Cloud Volumes ONTAP include:
- Data encryption in flight and at rest with multiple encryption
- NTFS / Share Permissions and EXT / Export Permissions for file shares
- Ransomware protection with immutable, WORM storage capabilities
- Automatic alerts on suspicious activity
- Vscan antivirus scanning
- SSO and Identity Federation
Read more about Cloud Volumes ONTAP’s security features here.
