Después de varios años entrando a entornos productivos para diagnosticar, migrar o documentar operaciones de HSM en instituciones financieras peruanas y de la región, se repite la misma lista de errores. Ninguno es nuevo. Ninguno es exclusivo de una marca. Y todos son prevenibles —si alguien tiene el tiempo y la disciplina de mirarlos.
Aquí los ocho que más cuestan, en el orden en que típicamente los descubrimos.
1. El esquema de llaves no está documentado
La primera pregunta cuando entramos a un HSM productivo es: “¿Me puedes mostrar la jerarquía de llaves?” Lo esperable es un diagrama con la ZMK, las ZPKs derivadas, las PVKs, las llaves MAC, los tiempos de vida y las dependencias.
Lo que típicamente vemos: una página en blanco. O un PDF de 2019 que ya no refleja la realidad. O alguien dice “Pedro sabe, pero está de vacaciones.”
Si Pedro está de vacaciones cuando el regulador pregunta, el problema lo tiene la institución, no Pedro.
2. Las ceremonias se ejecutaron pero no se documentaron
Ceremonia ejecutada + sin acta firmada = ceremonia que no ocurrió, desde el punto de vista de auditoría. Es una de las brechas más fáciles de cerrar y de las más comunes.
El estándar mínimo: guion previo a la ceremonia, dos roles independientes con identificación, acta firmada con timestamp y resumen de lo ejecutado, archivo bajo custodia bipartita. Si ya pasaron meses sin esto, no se puede reconstruir hacia atrás —pero sí se puede establecer la disciplina para todas las futuras.
3. El control dual existe en el papel, no en la práctica
Política dice: dos personas para activar la CA, dos personas para cargar llaves, dos personas para acceder al cuarto del HSM. Realidad: una sola persona tiene las dos smart cards, ambos PINs, y opera todo solo “para ir más rápido.”
Esto se cura solo con voluntad institucional. Tecnología no lo arregla. Si no hay dos personas competentes en la institución, el problema es de capital humano, no de criptografía.
4. El HSM productivo se usa para desarrollo
Vemos esto con frecuencia: el equipo de desarrollo no quiere esperar a que provisionen un HSM separado, así que apuntan al productivo “solo para probar.” Llaves de prueba conviven con llaves productivas. Una vez visto, no se puede dejar de ver.
La solución es invertir en un simulador (Atalla, Utimaco y otros lo tienen) o aceptar el costo de un HSM de desarrollo dedicado. Es siempre más barato que el incidente que esto previene.
5. Las renovaciones se hacen reactivamente
“Ah, el certificado de OCSP venció anoche. Estoy renovándolo ahora.” Si la primera señal de que algo va a expirar es que ya expiró, hay un proceso de monitoreo de vencimientos que no existe.
Mínimo razonable: alertas a 90, 60, 30 y 7 días antes de cada vencimiento. Idealmente integrado con el sistema de tickets del equipo de seguridad. Una hoja de Excel con fechas tampoco resuelve.
6. No hay runbook para los incidentes frecuentes
“¿Qué hacemos si una smart card se rompe?” “Nunca pasó.” “¿Qué hacemos si el HSM secundario no responde?” “Llamamos al fabricante.” “¿Qué hacemos si necesitamos rotar la ZMK de emergencia?” “Hmm.”
Cada uno de estos escenarios debe tener un runbook documentado, con quién decide, qué pasos se ejecutan, qué se loguea, cuándo se notifica al directorio. Lo barato es escribirlo ahora. Lo caro es improvisarlo durante un incidente real.
7. Los desarrolladores no tienen guía de cómo invocar al HSM
El equipo de seguridad opera el HSM. El equipo de desarrollo lo consume. Casi nunca hay un documento puente que diga: “así se llama tal método, así se interpreta tal código de error, así se reintenta cuando hay timeout.”
El resultado: cada nueva integración reabre la misma discusión, los mismos errores se reintroducen, y el equipo de seguridad termina haciendo soporte a desarrolladores en lugar de gobernar la plataforma. Una guía de desarrollador escrita una vez evita meses-persona acumulados de fricción.
8. La migración legacy nunca se programó
El HSM tiene cinco años. El fabricante anunció fin de soporte en 18 meses. Nadie ha empezado a planificar el reemplazo porque “hay tiempo.”
No hay tiempo. Una migración de HSM con continuidad de servicio toma típicamente 6-9 meses de planificación y ejecución: re-key controlado, validación en paralelo, ventanas de corte negociadas, contingencias documentadas. Llegar al fin-de-vida sin plan obliga a hacerlo apurado, y “apurado” es exactamente la palabra que no quieres asociar con tu HSM.
Cómo verse profesional desde el primer día
Si tu institución acaba de comprar (o piensa comprar) un HSM, antes de encenderlo:
- Define el esquema de llaves en papel
- Escribe el guion de la ceremonia de instalación
- Acuerda quiénes son los dos custodios y obtén firmas de aceptación
- Define las métricas de monitoreo desde el día cero
- Programa la primera revisión a los 90 días
No son tareas glamorosas. Son las que separan una operación profesional de una caja fuerte abandonada.
En 2PSECURE instalamos, configuramos y entregamos HSMs end-to-end con esquema de llaves, ceremonias documentadas, runbooks y guías para desarrolladores. Como representantes oficiales en Perú de Utimaco y HST, también ejecutamos migraciones desde equipos legacy con continuidad de servicio. Si tu HSM está en alguno de los ocho escenarios de arriba, conversemos sobre tu caso.
¿Te resultó útil? Compártelo: