Header Ads Widget

Ticker

6/recent/ticker-posts

Mejora de la seguridad de la banca abierta con FAPI 2.0

 

Ya sea que crea o no el bombo publicitario, la banca abierta aún obtiene una cantidad increíble de cobertura en los servicios financieros y la prensa informática. Sin embargo, también hay una gran cantidad de variación en diferentes regiones. El Reino Unido aparentemente está haciendo una pausa para pensar, los organismos de estándares como el Grupo de Berlín están mirando hacia las finanzas abiertas , y regiones como Brasil se están acelerando rápidamente con nuevos estándares y regulaciones para todo el mercado .

Sin embargo, un área que se está volviendo cada vez más consistente es la seguridad para las API de banca abierta . Cuando una API no entra en el ámbito de los datos abiertos, donde los datos deben estar disponibles y accesibles de forma gratuita, un número cada vez mayor de regiones y organismos de normalización están mirando hacia el estándar API de grado financiero (FAPI) . Hemos cubierto FAPI en el blog antes , pero a medida que la banca abierta se vuelve más omnipresente, el alcance y las protecciones que ofrece FAPI están madurando.

Los cambios que está diseñando el Grupo de Trabajo FAPI han dado lugar a una nueva versión de los estándares: FAPI 2.0 . En esta publicación, describimos las novedades y descubrimos por qué FAPI 2.0 mejora lo que se hizo antes.

Visión general
Al igual que FAPI 1.0 antes, el objetivo continuo de FAPI 2.0 es proporcionar una protección significativa para las API de servicios financieros a través de estándares basados ​​en OAuth. El sitio web del grupo de trabajo describe los siguientes tres objetivos de alto nivel:

  • Permitir que las aplicaciones utilicen los datos almacenados en la cuenta financiera.
  • Permitir que las aplicaciones interactúen con la cuenta financiera.
  • Permitir a los usuarios controlar la configuración de seguridad y privacidad.
Estos objetivos han sido consistentes desde FAPI 1.0. Sin embargo, están surgiendo temas claros en el desarrollo de FAPI 2.0:

  • Cohesión : Los perfiles FAPI 1.0 crecieron orgánicamente en muchos casos, y algunos elementos se tomaron del ahora desaparecido Perfil de Seguridad de Banca Abierta del Reino Unido. Desde sus inicios, FAPI 2.0 es un producto del Grupo de Trabajo FAPI, con metas y objetivos claros para el Perfil.
  • Representación : los nuevos requisitos se basan en un modelo de atacante formalizado que proporciona una representación bien definida de las amenazas que el perfil pretende abordar. Esto crea una línea de base mejorada para los implementadores que intentan comprender los estándares.
  • Riqueza : A medida que la banca abierta evoluciona hacia las finanzas abiertas, es necesario admitir un mayor nivel de sofisticación en las solicitudes de autorización que se pueden realizar, con soporte para metadatos de autorización más detallados.
Estos temas se harán evidentes a medida que recorramos cada perfil de FAPI 2.0, a saber:

  • Base
  • Avanzado
  • Gestión de subvenciones
  • Cada uno de los perfiles anteriores aún está evolucionando, y la Gestión de Subvenciones ahora está aprobada como un Borrador de Implementadores . Al igual que FAPI 1.0, el perfil de línea de base constituye el nivel de entrada para el cumplimiento de FAPI y se basa en OpenID Connect Core . Los perfiles básicos y avanzados se relacionan con el fortalecimiento gradual de la seguridad de la API, mientras que la gestión de subvenciones se relaciona con la formalización de la gestión del consentimiento.

Perfil de línea de base
El perfil de línea de base reemplaza nominalmente al perfil de solo lectura ahora renombrado de FAPI 1.0. Al igual que su predecesor, el perfil de línea de base establece los requisitos mínimos para un servidor de autorización, servidor de recursos y cliente compatible con FAPI. El perfil de línea de base en sí describe algunos de los cambios y mejoras significativos del perfil equivalente FAPI 1.0. Los cambios incluyen:

