Integrações com segurança: Autenticidade e integridade sem trafegar dados secretos

Em um blog post anterior, vimos como a autenticação com o usuário final pode ser feita sem trafegar a senha, usando propriedades criptográficas para provar que o usuário tem a informação sem precisar enviá-la na requisição.

Porém, não é só o usuário final que precisa provar sua identidade. Sistemas corporativos frequentemente precisam se comunicar com APIs de parceiros, fornecedores, e até produtos internos que ficam em redes diferentes, necessitando uma autenticação para trafegar dados importantes de forma segura. Nesse cenário, não há um usuário final inserindo uma senha que só ele conhece, mas sim um sistema automatizado fazendo as requisições.

Nesse cenário, uma forma tentadora de autenticar chamadas é com um token fixo, onde um texto secreto conhecido por ambos os lados é enviado em toda requisição, pois sua configuração é rápida, tem custo baixo e exige pouca expertise técnica. Contudo, cada requisição que carrega essa informação é uma chance de vazamento, seja por logs, inspeção de tráfego, ou simples erro humano.

Quando pensamos em segurança de integração, vale separar três propriedades: confidencialidade (ninguém lê a mensagem sem autorização), integridade (ninguém altera a mensagem) e autenticidade (garantia sobre quem enviou a mensagem). Fazer todas as requisições por https já cuida da confidencialidade no transporte, mas não resolve sozinho a integridade nem a autenticidade.

É aí que entram mecanismos como o HMAC, onde cada lado da integração gera um hash da informação sendo trafegada e um segredo compartilhado que nunca trafega na rede. A ideia principal é não enviar o dado secreto, mas sim uma evidência calculada a partir dele (o hash), suficiente para demonstrar posse da chave de API, mas insuficiente para reconstruir a chave. Assim, um agente não autorizado que interceptar a requisição continua sem saber o segredo e não consegue forjar hashes de mensagens ilegítimas.

Como é possível uma informação derivada servir como prova de conhecimento do segredo e mesmo assim não permitir sua reconstrução?

Vamos imaginar que um professor propõe um exercício de aritmética a uma classe e quer que seus alunos consigam verificar a resposta sozinhos. Existe um jeito conveniente e que funciona até mesmo em uma videoconferência: o professor submete a resposta a alguma operação matemática que é facilmente reprodutível, porém difícil de reverter, e expõe essa informação derivada como uma forma fácil dos alunos verificarem sua resposta:

O hash é similarmente uma operação que deriva valores usáveis em verificações. Enquanto no nosso exemplo, há uma chance de 1 em 100000 de uma resposta errada ser aceita se os últimos cinco dígitos do cálculo coincidirem, um algoritmo de hash usa cálculos muito mais complexos que reduzem essa chance a praticamente zero. Assim, o servidor enviando a requisição consegue demonstrar que conhece o segredo dizendo que "a informação secreta, misturada com a mensagem e embaralhada desta maneira específica, resulta neste valor!". O servidor recebendo a mensagem consegue facilmente reproduzir o processo e verificar se chega no mesmo resultado, mas qualquer outro escutando a mensagem não consegue usar o valor derivado para deduzir a informação secreta. O hash não é meramente difícil de reverter: é um processo meticulosamente construído para que seja irreversível na prática.

Incluir a mensagem junto com a informação secreta no hash faz com que qualquer alteração na mensagem exija seu recálculo. Adicionalmente, é uma boa prática incluir um timestamp que indique quando a mensagem foi enviada para evitar que mensagens antigas sejam reenviadas por agentes mal-intencionados.

A abordagem com HMAC tem vantagens quanto à autenticidade (pois só quem conhece a chave secreta consegue gerar assinaturas corretas) e à integridade (qualquer bit alterado na mensagem faz a verificação falhar). E isso não precisa complicar a implementação técnica das aplicações; considere a solução em uma rede na AWS:

Usando o código em um Lambda Authorizer, precisamos de poucas linhas de código, e como o HMAC é um padrão comum, não exige escrita ou validação manual de operações matemáticas complexas. Em troca, elimina-se a superfície de ataque relacionada a credenciais fixas, e a rastreabilidade se torna mais simples, pois logs das requisições não revelam a chave secreta, facilitando a conformidade com políticas de least privilege. Graças ao AWS Lambda ser uma solução totalmente gerenciada, não ficamos limitados em escalabilidade.

Vale notar os cuidados necessários para a implementação. Como o HMAC ainda usa uma informação secreta, é importante que a sua criação e armazenamento sejam feitas de forma segura dos dois lados da integração, e o algoritmo de hash precisa ser o mesmo nos dois lados da chamada, incluindo os dados e a formatação usada nos cálculos.

Há outras abordagens além do HMAC, adereçando requisitos diferentes. Por exemplo, a abordagem com chaves assimétricas adiciona segurança na criação e transmissão da informação secreta porque um dos lados da integração fornece sua chave pública, evitando a necessidade de combinar um segredo compartilhado. Porém, isso também significa que só este lado que publicou sua chave consegue enviar mensagens, tornando a estratégia preferível em integrações assimétricas com um sistema publicando notificações para vários.

Estas abordagens também podem ser combinadas com uma estratégia chamada dataless, onde a própria requisição não trafega nenhuma informação sensível ou que pode identificar o usuário ou algum recurso; neste caso, a requisição inclui apenas identificadores opacos que o recebedor consegue usar em outras integrações que ele considera mais seguras.

Dessa maneira, diferentes estratégias existem com suas próprias características, e conhecer as opções é importante para desenhar a melhor solução para uma integração. Porém, lembre-se que em aplicações de alto valor, usar assinaturas criptográficas ao invés de credenciais fixas e abertas é mais do que uma recomendação ou uma segurança adicional; é praticamente uma exigência para integrações resilientes, auditáveis e escaláveis.

Muralis insigths | Escrito por: Rafael Takahashi, Arquiteto de Software.