Gestão de chaves e ciclo de vida: geração, armazenamento, rotação e revogação

Gestão de chaves é o conjunto de práticas e controles que garantem que chaves criptográficas sejam geradas, armazenadas, usadas, rotacionadas e revogadas de forma segura e auditável. Na prática, muitos incidentes não acontecem por “quebra” de algoritmos, mas por falhas no ciclo de vida: chaves expostas em repositórios, permissões excessivas, rotação inexistente, cópias sem controle, ou incapacidade de revogar rapidamente após um vazamento.

Este capítulo foca no ciclo de vida operacional das chaves (independente do algoritmo), com decisões e passos práticos para equipes de engenharia, segurança e operações.

O que é o ciclo de vida de uma chave

Uma chave passa por estados e eventos previsíveis. Um modelo útil para organizar processos é:

• Planejamento: definir propósito, escopo, proprietários, requisitos de disponibilidade e auditoria.
• Geração: criar a chave com entropia adequada e parâmetros corretos.
• Distribuição/Provisionamento: entregar a chave (ou permitir seu uso) para serviços autorizados, minimizando exposição.
• Armazenamento: manter a chave protegida em repouso, com controles de acesso e backup seguro.
• Uso: aplicar a chave somente para o propósito definido, com limites (por exemplo, volume, tempo, contexto).
• Rotação: substituir por uma nova chave periodicamente ou por evento.
• Revogação/Desativação: impedir uso futuro quando comprometida, expirada ou desnecessária.
• Destruição: apagar material criptográfico e cópias, garantindo que não seja recuperável.

Dois conceitos aparecem o tempo todo:

• Identidade da chave: um identificador estável (Key ID) que permite referenciar a chave sem expor seu material. Ajuda em logs, auditoria e rotação.
• Separação entre “chave” e “acesso à chave”: idealmente, aplicações não “possuem” a chave; elas recebem permissão para usá-la via um serviço/infra de chaves.

Classificação e escopo: antes de gerar qualquer chave

Antes da geração, defina atributos que determinam controles e processos:

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

• Tipo de chave: simétrica, par assimétrico, chave de assinatura, chave de criptografia, chave para MAC, chave de wrapping (para proteger outras chaves), etc.
• Finalidade (purpose): “criptografar dados em repouso do serviço X”, “assinar tokens internos”, “proteger segredos de integração”, etc. Evite reutilizar a mesma chave para finalidades diferentes.
• Escopo: por ambiente (prod/homolog), por serviço, por tenant/cliente, por região. Quanto menor o escopo, menor o impacto de um vazamento.
• Criticidade: impacto se vazar (financeiro, regulatório, reputacional). Isso define exigência de HSM, quorum, auditoria e rotação.
• Requisitos de disponibilidade: se a chave ficar indisponível, o serviço para? Isso influencia redundância e estratégia de backup.
• Requisitos de auditoria: quais eventos precisam ser registrados (uso, falha, rotação, mudança de política).

Uma forma prática de materializar isso é manter um “registro de chaves” (key registry) com metadados: Key ID, dono, propósito, data de criação, data de expiração, política de rotação, serviços autorizados, e links para runbooks.

Geração de chaves: entropia, isolamento e repetibilidade operacional

Princípios de geração segura

• Use um gerador criptograficamente seguro (CSPRNG) do sistema operacional ou de um serviço de chaves. Evite gerar chaves com randômicos fracos, timestamps, UUIDs ou “misturas caseiras”.
• Gere no local mais confiável: preferencialmente dentro de um módulo/serviço de chaves (HSM/KMS) para que o material não saia em texto puro.
• Não reutilize chaves entre ambientes e clientes. Chave de homologação não deve existir em produção.
• Defina tamanho e parâmetros conforme política interna e recomendações atuais. Padronize para reduzir variação e erros.

Passo a passo prático: geração com serviço central de chaves

Um fluxo genérico (independente do fornecedor) para criar uma chave simétrica de criptografia de dados:

