Actualice de forma segura a Vormetric Data Security Manager y migre sin problemas a CipherTrust Manager.

Actualizar Vormetric Data Security Manager (DSM) , el dispositivo de gestión de claves y políticas de Thales para entornos de cifrado transparente de Vormetric (VTE), puede parecer relativamente sencillo, pero si algo sale mal, los datos protegidos por el cifrado gestionado por DSM pueden perderse o volverse inaccesibles. Thales anunció que Vormetric DSM llegó al final de su ciclo de vida en junio de 2024, lo que convierte la migración a CipherTrust Manager (CTM) en una decisión crítica y urgente para todos los usuarios restantes de DSM. Este artículo no proporciona los comandos de actualización paso a paso, sino que aborda los aspectos que las organizaciones deben tener en cuenta: los puntos técnicos y no técnicos que la guía de actualización oficial no destaca, y los desafíos reales que presentan las actualizaciones de DSM en producción y las migraciones a CTM. La acción recomendada es: documentar el inventario completo de agentes y la matriz de compatibilidad antes de realizar cualquier cambio, actualizar DSM a la versión 6.4.5 o 6.4.6 antes de intentar la migración a CTM, y realizar pruebas piloto exhaustivas en un entorno que no sea de producción antes de cualquier transición a producción. Para obtener información sobre el contexto de la gestión de claves, consulte CipherTrust Manager y ¿Qué es la gestión de claves?

Respuesta rápida: ¿Cuáles son los dos caminos y cuál se aplica a usted?

Existen dos rutas operativas distintas: actualizar una instancia de DSM existente a una versión más reciente y migrar completamente de DSM a CipherTrust Manager (CTM). Para la mayoría de las organizaciones, estas dos rutas son secuenciales, no alternativas: si su DSM no está en la versión 6.4.5 o 6.4.6, debe actualizarlo antes de que las herramientas de migración puedan transferir sus datos a CTM. Ambas rutas conllevan riesgo de pérdida de datos e inactividad si se ejecutan sin una planificación exhaustiva, una matriz de compatibilidad y pruebas piloto. CTM es un producto diferente de DSM, no solo una versión actualizada, por lo que la migración también requiere nuevos manuales de operaciones, nuevos procedimientos operativos estándar, nueva documentación de arquitectura y capacitación para los equipos de operaciones.

Planificación: Qué documentar antes de empezar

Todo empieza con una buena planificación, y la actualización de DSM no es la excepción. Un análisis completo del entorno actual es vital para evaluar cualquier obstáculo o desafío futuro que pueda enfrentar.

1. Documente todos los agentes, versiones de agentes y puntos de protección. Al actualizar DSM, puede consultar la lista de todos los agentes y confirmar que todos los puntos de protección estén activos y en buen estado. Si algo no coincide con lo esperado, es posible que deba solucionar el problema antes de continuar. Las versiones de los agentes también pueden indicar si tiene agentes incompatibles con la versión de DSM a la que desea actualizar. Una matriz de compatibilidad le ayudará a determinar qué agentes son compatibles y cuáles necesitan actualizarse. También puede desarrollar una ruta de actualización a partir de este inventario. Thales define una ruta de actualización obligatoria que debe seguirse: por ejemplo, si actualiza de DSM 5.3 a 6.2, no puede pasar directamente a 6.2 sin pasar por la versión intermedia 6.0.0.

2. Planificar la transición a la producción. Muchas organizaciones que buscan actualizar sus sistemas ya deberían contar con una instancia de DSM en producción. Generalmente, prefieren no actualizar la instancia de DSM existente; en su lugar, implementan otra instancia de DSM con la versión objetivo, realizan pruebas piloto y solo cambian a la nueva instancia de DSM como instancia de producción una vez finalizadas las pruebas. Las organizaciones deben planificar el cronograma de transición, la comunicación y los procedimientos de reversión antes de comenzar cualquier trabajo de actualización.

Una planificación minuciosa garantiza que los pasos siguientes se desarrollen sin problemas y que DSM pueda actualizarse a la versión deseada sin interrupciones inesperadas de datos o servicios.

Actualización de los DSM: Desafíos del mundo real

La planificación puede facilitar el proceso de actualización, pero actualizar un DSM en producción suele revelar desafíos que no eran visibles durante la planificación. Los desafíos que se presentan en las actualizaciones de producción reales incluyen:

