Gerenciamento de Chaves (KMS, HSM)

Gerenciamento de chaves é a disciplina de criar, distribuir, usar, rotacionar e destruir chaves criptográficas ao longo de todo o ciclo de vida, garantindo que o valor da criptografia não se perca pela chave errada no lugar errado. Em produção, a chave é o ativo que concentra todo o valor do sistema: dado cifrado com chave protegida é inútil para o atacante, e chave exposta junto do dado devolve o problema original. Serviços como o AWS KMS resolvem a operação corrente com material protegido em hardware, políticas de uso por chave e trilha completa de auditoria, enquanto HSMs dedicados atendem requisitos regulatórios que exigem controle exclusivo sobre o segredo. Este arquivo cobre o ciclo de vida da chave, a operação do KMS com CMKs e aliases, a distinção entre key policies e IAM, o papel do HSM em cenários FIPS e os custos por requisição.

Conceito: a chave como ativo central

A criptografia moderna assume que o algoritmo é público e que a segurança mora inteiramente na chave. Essa premissa muda o desenho da arquitetura: o dado pode estar replicado em muitas regiões, mas a chave precisa estar em um lugar único, protegido, auditável e sob política própria. O serviço de chaves funciona como gargalo deliberado, um choke point onde toda operação de cifra e decifra passa por autenticação, autorização e registro, convertendo o acesso ao dado em evento verificável.

A hierarquia de chaves organiza esse gargalo. Na base fica o material protegido pelo serviço ou pelo HSM; acima ficam as chaves de cliente, as CMKs, que representam uma identidade lógica de chave; na ponta ficam as chaves de dados efêmeras usadas no envelope encryption para cifrar payloads de qualquer tamanho. Cada nível minimiza o tempo de vida e a exposição do material, e o desenho correto da hierarquia é decisão de arquitetura, não detalhe de implementação.

O problema que o gerenciamento de chaves resolve

Sem um sistema dedicado, chaves acabam em código, variáveis de ambiente, arquivos de configuração e repositórios git, com rotação manual ou inexistente e nenhum registro de quem as usou. Esses erros não são teóricos: segredo versionado em repositório é achado recorrente em vazamento, e chave sem rotação significa que um comprometimento antigo vale para sempre. O gerenciamento centralizado resolve os três problemas de uma vez: a chave nunca sai do serviço em texto claro, o uso depende de autorização fina por identidade e toda operação gera trilha imutável.

Há também o problema operacional de rotacionar sem parar nada. Rotação de chave manual em produção envolve janelas de migração, riscos de incompatibilidade e coordenação entre times, o que na prática significa que não acontece. Serviços gerenciados automatizam esse ciclo, e a automação é justamente o que torna a rotação uma política executável em vez de uma promessa.

Ciclo de vida da chave

O ciclo de vida completo vai da criação ao destruição programada, e cada fase tem um cuidado específico de produção.

A fase de destruição é a mais delicada: toda chave destruída torna permanentemente ilegível todo dado cifrado por ela, então o inventário de dependências precisa ser revisado e a destruição, programada com janela de espera que permita abortar. A fase de rotação tem nuance inversa: o material antigo é retido para decifrar dados históricos, então rotação encolhe a janela de exposição futura, não resolve vazamento passado.

AWS KMS: CMKs, aliases e key policies

A CMK, hoje chamada de KMS key, é o objeto lógico que representa uma chave, com material protegido pelo serviço e um documento de política próprio. As APIs principais são Encrypt, Decrypt e GenerateDataKey para chaves simétricas, e Sign e Verify para assimétricas. O alias é o indirecionamento que desacopla aplicação de chave: o código referencia alias/financeiro-dados, e a chave por trás pode ser trocada sem redeploy, o que é essencial em rotação manual e migração de domínio. A política da chave, a key policy, é o documento obrigatório que define quem administra e quem usa.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Administracao restrita ao papel de seguranca",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/seguranca-key-admin" },
      "Action": ["kms:Create*", "kms:PutKeyPolicy", "kms:ScheduleKeyDeletion", "kms:DescribeKey"]
    },
    {
      "Sid": "Uso delegado ao IAM para a aplicacao",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/app-pagamentos" },
      "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
      "Resource": "*"
    }
  ]
}

