Sophos Protected Browser: rozwiązywanie problemów z dostępem i logowaniem

Ten runbook pomaga ustalić przyczyny problemów z dostępem przez Protected Browser i do bezagentowych zasobów RDP/SSH ZTNA. W Sophos Central należy otworzyć Meine Produkte > Protected Browser i rozpocząć od widocznego objawu. Naprawiana jest wyłącznie przyczyna potwierdzona podczas kontroli. Szerokie zmiany w DNS, katalogu użytkowników lub ZTNA utrudniają diagnostykę.

Szybka ścieżka: Jeśli już samo dodawanie lub edytowanie zasobu kończy się niepowodzeniem, należy sprawdzić adresy e-mail wszystkich członków używanej grupy użytkowników. Jeśli istniejący zasób jest nieosiągalny bez konkretnego komunikatu o błędzie, należy najpierw przetestować portal użytkownika ZTNA, a następnie rozpoznawanie DNS nazwy FQDN bramy ZTNA. W przypadku komunikatu „Netzwerk nicht erreichbar” lub „Verbindung konnte nicht hergestellt werden” należy bezpośrednio porównać dostawcę tożsamości skonfigurowanego w ZTNA z metodą logowania w sesji Protected Browser. Jeśli logowanie do Protected Browser nie działa, należy sprawdzić dostęp do Self Service Portal oraz unikatowość adresu e-mail między tenantami. Komunikat „Hostschlüsselüberprüfung fehlgeschlagen” należy obsłużyć osobno.

Wymagania wstępne i bezpieczne granice działań

Opisane kontrole wymagają już skonfigurowanego środowiska Protected Browser i ZTNA oraz jednoznacznie określonego użytkownika, którego dotyczy problem. Brak menu lub uprawnień nie dowodzi konkretnego problemu z licencją lub rolą. W takim przypadku kontrolę należy przekazać odpowiedzialnemu administratorowi Sophos Central.

Do sprawdzenia użytkownika w Sophos Central potrzebny jest dostęp do Meine Umgebung > Benutzer und Gruppen > Benutzer. Test łączności wymaga znajomości faktycznie skonfigurowanej nazwy FQDN bramy ZTNA oraz typu bramy: Sophos Cloud Gateway lub brama lokalna. W poleceniu symbol zastępczy należy zastąpić nazwą FQDN bramy ZTNA, a nie nazwą docelowego zasobu RDP/SSH.

Podczas diagnostyki należy zmieniać tylko jedną wartość naraz, a następnie ponawiać test z tym samym użytkownikiem i urządzeniem. Jeśli wymaganie wstępne jest niejasne lub brakuje dostępu do zarządzania użytkownikami, należy przerwać diagnostykę i przekazać sprawę odpowiedzialnemu administratorowi Sophos Central, usługi katalogowej lub ZTNA.

Rozwiązywanie problemów według objawów

Dodawanie lub edytowanie bezagentowego zasobu RDP/SSH kończy się niepowodzeniem

Prawdopodobna przyczyna: Co najmniej jeden członek używanej grupy użytkowników nie ma prawidłowego adresu e-mail. Może to dotyczyć zarówno zasobu ZTNA, jak i zasobu RDP/SSH w grupie aplikacji Protected Browser.

Kontrola:

1. Otworzyć Meine Umgebung > Benutzer und Gruppen > Benutzer.
2. W kolumnie E-Mail sprawdzić wszystkich użytkowników grupy, która ma zostać przypisana do zasobu lub grupy aplikacji.

Oczekiwany wynik: Każdy użytkownik w grupie, której dotyczy problem, ma prawidłowy adres e-mail. Pusty wpis potwierdza stan błędu.

Bezpieczne działanie: Brakujący adres należy dodać w nadrzędnej usłudze katalogowej. Bezpośrednio w Sophos Central należy go dodać wyłącznie dla użytkowników utworzonych ręcznie w Sophos Central. Nie należy zmieniać istniejących adresów na podstawie przypuszczeń.

Ponowna walidacja: Ponowić próbę dodania lub edytowania tego samego zasobu bez zmiany grupy. Jeśli operacja nadal nie działa pomimo kompletnej kolumny E-Mail, ta przyczyna nie została potwierdzona. Zamiast zmieniać kolejne dane tożsamości, należy zapisać typ zasobu, grupę, czas i widoczny komunikat, a następnie eskalować sprawę.

Bezagentowy zasób RDP/SSH jest nieosiągalny przez Protected Browser

Prawdopodobna przyczyna: Urządzenie nie może prawidłowo rozpoznać nazwy FQDN bramy ZTNA. Pierwszym punktem rozgraniczenia jest jednak portal użytkownika ZTNA: jeśli również on jest nieosiągalny przez Protected Browser, problem występuje przed konkretnym zasobem RDP/SSH.

Kontrola:

1. Na tym samym urządzeniu i jako ten sam użytkownik spróbować otworzyć portal użytkownika ZTNA przez Protected Browser.
2. Jeśli portal jest nieosiągalny, wykonać zapytanie DNS na urządzeniu, którego dotyczy problem:

nslookup <ZTNA-Gateway-FQDN>

<ZTNA-Gateway-FQDN> należy zastąpić faktycznie skonfigurowaną nazwą bramy. nslookup jest testem tylko do odczytu i nie zmienia konfiguracji.

Oczekiwany wynik: W przypadku Sophos Cloud Gateway nazwa bramy jest rozpoznawana jako adres serwera proxy bramy. W przypadku bramy lokalnej jest rozpoznawana jako adres bramy ZTNA skonfigurowany na własnym serwerze DNS. Odpowiedź należy porównać z faktycznie skonfigurowanym celem właściwym dla danego modelu bramy. Jeśli rozpoznawanie nie działa, trzeba sprawdzić konfigurację DNS. Inna odpowiedź potwierdza błąd dopiero wtedy, gdy nie odpowiada skonfigurowanemu celowi. Jeśli docelowa wartość jest nieznana, nie należy zmieniać DNS, lecz przekazać kontrolę osobie odpowiedzialnej za DNS/ZTNA.

Bezpieczne działanie: Konfigurację DNS należy poprawić zgodnie z właściwą procedurą DNS/ZTNA. Prawidłowa strefa i cel zależą od modelu bramy, dlatego nie należy tu wprowadzać ogólnych zmian DNS.

Ponowna walidacja: Gdy osoba odpowiedzialna za DNS/ZTNA potwierdzi poprawkę zgodną z właściwą procedurą, należy ponownie wykonać to samo zapytanie nslookup. Następnie należy otworzyć portal użytkownika ZTNA i dopiero potem przetestować pierwotny zasób RDP/SSH. Jeśli odpowiedź DNS jest zgodna z oczekiwaniami, a portal jest osiągalny, ale zasób nadal nie, należy udokumentować te dwie pozytywne kontrole i eskalować badanie ZTNA specyficzne dla zasobu.

„Netzwerk nicht erreichbar” lub „Verbindung konnte nicht hergestellt werden”

Prawdopodobna przyczyna: ZTNA korzysta z dostawcy tożsamości, takiego jak Okta lub Entra ID, ale użytkownik zalogował się do Protected Browser za pomocą Sophos ID lub jako użytkownik lokalny. Podczas dostępu do aplikacji SSH lub RDP za bramą ZTNA mogą wtedy pojawić się wymienione komunikaty.

Kontrola: Ustalić, który dostawca tożsamości jest skonfigurowany w ZTNA, i porównać go z metodą logowania bieżącej sesji Protected Browser.

Oczekiwany wynik: Przyczyna zostaje potwierdzona, jeśli ZTNA korzysta z dostawcy tożsamości, ale sesja Protected Browser nie została uwierzytelniona przez tego dostawcę.

Bezpieczne działanie: Zakończyć sesję, której dotyczy problem, i zalogować użytkownika do Protected Browser za pośrednictwem dostawcy tożsamości skonfigurowanego w ZTNA. Nie należy zmieniać dostawcy tożsamości ZTNA w celu obejścia pojedynczego błędu logowania.

Ponowna walidacja: W nowo uwierzytelnionej sesji otworzyć tę samą aplikację SSH lub RDP. Jeśli komunikat nadal występuje mimo zgodnych metod logowania, należy zapisać dostawcę tożsamości, użytkownika, zasób i czas, a następnie przekazać sprawę osobie odpowiedzialnej za ZTNA.

Użytkownik nie może zalogować się do Protected Browser

Należy tu sprawdzić dwie niezależne przyczyny. Nie należy naprawiać ich jednocześnie, aby można było ustalić rzeczywistą przyczynę.

Brak dostępu do Self Service Portal

Kontrola: Otworzyć Meine Umgebung > Benutzer und Gruppen > Benutzer i sprawdzić kolumnę Rolle dla użytkownika, którego dotyczy problem. Można też wybrać nazwę użytkownika i sprawdzić tekst pod zdjęciem profilowym.

Oczekiwany wynik: Jeśli użytkownik ma dostęp do Sophos Central Self Service Portal, w kolumnie Rolle lub pod zdjęciem profilowym wyświetla się SelfService.

Bezpieczne działanie: Jeśli brakuje SelfService, przypisanie dostępu do Self Service Portal należy przekazać odpowiedzialnemu administratorowi Sophos Central.

Ponowna walidacja: Najpierw potwierdzić wyświetlanie SelfService, a następnie ponowić logowanie dokładnie dla tego użytkownika.

Adres e-mail jest powiązany z wieloma kontami Sophos Central

Kontrola: Ustalić, czy adres e-mail użytkownika, którego dotyczy problem, jest przypisany do wielu kont Sophos Central.

Oczekiwany wynik: Adres nie może być powiązany z wieloma kontami Sophos Central.

