mTLS: autenticação segura entre serviços

O que é mTLS e como difere do TLS unidirecional

Autenticação mútua como fundamento de comunicação segura entre serviços

O TLS convencional autentica apenas o servidor para o cliente — o cliente verifica o certificado do servidor mas o servidor não verifica quem é o cliente, confiando em mecanismos de autenticação na camada de aplicação como tokens JWT ou API keys. O mTLS (mutual TLS) adiciona autenticação bidirecional: tanto o servidor quanto o cliente apresentam certificados X.509 durante o handshake, e ambos verificam a validade e confiança dos certificados da outra parte antes de estabelecer a conexão. Isso significa que um serviço malicioso ou comprometido sem o certificado correto não consegue nem mesmo estabelecer conexão TCP autenticada com outros serviços, independentemente de possuir tokens ou credenciais. Em arquiteturas de microsserviços, o mTLS é a base do modelo zero trust onde nenhuma comunicação interna é implicitamente confiável.

Certificados de cliente — como funcionam

A mecânica da autenticação por certificado no lado do cliente

Um certificado de cliente é um arquivo X.509 emitido para uma entidade específica (um serviço, um usuário ou um dispositivo) assinado por uma Certificate Authority confiável, contendo informações de identidade como Common Name e Subject Alternative Names. Durante o handshake mTLS, após o servidor apresentar seu certificado, ele envia um CertificateRequest ao cliente exigindo que ele também apresente um certificado. O cliente responde com seu certificado e uma assinatura digital que prova que possui a chave privada correspondente — sem a chave privada, um atacante não consegue se passar pelo cliente mesmo possuindo o certificado público. O servidor verifica se o certificado do cliente foi assinado por uma CA confiável e se não está na lista de revogação (CRL ou OCSP), completando a autenticação mútua.

Certificate Authority — emitindo e gerenciando certificados

A infraestrutura de PKI que sustenta o mTLS em produção

Uma Certificate Authority interna é necessária para mTLS em microsserviços, pois certificados públicos de Let's Encrypt são projetados para autenticar domínios públicos, não identidades de serviços internos. Ferramentas como CFSSL da Cloudflare, Vault PKI Secrets Engine e step-ca permitem criar e operar uma CA interna com emissão automatizada de certificados de curta duração para serviços. Certificados de curta duração (horas ou dias em vez de anos) são preferidos pois reduzem a janela de exposição em caso de comprometimento de chave, mas exigem renovação automática bem configurada. A hierarquia de CA — Root CA offline e Intermediate CA online para emissão diária — é uma prática de segurança que protege a Root CA de exposição mesmo se a Intermediate CA for comprometida.

mTLS em microsserviços — zero trust na prática

Implementando autenticação baseada em identidade de serviço

Em microsserviços, cada serviço recebe uma identidade criptográfica única representada por seu certificado mTLS — o SPIFFE (Secure Production Identity Framework For Everyone) padroniza esse conceito com SVIDs (SPIFFE Verifiable Identity Documents) como URIs únicos por serviço. A identidade do serviço baseada em certificado mTLS permite políticas de autorização granulares: o serviço A pode chamar o serviço B apenas nos endpoints de leitura, enquanto o serviço C tem acesso total — tudo verificado criptograficamente sem depender de IPs ou tokens. Essa abordagem elimina problemas de lateral movement após um comprometimento, pois um serviço atacado não consegue se autenticar como outro serviço sem seu certificado específico. Service accounts do Kubernetes podem ser mapeadas para identidades SPIFFE, integrando a gestão de identidades com a plataforma de orquestração.

Service mesh — Istio, Linkerd e mTLS automático

Delegando a complexidade do mTLS para a infraestrutura de rede

Service meshes automatizam completamente o mTLS entre serviços injetando um sidecar proxy (Envoy no Istio, linkerd-proxy no Linkerd) em cada pod, que intercepta todo o tráfego de saída e entrada e aplica mTLS transparentemente sem qualquer mudança no código da aplicação. O Istio usa sua própria CA (Istiod) para emitir e rotacionar certificados automaticamente para todos os serviços no mesh, com política configurável de mTLS STRICT que recusa conexões sem certificado válido. O Linkerd tem uma arquitetura mais simples que o Istio, com menor overhead de proxy e operação mais fácil, sendo preferido em ambientes que não precisam de todo o conjunto de funcionalidades do Istio. A observabilidade incluída nos service meshes — métricas de latência, error rate e tráfego por par de serviços — é um benefício adicional além do mTLS.

