تداوم و بازیابی: بازگردانی که هیچ‌کس آن را آزمایش نکرد

هر داشبورد پشتیبان‌گیری علامت‌های سبز نمایش می‌دهد. کارها تکمیل شدند، سیاست نگهداری رعایت شد، فضای ذخیره‌سازی مطابق انتظار استفاده شد. هیچ‌یک از این‌ها نمی‌گوید که آیا می‌توانید یک domain controller را از bare metal در کمتر از چهار ساعت طی یک حادثه واقعی برگردانید. شکاف بین "پشتیبان‌گیری موفق" و "بازگردانی موفق" همان جاست که بیشتر طرح‌های تداوم به‌خاموشی ناکام می‌شوند.

چرا علامت دروغ می‌گوید

نرم‌افزار پشتیبان‌گیری زمانی موفقیت را گزارش می‌کند که نوشتن بایت‌ها به یک مقصد را تمام کند. نمی‌داند آن بایت‌ها قابل استفاده هستند یا نه. یک پشتیبان‌گیری SQL Server می‌تواند به‌صورت تمیز تکمیل شود و باز هم غیرقابل‌بازگردانی باشد زیرا زنجیره transaction log سه روز پیش شکست و هیچ‌کس متوجه نشد. عکس‌های لحظه‌ای VM می‌توانند در کنسول خوب به‌نظر برسند در حالی که writer VSS زیرین به‌خاموشی در درون guest OS ناکام شد، و تصویر crash-consistent (نه application-consistent) تولید کرد.

اپراتورهای باجافزار این را می‌دانند. گروه‌هایی که playbook‌های سبک Conti را در حوادث گذشته اجرا کردند، عمداً بر زیرساخت پشتیبان‌گیری هدف قرار دادند — shadow copy‌ها را با vssadmin delete shadows /all /quiet حذف کردند، مخازن Veeam را غیرفعال کردند، اهداف پشتیبان‌گیری بر پایه NAS را که از طریق SMB قابل‌دسترسی بودند رمزگذاری کردند. اگر پشتیبان‌گیری‌های شما در همان بخش شبکه و با اعتبارنامه‌های دامنه‌ای که می‌توانند آن‌ها را لمس کنند همراه تولید قرار دارند، آن‌ها هدف هستند، نه شبکه ایمنی.

یک runbook بازگردانی بسازید، نه سیاست پشتیبان‌گیری

طرح تداوم باید دستورالعمل‌های بازگردانی گام‌به‌گام داشته باشد که برای شخصی نوشته‌شده باشد که معمولاً این کار را انجام نمی‌دهد. یادداشت کنید:

• ترتیب بازیابی دقیق (domain controller‌ها و DNS اول، سپس برنامه‌های اصلی، سپس بقیه)
• جایی که اعتبارنامه‌های کنسول پشتیبان‌گیری زندگی می‌کنند اگر vault رمزعبور شما نیز خراب شده باشد
• دستور بازگردانی دقیق یا مسیر کنسول، نه "از Veeam برای بازگردانی VM استفاده کنید"
• مدت زمان مورد انتظار برای هر سیستم، بر اساس آزمایش‌های واقعی اندازه‌گیری‌شده، نه اعداد تبلیغاتی فروشنده

برای Veeam Backup & Replication، این به‌معنی مستندسازی مراحل واقعی است: کنسول را باز کنید، به Backups > Disk بروید، روی نقطه بازگردانی راست‌کلیک کنید، Instant VM Recovery یا Full VM Restore را بسته به سناریو انتخاب کنید، و میزبان هدفی را با ظرفیت آزاد کافی انتخاب کنید. اگر میزبان اولیه شما نیز توسط حملات دچار آسیب شده باشد، باید یک میزبان دوم جدا و ایزوله‌شده از قبل شناسایی و مجاز شده باشد.

بازگردانی‌های آزمایشی را در یک زمانبندی انجام دهید، نه به‌صورت تصادفی

