Error de copia de seguridad de CipherTrust Manager

Publicado: marzo de 2023. Actualizado: agosto de 2026. Revisado por el equipo de ingeniería de gestión de claves de Encryption Consulting.

Un fallo en la copia de seguridad de CipherTrust Manager no es un simple error estético. Significa que, si el dispositivo se pierde, se daña o necesita reconstruirse, no existe una forma verificada de recuperar las claves, las políticas y el historial de auditoría. Esta guía explica por qué se produce el error de copia de seguridad, cómo solucionarlo en un clúster en producción y las medidas operativas, como la propiedad, la rotación, el control de acceso y la evidencia de auditoría, que evitan que vuelva a ocurrir.

¿Qué causa los errores de copia de seguridad de CipherTrust Manager?

La mayoría de los errores de copia de seguridad de CipherTrust Manager se deben a una de estas tres causas principales: una clave de copia de seguridad faltante o incorrecta en el nodo que ejecuta la tarea, una condición previa de la política que no se eliminó antes de que comenzara la copia de seguridad, o un límite de compatibilidad de versión y restauración. CipherTrust Manager trata cada copia de seguridad como un artefacto local del nodo cifrado con una clave específica, y no sincroniza automáticamente las copias de seguridad ni las claves de copia de seguridad en todo el clúster. Según la propia documentación de Thales, «las copias de seguridad y las claves de copia de seguridad no se copian automáticamente a otros nodos del clúster. Solo existen en el nodo donde se crean o se copian». Una vez comprendido este comportamiento, la mayoría de los «errores» de copia de seguridad resultan ser deficiencias en la distribución de claves, en lugar de una función defectuosa.

Consideremos un clúster de CipherTrust Manager de cuatro nodos (thales01.ec.com, thales02.ec.com, thales03.ec.com, thales04.ec.com). Siguiendo el procedimiento estándar, se crea una programación de copia de seguridad del sistema en un nodo, y los metadatos de dicha programación se replican en los demás. Sin embargo, la clave de copia de seguridad no se replica. Si la tarea programada se ejecuta en un nodo que nunca recibió la clave, la tarea falla.

Escenarios de errores comunes y sus causas principales

Este es el escenario que Encryption Consulting observa con mayor frecuencia, y es el tema central de la solución paso a paso que se describe a continuación. La razón principal de este error es que las copias de seguridad programadas se ejecutan en el nodo que recibe la tarea, y si ese nodo no tiene la clave de copia de seguridad presente y marcada como predeterminada, la tarea no puede cifrar el archivo de copia de seguridad y, por lo tanto, falla.

Se han producido otros fallos de copia de seguridad y restauración con la suficiente regularidad como para merecer la pena documentarlos junto con este, todos ellos confirmados con la documentación de administración de CipherTrust Manager de Thales:

• La copia de seguridad falla silenciosamente y no se genera ningún archivo. La documentación de Thales indica que “todas las políticas de quórum deben estar desactivadas antes de crear una copia de seguridad”. Si se deja activada una política de quórum en el nodo, la tarea se bloquea antes de que pueda ejecutarse.
• La copia de seguridad se completa, pero la restauración falla con un error clave. La clave de respaldo utilizada durante la restauración no coincide con la clave que cifró el archivo. Esto ocurre cuando un administrador toma la clave de respaldo que tenga a mano en un nodo diferente, en lugar de la que estaba activa en el nodo de origen al momento de la copia de seguridad.
• La restauración ha sido rechazada en un nodo de clúster existente. Las copias de seguridad del sistema no están diseñadas para restaurarse en un nodo de clúster en funcionamiento. Thales recomienda utilizar el método de eliminación y reconstrucción del clúster en lugar de una restauración directa en ese caso.
• La restauración se rechaza al cruzar un límite de versión. Las copias de seguridad de CipherTrust Manager se restauran, de forma predeterminada, a las tres versiones menores siguientes (por ejemplo, una copia de seguridad 2.6 se restaura limpiamente a 2.7, 2.8 o 2.9). Restaurar una copia de seguridad anterior a esa requiere una --force Thales recomienda contactar con el servicio de asistencia técnica antes de utilizar esta opción.
• El comando de copia de seguridad o restauración falla con un error de ocupado o bloqueado. En CipherTrust Manager, solo se puede ejecutar una operación de copia de seguridad o restauración a la vez. Si se inicia una segunda tarea mientras ya hay una en curso, esta será rechazada.
• Una copia de seguridad vinculada a una raíz de confianza de HSM se vuelve inutilizable. Opcionalmente, las copias de seguridad del sistema pueden vincularse a una clave raíz de confianza del HSM para una mayor protección, pero si esa clave del HSM se elimina posteriormente, la copia de seguridad que dependía de ella nunca podrá restaurarse.

