قرار دادن یک ارتقا در جریان کارهای واقعی محل
فرض کنید یک ساختمان اداری قصد دارد نرم‌افزار گروهی از تجهیزات سیستم دسترسی را به‌منظور رفع مشکلات تأییدشده‌ای به‌روزرسانی کند. کارشناسان تست شماره نسخه به‌روزرسانی‌شده را مشاهده می‌کنند، اما پذیرش‌دهنده نگران این است که پرسنل شیفت شب نتوانند وارد شوند و تیم تأسیسات نیز باید سازگاری با کنترلرهای موجود را تأیید کند. این یک سناریوی فرضی است و نشان‌دهنده خرابی واقعی هیچ محصول خاصی نیست. تغییرات سیستم دسترسی تنها بر رابط مدیریتی تأثیر نمی‌گذارند، بلکه بر عبور عادی افراد، ارتباط محلی و اینکه در شرایط غیرعادی چه کسی مسئولیت اقدام را بر عهده دارد نیز تأثیر می‌گذارند؛ بنابراین تأیید نباید تنها به بازگشت دستگاه به وضعیت آنلاین محدود شود.
شرکت JOTOglobal پیشنهاد می‌کند که ابتدا روی یک دستگاه نماینده با تأثیر کنترل‌شده شروع شود و اهداف ارتقا، افراد مجازکننده، مجریان، مشاهده‌کنندگان محلی و شرایط توقف به‌وضوح تعیین گردند. دستگاه نمایشی روی جلد صرفاً به‌عنوان نمایش سخت‌افزاری است و نشان‌دهنده پشتیبانی از تمامی عملیات مطرح‌شده در این متن نیست. قابلیت‌های واقعی ارتقا، بازگشت به نسخه قبلی و پشتیبان‌گیری باید بر اساس مدل دقیق، نسخه سخت‌افزاری و مسیرهای صریحاً پشتیبانی‌شده توسط سازنده بررسی شوند و نباید از پشتیبانی دستگاه‌های سری دیگر برای استنباط پشتیبانی دستگاه فعلی استفاده شود.
ابتدا مبنای تغییر و وابستگی‌ها را تأیید کنید
استاندارد NIST SP 800-53 Rev.5 شامل کنترل تغییر پیکربندی (CM-3) و رفع نقص (SI-2) می‌شود و به‌عنوان مرجعی برای مدیریت تغییرات عمل می‌کند، اما مراحل عملیاتی فرم‌ور (firmware) را برای تمامی تجهیزات سیستم دسترسی تعریف نمی‌کند. فرم‌بررسی محلی، تقسیم وظایف و روش‌های شبیه‌سازی ارائه‌شده در این متن، پیشنهادات مستقل JOTOglobal هستند. سازمان‌ها باید نحوه اجرای این اقدامات را با توجه به مسئولیت‌های امنیتی، مقررات محلی و اسناد سازنده تعیین کنند و استفاده از این فهرست را نباید معادل دستیابی به گواهینامه یا تأمین تمامی الزامات امنیتی ساختمان دانست.
مسئول سیستم ابتدا منبع بسته ارتقا، مدل‌های قابل‌اجرا، نسخه سخت‌افزاری، نسخه فعلی نرم‌افزار، نسخه هدف و محدودیت‌های شناخته‌شده را بررسی می‌کند. دستورالعمل‌های منتشرشده مربوط به این نسخه را مطالعه کرده و اطمینان حاصل می‌کند که تغییراتی در قالب داده‌ها، گواهی‌ها، رابط‌ها یا سازگاری با پلتفرم مدیریت ایجاد نشده است. بسته ارتقا باید از کانال رسمی سازنده که توسط سازمان تأیید شده است، دریافت شود و تمامیت فایل آن باید با روش‌های ارائه‌شده توسط سازنده بررسی شود؛ موفقیت این بررسی تنها نشان می‌دهد که فایل با معیار بررسی مربوطه مطابقت دارد و به‌طور خودکار تأیید‌کننده سازگاری محلی نیست.
کنترلرها، خواننده‌ها، پلتفرم مدیریت، همگام‌سازی داده‌های هویتی، شبکه و تأمین برق را به‌صورت لیستی از وابستگی‌ها ثبت کنید. مسئول تأسیسات باید مشخص کند کدام درها با فرآیندهای اضطراری محلی مرتبط هستند و مسئول کسب‌وکار باید پنجره نگهداری قابل‌قبول را تأیید کند. در صورت وجود ارتباط با سیستم‌های اعلام حریق، تخلیه اضطراری یا سایر سیستم‌های امنیتی، باید تیم‌های مسئول و صلاحیت‌دار طبق الزامات محلی اقدام کنند؛ این متن هیچ دستورالعملی برای تغییر این مکانیزم‌های حفاظتی ارائه نمی‌دهد و غیرفعال کردن این حفاظت‌ها برای انجام ارتقا را توصیه نمی‌کند.
پشتیبان‌گیری و بازگشت به نسخه قبلی باید از نظر قابلیت اجرا تأیید شوند
قبل از اجرا، پیکربندی‌های ضروری که توسط سازنده قابل صادر شدن هستند، ذخیره شوند و اطلاعاتی از جمله دستگاه مربوطه، زمان، نسخه و محل ذخیره‌سازی ثبت گردد و دسترسی به آن محدود شود. پیکربندی‌ها ممکن است شامل شناسه افراد، اطلاعات شبکه یا اعتبارنامه‌ها باشند و نباید به‌صورت مستقیم در تیکت‌های عمومی آپلود شوند. اگر محیط تست قانونی و قابل‌استفاده‌ای وجود داشته باشد، باید قابلیت خواندن پشتیبان و شرایط لازم برای بازیابی آن بررسی شود. وجود یک نام فایل پشتیبان به‌تنهایی کافی نیست تا اطمینان حاصل شود که پس از خرابی دستگاه بازیابی امکان‌پذیر است.
طرح بازگشت باید بین سه مسیر بازیابی پیکربندی، بازگشت به نسخه قدیمی و جایگزینی با دستگاه اضافی تمایز قائل شود. برخی به‌روزرسانی‌ها ممکن است ساختار داده‌ها را تغییر دهند یا بازگشت به نسخه قبلی را ممنوع کنند و باید بر اساس پشتیبانی واقعی توضیح داده شوند. اگر بازگشت به نسخه اصلی امکان‌پذیر نباشد، نباید در برنامه عبارت «بازگشت یک‌کلیکی» ذکر شود؛ بلکه می‌توان از دستگاه اضافی تأییدشده یا راهکار پشتیبانی محلی استفاده کرد و به‌صراحت ثبت کرد که زمان بازیابی هنوز تأیید نشده است. در صورت عدم وجود مسیر بازیابی قابل‌قبول، باید ابتدا شرایط لازم فراهم شود و سپس تصمیم به گسترش تغییر در محیط تولید گرفته شود.
در پنجره اجرا همزمان اقدامات فنی و مشاهده محلی را برنامه‌ریزی کنید
قبل از ارتقا، مسئول محل اطمینان حاصل کند که اطلاع‌رسانی به افراد مربوطه انجام شده، ترتیبات عبور موقت مطابق با مقررات موجود است و در صورت بروز امری غیرعادی، امکان تماس با پشتیبان شیفت فراهم است. مجری فنی مراحل تأییدشده را اجرا می‌کند و مشاهده‌کننده وضعیت دستگاه، زمان و تأثیرات واقعی را ثبت می‌کند. در صورت مشاهده قطع ارتباط، راه‌اندازی مکرر یا ناهنجاری داده‌ها که با پیش‌بینی متفاوت باشد، اجرای اقدامات متوقف و به سطح بالاتر ارجاع داده می‌شود؛ نباید به‌دلیل نزدیک شدن به پایان پنجره نگهداری، مراحل جدید و تأییدنشده را به‌صورت مکرر امتحان کرد.
شناسه بسته ارتقا، زمان شروع و پایان، تغییرات وضعیت دستگاه و نتیجه اجرا ثبت شود و لاگ‌های ضروری در مکانی کنترل‌شده ذخیره گردند. پس از ارتقا، ابتدا نسخه و پیکربندی بررسی شود، سپس اتصال مدیریتی، همگام‌سازی داده‌های هویتی و ثبت رویدادها بررسی گردد. تشخیص دستگاه توسط پلتفرم و عملکرد صحیح عبور فیزیکی دو نتیجه متفاوت هستند؛ نباید اتصال شبکه یا قابلیت دسترسی به صفحه مدیریتی جایگزین تأیید عملکرد کسب‌وکاری شود.
تست محلی با هویت‌های مجاز و محدوده عملیاتی مشخص انجام می‌شود. بررسی می‌شود که هویت‌های معتبر در بازه زمانی تأییدشده و مطابق قوانین موجود قادر به عبور هستند، هویت‌های نامعتبر یا لغوشده همچنان رد می‌شوند و زمان و نتیجه رویدادهای مربوطه به‌درستی ثبت می‌شوند. برای تست نباید مجوزهای واقعی افراد به‌صورت موقت گسترش یابد و نباید از شبیه‌سازی برای تغییر قفل‌ها، ارتباط اضطراری یا ترتیبات تخلیه استفاده شود. پروژه‌های دارای مکانیزم‌های عبور ویژه باید توسط تیم‌های تخصصی مربوطه تأیید و مرزهای آن ثبت گردد.
بازیابی در صورت شکست نیز باید در تأیید گنجانده شود
در شرایطی امن، تأییدشده و بدون تأثیر بر حفاظت‌های محلی، پردازش قطع اتصال نگهداری و انتقال پشتیبانی به تیم جایگزین بررسی شود. اجرای واقعی بازگشت به نسخه قبلی یا جایگزینی دستگاه باید بر اساس پشتیبانی سازنده و ارزیابی ریسک محلی تصمیم‌گیری شود؛ نباید با خراب کردن تجهیزات تولیدی، قابلیت بازگشت را اثبات کرد. اگر تنها اسناد بازیابی بررسی شده و تست عملی انجام نشده باشد، در ثبت تأیید باید صریحاً ذکر شود: «بررسی اسناد انجام شده، اما اجرای عملیات تأیید نشده است» تا برنامه‌ریزی با شواهد واقعی اشتباه گرفته نشود.
فهرست تأیید باید به‌صورت جداگانه وضعیت فنی، عبور عادی، رد دسترسی، کامل‌بودن لاگ‌ها و موارد باقی‌مانده را فهرست‌بندی کند و مسئولان مربوطه نتیجه را امضا کنند. در صورت مشاهده ناهنجاری، محدوده تأثیر، اقدامات موقت و زمان تست مجدد بعدی باید ذکر شود. تنها بخش‌هایی که تست شده‌اند می‌توانند به‌عنوان «تأییدشده» اعلام گردند. به‌ویژه نباید از نتایج تست دستگاه‌های دیگر به‌جای تست دستگاه فعلی استفاده شود و نباید به‌دلیل عملکرد صحیح در ساعت‌های روز، بررسی قوانین مربوط به شیفت شب نادیده گرفته شود.
پس از داشتن شواهد، گسترش به دسته‌های بعدی را آغاز کنید
پس از تکمیل دستگاه اول، یک پنجره مشاهده را در نظر بگیرید که با شرایط واقعی کار همخوانی داشته باشد، سپس بر اساس مدل دستگاه، مکان و وابستگی‌ها به‌صورت دسته‌بندی اقدام کنید. هر دسته باید لیست دستگاه‌های قابل‌ردیابی و سوابق تغییر را داشته باشد تا در صورت بروز خرابی، بتوان به‌سرعت تشخیص داد کدام دستگاه‌ها به‌روزرسانی شده‌اند و کدام‌ها هنوز در وضعیت اولیه باقی مانده‌اند. بین دسته‌ها روند ناهنجاری‌ها را بررسی کنید؛ در صورت مشاهده مشکل مشترک، گسترش به دسته‌های بعدی را فوراً متوقف کنید و اجازه ندهید تمامی محل‌ها همزمان وارد وضعیتی شوند که نیاز به مداخله دستی داشته باشند.
پس از تکمیل تغییر، لیست تجهیزات، خط پایه نسخه‌ها، محل پشتیبان‌گیری و اطلاعات تماس پشتیبانی را به‌روزرسانی کنید و دسترسی‌های موقت نگهداری را غیرفعال کنید. این متن جایگزین دفترچه راهنمای سازنده، مقررات امنیتی محلی یا تأیید حرفه‌ای سیستم‌های مرتبط نیست. نتیجه قابل‌تحویل، یک تغییر مبتنی بر شواهد، قابل‌ردیابی و با مرزهای بازیابی مشخص است: می‌دانیم چرا ارتقا انجام شده، کدام قابلیت‌ها تست شده‌اند، کدام شرایط هنوز تأیید نشده‌اند و در صورت بروز امری غیرعادی، چه کسی مسئول بازگرداندن وضعیت عادی محل است.