Bezagentowy dostęp RDP i SSH za pomocą Sophos Protected Browser

Sophos Protected Browser umożliwia dostęp do wewnętrznych hostów RDP i SSH bez agenta ZTNA na urządzeniu użytkownika. Sophos wymienia te dwa przypadki użycia pod Access RDP agentlessly via Protected Browser i Access SSH agentlessly via Protected Browser. Dostęp pozostaje ograniczony do Protected Browser: połączenia utworzonego jako zasób RDP lub SSH bez agenta nie można otworzyć za pomocą zwykłego klienta RDP lub SSH.

Bezpieczna procedura jest taka sama dla obu protokołów: najpierw należy przygotować obsługę tożsamości, bramę i łączność, a następnie utworzyć politykę ZTNA bez agenta oraz osobny zasób dla każdego hosta. W Protected Browser zasób dodaje się do grupy aplikacji i zezwala na niego za pomocą polityki internetowej. Dopiero wtedy można rozpocząć testy z niewielką grupą użytkowników.

Wymagania, licencje i role

Przed konfiguracją muszą zostać spełnione następujące punkty:

Protected Browser jest zainstalowany na obsługiwanym urządzeniu z systemem Windows lub macOS. W poniższym przykładzie użyto urządzenia z systemem Windows i zielonym stanem kondycji.
Użytkownicy i grupy są synchronizowane, dostawca tożsamości jest skonfigurowany, a brama ZTNA działa.
Brama może połączyć się z wewnętrznym hostem RDP lub SSH. To połączenie jest sprawdzane przed utworzeniem zasobu.
Dla zasobu istnieje najmniejsza możliwa grupa użytkowników. Obiekt współdzielony dla wszystkich pracowników nie nadaje się do dostępu administracyjnego.
Osoba wykonująca procedurę może zarządzać politykami i zasobami w obszarze My Products > ZTNA oraz obiektami polityk i politykami internetowymi w obszarze My Products > Protected Browser.

Informacje o produkcie udostępnione dla tego procesu nie określają konkretnej nazwy roli ani oddzielnej licencji SKU. Nie należy zatem uznawać samej widoczności menu za potwierdzenie uprawnień ani nadawać ogólnych praw superadministratora. Przed dokonaniem zmiany sprawdź we własnej dzierżawie, czy ZTNA i Protected Browser są dostępne i czy użyte konto administratora ma uprawnienia do tworzenia wspomnianych obiektów. Jeśli brakuje strony lub przycisku, przed kontynuowaniem pracy poproś osobę odpowiedzialną o sprawdzenie licencji i ról w dzierżawie.

Możliwe tryby wdrożenia ZTNA to Bramka lokalna i Sophos Cloud Gateway. Ich udostępnianie, synchronizacja użytkowników i tożsamości, domeny, certyfikaty i DNS stanowią część wspólnego fundamentu ZTNA. Prawidłowa kolejność została wyjaśniona Konfiguracja Sophos ZTNA. W tym przewodniku celowo nie powtarzamy tych typowych procedur.

Wcześniejsze sprawdzenie DNS i certyfikatów

Domena bramy, certyfikat i wymagane publiczne i wewnętrzne rozpoznawanie DNS muszą już działać. Właściciel ZTNA przygotowuje tę wspólną podstawę zgodnie z podanym przewodnikiem ZTNA; w tym miejscu nie jest ona powielana ani zmieniana.

Opisane tutaj zasoby RDP i SSH korzystają ze specjalnego formularza: wpisz adres w polu Internal FQDN/IP address of the resource; nie można dodać wartości External FQDN. Dlatego też nie wolno kopiować do tego pola ogólnych przykładów DNS dla aplikacji internetowych ZTNA. Domeny i certyfikaty są przygotowywane przez właściciela ZTNA przed utworzeniem zasobu RDP lub SSH.

Przygotuj przykładowe wartości

Poniższe nazwy umożliwiają rozpoznawanie powiązanych obiektów. Nie stanowią one specyfikacji produktu i należy je dostosować do własnej konwencji nazewnictwa:

Polityka ZTNA: Agentenloser Zugriff
Zasób RDP: Agentenloses RDP
Zasób SSH: Agentenloses SSH
Stan urządzenia: Grünes Windows
Grupa aplikacji: Agentenlose RDP-Gruppe lub Agentenlose SSH-Gruppe
Polityka internetowa: Agentenloser RDP-Zugriff von Windows-Systemen mit grüner Integrität lub wariant SSH
Host wewnętrzny: na przykład rdp01.intern.example lub ssh01.intern.example

