Gestión de claves, jerarquía, KMS, HSM y rotación

Una jerarquía de claves tiene tres niveles. Arriba, una clave raíz que casi nunca se usa. En medio, claves de cifrado de claves (KEK, por sus siglas en inglés), que envuelven a las de datos. Abajo, claves de cifrado de datos (DEK), que cifran directamente las tablas y los archivos. Este esquema se llama cifrado por sobres: la clave de datos se guarda cifrada por la KEK, junto al dato que cifra.

La ventaja es operativa. Rotar una KEK no obliga a descifrar y volver a cifrar todos los datos: basta con reenvolver las claves de datos con la clave nueva, que son pocas y pequeñas. Y la clave que protege todo lo demás puede vivir en un sitio mucho más protegido, porque se consulta rara vez.

Cada clave de datos tiene que estar protegida por otra de nivel superior, o por un control de acceso equivalente, porque una clave que se guarda junto a lo que cifra no es una barrera, es un candado con la llave en la cerradura. Los lugares habituales donde aparece esta falla son los archivos de configuración de la aplicación, los repositorios de código y las variables de entorno: sitios cómodos de los que nadie cuestiona cuántas personas o procesos los leen.

En el inventario, la columna que dice quién protege cada clave es la que hay que leer con ojos de auditor.

Un servicio de gestión de claves (KMS) administrado por el proveedor guarda las claves, controla quién las usa y deja registro de cada uso; es suficiente para la mayoría de claves de datos. Un HSM, un dispositivo dedicado y resistente a manipulación, añade una propiedad más fuerte: la clave se genera dentro y no puede exportarse en claro. Cuesta más, se opera con más ceremonia y exige gente que lo custodie.

La pregunta del arquitecto es cuánto daño causaría que esa clave se expusiera. La raíz sostiene a todas las demás, así que su exposición lo compromete todo y justifica el dispositivo; una clave de datos de una sola tabla, cuya rotación es barata, no lo justifica. Un HSM por cada clave no es seguridad, es presupuesto mal decidido.

Una política de rotación fija un plazo máximo por clase de clave. Rotar limita cuánto dato queda expuesto si una clave se filtra sin que nadie lo sepa y cuántas veces se ha usado la misma clave. Medir el cumplimiento es aritmética con fechas: a la fecha de corte del inventario, se suma el plazo de la clase a la fecha de la última rotación y se compara. Una clave cuya rotación está en cero no se ha rotado nunca; su plazo se cuenta desde que se creó.

El resultado no es un reproche sino una lista de trabajo con orden. Y es el argumento más sencillo de llevar a la dirección: la propia política de la empresa, incumplida, con números.

No todas las rotaciones cuestan lo mismo. Rotar una clave envolvente es reenvolver las claves de datos que protege, algo que el servicio hace en minutos y sin tocar las tablas. Rotar una clave de datos es distinto: hay que descifrar con la antigua y volver a cifrar todo lo que cifraba, y en una tabla grande eso es una ventana de mantenimiento, espacio extra y riesgo de error.

Esa diferencia decide el orden de trabajo y el costo que el arquitecto declara. También decide cómo se diseña: claves de datos por tabla o por conjunto pequeño, no una gigante para todo, de modo que recifrar sea posible.