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. Een groep kan niet leeg blijven. Om een regel naar een positie buiten de groep te verplaatsen, moet u deze eerst met Detach loskoppelen of de hele groep verplaatsen. Na het aanmaken, klonen of automatisch genereren van regels moet daarom de werkelijke Rule position worden gecontroleerd.

Wie regels via de API beheert, moet in SFOS 22 rekening houden met enkele vaste limieten. Een Rule name mag maximaal 60 tekens lang zijn en mag geen komma bevatten. Voor Rule groups staat de API 150 tekens in de naam, 255 tekens in de beschrijving en maximaal 200 regelverwijzingen toe. Deze limieten gelden voor de API. Voor de Description vermeldt de huidige WebAdmin-help geen tekenlimiet. Houd deze desondanks kort, zodat de tekst in de regeltabel leesbaar blijft.

Wat in de Description hoort

Source, Destination, Services, Action en Security profiles 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

Een uitvoerig gedocumenteerde DNAT-regel kan er als volgt uitzien:

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

Deze indeling toont Source, Destination en Service ook buiten WebAdmin. Als iemand de regel wijzigt, moet de Description echter eveneens worden bijgewerkt. Anders spreken beide elkaar tegen. Daarom adviseren we de compacte sjabloon. Als Configuration Audit de wijzigingen betrouwbaar vastlegt, volstaan doel, Owner, ticket en review in de Description. Het uitgebreide voorbeeld kan 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:

PREFIX_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 en DROP geven de actie aan, DNAT markeert de firewallregel van een publicatie en TEMP een tijdelijke vrijgave. DNAT verwijst hier niet naar de NAT-regel zelf. Bron, doel en dienst maken de richting zichtbaar. Afkortingen moeten in de 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 momentopname. De huidige Sophos-help noemt, afhankelijk van de weergave, 12 of 24 uur zonder overeenkomend verkeer. 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, activeringsstatus, Source, Destination, Services, Action en Security profiles vast. Controleer gebruikte hosts en services zo nodig via Object Usage; de teller daarvan toont configuratieafhankelijkheden, niet het verkeer van een regel.
Leg vóór More options > Reset data transfer count het tijdstip en de actuele tellerstand vast in de Change. Reset de teller alleen als de daaropvolgende observatieperiode ook weinig voorkomende verbindingen omvat.
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 in een afgesproken tijdvenster uit en observeer ze. Valt verwacht verkeer uit, schakel de regel dan onmiddellijk weer in, controleer de positie en herhaal de test met de verwachte Rule ID.
Documenteer de beslissing, test en verwijdering in de Change.

De uitgeschakelde regel wordt pas verwijderd als de afgesproken observatieperiode zonder storing is verstreken en de Owner ermee instemt. Een tellerstand van nul is geen bewijs als de periode te kort was. Ook een ontbrekende logvermelding volstaat niet als bewijs. Mogelijk was Log firewall traffic uitgeschakeld, werd een verbinding verbroken zonder vastgelegde Destroy-gebeurtenis of waren de logbestemmingen niet correct 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. Ze laat niet zien wie de regel daadwerkelijk heeft gewijzigd. In SFOS 22 legt Configuration Audit de vorige en nieuwe status vast, samen met tijdstempel, beheerder en bron-IP. De status wordt in de Device Console gecontroleerd met system configuration-audit show, niet in de Advanced Shell. 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. De huidige Sophos-help noemt voor Unused, afhankelijk van de weergave, 12 of 24 uur zonder overeenkomend verkeer. Vóór verwijdering zijn een representatieve observatieperiode, logs, bevestiging van de Owner en een gecontroleerde uitschakeltest nodig waarbij de wijziging direct kan worden teruggedraaid.

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.