برای دسترسی پیمانکار به زیرساخت سازمان، امنیت ضروری است؛ اما امنیت با زیاد کردن تعداد صفحه‌های ورود، کدهای یک‌بارمصرف و تأییدهای تکراری ساخته نمی‌شود. اگر برای یک ریموت ساده، پیمانکار ابتدا VPN را برقرار کند، سپس کد Google Authenticator وارد کند، بعد وارد PAM شود و آنجا دوباره یک کد دیگر بگیرد تا در نهایت بتواند یک نشست RDP یا SSH را شروع کند، باید یک سؤال ساده پرسید: هرکدام از این مراحل دقیقاً چه ریسک متفاوتی را کنترل می‌کنند؟

چندلایه بودن امنیت به‌خودی‌خود ارزشمند است؛ اما چندلایه بودن با تکرار بی‌هدف یک کنترل تفاوت دارد. NIST در معماری Zero Trust تأکید می‌کند که اعتماد نباید صرفاً به دلیل حضور کاربر در شبکه داخلی یا اتصال از طریق VPN اعطا شود؛ تصمیم دسترسی باید بر اساس هویت، دستگاه، منبع مقصد و سیاست دسترسی گرفته شود. CISA نیز MFA را برای دسترسی‌های راه دور و حساب‌های مدیریتی توصیه می‌کند. مسئله این نیست که MFA بد است؛ مسئله این است که MFA و کنترل دسترسی باید در جای درست معماری قرار بگیرند.

اگر برای یک ریموت ۱۵ دقیقه‌ای، پیگیری گرفتن دسترسی ۳۰ یا ۴۵ دقیقه طول می‌کشد، یک تصمیم روشن لازم است: یا مسیر دسترسی را اصلاح کنید، یا سرویس ریموت استاندارد پیمانکار را نصب کنید. اگر قرار است هر بار گرفتن ریموت از خودِ رفع مشکل بیشتر زمان ببرد، ادامه این مدل همکاری از نظر عملیاتی منطقی نیست.

امنیت واقعی یا فقط اصطکاک بیشتر؟

گاهی سازمان تصور می‌کند هرچه تعداد درهای ورودی بیشتر شود، امنیت نیز بیشتر شده است. نتیجه چنین نگاهی معمولاً زنجیره‌ای شبیه این است:

VPN → MFA → PAM → MFA دوم → Remote Session

این مدل در بعضی سناریوهای بسیار حساس می‌تواند قابل توجیه باشد؛ مثلاً دسترسی یک مدیر ممتاز به Domain Controller، پایگاه‌داده مالی یا تجهیزات Core. اما اگر همین زنجیره برای هر ریموت پشتیبانی روزمره نیز بدون توجه به سطح ریسک تکرار شود، سازمان عملاً هزینه عملیاتی ایجاد کرده است.

حتی از نظر مفهومی، وارد کردن دو کد TOTP از یک گوشی الزاماً به معنی «دو عامل مستقل» نیست. ممکن است دو سامانه مستقل احراز هویت خودشان را اجرا کنند و این موضوع در برخی معماری‌ها دفاع اضافه ایجاد کند، اما ارزش امنیتی آن باید در مقابل هزینه و پیچیدگی عملیاتی سنجیده شود. تکرار یک تجربه احراز هویت بدون تصمیم‌گیری مبتنی بر ریسک، الزاماً همان چیزی نیست که Zero Trust از آن صحبت می‌کند.

برای MSP، زمان گرفتن دسترسی خودش یک KPI است

این موضوع برای یک MSP جدی‌تر است. تیم پشتیبانی ممکن است در طول روز به ده‌ها یا صدها سازمان مختلف متصل شود. اگر هر مشتری یک VPN متفاوت، یک Client متفاوت، یک روش MFA متفاوت و یک فرآیند تأیید جداگانه داشته باشد، بخش قابل توجهی از زمان کارشناسان نه صرف عیب‌یابی، بلکه صرف «رسیدن به نقطه‌ای می‌شود که بتوانند عیب‌یابی را شروع کنند».

از دید مشتری شاید این مراحل چند کلیک باشد؛ اما از دید پیمانکار یعنی نصب و نگهداری Cisco AnyConnect، FortiClient، OpenVPN، Windows VPN و ده‌ها ابزار دیگر، نگهداری Credentialها و پروفایل‌ها، هماهنگی برای OTP، انتظار برای تأیید و سپس ورود به PAM. بعد از تمام این مراحل تازه کار اصلی شروع می‌شود.

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

