Sophos Firewall-regels zinvol documenteren

Een firewallregel is niet alleen een technische vrijgave, maar een operationele beslissing: wie mag waarheen, via welke dienst en om welke reden? Zonder deze context blijven oude test-, partner- of migratieregels vaak jarenlang actief, omdat niemand hun doel met zekerheid kan beoordelen.

De belangrijkste gegevens horen daarom direct in Rule name en Description. Een ticket of wiki bevat de details, terwijl de regel zelf de context voor het dagelijkse beheer toont. Voor een betrouwbare opschoning is de beschrijving alleen echter niet voldoende; daarvoor zijn ook Rule ID, logging, gebruiksgegevens, bevestiging van de Owner en een gecontroleerde observatieperiode nodig.

Voor de technische opbouw is Sophos Firewall-regels begrijpen en veilig configureren het basisartikel. De volgende handleiding richt zich op naamgeving, documentatie en review.

Waar de documentatie wordt ingevoerd

Het pad is Rules and policies > Firewall rules. Kies daar eerst IPv4 of IPv6 en bewerk een bestaande regel of maak via Add firewall rule > New firewall rule een nieuwe regel aan.

In de algemene instellingen zijn vooral de volgende velden van belang voor de documentatie:

Rule name: korte, makkelijk scanbare naam van de verbinding.
Rule position: positie in de regellijst die van boven naar beneden wordt geëvalueerd.
Rule group: organisatorische groepering van de regel.
Description: doel, Owner, ticket, review en bewuste uitzondering.
Log firewall traffic: genereert logs en rapportgegevens voor overeenkomende verbindingen.

Sophos Firewall-regel met Description-veld — In het Description-veld worden doel, Owner, ticket en reviewnotitie direct bij de Sophos Firewall-regel vastgelegd.

Rule group verbetert het overzicht, maar verandert niets aan de evaluatielogica. Sophos Firewall controleert de afzonderlijke regels van boven naar beneden en stopt bij de eerste overeenkomst. Na het aanmaken, klonen of automatisch genereren van regels moet daarom de werkelijke Rule position worden gecontroleerd.

Wat in de Description hoort

Source, Destination, Services, Action en Security-profielen zijn al zichtbaar in de regel. De Description moet deze velden niet herhalen, maar juist de informatie toevoegen die later anders ontbreekt.

Een bruikbare minimumstandaard bestaat uit:

Doel: Welk bedrijfs- of operationeel proces heeft deze vrijgave nodig?
Owner: Welk team is verantwoordelijk voor de applicatie en de beslissing?
Change of ticket: Waar staan de goedkeuring, test en technische details?
Review- of verloopdatum: Wanneer wordt de regel opnieuw gecontroleerd of verwijderd?
Uitzondering: Welke bewuste afwijking of beperking moet een beheerder kennen?

De maker en het tijdstip van wijziging hoeven niet handmatig te worden bijgehouden als Configuration Audit en het changeproces deze informatie betrouwbaar leveren. De naam van een persoon in de Description raakt snel verouderd; een vast team of een rol is meestal een betere Owner.

Compacte sjabloon

Voor veel regels volstaat één gestructureerde regel:

Doel=ERP-toegang; Owner=APP-TEAM; Change=CHG-1842; Review=2027-01-31

Bij een bewuste uitzondering wordt een korte toelichting toegevoegd:

Doel=Partner-upload; Owner=INTEGRATION; Change=CHG-1910; Review=2027-01-31; Uitzondering=alleen gedefinieerde partnernetwerken

Uitgebreid praktijkvoorbeeld

Voor teams die een uitgebreidere conventie gebruiken, kan een gedocumenteerde DNAT-regel er bijvoorbeeld als volgt uitzien:

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 en LAST MODIFIED zijn alleen zinvol als het team deze gegevens consequent bijhoudt. Als Configuration Audit een betrouwbare wijzigingshistorie biedt, volstaan doel, Owner, ticket en Review in de Description; het uitgebreide voorbeeld kan dan in de change of het runbook staan.

