نحوه راه‌اندازی MFA برای دروازه RD: معماری، مراحل و بهترین شیوه‌ها

معرفی

گذرگاه دسکتاپ از راه دور (RD Gateway) RDP را از طریق HTTPS ایمن می‌کند، اما فقط رمزهای عبور نمی‌توانند از فیشینگ، پر کردن اعتبارنامه یا حملات brute-force جلوگیری کنند. افزودن احراز هویت چندعاملی (MFA) این شکاف را با تأیید هویت کاربر قبل از برقراری جلسه پر می‌کند. در این راهنما، شما یاد خواهید گرفت که چگونه MFA با RD Gateway و NPS یکپارچه می‌شود، مراحل پیکربندی دقیق و نکات عملیاتی که استقرار شما را در مقیاس قابل اعتماد نگه می‌دارد.

چرا RD Gateway به MFA نیاز دارد؟

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

برای RDP که به اینترنت متصل است، خطرات غالب شامل استفاده مجدد از رمز عبور، تلاش‌های brute-force، پخش توکن و سرقت جلسه از طریق پیکربندی نادرست TLS است. MFA با نیاز به یک عامل دوم که در برابر پخش اعتبار مقاوم است، به مقابله با این موارد می‌پردازد.

بسیاری از چارچوب‌ها—کنترل‌های NIST 800-63، ISO/IEC 27001 و مبنای مختلف بیمه سایبری—به طور ضمنی یا صریح انتظار MFA را دارند دسترسی از راه دور پیاده‌سازی MFA بر روی RDG هم به هدف کنترل و هم به انتظارات حسابرسان پاسخ می‌دهد بدون اینکه نیاز به بازطراحی ساختار تحویل شما باشد.

چگونه MFA در معماری دروازه RD جا می‌گیرد؟

سطح کنترل ساده است: کاربر RDP را از طریق RDG راه‌اندازی می‌کند؛ RDG احراز هویت را از طریق RADIUS به NPS ارسال می‌کند؛ NPS سیاست را ارزیابی کرده و ارائه‌دهنده MFA را فراخوانی می‌کند؛ در صورت موفقیت، NPS Access-Accept را برمی‌گرداند و RDG اتصال را کامل می‌کند. مجوز دسترسی به دارایی‌های داخلی هنوز تحت تأثیر RD CAP/RD RAP است، بنابراین اثبات هویت افزایشی است نه مخرب.

• جریان احراز هویت و نقاط تصمیم گیری
• ملاحظات UX برای کاربران از راه دور

جریان احراز هویت و نقاط تصمیم گیری

نقاط کلیدی تصمیم‌گیری شامل جایی است که منطق MFA اجرا می‌شود (NPS با افزونه Entra MFA یا یک پروکسی RADIUS شخص ثالث)، کدام عوامل مجاز هستند و چگونه خطاها مدیریت می‌شوند. متمرکز کردن تصمیمات بر روی NPS، حسابرسی و کنترل تغییرات را ساده می‌کند. برای املاک بزرگ، در نظر داشته باشید که یک جفت NPS اختصاصی برای جدا کردن ارزیابی سیاست از ظرفیت RDG و ساده‌سازی زمان‌های نگهداری داشته باشید.

ملاحظات UX برای کاربران از راه دور

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

لیست پیش‌نیازها چیست؟

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

• نقش‌ها، پورت‌ها و گواهی‌نامه‌ها
• آمادگی دایرکتوری و هویت

نقش‌ها، پورت‌ها و گواهی‌نامه‌ها

نقش NPS را بر روی یک سرور با اتصال AD قابل اعتماد پیاده‌سازی کنید. استانداردسازی بر روی RADIUS UDP 1812/1813 و هرگونه استفاده از 1645/1646 را مستند کنید. بر روی RDG، یک گواهی TLS عمومی معتبر برای شنونده HTTPS نصب کنید و پروتکل‌ها و رمزنگاری‌های ضعیف را حذف کنید. اسرار مشترک را در یک خزانه ثبت کنید، نه در یک تیکت یا یادداشت دسکتاپ.

آمادگی دایرکتوری و هویت

