داشتن فایل پشتیبان به تنهایی به معنی آمادگی در برابر باج‌افزار نیست. اگر نسخه پشتیبان همیشه به همان شبکه متصل باشد، با همان حساب مدیریتی کنترل شود یا امکان حذف آن از طریق حساب آلوده وجود داشته باشد، مهاجم ممکن است نسخه‌های پشتیبان را نیز رمزگذاری یا پاک کند. در چنین شرایطی سازمان نه فقط فایل اصلی، بلکه راه بازگشت خود را هم از دست می‌دهد. پشتیبان‌گیری مقاوم در برابر باج‌افزار باید چند لایه مستقل داشته باشد: نسخه‌های جدا از محیط عملیاتی، کنترل دسترسی متفاوت، رمزنگاری، نگهداری آفلاین یا تغییرناپذیر و آزمون منظم بازیابی. هدف این مقاله ساختن یک برنامه عملی است که در زمان حادثه بتواند داده و سرویس را با کمترین آشفتگی به وضعیت سالم برگرداند.
اول دارایی‌ها و اولویت بازیابی را شناسایی کنید
پیش از انتخاب ابزار، مشخص کنید چه داده‌ها و سرویس‌هایی برای ادامه کار ضروری‌اند. پایگاه داده، فایل‌های کاربران، کد برنامه، تنظیمات سرور، کلیدهای رمزنگاری، ایمیل، اسناد و سامانه‌های احراز هویت ممکن است نیازهای متفاوتی داشته باشند. برای هر دارایی، مالک، محل نگهداری، حجم، میزان تغییر و وابستگی‌های آن را ثبت کنید. سپس دو مفهوم را تعریف کنید: RPO یعنی حداکثر میزان داده‌ای که از دست رفتن آن قابل تحمل است و RTO یعنی زمان هدف برای بازگرداندن سرویس. اگر RPO چهار ساعت باشد، نسخه‌برداری روزانه کافی نیست. اگر RTO کوتاه باشد، صرف داشتن فایل فشرده بدون راهنمای بازیابی نیز پاسخگو نخواهد بود.
اصل ۳-۲-۱ را به شکل عملی توسعه دهید
قاعده شناخته‌شده ۳-۲-۱ می‌گوید دست‌کم سه نسخه از داده داشته باشید، آن‌ها را روی دو نوع رسانه یا بستر نگه دارید و حداقل یک نسخه را خارج از محل اصلی قرار دهید. برای تهدید باج‌افزار، این قاعده باید با یک لایه آفلاین یا تغییرناپذیر و آزمون بازیابی تکمیل شود؛ گاهی آن را به صورت ۳-۲-۱-۱-۰ بیان می‌کنند: سه نسخه، دو نوع رسانه، یک نسخه خارج از محل، یک نسخه آفلاین یا immutable و صفر خطای تأییدنشده در آزمون بازیابی. این اعداد یک الگوی طراحی‌اند، نه تضمین مطلق. باید بررسی کنید مهاجم با چه سطح دسترسی می‌تواند هر نسخه را حذف کند و آیا مسیر بازگشت مستقل از شبکه آلوده وجود دارد.
نسخه آفلاین و نسخه تغییرناپذیر چه تفاوتی دارند؟
نسخه آفلاین در حالت عادی به شبکه متصل نیست و از راه دور نمی‌توان به سادگی آن را تغییر داد. رسانه قابل جداسازی یا سامانه‌ای که پس از پایان عملیات از شبکه خارج می‌شود، می‌تواند چنین نقشی داشته باشد؛ اما باید خطر گم شدن، آسیب فیزیکی و مدیریت چرخه نگهداری آن را نیز در نظر گرفت. نسخه تغییرناپذیر یا immutable برای مدت مشخصی در برابر تغییر یا حذف محافظت می‌شود، حتی اگر حسابی با دسترسی معمولی تلاش کند آن را پاک کند. این قابلیت می‌تواند در ذخیره‌سازی شیءگرا یا سامانه‌های پشتیبان وجود داشته باشد. تغییرناپذیری را با قفل قانونی یا retention policy اشتباه نگیرید؛ تنظیمات و سطح دسترسی مدیر باید جداگانه بررسی شوند.
دسترسی به مخزن پشتیبان را از محیط اصلی جدا کنید
اگر مدیر سرور تولید با همان حساب بتواند همه نسخه‌های پشتیبان را حذف کند، جداسازی واقعی ندارید. حساب‌های مدیریتی پشتیبان باید مستقل باشند و برای عملیات حساس از احراز هویت چندمرحله‌ای مقاوم استفاده شود. دسترسی نوشتن، خواندن، حذف و تغییر سیاست نگهداری را تا حد امکان از هم جدا کنید. حساب سرویس برنامه نباید مجوز مدیریت مخزن پشتیبان را داشته باشد. کلیدهای دسترسی را در فایل تنظیمات عمومی یا همان سروری که قرار است پشتیبان بگیرد ذخیره نکنید. دسترسی اضطراری باید محدود، ثبت‌شده و قابل بازبینی باشد. اصل حداقل دسترسی کمک می‌کند آلوده شدن یک حساب به معنی از دست رفتن تمام نسخه‌ها نباشد.
رمزنگاری و مدیریت کلید
پشتیبان باید هنگام انتقال و در زمان ذخیره رمزنگاری شود، به‌خصوص اگر از فضای ابری یا رسانه قابل حمل استفاده می‌کنید. اما رمزنگاری بدون برنامه مدیریت کلید می‌تواند بازیابی را غیرممکن کند. کلید رمزگشایی نباید فقط روی همان سرور یا در همان حسابی باشد که حادثه ممکن است آن را از بین ببرد. نسخه پشتیبان کلیدها را در محل امن و جداگانه نگه دارید، دسترسی را محدود کنید و فرایند تحویل اضطراری را مستند کنید. دوره‌ای بازیابی را با همان کلیدها آزمایش کنید. از ثبت کلید در گزارش‌ها، اسکرین‌شات‌ها یا فایل‌های عمومی جلوگیری کنید. اگر کلید گم شود، نسخه رمزنگاری‌شده ممکن است عملاً غیرقابل استفاده باشد.
از چه چیزی باید نسخه پشتیبان بگیرید؟
فقط گرفتن فایل‌های قابل مشاهده کافی نیست. برای یک وب‌سایت، پایگاه داده، فایل‌های بارگذاری‌شده، کد سفارشی، تنظیمات وب‌سرور، نسخه PHP، فهرست افزونه‌ها و قالب‌ها، گواهی‌ها و تنظیمات DNS ممکن است در بازیابی نقش داشته باشند. برای رایانه شخصی، اسناد، تصاویر، پروژه‌ها، تنظیمات برنامه‌ها و کلیدهای بازیابی اهمیت دارند. فهرست وابستگی‌ها را نگه دارید تا بدانید برای بازگردانی هر سرویس چه نسخه نرم‌افزار و چه دسترسی‌هایی لازم است. فایل‌های موقت و کش معمولاً نیاز به پشتیبان ندارند، اما حذف آن‌ها باید آگاهانه باشد. نسخه پشتیبان باید با هدف بازیابی طراحی شود، نه صرفاً کپی کردن همه چیز بدون اولویت.
برنامه زمان‌بندی و نگهداری نسخه‌ها
تناوب پشتیبان‌گیری باید با RPO و نرخ تغییر داده هماهنگ باشد. پایگاه داده پرتغییر ممکن است به نسخه‌های مکررتر یا ثبت پیوسته تغییرات نیاز داشته باشد؛ فایل‌های ثابت می‌توانند با تناوب کمتر ذخیره شوند. سیاست نگهداری باید نسخه‌های کوتاه‌مدت برای بازیابی سریع و نسخه‌های بلندمدت برای کشف آلودگی دیرهنگام داشته باشد. اگر مهاجم چند هفته در شبکه حضور داشته باشد، ممکن است نسخه‌های اخیر نیز آلوده باشند؛ بنابراین فقط نگهداری آخرین نسخه خطرناک است. زمان نگهداری را با ظرفیت ذخیره‌سازی، الزامات قانونی و نیاز عملیاتی متعادل کنید. نسخه‌ها را با تاریخ، سامانه، نوع داده و وضعیت موفقیت مشخص کنید تا در زمان بحران انتخاب نسخه سالم دشوار نشود.
آزمون بازیابی؛ مهم‌تر از پیام موفقیت پشتیبان
پیام «Backup completed» ثابت نمی‌کند که فایل قابل بازیابی است. باید به شکل دوره‌ای نسخه را در محیط جداگانه بازگردانید و صحت داده و عملکرد سرویس را بررسی کنید. برای پایگاه داده، فقط باز شدن فایل کافی نیست؛ اتصال برنامه، صحت رکوردها و اجرای عملیات اصلی را آزمایش کنید. برای فایل‌ها، چند نمونه را باز و یکپارچگی آن‌ها را بررسی کنید. زمان واقعی بازیابی را اندازه بگیرید و با RTO مقایسه کنید. خطاهای بازیابی را ثبت و برنامه را اصلاح کنید. آزمون باید شامل کلید رمزگشایی، دسترسی‌ها، وابستگی نرم‌افزاری و راه‌اندازی مجدد سرویس باشد. اگر بازیابی هرگز تمرین نشده، در زمان حادثه اولین تجربه تیم خواهد بود؛ آن زمان بدترین زمان برای کشف نقص است.
برنامه بازیابی پس از حادثه را بنویسید
در رخداد باج‌افزار، بازگرداندن عجولانه داده روی محیط آلوده می‌تواند آلودگی را دوباره وارد کند. برنامه باید مشخص کند چه کسی حادثه را اعلام می‌کند، چه کسی شبکه یا میزبان آلوده را جدا می‌کند، چه کسی نسخه سالم را انتخاب می‌کند و ترتیب بازگردانی سرویس‌ها چیست. پیش از بازیابی، باید منشأ حادثه و سطح آلودگی تا حد معقول بررسی شود و محیط پاک یا بازسازی‌شده آماده باشد. سرویس‌های هویت، شبکه و سامانه‌های حیاتی ممکن است پیش از برنامه‌های کم‌اهمیت‌تر بازیابی شوند. ارتباط با کارکنان، مشتریان و مراجع مسئول نیز باید در برنامه دیده شود. تصمیم‌های بحرانی را در لحظه بحران به حافظه افراد وابسته نکنید.
نظارت بر سلامت نسخه‌ها و هشدارها
گزارش پشتیبان‌گیری را به صورت منظم بررسی کنید و برای شکست عملیات، کاهش غیرعادی حجم نسخه، حذف گسترده فایل‌ها، تغییر سیاست نگهداری و ورود غیرمنتظره به مخزن هشدار بسازید. اگر تعداد فایل‌های پشتیبان ناگهان صفر یا بسیار کم شود، ممکن است مشکل اتصال یا حذف عمدی رخ داده باشد. گزارش‌ها باید در محلی جدا از سامانه اصلی نگهداری شوند تا مهاجم نتواند به سادگی ردپا را پاک کند. دسترسی به گزارش‌ها را محدود کنید و برای تغییر تنظیمات حساس تأیید دو نفره را در نظر بگیرید. پایش باید هم سلامت فنی و هم رفتار دسترسی را پوشش دهد؛ صرف موفق بودن زمان‌بندی کافی نیست.
خطاهای رایج در طراحی پشتیبان
اتصال دائمی همه نسخه‌ها، استفاده از حساب مدیریتی مشترک، نگهداری کلید کنار فایل رمزنگاری‌شده، حذف نسخه‌های قدیمی بدون آزمون و نداشتن راهنمای بازیابی از خطاهای جدی‌اند. برخی سازمان‌ها نسخه پشتیبان را روی همان دستگاه یا همان حساب ابری نگه می‌دارند و آن را خارج از محل تصور می‌کنند؛ اما اگر همان اعتبارنامه به هر دو دسترسی داشته باشد، جداسازی ضعیف است. خطای دیگر، آزمون نکردن بازیابی در مقیاس واقعی است؛ بازگرداندن یک فایل کوچک لزوماً نشان نمی‌دهد یک پایگاه داده بزرگ در زمان موردنیاز بالا می‌آید. همچنین پشتیبان‌گیری از داده آلوده، آلودگی را حفظ می‌کند. نسخه‌های متعدد باید با اسکن و بررسی نقطه بازگشت همراه باشند.
چک‌لیست اجرای اولیه
فهرست دارایی‌ها و مالک هرکدام را تهیه کنید؛ RPO و RTO را تعیین کنید؛ دست‌کم یک نسخه جدا از محیط تولید و یک نسخه آفلاین یا تغییرناپذیر داشته باشید؛ حساب و کلیدهای مدیریت پشتیبان را از محیط اصلی جدا کنید؛ رمزنگاری انتقال و ذخیره را فعال کنید؛ سیاست نگهداری چندنسخه‌ای بنویسید؛ هشدار شکست و حذف غیرعادی بسازید؛ راهنمای بازیابی را مستند کنید؛ و بازیابی کامل را در محیط ایزوله تمرین کنید. برای شروع لازم نیست همه زیرساخت را یک‌باره عوض کنید. ابتدا مهم‌ترین داده‌ها را پوشش دهید، سپس شکاف‌ها را بر اساس ریسک و هزینه اولویت‌بندی کنید.
جمع‌بندی
پشتیبان‌گیری مقاوم در برابر باج‌افزار یک فرایند کامل است، نه یک زمان‌بندی ساده. نسخه‌های جدا، دسترسی مستقل، رمزنگاری، نگهداری آفلاین یا تغییرناپذیر و آزمون بازیابی باید کنار هم قرار گیرند. راهنمای امنیت حساب‌های آنلاین و مقاله انتخاب نرم‌افزار مدیریت رمز عبور برای تیم نیز به تقویت لایه دسترسی کمک می‌کنند. برای توصیه‌های تکمیلی، راهنمای CISA درباره باج‌افزار را مطالعه کنید؛ این راهنما بر نسخه‌های آفلاین و آزمون بازیابی تأکید دارد. برنامه خود را با یک بازیابی واقعی بسنجید، نه با پیام موفقیت نرم‌افزار.
پرسش‌های متداول
آیا فضای ابری به تنهایی نسخه پشتیبان امن محسوب می‌شود؟
خیر. باید سطح دسترسی، امکان حذف، تغییرناپذیری، رمزنگاری و جداسازی حساب‌ها را بررسی کنید. فضای ابری می‌تواند بخشی از راهکار باشد، اما به تنهایی تضمین نمی‌دهد.
هر چند وقت یک بار باید بازیابی آزمایشی انجام شود؟
تناوب به اهمیت داده و سرعت تغییر آن بستگی دارد. برای داده‌های حیاتی آزمون باید منظم و پس از تغییر مهم زیرساخت نیز تکرار شود. معیار اصلی، اثبات بازیابی در زمان هدف است.
نسخه پشتیبان آفلاین بهتر است یا immutable؟
هر دو تهدیدهای متفاوتی را کاهش می‌دهند. نسخه آفلاین از دسترسی شبکه‌ای جلوگیری می‌کند و نسخه تغییرناپذیر حذف یا تغییر را در دوره مشخص محدود می‌کند. ترکیب آن‌ها معمولاً دفاع چندلایه‌تری می‌سازد.
منابع رسمی
- راهنمای مقابله با باج‌افزار CISA؛ شامل توصیه‌های پشتیبان‌گیری آفلاین و بازیابی.
- اهداف عملکرد امنیت سایبری بین‌بخشی CISA.
