HSM / KMS en la Nube — Por Tenant
Para qué sirve esta pantalla
La pestaña Por tenant es donde se le da a un tenant un backend de protección de claves propio en lugar de heredar el del despliegue. El tenant de destino se elige en un selector, nunca accediendo a él, y se repite como texto junto a la superficie para que una escritura no pueda caer en un tenant que no elegiste. En una instalación operada por el cliente todos los tenants tienen derecho a esto y no se consulta ninguna edición licenciada; en una instalación SaaS o SaaS dedicada, solo un tenant cuya edición efectiva es Enterprise.
El backend propio de un tenant es siempre un servicio de claves en la nube: AWS KMS, Google Cloud KMS, Google Cloud KMS (HSM), Azure Key Vault o Azure Managed HSM. Aquí nunca se ofrece un HSM físico. Se vincula una sola vez, en la pestaña Configuración, y cada tenant que conserva el valor por defecto lo hereda con una clave de cifrado de claves propia. Un tenant que debe guardar su clave en un HSM propio usa AWS KMS con una clave en un almacén de claves de AWS CloudHSM.
La declaración de custodia de la tarjeta indica quién opera el servicio de claves que guarda la clave de cifrado de claves del tenant: el propio tenant cuando aportó su backend; tu organización cuando la instalación la opera el cliente; ANKATech en una instalación SaaS o SaaS dedicada, compartido por todos los tenants del mismo nivel.
Qué debe existir antes
Los controles de esta pestaña dependen de tres permisos para gestionar desde la plataforma el backend propio de un tenant, cada uno para sus propios controles: declararlo —lo que incluye cambiarlo, rotar su credencial, validarlo y revertirlo—, vincularlo y ejecutar su prueba de conexión. Un rol puede tener cualquiera de ellos sin los demás. Solo los tiene el superadministrador de plataforma; la escritura de la configuración de plataforma ni los concede ni se exige para ninguno.
Qué se concede a la credencial del tenant
La credencial de la clave propia de un tenant debe poder leer el estado de la clave y sus versiones, además de envolver y desenvolver: la comprobación de custodia de claves los lee después de una restauración o una actualización, por lo que vincular el backend y rotar la credencial los comprueban contra la clave declarada. Concédele:
- AWS KMS:
kms:DescribeKey, máskms:ListKeyRotationspara una clave con material importado (origenEXTERNAL). - Google Cloud KMS:
cloudkms.cryptoKeys.getycloudkms.cryptoKeyVersions.list. El rolroles/cloudkms.cryptoKeyEncrypterDecrypterno incluye ninguno de los dos. - Azure Key Vault y Managed HSM: nada nuevo; basta el permiso de clave
getque ya se exige.
La lista completa de permisos, con el motivo de cada uno, está en los requisitos previos del cliente por nube, en la documentación para clientes.
Decisiones que tomas aquí
Qué backend puede declarar un tenant
Cuáles de los cinco puede declarar un tenant lo acota tu propia lista de permitidos, uno de los valores de la pestaña Configuración. Una lista vacía no significa "no se admite nada": significa que no se ha fijado ninguna restricción, así que los cinco siguen disponibles. Una lista guardada que nombra solo backends HSM, de antes de que salieran de esta pestaña, no admite ninguno de los cinco: vacíala o nombra backends en la nube.
Declarar un backend no lo pone en vigor. Hasta que el backend del tenant esté vinculado, el tenant no puede crear claves: su primera clave se rechaza hasta que la vinculación tenga éxito, y no sigue usando el backend que tenía antes. Vincula el backend antes de que el tenant empiece a trabajar.
En AWS KMS la clave se declara con el ARN de la clave; un ARN de alias se rechaza. También se rechaza una clave que este despliegue creó o usa para su propia custodia de claves. Una credencial o una clave rechazada no cambia nada:
La comprobación de la credencial, y su rotación
La comprobación de credencial de la tarjeta es un hecho que registra el servidor, no una deducción del estado del backend. Muestra Not checked yet mientras no haya ninguna registrada, también en un backend ACTIVE; una prueba de conexión o una rotación la registra en cualquier estado. Muestra Proven at con la hora tras una comprobación superada, y Last check failed at con la hora y el motivo cuando una prueba de conexión no se superó: rechazada, sin contacto o sin respuesta a tiempo. Declarar, cambiar o retirar el backend la borra.
Rotar la credencial de acceso de un tenant nunca toca el material de claves, y comprueba la credencial nueva antes de reemplazar la anterior. Se comprueba solo la credencial nueva contra la clave declarada: si el tenant ya tiene claves no compuestas que no son importaciones solo públicas, primero se descifra con ella la más reciente, y después se cifra y descifra con ella un valor desechable. La credencial vigente no se usa, así que una rotación funciona incluso después de desactivar la credencial anterior en el proveedor de nube.
Una credencial que no supera la comprobación se rechaza con su motivo y la comprobación en curso, y la credencial vigente no cambia. Lee primero el motivo: una credencial que el servicio de claves no acepta se informa contra la primera comprobación, y lo que hay que corregir es el secreto. Una credencial que solo puede descifrar se rechaza, porque las claves nuevas también deben cifrarse con ella. Enviar la misma credencial da la misma respuesta; corrígela primero. Si no se puede contactar el servicio de claves, el rechazo es temporal: reintenta en breve.
Después de una rotación correcta, la credencial anterior puede seguir en uso durante un breve tiempo (de forma predeterminada, hasta 60 segundos), así que desactívala en el proveedor de nube solo después de ese tiempo. Una rotación sobre una declaración HSM guardada antes de que el backend propio de un tenant pasara a ser solo en la nube también se rechaza y no cambia nada. Cuando un tenant ya tiene material de claves, declarar aquí otro backend se rechaza, y el rechazo indica que el cambio es un traslado de custodia de claves.
La custodia de claves, y su traslado
Debajo de la tarjeta, Custodia de claves muestra un traslado de custodia de claves: dónde se protegen las claves del tenant, el traslado abierto y su progreso, la rotación de su clave de cifrado de claves, las retiradas aún conservadas y el historial. Cuando se ha observado, Rotación en el proveedor indica si la clave propia del tenant rota automáticamente en su proveedor; la plataforma nunca la rota.
Si la instalación la opera el cliente, el traslado se inicia aquí —hacia el KMS propio del tenant, hacia otro o de vuelta al backend del despliegue, confirmándolo con el nombre del tenant— y se programa, cancela, anula o revierte; durante su ventana el tenant está en mantenimiento. En una instalación SaaS o SaaS dedicada esta pestaña solo lee el backend propio de un tenant: lo gestiona su administrador, cada escritura aquí queda inactiva e indica por qué, y la prueba de conexión sigue disponible.
Destruir una clave de cifrado de claves retirada
Una clave de cifrado de claves retirada, pasada su retención y sin nada envuelto con ella, ofrece Destruir…. La plataforma retiene toda destrucción durante el período de espera del despliegue (30 días por defecto) sin llamar al proveedor ni al HSM de la clave: la lista muestra Destrucción prevista para el con la fecha en que termina el período, y hasta entonces Cancelar la destrucción… devuelve la clave a retirada.
Cuando termina el período, la plataforma vuelve a comprobar la clave. Si envuelve otra vez material de claves, comparte su objeto de clave con una clave en uso, pertenece a un tenant cuya custodia se está trasladando, o el objeto con su nombre no es el registrado, no se destruye nada, la clave vuelve a estar retirada y se genera una alerta de plataforma; destruirla entonces requiere una nueva solicitud y, si el objeto no era el registrado, solo después de investigar el token o el servicio de claves.
Si no, la plataforma envía la destrucción al proveedor de la clave. Hasta que se registra la respuesta del proveedor, la lista muestra Enviada al proveedor y Cancelar la destrucción… queda deshabilitado. Después, un HSM destruye el objeto de clave: la lista muestra Destruida en el HSM, pendiente de confirmación, sin cancelación.
Un Cloud KMS inicia su propio período de espera, que se suma al de la plataforma: la lista muestra En su proveedor con la fecha del proveedor, y Cancelar la destrucción… la cancela en el proveedor hasta entonces. En ambos casos figura como Destruida cuando el proveedor lo confirma. Después, nada de lo que siga envuelto con la clave, incluso en copias de seguridad anteriores, se puede descifrar. La clave propia de un tenant nunca se destruye.
Cómo se relaciona con otras pantallas
El backend propio del despliegue, que hereda todo tenant sin backend propio, se configura en la pestaña Configuración:
Las claves de un tenant son lo que protege su backend: