La escena se repite en empresas de todos los tamaños: el ERP firma comprobantes con una librería, el sistema de recursos humanos usa una herramienta de escritorio, un script del área de operaciones firma actas con el certificado copiado en una carpeta compartida y nadie tiene la lista completa de dónde está el archivo .p12. Cada área resolvió su problema y la empresa terminó con cuatro implementaciones distintas, cuatro copias del certificado y ninguna trazabilidad común.
Un servicio de firma interno resuelve eso: un único componente que expone la capacidad de firmar al resto de la organización, con una sola custodia de credenciales, un solo registro de auditoría y una sola integración con el proveedor. Este artículo describe sus piezas, las decisiones de diseño que hay que tomar y los errores que se pagan caro.
Cuándo conviene construirlo
No toda empresa lo necesita. La señal de que ya hace falta suele ser alguna de estas:
- Más de dos sistemas necesitan firmar documentos.
- El certificado está copiado en más de un servidor o estación.
- Los volúmenes obligan a firmar por lotes y no de a un documento.
- Auditoría o el área legal piden evidencia consolidada de quién firmó qué.
- La empresa tiene varios firmantes con distintos certificados y hay que decidir cuál usa cada proceso.
Con un solo sistema y un solo firmante, la integración directa descrita en cómo integrar una API de firma electrónica suele ser suficiente. El servicio interno aparece cuando el problema deja de ser técnico y pasa a ser de gobierno.
Los componentes
Un servicio de firma razonable se compone de seis piezas, que pueden desplegarse juntas al inicio y separarse después:
| Componente | Responsabilidad |
|---|---|
| Fachada de entrada | Autenticar al sistema solicitante, autorizar la operación y validar la petición |
| Orquestador | Resolver qué certificado corresponde, encolar, controlar reintentos y estados |
| Motor de firma | Ejecutar la operación criptográfica con el formato requerido |
| Custodia de credenciales | Guardar o delegar el acceso a la clave privada |
| Repositorio documental | Almacenar el documento firmado y su evidencia asociada |
| Auditoría | Registrar cada evento de forma inalterable |
La separación entre orquestador y motor de firma parece innecesaria al principio y se agradece después: permite cambiar de proveedor o de modelo de custodia sin tocar a los sistemas que consumen el servicio.
Dónde vive la clave privada
Es la decisión estructural del diseño y condiciona todo lo demás. Hay tres modelos:
- Archivo .p12 en el servidor. Simple y barato. El servicio carga el archivo y firma localmente. Contrapartida: el secreto es exportable, hay que custodiarlo con cuidado y la escalabilidad horizontal obliga a replicarlo.
- Token USB conectado a una máquina. Funciona para volúmenes bajos, pero ata el servicio a un equipo físico. Es el modelo que peor tolera la nube y la alta disponibilidad.
- Firma en la nube o módulo de seguridad de hardware. La clave nunca sale del servicio; el motor envía el resumen del documento y recibe la firma. Es lo que mejor se comporta en despliegues distribuidos y lo que más limpio deja el manejo de secretos.
La comparación completa está en firma en la nube frente a archivo .p12 y token, y las garantías del tercer modelo en HSM y firma electrónica de alta seguridad. Sea cual sea la elección, la custodia de las credenciales debe diseñarse con los criterios de manejo de secretos y rotación de claves.
Síncrono o asíncrono
La mayoría de los equipos empieza con una llamada que devuelve el documento firmado y descubre el problema con el primer lote grande o con la primera caída del proveedor. El diseño recomendado combina ambos modos:
- Síncrono para operaciones interactivas, cuando un usuario espera el resultado en pantalla y el documento es uno solo.
- Asíncrono para todo lo demás: se recibe la solicitud, se responde con un identificador y se procesa en una cola. El resultado se comunica con una notificación automática o consultando el estado.
El modo asíncrono es el que sostiene los picos, absorbe la indisponibilidad temporal del proveedor y permite reintentar sin que el sistema de origen tenga que saber nada de eso.
Idempotencia y reintentos: la parte que siempre se subestima
Un servicio de firma sin idempotencia genera documentos duplicados. El escenario es siempre el mismo: la petición llega, el motor firma, la respuesta se pierde por un tiempo de espera agotado, el cliente reintenta y el documento se firma dos veces. En facturación electrónica eso puede significar dos comprobantes distintos para la misma venta.
La solución conocida es que cada solicitud lleve una clave de idempotencia definida por el sistema de origen, que el servicio la registre antes de firmar y que devuelva el resultado ya calculado si la clave se repite. Junto con eso conviene definir una política explícita de reintentos con espera creciente y un límite, más una cola de mensajes no procesados para lo que agota los intentos. Un lote de mil documentos que reintenta sin control es una excelente forma de saturar al proveedor y quedarse sin servicio.
Formatos, sellado de tiempo y validación
El formato de la firma no es un detalle: define si el archivo se puede validar en el futuro y si lo aceptan los sistemas que lo reciben. Existen formatos avanzados para PDF, para XML y para archivos genéricos, con distintos niveles de información incorporada. Cuál corresponde depende del destinatario: los portales del Estado, el SRI y las contrapartes privadas tienen requisitos propios, y hay que confirmarlos en la documentación oficial de cada uno antes de fijar la implementación.
Dos recomendaciones que se sostienen en cualquier escenario. Primera: incorporar sellado de tiempo siempre que sea posible, porque acredita el momento de la firma y hace que el documento siga siendo verificable cuando el certificado ya venció. Segunda: validar lo que se firmó, dentro del propio servicio, antes de darlo por bueno. El detalle de esa verificación está en cómo validar firmas electrónicas de forma programática.
Escala: firma masiva sin tumbar nada
Cuando el volumen crece, tres controles marcan la diferencia:
- Límite de concurrencia hacia el proveedor. Definido según lo que el proveedor soporte, no según lo que tu infraestructura aguante.
- Colas por prioridad. Que un lote de cierre mensual no bloquee la firma de un contrato que alguien está esperando en pantalla.
- Procesamiento por lotes con estado por documento. Que el fallo de uno no invalide los novecientos noventa y nueve restantes.
Los patrones aplicados a grandes volúmenes están en firma electrónica masiva en la nube.
Construir o integrar
La pregunta correcta no es si desarrollar todo desde cero, sino qué capa desarrollar. Lo que aporta valor propio es la fachada, la resolución de qué certificado usa cada proceso, la auditoría y la integración con los sistemas internos. Lo que casi nunca conviene reimplementar es el motor criptográfico y el manejo de formatos avanzados: ahí es donde un componente ya probado ahorra meses y evita errores sutiles que solo aparecen en validación. El punto de partida habitual está en qué es un SDK de firma electrónica y cómo se usa.
Para dimensionar cuántos certificados corporativos necesita el servicio —uno por firmante, más los de ambientes de prueba— revisa la página de precios o pide una cotización corporativa.
Si el servicio va a firmar comprobantes electrónicos, considera que esa parte ya está resuelta: el grupo desarrolla Azur, un sistema de facturación electrónica autorizado por el SRI que trabaja con el certificado de la compañía. Crear la cuenta en azur.com.ec/registro suele ser más rápido que construir el módulo fiscal dentro del servicio de firma.
Observabilidad desde el primer día
Un servicio de firma que no registra es una caja negra en el peor lugar posible: el punto donde la empresa compromete su identidad jurídica. Los campos mínimos de cada evento, la protección del registro y el armado del expediente probatorio están en logs y trazabilidad de cada firma. Diseñar la auditoría al final es rehacer el servicio.
Una bandeja para lo que falla
El grupo también desarrolla Omnifox, una plataforma omnicanal que reúne WhatsApp, correo, redes sociales y llamadas en una sola bandeja compartida. En la operación de un servicio de firma sirve para lo que ninguna alerta técnica resuelve: cuando un lote falla y hay que avisar al área contable, al proveedor y al responsable del certificado, todo el hilo queda en un solo lugar, asignado y con estado. Más información en omnifox.io.
Preguntas frecuentes
¿Un servicio de firma interno necesita un certificado propio?
Necesita acceso a los certificados de los firmantes autorizados, que son personas: representante legal, gerentes o apoderados según el documento. El servicio no firma "por sí mismo": firma en nombre de un titular, y por eso la resolución de qué certificado corresponde a cada proceso es una de sus funciones centrales.
¿Conviene exponerlo a toda la organización o solo a algunos sistemas?
Solo a sistemas registrados, cada uno con su propia identidad y con permisos acotados a los tipos de documento que le corresponden. Un servicio abierto a cualquier consumidor interno pierde la trazabilidad que justificaba construirlo.
¿Qué pasa si el proveedor de firma no está disponible?
Con diseño asíncrono, las solicitudes se acumulan en la cola y se procesan cuando el servicio vuelve, sin pérdida. Con diseño solo síncrono, cada llamada falla y el problema se traslada a cada sistema de origen. Esa es la razón principal para no quedarse solo con el modo síncrono.
¿Se puede desplegar en la nube si el certificado está en un token USB?
Es la peor combinación posible: el token exige presencia física en un equipo determinado. Si el destino es un despliegue distribuido, lo razonable es migrar a archivo .p12 con custodia adecuada o, mejor, a firma en la nube.
¿Cuánto tiempo toma implementar un servicio así?
Depende del alcance y de cuántos sistemas se integren, así que no conviene tomar una estimación de un artículo. Lo que sí es constante es el orden: primero un sistema y un tipo de documento en producción, después los demás. Los proyectos que arrancan integrando todo a la vez son los que no llegan.
Si tu empresa está diseñando un servicio de firma interno y necesita certificados corporativos para producción y pruebas, conversa con un asesor de Firmas.com.ec. Solicita tu cotización corporativa.