ساخت یک سرور دسکتاپ از راه دور: راه‌اندازی، امنیت و مقیاس‌پذیری

معرفی

استقرار خدمات دسکتاپ از راه دور می‌تواند مشکلات کار از راه دور، متمرکز کردن برنامه‌ها و دسترسی شخص ثالث را در یک پلتفرم حل کند. با این حال، RDS می‌تواند به سرعت در صورت پیکربندی نادرست مجوزها، گواهی‌ها یا کنترل‌های امنیتی شکست بخورد. این مقاله بر روی تصمیمات واضح و پیش‌فرض‌های ایمن که می‌توانید بلافاصله اعمال کنید، تمرکز دارد. شما با یک برنامه ساخت که می‌توانید مستند کنید و از آن پشتیبانی کنید، به پایان خواهید رسید.

سرور دسکتاپ از راه دور در اصطلاحات ویندوز چیست؟

RDS در مقابل Remote Desktop استاندارد

ویندوز پرو ریموت دسکتاپ یک ویژگی یک به یک برای یک ماشین واحد است. یک سرور ریموت دسکتاپ معمولاً خدمات ریموت دسکتاپ ویندوز سرور (RDS) است که از بسیاری از کاربران همزمان پشتیبانی می‌کند. RDS همچنین سیاست‌های مرکزی، کنترل جلسه و مجوزدهی را اضافه می‌کند. این تفاوت برای پشتیبانی و انطباق اهمیت دارد.

نقش‌های RDS که اهمیت دارند

بیشتر پیاده‌سازی‌های واقعی از مجموعه کوچکی از خدمات نقش استفاده می‌کنند:

• میزبان جلسه RD: جلسات کاربر و RemoteApps (برنامه‌های منتشر شده) را اجرا می‌کند.
• کارگزار اتصال RD: جلسات را پیگیری کرده و کاربران را به طور قابل اعتماد متصل می‌کند.
• دسترسی وب RD: یک پورتال برای برنامه‌ها و دسکتاپ‌ها فراهم می‌کند.
• گذرگاه RD: پوشش RDP داخل HTTPS برای دسترسی ایمن‌تر به اینترنت.
• مدیریت مجوزهای دسترسی کلاینت RDS (CALs).

شما می‌توانید نقش‌ها را در محیط‌های کوچک ترکیب کنید، اما طراحی‌های تولید معمولاً حداقل میزبان‌های جلسه و دروازه را جدا می‌کنند. جداسازی نقش‌ها تنها به عملکرد مربوط نمی‌شود.

مرحله ۱: طراحی RDS خود را برنامه‌ریزی کنید

توپولوژی: سرور تک vs سرور چندگانه

یک راه‌اندازی تک‌سرور می‌تواند برای یک آزمایشگاه یا یک دفتر کوچک با ترافیک کم کار کند. برای تولید، نقش‌ها را جدا کنید تا از قطعی‌ها کاسته و عیب‌یابی را ساده‌تر کنید. یک تقسیم‌بندی رایج این است که یک سرور برای کارگزار، وب و مجوز و یک یا چند سرور برای میزبان جلسه داشته باشید. اگر کاربران خارجی متصل شوند، RD Gateway را در صورت امکان بر روی یک سرور جداگانه قرار دهید.

اندازه‌گیری: CPU، RAM، ذخیره‌سازی، شبکه

برنامه‌ریزی ظرفیت جایی است که تجربه کاربری به دست می‌آید یا از دست می‌رود. برنامه‌های تعاملی در زمان ورود و راه‌اندازی برنامه اوج می‌گیرند، بنابراین اندازه‌گیری نیاز به اولویت‌های عملی دارد:

• CPU: برای پاسخگویی بهتر در جلسات، سرعت کلاک بالاتر را ترجیح دهید
• RAM: برنامه‌ریزی برای همزمانی اوج به منظور جلوگیری از صفحه‌بندی
• ذخیره‌سازی: SSD برای کاهش تأخیر I/O پروفایل و برنامه
• شبکه: اولویت دادن به تأخیر کم به جای پهنای باند خام

فشار حافظه باعث جلسات کند و شکست‌های تصادفی می‌شود، بنابراین برای همزمانی اوج برنامه‌ریزی کنید. ذخیره‌سازی SSD زمان بارگذاری پروفایل را کاهش می‌دهد و ثبات ورود به سیستم را بهبود می‌بخشد. مسیرهای شبکه با تأخیر کم معمولاً بیشتر از پهنای باند خام اهمیت دارند.

