Criptografia In Transit

Criptografia In Transit

1) Definição e limites de controle

Criptografia in transit é a proteção de dados em todo o caminho de transmissão de rede (navegador, servidor, serviço serviço, agente, corretor, base aplicativo, datacenter datacenter), para que a interceptação passiva e os ataques ativos ao canal não divulguem o conteúdo e não permitam a modificação sem detecção.

O que cobramos são API público e privado (HTTP/HTTPS, gRPC), streaming e corretores (Kafka, NATS, RabbitMQ), WebSocket, bases de dados e cachês na rede, tráfego de serviço dentro dos clusters, VPN/entre-centros e nuvens, consultas DNS, móvel/IOT-clientes

O que não cobrimos completamente, como ataques a pontos finais (comprometimento do servidor/navegador), vulnerabilidades de aplicativos, fuga de logs/dampos. Isso é resolvido por controladores individuais (A&A, minimização de direitos, criptografia at rest, loging seguro).

2) Modelo de ameaças e metas

Riscos: interceptação/troca de tráfego (MITM), downgrade de protocolo/cifra, certificados falsos/SA, vazamento de chaves, ataques a metadados SNI, conteúdo misto, interferência errada de TLS em balanços, ligações entre servidores não seguros.

1. Privacidade + integridade com autenticação criptográfica.

2. Oposição ao downgrade (política rigorosa e config).

3. Identificação das partes (servidor, mútuo, se necessário).

4. Ciclo de vida controlado de certificados/chaves e auditoria.

5. Perfil de desempenho sem compromissos de segurança.

3) Princípios básicos

O TLS está por omissão. Tráfego externo e interno - cifra.
Versões modernas. TLS 1. 3 como padrão; TLS 1. 2 - apenas com políticos rigorosos. Desativar 1. 0/1. 1.
Cifra AEAD com PFs. AES-GCM ou ChaCha20-Poly1305; PFF via (EC) DHE.
Curvas/K.-exchange. X25519 (preferencialmente) ou secp256r1 (P-256). Chave RSA ≥2048, melhor ECDSA (P-256).
Onde há pouca confiança. Canais entre servidores, admin-API, corretores, bases - via autenticação mútua.
HSTS para web. HTTPS + proload compulsório para domínios públicos.
«Criptografar» de forma consciente. Terminação TLS no perímetro + criptografia para backends ou passthrough de passagem - selecionamos através do modelo de ameaças.
Crypto-agility. É possível alterar curvas/suítes/versões com inatividade zero.

4) Pilha de protocolos e cenários

4. 1 HTTP/2, HTTP/3 (QUIC), gRPC, WebSocket

ALPN: h2 para HTTP/2, h3 para HTTP/3; proibição h2c (sem TLS).
HTTP/3/QUIC: reduz a latência, 0-PTT embutido e a migração de conexões; 0-PTT permitir seletivamente (risco de réplica).
gRPC: acima de h2/h3; necessariamente TLS, opcionalmente mTLS + para-RPC autorização.
WebSocket: apenas wss ://; proxy/balanço - upgrade correto e pinning TLS.

4. 2 Tráfego entre servidores e serviço-bagunça

Modelo Sidecar (Istio/Linkerd e etc.). mTLS automático, políticas de resolução, rotação de certificados.
SPIFFE/SPIRE. Identidades descentralizadas de serviços (SPIFF ID), certificados SVID, TTL curtos.
Os parâmetros TLS são centralizados. Minimizar a variação de configs no código de serviços.

4. 3 Corretores/estêncil/filas

Kafka/NATS/RabbitMQ: TLS para kliyent↔broker e broker↔broker; se possível, mTLS.
SASL acima do TLS: Se o mTLS não é possível, a autenticação é por tocador/login, mas o canal é encriptado.
LCA e aprovação de tópicos. Criptografia ≠ controle de acesso.

4. 4 Bancos de dados e cachês

PostgreSQL/MySQL/SQL Server: incluir TLS, validação CN/SAN, pin SA/raiz.
Redis/Memcached: usar stunno/TLS-redis; a proibição do tráfego plain na venda.

4. 5 Rede/túneis

Entre centros de dados/nuvens: IPsec (IKEv2) ou WireGuard (conjunto moderno de primitivos).
Acesso Admin: SSH com KECH/cifra modernos; proibição de senhas, apenas chaves/SSO.

4. 6 DNS e protocolos auxiliares

DNS over HTTPS (DoH )/DNS over TLS (DoT) para clientes e dentro do cluster, sempre que possível.
Desativar conteúdo misto. Nada em http ://nas páginas https ://.

5) Certificados, PKI e gerenciamento de chaves

Modelo PKI: para domínios externos - CA público; para tráfego interno - seu próprio CA ou SPIRE-CA.
Automação: ACME/Cert-Management para Kubernetes, TTL curtos, roteiro automático.
OCSP stapling и CRL. Ativar stapling nas frentes; atualizar cadeias regularmente.
Pinning com cuidado. Em clientes móveis/descompostos - pin CA/SPKI com um mecanismo de discagem de emergência.
Armazenamento de chaves: chaves privadas em armazéns HSM/KMS/Secret; um mínimo de exposições; a proibição do loging.

6) Configurações: perfis práticos

• Versões: TLS 1. 3 (obrigatório), TLS 1. 2 (fallback).

