امنیت شبکه پایه‌ی هر معماری دفاعی است: تعیین میکند چه چیزی به چه چیزی میتواند وصل شود. اما یک واقعیت ساده وجود دارد که بخش بزرگی از بودجه‌های امنیتی آن را نادیده می‌گیرند: برنامه‌ی وبی که روی پورت ۴۴۳ منتشر شده، برای مهاجم هم روی همان پورت ۴۴۳ در دسترس است. هیچ فایروالی نمی‌تواند تفکیک کند که کدام درخواست HTTPS معتبر، سوءاستفاده است. این مقاله کنترلهای واقعی امنیت شبکه را توضیح می‌دهد و بعد صریحاً می‌گوید مرز اثرگذاری آن‌ها کجا تمام می‌شود.
در یک نگاه
- پرارزش‌ترین کنترل امنیت شبکه، جداسازی است؛ و اثر آن را باید با آزمون اثبات کرد، نه با نمودار معماری.
- فیلترکردن ترافیک خروجی تقریباً همیشه فراموش می‌شود، در حالی که اثر SSRF و ارتباط با سرور فرمان را محدود میکند.
- اعتماد صفر یک رویکرد معماری است، نه محصولی که خریداری شود؛ اصلش این است که موقعیت شبکهای، اعتماد تولید نمی‌کند.
- کنترل شبکه جلوی نقص لایهی برنامه را نمی‌گیرد — یک نقص کنترل دسترسی با درخواست معتبر HTTPS بهره‌جویی می‌شود.
امنیت شبکه چه چیزی را محافظت میکند؟
امنیت شبکه به یک پرسش پاسخ می‌دهد: چه چیزی مجاز است به چه چیزی وصل شود، و در آن مسیر چه چیزی دیده یا ثبت می‌شود؟ ابزارهای متعارف آن:
- کنترل مسیر ترافیک: فایروال، فهرست‌های کنترل دسترسی روی تجهیزات، گروه‌های امنیتی در محیط ابری.
- جداسازی: تفکیک شبکه به بخش‌هایی با سطوح اعتماد متفاوت.
- کنترل دسترسی به شبکه: این‌که چه دستگاهی اجازه‌ی اتصال دارد — از جمله در بستر بی‌سیم که در امنیت وای‌فای بحث شده.
- رمزنگاری مسیر: VPN و TLS برای ترافیک بین بخش‌ها.
- پایش و تشخیص: سامانه‌های تشخیص و پیشگیری نفوذ و تحلیل جریان ترافیک.
در چارچوب امنیت اطلاعات، این‌ها لایهی زیرساخت را می‌پوشانند. ارزیابی مجاز همین لایه، موضوع تست نفوذ شبکه و سرویس تست نفوذ شبکه‌ی پی‌هانتر است.
جداسازی: مؤثرترین کنترل
اگر بخواهیم یک کنترل شبکهای را بر بقیه ترجیح دهیم، جداسازی است. منطقش صریح است: مهاجمی که یک پایگاه به دست آورده، فقط تا مرزی میتواند پیش برود که شبکه به او اجازه می‌دهد. بدون جداسازی، یک ایستگاه کاری آلوده به معنای دسترسی به پایگاه‌داده‌ی عملیاتی است.
سطوح جداسازی که در عمل معنا دارند:
- تفکیک محیط‌ها: توسعه، آزمون و عملیات باید شبکه‌های جدا داشته باشند. محیط آزمایشی با دادهی واقعی و بدون کنترل، پرتکرارترین یافته‌ی جدی در ارزیابی‌های داخلی است.
- تفکیک لایه‌ها: لایهی وب، لایهی برنامه و لایهی داده. پایگاه‌داده نباید از هیچ‌جا جز سرور برنامه قابل دسترس باشد.
- تفکیک شبکه‌ی کاربران از سرورها و جدا نگه‌داشتن شبکه‌ی مهمان.
- تفکیک شبکه‌ی مدیریتی: دسترسی به رابط مدیریت تجهیزات از شبکه‌ی عمومی کاربران، یک ریسک مستقیم است.
دو نکته‌ی مهم: اول، VLAN به‌تنهایی جداسازی نیست — تا وقتی قواعد صریح فیلترینگ بین بخش‌ها اعمال نشده، شما فقط برچسب‌گذاری منطقی انجام داده‌اید. دوم، جداسازی باید آزموده شود. PCI DSS v4.0.1 دقیقاً همین را الزام کرده: آزمون کنترلهای جداسازی حداقل هر ۱۲ ماه و پس از هر تغییر، و برای ارائه‌دهندگان سرویس هر شش ماه. اگر جداسازی شما فقط روی نمودار معماری وجود دارد، در عمل وجود ندارد.
هدف نهایی، محدودکردن حرکت جانبی است — همان چیزی که در تست نفوذ داخلی سنجیده می‌شود.
فایروال: چه میکند و چه نمی‌کند
فایروال بر پایه‌ی آدرس، پورت، پروتکل و وضعیت اتصال تصمیم میگیرد. نسخه‌های مدرن‌تر می‌توانند برنامه‌ی سطح بالاتر را هم تشخیص دهند و سیاست‌های مبتنی بر هویت اعمال کنند. کاری که خوب انجام می‌دهد: بستن سطح حمله‌ی غیرضروری.
بخشی که معمولاً پیکربندی نمی‌شود، ترافیک خروجی است. بیشتر سازمان‌ها ورودی را سخت‌گیرانه می‌بندند و خروجی را کاملاً باز می‌گذارند. اما کنترل خروجی دو اثر مستقیم دارد: محدودکردن ارتباط با سرور فرمان و کنترل پس از یک آلودگی، و کاهش دامنهی اثر SSRF. الگوی درست، رد پیشفرض با فهرست سفید است:
# app tier egress — default deny
allow 10.0.2.0/24 -> payments.partner.example:443
allow 10.0.2.0/24 -> 10.0.9.10:5432
deny any -> anyیک هشدار فنی مهم درباره‌ی SSRF: بستن آدرس‌های خاص مانند آدرس فراداده‌ی نمونه‌های ابری، به‌تنهایی کافی نیست. فهرست‌های سیاه با کدگذاری‌های جایگزین آدرس، نام دامنهی تحت کنترل مهاجم و زنجیره‌ی تغییر مسیر دور زده میشوند. راهکار درست ترکیبی است: کنترل خروجی با رد پیشفرض در لایهی شبکه، به‌همراه فهرست سفید مقصد و الگوی «یک‌بار تفکیک نام، سپس اتصال به همان آدرس تفکیک‌شده» در خود برنامه.
و یک تفکیک اصطلاحی که مرتب اشتباه می‌شود: فایروال شبکه با فایروال برنامه‌ی وب یکی نیست. اولی درباره‌ی اتصال است، دومی درباره‌ی محتوای درخواست HTTP — و هیچ‌کدام جای دیگری را نمی‌گیرد.
اعتماد صفر به زبان ساده
معماری سنتی بر یک فرض بنا شده بود: هر چیزی داخل شبکه، مورد اعتماد است. اعتماد صفر (Zero Trust) دقیقاً همین فرض را حذف میکند. سند مرجع این حوزه، NIST SP 800-207 (منتشرشده در ۲۰۲۰) است.
سه اصل عملی آن، بدون اصطلاحات بازاریابی:
- موقعیت شبکهای اعتماد تولید نمی‌کند. این‌که درخواستی از شبکه‌ی داخلی آمده، دلیلی برای مجاز بودن آن نیست.
- هر درخواست، جداگانه احراز هویت و مجوزدهی می‌شود — بر پایه‌ی هویت کاربر، وضعیت دستگاه و حساسیت منبع.
- حداقل دسترسی و فرض رخنه. دسترسی‌ها باریک و موقت‌اند و معماری با این فرض طراحی می‌شود که مهاجم از قبل داخل است.
هیچ محصولی «اعتماد صفر» را برای شما پیاده نمی‌کند. این یک تغییر معماری چندساله است که با موجودی داراییها، هویت مرکزی، احراز هویت چندعاملی و مجوزدهی در سطح منبع شروع می‌شود. فروشندگانی که آن را به‌عنوان یک بسته‌ی نصب‌شدنی می‌فروشند، در واقع یک مؤلفه از آن را می‌فروشند.
نکته‌ی مهم برای خواننده‌ی این سایت: اصل دوم اعتماد صفر — مجوزدهی در هر درخواست — دقیقاً همان چیزی است که در لایهی برنامه به آن کنترل دسترسی می‌گوییم. یعنی اعتماد صفر بدون درست‌کردن مجوزدهی داخل برنامه، ناقص است.
مرز کنترل شبکه و نقص لایهی برنامه
«فایروال و جداسازی داریم، پس برنامه‌ی ما محافظت‌شده است.» برنامه‌ی وب شما عمداً روی پورت ۴۴۳ منتشر شده تا کاربران به آن دسترسی داشته باشند — و مهاجم هم یکی از همان کاربران است. او نیازی به دور زدن فایروال ندارد: ثبت‌نام میکند، وارد می‌شود، و یک شناسه را در درخواست تغییر می‌دهد. همه‌ی بسته‌ها معتبر، رمزنگاری‌شده و مجاز هستند. کنترل شبکه ساختاراً نمی‌تواند تشخیص دهد که یک درخواست HTTPS معتبر، سوءاستفاده است — چون این تشخیص نیازمند دانستن قواعد کسبوکار است.
جدول زیر مرز را دقیق میکند:
| مسئله | کنترل شبکه | کنترل لایهی برنامه |
|---|---|---|
| سرویس داخلی در معرض اینترنت | حل میکند | — |
| پورت مدیریتی باز روی پایگاه‌داده | حل میکند | — |
| حرکت جانبی پس از رخنه | محدود میکند | — |
| دسترسی کاربر به دادهی کاربر دیگر | هیچ اثری ندارد | مجوزدهی سمت سرور |
| تزریق در پارامترهای برنامه | هیچ اثری ندارد | کوئری پارامتری و اعتبارسنجی |
| سوءاستفاده از منطق کسبوکار | هیچ اثری ندارد | طراحی و آزمون سناریوی سوءاستفاده |
| SSRF | اثر را محدود میکند | فهرست سفید مقصد در برنامه |
| ربایش نشست از مسیر ناامن | تا حدی | HSTS و پرچم‌های کوکی |
سه سطر آخرِ ستون میانی، همان دلیلی است که این سایت روی امنیت برنامه‌های وب تمرکز دارد. برای بیشتر سازمان‌های ایرانی، دادهی حساس داخل یک سامانه‌ی تحت وب یا API زندگی میکند و مسیر ورود مهاجم هم همان درِ باز و مشروع پورت ۴۴۳ است — به همین دلیل تست نفوذ برنامه‌ی وب بیشترین بازده کاهش ریسک را دارد.
ترکیب درست هر دو لایه: شبکه سطح حمله را کوچک میکند و اثر رخنه را محدود؛ آزمون لایهی برنامه، خود نقص را پیدا میکند. فهرست عملیاتی هر دو در چک‌لیست امنیت سازمان و چک‌لیست امنیتی پی‌هانتر آمده است.
پرسش‌های متداول
تفاوت امنیت شبکه و امنیت برنامه چیست؟
امنیت شبکه تعیین میکند چه چیزی به چه چیزی وصل شود؛ امنیت برنامه تعیین میکند برنامه با درخواستهای مجاز چه رفتاری داشته باشد. یک برنامه میتواند در شبکهای بیعیب اجرا شود و بهدلیل نقص کنترل دسترسی، کل دادهی مشتریان را افشا کند.
آیا فایروال جلوی هک شدن سایت را میگیرد؟
خیر. فایروال شبکه پورتهای غیرضروری را میبندد، اما سایت شما عمداً روی پورت ۴۴۳ باز است. حملات لایهی برنامه از همان مسیر مجاز انجام میشوند. WAF هم یک کنترل جبرانی است و نسبت به نقص کنترل دسترسی و منطق کسبوکار نابیناست.
جداسازی شبکه را چطور اثبات کنیم؟
فقط با آزمون: تلاش برای اتصال از هر بخش به بخشهای دیگر و مقایسهی نتیجه با سیاست اعلامشده. نمودار معماری، شاهد نیست. PCI DSS این آزمون را حداقل سالانه و پس از هر تغییر در کنترلهای جداسازی الزام کرده است.
اعتماد صفر را از کجا شروع کنیم؟
از موجودی داراییها و هویت مرکزی، سپس احراز هویت چندعاملی و حذف اعتماد مبتنی بر موقعیت شبکهای. مرحلهای که بیشترین اثر را دارد و بیشترین بیتوجهی را میبیند، مجوزدهی در سطح منبع داخل خود برنامهها است.
کنترل ترافیک خروجی چه فایدهای دارد؟
دو فایدهی مستقیم: محدودکردن ارتباط مهاجم با زیرساخت خودش پس از یک آلودگی، و کاهش دامنهی اثر SSRF. اما توجه کنید که بستن چند آدرس خاص کافی نیست؛ الگوی درست رد پیشفرض با فهرست سفید است، همراه با اصلاح در سمت برنامه.
منابع
امیر پیامنی
شکارچی ضعف‌های زیرساخت؛ از نقشه‌برداری سطح حمله تا بهره‌برداری از سرویس‌های شبکه و حرکت جانبی داخل دامنه.