JOTO GLOBAL
→ بینش‌ها

هشدار ارسال شد؛ سازمان چگونه پذیرش مسئولیت و بازیابی را تأیید کند؟

اعلان، پذیرش، ارجاع، تلاش محدود و پذیرش کاری را به فرایند بازیابی قابل اجرا متصل کنید.

هشدار ارسال شد؛ سازمان چگونه پذیرش مسئولیت و بازیابی را تأیید کند؟

از یک هشدار مؤثر بر کسب‌وکار آغاز کنید

فرض کنید شبکه یک شعبه شبانه دچار اختلال دسترسی می‌شود. پایش به فردی پیام می‌دهد که دیگر در آن نقش نیست و تیم کشیک صبح متوجه می‌شود. این مثال فرضی فرایند است، نه نمونه مشتری. تحویل موفق پیام انجام یک مرحله اعلان را ثابت می‌کند، نه پذیرش مسئولیت بازیابی. JOTOglobal پیشنهاد می‌کند از یک خدمت با اثر کاری روشن آغاز و مسیر کشف، پذیرش، ارزیابی، اقدام و تأیید بازیابی ترسیم شود.

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

هدف بازیابی و تمرین را وارد فرایند کنید

NIST SP 800-34 Rev.1 تحلیل اثر کسب‌وکار، راهبرد بازیابی و آزمون، آموزش و تمرین را در برنامه‌ریزی تداوم بررسی می‌کند. برای هر هشدار شرکت مهلت پاسخ تعیین نمی‌کند و خرید نرم‌افزار پایش توان بازیابی را ثابت نمی‌کند. این مقاله اصول برنامه‌ریزی و تأیید را در تحویل خرابی خدمت به کار می‌برد. طراحی پذیرش، ارجاع و مدارک پیشنهاد مستقل JOTOglobal است، نه تکلیف قانونی یکسان ناشی از راهنمای فدرال آمریکا.

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

اعلان باید به کار قابل تحویل مرتبط باشد

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

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

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

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

بازیابی خودکار فقط اقدام از پیش تأییدشده، محدود و دارای نتیجه قابل‌سنجش را اجرا و تعداد و بسامد تلاش را محدود کند. پیش از راه‌اندازی مجدد، تغییر ورودی یا اجرای دوباره، کار فعال، ارسال تکراری و احتمال گسترش خرابی بررسی شود. علت، هدف، نتیجه اجرا و تأیید بازیابی هر اقدام ثبت شود. در شرط توقف، وضعیت حفظ و کار به انسان سپرده شود؛ تا ظاهر شدن موقت چراغ سبز بی‌پایان تلاش نکنید.

پذیرش بازیابی به مسیر کسب‌وکار بازگردد

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

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

با تمرین خلأ تحویل و پوشش را پیدا کنید

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

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

منابع

NIST SP 800-34 Rev.1: Contingency Planning Guide for Federal Information Systems