Capítulo 17 — Conceitos de criptografia
Mapa da aula
Aula 17 publicada. Mapa, exemplo, EX049.
flowchart TD
N0["17.1 TLS em trânsito"]
N1["17.2 Em repouso"]
N2["17.3 Hashes"]
N3["17.4 Antipadrões"]
N4["17.5 Custódia de chaves"]
N5["17.7 Testar a negação da exportação de chaves"]
N6["17.8 Tokens de plataforma de vida curta"]
N7["17.9 Registrar as cerimônias de chaves"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX049"]
Desenho lógico
flowchart LR
N0["17.1 TLS em trânsito"]
N1["17.2 Em repouso"]
N2["17.3 Hashes"]
N3["17.4 Antipadrões"]
N4["17.5 Custódia de chaves"]
N5["17.7 Testar a negação da exportação de chaves"]
N6["17.8 Tokens de plataforma de vida curta"]
N7["17.9 Registrar as cerimônias de chaves"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX049"]
[17.1 TLS em trânsito]
|
v
[17.2 Em repouso]
|
v
[17.3 Hashes]
|
v
[17.4 Antipadrões]
|
v
[17.5 Custódia de chaves]
|
v
[17.7 Testar a negação da exportação de chaves]
|
v
[17.8 Tokens de plataforma de vida curta]
|
v
[17.9 Registrar as cerimônias de chaves]
|
v
[Exemplo resolvido] --> [Exercício EX049]
Objetivos de aprendizagem
Você vai (1) dizer o que o TLS faz; (2) proteger evidências em repouso; (3) evitar inventar esquemas.
17.1 TLS em trânsito
Confidencialidade e integridade das sessões — não a AuthZ da aplicação. O TLS impede que alguém no caminho da rede leia ou altere silenciosamente o tráfego entre o navegador de um cliente e os servidores do TRB, e permite ao navegador verificar que está falando com o domínio real do banco. Ele não faz nada quanto ao que acontece depois que a requisição chega. Se a aplicação entrega ao cliente A o extrato do cliente B, ela o faz por uma conexão perfeitamente cifrada. Os achados mantêm as duas coisas separadas. Uma versão de protocolo desatualizada ou uma suíte de cifras fraca é um achado de transporte. Uma verificação de titularidade ausente é um achado de aplicação, e corrigir as configurações de TLS o deixaria intocado.
17.2 Em repouso
Cifragem do cofre de evidências e logs de acesso à chave. Cifrar o armazenamento do cofre protege contra alguém que obtenha os discos, os backups ou os snapshots sem passar pela aplicação, por exemplo um bucket de armazenamento mal configurado ou um disco descartado. Isso não protege contra quem consegue fazer login normalmente no cofre, porque a aplicação decifra os dados para essa pessoa. A chave que destrava o armazenamento é o verdadeiro ativo, e é por isso que seu uso é registrado separadamente do acesso aos arquivos. Uma rajada de eventos de uso da chave sem logins correspondentes no cofre sugeriria que alguém está lendo o armazenamento diretamente, que é o cenário que a cifragem em repouso existe para impedir.
17.3 Hashes
SHA-256 para a integridade das evidências, não para aulas sobre o desenho do armazenamento de senhas aqui. Um hash de uso geral como o SHA-256 é projetado para ser rápido, o que serve para tirar a impressão digital de arquivos de evidência: calcular o hash de um grande arquivo de capturas de tela leva segundos, e qualquer mudança aparece. A mesma velocidade o torna uma má escolha para armazenar senhas, onde a lentidão é uma defesa deliberada contra a adivinhação. O armazenamento de senhas precisa de funções dedicadas, como Argon2 ou bcrypt, um tema dos capítulos de identidade. Neste livro, o SHA-256 responde a uma pergunta, se este é o mesmo arquivo que foi capturado, e os testadores não devem presumir que um sistema é seguro porque ele usa um hash em algum lugar.
17.4 Antipadrões
Criptografia caseira para os tokens do TrackScope é proibida. Um dos primeiros protótipos do TrackScope construía tokens de sessão codificando em base64 o nome do testador e um carimbo de tempo e, depois, aplicando XOR do resultado com uma string fixa. Parecia ilegível e não oferecia proteção nenhuma. Quem visse dois tokens conseguiria recuperar a string fixa e forjar tokens novos. A regra desde então é usar a biblioteca de tokens assinados do framework ou um padrão consolidado, como JWTs assinados com uma chave mantida no cofre, e nunca inventar um algoritmo ou uma codificação. Quando Sam vê tokens opacos num sistema em teste, ele confere se mudam de forma previsível entre requisições, um sinal comum de esquemas caseiros.
17.5 Custódia de chaves
Chaves da plataforma em HSM ou cofre, com controle dual onde exigido. Quem detém uma chave de assinatura pode se passar pelo sistema que a usa. As chaves mais importantes do TRB, como a que assina os arquivos de escopo do TrackScope e a chave mestra do cofre, ficam num módulo de segurança de hardware. O HSM executa operações com a chave, mas não a entrega. Controle dual significa que operações sensíveis, como exportar uma chave ou mudar quem pode usá-la, precisam de duas pessoas autorizadas agindo juntas, para que nenhuma conta comprometida ou descuidada consiga fazê-las sozinha. Chaves menos críticas ficam no cofre de software, ainda com acesso registrado e donos nomeados.
17.6 Limites
A criptografia não detém administradores mal-intencionados autorizados com chaves válidas. Cifragem, assinatura e hashes protegem contra pessoas sem as chaves. Um administrador que detém legitimamente uma chave pode decifrar, assinar ou alterar dados, e a criptografia vai confirmar fielmente suas ações como válidas. Os controles contra pessoas de dentro são, portanto, procedimentais e detectivos: segregação de funções, controle dual para as operações mais sensíveis, logs que o administrador não consegue apagar e revisões do uso das chaves. Quando um relatório diz que os dados estão protegidos por cifragem, Sam acrescenta quem pode decifrá-los, porque é nessa lista que está o risco remanescente.
17.7 Testar a negação da exportação de chaves
As cerimônias de exportação no HSM para chaves da plataforma exigem duas pessoas e um código de motivo. O papel de estagiário de Sam não pode exportar. Ele testou a negação tentando uma exportação em staging e registrou o log de negação como evidência de que o controle funciona. O teste foi combinado com antecedência com o dono do HSM e rodado contra uma chave de staging que não protege nada real; assim, uma falha não teria tido consequências. O log de negação registra a conta, a operação pedida, o horário e o motivo da recusa. Um auditor pode se apoiar nesse registro em vez de numa declaração de que a política existe. Ele também dá um ponto de referência se o comportamento do controle algum dia mudar.
17.8 Tokens de plataforma de vida curta
Os tokens da plataforma expiram dentro da janela mais uma hora. Sam testa que tokens expirados não conseguem registrar achados. Tokens que persistem são achados contra a plataforma. Um token que sobrevive ao seu propósito é uma credencial esperando para ser roubada. A hora extra permite aos testadores terminar a redação depois que a janela fecha, e qualquer coisa mais longa só acrescenta exposição. O teste é direto. Sam guarda um token de uma janela encerrada, espera passar sua expiração e tenta criar um achado com ele. A plataforma precisa recusar, e a recusa precisa aparecer no log. Se a tentativa tiver sucesso, o achado nomeia o componente da plataforma que deixou de verificar a expiração.
17.9 Registrar as cerimônias de chaves
As notas das cerimônias listam os participantes e os ids das chaves, nunca material secreto. Sam arquiva as notas no cofre com a mesma retenção das evidências. Uma cerimônia de chaves é o evento formal em que uma chave é criada, rotacionada ou exportada sob controle dual. Suas notas mostram que o evento seguiu o procedimento, cobrindo quem estava presente, qual chave estava envolvida, qual código de motivo se aplicava e o que cada pessoa conferiu. Valores secretos nunca aparecem, nem parcialmente, porque as notas são lidas por auditores e revisores que não devem conseguir reconstruir uma chave. Manter as notas sob o cronograma de retenção das evidências significa que elas ficam disponíveis enquanto qualquer coisa assinada com aquela chave puder ser questionada.
17.10 Uma string com cara de chave bloqueada na CI
Sam tenta fazer commit de um blob base64 "temporário" que parece uma chave. A CI falha. Ele fica contente. A mensagem de falha leva ao documento da cerimônia de chaves. As salvaguardas devem ensinar, não só bloquear. O blob era um fixture de teste copiado de staging, e Sam pretendia removê-lo antes do merge. Um scanner de segredos no pipeline não confia em intenções. Uma vez que uma chave está no histórico de versões, ela está em todo clone do repositório, e apagá-la num commit posterior não a remove. O link da mensagem explicava como pedir uma chave de teste adequada, o que resolveu o problema imediato e mostrou o caminho correto para a próxima vez.
17.11 Quando tokens de vida curta incomodam as pessoas
A validade do token mais uma hora certa vez pegou um analista que escrevia tarde. Melhor uma nova autenticação do que um token num notebook roubado semanas depois. O analista perdeu alguns minutos de texto não salvo quando o token expirou no meio de uma frase. A resposta razoável foi corrigir o incômodo sem alongar a validade. O FindingsDesk agora salva os rascunhos localmente de forma cifrada e pede ao usuário que faça login de novo antes de enviar, em vez de descartar o trabalho. Controles de segurança que custam esforço às pessoas tendem a ser contornados; por isso, reduzir o custo sem enfraquecer o controle faz parte de projetá-lo.
17.12 Guardar as negações como evidência
Os logs de negação das cerimônias são retidos como evidência positiva para os examinadores que perguntam se os papéis de estagiário são impostos. Os examinadores frequentemente perguntam como o banco sabe que uma restrição é imposta, e não apenas escrita. Uma exportação de configuração mostra a configuração pretendida. Um registro datado de uma tentativa real sendo recusada mostra a configuração em vigor. Os logs de negação são arquivados com o controle a que se referem e renovados sempre que o software do HSM ou as definições de papéis mudam, para que a evidência nunca descreva uma versão do sistema mais antiga que a examinada.
17.13 Usar os registros de negação na integração
Os pacotes de evidência positiva de negação são reutilizados na primeira semana de integração. Os funcionários novos aprendem mais vendo um controle real recusar uma requisição real do que lendo que as chaves estão protegidas. Cada pacote junta a requisição, a recusa e a política que a causou e mostra como ler o log. Ele também define expectativas. Os estagiários novos veem no primeiro dia que seu papel não pode exportar chaves e que tentar deixa um registro, o que torna a regra concreta. Os pacotes contêm apenas dados de staging e são revisados antes de serem reutilizados.
Exemplo resolvido (TRB sintético)
Sam rejeita um PR que cifra os arquivos de escopo com uma chave AES fixa no código-fonte.
Caso sintético — Riverstone Transit Bank (TRB). O banco, Sam Ito, TrackScope/FindingsDesk/PulseMap e todos os números são inventados para fins didáticos.
Erros e limites
Este livro não concede nenhuma autoridade para testar bancos ou sistemas de pagamento reais. Os laboratórios usam apenas endereços de faixas de documentação e dados sintéticos; código de exploit nunca é fornecido.
Exercícios
- EX049 — TLS vs AuthZ. O TLS corrige um IDOR? Rubrica: 3 = não, porque o TLS não corrige bugs de autorização; 2 = não, sem justificativa; 1 = sim; 0 = nada.
- EX050 — Chave fixa no código. Por que rejeitar chaves AES fixas no código-fonte? Rubrica: 3 = exposição da chave no repositório; sem controle dual; 2 = parcial; 1 = tudo bem; 0 = nada.
- EX051 — Uso do hash aqui. Para que servem os digests SHA-256 neste curso? Rubrica: 3 = integridade das evidências; 2 = parcial; 1 = cifrar o tráfego; 0 = nada.
Síntese
Use criptografia padrão corretamente; nunca crie a sua própria para os segredos do engajamento.
Continue estudando — capítulo 17 de 40
← Capítulo 16 (rascunho) · Índice de capítulos do curso · Capítulo 18 (rascunho) →