انتقال SSH، VPN یا RD Gateway: کدام مسیر برای یک دسکتاپ RDP؟

هر سه گزینه RDP را حمل می‌کنند، پس پروتکل عامل تعیین‌کننده نیست. پرسش واقعی این است که یک کاربر چه مقدار دسترسی باید بگیرد و چه کسی چیزی را که آن را می‌دهد اداره می‌کند. یک پورت TCP منتقل‌شده، یک شبکه خصوصی مسیریابی‌شده و یک دروازه دسکتاپ به این پرسش در سه اندازه مختلف پاسخ می‌دهند. اول اندازه را انتخاب کنید و محصول در پی می‌آید.

پرسش دامنه است، نه پروتکل

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

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

یک سرویس TCP منتقل‌شده

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

ورود SSH دسترسی به مسیر انتقال را احراز می‌کند و نه بیشتر. احراز هویت Windows و مجوز RDP هنوز در مقصد رخ می‌دهند، پس یک حساب پرش معتبر به معنای نشست دسکتاپ معتبر نیست. این‌ها دو دروازه مستقل هستند و هر دو باید باز شوند.

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

یک فضای کاری خصوصی مسیریابی‌شده

VPN یک DNS خصوصی و دسترسی به چندین سرویس را که با هم استفاده می‌شوند می‌دهد و ارزش واقعی آن همین است. پنهان کردن یک پورت دسکتاپ یک عارضه جانبی است، نه دلیل ساخت آن. این تفاوت زمانی مهم است که کسی می‌پرسد VPN اصلاً چرا وجود دارد.

مسیرها و مجوزهای منابع را به مقصدهای موردنظر محدود کنید. کاربر متصل به‌طور خودکار مستحق کل LAN نیست و دیوار آتش مقصد به‌همراه حقوق ورود Windows مرزهای جدایی می‌مانند که VPN آن‌ها را جایگزین نمی‌کند.

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

یک دروازه مخصوص RDP

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

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

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

آنچه هر سه هنوز نیاز دارند

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

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

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