Gestão de Chaves de Encriptação: Melhores Práticas 2026
Domine a gestão de chaves de encriptação com práticas comprovadas para geração, armazenamento, rotação e gestão do ciclo de vida das chaves em 2026.
A gestão de chaves em 2026 implica gerar chaves com um CSPRNG (não /dev/urandom em VMs com pouca entropia; use getrandom() ou BCryptGenRandom), armazená-las em hardware (AWS KMS, YubiHSM 2, Thales Luna, Secure Enclave), rodá-las num calendário que corresponda à exposição à ameaça (90 dias para chaves de encriptação ativas, anualmente para KEKs) e destruí-las com apagamento criptográfico ou destruição física. A NIST SP 800-57 Parte 1 Rev 5 cobre o ciclo de vida; a FIPS 140-3 certifica os módulos; o PCI DSS 4.0 Requisito 3.6 audita o processo. Acerte nisto e a criptografia em si (AES-256-GCM, X25519) quase nunca importa.
Gerar chaves em que pode confiar
A geração de chaves é o ponto de falha silencioso da criptografia. A CVE OpenSSL de 2006-2008 do Debian (patch específico do Debian para o RNG) tornou todas as chaves SSH geradas em sistemas afetados previsíveis. Mais recentemente, a Fortinet distribuiu routers em 2021 com chaves derivadas de fontes de entropia baixa no momento do arranque. A geração segura usa o CSPRNG do SO — getrandom() no Linux 3.17+, BCryptGenRandom no Windows, SecRandomCopyBytes no macOS/iOS — ou um RNG de hardware num HSM. A crypto.getRandomValues() da Web Crypto API obtém da fonte do SO. Nunca implemente o seu próprio RNG, nunca inicialize com time() ou PID, e verifique no arranque da VM que o pool foi inicializado (verifique /proc/sys/kernel/random/entropy_avail > 256).
Estrutura hierárquica de chaves: KEKs, DEKs e chaves de sessão
Os sistemas reais usam chaves em camadas. Uma Data Encryption Key (DEK) encripta dados reais com AES-256-GCM. Uma Key Encryption Key (KEK) encripta as DEKs, guardada num HSM. Uma KEK raiz (por vezes uma chave mestre) encripta as KEKs, detida em hardware resistente a adulteração. Rodar a DEK re-encripta dados; rodar a KEK re-envolve as DEKs (rápido); rodar a raiz é uma operação major. Este padrão de envelope permite rodar frequentemente nas camadas que conseguem, sem desencriptar petabytes. O AWS KMS, Google Cloud KMS e HashiCorp Vault implementam todos isto. Para serviços de transferência de ficheiros, a chave AES por transferência é uma DEK; a KEK derivada de palavra-passe (via PBKDF2 ou Argon2id) envolve-a.
Armazenamento: HSMs, KMS e o que é realmente diferente
Um Hardware Security Module é uma caixa resistente a adulteração que gera, guarda e usa chaves sem nunca as exportar. Dispositivos FIPS 140-3 Nível 3 (Thales Luna 7, AWS CloudHSM, YubiHSM 2) detetam adulteração física e zeroizam. Um Key Management Service (AWS KMS, Google Cloud KMS, Azure Key Vault) é software a correr em HSMs, acessível via API. Para a maioria das aplicações, o KMS é suficiente — paga 1 $/mês por chave, chama Encrypt/Decrypt via HTTPS, e a AWS trata da operação HSM. O HSM direto é necessário quando os reguladores o exigem (PCI DSS 4.0 Requisito 3.6.1.1 para emissão de cartões) ou quando não pode confiar na jurisdição legal do fornecedor cloud.
Calendários de rotação que correspondem ao risco
A NIST SP 800-57 define períodos criptográficos — o tempo que uma chave permanece ativa. Para chaves simétricas de dados a encriptar ativamente novos dados, 1-2 anos no máximo. Para chaves que apenas desencriptam dados existentes, 3-5 anos. Para KEKs raiz, 5-10 anos. O PCI DSS Requisito 3.7.4 impõe a definição do período criptográfico. Na prática, automatize a rotação: a rotação automática do AWS KMS é anual; o Google KMS é configurável. Para serviços de transferência de ficheiros em que cada upload recebe uma chave aleatória nova, a rotação não se aplica às chaves de dados (são de uso único) mas aplica-se a certificados TLS (90 dias via Let's Encrypt), chaves de assinatura para registos de auditoria (anualmente) e à chave mestre que envolve segredos por utilizador.
Destruição e apagamento criptográfico
Quando o período criptográfico de uma chave termina ou os dados têm de ser eliminados ao abrigo do Artigo 17.º do RGPD, destrua a chave. Destruição física (triturador de smartcard) para tokens de cópia de segurança offline. Apagamento criptográfico para chaves guardadas na cloud: encripte a chave com uma chave de envoltura, depois destrua a chave de envoltura — todos os dados encriptados sob a primeira chave tornam-se texto cifrado que ninguém consegue desencriptar. É assim que os fornecedores cloud cumprem pedidos de eliminação à escala de terabytes sem realmente limpar cada setor de disco. Documente a destruição num registo de auditoria com timestamp, ID da chave (não o material da chave) e o método de destruição. A NIST SP 800-88 Rev 1 cobre a sanitização.
Controlo de acesso e separação de funções
Nenhuma pessoa deve poder extrair uma chave de produção. Implemente quórum m-de-n para funções de administrador HSM: quaisquer 2 de 5 responsáveis para exportar uma chave raiz, quaisquer 1 de 3 para rodar uma KEK, 0 necessários para operações de rotina de DEK. As concessões do AWS KMS permitem delegar capacidades específicas (apenas encriptar, apenas desencriptar) via políticas IAM. O Shamir Secret Sharing do HashiCorp Vault divide a chave de desbloqueio entre depositários. Registe cada uso de chave com a identidade do chamador, operação e recurso. O PCI DSS 3.6.2 e o SOC 2 CC6.1 auditam ambos isto.
Encriptação de envelope e BYOK
Bring Your Own Key (BYOK) permite que os clientes carreguem a sua própria KEK raiz para um KMS cloud. O fornecedor cloud envolve as chaves de dados dos inquilinos sob a KEK do cliente, por isso a revogação do cliente torna os dados irrecuperáveis sem envolvimento do fornecedor. AWS KMS Import Key, Google Cloud EKM (External Key Manager), Azure Key Vault BYOK — todos resolvem isto. Para serviços de transferência de ficheiros que tratam clientes regulados (saúde, finanças), BYOK satisfaz os requisitos de "o cliente controla as chaves" mesmo em infraestrutura partilhada. O HSM do cliente no seu centro de dados gera a chave; o fornecedor nunca vê material de chave em texto claro.
Cópia de segurança e recuperação de material de chave
Chaves perdidas significam dados perdidos. Faça cópia de segurança das chaves raiz via divisões Shamir Secret Sharing detidas por depositários geograficamente separados. O AWS KMS oferece exportação de material de chave apenas para CMKs criadas com BYOK. O YubiHSM 2 suporta cópia de segurança de chave de envoltura. Documente o procedimento de recuperação, teste-o anualmente (execute realmente o procedimento, não se limite a lê-lo) e mantenha pelo menos dois depositários vivos em qualquer momento — um fator de autocarro de um é inaceitável. Para chaves menos críticas, cópias de segurança offline encriptadas em meios com air-gap (cassete LTO, USB encriptado num cofre) em 2 ou mais locais. O procedimento de recuperação pertence ao seu runbook de recuperação de desastre.
O caso especial da encriptação no lado do cliente
Para serviços como o HexaTransfer em que os utilizadores encriptam no browser, a gestão de chaves tradicional não se aplica — não existe chave do lado do servidor para rodar porque o servidor nunca vê chaves. O browser deriva uma chave da palavra-passe do utilizador, usa-a uma vez e descarta-a. A gestão de chaves desloca-se para a educação do utilizador: escolha palavras-passe fortes, não as reutilize, use um gestor de palavras-passe. A responsabilidade do serviço é usar um KDF forte (Argon2id com m=64MB, t=3, p=1, ou PBKDF2 com 600k+ iterações), gerar salts aleatórios corretamente e zeroizar o material de chave na memória após uso (via handles opacos crypto.subtle ou limpezas explícitas de memória WebAssembly).
Monitorização e resposta a incidentes
O comprometimento de chaves é o pior incidente possível. Monitorize operações KMS para anomalias: uma chave API que normalmente faz 100 chamadas Decrypt/hora de repente a fazer 10 000 é exfiltração. Alerte sobre erros KMS (falha de autenticação, chave não encontrada, quota excedida). Ligue os alertas a um runbook que inclua rotação de chaves, invalidação de credenciais e captura forense. Tenha um plano de recuperação de comprometimento de chaves: com que rapidez consegue rodar a raiz? Como re-encripta TB de dados? Teste o plano anualmente. Um KMS bem gerido com comprometimento não detetado é pior do que um visivelmente quebrado.
Experimente em hexatransfer.com — gratuito, sem conta, até 10 GB.
Envie arquivos grandes com segurança e criptografia de ponta a ponta
Transfira arquivos de até 10 GB gratuitamente com criptografia de ponta a ponta. Sem necessidade de conta. Seus arquivos são criptografados no navegador antes do envio — ninguém mais pode lê-los.
Enviar um arquivo