Dokumentera Sophos Firewall-regler på ett bra sätt

En brandväggsregel är inte bara ett tekniskt tillstånd, utan ett driftbeslut: Vem får ansluta vart, via vilken tjänst och av vilken anledning? Utan den här kontexten förblir gamla test-, partner- eller migreringsregler ofta aktiva i flera år eftersom ingen med säkerhet kan bedöma deras syfte.

De viktigaste uppgifterna ska därför stå direkt i Rule name och Description. Ett ärende eller en wiki innehåller detaljerna, medan regeln visar den information som behövs i den dagliga driften. För en tillförlitlig rensning räcker dock inte beskrivningen ensam. Det behövs även Rule ID, loggning, användningsdata, bekräftelse från owner och en kontrollerad observationsperiod.

För den tekniska uppbyggnaden är Förstå och konfigurera Sophos Firewall-regler säkert grundartikeln. Den här guiden fokuserar på namngivning, dokumentation och granskning.

Var dokumentationen anges

Sökvägen är Rules and policies > Firewall rules. Välj först IPv4 eller IPv6 och redigera en befintlig regel eller skapa en ny via Add firewall rule > New firewall rule.

I de allmänna inställningarna är följande fält särskilt relevanta för dokumentationen:

Rule name: ett kort namn på anslutningen som är lätt att överblicka.
Rule position: regelns position i listan som utvärderas uppifrån och ned.
Rule group: regelns organisatoriska gruppering.
Description: syfte, owner, ticket, granskning och medvetna undantag.
Log firewall traffic: skapar loggar och rapportdata för matchande anslutningar.

Sophos Firewall-regel med Description-fält — I Description-fältet dokumenteras syfte, owner, ticket och granskningsinformation direkt i Sophos Firewall-regeln.

Rule group förbättrar överblicken men ändrar inte utvärderingslogiken. Sophos Firewall kontrollerar de enskilda reglerna uppifrån och ned och stannar vid den första matchningen. Efter att regler har skapats, klonats eller genererats automatiskt måste därför deras faktiska Rule position kontrolleras.

Vad som ska stå i Description

Source, Destination, Services, Action och Security-profiler visas redan i regeln. Description ska inte upprepa dessa fält, utan komplettera dem med information som annars saknas senare.

En praktisk minimistandard omfattar:

Syfte: Vilken affärs- eller driftprocess behöver åtkomsten?
Owner: Vilket team ansvarar för applikationen och beslutet?
Change eller ticket: Var finns godkännande, test och tekniska detaljer?
Granskning eller slutdatum: När ska regeln granskas igen eller tas bort?
Undantag: Vilken medveten avvikelse eller begränsning behöver en administratör känna till?

Skapare och ändringstidpunkt behöver inte underhållas manuellt om Configuration Audit och ändringsprocessen tillförlitligt registrerar den informationen. Ett personnamn i Description blir snabbt inaktuellt. Ett permanent team eller en roll är oftast en bättre owner.

Kompakt mall

För många regler räcker en enda strukturerad rad:

Syfte=ERP-atkomst; Owner=APP-TEAM; Change=CHG-1842; Review=2027-01-31

Vid ett medvetet undantag läggs en kort notering till:

Syfte=Partneruppladdning; Owner=INTEGRATION; Change=CHG-1910; Review=2027-01-31; Undantag=endast definierade partnernät

Detaljerat praktiskt exempel

För team som använder en mer detaljerad konvention kan en dokumenterad DNAT-regel exempelvis se ut så här:

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 och LAST MODIFIED är bara meningsfulla om teamet underhåller uppgifterna konsekvent. Om Configuration Audit ger en tillförlitlig ändringshistorik räcker syfte, Owner, ticket och Review i Description; det detaljerade exemplet kan då finnas i ändringsärendet eller runbooken.

Description är en vägvisare, inte en fullständig CMDB. Långa testprotokoll, arkitekturbeslut och rollback-instruktioner hör hemma i det länkade ärendet eller runbooken.

Namnge regler konsekvent

Ett bra namn går att förstå i regelöversikten utan att regeln behöver öppnas. Schemat behöver inte vara identiskt i alla företag, men det ska användas konsekvent inom samma miljö.

Ett beprövat exempel är:

TYP_KALLA_MAL_TJANST

Exempel:

ALLOW_VLAN12_WAN_HTTPS
ALLOW_VPNUSERS_SRVERP_HTTPS
DNAT_WAN_SRVWEB01_HTTPS
TEMP_PARTNER_SRVAPP_SFTP
DROP_VLANIOT_INTERNAL_ANY

ALLOW, DNAT, TEMP och DROP gör listan lättare att skanna. Källa, mål och tjänst visar riktningen. Förkortningar bör förklaras i en intern namnstandard, annars blir ett kompakt namn bara en ny gåta.

Undvik generiska namn som Rule1, Test, Allow, Internet och Temp. Namn som enbart består av ett ärendenummer är också olämpliga. CHG-1842 går visserligen att slå upp, men förklarar varken riktning eller tjänst vid en driftstörning.

Tillfällig och publicerad åtkomst

Tillfälliga regler behöver ett verkligt slutdatum och en owner. Ett prefix som TEMP gör dem lättare att hitta, men ersätter inte en process för avveckling. Datumet ska finnas både i Description och i ärende- eller ändringssystemet, så att en förfallen granskning inte enbart upptäcks genom att någon tittar i brandväggen.

