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 sammanhanget för 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 medvetet 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. En grupp får inte vara tom. Om en regel ska flyttas över en gruppgräns måste den först kopplas loss med Detach, alternativt måste hela gruppen flyttas. Efter att regler har skapats, klonats eller genererats automatiskt måste därför deras faktiska Rule position kontrolleras.

Den som hanterar regler via API måste ta hänsyn till vissa fasta gränser i SFOS 22. Ett Rule name får innehålla högst 60 tecken och inget kommatecken. För Rule groups tillåter API:t 150 tecken i namnet, 255 tecken i beskrivningen och högst 200 regelreferenser. Dessa gränser gäller API:t. Den aktuella WebAdmin-hjälpen anger ingen teckengräns för Description. Den bör ändå hållas kort så att den är läsbar i regeltabellen.

Vad som ska stå i Description

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

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?

Uppgifter om vem som skapade regeln och när den ändrades 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

En utförligt dokumenterad DNAT-regel kan se ut så här:

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

Formatet visar Source, Destination och Service även utanför WebAdmin. Om någon ändrar regeln måste även Description uppdateras. Annars motsäger de varandra. Vi rekommenderar därför den kompakta mallen. Om Configuration Audit registrerar ändringarna tillförlitligt räcker syfte, owner, ticket och granskning i Description. Det utförliga exemplet kan 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:

PREFIX_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 och DROP anger åtgärden, DNAT betecknar brandväggsregeln för en publicering och TEMP en tillfällig åtkomst. Här betecknar DNAT inte själva NAT-regeln. 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, publikt exponerad 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 ögonblicksbild. Beroende på vy anger den aktuella Sophos-hjälpen 12 eller 24 timmar utan matchande trafik. 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, aktiveringsstatus, Source, Destination, Services, Action och Security Profiles. Kontrollera vid behov använda värdar och tjänster via Object Usage. Dess räknare visar konfigurationsberoenden, inte trafiken för en regel.
Spara tidsstämpeln och det aktuella räknarvärdet i ändringsärendet innan du väljer More options > Reset data transfer count. Nollställ bara räknaren om den efterföljande observationsperioden även omfattar sällsynta anslutningar.
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 regler som inte längre behövs under ett överenskommet tidsfönster och övervaka utfallet. Om förväntad trafik upphör ska regeln omedelbart aktiveras igen, dess position kontrolleras och testet upprepas med förväntat Rule ID.
Dokumentera beslut, test och avveckling i ändringsärendet.

Den inaktiverade regeln raderas först när den överenskomna observationsperioden har löpt ut utan störningar och owner har godkänt det. En räknare som visar noll är inget bevis om observationsperioden var för kort. Inte heller en saknad loggpost räcker som bevis. Log firewall traffic kan ha varit avstängt, en anslutning kan ha brutits utan en loggad Destroy-händelse eller loggmålen kan ha varit felaktigt konfigurerade. Under System services > Log settings anges vilka brandväggsloggar som skickas lokalt, till Sophos Central eller till Syslog-servrar.

Spåra ändring och effekt

Description förklarar varför en regel ska finnas. Den visar inte vem som faktiskt ändrade regeln. I SFOS 22 registrerar Configuration Audit föregående och nytt tillstånd samt tidsstämpel, administratör och käll-IP. Statusen kontrolleras i Device Console med system configuration-audit show, inte i Advanced Shell. 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 brandväggsregel 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 och valts med omsorg,
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,
fastställd process för utgångsdatum 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. Beroende på vy anger den aktuella Sophos-hjälpen att Unused motsvarar 12 eller 24 timmar utan matchande trafik. Innan regeln raderas behövs en representativ observationsperiod, loggar, bekräftelse från owner och ett kontrollerat inaktiveringstest med återställningsmöjlighet.

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.