Gestión de claves y KMS

Cifrar datos grandes directamente con una clave del KMS no es práctico: cada operación viajaría al servicio. Lo habitual es el cifrado por sobres. Una clave de datos se genera para cifrar el contenido; esa clave de datos se cifra a su vez con una clave maestra que vive en el KMS (o el HSM) y se guarda cifrada junto al dato. Para leer, el servicio pide al KMS que descifre la clave de datos, y solo entonces la usa.

La ventaja operativa es doble: la clave maestra nunca sale del servicio, y revocar o rotar la maestra no obliga a recifrar todos los datos a la vez.

La separación de funciones pide que quien administra una clave (cambia su política, programa su borrado) no sea la misma identidad que la usa para operar. Si una cuenta de servicio puede hacer las dos cosas, un fallo en ese servicio permite ampliar sus propios permisos o borrar la evidencia. Compara las columnas administra y usan del inventario.

El registro de uso del KMS es una fuente de detección: todo intento, permitido o denegado, queda anotado. Un denegado sobre una clave que la cuenta nunca debería tocar es una señal para revisar la política de acceso o la configuración del servicio, no solo un ruido. Busca los intentos denegados.

El volumen de uso de una clave sirve de línea base: si pasa de unos pocos a miles de descifrados en una tarde, hay algo que mirar. Para fijar la línea base de la clave de pagos, cuenta sus operaciones de descifrado que sí se permitieron en el registro de estos dos días.

La clave de reportes tiene como administrador al propio servicio y no rota sola. Una política sana por clave define quién administra, quién usa y para qué operaciones (cifrar, descifrar, firmar), siguiendo mínimo privilegio. La guía de gestión de claves del NIST (SP 800-57) trata la separación de funciones y la limitación del acceso como parte de la protección de las claves.