Agentlös RDP- och SSH-åtkomst med Sophos Protected Browser

Sophos Protected Browser ger åtkomst till interna RDP- och SSH-värdar utan ZTNA-agent på användarens enhet. Sophos listar dessa två användningsfall under Access RDP agentlessly via Protected Browser och Access SSH agentlessly via Protected Browser. Åtkomsten är begränsad till Protected Browser: en anslutning som skapats som en agentlös RDP- eller SSH-resurs kan inte öppnas med en vanlig RDP- eller SSH-klient.

Det säkra arbetsflödet är detsamma för båda protokollen: konfigurera först identitet, gateway och anslutning. Skapa sedan en agentlös ZTNA-policy och en separat resurs för varje värd. Lägg till resursen i en applikationsgrupp i Protected Browser och tillåt den via en internetpolicy. Testa därefter med en liten användargrupp.

Krav, licens och roller

Följande punkter måste uppfyllas innan konfigurering:

Protected Browser är installerad på en Windows- eller macOS-enhet som stöds. I exemplet nedan används en Windows-enhet med grön hälsostatus.
Användare och grupper synkroniseras, en identitetsleverantör konfigureras och en ZTNA-gateway är i drift.
Gatewayen kan nå den interna RDP- eller SSH-värden. Denna anslutning kontrolleras innan resursen skapas.
Minsta möjliga användargrupp finns för resursen. Ett delat objekt för alla anställda är olämpligt för administrativ åtkomst.
Den som utför proceduren kan hantera policyer och resurser under My Products > ZTNA samt policyobjekt och internetpolicyer under My Products > Protected Browser.

Den produktinformation som godkänts för processen anger inte något särskilt rollnamn eller separat licens-SKU. Utgå därför inte från att en synlig meny innebär behörighet och tilldela inte generella superadministratörsrättigheter. Kontrollera före ändringen att ZTNA och Protected Browser är tillgängliga i organisationens klientorganisation och att administratörskontot får skapa objekten. Om en sida eller knapp saknas ska den som ansvarar för licenser eller roller utreda detta innan arbetet fortsätter.

Local Gateway och Sophos Cloud Gateway är möjliga ZTNA-distributionslägen. Distributionen av dem samt användar- och identitetssynkronisering, domäner, certifikat och DNS ingår i den gemensamma ZTNA-grunden. Den korrekta ordningen förklaras i Inställning av Sophos ZTNA. Denna guide upprepar avsiktligt inte dessa vanliga procedurer.

Kontrollera DNS och certifikat i förväg

Gatewaydomänen, certifikatet och den obligatoriska offentliga och interna DNS-upplösningen måste redan fungera. ZTNA-ägaren konfigurerar denna gemensamma grund enligt den länkade ZTNA-guiden; den varken upprepas eller ändras här.

RDP- och SSH-resurserna som beskrivs här använder ett särskilt formulär: ange adressen i Internal FQDN/IP address of the resource; External FQDN kan inte läggas till. Därför får allmänna DNS-exempel för ZTNA-webbapplikationer inte kopieras till detta fält. Domäner och certifikat förbereds av ZTNA-ägaren innan RDP- eller SSH-resursen skapas.

Förbered exempelvärden

Följande namn gör det lätt att känna igen relaterade objekt. De är inte en produktspecifikation och ska anpassas till organisationens namnstandard:

ZTNA-policy: Agentenloser Zugriff
RDP-resurs: Agentenloses RDP
SSH-resurs: Agentenloses SSH
Enhetsstatus: Grünes Windows
Applikationsgrupp: Agentenlose RDP-Gruppe eller Agentenlose SSH-Gruppe
Internetpolicy: Agentenloser RDP-Zugriff von Windows-Systemen mit grüner Integrität eller SSH-varianten
Intern värd: till exempel rdp01.intern.example eller ssh01.intern.example