O padrão desse documento é o mais importante do tópico: administração restrita a um papel de segurança e uso delegado ao IAM para os papéis de aplicação. A primeira declaração impede que qualquer pessoa altere a política ou destrua a chave, e a segunda permite que o controle granular de uso fique nas políticas IAM, que o time de plataforma já administra. O Resource: "*" no bloco de uso é exigência do serviço para key policies, não um erro, porque a política está anexada à chave em si.

Rotação automática e rotação manual

A rotação automática do KMS, disponível para chaves simétricas, cria material novo a cada 12 meses mantendo o mesmo identificador de chave. Nada na aplicação muda, nada precisa ser recifrado, e o material antigo permanece disponível para decifrar dados históricos. Essa transparência é o que torna a rotação uma configuração em vez de um projeto. Chaves assimétricas não suportam rotação automática, porque o certificado e a chave pública publicados não podem trocar silenciosamente; nesses casos a estratégia é criar chave nova, trocar o alias e manter a chave antiga para verificação de assinaturas antigas.

A nuance que confunde é o efeito real da rotação sobre dados já cifrados. Como o material antigo decifra o histórico, um atacante que obteve o material de hoje ainda lê o passado. A rotação limita a exposição futura e reduz o valor de material antigo ao longo do tempo, e a proteção do histórico vem do desenho do envelope encryption, com chaves de dados de vida curta por objeto ou por lote.

Key policies versus IAM policies

A avaliação de permissão do KMS tem lógica própria, e entendê-la evita tanto o acesso indevido quanto a frustração de política que não funciona.

A regra de avaliação funciona assim: o acesso é permitido quando a key policy autoriza diretamente, ou quando a key policy delega ao IAM e a política IAM também autoriza; uma negação explícita em qualquer um dos dois vence tudo. O erro clássico é criar política IAM perfeita e esquecer que a key policy da chave nunca delegou ao IAM, e o resultado é acesso negado sem explicação óbvia. O padrão recomendado é a key policy conceder kms:* ao papel administrador e delegar o restante ao IAM, mantendo a administração fora do alcance do gerenciamento de identidades comum.

Condições de acesso e EncryptionContext

Além de definir quem pode usar a chave, o KMS permite restringir como ela é usada. Condições como kms:ViaService limitam as chamadas a um serviço específico, aws:PrincipalOrgID restringe o uso à organização, e o EncryptionContext cria vínculo entre a chave e o uso declarado, porque o contexto informado na decifração precisa ser idêntico ao da cifragem. O EncryptionContext é o mecanismo que impede, por exemplo, que um material cifrado para snapshot de produção decifre dados de outro domínio, mesmo com a mesma CMK. Em serviços como DynamoDB e S3 com SSE-KMS, o contexto é preenchido automaticamente pelo serviço, e políticas podem exigi-lo como condição.

# Cifra vinculando o uso a um contexto declarado
aws kms encrypt \
    --key-id alias/financeiro-dados \
    --encryption-context dominio=pagamentos,ambiente=producao \
    --plaintext fileb://payload.bin

# A decifração só funciona com o contexto idêntico ao da cifra
aws kms decrypt \
    --ciphertext-blob fileb://payload.cipher \
    --encryption-context dominio=pagamentos,ambiente=producao

O uso disciplinado do contexto transforma a chave genérica em chave com escopo verificável, e vale para auditoria tanto quanto para segurança. Alarmes sobre Decrypt sem contexto ou com contexto inesperado são detecção de abuso de baixo custo.

HSM e requisitos regulatórios (FIPS)

O HSM, hardware security module, é um dispositivo resistente a violação física que gera e guarda chaves sem jamais expô-las em texto claro, nem para o operador. A validação relevante é a FIPS 140, com níveis de 1 a 3, onde o nível 3 exige proteção contra ataques físicos ativos. O AWS KMS roda sobre HSMs validados, o que já atende à maioria das exigências; o AWS CloudHSM vai além, oferecendo HSMs dedicados de locação única, sob controle exclusivo do cliente, o que é requisito de reguladores específicos, emissores de certificado e arquiteturas de root of trust.

