Távoli asztali szerver építése: Beállítás, biztonság és skálázás

Bevezetés

A Remote Desktop Services telepítése megoldhatja a távoli munkát, az alkalmazások központosítását és a harmadik fél hozzáférését egy platformon. Azonban az RDS gyorsan megbukhat, ha a licencelés, a tanúsítványok vagy a biztonsági intézkedések rosszul vannak konfigurálva. Ez a cikk a világos döntésekre és a biztonságos alapértelmezett beállításokra összpontosít, amelyeket azonnal alkalmazhat. Egy olyan építési tervvel fog végezni, amelyet dokumentálni és támogatni tud.

Mi az a Távoli Asztali Szerver Windows kifejezésekben?

RDS vs standard Remote Desktop

A Windows Pro Remote Desktop egy egy az egyben funkció egyetlen géphez. A távoli asztali kiszolgáló jellemzően a Windows Server Remote Desktop Services (RDS), amely sok egyidejű felhasználót támogat. Az RDS központi politikákat, munkamenet-ellenőrzést és licencelést is hozzáad. Ez a különbség fontos a támogatás és a megfelelőség szempontjából.

Az RDS szerepek, amelyek számítanak

A legtöbb valós telepítés egy kis szerepkörszolgáltatás-csoportot használ:

• RD Session Host: felhasználói munkameneteket és RemoteAppokat (publikált alkalmazásokat) futtat.
• RD Connection Broker: nyomon követi a munkameneteket és megbízhatóan újracsatlakoztatja a felhasználókat.
• RD Web Access: egy portált biztosít az alkalmazások és asztali számítógépek számára.
• RD Gateway: burkolatok RDP belsejében HTTPS a biztonságosabb internet-hozzáférés érdekében.
• RD Licencelés: kezeli az RDS Kliensek Hozzáférési Licencét (CAL).

Kis környezetekben kombinálhatja a szerepeket, de a termelési tervek általában legalább a munkamenet-hosztokat és a kaput különválasztják. A szerepek elkülönítése nemcsak a teljesítményről szól.

1. lépés: Tervezze meg az RDS kialakítását

Topológia: egyetlen szerver vs több szerver

Egy egykiszolgálós beállítás működhet egy laborban vagy egy kis irodában alacsony egyidejűség mellett. Termeléshez külön szerepeket kell létrehozni a leállások csökkentése és a hibaelhárítás egyszerűsítése érdekében. Egy gyakori felosztás egy szerver a Broker, Web és Licencelés számára, és egy vagy több szerver a Session Host számára. Ha külső felhasználók csatlakoznak, lehetőség szerint helyezze az RD Gateway-t egy külön szerverre.

Méretezés: CPU, RAM, tárolás, hálózat

Kapacitás-tervezés az a terület, ahol a felhasználói élmény nyer vagy veszít. Az interaktív alkalmazások a bejelentkezés és az alkalmazás indítása során csúcsosodnak, ezért a méretezésnek gyakorlati prioritásokat kell figyelembe vennie:

• CPU: a session válaszidejének javítása érdekében részesítse előnyben a magasabb órajelet
• RAM: tervezze meg a csúcs egyidejűséget a lapozás elkerülése érdekében
• Tárhely: SSD a profil és az alkalmazás I/O késleltetésének csökkentésére
• Hálózat: a nyers sávszélesség helyett a kis késleltetést részesítse előnyben

A memória nyomás lassú munkameneteket és véletlenszerű hibákat okoz, ezért tervezzen a csúcs egyidejűségre. Az SSD tárolás csökkenti a profil betöltési idejét és javítja a bejelentkezési konzisztenciát. Az alacsony késleltetésű hálózati útvonalak általában fontosabbak, mint a nyers sávszélesség.

Hozzáférési modell: belső, VPN vagy internet

Döntse el, hogyan érjék el a felhasználók a szolgáltatást, mielőtt telepítené a szerepeket. A belső hozzáférés a legegyszerűbb, és csökkenti a kitettséget. A VPN-hozzáférés egy vezérlési réteget ad hozzá, de klienskezelést igényel. Az internetes hozzáférésnek RD Gateway-t kell használnia HTTPS-en keresztül, így elkerülheti a kitettséget. port 3389 Ez az egy döntés megelőz sok biztonsági incidenst.

Ha támogatnia kell a nem kezelt eszközöket, tervezzen szigorúbb ellenőrzéseket és világosabb határokat. Az internet-hozzáférést termékként kezelje, ne csak egy jelölőnégyzetként, a személyazonosság, a tanúsítványok és a megfigyelés felelősségével.

