Vai al contenuto
Avanet

Accesso RDP e SSH senza agente con Sophos Protected Browser

Sophos Workspace Protection

Sophos Protected Browser consente di accedere a host RDP e SSH interni senza un agente ZTNA sul dispositivo dell’utente. Sophos elenca questi due casi d’uso sotto Agentenlose RDP-Anwendungen e Agentenlose SSH-Anwendungen. L’accesso rimane limitato a Protected Browser: una connessione creata come risorsa RDP o SSH senza agente non può essere aperta con un normale client RDP o SSH.

La procedura sicura è identica per entrambi i protocolli: prima si predispongono identità, gateway e connettività, quindi si creano una policy ZTNA senza agente e una risorsa per ciascun host. In Protected Browser, la risorsa viene aggiunta a un gruppo di applicazioni e autorizzata mediante una policy Internet. Solo a questo punto si eseguono i test con un gruppo ristretto di utenti.

Requisiti, licenza e ruoli

Prima della configurazione è necessario soddisfare i seguenti punti:

  • Protected Browser è installato su un dispositivo Windows o macOS supportato. L’esempio seguente utilizza un dispositivo Windows con stato di integrità verde.
  • Utenti e gruppi vengono sincronizzati, viene configurato un provider di identità e un gateway ZTNA è operativo.
  • Il gateway può raggiungere l’host RDP o SSH interno. Questa connessione viene controllata prima della creazione della risorsa.
  • Per la risorsa esiste il gruppo utenti più piccolo possibile. Un oggetto condiviso per tutti i dipendenti non è adatto per l’accesso amministrativo.
  • La persona che esegue la procedura può gestire policy e risorse in Meine Produkte > ZTNA, nonché oggetti policy e policy Internet in Meine Produkte > Protected Browser.

Le informazioni sul prodotto rilasciate per questo processo non specificano un nome di ruolo specifico o uno SKU di licenza separato. Non si deve quindi dedurre l’autorizzazione dalla sola presenza di un menu, né concedere privilegi generici di super amministratore. Prima di apportare la modifica verificare nel proprio tenant se ZTNA e Protected Browser sono disponibili e se l’account amministratore utilizzato è autorizzato a creare gli oggetti menzionati. Se manca una pagina o un pulsante, chiedere alla persona responsabile di verificare la licenza e i ruoli nel tenant prima di continuare a lavorare.

Gateway locale e Sophos Cloud Gateway sono possibili modalità di distribuzione ZTNA. Il loro provisioning, sincronizzazione di utenti e identità, domini, certificati e DNS fanno parte della base comune ZTNA. Viene spiegato l’ordine corretto Configurazione di Sophos ZTNA. Questa guida non ripete intenzionalmente queste procedure comuni.

Verificare prima DNS e certificati

Il dominio del gateway, il certificato e la risoluzione DNS pubblica e interna richiesta devono essere già funzionanti. Il responsabile ZTNA configura questa base comune attenendosi alla guida ZTNA collegata; in questa sede non viene né duplicata né modificata.

Le risorse RDP e SSH qui descritte usano invece un modulo specifico: inserire l’indirizzo in Interner FQDN/IP-Adresse der Ressource; non è possibile aggiungere Externen FQDN. Non copiare quindi in questo campo gli esempi DNS generali per le applicazioni web ZTNA. Il responsabile ZTNA prepara domini e certificati prima della creazione della risorsa RDP o SSH.

Preparare valori di esempio

I nomi seguenti consentono di riconoscere gli oggetti correlati. Non costituiscono una specifica del prodotto e devono essere adattati alla convenzione di denominazione adottata:

  • Politica ZTNA: Agentenloser Zugriff
  • Risorsa RDP: Agentenloses RDP
  • Risorsa SSH: Agentenloses SSH
  • Stato del dispositivo: Grünes Windows
  • Gruppo di applicazioni: Agentenlose RDP-Gruppe o Agentenlose SSH-Gruppe
  • Politica Internet: Agentenloser RDP-Zugriff von Windows-Systemen mit grüner Integrität o variante SSH
  • Host interno: ad esempio rdp01.intern.example o ssh01.intern.example

Un FQDN è più facile da gestire rispetto a un indirizzo IP variabile, ma deve essere risolto correttamente dal gateway. Se si testano entrambi i protocolli, creare risorse e gruppi di applicazioni separati, in modo da mantenere tracciabili le assegnazioni, la convalida e la successiva dismissione.

Aggiungere una policy ZTNA senza agente

