Projetar sistemas seguros é uma tarefa difícil para nós, arquitetos. Cada decisão arquitetural pode gerar brechas no sistema, que irão afetar atributos de qualidade, segurança e confidencialidade. Uma decisão arquitetural que praticamente todo projeto de software passa, é a utilização de componentes de autenticação e autorização. Sistemas que implementam as especificações oAuth2 e OpenId são escolhas “seguras”. Com a chegada do Open Banking, temos especificações de protocolos que adicionam camadas extras de segurança para os sistemas.

Umas das bases do Open Banking é aumentar a segurança na solicitação de autorizações para comunicação entre dois sistemas. O objetivo é mitigar brechas que os fluxos de autorização trazem, como vazamento de credenciais, ataques de replay e mix-up.

Neste artigo, vamos apresentar algumas especificações do Open Banking, que incrementam o nível de segurança na comunicação entre sistemas, e que podem ser empregadas em qualquer solução que demande um incremento de segurança.

Autorização entre sistemas via mTLS

Ao utilizar o fluxo client credentials, as credenciais para solicitar autorização podem ser mantidas dentro do aplicativo. Isso é uma brecha de segurança porque qualquer credencial compilada e distribuída com o aplicativo, não é realmente secreta. A credencial pode ser extraída do aplicativo com relativa facilidade. Uma pessoa mal intencionada, de posse destas credenciais, pode iniciar um roubo de dados do sistema.

Para mitigar essa falha de segurança, o uso de Mutual TLS (mTLS) é uma ótima recomendação. Credenciais de acesso não são mais enviadas na requisição. As credenciais de acesso são substituídas por um certificado SSL reconhecido pelo servidor. Então, cada cliente que necessita requisitar autorizações para um servidor, deve enviar a cadeia de certificados reconhecida pelo servidor para receber a autorização. Contudo, no modelo mTLS o cliente também deve reconhecer a autoridade do certificado do servidor. Assim, ambos os lados da requisição garantem sua identidade e nenhum secret é transmitido. Mas é importante ressaltar que em ambos os fluxos, client credentials e Mutual TLS, devemos utilizar um cofre para armazenar a secret ou o certificado.

Registro de clientes dinâmicos (DCR)

É normal que aplicações mobile requisitem dados para serviços HTTP (APIs). Para garantir essa comunicação é necessário que os serviços HTTP “confiem” em quem está fazendo a requisição, no caso, o aplicativo mobile. Uma forma é utilizar o fluxo client credentials como forma de alcançar essa “confiança” e solicitar autorizações. Contudo, manter essa secret dentro do aplicativo é um risco de segurança, além de que todas as solicitações de autorização serão emitidas para um único cliente cadastrado no provedor de identidade.

Utilizar o registro de clientes dinâmicos (DCR) permite que cada cliente mobile solicite o registro dentro do provedor de identidade. Essa solicitação de registro é feita com o auxílio do fluxo mTLS para garantir que a requisição de registro é “confiável”. Uma vez que o registro deste cliente é realizado, temos um novo client ID para solicitar tokens de acesso. Com isso, toda requisição de token passa a ser rastreável a um cliente específico.

Requisições de autorização seguras (JAR E JARM)

Para que um cliente público, como um site SPA, precise fazer uma requisição para recursos protegidos como uma API HTTP, este cliente precisa solicitar uma autorização com um servidor de identidade. Neste cenário é recomendado que seja utilizado o fluxo de autorização authorization code com PKCE. O problema é que a resposta deste fluxo é enviada aberta, possibilitando que um atacante possa ler ou manipular esta resposta.

Este novo modo de resposta, JARM (JWT Secured Authorization Response Mode) entrega uma resposta de autorização empacotando os parâmetros dentro de um JWT assinado e opcionalmente criptografado pelo provedor de identidade. Assim um atacante (man in the middle) não consegue alterar facilmente os parâmetros da resposta. JARM também previne ataques mix-up pois dentro do JWT de resposta temos os parâmetros de issuer, utilizado pelo cliente para garantir que a resposta veio do servidor de autorização correto.

O grupo de trabalho FAPI, tem trabalhado para desenvolver uma especificação oAuth com alto grau de segurança para sistemas financeiros (Open Banking). Contudo, algumas das especificações criadas podem ser utilizadas para incrementar a segurança e confidencialidade de qualquer arquitetura. Então, mesmo que seu sistema não seja da área financeira, estudar a especificação Open Banking pode trazer incrementos na sua arquitetura.

Como a EximiaCo pode lhe ajudar

Conheça a nossa consultoria e assessoria em Arquitetura de Software que atua na modernização de aplicações de forma segura e escalável, promovendo a evolução de seus sistemas com menor custo e risco. Se sua empresa quer promover a autonomia de seu time no desenvolvimento de aplicações seguindo as melhores práticas de segurança, conheça a capacitação in company Desenvolvimento de Software Seguro, que aborda as vulnerabilidades de segurança em aplicações para seu negócio crescer com mais segurança e confiança.