در مطلب قبلی، Open‑E JovianVHR را معرفی کردیم و با قابلیت حفاظت دولایه از بکاپ‌های Veeam آشنا شدیم. در این مطلب، برای درک بهتر این معماری، به سراغ Linux Hardened Repository یا LHR می‌رویم؛ مخزنی که یکی از لایه‌های این حفاظت را فراهم می‌کند. Hardened Repository چگونه از فایل‌های بکاپ در برابر حذف یا تغییر محافظت می‌کند و JovianVHR چگونه این حفاظت را تکمیل می‌کند؟ در ادامه، نحوهٔ عملکرد این مخزن، اصول ایمن‌سازی آن و نقش Snapshotهای ZFS در ایجاد لایهٔ دوم حفاظت را بررسی می‌کنیم.
راهنمای مطالعه
چرا بکاپ بدون حفاظت کافی در معرض خطر است؟
اگر دسترسی‌های مدیریتی مخزن بکاپ به‌درستی تفکیک و محدود نشده باشند، مهاجم ممکن است پس از نفوذ برای تغییر یا حذف فایل‌های بکاپ اقدام کند. به همین دلیل، داشتن نسخه پشتیبان باید با حفاظت از خود مخزن، کنترل دسترسی و آزمون بازیابی همراه باشد.
Linux Hardened Repository یکی از روش‌های تقویت این حفاظت است و امنیت آن به پیکربندی و نگهداری صحیح محیط وابسته است.
پیامدهای مالی و آمارهای حملات باج‌افزار
پیامدهای مالی Data Breachهای امروزی و حملات Ransomware باعث شده است Immutability دیگر صرفاً یک قابلیت اختیاری در زیرساخت IT نباشد، بلکه به یکی از اجزای ضروری مدیریت ریسک تبدیل شود. آمارهای سال‌های اخیر حوزه Cybersecurity نیز اهمیت برخورداری از قابلیت‌های قابل‌اعتماد برای Recovery را نشان می‌دهند.
متوسط هزینه رخدادهای Ransomware یا اخاذی سایبری: ۵.۰۸ میلیون دلار
طبق گزارش IBM در سال ۲۰۲۵، میانگین جهانی هزینه یک رخداد نشت داده ۴٫۴۴ میلیون دلار بوده است. این شاخص همه رخدادهای بررسی‌شده را در بر می‌گیرد و مختص باج‌افزار نیست.
مجموع مبالغ دریافت‌شده توسط مهاجمان باج‌افزار: ۸۱۳ میلیون دلار
طبق برآورد منتشرشده Chainalysis در گزارش ۲۰۲۵، پرداخت‌های باج‌افزاری شناسایی‌شده در سال ۲۰۲۴ حدود ۸۱۳٫۵۵ میلیون دلار بوده؛ حدود ۳۵٪ کمتر از سال ۲۰۲۳
مدت اختلال پس از حمله باج‌افزاری
زمان بازیابی پس از حمله باج‌افزاری به گستردگی حادثه، سلامت بکاپ‌ها و آمادگی سازمان وابسته است. داشتن بکاپ به‌تنهایی کافی نیست؛ آزمون دوره‌ای بازیابی به ارزیابی زمان موردنیاز برای بازگرداندن سرویس‌ها کمک می‌کند.
Linux Hardened Repository چیست و چگونه Immutability را فراهم می‌کند؟
Linux Hardened Repository یک Backup Repository امن روی Linux Server اختصاصی و Hardeningشده است که از Immutable Backup پشتیبانی می‌کند. Immutable Backup نسخه‌ای از داده‌هاست که طی یک دوره نگهداری مشخص، از طریق دسترسی‌های عملیاتی معمول قابل‌تغییر یا حذف نیست.
هدف LHR ایجاد نوعی جداسازی منطقی یا Virtual Air Gap در زنجیره Backup است. در این معماری، کنترل Retention داده‌های Backup از Credentialهای مدیریتی محیط Production جدا می‌شود؛ بنابراین، به‌خطر‌افتادن حساب‌های محیط اصلی به‌تنهایی نباید امکان تغییر یا حذف Backupهای محافظت‌شده را در اختیار مهاجم قرار دهد.
در Hardened Repository، محدودکردن دسترسی‌ها و اعمال تغییرناپذیری، امکان دست‌کاری بکاپ‌ها را کاهش می‌دهد. این حفاظت به معنی قطع ارتباط شبکه یا ایجاد Air Gap فیزیکی نیست؛ مخزن همچنان برای دریافت بکاپ و عملیات بازیابی با اجزای مجاز زیرساخت ارتباط دارد.
Veeam Backup Server
ایجاد و ارسال Backup Job
انتقال امن Backup
Linux Hardened Repository
دریافت و نگهداری Backup روی XFS
اعمال Immutability
Immutable Backup Files
محافظت از تغییر و حذف در دوره Retention
مبانی Linux Hardened Repository و XFS
عملکرد Linux Hardened Repository به قابلیت‌های امنیتی Linux و ویژگی‌های File System انتخاب‌شده برای Backup Repository وابسته است.
XFS، Reflink و ویژگی Immutable
در این معماری، دو قابلیت نقش‌های متفاوتی دارند: ویژگی immutable لینوکس برای محدودکردن تغییر فایل‌ها به کار می‌رود و reflink در XFS امکان استفاده از Veeam Fast Clone را فراهم می‌کند. امنیت مخزن علاوه بر این قابلیت‌ها، به کنترل دسترسی و سخت‌سازی سیستم‌عامل وابسته است.
ویژگی Immutable
ویژگی immutable از تغییر یا حذف معمول فایل، تا زمانی که فعال است، جلوگیری می‌کند. بااین‌حال، دسترسی دارای اختیار کافی در سیستم‌عامل می‌تواند این ویژگی را تغییر دهد. بنابراین حفاظت مؤثر به محدودکردن دسترسی‌های مدیریتی و سخت‌سازی مخزن نیز وابسته است.
بهبود Performance با Fast Clone یا Reflink
Veeam Fast Clone با استفاده از reflink در XFS، در عملیات پشتیبانی‌شده مانند ساخت Synthetic Full از بلوک‌های موجود دوباره استفاده می‌کند. این روش می‌تواند زمان عملیات، ورودی‌وخروجی دیسک و فضای اضافی موردنیاز را کاهش دهد.
میزان بهبود به نوع عملیات و پیکربندی مخزن وابسته است و به معنی افزایش یکسان سرعت همه بکاپ‌ها یا تضمین RPO نیست.
Immutability بدون Hardening، محدودسازی SSH و Least Privilege حفاظت کاملی ایجاد نمی‌کند.
پیاده‌سازی Linux Hardened Repository و بهترین روش‌های امنیتی
جزئیات استقرار و احراز هویت باید با نسخه Veeam و روش آماده‌سازی مخزن تطبیق داده شود. برای اینکه Linux Hardened Repository بتواند سطح حفاظتی موردنیاز محیط‌های Enterprise را فراهم کند، پیکربندی اولیه به‌تنهایی کافی نیست. Linux Server میزبان Repository باید براساس استانداردهای امنیتی Hardening شود، Attack Surface آن کاهش یابد و دسترسی‌ها مطابق اصل Least Privilege تعریف شوند.
اطلاعات ورود یک‌بارمصرف و مدیریت SSH
در روش استقرار با Single-use Credentials، اطلاعات ورود فقط هنگام افزودن سرور لینوکسی و استقرار Veeam Data Mover استفاده می‌شود و در زیرساخت بکاپ ذخیره نمی‌شود. منظور، رمز یک‌بارمصرف برای هر عملیات بکاپ نیست.
اصل حداقل دسترسی (Least Privilege)
در زمان راه‌اندازی اولیه باید از Single-use Credentials متعلق به یک حساب Non-root استفاده شود. این Credentialها فقط برای استقرار مؤلفه‌های موردنیاز Veeam روی Repository Server کاربرد دارند و در زیرساخت Veeam ذخیره نمی‌شوند.
در نتیجه، اگر Veeam Backup Server به خطر بیفتد، مهاجم نمی‌تواند این Credentialها را از آن استخراج و برای ورود به Hardened Repository استفاده کند. حساب مورداستفاده برای استقرار نیز نباید دسترسی دائمی و بیش از نیاز در اختیار داشته باشد.
غیرفعال‌کردن SSH
در روش استقرار مبتنی بر SSH، پس از تکمیل نصب و تأیید ارتباط سرویس‌ها، دسترسی SSH غیرضروری را مطابق مستندات نسخه مورد استفاده غیرفعال کنید. مسیر مدیریت امن و دسترسی کنسول باید از قبل مشخص باشد.
در صورت ضرورت ادامه دسترسی SSH، باید کنترل‌های زیر اعمال شوند:
✓ غیرفعال‌کردن Root Login
✓ محدودکردن دسترسی SSH به حساب‌های مدیریتی مشخص
✓ محدودکردن دسترسی به شبکه‌ها یا IPهای مدیریتی مجاز از طریق Firewall
✓ استفاده از Key-based Authentication به‌جای Password
✓ اعمال Password Policy قوی در صورت استفاده از احراز هویت مبتنی بر Password
✓ ثبت و پایش تلاش‌های ورود و فعالیت‌های مدیریتی
برای جزئیات بیشتر می‌توان به مستندات Veeam درباره Credentialها و تنظیمات SSH مراجعه کرد.
حفاظت دولایه از بکاپ با XFS و ZFS
در معماری مبتنی بر Open‑E JovianVHR، حفاظت فایل‌های بکاپ در Hardened Repository با Snapshotهای ZFS در لایه ذخیره‌سازی تکمیل می‌شود. هدف، کاهش وابستگی حفاظت به یک سازوکار واحد است. اثربخشی این طراحی به تفکیک دسترسی‌های مدیریتی و تنظیم درست سیاست‌های حفاظت در هر دو لایه وابسته است.
ترکیب Linux Hardened Repository، XFS و ZFS
ترکیب LHR، XFS و ZFS علاوه بر بهینه‌سازی Performance عملیات Backup، میان لایه نرم‌افزار Backup و زیرساخت Storage جداسازی ایجاد می‌کند. در نتیجه، به‌خطر‌افتادن یکی از این لایه‌ها لزوماً به حذف تمام Restore Pointها منجر نمی‌شود.
لایه اول: حفاظت از فایل‌های بکاپ با Linux Hardened Repository و XFS
لایه نخست از Linux Hardened Repository و قابلیت‌های امنیتی Linux برای محافظت از Backup Fileها استفاده می‌کند. در این لایه، Veeam دوره Immutability را مدیریت می‌کند و Linux Immutable Attribute از تغییر یا حذف فایل‌های محافظت‌شده از طریق عملیات معمول Repository جلوگیری می‌کند.
XFS نیز با پشتیبانی از Reflink و Veeam Fast Clone، ایجاد سریع‌تر و بهینه‌تر Synthetic Full Backupها را از نظر مصرف فضای Storage امکان‌پذیر می‌سازد.
لایه دوم: حفاظت در سطح Storage با Snapshotهای ZFS
Snapshotهای ZFS وضعیت داده‌ها را در یک نقطه زمانی حفظ می‌کنند. به کمک سازوکار Copy-on-Write، تغییرات بعدی داده‌ها، محتوای فقط‌خواندنی Snapshot را بازنویسی نمی‌کنند.
در Open‑E JovianVHR، مدیریت این Snapshotها در لایه Storage انجام می‌شود. با تفکیک دسترسی‌های مدیریتی این لایه از محیط بکاپ، نفوذ به مخزن Linux Hardened Repository الزاماً به معنی دسترسی به مدیریت Snapshotها نیست.
حفاظت از Snapshotها در برابر حذف، به کنترل دسترسی مدیریتی و تنظیم صحیح سیاست نگهداری وابسته است. همچنین، Snapshot روی همان Storage جایگزین نسخه پشتیبان مستقل نیست.
حفاظت دولایه با Open-E JovianVHR
در مطلب پیشین، Open-E JovianVHR و معماری حفاظت دولایه از بکاپ‌های Veeam را معرفی کردیم. برای بررسی نقش JovianVHR در تکمیل حفاظت Hardened Repository، این راهکار را بیشتر بشناسید.
مزایای تکمیلی Open‑E JovianVHR برای زیرساخت بکاپ
زیرساخت مبتنی بر ZFS در Open‑E JovianVHR علاوه بر ایجاد لایه دوم حفاظت، قابلیت‌های زیر را برای نگهداری و بازیابی Backupهای سازمانی فراهم می‌کند:
یکپارچگی داده‌ها
ZFS با Checksum خطاهای داده را شناسایی می‌کند. ترمیم خودکار زمانی امکان‌پذیر است که نسخه سالم در ساختار افزونه موجود باشد.
افزونگی داده‌ها
آرایش‌هایی مانند Mirror و RAID‑Z، متناسب با طراحی، تحمل خرابی دیسک را فراهم می‌کنند. سطح حفاظت به آرایش انتخاب‌شده وابسته است.
استفاده بهینه از ظرفیت
فشرده‌سازی و حذف داده‌های تکراری می‌توانند مصرف ظرفیت را کاهش دهند. میزان صرفه‌جویی به نوع داده و تنظیمات بستگی دارد.
عملکرد ذخیره‌سازی
قابلیت‌های کش و تنظیمات ذخیره‌سازی می‌توانند عملکرد را بهبود دهند. نتیجه باید با بار کاری واقعی بکاپ و بازیابی ارزیابی شود.
برای بررسی معماری، قابلیت‌های Immutability و مشخصات فنی این راهکار، با Open‑E JovianVHR بیشتر آشنا شوید.
نقش دو لایه حفاظت در معماری پیشنهادی
| لایه | سازوکار اصلی | نقش در حفاظت | شرط مهم |
|---|---|---|---|
| Linux Hardened Repository با XFS | حفاظت تغییرناپذیری فایل‌های بکاپ | محدودکردن تغییر و حذف فایل‌های محافظت‌شده در دوره تعیین‌شده | سخت‌سازی میزبان و کنترل دسترسی مدیریتی |
| لایه ZFS در Open‑E JovianVHR | Snapshotهای نقطه‌زمانی | حفظ وضعیت پیشین داده در لایه ذخیره‌سازی | حفاظت از مدیریت Storage و تنظیم سیاست Snapshot |
این دو لایه مکمل یکدیگرند؛ سطح حفاظت نهایی به پیکربندی و نگهداری هر دو وابسته است.