Sophos Firewall Utwórz lub przywróć kopię zapasową

Kopia zapasowa Sophos Firewall to coś więcej niż plik awaryjny. Stanowi podstawę do aktualizacji oprogramowania sprzętowego, wymiany sprzętu, migracji XG do XGS, ponownego tworzenia obrazu, pracy HA i czystych procesów odzyskiwania. Jeśli nie zostaną przygotowane kopie zapasowe, Secure Storage Master Key i przywracanie zgodności, planowana zmiana szybko przeradza się w niepotrzebnie długą przerwę.

W artykule wyjaśniono, jak tworzyć i przywracać kopie zapasowe Sophos Firewall, jakie dodatkowe informacje należy udokumentować i jakie kontrole są ważne przed przywróceniem na inny sprzęt lub platformy.

⚠️ Ważne: Kopia zapasowa jest użyteczna tylko wtedy, gdy można ją wykryć, odszyfrować i jest kompatybilna ze środowiskiem docelowym. Przed aktualizacją oprogramowania sprzętowego, ponownym obrazem, zmianami HA lub migracją należy dokładnie sprawdzić plik kopii zapasowej, hasło kopii zapasowej, Secure Storage Master Key, wersję docelową, dostęp do zarządzania i proces przywracania.

Instrukcje wideo

Która ścieżka odzyskiwania jest odpowiednia?

Tworzenie kopii zapasowych i przywracanie to często tylko część problemu. W zależności od sytuacji sensowny jest inny proces:

• Zaplanuj aktualizację oprogramowania sprzętowego: Sophos Firewall Aktualizacja oprogramowania sprzętowego: przygotowanie i najlepsze praktyki.
• Zainstaluj obraz oprogramowania sprzętowego w WebAdmin: Sophos Firewall Wykonaj aktualizację oprogramowania sprzętowego.
• Zawiesza się centralna aktualizacja lub zasady grupy: Sophos Central Sprawdź kolejkę zadań zarządzania zaporą ogniową.
• Zainstaluj ponownie całkowicie system operacyjny Firewall: Sophos Firewall Zainstaluj ponownie system operacyjny: Reimage z pamięci USB.
• Wada sprzętu, powtarzający się błąd lub RMA: Otwórz zgłoszenie do pomocy technicznej Sophos: przygotowanie i portal.
• Przywróć lub odbuduj klaster HA: Sophos Firewall Warianty klastra HA.

W praktyce procesy te nakładają się na siebie. Przed ponownym wykonaniem obrazu prawie zawsze wymagana jest kopia zapasowa. Przed zgłoszeniem do pomocy technicznej ważny jest numer seryjny, wersja oprogramowania sprzętowego, dzienniki i poprzednie kroki. Po centralnie kontrolowanej aktualizacji kolejka zadań może wyjaśnić, dlaczego zmiana nie dotarła jeszcze do zapory ogniowej.

Dlaczego sama kopia zapasowa nie wystarczy

Pobrana kopia zapasowa zmniejsza ryzyko, ale nie rozwiązuje automatycznie każdego problemu z odzyskiwaniem. W praktyce potrzebne są również:

• bezpieczna lokalizacja poza zaporą ogniową
• przejrzyste mapowanie do zapory ogniowej, numeru seryjnego, lokalizacji i wersji SFOS
• odpowiedni Secure Storage Master Key (SSMK)
• hasło kopii zapasowej, jeśli kopia zapasowa została zaszyfrowana
• udokumentowane WAN, VLAN, HA, VPN i informacje o licencji
• zweryfikowany plan przywracania obejmujący wymianę sprzętu, ponowne utworzenie obrazu lub migrację

Szczególnie przed aktualizacją oprogramowania sprzętowego, ponownym obrazem za pomocą pamięci USB lub SFOS sprawdzeniem aktualizacji 22 należy nie tylko utworzyć kopię zapasową, ale także ją profesjonalnie sprawdzić.

Przed pierwszą kopią zapasową: sprawdź Secure Storage Master Key

Przed produktywnym wykorzystaniem ręcznych lub zaplanowanych kopii zapasowych należy ustawić i bezpiecznie udokumentować Secure Storage Master Key (SSMK). Bez tego klucza przywracanie na nowym urządzeniu lub w niektórych scenariuszach odzyskiwania może się nie powieść.

Jest to szczególnie istotne, jeśli:

• przygotowywana jest zastępcza zapora ogniowa
• planowana jest migracja do innego modelu
• Konfiguracje są przenoszone pomiędzy sprzętem, urządzeniem wirtualnym i chmurą
• Kopie zapasowe są przechowywane poza zaporą ogniową

SSMK należy do menedżera haseł lub innej procedury bezpiecznego odzyskiwania. Nie powinna być znana tylko jednej osobie. Jeśli klucz będzie wyszukiwany tylko w sytuacji awaryjnej, cenny czas na dotarcie do celu już zostanie stracony.

Ważne: starsze kopie zapasowe pozostają powiązane z SSMK, za pomocą którego zostały utworzone. Jeśli klucz zostanie później zmieniony lub zresetowany, nowy klucz nie będzie wystarczający dla starych kopii zapasowych. Dlatego wcześniejsze wersje SSMK należy również udokumentować, podając datę, okres ważności i zaporę, której dotyczy problem. Zmiana SSMK nie jest zwykłym porządkiem, ale zmianą istotną dla odzyskiwania.

Zaplanowane kopie zapasowe bez zestawu SSMK również stanowią przypadek szczególny. Sophos Firewall może nadal tworzyć takie kopie zapasowe zgodnie z harmonogramem przywracania, ale brakuje dodatkowej ochrony SSMK. Ponadto częstotliwość tworzenia kopii zapasowych należy uznać za możliwą do zarządzania dopiero po ustawieniu SSMK. W przypadku wydajnych zapór sieciowych ma to zatem sens: skonfiguruj SSMK, następnie utwórz nową ręczną kopię zapasową i dopiero wtedy oceń zaplanowane kopie zapasowe jako niezawodną ścieżkę odzyskiwania.

Utwórz kopię zapasową: ręczną i automatyczną

Ścieżka WebAdmin to:

Backup & Firmware > Backup & Restore

Ręczna kopia zapasowa przed zmianami

Użyj Backup Now, aby natychmiast wykonać kopię zapasową. Kopia zapasowa powinna wówczas nie tylko pozostać w folderze pobierania przeglądarki, ale powinna być świadomie przechowywana.

Przed tą pracą należy zawsze utworzyć ręczną kopię zapasową:

• Aktualizacja oprogramowania sprzętowego lub poprawka stwarzająca ryzyko ponownego uruchomienia lub zmiany zachowania
• Interfejs, VLAN, routing, SD-WAN lub konwersja VPN
• konfiguracja HA, przełączanie ról HA lub konserwacja HA
• poważna zmiana NAT, WAF lub reguły zapory sieciowej
• Ponowny obraz, przywrócenie ustawień fabrycznych lub wymiana sprzętu
• Migracja z XG do XGS, sprzętu do wirtualnego lub wirtualnego do chmury

Po pobraniu powinieneś przynajmniej udokumentować datę, nazwę zapory ogniowej, numer seryjny, wersję SFOS i cel kopii zapasowej. W przypadku większych zmian porównanie z Sophos Firewall Config Studio pomoże później, aby móc zrozumieć różnice konfiguracyjne przed i po zmianie.

Skonfiguruj automatyczne kopie zapasowe

Aby mieć pewność, że kopie zapasowe nie zostaną zapomniane, należy skonfigurować automatyczną kopię zapasową. W Frequency możesz zdefiniować codzienne, cotygodniowe lub miesięczne kopie zapasowe.

Automatycznie generowane kopie zapasowe można zapisywać lokalnie na zaporze sieciowej, na serwerze FTP lub pocztą elektroniczną. Miejsce przechowywania jest mniej ważne niż otaczający go proces:

• Każdy, kto przechowuje kopie zapasowe za pośrednictwem poczty elektronicznej lub na serwerze zewnętrznym, powinien sprawdzić szyfrowanie i ochronę dostępu.
• Lokalne kopie zapasowe na zaporze nie pomogą, jeśli urządzenie wymaga całkowitej wymiany lub ponownej instalacji.
• Tylko najnowsza lokalna kopia zapasowa pozostaje istotna na samej zaporze. Jeśli musisz zachować starsze wersje, powinieneś świadomie je pobrać lub zapisać zewnętrznie.
• W przypadku kopii zapasowych FTP lub poczty e-mail należy sprawdzić nie tylko ustawienie. Należy przetestować także dostarczanie, pobieranie, uprawnienia i wykrywalność.
• Centralne kopie zapasowe są wygodne, ale nie powinny być jedyną znaną ścieżką odzyskiwania.
• Automatyczne kopie zapasowe nie zastępują ręcznych kopii zapasowych bezpośrednio przed ryzykownymi zmianami.
• Starymi kopiami zapasowymi należy zarządzać z uwzględnieniem okresu przechowywania, dostępu i procesu usuwania. W przypadku kopii FTP i Backup prefix nie należy używać złożonych znaków specjalnych bez testu. Sophos ma ograniczenia dla prefiksu, nazwy użytkownika i hasła. Po konfiguracji liczy się nie zapisane ustawienie, lecz prawdziwy test backupu, pobrania i restore.

Jeśli zapora sieciowa jest podłączona do Sophos Central, sensowne może być również centralne przechowywanie kopii zapasowych konfiguracji. Połączenie centralne opisano w artykule Sophos Firewall połącz z Sophos Central.

Prawidłowo organizuj centralne kopie zapasowe

