O blog da AWS

Suportando Autorização de APIs com provedores OIDC FAPI-Compliant para o Open Banking no Brasil utilizando o Amazon API Gateway

Por Lucas Lins, Arquiteto de Soluções na AWS
Enrico Bergamo, Arquiteto de Soluções especialista em Serverless na AWS
Paulo Aragão, Arquiteto de Soluções Sênior na AWS
Julio Carvalho, Arquiteto Principal de Segurança para o mercado Financeiro na AWS
Amanda Quinto, Arquiteta de Soluções da AWS

 

Introdução

Como comentado em um dos posts anteriores, o Open Banking, ou Sistema Financeiro Aberto, é a possibilidade de clientes de produtos e serviços financeiros permitirem o compartilhamento de suas informações entre diferentes instituições autorizadas pelo Banco Central (BACEN) e a movimentação de suas contas bancárias a partir de diferentes plataformas e não apenas pelo aplicativo ou site do banco, de forma segura, ágil e conveniente. O novo sistema trará autonomia e controle para o consumidor, e é o consumidor quem decide quando e com quem quer compartilhar seus dados financeiros. Isto significa que o compartilhamento só será possível através do seu consentimento à instituição detentora dos dados – após a autorização, aplicativos de terceiros que acessam, com segurança, os dados financeiros, podem ser oferecidos aos consumidores. Todo o processo se dará de forma padronizada através de determinações específicas emitidas pelos órgãos reguladores do Brasil, no caso o BACEN (Banco Central), e ocorrerá através da conexão de APIs permitindo uma comunicação rápida e confiável diretamente entre duas instituições.

Além disso, o BACEN publicou, no dia 23 de junho de 2020, a Circular 4.032 dispondo sobre a estrutura inicial responsável pela governança do processo de implementação do Open Banking no país. Tal estrutura é composta por três níveis, sendo:

  • I – Conselho Deliberativo: responsável por decidir sobre as questões necessárias para a implementação do novo sistema e propor ao BACEN os padrões técnicos do Open Banking;
  • II – Secretariado: responsável por organizar e coordenar os trabalhos;
  • III – Grupos Técnicos: encarregados de elaborar estudos e propostas técnicas para a implementação do ecossistema.

Essa estrutura é responsável por estabelecer e fornecer os requerimentos técnicos obrigatórios para que as instituições participantes façam parte do Open Banking. Alguns destes requerimentos tem como base as principais diretrizes definidas pela PSD2 (Payment Services Directive) na União Européia, como a autenticação de clientes através do protocolo de segurança mTLS, e a utilização de um perfil de segurança de nível mais elevado chamado FAPI (Financial-grade API). Por outro lado existem requerimentos que são específicos para o território brasileiro, como é o caso do certificado digital ICP-Brasil, que será utilizado para reforçar a segurança nas comunicações entre as entidades que irão compor o Open Banking.

No último post de nossa série sobre o Open Banking no Brasil, descrevemos o passo a passo de como os participantes do Open Banking podem utilizar o serviço Amazon API Gateway em conjunto com certificados digitais ICP-Brasil para exporem suas APIs e cumprirem o requerimento de autenticação TLS mútua (mTLS).

Neste post, descrevemos o passo a passo de como os participantes do Open Banking podem utilizar o serviço Amazon API Gateway para autorizar o acesso em suas APIs utilizando provedores de identidade OpenID Connect (OIDC) que seguem a conformidade da diretiva FAPI através de Lambda Authorizers,  cumprindo assim o requerimento de autorização das APIs.

 

Principais serviços AWS utilizados na arquitetura proposta

Exposição de APIs

O Amazon API Gateway é um serviço gerenciado que permite que desenvolvedores criem, publiquem, mantenham, monitorem e protejam APIs em qualquer escala com facilidade. APIs agem como a “porta de entrada” para aplicativos acessarem dados, lógica de negócios ou funcionalidade de seus serviços de back-end. Usando o API Gateway, você pode criar APIs do tipo RESTful e APIs do tipo WebSocket que habilitam aplicativos de comunicação bidirecionais em tempo real. O API Gateway dá suporte a cargas de trabalho que rodam em conteineres e serverless, assim como aplicativos da web.

Além do Console AWS, CLI, o AWS Cloudformation e o AWS SAM, o Amazon API Gateway também suporta a importação e exportação de APIs baseadas na especificação do OpenAPI, bem como possibilitando o uso de extensões do OpenAPI próprias do API Gateway, que serão utilizada nesta solução na definição de nossas APIs.