• 1) Criar uma solicitação: o time do serviço abre um ticket/PR com propósito, escopo, ambientes, e necessidade de rotação.
• 2) Aprovação: segurança valida escopo e controles (por exemplo, se precisa de HSM, quorum, ou restrição por rede).
• 3) Criar a chave no serviço de chaves: a chave recebe um Key ID e política de acesso inicial (quem pode usar, quem pode administrar).
• 4) Configurar aliases/versões: criar um alias estável (ex.: alias/serviceX-data) que aponta para a versão atual. Isso facilita rotação sem alterar código.
• 5) Registrar metadados: atualizar o key registry com Key ID, alias, dono, datas e runbook.
• 6) Validar em ambiente controlado: testar criptografar/descriptografar com dados de teste e verificar logs/auditoria.

Para pares assimétricos, o passo a passo é similar, com a diferença de que a chave privada idealmente nunca sai do módulo seguro; apenas a chave pública é exportada/distribuída.

Armazenamento de chaves: onde e como guardar

“Armazenar” significa proteger o material em repouso e controlar quem pode obtê-lo ou usá-lo. Há três padrões comuns:

• Chave gerenciada por serviço de chaves (recomendado): aplicações chamam uma API para criptografar/descriptografar ou para obter uma chave derivada/temporária. O material principal fica protegido e auditável.
• Chave armazenada como segredo (aceitável em casos limitados): a chave fica em um cofre de segredos e é entregue ao processo em runtime. Exige disciplina forte de acesso, rotação e prevenção de vazamento em logs/memória.
• Chave embutida no código/arquivo: antipadrão. Dificulta rotação, vaza em repositórios e artefatos, e costuma ser copiada para múltiplos lugares.

Envelope encryption e hierarquia de chaves

Para reduzir exposição e facilitar rotação, use hierarquia:

• DEK (Data Encryption Key): chave que criptografa os dados (pode ser por arquivo, por objeto, por registro, por sessão).
• KEK (Key Encryption Key) ou wrapping key: chave que criptografa (wrap) a DEK. A KEK fica no serviço de chaves; a DEK wrapped pode ser armazenada junto do dado.

Benefícios: você pode rotacionar a KEK sem recriptografar todo o dado (basta rewrap das DEKs), e pode limitar o impacto se uma DEK vazar (escopo menor).

Controles essenciais no armazenamento

• Controle de acesso por função: separar “administrar chave” (criar, rotacionar, mudar política) de “usar chave” (encrypt/decrypt/sign/verify). Evite que a mesma identidade tenha ambos sem necessidade.
• Princípio do menor privilégio: serviços só devem ter permissão para as operações estritamente necessárias e apenas no ambiente correto.
• Segmentação: chaves de produção acessíveis apenas de redes/identidades de produção.
• Auditoria imutável: logs de uso e administração, com retenção e monitoramento.
• Backups e recuperação: se a chave é crítica para descriptografar dados, planeje como recuperar em caso de falha do serviço de chaves, perda de região, ou erro humano. Para alguns cenários, isso envolve exportação controlada, escrow com quorum, ou chaves replicadas.

Distribuição e uso: como evitar que a chave “vire arquivo”

O objetivo é que a aplicação consiga executar operações criptográficas sem que o material da chave circule desnecessariamente.

Padrões práticos

• Chave não exportável: preferir chaves marcadas como não exportáveis; a aplicação pede a operação (ex.: “descriptografe este blob”) e recebe o resultado.
• Credenciais de curta duração: em vez de credenciais estáticas para acessar o serviço de chaves, use identidades com tokens temporários (reduz impacto de vazamento).
• Contexto de criptografia: associe metadados obrigatórios (ex.: nome do serviço, ambiente, tenant) que precisam bater na hora de descriptografar. Isso reduz uso indevido se um blob for copiado para outro contexto.
• Limites de uso: quando possível, limite por taxa, por IP/rede, por horário, por região.

Passo a passo prático: criptografar dados com DEK + KEK

• 1) Aplicação solicita uma DEK: pede ao serviço de chaves uma DEK nova (ou derivada) para aquele objeto.
• 2) Serviço retorna: a DEK em texto puro (apenas na memória do processo) e a DEK wrapped pela KEK (para persistir).
• 3) Aplicação criptografa o dado: usa a DEK em memória para criptografar o payload.
• 4) Persistência: armazena o dado criptografado + a DEK wrapped + metadados (Key ID/alias, versão, contexto).
• 5) Descriptografia: ao ler, a aplicação envia a DEK wrapped ao serviço de chaves para unwrap e obtém a DEK em memória para descriptografar.

