AWS to enterprises: Bring your own encryption

AWS Key Management Service offers a plus for enterprises that want the benefits of local key management as a service without ceding control

AWS to enterprises: Bring your own encryption
Monkey Business Images

It's hard enough to track and manage all the keys an enterprise uses without throwing cloud servers into the mix as well. Public cloud infrastructure providers like Google and Amazon offer key management services as part of their cloud, but not all enterprises can cede control of their keys to a third-party provider.

The ability to bring your own keys to the cloud is an important cloud security feature, and it's heartening to see Amazon Web Services add this capability to its Key Management Service (KMS).

"Customers tell us that local control over the generation and storage of keys would help them meet their security and compliance requirements in order to run their most sensitive workloads in the cloud. In order to support this important use case, I am happy to announce that you can now bring your own keys to KMS," Jeff Barr, AWS chief evangelist, wrote in a blog post.

As organizations move sensitive applications to public cloud environments, key management becomes a priority. Services like KMS give enterprises the ability to manage the lifecycle of their keys, including creating, rotating, and revoking them, via a centralized application.

However, many organizations need to retain control over their cryptographic keys, which rules out managed services where the provider handles all the keys. At the same time, these organizations still want to take advantage of the scalability, availability, and hardware maintenance offered by a fully managed service.

AWS KMS gives enterprises centralized control over all their encryption keys, so it's easy to encrypt data stored in S3, EBS, RDS, Redshift, and other integrated AWS products. The new feature lets customers import keys from any key management and Hardware Security Module (HSM) solution that supports the RSA PKCS #1 standard and use them with other AWS items and internal applications. It's available in AWS GovCloud for U.S. customers and all commercial AWS regions except China.

The import process can be initiated from the AWS Management Console or AWS command-line interface or by making calls to the KMS API. The process requires customers to initially wrap the local key with a KMS-generated public key so that secret keys are not transmitted in the open, Barr said. The public key is unique to the customer's AWS account, and KMS automatically creates a CloudWatch metric to track when the key is set to expire. Customers can create notification alerts as a reminder to reimport the key, for example. Detailed auditing information is available via AWS CloudTrail.

Putting enterprises in control of their cryptographic keys and certificates is a "fundamental element" in cloud security, said Kevin Bocek, vice president of security strategy and threat intelligence at key management company Venafi. Organizations can then decide what keys and certificates will be used in the cloud, as well as for important network and security tools like load balancers, web application firewalls, and next-generation firewalls.

"Bringing your own keys and certificate to Amazon leaves enterprises in control, and control in the cloud is the top concern globally for enterprise security architects," Bocek said. "If you don't bring your own the keys and certificates, then you won't be able to feed them into other systems like these."

Many organizations are beginning to demand the ability to manage keys in-house and release them to the cloud as needed. Google takes a slightly different approach from AWS for customers interested in creating their own encryption key for Google Compute Engine.

Since Google Compute Engine automatically encrypts all data at rest, users provide a Customer-Supplied Encryption Key (CSEK) to protect the Google-generated keys employed for data encryption. This method lets customers control data encryption in the cloud via an internally generated key without changing Google's automatic processes.

Since Google doesn't store CSEKs on its servers, a customer who loses the key loses access to the data. Creating a CSEK requires the gcloud command-line tool, and the enterprise must provide a 256-bit string key encoded in base 64. The full CSEK service is currently available in only the United States, the United Kingdom, Canada, Denmark, France, Germany, Japan, and Taiwan.

Copyright © 2016 IDG Communications, Inc.