El archivo .p12 de la compañía terminó en el repositorio. No en el servidor de producción: en el repositorio, con la contraseña escrita en un archivo de configuración de ejemplo, subido hace dos años por alguien que ya no trabaja en la empresa. Es el hallazgo más repetido de cualquier revisión de seguridad sobre un flujo de firma automatizada, y casi siempre aparece cuando ya no hay manera de reconstruir quién clonó ese historial.
Automatizar la firma implica que un proceso sin intervención humana pueda usar la identidad digital de la empresa. Ese es el punto delicado: el certificado deja de estar en un token bajo llave y pasa a ser un secreto que el pipeline necesita leer. Este artículo está escrito para equipos de desarrollo y arquitectura que necesitan custodiar, rotar y auditar esas credenciales sin frenar las entregas.
Inventario: qué secretos existen realmente en un flujo de firma
La mayoría de los equipos piensa que el secreto es uno solo, el certificado. En la práctica son varios, y cada uno tiene un impacto distinto si se filtra:
| Secreto | Dónde suele vivir | Impacto si se filtra |
|---|---|---|
| Archivo de certificado (.p12) | Servidor de firma, imagen de contenedor, artefacto de build | Suplantación de la identidad de la empresa |
| Contraseña del .p12 | Variable de entorno, gestor de secretos | Sin ella el archivo es inútil; con ella, control total |
| Credenciales de API del proveedor de firma en la nube | Gestor de secretos, configuración del servicio | Firma de documentos a nombre de la empresa |
| Secreto compartido de los webhooks | Servicio receptor de notificaciones | Notificaciones falsificadas que disparan procesos |
| Claves de cifrado del repositorio documental | Servicio de almacenamiento | Acceso a documentos firmados y a datos personales |
Un secreto no inventariado es un secreto sin dueño, sin rotación y sin monitoreo. Antes de discutir herramientas conviene tener esta tabla completa, con un responsable por fila.
Dónde no deben estar nunca
La lista de lugares prohibidos es corta y no admite excepciones "temporales", que son las que se vuelven permanentes:
- El repositorio de código. Ni en la rama principal, ni en una rama vieja, ni en el historial. Borrar el archivo en un cambio posterior no elimina el secreto: sigue en el historial y en cada copia que alguien haya hecho.
- Los logs del pipeline. Imprimir variables de entorno para depurar es la fuga más común, y esa salida suele ser visible para más gente de la que se supone.
- Las capas de una imagen de contenedor. Copiar el certificado durante el build y borrarlo después no lo elimina: queda en la capa intermedia.
- Archivos de configuración compartidos por chat o correo. Se reenvían, quedan en tres escritorios y viven para siempre en el historial de la conversación.
- Tickets y capturas de pantalla. El rastro más difícil de limpiar, porque no está en ningún sistema técnico.
Dónde sí: jerarquía de custodia
Ordenadas de menor a mayor garantía, estas son las opciones reales:
- Variables de entorno inyectadas en despliegue. Mejor que un archivo en el repositorio, pero legibles por cualquiera que entre al contenedor. Es el mínimo aceptable, no el objetivo.
- Gestor de secretos. Aporta tres cosas que las variables no dan: acceso por identidad de la carga de trabajo en vez de por valor copiado, versionado del secreto y registro de cada lectura.
- Módulo de seguridad de hardware o firma en la nube. El salto cualitativo: la clave privada nunca sale del dispositivo o del servicio. La aplicación no recibe el certificado; envía el resumen del documento y recibe la firma. Este modelo, descrito en HSM y firma electrónica de alta seguridad, resuelve el problema de raíz porque elimina el secreto exportable.
La decisión entre custodiar un archivo o delegar la operación criptográfica al proveedor tiene consecuencias de arquitectura, no solo de seguridad. La comparación de fondo está en firma en la nube frente a archivo .p12 y token.
Rotación: eventos, no solo calendario
Rotar significa reemplazar un secreto por otro nuevo y dejar el anterior inservible. Hay dos disparadores y conviene tener ambos definidos por escrito.
El primero es el calendario. La periodicidad debe quedar fijada en la política interna de la empresa; no la copies de un artículo, defínela según el riesgo del sistema y verifica con el proveedor qué permite su plataforma. Lo importante es que exista una fecha y un responsable, no el número exacto.
El segundo, más importante, son los eventos que obligan a rotar aunque el calendario diga que falta:
- Salida de una persona que tuvo acceso al secreto, aunque haya sido de forma temporal.
- Sospecha o confirmación de exposición, incluida la aparición del valor en un log o en un repositorio.
- Cambio de proveedor de firma, de infraestructura o del titular del certificado.
- Renovación del certificado por vencimiento de su vigencia.
Para rotar sin cortar la operación, el patrón habitual es la ventana de solapamiento: se crea la credencial nueva, se despliega en paralelo, se verifica que el tráfico ya usa la nueva y recién entonces se revoca la anterior. Que se puedan tener dos credenciales activas a la vez depende del proveedor y del tipo de secreto; confírmalo antes de diseñar el procedimiento.
Separación de ambientes
El certificado de producción no debe existir fuera de producción. Suena obvio y se incumple todo el tiempo con la misma justificación: "necesitamos probar con el real". En desarrollo alcanza con certificados de prueba generados internamente, que permiten validar el armado del documento, el flujo y el manejo de errores. En producción, el acceso al secreto debe llegar solo desde la carga de trabajo, nunca desde una estación de desarrollo. Qué se puede verificar sin un certificado real y qué no está desarrollado en pruebas automatizadas de firma y validación.
Cuentas de servicio, permisos y rendición de cuentas
Tres reglas que evitan la mayoría de los incidentes:
- Una identidad por sistema. Si el ERP, el sistema documental y el proceso de facturación firman, cada uno debe tener su propia credencial. Compartir una sola vuelve imposible saber quién firmó qué y obliga a rotarla en todos lados al mismo tiempo.
- Privilegio mínimo. Quien despliega no necesariamente necesita leer el secreto. Separar el permiso de "usar" del permiso de "ver" es la diferencia entre un incidente contenido y una fuga total.
- Todo acceso deja rastro. Cada lectura del secreto y cada operación de firma debe quedar registrada, con marca de tiempo y con la identidad que la solicitó. Ese registro es el insumo de los logs y la trazabilidad de cada firma, y es lo primero que se pide cuando algo se cuestiona.
El diseño de esos límites es parte del propio servicio de firma. Si todavía estás definiendo componentes, revisa la arquitectura de un servicio de firma interno antes de repartir credenciales entre aplicaciones.
Qué hacer cuando un secreto se expone
El procedimiento debe estar escrito antes de necesitarlo, porque el día que hace falta nadie improvisa bien:
- Contener. Revocar o deshabilitar la credencial expuesta. Si es el certificado, gestionar su revocación con la entidad emisora y emitir uno nuevo.
- Rotar todo lo relacionado. Si la contraseña estaba junto al archivo, ambos se consideran comprometidos, y también cualquier otro secreto que haya viajado por el mismo canal.
- Reconstruir la ventana. Determinar desde cuándo estuvo expuesto y qué se firmó en ese período. Sin logs de firma, este paso es imposible.
- Evaluar el impacto legal. Si en los documentos hay datos personales, aplican las obligaciones de notificación que se explican en las obligaciones de la LOPDP al firmar y almacenar documentos.
- Limpiar el rastro y cerrar la causa. Depurar historial, imágenes y logs conservados, asumiendo que lo expuesto ya fue copiado, y dejar un control concreto que impida la repetición: análisis automático de secretos en cada cambio y bloqueo de subida.
Integrar sin exponer
Cuando el flujo de firma se consume por API, el patrón recomendado es que la credencial viva en un único servicio y que las demás aplicaciones hablen con ese servicio, no con el proveedor: así hay un solo lugar que rotar y uno solo que auditar. Las bases de esa integración están en cómo integrar una API de firma electrónica en tu sistema.
Si el proceso automatizado firma comprobantes electrónicos, el certificado pasa a ser una dependencia directa de la facturación: cualquier error de custodia se traduce en emisión detenida. El grupo también desarrolla Azur, un sistema de facturación electrónica autorizado por el SRI que trabaja con el certificado de la compañía. Puedes crear tu cuenta en azur.com.ec/registro.
Para conocer valores de certificados corporativos según la cantidad de firmantes y ambientes, revisa la página de precios o pide una cotización corporativa.
Coordinar la respuesta cuando algo 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 un incidente de credenciales, el problema no suele ser técnico sino de coordinación: el aviso del proveedor llega a un correo personal, el equipo de seguridad se entera tarde y nadie sabe quién está atendiendo qué. Con una bandeja compartida cada aviso queda asignado, con estado y con historial consultable. Más información en omnifox.io.
Preguntas frecuentes
¿Se puede guardar el archivo .p12 dentro de la imagen del contenedor?
No es recomendable. La imagen se replica en registros, cachés y estaciones de trabajo, y el archivo queda accesible en las capas aunque se borre después. Lo correcto es montarlo en tiempo de ejecución desde un gestor de secretos o, mejor aún, no tener el archivo y delegar la operación criptográfica al proveedor.
¿Cada cuánto hay que rotar la contraseña del certificado?
No existe una cifra universal y no conviene tomar una de un artículo. Define la periodicidad en tu política interna según el riesgo del sistema, y rota de inmediato ante cualquiera de los eventos descritos arriba. Consulta también con el proveedor qué operaciones de cambio soporta su plataforma.
¿Qué pasa con los documentos firmados si el certificado se revoca?
Los documentos firmados durante la vigencia mantienen su validez, especialmente si se firmaron con sellado de tiempo, porque queda acreditado que la firma se hizo cuando el certificado estaba vigente. La revocación impide firmar de ahí en adelante. Ese es justamente uno de los motivos para incluir sellado de tiempo desde el primer día.
¿El equipo de desarrollo debería poder ver el secreto de producción?
No, y el diseño debe hacerlo innecesario. La aplicación obtiene el secreto por su propia identidad en tiempo de ejecución; las personas obtienen acceso a los logs y a las métricas para depurar. Si depurar exige leer el valor, hay un problema de arquitectura antes que de permisos.
Si tu empresa está automatizando la firma y necesita certificados corporativos con una custodia bien definida, conversa con un asesor de Firmas.com.ec. Solicita tu cotización corporativa.