راهنمای گام‌به‌گام حفاظت از Backupهای سازمانی در زمان بحران

در سال‌های اخیر، شاهد تغییر قابل ملاحظه‌ای در تاکتیک مهاجمان Ransomware بوده‌ایم: دیگر صرفاً داده‌های سازمان را رمزگذاری نمی‌کنند، بلکه پشتیبان‌ها و زیرساخت‌های بازیابی را هدف می‌گیرند تا راه بازگشت را ببندند. این رویکرد باعث می‌شود که حتی اگر سازمان اقدام به پرداخت باج نکند، امکان بازیابی اطلاعات از طریق پشتیبان‌ها را نداشته باشد، یعنی پشتیبان‌های قبلی بی‌اثر شوند. این واقعیت جدید نشان‌دهنده اهمیت حیاتی داشتن استراتژی پشتیبان مقاوم و ایمن است.

همین چند ماه پیش، در حملات به محیط‌های کلود، مهاجمان پشتیبان‌ها را حذف کرده یا سیاست‌های چرخه عمر یا lifecycle Policies را دستکاری کردند تا فایل‌ها به‌صورت خودکار پس از چند روز پاک شوند. در یک مورد دیگر از گروه Storm-0501، استفاده شد تا در محیط ابری علاوه بر رمزگذاری داده‌ها، پشتیبان‌ها را نیز نابود کنند.

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

نمونه‌هایی از حملات اخیر به پشتیبان‌ها

1. دستکاری سیاست چرخه عمر و حذف خودکار پشتیبان‌ها
   در حملاتی مانند Codefinger، مهاجمان به پلتفرم پشتیبان ابری نفوذ کرده و قوانین Retention را طوری تغییر می‌دهند که فایل‌های پشتیبان به‌صورت خودکار خیلی زود حذف شوند یعنی حتی پیش از اطلاع سازمان، بنای حذف گذاشته شده است.
   آن‌ها از امکانات Native سرویس کلود مانند Azure Blob یا Amazon S3 استفاده کرده‌اند تا عملیات حذف را انجام دهند.
2. حذف یا رمزگذاری پشتیبان پس از نفوذ
   در نمونه Storm-0501 دیده شده که مهاجم پس از نفوذ و استخراج داده‌ها، پشتیبان‌ها را نیز از بین برد تا سازمان نتواند از نسخه‌های پشتیبان بدون پرداخت باج بازگردد.
   آن‌ها می‌توانند با دسترسی مدیریتی به فضای ذخیره‌سازی ابری، اسنپشات‌ها را حذف یا اصلاح کنند.

بیشتر بخوانید: بررسی و مقایسه‌ی راهکارهای بازیابی پس از فاجعه و پشتیبان‌گیری

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

1. جعل یا تغییر پشتیبان‌ها یا  Corruption
   به‌جای حذف کامل، برخی مهاجمان پشتیبان را تغییر می‌دهند یا آن را خراب می‌کنند تا وقتی سازمان بخواهد بازگردانی انجام دهد، داده‌ها معیوب باشند یعنی امکان بازیابی واقعی را از بین می‌برند.
2. به‌کارگیری دسترسی OAuth یا توکن‌ها برای نفوذ به پشتیبان‌های ابری
   در برخی حملات، مهاجمان از توکن‌های OAuth یا رمز عبور پنهانی استفاده کرده‌اند تا به محیط پشتیبان ابری دسترسی یابند و پشتیبان‌ها را تحت کنترل خود بگیرند.

بیشتر بخوانید: بایدها و نبایدهای پشتیبان گیری از داده‌ها

این نمونه‌ها به‌روشنی نشان می‌دهند که داشتن نسخه پشتیبان کافی نیست؛ بلکه باید پشتیبان‌ها به گونه‌ای طراحی شوند که خود هدف حمله قرار نگیرند.

چرا پشتیبان‌های معمولی دیگر کافی نیستند؟

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

الزامات و معیارهای طراحی یک پشتیبان مقاوم

در ادامه ویژگی‌ها و معماری‌هایی که یک سیستم پشتیبان باید داشته باشد مطرح می‌کنم تا در برابر حملات اخیر مقاوم باشد:.

1. ایزولاسیون کامل و جداشدگی محیط

• پشتیبان‌ها باید در شبکه کاملاً جداگانه (air-gapped یا logical isolation) قرار گیرند.
• دسترسی از محیط تولید (production) به پشتیبان فقط از کانال‌های کنترل‌شده و محدود ممکن باشد.
• پشتیبان باید روی سیستم‌هایی قرار گیرد که خودشان از دید کاربران عادی کنترل‌نشده‌اند.

۲. نسخه‌های ایمن و Immutable Backups

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

• استفاده از پشتیبان‌های غیرقابل تغییر Immutable / WORM که پس از نوشتن، امکان تغییر یا حذف نداشته باشند.