È possibile riutilizzare una policy senza agente esistente, purché abbia un ambito adeguato. Una policy pilota dedicata riduce tuttavia il rischio di influire involontariamente sulle risorse di produzione.

  1. Aprire Meine Produkte > ZTNA > Richtlinien.
  2. Fare clic su Richtlinie hinzufügen.
  3. In Richtlinie hinzufügen, selezionare il tipo Agentenlos. In altre viste ZTNA questo tipo è indicato come Ohne Agent. Il messaggio Agent anfordern riguarda il percorso basato sull’agente; questa policy non richiede un agente.
  4. In Neue Richtlinie, inserire un nome, ad esempio Agentenloser Zugriff.
  5. Aprire Richtlinie durchgesetzt e attivare Richtlinie wird durchgesetzt.
  6. Fare clic su Speichern.

La policy ZTNA di tipo Agent e i relativi tunnel non fanno parte di questo flusso. Anche lo Zeitüberschreitung wegen Inaktivität des Agent-Tunnels globale si applica al tunnel dell’agente e non è un timer di sessione RDP o SSH per Protected Browser. Il proprietario della ZTNA dovrebbe comunque conoscere lo Mindestzeit, bevor die Geräte-Integrität eine Regel auslöst globale se l’integrità del dispositivo viene utilizzata nell’ambiente generale.

Aggiungere una risorsa RDP o SSH

Aprire Meine Produkte > ZTNA > Ressourcen und Zugriff e fare clic su Ressource hinzufügen. Compilare il modulo in base al protocollo scelto.

Risorsa RDP

  1. Inserire, ad esempio, Agentenloses RDP come Ressourcenname. La descrizione è facoltativa.
  2. Scegliere il gateway in grado di raggiungere rdp01.intern.example.
  3. Sotto Zugriffsmethode selezionare il valore Agentenlos.
  4. Scegliere la policy Agentenloser Zugriff.
  5. Per Ressourcentyp, selezionare RDP. La porta 3389 e il tipo di porta di accesso TCP vengono impostati automaticamente e non possono essere modificati in questo modulo.
  6. In Interner FQDN/IP-Adresse der Ressource, inserire l’host interno. Non è possibile aggiungere un FQDN esterno per questo tipo di risorsa.
  7. In Benutzergruppen zuweisen, spostare solo il gruppo pilota necessario da Verfügbar a Zugewiesen.
  8. Fare clic su Speichern.

Risorsa SSH

Per SSH utilizzare lo stesso flusso con questi valori specifici del protocollo:

  1. Ressourcenname: ad esempio Agentenloses SSH.
  2. Zugriffsmethode: Agentenlos.
  3. Richtlinie: Agentenloser Zugriff.
  4. Ressourcentyp: SSH. La porta 22 e il tipo di porta di accesso TCP vengono impostati automaticamente e non possono essere modificati.
  5. Interner FQDN/IP-Adresse der Ressource: ad esempio ssh01.intern.example; uno FQDN esterno non è disponibile.
  6. Benutzergruppen zuweisen: spostare solo il gruppo pilota previsto in Zugewiesen, quindi fare clic su Speichern.

Le risorse basate su agente e le app Web offrono funzionalità diverse. Ad esempio, l’agente può valutare l’integrità del dispositivo nella policy di accesso ZTNA e controllare le app locali. In questa procedura la risorsa resta Ohne Agent; se necessario, l’ulteriore controllo del dispositivo viene configurato nella policy Internet di Protected Browser.

Limitare l’accesso a Protected Browser

Creare uno stato del dispositivo facoltativo

L’aggiunta dello stato del dispositivo è facoltativa. Senza questo oggetto, il gruppo pilota deve essere particolarmente ristretto. Per l’esempio documentato con dispositivi Windows gestiti:

  1. Aprire Meine Produkte > Protected Browser > Richtlinienobjekte.
  2. Fare clic su Objekt hinzufügen > Gerätestatus.
  3. Inserire Grünes Windows come nome.
  4. Sotto OS-Plattform selezionare il valore Windows.
  5. Sotto Endpoint Protection selezionare l’opzione Prüfen, ob Gerät durch Sophos Endpoint geschützt ist e poi lo stato di integrità Grün.
  6. Fare clic su Speichern.

Controlli aggiuntivi aumentano la sicurezza, ma possono anche escludere più dispositivi. Ogni condizione aggiuntiva viene quindi prima testata con il gruppo pilota.