För publicerade servrar räcker inte brandväggsregeln som enda dokumentation. DNAT-regel, Firewall Rule ID, offentlig tjänst, intern målserver och godkännande ska dokumenteras tillsammans i ärendesystemet. I brandväggsregelns Description räcker en hänvisning till ändringsärendet och syftet. NAT-detaljer bör inte dupliceras som en svårläst andra konfiguration i textform.

För den tekniska konfigurationen, se Publicera en server via DNAT på Sophos Firewall och Förstå NAT på Sophos Firewall.

Vad som inte ska stå i Description

Regelbeskrivningen är synlig för administratörer och är inte ett Secret Store. Ange inte:

lösenord, API-nycklar eller tokens,
privata nycklar eller Preshared Keys,
personuppgifter eller konfidentiella kunduppgifter utan ett tvingande skäl,
fullständiga åtkomstinstruktioner för externa personer,
långa URL:er med sessions-, token- eller konfidentiella parametrar.

En intern ticket-identifierare som CHG-1842 räcker. Den faktiska länken och känsliga detaljer ska ligga i det avsedda systemet med egen åtkomstkontroll.

Granska befintliga regler kontrollerat

En Description som saknas är en anledning till granskning, men inte till omedelbar radering. Även SFOS-statusen Unused är bara en kortsiktig indikator. Den innebär att regeln inte har matchat någon trafik under de senaste 24 timmarna. Månatliga jobb, nödåtkomst eller säsongsberoende applikationer kan ändå vara legitima.

En säker granskning genomförs så här:

Markera regler som saknar Description, har ett generiskt namn, innehåller TEMP eller har ett passerat granskningsdatum.
Registrera Rule ID, position, Source, Destination, Services, Action och Security-profiler.
Välj vid behov Reset data transfer count under More options och övervaka en period som är representativ för applikationen.
Kontrollera överförda data under Reports > Dashboards > Traffic dashboard vid Allowed policies.
Sök i Log viewer efter Rule ID, källa, mål och tjänst.
Kontrollera owner och ticket mot det aktuella verksamhetsbehovet.
Inaktivera först regler som inte längre behövs, observera dem under den överenskomna perioden och radera dem först därefter.
Dokumentera beslut, test och avveckling i ändringssystemet.

En räknare som visar noll är inget bevis om observationsperioden var för kort. På samma sätt bevisar en saknad loggpost ingenting om Log firewall traffic var avstängt eller om lokala eller externa loggmål inte var korrekt konfigurerade. Under System services > Log settings anges vilka brandväggsloggar som lagras lokalt eller skickas till Sophos Central eller Syslog-servrar.

Spåra ändring och effekt

Description förklarar varför en regel ska finnas. Det bevisar inte vem som faktiskt ändrade den. SFOS 22 kan registrera ändringar i brandväggsregler via Configuration Audit med föregående och ny konfiguration, tidsstämpel, administratör och käll-IP. Statusen kontrolleras med system configuration-audit show. Funktionen är aktiverad som standard.

I driftprocessen bör tre typer av underlag användas tillsammans:

Description och ticket: syfte, owner, godkännande och granskning.
Configuration Audit: vem som ändrade vilken konfiguration och när.
Log Viewer och Reports: vilka anslutningar regeln faktiskt behandlar.

Artikeln Kontrollera Audit Trail-loggar i Sophos Firewall beskriver Configuration Audit och analysen mer ingående. Efter varje regeländring visar Testa en firewallregel med Log Viewer, Policy Test och Packet Capture om förväntat Rule ID faktiskt används.

Minimistandard för nya regler

Innan ett ändringsärende avslutas bör en ny regel uppfylla följande krav:

konsekvent Rule name,
Rule position och Rule group har kontrollerats medvetet,
Source, Destination och Services utan onödigt brett Any,
Description med syfte, owner, ändringsärende och granskning,
Log firewall traffic inställt utifrån drift- och dataskyddsbehov,
inga hemligheter eller personuppgifter i namn och Description,
funktionstest med förväntat Rule ID,
process för slutdatum och avveckling av tillfälliga regler.

FAQ

Vilka uppgifter ska finnas i en Sophos Firewall-regel?

Rule name och Description ska åtminstone visa syfte, ansvarigt team, ändringsreferens och granskningsdatum. Tekniska detaljer, godkännande och rollback ska ligga i ärendesystemet eller runbooken.

Innebär statusen Unused att en regel kan raderas?

Nej. Unused betyder bara att regeln inte har matchat någon trafik under de senaste 24 timmarna. Innan den raderas behövs en representativ observationsperiod, loggar, bekräftelse från owner och ett kontrollerat inaktiveringstest.

Räcker dataräknaren som bevis på användning?

Nej. Räknaren underlättar övervakningen, men måste bedömas tillsammans med Log Viewer, Reports och verksamhetsprocessen. Sällsynta eller säsongsberoende anslutningar kan förbli oanvända under ett kort test.

Ska lösenord eller inloggningsuppgifter stå i Description?

Nej. Hemligheter, privata nycklar och konfidentiella inloggningsuppgifter ska lagras i ett avsett system med egen åtkomstkontroll, inte i brandväggsregler.

Vad är skillnaden mellan Description och Configuration Audit?

Description dokumenterar syfte och ansvar. Configuration Audit registrerar den faktiska ändringen med föregående och nytt tillstånd, tidsstämpel, administratör och käll-IP. Båda behövs för en tillförlitlig granskning.