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. None uniemożliwia administratorowi wyświetlenie danej konfiguracji w WebAdmin lub pobranie jej przez API. Read-only pozwala natomiast ją odczytać, ale nie zmieniać.
• 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.

Podczas pierwszej konfiguracji trzeba zmienić fabryczne hasło domyślnego superadministratora. Nowe hasło nie może być często używanym hasłem ani słowem słownikowym: firewall porównuje je z odpowiednią bazą danych i w razie zgodności prosi o zmianę. Ta kontrola jest już częścią pierwszej konfiguracji, a nie dopiero tworzenia kont osobistych.

Przy aktualizacji z 18.0 MR3 lub wcześniejszej wersji albo 17.5 MR14 konieczna jest jednorazowa zmiana hasła domyślnego superadministratora, aby skorzystać z silniejszej ochrony hasła. Nie jest to ogólny wymóg przy każdej aktualizacji firmware.

Przechowywać bieżące hasło w sejfie haseł z kontrolowanym dostępem. Jeśli nastąpi powrót do wcześniejszej wersji firmware, która używa tego hasła, będzie ono potrzebne do zalogowania. Przed wycofaniem firmware muszą więc być dostępne hasło wymagane przez wcześniejszą wersję i niezależna ścieżka awaryjna; nie należy zakładać, że ostatnie hasło ustawione w nowszym firmware jest tam również ważne.

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 Fusion. Użytkownik oznaczony jako Managed by Central w Authentication > Users jest zarządzany w Sophos Fusion i nie można go edytować lokalnie.

Dla SFOS 23 artykuł Google Workspace OIDC z mapowaniem grup administratorów opisuje kolejny sposób scentralizowanego logowania z osobnym kontem serwisowym, lokalnymi profilami Device Access oraz planowaniem i weryfikacją możliwości powrotu do poprzedniej konfiguracji.

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ń.

Zmiana istniejących uprawnień bez utraty dostępu

Aby sprawdzić istniejący profil, otworzyć Profiles > Device access i wybrać Edit przy odpowiednim profilu. Za pomocą Expand rozwinąć podmenu, aby zobaczyć całą bieżącą macierz uprawnień; podczas samego sprawdzania nie zmieniać ani nie zapisywać żadnych uprawnień. Profile standardowe pozostają nieedytowalne: Edit umożliwia jedynie ich przeglądanie, a uprawnienia można zmieniać wyłącznie w profilach niestandardowych.

Zmiana profilu wpływa na wszystkich administratorów, którym go przypisano. Przed zaostrzeniem ustawień należy udokumentować bieżącą nazwę profilu, całą rozwiniętą macierz uprawnień i wszystkie przypisane konta. Stan poprzedni obejmuje również kolejność w Authentication > Services > Administrator authentication methods, harmonogram, ograniczenie logowania, dostęp WebAdmin w Administration > Device access oraz bieżące wartości złożoności hasła i Block login. Aktualna kopia konfiguracji, otwarta sesja drugiego pełnego administratora i sprawdzony dostęp do konsoli są warunkami wstępnymi, ale nie stanowią samego wycofania.

Zamiast bezpośrednio edytować wspólny profil, należy utworzyć osobno profil bardziej restrykcyjny i przypisać go najpierw dokładnie jednemu kontu pilotażowemu. Pozostałe konta migruje się pojedynczo dopiero po teście pozytywnym, negatywnym i kontroli audytu.

Bezpieczne wycofanie przywraca z nadal otwartej pełnej sesji dokładnie udokumentowane wcześniejsze wartości: ponownie przypisuje pilotowi poprzedni profil i cofa zmienione metody oraz kolejność uwierzytelniania, harmonogram, ograniczenie logowania, Device Access i wartości blokady do ich poprzedniego stanu. Gdy sesja nie działa, używa się sprawdzonego drugiego administratora lub lokalnej konsoli. Pełną kopię przywraca się tylko w zaplanowanym oknie awaryjnym, ponieważ cofa też niezwiązane zmiany.

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. SFOS zapisuje ją małymi literami i automatycznie konwertuje wielkie litery; 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 znajdują się dwie oddzielne sekcje: Administrator password complexity settings dla administratorów i User password complexity settings dla użytkowników. W każdej sekcji osobno włączyć Enable password complexity check i ustawić wymaganą złożoność. Ustawienie dla administratorów nie zastępuje ustawienia dla użytkowników. Wartości dobrać zgodnie z własną polityką haseł; nie podaje się tutaj stałej minimalnej długości ani liczby znaków jako wymogu produktu. Przed zmianą udokumentować oba ustawienia i ich poprzednie wartości. Po zapisaniu ponownie otworzyć stronę i sprawdzić obie sekcje oddzielnie, zachowując dostępność przetestowanej ścieżki awaryjnej.

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.

