Enterprises across industry segments are moving IT workloads and functions to the cloud, frequently ahead of any strategy or consistent capability to secure sensitive data. The advantages of cloud migration, such as scale, agility, and consumption-based pricing, are compelling and seem to outweigh the risks in the short term.
Most enterprise IT today is hybrid, with some workloads in the cloud and some hosted within the enterprise data center. Many enterprises are adopting a cloud-first or cloud-only approach for all new IT functions and business. With decentralized IT functions, frequent mergers and acquisitions, and shadow IT, most enterprises are multi-cloud, leveraging more than one cloud service provider (CSP).
Data security is rarely the first consideration for selection of a cloud service provider (CSP). The emergence of strict new data privacy regulations such as GDPR and CCPA is driving the need for CISOs to more effectively address data protection and data governance in these very complex hybrid IT ecosystems across geographies.
CISOs are looking to their CSPs for data security solutions but are struggling with the confusing array of security models and services offered.
The good news is that even the CSPs have realized the increasing need for data-centric security and have started to offer new capabilities in this space. The big three CSPs—Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure—offer key broker/key management services (KMS), AWS KMS, GCP KMS, and Cloud HSM services.
Here's what your team needs to know about new data-centric security capabilities, including bring your own key (BYOK), in the age of the cloud.
CSPs' key management services
CSPs offer native key management, encryption, and hardware security module (HSM) services. These security services have typically been added as a layer on top of their existing stacks; they're afterthoughts due to late recognition of their customers' increasing data security concerns, and are not enterprise-grade.
With multi-cloud, the challenges inherent in CSP security offerings include deficiencies in uniformity, homogeneity, coverage, customer control and ownership, functionality, scalability, performance, visibility, and more. On top of these, there are broader challenges with key management and vendor lock-in.
As enterprises transition from being just compliant to being secure, they will focus on data-centric security services that keep their sensitive data protected persistently—while at rest, in transit, and in use. They will opt for this approach rather than server-side or transparent encryption services across storage and databases, which offer very little actual security.
KMSs typically expose an API for managing keys and secrets. The premise of key management or brokerage across all of the big three CSPs is the use of the master key and working key model. The master key, usually referred to as the customer master key (CMK), never leaves the KMS application and is not used to protect sensitive data in bulk.
Instead, the CMK is typically used to generate working keys and/or to encrypt working keys or other secrets, and thus serves as a key encryption key (KEK). Working keys are data encryption keys (DEKs) and are used by applications to encrypt/decrypt actual sensitive data.
AWS and GCP use symmetric (AES-256) CMKs, but Azure uses only asymmetric (RSA-2048, -3072, -4096) key pairs, storing the private keys in its KMS.
CMKs may either be software-managed or stored inside a FIPS-compliant HSM controlled by the CSP. There are different models of master key management in terms of customer control and visibility:
- Customer-managed master key: Customer can view key metadata and manage the key
- CSP-managed master key: Customer can view key metadata but cannot manage the key
- CSP-owned master key: Customer can neither view key metadata nor manage the key
Cloud HSM is a service through which keys are generated by, and stored within, FIPS 140-2-compliant HSMs that are hosted and managed by the CSP. This model allows higher throughput than the KMS-based model of encryption. These HSMs offer a subset of the PKCS#11 standard API specifications, which are exposed either directly or through the KMS interface to take advantage of the other cloud service integrations existing with the KMS.
An important caveat is that these CSP crypto services are available in specific physical locations, referred to as regions. Even when these services are available, cross-region integrations and availability of keys across CSP regions are not guaranteed. Also, some CSPs do not specify their level of FIPS 140-2 compliance.
Bring your own key
CSPs also allow customers to optionally import their own key material. This BYOK model lets customers generate the keys themselves (typically using on-premises HSMs) and upload them to the CSP's KMS. Customers are usually required to download a certificate from the CSP, along with an import token.
The symmetric keys generated by the customer are encrypted using the public key bound to the downloaded certificate. The encrypted symmetric keys plus the CSP token or a hash of the key material are then uploaded to the CSP KMS. The tokens/hashes are used for authentication and integrity purposes. In some BYOK implementations, the CSP requires padding and Base64-encoding encrypted keys prior to upload.
What BYOK really buys you
When CSPs offer the BYOK option, it creates the perception of increased security and control. But digging deeper into the BYOK model reveals that it is applied only at varying tiers of the key hierarchy across CSPs, and customers are not necessarily in control of the keys that actually protect data. In other words, BYOK is applied to master keys or KEKs, and customers almost never get to import the DEKs actually used for data encryption.
Some CSPs have a key hierarchy where DEKs are at the lowest tier, with one or more KEKs layered above. One of the CSPs even offers BYOK only at the fourth tier of this hierarchy, meaning that the other three keys—the second-level KEK, the first-level KEK, and the DEK—are owned by the CSP.
DEK <- KEK1 <- KEK2… <- KEKn (YOUR Key)
Regardless of the key hierarchy tier where BYOK is offered, CSPs still have control over all keys below. The perception created by CSPs and sold to enterprises is that the option to bring in their encryption keys provides control, when in fact it does not.
BYOK can address concerns around key types and strengths (AES‑256 versus AES-128 or 3DES), key generation sources (HSM versus software), and can be handy for enterprise audit processes. But when the keys are uploaded into the CSP KMS, there should be no perception that customers have total control of and exclusive access to those keys.
From a key rotation perspective, BYOK addresses enterprise policy requirements. Since enterprises cannot rotate CSP-owned DEKs and KEKs, BYOK-KEKs are allowed to be rotated, and this satisfies audit and compliance requirements. For SaaS offerings such as Office 365, where Microsoft leverages Azure Key Vault-based keys, the BYOK option is applied to the topmost key in the vault key hierarchy, and that is what gets rotated.
An example:
DEK <- KEK1 <- KEK2…. <- KEKm (YOUR Key, post rotation)
DEK best practices and concerns
For customer-developed applications deployed across the CSPs' infrastructure- and platform-as-a-service offerings, CSPs provide some common best practices around DEK usage. For example, they encourage use of unique keys for each data element, whether it's generated by the KMS or the cloud HSM. And this is the case regardless of whether every application request (GenerateDataKey) for DEKs will generate a new/unique key, which is the case with AWS, or if the key is locally generated by the application, as in Azure and GCP.
In either of these cases, it is advised to encrypt the DEK with a KEK, stored securely in the KMS or cloud HSM, and to store the encrypted DEK with the encrypted data during a write operation. This is called the envelope encryption model, and the premise of this best practice is that this means there is no need for DEKs to be rotated.
However, generating unique keys for each data element, even for a specific data type, could result in a huge number of keys. And generating a key each time to encrypt data also adds more overhead to the process, which impacts performance.
Having developers generate and manage DEKs (itself a risk) at the application layer frequently means they use the same or shared keys across data types and environments. In such scenarios, the DEKs tend to persist, and thus are subject to compromise, necessitating rotation.
With typical implementation of symmetric cryptographic services, a DEK rotation every n years could result in a burdensome requirement to re-encrypt all data. A periodic rotation at the KEK level avoids this situation and is easy to execute. However, this approach offers no assistance for enterprises with compromised DEKs.
To handle key rotation at the DEK level, enterprises should consider use of available, alternative cryptographic and key management solutions that simplify DEK rotation without involving bulk re-encryption of data.
When to consider CSP crypto services and BYOK
When enterprises consume SaaS to store or process sensitive data, they face unique challenges. SaaS providers offer limited or no alternatives for custom development, so enterprises are typically restricted to very few options for data security.
One option is to leverage an encryption gateway, which acts as a web proxy to intercept and protect sensitive data prior to storing it in the SaaS cloud. The other option is to leverage the SaaS provider's encryption capabilities, if available.
Some SaaS providers also offer BYOK. In those cases, adopting the BYOK model makes sense. Most SaaS providers implement platform-level encryption (database, storage) by default, and typically also offer field-level encryption services at additional cost. These allow you to choose which fields to protect, the encryption algorithm, and the key strength to be used, as well as whether to use provider‑generated keys or BYOK.
Opting for such SaaS providers' data-centric crypto services certainly provides added security. One way to exercise some control in the key management space is by adding BYOK to the mix, which helps in meeting some compliance and audit requirements, even though the challenges discussed above continue to apply.
In a nutshell, if you can't bring your own encryption to the cloud, at least bring your own key.
