Criptografia em trânsito é o conjunto de mecanismos que protege dados enquanto trafegam entre componentes (cliente, API, serviços internos, bancos, filas, dispositivos). Na prática, ela precisa entregar três propriedades simultâneas: confidencialidade (ninguém lê), integridade (ninguém altera sem ser detectado) e autenticação do par (você fala com quem acha que está falando). O desafio aplicado não é “qual algoritmo usar”, mas sim “qual protocolo e qual arquitetura usar em cada trecho do caminho”, porque cada protocolo impõe limites, padrões de interoperabilidade e pontos de falha típicos.
Este capítulo foca em padrões de uso por protocolo e por arquitetura: como escolher o mecanismo certo para HTTP, gRPC, WebSockets, bancos de dados, mensageria, IoT e redes internas; como lidar com terminação de criptografia em proxies; e como evitar armadilhas como criptografia “só até o load balancer”, downgrade de segurança, e confiança excessiva na rede interna.
1) Onde a criptografia “em trânsito” realmente começa e termina
Em arquiteturas modernas, o caminho de uma requisição raramente é “cliente → servidor”. Normalmente é algo como: cliente → CDN/WAF → load balancer → gateway → serviço A → serviço B → banco → fila → worker. Em cada salto, você decide se o canal é criptografado e onde a criptografia termina (terminação) e recomeça (re-encriptação).
1.1 Terminação, re-encriptação e o problema do “último metro”
- Terminação na borda: a criptografia termina no CDN/WAF/LB e o tráfego segue em texto claro internamente. Isso simplifica, mas cria um “último metro” vulnerável dentro do data center/VPC.
- Re-encriptação: termina no proxy e inicia novamente até o serviço. Isso permite inspeção/roteamento no proxy, mas mantém proteção entre saltos.
- Pass-through: o proxy não termina a criptografia; apenas encaminha. Reduz visibilidade no proxy, mas preserva ponta a ponta até o serviço.
Um padrão seguro em ambientes distribuídos é tratar a rede interna como não confiável e usar criptografia entre serviços (mTLS ou equivalente), mesmo dentro de VPC/cluster. Quando isso não for possível, documente explicitamente onde a criptografia termina e quais controles compensatórios existem (segmentação, ACLs, observabilidade de rede, hardening de hosts).
2) Padrões por protocolo de aplicação
2.1 HTTP/REST: HTTPS como padrão, e o que muda na arquitetura
Para HTTP, o padrão de fato é HTTPS. O ponto arquitetural é: onde você termina o HTTPS e como garante que o tráfego interno não degrade a segurança.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
- Cliente → borda: HTTPS obrigatório, com redirecionamento HTTP→HTTPS e políticas de transporte estritas (por exemplo, HSTS) quando aplicável.
- Borda → origem: preferir HTTPS também (re-encriptação). Se usar HTTP interno, restrinja por rede e identifique claramente o risco.
- Serviço → serviço: em microserviços, prefira HTTPS/mTLS ou um service mesh que forneça criptografia transparente.
Evite “inventar” criptografia no payload (por exemplo, criptografar JSON manualmente) como substituto do canal. Isso costuma quebrar observabilidade, caching, validação e aumenta risco de erro. Payload encryption só faz sentido quando você precisa de confidencialidade além do canal (por exemplo, múltiplos intermediários que não devem ver dados), e mesmo assim deve ser padronizada (ver seção de criptografia de mensagem).
2.2 gRPC: HTTP/2 com criptografia de canal e identidade de serviço
gRPC normalmente roda sobre HTTP/2 e herda o modelo de canal criptografado. O padrão arquitetural é usar criptografia entre serviços com identidade forte (certificados por serviço) para evitar que um serviço “se passe” por outro.
- Dentro de cluster: mTLS entre workloads é o padrão mais robusto.
- Entre clusters/regiões: criptografia de canal + controle de roteamento (por exemplo, gateways) para reduzir superfície.
Como gRPC é sensível a proxies intermediários, é comum terminar criptografia em gateways específicos. Se fizer isso, garanta re-encriptação até o destino e políticas de autorização baseadas em identidade do chamador (não apenas IP).
2.3 WebSockets: upgrade de HTTP e persistência de sessão
WebSockets usam um handshake HTTP e depois mantêm um canal persistente. O padrão é WSS (WebSocket sobre TLS). O risco típico é esquecer que o canal fica aberto por muito tempo: rotação de credenciais, expiração de tokens e mudanças de permissão precisam ser tratadas no nível da aplicação.
- Use WSS sempre que houver dados sensíveis ou autenticação.
- Planeje reconexão: quedas e renegociação são normais; não dependa de “conexões eternas”.
- Controle de origem: valide origem e autenticação no handshake e revalide permissões periodicamente.
2.4 SMTP/Email: STARTTLS, MTA-STS e limites do modelo
Email é um caso clássico em que “criptografia em trânsito” pode ser oportunística. STARTTLS pode criptografar o salto entre servidores, mas nem sempre é obrigatório e pode falhar por downgrade se não houver políticas.
- Entre cliente e provedor: normalmente é TLS obrigatório (IMAPS/SMTPS/Submission).
- Entre servidores (MTA): STARTTLS pode ser negociado; para endurecer, use políticas como MTA-STS/DANE quando disponíveis no seu contexto.
Arquiteturalmente, trate email como um meio com múltiplos intermediários. Se você precisa confidencialidade real ponta a ponta do conteúdo, isso é criptografia de mensagem (por exemplo, S/MIME/PGP), não apenas “em trânsito”.
2.5 DNS: do “texto claro” ao DoT/DoH e validação
DNS tradicional é em texto claro e expõe metadados (nomes consultados). Para reduzir observação e manipulação no caminho, existem DNS-over-TLS (DoT) e DNS-over-HTTPS (DoH). O padrão de uso depende do ambiente:
- Endpoints (clientes): DoH/DoT pode proteger consultas em redes não confiáveis.
- Ambiente corporativo: pode haver trade-off com inspeção e políticas internas; muitas vezes usa-se um resolvedor interno com canal protegido até ele.
Não confunda criptografia do transporte do DNS com validação de autenticidade do dado DNS (DNSSEC). Um pode existir sem o outro; em arquiteturas críticas, considere ambos conforme necessidade.
2.6 Bancos de dados: criptografia de conexão e identidade do servidor
Conexões a bancos (PostgreSQL, MySQL, SQL Server, MongoDB etc.) frequentemente atravessam redes internas. O padrão recomendado é habilitar TLS no cliente e no servidor do banco, e validar a identidade do servidor (evitar “TLS sem verificação”).
- Aplicação → banco: TLS habilitado, validação de certificado, e preferencialmente autenticação forte do cliente (quando suportado).
- Poolers/proxies: se houver um proxy de conexão, decida se ele termina TLS. Se terminar, re-encripte até o banco ou restrinja fortemente o segmento.
Um erro comum é ativar TLS “para cumprir requisito”, mas aceitar qualquer certificado ou desabilitar verificação de hostname. Isso remove a proteção contra ataque de intermediário.
2.7 Mensageria e streaming: AMQP, Kafka, MQTT
Em filas e streams, o tráfego é contínuo e envolve múltiplos produtores/consumidores. O padrão é criptografar o canal cliente↔broker e, quando necessário, broker↔broker.
- AMQP/RabbitMQ: TLS para conexões de clientes; em clusters, proteger links internos conforme topologia.
- Kafka: TLS para client/broker e, em ambientes multi-tenant, mTLS para identidade de clientes. Em inter-broker, TLS também é comum.
- MQTT (IoT): TLS é essencial, pois dispositivos operam em redes hostis. Atenção a restrições de CPU/memória e a reconexões frequentes.
Arquiteturalmente, mensageria costuma ser o “backbone” do sistema. Se o broker vira um ponto de terminação onde tudo é descriptografado, ele se torna um ativo crítico: endureça acesso, monitore, e considere criptografia de mensagem quando o broker não deve ver payloads (ver seção 4).
3) Padrões por arquitetura: borda, malha de serviços e zero trust
3.1 Arquitetura com reverse proxy/API gateway
Gateways centralizam autenticação, rate limiting, roteamento e às vezes terminação de TLS. Padrões comuns:
- TLS na borda + mTLS interno: o gateway termina TLS do cliente e inicia mTLS para serviços internos. Bom equilíbrio entre controle e segurança.
- Pass-through para serviços: útil quando o serviço precisa ver o certificado do cliente (mTLS ponta a ponta) ou quando você quer reduzir pontos de descriptografia.
Decisão prática: se você precisa de autenticação do cliente baseada em certificado no serviço final, pass-through ou propagação segura de identidade (por cabeçalhos assinados internamente) é necessária. Se usar cabeçalhos para propagar identidade, trate-os como dados sensíveis e só confie neles em canais autenticados entre gateway e serviços.
3.2 Service mesh: criptografia “por padrão” entre workloads
Uma malha de serviços normalmente injeta proxies lado a lado (sidecars) que estabelecem canais criptografados automaticamente entre serviços. O padrão arquitetural é:
- mTLS obrigatório entre serviços, com identidade por workload.
- Políticas de autorização baseadas em identidade (quem pode chamar quem), não em rede.
- Observabilidade no proxy, sem exigir que cada time implemente criptografia manualmente.
O cuidado aqui é operacional: rotação de identidades/certificados, compatibilidade com tráfego não-HTTP, e evitar “exceções permanentes” (serviços que ficam fora da malha e viram pontos fracos).
3.3 Zero trust interno: criptografia como requisito, não como opção
Em zero trust, a rede não é um perímetro confiável. Padrões aplicados:
- Criptografia e autenticação em cada salto relevante.
- Autorização explícita por identidade e contexto.
- Segmentação para reduzir blast radius mesmo com criptografia.
Na prática, isso significa que “tráfego interno em HTTP” deve ser exceção temporária e rastreada, não padrão.
4) Quando o canal não basta: criptografia de mensagem (end-to-end no payload)
Há cenários em que você precisa que intermediários (proxies, brokers, logs, ferramentas de APM) não consigam ler o conteúdo, mesmo que o canal seja criptografado. Aqui entra criptografia de mensagem: o payload é criptografado pelo emissor e só o destinatário final consegue abrir.
Padrões de uso:
- Eventos em mensageria com brokers operados por terceiros ou multi-tenant: criptografar campos sensíveis no payload.
- Integrações B2B com múltiplos hops e armazenamento temporário: proteger o conteúdo além do transporte.
- Dados altamente sensíveis que não devem aparecer em observabilidade: criptografia seletiva de campos.
Trade-offs: perde-se capacidade de roteamento por conteúdo, inspeção de segurança e debugging. Um padrão prático é criptografar apenas campos sensíveis e manter metadados mínimos em claro para roteamento.
5) Passo a passo prático: desenhando criptografia em trânsito para um sistema típico
A seguir, um roteiro aplicável para projetar e revisar criptografia em trânsito em uma arquitetura comum (cliente web/mobile + API + microserviços + banco + mensageria).
Passo 1 — Mapear fluxos e “saltos” reais
Liste todos os caminhos de dados, incluindo componentes de infraestrutura:
- Cliente → CDN/WAF → LB → API Gateway
- Gateway → Serviço A → Serviço B
- Serviço B → Banco
- Serviço A → Broker → Worker
- Serviços → provedores externos (pagamentos, email, etc.)
Para cada seta, registre: protocolo, porta, se há proxy no meio, e se o tráfego cruza domínios de confiança (VPCs, contas, regiões, fornecedores).
Passo 2 — Definir o padrão por tipo de tráfego
- North-south (cliente↔sistema): TLS obrigatório na borda; preferir terminação em componente controlado (gateway) com políticas consistentes.
- East-west (serviço↔serviço): mTLS por padrão (mesh ou bibliotecas), principalmente em microserviços.
- Dados (serviço↔banco/cache): TLS com validação de identidade do servidor; avaliar autenticação mútua onde fizer sentido.
- Mensageria: TLS cliente↔broker; avaliar criptografia de mensagem para payloads sensíveis.
Passo 3 — Escolher pontos de terminação conscientemente
Decida onde a criptografia pode terminar sem criar um “buraco”:
- Se terminar no LB, o segmento LB→serviço precisa ser protegido (re-encriptação) ou isolado com controles fortes.
- Se usar inspeção (WAF, DLP), documente quais dados são visíveis ali e como são protegidos (acesso, logs, retenção).
Passo 4 — Padronizar identidade e autorização entre serviços
Criptografia em trânsito não substitui autorização. Um padrão robusto é: identidade forte no canal (mTLS) + autorização por política (quem pode chamar quem). Evite confiar em IP de origem como identidade.
Passo 5 — Tratar exceções: legados e integrações
Para componentes legados que não suportam TLS:
- Coloque um proxy/sidecar que ofereça TLS externamente e fale o protocolo legado internamente, em segmento isolado.
- Minimize o trecho em texto claro (idealmente dentro do mesmo host) e monitore.
Para integrações externas:
- Use canais criptografados e valide a identidade do destino.
- Evite “pinning” rígido sem estratégia de rotação; prefira mecanismos operacionais estáveis.
Passo 6 — Validar com testes e observabilidade
Checklist prático de validação:
- Captura de tráfego em pontos internos confirma que não há dados sensíveis em claro onde não deveria.
- Verificação de que clientes recusam conexões inválidas (certificado errado, hostname errado).
- Monitoramento de falhas de handshake e tentativas de downgrade.
- Inventário de endpoints que aceitam conexões sem criptografia (deve ser zero ou exceções justificadas).
6) Armadilhas comuns por protocolo e como evitá-las
6.1 “TLS habilitado” mas sem validação
O erro: configurar cliente para aceitar qualquer certificado, ou desabilitar verificação de hostname “para funcionar”. Isso abre espaço para intermediário malicioso. Padrão: validação sempre ligada; exceções apenas em ambientes de teste isolados e com data de expiração.
6.2 Misturar autenticação de aplicação com confiança no canal
O erro: assumir que, porque há TLS, qualquer requisição interna é confiável. Padrão: autenticação/autorização explícitas entre serviços, e políticas de acesso mínimas.
6.3 Terminar criptografia cedo demais
O erro: descriptografar no primeiro proxy e trafegar em claro por conveniência. Padrão: re-encriptação até o serviço, ou mTLS interno; se não, segmentação forte e justificativa formal.
6.4 WebSockets e sessões longas sem revalidação
O erro: permissões mudam, mas a conexão continua autorizada indefinidamente. Padrão: revalidação periódica, expiração de sessão e mecanismos de revogação no nível da aplicação.
6.5 Mensageria: confiar no broker como “zona segura”
O erro: tudo passa descriptografado pelo broker e vai para logs/monitoramento. Padrão: TLS sempre; para payload sensível, criptografia de mensagem ou ofuscação/mascaramento com governança de logs.
7) Tabela mental de escolha rápida (protocolo → padrão recomendado)
- HTTP/REST: HTTPS na borda; preferir HTTPS/mTLS interno em microserviços; evitar payload crypto como substituto.
- gRPC: TLS/mTLS por serviço; gateways para borda; políticas por identidade.
- WebSockets: WSS; revalidação de autorização ao longo do tempo.
- Banco de dados: TLS com validação; cuidado com proxies/poolers.
- Kafka/AMQP/MQTT: TLS cliente↔broker; mTLS em multi-tenant; considerar criptografia de mensagem para payload sensível.
- SMTP: TLS cliente↔provedor; STARTTLS entre MTAs com políticas quando necessário; para conteúdo sensível, criptografia de mensagem.
- DNS: DoT/DoH para proteger consulta em redes hostis; resolvedor interno com canal protegido em corp; considerar DNSSEC conforme necessidade.
// Exemplo de checklist operacional (pseudo) para revisão de um serviço interno
// 1) O serviço expõe porta HTTP em claro? (deve ser não)
// 2) O cliente valida certificado e hostname? (deve ser sim)
// 3) Há mTLS entre serviços? (preferencial)
// 4) Logs capturam payload sensível? (deve ser não)
// 5) Há exceções documentadas com prazo? (se sim, rastrear)
