Rotação de chaves e tokens

1) Por que precisa de rotação

Chaves e tokens são inevitavelmente «envelhecidos» - exposição em logs/bacaps, riscos privilegiados, vulnerabilidades das bibliotecas, fuga de parceiros. A rotatividade reduz o «tempo de vida de risco» e permite a governabilidade dos incidentes. O objetivo é construir ciclos previsíveis de rotatividade e mecanismos de reversão rápida sem interrupção.

2) Área: o que é exatamente rotativo

Chaves de assinatura/criptografia: JWT (JWS/JWE), OAUTH/OIDC, SAML, webhooks (HMAC), licenças.
Segredos de integração: chaves API, cliente secret, senhas de tecnologia. usuários.
TLS/mTLS: certificados de servidor/cliente, raiz/CA intermediário.
Chaves de dados: KEK/CMK em KMS/HSM, DEK (envelope encrypition).
Токены: access/refresh, service-to-service (mTLS, HMAC), short-lived session.

3) Armazenamento, versões, marcas

KMS/HSM/Vault como fonte de verdade. É proibido armazenar chaves privadas em arquivos de imagem git/ENG.
Versionização: 'key _ id '/' version' + marcas: 'purpose = jwt-sign',' eng = prod ',' alg = ES256 ',' created _ at ',' rotates _ at '.
Políticas de acesso: princípio de direitos mínimos necessários (least privilegege), divisão de responsabilidades (SoD).
Auditoria: quem criou/leu/assinou; revistas imutáveis.

4) Pattern básicos de rotação

4. 1 Janelas sobrepostas (graceful rollover)

A nova chave é publicada no JWKS/Distribuindo o certificado.
A janela de sobreposição é validada com as chaves antigas e novas, e a assinatura é apenas nova.
Após o período grace - Remova o antigo do conjunto de confiança.

4. 2 Edição dupla (dual-run)

Um curto período em que algumas instâncias são assinadas por outras antigas, uma parte é nova (para grandes flits).
Requer uma JWKS estritamente sincronizada e monitorizar a proporção de validação por 'kid'.

4. 3 Rotate-on-schedule vs rotate-on-use

Programado para cada N dias/semana (chaves de assinatura, TLS).
Quando usado, os tokens refresh são descartáveis por cada novo lançamento (rotação «deslizante»).

5) JWT/JWKS: prática

5. 1 Cabeçalhos e identificadores

Use 'kid' no cabeçalho JWS para selecionar a chave de verificação.
Mínimo clive, curto 'exp', correto 'aud/iss/nbf'.

json
{ "alg": "ES256", "kid": "jwt-2025-10", "typ": "JWT" }

5. 2 Publicação do JWKS

O JWKS deve conter todas as chaves de verificação ativas (antiga + nova na janela grace).
O TTL curto (por exemplo, 5-15 min) é o armazenamento em dinheiro do JWKS dos clientes.
Em caso de comprometimento - remover chave comprometida do JWKS (acentuado), força deficiente do cachê.

json
{
"keys": [
{ "kty":"EC","crv":"P-256","kid":"jwt-2025-10","use":"sig","alg":"ES256","x":"...","y":"..." },
{ "kty":"EC","crv":"P-256","kid":"jwt-2025-07","use":"sig","alg":"ES256","x":"...","y":"..." }
]
}

5. 3 Cadens e prazos

Assinatura JWT: rotação da chave a cada 3-6 mes (ou mais frequentemente para high-risk).
'exp' access-token: 5-30 min; refresh - 7-30 dias (com «rotate-on-use»).
«Colagem» forçada com PoP/DPoP (consult. 8) para reduzir o risco de roubo.

6) Rotação HMAC (webhooks/assinaturas)

Guarde segredos ativos e canarinhos; aceitem as assinaturas dos dois.
Cabeçalhos: 'X-Signatura' + 'X-Timestamp'; limite de janela de £300s.
Desligamento total do antigo - depois que o remetente mudou de lado.
Para os parceiros: Publique a data-hora de mudança e endpoint a verificação.

7) TLS/mTLS e cadeias de confiança

ACME/auto-renew para certificados públicos de servidor (Let' s Encrypt ou CA corporativo).
mTLS: Certificados de cliente curtos (7 a 30 dias), rotação automática por canal (SPIFFE/SPIRE/mesh).
Rotação CA intermediário/raiz - apenas através de âncoras de confiança sobrepostas (trust bundle) e canary longo.
Acompanhe OCSP/CRL e clock-skew. No logi, as razões da rejeição da validação.

8) e ligação do cliente

DPoP (Demonstration of Proof-of-Position): O tocador está ligado ao público-key do cliente; reduz o risco de replay.
Rotação da chave do cliente = lançamento de uma nova chave DPoP, e os tokens de curta duração.
O serviço-a-serviço é preferido mTLS (o dispositivo/worker «traz» a chave para HSM/TPM).

9) Refresh-tokens: rotate-on-use

Tokens refresh descartáveis: cada troca → novo refresh + access.
Lista de retirados 'jti '/' sid' armazenados com TTL = tempo de vida refresh.
Descrição de reutilização (re-play): Revogação imediata da sessão/dispositivo, alert.

10) Críticas e listas de bloqueio

JWT sem introspecção: use o curto 'exp' + 'lista preta' 'jti' para malas críticas (local/Redis, charding por hashtag).
OAUth introspation: servidor centralizado de estatais; Dê-lhe um «ativo = falso/true» com um TTL curto.
Chave API: guarde o hash da chave (como senhas), rótulos de dono/tenante, scope, data de criação/último acesso; A crítica é instantânea.