مدل درست برای دسترسی پیمانکار چیست؟

برای بیشتر سناریوهای پشتیبانی سازمانی، معماری زیر هم امن‌تر و هم عملیاتی‌تر است:

• هویت اختصاصی برای هر پیمانکار: حساب مشترک و رمز عبور مشترک حذف شود.
• MFA قوی در نقطه ورود: ورود پیمانکار به درگاه دسترسی با MFA انجام شود.
• دسترسی فقط به مقصد مجاز: پیمانکار نباید بعد از اتصال به VPN کل شبکه را ببیند؛ فقط سرور، کلاینت یا سرویس موردنیاز باید در دسترس باشد.
• دسترسی زمان‌دار: مجوز برای بازه مشخص صادر و بعد از پایان کار خودکار لغو شود.
• Approval در دسترسی‌های حساس: برای منابع مهم، شروع نشست نیازمند تأیید مسئول سازمان باشد.
• Least Privilege: فقط همان سطح دسترسی لازم برای کار داده شود.
• Session Recording و Audit: نشست‌های ممتاز ثبت، قابل بازبینی و قابل انتساب به یک هویت مشخص باشند.
• Step-up Authentication: احراز هویت مجدد فقط زمانی اعمال شود که ریسک واقعاً افزایش یافته؛ مثلاً هنگام ورود به یک منبع فوق‌حساس یا Elevation به Administrator.

PAM360 دقیقاً کجای این معماری قرار می‌گیرد؟

ManageEngine PAM360 برای همین نقطه طراحی شده است: متمرکز کردن دسترسی‌های ممتاز و تبدیل دسترسی دائم و کنترل‌نشده به دسترسی سیاست‌محور، زمان‌دار و قابل ممیزی. PAM360 می‌تواند نشست‌های RDP، SSH، VNC و برخی دسترسی‌های دیگر را از طریق درگاه مرکزی برقرار کند، Credential را از کاربر مخفی نگه دارد، نشست‌ها را ثبت کند و در سناریوهای مناسب دسترسی Just-in-Time ارائه دهد.

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

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

مثال ساده

فرض کنید پیمانکار برای رفع یک مشکل ServiceDesk یا SQL فقط به یک سرور مشخص نیاز دارد. مدل ضعیف این است که ابتدا به VPN کل سازمان متصل شود، بعد OTP بدهد، بعد وارد PAM شود، دوباره OTP بدهد و بعد RDP را باز کند.

مدل بهتر این است که پیمانکار با هویت شخصی و MFA وارد PAM شود، درخواست دسترسی دو ساعته به همان سرور را ثبت کند، در صورت لزوم تأیید بگیرد و نشست RDP از داخل PAM شروع شود. Credential واقعی سرور در اختیار پیمانکار قرار نگیرد، Session ضبط شود و پس از پایان بازه دسترسی خودکار بسته شود.

این مدل هم امنیت بیشتری دارد و هم تجربه عملیاتی قابل دفاع‌تری ایجاد می‌کند.

هر چیزی را با برچسب امنیت توجیه نکنیم

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

یا مسیر دسترسی را استاندارد کنید، یا سرویس ریموت مورد توافق پیمانکار را نصب کنید. اینکه برای هر تماس پشتیبانی نیم ساعت دنبال VPN، کد، تأیید و کد دوم باشیم و بعد در پنج دقیقه مشکل را حل کنیم، نه نشانه بلوغ امنیت است و نه نشانه کیفیت.

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

جمع‌بندی

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

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

برای پشتیبانی‌های عادی که هدف صرفاً کنترل و رفع مشکل یک Endpoint است، استفاده از یک راهکار استاندارد Remote Support نیز می‌تواند از پراکندگی VPNها و ابزارها جلوگیری کند. در مدانت، MedaDesk دقیقاً با همین نگاه به مسئله پشتیبانی و ریموت سازمانی توسعه داده شده است.

منابع:

• NIST SP 800-207 — Zero Trust Architecture
• CISA — Require Multifactor Authentication
• ManageEngine PAM360 Documentation
• PAM360 — Privileged Session Recording