• یک از استراتژی‌های مدرن: مدل 3-2-1-1-0: داشتن سه نسخه، روی دو رسانه متفاوت، یک نسخه خارج از سایت، یک نسخه immutable و صفر خطا

3. نسخه‌های ایمن و Immutable Backups

• استفاده از پشتیبان‌های غیرقابل تغییر Immutable / WORM که پس از نوشتن، امکان تغییر یا حذف نداشته باشند.
• یک از استراتژی‌های مدرن: مدل 3-2-1-1-0 داشتن سه نسخه، روی دو رسانه متفاوت، یک نسخه خارج از سایت، یک نسخه Immutable و صفر خطا.
• نگهداری نسخه‌های پشتیبان در زمان‌های مختلف به‌صورت تعدادی نسخه تاریخی، به طوری که حذف همه آن‌ها توسط مهاجم دشوار باشد.

بیشتر بخوانید: بایدها و نبایدهای پشتیبان گیری از داده‌ها

۴. لاگ، مانیتورینگ و هشدار

• تمام تغییرات در پشتیبان‌ها حذف، تغییر تنظیمات، دسترسی‌ها باید ثبت و به سیستم SIEM ارسال شود.
• نظارت بر الگوهای غیرمعمول حذف دسته‌ای یا تغییر تنظیمات Retention. 
• تشخیص رفتاری Behavior-Based Detection برای فعالیت‌های پشتیبان که خارج از الگوهای معمول هستند.

5. تست منظم و بازیابی تمرینی

• اجرای دوره‌ای Restore تستی از نسخه‌های پشتیبان برای اطمینان از صحت و کارکرد.
• شبیه‌سازی حملات پشتیبان مثلاً سناریوی حذف Backups در تمرین‌های Red Team / Tabletop.
• مستندسازی فرآیند بازیابی و تضمین زمان بازگشت خدمت یا RTO و نقطه قابل قبول بازیابی RPO.

۶. لایه حفاظتی و Virtual Patching

• دسترسی پشتیبان‌ها از طریق لایه‌ای واسط مانند Gateway امن یا Proxy کنترل‌شده انجام شود.
• اعمال قواعد IPS/IDS برای جلوگیری از حذف یا تغییر غیرمجاز پشتیبان‌ها.
• اگر سرویس پشتیبان نرم‌افزاری است، از نسخه‌ای که Patch شده باشد استفاده کنید یا اگر وصله رسمی وجود ندارد، از تعمیرات موقت Hotfix یا Rule امتناعی بهره ببرید.

۷. تقسیم پشتیبان در محیط‌های مختلف

• کپی‌برداری پشتیبان‌ها در محیط‌های متفاوت : On-Premises، ابری، چند منطقه جغرافیایی.
• عدم تکیه بر یک ارائه‌دهنده ابری تنها زیرا اگر آن محیط دچار نفوذ شود، کل پشتیبان‌ها در خطر هستند.
• استفاده از فناوری‌هایی که امکان انتقال امن و رمزنگاری بین نقاط پشتیبان را فراهم می‌کنند.

۸. جداسازی و امنیت فضای ذخیره‌سازی

• پشتیبان‌ها باید در محیطی با دسترسی محدود و امن ذخیره شوند NAS،Object Storage  با سیاست‌های امن.
• استفاده از رمزنگاری داده در حالت استراحت (At Rest) و در هنگام انتقال In transit.
• پشتیبان‌ها نباید بخشی از ساختار دسترسی عمومی یا مشترک باشند.

روند پیشنهادی پیاده‌سازی در سازمان

۱. ارزیابی وضعیت فعلی پشتیبان‌ها: کجا ذخیره می‌شوند، چه دسترسی‌هایی دارند، آیا immutable هستند؟
2. طراحی معماری پشتیبان مقاوم: تعیین محیط ایزوله، رسانه‌های مختلف، استراتژی Retention و نسخه‌های تاریخی.
3. پیاده‌سازی لایه‌های دسترسی و کنترل: MFA محدودسازی حقوق، تفکیک حساب‌ها.
4. راه‌اندازی مانیتورینگ هوشمند: ثبت لاگ، بررسی رفتار، هشدار به تغییرات مشکوک.
5. اجرای تمرینات Restore و سناریوهای حذف پشتیبان: Red Team، Tabletop

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

بنابراین هر سازمانی باید استراتژی پشتیبان مقاومی بسازد که شامل ایزولاسیون، Immutable Backups، کنترل دسترسی دقیق، مانیتورینگ پیشرفته و تمرین عملی بازیابی باشد. در عصر تهدیدات پیشرفته، داشتن فقط نسخه‌های پشتیبان کافی نیست، باید پشتیبان‌ها را به گونه‌ای طراحی کرد که خودشان «نقطه آسیب‌ناپذیر» باشند.

چک‌لیست امنیتی پشتیبان‌گیری سازمانی

1. معماری و طراحی

