Home / Knowledge hub / Cloud key management
Knowledge hub
Cloud key management
Using the provider's managed service to create, store and rotate encryption keys.
What it means
Encryption is only as strong as the care given to its keys. Cloud key management means using a managed service from your provider, such as AWS KMS, Azure Key Vault or Google Cloud KMS, to create keys, store them, control who can use them and rotate them.
In these services the key material generally stays inside the service. Your application asks the service to encrypt or decrypt, instead of holding the key itself. That makes the key much harder to leak by accident. If a thief copies the data but cannot reach the key, the copy is useless to them.
Why it matters
Keys written into code, files or environment variables get copied into repositories, backups and logs. A managed service takes that burden away and gives you what hand-built setups rarely have: access rules per key, a log of every use, and automatic rotation. Auditors and customers often ask how you manage keys and who can reach them.
It also makes encryption real. A storage service can encrypt at rest, but if everyone can use the key, nothing is gained. See encryption at rest and hardware security modules. Encryption without key control gives a false sense of safety.
How it shows up
You meet it when turning on encryption for storage, databases and queues, and when your application encrypts sensitive fields. Many designs use envelope encryption: a master key in the service protects smaller data keys, which protect the data. The key then stays in the service.
Check who may use each key and who may administer it, and keep those groups separate. Turn on rotation, and log and alert on unusual use. The usual mistakes are one key for everything, policies that allow any role in the account to decrypt, and deleting a key that data still needs, which makes that data unrecoverable.
Questions people ask
Cloud key management, answered
Who holds the key in a managed service?
The provider runs the service and stores the key material, but you control who is allowed to use it through policies. Some services let you bring or hold your own keys for stricter needs.
Know which option you chose.
Is a managed key the same as an HSM?
Not exactly. Many managed services are backed by hardware security modules, and some offer dedicated ones. The service adds policies, logging and an interface on top.
Check the provider's documentation for the details.
What is the risk of deleting a key?
Anything encrypted under it becomes unreadable, and backups of that data become useless too. Providers add a waiting period before deletion for this reason.
Treat deleting a key as a controlled, reviewed change.
Does using a KMS mean our data is safe?
No. If your application, or any role in the account, may ask the service to decrypt, an attacker who gains that access gets the plaintext. The key policy matters as much as the encryption.
Limit who can call decrypt.
Should we rotate keys?
Yes, within the options your service supports. Rotation limits how much data one key protects and how long a leaked key remains useful.
Check how old data is handled after rotation.
Related
Terms that sit next to this one
Key rotation
Replacing a credential on a schedule so a leaked one has a short life.
Envelope encryption
Encrypting data with a data key, then encrypting that key with a master key.
Hardware security module (HSM)
A tamper-resistant device that holds keys and does cryptography inside it.
Encryption at rest
Stored data scrambled so a stolen disk is useless without the key.
Secrets management
Keeping keys, passwords and tokens out of code and in a vault.
Who can ask for the plaintext?
We check how your application and APIs handle sensitive data and whether one signed-in account can reach another's, and report what we proved. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.