1. La transición del antiguo DSM al nuevo DSM sin interrumpir el registro del agente requiere una cuidadosa orquestación de la secuencia de re-registro del agente.
2. Actualizar DSM a una versión en la que todos los agentes existentes sigan siendo compatibles, especialmente cuando el entorno incluye una combinación de versiones de agentes de diferentes épocas.
3. La configuración de clústeres de alta disponibilidad (HA) con DSM en diferentes subredes introduce complejidades de red y sincronización de clústeres que no se abordan en la documentación básica de actualización.
4. Planificación de la duración de la actualización: Las actualizaciones de DSM pueden llevar un tiempo considerable dependiendo del tamaño del entorno, y sin una planificación de transición adecuada, los sistemas de producción pueden sufrir tiempos de inactividad no planificados; con una planificación adecuada, la transición a DSM puede ser fluida y sin tiempos de inactividad.

Las organizaciones deben prepararse exhaustivamente para la actualización de los DSM, ya que un error en el proceso de actualización puede provocar que los datos cifrados sean inaccesibles de forma permanente.

Migración a CipherTrust Manager

Thales anunció que Vormetric DSM llegó al final de su ciclo de vida en junio de 2024. Como resultado, las organizaciones están migrando sus DSM a CipherTrust Manager . La migración de DSM a CTM presenta un desafío diferente: CTM es un producto distinto, no solo una actualización de DSM, y la migración requiere la creación de nuevos procedimientos operativos desde cero, además de la migración técnica de claves, políticas y configuraciones.

Entre las preocupaciones más comunes que tienen las organizaciones al planificar una migración a CTM se incluyen:

• Migración de políticas, claves, conjuntos de usuarios y conjuntos de procesos: qué objetos se conservan y cuáles deben reconstruirse.
• Migración de hosts y reinscripción de agentes a CTM
• Configuración de alta disponibilidad en la arquitectura CTM, que difiere de DSM HA.
• Tiempo de inactividad e interrupción del sistema durante el período de migración.
• Riesgo de pérdida de datos por errores de migración de claves o configuración incorrecta de Guardpoint

Si las organizaciones ya utilizan DSM 6.4.5 o 6.4.6, pueden migrar a CipherTrust Manager y restaurar los siguientes objetos:

1. Claves de agente, incluidas las claves con versiones y las claves de agente accesibles mediante KMIP.
2. Llaves de bóveda
3. Objetos "Trae tus propias llaves" (BYOK)
4. Dominios
5. Configuración del cifrado transparente (CTE) de CipherTrust

Objetos que NO se restauran durante la migración

1. La mayoría de las Gestión de claves Claves del Protocolo de Interoperabilidad (KMIP), excepto las claves de agente accesibles mediante KMIP.
2. Claves asociadas con CipherTrust Cloud Key Manager (CCKM), incluidas las claves de material de clave como servicio (KMaaS).
3. Nombre de host y configuración del host de DSM

La falta de migración de las claves KMIP y CCKM estándar es una de las deficiencias más comunes que se subestiman. Las organizaciones con integraciones basadas en KMIP deben planificar cómo se restablecerán dichas integraciones en CTM antes de iniciar la migración. Al migrar, es fundamental realizar pruebas piloto exhaustivas para garantizar que la migración se lleve a cabo sin pérdida de datos. Los clientes también deben realizar una limpieza del DSM antes de la migración, eliminando todos los servidores dados de baja y los usuarios inactivos, de modo que solo se transfieran a CTM las configuraciones válidas y actuales. Si se migra de DSM a CTM, los agentes que ejecutan agentes VTE anteriores a la versión 7.0 deben actualizarse a CipherTrust Transparent Encryption (CTE) antes de que pueda proceder la migración.

Ventajas de migrar a CipherTrust Manager

1. Interfaz de usuario mejorada basada en navegador que reemplaza la interfaz anterior de DSM.
2. Sin limitaciones de hipervisor: CTM admite la implementación en entornos físicos y virtuales sin las restricciones de hipervisor de DSM.
3. Interfaz CLI remota con todas las funciones para la gestión operativa.
4. Gestor de claves en la nube CipherTrust integrado (CCKM) para la gestión unificada de claves en la nube en AWS, Azure, GCP y otros proveedores de servicios en la nube.
5. Mejores capacidades de gestión de claves con material de claves KMIP: integra políticas, registro y gestión en una experiencia KMIP simplificada y más completa.
6. Admite agentes CTE (anteriormente llamados agentes VTE) a partir de la versión 7.0, lo que proporciona una ruta clara para la gestión de hosts cifrados.
7. Nueva API REST para automatización, que permite la integración con cadenas de herramientas DevOps y plataformas de orquestación de seguridad.

Más allá de estas mejoras en toda la plataforma, CTM también ofrece capacidades especializadas que vale la pena considerar:

