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

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

قاعده‌ی ۳-۲-۱-۱-۰

قاعده‌ی قدیمی ۳-۲-۱ برای خرابی دیسک و آتش‌سوزی طراحی شده بود. در برابر باج‌افزار دو عدد دیگر هم لازم است:

  • ۳ نسخه از داده‌ها: نسخه‌ی اصلی و دو پشتیبان
  • ۲ نوع رسانه‌ی متفاوت، مثلاً دیسک و نوار، یا دو سامانه‌ی ذخیره‌سازی جدا
  • ۱ نسخه بیرون از محل
  • ۱ نسخه‌ی آفلاین یا تغییرناپذیر، که نشود از روی شبکه پاکش کرد
  • ۰ خطا در آزمون بازیابی

دو عدد آخر همان‌هایی است که بیشتر سازمان‌ها ندارند.

نسخه‌ی تغییرناپذیر یعنی چه

نسخه‌ای که حتی مدیر سیستم هم تا پایان یک مدت مشخص نتواند پاک یا بازنویسی کند. چند راه رایج:

  • ذخیره‌سازی object با قابلیت قفل (Object Lock) در حالتی که حتی مدیر هم نتواند قفل را بردارد
  • نوار یا دیسکی که پس از پشتیبان‌گیری از سامانه جدا و در جای دیگری نگه داشته می‌شود
  • مخزن پشتیبانی که فقط اجازه‌ی افزودن می‌دهد و حذف در آن، تأخیر و تأیید جداگانه می‌خواهد

خطاهایی که پشتیبان را بی‌اثر می‌کند

  1. سرور پشتیبان عضو دامنه است. مهاجمی که ادمین دامنه شده، به سرور پشتیبان هم دسترسی دارد. سامانه‌ی پشتیبان باید حساب‌ها و رمزهای خودش را داشته باشد.
  2. مقصد پشتیبان یک پوشه‌ی اشتراکی باز است. هر سروری که بتواند در آن بنویسد، باج‌افزارش هم می‌تواند.
  3. snapshot روی همان ذخیره‌سازی نگه داشته می‌شود. snapshot برای برگرداندن یک فایل عالی است، اما اگر کنسول ذخیره‌سازی در دست مهاجم باشد، snapshotها هم از بین می‌روند.
  4. فقط از داده پشتیبان گرفته شده، نه از پیکربندی. بازیابی بدون پیکربندی فایروال، اکتیو دایرکتوری و زیرساخت مجازی‌سازی، روزها طول می‌کشد.
  5. کلید رمزگذاری پشتیبان روی همان سرور است. کلید را جدا نگه دارید؛ پشتیبان رمزگذاری‌شده بدون کلیدش بی‌فایده است.

آزمون بازیابی

پشتیبانی که بازیابی‌اش امتحان نشده، فقط یک امید است. دست‌کم هر سه ماه یک بار:

  1. یک سرور کامل را در محیطی جدا از صفر بازیابی کنید، نه فقط یک فایل.
  2. زمان کل کار را اندازه بگیرید و با مدت قطعی‌ای که سازمان تحمل می‌کند (RTO) مقایسه کنید.
  3. ببینید آخرین نسخه‌ی سالم چقدر قدیمی است و چه مقدار داده از دست می‌رود (RPO).
  4. نتیجه را ثبت کنید، حتی اگر همه‌چیز درست پیش رفت.
اولین بازیابی کامل را در روز حادثه انجام ندهید. آن روز باید دومین یا دهمین بار باشد.

جمع‌بندی

از خودتان بپرسید: اگر مهاجمی امروز ادمین دامنه شود، می‌تواند پشتیبان‌ها را پاک کند؟ اگر جواب «بله» یا «نمی‌دانم» است، یک نسخه‌ی آفلاین یا تغییرناپذیر و یک آزمون بازیابی کامل، دو کار این ماه شماست. و اگر نمی‌دانید مهاجم چقدر در شبکه بوده، لاگ متمرکز اولین جایی است که باید جوابش را پیدا کنید.