Prawidłowe zarządzanie grupami użytkowników i grupą główną w Sophos Firewall

Grupy użytkowników w Sophos Firewall łączą wspólne zasady dla uwierzytelnionych użytkowników. Pozwalają ujednolicić Access Time, limity, Traffic Shaping, Remote Access i Sign-in Restrictions. Grupa nie zapewnia jednak automatycznego dostępu. Znaczenie mają również rozpoznana tożsamość, obowiązująca grupa główna, konkretna zasada zapory lub VPN oraz jej kolejność.

Bezpieczna skrócona procedura wygląda następująco:

1. Ustalić źródło użytkowników i zadanie, które grupa ma realizować.
2. Dla zwykłych użytkowników stosować grupę typu Normal, a tożsamości urządzeń oparte na adresie IP planować osobno jako Clientless.
3. Utworzyć lub zaimportować małą grupę pilotażową o jednoznacznym przeznaczeniu i możliwie niewielkiej liczbie wspólnych zasad.
4. W sekcji Authentication > Services sprawdzić zamierzoną Default Group albo grupę rezerwową na serwerze Entra.
5. Dla Active Directory udokumentować kolejność w Authentication > Groups > Reorder i określić oczekiwaną grupę główną.
6. Unikać wyjątków dla poszczególnych użytkowników lub jawnie je dokumentować, ponieważ zastępują zasady grupowe.
7. Wykonać nowe logowanie i sprawdzić pola Group oraz Other group memberships w Authentication > Users.
8. Przetestować daną funkcję z użytkownikiem pozytywnym i negatywnym; w przypadku ruchu sprawdzić również oczekiwaną Firewall Rule ID.
9. Dopiero po udanym pilotażu dodać kolejnych użytkowników, a następnie regularnie przeglądać kolejność grup, Default Group i wyjątki.

⚠️ Reorder nie jest nieszkodliwą funkcją sortowania. W przypadku użytkowników AD przesunięcie grupy może zmienić grupę główną, a tym samym MFA, limity, Access Time, Remote Access i inne zasady dla wielu użytkowników. Najpierw należy udokumentować istniejącą kolejność, zasady grup, użytkowników pilotażowych i drogę powrotu.

Zrozumienie modelu grup w kilka minut

Grupa jest na zaporze wspólnym nośnikiem zasad. Może przypisać te same ustawienia wielu użytkownikom, dzięki czemu nie trzeba zarządzać każdym kontem osobno. Nie zastępuje ani uwierzytelniania, ani reguły zapory. Użytkownik może być widoczny we właściwej grupie, a mimo to nie uzyskać dostępu, jeśli brakuje oczekiwanej reguły, zasady VPN, strefy, trasy lub drogi powrotnej.

W eksploatacji pomagają cztery odrębne pytania:

1. Skąd pochodzi tożsamość? Lokalnie, z Active Directory, LDAP, RADIUS, Microsoft Entra ID lub mapowania Clientless opartego na adresie IP.
2. Która grupa obowiązuje? W AD może to być grupa główna albo, w przypadku obsługiwanych funkcji, inne członkostwo w grupie.
3. Która zasada grupowa obowiązuje? Access Time, Quota, Remote Access i inne pola mają różne reguły oceny.
4. Która reguła zezwala na ruch? Same zasady grupowe nie otwierają ścieżki sieciowej.

Nie mieszać grup Normal, importowanych i Clientless

Lokalna grupa typu Normal jest odpowiednia dla użytkowników uwierzytelniających się za pomocą obsługiwanej usługi. Użytkownik lokalny otrzymuje grupę w obiekcie użytkownika. W przypadku zewnętrznego źródła użytkowników lokalne rekordy użytkowników powstają zwykle dopiero po pierwszym udanym logowaniu.

Tymczasowe konta gości są generowane za pośrednictwem Guest user settings i dziedziczą świadomie wybraną restrykcyjną grupę. Bezpieczne tworzenie i obsługa kont gości w Sophos Firewall opisuje tworzenie, ważność, test Captive Portal i wycofanie kont.

Grupy AD są pobierane za pomocą kreatora importu. Członkostwa są utrzymywane w katalogu i oceniane przy logowaniu. Pełny proces konfiguracji serwera, LDAPS i importu opisuje artykuł Łączenie Active Directory z Sophos Firewall. W przypadku ogólnego LDAP trzeba osobno zaplanować bazę wyszukiwania, memberOf lub inny atrybut grupy oraz lokalną Default Group; pola te wyjaśnia artykuł Łączenie serwera LDAP z Sophos Firewall.

Grupa typu Clientless służy do innego celu. Przypisuje tożsamość do stałego adresu IP bez logowania się człowieka. Jest przeznaczona dla drukarek lub innych jednoznacznie przypisanych systemów i nie zastępuje uwierzytelniania użytkowników. Artykuł Konfiguracja Clientless Users w Sophos Firewall opisuje bezpieczny test adresu IP, reguły i wyniku negatywnego.

