Header Ads Widget

Ticker

6/recent/ticker-posts

Cómo proteger la banca abierta


 La banca abierta se está convirtiendo rápidamente en un fenómeno global. Impulsadas por la legislación PSD2 de la UE, las empresas de Europa y otras regiones han comenzado a adoptar prácticas de estilo de banca abierta , ya sea impulsadas por la regulación gubernamental o la presión del mercado.

Los bancos están abriendo API para que las FinTechs se integren con los datos de los clientes, generando una economía completamente nueva de servicios financieros componibles que mejoran la experiencia del cliente bancario final. Sin embargo, los datos bancarios son un punto de contacto sensible. La apertura de la infraestructura bancaria conlleva un riesgo significativo y requiere una postura de seguridad mejorada para cumplir con las normativas de cumplimiento y de datos. Entonces, ¿cómo podemos asegurar la banca abierta?

A continuación, analizaremos cómo abrir bancos sin hacerlos vulnerables. Presentaremos qué es la banca abierta y cubriremos los estándares de seguridad de grado bancario de última generación para garantizar que las API bancarias y la privacidad de los datos cumplan con las últimas regulaciones y cumplimiento.

Recientemente, contratamos al experto en banca abierta Chris Wood y al experto en API para nuestro LiveCast de seguridad de banca abierta . Mira la grabación completa a continuación:

¿Qué es Open Banking Security?

Han pasado más de diez años desde que el Open Bank Project propuso un modelo de banca abierta. Y han pasado más de cinco años desde que se introdujo la legislación PSD2 en la UE. Estas iniciativas proponen que los bancos adopten una interfaz abierta para que los proveedores externos (TPP) se integren. Estas API bancarias permiten a los TPP estrictamente controlados acceder a las cuentas de los clientes, recuperar información, iniciar pagos y realizar otras acciones para mejorar la experiencia del cliente asociada con las finanzas abiertas .

Sin embargo, interrumpir el viaje de la banca en línea al introducir a terceros en la combinación conlleva un riesgo inherente. Sin mencionar el aumento de las amenazas cibernéticas y las infracciones asociadas con la información digital sensible. Por lo tanto, han surgido estándares de seguridad de banca abierta para proteger la información de identificación personal (PII) sensible, autenticar los TPP y ofrecer formas de compartir autorizaciones entre una nueva red de servicios financieros, todo sin sacrificar la experiencia del usuario final. Para que la banca abierta tenga éxito, realmente "necesitamos asegurarnos de que las API sean seguras", dijo Chris Wood. Los datos del cliente deben permanecer seguros y solo accesibles por TPP autorizados.

Cinco estándares de seguridad de la banca abierta

Entonces, ¿cómo aseguramos este nuevo paradigma? Como describe Wood, se están creando muchos estándares API diferentes en varias partes del mundo para garantizar que la banca abierta pueda evolucionar y permanecer segura. Wood propone adoptar estos estándares para controlar el transporte, autenticación, autorización y delegación de credenciales. Los principales estándares incluyen HTTPS, mTLS, OAuth 2.0, OpenID Connect, FAPI y otros. A continuación, proporcionaremos una descripción general de alto nivel de estos estándares y veremos dónde encajan dentro del rompecabezas de seguridad de banca abierta.

1. mTLS

En primer lugar, Wood destaca la importancia de la autenticación mutua sobre la seguridad de la capa de transporte (mTLS), en la que tanto los clientes como los servidores presentan y validan los certificados. La validación de certificados de servidor con autenticación bidireccional está probada y es verdadera, y es bastante ubicua, lo que significa que está disponible para que el mercado la implemente. Esto puede ayudar a evitar ataques man-in-the-middle, repetición y suplantación de identidad.

2. eIDAS

Pero no se detiene ahí. Hay capas adicionales sobre mTLS a considerar. eIDAS (identificación electrónica, autenticación y servicios de confianza) es un estándar de la UE para la identificación electrónica que PSD2 requiere que los proveedores de servicios de confianza de calidad (QTSP) adopten. Esto especifica el uso de ASN.1, un formato de datos, para transportar atributos adicionales.

3. OAuth 2.0

OAuth 2.0 es bastante ubicuo y conocido en la tierra de las API; la mayoría de los probadores lo usan de alguna forma. OAuth otorga poderes de seguridad únicos Por ejemplo, con OAuth, una aplicación que consume la API de Twitter no necesita ver la contraseña del usuario. OAuth cuenta con el apoyo de iniciativas de banca abierta como el Grupo de Berlín y STET .

Otras instituciones de banca abierta aún no han adoptado OAuth. Según Wood, "ciertamente hay formas de mejorar OAuth ... la actualización de OAuth para agregar seguridad y funciones adicionales se considera importante". Aboga por una combinación de OAuth 2.0 y mTLS. Aquí es también donde entra OpenID Connect.

4. OpenID Connect

OpenID Connect se encuentra en la parte superior de OAuth para proporcionar más pruebas de autenticación con un token de identificación. La especificación lo describe como "una capa de identidad simple sobre el protocolo OAuth 2.0". En forma de JSON Web Token (JWT), este token dice que el usuario se ha autenticado y ofrece muchas características adicionales para ampliar las capacidades.

