Bezpieczna konfiguracja administratorów i profili Sophos Firewall

Do codziennej administracji każda osoba powinna otrzymać własne konto. Najpierw tworzy się odpowiedni profil Device Access, a następnie w Authentication > Users lokalnego użytkownika z ustawieniem User type: Administrator. Profil określa, co administrator może wyświetlać lub zmieniać. MFA, źródła logowania i Device Access dodatkowo chronią logowanie oraz dostępność WebAdmin.

Domyślny administrator admin pozostaje przetestowanym dostępem awaryjnym i nie jest używany jako wspólne konto do codziennej pracy. Dzięki temu zmiany można przypisać konkretnej osobie, a błąd w ograniczonym profilu nie blokuje ostatniej drogi odzyskiwania dostępu.

Konfiguracja lokalnego administratora w ośmiu krokach

1. Sprawdzić kopię zapasową, domyślnego administratora i dostęp awaryjny. Istniejącą sesję administracyjną pozostawić otwartą do zakończenia testu.
2. Pisemnie określić zadanie i wymagane uprawnienia, na przykład tylko diagnostykę albo także zmiany obiektów sieciowych.
3. W Profiles > Device access > Add utworzyć własny profil, a niepotrzebne obszary pozostawić jako None.
4. W Authentication > Users > Add wpisać osobistą nazwę użytkownika i ustawić User type na Administrator.
5. Przypisać nowy profil, silne unikatowe hasło i służbowy adres e-mail.
6. W razie potrzeby ograniczyć Schedule for device access i Login restriction for device access w Administrator advanced settings.
7. Sprawdzić, czy Local nadal jest dostępne w Authentication > Services > Administrator authentication methods. Następnie skonfigurować MFA i dostęp do WebAdmin z sieci zarządzającej.
8. Przeprowadzić pozytywny i negatywny test konta w prywatnym oknie przeglądarki. Dopiero potem zmieniać kolejne konta lub wyłączać stare dostępy.

⚠️ Nowy profil można wdrożyć produkcyjnie dopiero wtedy, gdy dostępny jest drugi działający administrator i udokumentowana droga odzyskiwania. Wbudowany profil Administrator zapewnia pełny dostęp i powinien być przypisany tylko najmniejszej niezbędnej grupie osób.

Rozdzielenie pięciu warstw ochrony

W dostępie administracyjnym współdziała kilka ustawień. Realizują różne zadania i nie zastępują się wzajemnie:

• Konto użytkownika: identyfikuje osobę. Konta osobiste umożliwiają śledzenie zmian, natomiast konta zespołowe, takie jak firewalladmin, zacierają to przypisanie.
• Profil Device Access: za pomocą None, Read-only i Read-write określa, które menu i funkcje są widoczne lub możliwe do zmiany. Uprawnienia dotyczą również API.
• Schedule i Login Restriction: ograniczają, kiedy i z jakich adresów IPv4 dane konto administratora może korzystać z WebAdmin.
• Device Access i Local Service ACL: określają, z jakich stref i źródeł WebAdmin jest w ogóle dostępny. Konfigurację opisuje artykuł Bezpieczna konfiguracja Device Access i Local Service ACL.
• MFA i Audit Trail: MFA chroni konto dodatkowo poza hasłem. Audit Trail pomaga przypisać obsługiwane zmiany do tożsamości, źródła i konsoli. Dla Data Anonymization w logach i raportach przygotowuje się dodatkowo co najmniej dwa indywidualne konta authorizerów.

Profil Read-only nie chroni na przykład przed kradzieżą hasła. Z kolei MFA nie zapobiega atakom na niepotrzebnie publicznie dostępną stronę logowania. Dopiero współdziałanie tych warstw ogranicza zarówno uprawnienia, jak i powierzchnię ataku.

Komunikat logowania i dostosowane wiadomości dodają do tych warstw wyłącznie widoczne informacje. Akceptacja nie rozszerza ani profilu Device Access, ani dostępu sieciowego i nie zastępuje żadnego z pięciu mechanizmów kontroli.