Pontos de atenção: limpar buffers quando possível, evitar logs com payloads, e garantir que dumps de memória e ferramentas de debug em produção sejam controlados.

Rotação de chaves: quando, por quê e como fazer sem downtime

Rotação é a substituição planejada de uma chave por outra. Ela reduz janela de exposição e limita impacto de comprometimentos não detectados. Há dois tipos:

• Rotação programada: periódica (por exemplo, a cada 90/180/365 dias), conforme criticidade e requisitos.
• Rotação por evento: após suspeita de vazamento, mudança de equipe/fornecedor, alteração de política, incidente, ou descoberta de acesso indevido.

Estratégias de rotação

• Rotação por versão (key versioning): manter múltiplas versões ativas para descriptografia/verificação, mas usar apenas a versão mais recente para criptografia/assinatura.
• Alias apontando para “current”: aplicações referenciam um alias estável; a rotação troca o alvo do alias.
• Recriptografia gradual: dados antigos permanecem com chaves antigas até serem regravados (lazy re-encryption). Útil quando recriptografar tudo é caro.
• Rewrap de DEKs: se você usa envelope encryption, pode rotacionar a KEK e rewrap as DEKs sem tocar no dado criptografado.

Passo a passo prático: rotação sem quebrar leitura de dados antigos

Exemplo genérico para dados em repouso com envelope encryption:

• 1) Preparar suporte a múltiplas versões: o formato do dado deve carregar key_id e/ou key_version e o blob da DEK wrapped.
• 2) Criar nova versão da KEK: no serviço de chaves, gerar nova versão e manter a antiga habilitada para unwrap.
• 3) Atualizar o alias “current”: apontar para a nova versão para operações de wrap/geração de DEK.
• 4) Implantar e monitorar: garantir que novas gravações usam a nova versão; monitorar falhas de decrypt/unwrap.
• 5) Rewrap em lote (opcional): um job percorre objetos e rewrap as DEKs para a nova KEK, sem recriptografar o payload.
• 6) Desativar versão antiga: após janela segura e confirmação de que não há dependências, desabilitar a versão antiga para uso e manter apenas para leitura se necessário por um período definido.
• 7) Remover/Destruir: quando não houver mais dados dependentes, destruir a versão antiga conforme política.

Para chaves de assinatura, a rotação costuma exigir distribuição de chave pública nova e um período de convivência: sistemas verificadores aceitam assinaturas com a chave antiga e a nova até a migração completa.

Revogação e desativação: reagindo a comprometimento e reduzindo blast radius

Revogar é impedir uso futuro de uma chave (ou de uma credencial que dá acesso a ela). Na prática, você precisa de mecanismos rápidos e testados, porque incidentes exigem ação em minutos.

Cenários comuns que exigem revogação

• Suspeita de vazamento: chave apareceu em log, repositório, artefato, ticket, ou foi acessada por identidade indevida.
• Comprometimento de host/contêiner: se a chave era entregue ao processo, considere-a exposta.
• Erro de configuração: política de acesso permitiu uso amplo por engano.
• Fim de vida do sistema: serviço descontinuado, migração concluída.

Revogação na prática: o que fazer primeiro

• 1) Conter: bloquear identidades suspeitas e reduzir permissões imediatamente (muitas vezes é mais rápido revogar o acesso do que destruir a chave).
• 2) Desabilitar a chave/versão: no serviço de chaves, desabilitar operações de uso (encrypt/decrypt/sign) conforme o caso.
• 3) Rotacionar por evento: criar nova chave/versão e atualizar alias/configurações para que o sistema volte a operar com material novo.
• 4) Tratar dados existentes: decidir se é necessário recriptografar/rewrap, invalidar tokens, ou reemitir artefatos assinados.
• 5) Auditar e caçar cópias: procurar a chave em repositórios, imagens de contêiner, backups, logs e máquinas de desenvolvedores.