مدل دسترسی: داخلی، VPN یا اینترنت

قبل از نصب نقش‌ها، تصمیم بگیرید که کاربران چگونه به سرویس دسترسی پیدا خواهند کرد. دسترسی فقط داخلی ساده‌ترین است و خطرات را کاهش می‌دهد. دسترسی VPN یک لایه کنترل اضافه می‌کند اما نیاز به مدیریت کلاینت دارد. دسترسی اینترنت باید از RD Gateway بر روی HTTPS استفاده کند تا از افشای اطلاعات جلوگیری شود. پورت 3389 این یک تصمیم است که از بسیاری از حوادث امنیتی جلوگیری می‌کند.

اگر مجبور به پشتیبانی از دستگاه‌های بدون مدیریت هستید، برای کنترل‌های سخت‌گیرانه‌تر و مرزهای واضح‌تر برنامه‌ریزی کنید. دسترسی به اینترنت را به عنوان یک محصول در نظر بگیرید، نه یک گزینه، با مالکیت برای هویت، گواهی‌ها و نظارت.

مرحله ۲: آماده‌سازی ویندوز سرور برای RDS

پچ، خط پایه و دسترسی مدیر

پچ کردن ویندوز سرور به طور کامل قبل از افزودن نقش‌های RDS و حفظ یک چرخه به‌روزرسانی قابل پیش‌بینی. یک استاندارد سخت‌افزاری پایه که با محیط شما مطابقت دارد، اعمال کنید. از مرزهای مدیریتی واضح استفاده کنید:

• حساب‌های مدیر ویژه را از حساب‌های کاربری روزمره جدا کنید
• فقط از یک میزبان پرش مدیریت شده (نه از نقاط پایانی)
• عضویت مدیر محلی را محدود کرده و تغییرات را به طور منظم بررسی کنید

نام‌های DNS و وضعیت فایروال

نام DNS کاربر-محور را زود انتخاب کنید و آن را در تمام ابزارها و گواهی‌ها ثابت نگه دارید. قوانین فایروال را با ذهنیت "کمترین مواجهه" برنامه‌ریزی کنید. برای استقرارهای رو به اینترنت، هدف این است که فقط TCP 443 را به دروازه (گیت‌وی) نمایش دهید. TCP 3389 را از اینترنت عمومی بسته نگه دارید.

پیش‌نیازهای ساخت: پیوستن به دامنه و حساب‌های خدماتی (در صورت نیاز)

بیشتر استقرارهای RDS تولید به دامنه متصل هستند زیرا کنترل دسترسی مبتنی بر گروه و GPO برای مدیریت مرکزی اهمیت دارند. سرورها را به دامنه AD صحیح متصل کنید، سپس همگام‌سازی زمان و حل DNS را تأیید کنید. اگر از حساب‌های خدماتی برای عامل‌های نظارتی یا ابزارهای مدیریتی استفاده می‌کنید، آن‌ها را با حداقل دسترسی ایجاد کنید و مالکیت را مستند کنید.

مرحله ۳: نصب نقش‌های خدمات دسکتاپ از راه دور

استقرار استاندارد با مدیر سرور

از مسیر نصب خدمات دسکتاپ از راه دور در مدیر سرور برای یک راه‌اندازی تمیز استفاده کنید. یک استقرار دسکتاپ مبتنی بر جلسه را برای دسکتاپ‌های چند کاربره و RemoteApps انتخاب کنید. خدمات نقش را بر اساس طرح توپولوژی خود، نه راحتی، اختصاص دهید. محل نصب هر نقش را مستند کنید تا ارتقاءهای آینده را ساده‌تر کنید.

قوانین کلی قرارگیری و تفکیک نقش‌ها

قرارگیری نقش‌ها بر عملکرد و سرعت عیب‌یابی تأثیر می‌گذارد. هم‌مکانی همه چیز می‌تواند کار کند، اما همچنین گلوگاه‌ها را پنهان می‌کند تا زمانی که بار کاربر افزایش یابد. جدا کردن نقش‌های لبه از نقش‌های محاسباتی، شناسایی قطعی‌ها را آسان‌تر می‌کند و خطر امنیتی را کاهش می‌دهد.

