Documentar corretamente regras da Sophos Firewall

Uma regra de firewall não é apenas uma autorização técnica, mas também uma decisão operacional: quem pode aceder a quê, através de que serviço e por que motivo? Sem este contexto, as antigas regras de teste, de parceiros ou de migração permanecem muitas vezes ativas durante anos, porque ninguém consegue avaliar com segurança a sua finalidade.

Por isso, as informações mais importantes devem constar diretamente em Rule name e Description. Um ticket ou uma wiki contém os detalhes; a própria regra apresenta o contexto necessário para a operação diária. No entanto, a descrição por si só não é suficiente para uma limpeza fiável; também são necessários a Rule ID, logging, dados de utilização, confirmação do owner e um período de observação controlado.

Para a estrutura técnica, consulte o artigo de base Compreender e configurar regras da Sophos Firewall em segurança. As instruções seguintes centram-se na nomenclatura, documentação e review.

Onde introduzir a documentação

O caminho é Rules and policies > Firewall rules. Primeiro, selecione IPv4 ou IPv6 e edite uma regra existente ou crie uma nova através de Add firewall rule > New firewall rule.

Nas definições gerais, os seguintes campos são particularmente relevantes para a documentação:

Rule name: nome curto e fácil de identificar para a ligação.
Rule position: posição na lista de regras, que é avaliada de cima para baixo.
Rule group: agrupamento organizacional da regra.
Description: objetivo, owner, ticket, review e exceção deliberada.
Log firewall traffic: gera logs e dados de relatório para as ligações correspondentes.

Regra da Sophos Firewall com campo Description — O campo Description regista o objetivo, o owner, o ticket e a indicação de review diretamente na regra da Sophos Firewall.

Rule group melhora a organização, mas não altera a lógica de avaliação. A Sophos Firewall verifica cada regra de cima para baixo e para na primeira correspondência. Por isso, depois de criar, clonar ou gerar automaticamente regras, é necessário verificar a Rule position efetiva.

O que deve constar na Description

Source, Destination, Services, Action e Security Profiles já estão visíveis na regra. A Description não deve repetir estes campos, mas complementar as informações que, de outro modo, se perderiam mais tarde.

Um standard mínimo adequado à prática inclui:

Objetivo: Que processo comercial ou operacional necessita da autorização?
Owner: Que equipa é responsável pela aplicação e pela decisão?
Change ou ticket: Onde estão registados a aprovação, o teste e os detalhes técnicos?
Review ou data de validade: Quando será a regra novamente revista ou removida?
Exceção: Que desvio ou restrição deliberada deve ser conhecida por um administrador?

Não é necessário manter manualmente o autor e a data da alteração se o Configuration Audit e o processo de change fornecerem estas informações de forma fiável. O nome de uma pessoa na Description fica rapidamente desatualizado; uma equipa permanente ou uma função costuma ser a melhor opção para owner.

Modelo compacto

Para muitas regras, basta uma única linha estruturada:

Objetivo=Acesso-ERP; Owner=APP-TEAM; Change=CHG-1842; Review=2027-01-31

No caso de uma exceção deliberada, acrescente uma indicação curta:

Objetivo=Upload-de-parceiros; Owner=INTEGRATION; Change=CHG-1910; Review=2027-01-31; Exceção=apenas redes de parceiros definidas

Exemplo prático detalhado

Para equipas que utilizam uma convenção mais detalhada, uma regra DNAT documentada pode ter, por exemplo, o seguinte formato:

DNAT - Synology HTTPS
---
AUTHOR: Patrizio
LAST MODIFIED: 24.06.2026 [PP]
SOURCE: WAN_CH, WAN_DE
DESTINATION: WAN_Public_IP
SERVICE: TCP 5555 -> TCP 443
COMMENT: Access to Synology DSM only from defined countries
DOC: https://ticket/CHG-1842

AUTHOR e LAST MODIFIED só são úteis se a equipa mantiver estas informações de forma consistente. Se o Configuration Audit fornecer um histórico fiável, na Description bastam o objetivo, o Owner, o ticket e a Review; o exemplo detalhado pode ficar no change ou no runbook.

A Description é uma indicação, não uma CMDB completa. Protocolos de teste extensos, decisões de arquitetura e instruções de rollback devem ficar no ticket ou runbook associado.

Atribuir nomes consistentes às regras

Um bom nome deve ser compreensível na vista geral das regras sem ser necessário abrir a regra. O esquema não tem de ser igual em todas as empresas, mas deve ser aplicado de forma consistente dentro de cada ambiente.

Por exemplo, o seguinte esquema tem demonstrado bons resultados:

TIPO_ORIGEM_DESTINO_SERVICO

Exemplos:

ALLOW_VLAN12_WAN_HTTPS
ALLOW_VPNUSERS_SRVERP_HTTPS
DNAT_WAN_SRVWEB01_HTTPS
TEMP_PARTNER_SRVAPP_SFTP
DROP_VLANIOT_INTERNAL_ANY

ALLOW, DNAT, TEMP ou DROP facilitam a leitura rápida. Source, Destination e Service tornam visível a direção. As abreviaturas devem ser explicadas num standard interno de nomenclatura; caso contrário, um nome compacto torna-se apenas um novo enigma.

Evite nomes genéricos como Rule1, Test, Allow, Internet ou Temp. Também são inadequados os nomes que contêm apenas um ticket. Embora seja possível procurar CHG-1842, em caso de incidente este identificador não explica a direção nem o serviço.

Acessos temporários e publicados

