پشتیبانی امن از راه دور را می‌توان با یک واسط کنترل‌شده انجام داد؛ به‌گونه‌ای که کارشناس بیرونی فقط به سامانه موردنیاز دسترسی داشته باشد و مسیر عمومی به شبکه داخلی دریافت نکند. در این معماری، هویت کارشناس بررسی می‌شود، مجوز به مأموریت و زمان مشخص محدود است و سازمان امکان پایش و خاتمه نشست را دارد.
این مدل برای سازمان‌ها و صنایعی کاربرد دارد که به تخصص پیمانکاران نیاز دارند، اما نمی‌خواهند هر درخواست پشتیبانی به ایجاد حساب دائمی، بازکردن پورت اینترنتی یا دسترسی گسترده به زیرساخت منجر شود. اجرای درست آن به طراحی مسیر ارتباط، سیاست دسترسی و کنترل تبادل فایل وابسته است.
منظور از پشتیبانی بدون اتصال مستقیم چیست؟
بدون اتصال مستقیم به معنای نبود ارتباط نیست. برای پشتیبانی آنلاین، ارتباطی میان کارشناس و خدمت سازمان برقرار می‌شود؛ تفاوت در این است که نشست از یک درگاه یا کارگزار عبور می‌کند و کارشناس، دسترسی شبکه‌ای عمومی و مسیریابی‌شده به سامانه هدف نمی‌گیرد.
برای مثال، پیمانکاری که باید خطای یک نرم‌افزار را بررسی کند، می‌تواند پس از احراز هویت وارد محیط کاری واسط شود و فقط به همان نرم‌افزار دسترسی داشته باشد. دسترسی به سایر سرورها، انتقال فایل، حافظه موقت و اجرای ابزارهای مدیریتی باید جداگانه تعیین شوند.
- هر کارشناس هویت اختصاصی و قابل پیگیری دارد.
- مقصد، پروتکل و مدت دسترسی از پیش مشخص می‌شود.
- دسترسی به منابع خارج از مأموریت مسدود است.
- نشست متناسب با حساسیت سامانه پایش و ثبت می‌شود.
- سازمان می‌تواند دسترسی را لغو و نشست فعال را خاتمه دهد.
وجود یک سرور واسط به‌تنهایی این شرایط را ایجاد نمی‌کند. اگر همان سرور دسترسی گسترده به شبکه داشته باشد یا کنترل‌های آن قابل دورزدن باشند، بخشی از ریسک همچنان باقی می‌ماند.
چرا مسیر پشتیبانی به ریسک امنیتی تبدیل می‌شود؟
تولیدکننده تجهیزات، پیمانکار نرم‌افزار یا تیم پشتیبانی ممکن است برای رفع خطا و بازیابی خدمت به دسترسی فوری نیاز داشته باشد. مشکل زمانی آغاز می‌شود که دسترسی ایجادشده از نیاز واقعی گسترده‌تر باشد یا پس از پایان کار باز بماند.
دسترسی بیشتر از نیاز مأموریت
کارشناس ممکن است فقط به یک سرور نیاز داشته باشد، اما به یک زیرشبکه کامل دسترسی پیدا کند. در این شرایط، سرقت حساب، آلودگی دستگاه کارشناس یا خطای انسانی می‌تواند منابع بیشتری را درگیر کند.
باقی‌ماندن حساب‌ها و مسیرهای موقت
حساب پیمانکار، قاعده فایروال یا ابزار کنترل از راه دور گاهی برای یک کار کوتاه فعال می‌شود و ماه‌ها باقی می‌ماند. نبود مالک مشخص و تاریخ انقضا، تشخیص دسترسی‌های معتبر را دشوار می‌کند.
نبود سابقه قابل انتساب
استفاده چند نفر از یک حساب مشترک، ارتباط‌نداشتن نشست با تیکت و ثبت‌نشدن فعالیت‌ها، پاسخ‌گویی پس از رخداد را محدود می‌کند. صرف ثبت زمان ورود، مشخص نمی‌کند چه تغییری روی سامانه انجام شده است.
استفاده مهاجمان از ابزارهای مجاز
ابزار پشتیبانی می‌تواند برای فعالیت مجاز استفاده شود و هم‌زمان در اختیار مهاجم قرار گیرد. MITRE ATT&CK این نوع سوءاستفاده را در تکنیک T1219 مستند کرده است. بنابراین مجازبودن نام یک نرم‌افزار، جای بررسی هویت و رفتار استفاده‌کننده را نمی‌گیرد.
انتقال فایل بدون کنترل مستقل
رفع اشکال معمولاً با انتقال وصله، اسکریپت، گزارش رخداد یا فایل تنظیمات همراه است. فعال‌بودن بی‌ضابطه Clipboard، درایو مشترک یا بارگذاری فایل می‌تواند مسیر ورود فایل آلوده یا خروج اطلاعات سازمان باشد.
معماری پشتیبانی امن از راه دور چگونه کار می‌کند؟
در معماری اعتماد صفر یا Zero Trust، حضور کاربر در شبکه داخلی مبنای اعتماد ضمنی نیست. NIST در سند SP 800-207 بر احراز هویت و مجوزدهی پیش از برقراری نشست با منبع سازمانی تأکید می‌کند.
کاربرد این اصل در پشتیبانی، محدودکردن دسترسی به منبع موردنیاز و بررسی مجوز هر نشست است. فرایند پیشنهادی می‌تواند مراحل زیر را داشته باشد:
- درخواست پشتیبانی با هدف، سامانه مقصد و مسئول داخلی ثبت می‌شود.
- مالک خدمت یا مسئول تعیین‌شده، دامنه و بازه زمانی دسترسی را تأیید می‌کند.
- کارشناس با حساب اختصاصی و احراز هویت چندمرحله‌ای وارد درگاه می‌شود.
- واسط نشست فقط ارتباط مجاز با مقصد تعیین‌شده را برقرار می‌کند.
- انتقال فایل، در صورت نیاز، از مسیر دارای کنترل مستقل انجام می‌شود.
- رویدادها و فعالیت‌های قابل ثبت، متناسب با پروتکل نگهداری می‌شوند.
- با پایان مجوز، دسترسی منقضی و نشست مطابق سیاست سازمان خاتمه می‌یابد.
مجوز پشتیبانی باید مشخص کند چه کسی، برای چه کاری، به کدام سامانه و تا چه زمانی دسترسی دارد.
چه کنترل‌هایی برای دسترسی پیمانکاران لازم است؟
هویت اختصاصی و احراز هویت چندمرحله‌ای
هر شخص باید حساب مستقل داشته باشد. حساب به شرکت پیمانکار، قرارداد و مسئول داخلی مرتبط می‌شود و با پایان همکاری بازبینی یا غیرفعال خواهد شد. راهنمای مشترک CISA و نهادهای همکار نیز احراز هویت چندمرحله‌ای و محدودسازی مجوزها را از کنترل‌های ایمن‌سازی دسترسی راه دور می‌داند.
مجوز محدود و زمان‌دار
مجوز باید متناسب با کار تعریف شود؛ برای نمونه، دسترسی به یک سرور برای دو ساعت و با سطح مشاهده، اگر بررسی خطا به تغییر نیاز ندارد. محدودیت زمانی باید روی نشست فعال هم اعمال شود؛ منقضی‌شدن حساب بدون قطع ارتباط موجود کافی نیست.
کنترل مقصد در واسط نشست
واسط نشست باید مانع اتصال به مقصدهای تأییدنشده شود. سخت‌سازی خود واسط، محدودکردن ابزارهای قابل اجرا، جداسازی شبکه و محافظت از اطلاعات ورود سامانه‌های هدف نیز بخشی از طراحی است.
ثبت فعالیت و امکان توقف نشست
اطلاعات ثبت‌شده می‌تواند شامل هویت، مقصد، زمان شروع و پایان، فرمان‌ها یا تصویر نشست باشد. همه این موارد در تمام پروتکل‌ها و محصولات به یک شکل در دسترس نیستند و باید پیش از استقرار بررسی شوند.
مدت نگهداری سوابق، دسترسی به آن‌ها و محافظت در برابر حذف یا تغییر نیز باید مشخص باشد. ضبط نشست ممکن است اطلاعات حساس را ثبت کند؛ بنابراین خود این سوابق به کنترل دسترسی نیاز دارند.
فرایند دسترسی اضطراری
برای بحران‌ها می‌توان دسترسی اضطراری یا Break-glass تعریف کرد. این مسیر باید از پیش تصویب و آزمایش شود، مسئول مشخص داشته باشد و پس از استفاده بازبینی شود. ایجاد دسترسی نامحدود در زمان حادثه، جایگزین برنامه اضطراری نیست.
تداوم خدمت و استقلال عملیاتی
درگاه پشتیبانی خود به یکی از اجزای مهم زیرساخت تبدیل می‌شود. وابستگی به اینترنت یا سرویس بیرونی، افزونگی، بازیابی و نحوه پشتیبانی از خود درگاه باید پیش از بهره‌برداری بررسی شوند.
تبادل فایل چگونه کنترل می‌شود؟
در معماری پیشنهادی، انتقال فایل سیاست مستقلی از کنترل نشست دارد. سازمان می‌تواند انتقال مستقیم فایل، درایو مشترک و Clipboard را ببندد و مسیر مشخصی برای دریافت وصله یا خروج گزارش تعریف کند. جداسازی منطقی این مسیرها لزوماً به دو تجهیز فیزیکی جدا نیاز ندارد؛ مهم، اعمال مستقل سیاست و جلوگیری از دورزدن آن است.
- نوع واقعی و ساختار فایل با پسوند آن تطبیق داده شود.
- اندازه و محتوای مجاز بر اساس سیاست سازمان بررسی شود.
- فایل با ابزارهای ضدبدافزار و در صورت نیاز تحلیل تکمیلی بررسی شود.
- مبدأ، مقصد و تأییدکننده انتقال ثبت شوند.
- اطلاعات حساس پیش از خروج از سازمان بررسی و در صورت نیاز حذف شوند.
مقدار هش می‌تواند برای بررسی یکسان‌بودن فایل با نسخه مرجع استفاده شود؛ اما به‌تنهایی سالم‌بودن آن را اثبات نمی‌کند. اسکن ضدبدافزار نیز تضمین شناسایی همه تهدیدها نیست و باید در کنار سایر کنترل‌ها قرار گیرد.
آیا VPN برای پشتیبانی امن کافی است؟
VPN می‌تواند ارتباط را در لایه انتقال محافظت کند، اما به‌تنهایی درباره مجازبودن هر اقدام، ثبت فعالیت داخل نشست یا کنترل محتوای فایل تصمیم نمی‌گیرد. امنیت آن به تنظیمات، محدودیت مسیرها و کنترل‌های مکمل وابسته است.
در یک طراحی مناسب، VPN می‌تواند باقی بماند و فقط دسترسی به درگاه پشتیبانی را فراهم کند. پس از آن، هویت کارشناس، مقصد مجاز و بازه زمانی نشست جداگانه کنترل می‌شوند. بنابراین موضوع، حذف اجباری VPN نیست؛ موضوع، جلوگیری از تبدیل آن به دسترسی گسترده و دائمی است.
پشتیبانی در IT، OT و شبکه‌های جداشده چه تفاوتی دارد؟
سرورها و سامانه‌های فناوری اطلاعات
برای پشتیبانی سامانه‌های IT، درگاه دسترسی، میزکار واسط یا Jump Host می‌تواند ارتباط با منابع مشخص را فراهم کند. مجوز اجرای ابزار، انتقال فایل، چاپ و دسترسی به سامانه‌های دیگر باید متناسب با مأموریت تنظیم شود.
شبکه‌های صنعتی و OT
در محیط صنعتی، تغییر تنظیمات ممکن است بر ایمنی و تداوم فرایند اثر بگذارد. راهنمای امنیت OT در NIST SP 800-82 Rev. 3 نیز بر توجه به الزامات عملکرد، قابلیت اطمینان و ایمنی این محیط‌ها تأکید دارد.
دسترسی پیمانکار در OT باید با مسئول بهره‌برداری هماهنگ شود، به تجهیز یا ایستگاه مهندسی مشخص محدود باشد و در بازه مجاز تعمیرات انجام شود. امکان بازگشت از تغییر، نظارت اپراتور و جلوگیری از دسترسی به نواحی مجاور نیز باید بررسی شوند.
شبکه‌های دارای Air Gap
شبکه‌ای که واقعاً Air Gap است، مسیر آنلاین به شبکه بیرونی ندارد. پشتیبانی در این وضعیت می‌تواند با حضور کارشناس داخلی، راهنمایی متخصص بیرونی و انتقال کنترل‌شده گزارش‌ها یا فایل‌های مجاز انجام شود.
ایجاد مسیر آنلاین، حتی اگر موقت و تحت نظارت باشد، وضعیت جداسازی را تغییر می‌دهد. چنین اقدامی باید تابع ارزیابی ریسک و مجوز سازمان باشد و نباید حفظ کامل Air Gap نامیده شود.
یک نمونه از پشتیبانی کنترل‌شده در صنعت
فرض کنید سازنده یک نرم‌افزار صنعتی باید خطای سامانه تولید را بررسی کند. جدول زیر دو شیوه مدیریت همین درخواست را مقایسه می‌کند. ستون دوم یک طراحی پیشنهادی است و اجرای آن به قابلیت ابزارها و سیاست سازمان وابسته است.
| وضعیت فاقد کنترل کافی | معماری واسط پیشنهادی | |||
|---|---|---|---|---|
| حساب پیمانکار بدون تاریخ پایان، فعال است. | مجوز به تیکت و بازه زمانی مشخص متصل است. | |||
| کارشناس به چند سامانه غیرمرتبط دسترسی دارد. | فقط مقصد و پروتکل موردنیاز مجاز است. | |||
| وصله مستقیماً از دستگاه کارشناس منتقل می‌شود. | فایل پیش از انتقال از مسیر بررسی و تأیید عبور می‌کند. | |||
| چند کارشناس از یک حساب استفاده می‌کنند. | هر کارشناس با هویت اختصاصی وارد می‌شود. | |||
| فقط زمان ورود به شبکه ثبت می‌شود. | سوابق نشست متناسب با پروتکل برای بازبینی نگهداری می‌شود. | |||
| بستن دسترسی به پیگیری دستی وابسته است. | انقضای مجوز و خاتمه نشست از پیش تعریف و آزمایش شده است. |
چک‌لیست ارزیابی پشتیبانی از راه دور
پیش از انتخاب ابزار، وضعیت فعلی را بررسی کنید. پاسخ نامشخص به این پرسش‌ها می‌تواند نشانه ضعف در فرایند، مستندسازی یا معماری باشد:
- چه ابزارهای دسترسی راه دور نصب هستند و مسئول هرکدام چه کسی است؟
- کدام پیمانکاران حساب فعال دارند و آخرین استفاده آن‌ها چه زمانی بوده است؟
- آیا حساب مشترک یا دسترسی بدون تاریخ انقضا وجود دارد؟
- آیا احراز هویت چندمرحله‌ای برای کاربران بیرونی اعمال می‌شود؟
- کارشناس به یک خدمت دسترسی دارد یا به چند بخش شبکه؟
- آیا مقصد، پروتکل و زمان نشست قابل محدودکردن است؟
- درخواست دسترسی را چه کسی تأیید می‌کند؟
- چه فعالیت‌هایی ثبت می‌شوند و چه کسی سوابق را بازبینی می‌کند؟
- آیا لغو مجوز، نشست فعال را هم قطع می‌کند؟
- فایل‌ها از چه مسیری وارد و خارج می‌شوند؟
- آیا مسیرهای پشتیبانی IT و OT از یکدیگر تفکیک شده‌اند؟
- در صورت اختلال در درگاه، اینترنت یا سرویس بیرونی، چه برنامه جایگزینی وجود دارد؟
راهکارهای آوید در معماری پشتیبانی چه نقشی دارند؟
شرکت رایانش ابری آوید، طراحی مسیر پشتیبانی را بر اساس نوع سامانه، حساسیت شبکه و نیاز واقعی کارشناس بررسی می‌کند. در این رویکرد، اجزای مختلف می‌توانند نقش‌های متفاوتی داشته باشند؛ انتخاب محصول و قابلیت موردنیاز باید در ارزیابی فنی و پایلوت مشخص شود.
| راهکار یا بستر | نقش قابل بررسی در طراحی | |||
|---|---|---|---|---|
| دورکاد | فراهم‌کردن دسترسی کنترل‌شده کاربران بیرونی به خدمات تعیین‌شده سازمان. | |||
| راکارد | انجام پشتیبانی و دسترسی راه دور در محدوده مجوزهای تعریف‌شده. | |||
| تشناد | بررسی امکان ارتباط پروتکلی کنترل‌شده میان نواحی، متناسب با سناریوی IT یا OT. | |||
| فایلاد | کنترل مسیر تبادل فایل و بررسی فایل‌ها بر اساس سیاست‌های سازمان. | |||
| PVM Desktop | فراهم‌کردن میزکار مجازی واسط برای فعالیت کارشناس، همراه با کنترل‌های موردنیاز دسترسی و شبکه. |
اگر محیط واسط روی زیرساخت مجازی مستقر شود، انتخاب بستر مجازی‌سازی نیز به موضوع تداوم خدمت و استقلال عملیاتی مرتبط می‌شود. در این بخش می‌توان ظرفیت PVM را به‌عنوان بستر مجازی‌سازی بومی بررسی کرد. کنترل هویت، ثبت نشست و مدیریت مجوز همچنان به اجزای مربوط به خود نیاز دارند و از انتخاب بستر مجازی‌سازی به‌تنهایی حاصل نمی‌شوند.
در نمایشگاه یزد پایدار ۱۴۰۵ درباره چه موضوعی گفت‌وگو کنیم؟
آوید در نمایشگاه یزد پایدار، از ۳۰ مهر تا ۳ آبان ۱۴۰۵ در محل دائمی نمایشگاه‌های بین‌المللی استان یزد، میزبان مدیران فناوری اطلاعات، مسئولان امنیت و پدافند غیرعامل و کارشناسان صنایع خواهد بود.
یکی از موضوعات این گفت‌وگوها، بررسی مسیر فعلی پشتیبانی پیمانکاران است: چه کسی وارد می‌شود، به چه منابعی می‌رسد، چه فایلی جابه‌جا می‌کند و دسترسی او چگونه پایان می‌یابد؟ در کنار آن، امکان استقرار محیط واسط بر بستر مجازی‌سازی بومی نیز قابل بررسی است.
گفت‌وگوی اولیه می‌تواند به شناسایی مسیرهای دسترسی پرریسک، ترسیم معماری مفهومی و تعیین دامنه یک پایلوت محدود کمک کند. ارزیابی کامل امنیت یا تأیید انطباق، به بررسی فنی جداگانه نیاز دارد.
برای شروع، اطلاعات کلی مانند تعداد پیمانکاران، نوع سامانه‌ها، پروتکل‌های مورد استفاده و روش فعلی انتقال فایل کافی است. IP، گذرواژه، نقشه محرمانه شبکه و جزئیات حساس را در فضای عمومی نمایشگاه ارائه نکنید.
