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

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

در این مقاله، طراحی معماری DMZ مبتنی بر Cisco Adaptive Security Appliance و Cisco Firepower Threat Defense را به‌صورت مهندسی بررسی می‌کنیم و سناریوهای عملی برای انتشار سرویس‌های اینترنتی ارائه می‌دهیم.

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

مفهوم واقعی DMZ در معماری امنیتی

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

DMZ در واقع یک بافر امنیتی بین دنیای غیرقابل اعتماد اینترنت و شبکه قابل اعتماد داخلی است. هر سرویسی که از بیرون قابل دسترس است، ذاتاً در معرض اسکن، Exploit، Brute Force و انواع حملات لایه کاربردی قرار دارد. بنابراین فرض طراحی باید این باشد که احتمال compromise شدن یک سرویس اینترنتی صفر نیست. معماری DMZ باید طوری طراحی شود که اگر این اتفاق رخ داد، دامنه آسیب کنترل شود.

در Cisco Adaptive Security Appliance و Cisco Firepower Threat Defense، DMZ یک Zone با Policy مستقل است. این یعنی ارتباط Outside به DMZ، DMZ به Inside و Inside به DMZ هرکدام به‌صورت جداگانه تعریف و کنترل می‌شوند. این تفکیک منطقی باعث می‌شود هیچ ارتباطی به‌صورت ضمنی یا پیش‌فرض بین این نواحی برقرار نباشد.

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

نکته مهم دیگر این است که DMZ ذاتاً یک محیط کم‌اعتماد است. بنابراین نباید سرویس‌های مدیریتی، Backup گسترده یا دسترسی‌های گسترده Domain Admin از داخل به DMZ بدون محدودیت برقرار باشد. حتی دسترسی مدیریت به سرورهای DMZ باید از طریق Jump Server یا شبکه مدیریتی جداگانه انجام شود.

در معماری‌های پیشرفته‌تر، خود DMZ نیز به چند بخش تقسیم می‌شود. برای مثال Web Server، Application Server و Reverse Proxy در VLANهای جداگانه قرار می‌گیرند و ترافیک بین آن‌ها نیز از طریق فایروال کنترل می‌شود. این رویکرد که Micro-Segmentation نامیده می‌شود، احتمال حرکت جانبی در داخل DMZ را کاهش می‌دهد.

همچنین باید در نظر داشت که DMZ فقط برای وب‌سرور نیست. هر سرویسی که از بیرون در دسترس است، از Mail Gateway گرفته تا VPN Concentrator یا API عمومی، باید در این ناحیه نیمه‌مورداعتماد قرار گیرد.

مدل‌های معماری DMZ

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

مدل سه‌اینترفیسی

این مدل رایج‌ترین طراحی در سازمان‌های متوسط است. یک فایروال با سه Interface یا Sub-Interface تعریف می‌شود: Outside، Inside و DMZ. تمام ترافیک بین این سه ناحیه از طریق همان فایروال کنترل می‌شود.

در Cisco Adaptive Security Appliance و Cisco Firepower Threat Defense این مدل به‌سادگی قابل پیاده‌سازی است. برای هر مسیر Policy جداگانه تعریف می‌شود و NAT برای انتشار سرویس‌ها روی Interface Outside انجام می‌گیرد.

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

مدل دو فایروال

در این معماری، دو فایروال مجزا استفاده می‌شود. فایروال اول بین Outside و DMZ قرار می‌گیرد و فایروال دوم بین DMZ و Inside. این مدل معمولاً در سازمان‌های حساس یا دیتاسنترهای حیاتی استفاده می‌شود.

در این طراحی، حتی اگر فایروال بیرونی دچار ضعف پیکربندی شود، فایروال داخلی همچنان یک لایه دفاعی جداگانه فراهم می‌کند. این رویکرد Defense in Depth را تقویت می‌کند.

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

مدل Segmented DMZ

در این مدل، DMZ خود به چند سگمنت یا VLAN تقسیم می‌شود. برای مثال:

VLAN مخصوص Web Server
VLAN مخصوص Application Server
VLAN مخصوص Reverse Proxy یا Load Balancer

ترافیک بین این سگمنت‌ها نیز از طریق فایروال کنترل می‌شود. این معماری به‌ویژه در دیتاسنترهایی با ترافیک East-West بالا کاربرد دارد.

در Cisco Firepower Threat Defense می‌توان با استفاده از Zone-Based Architecture و Policyهای دقیق، این تفکیک را پیاده‌سازی کرد. هر سگمنت به‌عنوان Zone مجزا تعریف می‌شود و ارتباط بین آن‌ها محدود و کنترل‌شده است.