Cómo solucionar el error de copia de seguridad de CipherTrust Manager (paso a paso)

La solución para el error de clave de copia de seguridad NCERRInvalidParamValue consiste en crear una clave de copia de seguridad del sistema predeterminada y distribuirla a todos los nodos del clúster, de modo que la programación se ejecute correctamente independientemente del nodo en el que se ejecute la tarea. Los pasos que se describen a continuación presuponen que la programación se creó originalmente desde thales01.ec.com.

1. En thales01.ec.com, diríjase a Claves de respaldo en Configuración de administrador.

   

2. Cree una nueva clave de copia de seguridad del sistema y establézcala como predeterminada.

   

3. Descargue la clave de copia de seguridad del sistema recién creada para poder cargarla en los demás nodos del clúster de CipherTrust Manager.

   

4. Introduzca una contraseña para la clave de copia de seguridad y haga clic en “Descargar”.

   

5. Siga esta ruta para cargar la clave de copia de seguridad del sistema en cada nodo del clúster de CipherTrust Manager: Configuración de administración > Claves de copia de seguridad > Agregar clave de copia de seguridad > Cargar clave de copia de seguridad. Seleccione el archivo descargado e ingrese la contraseña del paso anterior.

   

6. Una vez que la carga se haya realizado correctamente, haga clic en el icono de opciones múltiples y seleccione "Establecer como predeterminado" en cada nodo.

   

7. Para configurar una copia de seguridad a nivel del sistema, vaya a Configuración de administración > Programaciones.

   

8. Haz clic en “Añadir horario”.

   

9. Seleccione “Copia de seguridad del sistema” y haga clic en “Siguiente”.

   

10. Introduzca un nombre para el horario y haga clic en “Siguiente”.

    

11. Configure la frecuencia de la copia de seguridad y haga clic en “Siguiente”.

    

12. Establezca el número de copias de seguridad que desea conservar y seleccione "Usar clave de copia de seguridad predeterminada". El uso de la clave predeterminada es lo que permite que la programación se realice correctamente independientemente del nodo del clúster en el que se ejecute la tarea, ya que la misma clave está presente en todas partes.

    

Si la tarea sigue fallando incluso después de que todos los nodos tengan la misma clave predeterminada, desactive cualquier política de quórum activa antes de la siguiente ejecución programada y confirme que no haya ninguna otra tarea de copia de seguridad o restauración en curso en ese nodo.

Responsabilidad de propiedad y programación de copias de seguridad

El error NCERRInvalidParamValue suele ser síntoma de la falta de un propietario, no solo de la falta de una clave. Cuando no hay una persona responsable de confirmar que la copia de seguridad se haya realizado correctamente, las deficiencias en la distribución de claves pasan desapercibidas hasta que se necesita una restauración. Un modelo de propiedad viable para un clúster de CipherTrust Manager incluye:

• Un propietario de respaldo designado (individual o por turnos de guardia) responsable de cada nodo del clúster, no solo del nodo en el que se creó la programación.
• Un manual de procedimientos documentado que enumera qué nodo contiene actualmente qué clave de copia de seguridad predeterminada, y que se actualiza cada vez que se agrega, reconstruye o elimina un nodo.
• Una comprobación periódica, al menos semanal, que confirme que la última copia de seguridad programada se ha completado realmente en todos los nodos, no solo en el nodo en el que se ejecutó.
• Es fundamental establecer un procedimiento claro para escalar los problemas cuando una copia de seguridad programada falla dos veces seguidas, en lugar de dejar que las notificaciones de fallos se acumulen sin leer.

Disparadores de rotación para claves de cifrado de respaldo

Una clave de respaldo es una clave criptográfica como cualquier otra clave de CipherTrust Manager, y debe rotarse según desencadenantes definidos en lugar de dejarse indefinidamente. Encryption Consulting recomienda rotar la clave de respaldo del sistema cuando ocurra cualquiera de las siguientes situaciones:

• Un administrador que tenía acceso al archivo de clave de respaldo o a su contraseña abandona el equipo o cambia de función.
• La restauración falla porque se utilizó una clave de copia de seguridad incorrecta, lo que a menudo indica que el inventario de claves está desactualizado.
• Un nodo del clúster se desactiva o se reemplaza, ya que su copia local de la clave de respaldo debe eliminarse junto con él.
• La política general de rotación de claves de la organización así lo exige, con la misma periodicidad que se aplica a otros materiales criptográficos de larga duración.
• Una clave de respaldo estaba vinculada a una clave raíz de confianza de HSM que, a su vez, está siendo rotada o retirada, ya que la documentación de Thales confirma que una copia de seguridad vinculada a HSM no se puede restaurar una vez que se elimina esa clave raíz de confianza.

Tras la rotación, la nueva clave predeterminada debe distribuirse manualmente a cada nodo del clúster, del mismo modo que se distribuyó la clave original en la solución anterior. Rotar la clave en un nodo y olvidarse de los demás simplemente reproduce el error original con una nueva clave.

Política de acceso: ¿Quién puede iniciar o restaurar una copia de seguridad?

El modelo de acceso de CipherTrust Manager se basa en dominios y grupos con roles definidos, por lo que las acciones relacionadas con las copias de seguridad deben limitarse estrictamente a este modelo. La documentación de Thales especifica claramente que la descarga de registros del dominio raíz está restringida a grupos concretos: «Solo los usuarios que pertenecen a los grupos Administradores del sistema y Administradores pueden descargar los registros del dominio raíz». Este mismo principio se aplica a la creación y restauración de copias de seguridad, que acceden a las claves de todos los dominios simultáneamente para realizar una copia de seguridad del sistema.

Una política de acceso sólida para las operaciones de copia de seguridad mantiene un grupo reducido de usuarios que pueden crear o cargar claves de respaldo, separándolo de los usuarios que administran las claves a diario. Además, requiere la aprobación de un segundo responsable antes de ejecutar una restauración en un clúster de producción y evita que se comparta una contraseña de clave de respaldo sin documentar en un mensaje de chat o ticket. La restauración es la acción de mayor riesgo: una restauración incorrecta puede revertir claves, políticas y usuarios a un estado obsoleto en todo el sistema.

Evidencia de auditoría sobre el éxito y el fracaso de las copias de seguridad.

Un programa de copias de seguridad que "suele funcionar" no constituye evidencia de nada para un auditor. Los registros del sistema de CipherTrust Manager registran acciones administrativas, cambios de configuración y operaciones tanto exitosas como fallidas, que son la materia prima para la evidencia de auditoría de copias de seguridad. Los registros se pueden obtener desde la GUI en Configuración de administración > Registros o a través de la ksctl logs download La herramienta de línea de comandos y los registros descargados están protegidos contra ataques informáticos mediante un hash SHA-256 firmado con un par de claves asimétricas, verificable con OpenSSL.

