Criptografia aplicada por caso de uso: APIs, microserviços e mensageria

O que muda quando a criptografia é aplicada “por caso de uso”

Em ambientes modernos, a pergunta raramente é “qual algoritmo usar?” e quase sempre é “onde exatamente aplicar criptografia para reduzir risco sem quebrar interoperabilidade, observabilidade e desempenho?”. Em APIs, microserviços e mensageria, a criptografia aparece em camadas diferentes: transporte (entre componentes), mensagem (payload), identidade (quem é quem) e proteção de segredos (chaves e tokens). O desafio prático é que esses sistemas são distribuídos, têm múltiplos hops, passam por gateways, proxies, filas e reprocessamentos, e precisam de rastreabilidade e governança.

Este capítulo foca em padrões de aplicação: como proteger chamadas síncronas (APIs), comunicação leste-oeste (microserviços) e fluxos assíncronos (mensageria), com decisões arquiteturais e passos práticos. A ideia é fornecer um “mapa de decisões” e checklists implementáveis, evitando repetir fundamentos já cobertos em capítulos anteriores.

APIs: criptografia aplicada em chamadas síncronas

Objetivo prático em APIs

Em APIs, normalmente você quer: (1) confidencialidade e integridade em trânsito, (2) autenticação forte do cliente e do servidor, (3) autorização consistente, (4) proteção contra replay e abuso, (5) minimização de exposição de dados sensíveis em logs e caches. A criptografia entra principalmente em: TLS, autenticação baseada em tokens/assinaturas, e criptografia de campos (quando há intermediários não confiáveis).

Decisão 1: TLS “fim a fim” vs TLS “até o gateway”

Um padrão comum é terminar TLS no API Gateway/Ingress e seguir com tráfego interno em rede “confiável”. Em ambientes com múltiplos times, clusters e redes compartilhadas, essa suposição costuma falhar. A alternativa é manter TLS também no tráfego interno (mTLS ou TLS com autenticação do servidor) para reduzir risco de interceptação lateral e para permitir políticas por identidade do workload.

• TLS até o gateway: simplifica observabilidade e inspeção, mas aumenta a superfície interna (tráfego em claro após o gateway).
• TLS fim a fim: reduz exposição, mas exige gestão de certificados e pode complicar debugging/observabilidade.
• mTLS interno: adiciona autenticação mútua e permite autorização por identidade de serviço, útil em microserviços.

Decisão 2: token de acesso vs requisições assinadas

Para APIs, dois padrões frequentes são: (a) token de acesso (por exemplo, JWT opaco ou estruturado) e (b) requisições assinadas (estilo “signature over request”). Tokens são simples para clientes e caches, mas exigem cuidado com escopo, expiração e revogação. Requisições assinadas reduzem dependência de um token portável e podem mitigar replay quando combinadas com nonce/timestamp, mas aumentam complexidade de clientes e de canonicalização de headers.

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

Uma regra prática: use tokens quando você controla bem o emissor e o ciclo de vida; use assinatura de requisição quando você precisa de não repúdio operacional, forte proteção contra replay e quando o cliente consegue implementar canonicalização de forma consistente.

Passo a passo: endurecimento criptográfico de uma API pública

A seguir, um roteiro aplicável a uma API exposta na internet, com gateway e serviços internos.

1) Defina fronteiras e dados sensíveis

• Liste endpoints e classifique dados: PII, credenciais, segredos, dados financeiros, identificadores internos.
• Mapeie onde esses dados passam: gateway, WAF, serviços, filas, logs, APM.
• Decida se algum intermediário não deve ver o payload (ex.: provedor de gateway gerenciado, proxy de terceiros).

2) Configure TLS no edge com políticas explícitas

• Habilite apenas versões modernas de TLS e cipher suites aprovadas pela sua política.
• Ative HSTS quando aplicável (para navegadores) e redirecione HTTP para HTTPS.
• Garanta validação correta de hostname e cadeia de certificados no cliente (especialmente SDKs internos).

3) Autenticação e autorização com escopo mínimo

