DMZ در شبکه سازمانی نباید فقط یک VLAN باشد که چند سرور عمومی داخل آن قرار گرفتهاند. DMZ مرز کنترلشده بین اینترنت، سرویسهای قابل دسترس عمومی و شبکه داخلی است. اگر این مرز درست طراحی نشود، یک آسیبپذیری در وبسرور یا VPN میتواند مسیر حرکت به داخل شبکه را باز کند. طراحی خوب DMZ یعنی فرض کنیم سرویس عمومی ممکن است روزی درگیر شود و از قبل مسیر گسترش آسیب را محدود کنیم.
در طراحی DMZ باید سرویسها بر اساس نقش جدا شوند: وبسرور، reverse proxy، WAF، VPN portal، mail relay، API gateway و سیستمهای مدیریتی نباید همه در یک سطح اعتماد باشند. بعضی سرویسها فقط از اینترنت درخواست میگیرند، بعضی باید به backend داخلی وصل شوند، بعضی فقط باید لاگ بفرستند. همین تفاوتها باید در Policy و routing دیده شود.
اول جریان ترافیک را روی کاغذ بیاورید
قبل از ساخت Rule، باید جریان ترافیک مشخص شود. کاربر از اینترنت به کدام IP میرسد؟ NAT کجا انجام میشود؟ WAF قبل از وبسرور قرار دارد یا بعد از load balancer؟ backend داخل شبکه داخلی است یا در zone جدا؟ لاگها کجا میروند؟ دسترسی مدیریتی از کدام مسیر مجاز است؟ اگر این پرسشها جواب نداشته باشند، Rule Base پر از استثنا میشود.
- مسیر اینترنت به سرویس عمومی
- مسیر سرویس DMZ به backend داخلی
- مسیر مدیریت و backup
- مسیر ارسال لاگ به SIEM یا syslog
- مسیر health check از load balancer یا WAF
اصل مهم: DMZ نباید به همه داخل وصل باشد
گاهی برای راحتی، سرورهای DMZ به چند subnet داخلی دسترسی گسترده میگیرند. این دقیقاً خلاف هدف DMZ است. اگر یک وبسرور فقط باید به یک API داخلی روی پورت مشخص وصل شود، همان باید باز باشد. دسترسی به database، file share، domain controller یا management subnet باید با حساسیت بالا بررسی شود. هر Rule از DMZ به داخل باید دلیل، مالک و تست داشته باشد.
در طراحی بهتر، سرویسهای حساس پشت چند لایه قرار میگیرند: WAF یا reverse proxy در لبه، application در zone جدا، database در zone داخلیتر، و مسیر مدیریت جدا از مسیر کاربران. این جداسازی ممکن است در ابتدا کمی پیچیدهتر باشد، اما در روز حادثه ارزشش مشخص میشود.
لاگ و مانیتورینگ DMZ
DMZ بدون لاگ مناسب، فقط یک بخش جدا روی دیاگرام است. باید بدانیم چه کسی به سرویس رسیده، چه چیزی توسط WAF block شده، چه خطاهایی روی backend رخ داده، آیا ترافیک غیرعادی از DMZ به داخل دیده میشود، و آیا تغییرهای firewall policy ثبت شدهاند. اگر لاگها فقط روی خود سرورها بمانند، در رخداد جدی ممکن است همان شواهد از دست برود.
DMZ در پروژه پیادهسازی فایروال
وقتی فایروال سازمانی جدید پیاده میشود، DMZ یکی از بخشهایی است که باید جداگانه طراحی شود. مهاجرت Ruleهای قدیمی بدون بازبینی میتواند ضعفهای قبلی را به فایروال جدید منتقل کند. بهتر است قبل از cutover، سرویسهای DMZ لیست شوند، جریان ترافیک هر کدام نوشته شود، Ruleهای لازم با حداقل دسترسی ساخته شوند و سناریوی تست برای هر سرویس آماده باشد.
این مطلب با مشاوره و پیادهسازی فایروال سازمانی، طراحی و هاردنینگ امنیت شبکه و مشاوره و پیادهسازی WAF مرتبط است. DMZ خوب فقط شبکه را مرتبتر نمیکند؛ اثر حادثه را محدود و عیبیابی را قابل انجام میکند.
DMZ را با تست نفوذ فرضی مرور کنید
یک روش خوب برای سنجش طراحی DMZ این است که فرض کنیم یکی از سرویسهای عمومی compromise شده است. از آن نقطه مهاجم به کجا میتواند برسد؟ آیا فقط همان سرویس محدود میشود یا مسیر به subnet داخلی، management، database یا shareهای فایل باز است؟ آیا لاگ کافی داریم که حرکت از DMZ به داخل را ببینیم؟ این تمرین ساده ضعفهایی را نشان میدهد که در طراحی عادی دیده نمیشوند.
اگر پاسخ این سؤالها مبهم است، DMZ هنوز کامل طراحی نشده است. مرزبندی خوب باید حتی در حالت شکست یک سرویس هم اثر حادثه را محدود کند. این یعنی Ruleهای خروجی از DMZ به داخل باید کم، دقیق، مستند و قابل مانیتور باشند. همچنین مسیر مدیریت سرورهای DMZ نباید از همان مسیری باشد که کاربران اینترنتی به سرویس میرسند.
برای اینکه این موضوع در اجرا هم نتیجه بدهد، بهتر است بعد از هر تغییر یک شاخص ساده برای موفقیت داشته باشیم: آیا سرویس سالم مانده، آیا لاگ کافی داریم، آیا مسیر rollback روشن است، و آیا تیم فنی میتواند سه ماه بعد دلیل این تصمیم را بفهمد؟ اگر جواب این سؤالها مثبت نباشد، حتی تغییر درست هم در نگهداری روزمره دردسر میسازد.
همین نگاه ساده جلوی کارهای نمایشی را میگیرد. معیار موفقیت باید در شبکه واقعی قابل مشاهده باشد، نه فقط در متن گزارش.
در کار اجرایی، یک نکته دیگر هم مهم است: هر پیشنهاد باید صاحب، زمان بازبینی و سطح ریسک داشته باشد. اگر پیشنهادی این سه مورد را ندارد، احتمالاً هنوز برای اجرا آماده نیست. این کار متن را از توصیه عمومی جدا میکند و به برنامهای تبدیل میکند که تیم فنی میتواند آن را مرحلهبهمرحله دنبال کند.