Ett FQDN är enklare att hantera än en IP-adress som ändras, men det måste kunna slås upp korrekt från gatewayen. Skapa separata resurser och applikationsgrupper om båda protokollen ska testas. Då går tilldelningar, validering och senare avveckling att följa upp.

Lägg till agentfri ZTNA-policy

En befintlig agentlös policy kan återanvändas om den har rätt avgränsning. En särskild pilotpolicy minskar dock risken för att produktionsresurser påverkas av misstag.

Öppna My Products > ZTNA > Policies.
Klicka på Add policy.
Välj Agentless under Add policy. Andra ZTNA-vyer beskriver också detta som åtkomst utan agent. En uppmaning att begära en agent gäller den agentbaserade vägen; den här policyn kräver ingen agent.
Ange ett namn under New policy, till exempel Agentenloser Zugriff.
Öppna Policy enforced och aktivera Policy is enforced.
Klicka på Save.

ZTNA-policytypen Agent och dess tunnlar ingår inte i detta flöde. Den globala tidsgränsen för inaktivitet i agenttunneln gäller också för agenttunneln och är inte en RDP- eller SSH-sessionstimer för Protected Browser. ZTNA-ägaren bör fortfarande känna till den globala minimitiden innan enhetshälsan utlöser en regel om enhetsintegritet används i den övergripande miljön.

Lägg till RDP- eller SSH-resurs

Öppna My Products > ZTNA > Resources & Access och klicka på Add Resource. Fyll i formuläret enligt det valda protokollet.

RDP-resurs

Ange till exempel Agentenloses RDP som Resource name. En beskrivning är valfri.
Välj den gateway som kan nå rdp01.intern.example.
Välj under Access method värdet Agentless.
Välj policyn Agentenloser Zugriff.
För Resource type, välj RDP. Port 3389 och accessporttyp TCP ställs in automatiskt och kan inte ändras i detta formulär.
Ange den interna värden under Internal FQDN/IP address of the resource. En extern FQDN kan inte läggas till för den här resurstypen.
Flytta under Assign User Groups endast den avsedda pilotgruppen från de tillgängliga grupperna till Assigned User Groups.
Klicka på Save.

SSH-resurs

Använd samma arbetsflöde för SSH, men med följande protokollspecifika värden:

Resource name: till exempel Agentenloses SSH.
Access method: Agentless.
Policy: Agentenloser Zugriff.
Resource type: SSH. Port 22 och accessporttyp TCP ställs in automatiskt och kan inte ändras.
Internal FQDN/IP address of the resource: till exempel ssh01.intern.example; en extern FQDN är inte tillgänglig.
Assign User Groups: flytta endast den avsedda pilotgruppen till Assigned User Groups och klicka sedan på Save.

Agentbaserade resurser och webbappar har andra funktioner. Agenten kan exempelvis ta hänsyn till enhetens hälsa i ZTNA-åtkomstpolicyn och styra lokala appar. I den här proceduren förblir resursen Agentless. Konfigurera vid behov den extra enhetskontrollen i internetpolicyn för Protected Browser.

Begränsa åtkomsten till Protected Browser

Skapa valfri enhetsstatus

Att lägga till en enhetsstatus är valfritt. Utan detta objekt bör pilotgruppen vara särskilt begränsad. För det dokumenterade exemplet med hanterade Windows-enheter:

Öppna My Products > Protected Browser > Policy objects.
Klicka på Add object > Device posture.
Ange Grünes Windows som namn.
Välj under OS platform värdet Windows.
Välj under Endpoint Protection alternativet Check if device is protected by Sophos Endpoint och därefter integritetsstatusen Green.
Klicka på Save.

Ytterligare kontroller ökar säkerheten, men kan också utesluta fler enheter. Varje ytterligare villkor testas därför först med pilotgruppen.

Skapa applikationsgrupp

