KMS

Lo característico de un KMS no es que guarde claves, sino que normalmente no las entrega. Una aplicación no recupera una clave y cifra en local; le pide al KMS que cifre o descifre en su nombre y recibe solo el resultado, así que el material de la clave se queda dentro del servicio. Para datos en volumen esto se hace con envelope encryption: el KMS protege una clave pequeña de cifrado de claves, que a su vez protege una clave de datos usada para la carga real, de modo que al KMS se le llama para desenvolver la clave de datos y no para procesar cada byte. Los despliegues con más exigencia respaldan el KMS con un hardware security module, para que las claves no existan nunca en software. Es lo que sostiene el cifrado en reposo de todo un parque cloud.

El modelo mental equivocado es pensar que un KMS es un sitio donde guardar claves que después recoges, cosa que lo confunde con un gestor de secretos: un gestor de secretos devuelve el secreto para que la aplicación lo use, mientras que un KMS se queda la clave y devuelve solo resultados. Lo que falla de verdad rara vez es la criptografía y casi siempre es la política de acceso. Si un conjunto amplio de identidades puede llamar al KMS para descifrar, entonces el KMS no está protegiendo los datos frente a esas identidades, y un atacante que comprometa una de ellas descifra a su gusto sin ver jamás una clave. Desde el lado ofensivo, el objetivo no es la clave, sino el permiso para usarla.

Revisamos el KMS como un problema de control de acceso: qué identidades pueden cifrar, descifrar o administrar cada clave, si esas concesiones respetan el mínimo privilegio, si las claves se rotan, y si las claves de más valor están respaldadas por un HSM. Cuando una identidad comprometida puede llamar al KMS para descifrar datos sensibles, lo demostramos, porque la exposición es poder usar la clave. Mantenemos clara en el informe la distinción con la gestión de secretos. Esto forma parte de cómo revisamos la gestión de claves y su acceso.