Selektywny eksport i import konfiguracji Sophos Firewall

W sekcji Backup and firmware > Import export Sophos Firewall może wyeksportować pełną konfigurację lub jej wybraną część. Eksport można sprawdzić na chronionym systemie administracyjnym, zmodyfikować w kontrolowany sposób i ponownie zaimportować jako plik .tar. Nadaje się to do jasno ograniczonych zmian obiektów, migracji i udokumentowanych zmian masowych.

Import nie jest jednak restore. Nie zastępuje całej bieżącej konfiguracji, lecz dodaje nowe ustawienia i nadpisuje zgodne ustawienia z pakietu importowego. Ustawienia, których nie ma w pakiecie, pozostają bez zmian. Przed każdym importem produkcyjnym potrzebne są zatem pełny backup firewalla z hasłem i SSMK, awaryjna ścieżka zarządzania i plan testów.

⚠️ Ważne: Entities.xml może zawierać hasła, secrety, użytkowników, obiekty sieciowe, reguły i inne poufne dane. Pliki należy przetwarzać wyłącznie na zaufanym systemie administracyjnym, nie rozpowszechniać ich przez niekontrolowaną chmurę ani komunikatory, a po zmianie bezpiecznie zarchiwizować lub usunąć.

Selektywny import w dziesięciu krokach

1. Zapisać cel, objęte typy obiektów i oczekiwane zmiany.
2. Utworzyć pełny backup do restore i sprawdzić hasło oraz Secure Storage Master Key.
3. Zapisać docelowy firmware, wersję patternów, platformę, liczbę portów i zgodność modelu.
4. W Backup and firmware > Import export wybrać Export selective configuration.
5. Wybrać tylko potrzebne typy konfiguracji i świadomie uwzględnić zależności.
6. Bezpiecznie zapisać wyeksportowany plik .tar i zachować go bez zmian jako punkt odniesienia.
7. Rozpakować pakiet, sprawdzić Entities.xml i zmienić tylko zaplanowane pola.
8. Ponownie spakować Entities.xml oraz istniejące pliki towarzyszące, bez zmiany nazw, jako .tar.
9. Zaimportować pakiet w oknie serwisowym i podać SSMK, jeśli dotyczy informacji poufnych.
10. Sprawdzić obiekty, zależne polityki, oczekiwany Firewall Rule ID, logi i rzeczywisty ruch.

Jeśli import ma nieoczekiwany zakres, brakuje zależności albo zgodność platformy docelowej nie jest jednoznaczna, nie należy importować do produkcji. Niezmieniony pakiet eksportowy służy do porównania, a pełny backup jako ścieżka odzyskiwania.

Nie mylić importu/eksportu z backupem

Pełny backup odwzorowuje firewall jako pakiet odzyskiwania. Podczas restore zastępuje bieżącą konfigurację, aktywuje adres zarządzania zapisany w backupie i ponownie uruchamia firewall. Obszar importu/eksportu działa natomiast na obiektach konfiguracji:

• Nowe ustawienia z pakietu są dodawane.
• Istniejące zgodne ustawienia są aktualizowane wartościami z importu.
• Ustawienia nieobecne w pakiecie pozostają bez zmian.
• Selektywny import nie usuwa więc automatycznie starych obiektów ani wcześniejszych wartości poza importowanym obiektem.
• Udany import nie dowodzi, że istnieją wszystkie zależności ani że działa ścieżka ruchu.

Przy wymianie sprzętu, reimage, pełnym odzyskiwaniu lub dużej zmianie modelu podstawową procedurą pozostaje backup i restore. Import/eksport pasuje wtedy, gdy zakres jest wyraźnie ograniczony, zależności obiektów są zrozumiałe, a efekt można zweryfikować osobno.

Przygotowanie eksportu

Określenie zakresu i zależności

W Export selective configuration wybiera się wymagane typy konfiguracji. Include dependent entity dołącza obiekty zależne. Ta opcja jest pomocna, ale nie zastępuje kontroli zawartości.

Przykładem jest reguła firewall odwołująca się do hostów, usług, schedule, Web Policy albo obiektów NAT. Jeśli wyeksportuje się tylko regułę, na docelowym firewallu może brakować zależności albo mogą one wskazywać obiekty o innych nazwach. Przed eksportem należy udokumentować:

• który obiekt główny ma zostać zmieniony lub przeniesiony;
• które hosty, sieci, usługi, grupy, profile i polityki od niego zależą;
• które obiekty o tych samych nazwach już istnieją na celu;
• które przepływy produkcyjne mogą zostać dotknięte po imporcie;
• jak zostanie przywrócony poprzedni stan.

Dla konfiguracji RED istnieje udokumentowany wyjątek: REDDevice nie eksportuje automatycznie wymaganej konfiguracji serwera DHCP, nawet po włączeniu Include dependent entity. Trzeba dodatkowo wybrać DHCPServer albo po imporcie kontrolowanie odtworzyć serwer DHCP.

