راهنمای Backup ضد باجافزار؛ چگونه از نسخههای پشتیبان هم محافظت کنیم؟
داشتن Backup کافی نیست؛ باید مطمئن شویم مهاجم نمیتواند نسخههای پشتیبان را هم حذف یا خراب کند.
وقتی باجافزار وارد سازمان میشود، اولین هدف همیشه فایلهای کاربران نیستند. مهاجم حرفهای تلاش میکند مسیرهای بازیابی را هم از بین ببرد تا سازمان مجبور شود برای بازگشت سرویس مذاکره کند. بنابراین Backup باید بخشی از معماری امنیت و تداوم کسبوکار باشد، نه فقط یک Job که هر شب اجرا میشود.
Backup موفق با Backup قابل بازیابی فرق دارد
ممکن است Job هر شب با وضعیت Success تمام شود، اما در بحران متوجه شویم Repository در دسترس نیست، نسخهها بیش از حد قدیمیاند یا Restore زمان زیادی میبرد. اولین اصل این است که فرآیند بازیابی باید بهصورت دورهای تست شود.
قانون ۳-۲-۱ را ساده بفهمیم
- حداقل ۳ کپی از دادههای مهم داشته باشید.
- کپیها روی حداقل ۲ نوع رسانه یا مقصد نگهداری شوند.
- حداقل ۱ کپی خارج از سایت اصلی باشد.
برای سازمانهای حساس، این مدل را میتوان با یک لایه مقاومتر در برابر حذف یا تغییر تکمیل کرد. هدف این است که یک رخداد واحد نتواند داده اصلی و همه نسخههای پشتیبان را همزمان از بین ببرد.
Immutable Backup چیست؟
Immutable Backup یعنی نسخه پشتیبان در یک بازه مشخص قابل تغییر یا حذف نباشد. در سناریوهای مناسب، Object Lock و فناوریهای مشابه میتوانند کمک کنند نسخهای داشته باشیم که حتی در صورت دسترسی مهاجم به بخشی از زیرساخت، بهسادگی پاک نشود.
چرا Segmentation مهم است؟
اگر Backup Repository دقیقاً در همان سطح دسترسی Serverهای اصلی قرار داشته باشد، compromise شدن حساب مدیریتی میتواند هر دو را تهدید کند. جداسازی شبکه، محدودسازی دسترسی و استفاده از حسابهای اختصاصی، سطح ریسک را پایین میآورد.
حساب Backup را مثل حساب معمولی نسازید
حسابهایی که امکان حذف یا تغییر Backup دارند باید محدود، اختصاصی و تا حد امکان جدا از حسابهای روزمره باشند. دسترسی مدیریتی دائمی برای همه اعضای تیم IT ضرورت ندارد.
Restore Test را در تقویم بگذارید
- یک Workload مهم را انتخاب کنید.
- سناریوی Restore را مستند کنید.
- زمان واقعی بازیابی را اندازه بگیرید.
- درستی داده و سرویس را بررسی کنید.
- مشکلات را ثبت و اصلاح کنید.
RPO و RTO چه نقشی دارند؟
RPO میگوید چه مقدار داده میتوان از دست داد و RTO میگوید سرویس چه مدت میتواند خارج از دسترس باشد. این دو عدد مشخص میکنند Backup هر چند وقت اجرا شود و چه نوع Recovery لازم است. بدون RPO/RTO، طراحی Backup معمولاً بر اساس حدس انجام میشود.
Veeam در معماری ضدباجافزار
Veeam میتواند بخشی از معماری Backup و Recovery سازمان باشد و در سناریوهای مناسب از قابلیتهایی مانند Immutable Backup و Object Lock استفاده شود. اما هیچ نرمافزاری بهتنهایی امنیت ایجاد نمیکند؛ Repository، شبکه، حسابهای مدیریتی، MFA، دسترسیها و فرآیند Restore باید کنار هم طراحی شوند.
در صفحه Veeam طوبی نت مدل راهکار را توضیح دادهایم. اگر برای طراحی Backup سازمانی به دنبال یک معماری قابل اتکا هستید، بهتر است ابتدا Workloadها و RPO/RTO را مشخص کنید.
اشتباهات رایج
- همه Backupها روی همان Storage اصلی قرار دارند.
- Backupها قابل حذف با همان حسابهای مدیریتی هستند.
- Restore Test انجام نمیشود.
- هیچ نسخهای خارج از سایت وجود ندارد.
- Retention بدون توجه به نیاز واقعی تنظیم شده است.
سؤالات متداول
آیا Immutable Backup جایگزین Backup خارج از سایت است؟
خیر. هدفهای این دو متفاوتاند و بسته به ریسک، میتوان هر دو را در معماری داشت.
آیا Backup روزانه برای همه سرویسها کافی است؟
به RPO مورد انتظار بستگی دارد. برای سرویسهای حیاتی ممکن است فاصله کوتاهتری لازم باشد.
چند بار Restore Test انجام دهیم؟
باید دورهای و بر اساس اهمیت سرویس انجام شود؛ مهمتر از تعداد، واقعی بودن تست و ثبت نتیجه است.
جمعبندی
Backup ضدباجافزار یعنی داده اصلی، نسخههای پشتیبان و مسیر بازیابی را یک معماری واحد ببینیم. Immutability، Segmentation، دسترسی محدود و Restore Test در کنار Backup معمولی، سطح آمادگی سازمان را به شکل محسوسی افزایش میدهند.
Backup را برای روز بحران طراحی کنید
طوبی نت میتواند معماری Backup، Repository، شبکه، امنیت و سناریوی Recovery را متناسب با زیرساخت شما بررسی کند.