Świadomy wybór Default Group i grupy rezerwowej

W sekcji Authentication > Services > Firewall authentication methods ustawienie Default group określa grupę przydzielaną użytkownikowi zewnętrznemu, gdy nie istnieje pasująca grupa lokalna. Szeroka lub rozwijana przez lata Default Group może więc przypisać nieoczekiwane zasady. Bezpieczniejsza jest celowo restrykcyjna grupa rezerwowa, której działanie sprawdzono testem pozytywnym i negatywnym.

Microsoft Entra ID SSO używa własnego ustawienia Fallback user group w konfiguracji serwera Entra. Obowiązuje ono również wtedy, gdy serwer jest używany w Firewall authentication methods. Nie należy więc utożsamiać ogólnej Default Group z grupą rezerwową Entra.

Planowanie przykładu i wymagań

Poniższy przykład rozdziela trzy cele:

• Local_Contractors: lokalna grupa pilotażowa dla niewielkiej liczby współpracowników zewnętrznych;
• SFOS_Internet_Standard: importowana grupa AD dla standardowego dostępu do Internetu;
• SFOS_SSLVPN: importowana grupa AD dla zasady SSL VPN;
• auth-pilot@example.com: świadomie utworzone konto testowe;
• LAN-Users-to-WAN: logowana reguła zapory do testu Internetu.

example.com jest domeną zarezerwowaną do celów dokumentacyjnych. Nazwy grup, użytkownika i reguły należy zastąpić własną konwencją nazewniczą. Dobra nazwa grupy opisuje funkcję, a nie tylko dział. Przykładowo SFOS_SSLVPN pozostaje czytelne również po późniejszej zmianie struktury organizacyjnej.

Przed pierwszą zmianą należy zapisać:

• aktualną kolejność w Authentication > Groups;
• Default Group oraz, w przypadku Entra ID, grupę rezerwową;
• zasady grup i wyjątki specyficzne dla użytkowników;
• objęte zmianą usługi uwierzytelniania i zasady Remote Access;
• przetestowany dostęp administratora i niezależną ścieżkę zarządzania;
• użytkownika pilotażowego z oczekiwanym działaniem pozytywnym i negatywnym.

Tworzenie lokalnej grupy użytkowników

W sekcji Authentication > Groups > Add należy utworzyć wspólną konfigurację bazową:

1. W polu Name wpisać Local_Contractors.
2. W polu Group type wybrać Normal.
3. Ustawiać Surfing quota, Access time, Network traffic i Traffic shaping tylko wtedy, gdy grupa rzeczywiście potrzebuje tych funkcji wspólnie.
4. Pola Remote Access, takie jak SSL VPN policy lub IPsec remote access, aktywować tylko dla planowanego dostępu.
5. Ograniczyć Sign-in restriction do rzeczywiście potrzebnych adresów źródłowych lub planowanego zakresu, jeśli model uwierzytelniania na to pozwala.
6. Quarantine digest i MAC binding włączać wyłącznie świadomie.
7. Zapisać przyciskiem Save.

Nazwy pól są określone przez produkt. Wybrane zasady zależą natomiast od środowiska. Zwykła grupa internetowa nie potrzebuje automatycznie VPN, Quota ani MAC Binding. Im mniej zadań łączy grupa, tym łatwiej zrozumieć jej działanie i wycofanie.

Przypisywanie użytkowników bez tworzenia ukrytych wyjątków

Tworzenie i zarządzanie zwykłymi lokalnymi użytkownikami opisuje w pełni nazwę użytkownika, hasło, dziedziczenie grupy, metodę uwierzytelniania i weryfikację. Można ich przypisać do grupy w Authentication > Users. Podczas edycji grupy opcja Show group members pokazuje członków, a Add member(s) pozwala dodać odpowiednich użytkowników lokalnych. Dla tożsamości zarządzanych zewnętrznie źródłem członkostwa pozostaje katalog. Ręczne przypisanie lokalne nie zastępuje prawidłowej konfiguracji AD, LDAP ani Entra.

Zasady specyficzne dla użytkownika mają pierwszeństwo przed zasadami grupy. Wyjątek może być przydatny dla udokumentowanego przypadku lub pilotażu, ale może sprawić, że późniejsza zmiana grupy będzie wyglądać na nieskuteczną. Dla każdego odbiegającego użytkownika należy więc zapisać zastąpione pole, powód wyjątku i sposób powrotu do wartości grupowej.

Pełne tworzenie i testowanie zasad Access Time, limitów Surfing i Network Traffic oraz MFA dla Sophos Firewall pozostaje w odpowiednich artykułach specjalistycznych. W obiekcie grupy przypisuje się tylko wcześniej zaplanowaną zasadę.