Domyślny administrator, konta lokalne i tożsamości centralne

Domyślny użytkownik admin ma uprawnienia wbudowanego profilu Administrator. Nadaje się jako lokalny dostęp awaryjny, ale nie jako współdzielone konto do codziennej pracy. Hasło, MFA, dostęp konsolowy i procedura odzyskiwania muszą być udokumentowane i przetestowane niezależnie od kont osobistych.

Indywidualne lokalne konta administratorów sprawdzają się w małych zespołach, na izolowanych firewallach i jako świadomy fallback. Większe zespoły mogą zarządzać rolami administratorów przez Microsoft Entra ID SSO dla WebAdmin, TACACS+ z lokalnym przypisaniem profilu lub role administracyjne Sophos Central. Użytkownik oznaczony jako Managed by Central w Authentication > Users jest zarządzany w Central i nie można go edytować lokalnie.

Automatyzacje nie otrzymują osobistego konta do codziennej pracy. Dla XML API używa się oddzielnego konta serwisowego z własnym właścicielem, ograniczonymi prawami i stałym dozwolonym źródłem. Pełny sposób ochrony opisuje artykuł Zabezpieczanie dostępu do XML API Sophos Firewall.

Planowanie profilu Device Access

W Profiles > Device access Sophos udostępnia kilka nieedytowalnych profili standardowych:

• Administrator: pełny dostęp do WebAdmin i API. Sophos opisuje również pełny dostęp do CLI, jednak bezpośrednie logowanie SSH w SFOS jest nadal możliwe wyłącznie z domyślną nazwą użytkownika admin.
• Audit admin: dostęp do odczytu i zapisu logów oraz raportów.
• Crypto admin: dostęp do odczytu i zapisu certyfikatów bezpieczeństwa.
• HAProfile: dostęp Read-only do urządzenia Auxiliary w klastrze HA.
• Security admin: dostęp do zapisu funkcji z wyjątkiem profili, logów i raportów.

Profile te są praktycznym punktem wyjścia, ale nie zawsze odpowiadają roli potrzebnej w danym środowisku. Własny profil jest lepszy, gdy osoba potrzebuje tylko jasno ograniczonego zakresu zadań.

Wyprowadzanie uprawnień z zadania

Sama nazwa profilu nie ma skutku technicznego. Profil o nazwie ReadOnly może nadal zawierać prawa zapisu. Decydująca jest pełna macierz uprawnień wraz z rozwiniętymi podmenu.

Dla konta helpdesku można na przykład przyjąć taki plan:

• Ustawić diagnostykę, logi i obszary konfiguracji potrzebne do wsparcia jako Read-only.
• Nadawać Read-write tylko wtedy, gdy zespół musi samodzielnie wykonać konkretnie nazwaną zmianę.
• Profile administratorów, certyfikaty i wszystkie niepotrzebne obszary produktu pozostawić jako None.
• Dla każdego prawa zapisu zdefiniować przykład tego, co ma być dozwolone, oraz przykład tego, czego wyraźnie nie wolno zmieniać.

Profil Network Operations może szerzej odczytywać dane i na przykład zmieniać wybrane obszary sieciowe. Nadal nie potrzebuje pełnego dostępu do administratorów, certyfikatów ani innych niezależnych funkcji bezpieczeństwa. Least Privilege nie oznacza jak najmniejszej liczby widocznych menu, lecz dokładnie te prawa, które są potrzebne do realizacji przypisanego zadania.

Tworzenie własnego profilu

1. Otworzyć Profiles > Device access.
2. Wybrać Add.
3. Wpisać jednoznaczną nazwę, na przykład SFOS-NOC-Limited.
4. Dla każdego widocznego menu wybrać None, Read-only lub Read-write.
5. Za pomocą Expand otworzyć podmenu i bardziej precyzyjnie ograniczyć odmienne uprawnienia.
6. Zapisać przyciskiem Save.
7. Ponownie porównać profil z udokumentowanymi zadaniami i testami negatywnymi.