De Description is een wegwijzer, geen volledige CMDB. Uitgebreide testverslagen, architectuurbeslissingen en rollback-instructies horen in het gekoppelde ticket of runbook.

Regels consistent benoemen

Een goede naam is in het regeloverzicht te begrijpen zonder de regel te openen. Het schema hoeft niet voor elk bedrijf hetzelfde te zijn, maar moet binnen één omgeving consequent worden toegepast.

Een beproefd voorbeeld is:

TYPE_BRON_DOEL_DIENST

Voorbeelden:

ALLOW_VLAN12_WAN_HTTPS
ALLOW_VPNUSERS_SRVERP_HTTPS
DNAT_WAN_SRVWEB01_HTTPS
TEMP_PARTNER_SRVAPP_SFTP
DROP_VLANIOT_INTERNAL_ANY

ALLOW, DNAT, TEMP en DROP helpen bij het scannen. Bron, bestemming en dienst maken de richting zichtbaar. Afkortingen moeten in een interne naamgevingsstandaard worden uitgelegd; anders wordt een compacte naam alleen maar een nieuw raadsel.

Vermijd generieke namen zoals Rule1, Test, Allow, Internet en Temp. Namen die alleen een ticketnummer bevatten zijn eveneens ongunstig. CHG-1842 kan weliswaar worden opgezocht, maar maakt bij een storing noch de richting noch de dienst duidelijk.

Tijdelijke en gepubliceerde toegang

Tijdelijke regels hebben een echte verloopdatum en een Owner nodig. Een voorvoegsel zoals TEMP vereenvoudigt het zoeken, maar vervangt geen verwijderingsproces. De datum hoort zowel in de Description als in het ticket- of changesysteem, zodat een geplande controle niet alleen afhankelijk is van iemand die in de firewall kijkt.

Bij gepubliceerde servers is de firewallregel alleen niet voldoende als documentatie. De DNAT-regel, Firewall Rule ID, publieke dienst, interne doelhost en goedkeuring horen gezamenlijk in het ticket. In de Firewall-Description volstaat een verwijzing naar de Change en het doel; NAT-details moeten niet als moeilijk leesbare tweede configuratie in tekstvorm worden gedupliceerd.

Voor de technische uitvoering helpen Een server via DNAT op Sophos Firewall publiceren en NAT op Sophos Firewall begrijpen.

Wat niet in de Description hoort

De regelbeschrijving is zichtbaar voor beheerders en is geen Secret Store. Voer hier niet het volgende in:

wachtwoorden, API-sleutels of tokens,
privésleutels of Preshared Keys,
persoonsgegevens of vertrouwelijke klantgegevens zonder dwingende reden,
volledige toegangsinstructies voor externe personen,
lange URL’s met sessie-, token- of vertrouwelijke parameters.

Een interne ticket-ID zoals CHG-1842 is voldoende. De eigenlijke link en gevoelige details blijven in het daarvoor bestemde systeem met eigen toegangscontrole.

Bestaande regels gecontroleerd beoordelen

Een ontbrekende Description is een aanleiding voor een review, maar geen reden om de regel direct te verwijderen. Ook de SFOS-status Unused is slechts een kortetermijnsignaal: deze betekent dat de regel gedurende de afgelopen 24 uur geen overeenkomend verkeer heeft verwerkt. Maandelijkse taken, noodtoegang of seizoensgebonden applicaties kunnen desondanks legitiem zijn.

Een veilige review verloopt als volgt:

Markeer regels met een ontbrekende Description, een generieke naam, TEMP of een verstreken reviewdatum.
Leg Rule ID, Position, Source, Destination, Services, Action en Security-profielen vast.
Kies indien nodig onder More options voor Reset data transfer count en observeer gedurende een periode die representatief is voor de applicatie.
Controleer onder Reports > Dashboards > Traffic dashboard bij Allowed policies de overgedragen gegevens.
Zoek in de Log viewer op Rule ID, bron, bestemming en dienst.
Toets de Owner en het ticket aan de actuele bedrijfsbehoefte.
Schakel regels die niet meer nodig zijn eerst uit, observeer ze gedurende de afgesproken periode en verwijder ze pas daarna.
Documenteer de beslissing, test en verwijdering in de Change.