Sophos Central może zaplanować tworzenie kopii zapasowych konfiguracji zapory ogniowej, natychmiast je utworzyć, pobrać i udostępnić do późniejszego przywrócenia. Ścieżka Centralna znajduje się pod adresem:

My Products > Firewall Management > Backup

Centralne kopie zapasowe są pomocne, ponieważ nie znajdują się na samej zaporze i przepływają na konto Health Check. Niemniej jednak ta ścieżka zapasowa wymaga świadomego działania:

• Globalna częstotliwość backupu w Sophos Central zaczyna się jako Never. Przy ręcznej konfiguracji przez Schedule Backup UI może pokazać inną sugerowaną wartość. Jeśli firewall zostanie automatycznie dodany jako pierwszy do harmonogramu backupów, Sophos Central jednorazowo ustawia częstotliwość na Monthly z datą początkową pierwszego dnia miesiąca. Jeśli firewall mimo włączonego Send configuration backup to Sophos Central nie pojawia się w harmonogramie, użyj Schedule Backup > Add new firewall; alternatywnie usuń zaznaczenie, Apply, zaznacz ponownie, Apply, a następnie wykonaj accept-services w Sophos Central.
• Zaplanowane kopie zapasowe Central są uruchamiane o godzinie 08:00 w strefie czasowej regionu Sophos Central. Czasu tego nie można regulować.
• Sophos Central próbuje utworzyć kopię zapasową maksymalnie pięć razy. Jeśli nadal się to nie powiedzie, generowany jest alert i wysyłana jest wiadomość e-mail do administratora centralnego.
• Centrala przechowuje pięć najnowszych kopii zapasowych. Kopię zapasową można także przechowywać na stałe do czasu jej wymiany lub usunięcia.
• Podczas pobierania z Centrali kopia zapasowa jest ponownie szyfrowana przy użyciu nowego hasła. To hasło jest następnie uwzględniane w procesie odzyskiwania.
• Gdy zapora sieciowa zostanie usunięta z zarządzania Sophos Central, Sophos usuwa również powiązane z nią pliki centralnej kopii zapasowej. Przed zmianą kont, czyszczeniem najemcy lub RMA należy wcześniej pobrać wymagane kopie zapasowe.
• W przypadku klastrów HA podstawowy i pomocniczy są uwzględnione w harmonogramie tworzenia kopii zapasowych, ale kopia zapasowa jest tworzona przez podstawowy.

Centralna kopia zapasowa jest zatem dobrą dodatkową ścieżką odzyskiwania, ale nie ma powodu zaniedbywać lokalnego odzyskiwania, SSMK, dostępu administratora i dokumentacji witryny.

Bezpiecznie przechowuj kopię zapasową

Kopie zapasowe zapory sieciowej zawierają poufne informacje o strukturze sieci, obiektach, regułach, usługach, VPN, certyfikatach i częściowo chronionych danych kont. Dlatego należy je traktować jak wrażliwe pliki infrastruktury.

Te reguły mają sens w działaniu:

• Nie przechowuj niezaszyfrowanych plików kopii zapasowych w ogólnych folderach zespołu.
• Ogranicz dostęp do kopii zapasowych zapory ogniowej do administratorów i menedżerów odzyskiwania.
• Dokumentuj hasło kopii zapasowej i SSMK osobno, ale tak, aby można je było znaleźć.
• Użyj jasnej konwencji nazewnictwa dla każdej witryny lub zapory sieciowej.
• Po odejściu administratora sprawdź, czy dostęp do magazynu kopii zapasowych i menedżera haseł nadal działa.
• Informacje istotne dla przywracania dokumentów, takie jak dane dostępowe WAN, PPPoE, statyczne dane dostawcy lub oddzielne przypisanie portów HA.

Kopia zapasowa nie zastępuje dokumentacji operacyjnej. Zwłaszcza w przypadku klastrów HA, wielu łączy WAN lub złożonych środowisk VPN należy również udokumentować, które interfejsy, dane dostawcy i zależności należy sprawdzić w pierwszej kolejności po przywróceniu.

Przygotuj pakiet odzyskiwania dla każdej zapory ogniowej

W sytuacji awaryjnej większość czasu tracisz nie na przesyłanie pliku kopii zapasowej, ale na szukanie dodatkowych informacji. Dlatego w przypadku wydajnych zapór ogniowych dla każdej lokalizacji lub klienta powinien być dostępny mały pakiet odzyskiwania.

Ten pakiet zawiera:

