Sophos Firewall: sprzęt, maszyna wirtualna czy chmura?

Sophos Firewall może działać jako urządzenie XGS Appliance, urządzenie wirtualne, Software Appliance lub Cloud Deployment. Wszystkie te warianty korzystają z Sophos Firewall OS, ale różnią się modelem eksploatacji. Wybór wpływa na wydajność, wsparcie, projekt interfejsów i portów sieciowych, HA, odzyskiwanie, licencjonowanie, monitorowanie oraz podział odpowiedzialności za platformę w razie awarii.

W nowych projektach nie należy kierować się wyłącznie ceną. Ważne jest dopasowanie wariantu do lokalizacji, platformy wirtualizacji, architektury chmury i zespołu operacyjnego. Przy doborze zasobów do wymaganej wydajności należy również korzystać z przewodnika doboru zasobów Sophos Firewall.

Wybór platformy decyduje także o funkcjach zgodności: Tryb FIPS 140-3 jest dostępny na urządzeniach XGS Appliance, obsługiwanych platformach wirtualnych, AWS i Azure, ale nie na Software Appliances ani sprzęcie XG i SG.

Wybierz model operacyjny

Szybka decyzja

• Urządzenie XGS Appliance: Zwykle odpowiednie, gdy dana lokalizacja potrzebuje dedykowanej zapory z portami fizycznymi i jasno określonym zakresem wsparcia.
• Urządzenie wirtualne: Zwykle odpowiednie, gdy dostępna jest stabilna platforma wirtualizacji, a strefy sieciowe można prawidłowo odseparować w środowisku wirtualnym.
• Software Appliance: Zwykle odpowiednie, gdy świadomie wybiera się własny sprzęt jako platformę zapory i zapewnia jego eksploatację oraz wsparcie.
• Cloud Deployment: Zwykle odpowiednie do ochrony obciążeń w AWS lub Azure albo do łączenia ich z sieciami lokalnymi.

Najważniejsza zasada: zapora wirtualna lub chmurowa nie zwalnia z dokładnego planowania. CPU, pamięć RAM, pamięć masową, przełączniki wirtualne, routing, HA, kopie zapasowe i monitorowanie trzeba zaplanować równie starannie jak w przypadku urządzenia sprzętowego.

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.

• Hiperwizor jest już silnie obciążony: IPS, TLS Inspection, VPN i rejestrowanie zdarzeń wymagają przewidywalnej rezerwy zasobów CPU oraz wydajności operacji wejścia/wyjścia.
• WAN, LAN, DMZ i zarządzanie korzystają z tego samego fizycznego wąskiego gardła: Poprawna separacja logiczna niewiele pomaga, jeśli rzeczywista ścieżka danych jest przeciążona lub nieprawidłowo podzielona na segmenty.
• Żaden zespół nie czuje się współodpowiedzialny za hiperwizor i zaporę: Obsługa incydentów utknie pomiędzy zespołami odpowiedzialnymi za platformę, sieć i zaporę.
• HA potraktowano jedynie jako punkt do odhaczenia: Bez testów hostów, pamięci masowej, sieci i przywracania nie można potwierdzić wysokiej dostępności.
• Routing w chmurze nie jest w pełni udokumentowany: Zapora chroni tylko ruch, który faktycznie jest przez nią kierowany.
• Nigdy nie przećwiczono przywracania: Na kopii zapasowej można polegać tylko wtedy, gdy przywracanie zostało przetestowane w realistycznych warunkach lub przynajmniej właściwie zaplanowane.

W takich przypadkach urządzenie XGS Appliance jest często nie tyle mniej nowoczesne, ile po prostu stanowi solidniejsze rozwiązanie operacyjne. 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 Appliance

Urządzenie XGS Appliance jest zwykle najbardziej przewidywalnym wariantem dla tradycyjnych lokalizacji. Sprzęt, porty sieciowe, wsparcie, RMA, cykl życia i system operacyjny zapory tworzą spójne rozwiązanie.

Oferta sprzętu fizycznego Sophos obejmuje różne potrzeby: od użytkowników domowych i małych firm po duże przedsiębiorstwa. Dobór urządzenia XGS Appliance zależy od ruchu, funkcji ochrony, portów i wymagań HA. W razie potrzeby poproś dział sprzedaży Sophos lub partnera o sprawdzenie wyboru względem tych wymagań. Przydatność w sieci domowej nie oznacza automatycznie, że na wybranym sprzęcie wolno używać bezpłatnej licencji Home.

Zalety:

• dedykowany sprzęt zapory,
• określona konfiguracja portów sieciowych i możliwości rozbudowy,
• jednoznaczne przypisanie interfejsów do WAN, LAN, DMZ, łącza HA i zarządzania,
• prosty proces wsparcia i wymiany sprzętu,
• brak zależności od zasobów hiperwizora,
• dobre dopasowanie do oddziałów, centrali i zapór brzegowych.

Największa zaleta dotyczy eksploatacji: w razie problemu nie trzeba najpierw ustalać, czy przyczyną jest hiperwizor, vSwitch, pamięć masowa, routing w chmurze czy sama zapora. Dla wielu lokalizacji małych i średnich przedsiębiorstw jest to ważniejsze niż maksymalna elastyczność.

Urządzenie wirtualne

Wirtualny Sophos Firewall ma sens, gdy istnieje już prawidłowo zaprojektowana platforma wirtualizacji, a zapora ma zostać zintegrowana z centrum danych, środowiskiem wielodzierżawnym lub projektem segmentacji wewnętrznej.

Udostępnia w postaci zwirtualizowanej funkcje bezpieczeństwa SFOS dostępne na urządzeniach sprzętowych, w tym ochronę opartą na tożsamości. Decyzje dotyczące bezpieczeństwa uwzględniają więc tożsamość użytkownika, a nie tylko adres sieciowy. Organizacje i dostawcy zarządzanych usług bezpieczeństwa (MSSP) mogą skupić ochronę sieci wirtualnych centrów danych lub biur na jednej wirtualnej zaporze. Dostępne funkcje zależą od licencji i obsługiwanej platformy; nie oznacza to identycznej akceleracji sprzętowej ani takiej samej przepustowości jak w XGS Appliance.

