Capítulo 19 — Identidade e criptografia
Mapa da aula
Aula 19 publicada. Mapa, exemplo, EX055.
flowchart TD
N0["19.1 Configuração de autenticação"]
N1["19.2 Hashing de evidências"]
N2["19.3 Segredos nas ferramentas"]
N3["19.2b O que um hash não prova"]
N4["19.3b Escolha de algoritmos"]
N5["19.1b Inventário de certificados"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX055"]
Desenho lógico
flowchart LR
N0["19.1 Configuração de autenticação"]
N1["19.2 Hashing de evidências"]
N2["19.3 Segredos nas ferramentas"]
N3["19.2b O que um hash não prova"]
N4["19.3b Escolha de algoritmos"]
N5["19.1b Inventário de certificados"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX055"]
[19.1 Configuração de autenticação]
|
v
[19.2 Hashing de evidências]
|
v
[19.3 Segredos nas ferramentas]
|
v
[19.2b O que um hash não prova]
|
v
[19.3b Escolha de algoritmos]
|
v
[19.1b Inventário de certificados]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX055]
Objetivos de aprendizagem
Você vai (1) avaliar a configuração de autenticação sem atacar a criptografia; (2) usar hashing para a integridade das evidências; (3) tratar segredos com segurança nas ferramentas.
19.1 Configuração de autenticação
Pergunte: qual IdP, quais fatores, quais papéis, quais tempos de vida de token? Leia a configuração e os logs mediante autorização. Quebrar TLS ou quebrar hashes de senha está fora dos laboratórios deste livro e, em geral, fora do escopo dos estudantes. A configuração e os logs lidos com um papel concedido respondem sobre tempo de vida, fatores e mapas de papéis sem transformar o laboratório em quebra de criptografia. Achados sobre tempo de vida de tokens são operacionais e corrigíveis. Sam registra o produto e a versão do IdP ao lado de cada achado de autenticação, para que a remediação mire o console certo. Pedidos de quebra de hashes de senha são recusados com uma referência a esse limite.
19.2 Hashing de evidências
Calcule o hash dos arquivos de evidência (SHA-256) e guarde os resumos no ticket. Calcule de novo mais tarde para detectar adulteração. O laboratório mostra uma divergência quando um arquivo mudou.
"""Verify integrity of a synthetic evidence package."""
import hashlib, json
files = {
"roe.pdf": b"SYNTHETIC-ROE-v1",
"scope.csv": b"host,port\n10.20.1.10,443\n",
"findings.json": b'[{"id":"SYN-001"}]',
}
expected = {n: hashlib.sha256(b).hexdigest()[:16] for n,b in files.items()}
# Simulate tampering of findings.json
current = dict(expected)
current["findings.json"] = hashlib.sha256(b'[{"id":"SYN-001"},{"id":"TAMPERED"}]').hexdigest()[:16]
print(json.dumps(expected, indent=1))
for n in sorted(expected):
status = "OK" if expected[n] == current[n] else "MISMATCH"
print(f"{n:16} {status}")
Saída esperada:
{
"roe.pdf": "18d74983d403e7db",
"scope.csv": "01cc4815eddf3de6",
"findings.json": "7f5f178ab43ef00f"
}
findings.json MISMATCH
roe.pdf OK
scope.csv OK
Resumos no ticket tornam visível uma adulteração posterior, mesmo que o repositório de arquivos seja alterado. Recalcular o hash na hora da revisão é uma verificação de uma linha. O caso de divergência do laboratório treina o reflexo de investigar quando os hashes discordam. Sam se recusa a encerrar um achado cujo resumo atual seja diferente do que está no ticket sem uma nota AUTH explicando a mudança.
19.3 Segredos nas ferramentas
As credenciais de avaliação ficam num cofre; as ferramentas buscam tokens de vida curta. Nada de segredos no git, em capturas de tela ou no chat. Troque-os ao fim do engajamento. Tokens de vida curta limitam por quanto tempo uma string vazada funciona. O git e o chat são permanentes o bastante para que qualquer segredo colado ali seja tratado como queimado. A troca no encerramento está na mesma lista de verificação que a desativação da conta. A CI de Sam procura strings com formato de token e faz o build falhar quando elas aparecem.
Caso sintético — Riverstone Transit. O laboratório de hash mostrou o findings.json divergente — alguém tinha editado um campo de severidade depois da lacração. Sam restaurou o arquivo a partir do repositório lacrado e abriu um achado de processo sobre edições sem controle.
19.4 Erros e limites
Hashes detectam mudança, não distinguem má-fé de acidente. Combine-os com logs de acesso. Um arquivo alterado pode ser uma captura de tela editada ou uma troca maliciosa; o hash sozinho não diz qual. Os logs de acesso mostram quem tocou o objeto e quando. Sam sempre registra o hash e a referência do log juntos antes de declarar uma evidência lacrada, e trata um log ausente como uma lacração incompleta, mesmo quando o resumo ainda bate. Acidente ou má-fé passa então a ser uma pergunta para o log de acesso e para as pessoas que o mantêm.
19.2b O que um hash não prova
Um resumo que bate diz que os bytes são os mesmos do momento da lacração; não diz que os bytes foram obtidos legalmente, que a conta estava autorizada nem que a interpretação no texto do achado está correta. Combine os hashes com a versão da ROE, o id de quem agiu e uma breve nota de método, para que um revisor possa reconstruir a alegação, não só o arquivo. Revisores que param numa marca verde deixam passar coletas ilegais e interpretações erradas. A versão da ROE e o id de quem agiu amarram os bytes à permissão e à pessoa. Uma breve nota de método explica o que o arquivo deveria mostrar. A lista de verificação de lacração de Sam tem quatro caixas: resumo, ROE, quem agiu, método.
19.3b Escolha de algoritmos
Prefira SHA-256 ou mais forte para os manifestos de evidências; evite MD5/SHA-1 em trabalhos novos. Documente o algoritmo no manifesto para que um leitor futuro não precise adivinhar. A agilidade criptográfica aqui é um campo de versão, não uma troca silenciosa no meio do engajamento. Colisões de MD5 e SHA-1 são história para ensino, não base para novos manifestos. Nomear o algoritmo no manifesto impede que um leitor futuro presuma MD5 só porque uma ferramenta legada o imprimiu. Trocas silenciosas no meio do engajamento dividem o conjunto de evidências em resumos incompatíveis. Sam fixa o algoritmo na configuração do TrackScope e rejeita envios que o omitam.
19.1b Inventário de certificados
Para ativos com TLS exposto, registre os certificados apresentados (titular, emissor, notAfter) mediante autorização. Certificados expirados ou divergentes são achados sobre a integridade das operações; não transforme o exercício num ataque a TLS de nível de pesquisa. Titular, emissor e notAfter, lidos mediante autorização, bastam para sinalizar expiração e divergência de nome. Sam guarda a impressão digital do PEM no ticket para que um reteste veja se o certificado mudou. As execuções de inventário são agendadas, não improvisadas durante uma varredura ruidosa. Certificados que vencem dentro da janela do engajamento são comunicados ao contato do cliente no mesmo dia, em vez de esperarem o relatório final.
Exercícios
- EX055 — Perguntas de autenticação. Liste cinco perguntas de configuração para o SSO dos funcionários da Riverstone. Rubrica: 3 = cinco concretas (IdP, MFA, papéis, tempo de vida, caminho de administração); 2 = três; 1 = uma; 0 = nada.
- EX056 — Laboratório de hash. Qual arquivo divergiu e o que você faz? Rubrica: 3 = findings.json; restaurar/relacrar; investigar quem escreveu; 2 = só o arquivo; 1 = vago; 0 = errado.
- EX057 — Regra de segredos. Escreva uma política de uma linha para senhas de avaliação em tickets. Rubrica: 3 = nunca no corpo do ticket; referenciar o id no cofre; 2 = "não compartilhe"; 1 = fraco; 0 = permite colar.
Síntese
Leia a configuração de identidade; calcule o hash das evidências; mantenha os segredos num cofre.
Continue estudando — capítulo 19 de 50
← Capítulo 18 (rascunho) · Índice de capítulos do curso · Capítulo 20 (rascunho) →