5. FAPI

La API de grado financiero (FAPI) es un perfil de OpenID Foundation que se encuentra en OpenID Connect, lo que brinda seguridad adicional para las organizaciones financieras. El estándar proporciona características de seguridad adicionales en el servidor de autorización, reforzando los comportamientos al segmentar los permisos de TPP. FAPI está organizado en cuatro borradores: un perfil de seguridad de API de solo lectura, un perfil de seguridad de API de lectura y escritura, modo de respuesta de autorización segura de JWT para OAuth 2.0 (JARM) y autenticación de canal secundario iniciada por el cliente (CIBA), que proporciona un nuevo medio de solicitar la autenticación de un usuario. Wood ve a FAPI como "un pilar importante para el crecimiento futuro de la banca abierta".

Una implementación de seguridad de banca abierta

Ahora que tenemos una amplia introducción a los estándares de seguridad de banca abierta, ¿cómo es una implementación segura de banca abierta? Bueno, resulta que las mismas técnicas para proteger las API se aplican en gran medida a proteger las arquitecturas de banca abierta, dice Daniel Lindau. Lindau analizó un flujo de implementación de muestra para permitir la seguridad y el cumplimiento de nivel financiero .

Flujo de implementación

Lindau describe cuatro jugadores principales dentro de una configuración de seguridad de banca abierta: un tercero, un servicio de token bancario, API de banca abierta y, en el corazón de todo, una puerta de enlace API. Para generar una clave o certificado para que un tercero llame a las API, Lindau recorrió un flujo de muestra:

  1. Asumiremos que el tercero ya está registrado. Para comenzar, deben solicitar acceso a una cuenta de usuario, probablemente a través de un flujo de código OAuth.
  2. Luego, el Token Service autentica al usuario. Como parte de los estándares de banca abierta, el servicio Token debe admitir la autenticación multifactor.
  3. El Token Service ahora le pregunta al usuario si permite que el tercero acceda a su información. Esto podría involucrar una ventana emergente, una interfaz de usuario de página web o una aplicación de autenticación. Independientemente, PSD2 requiere un consentimiento firmado criptográficamente.
  4. A continuación, el servicio de token emite un token al tercero, lo que demuestra que se ha producido el consentimiento. Lindau recomienda transformar esto en un Token restringido por remitente, para que solo el que tenga el token pueda usarlo, mejorando así la seguridad.
  5. A continuación, el tercero envía el token a API Gateway. Dado que es un token restringido por el remitente, se debe utilizar mTLS.
  6. Luego, API Gateway valida el token, lo introspecciona con el servicio de token bancario y recibe un token de valor, un JWT, que permite a API Gateway hacer cumplir el remitente y proporcionar controles de acceso de grano grueso que contienen alcances para políticas específicas.
  7. Este JWT se pasa a las API, que contiene los datos y las afirmaciones que necesitan para autorizar la solicitud. Luego, la autorización de la API utiliza una decisión de acceso detallada para aceptar la solicitud.

Según Lindau, el flujo anterior demuestra un proceso seguro para evitar que los datos confidenciales lleguen al mundo exterior. La clave aquí es usar protocolos abiertos para hacer cumplir el acceso restringido por el remitente, que se verifica dentro de los JWT durante todo el proceso. Esto asegura la afirmación directa del usuario de principio a fin.

Para habilitar una configuración firme, Lindau enfatiza algunas otras áreas: Registro de TPP , como en el registro de cliente dinámico (RFC 7591) y la administración de registro de cliente dinámico (RFC 7592), así como la autenticación de cliente fuerte . También destaca los beneficios de usar una API de Hypermedia para la autenticación , un concepto que Curity está impulsando para estandarizar. El uso de una API de autenticación de hipermedia permitiría al servidor controlar todo el flujo de autenticación y recibir enlaces de hipermedia que destacan capacidades adicionales.

Estándares de seguridad de la banca abierta: estándares presentes y futuros

La banca abierta está ganando importancia en la UE y se está extendiendo a otros mercados mundiales. La apertura del acceso a la API del banco a terceros podría permitir muchas innovaciones que ahorran tiempo, como aplicaciones de préstamos más fáciles, iniciación de pagos externos o agregaciones de cuentas más fluidas.

Para construir una implementación de banca abierta segura, Lindau cubrió algunas preocupaciones esenciales:

  • Utilice el registro de cliente dinámico para TPPS: esto ayudará a recopilar la configuración del cliente.
  • Utilice siempre tokens restringidos por remitente: no hay necesidad de tokens de portador cuando tiene claves confiables con sus clientes.
  • Centralice la autenticación y utilice métodos de múltiples factores
  • Utilice decisiones de control de acceso en capas, con información general en la puerta de enlace y detallada para las API.
  • ¡Por último, Daniel recomienda consultar los estándares !

Sobre ese último punto, los estándares están destinados a evolucionar. En términos de adopción futura de estándares, Wood prevé un mayor uso de interacciones CIBA o "estilo CIBA" y un mayor uso de estándares biométricos, como FIDO2 . También espera que la gestión de acceso a nivel de políticas se vuelva más común, junto con mejoras en las experiencias de banca móvil nativa .

Publicar un comentario

0 Comentarios