Gerenciamento de chaves e rotação

As chaves são as raízes da plataforma. Um sistema de gerenciamento de chaves confiável (KMS/HSM + processos + telemetria) transforma a criptografia em uma única integração em uma operação diária: as chaves são atualizadas regularmente, são utilizadas de forma transparente, os compromissos são localizados e os clientes passam por uma mudança de chave sem downthame.

1) Objetivos e princípios

Crypto agility: possibilidade de alterar algoritmo/comprimento de chave sem grandes migrações.
Least exposure: as chaves privadas não deixam o KMS/HSM; operações de assinatura/decifração - removidas.
Short-lived arts: token/chaves de sessão vive minutos-relógio, não semanas.
Dual-key/Dual-cert janelas: rotações sem custo.
Regional & tenant isolation: as chaves estão divididas por região e locatário.
Full auditability: registro de operações imutável, avaliação HSM, controle de acesso.

2) Classificação das chaves

Raiz (Root CA/Master Key): Uso muito raro, mantido no HSM, usado para o lançamento de chaves intermediárias ou de dados-key.
Operação: assinatura JWT/eventos, TLS, assinatura de webhooks, criptografia de configurs/PII.
Sessão/horário: DPoP, mTLS-binding, ECDH para canal/diálogo.
As chaves de integração (públicas) e os segredos do HMAC.
Data Keys (DEK): usam criptografia envelope sob KEK, não são armazenados de forma explícita.

3) Identificação de chaves e política de uso

yaml key:
kid: "eu-core-es256-2025-10"
alg: "ES256"         # или EdDSA, RSA-PSS, AES-GCM, XChaCha20-Poly1305 purpose: ["jwt-sign","webhook-sign"]
scope: ["tenant:brand_eu","region:EE"]
status: "active"       # active      next      retiring      revoked created_at: "2025-10-15T08:00:00Z"
valid_to:  "2026-01-15T08:00:00Z"

Regras: «Um objetivo é uma chave» (mínimo de sharing), campos e prazos claros.

4) Ciclo de vida da chave (KMS/HSM)

1. Generate: no HSM/KMS, com política de exportação = proibido.
2. Publish: para assimetria - JWKS/certificado com 'kid'.
3. Use: operações remotas (sign/decrypt) com IAM controlado.
4. Rotate: iniciar a chave 'next' e ativar dual-accept.
5. Retire: Traduza o antigo para 'retiring', depois 'revoked'.
6. Destroy: destruir o material (com o protocolo purge) após a janela de discussões.

5) Rotação: estratégias

Scheduled: calendário (por exemplo, cada 1 a 3 meses para assinar JWT, 6 a 12 m para sertões TLS).
Rolling: mudança gradual dos consumidores (JWKS já contém uma nova chave; o emissor começa a assinar o novo após o aquecimento dos cajus).
Forted (segurança): rotação imediata para comprometimento; uma janela dual-accept curta e agressiva de artefatos.
Staggered per region/tenant: para não «bater» o mundo ao mesmo tempo.

Regra de ouro, primeiro a publicação, depois a assinatura nova, e só depois de expirado, a crítica do antigo.

6) Janela dual-key (câmbio)

Publicamos o JWKS com o antigo e novo 'kid'.
Os verificadores aceitam os dois.
O emissor começa a assinar em N/h.
Monitor a taxa de verificação do antigo/novo 'kid'.
Quando a meta é atingida, o retairim é antigo.

yaml jwks:
keys:
- kid: "eu-core-es256-2025-10" # new alg: "ES256"
use: "sig"
crv: "P-256"
x: "<...>"; y: "<...>"
- kid: "eu-core-es256-2025-07" # old alg: "ES256"
use: "sig"
...

7) Políticas de assinatura e validação

Algoritmos padrão: ES256/EdDSA para assinatura; O RSA-PSS está onde é necessário.
Proibir 'none '/algoritmos fracos; whitelisting do lado da verificação.
Clock skew: Permeamos £300 c, logando desvios.
Key pinning (serviços internos) e curto TTL JWKS-kesha (30-60 s).

8) Criptografia Envelope e KDF

ciphertext = AEAD_Encrypt(DEK, plaintext, AAD=tenant    region    table    row_id)
DEK = KMS. Decrypt (KEK, EncryptedDEK )//on access
EncryptedDEK = KMS. Encrypt (KEK, DEK )//on write

O KEK é armazenado no KMS/HSM, rotativo regularmente.
O DEK é criado para objeto/partição; quando o KEK é rotativo, executamos re-wrap (rapidamente, sem criptografia de dados).
Para os fluxos - ECDH + HKDF para a saída de chaves de canal de curta duração.

9) Regionalidade e multi-tenente

As chaves e JWKS são regimentais: 'eu-core', 'latam-core' - conjuntos diferentes de chaves.
Divisão IAM/auditoria por tenant/region; as chaves não são «arrastadas» entre os residentes.
'kid' codifique com prefixo de domínio de confiança 'eu-core-es256-2025-10'.

10) Segredos de integração (HMAC, API-chaves)