SFOS-NOC-Limited jest tylko przykładową nazwą. Należy ją dostosować do zespołu i zadania. Faktycznie nadane prawa trzeba dodatkowo udokumentować, ponieważ nazwa nie wyjaśnia macierzy uprawnień.

Tworzenie osobistego lokalnego administratora

Wprowadzanie użytkownika

1. Otworzyć Authentication > Users.
2. Wybrać Add.
3. W Username wpisać trwałą osobistą nazwę, na przykład m.mueller. Nazwy użytkownika nie można później zmienić.
4. Wprowadzić czytelną nazwę wyświetlaną i służbowy adres e-mail.
5. Ustawić User type na Administrator.
6. W Profile wybrać wcześniej sprawdzony profil SFOS-NOC-Limited.
7. Ustawić długie, unikatowe i bezpiecznie przekazane hasło. Jeśli firewall wykryje często używane hasło lub słowo słownikowe, zażąda silniejszego hasła.

m.mueller jest wzorem i należy go zastąpić jednoznaczną tożsamością odpowiedzialnej osoby. Nazw funkcjonalnych, takich jak noc-admin, należy używać tylko wtedy, gdy kryje się za nimi pojedyncza tożsamość techniczna z własnym właścicielem. Kilka osób nie powinno współdzielić hasła.

Ograniczanie czasu i źródła logowania

W Administrator advanced settings dostępne są dwie dodatkowe kontrole:

• Schedule for device access: zezwala na logowanie do WebAdmin wyłącznie w wybranym harmonogramie. Pasuje to do tymczasowego wsparcia lub określonych godzin pracy. Harmonogram dyżuru nie może nieświadomie blokować koniecznych działań awaryjnych.
• Login restriction for device access: zezwala na logowanie do WebAdmin wyłącznie z wybranych adresów IPv4 lub zakresu IPv4. Dla administracyjnego jump hosta można na przykład użyć 10.20.30.25 jako Selected node.

Adres 10.20.30.25 jest przykładem z sieci prywatnej. Należy go zastąpić stałym adresem własnego jump hosta lub stacji administracyjnej. Przy zmiennych adresach klientów administracyjny VPN lub wydzielona sieć zarządzająca są zwykle lepszym rozwiązaniem niż duży zakres IP.

Access Time dla zwykłych użytkowników i grup steruje dostępem do internetu; dla WebAdmin znaczenie ma Schedule for device access w Administrator advanced settings. Nie są to te same ustawienia.

Zachowanie uwierzytelniania lokalnego

W Authentication > Services > Administrator authentication methods lokalna baza danych musi być wybrana dla indywidualnych lokalnych kont administratorów. Domyślny superadministrator admin jest wyłączony z tej listy metod, ale nowo utworzeni administratorzy lokalni już nie.

Nie należy usuwać metody lokalnej, zanim nowe konto nie zostanie pomyślnie przetestowane w oddzielnej przeglądarce. W przypadku zewnętrznych serwerów uwierzytelniania kolejność określa, dokąd najpierw zostanie wysłana próba logowania. Zmiany tej kolejności należą więc do tego samego planu odbioru i rollbacku co samo konto.

Zabezpieczanie logowania za pomocą MFA i ograniczanie dostępności

Dla interaktywnych administratorów należy włączyć MFA. Indywidualne konta administratorów dodaje się w Authentication > Multi-factor authentication do Web admin console. Dla domyślnego użytkownika admin dostępny jest osobny przełącznik w Administration > Device access > MFA for default admin. Artykuł Włączanie MFA dla Sophos Firewall WebAdmin opisuje grupę pilotażową, rejestrację tokena, Login Security i odzyskiwanie. MFA należy najpierw przetestować z jednym nowym administratorem, a nie jednocześnie ze wszystkimi kontami.

WebAdmin pozostaje dodatkowo ograniczony do sieci zarządzających, VPN lub ściśle określonych źródeł. Aktywne Login restriction for device access nie czyni szerokiego udostępnienia z WAN bezpiecznym. Z kolei Local Service ACL nie zastępuje osobistego konta i jego profilu uprawnień.