Stanna kvar under My Products > Protected Browser > Policy objects.
Klicka på Add object > Application group.
Ange ett unikt namn, till exempel Agentenlose RDP-Gruppe.
Expandera ZTNA resources.
Välj den tidigare skapade resursen under Available och flytta den till Assigned.
Klicka på Save.

För SSH, skapa Agentenlose SSH-Gruppe och tilldela Agentenloses SSH. De separata grupperna förhindrar att en senare ändring av SSH-åtkomsten obemärkt ändrar RDP-åtkomsten.

Lägg till internetpolicy

Öppna My Products > Protected Browser > Web policy och välj fliken Policies.
Klicka på Add policy.
Ange ett unikt namn, till exempel Agentenloser RDP-Zugriff von Windows-Systemen mit grüner Integrität.
Se till att Allow är vald.
Om den används, välj enhetsstatus Grünes Windows.
Välj applikationsgruppen Agentenlose RDP-Gruppe.
Klicka på Save.

För SSH, skapa motsvarande policy med SSH-applikationsgruppen. På så sätt framgår det tydligt vilket protokoll och enhetsvillkor varje åtkomsttilldelning omfattar.

Kontrollera anslutning och förväntat resultat

Börja med att testa en enda behörig användare och en enhet som uppfyller det valda enhetsvillkoret.

Testa RDP

Starta Sophos Protected Browser och logga in.
Klicka högst upp i verktygsfältet på ikonen för anslutning till fjärrskrivbord och sedan på + New Host.
Ange ett visningsnamn och skriv in samma interna FQDN eller IP-adress som i ZTNA-resursen under Host. Port 3389 ställs in automatiskt.
Ange användarnamnet och lösenordet för målsystemet och klicka på Connect.

Testet lyckas om fjärrskrivbordssessionen öppnas i Protected Browser. En normal RDP-klient är inte en giltig korskontroll eftersom agentlösa RDP-resurser endast är tillgängliga via Protected Browser.

Testa SSH

Starta Protected Browser, logga in och klicka på SSH-ikonen i verktygsfältet.
Välj + New Host, ange ett visningsnamn och skriv in SSH-resursens värde under Host. Port 22 ställs in automatiskt.
Ange användarnamnet och lösenordet för målsystemet och klicka på Connect.

Testet lyckas om SSH-sessionen öppnas i webbläsaren. Utför sedan ett negativt test med en användare utanför den tilldelade gruppen och kontrollera att åtkomst nekas.

Kontrollera filöverföring

När anslutningen har upprättats används olika kontroller beroende på protokollet:

RDP: Expandera toppmenyn och välj File Transfer > Upload för uppladdningen. För att ladda ner, använd nedladdningssymbolen för önskad post.
SSH: Öppna reglaget längst ned och välj File Transfer > Upload To Folder för att ladda upp filen. Använd nedladdningssymbolen för att ladda ner.

Använd endast en ofarlig testfil utan konfidentiella uppgifter under piloten. Filerna skannas och överförs till värden endast om de är rena. Uppladdningen har lyckats när File scanned successfully visas och därefter en bekräftelse på uppladdningen. Kontrollera nedladdningen separat: den har lyckats när hela den valda filen har överförts till testenheten och kan öppnas där.

Felsökning efter symptom

RDP/SSH-åtgärd saknas eller en manuellt skapad värd ansluter inte

Kontrollera i följande ordning:

Valdes + New Host med RDP- eller SSH-symbolen och den exakta interna FQDN eller IP-adressen för den associerade resursen som angavs under Host?
Är testanvändaren medlem i gruppen som valts under Assign User Groups?
Är rätt ZTNA-resurs i applikationsgruppen under Assigned?
Använder internetpolicyn som tillåter åtkomst exakt denna applikationsgrupp?
Uppfyller testenheten den valfria enhetsstatusen, särskilt Windows, Sophos Endpoint och hälsostatus Green?

Det kan ta upp till en timme innan ändringar av en ZTNA-användargrupp syns på gatewayen. Skapa därför inte nya objekt direkt medan gruppändringen behandlas.

