Revisão de regras de firewall para ISO 27001, NIS2, DORA e GDPR
São 07:42 de uma segunda-feira. O CISO de um fornecedor SaaS e FinTech em crescimento está a olhar para três mensagens distintas.
A primeira vem do SOC. Um posto de trabalho de um programador comprometido tentou ligar-se, durante a noite, a uma sub-rede interna de bases de dados. O tráfego foi bloqueado, mas o analista quer confirmar que a regra de firewall é intencional, atual e aprovada.
A segunda vem de um grande cliente empresarial. O cliente quer evidência de que os ambientes de produção, desenvolvimento, corporativo e suporte estão segmentados, de que as regras de firewall são revistas e de que as exceções expiram.
A terceira vem do gestor de conformidade. A organização tem exposição à NIS2 como prestador digital importante, responsabilidades GDPR como subcontratante e clientes de serviços financeiros a solicitar evidência de gestão do risco das TIC alinhada com o DORA. O conselho de administração quer saber se a mesma evidência ISO/IEC 27001:2022 consegue responder às três exigências.
Depois chega a revisão pós-incidente. Um servidor de desenvolvimento esteve quase exposto à Internet durante uma alteração feita à noite. Não houve perda de dados de clientes, mas a equipa forense descobriu algo pior do que o erro inicial: uma regra de firewall de “teste temporário”, criada há cinco anos, ainda permitia movimentação ampla entre desenvolvimento e produção. Se um atacante tivesse obtido acesso, a rede teria oferecido pouca resistência.
É nesse momento que muitas organizações descobrem uma verdade desconfortável. Podem ter firewalls, VLAN, grupos de segurança na nuvem e diagramas, mas não têm governação sobre zonas de segmentação, titularidade das regras, acesso temporário, aprovações de alterações, recertificação e evidência de auditoria.
Em 2026, “temos uma firewall” já não é uma resposta defensável. Auditores, reguladores, clientes e seguradoras querem evidência de que as redes estão separadas de forma intencional, de que o tráfego é controlado por necessidade de negócio, de que as exceções de risco são governadas e de que os registos demonstram que os controlos estão a funcionar.
Porque a governação de firewalls é agora uma questão ao nível do conselho de administração
A segmentação de rede costumava ser tratada como um tema técnico de engenharia. As equipas de infraestrutura eram responsáveis pelas VLAN, os administradores de firewall mantinham os conjuntos de regras, as equipas de cloud geriam grupos de segurança e a conformidade via apenas um diagrama durante as auditorias.
Esse modelo operacional deixou de funcionar.
A Diretiva NIS2 exige que entidades essenciais e importantes implementem medidas técnicas, operacionais e organizativas adequadas e proporcionadas para gerir riscos para os sistemas de rede e informação. O Article 21 inclui políticas sobre análise de riscos, tratamento de incidentes, continuidade do negócio, segurança da cadeia de abastecimento, segurança na aquisição e manutenção, avaliação da eficácia, higiene básica de cibersegurança, controlo de acesso e gestão de ativos. Os órgãos de direção devem aprovar e supervisionar essas medidas de gestão de riscos de cibersegurança.
O DORA aplica-se desde 17 de janeiro de 2025 a muitas entidades financeiras e torna a gestão do risco das TIC uma disciplina governada e documentada. Os Articles 5, 6 e 8 exigem governação, um quadro de gestão do risco das TIC e a identificação de funções de negócio suportadas por TIC, ativos de informação, ativos de TIC, dependências, ativos críticos e interligações. Os Articles 9, 10 e 11 tratam de proteção, prevenção, deteção, resposta e recuperação. Os Articles 24 a 27 exigem testes de resiliência operacional digital, incluindo testes avançados para determinadas entidades. Isto torna a segmentação uma questão de resiliência, não apenas uma questão de firewall.
O GDPR acrescenta a camada de responsabilização de privacidade. O Article 32 exige medidas técnicas e organizativas adequadas para assegurar um nível de segurança adequado ao risco, incluindo confidencialidade, integridade, disponibilidade e resiliência. O Article 5(1)(f) exige integridade e confidencialidade, e o Article 5(2) exige responsabilização. Se sistemas com dados pessoais estiverem acessíveis a partir de endpoints comprometidos, redes de convidados ou caminhos de terceiros não geridos, uma autoridade de controlo poderá perguntar por que razão esses caminhos existiam.
A ISO/IEC 27001:2022 fornece a base do sistema de gestão que liga estas obrigações. Exige âmbito, requisitos das partes interessadas, avaliação de riscos, tratamento de riscos, Declaração de Aplicabilidade, planeamento e controlo operacional, responsabilização da liderança, objetivos mensuráveis, informação documentada e melhoria contínua. O Anexo A, suportado pela orientação ISO/IEC 27002:2022, inclui as áreas de controlo necessárias para risco de fornecedores, serviços na nuvem, registo, monitorização, arquitetura segura, separação de ambientes e gestão de alterações.
A conclusão é simples: a segmentação de rede e a revisão de regras de firewall são agora evidência de governação.
O padrão operacional da Clarysec: 8.20, 8.22 e 8.32
A Clarysec trata a segmentação e a revisão de firewalls como um único padrão operacional transversal aos controlos ISO/IEC 27002:2022, e não como tarefas técnicas isoladas.
Os três controlos principais são:
| Área ISO/IEC 27002:2022 | Pergunta de governação | Evidência esperada pelos auditores |
|---|---|---|
| 8.20 Segurança de redes | As redes são concebidas, geridas, monitorizadas e protegidas de acordo com o risco? | Diagramas de arquitetura, normas de firewall, procedimentos de rede segura, registos de monitorização, evidência IDS/IPS, amostras de configuração de VPN e de rede cloud |
| 8.22 Segregação de redes | As zonas estão separadas por sensibilidade, função e nível de confiança? | Modelo de zonas, matriz de fluxos de dados, desenho de VLAN e sub-redes, perímetros de DMZ, regras de firewall entre zonas, resultados de testes de segmentação |
| 8.32 Gestão de alterações | As alterações às regras são avaliadas, aprovadas, testadas, registadas e revistas? | Tickets de alteração, avaliações de risco, aprovações, planos de reversão, revisões pós-implementação, registos de alterações de emergência |
Em Zenith Blueprint: An Auditor’s 30-Step Roadmap [ZB], a Clarysec posiciona a segurança de redes na fase Controls in Action, Step 20: Controls 8.18 to 8.26. O guia enquadra claramente a pergunta central de auditoria:
“No essencial, este controlo exige que as organizações assegurem que as redes são seguras por arquitetura, e não apenas por adicionarem firewalls ou antivírus mais tarde. Isso significa pensar estrategicamente sobre segmentação de rede, controlo de acesso, cifragem em trânsito, monitorização e defesa em profundidade. Começa com uma pergunta simples: quem e o quê estão a comunicar, e deveriam estar?”
Essa pergunta — “quem e o quê estão a comunicar, e deveriam estar?” — é o melhor ponto de partida prático para a revisão de regras de firewall. Afasta a conversa de milhares de entradas ACL crípticas e aproxima-a de fluxos justificados pelo negócio.
O mesmo Zenith Blueprint orienta as equipas a avaliar a arquitetura de rede verificando se as regras de firewall, IPS/IDS e configurações de acesso remoto estão atuais e reforçadas, e a confirmar se grupos de segurança cloud, encaminhamento e regras de VPC ou sub-redes correspondem à arquitetura pretendida. Também indica aos auditores que devem esperar um Documento de Arquitetura de Segurança de Rede que mostre firewalls, gateways VPN, zonas DMZ, separação por VLAN e limites de confiança.
Para gestão de alterações, o Zenith Blueprint posiciona o controlo ISO/IEC 27002:2022 8.32 na fase Controls in Action, Step 21: Controls 8.27 to 8.34, e destaca por que motivo a governação de firewalls falha quando o controlo de alterações é fraco:
“Este controlo reconhece uma verdade dura em TI: muitos incidentes não são causados por ataques, mas por alterações mal geridas. Uma regra de firewall demasiado aberta. Uma definição de depuração deixada ativa. Uma dependência esquecida após uma migração.”
É exatamente assim que aberturas temporárias na firewall se tornam caminhos de ataque permanentes.
Como é uma boa segmentação de rede
Um programa maduro de segmentação tem quatro camadas.
Em primeiro lugar, tem um modelo de zonas. As zonas não são sub-redes arbitrárias. São limites de confiança alinhados com a função de negócio e a sensibilidade dos dados, como DMZ exposta à Internet, camada aplicacional de produção, camada de bases de dados de produção, rede de utilizadores corporativos, rede de gestão privilegiada, ambiente de desenvolvimento, ambiente de teste, rede de cópias de segurança, Wi‑Fi de convidados, zona OT ou IoT e zona de acesso de terceiros.
Em segundo lugar, tem uma matriz de fluxos. Para cada par de zonas, a organização documenta origem, destino, protocolo, porta, aplicação, responsável de negócio, proprietário do sistema, tipo de dados, justificação e requisito de registo permitidos.
Em terceiro lugar, tem titularidade das regras. Cada regra de firewall, regra de grupo de segurança cloud ou política de perímetro definido por software tem um proprietário, uma data de expiração ou recertificação, um ticket de alteração associado e uma justificação de negócio. “Any to any” deve ser tratado como uma constatação, salvo se estiver formalmente sujeito a aceitação do risco, limitado no tempo e suportado por controlos compensatórios.
Em quarto lugar, tem revisão recorrente. Revisão significa mais do que exportar uma base de regras de firewall uma vez por ano. Inclui recertificação pelo proprietário, comparação com tráfego observado, deteção de regras não utilizadas, validação de exceções temporárias, revisão da exposição à Internet, testes de segmentação e reconciliação com o inventário de ativos.
A Política de Segurança de Redes [P-NS] da Clarysec define claramente a expectativa empresarial:
“Todo o tráfego entre zonas deve ser controlado por firewalls ou por soluções de perímetro definido por software, com configurações explícitas de negação por defeito.”
Da Política Empresarial, Política de Segurança de Redes, secção “Requisitos de governação”, cláusula 5.2.
A mesma política liga diretamente as alterações de firewall à gestão de alterações:
“Qualquer alteração a conjuntos de regras de firewall, tabelas de encaminhamento ou configurações de grupos de segurança deve seguir a Política de gestão de alterações (P5) da organização, incluindo planos de reversão e registo para trilho de auditoria.”
Da Política Empresarial, Política de Segurança de Redes, secção “Requisitos de governação”, cláusula 5.4.
Para PME, a Network Security Policy-sme [P-NS-SME] da Clarysec apresenta o mesmo princípio em termos operacionais:
“As regras de negação por defeito devem ser aplicadas a todas as ligações de entrada, salvo quando forem explicitamente necessárias e aprovadas.”
Da Política PME, Network Security Policy-sme, secção “Requisitos de implementação da política”, cláusula 6.1.2.
E, especificamente para segmentação:
“O tráfego entre segmentos deve ser filtrado, e o acesso entre segmentos deve seguir o princípio do menor privilégio.”
Da Política PME, Network Security Policy-sme, secção “Requisitos de implementação da política”, cláusula 6.2.3.
Estas cláusulas de política permitem que um auditor trace o percurso do risco ao controlo, do controlo à regra, da regra à aprovação e da aprovação aos registos.
Um único pacote de evidência para ISO 27001, NIS2, DORA e GDPR
O erro que muitas equipas cometem é criar pacotes de evidência separados: um para ISO/IEC 27001:2022, um para NIS2, um para GDPR, um para clientes DORA e um para seguro cibernético.
Uma abordagem melhor é construir um único pacote de evidência de segmentação e governação de firewalls, mapeado entre referenciais.
Zenith Controls: The Cross-Compliance Guide [ZC] mapeia o controlo ISO/IEC 27002:2022 8.22 Segregação de redes como um controlo preventivo que suporta confidencialidade, integridade e disponibilidade, alinhado com o conceito de cibersegurança Protect e com a capacidade operacional de segurança de sistemas e redes. Liga o 8.22 ao 8.20 Segurança de redes, 8.21 Segurança dos serviços de rede, 8.7 Proteção contra malware, 8.27 Princípios de arquitetura e engenharia de sistemas seguros e 8.31 Separação de ambientes de desenvolvimento, teste e produção.
O guia explica a relevância da segmentação para a NIS2 da seguinte forma:
“A segregação de redes é uma resposta direta a estas obrigações, reduzindo superfícies de ataque e prevenindo movimentação lateral entre sistemas em rede.”
Esta frase explica por que razão os programas de higiene básica de cibersegurança NIS2 não devem tratar a segmentação como opcional. A contenção de ransomware não depende apenas da proteção de endpoint. Depende de limitar a movimentação lateral quando a prevenção falha.
Para o GDPR, o Zenith Controls mapeia o 8.22 para o Article 32 e o Recital 49, assinalando que diagramas de rede e políticas de zonas se tornam evidência-chave de conformidade. Para o DORA, o Zenith Controls mapeia a segurança de redes e a segregação para a gestão do risco das TIC e a contenção de incidentes. Os testes de segmentação podem suportar evidência de resiliência TIC, especialmente quando demonstram que o comprometimento de uma zona não consegue mover-se livremente para serviços financeiros críticos, repositórios de dados pessoais ou sistemas de gestão privilegiada.
| Artefacto de evidência | Utilização em ISO/IEC 27001:2022 e ISO/IEC 27002:2022 | Utilização NIS2 | Utilização DORA | Utilização GDPR |
|---|---|---|---|---|
| Documento de Arquitetura de Segurança de Rede | Suporta o âmbito do SGSI, o controlo operacional, 8.20 e 8.22 | Demonstra medidas técnicas para a segurança dos sistemas de rede e informação | Demonstra interligações TIC e dependências de serviços críticos | Demonstra perímetros de proteção em torno de sistemas com dados pessoais |
| Matriz de zonas e fluxos | Demonstra segregação baseada no risco e princípio do menor privilégio | Suporta higiene de cibersegurança e avaliação da eficácia | Suporta a classificação de ativos TIC e dependências | Suporta medidas técnicas do Article 32 e responsabilização |
| Registos de revisão de regras de firewall | Evidência de monitorização de controlos e melhoria contínua | Demonstra que as medidas são revistas e não estáticas | Suporta revisão de riscos TIC e testes de resiliência | Demonstra segurança contínua do tratamento |
| Tickets de alteração para regras de firewall | Suportam a 8.32 Gestão de alterações | Suportam manutenção segura e rastreabilidade | Suportam alteração TIC controlada e resiliência | Demonstram que alterações que afetam sistemas com dados pessoais são sujeitas a avaliação de risco |
| Registo de Exceções | Suporta tratamento de riscos e aceitação do risco residual | Demonstra supervisão da gestão sobre desvios | Suporta tolerância ao risco e governação | Demonstra responsabilização por exposição temporária |
| Registos de tráfego entre zonas bloqueado e permitido | Suportam registo, monitorização e eficácia dos controlos | Suportam deteção e resposta a incidentes | Suportam classificação de incidentes e reporte | Suportam avaliação de violação e preservação de evidência |
Esta tabela não é apenas um mapeamento de conformidade. É um roteiro para a recolha de evidência.
A revisão de regras de firewall que funciona na prática
Uma revisão de regras de firewall falha quando pergunta apenas: “Esta regra ainda é necessária?” Os proprietários das regras respondem frequentemente que sim, porque receiam quebrar alguma coisa.
Uma revisão melhor coloca seis perguntas:
- Que serviço de negócio esta regra suporta?
- Que proprietário do ativo e proprietário dos dados aprovaram o fluxo?
- O destino está na zona correta para os dados e a função?
- A regra é mais permissiva do que o tráfego observado exige?
- O registo está ativado para fluxos de alto risco?
- A regra tem data de revisão, data de expiração ou registo de exceção?
A Network Security Policy-sme exige revisão periódica:
“O prestador de suporte de TI deve realizar uma revisão anual das regras de firewall, da arquitetura de rede e das configurações sem fios.”
Da Política PME, Network Security Policy-sme, secção “Requisitos de governação”, cláusula 5.6.1.
A revisão anual é a linha de base, não o limite máximo. Regras de alto risco precisam de recertificação mais frequente.
| Categoria da regra | Exemplo | Frequência de revisão | Expectativa de aprovação |
|---|---|---|---|
| Entrada da Internet para produção | API pública para gateway aplicacional | Trimestralmente ou após lançamento de maior impacto | Proprietário do serviço, segurança, aprovador da alteração |
| Acesso entre zonas a base de dados de produção | Camada aplicacional para camada de base de dados | Trimestralmente | Proprietário da aplicação e proprietário dos dados |
| Acesso administrativo | Servidor de salto para portas de gestão de servidores | Mensal ou trimestral | Proprietário da infraestrutura e delegado do CISO |
| Acesso de terceiros | VPN do fornecedor para sub-rede de suporte | Mensal ou por marco contratual | Proprietário do fornecedor e segurança |
| Exceção temporária | Acesso de emergência durante migração | Antes da expiração, máximo 90 dias | Gestor do SGSI ou CISO |
| Regra interna padrão de baixo risco | Servidor de monitorização para endpoints geridos | Anual | Proprietário do serviço |
A Política de Segurança de Redes é explícita sobre exceções:
“O pedido deve ser revisto e aprovado pelo Gestor do SGSI ou pelo CISO e registado no Registo de Exceções do SGSI, com um período máximo de aprovação de 90 dias, renovável mediante reavaliação.”
Da Política Empresarial, Política de Segurança de Redes, secção “Tratamento do risco e exceções”, cláusula 7.3.
Para PME, a Network Security Policy-sme exige que os pedidos de exceção incluam os factos mínimos corretos:
“O pedido deve incluir a justificação, o âmbito, a duração e os controlos compensatórios (por exemplo, lista de permissões de IP, registo).”
Da Política PME, Network Security Policy-sme, secção “Tratamento do risco e exceções”, cláusula 7.3.3.
Essa cláusula transforma o tratamento de exceções de conversa informal em tratamento de riscos auditável.
Exemplo prático: remover uma regra de base de dados de produção de risco
Suponha que uma empresa encontra a seguinte regra durante a revisão:
| Campo | Valor atual |
|---|---|
| Origem | VLAN de utilizadores corporativos |
| Destino | Sub-rede de base de dados de produção |
| Porta | TCP 5432 |
| Ação | Permitir |
| Comentário | Acesso temporário para migração de relatórios |
| Criada | Há 14 meses |
| Proprietário | Desconhecido |
| Registo | Desativado |
Esta é uma constatação de auditoria clássica. Viola o princípio do menor privilégio, não tem proprietário claro, não tem expiração, não tem justificação atual e não tem registo. Também cria uma exposição GDPR Article 32 se a base de dados de produção contiver dados pessoais de clientes.
O processo de remediação deve criar evidência, não apenas remover uma regra inadequada.
| Passo | Ação | Referência Clarysec | Evidência de auditoria criada |
|---|---|---|---|
| 1. Mapear a regra para o modelo de zonas | Confirmar se utilizadores corporativos devem alguma vez chegar à sub-rede de base de dados de produção | Zenith Blueprint, Controls in Action Step 20 | Notas atualizadas de revisão da arquitetura e classificação de zonas |
| 2. Criar ou atualizar o registo de fluxo | Documentar origem, destino, porta, tipo de dados, proprietário, justificação e risco | Zenith Controls, mapeamento 8.22 | Entrada na matriz de zonas e fluxos |
| 3. Abrir um ticket de alteração | Propor a remoção ou substituição por um caminho controlado de serviço de relatórios | Política de Segurança de Redes, cláusula 5.4 | Registo de alteração com análise de riscos, plano de testes e plano de reversão |
| 4. Decidir o tratamento | Remover a regra ampla ou substituí-la por réplica só de leitura, bastião, lista de permissões de IP e registo | Política de Segurança de Redes, cláusula 7.3 | Decisão de tratamento de riscos ou exceção limitada no tempo |
| 5. Ativar o registo para fluxos aprovados | Enviar eventos de firewall entre zonas de alto risco para monitorização | Política de registo e monitorização, cláusula 6.1.1.6 | Registos SIEM, regras de alerta e capturas de ecrã de monitorização |
| 6. Validar a segmentação | Testar que a sub-rede de base de dados está inacessível exceto através de caminhos aprovados | Zenith Blueprint, Step 20 | Resultado do teste de segmentação e encerramento da remediação |
A Política de registo e monitorização [P-LM] da Clarysec inclui comunicações externas e acionamentos de regras de firewall como eventos relevantes para registo:
“Comunicações externas e acionamentos de regras de firewall.”
Da Política Empresarial, Política de registo e monitorização, secção “Requisitos de implementação da política”, cláusula 6.1.1.6.
Para regras entre zonas de alto risco, os acionamentos de firewall devem alimentar o SIEM ou a plataforma de monitorização, com alertas para hosts de origem, volumes ou janelas temporais invulgares.
A política PME também exige disciplina de alteração:
“Todas as alterações a configurações de rede (regras de firewall, ACLs de switches, tabelas de encaminhamento) devem seguir um processo de gestão de alterações documentado.”
Da Política PME, Network Security Policy-sme, secção “Requisitos de implementação da política”, cláusula 6.9.1.
Uma única limpeza desta regra cria evidência para controlo operacional ISO/IEC 27001:2022, ISO/IEC 27002:2022 8.20, 8.22 e 8.32, higiene básica de cibersegurança NIS2, GDPR Article 32 e gestão do risco das TIC alinhada com o DORA.
Redes cloud, SaaS e híbridas devem ser incluídas
A segmentação moderna não se limita a VLAN e firewalls físicas. Inclui grupos de segurança AWS, grupos de segurança de rede Azure, políticas de rede Kubernetes, tabelas de encaminhamento cloud, listas de permissões administrativas SaaS, endpoints privados, VPN, SD-WAN, proxies sensíveis à identidade e controlos de perímetro definido por software.
Para um fornecedor SaaS ou serviço digital regulado, a revisão de regras de firewall deve incluir, pelo menos:
- Balanceadores de carga e gateways aplicacionais expostos à Internet
- Grupos de segurança cloud e ACLs de rede
- Tabelas de encaminhamento de sub-redes privadas
- Caminhos de peering e transit gateway
- Caminhos de VPN e administração remota
- Interfaces administrativas e planos de gestão
- Ingress Kubernetes e políticas de rede
- Acesso de runners CI/CD à produção
- Cobertura de registos para fluxos de alto risco negados e permitidos
- Acesso de suporte de terceiros e caminhos break-glass
Se um grupo de segurança cloud permitir tráfego de base de dados de entrada a partir de um intervalo amplo de IP corporativos, trate-o como uma regra de firewall. Precisa de proprietário, justificação, aprovação, revisão, registo e expiração.
É também aqui que normas ISO de suporte reforçam a narrativa. A ISO/IEC 27017 apoia a clareza sobre responsabilidades de segurança cloud. A ISO/IEC 27033 fornece orientação mais aprofundada sobre arquitetura de segurança de rede, DMZ, zonas de segmentação, filtragem de tráfego e comunicações seguras entre redes. A ISO/IEC 27701 reforça a governação de privacidade quando informações pessoais identificáveis (PII) circulam entre redes. A ISO/IEC 27035 suporta a contenção de incidentes, e a ISO/IEC 27005 suporta a seleção da segmentação como tratamento de riscos para acesso não autorizado, propagação de malware e movimentação lateral.
Como os auditores testam o mesmo controlo de formas diferentes
Uma das forças do Zenith Controls é explicar como diferentes metodologias de auditoria examinam o mesmo controlo. A evidência pode ser reutilizada, mas as perguntas diferem.
| Perspetiva de auditoria | Pergunta provável | Melhor evidência |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | A segmentação é selecionada, implementada e revista com base no risco? | Avaliação de riscos, SoA, política de rede, diagramas, registos de revisão |
| Auditor ao estilo ISO/IEC 27007 | As regras de firewall implementadas e os esquemas de VLAN correspondem à política documentada? | Amostras de regras de firewall, ACLs de routers, desenho de VLAN, entrevistas a administradores |
| Abordagem de auditoria de certificação ISO/IEC 27006-1:2024 | Os perímetros críticos de rede são auditados com competência adequada e planeamento baseado no risco? | Plano de auditoria, amostragem técnica, evidência de grupos de segurança cloud, resultados de testes |
| Auditor orientado por NIST | Os perímetros e fluxos de informação são aplicados e monitorizados? | Regras de firewall, ACLs, testes de segmentação, registos de monitorização |
| Auditor COBIT 2019 | A segurança de redes é governada, monitorizada e reportada? | Matriz de titularidade, KPIs, reporte à gestão, Registo de Riscos |
| Auditor ISACA ITAF | Os controlos gerais de TI funcionam de forma consistente? | Tickets de alteração, aprovações de exceções, registos, amostras de recertificação de regras |
| Autoridade de controlo GDPR | Os sistemas com dados pessoais estavam protegidos por medidas técnicas adequadas? | Mapas de fluxo de dados, isolamento de zonas PII, caminhos de acesso, registos de firewall |
| Avaliador focado em DORA | A segmentação suporta a resiliência TIC e a contenção de incidentes? | Mapa de dependências de ativos TIC, fluxos de funções críticas, playbooks de incidentes, registos de testes |
Um avaliador focado em DORA pode perguntar se um comprometimento num gateway de pagamentos consegue pivotar para bases de dados de clientes. Uma autoridade competente NIS2 pode perguntar se ransomware num posto de trabalho administrativo consegue chegar a sistemas core de prestação do serviço. Uma autoridade GDPR pode perguntar que restrições ao nível da rede protegiam sistemas que tratam dados pessoais. Um auditor ISO pode simplesmente pedir a avaliação de riscos, a SoA, a política, o procedimento e a evidência de que as revisões ocorreram.
Os melhores programas respondem a todas estas perguntas com os mesmos artefactos.
Métricas que tornam a segmentação visível para a liderança
Tanto a NIS2 como o DORA reforçam a responsabilização da gestão. A ISO/IEC 27001:2022 exige liderança, objetivos, papéis, recursos, reporte e melhoria contínua. Isto significa que a segmentação precisa de métricas que a liderança consiga compreender.
Métricas de gestão úteis incluem:
- Percentagem de regras de firewall com proprietário atribuído
- Percentagem de regras com justificação de negócio documentada
- Número de regras temporárias expiradas
- Número de regras com origem, destino ou serviço “any”
- Número de serviços expostos à Internet por criticidade
- Percentagem de fluxos entre zonas de alto risco com registo ativado
- Número de alterações de firewall de emergência por trimestre
- Percentagem de regras amostradas associadas a tickets de alteração aprovados
- Número de falhas em testes de segmentação
- Tempo médio de remediação de regras de risco ou não utilizadas
- Número de exceções com mais de 90 dias
- Número de regras de acesso de terceiros revistas e recertificadas
A Política de Segurança de Redes identifica “eficácia das regras de firewall” como uma consideração de conformidade e aplicação na secção “Aplicação e cumprimento”, cláusula 8.2.2. Esta expressão é importante porque a existência de regras não basta. As regras devem ser eficazes, revistas e alinhadas com o risco atual.
Construir o pacote de evidência de segmentação para 2026
Um pacote prático de evidência de segmentação e revisão de regras de firewall deve estar pronto antes de o auditor o solicitar.
No mínimo, mantenha:
- Diagrama atual da arquitetura de rede, incluindo zonas cloud e híbridas
- Norma de classificação de zonas, incluindo sensibilidade e nível de confiança
- Matriz de fluxos para serviços críticos e sistemas com dados pessoais
- Exportação de regras de firewall e de grupos de segurança cloud
- Registo de proprietários de regras e recertificação
- Procedimento de revisão de firewall e calendário de revisão
- Registos de alteração para modificações de firewall amostradas
- Registo de Exceções com aprovações, expiração e controlos compensatórios
- Resultados de testes de segmentação e registos de remediação
- Evidência de registo e monitorização para fluxos de alto risco
- Playbooks de incidentes que demonstram contenção por zona
- Métricas de reporte à gestão e atas de reunião
Mapeie esta evidência para as cláusulas ISO/IEC 27001:2022 e áreas de controlo do Anexo A. Em seguida, cruze-a com NIS2 Article 21, GDPR Article 32, requisitos de gestão do risco das TIC e de testes do DORA, resultados do NIST CSF 2.0 como GOVERN, PROTECT, DETECT e RESPOND, e práticas de governação COBIT.
O NIST CSF 2.0 é especialmente útil como camada de comunicação com o conselho de administração. A sua função GOVERN centra-se em requisitos legais, regulamentares e contratuais, apetite ao risco, papéis, políticas e supervisão. Os seus resultados operacionais abordam gestão da configuração, registo, monitorização, proteção de dados, resposta a incidentes e recuperação. Isto ajuda a liderança a compreender o risco sem ler ACLs de firewall.
Constatações comuns que a Clarysec observa em auditorias de segmentação
Em SaaS, fintech, prestadores de serviços geridos e PME reguladas, as mesmas constatações surgem repetidamente:
- Rede plana entre endpoints de utilizadores e serviços de produção
- Bases de dados de produção acessíveis a partir de redes de desenvolvimento ou corporativas
- Grupos de segurança cloud amplos copiados de modelos antigos
- Regras temporárias de fornecedores sem expiração
- Alterações de firewall realizadas fora do processo de alteração
- Regras sem proprietário ou justificação de negócio
- Registo desativado em regras permissivas de alto risco
- Wi‑Fi de convidados sem isolamento completo
- Interfaces administrativas acessíveis a partir de redes gerais
- Diagramas que não correspondem ao encaminhamento real
- Ausência de evidência de que as revisões de regras foram concluídas
- Ausência de testes de segmentação após alterações de maior impacto na arquitetura
- Ausência de mapeamento entre sistemas com dados pessoais e zonas de rede
- Ausência de reporte à gestão sobre exposição de rede
Estas constatações não são apenas fragilidades técnicas. Comprometem a capacidade da organização de demonstrar higiene básica de cibersegurança NIS2, resiliência operacional DORA e responsabilização GDPR Article 32.
Da limpeza reativa ao controlo defensável
A segmentação de rede e a revisão de regras de firewall são o ponto em que a arquitetura de segurança encontra a realidade da auditoria. Se conseguir demonstrar um modelo de zonas baseado no risco, fluxos controlados entre zonas, alterações de firewall aprovadas, exceções limitadas no tempo, evidência de registo e validação periódica, consegue responder a uma ampla gama de questões ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST e COBIT com uma narrativa coerente.
A Clarysec pode ajudá-lo a construir essa narrativa.
Use Zenith Blueprint: An Auditor’s 30-Step Roadmap para estruturar o percurso de implementação, em especial Controls in Action Step 20 para segurança de redes e segmentação, e Step 21 para gestão de alterações. Use Zenith Controls: The Cross-Compliance Guide para mapear os controlos ISO/IEC 27002:2022 8.20, 8.22 e 8.32 entre expectativas de auditoria NIS2, DORA, GDPR, NIST e COBIT. Ancore as suas regras operacionais na Política de Segurança de Redes, na Network Security Policy-sme e na Política de registo e monitorização da Clarysec.
O próximo passo é simples e de elevado valor: selecione um serviço crítico, como produção de clientes, processamento de pagamentos ou gestão de identidades, e realize esta semana uma revisão por amostragem de 10 regras. Para cada regra, confirme proprietário, justificação, origem, destino, porta, registo, ticket de alteração e expiração. Se não conseguir demonstrar estes sete factos, tem o ponto de partida para o seu plano de melhoria de segmentação de 2026.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