• Defina escopos por recurso/ação (ex.: orders:read, orders:write), evitando tokens “admin” genéricos.
• Use expiração curta para tokens de acesso e rotação para refresh tokens quando existirem.
• Valide audiência (aud) e emissor (iss) para evitar uso cruzado de tokens entre APIs.

4) Mitigue replay e abuso

• Para operações sensíveis, exija idempotency key e valide unicidade por janela de tempo.
• Considere nonce/timestamp em requisições assinadas, com tolerância de clock e armazenamento de nonces recentes.
• Aplique rate limiting por identidade (cliente) e por IP, com respostas consistentes.

5) Criptografia de campos (quando necessário)

Se o gateway, proxies ou ferramentas de observabilidade não devem ter acesso a certos campos (ex.: número de documento, dados de cartão, segredos), aplique criptografia no nível do payload para esses campos antes de enviar. Isso é diferente de “TLS”: aqui você protege contra intermediários dentro do caminho.

• Defina quais campos serão criptografados e como serão serializados (ex.: base64 do ciphertext + metadados como versão).
• Evite criptografar o payload inteiro se você precisa de roteamento/validação por campos; criptografe apenas o mínimo necessário.
• Versione o esquema para permitir rotação de chaves e migração gradual.

6) Observabilidade sem vazamento

• Redija logs: nunca logue tokens, segredos, ou payloads com PII em texto.
• Padronize mascaramento no gateway e nos serviços.
• Para troubleshooting, use correlação por IDs e amostragem controlada, não dumps completos.

Exemplo prático: envelope de campo criptografado em JSON

Um padrão simples é encapsular o campo sensível em um objeto com metadados mínimos para permitir rotação e validação.

{  "customer_id": "12345",  "document": {    "v": 1,    "kid": "k-2026-01",    "alg": "AEAD",    "ct": "BASE64_CIPHERTEXT",    "iv": "BASE64_NONCE"  }}

O serviço que precisa do dado descriptografa usando a chave indicada por kid. Serviços que não precisam do dado tratam o objeto como opaco e não o registram em logs. Esse padrão exige disciplina: validação de schema, limites de tamanho e tratamento consistente de erros para não criar oráculos.

Microserviços: criptografia aplicada no tráfego leste-oeste e na identidade de serviço

O problema típico em microserviços

Em microserviços, o tráfego interno cresce rapidamente: chamadas serviço-a-serviço, sidecars, service mesh, jobs, autoscaling. O risco não é apenas “alguém na internet”, mas também: movimentação lateral após comprometimento de um pod/VM, credenciais vazadas em variáveis de ambiente, e confusão de identidade (um serviço se passando por outro).

mTLS como base para identidade de workload

Quando você usa mTLS internamente, cada serviço apresenta um certificado e o outro lado valida. Isso permite:

• Autenticação mútua entre serviços (não apenas criptografia do canal).
• Políticas por identidade (ex.: “serviço A pode chamar serviço B no endpoint X”).
• Redução de segredo estático: em vez de compartilhar chaves long-lived, você usa certificados com ciclo de vida curto e rotação automatizada.

Na prática, mTLS pode ser implementado na aplicação (bibliotecas TLS) ou via service mesh/sidecar. O ponto criptográfico relevante é garantir que a identidade apresentada no certificado seja mapeada de forma inequívoca para o workload (SPIFFE-like identities, SANs bem definidos, etc.) e que a rotação não quebre conexões.

Passo a passo: habilitando mTLS interno com governança mínima

1) Defina o modelo de identidade de serviço

• Escolha um formato de identidade estável: service.namespace.environment ou URI de identidade.
• Defina quais atributos entram no certificado (SAN) e quais não entram (evite dados mutáveis).
• Padronize nomes para evitar colisões entre times/ambientes.

2) Estabeleça uma autoridade emissora interna e automação

• Automatize emissão e renovação (certificados de curta duração reduzem impacto de vazamento).
• Garanta inventário: quais serviços têm quais identidades e validade.
• Defina procedimento de revogação/isolamento quando um serviço é comprometido.

3) Aplique políticas de autorização baseadas em identidade

