چطور بکاپ شرکت را در برابر حذف و باج‌افزار مقاوم‌تر کنیم؟

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

NCSC در بررسی حوادث مرتبط با بکاپ آنلاین به آسیب‌دیدن نسخه‌های USB، شبکه و فضای ابری متصل اشاره می‌کند. سؤال اصلی این است که اگر حساب یا دستگاه معمول شرکت درگیر شد، کدام نسخه هنوز از دسترس آن بیرون می‌ماند.

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

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

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

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

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

این روش مسئول مشخص می‌خواهد: چه کسی نسخه را به‌روز می‌کند، تاریخ آن را می‌داند و هنگام نیاز رسانه را در اختیار مسئول مجاز می‌گذارد؟ اگر همه رسانه‌ها هم‌زمان برای کار به شبکه متصل شوند، مزیت جداسازی کاهش پیدا می‌کند. حفاظت فیزیکی و رمزگذاری متناسب با حساسیت داده نیز مهم‌اند.

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

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

برای نمونه، مستند Object Lock در Amazon S3 بین حالت Governance و Compliance تفاوت می‌گذارد: در اولی، حساب دارای اختیار ویژه می‌تواند محدودیت را دور بزند؛ در دومی حفاظت نسخه در دوره تعیین‌شده سخت‌گیرانه‌تر است. این مثال تفاوت مدل‌ها را نشان می‌دهد، نه توصیه خرید یا فرض دسترس‌پذیری یک سرویس برای شرکت شما.

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

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

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

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

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

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

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

این راهنما برای طراحی حفاظت است. اگر حادثه در جریان است، بکاپ جدا را برای امتحان به دستگاه مشکوک وصل نکنید و نسخه‌های قدیمی را پاک نکنید. مسئول فنی یا تیم پاسخ به حادثه باید وضعیت محیط و نسخه مناسب بازیابی را بررسی کند؛ برگرداندن داده به محیط درگیر می‌تواند آن را دوباره در معرض آسیب قرار دهد.

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