• استراتژی3-2-1-1-0  پیاده‌سازی شود (۳ نسخه، ۲ رسانه، ۱ نسخه خارج از سایت، ۱ نسخه Immutable، خطا در تست.
• پشتیبان‌ها در محیط ایزوله air-gapped یا logically isolated ذخیره شوند.
• حداقل یک نسخه پشتیبان در مکان/Region جغرافیایی جداگانه نگهداری شود.

2. ایمن‌سازی نسخه‌ها

• استفاده از Immutable/WORM backups برای جلوگیری از تغییر یا حذف عمدی.
• نسخه‌های قدیمی‌تر پشتیبان به‌صورت دوره‌ای حفظ شوند Retention Policy چندلایه: روزانه، هفتگی، ماهانه.
• اسنپشات‌ها و Backupهای سازمانی رمزنگاری‌شده در حالت استراحت At Rest و انتقال In Transit باشند.

3. دسترسی و کنترل هویت

• دسترسی به سیستم پشتیبان فقط از طریق حساب‌های اختصاصی با Least Privilege.
• فعال‌سازی MFA برای همه حساب‌های مدیریتی Backupهای سازمانی.
• استفاده از حساب‌های جداگانه برای Backup Admin و System Admin Separation of Duties.
• بازبینی دوره‌ای دسترسی‌ها و حذف حساب‌های غیرضروری.

۴. مانیتورینگ و تشخیص تهدید

• ثبت کامل لاگ‌ها از عملیات پشتیبان ایجاد، حذف، تغییر policy.
• ارسال لاگ‌ها به SIEM برای تحلیل مرکزی.
• فعال‌سازی هشدار برای فعالیت‌های مشکوک مثل حذف دسته‌ای Backupهای سازمانی یا تغییر ناگهانی Retention Policy.
• مانیتورینگ سلامت نسخه‌های پشتیبان.Checksum/Hash Validation

۵. تست و اطمینان از کارایی

• اجرای تستRestore به‌صورت دوره‌ای (حداقل فصلی).
• تعریفRTO/RPO و بررسی دستیابی به آنها در سناریوهای آزمایشی.
• شبیه‌سازی سناریوی حمله Red Team / Tabletop برای بررسی مقاومت پشتیبان‌ها.

6. امنیت زیرساخت پشتیبان

• جداسازی شبکه‌ای Network Segmentation بین سرورهای پشتیبان و سیستم‌های  .Production
• اعمال IPS/IDS یا فایروال لایه ۷ روی سرویس‌های Backupهای سازمانی.
• محدود کردن دسترسی مدیریتی فقط از IPهای مشخص whitelisting.
• استفاده از نسخه‌های به‌روز نرم‌افزار پشتیبان (وصله‌های امنیتی فوری).

۷. فرآیندها و سیاست‌ها

• مستندسازی کامل سیاست پشتیبان‌گیری و بازیابی.
• تعریف مسئولیت‌ها Backup Owner ،IR Owner
• بازبینی سیاست‌ها حداقل سالی یک‌بار.
• آموزش کارکنان IT در مورد تهدیدات جدید (مثلاً حذف پشتیبان توسط مهاجمان).

8. بازیابی بحران یا Disaster Recovery

• وجود طرحDR/BCP  هماهنگ با پشتیبان‌ها.
• نگهداری نسخه‌های حیاتی در فضای آفلاین برای سناریوی حمله گسترده مانند  Ransomware
• تمرین مشترک بین تیم‌های IT و مدیریت برای سناریوی پشتیبان‌ها هدف حمله قرار گرفته‌اند.

داشتن پشتیبان کافی نیست؛ باید مطمئن شوید پشتیبان‌ها ایمن، غیرقابل تغییر، تست‌شده و ایزوله هستند.

خلاصه مقاله

حملات سایبری اخیر، به‌ویژه باج‌افزارها و سوءاستفاده از Zero-Dayها، نشان داده‌اند که مهاجمان در کنار داده‌های اصلی سازمان، نسخه‌های پشتیبان را نیز هدف قرار می‌دهند تا مسیر بازگشت مسدود شود. بنابراین صرف داشتن Backupهای سازمانی کافی نیست؛ بلکه این Backupهای سازمانی باید ایمن، ایزوله و غیرقابل تغییر Immutable باشند.

این مقاله توضیح می‌دهد که چگونه سازمان‌ها می‌توانند با یک راهبرد چندلایه، پشتیبان‌ها را به یک سپر دفاعی واقعی تبدیل کنند. گام‌های کلیدی شامل ایزوله‌سازی محیط Backup، استفاده از نسخه‌های Immutable، اجرای اصل 3-2-1-1-0، اعمال کنترل‌های دسترسی سخت‌گیرانه، مانیتورینگ هوشمند، تست‌های منظم بازگردانی و یکپارچه‌سازی با طرح‌های تداوم کسب‌وکار است.