Wdrożenia wirtualne i chmurowe z SFOS mogą za pośrednictwem Sophos Endpoint Security Heartbeat uwzględniać także stan bezpieczeństwa zarządzanych urządzeń końcowych w decyzjach dotyczących dostępu. Wymaga to odpowiednich uprawnień licencyjnych dla urządzeń końcowych i zapory, rejestracji w tej samej, właściwej organizacji oraz jawnie skonfigurowanej reakcji. Ochrona oparta na tożsamości nie jest równoważnym mechanizmem oceny stanu bezpieczeństwa urządzeń końcowych; sama rejestracja nie potwierdza ani izolacji, ani zablokowania wszystkich ścieżek ruchu. Wymagania wstępne, ścieżki reagowania i kontrole skuteczności opisuje instrukcja Security Heartbeat i Synchronized Security.

Sophos oferuje także centralne zarządzanie urządzeniami Sophos Firewall. Przegląd platform SFOS 22 używa nazwy Sophos Fusion (previously Sophos Central), a przegląd SFOS 23 — Sophos Central. Różnica nazw nie dowodzi, że centralne zarządzanie wprowadzono w SFOS 23. Podczas planowania sprawdź usługę używaną w swoim portalu zarządzania i wymagania dotyczące dodania zapory; sama centralna analiza logów nie jest centralnym zarządzaniem urządzeniami.

Do rozważanych platform wirtualnych należą VMware, Microsoft Hyper-V, KVM, Nutanix Prism i Citrix Hypervisor. Przed wdrożeniem należy sprawdzić konkretną wersję platformy w aktualnych informacjach Sophos o zgodności. Sophos podaje następujące wymagania minimalne: jeden vCPU, 4 GB RAM, dwie vNIC, dysk podstawowy 32 GB i dysk raportów 80 GB. Są to minima instalacyjne, a nie zalecany dobór zasobów do inspekcji ruchu produkcyjnego.

Weryfikacja nie może kończyć się na rodzinie produktów. Na przykład dla Nutanix Sophos wymaga AOS 6.5.x lub nowszego wydania LTS, dołączonej wersji AHV, zgodnej wersji Prism Central oraz klastra AHV zarejestrowanego w Prism Central. KVM wymaga hosta x86 z aktualnym jądrem Linux i włączoną obsługą Intel VT lub AMD-V. Jeśli zwiększa się liczbę vCPU i RAM z powodu większego obciążenia, należy również zaplanować większy dysk raportów dla dodatkowych logów.

Ważne pytania operacyjne:

• Czy zasoby CPU są gwarantowane, czy przydzielono maszynom wirtualnym znacznie więcej zasobów niż host może zapewnić?
• Czy pojemność pamięci RAM i zasoby pamięci masowej są odpowiednio dobrane?
• Czy wirtualne karty sieciowe i grupy portów są prawidłowo odseparowane?
• 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 spójny plan tworzenia kopii zapasowych i przywracania?
• Czy wiadomo, kto wspólnie diagnozuje problemy z hiperwizorem, pamięcią masową i zaporą?

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.

⚠️ Migawki hiperwizora ani kopie zapasowe wykonywane narzędziami dostawcy platformy wirtualizacyjnej nie są obsługiwanym zamiennikiem zintegrowanej funkcji kopii zapasowej Sophos. Aby umożliwić przywracanie zgodnie z obsługiwaną procedurą, należy zapisać konfigurację w Backup & Firmware > Backup & Restore. Kopie platformy mogą stanowić dodatkowe zabezpieczenie, ale nie mogą być jedyną metodą odzyskiwania.

Software Appliance

Software Appliance instaluje się na dedykowanym sprzęcie x86-64. Ten wariant może być przydatny w laboratoriach, środowiskach specjalnych lub projektach o ściśle określonych wymaganiach. W środowiskach produkcyjnych należy wybierać go świadomie, ponieważ dobór sprzętu, sterowniki, części zamienne, monitorowanie i wsparcie pozostają w dużej mierze odpowiedzialnością operatora.

SFOS na odpowiednim sprzęcie fizycznym zapewnia reguły i polityki zapory, reagowanie na zagrożenia oraz routing statyczny, SD-WAN i dynamiczny, zależnie od odpowiednich licencji i doboru zasobów platformy. Nazwy producentów, takie jak Dell lub HP, są przykładami, a nie zweryfikowaną listą zgodności poszczególnych modeli.

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.

Rozbieżne wymagania dotyczące dysku: Przeglądy platform SFOS 22 i 23 podają minimum 10 GB dla własnego sprzętu. Szczegółowe wymagania instalacyjne Software Appliance dla SFOS 22 wskazują natomiast co najmniej 32 GB i zalecają 64 GB. Ta instrukcja świadomie przyjmuje bardziej szczegółowy i ostrożny wymóg instalacyjny: co najmniej 32 GB, zalecane 64 GB. Nie planuj instalacji z dyskiem 10 GB; przed instalacją sprawdź również wymagania wybranej wersji SFOS. Sprzeczność wymaga wyjaśnienia dla konkretnej platformy i wersji SFOS.

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ć urządzenie XGS 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 trzeba chronić obciążenia w AWS lub Azure albo połączyć sieci chmurowe z lokalizacjami lokalnymi. W chmurze należy uwzględnić inne kwestie niż w tradycyjnej lokalizacji.

Zaplanuj:

• projekt VPC/VNet,
• tablice routingu,
• strefy dostępności,
• Elastic IPs lub Public IPs,
• Site-to-Site VPN lub SD-WAN,
• rejestrowanie zdarzeń i centralną analizę,
• koszty chmury związane z instancją, pamięcią masową, ruchem i architekturą HA,
• podział odpowiedzialności operacyjnej między zespołem chmurowym a zespołem zapory.

Zapora sieciowa w chmurze nie zastępuje czystego projektu sieci w chmurze. Chronione są tylko ścieżki faktycznie trasowane przez zaporę. Decyzje dotyczące wdrożenia i routingu opisują instrukcje Sophos Firewall w AWS oraz Sophos Firewall w Azure.

Instalacja urządzenia wirtualnego lub Software Appliance