• TLS 1. 3: `TLS_AES_128_GCM_SHA256`, `TLS_AES_256_GCM_SHA384`, `TLS_CHACHA20_POLY1305_SHA256`.
• TLS 1. 2: 'ECDHE-ECDSA-AES128-GCM-SHA256', 'ECDHE-RSA-AES128-GCM-SHA256' (+ opções AES256/CHACHA20, se necessário).
• Curvas: X25519, secp256r1.
• Certificados ECDSA-preferência, RSA-fallback.
• Cabeçalhos seguros: 'Strict-Transportation-Security', 'X-Contém-Tipos-Opções', 'X-Frame-Opções', 'Referrer-Policy'.
• Cookies: 'Secure', 'HttpOnly', 'SameSite' (Lax/Strict Design).

• O certificado do cliente é obrigatório.
• TTL de clientes SVID (relógio/dia) curtos, rotação automática.
• Políticas: quem pode se conectar a quem (intent-based/trabalhar através de uma autorização mesh).

7) Desempenho e confiabilidade

Aceleração de hardware: AES-NI/ARMv8 Crypto, preferência de ChaCha20-Poly1305 para CPU sem AES-NI.
Session resumption: TLS 1. 3 tickets; pensar o tempo de vida (equilíbrio entre perfuração e segurança).
0-PTT: somente para consultas idumpotentes; proteger-se de replay (mecanismos anti-replay do servidor).
Balanceadores/proxy: escolha claramente termination vs passthrough; termination - r-criptografar para backend.
Observabilidade: métricas de aperto/erro/negociação ALPN, porcentagem TLS 1. 3, vencimento de certificados, status OCSP.

8) Testes e verificação

Scan do perfil TLS. Verificações regulares de versões suportadas/suítes/curvas e HSTS/OCSP.
Testes negativos: proibição de downgrade, desvio de suítes fracas, falha de conexões sem SNI/sem certificado de cadeia de validade.
Pentest do canal: simulações MITM, verificação de pinning em clientes móveis, tentativas de replay 0-PTT.
Testes Chaos: caducidade/revogação do certificado, indisponibilidade OCSP/CA.

9) Erros frequentes e como evitá-los

O TLS está ativado, mas sem validação de haste. Sempre verificando CN/SAN, proibindo 'InsecureSkipVerify'.
Conteúdo misto. Bloqueie recursos http em páginas https e use CSP.
Versões fracas/antiquadas e suítes. Desativar TLS 1. 0/1. 1, CBC/RC4/3DES.
Falta de criptografia para dentro. Tráfego plain do balanceador para o aplicativo - risco.
Certificados de longa vida. Faça um TTL curto e atualizações automáticas.
SNI/ALPN inválido por proxy. Transferência correta do SNI/ALPN para TLS-passe-tru/terminação.

10) Mini-receitas (fatias de configuração)

ssl_protocols      TLSv1. 3 TLSv1. 2;
ssl_ciphers       TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve     X25519:P-256;
ssl_stapling      on;
ssl_stapling_verify   on;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params:
tls_minimum_protocol_version: TLSv1_3 validation_context:
trusted_ca: { filename: /etc/tls/ca. crt }
tls_certificates:
certificate_chain: { filename: /etc/tls/tls. crt }
private_key:   { filename: /etc/tls/tls. key }
require_client_certificate: true

[Interface]
PrivateKey = <priv>
Address  = 10. 10. 0. 1/24
[Peer]
PublicKey = <pub>
AllowedIPs = 10. 10. 0. 0/24
Endpoint  = gw. example. com:51820
PersistentKeepalive = 25

11) Políticas e conformidade

Requisitos mínimos: TLS 1. 3 onde for possível; TLS 1. 2 - com um conjunto limitado de suítes.
Regulador: PCI DSS/finsector - proibição de versões fracas/suítes; rotação obrigatória e auditoria.
Abordagem Zero Trust: identidade para cada carga de trabalho, verificação contínua e política de serviço.

12) Exploração e SLO

SLO: ≥99% dos apertos de mão bem sucedidos, ≥95% do tráfego no TLS 1. 3, 0% de conteúdo misto.
Alerts: caducidade de certificados (<14 dias), aumento das falhas de mão, queda da participação TLS 1. 3, erros OCSP stapling.
Procedimentos: substituição de emergência SA/raiz, revogação da chave comprometida, desativação 0-PTT.

13) Folhas de cheque

• O TLS 1 está desativado. 0/1. 1 e suítes fracos, AEAD e PFS incluídos.
• ALPN configurado (h2/h3); proibição h2c.
• O HSTS está incluído (para domínios públicos) e o mixed conteúdo não está disponível.
• Certificados auto-atualizados, o OCSP stapling funciona.
• Os canais internos estão protegidos por mTLS (ou o equivalente a WireGuard/IPsec).
• Verificou-se a validação de hosts/cadeias em clientes/SDK.

• Monitoramento de versões TLS/ALPN/erros e exportações.
• Plano de crypto-agility (tradução para novos suítes/curvas).
• Pentestais periódicos do canal e revezamento de configs.

14) FAQ

O TLS é suficiente apenas no perímetro?
Oh, não. O tráfego interno também deve ser encriptado (mTLS/túneis/mesh), especialmente nas nuvens e na multiplicidade.

Em: Será que o 0-RPT é necessário?
Ative-o de forma pontual para consultas idumpotentes, senão desligue por causa do risco de réplica.

Em: O que escolher para o Centro de Dados Mage? IPsec ou WireGuard?
O WireGuard é mais simples e rápido, o IPSEC é maduro e amplamente suportado. Ambos são válidos na configuração correta.

Como proteger os webhooks a caminho?
O: HTTPS com perfil atual + comprovação de certificado de remetente (se mTLS) + assinatura de carga útil e verificação de temporizador (consulte «Garantias de entrega de webhooks», «Assinatura e verificação de solicitações»).

• Criptografia At Rest
• Autenticação e autorização
• «Assinar e verificar solicitações»
• Autenticação S2S
• Gerenciamento de chaves e rotação