Parte 4 · padrão de referência
O mesh sobre uma rede segmentada em camadas
Numa rede em camadas típica (Purdue / IDMZ) há cinco firewalls entre sete camadas, com política de fluxo explícita. O desenho do mesh é derivado dessa política — mas nem tudo nele é imposição: parte é escolha de arquitetura, e vale saber qual é qual. Control plane na camada corporativa on-premises.
A política de fluxo — o que impõe e o que permite
| Regra rede em camadas | Natureza | Efeito no desenho |
|---|
| Bidirecional permitido entre camadas adjacentes | permissão | É o caso em que colocamos 100% dos fluxos de mesh |
| Outbound atravessando camadas: permitido | permissão | Não usamos — é o que tornaria o hop dispensável |
| Inbound atravessando camadas: BLOQUEADO | imposição | O control plane nunca disca para dentro do OT. Quem inicia é sempre o nó de dentro |
| "Preocupação com o quantitativo de regras a serem geridas nos firewalls" | alerta | O hop concentra S sites em 2 regras adjacentes por fronteira |
Detalhe que costuma passar batido: não há firewall entre Level 1 e Level 2 — eles são uma só zona no nível de rede. É mais um motivo para o execution node ficar no Level 3 e alcançar os dois de lá.
O que a política impõe: o sentido. Inbound atravessando camadas é bloqueado, logo o control plane nunca disca para dentro do OT. Consequência vendável: zero fluxo inbound para o OT — o time de segurança não precisa abrir um único fluxo para dentro da planta.
O que é escolha nossa, não imposição: o hop. Pela regra 2, o exec-ot do Level 3 poderia discar direto no control plane do IT — travessia outbound é permitida no slide. Adotamos o hop por três razões: responde ao alerta sobre volume de regras; mantém todos os fluxos no caso adjacente em vez de depender da exceção; e dá um ponto único de controle na borda. Se o cliente preferir o caminho direto, isso não viola a política — muda o custo de firewall e a postura, não a conformidade.
As camadas reais e onde cada nó fica
FW = firewall · note que NÃO há FW entre Level 1 e Level 2
OT L1 / L2 OT Level 3 IDMZ IT corporativa Cloud
┌────────────┐ ┌────────────┐ ┌─────────────┐ ┌──────────────┐ ┌────────────┐
│ PLC · IHM │ FW │ exec-ot │ FW │ hop1 · hop2 │ FW │ ctrl1 ctrl2 │ FW │ exec-cloud │
│ switches │────│ 1 por site │────│ exec-idmz │────│ gateway ×2 │────│ │
│ sensores │ │ │ │ bastion │ │ hub ×2 EDA ×2│ └────────────┘
└────────────┘ └────────────┘ │ Hosting Ctr │ │ PG · LB │
▲ └─────────────┘ │ exec-it ×2 │
│ SSH/SNMP/Modbus └──────────────┘
└── já liberado no HLD
SENTIDO DE INICIAÇÃO DA CONEXÃO DE MESH
exec-ot ═══▶ hop1 / hop2 ═══▶ ctrl1 / ctrl2
(OT L3) (IDMZ) (IT)
└─ adjacente ─┘ └─ adjacente ─┘
outbound outbound
✗ Nada disca para dentro do OT. ✗ Nenhum salto de camada.Quem tem hop e quem não tem referência genérica — a tabela do ambiente vem abaixo
A regra é profundidade de camada, não localização geográfica. O hop não é um por site — é um par HA no IDMZ compartilhado por todos os sites OT.
| Zona | Nó AAP | Fronteiras até o control plane | Hop? | Por quê |
|---|
| Camada corporativa (IT) | control ×2 + exec ×2 | 0 | não | Mesma zona do control plane |
| Cloud | exec ×1–2 | 1 — adjacente | não | Regra ponto a ponto resolve |
| IDMZ | exec ×1–2 | 1 — adjacente | não | Atende Hosting Center e devices do DMZ |
| OT Level 3 (por site) | exec ×1..N | 2 — L3→IDMZ→IT | SIM (escolha) | Duas fronteiras. A política permitiria o caminho direto — o hop evita a travessia |
| OT Level 1 / Level 2 | nenhum | — | — | Alcançados por SSH a partir do exec node do L3, que é adjacente e cujas portas já estão liberadas no HLD |
Os dois erros que esta tabela evita: (1) colocar execution node em L1/L2 — corta ~⅔ da contagem de nós na frota OT; (2) um hop por site — o hop não escala com a quantidade de plantas.
A conta de VMs o número do ambiente está no bloco abaixo
CONTROL PLANE — camada corporativa (fixo, igual à referência Red Hat)
├─ 2 × gateway (+Redis) ├─ 2 × EDA (+Redis) ├─ 1 × PostgreSQL externo
├─ 2 × controller ├─ 1 × metrics └─ 1 × load balancer
├─ 2 × hub (+Redis) (HAProxy ou NetScaler)
subtotal: 11 VMs
EXECUTION PLANE — distribuído por zona (delta do padrão)
├─ 2 × exec-it IT ├─ 1 × bastion/installer IDMZ
├─ 2 × hop (par HA) IDMZ ├─ 1–2 × exec-cloud cloud
├─ 1–2 × exec-idmz IDMZ └─ S × exec-ot OT L3, 1 por site
TOTAL ≈ 18 + S VMs
S = nº de zonas OT Level 3. É o driver DOMINANTE da conta — e é pendência aberta.Duas regras de leitura: o hop não entra na conta de capacidade — tem capacity=0, não roda job; entra na conta de VMs e de HA. E cada zona OT tem um piso de 1 execution node independente do pico de carga, porque alcance é binário e capacidade é contínua. Com poucos sites o pico manda na conta; com muitos sites, o piso de alcance manda.
