Criptografia em Trânsito (TLS)

Criptografia em trânsito é a proteção aplicada aos dados enquanto eles se deslocam entre dois pontos da rede, seja entre um usuário externo e a aplicação, seja entre dois serviços internos. O mecanismo padrão é o TLS, protocolo criptográfico que estabelece um canal cifrado, íntegro e autenticado sobre qualquer transporte orientado a conexão. Em produção a proteção é relevante porque grande parte dos interceptos reais acontece no caminho, e não no armazenamento, e o tráfego plano dentro da rede interna é alvo clássico de movimentação lateral após um comprometimento inicial. A camada de transporte também é o ponto natural de aplicação de políticas, como versão mínima de protocolo, conjunto de cifras permitido e identidade mútua entre serviços. Este arquivo cobre o funcionamento do handshake, o mTLS entre serviços, as escolhas de terminação no balanceador e a operação contínua de certificados e cifras.

Conceito: proteção de dados em movimento

Dados existem em três estados clássicos: em repouso, em uso e em trânsito. A criptografia em trânsito cobre o terceiro estado e garante que o conteúdo seja ilegível para qualquer observador da rede e que qualquer alteração seja detectada pelo destinatário. O TLS entrega três propriedades simultâneas: confidencialidade, com cifragem simétrica do payload; integridade, com autenticação de cada registro da sessão; e autenticidade, com o certificado provando a identidade do servidor e, no mTLS, também a do cliente. A autenticação é o que separa o TLS de uma cifra qualquer, porque sem ela um interceptador poderia simplesmente se passar pelo destino.

A fronteira da rede confiável desapareceu na prática. Ambientes com microsserviços, nuvem híbrida e fornecedores externos tratam qualquer enlace como potencialmente hostil, premissa conhecida como zero trust. Por isso a regra contemporânea é cifrar todo tráfego, inclusive o que nunca sai do datacenter: o custo com hardware moderno é baixo e o benefício elimina categorias inteiras de ataque no caminho.

O problema que a criptografia em trânsito resolve

Sem TLS, qualquer elemento do caminho pode ler e alterar o tráfego: o roteador do provedor, o NAT corporativo, o pod comprometido no mesmo nó ou o link entre datacenters. Os ataques concretos têm nomes e contramedidas bem definidas no desenho do protocolo, o que explica por que o TLS virou pressuposto de todo stack de produção.

O custo do TLS hoje é pequeno perto do benefício. Processadores modernos executam AES com instruções dedicadas, e a retomada de sessão com tickets elimina a maior parte do custo de handshake em conexões repetidas. O custo real é operacional e se concentra em certificados, que é exatamente onde a automação precisa entrar.

Handshake TLS 1.3 e funcionamento interno

O handshake é a negociação inicial em que cliente e servidor trocam parâmetros, autenticam identidade e derivam as chaves de sessão. O TLS 1.3 consolidou o processo em um único round trip: o cliente envia o ClientHello com seus compartilhamentos de chave; o servidor responde com certificado, parâmetros escolhidos e o compartilhamento próprio; ambos derivam a mesma chave por Diffie-Hellman efêmero e passam a falar registros cifrados com AEAD. O sigilo à frente é herdado da efemeridade: o comprometimento da chave de longo prazo não permite reconstituir sessões passadas, porque cada sessão dependeu de material efêmero descartado.

Três diferenças do TLS 1.2 merecem atenção operacional. Primeiro, o conjunto negociável encolheu drasticamente, o que remove grande parte da superfície de má configuração. Segundo, o handshake passou a ser cifrado após o ServerHello, escondendo certificado e extensões de observadores passivos. Terceiro, o modo de retomada com zero round trip, o 0-RTT, permite enviar dados na primeira mensagem da sessão retomada, mas esses dados são suscetíveis a replay e devem carregar apenas operações idempotentes, como consultas.

Duas extensões complementam o entendimento do protocolo. O SNI, Server Name Indication, leva o nome do domínio desejado já no primeiro pacote e permite a um mesmo endereço servir múltiplos certificados, base da hospedagem densa e das terminações centralizadas. O ALPN negocia o protocolo de aplicação dentro do handshake, e é por ele que HTTP/2 e HTTP/3 passam a valer sem round trip extra.

mTLS entre serviços

