وقتی اطلاعات سازمان، سرویس‌های کاربردی و ارتباط شعب به زیرساخت فناوری اطلاعات وابسته‌اند، خرابی سرور یا از دست رفتن دسترسی می‌تواند فعالیت مجموعه را مختل کند. صرفاً داشتن فضای ابری یا تهیهٔ نسخهٔ پشتیبان برای مدیریت این ریسک کافی نیست؛ باید بدانیم چه اطلاعاتی را با چه فاصله‌ای ذخیره می‌کنیم، چگونه سرورها را در دسترس کاربران مجاز قرار می‌دهیم و هویت و منابع پراکنده را چطور به شکلی کنترل‌شده مدیریت می‌کنیم.
در این راهنما سه موضوع به‌هم‌پیوسته را بررسی می‌کنیم: طراحی پلن بکاپ و بازیابی، انتشار امن سرورها در اینترنت و یکپارچه‌سازی منابع سازمانی. هدف، ساخت زیرساختی است که در برابر خرابی، خطای انسانی و تهدیدات امنیتی تاب‌آوری بیشتری داشته باشد و در زمان بروز مشکل، مسیر بازیابی آن از قبل مشخص باشد.
۱. طراحی پلن بکاپ و بازیابی اطلاعات سازمانی
پلن بکاپ باید بر اساس اهمیت اطلاعات و میزان قابل‌قبول اختلال طراحی شود، نه صرفاً بر اساس ظرفیت هارددیسک یا امکان گرفتن یک کپی روزانه. پایگاه دادهٔ نرم‌افزارهای مالی، پرونده‌های کاربران، فایل‌های اشتراکی، تنظیمات سرورها و اطلاعات هویتی ممکن است به روش‌ها و زمان‌بندی‌های متفاوتی برای پشتیبان‌گیری نیاز داشته باشند.
تعیین RPO و RTO
- RPO یا نقطهٔ هدف بازیابی: مشخص می‌کند سازمان حداکثر چه مقدار از داده‌های جدید را می‌تواند در رخدادی مانند خرابی یا حمله از دست بدهد. برای مثال، RPO چهار ساعت یعنی برنامهٔ بازیابی باید طوری طراحی شود که از دست رفتن داده از این بازه بیشتر نشود.
- RTO یا زمان هدف بازیابی: مدت زمانی است که کسب‌وکار می‌تواند توقف یک سرویس را تحمل کند. اگر سرویس حیاتی باید حداکثر طی چهار ساعت برگردد، فرآیند بازیابی، دسترسی به نسخه‌ها و ظرفیت جایگزین باید با این هدف سازگار باشد.
RPO و RTO دو شاخص متفاوت‌اند. گرفتن نسخهٔ پشتیبان هر چهار ساعت لزوماً به معنی بازیابی سرویس در چهار ساعت نیست؛ سرعت انتقال داده، حجم اطلاعات، وابستگی سرویس‌ها و زمان اعتبارسنجی نیز باید در برنامه لحاظ شوند.
انتخاب نوع و زمان‌بندی بکاپ
- نسخهٔ کامل: یک نسخهٔ کامل از محدودهٔ انتخاب‌شده می‌سازد؛ بازیابی آن معمولاً ساده‌تر است، اما فضای ذخیره‌سازی و زمان بیشتری ممکن است نیاز داشته باشد.
- نسخهٔ افزایشی: تغییرات پس از نقطهٔ پشتیبان‌گیری قبلی را ثبت می‌کند و می‌تواند حجم هر نوبت را کاهش دهد؛ زنجیرهٔ نسخه‌ها باید به‌درستی نگهداری و آزمایش شود.
- نسخهٔ تفاضلی: تغییرات پس از آخرین نسخهٔ کامل را نگه می‌دارد و در طراحی مناسب می‌تواند توازنی میان زمان تهیه و زمان بازیابی فراهم کند.
برای انتخاب روش، حجم داده، نرخ تغییر، پنجرهٔ نگهداری، سرعت شبکه و زمان موردنیاز برای برگرداندن سرویس باید بررسی شوند. نسخه‌برداری از ماشین مجازی یا Snapshot به‌تنهایی جایگزین بکاپ مستقل و آزموده‌شده نیست؛ خرابی فضای ذخیره‌سازی یا دسترسی مخرب ممکن است هم دادهٔ اصلی و هم Snapshot را تحت تأثیر قرار دهد.
اصل تنوع، جداسازی و محافظت از نسخه‌ها
یکی از الگوهای شناخته‌شده، قاعدهٔ ۳-۲-۱ است: نگهداری چند نسخه از اطلاعات، استفاده از بیش از یک نوع رسانه یا محل نگهداری، و داشتن یک نسخه در محل جداگانه. بسته به ریسک سازمان، بهتر است دست‌کم یک نسخه آفلاین یا با کنترل‌های قوی در برابر تغییر و حذف ناخواسته نیز در نظر گرفته شود.
- دسترسی مدیریتی سامانهٔ بکاپ را از دسترسی روزمرهٔ کاربران و سرورهای عملیاتی جدا کنید.
- در صورت پشتیبانی راهکار، از نگهداری تغییرناپذیر نسخه‌ها، دورهٔ نگهداری محافظت‌شده و کنترل تأیید چندنفره برای عملیات حساس استفاده کنید.
- انتقال و ذخیره‌سازی نسخه‌های حساس را با رمزنگاری مناسب محافظت کنید و کلیدهای رمزنگاری را مستقل و مستند نگه دارید.
- برای نسخه‌های ابری، مجوزها، هزینهٔ نگهداری، محل ذخیره، محدودیت‌های بازیابی و امکان خروج داده از سرویس را از قبل ارزیابی کنید.
- هشدار شکست کارهای بکاپ، کاهش فضای آزاد و حذف یا تغییر غیرمنتظرهٔ نسخه‌ها را به مسئول مشخصی متصل کنید.
در راهنمای CISA دربارهٔ مقابله با باج‌افزار بر نگهداری نسخه‌های پشتیبان رمزگذاری‌شده و آفلاین و آزمایش منظم دسترس‌پذیری و سلامت آن‌ها تأکید شده است. در محیط‌های ابری نیز قابلیت‌هایی نظیر حذف نرم، مخزن تغییرناپذیر و تأیید چندنفره می‌توانند در برابر حذف مخرب یا خطای مدیریتی کمک‌کننده باشند؛ جزئیات پیاده‌سازی به سرویس و طرح انتخابی وابسته است. برای نمونه، مستندات قابلیت‌های امنیتی Azure Backup این کنترل‌ها را توضیح می‌دهد.
آزمون بازیابی؛ مهم‌تر از سبز بودن گزارش بکاپ
موفقیت یک کار زمان‌بندی‌شده تنها نشان می‌دهد عملیات پشتیبان‌گیری بدون خطای گزارش‌شده پایان یافته است. تا وقتی بازیابی واقعی آزمایش نشده، نمی‌توان از سالم بودن نسخه و امکان بازگشت سرویس اطمینان کافی داشت.
- بکاپ را در محیطی جدا از سامانهٔ عملیاتی بازیابی کنید.
- سلامت فایل‌ها، سازگاری پایگاه داده و دسترسی برنامه به وابستگی‌های لازم را بررسی کنید.
- زمان واقعی بازگرداندن داده و سرویس را اندازه‌گیری و با RTO مقایسه کنید.
- میزان دادهٔ قابل‌بازیابی و فاصلهٔ آن با آخرین تغییرات را با RPO مقایسه کنید.
- نتیجه، مسئولیت‌ها، دسترسی‌ها و مراحل اصلاح مشکل را مستند کنید و آزمون را در بازه‌های برنامه‌ریزی‌شده تکرار کنید.
۲. انتشار امن سرورها در اینترنت
هر سروری نباید مستقیماً از اینترنت قابل‌دسترسی باشد. ابتدا باید فهرست سرویس‌ها و آدرس‌های در دسترس، نیاز واقعی کسب‌وکار و وابستگی‌های فنی مشخص شود. سپس تنها خدمات ضروری منتشر شوند و دسترسی مدیریتی و ارتباطات داخلی تا حد امکان از مسیرهای محدود و کنترل‌شده انجام شوند.
کاهش سطح مواجهه و طراحی مسیر دسترسی
- فقط سرویس‌هایی را عمومی کنید که واقعاً به کاربران یا سامانه‌های بیرونی نیاز دارند.
- برای وب‌سایت‌ها و APIها، در صورت تناسب معماری از Reverse Proxy و در کاربردهای مناسب از WAF استفاده کنید؛ این ابزارها جایگزین وصله‌کردن نرم‌افزار یا تنظیم امن خود سرور نیستند.
- سرویس‌های عمومی را در ناحیه‌ای جدا مانند DMZ قرار دهید و ارتباط آن‌ها با شبکهٔ داخلی را فقط به جریان‌های ضروری و مشخص محدود کنید.
- دسترسی مدیریتی را از مسیرهایی مانند VPN یا میزبان واسط امن و تحت نظارت انجام دهید؛ از انتشار مستقیم رابط‌های مدیریتی حساس در اینترنت اجتناب کنید.
- قوانین فایروال ورودی و خروجی را بر اساس نیاز واقعی تنظیم و به‌صورت دوره‌ای بازبینی کنید.
راهنمای CISA برای کاهش مواجههٔ اینترنتی بر شناسایی دارایی‌های در معرض اینترنت، حذف دسترسی‌های غیرضروری، به‌روزرسانی سیستم‌ها، استفاده از میزبان واسط امن، احراز هویت چندمرحله‌ای و پایش ترافیک تأکید دارد. همین رویکرد باید در برنامهٔ راهنمای انتشار امن سرور روی اینترنت">انتشار امن سرور روی اینترنت و طراحی لایه‌های حفاظتی شبکه نیز رعایت شود.
رمزنگاری، احراز هویت و نگهداری مستمر
- برای ارتباطات وب از TLS با گواهی معتبر و پیکربندی متناسب با برنامه استفاده کنید و تاریخ انقضای گواهی‌ها را پایش کنید.
- برای حساب‌های مدیریتی احراز هویت چندمرحله‌ای را فعال کنید و دسترسی‌ها را بر مبنای حداقل مجوز لازم بدهید.
- سیستم‌عامل، وب‌سرور، برنامه‌ها، تجهیزات مرزی و وابستگی‌های نرم‌افزاری را با برنامهٔ مشخص وصله کنید.
- گزارش ورودهای ناموفق، تغییر قوانین فایروال، خطاهای برنامه و ترافیک غیرمعمول را ثبت و بازبینی کنید.
- در زمان تغییر معماری، انتشار سرویس جدید یا تغییر قواعد دسترسی، آزمون و بازبینی امنیتی را بخشی از فرآیند انتشار قرار دهید.
امنیت سرور یک اقدام یک‌باره نیست. بعد از انتشار اولیه باید تغییرات نشانی‌ها و پورت‌ها، سرویس‌های تازه، حساب‌های غیرفعال، گواهی‌ها، نسخه‌های نرم‌افزار و هشدارهای امنیتی مرتب بررسی شوند. برای تکمیل این بخش می‌توانید راهنمای پیاده‌سازی امنیت شبکه">راهنمای پیاده‌سازی امنیت شبکه و مطلب آشنایی با نسل جدید دیوار آتش (NGFW)">نسل جدید دیوار آتش (NGFW) را نیز مطالعه کنید.
۳. یکپارچه‌سازی دامنه‌ها، کاربران و منابع سازمانی
سازمان‌هایی که شعب، سرورهای متعدد یا دامین‌های پراکنده دارند، ممکن است با حساب‌های تکراری، سیاست‌های متفاوت، دسترسی‌های دشوار و مدیریت پرهزینه روبه‌رو شوند. یکپارچه‌سازی منابع سازمانی با هدف ساده‌تر شدن مدیریت هویت، اعمال سیاست‌های هماهنگ و کنترل دسترسی‌ها انجام می‌شود؛ اما الزاماً به این معنا نیست که همهٔ دامنه‌ها باید بدون ارزیابی در یک دامنه ادغام شوند.
شناخت وضعیت موجود پیش از ادغام
پیش از طراحی باید دامنه‌ها، جنگل‌های Active Directory، رابطه‌های اعتماد، DNS، سایت‌ها و زیرشبکه‌ها، حساب‌های سرویس، برنامه‌های وابسته به هویت و الزامات امنیتی شناسایی شوند. محدودیت‌های شعب، دسترسی شبکه، حساسیت داده‌ها و تفاوت سیاست‌ها نیز باید مستند شوند.
مستندات Active Directory Domain Services توضیح می‌دهد که AD DS برای سازمان‌دهی هویت‌ها و اشیای شبکه، احراز هویت، کنترل دسترسی و مدیریت مبتنی بر سیاست‌ها به کار می‌رود. در سناریوهای ابری و ترکیبی نیز لازم است تفاوت میان AD DS خودمدیریت‌شده و راهکارهای هویت ابری در نظر گرفته شود؛ برای این انتخاب، مقایسهٔ راهکارهای هویت Microsoft مرجع مناسبی است.
انتخاب معماری مناسب
- مدیریت متمرکز در یک ساختار موجود: ممکن است برای سازمانی مناسب باشد که ساختار دامنه‌ای آن از ابتدا برای مدیریت مشترک طراحی شده است.
- ایجاد رابطهٔ اعتماد: در شرایطی که جداسازی دامنه‌ها باید حفظ شود اما تبادل هویت یا دسترسی محدود لازم است، می‌توان رابطهٔ اعتماد را پس از ارزیابی امنیتی بررسی کرد.
- مهاجرت مرحله‌ای: وقتی ادغام واقعی لازم است، انتقال کاربران، گروه‌ها، دستگاه‌ها، منابع و وابستگی‌های برنامه‌ای باید با برنامهٔ بازگشت و آزمون انجام شود.
- معماری ترکیبی: ممکن است بخشی از خدمات در محیط داخلی و بخشی در ابر اجرا شوند؛ در این حالت سازگاری هویت، DNS، ارتباط امن، پایداری اتصال و مدل مسئولیت امنیتی اهمیت دارد.
هیچ‌یک از این الگوها برای همهٔ سازمان‌ها بهترین انتخاب نیست. تصمیم نهایی باید بر اساس ساختار موجود، نیاز برنامه‌ها، سطح جداسازی موردنیاز و هزینهٔ عملیاتی گرفته شود. برای آشنایی با بستر کلی شبکه، راهنمای جامع شبکه‌های کامپیوتری">راهنمای جامع شبکه‌های کامپیوتری می‌تواند نقطهٔ شروع مناسبی باشد.
کنترل دسترسی و برنامهٔ مهاجرت
- ساختار فعلی کاربران، گروه‌ها، واحدهای سازمانی و مجوزها را مستند کنید.
- حساب‌های تکراری، حساب‌های قدیمی، حساب‌های سرویس و دسترسی‌های بیش از حد را شناسایی کنید.
- ساختار مقصد، قواعد نام‌گذاری، DNS، گروه‌های دسترسی، سیاست‌های امنیتی و مسئولیت مدیریت را طراحی کنید.
- ابتدا یک گروه یا شعبهٔ آزمایشی را منتقل کنید و سازگاری ورود کاربران، دسترسی برنامه‌ها و چاپگرها و منابع فایل را بررسی کنید.
- برای هر مرحله معیار موفقیت، پنجرهٔ تغییر، مالک تصمیم‌گیری و روش بازگشت تعیین کنید.
- پس از مهاجرت، گزارش‌گیری از رخدادهای هویتی، بازبینی مجوزها و آزمون بازیابی خدمات هویتی را در برنامهٔ نگهداری قرار دهید.
در این بخش، یکپارچه‌سازی باید با خدمات مایکروسافت و سرورهای سازمانی">طراحی خدمات مایکروسافت و سرورهای سازمانی و سیاست‌های خدمات پشتیبانی شبکه">پشتیبانی و نگهداری شبکه هماهنگ باشد. تمرکز صرف بر انتقال حساب‌ها، بدون توجه به وابستگی برنامه‌ها و مجوزها، می‌تواند باعث اختلال در فعالیت روزمره شود.
۴. برنامهٔ اجرایی پیشنهادی برای سازمان
برای جلوگیری از تغییرات پرریسک و هزینه‌های پیش‌بینی‌نشده، این سه حوزه را در یک برنامهٔ مرحله‌ای پیش ببرید:
- ارزیابی و اولویت‌بندی: سرویس‌های حیاتی، دارایی‌های اینترنتی، داده‌های حساس، وابستگی برنامه‌ها و ریسک‌های فعلی را شناسایی کنید.
- تعیین اهداف: برای سامانه‌های مهم، RPO، RTO، سطح دسترس‌پذیری و مسئولیت بازیابی را مشخص کنید.
- طراحی: محل نگهداری بکاپ، کنترل‌های دسترسی، مسیر انتشار سرورها، معماری هویت و نیازهای ارتباط بین شعب را مستند کنید.
- پیاده‌سازی آزمایشی: ابتدا روی یک سرویس یا محدودهٔ محدود تغییرات را اجرا کنید؛ خروجی‌ها را با معیارهای از پیش تعیین‌شده بسنجید.
- آزمون و تحویل: بازیابی واقعی، سناریوی قطع ارتباط، اعتبارسنجی دسترسی‌ها و بازگشت به وضعیت قبلی را بررسی کنید.
- پایش مستمر: نسخه‌های بکاپ، ظرفیت، رخدادهای امنیتی، مجوزها، وصله‌ها و تغییرات زیرساخت را در برنامهٔ نگهداری قرار دهید.
۵. چک‌لیست بازبینی زیرساخت
- آیا برای هر سرویس حیاتی RPO و RTO مشخص و تأیید شده است؟
- آیا نسخهٔ پشتیبان مستقل از محیط عملیاتی نگهداری می‌شود و در برابر حذف مخرب محافظت کافی دارد؟
- آیا بازیابی واقعی در محیط آزمایشی انجام شده و زمان آن اندازه‌گیری شده است؟
- آیا همهٔ پورت‌ها و سرویس‌های در معرض اینترنت ثبت شده‌اند و ضرورت انتشار هرکدام مشخص است؟
- آیا دسترسی مدیریتی محدود، محافظت‌شده و قابل‌ردیابی است؟
- آیا ساختار دامنه، هویت‌ها، وابستگی برنامه‌ها و مجوزهای منابع پیش از ادغام مستند شده‌اند؟
- آیا برای تغییرات مهم، برنامهٔ آزمون، مسئول اجرا و مسیر بازگشت وجود دارد؟
- آیا هشدارها و رخدادها به مسئول مشخصی می‌رسند و به‌صورت دوره‌ای بازبینی می‌شوند؟
۶. پرسش‌های متداول
آیا بکاپ ابری به‌تنهایی کافی است؟
لزوماً خیر. باید سطح جداسازی، مجوزها، حفاظت از حذف، رمزنگاری، دورهٔ نگهداری و امکان بازیابی بررسی شود. بر اساس ریسک سازمان ممکن است نگهداری یک نسخهٔ جداگانه یا آفلاین نیز لازم باشد.
هر چند وقت یک‌بار باید بکاپ تهیه کنیم؟
زمان‌بندی باید با RPO، میزان تغییر داده، اهمیت سرویس و توان بازیابی هماهنگ باشد. داده‌های پرتغییر ممکن است به نسخه‌های مکررتر نیاز داشته باشند؛ یک زمان‌بندی ثابت برای تمام سامانه‌ها الزاماً مناسب نیست.
آیا برای انتشار امن سرور همیشه به WAF نیاز داریم؟
خیر؛ نیاز به WAF به نوع سرویس، معماری، تهدیدات و الزامات سازمان بستگی دارد. در هر صورت، محدودسازی سطح دسترسی، وصله‌کردن، پیکربندی امن، محافظت از حساب‌های مدیریتی و پایش باید با توجه به ریسک اجرا شوند.
آیا باید همهٔ دامنه‌های سازمان را با هم ادغام کنیم؟
نه لزوماً. گاهی مدیریت متمرکز یا رابطهٔ اعتماد مناسب‌تر است؛ در موارد دیگر ممکن است مهاجرت مرحله‌ای لازم باشد. تصمیم باید پس از بررسی ساختار موجود، وابستگی‌ها، سیاست امنیتی و نیازهای عملیاتی گرفته شود.
جمع‌بندی
زیرساخت قابل‌اعتماد تنها با خرید فضای ابری، تهیهٔ بکاپ یا نصب فایروال ساخته نمی‌شود. سازمان به برنامهٔ بازیابی آزموده‌شده، انتشار کنترل‌شدهٔ سرویس‌ها و معماری هویت و منابع هماهنگ نیاز دارد. وقتی این سه حوزه با ارزیابی ریسک، مستندسازی، کنترل دسترسی و آزمون دوره‌ای پیش بروند، احتمال توقف طولانی‌مدت کاهش می‌یابد و مدیریت زیرساخت قابل‌پیش‌بینی‌تر می‌شود.
برای ارزیابی زیرساخت و انتخاب راهکار متناسب با نیاز مجموعه، می‌توانید از درخواست مشاوره و خدمات و پشتیبانی استفاده کنید یا از طریق صفحهٔ تماس با واریان شبکه گستر با کارشناسان شرکت در ارتباط باشید.
