Capítulo 15 — Infraestrutura crítica e segurança setorial: integração e dependências
Mapa da aula
Aula 15 publicada. Mapa, exemplo, EX057.
flowchart TD
N0["15.1 Interdependência"]
N1["15.2 Dependências como grafo"]
N2["15.4 Pontos de integração são fronteiras"]
N3["15.5 Atividade prática"]
N4["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX057"]
Desenho lógico
flowchart LR
N0["15.1 Interdependência"]
N1["15.2 Dependências como grafo"]
N2["15.4 Pontos de integração são fronteiras"]
N3["15.5 Atividade prática"]
N4["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX057"]
[15.1 Interdependência]
|
v
[15.2 Dependências como grafo]
|
v
[15.4 Pontos de integração são fronteiras]
|
v
[15.5 Atividade prática]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX057]
Objetivos de aprendizagem e conexão
Ao final deste capítulo, você deverá ser capaz de:
- modelar as dependências técnicas — virtualização, diretório, tempo, armazenamento, telecomunicações, energia — como um grafo e calcular o que uma única falha afeta;
- encontrar componentes compartilhados entre serviços e setores, incluindo o compartilhamento indireto por meio de uma dependência de uma dependência;
- tratar todo ponto de integração (roteadores de estação, redes de operadoras, gateways de fornecedores, exportações de dados) como uma fronteira a ser modelada, controlada e monitorada;
- transformar uma análise de dependências em verificações e controles concretos.
O Capítulo 13 encontrou um caminho até a KW-04 que contornava o firewall por meio de uma rede de operadora. Essa era uma dependência que ninguém tinha desenhado. Este capítulo as desenha de forma sistemática.
15.1 Interdependência
As infraestruturas críticas dependem umas das outras fisicamente (energia para as bombas), por meio de informação (telemetria sobre uma rede de operadora), geograficamente (dutos e locais compartilhados) e logicamente (pessoal, software e administração compartilhados). Essa classificação vem do artigo amplamente citado de Rinaldi, Peerenboom e Kelly (Rinaldi et al., 2001). Para um técnico, as surpresas mais frequentes são lógicas: um diretório, um cluster de hipervisores, uma fonte de tempo ou um coletor de monitoramento compartilhado por sistemas cujos donos acham, cada um, que ele é seu.
Para um técnico, as surpresas mais frequentes são lógicas: um diretório, um hipervisor ou uma fonte de tempo que vários serviços compartilham sem que nenhum dono os reivindique. Desenhe esses primeiro, depois os enlaces físicos e de operadora. O Laboratório 15 torna visíveis os nós compartilhados como contagens entre serviços.
15.2 Dependências como grafo
Escreva cada dependência como "A precisa de B". Para encontrar o que falha quando B falha, siga as arestas para trás — tudo o que precisa de B, tudo o que precisa desses, e assim por diante. Isso é uma busca em largura no grafo invertido. Dois resultados importam: o conjunto de serviços afetados e o caminho pelo qual cada um é afetado, porque o caminho diz onde um controle ou uma redundância quebraria a cadeia.
O compartilhamento indireto é o caso importante. No modelo do KVROC, o servidor de gestão predial do hospital e o servidor SCADA se autenticam ambos no ad-ops, que roda no esx-03, enquanto o front end da rede elétrica também roda no esx-03. Nenhum dono de serviço lista o esx-03 como "seu"; os três dependem dele.
15.3 Exemplo resolvido: as dependências do KVROC (sintético)
Laboratório 15 (salve como lab15.py e execute com python3 lab15.py):
# Lab 15 - trace failure impact through technical dependencies (offline, standard library only)
# Synthetic dependency map for the Kestrel Vale operations centre: "A needs B" edges.
from collections import deque
needs = {
"water-telemetry": ["scada-01", "cell-router-kw", "fw-01"],
"scada-01": ["ad-ops", "ntp-ops", "hist-02", "esx-02"],
"hist-02": ["esx-02", "san-01"],
"hospital-bms": ["bms-server", "fw-02"],
"bms-server": ["esx-02", "ad-ops"],
"grid-ss3-telecontrol": ["fep-01", "telco-mpls"],
"fep-01": ["ntp-ops", "esx-03"],
"ad-ops": ["esx-03"],
"ntp-ops": ["gps-clock"],
}
def impacted(failed):
rev = {}
for a, bs in needs.items():
for b in bs: rev.setdefault(b, []).append(a)
seen, q = set(), deque([failed])
while q:
for a in rev.get(q.popleft(), []):
if a not in seen: seen.add(a); q.append(a)
return sorted(seen)
services = {"water-telemetry", "hospital-bms", "grid-ss3-telecontrol"}
for comp in ["esx-02", "esx-03", "gps-clock", "san-01", "telco-mpls"]:
hit = impacted(comp)
print(f"{comp:<10} -> services {sorted(services & set(hit))} via {len(hit)} dependants")
counts = {c: len(services & set(impacted(c))) for c in {b for bs in needs.values() for b in bs}}
print("shared by all three services:", sorted(c for c, n in counts.items() if n == 3))
Saída esperada (Python 3.13.5):
esx-02 -> services ['hospital-bms', 'water-telemetry'] via 5 dependants
esx-03 -> services ['grid-ss3-telecontrol', 'hospital-bms', 'water-telemetry'] via 7 dependants
gps-clock -> services ['grid-ss3-telecontrol', 'water-telemetry'] via 5 dependants
san-01 -> services ['water-telemetry'] via 3 dependants
telco-mpls -> services ['grid-ss3-telecontrol'] via 1 dependants
shared by all three services: ['esx-03']
O esx-02 hospeda o servidor SCADA, o historiador e o servidor de gestão predial; assim, a sua falha afeta o monitoramento da água e do hospital. O esx-03 é o único componente que afeta os três serviços — diretamente, no caso do front end da rede elétrica, e indiretamente, pelo diretório, nos outros dois. O gps-clock, a referência do ntp-ops, afeta a água e a rede elétrica: perdê-lo não para nada imediatamente, mas o Capítulo 7 mostrou o que relógios à deriva fazem com toda investigação posterior. O telco-mpls afeta apenas a rede elétrica, e o san-01 apenas a água.
Seguem-se ações técnicas: o diretório precisa de um segundo controlador de domínio num host diferente (e o comportamento do servidor SCADA quando o diretório está inalcançável precisa ser testado — os operadores ainda conseguem entrar na IHM?); o ntp-ops precisa de uma segunda referência, independente, e de monitoramento do deslocamento; a capacidade e o grupo de administradores do esx-03 se tornam uma questão intersetorial, revisada com os três donos.
15.4 Pontos de integração são fronteiras
Todo lugar em que o serviço se conecta a algo que ele não controla é uma fronteira:
- Equipamentos de comunicação das estações — roteadores celulares, rádios, a rede privada da operadora. O redirecionamento de porta do Capítulo 13 estava aqui. A configuração de cada roteador pertence ao inventário de ativos, sob controle de mudanças e detecção de deriva (Capítulo 14).
- Gateways de suporte remoto de fornecedores — Capítulo 10.
- Exportações de dados — o envio diário do historiador ao servidor corporativo de relatórios (conduíte C4 do Capítulo 6). As exportações devem ser enviadas para fora a partir do lado de controle, nunca puxadas por um host corporativo com credenciais dentro da zona de controle.
- Serviços compartilhados — diretório, tempo, monitoramento. Os seus administradores administram, na prática, todos os dependentes.
O trabalho da CISA sobre as National Critical Functions enquadra essas dependências em escala nacional (National Critical Functions); o técnico aplica o mesmo raciocínio a um centro de operações.
15.5 Atividade prática
Acrescente um nó power-ups-a de que o esx-02 e o esx-03 precisam, e um nó cell-carrier de que o cell-router-kw e o telco-mpls precisam. Execute de novo o Laboratório 15 e registre quais componentes agora são compartilhados pelos três serviços. Depois proponha uma mudança técnica para cada um.
Depois da mudança, registre quais componentes são compartilhados pelos três serviços e proponha uma resposta técnica para cada um, como um segundo controlador de domínio ou uma segunda alimentação elétrica. Mantenha as novas arestas no mesmo formato do laboratório, para que o grafo continue executável. Revise as propostas com os três donos de serviço antes de qualquer mudança.
15.6 Erros comuns e limites
- Tratar o diretório e o serviço de tempo como "infraestrutura" sem dono de serviço.
- Contar dependentes em vez de olhar quais serviços são afetados e por quais caminhos.
-
O grafo do Laboratório 15 é binário (precisa / não precisa); as dependências reais têm modos degradados e temporizadores (uma credencial em cache funciona por horas; um relógio deriva devagar).
-
Listar apenas as dependências diretas e não perceber o hipervisor sob o diretório.
- Deixar o gps-clock sem dono nomeado, embora o Laboratório 15 mostre que a telecontrol da rede elétrica e a telemetria de água dependem dele.
- Presumir que uma operadora isola as redes privadas dos clientes sem verificar.
- Classificar o esx-03 pelos seus sete dependentes em vez de notar que ele é o único ativo compartilhado pelos três serviços.
Exercícios — capítulo 15
EX057 — Os caminhos importam. Objetivo: traçar um caminho de impacto. Insumos: Laboratório 15. Passos: modificar o programa para imprimir, para o esx-03, um caminho de dependência dele até cada serviço afetado. Evidência esperada: código e três caminhos. Rubrica: 3 = por exemplo, esx-03 → fep-01 → grid-ss3-telecontrol; esx-03 → ad-ops → scada-01 → water-telemetry; esx-03 → ad-ops → bms-server → hospital-bms; explica que um segundo diretório em outro host quebra dois dos três; 2 = caminhos sem interpretação; 1 = tentativa; 0 = nada.
EX058 — Novos componentes compartilhados. Objetivo: executar a atividade. Insumos: atividade 15.5. Passos: executar e interpretar. Evidência esperada: saída e duas mudanças técnicas. Rubrica: 3 = power-ups-a e esx-03 compartilhados pelos três (e cell-carrier afetando a água e a rede elétrica); mudanças como alimentações de UPS separadas para os dois hosts e uma segunda operadora ou um caminho de rádio para as estações mais críticas; 2 = apenas a saída; 1 = parcial; 0 = nada.
EX059 — Teste de modo degradado. Objetivo: testar o comportamento quando uma dependência falha. Insumos: ad-ops indisponível. Passos: escrever um plano de teste com escopo, numa janela de manutenção, para estabelecer se os operadores ainda conseguem entrar na IHM e se a varredura do SCADA continua. Evidência esperada: plano de teste com condições de parada. Rubrica: 3 = testar primeiro numa réplica reserva ou de laboratório; em produção, bloquear apenas o caminho da IHM até o diretório por uma janela curta, com as operações presentes; verificar logins em cache, contas locais de emergência, continuidade da varredura; condições de parada; evidências; 2 = sem a etapa da réplica; 1 = "desligar o controlador de domínio"; 0 = nada.
EX060 — Direção da exportação. Objetivo: configurar corretamente uma fronteira. Insumos: o servidor corporativo de relatórios hoje entra no hist-02 toda noite com uma senha armazenada para puxar o CSV. Passos: redesenhar e listar as mudanças de configuração nos dois hosts e no fw-01. Evidência esperada: desenho e mudanças. Rubrica: 3 = o hist-02 envia por HTTPS para um único endpoint; a credencial corporativa dentro da Z2 é removida; a direção da regra do fw-01 é invertida (apenas Z2 → Z6, host e porta específicos); a integridade do envio é verificada (resumo na carga ou arquivo assinado); monitoramento dos envios que falham; 2 = envio sem remover a credencial antiga; 1 = vago; 0 = nada.
Síntese do capítulo
Os serviços falham por meio daquilo de que dependem, e as dependências mais perigosas são as compartilhadas que nenhum dono reivindica. Modele as dependências como um grafo, percorra-o para trás a partir de cada componente e olhe os caminhos, não apenas as contagens. Trate todo ponto de integração — roteadores de estação, operadoras, gateways de fornecedores, exportações, diretório e tempo — como uma fronteira sujeita à mesma disciplina de controle, mudança e monitoramento que o firewall.
Continue estudando — capítulo 15 de 18
← Capítulo 14 · Índice de capítulos do curso · Capítulo 16 →
Siga para a próxima lição escrita.