گروه‌های AD اختصاصی برای کاربران و مدیران مجاز RDG ایجاد کنید؛ از دامنه "Domain Users" خودداری کنید. تأیید کنید که کاربران در MFA ثبت‌نام کرده‌اند اگر از Entra ID استفاده می‌کنند. برای ارائه‌دهندگان شخص ثالث، هویت‌ها را همگام‌سازی کنید و یک کاربر آزمایشی را از ابتدا تا انتها قبل از ثبت‌نام گسترده آزمایش کنید. فرمت‌های نام کاربری (UPN در مقابل sAMAccountName) را بین RDG، NPS و پلتفرم MFA هم‌راستا کنید تا از عدم تطابق‌های خاموش جلوگیری شود.

پیکربندی مرحله به مرحله MFA برای RD Gateway چیست؟

• نصب و ثبت‌نام NPS
• RD Gateway را به عنوان یک مشتری RADIUS اضافه کنید
• ایجاد سیاست‌های NPS (CRP و NP)
• نصب افزونه MFA یا عامل شخص ثالث
• نقطه RD Gateway به NPS مرکزی (فروشگاه RD CAP)
• آزمایش MFA از ابتدا تا انتها

مرحله ۱ — نصب و ثبت‌نام NPS

نقش خدمات سیاست شبکه و دسترسی را نصب کنید، باز کنید nps.msc و NPS را در Active Directory ثبت کنید تا بتواند ویژگی‌های کاربر را بخواند. تأیید کنید که سرور سیاست شبکه خدمات (IAS) در حال اجرا است و سرور می‌تواند به یک کنترل‌کننده دامنه با تأخیر کم دسترسی پیدا کند. نام کامل دامنه/IP NPS را برای لاگ‌ها و سیاست‌ها یادداشت کنید.

دستورات اختیاری:

نصب-ویندوزویژگی NPAS -شاملابزارهایمدیریت
nps.msc

اجرا netsh nps add registeredserver

خدمات Get-Service IAS | شروع خدمات Test-Connection -تعداد ۴ -نام کامپیوتر (Get-ADDomainController -Discover).HostName

مرحله ۲ — افزودن RD Gateway به عنوان یک مشتری RADIUS

در مشتریان RADIUS، دروازه RD خود را با IP/FQDN اضافه کنید و یک نام دوستانه تنظیم کنید (به عنوان مثال، RDG01 )، و از یک راز مشترک بلند و محفوظ استفاده کنید. UDP 1812/1813 را در سرور NPS باز کنید و قابلیت دسترسی را تأیید کنید. اگر چندین RDG را اجرا می‌کنید، هر کدام را به‌طور صریح اضافه کنید (تعاریف زیرشبکه ممکن است، اما آسان‌تر است که دچار اشتباه نشوید).

دستورات اختیاری

یک مشتری اضافه کنید: netsh nps add client name="RDG01" address=10.0.10.20 sharedsecret="VeryLongVaultedSecret" vendor=standard enable=YES

netsh advfirewall firewall add rule name="RADIUS Auth (UDP 1812)" dir=in action=allow protocol=UDP localport=1812
netsh advfirewall firewall add rule name="RADIUS Acct (UDP 1813)" dir=in action=allow protocol=UDP localport=1813

مرحله ۳ — ایجاد سیاست‌های NPS (CRP و NP)

