HSM / KMS en la Nube

Para qué sirve esta pantalla

Aquí se declara, se configura y se pone en vigor el backend de protección de claves de tu instalación. Ese backend guarda la clave de cifrado de claves bajo la que se envuelve el material de claves de todos los tenants, así que es la única decisión de custodia sobre la que se apoya toda la plataforma. Es el subsistema más grande de Configuración de Plataforma: le pertenecen 86 de los 316 valores de configuración del despliegue, y detrás de ellos hay registros propios — la declaración, sus coordenadas y el backend propio de cada tenant cuando lo tiene.

Se pueden declarar nueve backends, en dos familias. HSM autoalojado: SoftHSM, nShield y Thales Luna. Nube, por proveedor y variante: AWS KMS y AWS CloudHSM, Google Cloud KMS y Google Cloud KMS (HSM), Azure Key Vault y Azure Managed HSM. Hay exactamente uno activo por entorno; las dos familias son mutuamente excluyentes. Cada uno lleva una insignia de evidencia — Certificada, Experimental o Solo diseño — que indica hasta dónde lo ha ejercitado ANKATech, y un mecanismo marcado como Solo diseño no se puede declarar.

La pantalla tiene hasta tres pestañas: Configuración, Por tenant y, para quien pueda leer la pista de auditoría, Actividad. La pestaña Por tenant, donde se le da a un tenant un backend de protección de claves propio, tiene su propia ayuda, enlazada más abajo.

Qué debe existir antes

El permiso de lectura de la configuración de plataforma, que muestra los valores, y el permiso de lectura del estado de configuración inicial, que muestra hasta dónde ha llegado la declaración. Los roles integrados de administrador, auditor y visor de la plataforma tienen ambos.
El permiso de operaciones de arranque de la plataforma, para cada paso de la escalera descrita abajo: declarar, guardar coordenadas, validar y activar. Solo lo tiene el superadministrador de plataforma.
El permiso de escritura de secretos del despliegue, además, para sellar una credencial de nube o para retirar una declaración. Retirarla exige ambos, porque eliminar una credencial sellada es un cambio sobre ella.
El permiso de prueba de conexión del backend de claves, que es aparte: es un diagnóstico y no un acto de aprovisionamiento, así que comprobar si el backend responde no exige la autoridad para declarar uno.
Para un backend en la nube, una credencial a la que se concedieron los permisos del proveedor indicados abajo antes de sellarla.
Para un HSM autoalojado, el propio anfitrión preparado antes. La pantalla muestra la lista de comprobación de ese proveedor y el comando que hay que ejecutar, porque en una instalación operada por el cliente ese anfitrión es tuyo.

Qué se concede a una credencial de nube

La credencial que sellas para un backend en la nube crea y usa una clave por tenant y su rotación automática. Concédele:

AWS KMS: kms:CreateKey (una clave SYMMETRIC_DEFAULT por tenant), kms:CreateAlias, kms:ListAliases, kms:DescribeKey, kms:Encrypt, kms:Decrypt, kms:GetKeyRotationStatus y kms:EnableKeyRotation; además kms:ListKeyRotations cuando la clave del despliegue tiene material de clave importado (origen EXTERNAL), para que la comprobación de custodia de claves pueda leer sus materiales.
Google Cloud KMS: cloudkms.keyRings.create, cloudkms.keyRings.get, cloudkms.cryptoKeys.create, cloudkms.cryptoKeys.get, cloudkms.cryptoKeys.update, cloudkms.cryptoKeyVersions.useToEncrypt, cloudkms.cryptoKeyVersions.useToDecrypt y cloudkms.cryptoKeyVersions.list.
Azure Key Vault y Managed HSM: los permisos de clave create, get, wrapKey, unwrapKey, getrotationpolicy y setrotationpolicy.

La clave de sellado del estado de las claves no necesita ningún permiso propio: la plataforma la genera y la guarda envuelta por la clave del despliegue, así que nunca aparece en el proveedor.

