¿Cómo se gestiona con seguridad una cola masiva de firmas electrónicas?

¿Cómo mantener segura la cola de firma electrónica por lotes?

Fije cada trabajo de firma con el resumen del documento, la versión, el firmante y una clave única de operación; valide la autoridad en el momento de consumir, unifique las repeticiones y considere exitosa solo la salida verificada.

Cuando aumenta la carga, el objetivo no es solo acelerar la cola. Se necesita una máquina de estados que evite firmar dos veces el mismo documento, que un PDF modificado avance con una aprobación antigua, que un fallo transitorio del servicio parezca éxito permanente y que la prueba de firma se desvincule del registro del trabajo.

¿Con qué identidad debe entrar a la cola el trabajo de firma?

La identidad del trabajo debe basarse no solo en el nombre del archivo, sino en la identidad del documento, la versión inmutable, el resumen criptográfico, la identidad del firmante, la política de firma y el tipo de operación prevista.

La página vigente de la BTK que explica el marco de la Ley n.º 5070 indica que la firma electrónica segura permite detectar cambios posteriores en los datos firmados. El contenido técnico de preguntas frecuentes de la BTK también explica los límites de que el titular de la firma pueda ver los datos antes de firmar y de que los datos de creación de firma no salgan de la herramienta. La consecuencia para el diseño de la cola es clara: si el PDF se regenera después de que el usuario aprobó una versión, el mismo trabajo no debe continuar; debe abrirse una nueva aprobación con el nuevo resumen. [1] [2]

¿Qué estados deben distinguirse en la cola?

La tríada “pendiente, exitoso, fallido” es insuficiente; aceptación, precontrol, aprobación humana, firma, validación, archivo y revisión deben ser estados separados.

1. Aceptado: El documento de origen, la versión, el resumen y la clave de idempotencia se registran de forma atómica.
2. Precontrol: Se comprueban el acceso al documento, el formato, la titularidad, el rol del firmante, la selección de certificado y la conformidad con la política.
3. Pendiente de aprobación: El titular de la firma ve la versión correcta del documento que va a firmar y da su aprobación para la operación concreta.
4. Firmando: El worker toma la tarea con un bloqueo breve; aunque expire el bloqueo, el registro de idempotencia evita el segundo efecto secundario.
5. Validando: La firma generada se valida técnicamente sobre el documento firmado y el contexto del certificado.
6. Archivado: La salida firmada, el resultado de la validación, la prueba de sello de tiempo y la pista de operaciones se guardan en el mismo enlace de registro.
7. Requiere revisión: Una validación ambigua, un error permanente o una contradicción se asignan a una persona autorizada sin convertirse en éxito automático.

La guía de autorización de transacciones de OWASP recomienda conservar en el servidor los datos significativos de la transacción, ejecutar los pasos en orden y mantener un enlace de autorización único para cada operación. Esto significa que el consumidor de la cola no debe confiar en un campo “aprobado” proveniente del navegador; debe revalidar el resumen del documento, la autoridad y la transición de estado desde el registro del servidor. [5]

¿Cómo reintentar sin producir firmas duplicadas?

Reintente de forma limitada y demorada solo los errores transitorios; vincule cada intento a la misma clave de idempotencia y registre el resultado externo de la firma de forma atómica.

La guía OWASP Business Logic Security recomienda almacenar transaccionalmente la clave de idempotencia junto con el resultado para las llamadas externas que cambian estado. Si la conexión de red se corta después de que el worker envía la petición al servicio de firma, asumir “no hubo respuesta, no hubo operación” es peligroso. Primero debe consultarse si existe un resultado registrado con la misma clave de trabajo o un identificador de transacción del proveedor; solo si se demuestra que la operación no se produjo debe reenviarse. [4]

Clasifique los errores: un corte breve de conexión y la saturación transitoria declarada explícitamente por el servicio pueden reintentarse; el usuario no autorizado, el resumen del documento modificado, la selección de certificado inválida o el fallo de validación no deben repetirse automáticamente. Los reintentos demorados pueden usar espera creciente y dispersión aleatoria; pero el número de intentos y el tiempo total deben fijarse según el objetivo de servicio y la evaluación de riesgos de la organización, sin proclamar cifras universales sin fundamento.

¿Cuándo se considera realmente exitoso un trabajo?

Que se genere el archivo firmado no es por sí solo un éxito; deben registrarse juntos el valor de la firma, el enlace con el documento, el certificado de firma, la política de validación y, si procede, el resultado del sello de tiempo.