Lépés 2: Készítse elő a Windows Servert az RDS-hez

Javítás, alapvonal és adminisztrátori hozzáférés

A Windows Server-t teljesen frissítse, mielőtt RDS szerepköröket adna hozzá, és tartson fenn egy kiszámítható frissítési ciklust. Alkalmazzon egy alapvető megerősítési szabványt, amely megfelel a környezetének. Használjon világos adminisztrátori határokat:

• Válassza el a privilégiumos adminisztrátori fiókokat a napi felhasználói fiókoktól.
• Admin csak egy kezelt ugró hosztról (nem végpontokról)
• Korlátozza a helyi adminisztrátori tagságot, és rendszeresen ellenőrizze a változásokat.

DNS nevek és tűzfal állapot

Válassza ki a felhasználók számára látható DNS nevet korán, és tartsa azt következetesnek az eszközök és tanúsítványok között. Tervezze meg a tűzfal szabályokat a "legkisebb kitettség" szemléletével. Az interneten elérhető telepítések esetén törekedjen arra, hogy csak a TCP 443-at tegye elérhetővé a kapuhoz. Tartsa a TCP 3389-et zárva a nyilvános internetről.

Build prerequisites: domain join and service accounts (when needed)

A legtöbb RDS telepítés tartományhoz csatlakozik, mivel a csoportalapú hozzáférés-vezérlés és a GPO központi szerepet játszik a kezelésben. Csatlakoztassa a szervereket a megfelelő AD tartományhoz korán, majd ellenőrizze az időszinkronizálást és a DNS feloldást. Ha szolgáltatásfiókokat használ a monitorozó ügynökök vagy a kezelőeszközök számára, hozza létre őket a legkisebb jogosultsággal, és dokumentálja a tulajdonjogot.

3. lépés: Telepítse a Távoli Asztali Szolgáltatások Szerepeit

Standard telepítés a Server Manager segítségével

Használja a Remote Desktop Services telepítési útvonalát a Server Managerben a tiszta beállításhoz. Válasszon session-alapú asztali telepítést többfelhasználós asztalokhoz és RemoteAppokhoz. Szolgáltatásokat rendeljen a topológiai tervének megfelelően, ne a kényelem alapján. Dokumentálja, hol van telepítve minden szerepkör, hogy egyszerűsítse a jövőbeli frissítéseket.

Szerepkör elhelyezési és elkülönítési irányelvek

A szerepkörök elhelyezése befolyásolja a teljesítményt és a hibaelhárítás sebességét. Minden egy helyen történő elhelyezése működhet, de ez elrejti a szűk keresztmetszeteket, amíg a felhasználói terhelés meg nem nő. A szélső szerepkörök elkülönítése a számítási szerepköröktől megkönnyíti a leállások elkülönítését és csökkenti a biztonsági kockázatot.

• Csak laboratóriumi vagy nagyon kis telepítésekhez társított szerepek
• Tartsa az RD Gateway-t a Session Hoston kívül az interneten elérhető hozzáféréshez.
• Session hostok vízszintes hozzáadása ahelyett, hogy egy hosztot túlnövelnénk.
• Használjon következetes szerverneveket, hogy a naplók könnyen követhetők legyenek.

Telepítés utáni ellenőrzések

Érvényesítse a platformot a felhasználók hozzáadása előtt. Ellenőrizze, hogy a szolgáltatások futnak-e és automatikusan indulnak-e. Tesztelje az RD Web Access-t belsőleg, ha telepítette. Végezzen el egy tesztkapcsolatot a Session Host-ra, és erősítse meg, hogy a munkamenet létrehozása működik. Javítson ki minden hibát most, mielőtt tanúsítványokat és irányelveket adna hozzá.

Adj hozzá egy rövid érvényesítési ellenőrzőlistát, amelyet minden változtatás után megismételhetsz. Tartalmaznia kell egy kapcsolatellenőrzést, egy alkalmazásindítási tesztet és egy naplóellenőrzést az új figyelmeztetésekhez. A megismétlés az, ami az RDS-t "törékeny"-ből "előrejelezhető"-vé alakítja.

4. lépés: RD licencelés konfigurálása

Aktiválás, CAL-ok hozzáadása, mód beállítása

Telepítse az RD Licencelési szerepkört, majd aktiválja a licencszervert. Adja hozzá az RDS CAL-jait, és válassza ki a megfelelő licencelési módot: Felhasználónként vagy Eszközönként. Alkalmazza a licencszervert és a módot a Session Host környezetre. Ezt kötelező lépésként kezelje, ne későbbi feladatként.

