Autor: Wesley Santana
Co-autor: Alisson Neves
Integração B2B em sistemas que levam segurança a sério não deveria depender só de tokens/chaves de API e “boa fé”. À medida que você adiciona parceiros, ambientes e diferentes stacks, a API vira uma fronteira: mais caminhos de entrada, mais variações de configuração e mais pressão por controle de acesso consistente.
mTLS (mutual TLS) é uma forma pragmática de subir o nível: além do servidor provar quem é, o cliente também precisa provar sua identidade no handshake, ou seja, antes mesmo da sua API processar qualquer requisição.
TL; DR: mTLS adiciona autenticação no transporte (TLS). Não substitui autorização, rate limiting ou observabilidade, mas dificulta a exploração de acessos indevidos e ajuda a restringir o perímetro da API.
TLS: O que o cadeado no seu navegador de fato significa
Quando você chama uma API via HTTPS, ou acessa um site e vê o ícone do cadeado ao lado da URL no navegador, você está usando TLS por baixo. O TLS garante principalmente:
- Criptografia em trânsito (ninguém “lê” o tráfego no caminho).
- Integridade (o conteúdo não é alterado sem ser detectado).
- Autenticação do servidor (você valida que está falando com quem diz ser).
No TLS convencional, o servidor apresenta um certificado, e o cliente valida a cadeia de certificação até uma CA (Certificate Authority, Autoridade Certificadora) confiável. Quando a validação do certificado é feita corretamente, o TLS mitiga ataques do tipo man-in-the-middle, porque o cliente autentica o servidor antes de estabelecer o canal seguro.
O que muda no mTLS
No mTLS, o servidor também exige que o cliente apresente um certificado. Ou seja, o servidor autentica o cliente durante o handshake e a requisição só chega na aplicação se o cliente superar essa barreira.
Isso é especialmente útil quando:
- você quer limitar o acesso à API apenas a clientes autorizados.
- você quer combinar camadas, como mTLS + IP allowlist + token, para reduzir a superfície de ataque.
- você quer que sua infraestrutura filtre conexões antes mesmo de rodar validações de aplicação.
O que mTLS resolve bem (e o que NÃO resolve)
Resolve bem:
- Barreira pré-aplicação: a conexão pode ser bloqueada no handshake, antes mesmo de chegar à aplicação.
- Identidade forte: você adiciona autenticação baseada em certificado + chave privada.
- Reduz abuso de credenciais expostas: ter acesso apenas ao token não basta se a conexão exige o certificado do cliente.
Não resolve:
- Comprometimento do cliente: se a máquina/app do cliente for comprometida e a chave privada estiver acessível, o atacante pode usar o certificado.
- Autorização: mTLS autentica “quem é”, não “o que pode fazer”.
Em outras palavras: mTLS eleva o custo do ataque e restringe quem consegue estabelecer conexão com a API, mas não é bala de prata. O cliente continua responsável por manter uma gestão segura de segredos (tokens, certificados e chaves privadas).
mTLS na prática: como normalmente é implementado
Em integrações reais, o desenho costuma ser:
- Um API Gateway / Load Balancer estabelece o canal seguro de comunicação e valida o certificado do cliente.
- Só então o tráfego segue para os serviços internos.
- A aplicação mantém uma segunda camada de controle, como chave de API ou token (JWT/OAuth), para autorização, escopo e auditoria.
Esse modelo dá o melhor dos dois mundos:
- mTLS filtra conexões antes da requisição chegar à API.
- Chave de API/token decide o que aquele cliente pode fazer e registra trilha de auditoria.
Conceitos e terminologias
Quando falamos de mTLS, muitos termos técnicos surgem. Para evitar confusão, aqui vai um guia rápido sobre os principais conceitos:
CA (Certificate Authority / Autoridade Certificadora)
Entidade (ou cadeia de entidades) responsável por assinar certificados. O cliente/servidor valida um certificado verificando a cadeia de assinatura até uma CA confiável.
Certificado (Client/Server Certificate)
Arquivo público, geralmente com extensões .crt ou .cer, que contém a chave pública e metadados (identidade, validade, etc.), assinado por uma CA. Pode ser compartilhado com parceiros de integração, suporte técnico, times internos e qualquer parte que precise validar o certificado ou a cadeia de certificação. Se for vazado, o risco costuma ser baixo: em geral expõe apenas metadados (domínios, nomes de ambiente, emissor), mas não concede acesso sem a chave privada.
Private Key (Chave privada)
Chave usada para provar posse do certificado, geralmente presente em arquivos com a extensão .key ou .pem. Não deve ser compartilhada com ninguém, em hipótese alguma, nem mesmo com o parceiro com quem será feita a comunicação com mTLS. Se vazar, o risco é crítico: quem tiver a chave privada pode se passar pela integração e autenticar no mTLS como se fosse o titular do certificado, até que o certificado seja revogado e a chave rotacionada.
CSR (Certificate Signing Request)
Não é o certificado em si, mas um pedido de emissão de certificado que contém a chave pública e os dados de identificação, assinado com a chave privada correspondente. Deve ser compartilhado com o parceiro para emissão dos certificados.
PEM (extensão .pem)
Formato de codificação, com cabeçalho e rodapé, usado para representar certificados, CSRs, cadeias e também chaves privadas. Pode ser compartilhado apenas quando o conteúdo for certificado, CSR ou cadeia (por exemplo, quando contém BEGIN CERTIFICATE ou BEGIN CERTIFICATE REQUEST). Não deve ser compartilhado se contiver chave privada (por exemplo, BEGIN PRIVATE KEY, BEGIN RSA PRIVATE KEY ou BEGIN EC PRIVATE KEY). Se vazado, o risco varia conforme o conteúdo: um PEM com certificados/CSR tende a expor apenas metadados; um PEM com chave privada é equivalente a vazamento de credencial e é crítico.
Na Delfinance, uma vez gerado os certificados públicos, estes são enviados via .pem, contendo única e exclusivamente o certificado público.
Segurança como requisito: mTLS nas APIs da Delfinance
Nas APIs da Delfinance, o mTLS é obrigatório em qualquer integração. Isso reflete uma escolha de produto: segurança não é “configuração opcional”, é requisito obrigatório. Para quem se integra conosco, o ganho está em mais previsibilidade e confiança. E para quem opera em escala, significa uma plataforma preparada para parcerias robustas, com controles consistentes desde o primeiro contato com a API.
Se você quer se integrar com a Delfinance usando mTLS, o caminho mais rápido é seguir o nosso guia oficial de emissão e teste do certificado: visite a nossa documentação!
Se você ainda não é cliente, e quer iniciar uma conversa com nosso time e receber o passo a passo para virar parceiro e integrar com segurança e robustez, comece por aqui:
Leituras recomendadas
Para evoluir a integração com uma visão mais completa de engenharia em sistemas financeiros, confira nossos outros artigos:
