Sophos Firewall: sprzęt, wirtualny czy chmura?
Sophos Firewall może działać jako XGS Hardware Appliance, urządzenie wirtualne, Software Appliance lub Cloud Deployment. Technicznie rzecz biorąc, wszędzie działa Sophos Firewall OS, ale model operacyjny nie jest taki sam. Decyzja dotyczy wydajności, wsparcia, projektu portu, HA, odzyskiwania, licencjonowania, monitorowania i tego, kto jest odpowiedzialny za którą platformę w przypadku zakłóceń.
W przypadku nowych projektów nie należy po prostu pytać, który wariant jest tańszy. Ważne jest, który wariant pasuje do lokalizacji, platformy wirtualizacji, architektury chmury i zespołu operacyjnego. Przewodnik doboru Sophos Firewall jest również ważny przy doborze wydajności.
Wybór platformy decyduje także o funkcjach zgodności: Tryb FIPS 140-3 jest dostępny na XGS, obsługiwanych platformach wirtualnych, AWS i Azure, ale nie na Software Appliances ani sprzęcie XG i SG.
Wybierz model operacyjny
Szybka decyzja
- XGS Hardware Appliance: Najczęściej odpowiedni, gdy witryna potrzebuje dedykowanej, wyraźnie obsługiwanej zapory ogniowej z portami fizycznymi.
- Urządzenie wirtualne: Nadaje się głównie, jeśli dostępna jest stabilna platforma wirtualizacji i można wirtualnie oddzielić strefy sieciowe.
- Software Appliance: Zwykle odpowiednie, jeśli Twój własny sprzęt ma być celowo obsługiwany i wspierany jako platforma firewall.
- Cloud Deployment: Najbardziej odpowiedni do ochrony obciążeń w AWS lub Azure lub do łączenia się z sieciami lokalnymi.
Najważniejsza zasada: zapora wirtualna lub chmurowa nie jest darmową przepustką za mniej planowania. CPU, pamięć RAM, pamięć masowa, przełączniki wirtualne, routing, HA, tworzenie kopii zapasowych i monitorowanie muszą być zaplanowane równie dokładnie, jak w przypadku sprzętu.
Kiedy zachować ostrożność
Decyzja nie powinna opierać się wyłącznie na tym, co jest technicznie możliwe. Niektóre środowiska wyglądają elastycznie na papierze, ale stwarzają niepotrzebne ryzyko w działaniu.
- Hypervisor jest już intensywnie wykorzystywany: IPS, TLS Inspection, VPN i rejestrowanie wymagają przewidywalnego CPU i rezerwy we/wy.
- WAN, LAN, DMZ i zarządzanie napotykają to samo fizyczne wąskie gardło: Logicznie czysta separacja jest mało pomocna, jeśli rzeczywista ścieżka danych jest przeciążona lub niepoprawnie podzielona na segmenty.
- Żaden zespół nie czuje się współodpowiedzialny za hypervisora i zaporę ogniową: Incydenty pozostają pomiędzy zespołami zajmującymi się platformą, siecią i zaporą ogniową.
- HA zaplanowano jedynie jako pole wyboru: Bez testów hosta, pamięci masowej, sieci i przywracania wysoka dostępność nie zostanie udowodniona.
- Routing w chmurze nie jest w pełni udokumentowany: Zapora chroni tylko ruch, który jest przez nią faktycznie kierowany.
- Przywracanie nigdy nie było praktykowane: Kopia zapasowa jest niezawodna tylko wtedy, gdy przywracanie zostało realistycznie przetestowane lub przynajmniej odpowiednio zaplanowane. W takich przypadkach XGS Hardware Appliance jest często nie mniej nowoczesnym, ale po prostu solidniejszym rozwiązaniem operacyjnym. Z drugiej strony zapora wirtualna lub chmurowa może być bardzo przydatna, jeśli platforma, projekt sieci, monitorowanie i obowiązki są jasno określone.
Porównaj platformy
XGS Hardware Appliance
XGS Hardware Appliance jest zwykle najbardziej planowalnym wariantem dla klasycznych lokalizacji. Sprzęt, porty, wsparcie, RMA, cykl życia i zapora systemowa tworzą skoordynowany system.
Zalety:
- dedykowany sprzęt firewall,
- stałe wyposażenie portów i możliwości rozbudowy,
- jasne przypisanie łącza i zarządzania WAN, LAN, DMZ, HA,
- łatwy proces wsparcia i wymiany sprzętu,
- brak zależności od zasobów hypervisora,
- Dobrze nadaje się do oddziałów, centrali i zapór brzegowych. Największą zaletą jest działanie: jeśli wystąpi problem, nie musisz najpierw wyjaśniać, czy przyczyną jest hypervisor, vSwitch, pamięć masowa, routing w chmurze czy sama zapora sieciowa. Dla wielu lokalizacji MŚP jest to ważniejsze niż maksymalna elastyczność.
Urządzenie wirtualne
Wirtualny Sophos Firewall ma sens, jeśli istnieje już czysta platforma wirtualizacji, a zapora sieciowa ma zostać zintegrowana z centrum danych, środowiskiem wielodostępnym lub projektem wewnętrznej segmentacji.
Obsługiwane platformy wirtualne obejmują VMware, Microsoft Hyper-V, KVM, Nutanix Prism i Citrix Hypervisor. Przed wdrożeniem należy sprawdzić konkretną wersję platformy w aktualnych informacjach zgodności Sophos. Sophos podaje minimum: jeden vCPU, 4 GB RAM, dwie vNIC, dysk podstawowy 32 GB i dysk raportów 80 GB. Są to minima instalacyjne, a nie zalecenie sizingu dla ruchu inspekcyjnego w produkcji.
Ważne pytania operacyjne:
- Czy zasoby CPU są gwarantowane, czy też znacznie przekroczone?
- Czy pamięć RAM i pamięć masowa są wystarczająco duże?
- Czy wirtualne karty sieciowe i grupy portów są wyraźnie oddzielone?
- Czy istnieją dedykowane ścieżki sieciowe dla WAN, LAN, DMZ, HA i zarządzania?
- Czy wymagany jest tryb promiscuous, trunking VLAN lub SR-IOV?
- Czy istnieje koncepcja czystego tworzenia kopii zapasowych i przywracania?
- Czy jest jasne, kto wspólnie rozwiązuje problemy z hypervisorem, pamięcią masową i zaporą sieciową?
Wirtualna zapora sieciowa może działać bardzo dobrze. Jednak sytuacja szybko staje się problematyczna, gdy działa na przeciążonym hoście lub gdy WAN, LAN i zarządzanie wyglądają tylko na logicznie czyste, ale fizycznie przechodzą przez te same wąskie gardła.
⚠️ Snapshoty hypervisora ani backupy dostawcy platformy wirtualizacyjnej nie są wspieranym zamiennikiem zintegrowanego backupu Sophos. Aby uzyskać wspierany restore, konfigurację należy zapisać w Backup & Firmware > Backup & Restore. Backupy platformy mogą istnieć dodatkowo, ale nie mogą być jedyną ścieżką recovery.
Software Appliance
Software Appliance instaluje się na dedykowanym sprzęcie x86-64. Może to być przydatne w laboratoriach, środowiskach specjalnych lub bardzo ukierunkowanych projektach. W produkcji ten model trzeba wybrać świadomie, ponieważ sprzęt, sterowniki, części zamienne, monitoring i wsparcie są w dużej mierze odpowiedzialnością operatora.
Instalacja formatuje i ponownie partycjonuje dysk, usuwając istniejący system operacyjny oraz wszystkie pliki. Dla Software Appliance z SFOS 22 Sophos wymaga Legacy BIOS, co najmniej 4 GB RAM, dwóch interfejsów sieciowych i co najmniej 32 GB przestrzeni; zalecane jest 64 GB. Jeśli wymagania minimalne nie są spełnione, firewall może przejść w tryb fail-safe.
Jeśli appliance uruchamia się już w trybie Failsafe, przed zmianą zasobów należy zapisać przyczynę wykrytą przez SFOS za pomocą runbooka Diagnostyka Sophos Firewall w trybie Failsafe.
Sprawdź:
- Czy sprzęt nadaje się do pracy ciągłej?
- Czy karty sieciowe, pamięć masowa i konfiguracja BIOS/UEFI są odpowiednie?
- Czy istnieje sprzęt zastępczy?
- Czy proces instalacji i odzyskiwania jest udokumentowany?
- Kto jest odpowiedzialny za błędy sprzętowe?
W przypadku standardowych lokalizacji często łatwiej jest zastosować XGS Hardware Appliance. W specjalnych przypadkach technicznych Software Appliance może być nadal odpowiedni, jeśli zespół operacyjny dobrze zna platformę.
Cloud Deployment
Wdrożenia w chmurze są szczególnie przydatne, gdy obciążenia w AWS lub Azure wymagają ochrony lub gdy sieci w chmurze są połączone z lokalizacjami lokalnymi. W chmurze ważne są inne pytania niż w tradycyjnej lokalizacji.
Zaplanuj:
- Projektowanie VPC/VNet,
- tablice routingu,
- Strefy Dostępności,
- Elastyczne adresy IP lub publiczne adresy IP,
- Site-to-Site VPN lub SD-WAN,
- Rejestrowanie i centralna ocena,
- Koszty chmury, np. przechowywanie, ruch i projekt HA,
- Odpowiedzialność operacyjna pomiędzy zespołem zajmującym się chmurą a zespołem zapory ogniowej.
Zapora sieciowa w chmurze nie zastępuje czystego projektu sieci w chmurze. Chronione są tylko ścieżki faktycznie trasowane przez zaporę.
Zaplanuj eksploatację i odzyskiwanie
Wydajność i rozmiar
Jeśli chodzi o sprzęt, wydajność zależy od wybranego modelu. W przypadku wdrożeń wirtualnych, oprogramowania i chmur wydajność jest w większym stopniu zależna od platformy.
Szczególnie istotne:
- wykonanie CPU i rezerwacja CPU,
- RAM,
- opóźnienie przechowywania,
- wirtualne karty sieciowe,
- ścieżka sieciowa hypervisora lub chmury,
- liczba sesji,
- TLS Inspection,
- IPS,
- przepustowość VPN,
- Rejestrowanie i raportowanie.
Dlatego wartości zawarte w arkuszach danych należy zawsze czytać w kontekście. Przepustowość zapory sieciowej bez inspekcji zabezpieczeń nie jest taka sama jak w przypadku modułu Ochrona przed zagrożeniami, TLS Inspection lub IPsec VPN przy rzeczywistym obciążeniu. Wyjaśniono różnice Sophos Firewall Poprawnie zinterpretuj dane dotyczące wydajności.
HA i odzyskiwanie
Wysoka dostępność różni się znacznie w zależności od platformy. Jeśli chodzi o sprzęt, HA jest zwykle łatwiejszy do zrozumienia: dwa urządzenia, łącze HA, zdefiniowane interfejsy, przejrzyste urządzenie zastępcze. W przypadku wdrożeń wirtualnych i chmurowych pojawiają się dodatkowe pytania:
- Czy węzły HA działają na różnych hostach?
- Czy pamięć masowa, sieć i hypervisor są naprawdę zbędne?
- Czy wirtualne adresy MAC i reguły vSwitch są kompatybilne?
- Czy są jakieś zależności od routingu w chmurze lub równoważenia obciążenia?
- Czy kopie zapasowe i przywracanie działają na nowej instancji?
- Czy przetestowano awarię hosta lub strefy dostępności?
Podstawy wariantów HA można znaleźć w Konfigurowanie wysokiej dostępności Sophos Firewall (HA). Aby odzyskać, wymagana jest lektura Sophos Firewall Utwórz lub przywróć kopię zapasową.
Licencjonowanie i wsparcie
Licencje trzeba sprawdzić wcześnie, ponieważ firewalle sprzętowe, wirtualne i programowe są traktowane odmiennie. Od marca 2025 r. licencje wirtualne, programowe i cloud BYOL są ograniczone liczbą rdzeni CPU; wcześniejszy limit RAM już nie obowiązuje. Nie oznacza to, że dowolna ilość RAM kompensuje zły sizing CPU, storage lub NIC. Numer seryjny, licencja na rdzenie, wsparcie i subskrypcja nadal muszą odpowiadać instancji.
Sophos Firewall - Licencja podstawowa jest odpowiednia dla podstaw licencji podstawowej. Zmiany dotyczące licencji wirtualnych i oprogramowania, w przypadku których pamięć RAM nie jest już przedmiotem limitu licencji, są wymienione w poście na blogu Sophos Firewall VM & SW – Liczy się tylko CPU – Koniec z limitem pamięci RAM.
Co jest ważne w działaniu:
- Dokumentuj status licencji i wsparcia.
- Czysto zapisz numer seryjny i status rejestracji.
- Przed rozpoczęciem budowy sprawdź licencję HA.
- Przed aktualizacją sprawdź dostępność oprogramowania sprzętowego i wsparcia.
- Zapoznaj się z procedurą RMA lub procesem odzyskiwania dla wybranej platformy. Przed większymi aktualizacjami należy również użyć Sprawdź Sophos Firewall przed aktualizacją SFOS 22, ponieważ obsługa platformy, przestrzeń dyskowa, kopie zapasowe, HA i stare konfiguracje VPN mogą być istotne w przypadku aktualizacji.
W active-passive HA na appliance wirtualnych lub programowych node Primary wymaga Base Firewall License. W active-active oba nodes muszą mieć odpowiednie i identyczne licencje. Należy to rozstrzygnąć przed budową klastra, a nie podczas analizy pierwszego failoveru.
Macierz decyzyjna
- Klasyczna lokalizacja z WAN, LAN i DMZ: Głównie sprzęt. Wirtualny tylko z dobrą strategią wirtualizacji.
- Centrum danych z istniejącym zespołem hypervisorów: Sprzęt jest możliwy, wirtualnie często ma sens.
- Obciążenia w chmurze w AWS lub Azure: Bardziej wirtualny lub chmurowy, a nie klasyczny sprzęt.
- Łatwe wsparcie i ważne RMA: Więcej sprzętu. W przypadku rozwiązań wirtualnych lub chmurowych wiele zależy od zespołu obsługującego platformę.
- Wymaganych wiele portów fizycznych: Więcej sprzętu. Tylko wirtualne z czystą kartą sieciową i projektem vSwitch.
- Skalowanie dynamiczne i Infrastructure as Code: Bardziej wirtualne lub w chmurze.
- Mały zespół IT bez specjalistycznej wiedzy na temat hypervisora: Głównie sprzęt; Starannie planuj wirtualne zapory sieciowe.
- Projekt najemcy lub segmentacji w centrum danych: Sprzęt jest możliwy, wirtualnie często ma sens.
Typowe błędy
- Uruchom wirtualną zaporę ogniową na przepełnionym hoście.
- Nie oddzielaj WAN, LAN i zarządzania na hypervisorze.
- Wybierz sprzęt wyłącznie na podstawie ceny, a nie rozmiaru.
- Wdrażanie zapory sieciowej w chmurze, ale nie do końca przemyślenie tabel routingu.
- Zaplanuj HA, ale nie testuj awarii hosta, pamięci masowej ani chmury.
- Utwórz kopię zapasową, ale nigdy nie ćwicz przywracania.
- Sprawdź status licencji i wsparcia tylko podczas aktualizacji oprogramowania sprzętowego.
- Aktywuj później funkcje bezpieczeństwa, takie jak TLS Inspection lub IPS, bez rezerwy wydajności.
- Łącz zespół platformy, zespół sieciowy i menedżerów zapór firewall tylko w przypadku zakłóceń.
Lista kontrolna
- Jasno określona lokalizacja: lokalizacja, centrum danych lub chmura.
- Funkcje ruchu, przepustowości i bezpieczeństwa rejestrowane w celu zmiany rozmiaru.
- Celowo wybrane warianty sprzętu, wirtualnego, oprogramowania lub chmury.
- Udokumentowana odpowiedzialność za firewall, hypervisor, chmurę i sieć.
- Sprawdzono HA i projekt odzyskiwania.
- Przetestowano lub zaplanowano proces tworzenia kopii zapasowych i przywracania.
- Wyjaśniono licencję, wsparcie i rejestrację.
- Dostępne monitorowanie zapory ogniowej i platformy bazowej.
- Sprawdzono możliwość aktualizacji i obsługę platformy.
- Wyznaczona osoba odpowiedzialna za platformę, sieć, zaporę ogniową, tworzenie kopii zapasowych i przywracanie.