Ellenőrizze, hogy a licencelés alkalmazva van-e

Licencelési problémák gyakran a türelmi időszak után merülnek fel, ami megnehezíti a nyomon követésüket. Ellenőrizze Az eseménynéző a munkamenetgazdán a licencelési figyelmeztetésekhez. Ellenőrizze, hogy a munkamenetgazda elérheti a licencszervert a hálózaton. Ellenőrizze, hogy a mód megfelel a ténylegesen birtokolt CAL típusnak. Készítsen képernyőképeket az építési dokumentációjához.

• Ellenőrizze, hogy a licencszerver elérhető-e minden Session Host-ból.
• Ellenőrizze, hogy a licencelési mód alkalmazva van, ahol a munkamenetek futnak.
• Ellenőrizze az RDS-hez kapcsolódó naplókat figyelmeztetésekért a felhasználói bevezetés előtt
• GPO változtatások utáni újratesztelés, amelyek felülírhatják az RDS beállításokat

Licencelési hibák korai észlelésének mintái

A legtöbb licencelési "meglepetés" megelőzhető. A problémák gyakran a nem megfelelő CAL típusból és licencelési módból, egy telepített, de soha nem aktivált licencelési szerverből, vagy egy Session Hostból adódnak, amely nem tudja felfedezni a licencelési szervert DNS vagy tűzfal változások miatt.

Építsen be egy egyszerű szabályt a folyamatába: ne lépjen át a pilottól a termelésre, amíg a licencnaplók terhelés alatt tiszták. Ha az építése túléli a csúcs bejelentkezési teszteket, és még mindig nem mutat licencfigyelmeztetéseket, akkor megszüntette a jövőbeli leállások egy jelentős osztályát.

5. lépés: Asztalok és RemoteAppok közzététele

Munkamenet-gyűjtemények és felhasználói csoportok

A Session Collection egy elnevezett csoport a Session Hostokból és a felhasználói hozzáférési szabályokból. Használjon biztonsági csoportokat az egyéni felhasználói hozzárendelések helyett a tiszta adminisztráció érdekében. Hozzon létre különálló gyűjteményeket, amikor a munkaterhelések eltérnek, például "Irodai felhasználók" és "ERP felhasználók". Ez elősegíti a teljesítményhangolás és a hibaelhárítás kiszámíthatóságát.

Adjon egy világos térképet a gyűjtemények és az üzleti eredmények között. Amikor a felhasználók tudják, hogy melyik gyűjtemény támogatja mely alkalmazásokat, a helpdesk csapatok gyorsabban tudják irányítani a problémákat. A gyűjtemény tervezése az is, ahol következetes munkamenet-korlátokat és átirányítási szabályokat állít be.

RemoteApp közzétételi alapok

A RemoteApps csökkentik a felhasználói frusztrációt azáltal, hogy csak azt szolgáltatják, amire szükségük van, és olyan platformok, mint a TSplus Távhozzáférés egyszerűsítheti a kiadást és a webhozzáférést azok számára, akik kevesebb mozgó alkatrészt szeretnének. Ezenkívül korlátozzák a „teljes asztali” támadási felületet, amikor a felhasználóknak csak egy vagy két alkalmazásra van szükségük. A kiadás általában egyszerű, de a megbízhatóság a alkalmazásindítási útvonalak és függőségek tesztelésén múlik.

• Minden RemoteApp-ot egy standard felhasználóval teszteljen, ne adminisztrátori fiókkal.
• Érvényesítse a fájl társításokat és a szükséges segédkomponenseket
• Mielőtt a korlátozásokat érvényesítené, erősítse meg a nyomtató és a vágólap követelményeit.
• Dokumentálja a támogatott kliens típusokat és verziókat

Profilok és bejelentkezési sebesség alapjai

A lassú bejelentkezések gyakran a profil méretéből és a profil feldolgozási lépéseiből adódnak. Kezdj egy világos profil stratégiával, és tartsd egyszerűen. Teszteld a bejelentkezési időt valós felhasználói adatokkal, ne üres fiókokkal. Kövesd nyomon a bejelentkezési időt korán, hogy észlelhesd a visszaeséseket a változások után.

Védőkorlátokat kell bevezetni a méretezés előtt. Határozza meg a profilméret korlátait, a ideiglenes adatok tisztítási folyamatait, valamint azt, hogyan kezeli a gyorsítótárazott hitelesítő adatokat és a felhasználói állapotot. Sok "teljesítmény" incidens valójában "profil szétszóródás" incidens.

6. lépés: Külső hozzáférés biztosítása RD Gateway segítségével

Miért verik az HTTPS-t a nyitott RDP-t