Pobierz obraz bezpośrednio ze strony Sophos Firewall Installers. W sekcji Virtual Installers wybierz odpowiedni pakiet OVF dla Citrix lub VMware, pakiet VHD dla Hyper-V albo pakiet QCOW2 dla KVM, Proxmox lub Nutanix. Dla własnego sprzętu użyj zamiast tego obrazu ISO z sekcji Software Installers.

Przed importem sprawdź, czy wskazana wyżej strona pobierania została otwarta przez HTTPS, czy pakiet pobrano bez korzystania z zewnętrznego serwera lustrzanego i czy archiwum rozpakowano w całości bez błędów. W pakiecie OVF manifest, plik OVF i oba pliki VMDK muszą pozostać razem. Jeśli import zgłosi niezgodność manifestu lub sumy kontrolnej, przerwij i ponownie pobierz pakiet bezpośrednio od Sophos. Przy wewnętrznym przesyłaniu pliku można dodatkowo zapisać wartość SHA-256 bezpośrednio po pobraniu i porównać ją w systemie docelowym. Pozwala to wykryć błędy transmisji, ale nie zastępuje podpisu producenta.

Przed importem wymagane są co najmniej: 1 vCPU, 4 GB RAM, dwie vNIC, dysk podstawowy 32 GB i dysk raportów 80 GB. Niedostateczne zasoby powodują przejście w tryb fail-safe. Przed zmianą przydziału sprawdź zakupione uprawnienia do zasobów CPU i innych zasobów; minima instalacyjne nie stanowią doboru zasobów do produkcji. Zwiększ pojemność dysku raportów, gdy dodatkowe CPU/RAM umożliwiają generowanie większej ilości logów. Migawki hiperwizora i narzędzia do kopii zapasowych dostawcy platformy nie są obsługiwanymi kopiami zapory; używaj funkcji kopii zapasowej SFOS.

Poniższe procedury instalacji należy sprawdzić dla konkretnej kombinacji platformy i SFOS; udana instalacja nie potwierdza jeszcze działającej ścieżki produkcyjnej ani przywracania działania. Najpierw sprawdź aktualne wsparcie platformy, systemu operacyjnego, narzędzi zarządzania i obrazu. Zweryfikuj instalację na nowej, izolowanej maszynie wirtualnej przed skierowaniem przez nią ruchu produkcyjnego. Do czasu akceptacji pozostaw istniejącą zaporę i trasy produkcyjne bez zmian.

Przeglądy platform dla SFOS 22 i 23 wymieniają dodatkowo dla rodziny Citrix narzędzie zarządzania XCP-ng-Center jako alternatywę dla XenCenter, a dla VMware także VMware Workstation jako alternatywę dla opisanej tutaj ścieżki ESXi/vSphere. Wymienione tam opcje nie stanowią potwierdzenia aktualnego wsparcia ani ogólnego dopuszczenia wszystkich wersji XCP-ng. Przed wyborem którejkolwiek z tych alternatyw należy potwierdzić wsparcie dla konkretnych wersji hosta, platformy i narzędzia zarządzania. Jeśli wsparcie pozostaje niejasne, należy przerwać wdrożenie i zastosować ścieżkę, której wsparcie zostało potwierdzone. Poniższe kroki dla XenCenter i ESXi/vSphere nie są instrukcją instalacji tych alternatyw; w szczególności nie wolno traktować procedury ESXi jako instrukcji dla Workstation.

Citrix Hypervisor i XenCenter

Wymagania wstępne: Citrix Hypervisor jest już zainstalowany na osiągalnym hoście, a XenCenter na urządzeniu administracyjnym. Sprawdź obsługiwane wersje hosta, systemu operacyjnego i narzędzia. Zapisz rozpakowany pakiet Citrix OVF w miejscu, z którego XenCenter może odczytać wszystkie jego pliki.

1. W XenCenter kliknij prawym przyciskiem docelowy zasób i wybierz Import > Browse. Wskaż plik OVF, kliknij Open, a następnie Next.
2. W Import VM(s) to wybierz miejsce docelowe lub określ Home Server, a następnie kliknij Next. Wybierz repozytorium pamięci masowej dla obu dysków.
3. Świadomie przypisz interfejsy sieciowe: PortA do izolowanej sieci administracyjnej/LAN, a kartę od strony WAN do odrębnej, zaplanowanej sieci WAN/testowej. Nie udostępniaj fabrycznego WebAdmin w internecie.
4. Opcja Verify manifest content w kreatorze importu jest opcjonalna; zachowaj manifest i wyjaśniaj każdą niezgodność zamiast ją pomijać. Kliknij Next. W OS Fixup Settings pozostaw zaznaczone Don’t use Operating System Fixup.
5. Sprawdź podsumowanie i kliknij Finish. Potwierdź pomyślny import, obecność obu dysków oraz poprawne przypisanie obu kart sieciowych. Dopiero wtedy kliknij prawym przyciskiem tę nową VM i wybierz Start. Otwórz konsolę i wykonaj opisaną niżej wspólną procedurę pierwszego dostępu.

VMware ESXi i vSphere Client

Wymagania wstępne: na serwerze działa wersja ESXi objęta aktualnym wsparciem, a administrator ma działającą sesję zarządzania vSphere Client z dostępem sieciowym do serwera. Rozpakuj pakiet VMware na urządzeniu administracyjnym. Oznaczenia starszych wersji sprzętu wirtualnego nie potwierdzają aktualnego wsparcia ESXi 4 ani 5.

Świadomie wybierz szablon OVF:

• sf_virtual i sf_virtual_vm7: starsza wersja sprzętu 7, PCNet32 (Vlance), wirtualny deskryptor łącza 10 Mbps, half duplex, ustawienie stałe.
• sf_virtual_vm8: wersja sprzętu 8, E1000E, 1000 Mbps, full duplex, auto-negotiation On.
• sf_virtual_vm8_paravirtual: wersja sprzętu 8, VMXNET 3, 10000 Mbps, full duplex, auto-negotiation Off. Jeśli sterownik VMXNET 3 nie działa w danym wdrożeniu, użyj E1000E jako udokumentowanego wariantu zastępczego.
• sf_virtual_virtualbox nie jest szablonem VMware. Powyższe deskryptory łącza opisują właściwości wirtualnych kart sieciowych, a nie gwarantowaną przepustowość zapory.