• Ostatnia zweryfikowana kopia zapasowa: Podstawa przywracania, migracji lub ponownego tworzenia obrazu.
• Hasło kopii zapasowej i Secure Storage Master Key: Niezbędne do szyfrowanych kopii zapasowych i chronionych danych.
• Numer seryjny, model i wersja SFOS: Ważne dla wsparcia, licencjonowania i sprawdzania kompatybilności.
• WAN dane i informacje o dostawcy: Niezbędne, jeśli po przywróceniu brakuje dostępu do Internetu lub połączenia centralnego.
• Przypisanie interfejsu i portów: Kluczowe dla migracji XG do XGS, portów Flexi, łączy trunkingowych VLAN i HA.
• Dostęp administratora i Break Glass: Umożliwia dostęp lokalny, jeśli VPN, Centrala lub SSO jeszcze nie działają.
• Licencja i mapowanie centralne: Zapobiega pomyłkom związanym z wymianą sprzętu, wirtualnymi zaporami ogniowymi lub instancjami w chmurze.
• Usługi krytyczne i testy akceptacyjne: Szybko pokazuje po przywróceniu, czy VPN, NAT, WAF, DNS, DHCP i rejestrowanie znów działają.

Tego pakietu nie należy przechowywać jako niezabezpieczonego pliku tekstowego obok kopii zapasowej. Lepsze jest połączenie menedżera haseł, wewnętrznej dokumentacji operacyjnej i jasnej odpowiedzialności. Co najmniej dwie upoważnione osoby powinny wiedzieć, gdzie znajdują się te informacje i jak uzyskać do nich dostęp w sytuacji awaryjnej.

Pakiet naprawczy należy sprawdzić po zmianie personelu, relokacji, zmianie dostawcy, zmianie HA lub większej migracji. Formalnie aktualna kopia zapasowa jest mało pomocna, jeśli udokumentowany adres IP WAN, przypisanie portów lub przypisanie centralne nie jest już prawidłowe.

Przygotuj przywracanie

Przed przywróceniem należy najpierw wyjaśnić, jaki cel jest realizowany. Przywrócenie na tym samym urządzeniu po błędnej konfiguracji należy oceniać inaczej niż przywrócenie po zmianie obrazu, wymianie sprzętu lub zmianie platformy.

Przygotowanie:

• Czy dostępna jest nowa kopia zapasowa bieżącego stanu?
• Czy plik kopii zapasowej jest wyraźnie przypisany do właściwej zapory sieciowej?
• Are backup password and SSMK available?
• Czy wersja SFOS systemu docelowego jest zgodna z kopią zapasową?
• Czy ścieżka przywracania jest wspólna dla wersji źródłowej, wersji docelowej i platformy docelowej?
• Czy przywracanie na identycznym sprzęcie, innym modelu, urządzeniu wirtualnym czy w chmurze?
• Czy pojawi się Backup-Restore Assistant, czy nastąpi automatyczne mapowanie interfejsu?
• Czy zaangażowana jest funkcja HA, czy też kopia zapasowa HA została przywrócona do jednego urządzenia?
• Czy istnieje dostęp do zarządzania lokalnego, jeśli WAN, VPN lub Central nie działają natychmiast po przywróceniu?
• Czy wiadomo, który adres IP WebAdmin stanie się aktywny po przywróceniu?
• Czy udokumentowano strefę czasową, serwer NTP i wszelkie ręczne ustawienia daty/godziny?

⚠️ Przywrócenie powoduje zastąpienie bieżącej konfiguracji. W produktywnej zaporze sieciowej należy, jeśli to możliwe, utworzyć nową kopię zapasową bieżącego stanu przed przywróceniem, nawet jeśli bieżąca konfiguracja jest niepoprawna. Jeśli ścieżki migracji nie są obsługiwane, zapora może po potwierdzeniu uruchomić się z konfiguracją fabryczną. To ostrzeżenie nie powinno być traktowane i potwierdzane jako normalny komunikat o przywróceniu.

Czego przywracanie nie rozwiązuje automatycznie

Przywracanie odtwarza konfigurację, ale nie zastępuje pełnej kontroli działania. Po ponownym uruchomieniu ponownie obowiązują adresy IP zarządzania, konfiguracja interfejsu, Device Access, certyfikaty, trasy i usługi z przywróconej konfiguracji. Oznacza to, że WebAdmin może nagle być dostępny pod innym adresem IP niż podczas początkowej konfiguracji zapory zastępczej.

Ponadto powinieneś świadomie sprawdzić następujące punkty:

• Ręczne wartości daty i godziny nie zostały w pełni przywrócone do stanu operacyjnego. Po przywróceniu należy sprawdzić strefę czasową, NTP i aktualny czas.
• Hasło domyślnego konta admin nie jest zastępowane przez kopię zapasową podczas przywracania. Docelowa zapora sieciowa zachowuje istniejące domyślne hasło administratora.
• Dzienniki, raporty i dane z zewnętrznego monitoringu nie zastępują kopii zapasowej konfiguracji i powinny być tworzone oddzielnie lub przechowywane centralnie.
• Certyfikaty, VPN, połączenie centralne, cele Syslog i powiadomienia mogą być technicznie obecne po przywróceniu, ale nadal nie działają poprawnie ze względu na czas, DNS, routing lub zmienioną platformę docelową.
• Restore na inny sprzęt nie rozwiązuje automatycznie różnic portów i interfejsów na poziomie projektu. Mapowanie musi pasować do modelu okablowania i stref.
• Ustawienia zależne od modelu mogą powrócić do wartości domyślnych podczas przywracania na inną platformę, jeśli nie mieszczą się na urządzeniu docelowym. Dotyczy to na przykład wydajności sprzętu lub instancji oraz opcji portów.
• Rejestracja Sophos Central zostanie zachowana tylko w przypadku przywracania do tej samej zapory. Przywrócenie na inny sprzęt lub HA wyrejestrowuje zaporę z Sophos Central. Po przywróceniu trzeba ją zarejestrować ponownie, a Security Heartbeat, Sophos ZTNA, Central Management, Central Backup, Central Reporting oraz Task Queue trzeba sprawdzić pojedynczo i w razie potrzeby skonfigurować od nowa. W przypadku polityk grupowych do tej kontroli należy też przynależność do grupy.

Zaplanuj test przywracania bez ryzyka produkcyjnego

Test przywracania jest przydatny, ale nie należy go przeprowadzać pochopnie na produktywnej zaporze ogniowej. Celem nie jest regularne nadpisywanie urządzeń produkcyjnych, ale raczej sprawdzenie, czy najważniejsze wymagania dotyczące odzyskiwania działają.

Test bezpiecznego przywracania może wyglądać następująco, w zależności od środowiska:

• Pobierz plik kopii zapasowej z zaplanowanej pamięci.
• Sprawdź nazwę pliku, datę, nazwę zapory sieciowej, numer seryjny i wersję SFOS.
• Sprawdź hasło zapasowe i SSMK w menedżerze haseł.
• Uruchom sprawdzanie zgodności kopii zapasowych i przywracania dla planowanego modelu docelowego.
• Mapowanie interfejsu dokumentu i odchylenia portów przed migracją.
• Sprawdź planowaną wersję docelową pod kątem obsługiwanych ścieżek aktualizacji i przywracania kopii zapasowych.
• Sprawdź w laboratorium lub zaporze zastępczej, czy tworzenie kopii zapasowych jest ogólnie akceptowane.
• Nie pozostawiaj żadnych produktywnych sieci VPN, dostępu WAN ani aktywnych połączeń centralnych w stanie niekontrolowanym po przywróceniu testowym.

Jeśli nie jest dostępna zapora laboratoryjna ani zamienna, możliwy pozostaje co najmniej jeden test organizacyjny: znajdź kopię zapasową, sprawdź dostęp, potwierdź hasło/SSMK, oceń platformę docelową za pomocą kontroli zgodności i przeprowadź proces w elemencie Runbook odzyskiwania. Nie zastępuje to prawdziwego przywracania, ale zapobiega wielu klasycznym problemom awaryjnym.

W przypadku lokalizacji krytycznych powinno być również jasne, w jaki sposób zapora sieciowa staje się ponownie dostępna po ponownym utworzeniu obrazu lub wymianie sprzętu: dostęp lokalny, port zarządzania, dane WAN, status licencji, przypisanie Sophos Central i osoba kontaktowa na miejscu. Informacje te znajdują się nie tylko w kopii zapasowej, ale także w osobnej dokumentacji operacyjnej.

Przywróć kopię zapasową

Przywracanie odbywa się również w:

Backup & Firmware > Backup & Restore

Proces podstawowy:

1. Dotrzyj do docelowej zapory ogniowej poprzez WebAdmin.
2. Zapisz bieżący stan, jeśli to nadal możliwe.
3. W obszarze Restore configuration wybierz plik backupu przez Choose file.
4. W razie potrzeby wprowadź Encryption password lub SSMK.
5. Uruchom Upload and Restore.
6. Poczekaj na ponowne uruchomienie i odzyskanie.
7. Otwórz WebAdmin poprzez adres IP zarządzania z przywróconej konfiguracji.
8. Sprawdź strefę czasową, NTP i aktualny czas.
9. Następnie sprawdź sieć, usługi, VPN, HA i połączenie centralne.

Podczas przywracania zaimportowana konfiguracja zastępuje bieżącą konfigurację, usuwa lokalnie przechowywaną kopię zapasową na zaporze i ponownie uruchamia zaporę. Dlatego używana kopia zapasowa powinna pozostać dostępna zewnętrznie przed przywróceniem. Jeśli jedyna kopia znajduje się na docelowej zaporze ogniowej, proces odzyskiwania jest niepotrzebnie delikatny.

Jeśli wdrożono nowy lub wymieniony Sophos Firewall, kopię zapasową można zaimportować po pierwszym dostępie do urządzenia. Początkowy adres IP i początkowy dostęp zależą od odpowiedniego modelu i typu wdrożenia. W przypadku urządzeń sprzętowych lokalny dostęp początkowy jest powszechny za pośrednictwem standardowego adresu IP zarządzania lub kreatora konfiguracji.