Rotação de certificados sem downtime

Renovando certificados em produção sem interromper comunicação entre serviços

Certificados de curta duração exigem rotação frequente e automatizada, o que pode causar downtime se não implementado corretamente — o serviço que recebe conexões deve aceitar tanto o certificado antigo quanto o novo durante a transição. A estratégia de trust bundle expansion adiciona o novo certificado CA ao bundle de confiança de todos os serviços antes de emitir novos certificados de folha, garantindo que conexões com certificados emitidos pela nova CA sejam aceitas antes da transição. Ferramentas como cert-manager no Kubernetes automatizam a renovação de certificados com lead time configurável antes da expiração, acionando renovação quando o certificado está a X dias de vencer. Testar o processo de rotação regularmente em ambiente de staging é essencial para garantir que o mecanismo automático funciona antes de uma expiração emergencial em produção.

mTLS vs API keys vs JWT — quando usar cada um

Escolhendo o mecanismo de autenticação certo para cada contexto

API keys são simples de implementar mas são secrets estáticos que não expiram automaticamente, podem ser copiados e não identificam o chamador criptograficamente — adequadas para integrações simples de terceiros mas inadequadas para comunicação interna crítica. JWTs são tokens de curta duração com claims de identidade verificáveis via assinatura, mas dependem de que o serviço de emissão esteja disponível e que os tokens sejam transmitidos e armazenados com segurança. O mTLS provê identidade criptográfica forte sem depender de um servidor de identidade em tempo de execução — a verificação é local a partir do bundle de confiança — e garante tanto autenticação quanto criptografia em camada de transporte. A combinação mais robusta para microsserviços usa mTLS para autenticação de serviço a serviço e JWTs curtos para propagação da identidade do usuário final através da cadeia de chamadas.

Debugging de problemas com mTLS

Diagnosticando falhas de handshake e problemas de certificado em produção

Falhas de handshake mTLS geralmente resultam em erros como "certificate verify failed", "unknown ca" ou "certificate expired" nos logs, e o primeiro passo de diagnóstico é verificar se os certificados em uso estão dentro do prazo de validade e foram emitidos pela CA correta. O openssl s_client com a flag -cert e -key permite simular uma conexão mTLS de linha de comando, apresentando o certificado do cliente e exibindo detalhes do handshake e erros de verificação. Verificar se o trust bundle do servidor inclui a CA que emitiu o certificado do cliente é o erro mais comum — CAs intermediárias devem estar incluídas no bundle ou na chain do certificado. Ferramentas de service mesh como istioctl proxy-status e linkerd diagnostics permitem inspecionar o estado dos certificados e conexões mTLS em cada sidecar sem acesso direto aos pods.

mTLS com Envoy proxy

Configurando autenticação mútua no proxy mais usado em service meshes

O Envoy é o proxy de dados usado em Istio, AWS App Mesh e vários outros service meshes, configurado via xDS APIs dinâmicas que permitem atualizar certificados e políticas de TLS sem reiniciar o proxy. A configuração de downstream_tls_context define como o Envoy autentica clientes que se conectam a ele, especificando a CA de confiança e se o certificado de cliente é obrigatório (require_client_certificate). A configuração de upstream_tls_context define como o Envoy se autentica para serviços que ele chama como cliente, especificando qual certificado apresentar. O SDS (Secret Discovery Service) do Envoy integra com sistemas como Vault e cert-manager para entregar certificados dinamicamente sem precisar reiniciar o proxy ou montar arquivos em disco.

Conclusão — mTLS como fundamento do zero trust em microsserviços

Identidade criptográfica como a única autenticação confiável entre serviços

O mTLS transforma a comunicação entre serviços de um problema de confiança implícita para uma verificação criptográfica explícita, sendo a implementação mais robusta do princípio zero trust em arquiteturas de microsserviços. Combinado com service mesh para automação operacional e certificados de curta duração para minimizar impacto de comprometimento, o mTLS é a base de segurança sobre a qual políticas de autorização granulares podem ser construídas. Continue em: Fundamentos obrigatórios antes de produção.