1. W vSphere Client kliknij prawym przyciskiem miejsce wdrożenia i wybierz Deploy OVF Template > Local file > Choose files. Wskaż wybrany OVF wraz z sf_virtual-disk1.vmdk, sf_virtual-disk2.vmdk i sf_virtual.mf; kliknij Open > Next.
2. Podaj nazwę i lokalizację, wybierz zasób obliczeniowy i sprawdź szczegóły, przechodząc dalej przyciskiem Next.
3. Wybierz datastore i format dysków wirtualnych. Thick Provision Lazy Zeroed przydziela miejsce podczas tworzenia i zeruje bloki przy pierwszym zapisie. Thick Provision Eager Zeroed przydziela i zeruje miejsce podczas tworzenia, co może potrwać dłużej. Thin Provision przydziela miejsce w miarę potrzeb, oszczędzając przestrzeń; monitoruj rzeczywistą pojemność datastore. Ani opis formatów dysków, ani ta procedura nie potwierdzają wsparcia Sophos dla Fault Tolerance ani powszechnego ograniczenia konwersji dysków.
4. Świadomie przypisz obie sieci źródłowe, umieszczając PortA w izolowanej sieci administracyjnej. Sprawdź całą konfigurację i kliknij Finish. Poczekaj na pomyślne zakończenie wdrożenia; sprawdź pojemność obu dysków oraz przypisania i stan połączenia kart sieciowych.
5. Wybierz Actions > Power > Power on, otwórz konsolę i wykonaj wspólną procedurę pierwszego dostępu.

Hyper-V Manager

Wymagania wstępne: obsługiwany host Hyper-V i Hyper-V Manager na urządzeniu administracyjnym mającym dostęp sieciowy do hosta. Rozpakuj pakiet Hyper-V i umieść oba pliki VHD w pamięci masowej dostępnej dla hosta; ścieżka widoczna tylko na komputerze administratora nie wystarczy w przypadku hosta zdalnego.

1. Otwórz Action > Connect to Server, a następnie Action > New > Virtual Machine. W kreatorze wybierz nazwę i lokalizację, Generation 1 oraz Startup memory wynoszące co najmniej 4096 MB.
2. Dla pierwszej karty wybierz izolowany administracyjny przełącznik wirtualny. Wybierz Use an existing virtual hard disk > Browse > PRIMARY-DISK.vhd > Open. Sprawdź ustawienia i kliknij Finish; jeszcze nie uruchamiaj VM.
3. Kliknij nową VM prawym przyciskiem, otwórz Settings i w Hardware wybierz Network Adapter > Add. Przypisz drugą kartę do odrębnej zaplanowanej sieci i kliknij Apply.
4. Wybierz SCSI Controller > Hard Drive > Add > Virtual hard disk > Browse, wskaż AUXILIARY-DISK.vhd, a następnie wybierz Open > OK. Sprawdź podstawowy dysk rozruchowy, dodatkowy dysk SCSI, oba przełączniki i pojemność dysków.
5. Kliknij VM prawym przyciskiem i wybierz Connect; uruchom ją z konsoli. Wykonaj wspólną procedurę pierwszego dostępu.

KVM i Virtual Machine Manager

Wymagania wstępne: host Linux x86 z aktualnym jądrem i włączoną obsługą Intel VT lub AMD-V oraz zainstalowany i dostępny Virtual Machine Manager albo odpowiednie obsługiwane narzędzia zarządzania KVM. Poniższe polecenia tylko odczytują informacje; uruchom je na hoście Linux, nie w konsoli SFOS:

grep --color vmx /proc/cpuinfo
grep --color svm /proc/cpuinfo

Oczekuj flag vmx dla Intel lub svm dla AMD, niekoniecznie obu. Jeśli właściwe sprawdzenie nie zwraca dopasowań, przerwij i sprawdź możliwości CPU, ustawienia wirtualizacji w oprogramowaniu układowym oraz — w przypadku hosta zagnieżdżonego — udostępnienie tych funkcji. Sama widoczność flag nie potwierdza włączenia funkcji w oprogramowaniu układowym ani poprawnego działania KVM. #!sh w starszych instrukcjach jest znacznikiem formatowania, a nie prefiksem polecenia.

1. Rozpakuj archiwum KVM. Otwórz File > New Virtual Machine > Import existing disk image > Browse, wybierz PRIMARY-DISK.qcow2 za pomocą Choose volume, a następnie kliknij Forward.
2. Ustaw Memory (RAM) na co najmniej 4096 MB, a CPU na co najmniej 1, zgodnie z uprawnieniami licencyjnymi i doborem zasobów. Wybierz Customize configuration before install > Finish. Podaj nazwę i kliknij Apply.
3. Jako Network source pierwszej karty wybierz izolowaną sieć administracyjną. Zachowany przykład używa Device model > Hypervisor default; sprawdź, czy wynikowa karta jest obsługiwana, a następnie kliknij Apply. Nie wybieraj wspólnego mostu WAN/LAN bez segmentacji.
4. Wybierz dysk podstawowy, początkowo widoczny jako IDE Disk 1, a następnie Advanced options > Disk bus > VirtIO > Apply.
5. Wybierz Add Hardware > Network, wskaż odrębną zaplanowaną sieć i wybierz Device model > virtio > Finish.
6. Wybierz Add Hardware > Storage > Select or create custom storage > Manage. Wskaż AUXILIARY-DISK.qcow2 za pomocą Choose volume, ustaw Disk bus > VirtIO i kliknij Finish.
7. Przed Begin Installation sprawdź oba dyski, ich magistrale i pojemność oraz przypisania kart sieciowych. Wybierz zaporę i otwórz jej konsolę przyciskiem Open; wykonaj wspólną procedurę pierwszego dostępu.

Proxmox VE: procedura dla pamięci masowej typu directory