• Não confie apenas em “estar na rede”. Exija identidade do chamador.
• Implemente allowlists por serviço e por rota (least privilege).
• Separe ambientes (dev/stage/prod) com CAs ou domínios de confiança distintos.

4) Trate chamadas internas como potencialmente hostis

• Valide entrada como se fosse externa (mTLS não impede payload malicioso).
• Use timeouts e limites de tamanho para evitar DoS interno.
• Padronize erros para não vazar detalhes criptográficos/identidade.

5) Planeje observabilidade com tráfego criptografado

• Se você usa mesh, prefira métricas e tracing no sidecar em vez de inspeção de payload.
• Evite “descriptografar para observar” em pontos centrais; isso cria novos alvos.
• Quando for inevitável (ex.: debugging), use acesso break-glass com auditoria.

Exemplo prático: autorização por identidade de serviço

Imagine três serviços: checkout, payments e orders. Você quer permitir que checkout chame payments apenas em /authorize e /capture, e impedir que qualquer outro serviço chame payments. Com mTLS, a política pode ser baseada no SAN do certificado do chamador, sem depender de IPs dinâmicos. Isso reduz o risco de um serviço comprometido “varrer” a malha e acessar endpoints sensíveis.

Mensageria: criptografia aplicada em filas, tópicos e eventos

Por que mensageria exige decisões diferentes

Em mensageria (filas e pub/sub), a mensagem pode ficar armazenada por tempo indeterminado, pode ser reprocessada, pode passar por múltiplos consumidores e pode ser replicada entre regiões. Além disso, o “caminho” não é uma conexão direta: há brokers, storage interno, DLQs, replays e ferramentas de inspeção. Isso muda a pergunta de criptografia: não basta proteger o link; você precisa decidir quem pode ler o payload em cada etapa e por quanto tempo.

Três camadas de proteção em mensageria

• Canal: criptografia entre produtor/consumidor e broker (protege contra interceptação na rede).
• Broker/storage: proteção do armazenamento do broker (reduz risco de acesso físico/lógico ao disco do broker).
• Mensagem (end-to-end): payload criptografado de produtor para consumidor, de modo que o broker não consiga ler.

A camada “mensagem” é a que mais impacta arquitetura: afeta roteamento, filtragem, schema registry, deduplicação e observabilidade. Muitas vezes, um meio-termo é criptografar apenas campos sensíveis e manter metadados não sensíveis em claro para roteamento.

Decisão 1: criptografia end-to-end é necessária?

Use criptografia end-to-end no payload quando:

• O broker é operado por um time/terceiro que não deve ter acesso ao conteúdo.
• Há replicação para domínios com controles diferentes.
• Mensagens contêm dados altamente sensíveis e ficam retidas por longos períodos.
• Você precisa reduzir o impacto de credenciais do broker vazadas (um invasor que lê tópicos ainda não lê o conteúdo).

Se o broker e o ambiente são estritamente controlados e o risco principal é interceptação de rede, canal + controles de acesso podem ser suficientes, desde que você trate retenção, backups e DLQs como parte do mesmo domínio de risco.

Decisão 2: criptografar payload inteiro vs campos

• Payload inteiro: maximiza confidencialidade, mas impede inspeção, filtros por conteúdo e algumas estratégias de roteamento.
• Campos: preserva roteamento e validação parcial, mas exige governança para não deixar “quase sensível” em claro (ex.: combinações que reidentificam).

Passo a passo: aplicando criptografia em mensagens com envelope e rotação

1) Defina o contrato de mensagem e o que pode ficar em claro

• Separe headers/metadados (ex.: tipo de evento, versão, correlation id) do payload.
• Decida quais campos são sensíveis e se podem ser removidos/substituídos por referências.
• Inclua versão do schema e versão do envelope criptográfico.

2) Escolha um formato de envelope consistente

Um envelope típico inclui: versão, identificador de chave (kid), nonce/iv, ciphertext e tag (se aplicável). Evite inventar múltiplos formatos por time; padronize para facilitar bibliotecas internas e auditoria.