Sprawdzenie wersji i platformy docelowej

Sophos obsługuje import do tej samej lub nowszej wersji firmware. Wersja patternów na docelowym firewallu również musi być taka sama lub nowsza. Jeśli jest starsza, najpierw należy zaktualizować patterny, a potem ponownie zaplanować import.

Konfiguracje selektywne można przenosić tylko z niższego modelu na ten sam lub wyższy zgodny model. Cel musi mieć co najmniej tyle samo portów Ethernet. Jeśli nazwy portów albo funkcje platformy są inne, mapowanie trzeba wyjaśnić wcześniej. Przy takich migracjach Backup Restore Assistant jest często właściwszy niż ręczna modyfikacja XML.

Modele wireless mają dodatkowe ograniczenia dotyczące LocalWiFi, pasm częstotliwości, SSID, starszych Security Modes, TKIP i przypisań do bridge. Udany częściowy import nie oznacza, że przeniesiono każdą konfigurację wireless. Konfigurację docelową trzeba sprawdzić obiekt po obiekcie.

Klasyfikacja SSMK i informacji poufnych

Secure Storage Master Key nie jest podawany podczas eksportu. Ma jednak kluczowe znaczenie przy późniejszym imporcie, jeśli pakiet zawiera hasła, secrety, klucze albo zależne konfiguracje.

• Na innym firewallu albo po Factory Reset lub reimage trzeba podać SSMK należący do eksportu.
• Bez właściwego SSMK SFOS może zaimportować pozostałą część, ale informacje poufne i zależne konfiguracje zostaną utracone.
• Jeśli eksport nie zawiera informacji poufnych, SSMK nie jest potrzebny.
• Import bez komunikatu o błędzie nie dowodzi zatem, że przeniesiono wszystkie secrety i zależności.

SSMK nie jest przechowywany razem z plikiem eksportu. Eksport, pełny backup, hasło backupu i SSMK należy chronić oddzielnie, ale na potrzeby recovery jednoznacznie powiązać z tym samym firewallem i okresem.

Bezpieczna kontrola i modyfikacja pakietu eksportowego

Zrozumienie zawartości pakietu

Po eksporcie dostępny jest plik .tar. Pakiet bez poufnych informacji może zawierać tylko Entities.xml. W przypadku konfiguracji poufnych zawiera również:

• hashFile.json
• propertyfile

Pakiet należy rozpakować do osobnego katalogu roboczego:

tar -xvf <plik-eksportu>.tar

Nie wolno zmieniać nazwy Entities.xml. Jeśli występują hashFile.json i propertyfile, te pliki również trzeba zachować i ponownie dołączyć. Eksport plikowy nie jest odpowiednim formatem do niekontrolowanego globalnego wyszukiwania i zamiany.

Przygotowanie zmian z możliwością prześledzenia

Do raportów, porównań i uporządkowanego przygotowania Sophos Firewall Config Studio może analizować Entities.xml lokalnie w przeglądarce. Także tutaj obowiązuje zasada: wygenerowaną konfigurację należy sprawdzić przed importem. Własnej weryfikacji wymagają zwłaszcza interfejsy, strefy, NAT, VPN, Device Access, Authentication, certyfikaty i HA.

Przed ręczną zmianą należy skopiować niezmieniony Entities.xml. Następnie zmienić tylko zaplanowane wartości i przeczytać diff względem oryginału. Nie przebudowywać na podstawie domysłów nazw elementów, ID, odwołań ani nazw plików. Jeśli znaczenie pola jest niejasne, procedura kończy się przed importem.

Pliki należy ponownie spakować jako archiwum TAR:

tar -cvf <plik-importu>.tar Entities.xml hashFile.json propertyfile

Jeśli pierwotny eksport zawierał tylko Entities.xml, należy spakować tylko ten plik. Nie tworzyć pustych plików towarzyszących ani nie pobierać ich z innego eksportu.

Import konfiguracji

1. Pozostawić otwartą istniejącą sesję Full Admin i alternatywną ścieżkę zarządzania.
2. Potwierdzić okno serwisowe, plik backupu, hasło, SSMK i decyzję o rollbacku.
3. Otworzyć Backup and firmware > Import export.
4. W Import file wybrać wyłącznie przygotowany pakiet .tar.
5. Uruchomić Import i podać właściwy SSMK, gdy SFOS o niego poprosi.
6. W pełni udokumentować sukces, ostrzeżenia i odrzucone obiekty.
7. Przed kolejnymi importami najpierw zweryfikować efekt tego pakietu.

Przy zmianie kilka małych, logicznie rozdzielonych pakietów jest zwykle bezpieczniejszych niż jeden duży, niesprecyzowany import. Ułatwiają zrozumienie zakresu błędu, zależności i ścieżki odzyskiwania. Jest to decyzja operacyjna, a nie gwarancja, że dowolne obiekty można importować niezależnie.

