Menú

Contactar
Logo
Prensa

Operación de HSM

Operación de HSM que prevé los fallos.

Las claves protegidas deben seguir siendo utilizables también en caso de actualizaciones, fallos de dispositivo y cambios de personal. Asumimos las tareas de operación acordadas para su entorno de HSM y preparamos el mantenimiento, la recuperación y el cambio de generación con procedimientos documentados.

Especialistas revisando equipos en un centro de datos, imagen simbólica
Manual de operación con vías de escalado · Planificación e implementación a cargo de OTOKO®

Su encargo a OTOKO®

Lo que hacemos por usted.

Un HSM accesible puede resultar de todos modos inutilizable para una aplicación: las sesiones están ocupadas, faltan permisos o la conexión de red supera el tiempo límite. Combinamos los valores del dispositivo con pruebas de aplicación seleccionadas y un sistema de alertas controlado. Los registros deben permitir trazar los procesos administrativos sin recoger secretos. Para cada alarma se define quién la atiende, en qué horarios y qué intervenciones están permitidas.

El posible alcance del servicio

  • Levantar el inventario, las responsabilidades y las dependencias
  • Configurar la monitorización y los canales de alerta
  • Probar y planificar los cambios de firmware y de cliente
  • Probar la recuperación y la caída de un emplazamiento
  • Acompañar la sustitución de dispositivos y la retirada segura del servicio

Antes de comenzar, definimos el alcance concreto, su participación y los criterios de aceptación.

Tecnología explicada con claridad

Así llevamos a cabo la tarea.

01

Probar de forma conjunta las actualizaciones y las copias de seguridad

El firmware, la biblioteca de cliente y la aplicación forman una cadena de operación conjunta. Los cambios se comprueban primero en un entorno de pruebas adecuado; las indicaciones del fabricante y el modo de certificación exigido se tienen en cuenta en la aprobación. En el caso de las copias de seguridad, no basta con que exista un archivo. Deben estar disponibles los medios de acceso necesarios, los custodios, los dispositivos compatibles y los procedimientos de recuperación. Probamos el restablecimiento acordado y documentamos los límites, por ejemplo cuando determinadas claves no pueden replicarse o exportarse.

02

Hacer planificables la migración y la baja del servicio

Un cambio de generación comienza con el inventario, la comprobación de compatibilidad y la asignación de claves. La conmutación y la vuelta atrás se planifican por aplicación. Solo tras confirmarse la transferencia se realiza la retirada de servicio aprobada, con la destrucción de claves correspondiente y su evidencia. El traspaso también incluye los cambios de personal: la revocación de permisos y la sustitución de los medios de acceso deben funcionar sin que la organización dependa de una sola persona.

03

La alta disponibilidad no es por sí sola un plan de recuperación

Un clúster puede absorber el fallo de un dispositivo y, aun así, tener la misma configuración incorrecta en varios nodos. Por eso, las copias de seguridad, los medios de acceso y los procedimientos de restablecimiento deben considerarse de forma independiente. OTOKO® planifica con su equipo qué fallos deben quedar cubiertos y con qué rapidez debe recuperarse una aplicación utilizable. La prueba no termina con la importación correcta de una copia de seguridad: también debe poder ejecutarse de nuevo una operación representativa de firma o descifrado.

04

Conectar la monitorización, el mantenimiento y el escalado

La operación necesita señales visibles y una persona autorizada a reaccionar ante ellas. Asignamos las alarmas de dispositivo, los inicios de sesión fallidos y las pruebas de aplicación a medidas concretas. Los cambios en el firmware, el cliente y los permisos se aprueban de forma trazable. Para el soporte acordado se definen los horarios de servicio, la disponibilidad y el traspaso al fabricante u otros socios de operación. Que una aplicación funcione las veinticuatro horas no implica automáticamente que exista un contrato de soporte 24/7.

05

Ejemplo: gestionar el fin de vida útil sin pérdida de claves

Una serie de HSM existente se acerca al final de su soporte. OTOKO® inventaria los mecanismos utilizados, las claves exportables y no exportables, así como las dependencias restantes. De ahí resulta un plan de migración con entorno de pruebas, operación paralela y criterios de interrupción claros. Tras la migración se documentan las pruebas de aplicación y la recuperación de copias de seguridad en la plataforma de destino. Solo cuando se cumplen los requisitos técnicos y funcionales se procede a la eliminación controlada y a la retirada de servicio de los dispositivos antiguos.

Sala de reuniones en la oficina de OTOKO® en Colonia

Un resultado verificable

Con este resultado puede seguir trabajando.

  1. Manual de operación con vías de escalado
  2. Plan de mantenimiento y de ciclo de vida
  3. Informes de pruebas de recuperación y migración

El traspaso une la implementación y la documentación. Juntos revisamos los casos acordados y registramos las tareas pendientes.

Antes del primer paso

Sus preguntas sobre Operación de HSM.

¿Constituye ya un segundo HSM un plan de emergencia?

No. Se necesitan claves adecuadas, una conmutación de aplicación que funcione, custodios disponibles y procesos probados. Estos requisitos se comprueban conjuntamente.

¿Incluye la operación automáticamente un servicio las veinticuatro horas?

No. Los horarios de servicio, los procedimientos de respuesta y el alcance de la responsabilidad se definen en la oferta. A partir de ahí derivamos la monitorización y la disponibilidad de guardia.

¿En qué se diferencian el RTO y el RPO en la operación de HSM?

El RTO describe el tiempo previsto hasta la recuperación, y el RPO, la pérdida tolerable desde el último estado guardado. En el caso de las claves también deben tenerse en cuenta los cambios producidos desde la copia de seguridad y los datos que dependen de ellas. Ambos objetivos se comprueban junto con la aplicación.

¿Basta con una copia de seguridad existente como evidencia?

No. Deben estar disponibles el hardware compatible, las autorizaciones necesarias y los medios de acceso. Además, una prueba de recuperación debería demostrar que la aplicación puede ejecutar las operaciones previstas con las claves recuperadas.

¿Cómo acompañan ustedes un cambio de fabricante?

Primero comprobamos las reglas de exportación, los procedimientos de transferencia disponibles y la integración de destino. Para las claves no transferibles pueden ser necesarias claves nuevas y una migración controlada de certificados o datos. No se promete de forma genérica una transferencia directa sin pérdidas.

¿Basta una actualización de firmware para la criptografía poscuántica?

Solo si el hardware, el firmware, la aplicación y las evidencias necesarias encajan entre sí. Que el dispositivo admita un algoritmo no significa todavía que los protocolos, los certificados y las contrapartes puedan utilizarlo. Planificamos la transición como un cambio coordinado de toda la cadena de uso.

Su proyecto

¿Qué tarea desea resolver?

Describa su situación de partida y el resultado que desea. El servicio seleccionado se incluirá en la solicitud de contacto.

Solicitar este servicio

Nuestros socios

  • Microsoft
  • Microsoft Azure
  • Amazon AWS
  • Google Cloud
  • Thales Group
  • Arrow ECS
  • Vodafone
  • IBM
  • Veeam
  • Atlassian
  • JetBrains
  • NinjaOne
  • OPSWAT
  • Utimaco
  • Eviden

Accesibilidad

Adapta la visualización a tus necesidades.

Esta página aún no tiene una versión en lenguaje sencillo.

Actualmente, los ajustes solo se aplican a esta visita. Puedes permitir que se guarden de forma permanente en Configuración de cookies.