Diseño de un entorno bancario abierto y seguro
This post is also available in:
Inglés 
Francés 
Alemán 
Italiano 
Portugués, Brasil 
Ruso
Muchos de nosotros usamos productos innovadores como Mint, Chime o Venmo sin saber realmente que el manejo de los datos se hace a través de APIs bancarias abiertas.
La iniciativa de banca abierta está impulsada principalmente por la regulación europea, la Directiva sobre servicios de pago 2 (PSD2) para abrir datos de clientes bancarios cerrados y propietarios de depósitos a proveedores externos (TPP) de forma segura a través de APIs disponibles públicamente. El objetivo es estimular la innovación y aumentar la competencia. A diferencia de la banca tradicional, donde todos los datos del cliente están controlados por el banco matriz, en la banca abierta, los datos del cliente se exponen de forma segura a los TPP a través de APIs solo cuando el cliente proporciona su consentimiento. Gartner predice que para el año 2022, la interfaz de programación de las aplicaciones (API) se convertirá en el vector de ataque más frecuente, lo que resultará en violaciones de datos de aplicaciones web empresariales. El desafío de seguridad de la API requiere cobertura ante amenazas, una integración fácil y una visibilidad completa tanto para las APIs documentadas como no documentadas.
Según un estudio de Celent de 2018, se espera que la cantidad de instituciones financieras (IF) de EE. UU. con portales bancarios abiertos para facilitar el acceso de los TPP a los datos financieros y de otro tipo de los consumidores crezca de 20 a más de 200 para fines de 2021. En el primer trimestre de 2020, había más de 300 TPP registrados en el Reino Unido. Otros países, como India y Australia, han seguido el enfoque de la UE y tienen un ecosistema bancario abierto en crecimiento.
APIs de Banca Abierta: ¿Qué podría salir mal?
Antes de la banca abierta, muchos proveedores innovadores de tecnología financiera (FinTech) utilizaban el raspado de pantalla para obtener acceso a los datos del cliente, incluidas las credenciales de usuario, sin conocimiento del banco matriz. Las APIs de banca abierta simplificaron las implicaciones legales de compartir las credenciales e información de los clientes a través de las APIs, el consentimiento y la autoridad reguladora.
Si bien las APIs brindan enormes beneficios, también introducen preocupaciones de disponibilidad y seguridad, tales como:
- Interrupción del servicio: Los servicios de la API dejan de estar disponibles debido a errores de configuración de la aplicación, la red y la seguridad, los ataques de denegación de servicio o interrupciones de la infraestructura de las aplicaciones o de la autenticación.
- Problemas de confianza: Muchas soluciones para la banca abierta se basan en una infraestructura híbrida o solo en la nube. Sin embargo, la migración a nubes públicas crea problemas de confianza debido a la incompatibilidad con las soluciones de seguridad, desafíos de configuración en diferentes entornos, configuraciones incorrectas, y problemas relacionados con las políticas y los perfiles de seguridad de las aplicaciones.
- Aumento de la superficie de ataque: Los ataques a la API de diversos tipos son bastante comunes. Una encuesta de Radware reveló que al menos una vez al mes, el 55% de las organizaciones experimentan un ataque de DoS contra sus APIs, el 48% experimenta alguna forma de ataque de inyección y el 42%, una manipulación de elementos/atributos. Otros ataques incluyen los de autenticación y autorización de las APIs, ataques integrados como inyección SQL, secuencias de comandos entre sitios cruzados (XSS) y ataques de bots.
- Ataques de bots a las APIs: Los ataques de bots son programas automatizados diseñados para ingresar a las cuentas de los usuarios, robar identidades, cometer fraude de pagos, raspar contenido, precios, cupones o datos, difundir spam o propaganda, y afectar las actividades comerciales.
- Robo de datos: Muchas APIs procesan información confidencial de identificación personal (PII). La combinación de información sensible y confidencial junto con la falta de visibilidad sobre cómo operan estas APIs y las aplicaciones de terceros es una pesadilla de seguridad en el caso de una infracción.
- APIs no documentadas pero publicadas: Las APIs no documentadas pueden exponer información confidencial por accidente si no se prueban, y pueden estar abiertas a manipulaciones y explotación de sus vulnerabilidades.
¿Mis Puertas de Enlace de API (API Gateway) y Firewall de Aplicaciones web (WAF) no son suficientes?
Debido a que las amenazas varían, la seguridad de las APIs requiere una combinación de controles de seguridad que incluyen:
- Controles de acceso a la API mediante autenticación, autorización y gestión de acceso
- Protección contra ataques de BOTs a las APIs
- Prevención de ataques DDoS y de disponibilidad
- Protección contra ataques integrados, vulnerabilidades y manipulaciones de las APIs
- Prevención de la fuga de datos de PII y exposición excesiva de los datos
- Protección contra fraudes y estafas de phishing
Tradicionalmente, la protección contra DDoS, los WAFs y las puertas de enlace han sido las principales herramientas de seguridad utilizadas para la protección de las APIs. Si bien las puertas de enlace ofrecen gestión e integración de la API con capacidades de autenticación y autorización, sus capacidades de seguridad de la API, protección contra bots y aplicaciones web son limitadas o inexistentes. La mayoría de los WAF no comprenden las diferencias entre las APIs y las aplicaciones web normales. Incluso si comprenden la diferencia, no inspeccionan ni detectan los riesgos de seguridad reales relacionados con las APIs.
[También puede interesarte: 4 Preguntas para Hacer sobre el Cumplimiento de la Banca Abierta]
¡Los bots no siempre son amistosos o visibles!
Las APIs también están expuestas a ataques de bots. Según Forrester, más de un cuarto de las solicitudes en la web se originan en bots maliciosos. Se ha observado que estos bots intentan ataques automatizados dirigidos a las APIs, como la toma de control de cuentas, la denegación de servicio, el abuso de datos de pago y la denegación de inventario. La protección de las APIs contra ataques automatizados es diferente a la protección de las aplicaciones web y móviles, simplemente porque los comportamientos del bot, el flujo de navegación y los indicadores son diferentes.
La falta de herramientas de gestión de bots dedicadas en la mayoría de las organizaciones las pone en mayor riesgo de que los posibles malos actores lancen ataques exitosos a través de las APIs, como el relleno de credenciales, la fuerza bruta y los intentos de raspado.
¿Qué se requiere para asegurar las APIs de la banca abierta?
La solución de Radware está diseñada para proteger las APIs de los hackers y los ataques de los estados-nación. La solución protege a las APIs de la denegación de servicio, ataques de aplicaciones y bots, protege a la API contra vulnerabilidades y manipulaciones, previene interrupciones del servicio, y aborda las preocupaciones de confianza y seguridad de los clientes que migran a una implementación híbrida o de nube múltiple.
Conclusión:
Si bien la banca abierta todavía está en pañales, está creciendo muy rápidamente. La banca abierta abre los datos de los clientes a proveedores externos a través de las APIs para ofrecer servicios innovadores. No obstante, esto también significa una superficie de amenaza más amplia que debe protegerse contra el abuso y la malicia. Los bancos y la tecnología financiera (Fintech) que prosperan en este entorno, ofrecerán soluciones que fomenten la confianza del cliente a través de soluciones seguras. Para obtener más información sobre cómo Radware puede ayudarte, visita Seguridad sin Fricciones al Ritmo de la Innovación | Radware
