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.
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.
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.
Odpowiednie platformy wirtualne obejmują VMware, Microsoft Hyper-V, KVM, Nutanix Prism i Citrix Hypervisor. Ważne jest, aby platforma, narzędzia do zarządzania i konfiguracja sieci były aktualne i obsługiwane.
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 rozwiązły, 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.
Software Appliance
Software Appliance jest instalowany na własnym sprzęcie. Może to być przydatne w laboratoriach, środowiskach specjalnych lub bardzo ukierunkowanych projektach. W normalnej działalności klienta należy świadomie wybrać ten wariant, ponieważ za doborem sprzętu, sterownikami, częściami zamiennymi, monitorowaniem i wsparciem w większym stopniu odpowiada operator.
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ę.
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
Licencjonowanie należy rozważyć już na wczesnym etapie, ponieważ zapory sprzętowe, wirtualne i programowe mogą być traktowane odmiennie. W przypadku wirtualnych i programowych instancji firewall Sophos szczególnie istotny jest sposób planowania rdzeni CPU, numeru seryjnego, wsparcia i subskrypcji.
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.
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.