FQDN jest łatwiejszy do kontrolowania niż zmieniający się adres IP, ale musi być poprawnie rozwiązany z punktu widzenia bramy. Jeśli testowane są oba protokoły, należy utworzyć oddzielne zasoby i grupy aplikacji. Dzięki temu przypisania, wyniki weryfikacji i późniejsze wycofanie z eksploatacji pozostają łatwe do prześledzenia.

Dodaj bezagentową politykę ZTNA

Można ponownie wykorzystać istniejącą, odpowiednio zdefiniowaną politykę bezagentową. Jednakże posiadanie własnej polityki pilotażowej zmniejsza ryzyko niezamierzonego wpływu na zasoby produkcyjne.

Otwórz My Products > ZTNA > Policies.
Kliknij Add policy.
W obszarze Add policy wybierz typ Agentless. W innych widokach ZTNA ten typ jest określany jako Agentless. Monit o wymaganiu agenta dotyczy ścieżki opartej na agencie; ta polityka nie wymaga agenta.
W polu New policy wprowadź nazwę, na przykład Agentenloser Zugriff.
Otwórz Policy enforced i włącz Policy is enforced.
Kliknij Save.

Typ polityki ZTNA Agent i jego tunele nie są częścią tego przepływu. Również globalny Agent tunnel inactivity timeout ma zastosowanie do tunelu agenta i nie jest zegarem sesji RDP ani SSH dla Protected Browser. Właściciel ZTNA powinien nadal znać globalny Minimum time before device health triggers a rule, jeśli w całym środowisku używana jest integralność urządzenia.

Dodaj zasób RDP lub SSH

Otwórz My Products > ZTNA > Resources & Access i kliknij Add Resource. Wypełnij formularz odpowiednio do wybranego protokołu.

Zasób RDP

Na przykład wprowadź Agentenloses RDP jako Resource name. Opis jest opcjonalny.
Wybierz bramę, która może połączyć się z hostem rdp01.intern.example.
W obszarze Access method wybierz wartość Agentless.
Wybierz politykę Agentenloser Zugriff.
Dla Resource type wybierz RDP. Port 3389 i typ portu dostępowego TCP są ustawiane automatycznie i nie można ich zmienić w tym formularzu.
W przypadku Internal FQDN/IP address of the resource należy wprowadzić hosta wewnętrznego. Dla tego typu zasobu nie można dodać zewnętrznego FQDN.
W obszarze Assign User Groups przenieś tylko wymaganą grupę pilotażową z dostępnych grup do Assigned User Groups.
Kliknij Save.

Zasób SSH

W przypadku SSH użyj tego samego przepływu z następującymi wartościami specyficznymi dla protokołu:

Resource name: na przykład Agentenloses SSH.
Access method: Agentless.
Policy: Agentenloser Zugriff.
Resource type: SSH. Port 22 i typ portu dostępowego TCP są ustawiane automatycznie i nie można ich zmienić.
Internal FQDN/IP address of the resource: na przykład ssh01.intern.example; zewnętrzny FQDN nie jest dostępny.
Assign User Groups: przenieś tylko zamierzoną grupę pilotażową do Assigned User Groups, a następnie Save.

Zasoby oparte na agentach i aplikacje internetowe mają inne możliwości. Na przykład agent może uwzględnić stan urządzenia w polityce dostępu ZTNA i kontrolować aplikacje lokalne. Dla wybranej tutaj ścieżki zasób pozostaje Agentless. W razie potrzeby dodatkową kontrolę urządzenia konfiguruje się w polityce internetowej Protected Browser.

Ogranicz dostęp w Protected Browser

Utwórz opcjonalny stan urządzenia

Dodanie statusu urządzenia jest opcjonalne. Bez tego obiektu grupa pilotażowa powinna być szczególnie ograniczona. Udokumentowany przykład z zarządzanymi urządzeniami z systemem Windows:

Otwórz My Products > Protected Browser > Policy objects.
Kliknij Add object > Device posture.
Jako nazwę wpisz Grünes Windows.
W obszarze OS platform wybierz wartość Windows.
W obszarze Endpoint Protection wybierz opcję Check if device is protected by Sophos Endpoint, a następnie stan integralności Green.
Kliknij Save.

Dodatkowe kontrole zwiększają bezpieczeństwo, ale mogą również wykluczyć więcej urządzeń. Dlatego każdy dodatkowy warunek jest najpierw testowany z grupą pilotażową.

Utwórz grupę aplikacji

Pozostań w obszarze My Products > Protected Browser > Policy objects.
Kliknij Add object > Application group.
Wprowadź unikalną nazwę, na przykład Agentenlose RDP-Gruppe.
Rozwiń ZTNA resources.
W obszarze Available wybierz wcześniej utworzony zasób i przenieś go do Assigned.
Kliknij Save.