Em TLS padrão apenas o servidor apresenta certificado, e a identidade do cliente fica a cargo de tokens ou chaves de API na camada de aplicação. No mTLS, mutual TLS, os dois lados apresentam certificado e se validam mutuamente, convertendo a identidade de rede em identidade criptográfica verificável. Em malhas de serviço como Istio e Linkerd, o mTLS é implementado por sidecar: cada chamada entre workloads carrega um certificado de workload emitido pela própria malha, com rotação automática em prazos curtos, tipicamente 24 horas. O ganho é duplo, cifragem de todo enlace interno e bloqueio de qualquer chamador sem certificado válido, independentemente das regras de rede.

A nuance essencial é que mTLS autentica o workload, não o usuário final. Ele não substitui autorização de aplicação, tokens de sessão ou escopos OAuth; ele complementa esses mecanismos garantindo que a conversa ocorra apenas entre identidades conhecidas. A combinação típica em produção é mTLS na borda interna e autorização por identidade de serviço em cada chamada.

# mTLS estrito para o namespace de pagamentos (Istio)
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: mtls-estrito
  namespace: pagamentos
spec:
  mtls:
    mode: STRICT              # Exige certificado de workload em toda conexão
---
# Exceção temporária por porta durante migração de serviço legado
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: pagador-legado
  namespace: pagamentos
spec:
  selector:
    matchLabels:
      app: pagador-v1
  portLevelMtls:
    8080:
      mode: PERMISSIVE        # Janela de migração com dupla aceitação

O modo permissivo existe para migração, não para permanência. A sequência saudável é habilitar permissivo, medir quanto tráfego ainda chega plano, corrigir os chamadores remanescentes e só então aplicar estrito.

Terminação versus pass-through no balanceador

O balanceador pode encerrar o TLS e reencaminhar plano, terminação, ou apenas repassar o tráfego cifrado até o destino, pass-through. A terminação simplifica operação: um único certificado central, políticas de cifra em um lugar, inspeção L7 pelo balanceador e offload do custo criptográfico das aplicações. O pass-through preserva o sigilo ponta a ponta e permite que o destino valide o certificado do cliente, requisito de mTLS real e de cenários regulados com exigência de sigilo completo no caminho. Nenhum dos dois é universalmente correto, e a decisão depende de quem precisa inspecionar o tráfego e de onde estão os dados sensíveis.

O híbrido mais comum resolve a tensão: terminação na borda para roteamento e WAF, seguida de nova sessão TLS até o destino, prática conhecida como re-criptografia. Nesse desenho o caminho interno continua cifrado, o balanceador atua como cliente autenticado e o destino volta a validar identidade. Em AWS, o ALB executa terminação com ACM enquanto o NLB preserva o TLS até o target, o que materializa exatamente essa escolha.