• فقط برای آزمایشگاه یا استقرارهای بسیار کوچک نقش‌ها را هم‌محل کنید
• RD Gateway را برای دسترسی به اینترنت از Session Host خاموش نگه دارید
• به جای بزرگ کردن یک میزبان، میزبان‌های جلسه را به صورت افقی اضافه کنید
• از نام‌گذاری یکسان سرورها استفاده کنید تا پیگیری لاگ‌ها آسان باشد

بررسی‌های پس از نصب

پلتفرم را قبل از افزودن کاربران تأیید کنید. تأیید کنید که خدمات در حال اجرا هستند و به طور خودکار شروع می‌شوند. اگر RD Web Access را مستقر کرده‌اید، آن را به صورت داخلی آزمایش کنید. یک اتصال آزمایشی به میزبان جلسه برقرار کنید و تأیید کنید که ایجاد جلسه کار می‌کند. هر گونه خطا را اکنون برطرف کنید، قبل از اینکه گواهی‌نامه‌ها و سیاست‌ها را اضافه کنید.

یک چک لیست اعتبارسنجی کوتاه اضافه کنید که بتوانید پس از هر تغییر تکرار کنید. این چک لیست باید شامل یک تست اتصال، یک تست راه‌اندازی برنامه و یک بررسی لاگ برای هشدارهای جدید باشد. تکرار است که RDS را از "شکننده" به "قابل پیش‌بینی" تبدیل می‌کند.

مرحله ۴: پیکربندی مجوز RD

فعال‌سازی، افزودن CAL، تنظیم حالت

نقش RD Licensing را نصب کنید، سپس سرور مجوز را فعال کنید. CALهای RDS خود را اضافه کنید و حالت مجوز صحیح را انتخاب کنید: به ازای کاربر یا به ازای دستگاه. سرور و حالت مجوز را به محیط Session Host اعمال کنید. این را به عنوان یک مرحله ضروری در نظر بگیرید، نه یک کار بعدی.

مجوزها تأیید شده است

مسائل مربوط به مجوز معمولاً پس از یک دوره مهلت ظاهر می‌شوند که شناسایی آن‌ها را دشوار می‌کند. بررسی کنید مشاهده رویداد در میزبان جلسه برای هشدارهای مجوز. تأیید کنید که میزبان جلسه می‌تواند به سرور مجوز از طریق شبکه دسترسی پیدا کند. بررسی کنید که حالت با نوع CAL که در واقع دارید مطابقت دارد. از صفحه‌نمایش‌ها برای مستندات ساخت خود عکس بگیرید.

• تأیید کنید که سرور مجوز از هر میزبان جلسه قابل دسترسی است
• تأیید کنید که حالت مجوز در جایی که جلسات اجرا می‌شوند، اعمال شده است.
• قبل از ورود کاربر، لاگ‌های مربوط به RDS را برای هشدارها بررسی کنید
• پس از تغییرات GPO که ممکن است تنظیمات RDS را نادیده بگیرد، دوباره آزمایش کنید

الگوهای شکست مجوز برای شناسایی زودهنگام

بیشتر "شگفتی‌های" مجوز قابل پیشگیری هستند. مشکلات اغلب ناشی از عدم تطابق نوع CAL و حالت مجوز، یک سرور مجوز که نصب شده اما هرگز فعال نشده است، یا یک میزبان جلسه که به دلیل تغییرات DNS یا فایروال نمی‌تواند سرور مجوز را شناسایی کند، می‌باشد.

یک قانون ساده را در فرآیند خود بگنجانید: تا زمانی که گزارش‌های مجوز تحت بار تمیز نباشند، از مرحله آزمایشی به تولید منتقل نشوید. اگر ساخت شما آزمایش‌های اوج ورود را با موفقیت پشت سر بگذارد و هنوز هیچ هشدار مجوزی نشان ندهد، یک کلاس عمده از قطعی‌های آینده را حذف کرده‌اید.

مرحله ۵: انتشار دسکتاپ‌ها و RemoteApps

مجموعه‌های جلسه و گروه‌های کاربری

یک مجموعه جلسه گروهی نام‌گذاری شده از میزبان‌های جلسه و قوانین دسترسی کاربر است. از گروه‌های امنیتی به جای تخصیص‌های کاربر فردی برای مدیریت تمیز استفاده کنید. هنگامیکه بارهای کاری متفاوت است، مجموعه‌های جداگانه‌ای ایجاد کنید، مانند "کاربران دفتر" و "کاربران ERP". این کار تنظیم عملکرد و عیب‌یابی را پیش‌بینی‌پذیرتر می‌کند.