O Amazon API Gateway suporta a integração nativa de autorização baseada no Amazon Identity and Access Management (IAM) e Amazon Cognito. Também é possível usar os chamados Lambda Authorizers, que permitem que clientes criem funções Lambda e as associem com recursos específicos de suas APIs para realizar qualquer tipo de autorização customizada, seja ela baseada no enriquecimento de tokens JWT junto a headers adicionais da requisição, ou até mesmo implementando um fluxo de Basic Authentication.

Provedor OIDC

Para atendermos as necessidades de segurança do Open Banking no Brasil, é necessário que tenhamos não somente a parte de mTLS (TLS mútuo) como também um API desenvolvida com os perfis de somente-leitura do padrão FAPI. Este requerimento se dá para a fase 2 do Open Banking, sendo que a fase 3 irá requerer os perfis de leitura-escrita do padrão FAPI. Sendo assim, é necessário que os participantes do Open Banking implementem primeiro uma camada de mTLS, conforme descrita em nosso blog post anterior, e além disso também tenham um autorizador OIDC para implementar os perfis de segurança do FAPI. É nesta segunda camada, a de autorizador OIDC, que esta solução irá focar.

Importante: Para fins de demonstração e por proximidade com a comunidade Open Source, o provedor OIDC escolhido para esta demonstração é o node-oidc-provider, que permite que o desenvolvedor possa configurar todos fluxos OAuth desejados para autenticação, bem como tipos de tokens trafegados, seus escopos e claims, e também onde serão persistidos estes dados (ex. Amazon DynamoDB, Amazon ElastiCache Redis, ou Amazon DocumentDB). Neste exemplo, utilizaremos o fluxo de autenticação OAuth conhecido como Implicit Flow, que retorna para o usuário autenticado um ID Token no padrão JWT, e persistindo todos dados dos tokens e da sessão em memória. Este fluxo e a camada de persistência podem ser modificados seguindo a documentação do provedor OIDC, de acordo com a requerimento definido pelo Banco Central do Brasil (BACEN) para o Open Banking. Para consultar todos provedores OIDC FAPI-Compliant, você pode se referir a esta lista.

Para criarmos uma solução seguindo o AWS Well Architected Framework, vamos usar o AWS Fargate em conjunto com a solução Amazon ECS. O AWS Fargate é um mecanismo de computação serverless para contêineres que funciona com o Amazon Elastic Container Service (ECS) e com o Amazon Elastic Kubernetes Service (EKS). O uso de serviços com abordagem Serverless tem como proposta o foco no desenvolvimento de aplicativos, reduzindo a carga operacional com gerência de servidores. Assim, o participante do Open Banking foca na entrega de valor para o negócio.

A AWS oferece várias ferramentas para monitorar os recursos do Amazon ECS e responder a incidentes potenciais, como: Amazon CloudWatch, Amazon CloudWatch Logs, AWS CloudTrail e AWS Trusted Advisor. Se quiser saber mais como implementar estratégias de log na plataforma da AWS, veja esta documentação aqui.
Você deve coletar dados de monitoramento de todas as partes de sua solução da AWS para ser mais fácil realizar a depuração de uma falha de vários pontos (caso ocorra).

 

 

Arquitetura

A arquitetura de referência apresentada neste blog post considera a utilização dos serviços Amazon API Gateway, AWS Lambda, AWS Secrets Manager, e AWS Fargate.

Como peças centrais, temos:

  • Amazon API Gateway: para exposição das APIs definidas no Open Banking. Vale ressaltar que:
  • AWS Lambda:
    • Lambda Authorizer: Atrelado diretamente a cada recurso protegido do API Gateway para autorizar recursos baseado em regras específicas.
    • Recebe o token JWT no header de Authorization da requisição e reenvia diretamente para o provedor OIDC para validar sua assinatura a escopos autorizando o acesso ao recurso.
    • Backend: Simulação de um recurso protegido pelo API Gateway.
  • AWS Fargate: onde o provedor OIDC será hospedado e executado.
  • AWS Secrets Manager: para armazenar a porção pública das chaves JWK do provedor OIDC.

