Capítulo 27 — Arquitetura e engenharia de segurança: projeto de controles
Mapa da aula
Aula 27 publicada. Mapa, exemplo, EX079.
flowchart TD
N0["27.1 Projetar a partir dos requisitos"]
N1["27.2 Defesa em profundidade com propósito"]
N2["27.3 Especificações precisas"]
N3["Síntese"]
N0 --> N1 --> N2 --> N3
N3 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX079"]
Desenho lógico
flowchart LR
N0["27.1 Projetar a partir dos requisitos"]
N1["27.2 Defesa em profundidade com propósito"]
N2["27.3 Especificações precisas"]
N3["Síntese"]
N0 --> N1 --> N2 --> N3 --> Q["EX079"]
[27.1 Projetar a partir dos requisitos]
|
v
[27.2 Defesa em profundidade com propósito]
|
v
[27.3 Especificações precisas]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX079]
Objetivos de aprendizagem
Você vai (1) projetar controles que atendam a requisitos específicos; (2) combinar em camadas controles preventivos, detectivos e corretivos; (3) especificar os controles com precisão suficiente para implementá-los e testá-los.
27.1 Projetar a partir dos requisitos
Sofia projeta controles para o requisito de que as tabelas de tarifas sejam autênticas antes do uso. O controle preventivo é uma assinatura digital: as tabelas de tarifas são assinadas no escritório de tarifas com uma chave guardada num HSM, e todo consumidor verifica a assinatura com uma chave pública fixada (pinned) antes de carregá-las. O controle detectivo registra cada carga com a versão e o hash da tabela e gera um alerta se aparecer uma versão que o escritório de tarifas não publicou. O controle corretivo permite que as operações voltem à última tabela verificada em minutos. Cada controle se liga ao requisito e ao caso de abuso que atende.
27.2 Defesa em profundidade com propósito
Combinar controles em camadas só é útil se as camadas falharem de forma independente. Sofia verifica seu projeto das tabelas de tarifas: se a chave de assinatura fosse roubada, as assinaturas seriam verificadas, então o controle detectivo compara as versões carregadas com uma lista de publicações independente mantida pelo financeiro. Se o código de verificação tivesse um bug, o controle detectivo ainda perceberia versões inesperadas. Se os dois falhassem, o rollback limitaria o dano. Ela observa que dois controles que dependem da mesma chave ou do mesmo banco de dados não oferecem profundidade real. Defesa em profundidade significa perguntar, para cada camada, o que acontece se a anterior falhar.
27.3 Especificações precisas
A especificação de um controle precisa dizer o suficiente para que ele seja implementado e testado. Sofia escreve: o algoritmo de assinatura é o Ed25519, conforme especificado na RFC 8032; a chave pública é fixada na configuração e só é rotacionada por meio da gestão de mudanças; uma falha na verificação interrompe a carga e gera um alerta de alta prioridade; os logs incluem o identificador da tabela, a versão, o hash e o componente que fez a verificação. Ela anexa casos de teste: uma tabela corretamente assinada é carregada; uma tabela modificada é rejeitada; uma tabela assinada com uma chave desconhecida é rejeitada. Especificações precisas impedem que cada implementador faça premissas diferentes que deixam lacunas entre os componentes.
Exemplo resolvido
Sofia projeta tabelas de tarifas assinadas com uma chave guardada em HSM, verificações independentes de versão e rollback, testa a independência das camadas e escreve uma especificação com três casos de teste.
Caso sintético. O projeto das tarifas é sintético; a RFC 8032 é real.
Erros e limites
Chaves fixadas complicam a rotação de emergência. Os controles detectivos dependem de alguém responder aos alertas.
Exercícios
-
EX079 — Três tipos de controle. Cite os controles preventivo, detectivo e corretivo das tabelas de tarifas. Rubrica: 3 = verificação de assinatura; registro de versões e alertas; rollback;; 2 = três;; 1 = um;; 0 = nenhuma.
-
EX080 — Verificação de independência. Por que comparar as versões carregadas com a lista independente do financeiro? Rubrica: 3 = ainda detecta o uso indevido se a chave de assinatura for roubada;; 2 = independente;; 1 = redundante;; 0 = nenhuma.
-
EX081 — Teste da especificação. Dê um caso de teste da especificação. Rubrica: 3 = tabela corretamente assinada carrega, tabela modificada é rejeitada ou chave desconhecida é rejeitada;; 2 = um;; 1 = vago;; 0 = nenhuma.
Síntese
Um bom desenho de controles liga cada controle a um requisito, sobrepõe em camadas controles que falham de forma independente e os especifica com precisão.
Continue estudando — aula 27 (capítulo 27 de 50)
← Capítulo 26 · Índice das aulas · Capítulo 28 →
Continue para a próxima aula já escrita.