La Junta de Andalucía ha publicado la versión 2.2.5 de sus servicios REST de firma delegada, con un cambio de arquitectura que afecta a los equipos que integran estos servicios: el instalable pasa a estar independizado del kit general de integración con @firma.
La novedad fue anunciada el 21 de septiembre en el portal de Desarrollo de Servicios Digitales. Aunque la comunicación oficial es breve, el desacoplamiento tiene interés técnico porque permite gestionar el componente de firma delegada con un ciclo de despliegue más independiente respecto del resto de integraciones.
En una Administración con numerosos sistemas conectados a servicios corporativos de firma, reducir acoplamientos puede facilitar mantenimiento, actualización y trazabilidad.
Qué cambia con la versión 2.2.5
La Junta confirma dos hechos: existe una nueva versión 2.2.5 de los servicios REST de firma delegada y el instalable se ha independizado del kit de integración con @firma.
No se han anunciado en esa nota nuevas funciones de firma ni cambios jurídicos en el servicio. Por tanto, el interés principal está en la distribución y arquitectura del componente.
Separar instalables permite que una actualización específica no obligue necesariamente a sustituir otros elementos del kit.
Qué es la firma delegada
La firma delegada permite articular procesos donde una aplicación solicita una operación de firma mediante servicios corporativos y reglas previamente establecidas. Su uso debe estar alineado con el contexto jurídico y de seguridad aplicable.
En grandes organizaciones, centralizar capacidades evita que cada aplicación implemente mecanismos criptográficos propios.
El servicio corporativo puede concentrar auditoría, certificados, políticas y evolución tecnológica.
REST como interfaz de integración
Los servicios REST ofrecen una forma estandarizada de comunicación entre aplicaciones mediante HTTP y estructuras de datos definidas.
Para los equipos de desarrollo, una API estable reduce dependencia de integraciones antiguas y facilita automatización.
La Junta lleva tiempo modernizando sus fachadas de firma, como también demuestra la evolución de Port@Firmas REST.
Desacoplar componentes reduce riesgo de actualización
Cuando varias funciones se distribuyen dentro de un único paquete, actualizar una puede obligar a validar todas. Separarlas permite ciclos distintos.
Esta modularidad puede reducir el alcance de las pruebas y facilitar correcciones urgentes.
Sin embargo, exige una gestión rigurosa de versiones y dependencias para evitar combinaciones incompatibles.
Inventario de aplicaciones integradas
El cambio es una oportunidad para que los responsables revisen qué aplicaciones consumen firma delegada, qué versión tienen y quién mantiene cada integración.
Un inventario actualizado facilita planificar despliegues y reaccionar a vulnerabilidades.
La gobernanza de activos es una prioridad que también aparece en iniciativas como HAL y otras plataformas corporativas de datos, aunque el objeto tecnológico sea distinto.
Pruebas de regresión antes de producción
Una nueva versión de una API crítica debe validarse con escenarios representativos. Es importante comprobar solicitudes válidas, errores, timeouts, certificados y respuestas.
Los entornos de preproducción permiten verificar compatibilidad antes de afectar expedientes reales.
La automatización de pruebas reduce dependencia de comprobaciones manuales.
Observabilidad de la firma
Los servicios corporativos necesitan métricas sobre disponibilidad, latencia y errores. Un fallo de firma puede bloquear múltiples procedimientos.
La observabilidad debe permitir distinguir un problema de aplicación, de red o del servicio central.
Los logs necesitan proteger información sensible y conservar evidencias suficientes para auditoría.
Firma electrónica y continuidad administrativa
La firma forma parte de resoluciones, informes y documentos con efectos jurídicos. Una indisponibilidad prolongada puede retrasar expedientes.
Los planes de continuidad deben identificar qué procesos dependen del servicio y qué alternativas existen.
Centralizar mejora control, pero convierte el componente en infraestructura crítica.
Seguridad de credenciales y certificados
La arquitectura de firma debe proteger claves, certificados y mecanismos de autenticación. El acceso al servicio no puede depender únicamente de que una aplicación conozca un endpoint.
El principio de mínimo privilegio exige limitar qué aplicaciones pueden solicitar operaciones y bajo qué condiciones.
La trazabilidad permite investigar usos anómalos.
Relación con el Esquema Nacional de Seguridad
Los servicios de firma utilizados por Administraciones deben integrarse en los controles de seguridad de los sistemas que los consumen.
El ENS y su evolución hacia controles más automatizables refuerzan la necesidad de documentar activos, dependencias y evidencias.
Una API corporativa debe incluirse en el análisis de riesgos del servicio final.
Versionado y compatibilidad
Separar el instalable hace todavía más importante publicar una política de versiones. Los equipos deben conocer qué combinaciones están soportadas y cuándo deja de mantenerse una versión.
Una estrategia de deprecación gradual evita que aplicaciones antiguas bloqueen la evolución del servicio.
Los avisos deben llegar con tiempo suficiente para planificar cambios.
Documentación como parte del producto
Una API no está completa sin documentación de endpoints, formatos, errores y ejemplos.
Los equipos de la Junta necesitan poder integrar sin depender de conocimiento informal.
La documentación versionada permite saber qué comportamiento correspondía a cada despliegue.
Automatización del despliegue
Un componente independiente puede integrarse mejor en pipelines de CI/CD si dispone de artefactos y configuración reproducibles.
La automatización reduce diferencias entre entornos y facilita volver a una versión anterior cuando aparece un problema.
Andalucía está reforzando precisamente su modelo de desarrollo corporativo mediante plataformas como PAD y CadenaÚnica.
Menos acoplamiento, más responsabilidad de configuración
La modularidad no elimina complejidad; la redistribuye. Los responsables deben gestionar configuración, secretos y dependencias del nuevo instalable.
Una separación mal documentada puede generar versiones divergentes entre aplicaciones.
La gobernanza de configuración es por tanto parte del beneficio esperado.
La firma como building block reutilizable
Tratar la firma como componente común evita que cada trámite construya una solución propia.
Este patrón coincide con la arquitectura de building blocks reutilizables que promueve GovStack.
Los componentes compartidos permiten concentrar inversión en calidad y seguridad.
Qué deberían hacer los equipos integradores
Los responsables técnicos deberían revisar la nueva versión, validar compatibilidad con su aplicación y actualizar inventarios.
No es recomendable desplegar en producción únicamente porque el componente sea corporativo; cada sistema debe ejecutar sus pruebas.
También conviene registrar fecha de actualización y versión efectiva.
Qué no implica el anuncio
La publicación no significa que desaparezca @firma ni que todos los sistemas deban migrar inmediatamente. Tampoco anuncia un nuevo marco jurídico de firma.
El cambio confirmado es técnico: una nueva versión REST y un instalable independiente.
Cualquier obligación de migración debe consultarse en documentación específica.
Fuente oficial
La información procede del portal de Desarrollo de Servicios Digitales de la Junta de Andalucía, con fecha 21 de septiembre de 2026.
La actualización puede parecer menor frente a grandes proyectos de digitalización, pero este tipo de evolución de infraestructura es la que sostiene los trámites cotidianos. La capacidad de actualizar componentes con menos acoplamiento mejora mantenibilidad y reduce riesgo operativo.
Separación de ciclos de vida
Independizar el instalable permite que el equipo responsable publique una corrección o evolución de firma delegada sin tener que coordinar siempre la misma versión del kit general de @firma.
Este desacoplamiento reduce el área de cambio, pero obliga a documentar compatibilidades. Una aplicación debe saber qué versión del servicio usa y qué dependencias siguen siendo necesarias.
El beneficio aparece cuando el despliegue independiente se acompaña de pruebas automáticas y una política clara de soporte.
Gestión de artefactos y repositorios corporativos
Los instalables deberían distribuirse desde repositorios controlados, con hashes, versiones y trazabilidad. Esto evita descargar binarios desde ubicaciones no verificadas o mantener copias locales difíciles de actualizar.
Los equipos de DevSecOps pueden integrar la nueva pieza en pipelines y comprobar automáticamente dependencias conocidas.
La cadena de suministro del software es parte de la seguridad del servicio de firma.
Plan de migración para consumidores existentes
Aunque el anuncio no obliga a una migración inmediata, cada organismo puede identificar aplicaciones que consumen firma delegada y planificar su actualización.
Conviene priorizar sistemas críticos, versiones sin soporte o integraciones con configuraciones especiales. Un piloto con aplicaciones representativas puede revelar problemas antes de generalizar.
La migración debe incluir un procedimiento de vuelta atrás si aparecen errores en producción.
Pruebas funcionales de documentos reales
Las pruebas no deberían limitarse a comprobar que la API devuelve un código correcto. Hay que validar documentos, formatos, certificados, sellos y evidencias generadas.
Los casos deben cubrir documentos grandes, caracteres especiales, múltiples firmantes y errores de autenticación.
La firma tiene efectos jurídicos; una prueba superficial puede no detectar alteraciones que solo aparecen en el documento final.
Gestión de claves y secretos
Las credenciales usadas por aplicaciones para invocar servicios deben almacenarse en gestores de secretos y rotarse. Incluirlas en repositorios o ficheros de configuración compartidos aumenta riesgo.
El desacoplamiento del instalable es una ocasión para revisar cómo se distribuyen estos secretos en cada entorno.
También conviene separar identidades de pruebas y producción para evitar accesos cruzados.
Acuerdos de nivel de servicio
Cuando muchas aplicaciones dependen del mismo componente, la disponibilidad debe medirse con objetivos explícitos. Latencia, errores y ventanas de mantenimiento son relevantes para planificar procedimientos.
Un SLA interno facilita que los equipos consumidores conozcan qué esperar y cómo escalar incidencias.
Los cambios de versión deberían comunicarse con suficiente antelación para que los sistemas críticos ejecuten validaciones.
Auditoría del uso de firma delegada
La Administración necesita saber qué aplicación solicitó una firma, bajo qué identidad y sobre qué operación. Los registros deben permitir reconstruir eventos sin almacenar innecesariamente el contenido completo del documento.
La auditoría es especialmente importante en procesos automatizados donde no existe una interacción manual en cada paso.
Los responsables deberían revisar periódicamente accesos y detectar aplicaciones que ya no utilizan el servicio.
Preparación para cambios criptográficos futuros
Los servicios corporativos de firma tendrán que adaptarse a cambios de algoritmos y certificados durante los próximos años. Una arquitectura modular facilita sustituir componentes sin rediseñar cada aplicación.
España ya prepara una migración postcuántica de sistemas expuestos, lo que refuerza el valor de la criptoagilidad.
Las aplicaciones consumidoras deberían evitar asumir algoritmos o tamaños de clave de forma rígida.
Documentar incidencias conocidas
Cada versión puede tener limitaciones o configuraciones recomendadas. Publicar incidencias conocidas reduce tiempo de diagnóstico en equipos consumidores.
Una base de conocimiento central ayuda a distinguir un error de integración de un problema general.
La documentación operativa debe actualizarse junto con el software y no después.
Automatizar la gestión de versiones
La independencia del instalable permite tratar la firma delegada como un componente con su propio ciclo de entrega. Los equipos pueden automatizar comprobaciones de versión y detectar aplicaciones que se quedan atrás.
Un panel corporativo puede mostrar qué versión utiliza cada entorno y qué actualizaciones están pendientes. Esto ayuda a coordinar ventanas de mantenimiento y reduce diferencias entre desarrollo, pruebas y producción.
La trazabilidad de versiones también simplifica el diagnóstico cuando una incidencia solo aparece después de una actualización concreta.
Retirada ordenada de componentes antiguos
La modularidad facilita evolucionar, pero también obliga a retirar instalables que dejan de estar soportados. Mantener indefinidamente versiones antiguas multiplica el esfuerzo de seguridad y soporte.
Una política de fin de vida debería definir fechas, canales de aviso y requisitos mínimos para migrar. Los responsables de aplicaciones críticas necesitan tiempo suficiente para validar.
La Administración gana agilidad cuando actualizar deja de ser una operación excepcional y pasa a formar parte del mantenimiento ordinario.
Cuadro de mando para dependencias de firma
La separación del componente también permite visualizar mejor qué sistemas dependen de él. Un cuadro de mando puede relacionar aplicación, versión instalada, entorno, responsable y fecha de última actualización.
Esta información resulta especialmente útil cuando aparece una vulnerabilidad o una incompatibilidad. El equipo central puede localizar consumidores afectados sin depender de correos o inventarios locales.
Además, facilita programar renovaciones de certificados y revisar aplicaciones que llevan meses sin utilizar el servicio.
Pruebas periódicas de continuidad
La firma delegada debería incluirse en ejercicios de continuidad. Simular una indisponibilidad permite comprobar si los procedimientos críticos conocen sus alternativas y si los canales de escalado funcionan.
También es útil medir cuánto tiempo tarda el servicio en recuperarse después de una actualización fallida y si el rollback restaura todas las configuraciones.
Estas pruebas convierten la modularidad técnica en resiliencia operativa real.
Responsabilidad clara sobre el componente
El desacoplamiento técnico debe ir acompañado de una unidad responsable de mantener versión, documentación y soporte. Los consumidores necesitan un punto de contacto estable para incidencias y consultas de compatibilidad.
Asignar esta responsabilidad evita que el componente independiente termine convirtiéndose en software compartido sin propietario operativo.
Fotografía: https://kaboompics.com/ / Pexels.