APRENDER. PRATICAR. EVOLUIR.Duas chaves, duas responsabilidades
Num arquivo fictício de liquidação, cada lote é cifrado com uma chave de dados, a DEK. Outra chave, a KEK, protege essa DEK. O pacote guardado precisa do ciphertext, do IV, da tag, da DEK cifrada e da identificação necessária para encontrar a KEK correta. Guardar a DEK cifrada junto do lote pode ser adequado; guardar ali a DEK em claro elimina a separação pretendida. O desenho tem de explicar onde existe texto em claro durante o processamento, quem pode pedir a decifragem e como a aplicação autentica a resposta. Uma política que protege apenas o ficheiro, esquecendo permissões de uso da chave, deixa incompleto o controlo do caminho de leitura.
Contexto autenticado e resultado ainda não aceite
O exercício usa AES-256-GCM com IV aleatório de 12 bytes e tag de 16 bytes. Cada cifragem gera um IV novo; a unicidade por chave continua a ser uma obrigação de um desenho real, sobretudo com volume elevado. AAD associa tenant, objeto e versão ao ciphertext sem esconder esses campos. Se a aplicação pedir a abertura com contexto diferente, a autenticação falha. Não uses AAD para guardar segredos. Em Node, update() pode produzir bytes antes da validação final: o exemplo só devolve o resultado quando final() termina com sucesso. Uma falha de autenticação deve impedir a utilização desses bytes no processamento do lote, mesmo que pareçam legíveis.
Distingue rotação, rewrap e nova cifragem
Executa node run.mjs com o script completo da aula seguinte. O primeiro grupo cria um lote fictício e protege a mesma DEK sob uma KEK nova. O hash do ciphertext do lote mantém-se: foi alterado o invólucro da chave. A verificação retained data key still decrypts after rewrap mostra que alguém com a DEK original ainda consegue decifrar esse ciphertext. Para responder a uma exposição da DEK, avalia dados afetados, acesso, preservação de evidência e a necessidade de gerar uma DEK nova e voltar a cifrar. Não declares sanado um incidente apenas porque o painel de rotação está verde. O exercício local não reproduz a rotação interna de material de uma chave KMS.
O backup também tem dependências de chaves
O script conserva um invólucro antigo e outro novo. Retira a referência old do registo de chaves: o backup antigo falha, o novo funciona. Repor a referência recupera o primeiro. Isto demonstra indisponibilidade lógica, não apagamento físico; a variável oldKek continua em memória. No trabalho APS, inventaria também backups imutáveis, cópias exportadas e consumidores antigos antes de retirar uma chave. Define quem aprova, como ensaiar o restauro e quais os sinais para interromper a mudança. Um restauro com a conta pessoal do engenheiro não demonstra autonomia da identidade de operação. A evidência de recuperação deve usar a identidade prevista, o objeto correto e os requisitos de integridade do processo.
Interpreta as falhas antes de fechar a mudança
As duas execuções registadas passaram 36 verificações cada, das quais 12 pertencem ao grupo envelope. Alterações ao ciphertext, tag, contexto e chave provocam rejeição. Isso demonstra os casos ensaiados neste runtime, sem provar disponibilidade de KMS, proteção HSM, conformidade FIPS ou aceitação de uma aplicação. Para o handover, acrescenta uma matriz com a versão do backup, a chave de que depende, a identidade autorizada, o último restauro e a decisão de retenção. Se uma cópia ainda depende da chave antiga, mantém a retirada pendente ou migra-a por processo autorizado. Relaciona esta aula com retenção, incidentes e recuperação: o controlo só é útil quando os dados continuam recuperáveis por quem deve aceder-lhes.
Dados sintéticos de um lote de liquidação; nenhuma informação interna do BNP Paribas.
Armadilhas comuns
Aceitar um indicador técnico isolado como prova do controlo completo; omitir testes negativos e dependências.
Tópicos relacionados: Recuperação e incidentes cloud · Proteção de dados e IAM
Executa cifragem autenticada e distingue rewrap, exposição de DEK e dependências de recuperação.
Referência: AWS KMS cryptography essentials · CCSP examination outline effective 2026-08-01; January2026 V2 PDF