Para garantizar un proceso de copia de seguridad auditable, envíe estos registros a un SIEM central o a un repositorio de registros en lugar de depender únicamente de la consola de CipherTrust Manager. Conserve la evidencia del estado de finalización de cada copia de seguridad programada durante el período de retención de cumplimiento de la organización y mantenga un registro independiente de cada rotación de clave de copia de seguridad y de cada evento de restauración, incluyendo quién lo aprobó. Esta evidencia es lo que convierte la afirmación «tenemos copias de seguridad» en una respuesta válida durante una auditoría o después de un incidente.

Comparación de plataformas: Copia de seguridad manual frente a copia de seguridad automatizada/programada

CipherTrust Manager admite tanto copias de seguridad manuales bajo demanda como copias de seguridad periódicas. Ambas opciones no son intercambiables desde el punto de vista operativo, y la mayoría de las organizaciones necesitan ambas.

Factor	Respaldo manual	Copia de seguridad automatizada/programada
Desencadenar	Ejecutado por un administrador antes de un cambio planificado, una actualización o una ventana de mantenimiento.	Se ejecuta a intervalos definidos independientemente de si un administrador está observando.
Consistencia	Depende de que alguien se acuerde de ejecutarlo.	Siempre que la clave de respaldo y las condiciones previas del quórum estén configuradas correctamente en el nodo donde se ejecuta el trabajo.
Visibilidad de errores	El administrador que lo ejecutó detecta el fallo de inmediato.	Un fallo puede pasar desapercibido durante todo un ciclo a menos que exista un sistema de alerta o un proceso de revisión.
Registro de auditoría	Evento único, fácil de documentar individualmente.	Se necesita un proceso de revisión de registros periódico para demostrar la cobertura continua.
Mejor utilizado para	Instantáneas previas al cambio y a la actualización	Cobertura rutinaria de recuperación ante desastres entre cambios

Respuesta ante incidentes si se detecta un fallo de copia de seguridad durante un evento de recuperación ante desastres.

El peor momento para descubrir que una copia de seguridad de CipherTrust Manager está fallando silenciosamente es en medio de un evento de recuperación ante desastres, cuando no queda tiempo para solucionar primero la brecha subyacente en la distribución de claves. Si esto sucede, proceda en este orden:

1. Identifique cada nodo del clúster y verifique individualmente si existe un archivo de copia de seguridad reciente y utilizable en cada uno. Dado que las copias de seguridad son locales a cada nodo, puede existir una copia de seguridad en buen estado en un nodo distinto al que acaba de fallar.
2. Confirme qué clave de respaldo cifró la copia de seguridad utilizable más reciente y localice ese archivo de clave y contraseña exactos, en lugar de asumir que cualquier clave "predeterminada" que tenga a mano funcionará.
3. Si solo se dispone de una copia de seguridad con ámbito de dominio y no es posible una restauración completa del sistema, restaure primero la copia de seguridad con ámbito de dominio para recuperar las claves y las políticas de ese dominio, ya que las copias de seguridad con ámbito de dominio se pueden restaurar en cualquier nodo del clúster.
4. Si el destino es un nodo de clúster existente y en funcionamiento, no intente restaurar el sistema directamente. Utilice el método de eliminación y reconstrucción del clúster o póngase en contacto con el soporte técnico de Thales para obtener orientación sobre la secuencia más segura para ese entorno.
5. Una vez restablecido el servicio, considere el incidente como el detonante de una auditoría completa de las claves de copia de seguridad en todos los nodos, no solo en el que falló, y corrija la brecha en la distribución de claves que causó el fallo silencioso original.

El equipo de Servicios de Asesoramiento en Cifrado de Encryption Consulting puede realizar este tipo de simulacro de recuperación ante desastres en un clúster de CipherTrust Manager en funcionamiento antes de que se convierta en un incidente real, de modo que las deficiencias se detecten en un simulacro en lugar de durante una interrupción real del servicio.

Síntoma del error, causa probable y solución

