When it comes to the adoption of hybrid or multi-cloud IT, we find in our customer conversations that it’s not a question of whether to adopt but rather at what stage of maturity to adopt. To ensure that transition is secure, most customers are rethinking data protection, encryption, and key management controls.
Security in the cloud is a shared responsibility between the providers and the customer. AWS has a well-defined shared responsibility model; the provider is responsible for “Security of the Cloud” and the customer is responsible for “Security in the Cloud”. Azure, Google Cloud, and other providers have a similar model.
While the shared responsibility models are similar, there are considerable differences and nuances regarding the encryption and key management capabilities of each provider. For example, to shore up data protection in the cloud, each cloud provider offers Bring Your Own Key (BYOK), but with varying degrees of support.
In this blog, we will examine different approaches to encryption and BYOK within Google Cloud, Azure and AWS. We will also cover how Fortanix Self-Defending Key Management Service (SDKMS) can be used to securely enable a multi-cloud strategy.
With client-side encryption, the application typically has the responsibility of encrypting and decrypting the data it sends and receives from the cloud service providers. While client-side encryption provides a degree of protection to ensure that cloud providers can not access encrypted data, organizations often run into issues with complexity due to key management and multiple applications. Fortanix SDKMS is purpose-built to effectively address this scenario across multi-cloud deployments. SDKMS provides an extensive suite of client libraries, including PKCS11, Microsoft CNG, JCE, and Java and Python SDKs, that can be readily used with modern applications.
In contrast with client-side encryption, server-side encryption allows the cloud service provider to manage the encryption keys along with the data. While this approach offers simplicity, you leave data protection and keys under control of the service provider. BYOK is a solution in which the customer, rather than the cloud service provider (CSP), controls the encryption keys and therefore the data. To support BYOK, CSPs provide a method to transfer your keys to their domain in order to support data encryption within their services, thus eliminating the need for the application to perform any cryptographic operations.
While the benefits of BYOK are clear, the technology comes with a great deal of responsibility as well as potential complexity and integration challenges. Fortanix SDKMS offers the ease of use of modern cloud software with HSM-grade security, enabling your organization to readily adopt BYOK to meet security and compliance requirements as well as to avoid cloud provider lock-in.
Google recently added BYOK support with a capability called Customer Supplied Encryption Key (CSEK). Currently CSEK is supported in GCE (Compute Engine) and GCS (Cloud Storage). For the rest of the Google Cloud services, client-side encryption can be leveraged by using SDKMS APIs in the applications.
GCE by default enables disk encryption on the compute instances, with the keys being supplied and managed by Google. Alternatively, you provide a CSEK as an AES 256-bit key, supplied both as raw key or wrapped by a Google public key. We recommend that you always wrap the key to ensure safety of the original key.
GCS also server-eide encryption using CSEK, using an AES 256-bit key. GCS, however, does not support a key wrapping mechanism. This key needs to be provided with every upload and download request for the files. The key is only used ephemerally and never stored on any disk internally by Google.
AWS has had support for BYOK for some time now; however, this requires the use of its Key Management Service (KMS). To get started with KMS, you generate a Customer Master Key (CMK), which gets used to derive other keys. You can import your own 256-bit AES key as the CMK, thus enabling BYOK. AWS provides a wrapping key and a token to securely import customer keys. We can also set expiration date and user access policies for the keys in KMS. Once imported, you can use any of the KMS-integrated services (S3, EBS, RDS, Redshift, etc) for server side encryption.
Azure Key Vault supports direct import of customer RSA 2048-bit keys as both software-protected keys or HSM-protected keys. HSM-protected keys never leave the boundary of the Azure provided HSM whereas software keys are guaranteed to be encrypted at rest via secure Microsoft keys. Once imported, the keys can only be used within Azure and can never be exported.
Azure supports BYOK in Azure Information Protection where it allows the customer to manage the tenant key via Azure Key Vault (Tenant Key is the root key for the organization; other user or app keys are derived from it). Azure SQL Database and Data Warehouse also support BYOK for Transparent Data Encryption (TDE). You can use your imported keys in Key Vault to encrypt the Data Encryption Keys (DEK) used by SQL Database.
SDKMS supports easy and secure exporting of keys through its APIs. Check out this knowledge base on how to use SDKMS with cloud services providers for BYOK.
Get our blog updates in your inbox: