OpenCyber Academy
Tecnólogo · Capítulo 8 · Português
Código do curso: OCA-092Capítulo 08: OCA-092-C008

Capítulo 8 — Fundamentos de arquitetura de segurança

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 08 publicada. Mapa, exemplo, EX022.

flowchart TD
  N0["8.1 Zonas, conduítes e a direção da confiança"]
  N1["8.2 Defesa em profundidade e menor privilégio"]
  N2["8.3 Os caminhos de gerenciamento fazem parte da arqu"]
  N3["8.4 Projetar para a operabilidade"]
  N4["8.5 Desgaste: como as arquiteturas se deterioram"]
  N5["8.7 Atividade prática: desenhe o caminho de gerencia"]
  N6["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX022"]

Desenho lógico

flowchart LR
  N0["8.1 Zonas, conduítes e a direção da confiança"]
  N1["8.2 Defesa em profundidade e menor privilégio"]
  N2["8.3 Os caminhos de gerenciamento fazem parte da arqu"]
  N3["8.4 Projetar para a operabilidade"]
  N4["8.5 Desgaste: como as arquiteturas se deterioram"]
  N5["8.7 Atividade prática: desenhe o caminho de gerencia"]
  N6["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX022"]

[8.1 Zonas, conduítes e a direção da confiança]
    |
    v
[8.2 Defesa em profundidade e menor privilégio]
    |
    v
[8.3 Os caminhos de gerenciamento fazem parte da arqu]
    |
    v
[8.4 Projetar para a operabilidade]
    |
    v
[8.5 Desgaste: como as arquiteturas se deterioram]
    |
    v
[8.7 Atividade prática: desenhe o caminho de gerencia]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX022]

Objetivos de aprendizagem e conexão

Depois deste capítulo, você deve ser capaz de:

O Capítulo 2 comparou os fluxos observados com os conduítes declarados. Este capítulo trata da própria declaração: por que o LANTERN tem a forma que tem, e o que um implementador precisa proteger ao construí-lo. Você raramente vai projetar sozinho um sistema crítico inteiro, mas vai tomar dezenas de pequenas decisões que preservam o projeto ou o desfazem em silêncio.

8.1 Zonas, conduítes e a direção da confiança

No LANTERN, os dados fluem para cima: estações → relay → historiador → relatórios. Os comandos para as estações não passam pelo LANTERN de forma alguma; os operadores controlam as estações a partir do sistema separado da sala de controle. Essa é a propriedade mais importante do projeto. Se o relay for comprometido, um atacante pode falsificar ou bloquear a telemetria — algo sério —, mas não pode comandar uma bomba por meio dele. Toda mudança proposta deve ser conferida contra essa propriedade: "isto cria um caminho para que comandos, ou sistemas corporativos, alcancem a zona das estações?"

A segmentação das redes de controle em relação às redes de negócio, com caminhos controlados e monitorados entre elas, é uma orientação consistente entre as fontes de segurança de TO (NIST SP 800-82 Rev. 3; visão geral da ISA/IEC 62443). Os firewalls implementam isso; a orientação do NIST sobre firewalls recomenda políticas de negação por padrão que permitam apenas o tráfego necessário (NIST SP 800-41 Rev. 1).

8.2 Defesa em profundidade e menor privilégio

Defesa em profundidade significa vários controles independentes, para que uma falha não leve direto ao dano. Para que uma mensagem de telemetria forjada engane um operador, ela teria de alcançar o relay (segmentação), carregar um código de autenticação válido (Capítulo 15), passar na validação (Capítulo 3) e evitar os alertas de valores implausíveis (Capítulo 19). Cada camada precisa ser independente: dois controles que dependem da mesma senha são um controle só.

O menor privilégio — dar a cada usuário e processo apenas o acesso de que ele precisa — aparece nos princípios clássicos de projeto de Saltzer e Schroeder (Saltzer e Schroeder, 1975), junto com os padrões à prova de falha e a economia de mecanismo. Para um implementador, eles são concretos: a conta de serviço do relay não consegue gravar na sua própria configuração; a conta do historiador que o relay usa consegue inserir telemetria, mas não apagá-la.

8.3 Os caminhos de gerenciamento fazem parte da arquitetura

Muitos diagramas mostram o caminho dos dados e omitem o caminho de gerenciamento: como administradores, sistemas de backup, agentes de monitoramento e fornecedores alcançam cada host. Os caminhos de gerenciamento costumam transportar o acesso mais poderoso do sistema. No LANTERN, a administração só alcança os relays a partir de um host de salto de gerenciamento na zona corporativa, com MFA; os fornecedores alcançam o host de salto por meio de uma conta limitada no tempo (Capítulo 7); o monitoramento recebe logs enviados pelos relays, em vez de fazer login neles.

O RLY-02 do Laboratório 22, alcançando servidores de hora públicos, é um caminho de gerenciamento que ninguém desenhou.

8.4 Projetar para a operabilidade

Um projeto seguro que os operadores não conseguem operar será contornado. Pergunte, para cada controle: como ele é mantido? O que acontece às 03:00 quando ele falha? Como um engenheiro obtém acesso de emergência, e como esse acesso é registrado? O que o serviço faz quando o relay está fora — os operadores sabem que a visão do historiador está desatualizada? Projete os modos degradados de forma deliberada: as estações do LANTERN armazenam localmente 24 horas de leituras, então uma interrupção do relay perde atualidade, e não dados; a tela do operador mostra a idade de cada valor.

8.5 Desgaste: como as arquiteturas se deterioram

As arquiteturas se desgastam por meio de exceções que parecem razoáveis: uma regra de firewall "temporária" para um fornecedor, um laptop com duas interfaces usado para configuração, um servidor de relatórios movido para a zona de controle "para ficar mais rápido", uma conta de administrador compartilhada por conveniência. Cada uma é pequena; juntas, removem a separação. As defesas são rotineiras: conduítes registrados com responsável e data de expiração (Capítulo 2), revisões de fluxos, revisões de regras e a recusa de exceções não documentadas.

Fallowmere mostra cada tipo. A estação de trabalho corporativa conversando em Modbus com a PS-04 é um hábito de duas interfaces; o modem celular que a Kell deixou no CLP da PS-07 é uma exceção de fornecedor esquecida que nenhum registro de fluxo mostra; e o pedido para enviar setpoints recomendados do historiador para a PS-07 teria sido uma exceção de aparência razoável que inverteria a direção da confiança.

8.6 Exemplo resolvido: um pedido que atravessa zonas (sintético)

A operação de Água pede que o historiador envie semanalmente um arquivo de "setpoint recomendado" ao CLP da PS-07, para automatizar uma otimização. Conferido contra o Capítulo 8 ("Zonas, conduítes e a direção da confiança"), o pedido quebra a propriedade mais importante: ele cria um caminho da zona corporativa para a zona das estações que transporta informação de controle. Você não o recusa de imediato; devolve a questão de projeto ao seu dono, com alternativas: um operador revisa a recomendação no sistema da sala de controle e a aplica ali; ou o arquivo vai para o sistema da sala de controle, que o valida e o prepara para aprovação de um operador. Qualquer uma preserva a direção da confiança. O seu papel é mostrar a consequência e as alternativas, e registrar a decisão.

8.7 Atividade prática: desenhe o caminho de gerenciamento

Desenhe as zonas e os conduítes do LANTERN do Capítulo 2 e depois acrescente todos os caminhos de gerenciamento: SSH de administração via host de salto, acesso de fornecedor, backup, monitoramento, hora, atualizações de pacotes. Para cada um, registre origem, destino, protocolo, autenticação e responsável. Marque qualquer caminho que permitiria a uma única credencial alcançar tanto a zona corporativa quanto a das estações.

No LANTERN, o caminho a vigiar é a rota do fornecedor: a conta limitada no tempo da Kell alcança o host de salto, e o host de salto alcança os relays. Se essa mesma conta, ou uma credencial compartilhada opsuser, também abrir o compartilhamento de arquivos corporativo, uma única senha roubada atravessa as duas zonas. Marque também o caminho do servidor de hora, já que o RLY-02 do Laboratório 22 foi encontrado usando servidores de hora públicos que nenhum diagrama mostrava.

8.8 Erros comuns e limites

A arquitetura limita o que pode acontecer; ela não mostra o que de fato acontece. A verificação precisa de fluxos, logs e testes (Capítulos 2, 19 e 23).

Um exemplo de Fallowmere: os cartões de controle do risco R2 (Capítulo 18) seriam menos independentes do que parecem se o registro das sessões do fornecedor e a conta do fornecedor fossem administrados pelo mesmo login da Kell.

Exercícios — capítulo 8

EX022 — Confira a direção da confiança. Objetivo: avaliar pedidos de mudança contra a propriedade-chave do projeto. Entradas: três pedidos: (a) o relay busca uma nova allowlist de estações no historiador a cada hora; (b) o SIEM envia um comando de bloqueio automatizado ao firewall das estações quando vê um ataque; (c) o relay encaminha telemetria para a Halden Cloud num teste de análise de dados. Restrições: aceite, rejeite ou reprojete cada um, com um parágrafo. Etapas: avalie cada um contra as quatro propriedades de projeto do Capítulo 8 (direção da confiança, menor privilégio, caminhos de gerenciamento, operabilidade). Evidência esperada: três parágrafos. Rubrica: 3 = (a) reprojetar: a configuração deve fluir do controle de versões por meio de uma mudança, e não ser buscada numa zona de menor confiança; (b) reprojetar com cuidado: o bloqueio automatizado num caminho de TO exige acordo com a operação, falha segura e confirmação manual; (c) aceitável apenas como um novo conduíte declarado, com entrada no registro de fluxos de dados (Capítulo 12), contrato e monitoramento; 2 = dois bem argumentados; 1 = respostas secas; 0 = nada.

EX023 — Independência das camadas. Objetivo: testar a defesa em profundidade. Entradas: camadas propostas para proteger o relay: firewall gerenciado por E. Strand; administração do relay por E. Strand; chave HMAC gerada e guardada por E. Strand no relay; regras de monitoramento escritas por E. Strand. Restrições: não presuma má intenção. Etapas: (1) identifique a dependência comum; (2) diga qual evento único derrota todas as camadas; (3) proponha duas mudanças que restaurem a independência. Evidência esperada: meia página. Rubrica: 3 = uma única pessoa e um único conjunto de credenciais; o comprometimento ou o erro de uma conta derrota todas; mudanças como papéis de administração separados, chave mantida num armazenamento separado com custodiantes diferentes, regras de monitoramento de responsabilidade da equipe de segurança e revisadas por ela; 2 = parcial; 1 = "acrescentar mais controles"; 0 = nada.

EX024 — Modo degradado. Objetivo: projetar a operabilidade. Entradas: o relay fica fora por quatro horas durante a noite. Restrições: considere operadores, dados e alertas. Etapas: (1) descreva o que os operadores veem; (2) o que acontece com os dados; (3) quais alertas disparam e quem os recebe; (4) o que acontece quando o relay volta. Evidência esperada: uma página. Rubrica: 3 = as telas mostram a idade desatualizada, e não valores congelados como se fossem atuais; as estações armazenam em buffer; os alertas de silêncio de estação e de saúde do relay chegam ao plantão; a volta causa um envio do acúmulo que exige folga (Capítulo 1) e não dispara indevidamente as verificações de reprodução; 2 = falta um aspecto; 1 = genérico; 0 = nada.

Síntese do capítulo

A propriedade arquitetural mais importante do LANTERN é a direção da confiança: os dados fluem para cima, e os comandos nunca descem por ele. Proteja essa propriedade em toda mudança, mantenha as camadas realmente independentes, ponha os caminhos de gerenciamento no diagrama e projete deliberadamente os modos degradados e o acesso de emergência. As arquiteturas se deterioram por meio de exceções; registre cada uma com um responsável e uma data de expiração, e confira-as.

Respostas comentadas

EX022 — Confira a direção da confiança. (a) Reprojetar: uma allowlist de estações puxada do historiador torna um sistema da zona corporativa a fonte da configuração de segurança do relay; em vez disso, a allowlist vem do controle de versão, por meio de mudança (Capítulo 14), implantada nos relays. (b) Reprojetar com cuidado: o bloqueio automático no firewall da estação poderia cortar a telemetria legítima ou o acesso de engenharia durante um incidente; ele precisa do acordo da Água, de um modo de falha seguro e de escopo limitado ao tráfego que não é do processo, ou a alertas mais uma confirmação humana com um clique. (c) Aceitável apenas com um novo conduíte declarado, uma entrada no registro de fluxos de dados (Capítulo 12), termos de contrato e de retenção com a Halden, criptografia e monitoramento — e a data de término do piloto.

EX023 — Independência das camadas. A dependência comum é uma pessoa e um conjunto de credenciais: firewall, administração do relay, custódia das chaves e monitoramento ficam todos com E. Strand. Um único evento — o comprometimento da conta de E. Strand, ou um erro bem-intencionado — pode desativar todas as camadas e a detecção disso. Mudanças: separar os papéis (a equipe de rede é dona do firewall; a equipe de plataforma, do relay; a equipe de segurança, das regras de monitoramento e da sua revisão) e guardar as chaves num armazenamento com custodiantes separados, para que os administradores do relay não consigam lê-las ou substituí-las sem que se perceba.

EX024 — Modo degradado. Operadores: as telas do historiador mostram a idade dos valores aumentando e uma faixa de "relay offline", e não valores congelados apresentados como atuais. Dados: as estações guardam em buffer local (24 h). Alertas: os alertas de saúde do relay e de silêncio de estação chegam ao plantão da FSTS e à sala de controle da Água em 15–20 minutos. Retorno: as estações enviam o acúmulo; o relay precisa de folga para a rajada (Capítulo 1); as mensagens acumuladas são mais antigas que a janela de tempo ao vivo e precisam ser aceitas por um caminho explícito de acúmulo que ainda confira o MAC e a sequência (Capítulo 15), para que a verificação de replay não as rejeite por engano — e não vire um buraco de replay.