Padrões de Implementação do TLS Mútuo (mTLS)

O TLS padrão autentica somente o servidor perante o cliente por meio de um certificado. O TLS mútuo (mTLS) amplia esse mecanismo: ambas as partes apresentam e verificam certificados. O cliente apresenta um certificado de cliente depois que o servidor o solicita (por meio de CertificateRequest no estabelecimento de conexão TLS). O servidor verifica o certificado do cliente em relação a uma CA confiável. O mTLS é a base das redes de confiança zero: em vez de depender da segurança do perímetro da rede, os serviços autenticam uns aos outros de forma criptográfica em cada conexão. Malhas de serviços como Istio, Linkerd e Consul Connect implementam o mTLS de forma transparente entre microsserviços.

O estabelecimento de conexão mTLS amplia o TLS 1.3 da seguinte forma: depois do ServerHello e do certificado/mensagem de conclusão do servidor, o servidor envia uma mensagem CertificateRequest especificando autoridades certificadoras e algoritmos de assinatura aceitáveis. O cliente responde com seu Certificado (a cadeia de certificados do cliente) e CertificateVerify (uma assinatura sobre o histórico de mensagens, usando a chave privada do cliente). O servidor verifica a cadeia de certificados do cliente em relação ao seu repositório de CA confiáveis e valida a assinatura CertificateVerify. Se ambas as verificações forem aprovadas, a conexão será mutuamente autenticada. O cliente não pode falsificar um CertificateVerify sem a chave privada correspondente ao certificado.

Em ambientes de malha de serviços, os certificados de cliente normalmente são emitidos por uma CA interna. O Istio usa SVIDs do SPIFFE (Secure Production Identity Framework for Everyone): cada carga de trabalho recebe um certificado com um SAN de URI SPIFFE (Subject Alternative Name), como spiffe://cluster.local/ns/default/sa/payment-service. Esses certificados têm curta duração (24 horas) e são alternados automaticamente pelo plano de controle da malha (istiod). Em mTLS voltado ao usuário (por exemplo, VPN corporativa e clientes de API), os certificados podem ser emitidos por uma CA corporativa, ter períodos de validade mais longos e ser distribuídos por meio do MDM (Mobile Device Management) aos dispositivos dos funcionários.

A verificação de mTLS no servidor envolve várias etapas: (1) Validação da cadeia — verificar se o certificado do cliente se encadeia até uma CA raiz confiável no repositório de CA de clientes do servidor. (2) Verificação do período de validade — garantir que o certificado não esteja expirado nem ainda inválido. (3) Verificação de revogação — verificar por meio de OCSP ou CRL se o certificado não foi revogado. (4) Correspondência de SAN/CN — extrair a identidade declarada do SAN do certificado (URI SPIFFE, nome DNS ou endereço de e-mail). (5) Autorização — verificar se a identidade autenticada está autorizada a acessar o recurso solicitado. As etapas 4 e 5 exigem lógica no nível da aplicação, além da configuração básica do TLS.

Certificados de curta duração eliminam a necessidade de revogação explícita: se um certificado expirar em 24 horas, o comprometimento terá uma janela de impacto limitada. A alternância exige: (1) Pré-alternância — emitir um novo certificado antes que o antigo expire (alternar quando 80% do período de validade tiver transcorrido). (2) Troca sem indisponibilidade — o serviço deve aceitar os certificados antigo e novo durante a janela de transição. (3) Recarga ordenada — a pilha TLS deve recarregar as credenciais sem interromper as conexões existentes (nginx: nginx -s reload; Envoy: atualização dinâmica de certificados xDS). A SPIFFE Workload API (implementada pelo SPIRE) automatiza a distribuição e a alternância de certificados por meio de uma API de soquete de domínio Unix.

O Istio implementa mTLS de forma transparente por meio de proxies auxiliares do Envoy injetados em cada pod. O plano de controle (istiod) atua como uma CA usando um certificado intermediário assinado pela CA raiz da malha. O proxy auxiliar de cada pod recebe um SVID do SPIFFE por meio da API SDS (Serviço de descoberta de segredos). As políticas PeerAuthentication configuram o modo mTLS: STRICT (mTLS obrigatório), PERMISSIVE (mTLS e texto simples aceitos, para migração) ou DISABLE. Os recursos AuthorizationPolicy definem quais serviços podem se comunicar, com verificação baseada na identidade SPIFFE do certificado do cliente. Isso implementa confiança zero dentro do cluster sem alterações no código da aplicação.

