Documentare correttamente le regole di Sophos Firewall

Una regola firewall non è soltanto un’autorizzazione tecnica, ma una decisione operativa: chi può accedere a quale destinazione, tramite quale servizio e per quale motivo? Senza questo contesto, vecchie regole di test, per partner o per migrazioni rimangono spesso attive per anni, perché nessuno è più in grado di valutarne con certezza lo scopo.

Le informazioni più importanti devono quindi essere riportate direttamente in Rule name e Description. Un ticket o una wiki contiene i dettagli, mentre la regola stessa mostra il contesto necessario per l’operatività quotidiana. Tuttavia, per una pulizia affidabile la descrizione da sola non basta: servono anche Rule ID, logging, dati di utilizzo, conferma dell’Owner e un periodo di osservazione controllato.

Per la struttura tecnica, l’articolo di base è Comprendere e configurare in modo sicuro le regole di Sophos Firewall. Questa guida si concentra invece su denominazione, documentazione e review.

Dove inserire la documentazione

Il percorso è Rules and policies > Firewall rules. Selezionare prima IPv4 o IPv6, quindi modificare una regola esistente oppure crearne una tramite Add firewall rule > New firewall rule.

Nelle impostazioni generali, i campi particolarmente importanti per la documentazione sono:

• Rule name: nome breve e facilmente leggibile della connessione.
• Rule position: posizione della regola nell’elenco, che viene valutato dall’alto verso il basso.
• Rule group: raggruppamento organizzativo della regola.
• Description: scopo, Owner, ticket, review ed eventuale eccezione consapevole.
• Log firewall traffic: genera log e dati di report per le connessioni corrispondenti.

Rule group migliora la leggibilità, ma non modifica la logica di valutazione. Sophos Firewall controlla le singole regole dall’alto verso il basso e si ferma alla prima corrispondenza. Dopo la creazione di regole nuove, clonate o generate automaticamente, è quindi necessario verificare la Rule position effettiva.

Cosa inserire nella Description

Source, Destination, Services, Action e Security Profile sono già visibili nella regola. La Description non deve ripetere questi campi, ma aggiungere le informazioni che altrimenti andrebbero perse nel tempo.

Uno standard minimo adatto alla pratica comprende:

• Scopo: quale processo aziendale o operativo richiede l’autorizzazione?
• Owner: quale team è responsabile dell’applicazione e della decisione?
• Change o ticket: dove si trovano approvazione, test e dettagli tecnici?
• Review o data di scadenza: quando verrà riesaminata o rimossa la regola?
• Eccezione: quale deviazione o limitazione consapevole deve conoscere un amministratore?

Non è necessario mantenere manualmente autore e data della modifica se Configuration Audit e il processo di change management forniscono queste informazioni in modo affidabile. Il nome di una persona nella Description diventa rapidamente obsoleto; un team o un ruolo stabile è generalmente un Owner migliore.

Modello compatto

Per molte regole è sufficiente una singola riga strutturata:

Scopo=Accesso-ERP; Owner=APP-TEAM; Change=CHG-1842; Review=2027-01-31

In presenza di un’eccezione consapevole, si aggiunge una breve indicazione:

Scopo=Upload-partner; Owner=INTEGRATION; Change=CHG-1910; Review=2027-01-31; Eccezione=solo reti partner definite

Esempio pratico dettagliato

Per i team che adottano una convenzione più dettagliata, una regola DNAT documentata può essere strutturata ad esempio così:

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 sono utili solo se il team li mantiene con costanza. Se Configuration Audit fornisce uno storico affidabile, nella Description sono sufficienti scopo, Owner, ticket e Review; l’esempio dettagliato può rimanere nel change o nel runbook.

La Description è un riferimento, non una CMDB completa. Verbali di test estesi, decisioni architetturali e istruzioni di rollback devono rimanere nel ticket o nel runbook collegato.

Assegnare nomi coerenti alle regole

Un buon nome è comprensibile nell’elenco delle regole senza dover aprire la regola stessa. Lo schema non deve essere uguale in ogni azienda, ma deve rimanere coerente all’interno dello stesso ambiente.

Ad esempio, ha dato buoni risultati lo schema:

TIPO_ORIGINE_DESTINAZIONE_SERVIZIO

Esempi:

• ALLOW_VLAN12_WAN_HTTPS
• ALLOW_VPNUSERS_SRVERP_HTTPS
• DNAT_WAN_SRVWEB01_HTTPS
• TEMP_PARTNER_SRVAPP_SFTP
• DROP_VLANIOT_INTERNAL_ANY

ALLOW, DNAT, TEMP o DROP facilitano la lettura rapida. Source, Destination e Service rendono visibile la direzione. Le abbreviazioni devono essere spiegate in uno standard interno di denominazione; in caso contrario, un nome compatto diventa soltanto un nuovo enigma.