Segue o diagrama da arquitetura e passo-a-passo do fluxo de autorização de uma requisição realizado por um participante do Open Banking.

 

 

  1. No primeiro momento, o usuário da solução de Open Banking terá que se autenticar na solução. Para isso a aplicação irá (a) redirecionar a chamada para o Application Load Balancer do provedor OIDC. Ao chegar no provedor OIDC, ele irá autenticar o usuário e trocar as credenciais por um token JWT.
  2. O provedor OIDC devolve o token JWT de access/ID para o cliente. Neste token também existem campos que definem quais são os escopos que o usuário tem permissão de acesso.
  3. A aplicação então chama um recurso protegido da API passando o access/ID token como um Bearer token no header de Authorization da requisição.
  4. O Amazon API Gateway utiliza um Lambda Authorizer para verificar a assinatura do token JWT, utilizando a solução do provedor OIDC, e garante que o token esteja íntegro. Ele também valida os escopos que foram passados, e permite ou bloqueia o acesso ao recurso protegido conforme essa validação.
  5. O Lambda Authorizer recupera então a parte pública da chave JWK armazenada no AWS Secrets Managerpara verificar a assinatura do token. Essa chave pública foi armazenada no AWS Secrets Manager durante a configuração da solução detalhada aqui.
  6. O Lambda Authorizer usa a chave recuperada do AWS Secrets Manager para verificar a assinatura do token JWT no provedor OIDC.
  7. Caso o token seja verificado com sucesso, e contenha os escopos necessários para acessar o recurso da API, o Lambda Authorizer retorna uma credencial temporária do IAM permitindo que o API Gateway invoque o recurso protegido (AuthZ).
  8. Por fim, o Amazon API Gateway invoca o recurso protegido e executa a ação pedida pela aplicação.

Conclusão

Para o ano de 2021, o Open Banking é o grande tema para a indústria brasileira de serviços financeiros. No entanto, é apenas o começo de uma transformação que poderá habilitar uma maior integração entre os setores bancário, de seguros, energia e telecomunicações. A democratização das APIs irá estimular a competição no setor, permitindo a ampliação da oferta de produtos e serviços financeiros e o surgimento de novos participantes nestes mercados.

Usando os serviços da AWS os participantes do Open Banking possuem o controle e a confiança necessárias para executar seus negócios com segurança no ambiente de computação em nuvem mais flexível e seguro disponível. Além disso, usando a AWS, pagam apenas pelos serviços que usam.

A arquitetura apresentada contempla a parte de segurança para atendimento do requerimento de autorização de acesso a APIs utilizando provedores de identidade OpenID Connect (OIDC) FAPI-compliant. Os próximos blog posts aprofundarão o nível de detalhamento técnico sobre outros requerimentos obrigatórios para a implementação do Open Banking em território nacional.

 

Artefatos

Para facilitar o entendimento e implantação da solução, compartilhamos os seguintes códigos-fonte no GitHub:

Mais Conteúdo

[Blog Post] Suportando Mutual TLS (mTLS) Utilizando Certificados do ICP-Brasil para o Open Banking no Brasil utilizando o Amazon API Gateway

 

 

 

Sobre os autores

Lucas Lins é Arquiteto de Soluções na AWS, com mais de 15 anos de experiência em arquitetura de software e desenvolvimento de soluções envolvendo sistemas empresariais e de missão crítica. Especialista em FSI e Serverless, Lucas atua com ênfase no segmento de Startup, orientando e suportando os clientes em sua jornada na nuvem.

 

 

 

Enrico Bergamo é Arquiteto de Soluções especialista em Serverless na AWS para a América Latina, e atua auxiliando clientes de diversos segmentos em suas jornadas de modernização de aplicações na nuvem. Com mais de 10 anos de experiência em Arquitetura e Desenvolvimento de Sistemas, e DevOps, Enrico atuou diretamente com diversas empresas na definição, implementação, e implantação de diversas soluções corporativas.

 

 

 

Paulo Aragão é um Arquiteto de Soluções Sênior que trabalha há mais de 20 anos com clientes Enterprise. Ampla experiência em Computação de Alta Performance (HPC), atualmente dedica seus dias a ajudar clientes a inovarem através do uso de serviços de IA e ML na nuvem AWS. Apaixonado por música e mergulho, você pode encontra-lo em vídeos de covers musicais no Youtube ou no fundo do mar. No seu tempo livre, gosta de ler livros, jogar World of Warcraft, e cozinhar para os amigos.

 

 

 

Julio Carvalho é Principal Security Architect para o mercado financeiro da América Latina na AWS. Há 17 anos atuando com Segurança, ele ajuda clientes a criar arquiteturas seguras e a resolver desafios de proteção e de conformidade nas suas jornadas na nuvem. Já visitou 28 países, mas ainda não se decidiu sobre onde está a melhor comida.

 

 

 

Amanda Quinto é Arquiteta de Soluções da AWS no time de Public Sector com foco em Nonprofits Organization. Amanda já atuou em diversos projetos ajudando os times de desenvolvimento e sustentação em arquitetar sistemas resilientes e escaláveis. Formada pela FATEC-SP, é entusiasta de Devops, machine learning, e apaixonada por Kombis.