نویسنده: Vafa Akhtar Khavari وفا اخترخاوری
حوزه تخصصی: زیرساخت IT، امنیت شبکه و معماری امنیتی
وقتی صحبت از امنسازی شبکه میشود، یکی از اولین سؤالها این است: «چه فایروالی بخریم؟»
سؤال مهمی است؛ اما لزوماً سؤال اول نیست.
طراحی حرفهای امنیت شبکه با خرید تجهیزات آغاز نمیشود. نقطه شروع، شناخت داراییها، جریانهای ارتباطی، نیازهای کسبوکار و پیامدهای احتمالی یک حادثه امنیتی است.
پیش از انتخاب فایروال یا پیادهسازی سیاستهای امنیتی، باید بدانیم چه چیزی را محافظت میکنیم، چه کسانی به آن دسترسی دارند و اختلال در هر سرویس چه تأثیری بر سازمان خواهد گذاشت.
هدف اصلی امنیت اطلاعات، حفظ سه اصل اساسی است:
* محرمانگی (Confidentiality): جلوگیری از دسترسی غیرمجاز به اطلاعات
* یکپارچگی (Integrity): جلوگیری از تغییر یا تخریب غیرمجاز دادهها
* دسترسپذیری (Availability): اطمینان از دسترسی به اطلاعات و سرویسها در زمان موردنیاز
این سه اصل باید از ابتدای طراحی، در کنار یکدیگر دیده شوند.
۱. پیش از طراحی، داراییها و جریانهای ارتباطی را بشناسید
هر قانون فایروال بر اساس یک فرض درباره نیازهای ارتباطی شبکه نوشته میشود. اگر وابستگی سرویسها و جریان ترافیک را نشناسیم، این فرضها به حدس تبدیل میشوند.
نتیجه میتواند مجموعهای از قوانین بیشازحد باز باشد؛ قوانینی که به دلیل نگرانی از اختلال در سرویسهای ناشناخته، هیچکس حاضر به محدودکردن آنها نیست.
پیش از طراحی معماری امنیتی، چهار سؤال اساسی را پاسخ دهید:
* کدام سرویسها برای تداوم فعالیت سازمان حیاتی هستند؟
* دادههای حساس کجا ذخیره میشوند و از چه مسیرهایی انتقال مییابند؟
* کاربران، پیمانکاران، مدیران و سرویسهای خودکار به چه منابعی نیاز دارند؟
* کدام سیستمها قدیمی، آسیبپذیر یا فاقد امکان بهروزرسانی مناسب هستند؟
پس از شناخت داراییها، نوبت به ارزیابی ریسک میرسد.
امنیت مطلق وجود ندارد و منابع سازمان نیز محدودند. بنابراین، هزینه و پیچیدگی هر کنترل امنیتی باید با میزان کاهش ریسک و اهمیت دارایی موردنظر متناسب باشد.
معماری مناسب برای یک سازمان مالی الزاماً با معماری موردنیاز یک وبسایت اطلاعرسانی یکسان نیست.
اصل کلیدی: ابتدا ریسک را بشناسید؛ سپس کنترل امنیتی متناسب با آن را انتخاب کنید.
۲. سه اصل بنیادین معماری امنیت شبکه
دفاع در عمق (Defense in Depth)
هیچ کنترل امنیتی نباید تنها خط دفاعی سازمان باشد.
اگر مهاجم از فایروال محیطی عبور کند، تقسیمبندی شبکه، کنترل دسترسی، امنیت هویت و سامانههای پایش باید همچنان از گسترش حمله جلوگیری کنند.
دفاع در عمق به معنای انباشتن تجهیزات امنیتی نیست؛ بلکه به معنای طراحی لایههایی مکمل است که شکست یک لایه، کل معماری را بیدفاع نکند.
کمترین سطح دسترسی (Least Privilege)
هر کاربر، دستگاه یا سرویس باید فقط به منابعی دسترسی داشته باشد که برای انجام وظایف مشخص خود به آنها نیاز دارد.
برای مثال، رایانه یک کارمند عادی نباید صرفاً به دلیل اتصال به شبکه داخلی بتواند به رابط مدیریتی تجهیزات شبکه، سرورهای مجازیسازی یا سامانههای پشتیبانگیری دسترسی پیدا کند.
هدف، ایجاد محدودیت بیدلیل نیست؛ هدف، کاهش سطح دسترسی غیرضروری و محدودکردن پیامدهای احتمالی نفوذ است.
اعتماد صفر (Zero Trust)
در معماری سنتی، حضور در شبکه داخلی گاهی بهعنوان نشانهای از قابلاعتمادبودن در نظر گرفته میشد.
اما در مدل Zero Trust، موقعیت شبکه بهتنهایی مبنای اعتماد نیست.
بر اساس راهنمای NIST SP 800-207، دسترسی به منابع باید بر اساس سیاستهای مشخص و با درنظرگرفتن هویت، وضعیت دستگاه، شرایط درخواست و الزامات امنیتی مربوط ارزیابی شود.
به بیان ساده، سؤال دیگر فقط این نیست که «این سیستم به کدام VLAN متصل است؟»
سؤال اصلی این است:
«این هویت یا بار کاری، تحت چه شرایطی و با چه مجوزی باید به این منبع دسترسی داشته باشد؟»
اعتماد صفر به معنای بیاعتمادی مطلق به همه کاربران نیست؛ بلکه به معنای پرهیز از اعتماد ضمنی و ارزیابی کنترلشده دسترسیهاست.
۳. تقسیمبندی شبکه؛ محدودکردن دامنه حمله
فرض کنید یک کاربر فایل آلودهای را اجرا میکند و مهاجم به سیستم او دسترسی پیدا میکند.
اگر شبکه بهدرستی تقسیمبندی نشده باشد، مهاجم ممکن است بتواند سرورهای داخلی را شناسایی کند، سرویسهای باز را بررسی کند، اعتبارنامهها را به دست آورد و بهتدریج به سیستمهای حساستر برسد.
این فرایند حرکت جانبی (Lateral Movement) نام دارد.
هدف Network Segmentation این است که دسترسی مهاجم به یک بخش از شبکه، به معنای دسترسی آزاد به سایر بخشها نباشد.
تقسیمبندی کلان (Macro Segmentation)
در گام نخست، شبکه را بر اساس نقش، سطح حساسیت و نیازهای ارتباطی به بخشهای منطقی تقسیم کنید؛ برای مثال:
* شبکه کاربران
* شبکه سرورها
* شبکه پایگاههای داده
* ناحیه غیرنظامی (DMZ)
* شبکه مدیریت زیرساخت
* شبکه تجهیزات و سامانههای تخصصی
سیاست ارتباطی هر بخش باید متناسب با وظایف و سطح ریسک آن تعریف شود.
تقسیمبندی خرد (Micro-Segmentation)
در محیطهای حساستر، ممکن است جداسازی در سطح VLAN یا زیرشبکه کافی نباشد.
Micro-Segmentation امکان اعمال سیاستهای دقیقتر میان بارهای کاری، ماشینهای مجازی یا سرویسهای مشخص را فراهم میکند.
برای نمونه، میتوان سیاستی تعریف کرد که در آن:
* فقط سرویسهای مشخص برنامه اجازه ارتباط با پایگاه داده را داشته باشند.
* ارتباطات غیرضروری میان سرورها مسدود شوند.
* دسترسی مدیریتی فقط از مسیرهای تأییدشده امکانپذیر باشد.
* ارتباطات مجاز ثبت و برای شناسایی رفتارهای غیرعادی پایش شوند.
نکته مهم این است که ایجاد VLAN بهتنهایی معادل پیادهسازی تقسیمبندی امن نیست.
اگر مسیریابی بین VLANها بدون محدودیت انجام شود، جداسازی منطقی شبکه لزوماً مانع حرکت جانبی نخواهد شد.
برای هر جریان ارتباطی باید مشخص باشد:
مبدأ چیست؟ مقصد کدام است؟ چه پروتکل و پورتی لازم است؟ تحت چه شرایطی ارتباط مجاز است؟ و آیا این ارتباط باید ثبت یا پایش شود؟
انتخاب کنترل مناسب در هر مرز نیز اهمیت دارد. فیلترهای بسته، فایروالهای حالتدار و پراکسیهای لایه کاربرد، قابلیتهای متفاوتی دارند و باید بر اساس نیاز معماری انتخاب شوند.
۴. هویت، احراز هویت و دسترسی مدیریتی
شبکهای که کنترل هویت مناسبی ندارد، حتی با وجود تجهیزات امنیتی پیشرفته نیز آسیبپذیر خواهد بود.
کنترل دسترسی شبکه با 802.1X
استاندارد IEEE 802.1X چارچوبی برای کنترل دسترسی به شبکه بر اساس احراز هویت فراهم میکند و در شبکههای کابلی و بیسیم قابل استفاده است.
این سازوکار میتواند در کنار زیرساخت احراز هویت و سیاستهای شبکه، از اتصال بدون مجوز دستگاهها جلوگیری کند.
بااینحال، 802.1X بهتنهایی تضمینکننده امنیت دستگاه یا کاربر نیست و باید در کنار سایر کنترلهای امنیتی به کار رود.
ورود یکپارچه و احراز هویت چندعاملی
ورود یکپارچه (Single Sign-On یا SSO) تجربه کاربری را بهبود میدهد؛ اما اگر حساب کاربری به خطر بیفتد، ممکن است دسترسی به چندین سرویس تحت تأثیر قرار گیرد.
به همین دلیل، SSO باید همراه با کنترلهای مناسب، بهویژه احراز هویت چندعاملی (MFA)، سیاستهای دسترسی و پایش فعالیت حسابها پیادهسازی شود.
برای حسابهای مدیریتی، کنترلهای سختگیرانهتری لازم است؛ از جمله:
* جداسازی حسابهای عادی از حسابهای مدیریتی
* محدودکردن دسترسی به رابطهای مدیریتی
* استفاده از مسیرهای مدیریتی کنترلشده
* ثبت و بازبینی فعالیتهای حساس
* اعمال MFA و سیاستهای دسترسی متناسب با ریسک
مدیریت نقشها و بازبینی مجوزها
کنترل دسترسی مبتنی بر نقش (RBAC) در بسیاری از سازمانها رویکردی عملی و قابل مدیریت است.
در این مدل، مجوزها بر اساس وظایف سازمانی تعریف میشوند؛ برای مثال، کارشناس پشتیبانی، مدیر سامانه یا مسئول پشتیبانگیری.
اما تعریف نقشها بهتنهایی کافی نیست.
با تغییر مسئولیت افراد، ممکن است مجوزهای قبلی حذف نشوند و دسترسیها بهتدریج افزایش یابند. این وضعیت با عنوان خزش مجوزها (Privilege Creep) شناخته میشود.
بازبینی دورهای دسترسیها، حذف مجوزهای غیرضروری و رعایت تفکیک وظایف از کنترلهای ضروری برای مدیریت این ریسک هستند.
همچنین، سیاستهای امنیتی باید در تمام شعب و سایتهای سازمان بهصورت سازگار اجرا شوند؛ زیرا ضعف یک شعبه میتواند به نقطه ورود مهاجم به زیرساخت گستردهتر تبدیل شود.
۵. پایش و ثبت رویدادها؛ بدون دید، دفاع مؤثر دشوار است
اگر ندانیم در شبکه چه اتفاقی میافتد، تشخیص حمله، بررسی رفتار غیرعادی و تحلیل علت حادثه دشوار خواهد بود.
ثبت و جمعآوری متمرکز رویدادها باید از مراحل اولیه طراحی در نظر گرفته شود.
منابع مهم برای پایش میتوانند شامل موارد زیر باشند:
* فایروالها و تجهیزات مسیریابی و سوئیچینگ
* سرورها و سیستمعاملها
* سامانههای هویتی و احراز هویت
* سرویسهای حیاتی و پایگاههای داده
* تجهیزات و ابزارهای دسترسی از راه دور
* جریانهای ارتباطی میان بخشهای حساس شبکه
بسته به نیاز سازمان، این اطلاعات میتوانند در سامانههای مدیریت اطلاعات و رویدادهای امنیتی (SIEM) تجمیع و تحلیل شوند.
هدف فقط ذخیرهسازی گزارشها نیست؛ بلکه شناسایی الگوهای مشکوک، بررسی رخدادها، ارزیابی اثربخشی سیاستها و فراهمکردن شواهد لازم برای پاسخگویی و ممیزی است.
البته ثبت رویدادها باید با سیاستهای مشخص برای نگهداری داده، کنترل دسترسی به گزارشها و حفاظت از اطلاعات حساس همراه باشد.
۶. مرز امنیتی دیگر فقط یک نقطه نیست
با گسترش دورکاری، سرویسهای ابری و دسترسی از راه دور، مرز شبکه دیگر به فایروال پیرامونی سازمان محدود نمیشود.
اتصال امن به منابع سازمان باید بر اساس هویت، سطح ریسک، نوع دستگاه و نیاز واقعی کاربر طراحی شود.
VPN یکی از راهکارهای متداول برای ایجاد ارتباط امن از طریق شبکههای غیرقابلاعتماد است. IPsec میتواند برای حفاظت از ارتباطات در لایه شبکه استفاده شود و راهکارهای مبتنی بر TLS نیز در سناریوهای دسترسی از راه دور کاربرد دارند.
بااینحال، انتخاب VPN بهتنهایی مشکل دسترسی غیرضروری را حل نمیکند. پس از برقراری تونل نیز باید دسترسی کاربران به منابع داخلی محدود و کنترل شود.
در کنار این موارد، امنیت دستگاههای همراه و تجهیزات خارج از سازمان نیز اهمیت دارد:
* رمزنگاری اطلاعات ذخیرهشده
* استفاده از قفل صفحه و احراز هویت مناسب
* مدیریت وصلههای امنیتی
* کنترل اتصال به شبکههای بیسیم
* امکان مدیریت و پاکسازی از راه دور در صورت نیاز
* اعمال سیاستهای امنیتی برای دستگاههای سازمانی
اصل مهم این است که اتصال امن، جایگزین کنترل دسترسی مناسب نیست.
۷. طراحی برای خرابی، نه فقط برای جلوگیری از نفوذ
معماری امنیتی زمانی کاملتر میشود که برای شرایط شکست نیز برنامه داشته باشد.
اختلال در یک سرویس حیاتی، خرابی تجهیزات، حمله باجافزاری یا از دست رفتن مرکز داده میتواند فعالیت سازمان را مختل کند.
برای کاهش این ریسکها باید به موارد زیر توجه شود:
افزونگی (Redundancy): حذف نقاط شکست منفرد در بخشهای حیاتی، متناسب با نیازهای دسترسپذیری.
پشتیبانگیری (Backup): تهیه نسخههای پشتیبان با حفاظت مناسب در برابر حذف، دستکاری و دسترسی غیرمجاز.
بازیابی از فاجعه (Disaster Recovery): تعریف فرایندها، مسئولیتها و منابع لازم برای بازگرداندن سرویسها پس از یک حادثه جدی.
آزمون بازیابی: بررسی عملی امکان بازگردانی اطلاعات و سرویسها، نه صرفاً اطمینان از موفقیت عملیات پشتیبانگیری.
اهداف زمانی بازیابی نیز باید مشخص باشند:
* RTO: حداکثر زمان قابلقبول برای بازگرداندن سرویس
* RPO: حداکثر میزان قابلقبول ازدسترفتن داده، بر اساس فاصله زمانی بازیابی
پشتیبانگیریای که بازیابی آن هرگز آزمایش نشده است، بهتنهایی تضمینی برای تداوم کسبوکار نیست.
۸. مستندسازی و مدیریت تغییر؛ بخش فراموششده امنیت
بسیاری از مشکلات امنیتی نه از طراحی اولیه، بلکه از تغییرات کنترلنشده در طول زمان ایجاد میشوند.
یک قانون فایروال موقت ممکن است سالها باقی بماند. یک سرویس جدید ممکن است بدون بررسی وابستگیها در شبکه مستقر شود. یا تغییر پیکربندی یک شعبه، سطح امنیت آن را از استاندارد سازمان خارج کند.
برای جلوگیری از این وضعیت، باید موارد زیر بهصورت مستمر مدیریت شوند:
* نقشه بهروز توپولوژی شبکه
* فهرست داراییها و مالکان سرویسها
* مستندات جریانهای ارتباطی
* استانداردهای پیکربندی امن
* فرایند ثبت، ارزیابی و تأیید تغییرات
* بازبینی دورهای قوانین فایروال و مجوزهای دسترسی
* بررسی انطباق پیکربندی سایتها با استانداردهای سازمان
هرچه پیچیدگی شبکه بیشتر شود، شناخت وابستگی سرویسها اهمیت بیشتری پیدا میکند.
مستندسازی خوب فقط برای تحویل پروژه نیست؛ بخشی از کنترل امنیتی زیرساخت است.
۹. نقشه راه عملی برای پیادهسازی معماری امنیت شبکه
برای سازمانی که قصد دارد معماری امنیتی خود را بهصورت مرحلهای بهبود دهد، ترتیب زیر میتواند نقطه شروع مناسبی باشد:
مرحله اول: شناخت
۱. شناسایی داراییها و سرویسهای حیاتی
۲. ترسیم جریانهای ارتباطی و وابستگی سرویسها
۳. ارزیابی تهدیدها و اولویتبندی ریسکها
مرحله دوم: طراحی
۴. تعریف اصول Defense in Depth، Least Privilege و Zero Trust
۵. طراحی Macro Segmentation و تعیین مرزهای امنیتی
۶. شناسایی بخشهای نیازمند Micro-Segmentation
مرحله سوم: کنترل دسترسی
۷. تقویت مدیریت هویت و اجرای MFA
۸. جداسازی شبکه مدیریت و محدودکردن دسترسیهای مدیریتی
۹. بازبینی نقشها و حذف مجوزهای غیرضروری
مرحله چهارم: پایش و تابآوری
۱۰. جمعآوری متمرکز رویدادها و تعریف هشدارهای امنیتی
۱۱. امنسازی دسترسی از راه دور و دستگاههای همراه
۱۲. طراحی افزونگی، پشتیبانگیری و آزمون بازیابی
مرحله پنجم: نگهداری
۱۳. مستندسازی تغییرات و بهروزرسانی نقشه شبکه
۱۴. بازبینی منظم قوانین فایروال و سیاستهای دسترسی
۱۵. ارزیابی مستمر اثربخشی کنترلها و اصلاح نقاط ضعف
پنج اشتباه رایج که باید از آنها اجتناب کرد
۱. خرید تجهیزات امنیتی پیش از شناخت داراییها و نیازهای واقعی
۲. فرض اینکه ایجاد VLAN بهتنهایی شبکه را امن میکند
۳. استفاده از SSO بدون درنظرگرفتن MFA و کنترلهای تکمیلی
۴. نادیدهگرفتن بازبینی دورهای مجوزهای دسترسی
۵. طراحی شبکه بدون برنامه مشخص برای پایش، پاسخ به حادثه و بازیابی
جمعبندی: امنیت شبکه یک معماری است، نه یک محصول
طراحی حرفهای امنیت شبکه با شناخت داراییها و جریانهای ارتباطی آغاز میشود؛ با ارزیابی ریسک و تعیین سیاستهای دسترسی ادامه مییابد؛ و از طریق تقسیمبندی، مدیریت هویت، پایش مستمر و برنامهریزی برای بازیابی به یک معماری قابل اتکا تبدیل میشود.
فایروال، سوئیچ، سامانه مدیریت هویت یا ابزار SIEM هرکدام میتوانند بخشی از این معماری باشند؛ اما هیچیک بهتنهایی جایگزین طراحی اصولی نمیشوند.
هدف نهایی این نیست که صرفاً از ورود مهاجم جلوگیری کنیم؛ بلکه باید احتمال نفوذ، دامنه گسترش حمله و پیامدهای آن را تا حد امکان کاهش دهیم.
امنیت مؤثر زمانی شکل میگیرد که هر ارتباط دلیل مشخصی برای مجازبودن داشته باشد، هر دسترسی قابل ارزیابی باشد و هر حادثه امکان شناسایی، مهار و بازیابی داشته باشد.
⸻
منابع پیشنهادی برای مطالعه بیشتر
* NIST SP 800-207 — Zero Trust Architecture
* NIST Cybersecurity Framework 2.0
* راهنماهای Microsoft درباره Zero Trust و Network Segmentation
#NetworkSecurity #Cybersecurity #ZeroTrust #NetworkSegmentation #InfrastructureSecurity #NetworkArchitecture #InformationSecurity