Ta procedura oparta na ścieżkach plików dotyczy odpowiedniej pamięci masowej typu directory, a nie dowolnych backendów LVM, ZFS lub Ceph. Najpierw sprawdź /etc/pve/storage.cfg, aby ustalić rzeczywisty identyfikator pamięci masowej, backend i ścieżkę. Jeśli backend nie może używać tych ścieżek plików QCOW2, przerwij i uzyskaj właściwą, obsługiwaną procedurę importu; nie stosuj w nim przykładów dla pamięci katalogowej.

1. Wybierz serwer i Create VM. Podaj Name, zaznacz Do not use any media, dobierz ustawienia System, Hard Disk i CPU do środowiska oraz ustaw Memory (MB) na co najmniej 4096. Domyślne ustawienia Machine, SCSI Controller i Cache zależą od przykładu i nie są uniwersalnymi wymaganiami.
2. Wybierz izolowany administracyjny Bridge. Pozostaw Start after created niezaznaczone, sprawdź ustawienia i kliknij Finish. Zapisz VMID i potwierdź, że jest to nowa, nieużywana testowa VM.
3. Otwórz >_ Shell hosta z odpowiednimi uprawnieniami. Pozostaw wyłączoną tylko tę nową VM, zachowaj kopię /etc/pve/qemu-server/<vmid>.conf i zapisz istniejące przypisania dysków. Nigdy nie usuwaj ani nie zastępuj dysku produkcyjnego. /var/lib/vz/images/108/ jest wyłącznie przykładowym katalogiem dla VMID 108; użyj ścieżki odpowiadającej potwierdzonej pamięci masowej i VMID.
4. Prześlij do tego katalogu rzeczywiście pobrane archiwum KVM i rozpakuj je, na przykład poleceniem unzip ACTUAL_DOWNLOADED_ARCHIVE.zip po zastąpieniu symbolu zastępczego prawdziwą nazwą pliku. Oczekuj plików PRIMARY-DISK.qcow2 i AUXILIARY-DISK.qcow2; historyczna nazwa pliku kompilacji nie jest instrukcją pobrania bieżącej wersji.
5. Otwórz /etc/pve/qemu-server/<vmid>.conf w edytorze tekstu. Wyłącznie w tej wyłączonej, przeznaczonej do testów VM zastąp początkowe przypisanie scsi0 i dodaj przypisanie dysku dodatkowego. Zachowana przykładowa składnia to:

scsi0: vmdisk:<vmid>/PRIMARY-DISK.qcow2,size=32G
scsi1: vmdisk:<vmid>/AUXILIARY-DISK.qcow2,size=80G

Zastąp vmdisk potwierdzonym identyfikatorem pamięci masowej typu directory, a <vmid> rzeczywistym VMID; nie są to wartości, które można zastosować dosłownie. Etykiety size nie powiększają zbyt małego obrazu. Sprawdź, czy rzeczywiste obrazy spełniają wymagania minimalnej pojemności i czy żadne istniejące przypisanie scsi1 nie zostanie nadpisane.

6. W Hardware sprawdź oba miejsca podłączenia dysków, ich pojemność i podstawowy dysk rozruchowy. Użyj Add > Network device, aby dodać drugą kartę do świadomie wybranego, odrębnego Bridge. W Options pozostaw QEMU Guest Agent wyłączony. Ponownie sprawdź przypisania przed Start i otwarciem konsoli.
7. Jeśli edycja jest błędna, pozostaw nową VM wyłączoną i przywróć zapisaną konfigurację po ponownym sprawdzeniu VMID i tożsamości pamięci masowej. W ramach tego wycofania nie usuwaj oryginalnego pliku dysku. Jest to lokalna procedura cofnięcia zmian przed wdrożeniem produkcyjnym, nie metoda odtwarzania działającego środowiska produkcyjnego. Wykonaj wspólną procedurę pierwszego dostępu dopiero po pomyślnym sprawdzeniu poprawionej konfiguracji sprzętowej.

Nutanix Prism Central

Wymagania wstępne: AOS 6.5.x lub nowsze wydanie LTS, dołączona wersja AHV, zgodny Prism Central (PC) i klaster AHV zarejestrowany w PC. Wytyczne platformy wskazują najnowsze wydanie GA (LTS) partnerskiego urządzenia wirtualnego: GA oznacza General Availability, a LTS — Long-Term Support. Sprawdź faktycznie obsługiwane wydanie urządzenia partnerskiego i kombinację platformy; sama strona pomocy SFOS 23 nie określa najnowszego wydania GA. Potwierdź licencjonowane zasoby CPU, co najmniej 4 GB RAM, dwie karty sieciowe i dyski 32 GB/80 GB.

1. Na urządzeniu administracyjnym rozpakuj PRIMARY-DISK.qcow2 i AUXILIARY-DISK.qcow2 z pakietu Virtual Installers: Firewall OS for KVM.
2. W PC otwórz Virtual Infrastructure > Images > Add Image > Add File. Dodaj każdy plik z ustawieniem Image Type > Disk. Kliknij Next, wybierz Placement Method i Select Clusters dla miejsca docelowego, a następnie Save. Po przesłaniu odśwież widok i sprawdź dostępność obu obrazów.
3. Otwórz Infrastructure > VMs > Create VM. W General Configuration ustaw nazwę i strefę czasową; w Compute Details ustaw CPU zgodnie z licencją i wystarczającą ilość RAM. W Disks usuń domyślny CD-ROM wyłącznie z tej nowej VM.
4. Wybierz Add New Disk > Operation > Clone from Image Service > Bus Type > SCSI > Image > PRIMARY-DISK.qcow2 > Add. Powtórz dla AUXILIARY-DISK.qcow2 jako dysku logów; zachowany przykład dla dysku dodatkowego również używa SCSI. Nie przenoś tutaj instrukcji magistrali VirtIO z procedury KVM.
5. W Network Adapters (NIC) > Add New NIC > VLAN Name wybierz izolowany administracyjny VLAN i kliknij Add. Powtórz dla odrębnej, zaplanowanej drugiej sieci. Wskazana w materiale źródłowym opcja łączności DHCP jest opcjonalna; zaplanuj później stałą adresację interfejsów. Sam wybór VLAN nie przydziela adresu IP.
6. W VM Host Affinity > Set Affinity wybierz zatwierdzony host i kliknij Save, a następnie zapisz VM. Oczekuj komunikatu o powodzeniu; przed włączeniem sprawdź oba dyski, ich magistrale i pojemność oraz przypisania kart sieciowych.
7. Włącz nową VM i wybierz Launch console. Wykonaj wspólną procedurę pierwszego dostępu.