یک نقشه‌برداری واضح بین مجموعه‌ها و نتایج کسب‌وکار اضافه کنید. زمانی که کاربران می‌دانند کدام مجموعه از کدام برنامه‌ها پشتیبانی می‌کند، تیم‌های پشتیبانی می‌توانند مسائل را سریع‌تر هدایت کنند. طراحی مجموعه همچنین جایی است که شما محدودیت‌های جلسه و قوانین هدایت را به‌طور مداوم تنظیم می‌کنید.

مبانی انتشار RemoteApp

RemoteApps با ارائه تنها آنچه که کاربران نیاز دارند، اصطکاک کاربران را کاهش می‌دهند و پلتفرم‌هایی مانند TSplus دسترسی از راه دور می‌تواند انتشار و دسترسی وب را برای تیم‌هایی که می‌خواهند اجزای کمتری داشته باشند، ساده کند. آنها همچنین سطح حمله "دسکتاپ کامل" را محدود می‌کنند زمانی که کاربران فقط به یک یا دو برنامه نیاز دارند. انتشار معمولاً ساده است، اما قابلیت اطمینان به آزمایش مسیرهای راه‌اندازی برنامه و وابستگی‌ها بستگی دارد.

• هر RemoteApp را با یک کاربر استاندارد آزمایش کنید، نه یک حساب کاربری مدیر.
• اعتبارسنجی ارتباطات فایل و اجزای کمکی مورد نیاز
• قبل از اعمال محدودیت‌ها، الزامات چاپگر و کلیپ بورد را تأیید کنید
• انواع و نسخه‌های کلاینت‌های پشتیبانی شده را مستند کنید

پروفایل‌ها و اصول سرعت ورود

ورودهای کند معمولاً ناشی از اندازه پروفایل و مراحل پردازش پروفایل است. با یک استراتژی پروفایل واضح شروع کنید و آن را ساده نگه دارید. زمان ورود را با داده‌های واقعی کاربران آزمایش کنید، نه حساب‌های خالی. مدت زمان ورود را زود پیگیری کنید تا بتوانید پس از تغییرات، کاهش عملکرد را شناسایی کنید.

قبل از اینکه مقیاس‌گذاری کنید، محدودیت‌های اندازه پروفایل را تعریف کنید، فرآیندهای پاک‌سازی برای داده‌های موقتی را مشخص کنید و نحوه مدیریت اعتبارنامه‌های کش‌شده و وضعیت کاربر را تعیین کنید. بسیاری از حوادث "عملکرد" در واقع حوادث "گسترش پروفایل" هستند.

مرحله ۶: تأمین دسترسی خارجی با دروازه RD

چرا HTTPS از RDP نمایان بهتر است

تونل‌های RD Gateway ترافیک Remote Desktop را از طریق HTTPS بر روی پورت ۴۴۳. این امر قرارگیری مستقیم RDP را کاهش می‌دهد و نقطه کنترلی بهتری به شما می‌دهد. همچنین سازگاری با شبکه‌های محدود که فقط HTTPS مجاز است را بهبود می‌بخشد. برای اکثر تیم‌ها، این امن‌ترین پیش‌فرض برای دسترسی خارجی است.

سیاست‌ها، گواهی‌ها و گزینه‌های MFA

از سیاست‌های دروازه برای کنترل اینکه چه کسی می‌تواند متصل شود و به چه چیزی دسترسی داشته باشد، استفاده کنید. یک گواهی‌نامه که با نام DNS خارجی شما مطابقت دارد و توسط دستگاه‌های کاربر مورد اعتماد است، متصل کنید. اگر MFA لازم است، آن را در دروازه یا از طریق مسیر ارائه‌دهنده هویت خود اعمال کنید. قوانین را بر اساس گروه نگه‌دارید تا بررسی‌های دسترسی قابل مدیریت باقی بمانند.

• از سیاست‌های CAP/RAP مرتبط با گروه‌های امنیتی AD استفاده کنید
• دسترسی به منابع داخلی خاص را محدود کنید، نه به کل زیرشبکه‌ها
• اجرای MFA برای دسترسی خارجی زمانی که ریسک کسب و کار آن را توجیه می‌کند
• رویدادهای احراز هویت و مجوز را برای حسابرسی ثبت کنید