Bezpieczne działanie: Poprawienie przypisania należy zlecić odpowiedzialnemu administratorowi tenanta lub tożsamości. Bez potwierdzonego tenanta docelowego nie należy usuwać użytkownika ani zmieniać adresu używanego produkcyjnie.

Ponowna walidacja: Po potwierdzeniu unikatowego przypisania ponowić logowanie do Protected Browser. Jeśli nadal się nie powiedzie, na potrzeby eskalacji udokumentować SelfService, przypisanie adresu e-mail, czas i widoczny komunikat.

SSH zgłasza „Hostschlüsselüberprüfung fehlgeschlagen”

Prawdopodobna przyczyna: Klucz zapisany w kliencie SSH nie odpowiada już kluczowi hosta. Może się to zdarzyć po prawidłowej zmianie, takiej jak ponowna instalacja, ale ten sam komunikat może również wskazywać na nieoczekiwaną zmianę.

Kontrola: Uzyskać oczekiwany odcisk klucza hosta od osoby odpowiedzialnej za system za pośrednictwem niezależnego, zaufanego kanału i porównać go z odciskiem prawidłowego hosta docelowego. Nie należy polegać ani na nieudanym połączeniu SSH, ani na oferowanym w nim nowym kluczu. Jeśli oczekiwany odcisk nie został niezależnie potwierdzony, nie jest zgodny lub zmiany nie można wyjaśnić, należy zatrzymać się w tym miejscu i eskalować zdarzenie jako incydent bezpieczeństwa.

Oczekiwany wynik: Host docelowy, prawidłowa zmiana klucza i oczekiwany odcisk zostały niezależnie i jednoznacznie potwierdzone.

Bezpieczne działanie: Przed usunięciem należy ustalić, które wpisy usuwa funkcja oferowana przez używany klient SSH. Sophos podaje jako przykład Bekannte Hosts löschen, ale nie potwierdza, że ta funkcja usuwa wyłącznie hosta, którego dotyczy problem. Jeśli zakres usunięcia jest nieznany lub nie można niezależnie potwierdzić oczekiwanego odcisku, nie należy wykonywać resetu, lecz eskalować sprawę. Zapisany klucz można usunąć dopiero po ustaleniu zakresu i potwierdzeniu odcisku. Przy następnym połączeniu należy zaakceptować wyłącznie klucz, którego odcisk odpowiada niezależnemu potwierdzeniu.

Ponowna walidacja: Ponownie nawiązać połączenie. Weryfikacja klucza hosta powinna zakończyć się powodzeniem z nowo zaakceptowanym kluczem. Jeśli komunikat pojawi się ponownie lub klucz znów nieoczekiwanie się zmieni, nie należy wielokrotnie usuwać wpisów, lecz eskalować sprawę, podając nazwę hosta, czas i klient SSH.

Wycofanie zmian, eskalacja i ograniczenia operacyjne

Nie ma uniwersalnego rollbacku dla tych problemów. Bezpieczny powrót polega na unikaniu szerokich zmian i zapisaniu wartości początkowej każdego celowo zmienionego przypisania użytkownika. Jeśli działanie nie przyniesie skutku, należy zatrzymać się w odpowiednim punkcie eskalacji. Usunięcie znanych kluczy hosta SSH nie jest ogólnym resetem i jest dopuszczalne tylko wtedy, gdy odcisk został niezależnie potwierdzony, a zakres usunięcia jest znany.

Na potrzeby eskalacji wewnętrznej lub do pomocy technicznej należy zapisać co najmniej objaw, użytkownika, urządzenie, typ zasobu, model bramy, nazwę FQDN bramy ZTNA, czas i wynik bezpośrednio związanej kontroli. Dane logowania, klucze prywatne i tokeny nie mogą znaleźć się w zgłoszeniu.

Należy powtórzyć wyłącznie kontrolę związaną z faktycznie wykonanym działaniem lub potwierdzonym przekazaniem: ponowne dodanie lub edytowanie zasobu po poprawieniu adresu e-mail; logowanie po potwierdzeniu dostępu do Self Service Portal lub unikatowego przypisania konta; otwarcie zasobu po zalogowaniu przez skonfigurowanego dostawcę tożsamości; albo połączenie SSH po kontrolowanym resecie klucza hosta. Po przekazaniu osobie odpowiedzialnej za DNS/ZTNA należy ponownie przetestować nslookup, portal użytkownika i pierwotny zasób dopiero wtedy, gdy osoba ta potwierdzi poprawkę zgodną ze swoją procedurą.

Zakres względem powiązanych instrukcji

Ten runbook obejmuje wyłącznie opisane tutaj objawy dotyczące Protected Browser. Konfiguracja Protected Browser lub rozszerzenia oraz ogólna konfiguracja DNS i ZTNA należą do odpowiednich instrukcji konfiguracji. Jeśli taka konfiguracja jest wymagana, sprawę należy przekazać odpowiedzialnemu administratorowi.