Key Management in the Cloud

In my previous cloud security blogs, I mentioned the need to use key-based encryption for protecting data. Whether the data is in flight (i.e., being transmitted) or at rest (i.e., stored), it must be encrypted to ensure confidentiality, integrity and availability. Managing encryption keys can be challenging. There are different key types (symmetric vs. asymmetric), key strengths (128-bit through 2048-bit and greater), key usage (privacy, key exchange, authentication and digital signature) and key encryption algorithms (AES, 3DES, SHA-1, SHA-2, MD5, etc). Furthermore, each data end point, like storage or server, requires an integration point that also needs to be managed. For example, for storage we need an encryption integration point for each storage medium (disk, SAN, NAS or tape).

To help manage all of these encryption security components cloud security managers should utilize a centralized Key Management System (KMS) solution. While it is possible to use specific, individual point solutions from different vendors to handle parts of the key management tasks, a centralized approach is most preferable and cost effective. In this blog, I will examine the components of a generic KMS and use an example from Amazon Web Services to illustrate how it can be implemented.

One item to note is that the industry for key management solutions is still evolving, therefore you will see various names, terms and acronyms being used: Enterprise Key Management (EKM), Enterprise Key Management System (EKMS) and Encryption Key Management (EKM). All of these refer to the same concept we call KMS.

A KMS consists of two main components, a core key management server and the end-target integration points.

KMS server

A mature KMS performs five functions through the core key management server:

Key Generation: a KMS must be able to generate symmetric and asymmetric keys of varying bit lengths. These parameters are determined via your security policies and configured through the tool’s administrative console.
Secure Storage: every key used for encryption must be well-protected and secured. This means encrypting the keys themselves. This is called key wrapping.
Key Lifecycle Tracking: a key has a lifespan and very specific stages or states that it goes through. A common key lifecycle used is from NIST’s SP800-57 Recommendation for Key Management — Part 1: General (Revision 3): pre-activation state, active state, deactivated state, destroyed state, compromised state and destroyed compromised state.
Backup Mechanism: if the sets of encryption keys are ever lost, then the encrypted data is lost. To protect yourself against this the KMS must provide a secure method for backing up the encryption keys.
Auditing: a mature KMS will make reporting and auditing easier by providing documentation of what keys are being used, for what purpose and who has access to them. This information is critical for regulation and compliance audits.

To provide even greater protection and security, a KMS may optionally use a Hardware Security Module (HSM). A HSM is a self-contained hardware appliance that stores keys in a physically tamper-resistant device. If the KMS uses a HSM, all keys are stored in the HSM exclusively. These two components communicate through a secure, encrypted network link. This extra level of security may be required of some businesses’ compliance audit.

End-Target Integration Points
The second component of a KSM is the end-target integration point where the encrypted data resides (usually a storage device) or where the data is being sent (usually a server). These can also be called “service agents.” It is the service agents that actually use the encryption keys to convert plaintext data into encrypted data and then store it on a storage device, and then reverse the process when the data is accessed or transmitted. In order to use a KMS you must ensure that the end target has a service agent that can interoperate with the KMS. Not every KMS has support every storage device and/or server platform. Usually it is the KMS provider that provides the service agents to support a variety of storage/server devices.

Key Management in the Cloud
It is possible to extend a KMS solution that is in your data center to include IT components residing in the cloud. However, it is more convenient to use a cloud-based KMS, especially if the cloud provider offers one directly. This is the case with Amazon Web Services (AWS). As part of their IaaS offering, they have a KMS service where key management for all cloud data is performed right in the cloud environment. This ensures maximum performance and throughput since the key distribution and processing is done close to where the data resides. Just as important, a cloud provider-based KMS solution integrates natively with their storage, server and database IaaS offering. In AWS, you can use key encryption through their KMS to store encrypted data on NAS disks (EBS), on tape (Glacier), in a database (RDS/Oracle, RDS/SQL), warehouse (RedShift), on a per file basis (S3) and for Windows/Linux servers (EC2). AWS takes care of integrating the key encryption regardless of where or how you store your data. AWS also offers the equivalent of a HSM called CloudHSM where the encryption keys are stored on a physically tamper-resistant device for greater protection.

Using a cloud based KMS, like AWS’ KMS, greatly eases the work and planning involved in protecting data at rest and data in flight. With a proper implementation IT operations in the cloud can be just as secure as any IT operations in a data center.

Please support our Sponsors here :