1. Contraseña y autenticación PED: Al igual que en el HSM Luna de la serie S, Thales ofrece la opción de contraseña y dispositivo de entrada de PIN (PED) como mecanismos de autenticación para CTM. La autenticación mediante PED proporciona mayor seguridad, pero solo está disponible para dispositivos físicos k570.
2. Implementación multinube e híbrida: CTM admite la implementación en entornos multinube, incluidos AWS, Azure, GCP, VMware, Hyper-V y Oracle VM. Las organizaciones también pueden formar clústeres híbridos que combinan dispositivos físicos y virtuales para entornos de alta disponibilidad, lo que proporciona una flexibilidad de implementación que DSM no ofrecía.

Actualización de DSM frente a migración de CTM: Tabla de decisiones

Escenario	Acción sugerida	Requisito clave	Riesgo primario
DSM inferior a 6.4.5 y aún no hay planes de migración de CTM.	Actualice DSM a la versión 6.4.5 o 6.4.6 utilizando la ruta de actualización obligatoria de Thales.	Inventario completo de agentes y puntos de control; matriz de compatibilidad	Incompatibilidad del agente; interrupción del punto de control durante la actualización.
DSM en la versión 6.4.5 o 6.4.6 y planificación de la migración de CTM	Ejecutar una prueba piloto exhaustiva de CTM en un entorno que no sea de producción antes de la migración a producción.	Actualizar todos los agentes VTE inferiores a la versión 7.0 a CTE; limpieza de DSM previa a la migración.	Las claves KMIP que no se migran provocan que las integraciones se rompan después de la migración.
DSM con importantes integraciones de KMIP	Mapee todas las integraciones de KMIP antes de la migración; planifique el restablecimiento en CTM.	Identifique todas las claves KMIP que no migrarán y planifique su reinscripción.	Las aplicaciones que dependen de KMIP pierden el acceso a las claves después de la migración.
DSM en configuración de alta disponibilidad en diferentes subredes	Contrate a Encryption Consulting para la planificación de migraciones específicas de la arquitectura.	Documente todos los detalles de configuración de la red HA; planifique el enrutamiento de subredes.	Una configuración incorrecta del clúster HA provoca un fallo de sincronización o de división de clúster.
DSM ya ha superado el final de su ciclo de vida y no existe un plan de migración.	Comience a planificar la migración de inmediato; priorice en función de la criticidad de los datos.	Acceso al soporte y la documentación de Thales; verificación de la ruta de actualización.	Versión de DSM no compatible que genera riesgos de cumplimiento y seguridad.

Lista de verificación previa a la migración

• Documente todos los agentes DSM, las versiones de los agentes y los puntos de protección; cree un inventario completo de agentes antes de que comience cualquier actividad de actualización o migración.
• Desarrolle una matriz de compatibilidad que confirme qué agentes son compatibles con la versión DSM o CTM de destino.
• Verifique la ruta de actualización obligatoria de DSM e identifique todas las versiones intermedias necesarias para alcanzar la versión de destino.
• Confirme que la versión de DSM sea 6.4.5 o 6.4.6 antes de comenzar la migración de CTM; actualice primero DSM si está en una versión anterior.
• Actualice todos los agentes VTE anteriores a la versión 7.0 a agentes de CipherTrust Transparent Encryption (CTE) antes de la migración a CTM.
• Realice una sesión de limpieza de DSM: elimine todos los servidores dados de baja, los usuarios inactivos, las políticas obsoletas y los objetos no utilizados antes de la migración.
• Identificar todas las claves KMIP y CCKM en DSM que no se migrarán a CTM; planificar el restablecimiento de esas integraciones en CTM.
• Configure una instancia de CTM que no sea de producción y ejecute una migración piloto exhaustiva antes de modificar el DSM de producción.
• Valide todos los puntos de control y la accesibilidad de las claves en el entorno piloto de CTM antes de programar la migración a producción.
• Planifique el momento de la transición a la producción con ventanas de mantenimiento definidas y notifique a todas las partes interesadas del negocio sobre el impacto previsto en el servicio.
• Documente todos los nuevos manuales de operaciones de CTM, procedimientos operativos estándar y documentación de arquitectura antes de la puesta en marcha en producción.
• Planifique la configuración de alta disponibilidad de CTM para producción; pruebe la conmutación por error de alta disponibilidad en el entorno que no sea de producción antes de la implementación en producción.

Conclusión