Do powtarzalnej automatyzacji na SFOS 22.0 MR2 lub nowszym służy osobna procedura eksportu i importu konfiguracji przez API Sophos Central. Lokalny import WebAdmin pozostaje przydatny dla ukierunkowanych zmian ręcznych i niezależnej kontroli.

Pełna walidacja importu

Walidacja zaczyna się od obiektu i kończy na rzeczywistej ścieżce ruchu:

1. Otworzyć w WebAdmin zaimportowane obiekty i ich wartości.
2. Sprawdzić zależne hosty, usługi, grupy, profile i polityki.
3. Dla haseł, secretów i kluczy przetestować funkcję, a nie tylko widoczny wiersz obiektu.
4. Otworzyć objętą regułę firewall, NAT, web, VPN albo Authentication oraz sprawdzić kolejność i odwołania.
5. Wykonać kontrolowany test pozytywny i negatywny.
6. W Log Viewer porównać oczekiwane Firewall Rule ID, Action, użytkownika, Source, Destination i Service.
7. W HA oddzielnie sprawdzić stan klastra i działanie po planowanej zmianie ról; nie zakładać ciągłości sesji.
8. Udokumentować Audit Trail, czas, plik importu, wynik testów i decyzję o rollbacku.

W wielowarstwowej walidacji polityk pomaga Systematyczne testowanie reguł firewall. Przy błędach importu istotne mogą być apiparser.log, validation.log, validationError.log, applog.log oraz log odpowiedniej usługi. Usługi i logi Sophos Firewall pokazują ich przypisanie.

Bezpieczne zawężanie typowych błędów

Import zgłasza niezgodną wersję

Porównać aktywny firmware, wersję eksportu i stan patternów na obu firewallach. Nie próbować dopasować starszego firewalla docelowego przez ręczne zmiany XML. Najpierw ustanowić obsługiwany stan firmware i patternów albo przeprojektować ścieżkę migracji.

Brakuje obiektów mimo udanego importu

Sprawdzić, czy użyto Include dependent entity i jakie zależności rzeczywiście ma dany typ obiektu. Dla RED sprawdzić również DHCPServer. Nie ukrywać brakujących zależności za pomocą szerokich obiektów zastępczych ani Any.

Brakuje użytkowników, OTP lub secretów

Użytkownicy uwierzytelniani zewnętrznie, którzy pojawili się lokalnie automatycznie po zalogowaniu, nie są eksportowani tak jak użytkownicy utworzeni ręcznie. Dla MFA OTPSettings eksportuje ustawienia, a OTPTokens zawiera tylko wydane tokeny ręcznie utworzonych użytkowników lokalnych. Sprawdzić także SSMK i cel importu.

Jeśli brakuje informacji poufnych, nie należy po prostu nakładać nowego secretu na istniejący obiekt. Najpierw ustalić, czy przyczyną jest niewłaściwy SSMK, eksport bez ochrony SSMK czy nieeksportowalna tożsamość zewnętrzna. Następnie przetestować działanie użytkowników i grup przez nowe logowanie. Cykl życia kont opisuje Tworzenie i zarządzanie użytkownikami lokalnymi.

Plik TAR jest odrzucany

Sprawdzić nazwy plików i zawartość pakietu. SFOS oczekuje pliku .tar; nazwy Entities.xml nie wolno zmieniać. Istniejące hashFile.json i propertyfile muszą pochodzić z tego samego eksportu. Nie zmieniać jedynie rozszerzenia pliku ZIP na .tar.

Import zakończył się pomyślnie, ale ruch nie działa

Sprawdzić odwołania obiektów, strefy, kolejność reguł, NAT, routing, kontekst użytkownika/grupy i oczekiwany Firewall Rule ID. Zielony status importu potwierdza tylko operację konfiguracji, a nie jej efekt funkcjonalny.

Rollback i checklist

Selektywny import nie ma uniwersalnego przycisku cofania. Przy małych, w pełni udokumentowanych zmianach obiektów można kontrolowanie przywrócić poprzednie wartości. Jeśli zakres lub zależności są niejasne, należy użyć przygotowanej pełnej ścieżki restore.

Przed zakończeniem muszą być spełnione wszystkie poniższe punkty:

• pełny backup, hasło i SSMK są dostępne;
• niezmieniony pakiet eksportowy i wersja po edycji są zarchiwizowane osobno;
• potwierdzono wersję docelową, patterny i zgodność modelu;
• zaimportowano tylko potrzebne obiekty i zależności;
• przeanalizowano ostrzeżenia i nieudane obiekty częściowe;
• secrety i funkcje zależne przetestowano w praktyce;
• pozytywny i negatywny ruch produkcyjny trafiają w oczekiwaną regułę;
• logi i Audit Trail odpowiadają zmianie;
• w HA sprawdzono stan obu węzłów;
• kopie robocze nie pozostają bez ochrony na systemie administracyjnym.

Często zadawane pytania