قابلیت بازیابی اطلاعات؛ Backup امن در برابر حادثه و باج‌افزار

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

برای همین باید به Backup فقط به‌عنوان کپی اطلاعات نگاه نکرد. هدف اصلی، قابلیت بازیابی است؛ یعنی بدانیم چه چیزی، با چه فاصله زمانی، در چه مدت و با چه سطحی از اطمینان قابل برگشت است.

Backup و Recovery یکی نیستند

Backup یعنی داشتن نسخه‌ای از داده یا تنظیمات. Recovery یعنی توانایی برگرداندن سرویس به حالت قابل استفاده. ممکن است Backup وجود داشته باشد، اما Recovery به‌دلیل نبود تست، نبود مستندات یا وابستگی‌های فراموش‌شده شکست بخورد.

• RPO: حداکثر میزان داده‌ای که از دست رفتنش قابل قبول است.
• RTO: حداکثر زمانی که سرویس می‌تواند از دسترس خارج باشد.
• Restore Test: تست واقعی برگشت اطلاعات، نه فقط موفق بودن Job بکاپ.

تهدید باج‌افزار؛ Backup معمولی کافی نیست

در حملات باج‌افزاری، مهاجم معمولاً فقط سرورها را رمزگذاری نمی‌کند؛ اگر بتواند، سراغ Backupها هم می‌رود. اگر Backup روی همان شبکه، با همان Credentialها و بدون محدودیت نگهداری شود، احتمالاً در حادثه اصلی هم از بین می‌رود.

برای کاهش این ریسک، باید حداقل یک نسخه Backup به‌صورت Offline، Immutable یا خارج از دسترسی مستقیم ادمین‌های روزمره نگهداری شود. مدل 3-2-1 هنوز هم نقطه شروع خوبی است: سه نسخه از داده، روی دو نوع ذخیره‌سازی، و یک نسخه خارج از سایت یا خارج از دسترس مستقیم.

چه چیزهایی باید Backup شوند؟

فقط فایل‌های کاربران مهم نیستند. در شبکه و امنیت، خیلی از زمان بازیابی صرف بازسازی تنظیمات و وابستگی‌ها می‌شود. بهتر است این موارد هم در برنامه Backup دیده شوند:

• دیتابیس‌ها و فایل‌های سرویس‌های اصلی.
• تنظیمات فایروال، روتر، سوئیچ، VPN و Load Balancer.
• تنظیمات Active Directory، DNS، DHCP و Certificateها.
• اسکریپت‌ها، فایل‌های پیکربندی و مستندات عملیاتی.
• لیست وابستگی سرویس‌ها و ترتیب درست بازیابی.

تست Restore را جدی بگیرید

موفق بودن Job بکاپ به معنی قابل بازیابی بودن سرویس نیست. باید در بازه‌های مشخص، Restore روی محیط تست یا مسیر کنترل‌شده انجام شود. این کار مشخص می‌کند Backup ناقص است یا نه، نسخه درست انتخاب شده یا نه، و بعد از برگشت سرویس چه تنظیمات تکمیلی لازم است.

برای سرویس‌های حساس، بهتر است سناریوی بازیابی نوشته شود: از کجا شروع کنیم، چه کسی مسئول است، Credentialها کجا نگهداری می‌شوند، DNS یا فایروال چه تغییری لازم دارد و چطور صحت داده بررسی می‌شود.

اشتباهات رایج در Backup

• نگهداری Backup روی همان سروری که باید از آن محافظت شود.
• استفاده از یک حساب ادمین مشترک برای همه Jobها.
• تست‌نکردن Restore تا روز حادثه.
• نداشتن نسخه Offline یا Immutable.
• نامشخص بودن RPO و RTO برای سرویس‌های مهم.
• فراموش‌کردن Backup از تنظیمات تجهیزات شبکه و امنیت.

جمع‌بندی عملی

Backup خوب، فقط فایل ذخیره‌شده نیست؛ یک برنامه قابل اجرا برای برگشت سرویس است. اگر Backup دارید اما Restore را تست نکرده‌اید، هنوز نمی‌دانید در زمان حادثه چه اتفاقی می‌افتد. برنامه درست باید شامل نسخه‌بندی، محدودسازی دسترسی، نگهداری امن، تست دوره‌ای و مستندات بازیابی باشد.

برای شبکه‌های سازمانی، بهتر است Backup اطلاعات و Backup پیکربندی تجهیزات کنار هم دیده شوند. در حادثه واقعی، دیتابیس بدون DNS، فایروال، Certificate یا تنظیمات VPN ممکن است به‌تنهایی سرویس را برنگرداند.