Actualizar DSM puede ser un desafío y requiere una planificación y resolución de problemas exhaustivas. Migrar a CTM presenta un nivel de complejidad diferente, ya que CTM es un producto distinto, no simplemente una actualización de DSM. Las organizaciones que migran deben desarrollar nuevos manuales de operaciones, procedimientos operativos estándar y documentos de arquitectura, además de la migración técnica de claves y configuraciones. Dado que DSM llegará al final de su ciclo de vida en junio de 2024, las organizaciones que aún lo utilizan se enfrentan a un riesgo creciente debido a una plataforma sin soporte y deben priorizar la planificación de la migración de inmediato. Encryption Consulting puede ayudar a los clientes a planificar, actualizar y migrar sus DSM existentes. Como socio certificado de Thales y organización que ha brindado soporte a clientes de Vormetric con implementaciones y actualizaciones durante años, Encryption Consulting puede ayudar a planificar una migración completa a CipherTrust Manager y proporcionar evaluaciones de brechas y planificación previa para garantizar que los clientes no sufran pérdida de datos, tiempo de inactividad o problemas de producción. Contáctenos para obtener más información en [email protected ]

Fuentes:

• Portal de documentación de la plataforma CipherTrust: Migración de DSM (thalesdocs.com)
• Portal de documentación de la plataforma CipherTrust: Migración de CTE-DSM (thalesdocs.com)

Preguntas frecuentes

¿Qué es Vormetric Data Security Manager (DSM) y qué es CipherTrust Manager (CTM)?

Vormetric Data Security Manager (DSM) es el dispositivo de gestión de claves y políticas de Thales que administra claves de cifrado, políticas, conjuntos de usuarios, conjuntos de procesos y puntos de protección para agentes VTE en hosts protegidos. CipherTrust Manager (CTM) es la plataforma de gestión de seguridad de datos de próxima generación de Thales que reemplaza a DSM, con una interfaz de usuario moderna basada en navegador, sin limitaciones de hipervisor, CCKM integrado para la gestión de claves en la nube, capacidades KMIP mejoradas, compatibilidad con agentes CTE a partir de la versión 7.0 y una API REST para la automatización. Thales anunció que DSM llegó al final de su ciclo de vida en junio de 2024.

¿Qué objetos migran de DSM a CipherTrust Manager y cuáles no?

Los objetos que migran de DSM 6.4.5 o 6.4.6 a CTM incluyen: claves de agente (incluidas las claves con versiones y las claves de agente accesibles mediante KMIP), claves de bóveda, objetos BYOK, dominios y configuración de CTE. Los objetos que no migran incluyen: la mayoría de las claves KMIP, excepto las claves de agente accesibles mediante KMIP, las claves CCKM y KMaaS, y el nombre de host y la configuración de host de DSM. La no migración de las claves KMIP estándar es una de las deficiencias más subestimadas en la planificación de la migración.

¿Qué versión de DSM debe tener instalada una organización antes de migrar a CipherTrust Manager?

Las organizaciones deben tener instalada la versión 6.4.5 o 6.4.6 de DSM antes de migrar a CTM. Si utilizan una versión anterior, primero deben actualizar DSM a la versión 6.4.5 o 6.4.6 mediante la ruta de actualización obligatoria de Thales. Además, todos los agentes VTE anteriores a la versión 7.0 deben actualizarse a agentes CTE antes de que pueda procederse con la migración a CTM.

¿Cuáles son los mayores riesgos en una actualización de DSM o una migración de CTM?

Los mayores riesgos son: pérdida de datos por errores en la migración de puntos de control o claves que hacen que los datos cifrados sean permanentemente inaccesibles; tiempo de inactividad de la producción por una planificación deficiente del momento de la transición; incompatibilidad del agente con la versión de DSM o CTM de destino; y deficiencias de configuración en las integraciones de KMIP que dañan las aplicaciones dependientes después de la migración. Estos riesgos se mitigan mediante un inventario completo previo a la actualización, el desarrollo de una matriz de compatibilidad, la puesta en escena paralela para las pruebas de actualización, la limpieza de DSM previa a la migración y pruebas piloto exhaustivas antes de cualquier transición a producción.

¿Es posible realizar una actualización de DSM o una migración de CTM sin tiempo de inactividad?

La migración a DSM se puede realizar sin tiempo de inactividad de producción mediante un enfoque de actualización paralela, donde se inicia una nueva versión de DSM y se migran los agentes sin interrupciones. La migración de DSM a CTM implica un producto y una arquitectura diferentes y, por lo general, requiere ventanas de mantenimiento planificadas para operaciones de migración específicas. La duración del tiempo de inactividad depende de la complejidad del entorno, la cantidad de agentes y si la migración se puede realizar por etapas.