مزیت این مدل کاهش احتمال حرکت جانبی در صورت compromise شدن یک سرور است. اگر وب‌سرور آلوده شود، مهاجم به‌راحتی به Application Server دسترسی نخواهد داشت مگر اینکه Rule مشخصی اجازه دهد.

مدل DMZ با Reverse Proxy

در برخی سازمان‌ها، به‌جای انتشار مستقیم وب‌سرورها، یک Reverse Proxy یا Web Application Firewall در DMZ قرار می‌گیرد و سرورهای Application در شبکه داخلی یا سگمنت جداگانه‌ای پشت آن قرار می‌گیرند.

در این مدل، فقط Reverse Proxy به اینترنت Publish می‌شود. این ساختار سطح تماس مستقیم اینترنت با سرورهای اصلی را کاهش می‌دهد و امکان فیلتر لایه کاربردی دقیق‌تر فراهم می‌کند.

انتخاب مدل مناسب

انتخاب معماری باید بر اساس این عوامل انجام شود:

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

در یک سازمان متوسط با یک وب‌سایت و API عمومی، مدل سه‌اینترفیسی با Segmentation داخلی کافی است. اما در یک بانک یا دیتاسنتر حیاتی، مدل دو فایروال یا Segmented DMZ با لایه‌های متعدد دفاعی منطقی‌تر است.

طراحی Zone و Policy در فایروال سیسکو

طراحی DMZ بدون تعریف دقیق Zoneها و Policyها عملاً بی‌اثر است. آنچه امنیت واقعی را ایجاد می‌کند، نحوه تعریف مرزهای منطقی و کنترل دقیق جریان ترافیک بین آن‌هاست. در Cisco Firepower Threat Defense و Cisco Adaptive Security Appliance ابزارهای لازم برای این تفکیک وجود دارد، اما طراحی باید آگاهانه و مبتنی بر اصل حداقل دسترسی انجام شود.

تعریف Zoneها بر اساس سطح اعتماد

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

Outside که غیرقابل اعتماد است
DMZ که نیمه‌مورداعتماد است
Inside که مورداعتماد است

در طراحی‌های پیشرفته‌تر، ممکن است DMZ خود به چند Zone تقسیم شود، مانند Web-DMZ و App-DMZ. این تفکیک باعث می‌شود کنترل East-West Traffic نیز به‌صورت دقیق انجام شود.

در FTD، Zoneها به‌صورت منطقی تعریف می‌شوند و Interfaceها به آن‌ها Assign می‌شوند. در ASA نیز همین تفکیک از طریق Interface و Security Level انجام می‌شود، اما توصیه می‌شود همچنان طراحی ذهنی Zone-Based داشته باشید، حتی اگر ابزار مستقیم آن وجود نداشته باشد.

طراحی Policy مبتنی بر مسیر ترافیک

Policy نباید به‌صورت پراکنده نوشته شود. باید بر اساس مسیرهای مشخص طراحی گردد:

ترافیک Outside به DMZ
ترافیک DMZ به Inside
ترافیک Inside به DMZ
ترافیک Inside به Outside

هر مسیر باید مستقل تحلیل شود. برای مثال:

Outside به DMZ فقط پورت‌های مشخص و فقط به سرورهای مشخص
DMZ به Inside فقط ارتباط‌های کاملاً ضروری مانند اتصال به دیتابیس
Inside به DMZ برای مدیریت، Backup یا Monitoring با محدودیت IP

هیچ Rule عمومی بین DMZ و Inside نباید وجود داشته باشد.

اصل حداقل دسترسی در Policy

در بسیاری از پروژه‌ها، برای ساده‌سازی، Ruleهایی مانند Allow DMZ to Inside Any تعریف می‌شود تا سرویس سریع‌تر راه‌اندازی شود. این رویکرد در کوتاه‌مدت کار می‌کند، اما در بلندمدت یک ریسک جدی ایجاد می‌کند.

هر Rule باید دقیقاً مشخص کند:

کدام Source
به کدام Destination
روی چه Service یا Application
در چه جهت

در FTD بهتر است برای مسیر Outside به DMZ علاوه بر Port، Application Control و Intrusion Policy نیز فعال شود. این کار مانع عبور حملات لایه ۷ حتی در صورت باز بودن پورت 443 می‌شود.

ترتیب و ساختار Ruleها

Policy باید ساختارمند باشد. معمولاً Ruleهای خاص‌تر در بالای لیست و Ruleهای عمومی‌تر پایین‌تر قرار می‌گیرند. همچنین می‌توان Ruleها را به‌صورت منطقی دسته‌بندی کرد، مثلاً:

بخش مربوط به Publish سرویس‌های عمومی
بخش مربوط به ارتباط DMZ با دیتابیس
بخش مربوط به مدیریت