11) Chaves de dados: encriptação envelope

CMK/KEK (KMS/HSM) protege DEK; A rotação CMK acontece sem que os dados sejam reencaminhados: pena-wrap DEK.
DEK para cada objeto/tenante/partição; KDF/HKDF para chaves derivadas.
Políticas de destruição (crypto-shredding): remoção de KEK = não leitura de dados quando comprometidos.

12) Procedimentos de incidentes (comprometimento)

1. Congelar, desligar a emissão de tokens em uma chave comprometida, transferir a emissão para outra.
2. Retirar: remover 'kid' do JWKS, retirar certificados (OCSP/CRL) e bloquear as chaves de API na lista.
3. Reduzir TTL: reduzir temporariamente os 'exp' de tokens, aumentar a verificação de PoP/DPoP.
4. Compulsório logout: deficiente sessão (revoke 'sid '/' jti').
5. Forensica e relatórios: timelines, abrangência, quem/o que sofreu; atualizar playbooks.

13) Pipeline e rollout

13. 1 Geração e publicação

Gere chaves no HSM/KMS; exportação de chave privada, proibida.
Publicação automática do JWKS/Certificados com verificação e testes.
Lançamento canário: 1% a 5% dos clientes → 100%.

13. 2 Controle de saúde

Métricas: porcentagem de validação por 'kid', erro de assinatura/certificado, à deriva do relógio.
Alerts: sobe 401/403 devido à assinatura, OCSP/CRL não está disponível para certificados que expiram (T-30/T-7/T-1).

14) Configs e exemplos

14. 1 Exemplo de política Vault/KMS (pseudo)

hcl path "transit/keys/jwt-prod" {
capabilities = ["read," "update," "list"] # signature/rotation
}
path "transit/keys/jwt-prod/rotate" {
capabilities = ["update"]
}

14. 2 Exemplo de plano de rotação do JWT

T0: create a new version of the key (kid = jwt-2025-10), add to JWKS
T0 + 15m: start signing with a new kid; validate with old and new
T0 + 7d: remove old kid from JWKS
T0 + 30d: delete old private key from KMS (schedule purge)

14. 3 Envoy: atualização compulsória do JWKS (pseudo)

yaml jwt_authn:
providers:
oidc:
issuer: https://auth. example. com/
remote_jwks:
http_uri:
uri: https://auth. example. com/.well-known/jwks. json cluster: jwks_cluster timeout: 2s cache_duration: 300s # короткий TTL

15) Observação e auditoria

Метрики: `jwt_verify_fail_total{reason}`, `jwks_refresh_total`, `jwks_kid_share{kid}`, `token_revoked_total`, `refresh_rotations_total`, `dpop_fail_total`.
Логи: `kid`, `jti`, `sid`, `reason`, `client_id`, `tenant`, `trace_id` (без PII).
Dashboards: cartão de participação 'kid', certificados caducados, taxa de retirada, assinaturas por região.

16) Antipattern

Longa vida JWT sem reversão e sem curta 'exp'.
Falta «kid» e «manual» para atribuir a chave de verificação.
Armazenamento de segredos no END/k8s-Secret sem KMS e sem criptografia no nível etCD.
Tokens de refresh não rotativos; reutilização do refresh sem detecção.
Uma única API global «em todos».
«Silencioso» lançamento de novas chaves sem publicação de JWKS e monitoramento.
Janelas de sobreposição zero (substituição instantânea) → massa 401/403.

17) Especificidades do iGaming/Finanças

Reguladores e auditorias: logs de rotações/comentários imutáveis; Prova de tempo e actos.
Parcerias PSP/KYC: chaves individuais para parceiro/jurisdição; Rever rapidamente as violações da SLA/segurança.
Multiplicidade: para-tenant API chaves com scope; isolamento das chaves das marcas/regiões.
Alto risco: PoP/DPoP para operações críticas, curtas 'exp', mTLS entre serviços internos.
Backoffice: SSO/OIDC, sessões curtas, tokens de hardware (FIDO2), rotate-on-schedule generalizado.

18) Folha de cheque pró-prontidão

• Todas as chaves privadas no KMS/HSM/Vault; exportação não permitida.
• O JWKS é publicado e armazenado com um TTL curto; os títulos do JWT incluem 'kid'.
• Plano de rotação com janela sobreposta e rollout automático.
• Os tokens refresh são descartáveis; Lista de retirados 'jti' com TTL.
• segredos HMAC: ativo + canário; recepção por ambas; Hora T anunciada para a mudança.
• TLS/mTLS: auto-renew, alertas T-30/T-7/T-1, trust bundle para mudança CA.
• Criptografia Envelope: KEK/CMK rotinam sem interrupção, DEK per-objeto/tenante.
• Métricas/alertas por assinatura, JWKS, comentários; Os dashboards 'kid'.
• Playbook incidentes (comprometimento) e exercícios regulares.
• Testes canary e réplicas de validação com novas chaves/SA.

19) TL; DR

Mantenha as chaves em KMS/HSM, assine JWT com 'kid' e publique JWKS. Rotue as chaves e os certificados de sobreposição, e mantenha as taxas de validação por 'kid'. Refresh - rotate-on-use e curtas 'exp'; para operações críticas - PoP/DPoP e mTLS. Para os dados, use criptografia envelope com rotação KEK sem interrupção. Introduza métricas/alertas, playbooks de incidentes e roteiros regulares de canário.