gestão de consentimento

Especificações técnicas da gestão de consentimento no Open Banking Brasil

O open banking (OB), iniciativa global que vai permitir que os clientes possam autorizar o compartilhamento de seus dados com outras instituições financeiras – e que faz parte do Open Finance – está caminhando para a terceira fase de implementação no Brasil, de acordo com o calendário do Banco Central (BC). Portanto, nesse momento, as discussões estão todas voltadas para o desenvolvimento seguro das APIs e também da gestão de consentimento, que é um dos itens obrigatórios do OB.  

Afinal, ao que tudo indica, o open banking tornará o mercado financeiro mais competitivo, impactando diretamente na prestação de serviços e na criação de novos modelos de negócio. Ou seja, essa é uma ótima oportunidade para as empresas da área participarem desse ecossistema e aproveitarem os benefícios dessa iniciativa.  

Gestão de consentimento são as regras adotadas, de acordo com as normas da Lei Geral de Proteção de Dados (LGPD) e que estão completamente ligadas ao open banking. Isso porque, como já comentamos, os usuários poderão permitir ou revogar o compartilhamento de seus dados financeiros a qualquer momento.  

Pensando nisso, nesse post vamos abordar em detalhes as especificações técnicas da gestão de consentimento na API open bankingassim como os impactos do open banking e LGPD.  

O que é gestão de consentimento? 

Na gestão de consentimento, são observados alguns itens essenciais 

  • O que o usuário X consentiu? 
  • O que o usuário X não quer mais consentir? 
  • Quais consentimentos o usuário X revogou e como isso te afeta? 

De acordo com a LGPD, consentimento é a “manifestação livre, informada e inequívoca pela qual o titular concorda com o tratamento de seus dados pessoais para uma finalidade determinada”. As empresas que utilizarem dados sem o consentimento infringirão a lei e estarão sujeitaa multas.  

Esses conceitos estão completamente ligados ao open banking, afinal o compartilhamento e o uso de dados nesse ecossistema só serão permitidos mediante o consentimento. Isso garante a segurança dos titulares, assim como a transparência do processo.  

Pensando um pouco na segurança de dados na internet no geral, a pesquisa Radar FEBRABAN 2021, realizada pelo Instituto de Pesquisas Sociais, Políticas e Econômicas (Ipespe), com cerca de 3000 entrevistados ao redor do Brasil, traz alguns dados interessantes.  

Do ponto de vista do sentimento de segurança na internet, 41% dos entrevistados afirmaram que se sentem pouco seguros contra 24% que se sentem seguros e 5% muito seguros.  

Gráfico 1 - Pesquisa FEBRABAN 2021

Gráfico 1 – Pesquisa FEBRABAN 2021

 

Em contrapartida, apesar de a maioria (56%) tomar muito cuidado e adotar medidas proteção, existe uma outra parcela que toma poucos ou nenhum cuidado.  

Gráfico 2 – Pesquisa FEBRABAN 2021

Gráfico 2 – Pesquisa FEBRABAN 2021

 

Voltando para o open banking, os bancos, fintechs e instituições financeiras participantes precisam agir com transparência, seguindo o princípio da reciprocidade, para que eles possam utilizar esses dados – que foram autorizados – para entender melhor o comportamento dos clientes, oferecer melhores serviços e até mesmo criar novas iniciativas, de acordo com os insights gerados pelas análises.  

Não se gerencia o que não se mede, não se mede o que não se define, não se define o que não se entende, e não há sucesso no que não se gerencia”, disse uma vez William Edwards Deming, um estatístico americano.  

Dessa forma, é vantajoso que as pessoas se sintam seguras para utilizar o open banking Brasil e, em contrapartida, que as APIS sejam construídas com as melhores práticas e seguindo as regras do Banco Central.  

No tópico a seguir, você confere as especificações técnicas da gestão de consentimento do open banking.  