Kontrolowana obsługa importowanych grup AD

Grupy AD importuje się na zaporę w Authentication > Servers > Import. W klastrze HA import wykonuje się na urządzeniu Primary. Kreator importuje tylko wybrane grupy. Grupa utworzona później w AD nie pojawia się więc automatycznie na zaporze i musi zostać ponownie zaimportowana albo świadomie utworzona lokalnie z odpowiednią nazwą.

Zagnieżdżone grupy AD nie są oceniane. Jeśli podgrupa ma służyć do reguły zapory, zasady VPN lub innej funkcji, należy zaimportować właśnie tę podgrupę. Podstawowa grupa AD użytkownika również nie jest importowana jako zwykłe członkostwo. Do zasad lepiej nadają się więc jawne grupy zabezpieczeń niż domyślna grupa AD Domain Users.

Po zmianie członkostw AD, importowanych grup lub kolejności grup należy wykonać nowe logowanie. Dopiero wtedy zapora ponownie ocenia grupy i aktualizuje obiekt użytkownika.

Zrozumienie grupy głównej i kolejności grup

Dla użytkownika AD w Authentication > Users widoczne są dwa różne poziomy:

• Group: pierwsza pasująca grupa na liście zapory, a więc grupa główna;
• Other group memberships: pozostałe importowane grupy użytkownika.

Kolejność zmienia się w Authentication > Groups > Reorder. Jeśli auth-pilot@example.com należy do SFOS_Internet_Standard i SFOS_SSLVPN, przy następnym logowaniu grupą główną zostanie pasująca grupa umieszczona wyżej na liście.

Nie należy spontanicznie zmieniać tej kolejności dla pojedynczego incydentu. Najpierw trzeba sprawdzić, której funkcji dotyczy problem i czy w ogóle obsługuje ona inne grupy. Przesunięcie mogłoby naprawić przypadek VPN, a jednocześnie zmienić MFA, Quota lub Access Time dla innych użytkowników.

Wiele grup jest ocenianych różnie w zależności od funkcji

Poniższa granica dotyczy wyłącznie członkostw w grupach Active Directory. Nie wolno przenosić jej bez weryfikacji na LDAP, RADIUS ani Microsoft Entra ID.

Wiele grup AD może być uwzględnianych dla:

• Firewall rules i SSL/TLS inspection rules;
• SD-WAN routes;
• Web policies;
• IPS i Application control policies;
• Policy test;
• Remote access SSL VPN;
• Clientless SSL VPN.

W Remote access SSL VPN uprawnienia pasujących zasad użytkowników i grup są łączone. Jeśli uczestniczy w nich pasująca zasada Full Tunnel, wynikiem jest Full Tunnel. Dlatego tę kombinację należy sprawdzić w rzeczywistym teście klienta, a nie tylko porównując nazwy grup.

Dla poniższych funkcji uwzględniana jest wyłącznie grupa główna albo jawne przypisanie użytkownika:

• WAF rules, My policy overrides i Hotspots;
• Remote access IPsec VPN, L2TP i PPTP;
• Surfing quota, Access time, Network traffic i Traffic shaping;
• Quarantine digest, MAC binding i Sign-in restriction;
• MFA.

W funkcjach obsługujących wiele grup nadal liczy się kolejność odpowiedniej reguły lub zasady. Reguła zapory może na przykład dopasować się przez SFOS_SSLVPN, mimo że SFOS_Internet_Standard jest grupą główną. Nie oznacza to, że MFA lub Quota także korzysta z SFOS_SSLVPN.

Testowanie działania grupy z rzeczywistym użytkownikiem

Zapisana grupa i widoczny użytkownik nie są jeszcze dowodem sukcesu. W pilotażu należy zastosować ten sam proces, który później będzie obowiązywać produkcyjnie:

1. Zakończyć istniejącą sesję użytkownika pilotażowego i wykonać nowe logowanie.
2. W Authentication > Users udokumentować status, Group, Other group memberships i ewentualne wyjątki użytkownika.
3. W Current activities > Live users sprawdzić nazwę użytkownika, źródłowy adres IP i Client Type.
4. Dla reguły zapory opartej na użytkowniku wygenerować oczekiwany przepływ i sprawdzić Firewall Rule ID w Log Viewer.
5. W przypadku Access Time, Quota, MFA lub Remote Access przetestować osobno daną usługę.
6. Wykonać ten sam przepływ jako test negatywny z użytkownikiem spoza grupy pilotażowej.
7. Zapisać wynik, czas, kolejność grup i obowiązującą zasadę.

Testowanie reguł zapory za pomocą Log Viewer, Policy Test i Packet Capture przedstawia pełny test ruchu. Jeśli już nie jest jasne, czy zawodzi wybór usługi, tożsamość, grupa główna czy późniejsza reguła, artykuł Systematyczne rozwiązywanie błędów uwierzytelniania Sophos Firewall prowadzi przez cały łańcuch kontroli.

