CyGard
®
El HSM guarda la llave. CyGard gobierna su uso.
.png)
Criptografía de grado bancario, operada con procedimientos de ofimática
CyGard® es la capa de gobierno que le falta al HSM. Un único artefacto desplegado sobre el Tomcat del cliente, la base de datos corporativa que ya existe y el HSM que ya está instalado: sin licencias por llave, sin hardware adicional y sin proyectos de integración medidos en meses.
Cada llave tiene un estado del estándar NIST, un cryptoperiod que se cumple solo y una matriz de privilegios por aplicación, llave y operación que se impone en la propia API no en un procedimiento que alguien debe recordar.
Cómo funciona
Control demostrable, integración sencilla
CyGard decide si una operación está permitida: matriz de privilegios, estado NIST, rol del solicitante, rastro de auditoría. El custodio ejecuta el cómo: el HSM genera la llave y opera con ella dentro del token. Cambiar de custodio son tres variables de configuración, no una línea de código.
Recorrido de una firma
Barrera 1
Identidad
La clave de aplicación se compara contra su hash. En claro se revela una única vez, al crear la aplicación, y nunca vuelve a exponerse.
Barrera 2
Cupo
Limitación de tasa por clave de aplicación: peticiones por minuto en el plano de datos, por IP en el login.
Barrera 3
Estado
Una llave activa admite la operación; una desactivada no admite firmar; una suspendida no admite nada.
Barrera 4
Concesión
Debe existir la concesión explícita de esa aplicación, sobre esa llave, para esa operación. Sin ella, no hay firma.
Dos planos, dos credenciales
Plano de administración
Usuario y contraseña. Se crean llaves, se conceden privilegios, se transicionan estados y se emiten certificados. La autorización es por rol.
Administrador
Operador
Auditor
Plano de datos
Los microservicios consumidores solo pueden invocar operaciones criptográficas, autorizadas por la matriz de privilegios y por el estado de la llave.
Modo recomendado
La privada reside y opera dentro del HSM
La llave se genera en el token y las seis operaciones, firmar, verificar, cifrar, descifrar, envolver y desenvolver; se ejecutan
ahí dentro, sin que salga jamás.
Es el modo que satisface un requisito estricto de frontera criptográfica y el indicado para llaves de grado CA. La CA se crea dentro del token la primera vez que se usa, persiste entre
reinicios y firma certificados y CRL dentro del hardware.
El material nunca se "carga" en CyGard: se provisiona en el custodio, generándolo in situ o importando llaves existentes mediante envoltura, de modo que la parte privada no viaja en
claro por la red.
Alcance de la versión 1
Lo que queda fuera, por decisión de producto
La versión 1 es completa y operable sin ello. Dos límites conocidos más, coherentes con la topología de nodo único: la limitación de tasa se aplica por nodo, y la CRL en custodia por hardware se persiste en archivo, también por nodo.
Segundo factor en el plano
de administración
v1.1
Hoy: usuario y contraseña sobre JWT, con bloqueo de cuenta y limitación de tasa.
Control dual con quórum N de M
v1.2
Hoy: toda acción administrativa queda en la bitácora sellada, con actor y verificación de integridad
Alta disponibilidad activo-activo
v2
Hoy: nodo único; activo-pasivo es viable con base externa y partición de HSM compartida.
ML-DSA como tipo de llave gobernable
menor
Sujeto al firmware del HSM del cliente; la base ya está lista.
Una caja fuerte excelente, sin control de acceso interno
Privilegio excesivo por diseño
Un microservicio que solo debería verificar firmas recibe, en la práctica, la capacidad de firmar. Comprometerlo equivale a comprometer la CA: entre uno y otra no hay ninguna frontera técnica.
Ciclo de vida sin control efectivo
NIST SP 800-57 define estados y cryptoperiods con precisión, pero sin una herramienta que los imponga
siguen siendo una recomendación escrita. Y como rotar obliga a reconfigurar a todos los consumidores, se rota lo menos posible.
Trazabilidad no defendible
Una bitácora en una tabla plana la modifica cualquiera con acceso de escritura, incluido un atacante que ya está dentro. Sirve para operar el día a día; no sirve para probar nada ante un auditor.
El HSM protege el material, pero no gobierna su uso
Quien tiene el PIN de la partición puede firmar, verificar, cifrar y descifrar con cualquier llave que
viva ahí. De esa asimetría se desprenden tres consecuencias concretas.
Despliegue y operación
Un archivo WAR
Backend y consola en un solo artefacto sobre el Tomcat del cliente. Actualizar es reemplazar y reiniciar, sin tocar configuración, base de datos ni HSM.
La base que ya existe
PostgreSQL, MySQL o MariaDB, SQL Server, SQLite y H2. El motor se detecta por la URL y las migraciones crean el esquema al arrancar.
Cualquier HSM PKCS#11
SoftHSM en desarrollo, Thales Luna en producción, CloudHSM, nShield o Utimaco. Tres variables de configuración.
Asistente de arranque
Prueba la conexión, cifra la contraseña, aplica migraciones y crea el primer administrador, protegido por un token que solo conoce quien opera el servidor.
Consola autoalojada
TLS terminado en el Tomcat con el certificado corporativo, cabeceras estrictas y cero dependencias de recursos externos.
JDK 25 LTS
Integra ML-KEM y ML-DSA, los algoritmos post-cuánticos estandarizados por NIST, verificados por la suite de pruebas del proyecto.
Nueve cosas que cambian de sitio