RD Gateway alagútja a Remote Desktop forgalmat a következőn keresztül HTTPS a 443-as porton. Ez csökkenti az RDP közvetlen kitettségét, és jobb vezérlési pontot biztosít. Emellett javítja a kompatibilitást a lezárt hálózatokkal, ahol csak a HTTPS engedélyezett. A legtöbb csapat számára ez a legbiztonságosabb alapértelmezett beállítás a külső hozzáféréshez.

Politikák, tanúsítványok és MFA lehetőségek

Használjon átjáró politikákat annak ellenőrzésére, hogy ki csatlakozhat és mit érhet el. Kösse össze a tanúsítványt, amely megfelel a külső DNS nevének, és amelyet a felhasználói eszközök megbízhatónak tartanak. Ha MFA szükséges, érvényesítse azt az átjárón vagy az identitásszolgáltató útján. Tartsa a szabályokat csoportalapúaknak, hogy a hozzáférési felülvizsgálatok kezelhetők maradjanak.

• Használjon CAP/RAP politikákat, amelyek az AD biztonsági csoportokhoz kapcsolódnak.
• Korlátozza a hozzáférést a konkrét belső erőforrásokhoz, nem az egész alhálózatokhoz.
• Kényszerítse a többfaktoros hitelesítést a külső hozzáféréshez, amikor az üzleti kockázat indokolja.
• Bejelentkezési hitelesítési és jogosultsági események naplózása auditokhoz

A kapu és a peremréteg megerősítése

Kezelje az RD Gateway-t, mint egy interneten elérhető alkalmazásszervert. Tartsa frissítve, minimalizálja a telepített összetevőket, és korlátozza az adminisztrátori hozzáférési utakat. Tiltsa le azokat a gyenge örökölt beállításokat, amelyekre nincs szüksége, és figyelje a brute-force viselkedést. Ha a szervezete rendelkezik egy élső visszafelé proxyval vagy WAF stratégia, igazítsa a kapu telepítését ehhez.

Végül gyakorolja az incidensválasz intézkedéseit. Tudja, hogyan kell blokkolni egy felhasználót, forgatni a tanúsítványokat, és korlátozni a hozzáférést gyanított támadás esetén. Ezek az intézkedések sokkal könnyebbek, ha előre megtervezte őket.

Lépés 7: Teljesítmény és megbízhatóság finomhangolása

GPO-beállítások, amelyek csökkentik a munkamenet terhelését

Használja a Csoportházirendet a felesleges terhek csökkentésére anélkül, hogy megszakítaná a munkafolyamatokat. Korlátozza az inaktív munkameneteket, és állítson be bontási időkorlátokat a források biztonságos felszabadítása érdekében. Ellenőrizze a vágólap és a meghajtó átirányítását az adatok érzékenysége alapján. Alkalmazza a változtatásokat kis lépésekben, hogy mérni tudja a hatást.

Korai nyomkövetésre szolgáló jelzések

Monitorozza a CPU, memória és lemez késleltetést a Session Hostokon az első naptól kezdve. Kövesse nyomon a bejelentkezési időt és a munkamenetek számának trendjeit a héten. Figyelje a gateway hitelesítési hibákat a brute-force mintákra. Állítson be riasztásokat az erőforrások telítettségére, ne csak a szerverleállási eseményekre. A jó monitorozás megakadályozza a „meglepetés hétfőket.” Kezdje egy kis alapbeállítással:

• Bejelentkezési időtartam trendek (medián + legrosszabb 10%)
• Csúcsidőszakban a munkamenetgazda memória nyomása
• Lemez késleltetés a profil- és alkalmazásútvonalakon
• RD Gateway sikertelen bejelentkezések és szokatlan csúcsok

Működési stabilitás: javítási ablakok és változási ütemezés

A teljesítmény a működési fegyelemtől függ. Határozzon meg karbantartási időszakokat a Session Hostok és a Gateway szerverek számára, majd kommunikálja ezeket a felhasználóknak. Használjon fokozatos bevezetéseket, ahol egy Session Host frissül először, majd a többi. Ez a megközelítés csökkenti a széleskörű zavarok kockázatát egy rossz javítás vagy illesztőprogram-frissítés miatt.

A környezetében a "visszaállítás" jelentését is határozza meg. A virtuális gépeknél a pillanatképek segíthetnek, de csak akkor, ha gondosan és rövid ideig használják őket. Fizikai rendszerek esetén a visszaállítás jelentheti egy aranykép visszaállítását vagy egy nemrégiben végrehajtott változtatás eltávolítását automatizálás révén.

