A partir de enero de 2025, el sector financiero europeo deberá cumplir con el Digital Operational Resilience Act (DORA), un reglamento orientado a mejorar la resiliencia operativa digital y la ciberseguridad de este sector. DORA nace en un contexto donde la interconexión y dependencia de las tecnologías de la información y comunicación (TIC) son críticas, haciendo que un fallo o ataque pueda impactar profundamente. Su objetivo es claro: garantizar que las entidades tengan un marco sólido de gestión de riesgos para prevenir y resistir incidentes en una era donde las amenazas son constantes.
¿Quiénes estarán obligados a cumplir con DORA?
Este reglamento se dirige a entidades clave del sector financiero, como bancos, aseguradoras, plataformas de negociación, gestores de fondos, sociedades de valores y agencias de calificación. Sus principales requisitos incluyen la gestión del riesgo TIC, la notificación de incidentes, la evaluación de la resiliencia y la gestión de riesgos de proveedores externos. A partir de enero de 2025, cualquier incumplimiento podrá conllevar sanciones.
Más que cumplir, evolucionar
DORA exige robustez y resiliencia en el sistema financiero, pero ¿cómo se consigue? La construcción de una arquitectura resiliente y segura no solo es un requisito normativo, debe ser un enfoque que aplicar naturalmente en todos los proyectos, herramientas o aplicaciones. En Xeridia, alineados con estos principios, nuestras soluciones están diseñadas para adaptarse a normativas como DORA sin comprometer la innovación.
Bases para una arquitectura resiliente: técnicas y prácticas que fortalecen el software
Modernizar aplicaciones
Modernizar no significa, simplemente, actualizar una interfaz o darle una capa de IA; implica construir una infraestructura sólida que permita la continuidad, la seguridad y, claro está, el cumplimiento normativo.
Una aplicación antigua a veces es (más veces de las que quisiéramos admitir) sinónimo de fragilidad, rigidez, opacidad y bastante difícil de escalar. El código antiguo suele llevar consigo una gran deuda técnica y, en muchas ocasiones, escasa (o ninguna) documentación que nos haga más fácil la evolución. Pero ¿qué enfoque técnico es el más adecuado? Depende. Elegiremos uno u otro estratégicamente según el impacto y necesidades en la empresa:
- Retirar: las aplicaciones que ya no se usan, que no resultan valiosas o algo que sucede a menudo, que realizan funciones redundantes.
- Reemplazar: componente/s antiguos o la misma aplicación por otras opciones de software comercial listo para usar (COTS), SaaS u open source.
- Realojar (lift and shift): migrar una aplicación a una infraestructura más moderna (cloud) sin modificar su arquitectura. Pero la modernización no se detiene ahí, reubicar puede dar mayor flexibilidad, seguridad, pero no resuelve los problemas relacionados con el código.
- Renovar las plataformas: se traslada el código a una nueva plataforma con algunas modificaciones (cambios en la base de datos, middleware, optimizaciones de rendimiento…).
- Refactorizar: supone reescribir el código de la aplicación mejorando la estructura, pero sin cambiar el comportamiento (descomponer monolitos, añadir servicios nativos en cloud…).
- Reconstruir: módulos, capacidades, o componentes.
- Rediseñar: volver a diseñar y construir desde cero toda aplicación.
Microservicios y Kubernetes
Optar por microservicios permite una mayor flexibilidad y resiliencia. Una aplicación dividida en componentes más pequeños hace que, si uno falla, sea fácil aislarlo para que no afecte a los demás. Kubernetes, como orquestador de estos servicios, distribuye cargas y asegura el correcto funcionamiento de cada componente.
Despliegues distribuidos y patrones de resiliencia
Distribuir una aplicación o sistema en varios servidores o entornos geográficamente dispersos (bases de datos, APIs…) mejora la escalabilidad y la tolerancia a fallos.
Por su parte, el patrón Circuit Breaker (o interruptor de circuito) ayuda a detectar fallos evitando que estos se propaguen en cascada. Actúa como interruptor para detener temporalmente las llamadas a estos servicios fallidos hasta que se recuperen. Cuando los fallos son temporales, el patrón Retry (de reintento) realiza intentos automáticamente con las operaciones que resultaron fallidas para darle la oportunidad de recuperarse.
Junto con el patrón de reintento, se pueden emplear estrategias de backoff exponencial para incrementar los tiempos de espera entre intentos, en lugar de reintentar constantemente y evitar sobrecargas.
Integración y entrega continua (CI/CD)
Esta dupla hace que el flujo de desarrollo y despliegue de software sea ágil, estable y sólido (sin errores).
La integración continua hace que cuando se realiza un cambio de código, este se integre para comprobar que su funcionalidad sigue siendo compatible con el resto. Además, y de manera automática, CI ejecuta pruebas para evitar que los errores rompan el sistema.
CD por su parte se encarga de que el código esté siempre listo para ser desplegado. Cuando el código pasa las pruebas, se despliega automáticamente en entornos de preproducción y producción.
Arquitectura basada en eventos (Event-Driven Architecture, EDA)
Los componentes del sistema, que están desacoplados, se comunican entre sí mediante la publicación y el consumo de eventos, los cuales desencadenan acciones. Para ello es necesaria la utilización de un bróker de mensajes o eventos. La arquitectura basada en eventos proporciona escalabilidad, flexibilidad y una mayor tolerancia a fallos mediante la persistencia de los eventos, lo que garantiza que estos no se pierdan y se recuperen rápidamente tras un fallo.
Mirando bajo el capó: la observabilidad y el testing
Observar permite reaccionar a tiempo. La monitorización predictiva o el uso de logs estructurados y una trazabilidad distribuida ayuda a identificar, hacer seguimiento y resolver problemas.
Completando esta capacidad tenemos el testing. Desde las pruebas funcionales, a las pruebas de estrés, de carga y de integridad. El testing automatizado permite simular los picos de carga que han de soportar las aplicaciones e infraestructuras en determinadas condiciones para asegurar que todo responde de manera adecuada.
Construir plataformas resilientes es un trabajo de equipo
Al elegirnos, nuestros clientes encuentran en Xeridia un socio que entiende todas las necesidades de los entornos más exigentes, como el financiero. Nuestro enfoque combina la experiencia de equipos especializados en DevOps, Microservicios, arquitecturas Cloud y otras tecnologías innovadoras como GenAI, blockchain o las plataformas low-code. Trabajamos en equipo para anticiparnos a los retos y construir soluciones robustas que faciliten la evolución y el mantenimiento de infraestructuras fiables.