Een tellerstand van nul is geen bewijs als de observatieperiode te kort was. Ook een ontbrekende logvermelding bewijst niets wanneer Log firewall traffic eerder was uitgeschakeld of de lokale of externe logbestemmingen niet correct zijn geconfigureerd. Onder System services > Log settings wordt bepaald welke firewalllogs lokaal worden opgeslagen, naar Sophos Central worden verzonden of naar Syslog-servers worden doorgestuurd.

Wijziging en werking traceerbaar maken

De Description legt uit waarom een regel zou moeten bestaan. Deze bewijst niet wie de regel daadwerkelijk heeft gewijzigd. SFOS 22 kan wijzigingen aan firewallregels via Configuration Audit vastleggen met de vorige en nieuwe configuratie, tijdstempel, beheerder en bron-IP. De status wordt gecontroleerd met system configuration-audit show; de functie is standaard ingeschakeld.

Voor het beheerproces moeten drie soorten bewijs samen worden gebruikt:

Description en ticket: doel, Owner, goedkeuring en review.
Configuration Audit: wie wanneer welke configuratie heeft gewijzigd.
Log Viewer en Reports: welke verbindingen de regel daadwerkelijk heeft verwerkt.

Het artikel Sophos Firewall Audit Trail Logs controleren beschrijft Configuration Audit en de evaluatie ervan uitgebreider. Na elke regelwijziging laat Een firewallregel testen met Log Viewer, Policy Test en Packet Capture zien of de verwachte Rule ID daadwerkelijk wordt gebruikt.

Minimumstandaard voor nieuwe regels

Voordat een Change wordt afgerond, moet een nieuwe regel aan de volgende punten voldoen:

consistente Rule name,
Rule position en Rule group bewust gecontroleerd,
Source, Destination en Services zonder onnodig brede Any,
Description met doel, Owner, Change en review,
Log firewall traffic ingesteld volgens de operationele behoeften en privacyvereisten,
geen Secrets of persoonsgegevens in de naam en Description,
functietest met de verwachte Rule ID,
verloop- en verwijderingsproces voor tijdelijke regels.

FAQ

Welke gegevens horen in een Sophos Firewall-regel?

Rule name en Description moeten ten minste het doel, het verantwoordelijke team, de Change-referentie en de reviewdatum duidelijk maken. Technische details, goedkeuring en rollback blijven in het ticket of runbook.

Betekent de status Unused dat een regel kan worden verwijderd?

Nee. Unused betekent alleen dat de regel in de afgelopen 24 uur geen overeenkomend verkeer heeft verwerkt. Vóór verwijdering zijn een representatieve observatieperiode, logs, bevestiging van de Owner en een gecontroleerde uitschakeltest nodig.

Volstaat de gegevensteller als bewijs van gebruik?

Nee. De teller helpt bij de observatie, maar moet samen met Log Viewer, Reports en het bedrijfsproces worden beoordeeld. Zeldzame of seizoensgebonden verbindingen kunnen tijdens een korte test ongebruikt blijven.

Mogen wachtwoorden of toegangsgegevens in de Description staan?

Nee. Secrets, privésleutels en vertrouwelijke toegangsgegevens horen in een daarvoor bestemd systeem met eigen toegangscontrole, niet in firewallregels.

Wat is het verschil tussen Description en Configuration Audit?

De Description documenteert het doel en de verantwoordelijkheid. Configuration Audit legt de daadwerkelijke wijziging vast met de vorige en nieuwe status, tijdstempel, beheerder en bron-IP. Voor een betrouwbare review zijn beide nodig.