Gdy tylko zapora będzie dostępna i kreator instalacji zostanie zakończony, można przystąpić do przywracania w sposób opisany powyżej.

Przywróć na inny sprzęt lub inne platformy

Szczególnie w przypadku migracji pomiędzy XG i XGS lub pomiędzy sprzętem, urządzeniem wirtualnym i chmurą, przed przywróceniem powinieneś sprawdzić, czy kopia zapasowa jest kompatybilna. W tym celu Sophos oferuje publiczną sprawdzanie zgodności z kopiami zapasowymi i przywracaniem danych.

Ponadto wersja docelowa musi być zgodna. Sophos rozróżnia współdzielone ścieżki aktualizacji i przywracania kopii zapasowych oraz migracje niewspółdzielone. Jeśli zapora sieciowa ostrzeże przed ponownym uruchomieniem, że planowana migracja nie jest obsługiwana, nie należy tego po prostu potwierdzać. Po potwierdzonej, niewydanej migracji zapora sieciowa może uruchomić się z konfiguracją fabryczną, powodując utratę bieżącej konfiguracji.

W przypadku produktywnego przywracania oznacza to:

• najpierw zanotuj wersję źródłową, wersję docelową, model docelowy i platformę
• Przed przywróceniem przywróć docelową zaporę ogniową do obsługiwanej wersji SFOS
• Uruchom sprawdzanie zgodności kopii zapasowych i przywracania dla określonej kombinacji
• Potraktuj poważnie ostrzeżenia wyświetlane w oknie dialogowym przywracania lub aktualizacji i udokumentuj je
• Jeśli nie masz pewności, najpierw sprawdź, czy jest dostępny sprzęt zastępczy lub w środowisku testowym

Backup-Restore Assistant i automatyczne mapowanie interfejsów

To, czy pojawi się Backup-Restore Assistant, zależy od konkretnych warunków wersji i platformy, a nie tylko od „nowszego” backupu:

• Backup pochodzi z appliance (XG, SG z SFOS, XGS, virtual lub cloud), na którym działał SFOS 19.5 MR4 lub nowszy.
• Restore wykonywany jest na SFOS 20.0 MR2 lub nowszym.
• Restore wykonywany jest na serię XGS, appliance virtual lub cloud.
• Przy restore na serię XG lub SG Assistant się nie pojawia.

Assistant pomaga przypisać interfejsy, gdy backup z XG, SG z SFOS lub XGS jest przywracany na serię XGS, appliance virtual lub firewall cloud. Jest to szczególnie ważne, gdy firewall docelowy ma mniej portów, inne nazwy portów, warianty wireless lub moduły Flexi-Port.

Przy backupach z SFOS 19.5 MR3 lub starszych oraz przy każdym restore na XG/SG Assistant jest niedostępny. Firewall przypisuje wtedy interfejsy automatycznie. To szybsze, ale bardziej ryzykowne, ponieważ przypisanie nie jest świadomie potwierdzane w asystencie. Po takim restore należy szczególnie dokładnie sprawdzić interfejsy, strefy, bramy, VLANs, HA-link, trasy SD-WAN, reguły NAT i VPN.

Najważniejsze przypadki szczególne mapowania interfejsów:

Pseudo-porty wskazują, że decyzja operacyjna dotycząca portu nadal jest otwarta. Po restore należy je sprawdzić, przenieść na aktywny port albo czysto usunąć. Aby usunąć pseudo-port, otwórz go w Network > Interfaces, ustaw zone na None i uruchom firewall ponownie. Niepowiązane pseudo-porty z konfiguracją VLAN nie są przy tym automatycznie usuwane i wymagają dodatkowego czyszczenia.

Dalsze punkty do wyjaśnienia po restore:

Jeśli przypisanie portu jest inne, po przywróceniu zwykle trzeba sprawdzić lub przerobić mapowanie interfejsu. Przed migracją XG do XGS istotny jest także artykuł Jaka jest różnica między zaporą XG a XGS?.

Po większych pracach związanych z przywracaniem lub migracją pomocne może być porównanie konfiguracji. Sophos Firewall Używanie Config Studio pokazuje, jak porównać kopie zapasowe przed i po zmianie, a zwłaszcza sprawdzić, czy nie występują nieoczekiwane różnice.

Zapory sieciowe w chmurze i wirtualne

W przypadku zapór wirtualnych lub chmurowych nie należy polegać wyłącznie na kopiach zapasowych hypervisora, migawek lub dostawców usług w chmurze. Sophos obsługuje wbudowany w zaporę mechanizm tworzenia kopii zapasowych i przywracania kopii zapasowych konfiguracji zapory. Kopie zapasowe platformy mogą być przydatne jako dodatkowa ochrona infrastruktury, ale nie zastępują obsługiwanej kopii zapasowej konfiguracji.