Dla SSH utwórz Agentenlose SSH-Gruppe i przypisz Agentenloses SSH. Oddzielne grupy zapobiegają niezauważalnej zmianie dostępu RDP w przypadku późniejszej zmiany dostępu SSH.

Dodaj politykę internetową

Otwórz My Products > Protected Browser > Web policy i wybierz zakładkę Policies.
Kliknij Add policy.
Wprowadź unikalną nazwę, na przykład Agentenloser RDP-Zugriff von Windows-Systemen mit grüner Integrität.
Upewnij się, że wybrano Allow.
Jeśli jest używany, wybierz status urządzenia Grünes Windows.
Wybierz grupę aplikacji Agentenlose RDP-Gruppe.
Kliknij Save.

Dla SSH utwórz odpowiednią politykę z grupą aplikacji SSH. Dzięki temu wyraźnie widać, jaki protokół i jaki warunek urządzenia obejmuje każde zezwolenie.

Sprawdź połączenie i oczekiwany wynik

Najpierw wykonaj test z jednym uprawnionym użytkownikiem i urządzeniem spełniającym wybrany warunek.

Przetestuj RDP

Uruchom Sophos Protected Browser i zaloguj się.
Na górze paska narzędzi kliknij ikonę Podłączanie pulpitu zdalnego, a następnie kliknij + New Host.
Nadaj nazwę wyświetlaną i wprowadź w polu Host ten sam wewnętrzny FQDN lub adres IP co w zasobie ZTNA. Port 3389 jest ustawiany automatycznie.
Wprowadź nazwę użytkownika i hasło systemu docelowego, a następnie kliknij Connect.

Test zakończy się pomyślnie, jeśli sesja zdalnego pulpitu zostanie otwarta w Protected Browser. Zwykły klient RDP nie jest prawidłowym testem krzyżowym, ponieważ zasoby RDP bez agenta są dostępne tylko za pośrednictwem Protected Browser.

Przetestuj SSH

Uruchom Protected Browser, zaloguj się i kliknij ikonę SSH na pasku narzędzi.
Wybierz + New Host, nadaj nazwę wyświetlaną i wprowadź wartość zasobu SSH w polu Host. Port 22 jest ustawiany automatycznie.
Wprowadź nazwę użytkownika i hasło systemu docelowego, a następnie kliknij Connect.

Test zakończy się pomyślnie, jeśli w przeglądarce otworzy się sesja SSH. Następnie wykonaj test negatywny z użytkownikiem spoza przypisanej grupy i potwierdź, że dostęp został odrzucony.

Kontroluj przesyłanie plików

Po nawiązaniu połączenia stosowane są różne elementy sterujące w zależności od protokołu:

RDP: Rozwiń górne menu i wybierz File Transfer > Upload do przesłania. Aby pobrać, użyj symbolu pobierania dla żądanego wpisu.
SSH: Otwórz element sterujący poniżej i wybierz File Transfer > Upload To Folder do przesłania. Aby pobrać, użyj symbolu pobierania.

Podczas pilotażu używaj wyłącznie nieszkodliwego pliku testowego bez poufnych danych. Pliki są skanowane i przesyłane do hosta tylko wtedy, gdy zostaną uznane za czyste. Wysłanie powiedzie się, gdy pojawi się komunikat File scanned successfully, a następnie potwierdzenie przesłania. Pobieranie sprawdź oddzielnie: kończy się powodzeniem, gdy wybrany plik w całości dotrze na urządzenie testowe i można go na nim otworzyć.

Rozwiązywanie problemów na podstawie objawu

Brak działania RDP/SSH lub ręcznie utworzony host nie łączy się

Sprawdź kolejno:

Czy wybrano + New Host przy użyciu symbolu RDP lub SSH i dokładnego wewnętrznego FQDN lub adresu IP powiązanego zasobu wpisanego w Host?
Czy użytkownik testowy jest członkiem grupy wybranej w Assign User Groups?
Czy w grupie aplikacji pod Assigned znajduje się właściwy zasób ZTNA?
Czy polityka internetowa zezwalająca na dostęp korzysta dokładnie z tej grupy aplikacji?
Czy urządzenie testowe spełnia opcjonalny warunek stanu urządzenia, w szczególności Windows, Sophos Endpoint i status kondycji Green?

Zmiany w grupie użytkowników ZTNA mogą zająć do godziny, zanim będą widoczne na bramce. Dlatego nie należy od razu tworzyć nowych obiektów w czasie oczekiwania na zmianę grupy.