Gestão de consentimento no open banking: especificações técnicas  

As medidas de segurança para dados financeiros têm como objetivo garantir que a pessoa que está autorizando o uso dos dados é realmente o titular dessas informações. Os tokens, por exemplo são uma forma de garantir que isso aconteça.  

Isso porque, no geral, as APIs financeiras precisam ter/resolver:  

  • Mensagem de autenticação;  
  • Fonte da autenticação;  
  • Destino da autenticação;  
  • Autenticação do usuário;  
  • Confidencialidade;  
  • Token Phishing/replay.   

Recentemente, para o open banking foi definida a utilização do FAPI, ou Financial-grade API, que fornece diretrizes específicas para a implementação de serviços financeiros on-line.  

Financial-guide API (FAPI) – Gestão de consentimento 

O FAPI é um conjunto de especificações de schemas JSON, protocolos de segurança e privacidade que oferecem suporte para a utilização de serviços financeiros.  

De forma geral, o FAPI pode ser aplicado em serviços on-line que requeiram um alto nível de segurança, justamente porque é ele quem define as regras de utilização do OAuth 2.0 e OpenID Connect. Garantindo então, segurança à gestão de consentimento no setor financeiro, por exemplo.  

Além disso, o FAPI é uma alternativa segura ao compartilhamento de senha do usuário normalmente exigido em soluções que utilizam screen scraping, que é uma técnica de extração de dados, geralmente associada à recolha programática de dados visuais a partir de uma origem e comumente utilizada nas soluções pré-open banking 

Essa prática acaba criando uma vulnerabilidade na segurança, que é exatamente o contrário do que propõe o open banking, reforçando a necessidade de utilização de um modelo de API com dados estruturados. Além disso, recomenda-se também a utilização de um token como o OAuth 2.0 

A OpenID Foundation, uma organização internacional sem fins lucrativosvoltada para desenvolvedores, fornecedores e usuários, tem como objetivo auxiliar a comunidade fornecendo a infraestrutura necessária, ajudando a promover a adoção ampliada do OpenID, que é um sistema de identificação, no qual a identidade do utilizador é dada por um token que pode ser verificado por qualquer servidor utilizando o protocolo. 

Portanto, grande parte das informações apresentadas até o momento em relação à utilização do FAPI no open banking, foram retiradas do portal do OpenIDIsso porque, para corrigir a baixa eficiência do screen scraping, é recomendado o uso de modelos REST / JSON protegido por OAuth, para permitir que:  

  • as aplicações utilizem os dados armazenados na conta financeira, 
  • as aplicações interajam com a conta financeira e 
  • os usuários controlem as configurações de segurança e privacidade. 

Devem ser consideradas contas de banco comercial e de investimento, bem como contas de seguros e de cartão de crédito. 

Os principais benefícios do Financial-grade API são: 

  1. As especificaçõessão claras de ponto a ponto, para que os desenvolvedores possam utilizá-la como uma “lista de verificação”; 
  2. Requer uma série de testes que tem como objetivo garantir que o software seja seguro epossua interoperabilidade;  
  3. Padrões definidos paraproteger interações complexas (por exemplo, fluxos AuthZ desacoplados via CIBA e gestão de consentimento).  

Os desenvolvedores podem utilizar as diretrizes do FAPI para construir APIs seguras de open banking para: 

 – Aplicações que usem o padrão JSON para fornecer níveis de acesso a dados financeiros armazenados em contas.  

 – Aplicativos que utilizam uma interface de programa baseada em padrões (REST) ​​para compartilhamento de dados financeiros entre bancos, instituições e terceiros. 

 – Controle de segurança para usuários e configurações de privacidade a serem implementados de forma consistente com padrões abertos (OAuth) e provedores (OpenID Connect). 

De acordo com o portal do OpenID, esse momento nos permite aprofundar melhor nas questões do FAPI, que foi originalmente pensada para o uso no open banking, mas que está tendo seu uso expandido para outros casos de alta segurança.  

