ابتدا یک وظیفهٔ تعمیراتی را تعریف کنید، نه یک اتصال بلندمدت
فرض کنید یک ترمینال کسب‌وکار در شعبه‌ای دچار خرابی شده و نیاز به عیب‌یابی از سوی تأمین‌کنندهٔ خارجی از راه دور دارد. کارکنان محلی برای بازگشت سریع‌تر به کار، ممکن است تمایل داشته باشند مستقیماً یک آدرس اتصال بلندمدت ارسال کنند. نکتهٔ کلیدی در این سناریو فرضی این نیست که آیا تأمین‌کننده قابل اعتماد است یا خیر، بلکه این است که این بار چه کسی، از چه دستگاهی، به چه منابعی دسترسی دارد، چه اقداماتی انجام می‌دهد و پس از پایان وظیفه چگونه اطمینان حاصل می‌شود که دسترسی‌ها بازپس‌گرفته شده‌اند. رابطهٔ با تأمین‌کننده جایگزین ثبت مجوز دسترسی برای یک دسترسی مشخص نمی‌شود.
JOTOglobal پیشنهاد می‌کند ابتدا با یک دستگاه تنها، خرابی مشخص و پنجرهٔ زمانی محدود تعمیرات شروع کنید. در سفارش کار (تیکت) درخواست‌کننده، تأثیر بر کسب‌وکار، تماس‌گیرندهٔ تأمین‌کننده، مسئول داخلی همراه و شرایط پیش‌بینی‌شدهٔ پایان وظیفه ذکر شود. لاگ‌های عیب‌یابی، مشاهدهٔ از راه دور، تغییر پیکربندی و به‌روزرسانی نرم‌افزار را جداگانه توصیف کنید؛ انجام هر عمل ممکن است نیازمند سطح دسترسی متفاوتی باشد. اگر تنها نیاز به خواندن وضعیت دستگاه است، نباید به‌طور پیش‌فرض دسترسی به کل زیرشبکه یا تمامی پنل‌های مدیریتی اعطا شود.
اجرای اصول اعتماد صفر در مرز منابع
مستند NIST SP 800-207 تأکید می‌کند که نمی‌توان تنها بر اساس موقعیت شبکه یا مالکیت دارایی، اعتماد ضمنی اعطا کرد و اصل ارزیابی دسترسی به منابع و حداقل دسترسی را در هر جلسه مطرح می‌کند. این یک راهنمای معماری است، نه نتیجهٔ گواهی‌نامهٔ یک محصول خاص برای تعمیرات از راه دور. فیلدهای سفارش کار، وظایف و مراحل پذیرش این مقاله توسط JOTOglobal به‌صورت مستقل سازمان‌دهی شده‌اند؛ سازمان‌ها باید آن‌ها را با شبکهٔ موجود، سیستم هویت‌یابی و توانایی‌های پشتیبانی محلی خود ادغام کنند و نباید خرید یک نقطهٔ ورود را معادل انجام کلیهٔ اقدامات حکمرانی بدانند.
قبل از باز کردن دسترسی، مسئول سیستم داخلی منابع هدف و پروتکل‌های ضروری را تأیید می‌کند، مدیر شبکه محدودهٔ قابل دسترسی را تأیید می‌کند و مسئول امنیت الزامات تأیید هویت، ثبت لاگ و واکنش به رویدادهای غیرعادی را تأیید می‌کند. باید هویت تأمین‌کننده با شخص تأییدشده در سفارش کار تطبیق داده شود؛ در مواردی که چند نفر به‌صورت شیفتی کار می‌کنند، افراد واقعی انجام‌دهندهٔ اقدامات به‌صورت جداگانه ثبت می‌شوند و یک حساب اشتراکی نمی‌تواند کل مسئولیت را برعهده بگیرد. در سیستم‌های قدیمی که امکان ارتباط‌دادن هویت فردی وجود ندارد، این محدودیت و اقدامات همراه باید ثبت شوند، نه اینکه اعتبارهای اشتراکی را به‌عنوان دسترسی قابل ردیابی جلوه داد.
مسیر دسترسی باید رابطهٔ واقعی بین دستگاه و منبع را نیز پوشش دهد. اتصال تأمین‌کننده به سرور پرش (Jump Server) به‌خودی‌خود به‌معنای دسترسی به تمام سرورها نیست؛ ورود موفق به یک برنامه نیز نباید به‌طور خودکار گسترش یافته و به برنامهٔ دیگری منجر شود. باید بررسی شود که قابلیت‌هایی مانند آپلود فایل، کلیپ‌بورد، فوروارد پورت و اتصالات اضافی برای انجام وظیفه ضروری هستند یا خیر. اگر سیستم قادر به تفکیک این قابلیت‌ها نباشد، ریسک‌های باقی‌مانده و محدودیت‌های محلی به‌وضوح باید بیان شوند و در اسناد، مجوزهای دقیقی که از نظر فنی وجود ندارند، ثبت نشوند.
آماده‌سازی برای پایان و بازگرداندن قبل از شروع
پنجرهٔ تعمیرات باید با ساعات کاری شعبه هماهنگ باشد و زمان شروع، زمان پایان پیش‌بینی‌شده و نقش‌های مجاز برای تمدید ثبت شوند. مسئول داخلی قبل از انجام اقدامات، اطمینان حاصل می‌کند که پیکربندی‌های کلیدی نسخه‌برداری قابل‌استفاده دارند، محتوای قابل تغییر، اقداماتی که نیازمند تأیید مجدد هستند و شرایط فعال‌سازی بازگرداندن (Rollback) را مشخص می‌کند. فشار بازگرداندن کسب‌وکار نباید باعث شود افراد ارزیابی تأثیرات را نادیده بگیرند. در مواردی که شامل راه‌اندازی مجدد، به‌روزرسانی میان‌افزار یا تغییر در سرویس‌های وابسته است، باید از قبل به تیم محلی اطلاع داده شود و روش‌های جایگزین کار مشخص گردد.
تأمین‌کننده از طریق ورودی موجود و تأییدشدهٔ سازمان، احراز هویت عادی را انجام می‌دهد؛ رابطهٔ بین حساب دسترسی، تأییدکننده و انجام‌دهندهٔ اقدامات باید قابل بررسی باشد. اعتبارها فقط از طریق کانال‌های تأییدشده پردازش می‌شوند و رمزهای عبور و توکن‌های کامل در گروه‌های پشتیبانی چندنفره یا سفارش‌های کار عمومی چسبانده نمی‌شوند. اگر سیستم هویت‌یابی یا ورودی تعمیرات در دسترس نباشد، موضوع باید طبق فرآیند اضطراری موجود به مسئول مربوط ارجاع شود و نباید به‌منظور انجام به‌موقع سفارش کار، پورت‌های مدیریتی عمومی بدون ارزیابی موقتاً باز شوند.
ثبت اقدامات کلیدی در طول تعمیرات
لاگ‌ها باید بتوانند سفارش کار، انجام‌دهنده، دستگاه هدف، زمان جلسه و تغییرات کلیدی را به‌هم مرتبط کنند. کارکنان کسب‌وکار معمولاً نیاز دارند بدانند کدام سرویس‌ها تحت تأثیر قرار گرفته‌اند، آیا در حال حاضر قابل دسترس هستند و مسئول اقدام بعدی چه کسی است، نه اینکه به تمامی اعتبارهای فنی دسترسی داشته باشند. ضبط صفحه یا ثبت جلسه ممکن است حاوی داده‌های کسب‌وکاری باشد و باید بر اساس سیاست‌های سازمانی، کاربردها و دسترسی به آن محدود شود؛ نباید به‌دلیل تسهیل پیگیری مسئولیت، ضبط کامل بدون تفکیک به تمام شرکت‌کنندگان توزیع شود.
در صورتی که نیاز به گسترش محدودهٔ اقدامات احساس شد، ابتدا منابع جدید، اقدامات، تأثیرات و شرایط پایان را توضیح دهید و پس از تأیید توسط نقش داخلی تعیین‌شده، دسترسی‌ها را تنظیم کنید. نباید تشخیص اولیهٔ یک دستگاه را به‌طور خودکار به‌عنوان مجوز ارتقاء کل سایت تفسیر کرد. اگر اتصال افراد ناشناس، خروج داده‌های غیرمرتبط با وظیفه یا دسترسی افقی غیرعادی مشاهده شد، مسئول شیفت داخلی باید قادر باشد جلسهٔ مربوطه را متوقف کند، ضروری‌ترین سوابق را حفظ کند و بر اساس طرح پیش‌تعیین‌شده تصمیم بگیرد که آیا ادامه داده شود یا خیر.
قطع موقت و پایان وظیفه باید از هم جدا شوند. قطع اتصال شبکه لزوماً به معنای لغو حساب‌ها، دعوت‌های اتصال، مجوزهای شخص ثالث یا سایر جلسات ایجادشده نیست. قبل از اتصال مجدد، باید اطمینان حاصل شود که هنوز در پنجرهٔ تأییدشده هستید و هویت انجام‌دهنده و هدف اتصال دوباره بررسی شده است. اگر کار واقعی از یک شیفت به شیفت دیگر منتقل می‌شود، یادداشت‌های تحویل باید موارد تغییریافته، مواردی که نیاز به تأیید دارند و وضعیت فعلی دسترسی‌ها را به‌وضوح مشخص کنند تا شیفت بعدی تنها بر اساس عبارت «تأمین‌کننده هنوز در حال پردازش است» از کانال‌های نامشخص ادامه ندهد.
پذیرش نتایج بر اساس دو معیار: دسترسی و کسب‌وکار
پذیرش کسب‌وکاری بررسی می‌کند که آیا خرابی اولیه رفع شده و عملکرد ویژگی‌های مرتبط نیز طبیعی است یا خیر؛ پذیرش دسترسی بررسی می‌کند که آیا حساب‌های موقت، مجوزهای نقش، جلسات و دعوت‌های اتصال بر اساس قابلیت‌های هر سیستم، غیرفعال یا منقضی شده‌اند یا خیر. نباید تنها بر اساس پاسخ تأمین‌کننده «من خارج شدم» به عنوان پایان وظیفه عمل کرد. مدیران داخلی باید از سمت مدیریتی تأیید کنند و از یک حساب تست کنترل‌شده برای اطمینان از غیرقابل‌استفاده بودن مسیر دسترسی موقت استفاده کنند، نه اینکه از حساب‌های واقعی کارمندان برای آزمایش‌های مخرب استفاده شود.
ثبت پذیرش شامل شمارهٔ سفارش کار، انجام‌دهنده، تأییدکننده، تغییرات کلیدی، نتایج آزمون کسب‌وکاری، شواهد بازپس‌گیری دسترسی و موارد باقی‌مانده است. اعتبارهای بلندمدتی که نمی‌توان لغو کرد، حساب‌های اشتراکی داخلی دستگاه‌ها یا ابزارهای تعمیراتی آفلاین، باید به‌صورت جداگانه در لیست اصلاحی قرار گیرند و مسئول و زمان بازبینی برای هر کدام تعیین شود. بخش‌های انجام‌شده می‌توانند بسته شوند، اما نباید اتصال‌های باقی‌مانده را به‌عنوان بازپس‌گرفته‌شده ثبت کرد. خط پایهٔ پیکربندی پس از بازگرداندن نیز باید به‌روزرسانی شود تا پشتیبانی بعدی از اطلاعات منسوخ شروع نشود.
تشکیل یک روش پشتیبانی قابل تکرار از یک بار تعمیرات
می‌توان ابتدا سه سناریو را تمرین کرد: پایان عادی وظیفه در زمان تعیین‌شده، نیاز به تمدید تعمیرات و لغو فعال توسط مسئول داخلی پس از شناسایی ناهنجاری. بررسی کنید که آیا فرآیندهای تأیید، تعلیق، احیا و تحویل واقعاً توسط افرادی انجام می‌شوند یا خیر. برای تیم‌های بین‌المللی، همزمان منطقه‌های زمانی، کانال‌های ارتباطی و ترتیبات جایگزین نیز باید بررسی شوند. لازم نیست از ابتدا تمام تأمین‌کنندگان را پوشش دهید؛ ابتدا رایج‌ترین نوع تعمیرات را به یک فرآیند قابل تکرار تبدیل کنید و سپس بر اساس نقاط شکست واقعی گسترش دهید.
این روش برای محیط‌هایی که امکان محدودسازی یا حداقل نظارت بر دسترسی از راه دور وجود دارد، قابل اعمال است. برای دستگاه‌های کاملاً آفلاین، سیستم‌هایی که اجراي فیزیکی ضروری است یا کانال‌های قدیمی غیرقابل کنترل، باید از راهکارهای فیزیکی مربوطه استفاده شود و نمی‌توان ادعا کرد که کنترل مبتنی بر جلسه انجام شده است. نتیجهٔ نهایی باید یک نتیجهٔ بازیابی کسب‌وکار و یک سند پایان دسترسی باشد: دلیل باز کردن دسترسی، انجام‌دهنده، تغییرات اعمال‌شده، دسترسی‌های غیرفعال‌شده و مسائلی که همچنان نیازمند پیگیری مستمر هستند.