No hace falta ningún permiso de borrado: la plataforma nunca destruye una clave en la cuenta del backend del despliegue. Sin los permisos de rotación todo envoltorio sigue funcionando y la alerta de plataforma kek.rotation.missing queda abierta. La lista completa, con el motivo de cada permiso, está en Per-cloud client prerequisites, en la documentación para clientes.

Decisiones que tomas aquí

Leer en qué punto está el despliegue

Una insignia indica la posición, y es el veredicto del servidor mostrado tal cual, nunca compuesto aquí: Sin configurar, Declarado, pendiente de activación, Activando, Enlazado, pendiente de finalizar, Activo o Enlazado pero inalcanzable. Lee el último literalmente: se pinta como un fallo y no como un Activo más pálido, porque es el estado sobre el que de otro modo se actuaría como si fuera correcto. A su lado, el resultado de la última autocomprobación indica No ejecutada, No aplicable, Correcta o Fallida.

Un enlace surte efecto sin reinicio, lo emita quien lo emita: después de que init-hsm.sh --activate lo registre en el anfitrión, la insignia pasa a Enlazado, pendiente de finalizar y se ofrece Completar configuración. Activando significa que el backend todavía no está en servicio: no hay ningún backend de aprovisionamiento disponible o la última autocomprobación no fue correcta.

Mientras haya una entrega pendiente —solo en el camino del anfitrión de un equipo, antes de la segunda activación— la pantalla muestra el comando que entrega la configuración preparada e indica que la plataforma la está esperando; ejecútalo en el anfitrión como el usuario de despliegue del entorno, no como root. En una instalación alojada el comando no se muestra: la pantalla indica que hay una entrega pendiente y que la ejecuta el operador del despliegue.

Hay dos estados más que no son ninguno de esos: mientras el estado se está leyendo, o cuando no se pudo leer, la pantalla lo dice y no muestra la vista sana. Un backend cuyo estado nunca llegó no es un backend que funcione.

La escalera, y el único paso que alcanza el backend

Poner un backend en servicio ejecuta en orden hasta cinco eslabones: la comprobación de coordenadas, la declaración del backend, el guardado de las coordenadas, el sellado de la credencial y la activación. Cuáles se deben depende de hasta dónde haya llegado el despliegue y de la familia: un HSM autoalojado no sella aquí ninguna credencial, porque el PIN de su token lo custodia el anfitrión como secreto del despliegue y nunca pasa por la consola.

En un equipo nShield, Luna o AWS CloudHSM el camino del anfitrión requiere más de una ejecución: la primera activación instala la credencial de la partición y deja preparada la configuración, una entrega hace llegar esa configuración a los servicios en ejecución y una segunda activación enlaza.

La pantalla muestra siempre el comando del paso en el que estás: la primera activación con su argumento de credencial hasta que el anfitrión informa de que la credencial está instalada; después, la entrega y la segunda activación sin argumentos adicionales, hasta que los servicios en ejecución tengan la configuración preparada; a partir de ahí, solo la segunda activación sin argumentos adicionales. Ejecuta primero la entrega y la activación solo después: la activación lee la configuración que la entrega hace llegar. Nunca te pide instalar una credencial que el anfitrión ya instaló.

Solo la activación alcanza el backend. Guardar coordenadas registra una dirección y sellar una credencial almacena una credencial; la activación es donde la plataforma realiza un ciclo de envolver y desenvolver y se compromete a servir lo configurado. No hay opción de omitir esa prueba: es la única observación del backend en todo el recorrido.

En un HSM autoalojado ese ciclo crea una clave AES-256 temporal en el token declarado, confirma a partir de los atributos del propio objeto que no puede salir del token, envuelve y desenvuelve con ella, y la destruye. La etiqueta es aleatoria y queda fuera del espacio de nombres de las claves de tenant.

