Capítulo 18 — Arquitetura de segurança
Mapa da aula
Aula 18 publicada. Mapa, exemplo, EX035.
flowchart TD
N0["18.1 Arquiteturas de TO em camadas"]
N1["18.2 A DMZ e a intermediação de dados"]
N2["18.3 Confiança zero na TO"]
N3["18.4 Acesso remoto"]
N4["18.5 Arquitetura de monitoramento"]
N5["18.7 Atividade prática"]
N6["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX035"]
Desenho lógico
flowchart LR
N0["18.1 Arquiteturas de TO em camadas"]
N1["18.2 A DMZ e a intermediação de dados"]
N2["18.3 Confiança zero na TO"]
N3["18.4 Acesso remoto"]
N4["18.5 Arquitetura de monitoramento"]
N5["18.7 Atividade prática"]
N6["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX035"]
[18.1 Arquiteturas de TO em camadas]
|
v
[18.2 A DMZ e a intermediação de dados]
|
v
[18.3 Confiança zero na TO]
|
v
[18.4 Acesso remoto]
|
v
[18.5 Arquitetura de monitoramento]
|
v
[18.7 Atividade prática]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX035]
Objetivos de aprendizagem e conexão
Ao fim deste capítulo você será capaz de (1) descrever arquiteturas de referência para a tecnologia operacional, incluindo modelos em camadas e DMZs; (2) aplicar os princípios de confiança zero onde eles cabem na TO e explicar onde não cabem; (3) projetar arquiteturas de acesso remoto, registro em log e monitoramento; e (4) avaliar uma arquitetura pela consequência, e não apenas pela contagem de controles. Ele se apoia nos capítulos 11, 12 e 15 e prepara os capítulos 26 e 27.
18.1 Arquiteturas de TO em camadas
As arquiteturas de TO costumam ser descritas em níveis: processo físico (nível 0), sensores e atuadores com controle básico (1), controle supervisório (2), operações da instalação (3), uma zona desmilitarizada e o nível corporativo (4–5). O modelo, que descende da arquitetura de referência de Purdue e aparece no guia de TO do NIST, é uma ferramenta para posicionar ativos e condutos, não uma lei. Os sistemas modernos borram os níveis: sensores conectados à nuvem, serviços remotos de fornecedores e dispositivos de campo com enlaces celulares diretos. Na LRWA, os servidores SCADA ficam na zona de controle, as RTUs na zona de campo e a réplica do historiador na DMZ.
18.2 A DMZ e a intermediação de dados
A DMZ de TO fica entre as redes de controle e corporativa. Nenhum tráfego direto a atravessa: os sistemas corporativos falam com serviços da DMZ (réplica do historiador, servidor de correções, gateway de acesso remoto), que falam com os sistemas de controle. Um teste útil: se qualquer host corporativo for comprometido, ele consegue enviar um pacote que chegue a um controlador? Se sim, a DMZ é decorativa. Na LRWA, a revisão de fluxos aplicou esse teste e reprovou: um script de relatório corporativo alcançava diretamente uma RTU de campo. Mover esses dados para a réplica do historiador na DMZ é o modo como a LRWA torna sua DMZ real, e não decorativa, e o teste é repetido depois que cada novo conduto é acrescentado.
18.3 Confiança zero na TO
A confiança zero, como descrita no NIST SP 800-207, remove a confiança implícita baseada na localização na rede; todo acesso é autenticado, autorizado e avaliado por sessão. Na TO, o princípio é valioso para o acesso humano e de engenharia — identidades nominais, autenticação forte, privilégio sob demanda (just-in-time), gravação de sessões — e para dispositivos novos que o suportem. Ele se encaixa mal onde controladores legados não conseguem autenticar de forma alguma e onde as malhas de controle não toleram um ponto de decisão de política no seu caminho. A resposta de engenharia é aplicar a confiança zero nas fronteiras em que for possível (acesso de engenharia, intermediação de dados, gateways) e usar segmentação e monitoramento em torno do que não consegue autenticar.
18.4 Acesso remoto
O acesso remoto de fornecedores e da equipe é um dos principais caminhos de entrada na TO. Projete-o assim: um gateway de acesso na DMZ; autenticação multifator; contas nominais; acesso aprovado por sessão; conexões a um jump host, nunca diretamente aos controladores; gravação das sessões; e expiração automática. O incidente na estação de tratamento de água de Oldsmar foi inicialmente atribuído a acesso remoto não autorizado por meio de software de compartilhamento de área de trabalho; declarações posteriores, relatadas pela WUSF Public Media (2023), indicaram que provavelmente foi erro de um funcionário. De um modo ou de outro, o caso ilustra por que o compartilhamento de área de trabalho sem controle nas estações dos operadores é uma fraqueza de arquitetura, e por que os relatos iniciais de incidentes devem ser tomados como provisórios.
18.5 Arquitetura de monitoramento
O monitoramento de segurança de rede na TO costuma ser passivo: cópias do tráfego, vindas de portas espelhadas dos switches ou de taps, alimentam sensores que entendem protocolos industriais e estabelecem uma linha de base do comportamento normal. Os logs de servidores, firewalls e gateways vão para um coletor na DMZ ou numa zona de segurança dedicada. O monitoramento não pode criar novos caminhos para dentro do controle: os sensores recebem apenas cópias, e as interfaces de gerenciamento ficam numa rede separada. Na LRWA, os taps passivos ficam no switch da zona de controle e no head-end da LTE, e suas interfaces de gerenciamento são mantidas fora da rede monitorada.
18.6 Exemplo resolvido: a arquitetura-alvo do TMRP (sintético)
O alvo da LRWA: corporativo — firewall — DMZ (réplica do historiador, gateway de acesso remoto com MFA, preparação de correções, coletor de logs) — firewall — zona de controle (par SCADA, jump host de engenharia) — conduto de campo sobre LTE privada com autenticação na camada de aplicação (gateways para as RTUs legadas) — RTUs e painéis de controle locais com modo manual. Os taps de monitoramento passivo ficam no switch da zona de controle e no head-end da LTE. A arquitetura é avaliada pelas consequências: comandos forjados exigem comprometer uma chave de gateway de campo ou os servidores SCADA; o comprometimento do corporativo rende os dados da réplica do historiador, mas nenhum caminho de pacotes até os dispositivos de campo; a perda da LTE deixa as instalações em modo automático local ou manual, com baterias de telemetria de 24 h.
18.7 Atividade prática
Desenhe a arquitetura-alvo em texto ou num diagrama simples e anote em cada conduto as entradas da lista de permissões do Laboratório 5. Depois aplique o teste da DMZ da §18.2. Marque cada conduto com seu sentido e seu protocolo, e mostre onde ficam os taps passivos. Para cada entrada da lista de permissões, pergunte qual zona inicia a conexão e se o teste da DMZ ainda passa caso essa zona seja comprometida. Depois acrescente o caminho de engenharia pelo jump host e verifique que nenhuma regra deixa uma estação de engenharia alcançar diretamente uma RTU de campo, que foi uma das três violações de fluxo da LRWA. Um diagrama que esconde o sentido não consegue mostrar se a DMZ realmente funciona.
18.8 Erros comuns e limites
- DMZs com regras diretas "temporárias".
- Confiança zero alegada para sistemas que não conseguem autenticar.
- Acesso remoto que contorna o gateway (modems de fornecedores, ferramentas de compartilhamento de área de trabalho).
- Sensores de monitoramento com interfaces de gerenciamento na rede monitorada.
- Arquiteturas julgadas pelo número de controles, e não pelas consequências evitadas.
Na LRWA, o terceiro e o primeiro erros são os mais prováveis: um fornecedor querendo acesso rápido à RTU-B para diagnósticos, e uma regra direta temporária acrescentada durante uma interrupção. A arquitetura-alvo responde aos dois com o gateway de acesso da DMZ e o controle de mudanças em cada conduto.
Exercícios — capítulo 18
EX035 — Teste da DMZ. Objetivo: testar um projeto de DMZ. Entradas: uma regra proposta que permite ao servidor de ERP corporativo escrever o estado das ordens de serviço diretamente no banco de dados do SCADA por TCP/1433. Passos: aplique o teste da DMZ; proponha um projeto alternativo que atenda à necessidade do negócio. Evidência esperada: análise e projeto. Rubrica: 3 = regra rejeitada com o motivo, a alternativa intermedeia os dados pela DMZ, com o lado do controle buscando os dados ou com uma exportação unidirecional; 2 = a alternativa ainda é de entrada; 1 = aceita a regra; 0 = nada.
EX036 — Arquitetura de acesso remoto. Objetivo: projetar o acesso de fornecedores. Entradas: o fornecedor da RTU-B precisa de acesso trimestral para diagnósticos. Passos: especifique o caminho de acesso, a autenticação, a aprovação, o monitoramento e a expiração; liste as evidências que mostrariam que o projeto funciona. Evidência esperada: especificação e lista de evidências. Rubrica: 3 = gateway, MFA, aprovação por sessão, jump host, gravação, expiração, e evidências (logs, teste do caminho direto negado); 2 = sem evidências; 1 = VPN direta para o controle; 0 = nada.
Síntese do capítulo
Use modelos em camadas para posicionar ativos e condutos, torne a DMZ real não permitindo nenhuma travessia direta, aplique a confiança zero onde os sistemas conseguem autenticar e a segmentação onde não conseguem, faça todo acesso remoto passar por um gateway controlado, monitore de forma passiva sem criar caminhos e julgue a arquitetura pelas consequências que ela torna difíceis de causar.
Continue estudando — capítulo 18 de 50
← Capítulo 17 · Índice de capítulos do curso · Capítulo 19 →
Siga para a próxima lição escrita.