وقتی باج‌افزار از فایروال عبور می‌کند؛ چرا برنامه بازیابی بخشی از امنیت شبکه است؟

وقتی باج‌افزار از فایروال عبور می‌کند؛ چرا برنامه بازیابی بخشی از امنیت شبکه است؟

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

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

سؤال مهم برای یک سازمان حرفه‌ای فقط این نیست که:

«چگونه جلوی حمله را بگیریم؟»

سؤال مهم‌تر این است:

«اگر یکی از لایه‌های دفاعی شکست خورد، آیا می‌توانیم بدون پرداخت باج و بدون توقف طولانی کسب‌وکار، اطلاعات و سرویس‌ها را برگردانیم؟»

اینجاست که مفهوم بازیابی اطلاعات از یک موضوع صرفاً فنی خارج می‌شود و به بخشی از معماری امنیت سایبری تبدیل می‌گردد.

چرا فایروال به‌تنهایی کافی نیست؟

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

با این حال، فایروال معادل مصونیت کامل نیست.

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

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

در معماری امنیتی بالغ، فرض اصلی این نیست که «هیچ حمله‌ای موفق نمی‌شود». فرض اصلی این است که ممکن است یکی از لایه‌ها در مقطعی شکست بخورد و سیستم باید توان ادامه فعالیت و بازیابی را داشته باشد.

امنیت واقعی از چند لایه تشکیل می‌شود

معماری امنیتی حرفه‌ای را می‌توان در چهار مرحله اصلی خلاصه کرد:

پیشگیری از حمله، شناسایی رفتار مشکوک، محدود کردن دامنه آسیب و بازیابی سرویس‌ها.

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

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

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

این تفاوت میان یک سازمان آسیب‌پذیر و یک سازمان دارای تاب‌آوری سایبری است.

تفاوت Backup، Snapshot و Replication چیست؟

یکی از خطاهای رایج در پروژه‌های زیرساخت، یکی دانستن همه روش‌های حفاظت از اطلاعات است. در حالی که Backup، Snapshot و Replication اهداف متفاوتی دارند و نباید جایگزین یکدیگر در نظر گرفته شوند.

Backup

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

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

Snapshot

Snapshot تصویری از وضعیت اطلاعات در یک زمان مشخص است. این فناوری برای بازگرداندن سریع فایل‌ها یا Volume به وضعیت قبلی بسیار کاربردی است.

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

Replication

Replication اطلاعات را از یک سیستم به سیستم دیگر منتقل می‌کند و برای تداوم سرویس و بازیابی سریع بسیار مفید است.

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

به همین دلیل، معماری حرفه‌ای معمولاً ترکیبی از Backup، Snapshot، Replication و نسخه‌های محافظت‌شده خارج از دسترس مستقیم سیستم اصلی است.

خطر بکاپی که همیشه آنلاین است

یکی از اشتباهات جدی سازمان‌ها این است که تصور می‌کنند داشتن یک NAS یا هارد اکسترنال متصل به شبکه به معنی داشتن بکاپ امن است.

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

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

به همین دلیل باید میان «وجود بکاپ» و «وجود بکاپ قابل‌بازیابی» تفاوت قائل شد.

ممکن است یک شرکت هر شب از اطلاعات خود بکاپ بگیرد، اما در روز بحران متوجه شود:

بکاپ‌ها ناقص هستند،

نسخه‌های اخیر نیز آلوده شده‌اند،

فضای ذخیره‌سازی خراب شده است،

دسترسی به بکاپ با همان حساب‌های آلوده‌شده انجام می‌شود،

یا هیچ‌کس فرایند Restore را آزمایش نکرده است.

در این شرایط، گزارش موفق بودن Job بکاپ تقریباً هیچ ارزشی ندارد.

RPO و RTO؛ دو عددی که مدیران باید بدانند

بحث بکاپ فقط موضوع واحد IT نیست. مدیران ارشد سازمان نیز باید دو مفهوم ساده اما حیاتی را بدانند: RPO و RTO.

RPO

RPO مشخص می‌کند سازمان حداکثر چه مقدار از اطلاعات اخیر خود را می‌تواند از دست بدهد.