Creare un gruppo di applicazioni

  1. Rimanere in Meine Produkte > Protected Browser > Richtlinienobjekte.
  2. Fare clic su Objekt hinzufügen > Anwendungsgruppe.
  3. Inserire un nome univoco, ad esempio Agentenlose RDP-Gruppe.
  4. Espandere ZTNA-Ressourcen.
  5. In Verfügbar, selezionare la risorsa creata in precedenza e spostarla in Zugewiesen.
  6. Fare clic su Speichern.

Per SSH, creare Agentenlose SSH-Gruppe e assegnare Agentenloses SSH. I gruppi separati evitano che una successiva modifica dell’accesso SSH alteri inavvertitamente l’accesso RDP.

Aggiungere la policy Internet

  1. Aprire Meine Produkte > Protected Browser > Internetrichtlinie e selezionare la scheda Richtlinien.
  2. Fare clic su Richtlinie hinzufügen.
  3. Inserire un nome univoco, ad esempio Agentenloser RDP-Zugriff von Windows-Systemen mit grüner Integrität.
  4. Assicurarsi che Zulassen sia selezionato.
  5. Se utilizzato, selezionare lo stato del dispositivo Grünes Windows.
  6. Selezionare il gruppo di applicazioni Agentenlose RDP-Gruppe.
  7. Fare clic su Speichern.

Per SSH, creare la policy corrispondente con il gruppo di applicazioni SSH. In questo modo resta chiaro quale protocollo e quale condizione del dispositivo comprende ogni autorizzazione.

Controllare la connessione e il risultato previsto

Iniziare il test con un solo utente autorizzato e un dispositivo che soddisfi la condizione selezionata.

Prova RDP

  1. Avviare Sophos Protected Browser ed eseguire l’accesso.
  2. Nella parte superiore della barra degli strumenti, fare clic sull’icona Connessione desktop remoto e quindi fare clic su + Neuer Host.
  3. Assegnare un nome visualizzato e inserire lo stesso FQDN interno o lo stesso indirizzo IP della risorsa ZTNA in Host. La porta 3389 viene impostata automaticamente.
  4. Immettere il nome utente e la password del sistema di destinazione e fare clic su Verbinden.

Il test ha esito positivo se la sessione di desktop remoto viene aperta nello Protected Browser. Un normale client RDP non è un controllo incrociato valido perché le risorse RDP senza agente sono accessibili solo tramite Protected Browser.

Prova SSH

  1. Avviare Protected Browser, eseguire l’accesso e fare clic su SSH-Symbol nella barra degli strumenti.
  2. Selezionare + Neuer Host, assegnare un nome visualizzato e inserire il valore della risorsa SSH in Host. La porta 22 viene impostata automaticamente.
  3. Immettere il nome utente e la password del sistema di destinazione e fare clic su Verbinden.

Il test ha esito positivo se la sessione SSH si apre nel browser. Eseguire quindi un test negativo con un utente esterno al gruppo assegnato e verificare che l’accesso venga negato.

Controllare il trasferimento dei file

Una volta stabilita la connessione, vengono utilizzati controlli diversi a seconda del protocollo:

  • RDP: Espandere il menu superiore e selezionare Dateiübertragung > Hochladen per il caricamento. Per scaricare il file, usare il simbolo di download della voce desiderata.
  • SSH: Aprire il controllo nella parte inferiore e selezionare Dateiübertragung > In Ordner hochladen per caricare il file. Utilizzare il simbolo di download per scaricare.

Per l’operazione pilota si esegue il test solo con un file di test innocuo senza dati riservati. I file caricati vengono scansionati e caricati solo se sono puliti. Il caricamento ha esito positivo quando viene visualizzato Datei erfolgreich gescannt e quindi il messaggio di caricamento. Il download viene controllato separatamente: ha esito positivo se il file selezionato arriva completamente sul dispositivo di prova e lì può essere aperto.

Risoluzione dei problemi in base ai sintomi

L’azione RDP/SSH manca oppure un host creato manualmente non si connette

Controllare nell’ordine seguente:

  1. + Neuer Host è stato selezionato utilizzando il simbolo RDP o SSH e l’esatto FQDN interno o l’indirizzo IP della risorsa associata inserito in Host?
  2. L’utente del test è un membro del gruppo selezionato in Benutzergruppen zuweisen?
  3. La risorsa ZTNA corretta è nel gruppo di applicazioni in Zugewiesen?
  4. La policy Internet che consente l’accesso usa esattamente questo gruppo di applicazioni?
  5. Il dispositivo di prova soddisfa lo stato del dispositivo opzionale, in particolare Windows, Sophos Endpoint Protection e stato di integrità Grün?