سخت‌افزار کردن دروازه و لایه لبه

RD Gateway را مانند یک سرور برنامه‌ای که به اینترنت متصل است، مدیریت کنید. آن را به‌روز نگه‌دارید، اجزای نصب‌شده را به حداقل برسانید و مسیرهای دسترسی مدیر را محدود کنید. تنظیمات قدیمی و ضعیف که به آن‌ها نیاز ندارید را غیرفعال کنید و رفتارهای حمله‌ی brute-force را زیر نظر داشته باشید. اگر سازمان شما یک پروکسی معکوس لبه دارد یا WAF استراتژی، هماهنگ کردن استقرار دروازه با آن.

در نهایت، اقدامات پاسخ به حادثه را تمرین کنید. بدانید چگونه یک کاربر را مسدود کنید، گواهی‌نامه‌ها را چرخش دهید و در طول یک حمله مشکوک دسترسی را محدود کنید. این اقدامات زمانی که آن‌ها را برنامه‌ریزی کرده‌اید، بسیار آسان‌تر هستند.

مرحله ۷: تنظیم عملکرد و قابلیت اطمینان

تنظیمات GPO که بار جلسه را کاهش می‌دهند

از Group Policy برای کاهش بار اضافی غیرضروری بدون شکستن جریان کار استفاده کنید. جلسات بی‌کار را محدود کنید و زمان قطع اتصال را تنظیم کنید تا منابع را به‌طور ایمن آزاد کنید. کنترل کلیپ بورد و هدایت درایو را بر اساس حساسیت داده‌ها انجام دهید. تغییرات را به‌صورت گام‌های کوچک اعمال کنید تا بتوانید تأثیر را اندازه‌گیری کنید.

سیگنال‌های نظارتی برای پیگیری زودهنگام

عملکرد CPU، حافظه و تأخیر دیسک را از روز اول بر روی میزبان‌های جلسه نظارت کنید. زمان ورود و روند تعداد جلسات را در طول هفته پیگیری کنید. شکست‌های احراز هویت دروازه را برای الگوهای حمله brute-force زیر نظر داشته باشید. هشدارهایی برای اشباع منابع تنظیم کنید، نه فقط رویدادهای خاموشی سرور. نظارت خوب از بروز "دوشنبه‌های غافلگیرکننده" جلوگیری می‌کند. با یک مجموعه پایه کوچک شروع کنید:

• روند مدت زمان ورود (میانگین + بدترین ۱۰٪)
• فشار حافظه میزبان جلسه در ساعات اوج
• تاخیر دیسک در مسیرهای پروفایل و برنامه
• ورودهای ناموفق RD Gateway و افزایش‌های غیرمعمول

ثبات عملیاتی: زمان‌های پچ و تغییر ریتم

عملکرد به انضباط عملیاتی بستگی دارد. زمان‌های نگهداری را برای میزبان‌های جلسه و سرورهای دروازه تعریف کنید و سپس آن‌ها را به کاربران اطلاع دهید. از استقرارهای مرحله‌ای استفاده کنید که در آن یک میزبان جلسه ابتدا به‌روزرسانی می‌شود و سپس بقیه. این رویکرد خطر اختلال گسترده ناشی از یک وصله یا به‌روزرسانی درایور بد را کاهش می‌دهد.

همچنین تعریف کنید که "بازگشت" در محیط شما به چه معناست. برای ماشین‌های مجازی، عکس‌برداری می‌تواند کمک کند، اما فقط زمانی که با احتیاط و به‌طور موقت استفاده شود. برای سیستم‌های فیزیکی، بازگشت ممکن است به معنای بازگرداندن یک تصویر طلایی یا حذف یک تغییر اخیر از طریق اتوماسیون باشد.

مرحله ۸: مسائل رایج ساخت و مسیرهای رفع آنها

گواهینامه‌ها، DNS، فایروال و NLA

خطاهای گواهی معمولاً ناشی از عدم تطابق نام یا زنجیره‌های اعتماد گمشده هستند. مشکلات DNS به صورت "نمی‌توان سرور را پیدا کرد" یا بارگذاری ناموفق پورتال ظاهر می‌شوند. اشتباهات فایروال اغلب ترافیک داخلی نقش به نقش را مسدود می‌کنند، نه فقط ترافیک کاربر. احراز هویت سطح شبکه (NLA) را فعال کنید تا قبل از ایجاد جلسه، احراز هویت الزامی شود. هر لایه را به ترتیب آزمایش کنید تا عیب‌یابی سریع باقی بماند.