برای مثال، اگر RPO برابر یک ساعت باشد، سیستم بکاپ باید طوری طراحی شود که در بدترین حالت حداکثر اطلاعات یک ساعت اخیر از بین برود.

اما اگر سازمان فقط روزی یک بار بکاپ می‌گیرد، در یک حادثه ممکن است تا ۲۴ ساعت داده کاری خود را از دست بدهد.

RTO

RTO مشخص می‌کند یک سرویس در صورت حادثه، حداکثر چه مدت می‌تواند از دسترس خارج باشد.

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

مشکل این است که بسیاری از سازمان‌ها تجهیزات بکاپ می‌خرند بدون اینکه ابتدا RPO و RTO را مشخص کنند.

نتیجه چنین رویکردی معمولاً خرید تجهیزات نامتناسب یا طراحی معماری ناقص است.

سناریوی واقعی: وقتی فایل‌سرور سازمان از دسترس خارج می‌شود

فرض کنید یک شرکت با ۱۵۰ کاربر، اطلاعات مالی، قراردادها، فایل‌های پروژه و اسناد مشتریان را روی یک فایل‌سرور مرکزی نگهداری می‌کند.

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

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

در سازمان اول، تنها یک NAS متصل به Domain وجود دارد و Job بکاپ هر شب اجرا می‌شود. مهاجم پس از دسترسی به حساب مدیریتی، فایل‌های اصلی و نسخه‌های بکاپ را رمزگذاری کرده است.

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

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

تفاوت اصلی در وجود یا عدم وجود برنامه بازیابی است.

چرا معماری امنیت و ذخیره‌سازی باید با هم طراحی شوند؟

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

این رویکرد جزیره‌ای باعث ایجاد شکاف می‌شود.

برای مثال، تیم امنیت ممکن است شبکه را Segment کرده باشد، اما سرور بکاپ همچنان از تمام VLANها قابل‌دسترسی باشد. یا NAS دارای Snapshot باشد، اما حساب‌های مدیریتی آن با همان اطلاعات ورود Domain مدیریت شوند.

در یک معماری صحیح باید مشخص شود:

چه سیستم‌هایی به اطلاعات دسترسی دارند،

بکاپ از چه مسیری منتقل می‌شود،

چه کاربرانی اجازه حذف نسخه‌ها را دارند،

آیا مدیر Domain می‌تواند سیستم بکاپ را نیز مدیریت کند،

آیا نسخه‌ای خارج از سایت وجود دارد،

آیا Snapshotها قابل‌حذف توسط حساب‌های معمول مدیریتی هستند،

و در روز حادثه چه کسی مسئول تصمیم‌گیری برای Restore است.

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

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

تست Restore مهم‌تر از گزارش Backup Successful است

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

نرم‌افزار بکاپ گزارش می‌دهد عملیات با موفقیت انجام شده است و تیم IT تصور می‌کند همه چیز آماده است. اما ممکن است در زمان Restore مشکلاتی ظاهر شوند:

نسخه بکاپ ناقص باشد،

فایل خاصی به‌درستی ذخیره نشده باشد،

زمان بازیابی بسیار طولانی‌تر از حد انتظار باشد،

زیرساخت مقصد ظرفیت لازم را نداشته باشد،

یا مستندات دسترسی ناقص باشند.

به همین دلیل، تست Restore باید بخشی از برنامه عملیاتی سازمان باشد.

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

هدف این است که اولین تجربه Restore سازمان در روز حمله باج‌افزاری نباشد.

بکاپ خارج از سایت چرا اهمیت دارد؟

یکی از اصول مهم برنامه بازیابی این است که تمام نسخه‌های اطلاعات در یک مکان قرار نداشته باشند.

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

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

اما Offsite Backup نیز باید با برنامه انجام شود. صرف انتقال فایل‌ها کافی نیست.

باید مشخص شود:

اطلاعات با چه سرعتی منتقل می‌شوند،

آیا ارتباط رمزگذاری شده است،

چه نسخه‌هایی در مقصد نگهداری می‌شوند،

دسترسی مدیریتی چگونه کنترل می‌شود،

و Restore از سایت دوم چه مدت زمان می‌برد.

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