Lépés 8: Gyakori építési problémák és javítási útvonalak

Tanúsítványok, DNS, tűzfal és NLA

A tanúsítványhibák általában néveltérésekből vagy hiányzó bizalmi láncokból adódnak. A DNS-problémák "nem található a szerver" vagy sikertelen portálbetöltések formájában jelentkeznek. A tűzfalhibák gyakran blokkolják a belső szerep-hoz-szerep forgalmat, nem csak a felhasználói forgalmat. Engedélyezze a Hálózati Szintű Hitelesítést (NLA), hogy a munkamenet létrehozása előtt hitelesítést követeljen meg. Tesztelje az egyes rétegeket sorrendben, hogy a hibaelhárítás gyors maradjon.

• A pontos felhasználói névvel rendelkező hosztnév DNS feloldása
• TLS tanúsítvány egyezés + bizalmi lánc érvényesítés
• Tűzfal elérhetőség (443 a Gateway-hez, belső szerepkör forgalma engedélyezve)
• NLA engedélyezve és az azonosítás sikeres a munkamenet létrehozása előtt

Adjunk hozzá egy szokást, hogy az ügyfél szempontjából érvényesítünk. Ellenőrizzük a tanúsítvány megbízhatóságát egy tipikus felhasználói eszközön, nem csak a szervereken. Ellenőrizzük, hogy a felhasználók által használt pontos hosztnév megegyezik-e a tanúsítvánnyal. Sok "véletlenszerű" hiba előrejelezhető, ha reprodukáljuk őket egy valódi ügyféltől.

Lassú munkamenetek és megszakadások

A hirtelen megszakadások gyakran a licencelésre, profilhibákra vagy erőforrás-kimerülésre vezethetők vissza. A lassú munkamenetek általában memória nyomásra, lemez késleltetésre vagy nehéz bejelentkezési szkriptekre vezethetők vissza. Ellenőrizze az Eseménynézőt a Munkamenet Gazdán és a Gateway-en, és korrelálja az időbélyegeket. Erősítse meg, hogy a probléma felhasználó szintű vagy gyűjtemény-specifikus, mielőtt módosítaná a beállításokat. Használjon kis javításokat és tesztelje újra, a nagy "újraépítési" lépések helyett.

Nyomtató, perifériák és átirányítási problémák

A nyomtatás és a perifériák átirányítása a RDS jegyek nagy részét képezik. Az ok gyakran a meghajtó inkompatibilitás, a régi nyomtató felfedezési viselkedés vagy a túlzott átirányítási irányelvek. Standardizálja a nyomtató meghajtókat, ahol lehetséges, és tesztelje a leggyakoribb eszközökkel korán. Korlátozza az átirányítási funkciókat, amelyekre a felhasználóknak nincs szükségük, de kerülje a teljes blokkolást a résztvevők bevonása nélkül.

Ha a problémák továbbra is fennállnak, izolálja az egyes átirányítási funkciók letiltásával. Ez a megközelítés megakadályozza azokat a "javításokat", amelyek véletlenül megszakítják a szkennelést, a címke nyomtatást vagy az aláírási padokat. Dokumentálja a támogatott eszközöket, hogy a helpdesk be tudja állítani a felhasználói elvárásokat.

Hogyan egyszerűsíti a TSplus a Remote Desktop szolgáltatást?

TSplus Távhozzáférés egyszerűsített módot kínál a Windows asztalok és alkalmazások közzétételére anélkül, hogy teljes, több szerepkörű RDS halmazt kellene létrehozni. Az adminisztrátorok alkalmazásokat publikálhatnak, hozzárendelhetik őket felhasználókhoz vagy csoportokhoz, és hozzáférést biztosíthatnak egy testreszabható webportálon keresztül. A felhasználók böngészőből HTML5 segítségével vagy bármely RDP-kompatibilis kliensből csatlakozhatnak, a készülék igényeitől függően. Ez a megközelítés csökkenti a beállítási nehézségeket, miközben központosított ellenőrzést tart fenn az alkalmazások és munkamenetek felett a hatékony működés érdekében.

Következtetés

Egy megbízható távoli asztali szerver világos tervezési választásokkal és biztonságos alapértelmezett beállításokkal kezdődik. Méretezze a munkamenet-hosztokat a valós terhelésekhez, konfigurálja helyesen a licencelést, és kerülje a nyilvános RDP kitettséget. Használjon RD Gateway-t és tiszta tanúsítványokat a biztonságos külső hozzáféréshez. Megfigyeléssel és következetes politikákkal egy RDS környezet stabil maradhat a használat növekedésével.