Pierwszy dostęp, weryfikacja i bezpieczne wycofanie

Przed pierwszym włączeniem sprawdź przypisanie PortA i PortB do sieci zarządzania, LAN i WAN. Odwrócone przypisania mogą udostępnić WebAdmin bezpośrednio w internecie. Wyłącznie w izolowanym środowisku początkowym udokumentowane fabryczne konto i hasło administratora to admin / admin; konsola prosi o hasło administratora admin. Otwórz https://172.16.16.16:4444 z izolowanego klienta administracyjnego, na przykład 172.16.16.2/24. Zapoznaj się z Sophos End User Terms of Use, zaakceptuj je i kliknij Start setup, aby przejść do rejestracji i konfiguracji podstawowej. Podczas konfiguracji zmień fabryczne dane uwierzytelniające przed udostępnieniem urządzenia innym sieciom, a następnie skorzystaj z instrukcji pierwszych kroków.

Nie zmieniaj domyślnego hasła w CLI przed uruchomieniem asystenta: po takiej zmianie asystent nie wystartuje. Jeśli już do tego doszło, wykonaj konfigurację podstawową ręcznie; nie resetuj skonfigurowanej zapory tylko po to, aby odzyskać kreator. Reset fabryczny usuwa konfigurację i może być świadomie wybraną opcją wyłącznie dla zabezpieczonej, nowej testowej VM bez konfiguracji wymagającej zachowania.

Przed przełączeniem ruchu produkcyjnego sprawdź licencję i numer seryjny, prawidłowy rozruch w konsoli, oba dyski i raportowanie, interfejsy i strefy, obsługiwaną kopię zapasową SFOS oraz brak dostępu do WebAdmin z nieuprawnionej sieci. Są to kontrole do wykonania przez operatora.

Jeśli WebAdmin jest nieosiągalny, nie instaluj systemu ponownie bez uprzedniej diagnostyki. Sprawdź, czy klient znajduje się bezpośrednio w sieci PortA, czy vNIC jest podłączona i czy grupa portów lub most rzeczywiście prowadzi do izolowanej sieci administracyjnej. Potwierdź pełny rozruch w konsoli i wyklucz konflikt adresu 172.16.16.16. PortA nie może znajdować się w publicznej sieci WAN. Brak raportów lub tryb fail-safe wymagają sprawdzenia przypisania dysku raportów, jego magistrali i pojemności, CPU/RAM oraz obu vNIC; przed zmianą zasobów zapisz wykrytą przyczynę zgodnie z procedurą diagnostyki trybu fail-safe.

Jeśli zdecydujesz się wycofać nowe wdrożenie przed uruchomieniem produkcyjnym i żaden ruch produkcyjny nie przechodzi jeszcze przez nową VM, wyłącz ją, cofnij trasy testowe i tymczasowe bramy oraz kontynuuj pracę na niezmienionej istniejącej zaporze. Te kroki dotyczą tylko wycofania, a nie pomyślnie zweryfikowanego przejścia do produkcji. Po uruchomieniu produkcyjnym odzyskiwanie wymaga aktualnej kopii SFOS i udokumentowanej procedury odtworzenia, a nie migawki hiperwizora; skorzystaj z procedury tworzenia kopii zapasowej i przywracania.

Software Appliance na własnym sprzęcie

Sprzęt docelowy wymaga x86-64, Legacy BIOS, co najmniej 4 GB RAM, dwóch kart sieciowych i dysku HDD/SSD 32 GB (zalecane 64 GB). Nośnik USB musi mieć co najmniej 1 GB. Windows/macOS to system stacji służącej do zapisu nośnika, a nie system zachowywany obok SFOS. Pobierz Software Installers: Firewall OS Software ISO for Intel Hardware, rozpakuj archiwum i sprawdź obraz SW ISO oraz integralność przesyłania zgodnie z opisem powyżej. Nie używaj obrazu HW/XGS ani pakietu dysków wirtualnych.

⚠️ Zapis nośnika usuwa całą zawartość wybranego urządzenia USB. Następnie instalacja formatuje i ponownie partycjonuje dysk serwera docelowego, usuwając poprzedni system operacyjny i wszystkie dane. Przed każdą z tych operacji jednoznacznie zidentyfikuj urządzenie na podstawie pojemności i danych identyfikacyjnych, zapisz dane poza nim i sprawdź niezależną metodę przywracania. Przerwij, jeśli urządzenie docelowe nie jest jednoznacznie określone. Po instalacji nie ma automatycznego cofnięcia zmian; odzyskiwanie wymaga osobno zapisanych nośników i danych pierwotnego systemu albo zgodnej kopii SFOS wraz z jej hasłem i powiązanym SSMK.

Windows: Win32 Disk Imager

1. Podłącz USB i ustal jego literę dysku, pojemność oraz dane identyfikacyjne w narzędziu Zarządzanie dyskami systemu Windows; w miarę możliwości odłącz inne dyski wymienne. Pobierz i uruchom Win32 Disk Imager na stacji roboczej.
2. Okno wyboru pliku zwykle filtruje pliki IMG. Zmień filtr na *.* i wybierz rozpakowany plik Sophos SW .ISO.
3. Wybierz potwierdzone urządzenie USB, nie dysk systemowy ani dysk danych. Ponownie porównaj wybrany plik i dysk z zapisanymi danymi identyfikacyjnymi, następnie kliknij Write i potwierdź ostrzeżenie o usunięciu danych. Poczekaj na pomyślne zakończenie i bezpiecznie wysuń nośnik. Skopiowanie ISO jako zwykłego pliku nie tworzy nośnika rozruchowego.

macOS: alternatywny zapis nośnika narzędziami systemowymi

