Key Management

Key management is the operational discipline behind secure encryption. A strong encryption algorithm provides little protection if its keys are exposed alongside the encrypted data or available to unauthorized users. Effective key management covers secure generation, storage, distribution, authorized use, rotation, recovery, and eventual destruction. It also assigns responsibility for each stage so that neither the cloud provider nor the customer assumes the other has handled a required control.

Encryption at rest protects stored information, such as objects, database files, disks, and backups. Cloud services can often encrypt this data automatically, but engineers must still understand which keys are used and who can authorize decryption. Provider-controlled keys reduce administrative work. Customer-managed keys offer more direct control over permissions, lifecycle settings, and auditability, but introduce configuration and availability responsibilities. Customer-managed does not necessarily mean the customer holds or can export the underlying key material.

Encryption in transit protects information moving between endpoints, commonly through TLS for HTTPS connections. TLS uses certificates and asymmetric cryptography to authenticate endpoints and establish shared session keys that encrypt traffic. Protecting certificate private keys and renewing certificates are therefore important management tasks. Encrypting a storage volume does not encrypt network traffic, and enabling HTTPS does not automatically encrypt the destination database or its backups.

Cloud systems frequently use envelope encryption. A data key encrypts the actual data, and a separate key-encryption key protects that data key. The encrypted data key can be stored with the ciphertext because access to the protecting key is still required to recover it. This approach allows efficient local encryption of large datasets while centralizing protection and authorization for higher-level keys. Plaintext data keys should exist only where needed and should not be written into logs, source repositories, or application configuration.

For example, an application might upload reports to object storage using server-side encryption with a customer-managed key. Its workload identity needs the relevant storage permissions and the required key permissions. A user who can retrieve an encrypted object might still be unable to decrypt it, depending on the encryption configuration and authorization path. Conversely, encryption does not stop a compromised application identity that already has permission to read and decrypt the reports.

Key rotation introduces new key material to limit continued reliance on an older key. It does not inherently re-encrypt existing data or undo a previous disclosure. Older key material may need to remain available to decrypt retained records and backups. Disabling a key can interrupt applications immediately, while permanently deleting necessary key material can make data unrecoverable. Recovery plans must therefore account for both encrypted data and access to its keys.

The practical trade-off is control versus operational burden. Dedicated hardware security modules can satisfy specialized custody or cryptographic requirements, but require more design and administration than an integrated managed key service. Apply least privilege, separate key administration from data access where practical, audit key operations, and test recovery. For exam scenarios, first identify whether the requirement concerns stored data, network traffic, or control over cryptographic keys; these are related but distinct concerns.