Renovação de certificados (ACM e Let's Encrypt)

Certificados têm validade curta por design, e a operação dominante é a renovação automática. O Let's Encrypt emite certificados gratuitos pelo protocolo ACME, com prova de domínio por desafio HTTP ou DNS e prazos curtos que forçam automação saudável. O AWS Certificate Manager emite e renova certificados para serviços gerenciados como ALB, CloudFront e API Gateway sem intervenção, exigindo apenas a validação DNS inicial. A regra de engenharia é direta: renovação manual é incidente agendado, não tarefa de equipe.

# Emissão e renovação automática com certbot usando desafio DNS (Route 53)
certbot certonly --dns-route53 \
    -d api.empresa.com.br \
    --non-interactive --agree-tos -m sre@empresa.com.br

# Verificação programática de expiração, base dos alertas de certificado
openssl x509 -in /etc/letsencrypt/live/api.empresa.com.br/cert.pem \
    -noout -enddate -subject

# Hook pós-renovação: recarrega o serviço com o certificado novo
cat > /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh <<'EOF'
#!/bin/bash
nginx -t && systemctl reload nginx
EOF
chmod 750 /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

O requisito central é que a renovação também recarregue o consumidor do certificado. Sem o passo de recarga, o arquivo novo fica no disco e o processo continua servindo o antigo até o próximo restart, erro clássico de automação incompleta. O desafio DNS-01 escala melhor que o HTTP em cenários com muitos domínios e origens sem porta pública, e a credencial do cliente ACME deve ser limitada à zona necessária, porque um segredo com poder amplo de DNS converte o próprio sistema de renovação em risco.

Cipher suites e configuração mínima

Um cipher suite é a combinação nomeada de algoritmos de uma sessão: troca de chaves, autenticação, cifra simétrica e integridade. A configuração mínima aceitável hoje é TLS 1.3 com fallback para 1.2, apenas cifras com sigilo à frente, AEAD como AES-GCM ou ChaCha20-Poly1305 e ECDHE como troca de chaves. Versões anteriores a 1.2 devem ser desligadas e cifras legadas, como CBC sem autenticação, devem ficar fora do conjunto por histórico de ataques documentado. A lista deve permanecer curta: conjuntos enormes existem para compatibilidade, não para segurança.

# Configuração mínima segura de TLS no Nginx
server {
    listen 443 ssl;
    http2 on;

    ssl_protocols TLSv1.2 TLSv1.3;      # 1.3 preferido, 1.2 apenas como fallback
    ssl_prefer_server_ciphers on;       # O servidor decide a cifra da sessão
    ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384";
    ssl_session_cache shared:TLS:10m;   # Reuso de sessão evita handshake completo
    ssl_session_timeout 1d;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

Ferramentas de avaliação externa, como testssl.sh e o SSL Labs, validam a configuração efetiva da borda e viram rotina em auditorias. A checagem vale para endpoints internos também, porque configuração legada costuma sobreviver exatamente onde ninguém olha.

Onde o TLS atua na arquitetura

Em um sistema distribuído real, o TLS aparece em vários enlaces com mecanismos diferentes, e a consistência entre eles é o que evita tráfego plano esquecido.

O inventário desses enlaces deve existir como documento vivo da arquitetura, porque auditorias de dados pedem exatamente isso: onde o dado transita e como cada trecho está protegido.

Dados internos também precisam de trânsito cifrado

O erro histórico de tratar a rede interna como confiável custa caro em arquiteturas modernas. Um atacante com acesso a um pod, a uma VPC pareada ou a um link de backup captura tráfego plano entre réplicas de banco, entre brokers de Kafka e em chamadas gRPC internas. Cenários regulados, como saúde e pagamentos, já assumem essa premissa e cobram cifragem de enlaces internos em auditoria. A implementação varia por camada: TLS nativo nos bancos, listener TLS nos brokers, mTLS na malha de serviços e túnel cifrado entre VPCs conectadas.

Há um trade-off legítimo em enlaces de altíssima taxa, como replicação interna de banco ou tráfego de cluster, onde cifrar tudo custa CPU mensurável. A resposta madura não é abrir exceção silenciosa: mede-se o impacto, documenta-se a decisão e aplicam-se controles compensatórios, como segmentação de rede rigorosa e criptografia em repouso obrigatória.

Erros comuns

• Terminar TLS no balanceador e esquecer o tramo interno: o caminho até a aplicação fica plano e invisível para qualquer auditoria de dados.
• Deixar a renovação dependente de processo manual: certificado expirado é incidente determinístico, com data marcada no calendário.
• Manter versões antigas por garantia: TLS 1.0 e 1.1 e cifras legadas são vetor de downgrade e reprovação em scanner externo.
• Desligar a validação de certificado nos clientes internos: um SDK que aceita qualquer certificado anula o protocolo inteiro naquele enlace.
• Automatizar a emissão sem automatizar a recarga: certificado novo no disco não vira sessão nova sem reload do serviço.
• Tratar o 0-RTT como recurso gratuito: os dados iniciais de 0-RTT são suscetíveis a replay e não podem carregar operações sensíveis.

Boas práticas

• Exigir TLS 1.3 na borda com fallback monitorado para 1.2, removendo o 1.2 após verificar a base de clientes legados.
• Usar certificados de vida curta com emissão automática, preferindo validação DNS-01, que funciona sem porta pública exposta.
• Adotar mTLS com identidade de workload em qualquer arquitetura de microsserviços, iniciando em modo permissivo e migrando para estrito.
• Definir explicitamente o modelo de terminação por domínio: borda com inspeção e caminho interno cifrado ponta a ponta.
• Monitorar expiração de todos os certificados, inclusive os fora da automação, com alertas a 30 e 14 dias.
• Validar a configuração efetiva com scanner externo em cadência fixa, transformando o resultado de scanner em critério de release.