O que é DMZ industrial, como segmentar redes TI e OT, definir regras de firewall, proteger acessos remotos e testar segurança de serviços intermediários.
Confira!
Uma DMZ (Demilitarized Zone) é uma zona de rede intermediária criada para controlar as comunicações entre ambientes com níveis diferentes de confiança. Em redes corporativas, pode separar serviços expostos à internet da rede interna. Na indústria, uma DMZ entre TI e OT organiza a troca de informações e o acesso remoto entre sistemas corporativos e redes de automação, reduzindo a necessidade de conexões diretas com controladores e sistemas críticos.
A DMZ não é simplesmente uma VLAN. Ela deve possuir fronteiras verificáveis, regras de firewall restritivas, serviços intermediários identificados, autenticação, registro de atividades, monitoramento e procedimentos de resposta. Sua existência não garante segurança por si só: a efetividade depende dos fluxos permitidos, da segmentação e de como os sistemas internos operam quando a zona fica indisponível.
Este artigo apresenta a arquitetura de DMZ em redes TI e OT, as funções de historiadores, proxies, jump servers e gateways, os critérios de desenho de firewall e os ensaios necessários antes do aceite técnico de uma solução industrial.
O que é DMZ e qual é sua função na arquitetura
A expressão DMZ vem de demilitarized zone. Em uma arquitetura de redes, representa um segmento com políticas próprias que intermedeia conexões entre áreas com necessidades diferentes de exposição e proteção. A zona permite, por exemplo, disponibilizar um serviço a usuários corporativos sem autorizar que as mesmas máquinas acessem livremente a rede de controle industrial.
O controle decorre da arquitetura e de políticas, não do endereço IP ou do nome da VLAN. Quando redes corporativas e redes OT permanecem roteáveis sem filtros efetivos, adicionar uma VLAN chamada DMZ não impede acesso lateral. A delimitação deve ocorrer em fronteiras administradas, normalmente com firewalls, roteadores com controle apropriado e serviços que terminem sessões e republiquem dados quando necessário.
O NIST SP 800-82 Rev. 3 trata a segurança de tecnologia operacional considerando requisitos de disponibilidade, desempenho e segurança funcional. Isso exige equilibrar contenção de ameaças com a continuidade de processos produtivos; uma política aparentemente mais restritiva pode ser inadequada se interromper canais necessários à operação ou ao intertravamento.
DMZ corporativa e DMZ industrial: diferenças relevantes
A zona intermediária não deve permitir que um servidor comprometido se torne um caminho privilegiado para a automação. A matriz de arquitetura precisa especificar quais sistemas apenas recebem dados, quais iniciam sessões e quais, excepcionalmente, podem comandar funções operacionais. Sempre que houver integração bidirecional, o risco deve ser tratado explicitamente: uma conexão tecnicamente necessária pode precisar de proxy de aplicação, autenticação reforçada e restrições de operação.
A análise também precisa definir onde terminam os domínios administrativos. Se TI e OT compartilham os mesmos servidores de identidade, atualizações ou monitoramento, a perda de um serviço corporativo pode afetar a operação industrial. O projeto deve distinguir dependências aceitáveis, serviços que exigem autonomia local e procedimentos em modo degradado.
Uma DMZ corporativa pode hospedar aplicações web, servidores de autenticação intermediária, proxies e serviços que precisam receber acessos externos. A DMZ industrial também cria uma fronteira de mediação, mas protege sistemas que interagem com o processo físico, como SCADA, DCS, HMIs, PLCs, IEDs e redes de instrumentação.
| Aspecto | DMZ corporativa | DMZ industrial TI/OT |
| Principal finalidade | Expor serviços controlados e reduzir acesso à rede interna | Mediar integrações e acessos sem liberar comunicação ampla com processos |
| Serviços frequentes | Reverse proxy, web gateway, VPN, proxy de aplicações | Historiador replicado, jump host, proxy, coleta de logs, atualização validada |
| Requisito predominante | Segurança das aplicações e dados, com disponibilidade planejada | Segurança e disponibilidade com restrições operacionais e de segurança funcional |
| Controle essencial | Autenticação, segmentação, filtragem e observabilidade | Matriz de fluxos, acesso por janela, caminhos de dados definidos e testes de falha |
| Risco de arquitetura | Expor a rede interna por regras ou serviços excessivos | Permitir movimento lateral até sistemas que comandam o processo |
A DMZ deve ser definida pela relação entre zonas, serviços e fluxos, não pelo modelo de firewall escolhido. Pode haver mais de uma DMZ quando diferentes interfaces possuem requisitos distintos, por exemplo terceiros de manutenção, comunicação com nuvem industrial e compartilhamento de dados com sistemas corporativos. Essas zonas não devem ser reunidas automaticamente no mesmo segmento por conveniência.
Arquitetura TI/OT: zonas, conduítes e pontos de intermediação
O diagrama é uma representação conceitual de camadas de rede, não um conjunto de permissões automaticamente liberadas. Cada passagem pela fronteira deve ser justificada na matriz de fluxos e testada nos firewalls. Na prática, a topologia deve deixar claro se a troca de dados é iniciada pelo sistema OT, por um serviço de replicação ou por uma aplicação na DMZ, evitando comunicação irrestrita de estações da TI até controladores.
A arquitetura pode utilizar dois firewalls independentes, zonas distintas de um firewall com controles apropriados, proxies ou até mecanismos unidirecionais em aplicações específicas. Nenhum desenho é universalmente superior. A decisão depende de análise de ameaças, criticidade do processo, disponibilidade exigida, segregação administrativa e capacidade de inspeção dos protocolos. Para um empreendimento com alta criticidade, a análise de falhas comuns e de acesso de manutenção pode ser tão importante quanto o número de equipamentos.
A referência [NIST SP 800-82 Rev. 3](https://csrc.nist.gov/pubs/sp/800/82/r3/final) aborda a segurança de OT com restrições de segurança operacional, confiabilidade e desempenho. Não constitui, por si só, aprovação de determinada arquitetura ou substituto dos requisitos contratuais; os riscos e medidas precisam ser demonstrados para o processo real.
Em uma planta industrial, uma topologia conceitual possui camada empresarial, zona intermediária e redes de controle. O modelo de zonas e conduítes associado à família ISA/IEC 62443 ajuda a organizar a segregação conforme riscos e comunicações necessárias. A DMZ não substitui essa análise: é um dos mecanismos para implementar fronteiras entre áreas.
O diagrama ilustra uma política de intermediação e não determina que um único produto ou par de equipamentos físicos seja suficiente para todos os empreendimentos. É necessário avaliar isolamento administrativo, riscos de falha comum, segmentação interna, redundância, disponibilidade de links e caminho real dos pacotes. Uma DMZ com dois firewalls mal configurados pode ser menos segura que uma arquitetura com controles coerentes e comprovados.
A segmentação de redes IT/OT complementa essa definição, delimitando ativos, zonas e conduítes antes de escolher onde posicionar os mecanismos de acesso.
Matriz de fluxos e regras de firewall
Uma regra autorizada deve ter mecanismo de expiração ou rotina de revisão, especialmente para terceiros, testes temporários e manutenção. É recomendável correlacionar regras a solicitação aprovada, proprietário do serviço e evidência de necessidade. Portas comuns não bastam para identificar riscos de protocolos industriais; quando o controle exige identificação de comando ou função, a equipe precisa avaliar a inspeção de aplicação suportada e seus efeitos sobre o desempenho.
O plano de testes deve cobrir também comunicações negadas. Se uma estação da rede corporativa consegue alcançar diretamente a interface administrativa de um PLC sem um serviço autorizado, o desenho falhou mesmo que os fluxos positivos do historiador estejam funcionando. Devem ser verificados os caminhos alternativos por VPN, rede sem fio, manutenção, dual-homing e outras interfaces que eventualmente contornem a DMZ.
A matriz de fluxos é uma das entregas centrais do projeto. Deve partir dos processos que precisam trocar informações: qual aplicação fornece dados, qual sistema recebe, qual protocolo é utilizado, quem inicia a conexão e que função é autorizada. Uma regra genérica do tipo any-to-any ou uma liberação de sub-rede inteira em direção ao SCADA pode anular o controle de fronteira.
| Fluxo | Origem | Destino autorizado | Controle esperado |
| Visualização corporativa de produção | Aplicação em TI | Historiador ou serviço replicado na DMZ | Consulta à réplica; sem acesso direto ao PLC |
| Replicação de historiador | Serviço OT autorizado | Serviço intermediário | Identidade dedicada, direção e portas limitadas |
| Manutenção remota de fornecedor | Acesso externo autenticado | Bastion ou jump server na DMZ | MFA, autorização, prazo, registro e sessão auditável |
| Coleta de logs | Fontes autorizadas | Coletor intermediário | Integridade, sincronismo e retenção de registros |
| Atualização de sistemas OT | Repositório controlado | Destino OT aprovado | Inspeção, validação, janela e procedimento de reversão |
Uma regra técnica completa deve indicar origem e destino, porta e protocolo, serviço, finalidade, proprietário, criticidade, horário, sentido da sessão, identificação do pedido, data de revisão e evidência de teste. As políticas devem adotar negação por padrão, mas as exceções justificadas exigem análise de impacto e procedimento de aprovação.
Em ambientes OT, a adoção de uma regra deve ser validada quanto à segurança e ao desempenho. Protocolos industriais podem empregar descoberta, conexões persistentes ou tráfego cuja direção aparente não corresponde à origem funcional do dado. Por isso, testar apenas abertura de uma porta não comprova que a aplicação continuará estável.
Jump server, VPN e acesso remoto de fornecedores
O jump server ou bastion host é uma plataforma intermediária a partir da qual um operador devidamente autorizado acessa sistemas específicos. Ele reduz a necessidade de expor diretamente estações de engenharia, servidores SCADA ou consoles de supervisão. O jump server não deve possuir privilégios generalizados apenas por estar na DMZ.
A VPN pode proteger o transporte e autenticar a conexão remota, mas não substitui controle de destino, autorização por usuário, segregação de sessões e registro. Um projeto de acesso remoto deve definir identidade, MFA quando tecnicamente viável, autorização por chamado, janela temporária, limitação de comandos ou recursos, monitoramento e revogação.
Para manutenção de dispositivos críticos, é prudente planejar a participação da equipe de operação. O fornecedor deve receber o acesso estritamente necessário, e qualquer alteração de configuração deve permanecer registrada e vinculada a um procedimento de gestão de mudanças, incluindo possibilidade de retorno à versão anterior (rollback).
Historiadores, gateways e integrações com SCADA e nuvem
Um uso comum de DMZ industrial é tornar dados operacionais disponíveis à TI sem oferecer aos usuários corporativos acesso direto aos sistemas de controle. Isso pode ser feito com um historiador replicado, API intermediária, proxy de aplicação ou gateway de dados. O serviço intermediário recebe informações de origem autorizada e fornece uma interface de consulta adequada ao consumidor.
O desenho deve caracterizar como os dados atravessam a fronteira, a frequência da replicação, retenção, integridade, latência e tratamento de indisponibilidade. Um dashboard corporativo pode tolerar atraso de atualização; um comando de processo, em geral, não deve ser encaminhado pela mesma arquitetura sem estudo específico de segurança, disponibilidade e comando autorizado.
Na integração de dados de automação, protocolos como OPC UA podem participar da solução, desde que a exposição de serviços, certificados, autorizações e fronteiras seja tratada no projeto.
Monitoramento, logs, sincronismo e resposta a incidentes
A DMZ deve fornecer evidências de comunicações autorizadas e tentativas recusadas. É necessário monitorar acesso remoto, alterações de políticas, reinicialização de serviços, desempenho, novas conexões, falhas de autenticação, alteração de permissões e indisponibilidade de interfaces. Em vez de armazenar logs sem uso, a engenharia deve especificar quais eventos suportam investigação e qual equipe responde a cada alerta.
A confiabilidade do registro de eventos também depende de relógios sincronizados. Divergências de horário entre firewall, jump server e SCADA podem prejudicar a reconstrução da sequência de um incidente. Devem ser previstos fontes de tempo adequadas, política de retenção e proteção da integridade dos registros. A observabilidade deve permanecer disponível, quando possível, mesmo em degradação de um enlace.
É igualmente importante planejar mudanças programadas de regras. Toda política temporária de comissionamento ou manutenção deve ter prazo de encerramento e responsabilidade definida. Regras abertas durante a implantação não devem permanecer em produção como soluções permanentes.
Engenharia de fronteiras: roteamento, DNS, autenticação e serviços compartilhados
O desenho de uma DMZ deve partir do caminho real do tráfego. Diagramas que representam apenas três caixas — TI, DMZ e OT — podem omitir detalhes relevantes, como gateways padrão, rotas estáticas, NAT, conexões iniciadas por cada aplicação, inspeção com estado e interfaces de gerenciamento. Na elaboração do diagrama lógico, a engenharia precisa identificar, para cada segmento, os pontos de entrada e saída, os dispositivos que mantêm estado das sessões e os caminhos alternativos que poderiam contornar a fronteira.
Considere um serviço de supervisão que consulta uma réplica de dados na DMZ. O fluxo de consulta corporativa pode ser iniciado por um cliente TI e terminar na aplicação intermediária, enquanto a alimentação da réplica ocorre por uma conexão separada originada no ambiente OT. Se o projeto permitir que o mesmo cliente TI estabeleça uma sessão diretamente com o SCADA para contornar falhas do serviço intermediário, a DMZ deixa de exercer sua função de mediação. A disponibilidade da integração deve ser resolvida por uma arquitetura de serviço aprovada, não por exceções permanentes às regras.
A tradução de endereços (NAT), quando empregada, deve ser documentada tanto na forma percebida pela aplicação quanto na forma efetivamente processada pelo firewall. Caso um serviço dependa de retorno assimétrico por outro caminho, a inspeção stateful pode descartar sessões legítimas; a tentativa de resolver esse comportamento desabilitando controles de estado introduz uma nova exposição. A solução deve examinar a simetria das rotas, protocolos e a estratégia de alta disponibilidade sem assumir que cada enlace responde independentemente.
Os serviços auxiliares são igualmente relevantes. DNS, NTP, diretório de usuários, infraestrutura de certificados, repositórios de atualizações, backup e monitoramento podem criar dependências entre TI, DMZ e OT que não aparecem no desenho simplificado. Uma estação de engenharia OT que depende de autenticação contra um diretório corporativo pode perder acesso quando há falha da rede empresarial; uma DMZ que depende de um único servidor de horário pode perder precisão dos logs justamente durante um incidente.
| Dependência | Decisão de arquitetura | Teste requerido |
|---|---|---|
| DNS e resolução de nomes | Serviço intermediário ou resolução controlada por zona | Falha e expiração de registros sem acesso indevido |
| NTP e correlação de logs | Fontes de tempo e hierarquia coerentes entre fronteiras | Divergência de horário, indisponibilidade e recuperação |
| Autenticação de terceiros | Identidade individual e mínimo privilégio, com revogação | Conta expirada, credencial revogada e sessão interrompida |
| Backup e atualizações | Caminhos de distribuição controlados e restauração autorizada | Falha de repositório e recuperação sem liberação ampla |
| Administração de firewalls | Plano de gestão segregado e contas auditáveis | Falha da gestão remota sem desproteção do tráfego |
Esses serviços não precisam obrigatoriamente estar hospedados na DMZ. O projeto deve indicar quais podem ser compartilhados, quais precisam de uma instância própria, quais requerem operação degradada e quais não podem ser acessados a partir de determinados segmentos. A decisão integra a análise de segurança com disponibilidade e manutenção, especialmente quando existe risco de interrupção do processo físico.
Estudo aplicado: integração de CFTV, BMS e supervisão industrial
Considere um empreendimento com uma rede empresarial, centro de operações, sistema de CFTV, BMS predial e uma instalação industrial com SCADA. O contratante pretende centralizar dashboards e eventos, autorizar acesso remoto de fornecedores e manter sistemas operacionais separados da TI. A primeira tarefa é classificar ativos e fluxos: transmissão de vídeo, eventos de analytics, alarmes prediais, dados de processo, consultas históricas e comandos de operação possuem criticidades e necessidades de conexão diferentes.
A DMZ pode hospedar um portal autenticado, um serviço de publicação de eventos e um historiador replicado, mas isso não significa que as cargas tenham de compartilhar a mesma zona ou credencial. Vídeo contínuo pode exigir grande largura de banda e caminhos próprios, enquanto metadados e alarmes podem ser publicados seletivamente. Por sua vez, consultas de relatórios do BMS podem tolerar atraso que seria inaceitável para determinados intertravamentos de processo. É necessário preservar a independência de funções de segurança operacional ao planejar a integração.
A equipe não deve começar pela quantidade de portas do firewall. Deve elaborar uma matriz que relacione o produtor de cada dado, o consumidor, a finalidade, a direção da conexão, a sensibilidade do conteúdo, os níveis de autorização e o efeito da perda do serviço. Somente depois é possível especificar zonas, gateways, proxies, segmentação e capacidade da infraestrutura. Quando sistemas de diferentes fornecedores dependem do mesmo intermediário, a definição de interfaces de responsabilidade torna-se elemento contratual.
| Integração pretendida | Desenho de referência | Restrição essencial |
|---|---|---|
| Relatórios corporativos de produção | Historiador OT replica para serviço intermediário | A TI consulta a réplica, não os controladores |
| Alarmes de segurança eletrônica | Publicação controlada de eventos para centro de operações | Separar metadados de comandos aos equipamentos |
| Dashboards prediais | API ou serviço replicado a partir do BMS | Não conceder acesso genérico à rede de controladores |
| Manutenção de fornecedores | VPN até ponto aprovado, MFA e jump host | Permissões por ativo, janela e registro da sessão |
| Administração de equipamentos OT | Estação de engenharia e canal autorizado | Separar identidade administrativa de usuário de consulta |
Uma falha comum nessa situação é autorizar o acesso do centro de operações a uma sub-rede inteira para resolver integrações que poderiam ser atendidas por poucos serviços. Isso amplia o alcance de uma credencial comprometida e dificulta identificar quais caminhos realmente precisam permanecer disponíveis. Outra falha é permitir que um gateway de eventos da segurança eletrônica, originalmente destinado apenas a alarmes, receba comandos remotos não previstos no projeto. A matriz de dados e comandos deve delimitar essa diferença.
Na fase de comissionamento, cada caso deve ser ensaiado em sentido positivo e negativo. O painel corporativo deve conseguir obter o dado replicado, mas não iniciar comunicação direta com o PLC; o operador autorizado deve receber acesso à aplicação de manutenção definida, e não ao segmento completo; o sistema de eventos deve rejeitar publicações de origem não autorizada. Os testes demonstram a função da DMZ como limite de confiança, não apenas a conectividade das aplicações.
Alta disponibilidade, falhas e continuidade operacional
A redundância de firewalls não é automaticamente equivalente à redundância dos serviços da DMZ. Uma solução pode tolerar a falha de um equipamento de rede e continuar dependente de um único jump host, banco de dados, certificado, servidor de autenticação ou enlace físico. A análise de falhas deve separar esses domínios e identificar quais precisam permanecer operantes e quais podem ser interrompidos sem afetar a segurança funcional ou a continuidade da produção.
Na perda da DMZ, as funções locais do processo não devem depender de permissões emergenciais genéricas para continuar seguras. Isso exige identificar quais comunicações são exclusivamente informativas e quais participam de decisões operacionais. Para uma supervisão que apenas coleta indicadores de produtividade, a perda temporária de dados pode ser administrável; para uma função que integra comando ou condição de parada, qualquer dependência externa requer análise específica de falha, segurança e responsabilidade técnica.
A equipe deve documentar comportamento esperado na perda de um firewall, enlace, serviço de autenticação, relógio, réplica ou servidor intermediário. Para cada cenário, o projeto precisa estabelecer se a conexão é negada, se há failover por caminho equivalente ou se uma operação local assume a função. Uma escolha de ‘fail-open’ ou ‘fail-closed’ sem considerar o processo e as obrigações de segurança pode introduzir risco: abrir tudo amplia a exposição; bloquear sem estudo pode indisponibilizar funções necessárias.
Testar alta disponibilidade significa comprovar não só o retorno das sessões, mas também se o caminho alternativo continua sujeito às mesmas regras de segurança, se eventos relevantes permanecem registrados e se a configuração de política foi sincronizada. O teste deve considerar reconexão das aplicações, mudanças de endereço ou certificados e recuperação após indisponibilidade prolongada. A evidência resultante precisa identificar tempo observado, comportamento funcional e desvios em relação aos critérios contratados, sem prometer métricas não ensaiadas.
Gestão de mudanças, governança de regras e ciclo de vida da DMZ
Uma DMZ pode ser corretamente instalada e perder sua eficácia após alguns meses devido ao acúmulo de exceções. Novos fornecedores, aplicações, dispositivos IoT e serviços corporativos introduzem pedidos de comunicação. Se cada mudança resulta em mais uma regra ampla sem revisão do desenho, a zona intermediária gradualmente deixa de representar uma fronteira controlada. A governança deve considerar cada solicitação como alteração de engenharia, não apenas atividade operacional do administrador de firewall.
Uma requisição de mudança deve documentar ativo solicitante, serviço de destino, direção, protocolo, porta, responsável, razão técnica, duração, criticidade e plano de reversão. Alterações relevantes exigem avaliação de risco, verificação de conflitos, ensaio funcional e registro da versão anterior. Regras temporárias precisam de data e procedimento de expiração; regras permanentes devem ter revisão periódica baseada na utilização e no responsável pelo sistema.
A operação deve manter inventário de equipamentos e serviços, contas administrativas, certificados, backup das configurações, matriz de regras, diagrama As-Built, plano de resposta a incidentes e registros de testes. Esses elementos permitem distinguir alterações legítimas de desvios e apoiar investigações após falhas ou eventos de segurança. O histórico de decisões é tão relevante quanto o arquivo final exportado do firewall: sem justificativa e vínculo com o fluxo, a equipe não consegue avaliar se uma permissão ainda é necessária.
A responsabilidade pelo ciclo de vida também precisa ser definida. O proprietário do processo valida sua necessidade de comunicação; a engenharia estabelece arquitetura, critérios e impactos; a equipe de segurança avalia exposição e controles; os administradores implantam e registram as regras; a fiscalização verifica evidências. Em contratos EPCM ou de engenharia consultiva, a atuação independente pode apoiar design review, análise de riscos e aceite técnico, preservando as competências decisórias do contratante.
Projeto de DMZ: documentos e especificações exigíveis
Para contratar uma DMZ entre TI e OT, o contratante precisa fornecer ou exigir levantamento dos ativos, diagramas atuais, criticidade dos processos, necessidades de integração, controles existentes e requisitos de operação. O projeto deve gerar topologia lógica e física, matriz de zonas e conduítes, matriz de fluxos, regras de firewall, endereçamento, servidores e serviços intermediários, mecanismos de gestão de identidade, monitoramento, redundância e plano de transição.
É necessário definir com precisão responsabilidades de engenharia, fornecedor de firewall, integrador de automação, responsável pelo SCADA e equipe de segurança. Essa matriz de interfaces evita que cada contratado considere que a configuração de um sistema alheio será responsabilidade de outro fornecedor.
O Projeto de Rede Lógica e Redes Corporativas e o Projeto de Automação Industrial podem ser contratados como disciplinas coordenadas, com especificação de fronteiras e critérios de aceite comuns.
FAT, SAT e testes de aceitação de uma DMZ industrial
Os critérios devem ser rastreáveis a um identificador de requisito e uma regra específica. O relatório deve apresentar resultado esperado, resultado obtido, data, versão da configuração, evidências de log, responsável pelo teste e não conformidades. A simples evidência de conexão não demonstra restrição de privilégios; deve haver testes explícitos de bloqueio de tráfego não autorizado, expiração de credenciais e segmentação entre zonas.
| Cenário testado | Resultado esperado | Evidência de aceite |
|---|---|---|
| Acesso corporativo ao historiador replicado | Consulta permitida apenas ao serviço autorizado | Regra correspondente e registro de sessão |
| Acesso direto de TI a controlador OT | Tráfego negado, sem rota alternativa permitida | Log da negação e teste do caminho |
| Fornecedor fora da janela aprovada | Sessão e autorização encerradas | Logs, expiração e revogação |
| Falha de firewall ou serviço de DMZ | Comportamento conforme análise de segurança e continuidade | Relatório de contingência, alarmes e recuperação |
| Restauração após mudança | Configuração homologada recuperada | Backup, hash ou controle de versão e teste funcional |
Deve existir um procedimento de recuperação compatível com a operação: quem pode reverter uma alteração, em qual janela, sob que autorização e com qual validação. A indisponibilidade da DMZ não deve conduzir automaticamente à abertura generalizada de comunicação entre TI e OT. Soluções alternativas emergenciais exigem aprovação, duração delimitada e registro de riscos.
A conformidade deve ser demonstrada por testes de comunicação autorizada e negada, autenticação, revogação de acesso, falha de componentes, recuperação de serviços, sincronismo de logs e isolamento de zonas. O FAT permite verificar funcionalidades em ambiente representativo quando o escopo prevê; o SAT confirma comportamento no ambiente instalado. Nenhum dos dois deve ser reduzido a um ping entre duas sub-redes.
Um plano de teste pode incluir: (i) acesso corporativo permitido à réplica e negado ao SCADA; (ii) conexão de fornecedor limitada ao bastion e a destinos autorizados; (iii) sessão expirada com encerramento efetivo dos privilégios; (iv) falha de firewall ou serviço intermediário e avaliação da continuidade do processo; (v) restauração controlada de configurações e trilhas de auditoria. Esses itens precisam existir como procedimentos e evidências, não apenas como declaração comercial.
No recebimento, devem ser entregues configurações aprovadas, matriz de regras executadas, inventário, usuários administrativos, procedimentos de backup e restauração, planos de manutenção, registros de testes e desenhos As-Built. Pendências críticas de segurança ou de continuidade devem impedir aceite irrestrito.
Erros comuns de projeto e operação
Um problema recorrente é usar a mesma estação ou identidade administrativa para firewall, plataforma de autenticação e sistemas OT, elevando o risco de falha de modo comum. Outro é implantar redundância sem testar se a troca de caminho conserva os controles e os registros de auditoria. A arquitetura deve ser revisada não apenas no comissionamento inicial, mas sempre que novos sistemas corporativos, fornecedores, sensores ou gateways criem fluxos transversais.
Os principais problemas não surgem necessariamente do equipamento escolhido. Eles incluem uma DMZ nominal sem fronteira real, acesso direto de sistemas corporativos a controladores, regras amplas sem justificativa, serviços intermediários sem hardening, contas de fornecedor permanentes, logs desabilitados e configurações de exceção que não são removidas após os testes.
Outro erro é especificar somente a tecnologia e não sua integração com a operação. Um firewall pode aplicar regras conforme planejado e, ainda assim, derrubar um serviço OT mal mapeado. Assim, o projeto deve incluir testes funcionais dos processos afetados, rollback, janela de mudança e aceite conjunto das equipes envolvidas.
Considerações finais
A DMZ é uma zona intermediária de controle entre redes com diferentes níveis de confiança. No contexto TI/OT, sua função não é apenas separar endereços ou hospedar um firewall, mas impedir que aplicações corporativas e acessos externos disponham de conectividade irrestrita com SCADA, controladores e sistemas críticos. O modelo resulta da identificação das zonas, dos conduítes e dos fluxos necessários, com decisões explícitas sobre quais serviços podem iniciar conexões e quais precisam ser intermediados.
A arquitetura deve combinar filtragem e políticas restritivas com serviços adequados à finalidade: historiadores replicados para consultas, gateways para integração, bastion hosts para manutenção remota e mecanismos de autenticação, registro e monitoramento. As dependências de DNS, sincronismo de horário, certificados, atualizações e rotas também integram o projeto, pois podem introduzir caminhos alternativos ou comprometer a operação durante uma falha. Uma VLAN rotulada como DMZ, sem fronteiras e regras verificáveis, não entrega esse resultado.
Em instalações industriais, segurança cibernética e continuidade operacional precisam ser analisadas conjuntamente. A perda da DMZ, de um firewall ou de um serviço intermediário deve ter comportamento conhecido e compatível com o processo, sem levar automaticamente à abertura de acessos amplos. FAT e SAT precisam comprovar tanto comunicações permitidas quanto as negadas, autenticação, expiração de acessos, recuperação e impactos da indisponibilidade.
Por fim, uma DMZ só permanece eficaz com governança das mudanças: matriz de fluxos atualizada, justificativa das permissões, rastreabilidade, responsáveis, controle de versões e documentação As-Built. O produto final da engenharia é uma fronteira de segurança projetada, ensaiada e sustentável, capaz de permitir as integrações autorizadas sem transformar a TI em caminho livre até os sistemas operacionais.
Por Eng. Altair Andrade Galvão — Diretor de Engenharia e Projetos, A3A Engenharia.
Referências técnicas
[1] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security. 2023. Disponível em: https://csrc.nist.gov/pubs/sp/800/82/r3/final.
[2] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST SP 800-41 Rev. 1 — Guidelines on Firewalls and Firewall Policy. 2009. Disponível em: https://csrc.nist.gov/pubs/sp/800/41/r1/final.
[3] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 62443 — Industrial communication networks — Network and system security (família de normas). Disponível em: https://webstore.iec.ch/.
Perguntas frequentes
DMZ é uma zona intermediária que controla conexões entre ambientes de diferentes níveis de confiança, como internet, rede corporativa e redes OT.
Não. VLAN fornece segregação lógica de camada 2; uma DMZ depende de políticas de comunicação, fronteiras filtradas, serviços intermediários e monitoramento.
A DMZ industrial protege integrações com processos físicos e precisa compatibilizar segurança com disponibilidade, latência, segurança funcional e continuidade da produção.
Não existe uma quantidade universal. A arquitetura pode empregar diferentes interfaces e instâncias com controle adequado; a decisão depende dos riscos, isolamento e disponibilidade.
Caracterize zonas e fluxos, intermedeie acessos, aplique regras restritivas e serviços apropriados na DMZ e teste conexões autorizadas e negadas.
Não necessariamente. VPN protege o túnel; jump server intermedeia a sessão e ajuda a controlar destino, privilégios e registros de acesso.
É comum utilizar uma réplica ou serviço intermediário na DMZ para consultas corporativas, sem expor diretamente o sistema de controle.
É a documentação de origem, destino, porta, protocolo, finalidade, sentido, proprietário e condição de aprovação para cada comunicação necessária.
Teste comunicações permitidas e negadas, autenticação, sessões de terceiros, falhas, recuperação, logs, impacto operacional e conformidade com a matriz de requisitos.
O NIST SP 800-82 Rev. 3 oferece referência pública de arquitetura e segurança OT. A família IEC 62443 fornece referenciais para zonas, conduítes e requisitos de segurança.