Przed zmianą Block login należy dokładnie zapisać stan pola, liczbę i okno czasowe nieudanych prób oraz czas blokady. Po osiągnięciu progu źródłowy adres IP jest blokowany dla WebAdmin, CLI, VPN Portal i User Portal. Pojedyncza nieudana próba poniżej progu nie sprawdza tego mechanizmu; Sophos informuje również, że błędny CAPTCHA nie jest liczony jako nieudana próba logowania. W środowisku produkcyjnym należy najpierw tylko potwierdzić zapisanie wartości i poprawne logowanie z obu źródeł zarządzania. Jeśli rzeczywisty test blokady jest konieczny, należy przeprowadzić go w oknie serwisowym z odizolowanego źródła testowego aż do osiągnięcia progu. Następnie trzeba potwierdzić oczekiwaną blokadę, odczekać udokumentowany czas albo użyć niezależnej ścieżki awaryjnej, a potem potwierdzić poprawne logowanie. W razie nieoczekiwanego zachowania otwarta sesja awaryjna przywraca dokładnie wcześniejsze wartości.

Opcja Log out admin session after domyślnie kończy nieaktywne sesje WebAdmin po 10 minutach. Jej wyłączenie nie pozostawia sesji otwartej bez ograniczeń: SFOS nadal automatycznie wylogowuje ją po 30 minutach. Wyłączenie tej opcji nie jest więc sposobem na utrzymanie stałej sesji administracyjnej; rzeczywiste zachowanie należy sprawdzić w sesji testowej.

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.

Logi i raporty nie są synchronizowane między urządzeniami HA: podczas diagnostyki trzeba sprawdzić Log viewer > System i właściwe zdarzenia uwierzytelniania na obu urządzeniach. Od SFOS 22.0 MR1 zmiany na pojedynczym firewallu przez Sophos Fusion (dawniej Sophos Central) zapisują tożsamość użytkownika Sophos Fusion, a sesje Entra ID SSO ponownie oceniają zasady Conditional Access. Po aktualizacji należy sprawdzić przypisanie nieszkodliwą zmianą testową. Przed każdym wdrożeniem należy sprawdzić docelowy build, obsługiwaną ścieżkę aktualizacji i blokery właściwe dla wersji w kontroli aktualizacji do SFOS 22 oraz zatwierdzić je w zmianie; zawarta tam kontrola wydań i znanych problemów rozstrzyga o decyzji wdrożeniowej.

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.

Konto to trzeba odróżnić od dostępu producenta w Diagnostics > Support access. Generuje on na wybrany czas Access ID, dzięki któremu Sophos Support uzyskuje dostęp do WebAdmin i powłoki bez otrzymywania danych administratora. Firewall zestawia połączenie TCP 22 z *.apu.sophos.com; systemy nadrzędne muszą je dopuścić. Access ID przekazuje się wyłącznie w aktywnym zgłoszeniu, monitoruje stan podczas prac i natychmiast wyłącza Support access po ich zakończeniu, nawet przed upływem czasu.

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 Fusion 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.

NC-177609 jest udokumentowany konkretnie dla SFOS 22.0 GA Respin Build 411: po aktualizacji zmiany konfiguracji przez API wykonywane przez migrowanego użytkownika mogą być odrzucane, gdy MFA jest aktywne, a żądanie nie zawiera one-time token. Jeśli objaw dokładnie pasuje, należy udokumentować build i stan migracji konta. Udokumentowane obejście wymaga, aby automatyzacja korzystała z dedykowanego konta API o minimalnych uprawnieniach, dla którego MFA jest wyłączone albo które wyraźnie wykluczono z MFA; MFA pozostaje aktywne dla administratorów interaktywnych. Wyznaczony właściciel API musi zatwierdzić i udokumentować ten wyjątek, przypisać właściciela konta i termin przeglądu, ograniczyć źródło i uprawnienia API, przechowywać sekret w sejfie i rotować go, monitorować użycie oraz usunąć wyjątek, gdy przestanie być potrzebny. Po zmianie należy przeprowadzić walidację nieszkodliwym żądaniem odczytu, a następnie zatwierdzoną, kontrolowaną operacją zapisu z rollbackiem. Zabezpieczanie dostępu do XML API Sophos Firewall wraz z wyznaczonym właścicielem API odpowiada za ten proces; nie należy wnioskować o statusie poprawki na podstawie późniejszego buildu.

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.
• Udokumentowano stan poprzedni i wycofanie między kontami dla zmian profilu, uwierzytelniania i blokady.
• W HA sprawdzono nowe logowanie i oddzielne logi na obu urządzeniach.
• Konta API i wsparcia mają własnych właścicieli i cykle życia.
• Offboarding obejmuje status, sesje, MFA, sekrety i zależności.

FAQ