محدود کنید چه کسی می‌تواند به RDP دسترسی داشته باشد، در جایی که پشتیبانی می‌شود احراز هویت سطح شبکه را فعال نگه دارید، از اعتبارنامه‌های قوی فردی استفاده کنید و امتیاز مدیریتی را به حداقل برسانید. پیش از بستن اتصال فعلی، یک نشست دوم و دسترسی بازیابی را آزمایش کنید.
میزکار را به‌عنوان مرز مدیریت در نظر بگیرید
یک نشست RDP دسترسی تعاملی به یک سیستم راه دور فراهم می‌کند، بنابراین حسابی که برای آن استفاده می‌شود می‌تواند هدفی ارزشمند شود. با تصمیم‌گیری درباره اینکه چه کسی به دسترسی نیاز دارد و چه کاری باید انجام دهد آغاز کنید. یک ورود مدیر مشترک راحت است تا زمانی که بخواهید دسترسی یک نفر را حذف کنید یا یک تغییر پیکربندی را بفهمید. حساب‌های فردی این کارهای عملیاتی را روشن‌تر می‌کنند.
در جایی که نرم‌افزار اجازه می‌دهد، فعالیت روزمره را از تغییرات دارای امتیاز جدا کنید. کاربری که به یک برنامه تجاری نیاز دارد لزوماً به مدیریت سیستم بدون محدودیت نیاز ندارد. نقطه پایانی مدیر را نیز نگهداری کنید: ایمن کردن ماشین راه دور، اعتبارنامه‌هایی را که از یک دستگاه محلی آلوده یا مشترک وارد می‌شوند محافظت نمی‌کند. در طراحی دسترسی، هر دو سر نشست را در نظر بگیرید.
پیش از تکیه بر حفاظت ورود، دسترسی‌پذیری را محدود کنید
تصمیم بگیرید کدام شبکه‌ها یا دستگاه‌های مجاز باید بتوانند به میزبان نشست دسترسی داشته باشند. در جایی که معماری شما پشتیبانی می‌کند، از یک VPN کنترل‌شده یا Remote Desktop Gateway استفاده کنید، نه افشای گسترده مدیریت. مایکروسافت RD Gateway را به‌عنوان مسیری به منابع داخلی با سیاست‌های مجوزدهی اتصال و منبع مستند می‌کند. مناسب بودن آن به محیط بستگی دارد؛ صرفاً به این دلیل که یک طرح از RDP پشتیبانی می‌کند، یک ویژگی همراه نیست.
قواعد فایروال را به مسیر مورد نظر محدود کنید و تأیید کنید که نشانی‌های پویا کلاینت چگونه مدیریت خواهند شد. قاعده‌ای محدودکننده نسازید که بی‌درنگ تنها مدیر را بدون گزینه بازیابی قطع کند. نشست موجود را باز نگه دارید، مسیر جدید را از نشست دیگری آزمایش کنید و مکانیزم بازیابی مجاز را پیش از حذف مسیر دسترسی قدیمی مستند کنید.
احراز هویت و اعتماد را صریح نگه دارید
مایکروسافت برای بیشتر محیط‌های پشتیبانی‌شده، احراز هویت سطح شبکه را توصیه می‌کند. NLA پیش از برقراری یک نشست راه دور کامل، احراز هویت را الزامی می‌کند و در آن مرحله حفاظت اضافه می‌کند. این جایگزین فایروال، سیاست حساب یا به‌روزرسانی‌های سیستم نمی‌شود. سازگاری کلاینت را بررسی کنید و مشکلات احراز هویت را عیب‌یابی کنید، نه اینکه به‌عنوان نخستین پاسخ پیکربندی را به‌طور دائمی ضعیف کنید.
در جایی که ممکن است از اعتبارنامه‌های یکتا و یک عامل دوم از طریق یک معماری دسترسی پشتیبانی‌شده استفاده کنید. رفتار مورد انتظار هویت راه دور و گواهی را بررسی کنید، به‌ویژه پس از بازسازی یا تغییر نام میزبان. یک هشدار گواهی شایسته بررسی است؛ پذیرش مکرر هویت‌های غیرمنتظره یک بررسی اعتماد مفید را به پنجره‌ای نادیده‌گرفته‌شده تبدیل می‌کند. اعتبارنامه‌های بازیابی را در یک مخزن خصوصی تأییدشده نگه دارید.
| لایه | تصمیم | تأیید |
|---|---|---|
| شبکه | کدام کلاینت‌ها می‌توانند به میزبان دسترسی داشته باشند؟ | منابع غیرمنتظره نمی‌توانند متصل شوند |
| احراز هویت | کدام حساب و عوامل لازم هستند؟ | یک نشست دوم مجاز موفق می‌شود |
| امتیاز | کدام کارها به مدیریت نیاز دارند؟ | کاربران روزمره نمی‌توانند تنظیمات سیستم را تغییر دهند |
| بازیابی | دسترسی پس از یک اشتباه چگونه بازیابی می‌شود؟ | مسیر بازیابی مستندشده در دسترس است |
آنچه نشست می‌تواند حمل کند را کاهش دهید
ویژگی‌های کلیپ‌بورد، درایو، چاپگر و سایر تغییر مسیرها را در برابر جریان کاری واقعی بررسی کنید. یک مدیر ممکن است به افشای هر منبع محلی به میزبان راه دور نیاز نداشته باشد. برعکس، غیرفعال کردن یک مسیر انتقال مورد نیاز بدون جایگزین می‌تواند راه‌حل‌های ناامن را تشویق کند. روش مجاز انتقال فایل‌ها را مستند کنید و اسرار را از یادداشت‌های معمول میزکار یا پوشه‌های دانلود اشتراکی دور نگه دارید.
مایکروسافت برای محیط‌های مناسب مبتنی بر دامنه، Remote Credential Guard را فراهم می‌کند تا افشای اعتبارنامه در طول اتصال‌های RDP کاهش یابد. این به کلاینت‌های سازگار و احراز هویت Kerberos نیاز دارد و از اتصال‌های مستقیم به ماشین هدف پشتیبانی می‌کند؛ اتصال‌ها از طریق Remote Desktop Gateway یا Connection Broker پشتیبانی نمی‌شوند. الزامات مسیر دسترسی واقعی خود را بررسی کنید، نه اینکه آن را حفاظتی جهانی برای ماشین‌های مستقل میزبانی‌شده Windows در نظر بگیرید.
ماشین و شواهد مورد نیاز خود را نگهداری کنید
به‌روزرسانی‌های سیستم‌عامل و برنامه را زمان‌بندی کنید، از جمله یک فرایند راه‌اندازی مجدد آگاهانه. بررسی کنید که آیا یک به‌روزرسانی به راه‌اندازی مجدد نیاز دارد و سرویس را پس از آن بررسی کنید. سیاست‌های نشست معقول برای کارهای بدون نظارت یا قطع‌شده تعیین کنید، اما برنامه‌هایی را که باید به کار ادامه دهند در نظر بگیرید. یک سیاست مهلت زمانی باید به یک نیاز امنیتی یا عملیاتی پاسخ دهد، نه اینکه صرفاً عددی دلبخواه از محیطی دیگر کپی کند.
اطلاعات مفید دسترسی و رخداد را تحت یک سیاست مستند نگه دارید. شکست‌های مکرر احراز هویت و فعالیت مدیریتی غیرمنتظره را پایش کنید، بدون جمع‌آوری محتوای غیرضروری. محدود کنید چه کسی می‌تواند سوابق تشخیصی را بخواند و تصمیم بگیرید چه مدت لازم هستند. یک سیاست ثبت دقیق معنادارتر از نگه داشتن همه‌چیز به‌طور نامحدود یا وعده اینکه هیچ سابقه عملیاتی هرگز وجود نخواهد داشت، است.
یک توالی ایمن برای نخستین نشست
هنگام تحویل، سیستم مورد انتظار را بررسی کنید، اعتبارنامه‌های موقت را از طریق فرایند تأییدشده تغییر دهید و دسترسی فردی ایجاد کنید. فایروال و مسیر بازیابی را تأیید کنید، سپس یک اتصال دوم را آزمایش کنید. به‌روزرسانی‌ها را اعمال کنید، تغییر مسیر را بررسی کنید و برنامه مورد نیاز را نصب کنید. یک پشتیبان ایجاد کنید و بازیابی تنظیماتی که اهمیت دارند را پیش از وابستگی میزکار به کار روزمره تمرین کنید.
DeskLink RDP و پیکربندی‌های اختصاصی انتخاب‌شده، گزینه‌های مرتبط با Windows را در فهرست SwissOctet ارائه می‌دهند. سیستم‌عامل، مجوزدهی، امتیازات حساب و مسئولیت‌های مدیریتی سفارش خود را تأیید کنید. یک اتصال میزکار پشتیبانی‌شده آغاز یک برنامه مدیریت است؛ کنترل‌هایی که پیکربندی و بررسی می‌کنید تعیین می‌کنند آن دسترسی چگونه استفاده می‌شود.
چک‌لیست عملی شما.
- از حساب‌های فردی و امتیاز مناسب استفاده کنید.
- مسیر دسترسی مورد نظر RDP را محدود کنید.
- NLA را روی سیستم‌های سازگار فعال نگه دارید.
- پیش از بستن دسترسی فعلی، یک نشست دوم را آزمایش کنید.
- تغییر مسیر، به‌روزرسانی‌ها و سیاست نشست را بررسی کنید.
- مجوزدهی و رویه بازیابی را تأیید کنید.
جزئیاتی که اهمیت دارند.
آیا NLA یک میزبان RDP در معرض خطر را کاملاً ایمن می‌کند؟+
خیر. NLA یک کنترل احراز هویت است. دسترسی‌پذیری، اعتبارنامه‌ها، به‌روزرسانی‌ها و سطح دسترسی همچنان نیازمند توجه هستند.
آیا می‌توانم از Remote Credential Guard روی هر سرور Windows استفاده کنم؟+
خیر. کلاینت، میزبان و محیط احراز هویت باید الزامات مایکروسافت را برآورده کنند، از جمله ترتیب Kerberos قابل اعمال.
قبل از سخت‌تر کردن فایروال چه کاری باید انجام دهم؟+
یک مسیر بازیابی را تأیید کنید، نشست کاری را حفظ کنید و مسیر مجاز جدید را از طریق یک اتصال دوم آزمایش کنید.
به منبع بروید.
این منابع از مفاهیم فنی این راهنما پشتیبانی می‌کنند. پیش از تغییر یک سیستم تولیدی، مستندات جاری را دنبال کنید.
- مایکروسافت: فعال‌سازی Remote Desktop و Network Level Authentication learn.microsoft.com
- مایکروسافت: دسترسی Remote Desktop Gateway learn.microsoft.com
- مایکروسافت: Remote Credential Guard learn.microsoft.com
راهنمایی تحریریه توسط SwissOctet. مثال‌ها نمایشی هستند. مشخصات خدمات، گزینه‌های موجود و شرایط قراردادی باید جداگانه تأیید شوند.