Síntoma de error	Causa probable	Solución
codeDesc: NCERRInvalidParamValue, “La clave de respaldo especificada no existe para el ámbito (sistema)”	La clave de respaldo no se cargó ni se configuró como predeterminada en el nodo que maneja la tarea programada.	Cree y descargue la clave de copia de seguridad del sistema, cárguela en cada nodo del clúster y establézcala como predeterminada en cada uno de ellos.
La copia de seguridad programada no genera ningún archivo ni error claro.	Se dejó habilitada una política de quórum en el nodo antes de que se ejecutara el trabajo.	Desactive todas las políticas de quórum antes de ejecutar o programar la copia de seguridad.
La copia de seguridad se completa, pero la restauración falla debido a una discrepancia de clave.	La clave de respaldo utilizada para la restauración no es la misma clave que cifró el archivo en el nodo de origen.	Localice y utilice el archivo de clave de copia de seguridad específico que estaba activo en el nodo de origen en el momento de la copia de seguridad.
La restauración ha sido rechazada en un nodo de clúster existente.	Las copias de seguridad del sistema no están diseñadas para restaurarse en un nodo de clúster en funcionamiento.	Utilice el método de eliminación y reconstrucción del clúster en lugar de una restauración directa.
Restauración rechazada en un límite de versión	La copia de seguridad es más de tres versiones menores anterior a la versión en ejecución de CipherTrust Manager.	Utilice la opción –force restore solo después de consultar con el soporte de Thales, o bien restaure primero a través de una versión intermedia.
El comando de copia de seguridad o restauración falla con un error de ocupado o bloqueado.	Ya hay otra tarea de copia de seguridad o restauración en ejecución, y solo se permite una a la vez.	Espere a que termine el trabajo en curso antes de comenzar uno nuevo.

Limitaciones

• Las copias de seguridad y las claves de copia de seguridad están diseñadas para ser locales en cada nodo; no existe una replicación automática integrada en un clúster de CipherTrust Manager, por lo que la distribución de claves debe gestionarse manualmente cada vez que se modifica una programación o una clave.
• Una copia de seguridad del sistema no se puede restaurar directamente en un nodo que aún forma parte de un clúster activo; la recuperación de un entorno en clúster requiere el proceso de eliminación y reconstrucción.
• La función de restauración de compatibilidad solo se extiende a las tres versiones menores siguientes de forma predeterminada, lo que limita el tiempo durante el cual una copia de seguridad antigua puede restaurarse prácticamente sin la intervención del soporte técnico.
• Solo se puede ejecutar una tarea de copia de seguridad o restauración a la vez, lo que puede generar un cuello de botella durante una recuperación a gran escala que involucre varios dominios.
• Vincular una copia de seguridad a una clave raíz de confianza de HSM añade protección, pero también añade un modo de fallo estricto: si se elimina esa clave de HSM, la copia de seguridad se vuelve permanentemente irrecuperable.

¿Qué recomendaría Encryption Consulting?

Solucionar el error inmediato NCERRInvalidParamValue es una tarea de cinco minutos una vez que se comprende la causa. El problema recurrente que observamos en las implementaciones de CipherTrust Manager es que las claves de respaldo se tratan como un paso de configuración único en lugar de un ciclo de vida continuo, sin propietario designado, sin cadencia de rotación y sin registro de auditoría hasta que se necesita una restauración y esta falla.

El servicio HSM-as-a-Service de Encryption Consulting proporciona a las organizaciones una capa operativa gestionada en torno a plataformas como CipherTrust Manager, incluyendo la distribución consistente de claves de respaldo, la programación supervisada y la recopilación de evidencia, sin necesidad de personal adicional dedicado a la administración del dispositivo. Para las organizaciones que deseen evaluar y formalizar primero sus prácticas actuales de gestión y copia de seguridad de claves, nuestro equipo de Servicios de Asesoramiento en Cifrado puede realizar una evaluación de brechas según los criterios de propiedad, rotación, acceso y auditoría descritos anteriormente y crear un manual de procedimientos específico para la topología de su clúster.

Conclusión