Un rechazo previo al ciclo no contacta con nada y se puede reintentar sin riesgo. Un fallo producido por el propio backend nombra su causa con un vocabulario cerrado y nunca lleva una dirección, una región, un identificador de cuenta ni un mensaje del proveedor. Una ejecución que creó algunas claves de tenant y después falló se reconcilia en lugar de deshacerse: vuelve a ejecutarla tras corregir la causa y las claves existentes se adoptan sin contactar con el backend por ellas.

Una activación correcta desde esta pantalla también finaliza el aprovisionamiento inicial, así que después no queda nada que pulsar. Un enlace emitido en el anfitrión no lo hace: cuando los servicios en ejecución ya lo llevan, la insignia indica Enlazado, pendiente de finalizar y Completar configuración finaliza el aprovisionamiento inicial.

Retirar una declaración, y la ventana que se cierra

Una declaración se puede retirar mientras al menos uno de los tenants de arranque siga sin una clave de cifrado de claves activa, y se rechaza en cuanto ambos la tienen. Retirarla borra más que la fila que le da nombre: el backend declarado, las coordenadas guardadas, la credencial sellada junto con cualquier anterior retenida o candidata abandonada, y las filas de clave de cifrado de claves activa de los tenants de arranque. Volver a declarar el mismo backend cuesta por tanto una credencial nueva: no hay punto de restauración al otro lado del cambio.

Una vez cerrada esa ventana, el backend declarado es inmutable. Reapuntarlo dejaría huérfano, de forma permanente e irrecuperable, el material de claves ya envuelto con él, así que la plataforma lo rechaza; cambiarlo entonces significa destruir y volver a crear el entorno. Toda incertidumbre se resuelve como todavía enlazado: una afirmación contradicha, una que no se puede verificar y una lectura fallida se rechazan por igual.

Los valores en sí

Los parámetros del backend activo se muestran agrupados y en solo lectura, y cada uno de los demás backends es una fila estática con su nombre, su evidencia y la nota de que no está activo aquí — no es un control. Los secretos los enmascara el servidor antes de que lleguen a la consola y nunca se devuelven; una credencial que escribes es de solo escritura.

Debajo, Rotación de la clave de cifrado de claves de los tenants fija cada cuánto rota la plataforma, en línea, la clave de cifrado de claves de cada tenant en un backend PKCS#11: un número entero de meses de 1 a 24, 12 de forma predeterminada, que se guarda con el permiso para gestionar la custodia de claves. Un backend en la nube muestra Definido por el proveedor, porque su proveedor rota ese material de claves: cada tenant tiene allí su propia clave, y la plataforma activa al crearla la rotación automática del proveedor, cada 365 días por omisión.

Aquí se pueden definir tres coordenadas, y las tres están clasificadas como peligrosas: la estrategia con la que se selecciona el token (label o serial), la etiqueta del token y el número de serie del token. La tarjeta ofrece un control solo para las que lee la estrategia actual —la propia estrategia y la coordenada que nombra— y mantiene la otra nombrada, con el motivo por el que no se lee; cambiar la estrategia es lo que la recupera.

Cuando la estrategia no tiene valor, la tarjeta ofrece las tres. Un control indica Definir mientras no hay nada almacenado y Cambiar, junto al valor almacenado, cuando lo hay.

En AWS CloudHSM el módulo no informa ningún número de serie de token, así que la plataforma rechaza allí la selección por número de serie: la estrategia ofrece solo label, la tarjeta indica el motivo y una escritura de serial mediante la API se rechaza sin cambiar nada. Identifica ese token por su etiqueta.

La selección posicional no se acepta en este despliegue, así que la entrada del índice de ranura se publica sin efecto y debe quedar vacía. Ninguna ruta de módulo PKCS#11 es escribible en todo el catálogo, y el perfil de proveedor es fijo durante la vida del entorno.

Cómo se relaciona con otras pantallas

Esta pantalla está dentro del grupo Criptografía y Confianza, junto a la autoridad de sellado de tiempo y las reglas de confianza de migración:

Las claves de un tenant son lo que protege este backend, y el mapa de integraciones dibuja el estado de esta superficie junto al de las demás conexiones:

Dónde leer más

Estas páginas están en inglés: