KMS

The characteristic of a KMS is not that it holds keys but that it normally does not give them out. An application does not retrieve a key and encrypt locally; it asks the KMS to encrypt or decrypt on its behalf and receives only the result, so the key material stays inside the service. For bulk data this is done with envelope encryption: the KMS protects a small key-encryption key, which in turn protects a data key used for the actual payload, so the KMS is called to unwrap the data key rather than to process every byte. High-assurance deployments back the KMS with a hardware security module, so the keys never exist in software at all. It underpins encryption at rest across a cloud estate.

The wrong mental model is that a KMS is a place to keep keys you fetch, which conflates it with a secrets manager: a secrets manager returns the secret so the application can use it, whereas a KMS keeps the key and returns only results. The real weakness is rarely the cryptography and almost always the access policy. If a broad set of identities can call the KMS to decrypt, then the KMS is not protecting the data from those identities, and an attacker who compromises one of them can decrypt at will without ever seeing a key. From the offensive side, the target is not the key but the permission to use it.

We review the KMS as an access-control problem: which identities can encrypt, decrypt or manage each key, whether those grants follow least privilege, whether keys are rotated, and whether high-value keys are HSM-backed. Where a compromised identity can call the KMS to decrypt sensitive data, we demonstrate it, because the ability to use the key is the exposure. We keep the distinction from secrets management clear in the report. This is part of how we review key management and its access.