Mythbusting cloud key management services

Even if you don’t use the KMS directly, the wider cloud service is probably built on it. You can’t trust the cloud without also trusting the KMS. This means that you should be confident that the KMS meets your security needs before using the service. It also means that once you're comfortable using the cloud service, you should also be happy to use the KMS!

Many KMSs can be used in a mode where you bring your own encryption key (BYOK), or hold your own key (HYOK), rather than use keys generated by the KMS. Some customers use HYOK or BYOK because regulations require them to generate their keys, but others don’t feel comfortable trusting the cloud service to generate keys securely.

However, you already rely on the KMS to generate and protect keys well for the foundation of the cloud service. You also have to trust that the KMS handles data encryption keys securely, no matter how key encryption keys are generated or protected. Furthermore, when keys are generated externally and imported into or accessed by the KMS, you’re just providing more opportunities for the key to be lost or stolen. For all these reasons you should avoid HYOK or BYOK where you can.

So far, we’ve been discussing one very important part of the shared responsibility model, delegating key management to your cloud provider. The next step of this process is delegating KMS integration to your cloud provider. Most cloud services that benefit from good key management (like blob storage services) can integrate with the KMS directly. You should use this option, as it allows the storage service to manage keys more consistently and makes it easier for your cloud provider to spot anomalous activity. Sometimes, you can go a step further and delegate an entire use case to a managed service built on top of the KMS (such as a secrets management service), rather than using the KMS directly.

When considering a cloud KMS, customers often focus on whether the KMS can provide the same functionality as their existing approach to key management. Often, this means the unique advantages of the KMS are overlooked. One big security advantage to using a cloud KMS is the granularity of access control. In a KMS, your ability to use particular keys will be governed by the cloud service’s access control mechanism, which will typically be a kind of role-based access control (RBAC). Not only will this decide whether you can access a key, but also what operations you can perform using that key. For example, a log collector may be allowed to use a key to encrypt plaintext logs, but not to decrypt logs that have already been stored.

This more granular approach gives you much more robust capabilities for protecting your data. For example, you can allow your personnel to have full administrative control over databases and other storage systems, without giving them access to the keys necessary to decrypt the data in those systems. At the same time, since access controls are applied within the KMS, you never have direct access to the key, removing the risk of keys being lost accidentally.

Good data encryption is undermined by poor key management, so when you rely on encryption to protect your data, you need to ensure your key management is strong. Getting this right is difficult, as key management is a complex and subtle topic. This means that a cloud KMS is there to make your life easier and help secure the data you store in the cloud.

For the same reasons that you shouldn’t be building your encryption algorithm, you shouldn’t be building your own KMS. Moreover, a good cloud service can bring security benefits that are hard to achieve in traditional deployments, so use the KMS offered by your cloud provider, configure it by following our guidance, and take advantage of the additional security features it offers.

Jamie H
Senior Security Researcher