El error de clave de copia de seguridad NCERRInvalidParamValue es fácil de solucionar una vez que se sabe que CipherTrust Manager no distribuye las claves de copia de seguridad en un clúster por sí solo. La solución más compleja y duradera es operativa: asignar un propietario con nombre para las programaciones de copias de seguridad, establecer activadores de rotación reales para la clave de copia de seguridad, restringir quién puede activar o restaurar una copia de seguridad y conservar evidencia de auditoría que demuestre que la programación se ejecutó realmente, no solo que se configuró para ello. Los equipos que implementan esta disciplina evitan descubrir fallos en las copias de seguridad durante un evento real de recuperación ante desastres, que es el único momento en que su detección resulta realmente costosa.

Para problemas relacionados con CipherTrust Manager, consulte nuestras guías sobre el error de agrupación de CipherTrust Manager y el error de certificado de la interfaz web de CipherTrust Manager , o nuestra descripción general de la integración de un HSM de Thales con CipherTrust Manager local . Si la administración continua es el principal obstáculo, nuestro análisis sobre por qué los equipos recurren al soporte técnico especializado de CipherTrust Manager ofrece una visión operativa más amplia.

Preguntas frecuentes

¿Por qué CipherTrust Manager indica que "la clave de respaldo especificada no existe para el ámbito (sistema)"?
Este error significa que el nodo que recibió la tarea de copia de seguridad programada no tiene la clave de copia de seguridad presente y marcada como predeterminada. CipherTrust Manager no copia automáticamente las claves de copia de seguridad entre los nodos del clúster, por lo que, a menos que se cargue la misma clave predeterminada en todos los nodos, una tarea que llegue a un nodo que no la tenga fallará con este mismo mensaje.

¿Las claves de respaldo de CipherTrust Manager se replican automáticamente en todos los nodos del clúster?
No. La documentación de Thales indica claramente que las copias de seguridad y las claves de copia de seguridad no se copian automáticamente a otros nodos del clúster, sino que solo existen en el nodo donde se crearon o se cargaron manualmente. Cada nodo del clúster necesita que se le cargue por separado la misma clave de copia de seguridad predeterminada.

¿Es posible restaurar una copia de seguridad del sistema CipherTrust Manager directamente en un nodo del clúster?
No. Las copias de seguridad del sistema no están diseñadas para restaurarse en un nodo que aún forma parte de un clúster activo. Thales recomienda eliminar y reconstruir el clúster en ese caso. Las copias de seguridad con ámbito de dominio son diferentes y se pueden restaurar en cualquier nodo del clúster.

¿Con qué frecuencia se deben rotar las claves de cifrado de respaldo de CipherTrust Manager?
Thales no ha establecido un intervalo único, por lo que este debe ajustarse a la política general de rotación de claves de la organización, además de los desencadenantes basados ​​en eventos: tras cambios de personal con acceso a la clave, tras un fallo de restauración relacionado con una discrepancia de clave, antes de desactivar un nodo o tras cualquier sospecha de exposición del archivo de clave de respaldo o la contraseña.

¿Qué ocurre si una copia de seguridad de CipherTrust Manager está vinculada a una clave raíz de confianza de HSM que se elimina?
Según la documentación de Thales, una copia de seguridad vinculada al HSM no se puede restaurar si la clave raíz de confianza del HSM de la que depende se elimina manualmente. Cualquier organización que vincule copias de seguridad a una raíz de confianza del HSM debe considerar el ciclo de vida y los controles de eliminación de dicha clave como parte de la estrategia de copias de seguridad, y no como un aspecto independiente.

Referencias

• Thales Docs, “Copias de seguridad”, Guía de administración de CipherTrust Manager 2.9, thalesdocs.com
• Thales Docs, “Copias de seguridad”, Guía de administración de CipherTrust Manager 2.10, thalesdocs.com
• Thales Docs, “Registros del sistema”, Guía de administración de CipherTrust Manager, thalesdocs.com