O custo operacional do CloudHSM é o ponto frequentemente subestimado: gestão de cluster, cópia de segurança de chaves, configuração de cliente e ausência de rotação automática são responsabilidades novas e permanentes. Quando o regulador exige HSM dedicado mas o workload usa serviços gerenciados, o caminho intermediário é o custom key store, em que uma chave do KMS tem seu material alojado dentro do CloudHSM, unindo integração nativa e controle exclusivo.

Separação de funções

O princípio é que quem administra chaves não lê dados, e quem lê dados não altera políticas. Em termos práticos: o papel de segurança administra políticas, rotação e destruição, mas não tem permissão de Decrypt; os papéis de aplicação usam Decrypt e GenerateDataKey, mas não podem alterar nada. Essa separação é verificável em auditoria pelo próprio desenho das políticas, e não por promessa de processo. Chaves de domínios sensíveis costumam residir em conta dedicada de segurança, usada por delegação cross-account pelas contas de aplicação, o que adiciona mais uma fronteira administrativa.

A separação entre ambientes é igualmente importante: chaves de produção não podem ser usadas a partir de contas de desenvolvimento, e pipeline de CI não deve ter acesso a chaves que decifrem dados reais. Quando um processo legítimo precisa decifrar em produção, o caminho é uma tarefa com papel temporário e trilha, não uma credencial permanente compartilhada.

Envelope encryption e custo por requisição

O preço do KMS tem duas linhas: valor mensal por chave e valor por requisição de API, com camadas de desconto por volume. Em qualquer workload relevante, a linha de requisição domina a fatura, e o custo cresce exatamente com o throughput de leitura e escrita dos dados protegidos. As alavancas de otimização são o cache de chaves de dados com TTL e limite de uso, a agregação de payloads cifrados por lote em vez de item a item e a escolha consciente de granularidade, com uma chave por domínio de dados e não por microserviço ou por objeto.

O CloudHSM tem lógica inversa: custo fixo por hora, independentemente do uso. Em TPS constante muito alto, o ponto de cruzamento pode tornar o dedicado mais barato que o por requisição, além do argumento regulatório. A análise honesta pede a curva de requisições reais do workload, projetada por doze meses, contra o custo fixo do cluster dedicado com redundância.

Erros comuns

• Conceder kms:* amplo por wildcard em políticas IAM: a permissão genérica apaga a fronteira entre administrar e usar.
• Referenciar key id no código em vez do alias: a rotação manual quebra a aplicação, e o alias é justamente o contrato de desacoplamento.
• Assumir que rotação recifra dados: o material antigo decifra o histórico, e a proteção retroativa vem de chaves de dados de vida curta.
• Permitir uso de chaves de produção a partir de contas de desenvolvimento: o pipeline vira caminho de extração de dados.
• Deletar chave sem inventário de dependências: todo dado cifrado por ela se torna permanentemente ilegível.
• Tratar CloudHSM como KMS drop-in: sem integração nativa e sem rotação automática, o custo operacional aparece no primeiro incidente.

Boas práticas

• Definir uma CMK por domínio de dados, com alias estável e política mínima de uso por papel, como contrato explícito da arquitetura.
• Escrever a key policy com administração restrita ao time de segurança e uso delegado ao IAM, aplicando separação de funções no próprio documento.
• Habilitar rotação automática anual em toda chave simétrica, com alarme para chaves que excedem o prazo sem rotação.
• Configurar trilha de uso no CloudTrail com detecção de Decrypt em massa, padrão típico de exfiltração de dados.
• Usar cache de chaves de dados com TTL e limite de uso para controlar custo e latência em alto throughput.
• Exigir EncryptionContext nas políticas das chaves de domínio, restringindo o uso ao serviço e ao ambiente declarados.
• Adotar HSM dedicado apenas quando regulador ou arquitetura de root of trust exigir, preferindo custom key store para manter integração com serviços gerenciados.