Documentar regras da Sophos Firewall

As regras de firewall tornam-se rapidamente difíceis de acompanhar. No início, cada regra parece lógica: um servidor precisa de acesso à Internet, um serviço é publicado, uma VPN precisa de acesso ou uma aplicação requer portas específicas. Meses depois, muitas vezes já ninguém sabe porque a regra existe, quem a pediu e se ainda é necessária.

A contramedida mais simples não é uma grande CMDB, mas uma descrição limpa diretamente na regra da Sophos Firewall. Alguns dados consistentes já ajudam em troubleshooting, auditorias, limpezas e passagens de responsabilidade.

Para a estrutura de uma regra, Compreender e configurar corretamente regras da Sophos Firewall é o artigo base. Depois de guardar uma regra, Testar uma regra da Sophos Firewall com Log Viewer e Packet Capture é útil.

Porque A Documentação Das Regras É Importante

Uma regra de firewall não é apenas uma autorização técnica. É uma decisão operacional: quem pode aceder a quê, através de que serviço, com que risco e por que motivo?

Sem documentação surgem problemas típicos:

• Regras antigas continuam ativas porque ninguém conhece o objetivo.
• Regras de teste nunca são removidas.
• Auditorias demoram demasiado tempo.
• Incidentes demoram mais porque o owner da aplicação não é claro.
• Alterações são feitas diretamente na firewall, mas não ficam documentadas.
• Regras não são limpas por receio de efeitos colaterais.

Uma boa descrição não evita todos estes problemas, mas reduz claramente a fricção na operação diária.

Onde Inserir A Descrição

O campo Description encontra-se diretamente na regra de firewall. A regra é aberta em:

Rules and policies > Firewall rules

Depois, editar a regra em questão e preencher o campo de descrição.

O campo é limitado. Por isso, não deve substituir toda a documentação técnica, mas sim tornar visíveis as informações operacionais mais importantes diretamente na firewall. Os detalhes podem ficar num ticket, wiki, change request ou pasta de projeto.

O Que Deve Constar Na Descrição Da Regra

Source, Destination, Services, NAT e Security Features já são visíveis na regra. A descrição não deve repetir tudo, mas explicar o que mais tarde já não será evidente.

Informações úteis:

• Objetivo: Porque existe a regra?
• Aplicação / serviço: Que aplicação ou processo precisa da regra?
• Owner: Quem é responsável?
• Ticket / change: Onde está documentada a alteração?
• Criador / editor: Quem criou ou alterou a regra?
• Data: Quando foi criada ou revista pela última vez?
• Review: Quando deve ser revista ou removida?
• Particularidade: Exceção, desvio ou risco assumido.

Nem todas as regras precisam de todos os campos. Para uma regra standard de clientes, muitas vezes basta menos. DNAT, VPN, management, acessos de parceiros ou exceções temporárias devem ser descritos com mais precisão.

Combinar Nome E Description

O nome da regra deve ser curto e estruturado. A Description explica o contexto. Não existe um esquema perfeito para todas as empresas. O importante é que um administrador consiga perceber aproximadamente o que a regra faz ao percorrer a base de regras, sem abrir cada regra individualmente.

Na prática, três abordagens funcionam bem:

• Origem, destino, serviço: VLAN12_WAN_HTTPS. Boa variante standard para regras de clientes, servidores e VPN.
• Aplicação, origem, destino: ERP_VPNUSERS_SRVERP_HTTPS. Útil quando a aplicação é mais importante do que o segmento de rede.
• Tipo de regra como prefixo: DNAT_WAN_SRVWEB01_HTTPS. Útil em DNAT, regras Drop, regras temporárias ou casos especiais.

Usamos frequentemente o padrão SOURCE_DESTINATION_PORT, porque continua técnico e legível mesmo meses depois. A ação não precisa necessariamente de estar no nome, porque a Sophos Firewall já mostra Accept, Drop ou Reject na regra.

Exemplos típicos:

• VLAN12_WAN_HTTPS
• VLAN20_WAN_DNS
• VLANGUEST_WAN_WEB
• SRVEXC01_WAN_SMTP
• WSTONY01_SRVFILE_SMB
• VPNUSERS_SRVERP_HTTPS
• ADMINNET_FIREWALL_HTTPS
• DNAT_WAN_SRVWEB01_HTTPS
• DNAT_WAN_SRVDMS01_TCP5555
• DROP_VLANIOT_INTERNAL_ANY

Consoante o ambiente, o esquema pode ser ligeiramente alargado:

• ZONE_SOURCE_DESTINATION_PORT, por exemplo LAN_VLAN12_WAN_HTTPS
• APP_SOURCE_DESTINATION_PORT, por exemplo ERP_VPNUSERS_SRVERP_HTTPS
• CHANGE_SOURCE_DESTINATION_PORT, por exemplo CHG1842_VPNUSERS_SRVERP_HTTPS

Em ambientes pequenos, um padrão simples costuma ser suficiente. Em ambientes maiores com muitos VLANs, VPNs, redes de servidores e regras DNAT, um standard consistente torna-se muito mais valioso. Prefixos como DNAT, DROP ou TEMP fazem sentido quando ajudam a percorrer rapidamente as regras ou indicam um tipo especial de regra.

Devem evitar-se nomes demasiado genéricos, porque mais tarde já não permitem deduzir nada:

• Rule1
• Test
• Allow
• Internet
• Temp

Exemplo Compacto

Exemplo de uma regra em produção:

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

Se houver pouco espaço, pode ser mais curto. O objetivo, owner e ticket devem continuar reconhecíveis:

ERP VPN access, Owner Finance, CHG-1842, Review 2026-12

Para uma regra temporária, a data de expiração deve ser especialmente clara:

Temp vendor access para migração, Owner IT, CHG-1910, remove after 2026-07-31

O Que Não Deve Ser Escrito Na Description

O campo Description não deve conter:

• palavras-passe,
• chaves API,
• dados pessoais sem motivo,
• dados confidenciais de clientes,
• instruções completas de acesso para terceiros,
• URLs externos longos sem contexto interno.

Quando há prestadores externos envolvidos, normalmente basta uma pessoa de contacto interna, um ticket ou uma referência de documentação. Detalhes sensíveis pertencem a um sistema adequado de tickets, documentação ou palavras-passe, não a uma regra de firewall.

Review E Limpeza

A descrição da regra é apenas o primeiro passo. O essencial é rever as regras regularmente.

Procedimento prático:

1. Marcar regras sem Description.
2. Verificar regras com Test, Temp, Allow any ou nomes pouco claros.
3. Analisar Usage Counter e Log Viewer.
4. Procurar owner ou ticket.
5. Desativar regras que já não são necessárias, observar e remover mais tarde.
6. Documentar a alteração.

Em cada limpeza, Log firewall traffic deve estar ativo nas regras relevantes, para que o Log Viewer mostre se a regra ainda é usada. Para testes depois de alterações, usar Testar uma regra da Sophos Firewall com Log Viewer e Packet Capture.

Standard Mínimo Para Novas Regras

As novas regras da Sophos Firewall devem ter pelo menos:

• um nome claro,
• Source e Destination claros em vez de Any desnecessário,
• logging ativo em regras importantes,
• uma Description com objetivo, owner e ticket,
• uma data de review para regras temporárias ou de risco,
• nenhum segredo no campo de descrição,
• um teste após guardar.

Para servidores publicados, Publicar um servidor com DNAT na Sophos Firewall também é relevante. Para fundamentos de NAT, consultar Compreender NAT na Sophos Firewall: SNAT, DNAT, MASQ, PAT.

FAQ