این ساختار عیب‌یابی و Audit را ساده‌تر می‌کند.

Logging و مانیتورینگ

در مسیر Outside به DMZ، Logging باید فعال باشد، به‌ویژه برای ترافیک Drop شده. این Logها می‌توانند نشانه Scan یا تلاش Exploit باشند.

برای مسیر DMZ به Inside نیز Logging اهمیت زیادی دارد، زیرا هر ترافیکی در این مسیر بالقوه مشکوک است.

سناریوی عملی

فرض کنید یک وب‌سرور در DMZ دارید که باید به دیتابیس داخلی متصل شود. طراحی صحیح به این شکل است:

یک Rule از Outside به DMZ برای HTTPS
یک Rule از DMZ به Inside فقط برای IP وب‌سرور به IP دیتابیس روی پورت مشخص
عدم وجود هرگونه Rule عمومی از DMZ به سایر Subnetهای داخلی

اگر وب‌سرور compromise شود، مهاجم فقط می‌تواند به همان دیتابیس دسترسی داشته باشد، نه کل شبکه.

NAT و انتشار سرویس‌ها

برای انتشار سرویس در DMZ معمولاً از Static NAT یا Static PAT استفاده می‌شود. اما فقط تعریف NAT کافی نیست. باید Access Control Policy نیز محدود و دقیق باشد.

برای مثال اگر وب‌سرور فقط روی HTTPS سرویس می‌دهد، باز کردن پورت 80 یا Any اشتباه است. همچنین Logging برای ترافیک ورودی به DMZ باید فعال باشد.

در سناریوهای پیشرفته‌تر، می‌توان از Reverse Proxy یا Load Balancer در DMZ استفاده کرد و سرورهای Application را در VLAN جداگانه‌ای پشت آن قرار داد.

فعال‌سازی IPS و SSL Inspection برای DMZ

ترافیک Outside به DMZ پرریسک‌ترین مسیر در شبکه است. بنابراین Intrusion Policy در این مسیر باید سخت‌گیرانه‌تر باشد.

در صورت امکان، SSL Inspection برای ترافیک ورودی به وب‌سرور فعال شود تا حملات مخفی در HTTPS نیز قابل شناسایی باشند. البته این موضوع نیازمند مدیریت صحیح Certificate است.

سناریوی عملی در یک سازمان متوسط

فرض کنید سازمانی یک وب‌سایت عمومی و یک API برای مشتریان دارد. طراحی پیشنهادی به این شکل است:

وب‌سرور و API Server در VLAN DMZ قرار می‌گیرند.
دیتابیس در شبکه داخلی باقی می‌ماند.
فقط پورت 443 از Outside به DMZ باز است.
فقط پورت 1433 از DMZ به Inside برای دیتابیس مجاز است.
هیچ ارتباطی از DMZ به سایر Subnetهای داخلی مجاز نیست.

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

مانیتورینگ و Logging

تمام ترافیک ورودی به DMZ باید Log شود. Eventهای مشکوک باید به SIEM ارسال شوند. در صورت افزایش ناگهانی Connection یا Scan، باید Alert ایجاد شود.

همچنین بررسی دوره‌ای Ruleها و NATهای مرتبط با DMZ ضروری است. بسیاری از سرویس‌های قدیمی همچنان Publish باقی می‌مانند در حالی که دیگر استفاده نمی‌شوند.

اشتباهات رایج در طراحی DMZ

قرار دادن سرور Publish شده در شبکه داخلی
Allow کردن Any Any بین DMZ و Inside
عدم فعال‌سازی IPS روی مسیر Outside به DMZ
نبود Logging کافی
عدم تفکیک VLANهای مختلف در DMZ

جمع‌بندی مهندسی

DMZ یک VLAN ساده نیست، بلکه یک مرز کنترلی است که باید با دقت طراحی شود. فایروال سیسکو چه در قالب Cisco Adaptive Security Appliance و چه در قالب Cisco Firepower Threat Defense ابزارهای لازم برای طراحی DMZ امن را فراهم می‌کند، اما این طراحی باید مبتنی بر اصل حداقل دسترسی و تفکیک لایه‌ای باشد.

هدف این است که حتی در صورت compromise شدن یک سرویس اینترنتی، آسیب به شبکه داخلی محدود و قابل کنترل باقی بماند.

وینو سرور؛ مرجع تخصصی طراحی معماری DMZ

طراحی DMZ در محیط‌های Enterprise نیازمند تجربه عملی در ترکیب NAT، Access Control، IPS و معماری Zone-Based است. کوچک‌ترین خطا می‌تواند راه نفوذ مستقیم به شبکه داخلی ایجاد کند.

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