Le modifiche a un gruppo utenti ZTNA possono richiedere fino a un’ora per essere visibili sul gateway. Pertanto non si dovrebbero creare immediatamente nuovi oggetti mentre è in sospeso la modifica del gruppo.

Se l’host inserito manualmente è corretto, verificare che il gateway selezionato possa raggiungere l’host di destinazione. RDP usa la porta TCP fissa 3389 e SSH la porta TCP fissa 22; un servizio su una porta diversa non corrisponde a questi tipi di risorse.

Se l’errore persiste la diagnosi va al titolare della ZTNA. Il tempo di scadenza dei token di supporto è configurato nelle impostazioni globali di ZTNA. Il token Sophos-Support für Gateway-Instanz viene creato per l’istanza interessata in Gateway > Gateway-Einstellungen. Un token di supporto viene rilasciato solo per un caso specifico e con un tempo di scadenza volutamente breve.

L’accesso fallisce solo con lo stato del dispositivo attivato

Non rimuovere senza controllo la condizione del dispositivo da una policy di produzione. Confrontare prima la piattaforma, la protezione dell’endpoint e lo stato di integrità segnalato del dispositivo pilota con l’oggetto Grünes Windows. Per un confronto isolato, è possibile utilizzare una policy Internet pilota separata senza stato del dispositivo; il gruppo di utenti deve restare strettamente limitato.

Il file non è stato caricato

Un caricamento avviene solo dopo una scansione riuscita. Se manca il messaggio Datei erfolgreich gescannt o il file non è classificato come pulito, il caricamento non viene considerato riuscito. Non aggirare la scansione: usare un file di test innocuo e segnalare l’esito negativo indicando ora, utente, host di destinazione e nome del file.

Ripristino sicuro e dismissione

Le informazioni sul prodotto rilasciate non documentano un processo di cancellazione completo per tutti gli oggetti browser protetti coinvolti. Pertanto, gateway, DNS, certificati o policy condivise non vengono eliminati come presunto rollback.

Per un arresto dell’accesso immediato e reversibile, è possibile aprire una policy ZTNA dedicata in Meine Produkte > ZTNA > Richtlinien. Nella scheda Richtlinie durchgesetzt, impostarla su Richtlinie umgangen. In questo stato, gli utenti non possono accedere alle risorse gestite da questa policy.

Prima di procedere, controllare che alla policy siano assegnate soltanto le risorse RDP o SSH previste. Verificare quindi con l’utente pilota che non sia più possibile stabilire la connessione. Per ripristinare l’accesso, riportare la stessa policy dedicata su Richtlinie wird durchgesetzt e ripetere il test di connessione. Se la policy è utilizzata da altre risorse, interrompere la procedura prima della modifica e passare il caso al responsabile ZTNA.

Per rimuovere definitivamente le autorizzazioni, documentare innanzitutto la risorsa, il gateway, la policy, i gruppi di utenti, il gruppo di applicazioni e la policy Internet. Il rispettivo proprietario rimuove quindi le assegnazioni e gli oggetti in ordine di dipendenza. Senza un flusso di eliminazione condiviso e specifico del prodotto, viene raggiunto il limite di sicurezza prima che gli oggetti ZTNA, DNS o certificato condivisi vengano eliminati.

Funzionamento e ciclo di vita

Dopo ogni modifica ai gruppi di utenti, ai gateway, ai nomi host interni o alle condizioni del dispositivo, ripetere almeno un test positivo e uno negativo. Il responsabile deve inoltre controllare regolarmente:

  • se gli host RDP e SSH sono raggiungibili dal punto di vista del gateway;
  • se vengono assegnati solo i gruppi richiesti;
  • se le risorse, i gruppi di applicazioni e le politiche Internet siano ancora chiaramente collegati tra loro;
  • se domini e certificati sono validi e assegnati al gateway corretto;
  • se il tempo minimo globale per le regole di integrità del dispositivo corrisponde al comportamento desiderato;
  • se un token di supporto generato è scaduto e non esiste più del necessario.

Le risorse RDP e SSH senza agente rimangono un percorso di accesso separato. Le modifiche ai timeout del tunnel dell’agente o alla distribuzione basata sull’agente non sostituiscono quindi una nuova verifica in Protected Browser. Queste indicazioni non definiscono date di transizione, disattivazione o fine vita. Dopo una modifica del prodotto, il responsabile deve controllare le impostazioni visibili nel tenant e ripetere il processo pilota.