Evitare nomi generici come Rule1, Test, Allow, Internet o Temp. Sono poco utili anche i nomi che contengono soltanto un ticket. CHG-1842 può essere cercato, ma in caso di incidente non spiega né la direzione né il servizio.

Accessi temporanei e servizi pubblicati

Le regole temporanee richiedono una data di scadenza effettiva e un Owner. Un prefisso come TEMP facilita la ricerca, ma non sostituisce un processo di dismissione. La data deve figurare sia nella Description sia nel sistema di ticketing o change management, affinché una review in scadenza non dipenda soltanto da un controllo visivo del firewall.

Per i server pubblicati, la sola regola firewall non è sufficiente come documentazione. Regola DNAT, Firewall Rule ID, servizio pubblico, host di destinazione interno e approvazione devono essere riportati insieme nel ticket. Nella Description del firewall è sufficiente indicare change e scopo; i dettagli NAT non devono essere duplicati sotto forma di una seconda configurazione testuale difficile da leggere.

Per l’implementazione tecnica, consultare Pubblicare un server tramite DNAT su Sophos Firewall e Comprendere il NAT su Sophos Firewall.

Cosa non inserire nella Description

La descrizione della regola è visibile agli amministratori e non è un Secret Store. Non inserirvi:

• password, chiavi API o token,
• chiavi private o Preshared Key,
• dati personali o dati riservati dei clienti senza una necessità imprescindibile,
• istruzioni di accesso complete per persone esterne,
• URL lunghi contenenti parametri di sessione, token o informazioni riservate.

È sufficiente un identificativo interno del ticket come CHG-1842. Il collegamento vero e proprio e i dettagli sensibili rimangono nel sistema previsto, dotato di un proprio controllo degli accessi.

Verificare in modo controllato le regole esistenti

Una Description mancante indica la necessità di una review, ma non giustifica l’eliminazione immediata. Anche lo stato SFOS Unused è soltanto un segnale relativo a un periodo breve: significa che la regola non ha rilevato traffico corrispondente nelle ultime 24 ore. Job mensili, accessi di emergenza o applicazioni stagionali possono comunque essere legittimi.

Una review sicura si svolge nel modo seguente:

1. Contrassegnare le regole con Description mancante, nome generico, prefisso TEMP o data di review scaduta.
2. Registrare Rule ID, Position, Source, Destination, Services, Action e Security Profile.
3. Se necessario, selezionare Reset data transfer count in More options e osservare un periodo rappresentativo per l’applicazione.
4. In Reports > Dashboards > Traffic dashboard, controllare i dati trasferiti alla voce Allowed policies.
5. Nel Log viewer, cercare Rule ID, Source, Destination e Service.
6. Verificare Owner e ticket rispetto alle esigenze aziendali attuali.
7. Disattivare prima le regole non più necessarie, osservarle per il periodo concordato e solo in seguito eliminarle.
8. Documentare nel change la decisione, il test e la dismissione.

Un contatore a zero non costituisce una prova se il periodo di osservazione è stato troppo breve. Allo stesso modo, l’assenza di una voce di log non dimostra nulla se Log firewall traffic era disattivato o se le destinazioni di logging locali o esterne non erano configurate correttamente. In System services > Log settings si stabilisce quali log del firewall vengono archiviati localmente, inviati a Sophos Central o trasmessi a server Syslog.

Tracciare modifica ed effetto

La Description spiega perché una regola dovrebbe esistere, ma non dimostra chi l’ha effettivamente modificata. SFOS 22 può registrare tramite Configuration Audit le modifiche alle regole firewall, includendo configurazione precedente e nuova, timestamp, amministratore e Source IP. Lo stato si verifica con system configuration-audit show; la funzione è attiva per impostazione predefinita.

Nel processo operativo devono interagire tre tipi di evidenze:

• Description e ticket: scopo, Owner, approvazione e review.
• Configuration Audit: chi ha modificato quale configurazione e quando.
• Log Viewer e Reports: quali connessioni sono state effettivamente elaborate dalla regola.

L’articolo Verificare i log Audit Trail di Sophos Firewall descrive più nel dettaglio Configuration Audit e la relativa analisi. Dopo ogni modifica, Testare una regola firewall con Log Viewer, Policy Test e Packet Capture consente di verificare se viene applicata la Rule ID prevista.

Standard minimo per le nuove regole

Prima di concludere un change, una nuova regola deve soddisfare i seguenti requisiti:

• Rule name coerente,
• Rule position e Rule group verificati consapevolmente,
• Source, Destination e Services senza un Any inutilmente ampio,
• Description con scopo, Owner, Change e Review,
• Log firewall traffic impostato in base alle esigenze operative e di protezione dei dati,
• nessun secret o dato personale in nome e Description,
• test funzionale con la Rule ID prevista,
• processo di scadenza e dismissione per le regole temporanee.

FAQ