ETSI EN 319 102-1 V1.4.1 define las entradas y los resultados de los procesos de creación y validación de AdES; muestra que, en la validación, los estados exitoso, fallido e indeterminado no son lo mismo. En el flujo de VizyonTech, el worker no debe cerrar el trabajo solo porque se escribió el archivo; debe conservar la regla de validación aplicada y su resultado, y trasladar los resultados fallidos o indeterminados a la cola de revisión. [3]

RFC 3161 define el sello de tiempo como un protocolo de petición-respuesta que proporciona prueba de que unos datos existieron antes de un momento determinado. Por eso, si se requiere sello de tiempo, no debe guardarse solo un registro de “solicitado”; el message imprint, el estado de la respuesta, el token devuelto y el resultado de la validación deben vincularse al mismo trabajo de firma. Un nonce o un resumen del documento que no coincidan, una respuesta retrasada o una petición rechazada no deben contarse como éxito. [6]

La necesidad de validación a largo plazo depende del formato, la política y el plazo de conservación. En lugar de asumir el mismo perfil de archivo para cada firma, deben aplicarse el procedimiento de la organización y los criterios técnicos vigentes como una política versionada.

¿Cómo debe proteger el sistema ante la saturación al titular de la firma?

Cuando la tasa de aceptación supere la capacidad de firma, no acumule trabajo sin límite; aplique cuotas por cliente/organización, prioridades, backpressure y métricas visibles de envejecimiento.

• Capacidad equitativa: Un paquete grande de un único cliente no debe retener indefinidamente el trabajo de otras organizaciones; los límites por tenant y prioridad deben ser explícitos.
• Backpressure: Cuando la cola alcance el umbral operativo definido, debe ralentizarse la aceptación de paquetes nuevos o programarse para un momento planificado.
• Visibilidad de la duración de los trabajos: El promedio por sí solo no basta; deben monitorearse por separado el trabajo pendiente más antiguo, la edad por estado, el número de reintentos y la cola de revisión.
• Bloqueo breve, registro permanente: El bloqueo del worker es temporal; la identidad del trabajo, el historial de intentos y el resultado deben ser permanentes.
• Observación segura: Los registros no deben contener contenido de documentos, datos de acceso, PIN, claves privadas ni datos personales innecesarios.
• Cancelación controlada: Un trabajo aún no firmado puede cancelarse; si ya se generó la firma, la salida no se elimina y la decisión sobre el estado y la distribución pasa a revisión autorizada.

¿Qué escenarios deben probarse antes de pasar a producción?

Ejecute con evidencia no solo el flujo exitoso, sino también los escenarios de caída del worker, timeout, entrega duplicada, cambio de documento, pérdida de autoridad y validación indeterminada.

• ¿Cuando la misma clave de idempotencia llega con dos peticiones simultáneas se genera una única salida firmada?
• Si la llamada de firma se completa pero se pierde la respuesta, ¿el reintento encuentra el resultado registrado?
• Si el documento cambia tras la aprobación, ¿la comprobación del resumen detiene el trabajo y pide una nueva aprobación?
• Si el rol o el estado del certificado del firmante cambian durante la espera, ¿el consumidor lo reevalúa?
• Cuando el resultado de la validación es indeterminado, ¿el sistema no envía notificación de entrega exitosa?
• ¿El trabajo en la cola de errores puede reiniciarse por una persona autorizada conservando el motivo y los intentos previos?
• ¿El registro de archivo puede mostrar, bajo la misma versión, la salida firmada, el resultado de la validación, el sello de tiempo y la pista de operaciones?

¿Cómo aborda VizyonTech este flujo?

VizyonTech configura los pasos, desde la generación del informe hasta la aprobación humana, y desde la cola de firma electrónica hasta la validación y el archivo, junto con los roles, las versiones de documento y las reglas de excepción de la organización.

En el diseño de firma masiva extraemos primero los tipos reales de documento, los roles de firmante, la política de certificados y sellos de tiempo, los escenarios de interrupción del servicio y los canales de entrega. Luego validamos, en un flujo piloto de documentos, la identidad única del trabajo, las transiciones de estado permitidas, el comportamiento ante repeticiones, la cola de revisión y las medidas operativas visibles.

Cómo corregir posteriormente un informe firmado en la guía de revisión de informes firmados electrónicamente; cómo comprobará el usuario final la salida vigente lo abordamos en la guía de la página de validación del informe . Para planificar un piloto seguro con el volumen de documentos y los escenarios de error de su organización, ponerse en contacto con VizyonTech.