مقاله · تداوم کسب‌وکار
برنامه‌ریزی بازیابی فناوری اطلاعات پس از حادثه، گام‌به‌گام
برنامه بازیابی پس از حادثه پیش از آنکه موضوع فوری شود به یک پرسش پاسخ می‌دهد: اگر فردا سامانه‌هایمان از کار بیفتند، اول چه چیزی را، چگونه، توسط چه کسی و با چه سرعتی بازیابی می‌کنیم؟ این راهنما مراحل تدوین برنامه‌ای را مرور می‌کند که یک سازمان کوچک یا متوسط واقعاً بتواند آن را نگهداری و اجرا کند.
- تاریخ انتشار
- ۷ دقیقه مطالعه
در این صفحه
نکات کلیدی
- بازیابی پس از حادثه (DR) بخش فناوری اطلاعات تداوم کسب‌وکار است: بازگرداندن سامانهها و داده‌ها پس از یک اختلال.
- تحلیل اثر بر کسب‌وکار مشخص می‌کند کدام فرایندها مهم‌ترند و هر کدام تا چه مدت قطعی را تحمل میکنند.
- هدف زمان بازیابی (RTO) و هدف نقطه بازیابی (RPO) میزان تحمل کسب‌وکار را به اهداف فنی تبدیل میکنند.
- دستورالعملهای اجرایی (runbook) برنامه را به دستورهای گام‌به‌گامی تبدیل میکنند که فرد دیگری هم بتواند زیر فشار دنبال کند.
- تمرین‌های رومیزی و آزمایش‌های فنی بازیابی نشان میدهند برنامه کار می‌کند یا نه و آن را به‌روز نگه می‌دارند.
بازیابی پس از حادثه، تداوم کسب‌وکار و پاسخ به رخداد
این اصطلاحات با هم همپوشانی دارند، پس بهتر است از هم جدایشان کنیم. برنامه‌ریزی تداوم کسب‌وکار به این می‌پردازد که کل سازمان چگونه در طول اختلال به کار ادامه دهد: محل کار جایگزین، راهکارهای دستی، ترتیبات با تأمین‌کنندگان و ارتباطات. بازیابی پس از حادثه بخش فناوری این برنامه است: بازگرداندن سامانهها، برنامه‌ها و داده‌ها. پاسخ به رخداد هم به این می‌پردازد که چگونه یک رویداد امنیتی مانند باج‌افزار یا حساب نفوذشده را شناسایی، مهار و بررسی کنید.
در یک حمله سایبری هر سه هم‌زمان اجرا می‌شوند. پاسخ به رخداد تعیین می‌کند چه زمانی بازیابی امن است، بازیابی پس از حادثه بازگرداندن را انجام می‌دهد و برنامه تداوم کسب‌وکار در این فاصله خدمت‌رسانی به مشتریان را ادامه می‌دهد. یک برنامه بازیابی خوب به دو برنامه دیگر ارجاع می‌دهد، نه اینکه بخواهد جایگزینشان شود.
با تحلیل اثر بر کسب‌وکار شروع کنید
تحلیل اثر بر کسب‌وکار (BIA) گفت‌وگویی ساختاریافته با افرادی است که کسب‌وکار را اداره میکنند. این تحلیل پایه هر تصمیم بازیابی است.
فرایندهای حیاتی را فهرست کنید
فعالیت‌هایی را که درآمد ایجاد میکنند، به مشتریان خدمت میدهند یا تعهدات را برآورده میکنند شناسایی کنید؛ مانند صدور صورت‌حساب، حقوق و دستمزد، نوبت‌دهی، دسترسی به پرونده مشتریان و ایمیل.
وابستگی‌ها را ترسیم کنید
برای هر فرایند، برنامه‌ها، داده‌ها، دستگاهها، سرویس‌های شبکه، هویت‌ها و طرف‌های ثالثی را که به آن‌ها متکی است فهرست کنید. مواردی را که به‌راحتی فراموش می‌شوند هم بیاورید، مانند DNS، اتصال اینترنت، احراز هویت چندعاملی و پردازشگر پرداخت.
اثر را در طول زمان برآورد کنید
بپرسید بدون هر فرایند، پس از یک ساعت، یک روز و یک هفته چه اتفاقی می‌افتد؛ با در نظر گرفتن پیامدهای مالی، مشتریان، قراردادی، حقوقی و اعتباری.
آستانه‌های تحمل را تعیین کنید
درباره حداکثر زمان قابل تحمل قطعی برای هر فرایند و اینکه کسب‌وکار چه مقدار داده را می‌تواند دوباره وارد کند یا از دست بدهد توافق کنید.
رتبه‌بندی و تأیید
سامانهها را در سطوح بازیابی گروه‌بندی کنید و اولویتها را به تأیید مدیران برسانید، چون این اولویتها هم برنامه و هم بودجه را تعیین میکنند.
RTO و RPO به زبان عملی
هدف زمان بازیابی (RTO)
مدت زمانی که یک سامانه می‌تواند از دسترس خارج باشد پیش از آنکه اثرش غیرقابل قبول شود. RTO چهار ساعته یعنی روش بازیابی باید به‌طور واقع‌بینانه سامانه را ظرف چهار ساعت برگرداند، از جمله زمان لازم برای متوجه شدن مشکل و تصمیم به اقدام.
هدف نقطه بازیابی (RPO)
مقدار داده‌ای که، بر حسب زمان، می‌توانید از دست دادنش را بپذیرید. RPO یک‌ساعته مستلزم پشتیبان‌گیری یا تکثیر دستکم ساعتی است؛ پشتیبان‌گیری شبانه یعنی ممکن است تا یک روز کار از دست برود.
سطح‌بندی
همه سامانهها به اهداف یکسان نیاز ندارند. سطح ۱ ممکن است هویت، ایمیل و نرم‌افزار اصلی کسب‌وکار باشد؛ سطح ۳ ممکن است بایگانی‌هایی باشد که می‌توانند چند روز منتظر بمانند.
هزینه تابع اهداف است
RTO و RPO کوتاه‌تر، از راه تکثیر، زیرساخت آماده‌به‌کار یا خدمات سطح بالاتر، هزینه بیشتری دارند. تحلیل اثر بر کسب‌وکار به مدیران امکان می‌دهد با در نظر گرفتن این بده‌بستان اهداف را انتخاب کنند.
انتخاب راهبردهای بازیابی
وقتی اهداف تعیین شد، برای هر سطح یک روش بازیابی انتخاب کنید و مطمئن شوید می‌تواند به آن اهداف برسد.
- بازیابی از پشتیبان روی سخت‌افزار موجود یا جایگزین: کمترین هزینه، طولانی‌ترین زمان بازیابی، مناسب برای سطوح پایین‌تر.
- بازیابی یا انتقال به زیرساخت ابری: سکوهای پشتیبان‌گیری که می‌توانند سرورهای محافظت‌شده را در محیط ابری راه‌اندازی کنند، بدون نیاز به دفتر دوم زمان بازیابی را کوتاه میکنند.
- تکثیر به سامانه‌های آماده‌به‌کار: نسخه‌های تقریباً به‌روز که آماده اجرا هستند و در جایی به کار می‌روند که RTO و RPO کوتاه است.
- تاب‌آوری نرم‌افزار به‌عنوان سرویس: Microsoft 365 و دیگر سکوهای SaaS بازیابی زیرساخت را از برنامه شما حذف میکنند، اما همچنان به پشتیبان‌گیری داده، بازیابی هویت و برنامه‌ریزی دسترسی نیاز دارند.
- بازیابی در «اتاق تمیز» برای باج‌افزار: محیطی ایزوله که در آن سامانه‌های بازیابی‌شده پیش از اتصال دوباره اسکن و راستی‌آزمایی می‌شوند تا مهاجم را همراه با داده‌ها برنگردانید.
- راهکارهای دستی: فرم‌های کاغذی، زنجیره تماس تلفنی یا خروجی‌های فقط‌خواندنی که فرایندهای حیاتی را تا زمان بازیابی سامانهها در جریان نگه می‌دارند.
نوشتن دستورالعملهای اجرایی که بشود دنبالشان کرد
دستورالعمل اجرایی (runbook) روندی گام‌به‌گام برای بازیابی یک سامانه مشخص یا رسیدگی به یک سناریوی مشخص است. باید برای یک تکنسین شایسته که هرگز به آن سامانه دست نزده، در ساعت دو بامداد و زیر فشار، قابل استفاده باشد. یعنی محل دقیق پشتیبان‌ها، حساب‌ها و جایی که اعتبارنامه‌هایشان نگهداری می‌شود، ترتیب عملیات، روش راستی‌آزمایی موفقیت و اینکه اگر گامی شکست خورد با چه کسی تماس بگیرید.
ترتیب اهمیت دارد. معمولاً هویت اول می‌آید، چون بدون حساب‌های مدیریتی و MFA کارا، هیچ چیز دیگری قابل مدیریت نیست. سپس شبکه و DNS، بعد داده‌ها و برنامه‌های اصلی و پس از آن سامانه‌های سطوح پایین‌تر. وابستگی‌ها را صریح ثبت کنید تا کسی یک ساعت صرف بازیابی برنامه‌ای نکند که سرور پایگاه‌داده‌اش هنوز برنگشته است.
دستورالعمل‌ها را جایی نگه دارید که در زمان حادثه در دسترس بمانند: نسخه چاپی، نسخه آفلاین رمزگذاریشده یا مکان ابری جداگانه‌ای که به تنت اصلی شما وابسته نیست. فهرست تماس به‌روزی از کارکنان، ارائه‌دهنده فناوری اطلاعات، شرکت‌های اینترنت و تلفن، فروشندگان نرم‌افزارهای کلیدی، بیمه‌گر سایبری و بانک خود را ضمیمه کنید.
نقشها و ارتباطات
نقشها را روشن تعیین کنید: مسئول رخداد که تصمیم میگیرد، مسئول فنی که بازیابی را هدایت می‌کند، مسئول ارتباطات که کارکنان، مشتریان و تأمین‌کنندگان را در جریان می‌گذارد و یک نفر که تصمیم‌ها و زمان‌ها را ثبت می‌کند. در یک کسب‌وکار کوچک ممکن است یک نفر بیش از یک نقش داشته باشد، اما هر نقش باید یک جانشین مشخص داشته باشد.
از پیش قالب‌های پیام برای کارکنان، مشتریان و تأمین‌کنندگان آماده کنید و توافق کنید اگر ایمیل و Teams در دسترس نبودند از چه کانال‌هایی استفاده می‌کنید. در یک رخداد امنیتی، پیش از هر اظهارنظر بیرونی با بیمه‌گر و مشاوران حقوقی خود مشورت کنید، چون نحوه بیان هم برای تعهدات حریم خصوصی و هم برای ادعای بیمه می‌تواند مهم باشد.
برنامه را با تمرین‌های رومیزی و مانورهای فنی آزمایش کنید
برنامه‌ای که آزمایش نشده فقط یک فرضیه است. دو نوع آزمایش مکمل یکدیگرند.
تمرین رومیزی
تصمیم‌گیرندگان را برای یک یا دو ساعت دور هم جمع کنید و یک سناریوی واقع‌بینانه را مرور کنید، مانند کشف باج‌افزار در صبح دوشنبه یا آتش‌سوزی‌ای که دفتر را تعطیل می‌کند. یک تسهیل‌گر رویدادهای تازه را مطرح می‌کند و گروه با استفاده از برنامه درباره تصمیم‌ها گفت‌وگو می‌کند. شکاف‌ها به‌سرعت آشکار می‌شوند: تماس‌های جاافتاده، اختیارات نامشخص، فرض‌های نادرست درباره پشتیبان‌ها.
آزمایش فنی بازیابی
یک سامانه را واقعاً از پشتیبان در محیطی ایزوله بازیابی کنید و زمانش را با RTO مقایسه کنید. با یک کاربر کسب‌وکار تأیید کنید که داده‌ها کامل‌اند و برنامه کار می‌کند.
بازبینی پس از اقدام
ثبت کنید چه چیزی کار کرد، چه چیزی نه و چه کسی تا چه زمانی هر شکاف را برطرف می‌کند. دستورالعمل‌ها را بی‌درنگ، تا وقتی جزئیات در ذهن تازه است، به‌روز کنید.
نگهداری
برنامه را دستکم سالی یک بار و پس از تغییرات مهم بازبینی کنید؛ مانند برنامه جدید، جابه‌جایی دفتر، تغییر ارائه‌دهنده یا جابه‌جایی کارکنان در نقش‌های کلیدی.
بیمه‌نامه سایبری خود را بررسی کنید
بسیاری از بیمه‌نامه‌های سایبری برای نحوه رسیدگی به رخدادها شرایطی تعیین میکنند، مانند اطلاع‌رسانی فوری به بیمه‌گر و استفاده از شرکت‌های پاسخ‌دهنده مورد تأیید. بیمه‌نامه خود را بخوانید و الزامات آن را در برنامه منعکس کنید تا تصمیم‌های بازیابی پوشش بیمه را به خطر نیندازند.
پرسش‌های متداول
برنامه بازیابی پس از حادثه چقدر باید طولانی باشد؟
به اندازهای که قابل استفاده باشد و نه بیشتر. بسیاری از کسبوکارهای کوچک با یک سند کوتاه شامل اولویتها، نقشها و تماسها، بهعلاوه دستورالعملهای اجرایی جداگانه برای هر سامانه حیاتی، بهخوبی کار میکنند.
تفاوت RTO و RPO چیست؟
RTO یعنی یک سامانه با چه سرعتی باید بازیابی شود. RPO یعنی چه مقدار از دادههای اخیر را می‌توانید از دست بدهید. ممکن است سامانه‌ای باید ظرف یک روز برگردد اما بیش از یک ساعت داده از دست ندهد.
اگر همهچیز ما در Microsoft 365 است، باز هم به برنامه بازیابی نیاز داریم؟
بله، هرچند سادهتر خواهد بود. همچنان باید از دادههای حذفشده یا رمزگذاریشده، حساب مدیریتی نفوذشده، از دست رفتن دستگاهها یا قطعی اینترنت بازیابی کنید و باید بدانید چه کسی تصمیم میگیرد و کارکنان چگونه به کار ادامه میدهند.
هر چند وقت یک بار باید تمرین رومیزی برگزار کنیم؟
دستکم سالی یک بار برای بیشتر سازمانهای کوچک و متوسط آهنگ معقولی است، بهعلاوه یک تمرین اضافه پس از تغییرات بزرگ در سامانهها، ارائهدهندگان یا کارکنان کلیدی.
خدمات مرتبط
محصولات و بسته‌ها
برنامه بازیابی‌ای بسازید که بتوانید آزمایشش کنید
می‌توانیم تحلیل اثر بر کسب‌وکار را تسهیل کنیم، اهداف بازیابی واقع‌بینانه تعیین کنیم، برای سامانه‌های حیاتی شما دستورالعمل اجرایی بنویسیم و یک تمرین رومیزی با تیم مدیریتی‌تان برگزار کنیم.