Criptografia e proteção API: TLS, HSTS, PFF, Rotação de segredos

1) Quadro de ameaças e objetivos

API sob ataque de MitM, interceptação de tráfego, ataques de downgrade, falsificação de tokens, vazamentos de chaves e abuso de segredos de longa duração. Objetivos de proteção:

Privacidade e integridade (TLS 1. 3 + códigos fortes).
Proteção contra downgrade/stripping (HSTS, versões/cifra não permitidas).
Minimizar danos de comprometimento (PFS, TTL curto, rotação rápida).
Autenticação cliente/serviço confiável (mTLS/tokens) e rastreabilidade.

2) TLS como base (servidor e serviço-a-serviço)

Versões e códigos:

Por padrão, o TLS 1. 3; permitir o TLS 1. 2 apenas para compatibilidade. Desativar 1. 1/1. 0.

Números prioritários TLS 1. 3:

`TLS_AES_128_GCM_SHA256`, `TLS_AES_256_GCM_SHA384`, `TLS_CHACHA20_POLY1305_SHA256`.
Para TLS 1. 2: apenas ECDHE com AES-GCM/ChaCha20 e ECDSA/RSA assinados (por exemplo, 'ECDHE-ECDSA-AES128-GCM-SHA256').

Chaves e certificados:

Chaves de servidor: ECDSA P-256/P-384 (mais rápido e curto) ou RSA 2048 +/3072.
Chaves de cliente para mTLS: ECDSA P-256; emissão via CA ou HSM/KMS.
Inclua OCSP stapling, preferencialmente com a bandeira Must-Staple, e ALPN (HTTP/2/3).

PFS (Perfect Forward Secrecy):

Fornecido por trocas efêmeras (ECDHE) - mesmo que a chave de patos do servidor não seja decifrada.
Forçar a desativação de um acordo RSA/RSA estático.

Adições modernas:

O ECH (Encrypted Cliente Hello), se suportado pela frente/CDN, esconde o SNI.
HTTP/2/3 apenas com códigos fortes; a proibição de HTTP não protegido, redirecionado para HTTPS.

3) HSTS contra TLS-stripping

Inclua HTTP Strict Transportation Security no domínio de raiz e subterfúgios:


Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Coloque o domínio na lista HSTS proload.

Acompanhe a correção antes de publicar (a reversão é difícil).

4) Autenticação mútua: mTLS e/ou tokens

mTLS entre microsserviços/API interna: certificados bilaterais, rotação automática por serviço mesh (Istio/Linkerd) ou PKI próprio.

Clientes API (integração móvel/parceira): tokens (OAuth2/OIDC, JWT), opcionalmente mTLS para high-risk.

Para frentes públicas: TLS + Toquins de curta duração OAuth2/OIDC com referência ao dispositivo/DPoP.

5) Gerenciamento de certificados e ciclo de vida

Automação ACME (por exemplo, Let' s Encrypt/CA organizacional) com atualização automática 30 dias antes de expirar.

Vida curta de certificados (≤ 90 dias) + monitoramento de prazos, alertas e pacotes de canário.

PKI centralizado: CA raiz/intermediário, CRL/OCSP, auditoria de edições e retificação.

Exemplo nginx (fatia):

nginx ssl_protocols TLSv1. 3 TLSv1. 2;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve X25519:P-256:P-384;
ssl_stapling on; ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

6) Rotação de segredos: princípios e pattern

O objetivo do rotativo é limitar o «raio explosivo» de fugas, reduzir o tempo de abuso, e fornecer lançamentos silenciosos.

Regras básicas:

Armazenamento de segredos apenas em um gerente de segredo (KMS/Vault/Cloud SM). Não há segredos em Git/imagens.
TTL curtos e rotação automática: chaves de assinatura, senhas de banco de dados, chaves de API do provedor.
Publicação dupla (dual-key window): As chaves antiga e nova estão ativas ao mesmo tempo durante o período de sobreposição.
Versioning + kid (para JWT/JWKS), «grace» janela de validação de tokens antigos.

O que rotular regularmente:

Chaves JWT (assinatura/criptografia), HMAC-segredos de webhooks e callback 'ov, Senhas/contas de BD, confissão de caixas (Redis), tocas CI/CD, Segredos de provedores (KYC/AML, lenços, SMS/e-mail), chaves SSH automáticas.

Desencadeadores de rotação não programada, suspeita de fuga, demissão de funcionários com acesso, mudança de fornecedor, exigências do regulador.

7) JWT/JWKS: overlay de papel seguro

Publique o JWKS endpoint com a chave atual e futura ('kid' obrigatório).

Processo de rotação:

1. Gerar uma nova chave → adicionar ao JWKS como «segunda chave».

2. Atualizar assinantes → lançar novos tokens com uma nova chave.

3. Espere por TTL antigos tokens → remova a chave antiga do JWKS.

Instale os TTL (por exemplo, 5-15 minutos) + fluxos de refresh com verificação adicional.

8) Segredo-gestão na prática

KMS + envelope encrypition: chave mestra no HSM/KMS, os dados são criptografados por DEK.

Vault/Cloud Secret Gerente: versões dinâmicas de BD (emissão de estudos com TTL), rotação periódica.

Kubernetes: External Secrets/Secrets Store CSI; criptografar etcd; RBAC; a proibição de logar segredos.

Acesso por papel: IAM/ABAC, princípio de menores privilégios, limites de hardware (HSM, TPM).

Auditoria completa: quem, quando, porquê leu/alterou.

9) Segurança de transporte dentro do perímetro

Não confia na «rede interna»: por todo o lado (zero-trust).

O Service mesh automatiza certificados, reiniciamento e rotatividade, observabilidade (mTLS padrão).

Minimize as terminações TLS, seja em edge + east-west criptografado ou criptografado de forma completa.

10) Políticas de segurança API sobre TLS

Rate limiting/Proteção DoS, verificação da assinatura de webhooks (HMAC com rotação de segredos).

Content-Security-Policy/Referrer-Policy/X-Content-Type-Options для фронта.

mTLS para endpoint's críticos (pagamentos, adminca), IP allow-list para parceiros.

Proteção replay: timestamp + nonte em pedidos assinados, janelas de no máximo 5 minutos.

11) Monitoramento e testes

Observabilidade TLS: versões/cifra em métricas, alertas em tentativas de downgrade, aumento de falhas nos apertos de mão.

Scanners (CI/CD e regularmente à venda): verificação de códigos suportados, certificados, HSTS, OCSP.

Chaos/Doutor-exercício: caducidade do certificado, queda do gerente de segredo, comprometimento da chave de assinatura - verifique os planos de resposta.

12) Procedimentos de resposta

Comprometer a chave: Revogação imediata do certificado/remoção da chave do JWKS, inversão para reserva, regeneração forçada de tokens.

Terminação sem extensão: degradação temporária (apenas tráfego interno), reinstalação automática de certificados.

Relatório de incidente, timeline, sujeitos afetados, tecnologia. detalhes que ajustam as medidas.

13) Folha de cheque de verificação rápida (prod-ready)

Apenas TLS 1. 3 (+ 1. 2 para legasi), uma lista rigorosa de códigos.
HSTS с `preload`, OCSP stapling, ALPN.
ECDHE para PFS; ECDSA P-256/384 ou RSA 3072.
mTLS dentro de um cluster/entre serviços críticos.
JWKS + kid, TTL de toques curtos, plano de rotação.
Segredos - apenas em KMS/Vault, rotação automática de BD/provedores.
Atualização automática de certificados (ACME), alertas em 30 dias.
I/CD verificação de cabeçalhos de segurança e códigos vulneráveis.
Runbook documentado 'e: rotação, levantamento, incidentes.

Currículos

A API segura é uma combinação do TLS 1. 3 + HSTS + PFS como mínimo obrigatório e processos maduros de gerenciamento de chaves e segredos. Adicione mTLS entre os serviços, automatize o lançamento/rotação através do KMS/Vault/mesh, mantenha os TTL curtos e as «janelas duplas» ao trocar as chaves - e minimize os riscos de interceptação, downgrade e abuso de segredos sem quebrar a disponibilidade e velocidade do produto.