Sophos Firewall: hårdvara, virtuell eller moln?
Sophos Firewall kan fungera som XGS Hardware Appliance, virtuell apparat, Software Appliance eller Cloud Deployment. Tekniskt sett körs Sophos Firewall OS överallt, men driftsmodellen är inte densamma. Beslutet påverkar prestanda, support, portdesign, HA, återhämtning, licensiering, övervakning och frågan om vem som ansvarar för vilken plattform vid avbrott.
För nya projekt ska man inte bara fråga vilken variant som är billigare. Det som spelar roll är vilken variant som passar platsen, virtualiseringsplattformen, molnarkitekturen och driftteamet. Sophos Firewall Storleksguide är också viktig för prestandastorlek.
Valet av plattform avgör också vilka efterlevnadsfunktioner som finns: FIPS 140-3-läget erbjuds på XGS, virtuella plattformar som stöds, AWS och Azure, men inte på Software Appliances eller XG- och SG-hårdvara.
Välj driftmodell
Snabbt beslut
- XGS Hardware Appliance: Passar oftast när en webbplats behöver en dedikerad brandvägg som tydligt stöds med fysiska portar.
- Virtual Appliance: Mest lämpligt om en stabil virtualiseringsplattform är tillgänglig och nätverkszoner kan separeras rent virtuellt.
- Software Appliance: Vanligtvis lämplig om din egen hårdvara avsiktligt ska drivas och stödjas som en brandväggsplattform.
- Cloud Deployment: Mest lämplig när du skyddar arbetsbelastningar i AWS eller Azure eller ansluter till lokala nätverk.
Den viktigaste regeln: En virtuell brandvägg eller molnbrandvägg är inte ett gratiskort för mindre planering. CPU, RAM, lagring, virtuella switchar, routing, HA, backup och övervakning måste planeras lika noggrant som med hårdvara.
När ska man vara försiktig
Beslutet ska inte bara baseras på vad som är tekniskt möjligt. Vissa miljöer ser flexibla ut på pappret, men skapar onödiga risker i driften.
- Hypervisor används redan hårt: IPS, TLS Inspection, VPN och loggning behöver förutsägbar CPU och I/O-reserv.
- WAN, LAN, DMZ och förvaltningen går igenom samma fysiska flaskhals: En logiskt ren separation är till liten hjälp om den verkliga datavägen är överbelastad eller felaktigt segmenterad.
- Inget team känner sig gemensamt ansvariga för hypervisor och brandvägg: Incidenter kvarstår mellan plattforms-, nätverks- och brandväggsteam.
- HA planerades endast som en kryssruta: Utan testning av värd, lagring, nätverk och återställning är hög tillgänglighet inte bevisad.
- Molnrouting är inte helt dokumenterad: Brandväggen skyddar bara trafik som faktiskt dirigeras genom den.
- Återställning praktiserades aldrig: En säkerhetskopia är bara tillförlitlig om en återställning har testats realistiskt eller åtminstone ordentligt planerad. I sådana fall är en XGS Hardware Appliance ofta inte mindre modern, utan helt enkelt det mer robusta driftbeslutet. Omvänt kan en virtuell brandvägg eller molnbrandvägg vara mycket användbar om plattformen, nätverksdesignen, övervakningen och ansvaret är tydligt klarlagda.
Jämför plattformarna
XGS Hardware Appliance
En XGS Hardware Appliance är vanligtvis den mest planerade varianten för klassiska platser. Hårdvara, portar, support, RMA, livscykel och brandväggsoperativsystem kommer som ett koordinerat system.
Fördelar:
- dedikerad hårdvara för brandväggen,
- fast hamnutrustning och expansionsmöjligheter,
- tydlig tilldelning av WAN, LAN, DMZ, HA länk och hantering,
- enkel hårdvarusupport och ersättningsprocess,
- inget beroende av hypervisorresurser,
- Väl lämpad för filialer, huvudkontor och kantbrandväggar. Den största fördelen ligger i driften: Om det finns ett problem behöver du inte först klargöra om hypervisor, vSwitch, lagring, molnrouting eller själva brandväggen är orsaken. För många små och medelstora företag är detta viktigare än maximal flexibilitet.
Virtuell apparat
En virtuell Sophos Firewall är vettig om det redan finns en ren virtualiseringsplattform och brandväggen ska integreras i ett datacenter, en miljö med flera hyresgäster eller en intern segmenteringsdesign.
Relevanta virtuella plattformar omfattar VMware, Microsoft Hyper-V, KVM, Nutanix Prism och Citrix Hypervisor. Före deployment ska den konkreta plattformsversionen kontrolleras mot aktuell kompatibilitetsinformation från Sophos. Sophos anger minst en vCPU, 4 GB RAM, två vNIC, en primär disk på 32 GB och en rapportdisk på 80 GB. Detta är installationsminimum, inte en sizingrekommendation för inspection-trafik i produktion.
Viktiga operativa frågor:
- Är CPU-resurser garanterade eller kraftigt övertecknade?
- Är RAM och lagring tillräckligt dimensionerade?
- Är virtuella nätverkskort och portgrupper tydligt åtskilda?
- Finns det dedikerade nätverksvägar för WAN, LAN, DMZ, HA och hantering?
- Krävs promiskuöst läge, VLAN trunking eller SR-IOV?
- Finns det ett rent säkerhetskopierings- och återställningskoncept?
- Är det klart vem som felsöker hypervisor, lagring och brandvägg tillsammans?
En virtuell brandvägg kan fungera mycket bra. Saker och ting blir dock snabbt problematiska när den körs på en överbelastad värd eller när WAN, LAN och hanteringen bara ser logiskt rena ut, men fysiskt går igenom samma flaskhalsar.
⚠️ Hypervisorsnapshots eller backups från virtualiseringsleverantören är inte en supportad ersättning för Sophos integrerade backup. För en supportbar restore ska konfigurationen sparas under Backup & Firmware > Backup & Restore. Plattformens backups kan finnas som komplement, men får inte vara den enda recoveryvägen.
Software Appliance
En Software Appliance installeras på dedikerad x86-64-hårdvara. Detta kan vara användbart för laboratorier, specialmiljöer eller mycket riktade designer. I produktion måste modellen väljas medvetet eftersom hårdvara, drivrutiner, reservdelar, övervakning och support till stor del är operatörens ansvar.
Installationen formaterar och partitionerar om disken och raderar det befintliga operativsystemet samt alla filer. För en Software Appliance med SFOS 22 kräver Sophos Legacy BIOS, minst 4 GB RAM, två nätverksgränssnitt och minst 32 GB lagring; 64 GB rekommenderas. Om minimikraven inte uppfylls kan brandväggen gå in i fail-safe mode.
Om en appliance redan startar i Failsafe-läge ska orsaken som SFOS har identifierat sparas med runbooken Kontrollera Sophos Firewall i Failsafe-läge innan resurser ändras.
Kontrollera:
- Är hårdvaran lämplig för kontinuerlig drift?
- Är nätverkskort, lagring och BIOS/UEFI-konfiguration lämpliga?
- Finns det ersättningshårdvara?
- Är installations- och återställningsprocessen dokumenterad?
- Vem är ansvarig för hårdvarufel?
För standardplatser är en XGS Hardware Appliance ofta enklare. För speciella tekniska fall kan en Software Appliance ändå vara lämplig om driftteamet har god kontroll över plattformen.
Cloud Deployment
Molndistributioner är särskilt användbara när arbetsbelastningar i AWS eller Azure behöver skyddas eller när molnnätverk är anslutna till lokala platser. Olika frågor är viktiga i molnet än på den traditionella platsen.
Planera:
- VPC/VNet design,
- rutttabeller,
- Tillgänglighetszoner,
- Elastiska IP-adresser eller offentliga IP-adresser,
- Plats-till-plats VPN eller SD-WAN,
- Loggning och central utvärdering,
- Molnkostnader för till exempel lagring, trafik och HA design,
- Operativt ansvar mellan molnteam och brandväggsteam.
En molnbrandvägg är inte en ersättning för ren molnnätverksdesign. Endast de vägar som faktiskt dirigeras genom brandväggen är skyddade.
Planera drift och återställning
Prestanda och storlek
När det kommer till hårdvara beror prestanda på vilken modell du väljer. För virtuella, mjukvaru- och molninstallationer är prestandan mer plattformsberoende.
Särskilt relevant:
- CPU prestanda och CPU reservation,
- RAM,
- lagringslatens,
- virtuella nätverkskort,
- hypervisor eller molnnätverksväg,
- antal sessioner,
- TLS Inspection,
- IPS,
- VPN genomströmning,
- Loggning och rapportering.
Databladsvärden ska därför alltid läsas i sitt sammanhang. Brandväggsgenomströmning utan säkerhetsinspektion är inte detsamma som Threat Protection, TLS Inspection eller IPsec VPN under verklig belastning. Skillnaderna förklaras Sophos Firewall Tolka prestandadata korrekt.
HA och återställning
Hög tillgänglighet skiljer sig markant beroende på plattform. När det kommer till hårdvara är HA vanligtvis lättare att förstå: två apparater, HA länk, definierade gränssnitt, tydlig ersättningsenhet. Ytterligare frågor uppstår för virtuella och molninstallationer:
- Körs HA-noder på olika värdar?
- Är lagring, nätverk och hypervisor verkligen överflödiga?
- Är virtuella MAC-adresser och vSwitch-regler kompatibla?
- Finns det några beroenden av molnrouting eller lastbalansering?
- Fungerar säkerhetskopieringar och återställningar på en ny instans?
- Har felet hos en värd eller en tillgänglighetszon testats?
Grunderna för HA-varianter finns i Ställa in Sophos Firewall High Availability (HA). För återställning krävs läsning av Sophos Firewall Skapa eller återställ säkerhetskopia.
Licensiering och support
Licenser ska kontrolleras tidigt eftersom hårdvaru-, virtuella och mjukvarubrandväggar hanteras olika. Sedan mars 2025 begränsas virtuella, mjukvaru- och cloud BYOL-licenser av CPU-kärnor; den tidigare RAM-gränsen gäller inte längre. Det betyder inte att obegränsat RAM kompenserar för dålig sizing av CPU, storage eller NIC. Serienummer, core-licens, support och subscription måste fortfarande passa instansen.
Sophos Firewall - Baslicens är lämplig för grundlicensen. Förändringen av virtuella licenser och mjukvarulicenser, där RAM inte längre är i fokus för licensgränsen, listas i blogginlägget Sophos Firewall VM & SW - Endast CPU räknas - Ingen mer RAM-gräns.
Vad är viktigt i drift:
- Dokumentlicens och supportstatus.
- Spela in serienummer och registreringsstatus.
- Kontrollera HA licensiering innan du bygger.
- Kontrollera firmware och stödberättigande före uppgraderingar.
- Känn till RMA eller återställningsprocessen för den valda plattformen. Före större uppgraderingar bör Kontrollera Sophos Firewall före SFOS 22 uppgradering också användas eftersom plattformsstöd, lagringsutrymme, backup, HA och gamla VPN-konfigurationer kan vara uppgraderingsrelevanta.
För active-passive HA på virtuella eller Software Appliances kräver Primary en Base Firewall License. I active-active måste båda nodes ha passande och identiska licenser. Detta ska lösas innan klustret byggs, inte under analysen av första failover.
Beslutsmatris
- Klassisk plats med WAN, LAN och DMZ: Mestadels hårdvara. Endast virtuellt med en bra virtualiseringsstrategi.
- Datacenter med befintligt hypervisorteam: Hårdvara är möjlig, virtuellt är ofta vettigt.
- Molnbelastningar i AWS eller Azure: Mer virtuellt eller moln, inte klassisk hårdvara.
- Enkelt stöd och RMA viktigt: Mer hårdvara. Med virtuell eller moln beror mycket på plattformsteamet.
- Många fysiska portar krävs: Mer hårdvara. Endast virtuellt med ren NIC och vSwitch-design.
- Dynamisk skalning och Infrastructure as Code: Mer virtuellt eller moln.
- Små IT-team utan specialiserad hypervisorkunskap: Mestadels hårdvara; Planera virtuella brandväggar noggrant.
- Hyresgäst- eller segmenteringsdesign i datacentret: Hårdvara är möjlig, virtuellt är ofta vettigt.
Vanliga fel
- Kör virtuell brandvägg på överbokad värd.
- Separera inte WAN, LAN och hanteringen på hypervisorn.
- Välj bara hårdvara baserat på pris istället för storlek.
- Att implementera en molnbrandvägg, men inte helt tänka igenom routingtabeller.
- Planera HA men testa inte värd-, lagrings- eller molnfel.
- Skapa säkerhetskopia, men öva aldrig på återställning.
- Kontrollera endast licens- och supportstatus under uppgradering av firmware.
- Aktivera säkerhetsfunktioner som TLS Inspection eller IPS senare, utan prestandareserv.
- Samla endast plattformsteamet, nätverksteamet och brandväggshanterare vid störningar.
Checklista
- Plats tydligt definierad: plats, datacenter eller moln.
- Trafik, bandbredd och säkerhetsfunktioner registrerade för dimensionering.
- Hårdvara, virtuell, mjukvara eller molnvarianter avsiktligt valda.
- Ansvar för att brandvägg, hypervisor, moln och nätverk dokumenteras.
- HA och återställningsdesign kontrolleras.
- Säkerhetskopiera och återställa process testad eller planerad.
- Licens, support och registrering förtydligas.
- Övervakning för brandvägg och underliggande plattform tillgänglig.
- Uppgraderingsbarhet och plattformsstöd kontrolleras.
- Ansvarig för plattform, nätverk, brandvägg, backup och återställning namngiven.