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 permite uma limpeza fiável. Para isso, também são necessários a Rule ID, logging, dados de utilização, a 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. Um grupo não pode ficar vazio. Para deslocar uma regra para além dos limites do grupo, é necessário separá-la primeiro com Detach ou mover o grupo inteiro. Por isso, depois de criar, clonar ou gerar automaticamente regras, é necessário verificar a Rule position efetiva.

Quem gere regras através da API deve respeitar alguns limites fixos no SFOS 22. Um Rule name pode ter, no máximo, 60 carateres e não pode conter vírgulas. Para Rule groups, a API permite 150 carateres no nome, 255 carateres na descrição e um máximo de 200 referências a regras. Estes limites aplicam-se à API. A ajuda atual do WebAdmin não indica um limite de carateres para a Description. Ainda assim, esta deve ser curta para permanecer legível na tabela de regras.

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 de negócio 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

Uma regra DNAT documentada em pormenor pode ter o seguinte formato:

DNAT - Synology HTTPS
---
OWNER: NETOPS
LAST REVIEW: 2027-01-31
SOURCE: PARTNER_NETS
DESTINATION: WAN_Public_IP
SERVICE: TCP 5555 -> TCP 443
COMMENT: Access to Synology DSM only from defined partner networks
DOC: CHG-1842

Este formato apresenta Source, Destination e Service mesmo fora do WebAdmin. No entanto, se alguém alterar a regra, terá também de atualizar a Description. Caso contrário, as duas entram em contradição. Por isso, recomendamos o modelo compacto. Se o Configuration Audit registar as alterações de forma fiável, basta incluir na Description o objetivo, o owner, o ticket e o 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:

PREFIX_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 e DROP indicam a ação, DNAT identifica a regra de firewall de uma publicação e TEMP uma autorização temporária. Neste contexto, DNAT não designa a própria regra NAT. Source, Destination e Service mostram a direção. As abreviaturas devem estar explicadas no 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 retirada de serviç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 retrato momentâneo. Consoante a vista, a ajuda atual da Sophos indica 12 ou 24 horas sem tráfego correspondente. 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, estado de ativação, Source, Destination, Services, Action e Security Profiles. Se necessário, verificar os hosts e serviços utilizados através de Object Usage; o respetivo contador indica dependências da configuração, não o tráfego de uma regra.
Antes de usar More options > Reset data transfer count, registar no change o carimbo de data e hora e a contagem atual. Repor o contador apenas se o período de observação subsequente também abranger ligações pouco frequentes.
Em Reports > Dashboards > Traffic dashboard, verificar em Allowed policies os dados transferidos.
No Log viewer, procurar por Rule ID, origem, destino e serviço.
Confirmar o owner e o ticket face às necessidades comerciais atuais.
Desativar as regras que já não são necessárias numa janela acordada e observá-las. Se o tráfego esperado deixar de funcionar, reativar imediatamente a regra, verificar a sua posição e repetir o teste com a Rule ID esperada.
Documentar a decisão, o teste e a retirada de serviço no change.

A regra desativada só deve ser eliminada quando o período de observação acordado tiver terminado sem incidentes e o owner der a sua aprovação. 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 basta como prova. É possível que Log firewall traffic estivesse desativado, que uma ligação tenha terminado sem um evento Destroy registado ou que os destinos de log não estivessem configurados corretamente. Em System services > Log settings, define-se que logs de firewall são enviados localmente, para o Sophos Central ou para servidores Syslog.

Rastrear a alteração e o seu efeito

A Description explica por que motivo uma regra deve existir. Não mostra quem a alterou efetivamente. No SFOS 22, o Configuration Audit regista o estado anterior e o novo, bem como o carimbo de data e hora, o administrador e o IP de origem. O estado é verificado na Device Console com system configuration-audit show, e não na Advanced Shell. 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 expiração e retirada de serviç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. Consoante a vista, a ajuda atual da Sophos indica que Unused corresponde a 12 ou 24 horas sem tráfego correspondente. Antes de eliminar a regra, são necessários um período de observação representativo, logs, a confirmação do owner e um teste de desativação controlado com possibilidade de reversão.

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 de negócio. 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.