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. Un gruppo non può rimanere vuoto. Per spostare una regola oltre i confini del gruppo, occorre prima separarla con Detach oppure spostare l’intero gruppo. Dopo la creazione di regole nuove, clonate o generate automaticamente, è quindi necessario verificare la Rule position effettiva.

Chi gestisce le regole tramite API deve rispettare alcuni limiti fissi in SFOS 22. Un Rule name può contenere al massimo 60 caratteri e non può includere virgole. Per i Rule group, l’API consente 150 caratteri nel nome, 255 nella descrizione e un massimo di 200 riferimenti a regole. Questi limiti si applicano all’API. L’attuale guida di WebAdmin non indica un limite di caratteri per la Description, che dovrebbe comunque rimanere concisa per risultare leggibile nella tabella delle regole.

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

Una regola DNAT documentata in dettaglio può essere strutturata così:

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

Questo formato mostra Source, Destination e Service anche al di fuori di WebAdmin. Se qualcuno modifica la regola, tuttavia, deve aggiornare anche la Description, altrimenti le due informazioni entrano in conflitto. Per questo consigliamo il modello compatto. Se Configuration Audit registra le modifiche in modo 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:

PREFIX_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 e DROP indicano l’azione, DNAT identifica la regola firewall associata a una pubblicazione e TEMP un’autorizzazione temporanea. In questo caso, DNAT non indica la regola NAT stessa. 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’istantanea. A seconda della schermata, l’attuale guida di Sophos indica 12 o 24 ore senza traffico corrispondente. 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, stato di attivazione, Source, Destination, Services, Action e Security Profile. Se necessario, verificare gli host e i servizi utilizzati tramite Object Usage; il relativo contatore indica le dipendenze di configurazione, non il traffico di una regola.
3. Prima di selezionare More options > Reset data transfer count, registrare nel change il timestamp e il valore corrente del contatore. Azzerare il contatore solo se il successivo periodo di osservazione include anche le connessioni poco frequenti.
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 le regole non più necessarie durante una finestra concordata e osservarle. Se il traffico previsto si interrompe, riattivare subito la regola, controllarne la posizione e ripetere il test con la Rule ID prevista.
8. Documentare nel change la decisione, il test e la dismissione.

Eliminare la regola disattivata solo dopo che il periodo di osservazione concordato è trascorso senza disservizi e l’Owner ha dato il proprio consenso. Un contatore a zero non costituisce una prova se il periodo è stato troppo breve. Nemmeno l’assenza di una voce di log è sufficiente: Log firewall traffic potrebbe essere stato disattivato, una connessione potrebbe essersi interrotta senza un evento Destroy registrato oppure le destinazioni di logging potrebbero non essere state 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 indica chi l’ha effettivamente modificata. In SFOS 22, Configuration Audit registra lo stato precedente e quello nuovo, oltre a timestamp, amministratore e Source IP. Lo stato si verifica nella Device Console con system configuration-audit show, non nell’Advanced Shell. 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