Capítulo 36 — Perícia digital e análise de malware: desempenho e escala
Mapa da aula
Aula 36 publicada. Mapa, exemplo, EX106.
flowchart TD
N0["36.1 O problema da escala"]
N1["36.2 Aritmética da capacidade"]
N2["Laboratório — estimativa de capacidade"]
N3["36.3 Lendo o resultado"]
N4["36.4 Gargalos"]
N5["36.5 Hash durante a geração da imagem"]
N6["36.6 Escalando o EvidenceDesk"]
N7["36.7 Priorização"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX106"]
Desenho lógico
flowchart LR
N0["36.1 O problema da escala"]
N1["36.2 Aritmética da capacidade"]
N2["Laboratório — estimativa de capacidade"]
N3["36.3 Lendo o resultado"]
N4["36.4 Gargalos"]
N5["36.5 Hash durante a geração da imagem"]
N6["36.6 Escalando o EvidenceDesk"]
N7["36.7 Priorização"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX106"]
[36.1 O problema da escala]
|
v
[36.2 Aritmética da capacidade]
|
v
[Laboratório — estimativa de capacidade]
|
v
[36.3 Lendo o resultado]
|
v
[36.4 Gargalos]
|
v
[36.5 Hash durante a geração da imagem]
|
v
[36.6 Escalando o EvidenceDesk]
|
v
[36.7 Priorização]
|
v
[Exemplo resolvido] --> [Exercício EX106]
Objetivos de aprendizagem
Você vai (1) estimar a capacidade de geração de imagens e de verificação; (2) encontrar gargalos; (3) planejar a escala; (4) manter a integridade enquanto escala.
36.1 O problema da escala
Garfinkel (2010) destacou o crescimento dos volumes de dados como um desafio central. Para Northfield, um acúmulo de oito discos totalizando 20,5 TB precisa ter as imagens geradas e verificadas com hardware limitado. O tamanho dos discos cresceu muito mais depressa que as velocidades de leitura, então cada nova geração de discos leva mais tempo para ter a imagem gerada que a anterior. Um acúmulo não é apenas um atraso num caso; os itens em espera ocupam espaço de armazenamento, e suspeitos ou vítimas esperam por respostas. O primeiro passo de Priya é transformar o acúmulo em números: os tamanhos dos discos, as taxas de leitura e o número de estações de geração de imagens disponíveis.
36.2 Aritmética da capacidade
A 150 MB/s sustentados, um terabyte (10^12 bytes) leva cerca de 1,85 hora para ser lido. A verificação precisa de uma segunda leitura completa. O número vem de dividir 10^12 bytes por 150 × 10^6 bytes por segundo, o que dá cerca de 6.667 segundos. Priya usa terabytes decimais porque é assim que os fabricantes de discos rotulam a capacidade. A velocidade sustentada é menor que o pico anunciado de um disco, então ela a mede num disco apreendido real de cada tipo. O cálculo ignora o tempo de preparação, que ela soma à parte, cerca de quinze minutos por disco. Dobrar a leitura para a verificação dobra o total.
Laboratório — estimativa de capacidade
"""Imaging capacity estimate for a synthetic lab backlog."""
drives_tb = [1, 2, 2, 4, 0.5, 1, 8, 2]
rate_mb_s = 150
hours = [tb * 1e6 / rate_mb_s / 3600 for tb in drives_tb]
print(f"drives={len(drives_tb)} total_tb={sum(drives_tb)} hours={sum(hours):.1f}")
print(f"with verify pass: {2*sum(hours):.1f} h; split over 2 imagers: {sum(hours):.1f} h each")
Execute com python3 lab_capacity.py. Saída verificada:
drives=8 total_tb=20.5 hours=38.0
with verify pass: 75.9 h; split over 2 imagers: 38.0 h each
36.3 Lendo o resultado
Ler 20,5 TB uma vez leva 38,0 horas a 150 MB/s; com uma passada de verificação, são 75,9 horas num único gerador de imagens. Divididas entre dois geradores, cada um gasta cerca de 38,0 horas. O disco de 8 TB domina sozinho: cerca de 14,8 horas por leitura. Dividir o acúmulo por igual é mais difícil do que a aritmética sugere, porque o disco de 8 TB não pode ser dividido entre estações. Priya o atribui a um gerador de imagens e preenche o outro com os discos menores, para que os dois terminem mais ou menos ao mesmo tempo. Os números também mostram que um terceiro gerador de imagens só ajudaria se as gravações no armazenamento acompanhassem o ritmo, o que a medição seguinte confere.
36.4 Gargalos
O componente mais lento define a vazão: o disco de origem, a interface, o bloqueador de gravação ou o armazenamento de destino. Meça cada um; melhorar o componente errado desperdiça dinheiro. Priya cronometra uma cópia de uma origem rápida para um armazenamento nulo, e depois de um arquivo de teste para o destino, isolando as velocidades de leitura e de gravação. Em Northfield, o compartilhamento de rede usado como destino grava a apenas 110 MB/s, abaixo da taxa de leitura dos discos. Comprar bloqueadores de gravação mais rápidos não teria mudado nada. Passar o destino para um armazenamento conectado localmente eleva a vazão até o limite da origem.
36.5 Hash durante a geração da imagem
Calcular o digest durante a geração da imagem evita uma leitura extra para o hash da aquisição. A verificação da imagem armazenada ainda precisa de uma leitura separada, que é o que prova que a cópia armazenada está correta. Calcular o hash na mesma passada custa pouco tempo extra, porque os processadores modernos calculam o SHA-256 mais depressa do que a maioria dos discos entrega os dados. O hash da aquisição descreve o que foi lido da origem. A leitura de verificação descreve o que foi gravado no armazenamento. Se os dois coincidem, a cópia é fiel; pular a segunda leitura não deixaria nenhuma prova de que a própria gravação deu certo.
36.6 Escalando o EvidenceDesk
Os registros crescem devagar; a carga pesada é o armazenamento e o cálculo dos hashes. O projeto de Priya calcula o hash na estação de geração de imagens e deixa o EvidenceDesk verificar de forma assíncrona, enfileirando tarefas e relatando sua conclusão. Mesmo um laboratório grande acrescenta apenas milhares de registros por ano, o que um único servidor comporta com facilidade. Calcular o hash de uma imagem de vários terabytes, porém, pode levar horas, e bloquear a interface enquanto isso acontece travaria a entrada. A fila permite que a equipe continue trabalhando enquanto a verificação roda, e o início, o fim e o resultado de cada tarefa são gravados no log de custódia, de modo que o registro mostra quando a imagem foi confirmada.
36.7 Priorização
Os casos urgentes passam à frente na fila; a ordem da fila e os motivos são registrados. Um caso com um suspeito preso diante de um prazo para a acusação formal é urgente, enquanto uma revisão de uma fraude antiga geralmente não é. Os motivos precisam ser específicos, como "prazo da custódia às 14:00 de sexta-feira", para que os revisores posteriores possam ver que a fila não foi reordenada por conveniência. Hugo revisa o log mensalmente e pergunta sobre qualquer caso que tenha esperado tempo demais, para que o trabalho de menor prioridade não fique parado indefinidamente. Só o supervisor de plantão pode subir um item na fila, e cada movimentação fica visível para todos os peritos na tela da fila.
Energia e calor
Manter vários geradores de imagens funcionando sem parar aumenta o calor e a carga elétrica num laboratório pequeno. Priya confere a capacidade dos circuitos e a refrigeração antes de recomendar mais hardware.
Exemplo resolvido
Hugo pergunta se um terceiro gerador de imagens zeraria o acúmulo numa semana. Priya calcula: 75,9 horas ÷ 3 ≈ 25,3 horas para cada um, bem dentro de uma semana se o armazenamento de destino acompanhar — o que ela confere em seguida, descobrindo que ele suporta cerca de 400 MB/s, o suficiente para dois geradores de imagens em velocidade máxima, mas não para três.
Caso sintético. O acúmulo é gerado pelo script do laboratório.
Erros e limites
Discos reais com setores defeituosos rodam mais devagar; as estimativas supõem leituras constantes.
Exercícios
- EX106 — Horas do laboratório. Relate as horas de leitura única e com verificação para o acúmulo. Rubrica: 3 = 38,0 h e 75,9 h; 2 = um; 1 = errado; 0 = nada.
- EX107 — Terceiro gerador de imagens. Por que um terceiro gerador de imagens poderia não ajudar por completo? Rubrica: 3 = o armazenamento de destino, a ~400 MB/s, limita a dois em velocidade máxima; 2 = parcial; 1 = sempre ajuda; 0 = nada.
- EX108 — Hash durante a geração da imagem. O que o cálculo do hash durante a geração da imagem economiza, e o que não economiza? Rubrica: 3 = economiza a leitura extra para o hash da aquisição; ainda é preciso a leitura de verificação da cópia armazenada; 2 = parcial; 1 = economiza tudo; 0 = nada.
Síntese
Faça a aritmética, meça cada componente e nunca abra mão da leitura de verificação.
Continue estudando — capítulo 36 de 50
← Capítulo 35 (rascunho) · Índice de capítulos do curso · Capítulo 37 (rascunho) →