1. W Narzędziu dyskowym zidentyfikuj zewnętrzny USB na podstawie pojemności i danych identyfikacyjnych. Starsze instrukcje pokazują Partitions > Volume scheme: 1 partition > Format: Free Space > Apply; te elementy zależą od wersji i mogą nie istnieć w używanym wydaniu macOS. Nie zakładaj nieudokumentowanego odpowiednika ani nie formatuj innego dysku, aby odtworzyć ten dawny interfejs. Alternatywą jest procedura zapisu nośnika z instrukcji ponownej instalacji systemu, z użyciem tutaj SW ISO zamiast obrazu sprzętowego.
2. W Terminalu przejdź do katalogu z ISO. Przed uruchomieniem zastąp SOPHOS_ISO rzeczywistą nazwą pobranego pliku:

hdiutil convert -format UDRW -o sf.img.dmg SOPHOS_ISO

3. Oczekuj przekonwertowanego pliku sf.img.dmg. Uruchom diskutil list, ponownie zidentyfikuj całe zewnętrzne urządzenie USB i przed zapisem bezpośrednim odmontuj jego woluminy (w Narzędziu dyskowym Unmount, nie wysunięcie). Przerwij, jeśli nie możesz zidentyfikować lub odmontować właściwego urządzenia.
4. Poniższy zapis to szablon, a nie polecenie gotowe do wklejenia. Zastąp PATH_TO_USB potwierdzoną ścieżką całego urządzenia, nigdy partycji ani założonego z góry numeru dysku. Operacja usuwa całą zawartość tego urządzenia:

dd if=./sf.img.dmg of=PATH_TO_USB bs=1m

Użyj sudo tylko wtedy, gdy jest wymagane ze względu na uprawnienia do urządzenia, po ponownym sprawdzeniu celu. Ścieżka do urządzenia w trybie raw dodaje r do potwierdzonej nazwy urządzenia (/dev/diskN staje się /dev/rdiskN); N jest symbolem zastępczym, a nie numerem dysku do skopiowania. Dostęp raw może być szybszy, ale nie czyni operacji bezpieczniejszą. Poczekaj na powrót znaku zachęty i pomyślne zakończenie; wykonaj sync, aby zakończyć oczekujące zapisy, i bezpiecznie wysuń USB przed odłączeniem. W razie błędu przerwij zamiast instalować z nośnika, którego zapis nie został zweryfikowany.

Instalacja i kontrola serwera fizycznego

1. Zaplanuj przestój, zachowaj istniejącą ścieżkę ruchu przez zaporę oraz zewnętrzne kopie zapasowe, sprawdź Legacy BIOS, rozruch z USB i dokładnie zidentyfikuj dysk instalacyjny. W miarę możliwości odłącz niezwiązane z instalacją dyski danych. Podłącz lokalny monitor i klawiaturę oraz, jeśli to potrzebne, odpowiednią konsolę szeregową.
2. Uruchom serwer z przygotowanego USB. Przed wpisaniem y i naciśnięciem Enter przy potwierdzeniu instalatora ponownie sprawdź tożsamość serwera i dysku oraz potwierdź, że poprzedni system i wszystkie dane mogą zostać usunięte. Jeśli dysk docelowy instalatora nie jest jednoznaczny, przerwij. Wykonaj instrukcje do końca, wyjmij USB i uruchom serwer ponownie; pierwszy rozruch może potrwać kilka minut. Nie stosuj instrukcji diod LED urządzeń XGS do tego serwera.
3. Sprawdź wykryte karty sieciowe i zidentyfikuj interfejs zarządzania przed podłączeniem izolowanego klienta administracyjnego z adresem 172.16.16.2/24. Potwierdź prawidłowy rozruch i użyj https://172.16.16.16:4444, Terms of Use oraz Start setup zgodnie z opisem powyżej. Zabezpiecz dane uwierzytelniające, ukończ rejestrację i licencjonowanie oraz zapisz zewnętrzną kopię SFOS przed przełączeniem ruchu.
4. Jeśli USB nie uruchamia systemu, sprawdź, czy zapisano na nim obraz zamiast skopiować plik, czy użyto właściwego obrazu SW i czy wybrano Legacy BIOS oraz rozruch z USB. W przypadku niewykrytych kart sieciowych lub trybu fail-safe zapisz przyczynę podaną w konsoli i przed ponowną instalacją sprawdź wymagania minimalne oraz zgodność sterowników. Jeśli WebAdmin jest nieosiągalny, sprawdź tożsamość karty zarządzania, połączenie, adres klienta, pełny rozruch i konflikty adresów; nigdy nie podłączaj fabrycznego interfejsu zarządzania do publicznej sieci WAN jako obejścia. Przy wyborze następnego kroku korzystaj z wewnętrznych instrukcji: diagnostyka trybu fail-safe, pierwsze kroki oraz kopie zapasowe i przywracanie.

Zaplanuj eksploatację i odzyskiwanie

Wydajność i dobór zasobów

W przypadku urządzenia sprzętowego wydajność zależy od wybranego modelu. W przypadku urządzeń wirtualnych, Software Appliance i wdrożeń chmurowych zależy w większym stopniu od platformy.

Szczególnie istotne są:

• wydajność CPU i rezerwacja zasobów CPU,
• pamięć RAM,
• opóźnienia pamięci masowej,
• wirtualne karty sieciowe,
• ścieżka sieciowa hiperwizora lub chmury,
• liczba sesji,
• TLS Inspection,
• IPS,
• przepustowość VPN,
• rejestrowanie zdarzeń i raportowanie.

Wartości z kart katalogowych należy zawsze interpretować w odpowiednim kontekście. Przepustowość zapory bez inspekcji bezpieczeństwa nie jest tym samym co wydajność ochrony przed zagrożeniami, TLS Inspection lub IPsec VPN pod rzeczywistym obciążeniem. Różnice te wyjaśnia przewodnik interpretacji danych wydajnościowych Sophos Firewall.

HA i odzyskiwanie

Wysoka dostępność różni się znacznie w zależności od platformy.

W przypadku sprzętu architektura HA jest zwykle łatwiejsza do zrozumienia: dwa urządzenia, łącze HA, określone interfejsy i jednoznacznie ustalony sprzęt zastępczy. 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 hiperwizor rzeczywiście zapewniają redundancję?
• 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?

Podstawowe informacje o wariantach HA zawiera instrukcja konfiguracji wysokiej dostępności (HA) Sophos Firewall. Przy planowaniu odzyskiwania należy zapoznać się z instrukcją tworzenia i przywracania kopii zapasowej Sophos Firewall.