Om den manuellt angivna värden är korrekt, kontrollera att den valda gatewayen kan nå målvärden. RDP använder den fasta TCP-porten 3389 och SSH den fasta TCP-porten 22; en tjänst på en annan port motsvarar inte dessa resurstyper.

Om felet kvarstår lämnas felsökningen över till ZTNA-ägaren. Giltighetstiden för supporttoken konfigureras i ZTNA:s globala inställningar. Supporttoken för gatewayinstansen skapas i den berörda instansens gatewayinställningar. Dela endast en supporttoken för ett specifikt ärende och ge den en avsiktligt kort giltighetstid.

Åtkomsten misslyckas endast med aktiverad enhetsstatus

Ta inte bort enhetsvillkoret från en produktionspolicy utan kontroll. Jämför först pilotenhetens plattform, slutpunktsskydd och rapporterade hälsostatus med objektet Grünes Windows. För en isolerad jämförelse kan en separat internetpolicy för piloten användas utan enhetsstatus; håll fortfarande användargruppen strikt begränsad.

Filen laddas inte upp

En uppladdning sker först efter en lyckad skanning. Om meddelandet File scanned successfully saknas eller om filen inte klassificeras som ren, anses uppladdningen inte lyckas. Istället för att kringgå skanningen, använd en ofarlig testfil och eskalera den misslyckade genomsökningen med tid, användare, målvärd och filnamn.

Säker återställning och avveckling

Den godkända produktinformationen beskriver inte en fullständig raderingsprocess för alla berörda Protected Browser-objekt. Ta därför inte bort gateway, DNS, certifikat eller delade policyer som en påstådd återställning.

Öppna en dedikerad ZTNA-policy under My Products > ZTNA > Policies för ett omedelbart och reversibelt åtkomststopp. Gå till fliken Policy enforced och förbikoppla den dedikerade policyn. I det här tillståndet kan användarna inte komma åt resurserna som hanteras av policyn.

Kontrollera först att endast de avsedda RDP- eller SSH-resurserna är tilldelade policyn. Bekräfta därefter med pilotanvändaren att anslutningen inte längre kan upprättas. Återställ åtkomsten genom att ställa tillbaka samma dedikerade policy till Policy is enforced och upprepa anslutningstestet. Om andra resurser använder policyn, avbryt före ändringen och lämna över ärendet till ZTNA-ägaren.

För att permanent avveckla, dokumentera först resursen, gatewayen, policyn, användargrupperna, applikationsgruppen och internetpolicyn. Respektive ägare tar sedan bort tilldelningarna och objekten i beroendeordning. Utan ett godkänt produktspecifikt borttagningsflöde går säkerhetsgränsen före borttagning av delade ZTNA-, DNS- eller certifikatobjekt.

Drift och livscykel

Åtminstone varje gång det sker en ändring av användargrupper, gateways, interna värdnamn eller enhetsvillkor, upprepas ett positivt och negativt test. Dessutom bör ägaren regelbundet kontrollera:

om RDP- och SSH-värdarna är tillgängliga från gatewayens perspektiv;
om endast de grupper som behövs är tilldelade;
om resurser, applikationsgrupper och internetpolicyer fortfarande tydligt hör ihop;
om domäner och certifikat är giltiga och tilldelade rätt gateway;
om den globala minimitiden för enhetshälsoregler matchar det önskade beteendet;
om en genererad supporttoken har gått ut och inte existerar längre än nödvändigt.

Agentlösa RDP- och SSH-resurser förblir en separat åtkomstväg. Ändringar av tidsgränser för agenttunneln eller agentbaserad utrullning ersätter därför inte en ny kontroll i Protected Browser. Den här vägledningen anger inte heller några datum för övergång, avveckling eller livscykelns slut. Efter en produktändring ska ägaren kontrollera inställningarna som visas i klientorganisationen och köra pilotprocessen igen.