APRENDER. PRATICAR. EVOLUIR.1. Separar as garantias que o serviço precisa
Num serviço fictício de posições de fundos, cifrar o ficheiro evita que alguém sem a chave leia diretamente o conteúdo. Isso não responde, por si só, a quem pode pedir a leitura, se o ficheiro pertence ao fundo indicado ou se uma versão antiga está a ser reenviada. Desenha essas perguntas antes de escolher um algoritmo. Identifica dados, consumidores, chaves, administradores, backups e dependências de recuperação. Uma mudança de criptografia pode afetar batch, integração e retenção sem alterar a interface visível. Define quem aprova exceções e que evidência permite aceitar a mudança. O laboratório usa dados sintéticos e chaves efémeras para demonstrar primitivas; não implementa identidade de utilizadores, gestão empresarial de chaves ou aprovação de acesso. Essas fronteiras devem continuar visíveis no handover para APS.
2. Vincular contexto sem o tratar como segredo
O exercício usa AES-256-GCM e associa ao ciphertext um contexto composto por fundo e objeto. Esse contexto entra como dados adicionais autenticados, AAD: altera a verificação de integridade, mas não é cifrado por esse mecanismo. A leitura com outro fundo ou objeto falha. Na aplicação real, o contexto esperado deve resultar de informação de confiança e da decisão de autorização, não apenas de um campo fornecido pelo cliente. Um atacante que apresenta o contexto correto não ganha por isso permissão de leitura. Em AWS KMS, o encryption context é igualmente não secreto e pode aparecer em logs; não deve conter credenciais ou dados pessoais desnecessários. O exemplo local ilustra o vínculo criptográfico, mas não executa políticas IAM, grants ou chamadas ao KMS.
3. Não consumir plaintext antes da autenticação
Algumas APIs devolvem bytes durante a desencriptação antes de confirmar a tag de autenticação. O laboratório mostra esse comportamento com update() e uma tag incorreta: podem surgir bytes plausíveis antes de final() falhar. A função segura do exercício só devolve o resultado depois da verificação final. Não escrevas esses bytes numa base de dados, não os envies ao consumidor e não os uses para escolher uma ação antes de autenticar. Se a verificação falhar, trata o conteúdo como não confiável e preserva evidência operacional adequada, sem registar segredos. Uma falha não identifica sozinha a causa: pode haver corrupção, contexto errado, chave errada ou adulteração. O diagnóstico deve confirmar versão, identificadores e percurso dos dados, mantendo o controlo de integridade ativo.
4. Planear rotação, migração e dependências antigas
No laboratório, as novas escritas passam de data-v1 para data-v2. O ciphertext anterior não muda e continua a precisar da chave antiga. Só uma operação explícita de leitura e nova cifragem produz um registo protegido pela nova chave de dados. Este exercício de substituição local não reproduz a rotação interna de material de uma chave AWS KMS. Na rotação interna de uma chave KMS simétrica com material gerado pelo serviço (AWS_KMS), a identidade lógica mantém-se e o serviço conserva material necessário a leituras anteriores; a rotação não volta a cifrar os dados nem resolve uma chave de dados já comprometida. Para uma migração real, inventaria objetos ativos, versões, cópias e caminhos de recuperação. Mede cobertura por população e verifica amostras representativas de leitura e restauro antes de retirar dependências antigas. Uma escrita nova bem-sucedida não demonstra recuperação do histórico.
5. Ensaiar falhas e evitar garantias de apagamento indevidas
O exercício altera separadamente ciphertext, tag, nonce e contexto para confirmar rejeição. Usa nonces aleatórios de 96 bits e tags de 128 bits numa amostra pequena; isso não prova gestão de unicidade e limites de utilização à escala de produção. A reutilização de nonce com a mesma chave exige tratamento sério, não apenas repetição do teste positivo. Outra experiência remove a chave antiga do mapa, mas conserva uma cópia independente: a cópia ainda permite ler o registo. Apagar uma entrada não prova apagamento seguro em memória, backups ou outros sistemas. A eliminação de uma chave KMS tem regras próprias e pode tornar dados irrecuperáveis; não uses o comportamento de um mapa JavaScript como prova dessas regras. Regista claramente quais operações foram executadas e quais dependências continuam por ensaiar.
O registo antigo mantém o ciphertext após mudar a chave de escrita; uma cópia da chave antiga ainda o lê mesmo depois de retirar a entrada do mapa.
Armadilhas comuns
Contexto como autorização; plaintext de update() como autenticado; rotação como nova cifragem; apagar uma referência como apagar todas as cópias.
Tópicos relacionados: Assinaturas, origem e política de release
Confirma integridade antes de usar os dados e prova separadamente autorização, migração e recuperabilidade.
Referência: Node.js cryptographic API · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17