Mapa da aula
Aula 32 publicada. Mapa, exemplo, EX094.
flowchart TD
N0["32.1 Confiabilidade definida"]
N1["32.2 Pontos únicos de falha"]
N2["32.3 Backups"]
N3["32.4 Testes de restauração"]
N4["32.5 Formatos de longo prazo"]
N5["32.6 Envelhecimento das mídias"]
N6["32.7 Métricas de confiabilidade"]
N7["Disponibilidade durante interrupções"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX094"]
Desenho lógico
flowchart LR
N0["32.1 Confiabilidade definida"]
N1["32.2 Pontos únicos de falha"]
N2["32.3 Backups"]
N3["32.4 Testes de restauração"]
N4["32.5 Formatos de longo prazo"]
N5["32.6 Envelhecimento das mídias"]
N6["32.7 Métricas de confiabilidade"]
N7["Disponibilidade durante interrupções"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX094"]
[32.1 Confiabilidade definida]
|
v
[32.2 Pontos únicos de falha]
|
v
[32.3 Backups]
|
v
[32.4 Testes de restauração]
|
v
[32.5 Formatos de longo prazo]
|
v
[32.6 Envelhecimento das mídias]
|
v
[32.7 Métricas de confiabilidade]
|
v
[Disponibilidade durante interrupções]
|
v
[Exemplo resolvido] --> [Exercício EX094]
Objetivos de aprendizagem
Você vai (1) definir confiabilidade para o EvidenceDesk; (2) identificar pontos únicos de falha; (3) projetar backup e restauração; (4) testar a recuperação.
32.1 Confiabilidade definida
Confiabilidade é a probabilidade de um sistema desempenhar sua função ao longo de um período. Para o EvidenceDesk, a função é manter registros completos e corretos disponíveis quando necessários — possivelmente anos depois, em recursos judiciais. A expressão "ao longo de um período" importa aqui, porque um log de custódia que funciona hoje, mas não pode ser lido durante um recurso em 2034, falhou justamente no momento em que era necessário. Priya escreve, portanto, dois horizontes: a disponibilidade diária enquanto um caso está aberto e registros legíveis e verificáveis por pelo menos o período de retenção do laboratório depois que ele é encerrado. Cada escolha de projeto posterior é julgada em relação aos dois horizontes, e não apenas ao primeiro.
32.2 Pontos únicos de falha
O disco do servidor, o próprio servidor e o único administrador que conhece a configuração. Mitigações: discos espelhados, um procedimento de reconstrução documentado e um segundo administrador treinado. Hugo pede a Priya que percorra cada um deles imaginando-o perdido numa segunda-feira de manhã. Um disco morto é o caso mais fácil, já que o espelho continua funcionando. Um servidor morto significa reconstruir a partir do procedimento escrito, e é por isso que esse procedimento é testado em hardware reserva. O administrador é o mais difícil, porque o conhecimento vai embora com a pessoa; o segundo administrador faz sozinho uma reconstrução completa uma vez por ano, para provar que a documentação basta.
32.3 Backups
Backups diários em mídia de gravação única, cópias semanais guardadas fora do local, todos verificados por hash. Os backups incluem as âncoras da cadeia de custódia, para que os dados restaurados possam ser conferidos. A mídia de gravação única impede que um atacante posterior ou um script equivocado altere um backup depois de feito. Calcular o hash de cada conjunto de backup na criação e de novo depois de copiá-lo para fora do local mostra que a cópia corresponde ao original. Incluir as âncoras importa porque uma cadeia restaurada que só é conferida contra si mesma prova pouco; conferi-la contra valores enviados por e-mail e impressos meses antes mostra que o histórico restaurado é o verdadeiro.
32.4 Testes de restauração
A cada trimestre, o procedimento de Priya restaura o backup mais recente numa máquina reserva e verifica a cadeia contra as âncoras. Um backup que nunca foi restaurado é uma suposição, não um controle. O teste registra quanto tempo a restauração levou, quais arquivos não puderam ser lidos e se a cadeia foi verificada. Na primeira execução, Priya descobre que os registros são restaurados corretamente, mas o arquivo de âncoras, mantido numa pasta separada, nunca esteve no conjunto de backup, de modo que a cadeia restaurada não tinha nada externo contra o que ser conferida. A lacuna é corrigida, a lista de backup é atualizada, e o teste do trimestre seguinte confirma a mudança.
32.5 Formatos de longo prazo
Registros em JSON simples e imagens em formatos documentados continuam legíveis à medida que o software muda. Um arquivo de banco de dados proprietário pode precisar de uma versão específica de um produto para ser aberto, e essa versão pode não se instalar no hardware disponível daqui a dez anos. As linhas JSON podem ser lidas com qualquer editor de texto, e os significados dos campos estão escritos num documento de esquema guardado junto com os dados. Para as imagens, Priya mantém o formato bruto como cópia de referência, já que uma imagem bruta não precisa de nenhum software especial para que seus bytes sejam lidos.
32.6 Envelhecimento das mídias
As mídias de armazenamento se degradam; verificações periódicas de integridade e a migração para novas mídias mantêm as evidências legíveis. Os discos rígidos falham mecanicamente, as células flash perdem carga quando ficam sem energia, e os discos ópticos variam muito em vida útil conforme a marca e as condições de armazenamento. O cronograma de Northfield relê todos os anos cada imagem arquivada e compara seu hash com o valor armazenado. Qualquer divergência ou erro de leitura dispara uma cópia a partir do segundo conjunto. As mídias são migradas para hardware novo a cada cinco anos, com os hashes conferidos antes e depois de cada transferência.
32.7 Métricas de confiabilidade
O tempo médio entre falhas e o tempo médio de restauração são acompanhados; o tempo de restauração precisa atender às necessidades do laboratório para pedidos judiciais urgentes. O tempo médio entre falhas mostra com que frequência algo quebra; o tempo médio de restauração mostra por quanto tempo o laboratório fica sem registros quando isso acontece. O segundo importa mais para Northfield, já que um tribunal pode pedir um relatório de custódia em pouco tempo. Priya fixa uma meta de quatro horas úteis para restaurar o acesso de leitura e compara cada incidente real ou ensaiado com ela, anotando a causa sempre que a meta não é cumprida.
Disponibilidade durante interrupções
Se o servidor falhar numa semana de audiências, os peritos precisam dos registros de custódia rapidamente. O procedimento de Priya mantém uma exportação noturna assinada num notebook offline guardado no cofre, para que os registros possam ser apresentados enquanto o servidor é reconstruído. A exportação é conferida contra as âncoras todo mês, e a equipe ensaia sua recuperação duas vezes por ano, para que o procedimento funcione sob pressão.
Exemplo resolvido
O primeiro teste de restauração falha: o backup omitiu o arquivo de âncoras guardado numa pasta separada. Priya o acrescenta ao conjunto de backup, repete o teste e documenta as duas execuções.
Caso sintético. O teste é inventado.
Erros e limites
Os números de confiabilidade obtidos em testes curtos são aproximados; colete dados operacionais ao longo de anos.
Exercícios
- EX094 — Lista de pontos únicos de falha. Cite três pontos únicos de falha e suas mitigações.
Mostrar critérios de avaliação
Rubrica: 3 = disco/servidor/administrador, com espelhos, documento de reconstrução, segundo administrador; 2 = dois; 1 = um; 0 = nada. - EX095 — Falha na restauração. Por que o primeiro teste de restauração falhou?
Mostrar critérios de avaliação
Rubrica: 3 = o arquivo de âncoras foi omitido do backup; 2 = parcial; 1 = defeito da mídia; 0 = nada. - EX096 — Backup não testado. Por que um backup não testado é "uma suposição"?
Mostrar critérios de avaliação
Rubrica: 3 = não há evidência de que ele restaure corretamente; 2 = parcial; 1 = está tudo bem; 0 = nada.
Síntese
Sistemas de evidências confiáveis eliminam os pontos únicos de falha e provam a recuperação restaurando.
Continue estudando — capítulo 32 de 50
← Capítulo 31 (rascunho) · Índice de capítulos do curso · Capítulo 33 (rascunho) →