W praktyce oznacza to: migawka maszyny wirtualnej, obraz w chmurze lub mechanizm marketplace mogą pomóc w przywróceniu instancji. Do czystej konfiguracji SFOS, analizy migracji lub wsparcia nadal potrzebujesz ważnej kopii zapasowej zapory Sophos z odpowiednim SSMK, hasłem zapasowym, wersją docelową i udokumentowanym mapowaniem interfejsu.

Sprawdź po przywróceniu

Po przywróceniu powinieneś nie tylko sprawdzić, czy można osiągnąć WebAdmin. Zapora może być dostępna, a mimo to nieprawidłowo przetwarzać ważne usługi.

Sprawdź natychmiast po przywróceniu:

• WebAdmin-IP, dozwolone sieci zarządzania i Device Access.
• Interfejsy, strefy, sieci VLAN, mosty, grupy LAG i interfejsy aliasów.
• łącza WAN, PPPoE, statyczne dane dostawcy i brama domyślna.
• Trasy SD WAN, trasy statyczne i routing dynamiczny.
• Reguły zapory sieciowej, reguły NAT, reguły WAF i kolejność reguł.
• IPsec, SSL VPN, Sophos Connect, RED i dostęp zdalny.
• Certyfikaty, certyfikaty CA, certyfikat WebAdmin i TLS Inspection.
• DNS, DHCP, NTP, strefa czasowa i serwer Authentication.
• Stan HA podczas korzystania z klastra.
• Stan licencji, aktualizacje wzorców, poprawki i synchronizacja Sophos Central.
• Rejestrowanie, cele Syslog, raportowanie centralnej zapory sieciowej i raporty lokalne.

W zależności od problemu, Log Viewer, Test zasad i Packet Capture, Packet Capture w WebAdmin i Services i logi pomagają w kontroli technicznej.

Test akceptacji po przywróceniu

Przywracanie nie zostanie zakończone, dopóki kluczowe funkcje operacyjne nie zostaną potwierdzone w rzeczywistych testach. Dostępny WebAdmin tylko potwierdza, że ​​zapora sieciowa może być obsługiwana. Nie dowodzi to, że routing, NAT, VPN, WAF, uwierzytelnianie lub rejestrowanie znów działają poprawnie.

Dlatego powinna istnieć krótka matryca akceptacji dla produktywnych zapór ogniowych. Matryca ta nie musi być skomplikowana, ale powinna określać dla każdej lokalizacji, jaki test należy przeprowadzić po przywróceniu stanu i kto dokumentuje wynik.

Przydatnymi obowiązkowymi testami są:

• Zarządzanie: Otwórz WebAdmin z sieci zarządzania i przetestuj drugi dostęp administratora. Oczekuje się, że dostęp będzie możliwy tylko z dozwolonych sieci.
• Dostęp do Internetu: Klient testowy w LAN lub klient VLAN wywołuje zdefiniowane cele zewnętrzne. Należy zastosować poprawną regułę zapory sieciowej, regułę NAT i trasę WAN.
• DNS i DHCP: Klient otrzymuje adres i rozwiązuje nazwy wewnętrzne i zewnętrzne. Obszar DHCP, serwer DNS i trasy żądań DNS muszą się zgadzać.
• Sieć VPN typu lokacja-lokacja: W obu kierunkach osiągany jest zdefiniowany host dla każdej witryny. Reguły tuneli, routingu i zapory muszą być zgodne.
• Dostęp zdalny: Użytkownik testowy konfiguruje SSL VPN, IPsec lub Sophos Connect. Login, MFA, profil, DNS i cele wewnętrzne muszą działać.
• WAF lub DNAT: Opublikowana usługa jest testowana zewnętrznie. Certyfikat, reguła, backend i rejestrowanie muszą się zmieścić.
• Uwierzytelnianie: Sprawdź AD, LDAP, RADIUS, STAS lub Entra SSO z użytkownikiem testowym. Użytkownik powinien zostać rozpoznany i trafić w oczekiwaną regułę.
• Logowanie: Sprawdź Log Viewer, Syslog, Central Reporting lub SIEM. Przywracanie i testowanie ruchu powinno być wyraźnie widoczne.
• HA: Sprawdź stan klastra, role i synchronizację. Podstawowe i pomocnicze powinny być w oczekiwanym stanie.

Zdefiniowany punkt końcowy jest ważny. Jeśli podstawowe testy takie jak WAN, DNS, Remote Access czy HA nie działają po przywróceniu, nie należy dokonywać poprawek w wielu miejscach równolegle. Lepiej jest mieć wąski przypadek błędu z czasem, źródłem testu, celem, regułą, której dotyczy problem i fragmentem dziennika. Dzięki temu jest jasne, czy problem wynika z kopii zapasowej, mapowania interfejsu, sprzętu docelowego, czy późniejszej zmiany.

Typowe błędy

