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