یک سیاست درخواست اتصال ایجاد کنید که به آدرس IPv4 مشتری RDG شما محدود شود. گزینه احراز هویت در این سرور را انتخاب کنید (برای Microsoft Entra MFA از طریق افزونه NPS) یا به RADIUS از راه دور منتقل کنید (برای یک پروکسی MFA شخص ثالث). سپس یک سیاست شبکه ایجاد کنید که شامل گروه‌های AD شما باشد (به عنوان مثال، کاربران GRP_RDG با دسترسی مجاز. اطمینان حاصل کنید که هر دو سیاست بالای قوانین عمومی قرار دارند.

دستورات اختیاری

# تأیید اینکه کاربر در گروه مجاز است
Get-ADUser user1 -Properties memberOf |
  Select-Object -ExpandProperty memberOf |
  Where-Object { $_ -like "*GRP_RDG_Users*" }

سیاست صادرات برای مرجع: reg export "HKLM\SYSTEM\CurrentControlSet\Services\IAS\Policy" C:\NPS-Policy.reg /y

مرحله ۴ — نصب افزونه MFA یا عامل شخص ثالث

برای Microsoft Entra MFA، افزونه NPS را نصب کنید، اسکریپت اتصال مستأجر را اجرا کنید و NPS را دوباره راه‌اندازی کنید. تأیید کنید که کاربران در MFA ثبت‌نام کرده‌اند و روش‌های push/app را ترجیح می‌دهند. برای MFA شخص ثالث، پروکسی/نماینده RADIUS فروشنده را نصب کنید، نقاط پایانی/رازهای مشترک را پیکربندی کنید و CRP خود را به آن گروه از راه دور اشاره کنید.

دستورات اختیاری

# Entra MFA NPS Extension bind
Set-Location "C:\Program Files\Microsoft\AzureMfa\"
.\AzureMfaNpsExtnConfigSetup.ps1
Restart-Service IAS

# کلید ثبت‌نام مفید (۰–۳)  
New-Item -Path HKLM:\SOFTWARE\Microsoft\AzureMfa -Force | Out-Null  
New-ItemProperty HKLM:\SOFTWARE\Microsoft\AzureMfa -Name LOG_LEVEL -Value 2 -PropertyType DWord -Force | Out-Null

یک گروه و سرور RADIUS از راه دور پیکربندی کنید: netsh nps add remoteradiusservergroup name="MFA-VENDOR"
netsh nps add remoteradiusserver name="MFA-VENDOR" address=10.0.20.50 authport=1812 sharedsecret="AnotherVaultedSecret"

مرحله ۵ — اشاره RD Gateway به NPS مرکزی (فروشگاه RD CAP)

در سرور RD Gateway، RD CAP Store را به سرور مرکزی که NPS را اجرا می‌کند تنظیم کنید، میزبان NPS + کلید مشترک را اضافه کنید و اتصال را تأیید کنید. RD CAP را به گروه‌های کاربری مجاز خود و RD RAP را به کامپیوترها/مجموعه‌های خاص تنظیم کنید. اگر MFA موفق باشد اما دسترسی ناموفق باشد، ابتدا دامنه RAP را بررسی کنید.

مرحله ۶ — آزمایش MFA از ابتدا تا انتها

از یک مشتری خارجی، از طریق RDG به یک میزبان شناخته شده متصل شوید و یک اعلان MFA را تأیید کنید، NPS 6272 (دسترسی مجاز) و یک جلسه موفق. همچنین مسیرهای منفی (در گروه نیست، ثبت‌نام نکرده، عامل نادرست، توکن منقضی) را برای اعتبارسنجی وضوح خطا و آمادگی پشتیبانی آزمایش کنید.

کتابچه راهنمای عیب‌یابی MFA برای دروازه RD چیست؟

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

• بدون درخواست، حلقه‌ها یا زمان‌های خروج
• تطبیق سیاست و دامنه گروه
• لاگ‌برداری و تلمتری که واقعاً استفاده خواهید کرد
• بهترین شیوه‌های سخت‌افزاری و عملیاتی امنیت
• حریم، TLS و حداقل دسترسی
• نظارت، هشداردهی و کنترل تغییرات
• تاب‌آوری و بازیابی

بدون درخواست، حلقه‌ها یا زمان‌های خروج

عدم وجود درخواست معمولاً نشان‌دهنده نقص در ترتیب سیاست یا ثبت‌نام MFA است. حلقه‌ها نشان‌دهنده عدم تطابق کلید مشترک یا بازگشت به جلو بین NPS و یک پروکسی هستند. زمان‌های انقضا معمولاً به مسدود شدن UDP 1812/1813، مسیریابی نامتقارن یا بازرسی بیش از حد تهاجمی IDS/IPS اشاره دارند. به‌طور موقت verbosity ثبت‌نام را افزایش دهید تا تأیید کنید کدام پرش شکست می‌خورد.

تطبیق سیاست و دامنه گروه

سیاست درخواست اتصال تأیید می‌کند که به مشتری RDG هدف‌گذاری شده و قبل از هر قانون کلی اعمال می‌شود. در سیاست شبکه، گروه AD دقیق و رفتار تو در توی گروه را بررسی کنید؛ برخی از محیط‌ها نیاز به کاهش حجم توکن یا عضویت مستقیم دارند. به مشکلات استانداردسازی نام کاربری بین UPN و نام‌های به سبک NT توجه کنید.

لاگ‌برداری و تلمتری که واقعاً استفاده خواهید کرد

از NPS Accounting برای همبستگی استفاده کنید و لاگ‌های عملیاتی RDG را فعال نگه دارید. از پلتفرم MFA خود، درخواست‌ها، ردها و الگوهای جغرافیایی/IP هر کاربر را بررسی کنید. یک داشبورد سبک ایجاد کنید: حجم احراز هویت، نرخ شکست، دلایل اصلی شکست و زمان متوسط چالش. این معیارها هم ظرفیت و هم امنیت تنظیمات.

بهترین شیوه‌های سخت‌افزاری و عملیاتی امنیت

MFA ضروری است اما کافی نیست. آن را با تقسیم‌بندی شبکه، TLS مدرن، حداقل امتیاز و نظارت قوی ترکیب کنید. یک خط پایه کوتاه و اجباری را حفظ کنید—سخت‌سازی تنها در صورتی مؤثر است که به‌طور مداوم اعمال شود و پس از وصله‌ها و به‌روزرسانی‌ها تأیید گردد.

حریم، TLS و حداقل دسترسی

RDG را در یک بخش DMZ سخت شده قرار دهید که فقط جریان‌های مورد نیاز به LAN را داشته باشد. از یک گواهی عمومی معتبر بر روی RDG استفاده کنید و قابلیت‌های قدیمی را غیرفعال کنید. TLS و رمزنگاری‌های ضعیف. دسترسی RDG را از طریق گروه‌های AD اختصاصی محدود کنید؛ از اعطای مجوزهای گسترده خودداری کنید و اطمینان حاصل کنید که RD RAPها فقط سیستم‌ها و پورت‌هایی را که کاربران واقعاً نیاز دارند، نقشه‌برداری کنند.

نظارت، هشداردهی و کنترل تغییرات

هشدار در مورد افزایش در احراز هویت‌های ناموفق، جغرافیای غیرمعمول یا درخواست‌های مکرر برای هر کاربر. تغییرات پیکربندی را در NPS، RDG و پلتفرم MFA با یک مسیر تأیید ثبت کنید. سیاست‌ها را به عنوان کد در نظر بگیرید: تغییرات را در کنترل منبع یا حداقل در یک ثبت تغییرات پیگیری کنید و قبل از انتقال به تولید، در یک محیط آزمایشی تست کنید.

تاب‌آوری و بازیابی

NPS را به صورت افزونگی اجرا کنید و RDG را برای ارجاع به چندین سرور RADIUS پیکربندی کنید. رفتار fail-open در مقابل fail-closed را برای هر مؤلفه مستند کنید؛ به طور پیش‌فرض برای دسترسی خارجی به fail-closed تنظیم کنید. پیکربندی NPS، سیاست‌های RDG و تنظیمات MFA را پشتیبان‌گیری کنید؛ بازیابی را تمرین کنید، از جمله جایگزینی گواهی و ثبت‌نام مجدد افزونه یا عامل MFA پس از بازسازی.

نتیجه

اضافه کردن MFA به RD Gateway بزرگترین شکاف در RDP مواجه با اینترنت را می‌بندد: سوءاستفاده از اعتبارنامه. با متمرکز کردن سیاست بر روی NPS و ادغام Entra MFA یا یک ارائه‌دهنده RADIUS شخص ثالث، شما اثبات هویت قوی را بدون مختل کردن مدل‌های RD CAP/RD RAP تحمیل می‌کنید. با آزمایش‌های هدفمند اعتبارسنجی کنید، به طور مداوم نظارت کنید و MFA را با TLS سخت‌شده، حداقل امتیاز و طراحی مقاوم NPS/RDG ترکیب کنید.