Definér først hvad firewallen skal beskytte
En firewall er en kontrolleret adgangsgrænse mellem netværk eller mellem dele af et netværk. Når du skal vælge den rigtige, begynder du med at beskrive, hvad der skal beskyttes, og hvad der må tillades.
Start med at svare på:
- Hvilke typer systemer skal beskyttes (fx servere, arbejdsstationer, gæsteadgang)?
- Hvilken trafik er “normal” (kilder, destinationer, protokoller, typiske porte)?
- Hvilke forretningskrav findes der (tilgængelighed, eksterne integrationer, behov for logning)?
Det vigtige er at afklare scope for regelsættet: En firewall er kun så god som de politikker, du lægger ind, og den måde du vedligeholder dem på.
Brug et simpelt beslutningsmodel med tre lag
I praksis kan du vælge ud fra tre hensyn, som ofte hænger sammen:
- Adgangskontrol (hvad må passere)
- Skal den primært filtrere på IP/adresser, porte og protokoller?
- Eller skal den også kunne lave dybere vurdering af forbindelser og applikationsadfærd?
- Inspektion og synlighed (hvad kan den forstå)
- Overvej hvor meget logning du skal bruge til fejlfinding og opfølgning.
- Mere avanceret inspektion kan give bedre kontrol, men kan også øge kompleksitet og påvirke performance.
- Drift og administration (hvordan den holdes korrekt)
- Hvordan opdateres konfiguration og eventuelle sikkerhedsfunktioner?
- Hvor let er det at gennemgå ændringer, reproducere fejl og rulle tilbage?
Hvis du ikke kan svare nogenlunde på de tre punkter, er det svært at vurdere om en firewall passer til jeres virkelighed.
Sammenlign funktioner der betyder noget for valg
Når du sammenligner firewall-muligheder, så fokuser på funktioner, der påvirker sikkerhed og drift i hverdagen:
- Regelsprog og politikmodel: Er det let at udtrykke “tillad det nødvendige, bloker resten”, og kan regler håndteres uden at blive uigennemskuelige?
- Håndtering af applikationsnær trafik: Kræver jeres miljø at firewall’en forstår mere end bare porte (fx for at reducere utilsigtet adgang)?
- Logning og hændelsesoverblik: Kan du få nyttige logs til troubleshooting og audit?
- Ændringsstyring: Kan du versionere, dokumentere og teste ændringer før de rammer produktion?
- Robusthed: Planlæg for driftsscenarier som fejl, vedligehold og failover—uanset leveringsform.
Vælg ikke kun ud fra markedsnavne eller “sikkerhedsniveau”. Det du kan kontrollere, er hvordan regler skrives, hvordan trafik evalueres, og hvordan logning/administration fungerer i praksis. Hold også øje med, at mere avancerede muligheder ikke skaber et regelsæt, ingen kan vedligeholde.
Vær tydelig om grænser og undtagelser
Der findes ikke én firewall-type, der passer til alt. Her er typiske forhold, der kan ændre dit valg:
- Performance: Dybere inspektion kan påvirke throughput/latens. Hvis du har høj trafik, kan du være nødt til at afgrænse hvor dybt der inspiceres.
- Kompleksitet: Jo flere regler og jo mere detaljeret kontrol, desto større risiko for fejlkonfiguration.
- Falske positiver og fejlretninger: Hvis firewall’en skal træffe mere avancerede beslutninger, kan du få ekstra støj i logs eller blokering af legitim trafik.
- Afhængighed af korrekt politik: En “forkert” tilladelsesregel kan undergrave gevinsten. Derfor er review og test en del af valget.
Hvis du forventer at firewallen alene løser alle risici, kan du komme til at overvurdere effekten. En firewall er et vigtigt lag, men den skal kombineres med grundlæggende sikkerhedspraksis, fx opdateringer, adgangsstyring og overvågning.
Sådan gør du valget testbart i stedet for gætteri
For at vælge rigtigt, så omsæt krav til konkrete testspørgsmål. Du kan bruge denne arbejdsgang:
- Lav en trafiksamling for “det nødvendige”
- Identificér de vigtigste forbindelser (kilder, destinationer, porte/protokoller) og dokumentér forventet adfærd.
- Prøv politikker i et sikkert miljø
- Kør et kontrolleret testsetup og verificér, at legitim trafik virker, mens uønsket trafik stoppes.
- Mål både sikkerhed og drift
- Kig på logkvalitet (kan du forklare hændelser?), samt hvor let det er at lave ændringer og fejlsøge.
- Planlæg en gradvis udrulning
- Start med begrænset omfang, skift én ting ad gangen, og hold øje med effekter i logs.
- Fastlæg kriterier for “godt nok”
- Beslut på forhånd, hvilke fejl og hvilken mængde støj i hændelser der er acceptabel, inden du går i fuld drift.
Det vigtigste er, at valget bliver et kravbaseret og testbart valg—ikke en ren sammenligning af features på papiret.
