Redirecționare SSH, VPN sau RD Gateway: ce cale pentru un desktop RDP?

Toate trei opțiunile transportă RDP, deci protocolul nu este factorul decisiv. Adevărata întrebare este cât acces ar trebui să primească un utilizator și cine operează lucrul care îl acordă. Un port TCP redirecționat, o rețea privată rutată și un gateway de desktop răspund la această întrebare în trei dimensiuni diferite. Alegeți mai întâi dimensiunea și produsul va urma.

Întrebarea este amploarea, nu protocolul

Notați ce trebuie să atingă de fapt utilizatorul. Dacă răspunsul este un singur desktop, un design care acordă o subrețea este prea larg. Dacă răspunsul este desktop plus partaje de fișiere plus o consolă de administrare, un design care redirecționează un port va reveni luna viitoare pentru încă două redirecționări. Lista destinațiilor este cerința; tot restul este implementare.

Păstrați identitatea de intrare separată de contul Windows care se conectează la desktop. Fiecare design de mai jos are ambele, iar confundarea lor este modul în care un cont de gazdă de salt ajunge cu mai multă autoritate decât a intenționat cineva.

Un serviciu TCP redirecționat

O gazdă de salt SSH aprobată poate redirecționa un ascultător local către serviciul RDP pe care îl poate atinge. Legați acel ascultător la loopback atunci când există doar pentru mașina utilizatorului, ceea ce este intenția normală a unei redirecționări locale. Redirecționarea este o comoditate pentru o persoană, nu un serviciu pentru o echipă.

Autentificarea SSH autorizează accesul la calea de redirecționare și nimic mai mult. Autentificarea Windows și autorizarea RDP au loc în continuare la destinație, deci un cont de salt valid nu este o sesiune de desktop validă. Sunt două porți independente și ambele trebuie să se deschidă.

Restrângeți destinațiile de redirecționare ale contului de salt în loc să acordați un shell nelimitat. Acest design se potrivește unui set mic și explicit enumerat de mașini și adaugă o gazdă, o identitate și un ciclu de viață de operat. Acea gazdă suplimentară este partea pe care oamenii o uită când o compară cu un gateway: cineva trebuie să o patchuiască, să o monitorizeze și să dețină cheile ei.

Un spațiu de lucru privat rutat

Un VPN oferă DNS privat și acces la mai multe servicii folosite împreună, iar aceasta este valoarea lui reală. Ascunderea unui port de desktop este un efect secundar, nu motivul construirii lui. Această distincție contează când cineva întreabă de ce există VPN-ul.

Restrângeți rutele și permisiunile de resurse la destinațiile prevăzute. Un utilizator conectat nu merită automat întregul LAN, iar firewall-ul destinației plus drepturile de conectare Windows rămân limite separate pe care VPN-ul nu le înlocuiește.

Această aranjare este comodă pentru un spațiu de lucru gestionat deja stabilit. Costul este că integrarea, cerințele de dispozitiv, comportamentul resolver-ului și politica de conectare devin parte din mediul de lucru al utilizatorului și cineva trebuie să le dețină. Comparați acel cost cu licențierea gateway-ului înainte de a presupune că VPN-ul este opțiunea mai ieftină.

Un gateway specific RDP

Remote Desktop Gateway oferă o limită specifică RDP, nu una de rețea. Politica sa de autorizare a conexiunilor decide cine se poate conecta, iar politica de autorizare a resurselor decide la ce resurse interne pot ajunge prin el. Ambele politici fac parte din produs, nu sunt suplimente opționale.

Planificați împreună certificatele, integrarea identității și transporturile necesare. Gateway-ul nu este un releu TCP anonim, iar implementarea lui ca atare omite politicile care îl justifică. De asemenea, poartă cerințe de licențiere și operaționale pe care un singur port redirecționat nu le are. Bugetați-le înainte de revizuirea designului, nu după.

Acolo unde o echipă operează deja acces centralizat la desktopuri, acel cost general este deja plătit. Acolo unde o persoană are nevoie de o singură mașină, este o mașină mare cumpărată pentru o treabă mică.

De ce au în continuare nevoie toate trei

Păstrați verificările de identitate ale gazdei în fiecare design. Un alias local sau un tunel nu fac inofensiv un certificat neașteptat, iar acceptarea unuia nepotrivit pentru a trece printr-un proxy anulează scopul tunelului. Numele din client și numele de pe certificat trebuie reconciliate în mod deliberat.

Aplicați MFA la punctul de intrare unde politica o cere și păstrați controalele contului de la destinație. Cele două se completează: primul decide cine poate ajunge la ușă, al doilea cine o poate deschide. Omiterea oricăruia lasă un design care pare complet și nu este.

Alegeți limita care se potrivește cu munca și cu modelul operațional pe care îl aveți de fapt. Prezentare generală a rolurilor RDS descrie locul gateway-ului între gazda de sesiune și alte componente, iar acesta este contextul care face costul lui lizibil.