Armazenar em KMS-backed Secret Store, a emissão através de short-lived clientes secret (rotation policy ≤ 90 dias).
Suporte a dois segredos ativos (dual-secret) na rotatividade.

Para webhooks - timestamp + HMAC assinatura do corpo; janela de tempo ≤ 5 minutos

11) Controle de acesso e processos

Matriz IAM: quem pode 'generate', 'sign', 'decrypt',' rotate ',' destroy '(mínimo de papéis).
Uma cirurgia sensível de 4 olhos requer duas confirmações.
Mudança windows: janelas de inclusão de nova chave e regiões de teste de canários.
Runbooks: modelos de procedimentos para rotações scheduled e forced.

12) Observação e auditoria

• `sign_p95_ms`, `decrypt_p95_ms`, `jwks_skew_ms`,
• consumo por 'kid', 'old _ kid _ usage _ ratio',
• `invalid_signature_rate`, `decrypt_failure_rate`.

• Cada operação de assinatura/transcrição: 'who/what/when/where/kid/purpose'.
• Histórico de chaves e pedidos de rotação/recall.
• Avaliação HSM, registros de acesso a materiais-chave.

13) Playbooks (incidentes)

1. Comprometer chave de assinatura

Revoke imediatamente o antigo 'kid' (ou tradução para 'retiring' com janela mínima), publicação do novo JWKS, TTL de toquins reduzidos, força-logout/deficiência RT, comunicações a proprietários de integração, auditoria retrô.

2. Massa 'INVALID _ SINAL' após rotatividade

Verifique o cachê JWKS/clock skew, devolva o dual-aceitt, estenda a janela, envia aos clientes.

3. Aumento da latência KMS/HSM

Não é possível ativar o dinheiro local de assinaturas; em vez disso, batch/queue no emissor, autoscaling HSM proxy, priorizar os fluxos críticos.

4. Rejeição de uma região

Ativar os procedimentos de isolamento regional; não «puxar» chaves de outras regiões; degradar funções atribuídas a assinaturas em uma região tombada.

14) Testes

Contract: correto JWKS, correto 'kid '/alg/use, compatibilidade de clientes.
Negative: assinatura falsa, «kid» obsoleto, alg incorreto, clock skew.
Chaos: rotação instantânea, indisponibilidade do KMS, «deriva» do tempo.
Load: pico de assinaturas (JWT/webhooks), pico de transcrição (PII/pagamento).
E2E: janela dual-key: lançamento - verificação - transferência de tráfego - remoção do antigo.

15) Exemplo de configuração (YAML)

yaml crypto:
regions:
- id: "eu-core"
jwks_url: "https://sts. eu/.well-known/jwks. json"
rotation:
jwt_sign: { interval_days: 30, window_dual: "48h" }
webhook: { interval_days: 60, window_dual: "72h" }
kek:   { interval_days: 90, action: "rewrap" }
alg_policy:
sign: ["ES256","EdDSA"]
tls: ["TLS1. 2+","ECDSA_P256"]
publish:
jwks_cache_ttl: "60s"
audit:
hsm_attestation_required: true two_person_rule: true

16) Exemplo de JWKS e marcadores em artefatos

json
{ "alg":"ES256", "kid":"eu-core-es256-2025-10", "typ":"JWT" }

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

17) Anti-pattern

Chaves de longa duração «anos» e comuns a todas as regiões.
Rotação «em um momento» sem dual-accept.
Exportar chaves privadas do KMS/HSM «para rapidez».
Mistura de tarefas: assinar JWT com uma única chave e criptografar dados.
Nenhum registro/avaliação HSM ou limite IAM.
Não há nenhum mecanismo de ré-wrap para DEK na rotação KEK.
Os «segredos» manuais em ev em vez da Secret Store.

18) Folha de cheque antes de vender

• Todas as chaves privadas no KMS/HSM; Matriz IAM e princípio de quatro olhos configurados.
• Políticas de algoritmos, comprimento de chaves e prazo de vida foram aprovados.
• Processo dual-key ativado com monitoramento de participação por 'kid'.
• O JWKS é publicado com um TTL curto e aquecido; os clientes aceitam ≥2 chaves.
• Criptografia Envelope: KEK rotável, DEK re-wrap sem interrupção.
• Isolamento regional e conjuntos separados de chaves por tenentes.
• Playbooks de comprometimento/rolling/rotação de força; Testes de treino.
• Métricas ('old _ kid _ usage _ ratio', 'invalid _ indicação _ rate') e alertas estão ativadas.
• O conjunto de testes contracto/negativo/chaos/load/E2E foi concluído.
• Documentação para integrações: como processar a mudança 'kid', quais janelas e códigos de erro.

Conclusão

O controle de chaves é uma disciplina operacional: KMS/HSM como fonte de verdade, rotações regulares e seguras com dual-key, isolamento regional e tenente, criptografia envelope e observabilidade. Seguindo estas regras, você recebe criptocontos que são escalados, resistentes a incidentes e facilmente explicáveis para o auditor - e desenvolvedores e integradores passam por qualquer mudança sem dor.