امنیت سرور اختصاصی از لحظه تحویل سرور آغاز میشود و تا پایان چرخه عمر آن ادامه دارد. کنترل دسترسی، سخت سازی سیستم عامل، مدیریت آسیب پذیری، ثبت لاگ، مانیتورینگ و پاسخ به رخداد باید یک برنامه یکپارچه باشند. اگر یکی از این لایهها حذف شود، تیم فنی یا دیر متوجه نفوذ میشود یا شواهد کافی برای مهار و بررسی آن در اختیار نخواهد داشت.
این مقاله یک مرجع اجرایی برای CISO، مدیر زیرساخت و تیم DevOps است. تمرکز آن بر تصمیمهایی است که باید در سطح معماری، پیکربندی و عملیات روزانه گرفته شوند. هدف، ارائه نسخه واحد برای همه محیطها نیست؛ هر کنترل باید با حساسیت داده، مدل تهدید، الزامات کسب و کار و مسئولیتهای دیتاسنتر هماهنگ شود.
امنیت سرور اختصاصی چیست
امنیت سرور اختصاصی مجموعه کنترلهایی است که محرمانگی، یکپارچگی و دسترس پذیری سیستم عامل، سرویسها و دادهها را حفظ میکند. این کنترلها باید از دسترسی غیرمجاز جلوگیری کنند، احتمال بهره برداری از ضعفها را کاهش دهند، رفتار مشکوک را تشخیص دهند و امکان بازیابی کنترل شده سرویس را فراهم کنند.
مالک سرور در محیط اختصاصی آزادی بیشتری برای انتخاب سیستم عامل، شبکه و ابزارهای امنیتی دارد، اما همین آزادی مسئولیت بیشتری ایجاد میکند. نبود همسایه در لایه سیستم عامل به معنی امن بودن سرور نیست. حساب مدیریتی ضعیف، سرویس منسوخ، پورت باز یا نسخه پشتیبان متصل میتواند کل محیط را در معرض خطر قرار دهد.
مرز مسئولیت دیتاسنتر و مالک سرور
در طراحی امنیت سرور اختصاصی، پیش از اجرای کنترلها باید مرز مسئولیت مستند شود. دیتاسنتر معمولاً امنیت فیزیکی، برق، سرمایش، اتصال شبکه و بخشی از حفاظت لبه را مدیریت میکند. مالک یا بهره بردار سرور مسئول سیستم عامل، حسابها، سرویسها، دادهها، وصلهها، لاگها و فرایند پاسخ به رخداد است. جزئیات دقیق به قرارداد و نوع سرویس مدیریت شده یا مدیریت نشده بستگی دارد.
| حوزه | مسئول اصلی | سوال کنترلی |
|---|---|---|
| امنیت فیزیکی | دیتاسنتر | کنترل ورود، ثبت تردد و حفاظت رک چگونه انجام میشود |
| شبکه بالادستی و DDoS | دیتاسنتر و مشتری | چه ظرفیتی برای تشخیص و کاهش حمله در لبه وجود دارد |
| سیستم عامل و سرویسها | مالک سرور | چه خط مبنا و برنامه وصلهای اجرا میشود |
| داده و نسخه پشتیبان | مالک سرور | نسخهها کجا نگهداری و چگونه بازیابی میشوند |
| لاگ و پاسخ به رخداد | مالک سرور با همکاری دیتاسنتر | چه دادهای در زمان رخداد قابل دریافت است |
چارچوب مدیریت امنیت سرور اختصاصی
برنامه امنیت سرور اختصاصی بهتر است بر چرخه کامل مدیریت ریسک استوار باشد. چارچوب امنیت سایبری NIST این چرخه را با شش کارکرد حاکمیت، شناسایی، حفاظت، تشخیص، پاسخ و بازیابی توضیح میدهد. این نگاه مانع از آن میشود که تیم فقط روی پیشگیری تمرکز کند و مانیتورینگ یا بازیابی را به بعد موکول کند.
- حاکمیت: مالک کنترلها، سطح ریسک قابل قبول، استثناها و معیارهای گزارش دهی را مشخص کنید.
- شناسایی: داراییها، سرویسها، دادهها، وابستگیها و مسیرهای دسترسی را ثبت کنید.
- حفاظت: سخت سازی، کنترل دسترسی، فایروال، رمزنگاری و مدیریت وصله را اجرا کنید.
- تشخیص: متریک، لاگ، یکپارچگی فایل و رفتار شبکه را پایش کنید.
- پاسخ: برای رخدادهای محتمل راهنمای اقدام، نقشها و مسیر تصمیم گیری داشته باشید.
- بازیابی: نسخه پشتیبان قابل اعتماد، اولویت سرویسها و آزمون بازگشت به شرایط عادی را تعریف کنید.
شناسایی دارایی و خط مبنای امن
بدون فهرست دارایی، امنیت سرور اختصاصی قابل مدیریت نیست. تیم باید بداند چه سیستم عامل، بسته، سرویس، پورت، حساب، کلید، گواهی و عامل مانیتورینگ روی سرور وجود دارد. هر مورد باید مالک، کاربرد، نسخه و وضعیت پشتیبانی مشخص داشته باشد.
خط مبنای امن باید قابل تکرار باشد. میتوان تنظیمات پایه را با راهنماهای CIS Benchmarks تطبیق داد و سپس آن را با نیاز سرویس تنظیم کرد. هر انحراف از خط مبنا باید دلیل، مالک و تاریخ بازبینی داشته باشد. برای محیطهای بزرگ، مدیریت پیکربندی به صورت کد و کنترل نسخه، خطاهای دستی را کاهش میدهد و مقایسه تغییرات را آسان میکند.
سخت سازی سیستم عامل برای امنیت سرور اختصاصی
سخت سازی پایه اصلی امنیت سرور اختصاصی است. نصب حداقلی، غیرفعال کردن قابلیتهای بلااستفاده و محدود کردن سطح دسترسی، سطح حمله را کاهش میدهد. سخت سازی باید پیش از ورود سرور به محیط عملیاتی انجام شود و پس از هر تغییر مهم دوباره ارزیابی شود.
- فقط بستهها و سرویسهای ضروری را نصب و فعال کنید.
- بوت امن، تنظیمات کرنل و سیاستهای ماژولها را متناسب با سیستم عامل بررسی کنید.
- مجوز فایلها و مسیرهای حساس را بازبینی و دسترسی نوشتن را محدود کنید.
- برای پارتیشنها و نقاط اتصال حساس، گزینههای محدودکننده مناسب مانند noexec یا nosuid را پس از آزمون سازگاری ارزیابی کنید.
- ساعت سیستم را با منبع قابل اعتماد هماهنگ کنید تا ترتیب رویدادها و تحلیل لاگ معتبر بماند.
- نصب نرم افزار خارج از مخازن یا فرایند تایید شده را مسدود یا کنترل کنید.
مدیریت هویت و دسترسی در امنیت سرور اختصاصی
بخش بزرگی از حملات از حسابهای معتبر اما سرقت شده استفاده میکنند. امنیت سرور اختصاصی باید دسترسی مدیریتی را محدود، قابل انتساب و قابل بازبینی کند. حساب مشترک، کلید بدون مالک و دسترسی دائمی سطح بالا، تحلیل رخداد و پاسخ گویی را دشوار میکنند.
کنترل های ضروری دسترسی
- برای هر فرد حساب مستقل ایجاد کنید و حسابهای مشترک را حذف کنید.
- اصل حداقل دسترسی را برای کاربران، سرویسها و وظایف خودکار اجرا کنید.
- دسترسی مدیریتی را از شبکه یا میزبان واسط مشخص انجام دهید.
- برای پنلها، VPN و دسترسیهای حساس احراز هویت چندمرحلهای فعال کنید.
- کلیدها و توکنها را در سامانه مدیریت اسرار نگهداری و دورهای چرخش دهید.
- دسترسی کارکنان جداشده، پیمانکاران و حسابهای موقت را سریع لغو کنید.
- استفاده از sudo و تغییرات سطح دسترسی را ثبت و بازبینی کنید.
ایمن سازی SSH
در سرورهای لینوکسی، SSH یکی از مهمترین مسیرهای مدیریت است. برای حفظ امنیت سرور اختصاصی، ورود مستقیم Root را غیرفعال کنید، احراز هویت مبتنی بر کلید را در اولویت قرار دهید و کاربران مجاز را صریحاً محدود کنید. اگر دسترسی از اینترنت عمومی لازم نیست، SSH را پشت VPN یا شبکه مدیریتی قرار دهید.
تغییر پورت پیش فرض میتواند بخشی از اسکنهای خودکار را کاهش دهد، اما کنترل امنیتی اصلی نیست. کیفیت کلید، محدودیت مبدأ، MFA، ثبت رویداد و واکنش به تلاشهای تکراری اثر بیشتری دارند. هر تغییر در پیکربندی SSH باید در یک نشست جداگانه آزمایش شود تا تیم به دلیل خطای تنظیمات از سرور خارج نماند.
نقش امنیت شبکه در امنیت سرور اختصاصی
طراحی شبکه در امنیت سرور اختصاصی باید بر اصل منع پیش فرض استوار باشد. فقط پورتها، پروتکلها و مبدأهای موردنیاز را مجاز کنید. قوانین ورودی و خروجی هر دو اهمیت دارند؛ فیلتر خروجی میتواند ارتباط بدافزار با زیرساخت مهاجم یا انتقال غیرعادی داده را محدود کند.
- رابط مدیریت را از ترافیک سرویس عمومی جدا کنید.
- بین وب، برنامه، پایگاه داده و سامانه پشتیبان گیری تفکیک شبکه ایجاد کنید.
- IPv4 و IPv6 را هم زمان در قواعد فایروال پوشش دهید؛ غیرفعال بودن یکی را فرض نکنید.
- پورتهای در حال گوش دادن را با فهرست مصوب مقایسه و ایجاد پورت جدید را هشدار دهید.
- برای سرویسهای عمومی، ظرفیت و فرایند کاهش DDoS را با دیتاسنتر از پیش مشخص کنید.
- پنلهای مدیریتی و پایگاه داده را مستقیماً در اینترنت منتشر نکنید.
مدیریت آسیب پذیری و وصله برای امنیت سرور اختصاصی
مدیریت وصله باید بر اساس ریسک انجام شود، نه صرفاً تقویم. برای امنیت سرور اختصاصی، ابتدا همه نرم افزارها و نسخهها را شناسایی کنید، سپس آسیب پذیری را با میزان مواجهه، امکان بهره برداری و اهمیت سرویس بسنجید. یک ضعف بحرانی روی سرویس اینترنتی اولویت بیشتری از ضعفی با دسترسی محلی و کنترل شده دارد.
وصلههای حساس را در محیط آزمایشی یا روی نمونه همسان بررسی کنید. اگر نصب فوری ممکن نیست، کنترل جبرانی مانند محدود کردن دسترسی، غیرفعال کردن قابلیت آسیب پذیر یا قانون موقت فایروال تعریف کنید. پایان پشتیبانی سیستم عامل یا نرم افزار باید به برنامه مهاجرت منجر شود؛ باقی ماندن روی نسخه منسوخ یک استثنای دائمی قابل قبول نیست.
امنیت سرویس و داده در امنیت سرور اختصاصی
هر سرویس باید مستقل از سیستم عامل سخت سازی شود. وب سرور، پایگاه داده، کنترل پنل، عامل مانیتورینگ و ابزار پشتیبان گیری حساب، پورت، فایل تنظیمات و چرخه به روزرسانی جداگانه دارند. امنیت سرور اختصاصی زمانی کامل است که این وابستگیها نیز در ارزیابی و مانیتورینگ پوشش داده شوند.
رمزنگاری و مدیریت کلید
برای داده در حال انتقال از TLS با نسخه و تنظیمات پشتیبانی شده استفاده کنید. اعتبار گواهی، زنجیره اعتماد و تاریخ انقضا را مانیتور کنید. داده ذخیره شده و نسخه پشتیبان را بر اساس حساسیت رمزنگاری کنید و کلید رمزنگاری را کنار همان داده نگه ندارید. چرخش، لغو و دسترسی به کلید باید ثبت شود.
پشتیبان گیری در برنامه امنیت سرور اختصاصی
نسخه پشتیبان بخشی از امنیت سرور اختصاصی و برنامه بازیابی است. داشتن فایل پشتیبان بدون آزمون بازیابی، اطمینان کاذب ایجاد میکند. نسخهها باید از سرور اصلی جدا، در برابر حذف یا تغییر غیرمجاز محافظت و متناسب با حساسیت داده رمزنگاری شوند.
- برای سرویسهای حیاتی، RPO و RTO را با مالک کسب و کار تعیین کنید.
- حداقل یک نسخه خارج از محیط اصلی و یک نسخه آفلاین یا تغییرناپذیر نگه دارید.
- دسترسی سامانه پشتیبان گیری را از حسابهای عادی مدیریت سرور جدا کنید.
- موفقیت کار زمان بندی شده، حجم خروجی و خطاهای انتقال را مانیتور کنید.
- بازیابی نمونه و سناریوی بازیابی کامل را دورهای آزمایش و زمان واقعی آن را ثبت کنید.
مانیتورینگ سرور اختصاصی
مانیتورینگ سرور اختصاصی باید هم سلامت سرویس و هم نشانههای امنیتی را پوشش دهد. مشاهده مصرف CPU و RAM برای عملیات ضروری است، اما برای تشخیص رخداد کافی نیست. تیم باید بداند چه رفتارهایی طبیعی هستند، کدام تغییرها مجازند و چه انحرافی نیازمند بررسی فوری است.
در معماری امنیت سرور اختصاصی، دادههای مانیتورینگ باید از چند لایه جمع شوند: سخت افزار و سیستم عامل، سرویس، شبکه، هویت، فایلهای حساس و سامانه پشتیبان گیری. ترکیب این سیگنالها دقت تشخیص را بالا میبرد و از وابستگی به یک هشدار منفرد جلوگیری میکند.
| لایه | نمونه سیگنال | ریسک یا پیامد |
|---|---|---|
| منابع | CPU RAM دیسک inode و load | اختلال، استخراج رمزارز یا نشت حافظه |
| سرویس | وضعیت پردازش، زمان پاسخ و خطا | توقف سرویس یا تغییر غیرمجاز |
| هویت | ورود موفق و ناموفق، sudo و تغییر حساب | Brute Force یا سوءاستفاده از اعتبارنامه |
| شبکه | ترافیک خروجی، اتصال و پورت جدید | نشت داده، C2 یا پیکربندی اشتباه |
| فایل | تغییر باینری و تنظیمات حساس | دستکاری، وب شل یا Persistence |
| بازیابی | شکست Backup و آزمون Restore | ناتوانی در بازیابی پس از رخداد |
متریک های عملیاتی با ارزش امنیتی
مصرف ناگهانی CPU یا حافظه میتواند نتیجه بار واقعی، خطای نرم افزار یا فعالیت بدافزار باشد. هشدار باید با روند گذشته، زمان وقوع و وضعیت پردازشها غنی شود. پر شدن دیسک علاوه بر توقف سرویس، ممکن است لاگ گیری را مختل کند. inode، رشد مسیرهای حساس و حذف ناگهانی فایلهای لاگ نیز باید دیده شوند.
برای شبکه، فقط پهنای باند کلی کافی نیست. مقصدهای جدید، افزایش ترافیک خروجی، تغییر تعداد اتصالهای هم زمان، خطای DNS و باز شدن پورت جدید سیگنالهای مهمتری برای امنیت سرور اختصاصی هستند. در سرویس وب، نرخ خطا، افزایش پاسخهای ۴۰۱ و ۴۰۳ و الگوی درخواست غیرعادی میتواند آغاز حمله یا سوءاستفاده را نشان دهد.
ثبت لاگ امنیتی
لاگ باید پاسخ دهد چه کسی، در چه زمانی، از کجا، روی چه منبعی و با چه نتیجهای اقدام کرده است. برای پایش امنیت سرور اختصاصی، رویدادهای احراز هویت، تغییر دسترسی، اجرای دستور مدیریتی، تغییر فایل، شروع و توقف سرویس، خطای برنامه و ارتباط شبکهای مهم را ثبت کنید.
همه رویدادها ارزش یکسان ندارند. داده حساس مانند رمز عبور، توکن نشست و کلید خصوصی نباید وارد لاگ شود. دسترسی به لاگ محدود باشد، زمان سیستمها هماهنگ شود و لاگها به سامانه جداگانه منتقل شوند تا مهاجم نتواند با حذف فایل محلی رد خود را از بین ببرد. دوره نگهداری باید بر اساس نیاز بررسی رخداد، ظرفیت و الزام قانونی تعیین شود.
پایش یکپارچگی فایل در امنیت سرور اختصاصی
پایش یکپارچگی فایل یا FIM تغییر فایلهای حساس را با وضعیت مبنا مقایسه میکند. مسیرهایی مانند فایلهای پیکربندی، باینریهای سیستمی، کلیدهای SSH، زمان بندی وظایف و ریشه وب باید بر اساس نقش سرور انتخاب شوند. هشدار FIM بدون زمینه تغییر میتواند پرنویز باشد؛ بنابراین آن را با Change Management و اطلاعات بسته نصب شده مرتبط کنید.
عاملهای میزبان مانند auditd، osquery یا EDR میتوانند ایجاد پردازش، تغییر کاربر، اتصال شبکه و اجرای فایل را ثبت کنند. انتخاب ابزار باید با سیستم عامل، توان تیم و حجم داده هماهنگ باشد. هدف جمع آوری همه چیز نیست؛ هدف ثبت شواهدی است که به تشخیص و تصمیم عملی کمک میکند.
هشداردهی قابل اقدام
هشدار امنیت سرور اختصاصی باید مالک، شدت، زمینه و راهنمای اقدام داشته باشد. آستانه ثابت برای همه سرورها معمولاً نتیجه خوبی نمیدهد. ابتدا خط مبنای رفتاری را تعیین کنید، سپس هشدار را بر اساس نقش سرور، ساعت کاری، مبدأ دسترسی و اثر سرویس تنظیم کنید.
- ورود مدیریتی از مبدأ یا ساعت غیرمنتظره
- افزایش تلاش ورود ناموفق روی یک یا چند حساب
- افزوده شدن کاربر، کلید SSH یا وظیفه زمان بندی شده
- تغییر فایل یا باینری حساس خارج از پنجره تغییر
- باز شدن پورت یا شروع سرویس جدید
- افزایش غیرعادی ترافیک خروجی یا اتصال به مقصد ناشناخته
- توقف سرویس حیاتی، پر شدن دیسک یا شکست پشتیبان گیری
- نزدیک شدن انقضای گواهی TLS
برای کاهش خستگی هشدار، رویدادهای تکراری را گروه بندی کنید، هشدارهای کم ارزش را بازتنظیم کنید و کیفیت هر قانون را با شاخصهایی مانند نرخ مثبت کاذب و زمان رسیدگی بسنجید. هیچ هشداری نباید بدون مالک باقی بماند.
معماری مانیتورینگ و SIEM برای امنیت سرور اختصاصی
یک معماری متداول شامل عامل یا Exporter روی سرور، جمع کننده مرکزی، مخزن متریک یا لاگ، داشبورد و سامانه هشدار است. در محیطهای بزرگ، SIEM رویدادهای سیستم عامل، فایروال، برنامه، هویت و تجهیزات شبکه را هم بسته میکند. برای نمونه، ورود موفق پس از چند تلاش ناموفق و سپس ایجاد حساب جدید اهمیت بیشتری از هر رویداد منفرد دارد.
مسیر انتقال داده مانیتورینگ خود یک دارایی حساس است. ارتباط عامل با جمع کننده را رمزنگاری کنید، هویت عامل را اعتبارسنجی کنید، دسترسی نوشتن و خواندن را جدا کنید و برای قطع جریان لاگ هشدار بسازید. اگر مهاجم بتواند تله متری را متوقف یا جعل کند، امنیت سرور اختصاصی با نقطه کور روبه رو میشود.
ابزارهای متداول امنیت سرور اختصاصی
ابزار باید بر اساس نیاز، مهارت تیم و هزینه عملیاتی انتخاب شود. نام محصول جایگزین طراحی کنترل نیست. ترکیب زیر نمونهای از نقشهاست و میتوان آن را با ابزارهای متن باز یا تجاری دیگر پیاده کرد.
| نقش | نمونه ابزار | کاربرد |
|---|---|---|
| متریک | Prometheus و Node Exporter | جمع آوری متریک سیستم و سرویس |
| داشبورد | Grafana | نمایش روند، وضعیت و ظرفیت |
| هشدار | Alertmanager یا سامانه رخداد | مسیریابی و گروه بندی هشدار |
| امنیت میزبان | Wazuh، auditd یا osquery | لاگ، FIM و رویدادهای میزبان |
| لاگ و جستجو | OpenSearch یا Elastic Stack | ذخیره، جستجو و تحلیل رویداد |
| مدیریت رخداد | SIEM و SOAR | هم بستگی، اولویت بندی و اجرای Runbook |
پاسخ به رخداد
پاسخ به رخداد باید بخشی از برنامه امنیت سرور اختصاصی باشد، نه کاری که پس از نفوذ طراحی شود. راهنمای NIST SP 800-61 Revision 3 پاسخ به رخداد را در کل چرخه مدیریت ریسک قرار میدهد. تیم باید از قبل بداند چه کسی تصمیم به جداسازی سرور میگیرد، چه دادهای حفظ میشود و بازیابی با چه اولویتی انجام خواهد شد.
مراحل اجرایی
- اعتبارسنجی: هشدار را با لاگ، متریک و زمینه دارایی بررسی کنید.
- مهار: دسترسی مهاجم را با کمترین آسیب به شواهد و سرویس محدود کنید.
- حفظ شواهد: زمان، لاگ، تصویر دیسک یا حافظه و تغییرات انجام شده را مستند کنید.
- ریشه کنی: حساب، بدافزار، ضعف پیکربندی و مسیر نفوذ را حذف کنید.
- بازیابی: سرویس را از منبع قابل اعتماد برگردانید و مانیتورینگ تشدید شده اعمال کنید.
- بازنگری: علت، زمان تشخیص، نقاط کور و اقدام اصلاحی را ثبت کنید.
در رخداد جدی، بازسازی سرور از Image یا پیکربندی تایید شده معمولاً قابل اعتمادتر از پاک سازی دستی همان میزبان است. تصمیم نهایی باید با نوع نفوذ، کیفیت شواهد و محدودیت سرویس هماهنگ شود.
شاخص های مدیریتی
CISO و مدیر زیرساخت برای ارزیابی امنیت سرور اختصاصی به شاخصهایی نیاز دارند که کیفیت کنترل را نشان دهند، نه فقط تعداد هشدارها. شاخص باید روند، هدف و مالک داشته باشد.
- درصد سرورهای منطبق با خط مبنای امن
- میانگین زمان نصب وصلههای بحرانی بر اساس سطح مواجهه
- درصد حسابهای مدیریتی تحت MFA و بازبینی دسترسی
- پوشش ارسال لاگ و نرخ قطع تله متری
- میانگین زمان تشخیص و مهار رخداد
- نرخ مثبت کاذب هشدارهای مهم
- درصد موفقیت پشتیبان گیری و آزمون بازیابی
- تعداد استثناهای امنیتی منقضی یا بدون مالک
نقشه راه سی روزه امنیت سرور اختصاصی
اگر محیط هنوز برنامه منسجمی ندارد، همه کنترلها را هم زمان پیاده نکنید. نخست نقاط پرریسک و کور را ببندید و سپس بلوغ عملیات را افزایش دهید.
هفته اول
- فهرست سرورها، سرویسها، پورتها، حسابهای مدیریتی و مالکان را کامل کنید.
- دسترسی مستقیم Root و حسابهای بلااستفاده را بررسی کنید.
- وضعیت وصله، فایروال، پشتیبان گیری و ارسال لاگ را ارزیابی کنید.
هفته دوم
- خط مبنای سخت سازی را تصویب و ابتدا روی یک سرور کم ریسک آزمایش کنید.
- دسترسی مدیریت را پشت VPN یا شبکه مدیریتی ببرید و MFA را فعال کنید.
- لاگهای احراز هویت، sudo، سرویس و فایروال را به مخزن مرکزی ارسال کنید.
هفته سوم و چهارم
- داشبورد سلامت و هشدارهای حیاتی را پیاده کنید.
- FIM را برای فایلها و مسیرهای حساس فعال و با تغییرات مجاز هماهنگ کنید.
- بازیابی نمونه را اجرا و زمان واقعی RTO را ثبت کنید.
- یک سناریوی Brute Force یا دسترسی غیرمجاز را به صورت Tabletop تمرین کنید.
چک لیست امنیت سرور اختصاصی
- ☐ داراییها، سرویسها، پورتها و مالکان مستند شدهاند.
- ☐ سیستم عامل و نرم افزارها پشتیبانی و به روز هستند.
- ☐ سرویسها و بستههای غیرضروری حذف یا غیرفعال شدهاند.
- ☐ خط مبنای امن تعریف و انحرافها ثبت شدهاند.
- ☐ دسترسی مستقیم Root محدود است و حساب مشترک وجود ندارد.
- ☐ کلیدهای SSH و دسترسیهای مدیریتی مالک و تاریخ بازبینی دارند.
- ☐ MFA برای مسیرهای مدیریتی حساس فعال است.
- ☐ فایروال ورودی و خروجی بر اساس منع پیش فرض تنظیم شده است.
- ☐ رابط مدیریت و پایگاه داده مستقیماً در اینترنت در دسترس نیستند.
- ☐ برنامه مدیریت وصله و آسیب پذیری بر اساس ریسک اجرا میشود.
- ☐ داده، ارتباطات و نسخههای پشتیبان متناسب با حساسیت رمزنگاری میشوند.
- ☐ نسخه پشتیبان جدا، تغییرناپذیر یا آفلاین وجود دارد.
- ☐ بازیابی به صورت دورهای آزمایش میشود.
- ☐ لاگهای کلیدی به سامانه مرکزی و محافظت شده ارسال میشوند.
- ☐ CPU، RAM، دیسک، شبکه، سرویس و گواهیها مانیتور میشوند.
- ☐ تغییر فایلها، کاربران، کلیدها و سرویسهای حساس هشدار دارد.
- ☐ هشدارها مالک، شدت و Runbook مشخص دارند.
- ☐ قطع جریان لاگ و عامل مانیتورینگ قابل تشخیص است.
- ☐ فرایند پاسخ به رخداد، تماسها و اختیار مهار مستند است.
- ☐ شاخصهای مدیریتی و استثناهای امنیتی دورهای بازبینی میشوند.
سوالات متداول
امنیت سرور اختصاصی از کجا شروع میشود
از فهرست دارایی و تعیین مرز مسئولیت شروع کنید. سپس دسترسی مدیریتی، سرویسهای فعال، پورتها، وصلهها، پشتیبان گیری و ارسال لاگ را بررسی کنید. این ترتیب سریعترین راه برای شناسایی نقاط پرریسک است.
آیا تغییر پورت SSH امنیت را افزایش میدهد
این کار میتواند نویز اسکنهای خودکار را کم کند، اما جایگزین کلید SSH، محدودیت مبدأ، MFA، غیرفعال کردن Root و مانیتورینگ ورود نیست.
برای مانیتورینگ سرور اختصاصی چه ابزاری مناسب است
انتخاب ابزار به مقیاس، سیستم عامل، مهارت تیم و الزام نگهداری داده بستگی دارد. معمولاً یک سامانه متریک و داشبورد در کنار جمع آوری لاگ، FIM و هشداردهی لازم است.
آیا آنتی ویروس برای سرور کافی است
خیر. ضدبدافزار یا EDR فقط یکی از کنترلهاست. امنیت سرور اختصاصی به سخت سازی، کنترل دسترسی، وصله، شبکه، لاگ، مانیتورینگ و بازیابی نیاز دارد.
لاگ ها چه مدت نگهداری شوند
یک عدد ثابت برای همه سازمانها وجود ندارد. دوره نگهداری باید با زمان موردنیاز برای کشف و بررسی رخداد، حجم داده، هزینه و الزامات قراردادی یا قانونی هماهنگ شود.
هر چند وقت یک بار امنیت سرور بررسی شود
مانیتورینگ باید پیوسته باشد. وصله و هشدارها باید منظم بازبینی شوند و پس از تغییر مهم، رخداد امنیتی یا انتشار آسیب پذیری بحرانی ارزیابی خارج از برنامه انجام شود.
جمع بندی
امنیت سرور اختصاصی یک تنظیم اولیه یا خرید ابزار نیست. نتیجه قابل اعتماد زمانی به دست میآید که حاکمیت، فهرست دارایی، سخت سازی، کنترل دسترسی، شبکه، وصله، رمزنگاری، پشتیبان گیری و مانیتورینگ در یک چرخه عملیاتی قرار گیرند. این چرخه باید تغییرات را ثبت کند، رفتار غیرعادی را سریع تشخیص دهد و تیم را برای مهار و بازیابی آماده نگه دارد.
برای CISO، خروجی مطلوب دید روشن از ریسک و پوشش کنترل است. برای DevOps، پیکربندی قابل تکرار و هشدار قابل اقدام اهمیت دارد. برای مدیر زیرساخت، تداوم سرویس و بازیابی آزموده شده معیار اصلی است. برنامه امنیت سرور اختصاصی باید هر سه نیاز را هم زمان پاسخ دهد و با تغییر معماری یا مدل تهدید به روز شود.
منابع فنی
چارچوب امنیت سایبری NIST نسخه ۲
راهنمای پاسخ به رخداد NIST SP 800 61 Revision 3