Siguiendo con nuestro propósito de ayudar a que el ecosistema financiero sea de calidad y seguro, hicimos una revisión de una parte fundamental de las exigencias técnicas de la recién estrenada norma del sistema de finanzas abiertas. Aún falta que publiquen el anexo 3, pero ya hay varias cosas que podemos ir contándote.
.jpg?width=2304&height=1792&name=Firefly%20Una%20ilustraci%C3%B3n%20de%20una%20revisi%C3%B3n%20t%C3%A9cnica%20detallada%20y%20recomendaciones%20para%20implementar%20un%20sist%20(2).jpg)
En la normativa se establece que la base de este sistema serán las APIs, que deben tener una disponibilidad casi perfecta. Es decir, las APIs deben tener un tiempo de disponibilidad mínimo del 95% de forma diaria y de hasta un 99.5% de forma mensual. Esto pone un nivel de exigencia muy alto.
Pero eso no es todo, ya que también establece tiempos de procesamiento de transacciones. Por ejemplo, las APIs de consulta de los datos asociados deberán procesar transacciones en un tiempo máximo de 4.000 milisegundos. Asimismo, las destinadas al servicio de iniciación de pagos deberán procesar transacciones en un tiempo máximo de 800 milisegundos, sin considerar la ejecución y confirmación de las operaciones de pago con el sistema de pago.
Para lograr este alto nivel de operabilidad, se deben considerar varios frentes:
Porque si hay algo que ha demostrado la historia, es que hasta los sistemas más robustos pueden fallar. Por eso hay que estar preparados. Aquí viene la pregunta, ¿cómo me preparo? Hoy te contamos varios puntos que debes tener muy presentes:
Primero que todo, se debe trabajar en una buena arquitectura de software que permita una buena escalabilidad, desacoplamiento y flexibilidad para que las APIs puedan ir creciendo con el tiempo y soportando las necesidades actuales y futuras.
Igual de importante es la definición de la infraestructura y arquitectura del sistema que sustente las APIs. En esa línea, recomendamos hacer una correcta gestión del tráfico, es decir, distribuir eficientemente las solicitudes entrantes y el tráfico entre múltiples recursos o instancias para evitar sobrecargas y optimizar el rendimiento.
Por otra parte, implementar procesos automáticos de escalamiento, es decir, configurar el sistema para que pueda aumentar o disminuir algunos recursos, como el número de servidores, en respuesta a cambios en la demanda.
Además, es clave diseñar sin puntos únicos de fallo (SPOF), lo que significa identificar y eliminar cualquier componente o recurso que, si falla, pueda causar la caída de todo el sistema. Introducir redundancia y tolerancia a fallos en todos los niveles.
Siempre es una buena idea realizar pruebas de carga y pruebas de estrés para asegurarse de que nuestra infraestructura soporte la cantidad de solicitudes esperadas y conocer el número máximo de peticiones concurrentes que puede tolerar.
Una recomendación es seguir el principio de privilegio mínimo, es decir, cada componente del sistema debe tener solo los permisos necesarios para realizar su función, minimizando así el potencial de daño en caso de una brecha de seguridad.
Otro punto fundamental es hacer un seguimiento constante. Se debe monitorear el rendimiento y la disponibilidad de las APIs 24/7. Esto suena muy agotador, pero tranquilidad, que la norma da espacio para que contrates una empresa externa como Continuum para que te apoye en esto 😉. Esto es un tema serio, porque el incumplimiento de la disponibilidad puede ser sancionado.
Por ende, es fundamental que el sistema tenga una respuesta proactiva, es decir, el monitoreo que definas debe detectar el problema y desencadenar acciones correctivas automáticas.
En este punto somos enfáticos: hay que realizar muchas, pero muchas pruebas de falla y recuperación. Ponerse en los peores escenarios para simular fallos y escenarios de estrés y ciberataques, para validar que el sistema se recupera correctamente.
Otro punto importante es que la normativa establece que las mantenciones y actualizaciones deben ser avisadas y comunicadas, declarando claramente el detalle de los cambios y los tiempos que tomarán.
En esta línea, recomendamos recopilar y revisar métricas como los tiempos de respuesta, la tasa de error y el volumen de tráfico, además de analizar patrones de uso para entender cómo se consume la API y poder asegurar el rendimiento.
Conjuntamente, recomendamos seguir altos estándares de seguridad. Un buen ejemplo de esto es el Marco de Desarrollo Seguro de Software (SSDF) del NIST, que es una reconocida guía de buenas prácticas para implementar seguridad, no solo para desarrolladores, sino también para directivos y compradores de software. Otra sugerencia es revisar el proyecto OWASP API Security Top 10 , el cual entrega una revisión de las principales vulnerabilidades actuales que enfrentan las APIs.
Dicho todo lo anterior, debe existir un sistema alternativo para entregar la información que funcione en caso de que el sistema principal falle, es decir, debe tener la capacidad de mantener el servicio activo.
Este mecanismo debe mantener estándares de métricas, seguridad y trazabilidad, pudiendo visualizar el rendimiento, detectar posibles intrusos o vulnerabilidades y usar credenciales para identificar quiénes y cuándo accedieron, escribieron o recuperaron información.
Además, debe considerarse que no tenga problema con la integración de los sistemas necesarios que defina la CMF, para ofrecer una solución efectiva en caso de que el sistema principal falle.
Por eso te sugerimos contar con un “Disaster Recovery Plan (DRP)”, es un documento donde se describen los pasos a seguir en caso de problemas como caída de servidores, fallas de infraestructura, problemas con las bases de datos, entre otros, debido a algún acontecimiento como puede ser un desastre natural.
Aún se debe publicar el anexo 3 donde se darán a conocer más detalles de las exigencias técnicas que pedirá la CMF. Así que quédate atento, te mantendremos informado de las actualizaciones que vengan.