Zmiany, wycofanie i eksploatacja

Zmiany grup należy traktować tak samo jak zmiany zasad:

1. Udokumentować stan początkowy i użytkowników objętych zmianą.
2. Zmieniać tylko jedną grupę, zasadę lub pozycję naraz.
3. Ponownie uwierzytelnić użytkownika pilotażowego.
4. Ponownie sprawdzić grupę główną, inne członkostwa i konkretną funkcję.
5. Przy nieoczekiwanym działaniu przywrócić poprzednią kolejność grup i przypisanie zasady.
6. Wykonać kolejne nowe logowanie i powtórzyć test pozytywny oraz negatywny.

Grupę AD usuwa się najpierw w katalogu, a następnie na zaporze. Użytkownik, który nadal istnieje w AD, może zostać ponownie utworzony lokalnie przy późniejszym logowaniu. Purge AD users nie jest zatem przyciskiem synchronizacji ani standardowym krokiem po zmianie grupy.

Użytkownicy i grupy współdzielą wewnętrzny zakres identyfikatorów do 65535. Sama duża liczba widocznych obiektów nie dowodzi problemu z limitem. Jeśli użytkownik ma User ID powyżej 65535 i nie staje się Live User, należy zastosować osobną procedurę dotyczącą limitu identyfikatorów użytkowników Sophos Firewall.

Zawężanie błędów według objawu

Nowa grupa AD nie pojawia się na zaporze

Nowe grupy nie są synchronizowane automatycznie. Ponownie uruchomić kreator importu, a w środowisku HA wykonać go na urządzeniu Primary. Następnie w Authentication > Groups sprawdzić, czy istnieje dokładnie wymagana grupa. Nie tworzyć szerokiej grupy zastępczej tylko po to, aby logowanie zadziałało.

Użytkownik ma niewłaściwą grupę główną

Najpierw udokumentować członkostwa AD, importowane grupy i aktualną kolejność. Następnie sprawdzić, czy oczekiwana grupa w ogóle istnieje na zaporze. Planowaną zmianę w Reorder oceniać dopiero po nowym logowaniu i testować z kilkoma reprezentatywnymi użytkownikami.

Reguła zapory pasuje, ale MFA lub Quota nie działa

Reguły zapory obsługują inne grupy AD, natomiast MFA i limity nie. W obiekcie użytkownika sprawdzić, która grupa widnieje w Group jako grupa główna. Następnie skontrolować wyjątki specyficzne dla użytkownika i rzeczywiste przypisanie zasady. Dopasowanie reguły nie dowodzi, że MFA lub Quota ocenia grupy w ten sam sposób.

Zmiana grupy działa nieprawidłowo tylko dla jednego użytkownika

Porównać pola zasad specyficzne dla użytkownika w Authentication > Users. Indywidualny wyjątek ma pierwszeństwo przed zasadą grupową. Nie zmieniać wartości bez analizy, lecz najpierw porównać ją z udokumentowanym wyjątkiem i zamierzonym stanem dziedziczenia.

Użytkownik trafia do Default Group

W AD lub innym klasycznym serwerze uwierzytelniania prawdopodobnie brakuje pasującej grupy lokalnej albo mapowania grupy. Sprawdzić import, nazwę grupy, bazę wyszukiwania i zwracane atrybuty. W przypadku Microsoft Entra ID SSO sprawdzić zamiast tego Fallback user group serwera Entra. Nie poszerzać ogólnie Default Group, aby ukryć właściwy błąd mapowania.

Zagnieżdżona grupa AD nie działa

Zaimportować samą wymaganą podgrupę i dodać do niej użytkownika bezpośrednio. Następnie wykonać nowe logowanie i sprawdzić Group oraz Other group memberships. Import samej grupy nadrzędnej nie wystarcza.

Lista kontrolna eksploatacji

• Cel grupy i odpowiedzialne źródło użytkowników są udokumentowane.
• Grupy lokalne, importowane i Clientless nie są mieszane.
• Default Group lub grupa rezerwowa Entra została wybrana świadomie i restrykcyjnie.
• Kolejność grup i oczekiwane grupy główne są udokumentowane.
• Wyjątki użytkowników są uzasadnione albo usunięte.
• Konkretna funkcja obsługuje używane członkostwo w grupie.
• Użytkownik pilotażowy został ponownie uwierzytelniony i sprawdzony w Authentication > Users.
• Test pozytywny i negatywny potwierdzają oczekiwaną zasadę lub Firewall Rule ID.
• Remote Access, MFA, Access Time i limity zostały przetestowane osobno, jeśli są używane.
• Droga powrotu dla kolejności grup i przypisania zasad jest zapisana.

Często zadawane pytania