Transmisión más segura de solicitudes de autorización : FAPI 1.0 aprovechó el mecanismo OpenID Connect Core existente para enviar solicitudes de autorización como tokens web JSON firmados, con el enfoque más típico para enviar la solicitud a través del navegador cuando el usuario final es enviado al servidor de autorización. Las solicitudes de autorización enviadas (PAR) reemplazan este mecanismo por completo. PAR ordena que las solicitudes de autorización sean enviadas por un canal secundario protegido al Servidor de Autorización, asegurando que la solicitud sea confidencial. El servidor de autorización devuelve un URI en respuesta, que se pasa al punto final de autorización en lugar del objeto de solicitud. Esto mejora significativamente la protección de la integridad de la solicitud de autorización.
Mayor riqueza en metadatos de autorización : el perfil de línea de base hace referencia a las solicitudes de autorización enriquecidas (RAR), un estándar que agrega el authorization_detailsparámetro a una solicitud de autorización que “ permite a los clientes especificar sus requisitos de autorización detallados utilizando la expresividad de las estructuras de datos JSON“. Esto permitirá que tanto los Servidores de autorización como los Servidores de recursos se aseguren de hacer cumplir explícitamente el consentimiento del usuario, solo entregando los datos que el usuario ha acordado compartir. RAR también permite que el consentimiento se convierta en una parte explícita de los estándares de seguridad de la API. Antes del consentimiento, las API a menudo se implementaban por separado a la pila de seguridad. Los proveedores de seguridad ahora pueden aumentar el alcance de su oferta, extendiéndola para cubrir el consentimiento donde anteriormente ellos, y las organizaciones que implementan sus soluciones, pueden haber optado por implementar una API de consentimiento en la administración de API.
Mayor flexibilidad en la implementación de seguridad : el perfil incluye el estándar “Demostración de prueba de posesión en la capa de aplicación” (DPoP) como un medio para vincular tokens de acceso a una clave privada determinada. Esto permite a los implementadores alejarse de Mutual TLS (MTLS) como el único medio para restringir el uso del token de acceso.
Mejoras generales en la postura de seguridad : se introducen varias características para fortalecer la seguridad, como el uso obligatorio de la clave de prueba para el intercambio de código para todos los servidores y clientes de autorización. Los tokens de identificación ya no se devuelven a través del navegador, a través de la restricción del response_typeparámetro a code, y solo se devuelven a través de un canal secundario.
El perfil de línea de base, por lo tanto, proporciona un conjunto coherente de medidas que están diseñadas para aumentar tanto la seguridad como la usabilidad de los estándares FAPI. El perfil avanzado luego se basa en estos para proporcionar una mayor protección para las operaciones de lectura / escritura.

Perfil avanzado
El Perfil Avanzado todavía se está creando, pero al igual que con FAPI 1.0, sirve para fortalecer la seguridad de operaciones como realizar un pago. Las funciones no son necesariamente nuevas, pero al igual que el perfil de línea de base, el perfil refleja el modelo del atacante al abordar un conjunto de riesgos bien definidos. Los aspectos más destacados del borrador actual incluyen:

Obligar la firma de PAR con fines de no repudio.
Obligar el uso del modo de respuesta de autorización segura de JWT (discutido en nuestra publicación sobre FAPI 1.0) para proteger la integridad del código de autorización durante el vuelo.
Al igual que con el perfil de línea base, estas características sirven para unir aspectos de los estándares subyacentes de manera coherente, lo que garantiza que los esfuerzos de implementación existentes se puedan aprovechar de manera efectiva.

A medida que evoluciona el borrador, actualizamos esta publicación con nuevas funciones del perfil avanzado.
Gestión de subvenciones
El perfil final que introduce FAPI 2.0 es Gestión de subvenciones. Este estándar tiene como objetivo reemplazar la variedad de API de gestión de consentimiento que se han creado en los mercados bancarios abiertos de todo el mundo con un conjunto unificado de capacidades basadas en concesiones (los permisos otorgados por el Usuario final en función de su consentimiento).

Estas capacidades incluyen:

  • Otorgar acceso y devolver a grant_id.
  • Consultar los detalles de una subvención a través de a GET.
  • Actualización de una subvención.
  • Supresión de una subvención.
Estas capacidades pueden parecer triviales, pero sirven para formalizar comportamientos de gestión de subvenciones para los implementadores de FAPI. El estándar también utiliza RAR para respaldar la definición con los metadatos que normalmente se encuentran en las API de gestión de consentimiento existentes. Esto reúne un mecanismo cohesivo y rico para realizar actividades de gestión de subvenciones en una sola implementación que reduce la complejidad para los implementadores.

Pensamientos finales
En nuestra publicación original sobre FAPI 1.0, dijimos que el estándar es " tan bueno como su adopción ". Con ese fin, estamos viendo un número creciente de mercados y estándares bancarios abiertos que optan por usar FAPI, y muchas implementaciones que certifican su implementación como proveedores FAPI OpenID con la Fundación OpenID . Esta oleada de implementadores que certifican su pila, junto con el número creciente de perfiles específicos de países como el Reino Unido, Australia y Brasil, da crédito al hecho de que FAPI es el perfil de seguridad líder en el mercado.

Sin embargo, la banca abierta está todavía, relativamente hablando, en su infancia. Se están cometiendo errores y se están manipulando tonterías. También es imperativo que los estándares puedan evolucionar y mejorar. Por lo tanto, es lógico que el Grupo de Trabajo de FAPI busque evolucionar los estándares hacia FAPI 2.0. Los implementadores pueden mostrarse reacios al hecho de que se está creando un nuevo estándar. Sin embargo, solo adoptando la mejora continua en todo el ecosistema se puede hacer realidad la promesa de la banca abierta y su evolución hacia las finanzas abiertas.


Publicar un comentario

0 Comentarios