APRENDER. PRATICAR. EVOLUIR.Definir o contrato de recuperação
O laboratório contém pagamentos fictícios, cada um com um valor positivo e dois lançamentos. O contrato exige exatamente um débito e um crédito do mesmo valor. Esta regra deliberadamente simples permite separar integridade estrutural, integridade referencial e coerência de negócio. Antes de executar, escreve que observação aceitaria para cada condição. A existência de um ficheiro, uma tabela legível e um processo que responde são evidências diferentes. A lista p1 a p4 usada no final foi fornecida pelo exercício; não é uma confirmação obtida de um sistema de pagamentos. Numa operação real, essa referência precisaria de origem, âmbito temporal e autoridade próprios. O exercício ensina a formular essa necessidade, sem fingir tê-la resolvido externamente.
Comparar snapshots antes e depois do commit
O script abre ligações distintas à base SQLite. O escritor inicia uma transação e cria apenas parte do terceiro pagamento. A ligação de backup observa os dois pagamentos já confirmados; não deve incluir uma metade do terceiro. Depois de confirmar os dois lançamentos, outro backup contém o terceiro pagamento completo. Compara os identificadores e as falhas de reconciliação nos resultados. A cópia anterior mantém o seu conteúdo, embora a origem tenha avançado. Este ensaio usa WAL e a API de backup no ambiente registado. Não demonstra que copiar apenas o ficheiro principal de uma base ativa seja seguro, nem mede comportamento sob escritas contínuas, falhas de energia ou falta de espaço.
Distinguir verificações que podem passar em conjunto
Uma linha de lançamento adicional pode ser SQL válido e continuar a referenciar um pagamento existente. Por isso, as verificações estrutural e referencial passam, enquanto a regra de negócio falha. O relatório identifica p3 como pagamento inconsistente. Num segundo ficheiro, o exercício desativa explicitamente a imposição de chaves estrangeiras para introduzir uma referência inexistente; integrity_check continua a passar, mas foreign_key_check encontra o problema. Estas alterações são injeções controladas em dados fictícios, não instruções para reparar produção. A decisão de recuperação deve usar os controlos adequados ao resultado pretendido. Acrescentar mais repetições do mesmo controlo estrutural não substitui a verificação da propriedade que ele não avalia.
Interpretar o digest e a sua referência
O script regista um digest de uma cópia concluída e compara outra cópia com essa referência. Depois de alterar o valor de um pagamento, a correspondência deixa de existir. Contudo, calcular uma referência nova sobre o ficheiro alterado volta a produzir igualdade com esses bytes. A reconciliação continua a falhar, porque recalcular um hash não repara a aplicação. Para usar este resultado numa decisão, identifica quem capturou a referência, quando e com que proteção. O laboratório conserva a referência apenas no mesmo processo e contexto de confiança; não demonstra autenticação independente, armazenamento imutável ou admissibilidade de prova. Estas limitações não tornam a comparação inútil: delimitam a afirmação que se pode fazer a partir dela.
Observar o ponto em que o recuo muda de natureza
Executa a migração que renomeia a coluna enquanto a transação ainda está aberta. A consulta antiga falha, mas o rollback repõe o esquema anterior. Depois, observa uma migração confirmada: voltar ao código que lê o nome antigo não reverte a base. O script também acrescenta uma coluna sem remover as anteriores e verifica uma consulta explicitamente definida. Essa compatibilidade é local e limitada. Não concluas que qualquer cliente funciona, sobretudo quando a forma de leitura ou o significado dos dados difere. Ao preparar uma mudança, decide que versões coexistem, como se valida a transição e que estado persistido ficará depois de cada opção de recuo.
Reconciliar trabalho aceite e comunicar o limite
A última parte repõe a cópia que termina em p3 e compara-a com o conjunto exigido p1 a p4. As verificações de estrutura e referências passam, mas falta trabalho segundo o contrato do exercício. O script acrescenta p4 com os seus dois lançamentos e verifica novamente o conjunto e os valores. A tentativa seguinte de inserir a mesma chave é recusada e revertida. Isto demonstra comportamento local da chave e da transação; não prova idempotência de efeitos externos. As duas execuções conservaram 33 verificações e removeram os ficheiros temporários. Usa essa evidência para explicar o ensaio realizado, sem a converter numa garantia de RTO, integridade de um sistema real ou prontidão para reabrir uma aplicação bancária.
cd content/labs/cissp-operations-contracts
python3 recovery_release_lab.py --output learner-run.jsonUm backup abre sem erros e todas as referências existem, mas um pagamento tem dois débitos. A recuperação exige reconciliação da regra de negócio antes da aceitação.
Armadilhas comuns
Confundir um ficheiro legível com estado de negócio correto; recalcular o digest como correção; tratar rollback de código como reversão de dados; generalizar um ensaio local para produção.
Tópicos relacionados: Operações e recuperação · Software e supply chain · Avaliação e evidência
Aceitar recuperação requer critérios explícitos, controlos que realmente os avaliem e uma descrição honesta dos limites do ensaio.
Referência: Guide for Cybersecurity Event Recovery · CISSP outline effective April 15, 2024; current AI guidance consulted 2026-09-29