Revogação tem um custo: pode quebrar a capacidade de descriptografar dados antigos. Por isso, diferencie desabilitar para novos usos (bloquear encrypt/sign) de bloquear também leitura (decrypt/verify). Em incidentes, é comum bloquear imediatamente novos usos e planejar a migração/recriptografia para eliminar dependência da chave comprometida.

Políticas de expiração, retenção e destruição segura

Chaves não devem existir “para sempre” sem justificativa. Defina:

• Data de expiração: quando a chave deve ser rotacionada ou desativada.
• Janela de convivência: por quanto tempo versões antigas permanecem habilitadas para leitura/verificação.
• Retenção de material: se há necessidade regulatória de manter capacidade de descriptografar por X anos, isso impacta destruição.
• Destruição: processo formal para eliminar versões antigas e confirmar que backups/replicações também foram tratados.

Em serviços de chaves, “destruir” costuma ser uma operação irreversível. Exija aprovação e tenha um runbook com checagens: dependências, dados ainda criptografados, jobs de rewrap concluídos, e validação por métricas.

Auditoria, monitoramento e detecção de uso anômalo

Gestão de chaves sem observabilidade vira “caixa-preta”. Registre e monitore eventos como:

• Administração: criação, mudança de política, habilitar/desabilitar, rotação, destruição.
• Uso: chamadas de encrypt/decrypt/sign/verify, com identidade chamadora, origem, Key ID, sucesso/erro.
• Erros: picos de falha de decrypt podem indicar versão errada, corrupção de dados, ou tentativa de acesso indevido.

Exemplos de alertas úteis:

• Uso de uma chave fora do horário padrão ou fora da rede esperada.
• Aumento súbito de operações de decrypt (pode indicar extração em massa).
• Uso de uma chave por um serviço que não está na lista de autorizados.
• Tentativas repetidas de acesso negado (brute force de permissões).

Runbooks e testes: garantindo que rotação e revogação funcionam quando necessário

Processos de rotação e revogação precisam ser exercitados. Um runbook mínimo deve conter:

• Inventário: onde a chave é usada (serviços, filas, bancos, jobs, pipelines).
• Procedimento de rotação: comandos/ações, ordem, validações e rollback.
• Procedimento de revogação: contenção, desabilitar, substituir, e como lidar com dados legados.
• Critérios de sucesso: métricas (taxa de erro, latência, volume de operações), e amostras de leitura/escrita.
• Plano de comunicação: quem aprova, quem executa, quem é informado.

Teste em ambiente de homologação com dados representativos e simule falhas: versão antiga desabilitada cedo demais, alias apontando errado, permissões incompletas, ou indisponibilidade do serviço de chaves.

Erros comuns e como evitá-los

• Chave compartilhada por muitos sistemas: aumenta blast radius. Prefira chaves por serviço/escopo.
• Rotação “manual e rara”: vira evento traumático. Automatize e faça rotinas frequentes.
• Sem versionamento no formato do dado: dificulta migração. Sempre grave key_id/key_version e metadados necessários.
• Permissões amplas: identidades com * para chaves e operações. Restrinja por Key ID, operação e ambiente.
• Exportar chave privada sem necessidade: aumenta risco. Prefira não exportável e operações dentro do módulo seguro.
• Backups sem controle: cópias de chaves em locais não auditados. Defina onde pode existir cópia e como é protegida.
• Logs perigosos: registrar blobs, cabeçalhos sensíveis, ou exceções com material. Faça revisão de logging e mascaramento.

Checklist operacional para implantar gestão de chaves

• Existe um key registry com dono, propósito, escopo, datas e runbooks?
• Chaves de produção são separadas de homologação e desenvolvimento?
• Aplicações usam alias/Key ID e suportam múltiplas versões para leitura?
• Há política clara de rotação (programada e por evento) e ela é testada?
• Há auditoria centralizada de uso e alertas para anomalias?
• Permissões separam administrar vs usar e seguem menor privilégio?
• Há estratégia de backup/recuperação compatível com o risco e com a disponibilidade exigida?
• Existe procedimento de revogação rápido, com passos de contenção e migração?