Licencjonowanie i wsparcie

Licencjonowanie należy sprawdzić przed wdrożeniem lub zmianą zasobów. Starsze instrukcje instalacji platform ograniczają zarówno vCPU, jak i vRAM do zakresu zakupionej licencji. Artykuł, do którego odsyła poniższy link, opisuje zmianę dotyczącą komercyjnych licencji wirtualnych, Software Appliance i chmurowych BYOL, obowiązującą od 1 marca 2025 r.: przejście na licencjonowanie według rdzeni CPU bez wcześniejszego limitu RAM. Ten opis nie dowodzi, że wszystkie SKU, starsze uprawnienia lub licencje Home mają identyczne warunki. Przed przydzieleniem zasobów potwierdź zakupione SKU i uprawnienia do liczby rdzeni, numer seryjny, subskrypcję i wsparcie oraz rzeczywisty status licencji instancji w portalu licencyjnym. Jeśli zakres uprawnień jest niejasny, wstrzymaj zmianę i wyjaśnij go z dostawcą licencji. Nie przenoś zmiany komercyjnej na licencje Home ani nie wyciągaj z tego artykułu wniosku o nieograniczonych zasobach. Minimum instalacyjne 4 GB oraz dobór RAM, pamięci masowej i kart sieciowych do produkcji pozostają wymaganiami technicznymi niezależnie od ewentualnego limitu licencyjnego.

Podstawy opisuje artykuł Licencja podstawowa Sophos Firewall. Opis zmiany komercyjnego licencjonowania zawiera wpis Sophos Firewall VM i SW — licencjonowanie według CPU bez wcześniejszego limitu RAM; należy go czytać z uwzględnieniem powyższych zastrzeżeń.

W eksploatacji ważne są następujące działania:

• Dokumentuj status licencji i wsparcia.
• Dokładnie zapisuj numer seryjny i status rejestracji.
• Sprawdź licencjonowanie HA przed budową klastra.
• Przed aktualizacją sprawdź uprawnienia do oprogramowania układowego i wsparcia.
• Zapoznaj się z procedurą RMA lub odzyskiwania dla wybranej platformy.

Przed większymi aktualizacjami korzystaj również z listy kontroli Sophos Firewall przed aktualizacją do SFOS 22, ponieważ wsparcie platformy, wolne miejsce, kopie zapasowe, HA i starsze konfiguracje VPN mogą mieć znaczenie dla aktualizacji.

W HA active-passive na urządzeniach wirtualnych lub Software Appliance tylko węzeł podstawowy potrzebuje wszystkich wymaganych licencji, w tym Base Firewall. W HA active-active każdy węzeł potrzebuje własnej licencji Base Firewall i takich samych dodatkowych licencji ochronnych; daty ich wygaśnięcia mogą się różnić. Należy to rozstrzygnąć przed budową klastra, a nie podczas diagnozowania pierwszego przełączenia awaryjnego.

Macierz decyzyjna

• Tradycyjna lokalizacja z WAN, LAN i DMZ: Zwykle urządzenie sprzętowe. Wariant wirtualny tylko przy dobrze zaplanowanej strategii wirtualizacji.
• Centrum danych z zespołem odpowiedzialnym za hiperwizory: Urządzenie sprzętowe jest możliwe, ale wariant wirtualny często ma sens.
• Obciążenia chmurowe w AWS lub Azure: Raczej wariant wirtualny lub chmurowy niż tradycyjne urządzenie sprzętowe.
• Ważne są proste wsparcie i procedura RMA: Raczej urządzenie sprzętowe. W wariantach wirtualnych lub chmurowych wiele zależy od zespołu platformy.
• Potrzeba wielu portów fizycznych: Raczej urządzenie sprzętowe. Wariant wirtualny tylko z prawidłowo zaprojektowanymi kartami sieciowymi i vSwitch.
• Dynamiczne skalowanie i Infrastructure as Code: Raczej wariant wirtualny lub chmurowy.
• Mały zespół IT bez specjalistycznej wiedzy o hiperwizorach: Zwykle urządzenie sprzętowe; wariant wirtualny wymaga starannego planowania.
• Środowisko wielodzierżawne lub segmentacja w centrum danych: Urządzenie sprzętowe jest możliwe, ale wariant wirtualny często ma sens.

Typowe błędy

• Uruchamianie wirtualnej zapory na hoście z nadmiernym przydziałem zasobów.
• Brak prawidłowej separacji WAN, LAN i zarządzania na hiperwizorze.
• Wybór sprzętu według ceny zamiast doboru pojemności i wydajności do wymagań.
• Wdrożenie zapory chmurowej bez ukończonego projektu routingu.
• Planowanie HA bez testów awarii hostów, pamięci masowej lub chmury.
• Tworzenie kopii zapasowych bez ćwiczenia przywracania.
• Sprawdzanie statusu licencji i wsparcia dopiero podczas aktualizacji.
• Włączanie TLS Inspection lub IPS bez rezerwy wydajności.
• Angażowanie osób odpowiedzialnych za platformę, sieć i zaporę dopiero po wystąpieniu incydentu.

Lista kontrolna

• Jednoznacznie określone miejsce wdrożenia: lokalizacja fizyczna, centrum danych lub chmura.
• Udokumentowane parametry ruchu, przepustowości i funkcje bezpieczeństwa potrzebne do doboru zasobów.
• Świadomie wybrany wariant: urządzenie sprzętowe, urządzenie wirtualne, Software Appliance lub wdrożenie chmurowe.
• Udokumentowana odpowiedzialność za zaporę, hiperwizor, chmurę i sieć.
• Zweryfikowany projekt HA i odzyskiwania.
• Przetestowany lub zaplanowany proces tworzenia kopii zapasowych i przywracania.
• Wyjaśnione kwestie licencji, wsparcia i rejestracji.
• Dostępne monitorowanie zapory i platformy, na której działa.
• Sprawdzona możliwość aktualizacji i wsparcie platformy.
• Wskazane osoby odpowiedzialne za platformę, sieć, zaporę, kopie zapasowe i przywracanie.

Często zadawane pytania