Preguntas frecuentes de los desarrolladores
Preguntas frecuentes de los desarrolladores
El tratamiento de datos puede dar lugar a riesgos operacionales, amenazas de ciberseguridad y violaciones de datos, comprometiendo la privacidad y la seguridad de información sensible.
Por lo anterior, para el desarrollo e implementación de nuestro esquema de finanzas abiertas, se fijó un marco regulatorio sólido, el cual establece los estándares tecnológicos y de seguridad que deben aplicar las entidades vigiladas por la SFC para trasferir los datos de los consumidores financieros de forma segura y transparente, garantizando la protección de la información y de los derechos de los consumidores financieros.
Mediante Circular Externa 004 de 2024 la SFC definió los estándares tecnológicos y de seguridad, que deben cumplir las entidades vigiladas que participen en los ecosistemas de finanzas abiertas. Estos estándares garantizan que el tratamiento de datos de los consumidores financieros atienda expresamente las condiciones que este haya decidido en el consentimiento, y brinda las herramientas para que la circulación de los datos sea efectuada bajo las más robustas normas tecnológicas de tal forma que se minimiza el riesgo de ciberseguridad y operativo.
De acuerdo con la circular, las entidades vigiladas por la SFC deben implementar protocolos de tratamiento de información para atender las solicitudes de acceso a datos personales presentadas por los terceros receptores de datos en el desarrollo de esquemas de finanzas abiertas. Los protocolos de tratamiento de información que implementen las entidades vigiladas en desarrollo de los esquemas de finanzas abiertas deben cumplir, como mínimo, con los siguientes requisitos:
En materia de arquitectura:
b) Cumplir con el marco de referencia REST y su implementación debe ser RESTful o cualquiera que lo modifique, sustituya o adicione.
En materia de administración de datos, cumplir con el estándar ISO 20022 última versión, o cualquiera que lo modifique, sustituya o adicione, en lo relacionado con el diccionario de datos y utilizar el diccionario de campos que establece el referido estándar.
En materia de seguridad:
seguros para la implementación del Token de Acceso (Access Token), tales como: Client Credentials (RFC 6749), Authorization Code (RFC 6749), Authorization Code con PKCE (RFC 7636) o Refresh Token (RFC 6749), entre otros, últimas versiones o cualquiera que los modifique, sustituya o adicione. El Token de Acceso debe generarse haciendo uso del estándar JWT (JSON Web Token), debe firmarse utilizando algoritmos seguros tales como, RS256 o superiores, y debe utilizar private_key_jwt como método de autenticación.
b) Cumplir con el marco FAPI 2.0 última versión, o cualquiera que lo modifique, sustituya o adicione, desarrollado por The OpenID Foundation (OIDF) para los perfiles de seguridad.
c) Realizar el tratamiento de información bajo el protocolo TLS última versión, o cualquiera que lo modifique, sustituya o adicione y garantizando el proceso de autenticación mutua o recíproca (mutual authentication).
d) Contar con certificados digitales vigentes, de acuerdo con lo establecido en la Ley 527 de 1999 y normas que la sustituyan, modifiquen o reglamenten.
De acuerdo con lo señalado en la Circular Externa 004 de 2024 las entidades vigiladas deben implementar protocolos de tratamiento de información para atender las solicitudes de acceso a datos personales presentadas por los terceros receptores de datos en el desarrollo de esquemas de finanzas abiertas. Los protocolos de tratamiento de información que implementen las entidades vigiladas en desarrollo de los esquemas de finanzas abiertas deben cumplir con los siguientes requisitos allí establecidos.
La SFC tiene planteada una hoja de ruta respecto de asuntos relacionados con finanzas abiertas, según la cual la implementación del esquema será escalonada, generando estándares para diferentes casos de uso, así:
- Iniciación de pagos: Plazo diciembre de 2024.
- Agregación de productos: Plazo septiembre de 2025.
- Portabilidad de otros servicios financieros: Plazo junio de 2026.
Sí, la SFC definirá estándares tecnológicos y de seguridad, que permitan garantizar la interoperabilidad en cada uno de los casos de uso a que se hizo referencia en la anterior pregunta.
Los terceros receptores de datos deberán ejecutar la autorización de autenticación con el protocolo OAuth 2.0 desarrollado por el IETF OAuth Working Group. Para el efecto, se debe hacer uso de mecanismos seguros para la implementación del Token de Acceso (Access Token), tales como: Client Credentials (RFC 6749), Authorization Code (RFC 6749), Authorization Code con PKCE (RFC 7636) o Refresh Token (RFC 6749), entre otros. El Token de Acceso debe generarse haciendo uso del estándar JWT (JSON Web Token), debe firmarse utilizando algoritmos seguros tales como: PS256 o superiores, y debe utilizar private_key_jwt como método de autenticación.
El intercambio de información realizado a través de servicios denominados endpoints se protegerá con el protocolo TLS garantizando el proceso de autenticación mutua o recíproca (mutual authentication), haciendo uso de certificados digitales vigentes, de acuerdo con lo establecido en la Ley 527 de 1999 y normas que la sustituyan, modifiquen o reglamenten, para lo cual deben utilizar cualquiera de las siguientes suites de cifrado:
i) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ii) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Adicionalmente, se establecerán como método de prueba de posesión para el soporte de los tokens de acceso restringido los requisitos señalados en el documento RFC8705, el cual hace uso de la autenticación mTLS.
Son protocolos de seguridad criptográficos que deben ser utilizados para la conexión entre equipos de clientes, servidores de autorización y de recursos, definidos en combinaciones específicas de los algoritmos CipherSpecs y CipherSuites. Cada CipherSuites tiene un nombre único que se utiliza para identificarlo y describir su contenido algorítmico. Cada segmento en el nombre representa un algoritmo o protocolo diferente.
Para este caso particular TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 significa:
TLS: Define el protocolo de transmisión a usar.
ECDHE: Indica el algoritmo de intercambio de claves con el cual se encripta el tráfico en la sesión.
RSA: Mecanismo de firma digital de autenticación empleado durante el protocolo de enlace para garantizar que los datos intercambiados entre cliente y servidor no hayan sido alterados.
AES: Es el algoritmo simétrico de cifrado de sesión.
128: Tamaño de la clave de cifrado de sesión (bits).
GCM: Tipo de cifrado (dependencia del bloque de cifrado y opciones adicionales).
SHA256: Algoritmo de hash para la validación de la integridad del mensaje.
No, la Circular Externa 004 de 2024 establece que para desarrollar los protocolos de intercambio automático de información se debe utilizar el marco de referencia REST, dado que esta soportado en estándares reconocidos que brindan una mayor flexibilidad, rendimiento, escalabilidad, seguridad y fiabilidad generando ventajas frente a otros estándares.
Cumplir con el marco de referencia REST y su implementación RESTful proporciona beneficios en términos de interoperabilidad, escalabilidad, simplicidad y portabilidad. REST define un conjunto de principios y restricciones que facilitan la interoperabilidad entre sistemas. Permite que los sistemas sean escalables y utiliza una arquitectura cliente-servidor sin estado. REST usa recursos identificables mediante las URL (se utilizan para especificar la ubicación de un recurso) y operaciones CRUD (Crear, Leer, Actualizar, Eliminar, por sus siglas en ingles). Finalmente, las API RESTful son independientes del lenguaje de programación o la plataforma utilizada. Esto significa que una API RESTful puede ser consumida por diferentes tipos de clientes, incluidos navegadores web, aplicaciones móviles y otros servicios web.
No, la Circular Externa 004 de 2024 establece que el intercambio de información entre las aplicaciones en el ecosistema de finanzas abiertas debe realizarse a través del formato JSON (JavaScript Object Notation), es un formato abierto, ligero, compacto e independiente de cualquier lenguaje de programación, que permite representar los datos en un archivo más pequeño para una transferencia eficiente.
No, la Circular Externa 004 de 2024 de la SFC establece que los tokens de acceso deben firmarse utilizando algoritmos seguors tales como PS256 o superiores. El algoritmo HS256 (HMAC con SHA-256) es un algoritmo hash determinístico de clave simétrica que utiliza una clave secreta, la cual es conocida por las dos partes y se utiliza tanto para generar la firma como para validarla.
El algoritmo PS256 (RSASSA-PSS usando SHA-256 y MGF1 con SHA-256) provee una firma probabilística, lo que significa por cada entrada de datos (clave privada) obtiene una salida distinta por cada interacción realizada, debido a la introducción de datos aleatorios, ofreciendo un nivel de seguridad superior sin dejar de ser verificable mediante la misma clave pública que conocen las partes.
No, las versiones 1.0 y 1.1 del protocolo TLS registran vulnerabilidades, el marco FAPI 2.0 establece que las conexiones de los clientes y servidores (autorización, autenticación y recursos), deben estar protegidas usando la versión TLS 1.2 o superiores. Adicionalmente, las versiones 1.0 y 1.1 no son compatibles conlas suites de cifrados TLS ECDHE RSA WITH AES 128 GCM SHA256 y TLS ECDHE RSA WITH AES 256 GCM SHA384.
Última modificación 18/03/2024