Jeżeli ręcznie wprowadzony host jest poprawny, sprawdź dostępność hosta docelowego z perspektywy wybranej bramy. RDP korzysta ze stałego portu TCP 3389, a SSH ze stałego portu TCP 22; usługa działająca na innym porcie nie odpowiada tym typom zasobów.

Jeśli błąd będzie się powtarzał, diagnoza trafia do właściciela ZTNA. Czas ważności tokenów wsparcia jest konfigurowany w ustawieniach globalnych ZTNA. Token Sophos support for gateway instance dla instancji, której dotyczy problem, tworzy się w obszarze Gateway > Gateway Details. Token wsparcia jest wydawany tylko w konkretnym przypadku i z celowo krótkim czasem ważności.

Dostęp kończy się niepowodzeniem tylko przy aktywnym stanie urządzenia

Nie usuwaj bez kontroli warunku dotyczącego urządzenia z polityki produkcyjnej. Najpierw porównaj platformę, ochronę punktu końcowego i zgłoszony stan kondycji urządzenia pilotażowego z obiektem Grünes Windows. Do odizolowanego porównania można użyć oddzielnej pilotażowej polityki internetowej bez stanu urządzenia; grupa użytkowników musi pozostać ściśle ograniczona.

Plik nie został przesłany

Przesyłanie następuje dopiero po pomyślnym skanowaniu. Jeśli brakuje komunikatu File scanned successfully lub plik nie zostanie oceniony jako czysty, przesyłanie nie zostanie uznane za pomyślne. Zamiast pomijać skanowanie, użyj nieszkodliwego pliku testowego i eskaluj nieudane skanowanie podając czas, użytkownika, host docelowy i nazwę pliku.

Bezpieczne wycofywanie zmian i dostępu

Opublikowane informacje o produkcie nie dokumentują pełnego procesu usuwania wszystkich powiązanych obiektów Protected Browser. Dlatego brama, DNS, certyfikaty lub wspólne zasady nie są usuwane w ramach rzekomego wycofania.

Aby uzyskać natychmiastowe, odwracalne zatrzymanie dostępu, można otworzyć dedykowaną politykę ZTNA pod My Products > ZTNA > Policies. Na karcie Policy enforced należy wyłączyć wymuszanie tej dedykowanej polityki. W tym stanie użytkownicy nie mogą uzyskać dostępu do zasobów zarządzanych przez tę politykę.

Zanim to zrobisz, sprawdź, czy do tej polityki faktycznie przypisane są tylko zamierzone zasoby RDP lub SSH. Następnie potwierdź z użytkownikiem pilotażowym, że nie można już nawiązać połączenia. Aby przywrócić dostęp, ponownie ustaw tę samą dedykowaną politykę na Policy is enforced i powtórz test połączenia. Jeśli z polityki korzystają inne zasoby, przerwij procedurę przed zmianą i przekaż sprawę właścicielowi ZTNA.

Aby trwale wycofać z użytku, najpierw udokumentuj zasób, bramę, politykę, grupy użytkowników, grupę aplikacji i politykę internetową. Następnie odpowiedni właściciel usuwa przypisania i obiekty w kolejności zależności. Bez zatwierdzonej procedury usuwania właściwej dla produktu bezpieczna granica przebiega przed usunięciem współdzielonych obiektów ZTNA, DNS lub certyfikatów.

Działanie i cykl życia

Przynajmniej za każdym razem, gdy następuje zmiana w grupach użytkowników, bramach, wewnętrznych nazwach hostów lub stanie urządzenia, powtarzany jest test pozytywny i negatywny. Ponadto właściciel powinien regularnie sprawdzać:

czy hosty RDP i SSH są osiągalne z perspektywy bramy;
czy przydzielono tylko wymagane grupy;
czy zasoby, grupy aplikacji i zasady internetowe nadal wyraźnie do siebie pasują;
czy domeny i certyfikaty są ważne i przypisane do właściwej bramy;
czy globalny minimalny czas dla reguł kondycji urządzenia odpowiada pożądanemu zachowaniu;
czy wygenerowany token wsparcia wygasł i nie istnieje dłużej niż to konieczne.

Bezagentowe zasoby RDP i SSH pozostają osobną ścieżką dostępu. Dlatego zmiany w limitach czasu tunelu agenta lub wdrażaniu opartym na agencie nie zastępują nowego sprawdzenia w Protected Browser. Niniejszy przewodnik nie określa również dat przejścia, wycofania ani zakończenia eksploatacji. Po zmianie produktu właściciel powinien sprawdzić ustawienia widoczne w dzierżawie i ponownie przeprowadzić proces pilotażowy.