{  "meta": {    "event_type": "payment_authorized",    "schema_v": 3,    "correlation_id": "..."  },  "crypto": {    "v": 1,    "kid": "msgkey-2026-01",    "ct": "BASE64_CIPHERTEXT",    "iv": "BASE64_NONCE"  }}

3) Integre com gestão de chaves e rotação

• Use kid para permitir que consumidores escolham a chave correta sem tentativa e erro.
• Planeje rotação: por exemplo, produtores passam a usar nova chave em uma data, consumidores aceitam ambas por uma janela.
• Defina política para reprocessamento: mensagens antigas precisam continuar legíveis? Por quanto tempo?

4) Trate DLQ, retries e replays como parte do mesmo risco

• DLQ frequentemente vira “arquivo morto” com dados sensíveis. Aplique as mesmas regras de acesso e retenção.
• Garanta que ferramentas de suporte não tenham acesso fácil ao plaintext (evite scripts que imprimem payload descriptografado).
• Se houver replays, audite quem pode dispará-los e sob quais condições.

5) Validação e falhas: evite oráculos e vazamentos

• Se a descriptografia falhar, retorne erros genéricos e registre apenas metadados não sensíveis.
• Imponha limites de tamanho do ciphertext e do número de tentativas de processamento.
• Separe falhas de schema (mensagem malformada) de falhas criptográficas (autenticidade/integração), mas sem expor detalhes ao produtor.

Exemplo prático: evento com roteamento em claro e payload protegido

Suponha um tópico payments.events com consumidores diferentes: antifraude, conciliação e notificações. Você pode manter em claro apenas o necessário para roteamento e observabilidade (tipo do evento, timestamp, IDs não sensíveis), e criptografar os detalhes financeiros e PII. Assim, o broker e ferramentas de monitoramento conseguem operar sem acesso ao conteúdo sensível, e cada consumidor autorizado descriptografa localmente.

Integrações entre APIs, microserviços e mensageria: padrões que evitam armadilhas

Padrão 1: “Gateway termina TLS” + mTLS interno + criptografia de campos seletiva

Um arranjo comum e pragmático é: TLS forte no edge, mTLS entre serviços, e criptografia de campos para dados que não devem aparecer em logs/observabilidade ou que atravessam componentes operados por terceiros. Esse padrão reduz o número de lugares onde plaintext existe, sem exigir payload totalmente opaco.

Padrão 2: “Token no edge, identidade de serviço internamente”

Evite propagar o token do usuário final por todos os microserviços como se fosse credencial universal. Um padrão mais seguro é: o gateway valida o token do usuário e emite contexto mínimo (claims necessárias) para o serviço de borda, enquanto o tráfego interno usa identidade de serviço (mTLS) e autorização por serviço. Quando um serviço precisa agir “em nome do usuário”, use delegação explícita e escopos restritos, não repasse tokens amplos indiscriminadamente.

Padrão 3: “Eventos com envelope criptográfico versionado”

Mensagens vivem mais que deploys. Versione envelope e schema, e trate rotação de chaves como requisito de compatibilidade. Consumidores devem ser capazes de: (a) identificar versão, (b) escolher chave por kid, (c) falhar com segurança e (d) operar durante janelas de transição.

Checklist rápido por caso de uso

API pública

• TLS no edge com política explícita e validação correta no cliente.
• Autenticação com escopos mínimos e expiração curta.
• Mitigação de replay (idempotency key/nonce/timestamp) em operações sensíveis.
• Criptografia de campos quando intermediários não devem ver dados.
• Logs e métricas sem dados sensíveis.

Microserviços internos

• mTLS para identidade de serviço e políticas por identidade.
• Automação de emissão/rotação de certificados e inventário.
• Separação de ambientes e domínios de confiança.
• Observabilidade via métricas/tracing sem depender de inspeção de payload.

Mensageria

• Decisão explícita sobre end-to-end no payload vs apenas canal.
• Envelope criptográfico versionado com kid e suporte a rotação.
• DLQ/replay/retention tratados como parte do mesmo domínio de risco.
• Erros e logs sem vazamento de detalhes criptográficos.