O FAPI acaba se relacionando diretamente com o uso do OAuth no open banking e também com características proeminentes nas especificações de autenticação de backchannel iniciada pelo cliente (CIBA), como vamos ver em detalhes, abaixo:  

OAuth 2.0 

Aqui estamos falando sobre um framework aberto para autorização, que muito provavelmente já foi utilizado pela maioria dos usuários da internet, já que ele permite realizar login em sites de terceiros utilizando, por exemplo, a sua conta Google ou Facebook, sem expor a sua senha, assim como a autenticação de APIs.  

O Auth 2.0 funciona da seguinte forma: 

  1. A aplicação pede permissão de acesso para um usuário, sem que para isso ela tenha acesso a alguma senha dele 
  2. O usuário pode conceder ou não o acesso à aplicação 
  3. Depois da permissão ser aceita, caso o usuário precise alterar a senha de acesso, a permissão continuará válida para a aplicação  
  4. Caso necessário, a permissão dada à aplicação pode ser revogada a qualquer momento também. 

Ao conceder autorização para essas aplicações, elas têm acesso limitado às informações de usuários através do protocolo HTTP. OAuth 2.0 fornece uma variedade de fluxos de mensagens padronizados baseados em JSON e HTTP, que são utilizados pelo OpenID Connect para fornecer os serviços de identidade.  

OpenID Connect

OpenID Connect, é um padrão controlado pela OpenID Foundation – que já mencionamos acima – e funciona como uma camada de autenticação sobre o OAuth 2.0, permitindo que os desenvolvedores autentiquem usuários em sites e aplicativos sem ter que possuir e gerenciar arquivos de senha. 

Assim, os clientes podem verificar a identidade do usuário final com base na autenticação realizada por um servidor de autorização e obter informações básicas de perfil sobre o usuário final de maneira interoperável e semelhante a REST. 

Esse conjunto de especificações é extensível, permitindo que os participantes usem recursos opcionais, como criptografia de dados de identidade, descoberta de provedores OpenID e gerenciamento de sessão, quando for necessário.  

O OpenID Connect permite que páginas web utilizando JavaScript e aplicativos móveis nativos iniciem fluxos de autenticação e recebam dados verificáveis sobre a identidade dos usuários conectados, fazendo assim a gestão de consentimento.  

Client Initiated Backchannel Authentication (CIBA) 

A autenticação de backchannel iniciada pelo cliente (CIBA) é umespecificação que faz parte do FAPI. Dessa forma, aplicações clientes podem obter um identificador válido para o usuário, sendo capazes de iniciar um fluxo de autenticação de usuários sem a interação do usuário final no dispositivo original. Esse fluxo envolve a comunicação direta do cliente com o provedor OpenID sem redirecionamento através do navegador do usuário (dispositivo de consumo). 

O CIBA, que foi escrito por um grupo da OpenID Foundation, caracteriza os fluxos como desacoplados. Ou seja, o dispositivo que acessa a API é diferente do dispositivo no qual ocorre a autenticação do usuário e a confirmação do consentimento. Permitindo iniciação do fluxo de autenticação em dispositivos com recursos limitados, como um POS por exemplo. 

Ela oferece suporte a um método seguro de desacoplamento de casos de uso de autenticação e autorização para reduzir os riscos associados à engenharia social ou ameaça interna. 

OPUS open banking

A segunda fase de implementação do open banking Brasil já começou dia 13/08! É a partir desse momento que começa o compartilhamento de dados, seguindo todas as regras e protocolos que comentamos nesse post.  

Se você quer estar preparado para fazer parte dessa inovação, que vai mudar completamente o mercado financeiro, pode contar com o OPUS Open Banking, que é uma solução pronta, segura, com implantação ágil e totalmente aderente às diretrizes do Banco Central e da LPGP. Acesse!