As regras temporárias precisam de uma data de validade real e de um owner. Um prefixo como TEMP facilita a pesquisa, mas não substitui um processo de desativação. A data deve constar tanto na Description como no sistema de tickets ou de change, para que uma revisão pendente não dependa apenas de uma consulta à firewall.

No caso de servidores publicados, a regra de firewall por si só não é suficiente para a documentação. A regra DNAT, a Firewall Rule ID, o serviço público, o host de destino interno e a aprovação devem ser registados em conjunto no ticket. Na Description da firewall, basta indicar o change e o objetivo; os detalhes de NAT não devem ser duplicados sob a forma de uma segunda configuração em texto difícil de interpretar.

Para a implementação técnica, consulte Publicar um servidor por DNAT na Sophos Firewall e Compreender NAT na Sophos Firewall.

O que não deve constar na Description

A descrição da regra é visível para os administradores e não é um repositório de segredos. Não introduza:

palavras-passe, chaves de API ou tokens,
chaves privadas ou Preshared Keys,
dados pessoais ou dados confidenciais de clientes sem um motivo imperativo,
instruções de acesso completas para pessoas externas,
URLs extensos com parâmetros de sessão, token ou outros parâmetros confidenciais.

Um identificador interno de ticket, como CHG-1842, é suficiente. O link propriamente dito e os detalhes sensíveis permanecem no sistema previsto para esse fim, com controlo de acesso próprio.

Rever regras existentes de forma controlada

A ausência de uma Description indica a necessidade de review, mas não justifica a eliminação imediata. O estado Unused do SFOS também é apenas um indicador de curto prazo: significa que a regra não encontrou tráfego correspondente durante as últimas 24 horas. Tarefas mensais, acessos de emergência ou aplicações sazonais podem continuar a ser legítimos.

Um review seguro é efetuado da seguinte forma:

Marcar regras sem Description, com um nome genérico, TEMP ou uma data de review expirada.
Registar Rule ID, Position, Source, Destination, Services, Action e Security Profiles.
Em More options, selecionar Reset data transfer count, se necessário, e observar um período representativo para a aplicação.
Em Reports > Dashboards > Traffic dashboard, verificar em Allowed policies os dados transferidos.
No Log viewer, procurar por Rule ID, Source, Destination e Service.
Confirmar o owner e o ticket face às necessidades comerciais atuais.
Desativar primeiro as regras que já não são necessárias, observá-las durante o período acordado e só depois eliminá-las.
Documentar a decisão, o teste e a desativação no change.

Um contador a zero não constitui prova se o período de observação tiver sido demasiado curto. Do mesmo modo, a ausência de uma entrada de log não prova nada se Log firewall traffic estiver desativado ou se os destinos de log locais ou externos não estiverem configurados corretamente. Em System services > Log settings, define-se quais os logs de firewall armazenados localmente, enviados para o Sophos Central ou encaminhados para servidores Syslog.

Rastrear a alteração e o seu efeito

A Description explica por que motivo uma regra deve existir. Não prova quem a alterou efetivamente. O SFOS 22 pode registar alterações a regras de firewall através do Configuration Audit, incluindo as configurações anterior e nova, o carimbo de data e hora, o administrador e o IP de origem. O estado é verificado com system configuration-audit show; por predefinição, a função está ativada.

No processo operacional, devem ser combinadas três evidências:

Description e ticket: objetivo, owner, aprovação e review.
Configuration Audit: quem alterou que configuração e quando.
Log Viewer e Reports: que ligações foram efetivamente processadas pela regra.

O artigo Verificar os Audit Trail Logs da Sophos Firewall descreve em maior detalhe o Configuration Audit e a respetiva análise. Depois de cada alteração a uma regra, Testar uma regra de firewall com Log Viewer, Policy Test e Packet Capture mostra se a Rule ID esperada é realmente aplicada.

Standard mínimo para novas regras

Antes de concluir um change, uma nova regra deve cumprir os seguintes requisitos:

Rule name consistente,
Rule position e Rule group verificados deliberadamente,
Source, Destination e Services sem um Any desnecessariamente abrangente,
Description com objetivo, owner, change e review,
Log firewall traffic definido de acordo com as necessidades operacionais e de proteção de dados,
ausência de segredos ou dados pessoais no nome e na Description,
teste funcional com a Rule ID esperada,
processo de validade e desativação para regras temporárias.

FAQ

Que informações devem constar numa regra da Sophos Firewall?

Rule name e Description devem permitir identificar, pelo menos, o objetivo, a equipa responsável, a referência de change e a data de review. Os detalhes técnicos, a aprovação e o rollback permanecem no ticket ou runbook.

O estado Unused significa que uma regra pode ser eliminada?

Não. Unused significa apenas que a regra não encontrou tráfego correspondente durante as últimas 24 horas. Antes de a eliminar, são necessários um período de observação representativo, logs, a confirmação do owner e um teste de desativação controlado.

O contador de dados é suficiente como prova de utilização?

Não. O contador ajuda na observação, mas deve ser avaliado em conjunto com o Log Viewer, os Reports e o processo comercial. As ligações raras ou sazonais podem permanecer sem utilização durante um teste curto.

Devem constar palavras-passe ou dados de acesso na Description?

Não. Segredos, chaves privadas e dados de acesso confidenciais devem ser guardados num sistema próprio com controlo de acesso, e não em regras de firewall.

Qual é a diferença entre Description e Configuration Audit?

A Description documenta o objetivo e a responsabilidade. O Configuration Audit regista a alteração efetiva, incluindo o estado anterior e o novo, o carimbo de data e hora, o administrador e o IP de origem. Ambos são necessários para um review fiável.