Capítulo 19 — Identidade e criptografia
Mapa da aula
Aula 19 publicada. Mapa, exemplo, EX055.
flowchart TD
N0["19.1 Identidade dos parceiros"]
N1["19.2 Assinaturas"]
N2["19.3 Ciclo de vida das chaves"]
N3["19.4 Acesso dos analistas"]
N4["19.5 Múltiplos fatores"]
N5["Nota de prática — Acesso de emergência"]
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 Identidade dos parceiros"]
N1["19.2 Assinaturas"]
N2["19.3 Ciclo de vida das chaves"]
N3["19.4 Acesso dos analistas"]
N4["19.5 Múltiplos fatores"]
N5["Nota de prática — Acesso de emergência"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX055"]
[19.1 Identidade dos parceiros]
|
v
[19.2 Assinaturas]
|
v
[19.3 Ciclo de vida das chaves]
|
v
[19.4 Acesso dos analistas]
|
v
[19.5 Múltiplos fatores]
|
v
[Nota de prática — Acesso de emergência]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX055]
Objetivos de aprendizagem
Você vai (1) autenticar parceiros e analistas com a força adequada; (2) usar assinaturas digitais para proteger a integridade dos feeds; (3) gerenciar chaves e certificados ao longo de seu ciclo de vida; (4) aplicar acesso baseado em papéis a conteúdo rotulado com TLP.
19.1 Identidade dos parceiros
Servidores TAXII 2.1 autenticam os clientes, em geral com autenticação HTTP sobre TLS ou com certificados de cliente. O TLS mútuo permite que os dois lados provem sua identidade. As credenciais são por parceiro, para que uma possa ser revogada sem afetar as outras. Kofi mantém um registro das credenciais dos parceiros com suas datas de expiração e responsáveis. Quando um funcionário de um parceiro sai, o parceiro pode pedir a troca da credencial sem interromper os outros feeds. Credenciais compartilhadas entre parceiros tornariam isso impossível e esconderiam qual parceiro fez determinada requisição.
19.2 Assinaturas
Uma assinatura sobre um pacote exportado permite ao destinatário verificar que ele veio do Lantern e não foi alterado. Calcule primeiro o hash (SHA-256), assine o hash com uma chave privada mantida em hardware e publique a chave pública por um canal confiável. Se a verificação falhar, o pacote é posto de lado e os dois lados são avisados, porque ou o conteúdo mudou no caminho ou a chave errada está em uso. A tarefa de exportação de Kofi assina automaticamente, e a impressão digital da chave pública é lida em voz alta em uma chamada com cada novo parceiro.
19.3 Ciclo de vida das chaves
Gerar, distribuir, usar, rotacionar, revogar, destruir. Certificados expiram; certificados expirados em um cliente TAXII interrompem a coleta no pior momento. Coloque-os na agenda e monitore-os. O exemplo resolvido mostra o custo de pular essa etapa. O registro de Kofi lista cada certificado e cada chave com sua expiração, seu responsável e as etapas de substituição, e os alertas chegam com semanas de antecedência. A revogação é testada uma vez por ano com um certificado de teste, para que a equipe saiba que as etapas funcionam antes de precisar delas. Chaves destruídas são registradas com data e método, o que um auditor pode pedir para ver.
19.4 Acesso dos analistas
Os papéis seguem o TLP: todos os analistas leem CLEAR e GREEN; a equipe do SOC lê AMBER; o conteúdo AMBER+STRICT fica limitado à BEN; relatórios RED vão para as pessoas nomeadas em cada relatório. As decisões de acesso são registradas. O mapeamento fica no sistema de identidade, e não no código do Lantern, de modo que mudar quem pode ler conteúdo AMBER é uma mudança de acesso com aprovação própria. Kofi revisa mensalmente a composição dos grupos com o líder do SOC. Para relatórios RED, o Lantern verifica a lista de destinatários de cada relatório em vez de um grupo, o que corresponde ao significado do rótulo: apenas pessoas nomeadas.
19.5 Múltiplos fatores
O acesso dos analistas ao Lantern exige MFA. A técnica T1078 Valid Accounts do ATT&CK descreve adversários que usam credenciais legítimas; o MFA aumenta o custo. Uma senha roubada, sozinha, então não abre a plataforma. Kofi escolheu chaves de hardware para os analistas com acesso a material AMBER e RED, porque códigos enviados por mensagem de texto podem ser interceptados ou desviados. Contas de serviço não podem usar um segundo fator da mesma forma, então dependem de certificados e restrições de rede. Logins a partir de dispositivos novos são registrados e revisados toda semana.
Nota de prática — Acesso de emergência
Se o provedor de identidade falhar durante um incidente, os analistas ainda precisam do Lantern. Uma conta de emergência lacrada, com uma senha aleatória longa, guardada offline e registrada a cada uso, dá esse acesso. Seu uso dispara um alerta e uma revisão posterior, para que o acesso de emergência nunca vire rotina. Cada uso da conta de emergência é revisado em até um dia útil por alguém que não seja quem a usou.
Exemplo resolvido
O certificado de cliente de um parceiro expira em um domingo e interrompe seu feed. Kofi acrescenta monitoramento de expiração de certificados com alertas a 30, 14 e 3 dias e documenta com o parceiro um roteiro de rotação.
Caso sintético. O incidente de expiração é inventado.
Erros e limites
Assinaturas provam origem e integridade, não a veracidade do conteúdo. Contas compartilhadas pela equipe anulam os registros de acesso.
Exercícios
- EX055 — Limite da assinatura. O que uma assinatura válida em um feed prova, e o que ela não prova? Rubrica: 3 = origem/integridade; não a exatidão dos indicadores; 2 = uma das metades; 1 = prova a verdade; 0 = nenhuma.
- EX056 — Acesso a RED. Quem pode ler um relatório TLP:RED no Lantern? Rubrica: 3 = apenas os destinatários nomeados no relatório; 2 = uma equipe pequena; 1 = todo o SOC; 0 = nenhuma.
- EX057 — Alertas de expiração. Proponha um calendário de alertas para a expiração de certificados. Rubrica: 3 = várias antecedências (p. ex., 30/14/3 dias) + responsável; 2 = um alerta; 1 = vago; 0 = nenhuma.
Síntese
Autentique por parceiro, assine as exportações, gerencie o ciclo de vida das chaves e associe os papéis ao TLP com acesso registrado.
Continue estudando — capítulo 19 de 50
← Capítulo 18 (rascunho) · Índice de capítulos do curso · Capítulo 20 (rascunho) →