• رزولوشن DNS برای نام میزبان دقیق کاربرپسند
• TLS تطابق گواهی + اعتبارسنجی زنجیره اعتماد
• دسترس‌پذیری فایروال (۴۴۳ به دروازه، ترافیک نقش داخلی مجاز است)
• NLA فعال و احراز هویت قبل از ایجاد جلسه موفق است

عادت تأیید از دیدگاه مشتری را اضافه کنید. اعتماد به گواهی را بر روی یک دستگاه کاربر معمولی بررسی کنید، نه فقط بر روی سرورها. اطمینان حاصل کنید که نام میزبان دقیقی که کاربران استفاده می‌کنند با گواهی مطابقت دارد. بسیاری از شکست‌های "تصادفی" قابل پیش‌بینی هستند به محض اینکه آنها را از یک مشتری واقعی بازتولید کنید.

جلسات کند و قطع ارتباط

قطع‌های ناگهانی معمولاً به مجوز، شکست‌های پروفایل یا خستگی منابع مربوط می‌شوند. جلسات کند معمولاً به فشار حافظه، تأخیر دیسک یا اسکریپت‌های سنگین ورود مربوط می‌شوند. Event Viewer را در Session Host و Gateway بررسی کنید و زمان‌بندی‌ها را همبسته کنید. قبل از تغییر تنظیمات، تأیید کنید که مشکل در سطح کاربر یا خاص مجموعه است. از اصلاحات کوچک استفاده کنید و دوباره آزمایش کنید، به جای حرکات بزرگ "بازسازی".

پرینتر، لوازم جانبی و نقاط مشکل در هدایت

چاپ و هدایت دستگاه‌های جانبی سهم بزرگی از تیکت‌های RDS را تشکیل می‌دهد. علت معمولاً عدم تطابق درایور، رفتار کشف چاپگر قدیمی یا سیاست‌های هدایت بیش از حد است. درایورهای چاپگر را در صورت امکان استاندارد کنید و با رایج‌ترین دستگاه‌ها زودتر آزمایش کنید. ویژگی‌های هدایت را که کاربران به آن‌ها نیاز ندارند محدود کنید، اما از مسدودسازی کلی بدون ورودی ذینفعان خودداری کنید.

هنگامی که مشکلات ادامه دارد، با غیرفعال کردن یک ویژگی هدایت در هر بار، آن را ایزوله کنید. این رویکرد از "رفع" هایی که به طور تصادفی اسکن، چاپ برچسب یا پدهای امضا را خراب می‌کند، جلوگیری می‌کند. دستگاه‌های پشتیبانی شده را مستند کنید تا مرکز کمک بتواند انتظارات کاربران را تنظیم کند.

چگونه TSplus ارائه دسکتاپ از راه دور را ساده می‌کند؟

TSplus دسترسی از راه دور یک روش ساده برای انتشار دسکتاپ‌ها و برنامه‌های ویندوز بدون نیاز به ساخت یک پشته چندنقشی کامل RDS ارائه می‌دهد. مدیران می‌توانند برنامه‌ها را منتشر کرده، آن‌ها را به کاربران یا گروه‌ها اختصاص دهند و دسترسی را از طریق یک پورتال وب قابل تنظیم ارائه دهند. کاربران می‌توانند از یک مرورگر با استفاده از HTML5 یا از هر کلاینت سازگار با RDP، بسته به نیاز دستگاه، متصل شوند. این رویکرد اصطکاک راه‌اندازی را کاهش می‌دهد در حالی که کنترل متمرکز بر برنامه‌ها و جلسات را برای عملیات بهینه حفظ می‌کند.

نتیجه

یک سرور دسکتاپ از راه دور قابل اعتماد با انتخاب‌های طراحی واضح و پیش‌فرض‌های ایمن آغاز می‌شود. میزبان‌های جلسه را برای بارهای واقعی اندازه‌گیری کنید، مجوزها را به درستی پیکربندی کنید و از قرار گرفتن RDP عمومی جلوگیری کنید. از RD Gateway و گواهی‌های تمیز برای دسترسی خارجی ایمن استفاده کنید. با نظارت و سیاست‌های مداوم، یک محیط RDS می‌تواند در حین رشد استفاده، پایدار بماند.