Inoltro SSH, VPN o RD Gateway: quale percorso per un desktop RDP?

Tutte e tre le opzioni trasportano RDP, quindi il protocollo non è il fattore decisivo. La vera domanda è quanta accessibilità debba ottenere un utente e chi gestisce ciò che la concede. Una porta TCP inoltrata, una rete privata instradata e un gateway desktop rispondono a questa domanda in tre dimensioni diverse. Scegli prima la dimensione e il prodotto seguirà.

La domanda è la portata, non il protocollo

Annota cosa l’utente deve davvero toccare. Se la risposta è un solo desktop, un progetto che concede una sottorete è troppo ampio. Se la risposta è un desktop più condivisioni file più una console di amministrazione, un progetto che inoltra una porta tornerà il mese prossimo per altri due inoltri. L’elenco delle destinazioni è il requisito; tutto il resto è implementazione.

Tieni l’identità di ingresso separata dall’account Windows che accede al desktop. Ogni progetto sotto ha entrambi, e confonderli è il modo in cui un account host di salto finisce con più autorità di quanto chiunque intendesse.

Un servizio TCP inoltrato

Un host di salto SSH approvato può inoltrare un listener locale al servizio RDP che riesce a raggiungere. Associa quel listener a loopback quando esiste solo per la macchina dell’utente, che è l’intento normale di un inoltro locale. L’inoltro è una comodità per una persona, non un servizio per un team.

L’accesso SSH autentica l’accesso al percorso di inoltro, e nulla di più. L’autenticazione Windows e l’autorizzazione RDP avvengono ancora alla destinazione, quindi un account di salto valido non è una sessione desktop valida. Sono due porte indipendenti ed entrambe devono aprirsi.

Limita le destinazioni di inoltro dell’account di salto invece di concedere una shell senza restrizioni. Questo progetto si adatta a un insieme piccolo ed esplicitamente elencato di macchine, e aggiunge un host, un’identità e un ciclo di vita da gestire. Quell’host in più è la parte che le persone dimenticano quando lo confrontano con un gateway: qualcuno deve applicargli le patch, monitorarlo e possederne le chiavi.

Uno spazio di lavoro privato instradato

Una VPN fornisce DNS privato e accesso a più servizi usati insieme, e questo è il suo valore reale. Nascondere una porta desktop è un effetto collaterale, non il motivo per costruirla. Questa distinzione conta quando qualcuno chiede perché la VPN esista.

Limita le rotte e le autorizzazioni alle risorse alle destinazioni previste. Un utente connesso non merita automaticamente tutta la LAN, e il firewall di destinazione più i diritti di accesso Windows restano confini separati che la VPN non sostituisce.

Questa disposizione è comoda per uno spazio di lavoro gestito già consolidato. Il costo è che l’onboarding, i requisiti dei dispositivi, il comportamento del resolver e la politica di connessione diventano parte dell’ambiente di lavoro dell’utente, e qualcuno deve possederli. Confronta quel costo con le licenze del gateway prima di presumere che la VPN sia l’opzione più economica.

Un gateway specifico per RDP

Remote Desktop Gateway fornisce un confine specifico per RDP anziché uno di rete. La sua politica di autorizzazione delle connessioni decide chi può connettersi, e la sua politica di autorizzazione delle risorse decide quali risorse interne possono raggiungere tramite esso. Entrambe le politiche fanno parte del prodotto, non sono extra opzionali.

Pianifica insieme certificati, integrazione delle identità e trasporti richiesti. Il gateway non è un relè TCP anonimo, e distribuirlo come tale salta le politiche che lo giustificano. Comporta anche requisiti di licenza e operativi che una singola porta inoltrata non ha. Mettili a budget prima della revisione del progetto, non dopo.

Dove un team gestisce già un accesso desktop centralizzato, quel costo è già pagato. Dove una persona ha bisogno di una macchina, è una macchina grande comprata per un lavoro piccolo.

Ciò che tutti e tre richiedono ancora

Conserva i controlli di identità dell’host in ogni progetto. Un alias locale o un tunnel non rendono innocuo un certificato inatteso, e accettare un certificato non corrispondente per passare da un proxy annulla lo scopo del tunnel. Il nome nel client e il nome sul certificato devono essere riconciliati deliberatamente.

Applica MFA al punto di ingresso dove la politica lo richiede, e mantieni i controlli dell’account di destinazione. I due sono complementari: il primo decide chi può raggiungere la porta, il secondo chi può aprirla. Ometterne uno lascia un progetto che sembra completo e non lo è.

Scegli il confine che corrisponde al lavoro e al modello operativo che hai davvero. Panoramica dei ruoli RDS descrive il posto del gateway tra l’host di sessione e gli altri componenti, ed è questo il contesto che rende leggibile il suo costo.