Pomyślny test WebAdmin nie udostępnia również SSH. SFOS akceptuje do bezpośredniego logowania SSH tylko nazwę użytkownika admin, dlatego osobistego lokalnego administratora WebAdmin nie testuje się jako konta SSH. SSH wymaga dodatkowo osobnej decyzji w Device Access. Zarządzanie kluczem publicznym domyślnego administratora i bezpieczny dostęp SSH opisuje oddzielnie artykuł Łączenie się z Sophos Firewall przez SSH.

W Administration > Admin and user settings ustawienia Administrator password complexity, Session Timeout i Block login uzupełniają konfigurację kont. Wartości te obowiązują w całym systemie, dlatego nie należy ich agresywnie zaostrzać z myślą o jednym koncie. Szczególnie Block login może po błędnych próbach zablokować źródłowy adres IP dla wszystkich usług logowania; przed testem potrzebne jest drugie źródło zarządzania lub dostęp konsolowy.

Bezpieczne testowanie praw i logowania

Przed testem należy zachować dotychczasowe okno administratora i niezależną drogę odzyskiwania. Wielokrotne celowe błędne logowania są niewłaściwe, ponieważ Block login może tymczasowo zablokować wspólny źródłowy adres IP dla kolejnych usług logowania.

1. Otworzyć prywatne okno przeglądarki i wywołać WebAdmin pod przewidzianym FQDN z dozwolonej sieci zarządzającej.
2. Zalogować się przy użyciu nowego konta i MFA.
3. Sprawdzić, czy wszystkie potrzebne menu są widoczne i można odczytać wymagane informacje.
4. Jeśli profil zawiera prawa zapisu, wykonać nieszkodliwą, wcześniej zatwierdzoną zmianę testową z natychmiastowym rollbackiem.
5. Otworzyć obszar ustawiony na None lub Read-only. Konto nie może zapisać tam niedozwolonej zmiany.
6. Przeprowadzić maksymalnie jedną kontrolowaną próbę logowania z niedozwolonego źródła. Przy niejednoznacznym wyniku najpierw przeanalizować ustawienia i logi, bez generowania kolejnych błędnych prób.
7. Sprawdzić zmianę testową i użytego administratora w Configuration Audit Trail. Nie każdy obiekt zapewnia tam taki sam poziom szczegółowości; działanie techniczne trzeba dodatkowo sprawdzić w danej funkcji.
8. Wylogować się, zalogować ponownie i dopiero potem migrować następne konto.

W klastrze HA po planowanym failoverze należy dodatkowo sprawdzić nowe logowanie do aktualnie aktywnego węzła. Istniejąca sesja WebAdmin ani jej płynna kontynuacja nie są wiarygodnym kryterium powodzenia.

Widoczne menu nie dowodzi jeszcze działania praw zapisu. Ukryte menu nie dowodzi, że inne przypisane funkcje działają prawidłowo. Dlatego test pozytywny, test negatywny i przypisanie w audycie należy traktować łącznie.

Sprawdzanie i bezpieczne usuwanie kont

Dostępy administracyjne należy regularnie sprawdzać pod kątem właściciela, zadania, profilu, MFA, źródła logowania i ostatniego użycia. Tymczasowe konta wsparcia otrzymują dodatkowo udokumentowaną datę końcową. Dla ograniczonego czasowo przypadku Avanet obowiązuje osobna procedura Konfiguracja dostępu Avanet Support do Sophos Firewall.

Podczas offboardingu kontrolowany proces jest bezpieczniejszy niż natychmiastowe usunięcie:

1. Sprawdzić, czy konto jest używane w skryptach API, sejfach haseł, dokumentacji lub procesach wsparcia.
2. W Authentication > Users ustawić status jako nieaktywny.
3. W prywatnym oknie przeglądarki sprawdzić, czy nowe logowanie nie jest już możliwe.
4. Osobno sprawdzić aktywne sesje WebAdmin i bieżące zmiany. Wyłączenia konta nie wolno bez dodatkowej kontroli uznać za dowód, że każda istniejąca sesja została natychmiast zakończona.
5. Usunąć lub zmienić tokeny MFA, sekrety i zewnętrzne przypisania związane z kontem.
6. Po uzgodnionym okresie obserwacji usunąć użytkownika, jeśli nie ma już zależności.
7. Niepotrzebny profil niestandardowy usunąć dopiero wtedy, gdy nie jest przypisany do żadnego administratora.

Domyślny administrator nie podlega temu zwykłemu offboardingowi. Jeśli jego hasło lub dostęp MFA zostaną utracone, artykuł Odzyskiwanie hasła administratora Sophos Firewall pomaga przygotować drogę odzyskiwania.

Diagnozowanie typowych problemów

Konto istnieje, ale logowanie do WebAdmin nie działa

Należy sprawdzić kolejno:

• User type jest rzeczywiście ustawiony na Administrator.
• Status użytkownika jest aktywny, a hasło prawidłowe.
• Local jest wybrane w Administrator authentication methods.
• Schedule for device access zezwala na logowanie o bieżącej porze.
• Login restriction for device access zawiera rzeczywisty źródłowy adres IPv4.
• Token MFA, czas systemowy i rejestracja są prawidłowe.
• Block login nie zablokował źródłowego adresu IP po błędnych próbach.
• Device Access lub Local Service ACL zezwala na HTTPS z tego źródła.

Jeśli strona logowania nie jest w ogóle dostępna, analizę należy rozpocząć od Device Access, routingu i adresu źródłowego. Jeśli strona jest dostępna, ale odrzuca tylko to konto, bardziej prawdopodobne są użytkownik, profil, metoda uwierzytelniania, Schedule, Login Restriction i MFA.

W korelacji czasowej pomagają obszar Authentication w Log Viewer oraz access_server.log dla uwierzytelniania i autoryzacji. syslog.log uzupełnia je o zdarzenia systemowe i wywołane przez administratora. Zmiany obsługiwanych obiektów sprawdza się oddzielnie w configuration-audit.log.

Konto widzi zbyt dużo lub zbyt mało

Należy sprawdzić przypisany profil i jego rozwinięte podmenu. Read-only i Read-write mogą być ustawione różnie wewnątrz jednego menu głównego. Następnie trzeba ponowić test po nowym logowaniu i nie polegać wyłącznie na nazwie profilu.

W przypadku Managed by Central rola pochodzi z Sophos Central i nie jest zmieniana przy lokalnym użytkowniku. Przy Entra SSO o lokalnym profilu Device Access decyduje mapowanie ról lub grup serwera Entra.

WebAdmin działa, ale API lub SSH nie

Profil Device Access dotyczy również uprawnień API, jednak API wymaga dodatkowo włączonego dostępu API i dozwolonego źródła. SSH jest oddzielną usługą lokalną i nie stanowi odpowiedniego testu powodzenia dla ograniczonego profilu WebAdmin. Konto nie otrzymuje dostępu SSH tylko dlatego, że logowanie do WebAdmin działa.

Lista kontrolna eksploatacji

• Domyślny administrator i droga odzyskiwania są przetestowane i nie są współdzielone.
• Każda osoba korzysta z własnego konta.
• Profile wynikają z zadań, a rozwinięte podmenu zostały sprawdzone.
• Pełny dostęp jest ograniczony do najmniejszej niezbędnej grupy osób.
• MFA, Schedule i źródło logowania odpowiadają zastosowaniu.
• WebAdmin jest dostępny tylko z przewidzianych źródeł zarządzania.
• Wykonano pozytywne i negatywne testy uprawnień.
• Zmiany można, w obsługiwanym zakresie, przypisać w Audit Trail do osobistego konta administratora.
• Konta API i wsparcia mają własnych właścicieli i cykle życia.
• Offboarding obejmuje status, sesje, MFA, sekrety i zależności.

FAQ