نقش NAS در برنامه بازیابی اطلاعات

NAS در سازمان‌ها دیگر فقط یک فضای اشتراک فایل ساده نیست. سیستم‌های ذخیره‌سازی حرفه‌ای می‌توانند بخشی مهم از معماری Backup و Disaster Recovery باشند.

بسته به مدل و طراحی زیرساخت، NAS می‌تواند برای موارد مختلف استفاده شود:

نگهداری بکاپ سرورها،

ذخیره Snapshot،

Replication به سایت دوم،

آرشیو اطلاعات،

پشتیبان‌گیری از ماشین‌های مجازی،

و ایجاد لایه جداگانه برای بازیابی سریع.

با این حال، خرید NAS بدون طراحی صحیح نیز مشکل را حل نمی‌کند.

انتخاب تعداد Bay، نوع RAID، ظرفیت هارد، سرعت شبکه، مقدار Cache، نوع فایل‌سیستم، سیاست Snapshot و محل نگهداری نسخه دوم همگی باید بر اساس نیاز واقعی سازمان تعیین شوند.

یک شرکت کوچک با ۲۰ کاربر نیاز متفاوتی با یک سازمان چندشعبه‌ای یا مجموعه دارای زیرساخت مجازی‌سازی دارد.

اشتباهات متداول در برنامه بکاپ سازمانی

برخی اشتباهات بارها در سازمان‌ها تکرار می‌شوند.

اولین اشتباه این است که تنها یک نسخه از اطلاعات وجود دارد و همان نسخه Backup نامیده می‌شود.

دومین اشتباه این است که بکاپ در همان سیستم اصلی ذخیره می‌شود.

سومین اشتباه، استفاده از حساب‌های مدیریتی مشترک برای سرورهای اصلی و سیستم بکاپ است.

چهارمین اشتباه، نبود نسخه خارج از سایت است.

پنجمین اشتباه، نداشتن سیاست نگهداری نسخه‌هاست.

و شاید مهم‌ترین اشتباه، تست نکردن Restore باشد.

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

چک‌لیست ساده آمادگی در برابر حمله باج‌افزاری

قبل از هر بحران، مدیران فناوری اطلاعات باید بتوانند به چند سؤال ساده پاسخ دهند.

آخرین بکاپ سالم کجاست؟

چه کسی می‌تواند آن را حذف کند؟

اگر حساب مدیر Domain هک شود، آیا بکاپ نیز در خطر است؟

آخرین بار چه زمانی Restore آزمایش شده است؟

بازیابی فایل‌سرور اصلی چقدر زمان می‌برد؟

اگر ساختمان اصلی در دسترس نباشد، نسخه دیگری از اطلاعات وجود دارد؟

آیا کاربران به تمام منابع شبکه دسترسی دارند یا Segment بندی انجام شده است؟

آیا تجهیزات امنیتی و سیستم ذخیره‌سازی توسط یک معماری هماهنگ محافظت می‌شوند؟

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

جمع‌بندی

امنیت سایبری فقط ساختن دیوار بلندتر نیست.

فایروال، Endpoint Security، کنترل دسترسی و سیستم‌های تشخیص تهدید برای کاهش احتمال حمله ضروری هستند، اما معماری امنیتی زمانی کامل می‌شود که سازمان برای روز شکست یکی از این لایه‌ها نیز برنامه داشته باشد.

باج‌افزار زمانی به یک بحران جدی تبدیل می‌شود که سازمان نتواند اطلاعات خود را بازیابی کند.

بنابراین، برنامه امنیت حرفه‌ای باید سه هدف هم‌زمان داشته باشد:

کاهش احتمال نفوذ،

محدود کردن دامنه آسیب،

و بازگرداندن سریع اطلاعات و سرویس‌ها.

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

در نهایت، پرسش حرفه‌ای این نیست که «آیا ممکن است روزی مورد حمله قرار بگیریم؟»

پرسش درست این است:

«اگر فردا صبح بخشی از اطلاعات سازمان در دسترس نباشد، دقیقاً از کجا، با چه نسخه‌ای و در چه مدت زمانی آن را بازیابی خواهیم کرد؟»

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