• Kopia zapasowa jest przechowywana wyłącznie lokalnie na zaporze sieciowej: Nie można uzyskać do niej dostępu w przypadku defektu sprzętowego lub ponownego utworzenia obrazu. Kopie zapasowe należy przechowywać na zewnątrz i chronić.
• SSMK nieudokumentowany: Przywracanie chronionych danych może się nie powieść lub trwać znacznie dłużej. SSMK uczestniczy w procesie odzyskiwania środków.
• Po zmianie klucza nie można już znaleźć starego SSMK: Starszych kopii zapasowych nie można już odszyfrować. Poprzednie wersje SSMK powinny pozostać udokumentowane okresem czasu i odniesieniami do zapory ogniowej.
• Kopia zapasowa bez odniesienia do wersji lub urządzenia: Zaimportowano niewłaściwy plik. Nazwa zapory sieciowej, numer seryjny, wersja i data SFOS są częścią dokumentacji kopii zapasowej.
• Brak aktualnej kopii zapasowej przed przywróceniem: Brak ścieżki powrotu do bieżącego stanu. Przed przystąpieniem do produktywnego przywracania należy utworzyć nową kopię zapasową.
• Przywrócony WebAdmin IP nieznany: Po przywróceniu zapora sieciowa pojawia się w trybie offline, mimo że działa na innym adresie IP. Wstępnie zaplanuj zarządzanie adresem IP z kopii zapasowej i dostępem lokalnym.
• Po przywróceniu nie sprawdzono czasu i NTP: VPN, certyfikaty, uwierzytelnianie lub połączenie centralne mogą działać nieprawidłowo. Zaraz po przywróceniu sprawdź strefę czasową, NTP i aktualny czas.
• Potwierdzono nieudostępnioną ścieżkę przywracania: Zapora sieciowa uruchamia się z konfiguracją fabryczną lub przywracanie nie powiedzie się. Przed przywróceniem należy sprawdzić wersję docelową, wersję źródłową i sprawdzić kompatybilność.
• Nie sprawdzono mapowania portów: Po migracji interfejsy lądują nieprawidłowo. Należy przygotować sprawdzenie kompatybilności i mapowanie interfejsu.
• Zastosowano automatyczne mapowanie interfejsu bez sprawdzania: WAN, VLAN, VPN lub łącze HA znajdują się na niewłaściwych portach. Po przywróceniu porównaj każdy interfejs z modelem okablowania i strefy.
• Kontekst HA zignorowany: Klaster nie uruchamia się prawidłowo lub aktywowana zostaje niewłaściwa rola. Należy zaplanować role HA, poziom oprogramowania sprzętowego i kolejność przywracania.
• Zaznaczono tylko WebAdmin: Problemy z VPN, NAT, WAF lub DNS pozostają niewykryte. Po przywróceniu potrzebne są rzeczywiste testy serwisowe.

Operacyjna lista kontrolna

Regularny:

• Włącz automatyczne tworzenie kopii zapasowych lub zdefiniuj centralny proces tworzenia kopii zapasowych.
• Sprawdź miejsce przechowywania, dostęp i przechowywanie kopii zapasowych.
• Sprawdź SSMK i hasło zapasowe w menedżerze haseł.
• Aktualizuj pakiet odzyskiwania dla każdej witryny lub zapory sieciowej.
• Sprawdź przynajmniej losowo, czy można znaleźć i przypisać kopie zapasowe.

Przed poważnymi zmianami:

• Utwórz ręczną kopię zapasową i zapisz ją zewnętrznie.
• Udokumentuj nazwę zapory ogniowej, numer seryjny, wersję SFOS i cel zmiany.
• Sprawdź SSMK, hasło zapasowe i dostęp administratora.
• Ustaw plan wycofywania lub przywracania.
• Sprawdź kontrolę zgodności i mapowanie interfejsu dla migracji.
• Nie potwierdzaj ostrzeżeń o nieobsługiwanych ścieżkach przywracania lub migracji, dopóki nie zostanie wprowadzony alternatywny plan.

Po przywróceniu:

• Sterowanie WebAdmin-IP, zarządzanie sieciami i Device Access.
• Interfejsy testowe, routing, NAT, VPN, WAF, uwierzytelnianie i centrala.
• Sprawdź strefę czasową, NTP i aktualny czas.
• Macierz akceptacji procesu z rzeczywistymi źródłami testów, celami testów i oczekiwanymi logami.
• Sprawdź stan i role HA.
• Sprawdź dzienniki i monitorowanie.
• W przypadku wersji docelowych od SFOS 22.0 MR1 sprawdź ponownie, czy przywracanie lub import przywróciły stare konfiguracje Legacy Remote Access IPsec.
• Utwórz nową kopię zapasową przywróconego stanu docelowego.
• Udokumentuj odchylenia i w razie potrzeby porównaj je z Config Studio.

Często zadawane pytania