Para clientes de API externos, o mTLS fornece uma autenticação mais forte do que chaves de API ou tokens OAuth. O cliente mantém uma chave privada em armazenamento seguro (HSM, armazenamento de chaves do sistema operacional ou chave de software protegida por frase-senha). O certificado do cliente é fixado à CA esperada pelo ponto de extremidade da API. Cada solicitação à API é autenticada na camada TLS — não é necessário um cabeçalho Authorization separado. O API Shield da Cloudflare, os certificados de cliente do AWS API Gateway e o mTLS de contas de serviço do Google Cloud implementam esse modelo. Uma chave de API comprometida pode ser usada de qualquer lugar; uma chave privada mTLS comprometida exige também o roubo do dispositivo que executa o cliente.

As implantações de mTLS enfrentam vários desafios operacionais. (1) Distribuição de certificados — entregar certificados de cliente com segurança a todos os serviços, especialmente em ambientes dinâmicos nos quais os pods aumentam e diminuem de quantidade. (2) Comprometimento da CA — a CA interna é um alvo de alto valor; se for comprometida, todos os certificados de serviço serão invalidados. CAs protegidas por HSM e CAs raiz offline reduzem esse risco. (3) Depuração — o tráfego mTLS criptografado é opaco para ferramentas de depuração padrão; é necessária observabilidade da malha de serviços (Jaeger, Kiali). (4) Compatibilidade com dispositivos intermediários — os proxies de inspeção TLS interrompem o mTLS, a menos que sejam configurados explicitamente para encaminhar os certificados de cliente. (5) Incidentes de expiração de certificados — uma falha na rotação pode causar interrupções completas dos serviços.

O SPIFFE (Estrutura de identidade segura para produção para todos) define um padrão para a identidade de cargas de trabalho usando SVID X.509. O SPIRE (Ambiente de execução do SPIFFE) é a implementação de referência. O servidor SPIRE atua como autoridade de registro e CA. Os agentes SPIRE são executados em cada nó, atestam a identidade da carga de trabalho usando atestadores de nó (identidade de instância da AWS, JWT da conta de serviço do Kubernetes, TPM) e atestadores de carga de trabalho (PID do Unix, metadados do ambiente de execução de contêineres). A API de carga de trabalho entrega SVID às cargas de trabalho por meio de um soquete de domínio Unix usando uma API gRPC simples. O SPIRE integra-se ao Envoy, ao Nginx e às principais malhas de serviços como fonte de certificados.

Para implantações de mTLS de alta segurança, as chaves privadas devem residir em módulos de segurança de hardware (HSM), e não em armazenamentos de chaves de software. A biblioteca TLS (OpenSSL, BoringSSL) carrega a chave privada por meio da interface PKCS#11, que redireciona as operações de assinatura para o HSM. A chave privada nunca sai dos limites do HSM em texto simples. As opções de HSM na nuvem incluem o AWS CloudHSM, o Azure Dedicated HSM e o Google Cloud HSM. Para mTLS no nível do dispositivo (IoT, laptops empresariais), o TPM 2.0 fornece uma função semelhante — a chave do cliente TLS é vinculada ao TPM e a assinatura exige autorização do TPM, tornando extremamente difícil extrair a chave de um dispositivo comprometido.

Testar mTLS exige ferramentas que ofereçam suporte à apresentação de certificados de cliente. OpenSSL s_client: openssl s_client -connect host:443 -cert client.pem -key client.key -CAfile server-ca.pem. curl: curl --cert client.pem --key client.key --cacert server-ca.pem https://host. Para testar a malha de serviços, istioctl proxy-config secret pod/name mostra o certificado atual e sua validade. Execute kubectl exec em um pod e use curl no ponto de extremidade administrativo do proxy auxiliar (localhost:15000) para inspecionar os ouvintes ativos e sua configuração de mTLS. Os testes automatizados de rotação devem verificar se as conexões permanecem estáveis durante os eventos de rotação de certificados.

O mTLS acrescenta autenticação por certificado do cliente ao TLS — ambas as partes verificam os certificados umas das outras. Os SVID do SPIFFE fornecem identidade padronizada de carga de trabalho por meio de URIs do SPIFFE nos campos SAN dos certificados. O Istio implementa mTLS de forma transparente por meio de proxies auxiliares do Envoy com os modos STRICT/PERMISSIVE. Certificados de curta duração (24 h) eliminam a necessidade de revogação e limitam a janela de comprometimento. O SPIRE automatiza a emissão e a rotação de certificados por meio da API de carga de trabalho. As chaves privadas mTLS devem residir em HSM ou TPM em implantações de alta segurança. Os desafios operacionais incluem a proteção da chave da CA, a compatibilidade com dispositivos intermediários e a rotação sem tempo de inatividade.