یک چرخش انتخاب کنید. هر ماه، یک سیستم حیاتی را به یک VLAN جدا‌شده بازگردانید و بررسی کنید که بوت شود، احراز هویت شود، و داده را به‌صورت صحیح ارائه دهد. هر سه ماه، یک آزمایش تمام‌سطح اجرا کنید: domain controller، file server، و پایگاه داده اولیه خود را به زیرساخت جدا‌شده بازگردانید، سپس کسی خارج از تیم پشتیبان‌گیری سعی کند وارد شود و گزارش بکشد.

برای پایگاه‌داده‌ها، فقط فایل .bak را بازگردانید نه — تأیید کنید:

RESTORE VERIFYONLY FROM DISK = 'D:\Backups\prod_2024.bak'

سپس واقعاً آن را به یک نمونه آزمایشی بازگردانید و DBCC CHECKDB را علیه آن اجرا کنید. یک پشتیبان‌گیری که VERIFYONLY را پاس کند می‌تواند هنوز حاوی خرابی منطقی باشد که فقط زمانی ظاهر می‌شود که شما آن را جستجو کنید.

برای سیستم‌های Linux که از چیزی مثل Bacula یا restic استفاده می‌کنند، مسیر بازگردانی واقعی را آزمایش کنید:

restic restore latest --target /tmp/restore-test --repo /mnt/backup-repo

سپس فایل‌های پیکربندی بازگردانی‌شده را با تولید مقایسه کنید تا تأیید کنید که هیچ‌چیز به‌خاموشی ریخته نشده است.

کپی‌های غیرقابل تغییر و قانون 3-2-1-1

قانون کلاسیک 3-2-1 (سه کپی، دو نوع رسانه، یک نسخه خارج‌از‌سایت) به‌روز نیاز دارد برای عصر باجافزار: 3-2-1-1، جایی که "1" اضافی یک کپی غیرقابل‌تغییر یا air-gapped است. Object lock روی فضای ذخیره‌سازی سازگار S3 (Wasabi، Backblaze B2، یا AWS S3 با Object Lock فعال) حذف یا اصلاح را برای یک پنجره نگهداری تعریف‌شده جلوگیری می‌کند، حتی توسط حسابی با اعتبارات admin. آن را با تنظیم کنید:

aws s3api put-object-lock-configuration \
  --bucket backup-vault \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

حالت COMPLIANCE به‌معنی اینکه هیچ‌کس، از جمله حساب ریشه، نمی‌تواند نگهداری را کوتاه‌تر کند یا اشیاء را زودتر حذف کند. این وقتی مهم است که مهاجم دارای admin دامنه باشد.

RTO و RPO را با اعداد واقعی اندازه‌گیری کنید، نه حدس

Recovery Time Objective و Recovery Point Objective تا زمانی که یک executive پرسید "چقدر داده را از دست می‌دهیم و چقدر وقت خاموش هستیم" مانند تمرین‌های کاغذی به‌نظر می‌رسند. سه آزمایش بازگردانی آخر خود را وقت بگذارید. اگر هدف RPO شما یک ساعت است اما کار پشتیبان‌گیری فقط هر شش ساعت اجرا شود، شما یک شکاف مستندسازی‌شده دارید، و بهتر است آن شکاف را در یک تمرین tabletop پیدا کنید تا طی یک رویداد رمزگذاری واقعی ساعت 2 بامداد روز شنبه.

آزمایش را اجرا کنید، زمان واقعی ساعت را یادداشت کنید، و آن را با آنچه در سند بازیابی فاجعه قول دادید مقایسه کنید. تفاوت بین این دو عدد وضعیت واقعی طرح تداوم شما است.

برای اطلاعات بیشتر درباره تقویت سیستم‌هایی که از آن‌ها محافظت می‌کنید و ایجاد گردش‌های پاسخ حادثه، بخش‌های Blue Team و Digital Forensics مرتبط در Korra Studio را بررسی کنید.