آسیب‌پذیری یا پیکربندی نادرست امنیتی؛ کدام‌یک خطرناک‌تر است؟

در یک سازمان ممکن است تمام سیستم‌ها به‌روز باشند، آنتی‌ویروس و فایروال فعال باشد و حتی هیچ آسیب‌پذیری بحرانی شناخته‌شده‌ای روی سرورها وجود نداشته باشد؛ اما یک تنظیم اشتباه همچنان بتواند مسیر دسترسی مهاجم را باز کند.

برای مثال، فرض کنید یک سرور داخلی کاملاً Patch شده است، اما به دلیل یک Rule اشتباه روی Firewall، پورت مدیریتی آن از شبکه‌ای قابل دسترسی است که نباید به آن دسترسی داشته باشد. در این شرایط مشکل لزوماً وجود یک Vulnerability جدید نیست؛ نحوه پیکربندی سیستم و کنترل دسترسی، سطح حمله را افزایش داده است.

این وضعیت با عنوان Security Misconfiguration یا پیکربندی نادرست امنیتی شناخته می‌شود و می‌تواند در Firewall، Server، تجهیزات شبکه، سرویس‌های Cloud، حساب‌های کاربری و بسیاری از اجزای زیرساخت ایجاد شود.

 

پیکربندی نادرست امنیتی چیست؟

پیکربندی نادرست امنیتی زمانی رخ می‌دهد که یک سیستم، سرویس یا زیرساخت با تنظیماتی اجرا شود که از نظر امنیتی مناسب نیستند یا دسترسی و Exposure بیشتری از نیاز واقعی ایجاد می‌کنند.

این مشکل ممکن است از همان زمان نصب سیستم وجود داشته باشد یا بعدها در نتیجه تغییرات محیط ایجاد شود.

برای مثال:

• یک حساب پیش‌فرض همچنان فعال است.
• یک سرویس غیرضروری روی Server اجرا می‌شود.
• Management Interface از یک شبکه نامناسب قابل دسترسی است.
• یک Firewall Rule بیش از حد باز نوشته شده است.
• یک Storage در Cloud به‌صورت Public تنظیم شده است.
• یک کاربر مجوزی بیشتر از نیاز واقعی خود دارد.

در واقع، پیکربندی نادرست امنیتی الزاماً به معنی وجود یک نقص نرم‌افزاری نیست. ممکن است نرم‌افزار کاملاً به‌روز باشد، اما Configuration آن ناامن باشد.

در OWASP Top 10:2025، پیکربندی اشتباه امنیتی با عنوان A02:2025 در رتبه دوم قرار گرفت و مواردی مانند تنظیمات ناامن، قابلیت‌های غیرضروری، Accountهای پیش‌فرض و Permissionهای نادرست را از نمونه‌های آن می‌داند.

 

تفاوت Vulnerability با Security Misconfiguration چیست؟

این دو مفهوم به هم مرتبط هستند، اما یکسان نیستند.

Vulnerability یا آسیب‌پذیری، یک ضعف در طراحی، پیاده‌سازی، پیکربندی یا کنترل‌های یک سیستم است که می‌تواند شرایطی برای نقض محرمانگی، یکپارچگی یا دسترس‌پذیری ایجاد کند.

اما در Security Misconfiguration مشکل از نحوه تنظیم، استقرار یا مدیریت سیستم ایجاد می‌شود.

برای مثال فرض کنید یک Web Server داریم:

حالت اول:

Web Server از نسخه‌ای استفاده می‌کند که یک آسیب‌پذیری شناخته‌شده دارد.

مشکل اصلی Vulnerability است.

حالت دوم:

Web Server کاملاً Patch شده، اما پنل مدیریتی آن بدون نیاز واقعی از Internet قابل دسترسی است.

مشکل اصلی Misconfiguration است.

بنابراین یک سیستم می‌تواند هم‌زمان هر دو مشکل را داشته باشد؛ اما روش شناسایی و اصلاح آن‌ها یکسان نیست.

 

پیکربندی اشتباه چگونه سطح حمله را افزایش می‌دهد؟

هر سرویس، Port، Account یا Interface که بدون نیاز واقعی در دسترس باشد، می‌تواند بخشی از Attack Surface سازمان را تشکیل دهد.

فرض کنید یک سازمان یک سرور برای مدیریت زیرساخت دارد.

معماری صحیح:

Administrator → Management Network → Server

اما به دلیل یک تغییر اشتباه:

Internet → RDP → Server

حالا سروری که قرار بوده فقط از شبکه مدیریتی قابل دسترسی باشد، مستقیماً در معرض Internet قرار گرفته است.

این Exposure می‌تواند سطح حمله را افزایش دهد و فرصت‌هایی مانند تلاش برای سوءاستفاده از Credentialهای سرقت‌شده یا حملات Password Spraying را در اختیار مهاجم قرار دهد.

در این شرایط، مهاجم نیازی به استفاده از روش‌های پیچیده ندارد؛ همین دسترسی اشتباه می‌تواند راه ورود به Server را برای او باز کند.
در واقع، با باز شدن این مسیر، سرور بیش از حد لازم در معرض دسترسی قرار گرفته است.

 

پیکربندی‌های نادرست امنیتی که در شبکه‌های سازمانی باید بررسی شوند

۱. باز بودن Management Interface

Interface مدیریتی Firewall، Switch، Hypervisor یا Server نباید بدون دلیل از شبکه‌های غیرقابل اعتماد قابل دسترسی باشد.

برای مثال، اگر پنل مدیریتی یک Firewall از Internet قابل دسترسی باشد، مهاجم می‌تواند بدون عبور از برخی محدودیت‌های شبکه، مستقیماً سرویس مدیریتی تجهیز را هدف قرار دهد.

وضعیت نامناسب:

Internet → Firewall Management

وضعیت مناسب‌تر:

Admin → Management VLAN → Firewall Management

البته حتی در شبکه مدیریتی نیز باید دسترسی‌ها بر اساس IP، هویت کاربر و نیاز واقعی محدود شوند.

 

۲. Firewall Ruleهای بیش از حد باز

یکی از خطاهای رایج، ایجاد Ruleهایی است که برای ساده شدن مدیریت، محدوده بسیار بزرگی از ارتباطات را مجاز می‌کنند.

مثلاً:

Source: Any

Destination: Any

Service: Any

Action: Allow

چنین قوانیتی ممکن است در ظاهر مشکل یک سرویس را سریع حل کند، اما در عمل محدودیت‌های امنیتی Firewall را تا حد زیادی کاهش می‌دهد.

راهکار بهتر، مشخص کردن دقیق مبدأ، مقصد، سرویس و زمان موردنیاز است.

برای مثال:

Users → Application Server → TCP 443 → Allow

به‌جای:

Users → Any → Any → Allow

اصل مهم این است:

هر ارتباط باید به اندازه نیاز واقعی خود مجاز باشد، نه بیشتر.

 

۳. سرویس‌های غیرضروری روی سرور

فرض کنید یک سرور جدید برای اجرای یک Application راه‌اندازی شده است.

Application فقط به HTTPS نیاز دارد، اما روی سرور سرویس‌های دیگری مانند FTP، Telnet یا یک Remote Service قدیمی نیز فعال باقی مانده‌اند.

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

در نتیجه Hardening فقط نصب Patch نیست؛ باید بررسی شود:

• چه سرویس‌هایی فعال هستند؟
• کدام‌یک واقعاً موردنیازند؟
• چه Portهایی Listen می‌کنند؟
• کدام سرویس‌ها باید فقط از شبکه داخلی قابل دسترسی باشند؟

هر سرویس یا دسترسی غیرضروری باید غیرفعال یا تا حد امکان محدود شود.

 

۴. Permission بیش از نیاز

پیکربندی نادرست فقط به Network Configuration محدود نیست.

فرض کنید یک Application برای خواندن اطلاعات Database به یک Account نیاز دارد.

به‌جای دادن Permission فقط برای اجرای Queryهای موردنیاز، Account به سطح مدیریتی Database دسترسی پیدا کرده است.

در حالت عادی ممکن است هیچ مشکلی ایجاد نشود.

اما اگر Credential آن Account به سرقت برود، مهاجم همان سطح دسترسی اضافه را نیز در اختیار خواهد داشت.

به همین دلیل Least Privilege باید در مورد کاربران، Service Accountها و Applicationها نیز اعمال شود.

 

۵. منابع Cloud با دسترسی عمومی

در Cloud، یک اشتباه کوچک در Permission می‌تواند نتیجه بسیار بزرگ‌تری داشته باشد.

فرض کنید سازمان فایل‌های Backup را در یک Object Storage نگهداری می‌کند.

وضعیت مورد انتظار:

Application → Private Storage

اما به دلیل یک تنظیم اشتباه:

Internet → Public Storage

در این حالت، حتی اگر خود Storage کاملاً سالم باشد، Configuration اشتباه می‌تواند باعث افشای اطلاعات شود.

به همین دلیل در Cloud باید علاوه بر وضعیت خود سرویس، Permission، Network Exposure و Public Access نیز بررسی شود.

 

یک سناریوی واقعی: چگونه یک Rule اشتباه به مسیر نفوذ تبدیل می‌شود؟

فرض کنید یک شرکت چنین معماری‌ای دارد:

Internet

↓

FortiGate

↓

DMZ

↓

Application Server

↓

Database Server

برای دسترسی کاربران داخلی به Application، یک Rule روی Firewall ایجاد شده است:

User VLAN → Application Server → TCP 443 → Allow

این Rule منطقی است.

اما چند ماه بعد، تیم IT برای عیب‌یابی یک مشکل موقت، Rule دیگری ایجاد می‌کند:

User VLAN → Database Server → Any → Allow

مشکل برطرف می‌شود، اما Rule حذف نمی‌شود.

چند ماه بعد، یکی از سیستم‌های کاربران با یک بدافزار آلوده می‌شود و مهاجم کنترل آن سیستم را به دست می‌آورد.

اگر Rule دوم همچنان فعال باشد، مهاجم از نظر شبکه مسیر ارتباطی مستقیمی از User VLAN به Database Server خواهد داشت.

البته وجود این Rule به‌تنهایی به معنی دسترسی موفق مهاجم به داده‌های Database نیست؛ زیرا ممکن است Database همچنان Authentication، Authorization یا کنترل‌های امنیتی دیگری داشته باشد. با این حال، این Rule یک لایه مهم از محدودیت‌های شبکه را حذف کرده و یک مسیر ارتباطی غیرضروری ایجاد کرده است.

در صورت وجود Credential معتبر، ضعف در سرویس Database یا امکان سوءاستفاده از یک سرویس در دسترس، این مسیر می‌تواند برای حرکت جانبی مهاجم (Lateral Movement) مورد استفاده قرار گیرد.

 

چرا وجود چند لایه دفاعی اهمیت دارد؟

امنیت نباید فقط به یک کنترل مانند Firewall وابسته باشد. حتی اگر یک Rule به‌اشتباه بیش از حد باز باشد، کنترل‌های دیگری مانند Authentication، Network Segmentation، Least Privilege، Database Authorization و Monitoring می‌توانند احتمال تبدیل این اشتباه به یک رخداد جدی را کاهش دهند.

این رویکرد با مفهوم Defense in Depth یا «دفاع در عمق» شناخته می‌شود؛ یعنی امنیت به‌جای تکیه بر یک لایه، در چند لایه مختلف پیاده‌سازی شود.

بنابراین، هدف از اصلاح یک Configuration فقط بستن یک مسیر نیست؛ بلکه باید بررسی شود که در صورت شکست یا اشتباه یک کنترل، چه کنترل‌های دیگری از دارایی‌ها و اطلاعات سازمان محافظت می‌کنند.

یعنی یک تغییر موقت در Configuration، به یک مسیر ارتباطی دائمی و غیرضروری تبدیل شده است.

مشکل اینجا فقط وجود یک Rule نیست؛ بلکه سه مشکل هم‌زمان ایجاد شده است:

دسترسی بیش از نیاز → باقی ماندن تغییر موقت → نبود بازبینی دوره‌ای Rule

این سناریو نشان می‌دهد چرا مدیریت Configuration باید بخشی از فرآیند امنیتی مداوم سازمان باشد.

 

چگونه پیکربندی نادرست امنیتی را پیدا کنیم؟

اینجا صرفاً اسکن آسیب‌پذیری کافی نیست.

برای پیدا کردن Configurationهای اشتباه باید بدانیم سیستم اکنون چگونه تنظیم شده و وضعیت مورد انتظار چیست.

 

۱. دارایی‌ها را شناسایی کنید

قبل از بررسی Configuration باید مشخص باشد چه چیزهایی در شبکه وجود دارند:

• Serverها
• Firewallها
• Switchها
• Routerها
• Hypervisorها
• سرویس‌های Cloud
• Applicationها
• Accountهای مهم

سیستمی که اصلاً در Inventory وجود ندارد، ممکن است هیچ‌وقت در فرآیند بررسی امنیتی نیز دیده نشود.

 

۲. برای هر سیستم Baseline مشخص کنید

Security Baseline مجموعه‌ای از الزامات و تنظیمات امنیتی مورد انتظار برای یک سیستم، سرویس یا تجهیز است که بر اساس نقش سیستم، نیازهای کسب‌وکار، معماری و سیاست‌های امنیتی سازمان تعریف می‌شود.

برای مثال برای یک سرور:

• فقط سرویس‌های ضروری فعال باشند.
• RDP فقط از Management VLAN قابل دسترسی باشد.
• Accountهای پیش‌فرض غیرفعال باشند.
• کاربران معمولی Administrator نباشند.
• Logهای امنیتی فعال باشند.

حالا Configuration واقعی Server با این Baseline مقایسه می‌شود.

هر اختلاف باید بررسی شود.

 

۳. Configuration تجهیزات را بررسی کنید

در فایروال می‌توان مواردی مانند این‌ها را بررسی کرد:

• Ruleهای Any-to-Any
• Ruleهای بدون استفاده
• Policyهای قدیمی
• Management Access
• Serviceهای منتشرشده
• NATهای غیرضروری

سوئیچ:

• Management Access
• VLANها
• Trunkها
• ACLها
• Portهای بلااستفاده

سرور:

• سرویس‌های فعال
• Portهای Listening
• Local Accountها
• Permissionها
• Remote Access

این بررسی باید با نیاز واقعی سیستم مقایسه شود؛ چون هر Configuration متفاوت از حالت استاندارد الزاماً اشتباه نیست.

 

Vulnerability Scanner چه چیزی را پیدا می‌کند و چه چیزی را نه؟

این تفاوت برای تیم‌های IT و امنیت بسیار مهم است.

فرض کنید یک Vulnerability Scanner روی سرور اجرا شده و هیچ Vulnerability بحرانی گزارش نمی‌کند.

آیا می‌توان گفت سرور کاملاً امن است؟

خیر.

یک Vulnerability Scanner معمولی ممکن است تمرکز اصلی خود را بر آسیب‌پذیری‌های شناخته‌شده، نسخه نرم‌افزارها و وضعیت Patch قرار دهد.

برای مثال، Scanner ممکن است تشخیص دهد که سیستم‌عامل به‌روز است و آسیب‌پذیری شناخته‌شده‌ای ندارد؛ اما لزوماً نمی‌تواند بر اساس معماری و نیاز واقعی سازمان تشخیص دهد که آیا RDP باید از شبکه کاربران قابل دسترسی باشد یا خیر.

همچنین ممکن است وجود یک Firewall Rule قدیمی که Database Server را در معرض User VLAN قرار داده است، نیاز به بررسی جداگانه Configuration و Policy داشته باشد.

البته این موضوع به قابلیت‌های ابزار نیز بستگی دارد. برخی ابزارهای پیشرفته Vulnerability و Configuration Assessment می‌توانند علاوه بر آسیب‌پذیری‌ها، بخشی از تنظیمات، Policyها و Exposure سیستم را نیز بررسی کنند.

بنابراین نباید فرض کرد که نتیجه یک Vulnerability Scan به‌تنهایی نشان‌دهنده وضعیت کامل امنیتی Configuration است.

به همین دلیل:

Vulnerability Assessment و Configuration Assessment مکمل یکدیگر هستند.

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

در نهایت، Configuration باید نه فقط با وضعیت فعلی سیستم، بلکه با Security Baseline و نیاز واقعی سازمان نیز مقایسه شود.

 

چگونه جلوی ایجاد Configurationهای اشتباه را بگیریم؟

شناسایی Configuration اشتباه مهم است، اما جلوگیری از ایجاد آن اهمیت بیشتری دارد.

1. مدیریت تغییرات

هر تغییر مهم در Firewall، Server، Cloud یا تجهیزات شبکه باید مشخص باشد:

• چه کسی؟
• چه چیزی را؟
• چرا؟
• چه زمانی؟

تغییر داده است.

اگر یک Rule برای رفع مشکل موقت ایجاد می‌شود، باید مشخص باشد چه زمانی باید حذف یا بازبینی شود.

 

2. بازبینی دوره‌ای

Configuration یک سیستم ممکن است امروز صحیح باشد و شش ماه بعد دیگر با نیاز سازمان مطابقت نداشته باشد.

برای مثال:

یک Application حذف شده، اما Firewall Rule آن باقی مانده است.

یا یک Administrator دیگر در سازمان فعالیت نمی‌کند، اما Account او همچنان فعال است.

بنابراین بررسی دوره‌ای باید بخشی از فرآیند امنیت باشد.

 

3. استفاده از Automation

در محیط‌های بزرگ، بررسی دستی تمام Configurationها دشوار است.

می‌توان با ابزارهای Automation یا Configuration Management تغییرات را بررسی کرد و در صورت انحراف از Baseline، هشدار ایجاد کرد.

این موضوع مخصوصاً برای سازمان‌هایی که تعداد زیادی تجهیزات شبکه دارند اهمیت بیشتری پیدا می‌کند.

 

چک‌لیست سریع بررسی پیکربندی امنیتی

سؤال اصلی	مورد بررسی
آیا Interface مدیریتی از شبکه غیرقابل اعتماد قابل دسترسی است؟	Management Access
Ruleهای بیش از حد باز وجود دارند؟	Firewall Rules
سرویس غیرضروری فعال است؟	سرویس‌ها
آیا Account پیش‌فرض یا قدیمی باقی مانده؟	Accountها
کاربر یا Service Account دسترسی بیش از نیاز دارد؟	Permission
آیا RDP، SSH یا VPN بیش از حد در معرض شبکه قرار گرفته؟	Remote Access
Storage یا Resource به‌صورت Public در دسترس است؟	Cloud
آیا تغییرات ثبت و بازبینی می‌شوند؟	Configuration Change
وضعیت فعلی با استاندارد امنیتی سازمان مقایسه می‌شود؟	Baseline

این چک‌لیست جایگزین یک Security Audit کامل نیست، اما می‌تواند چند مورد پرریسک را خیلی سریع مشخص کند.

 

چرا پیکربندی نادرست امنیتی ایجاد می‌شود؟

بخش زیادی از این مشکلات نتیجه یک اشتباه بزرگ و واضح نیست.

گاهی یک Configuration در زمان ایجاد کاملاً منطقی بوده، اما بعداً شرایط تغییر کرده است.

مثلاً:

روز اول:
برای Troubleshooting یک Port باز می‌شود.

ماه سوم:
مشکل حل شده، اما Port همچنان باز است.

ماه ششم:
یک سرویس جدید به شبکه اضافه می‌شود.

ماه نهم:
یک حساب کاربری قدیمی همچنان Permission قبلی را دارد.

در این مرحله دیگر یک تغییر ساده نداریم؛ چند Configuration قدیمی روی هم قرار گرفته‌اند و سطح حمله را افزایش داده‌اند.

به همین دلیل Configuration Drift یکی از موضوعات مهم در مدیریت امنیت زیرساخت است.

Configurationهای نادرست همیشه نتیجه یک اشتباه مستقیم نیستند. این مشکلات می‌توانند در اثر تغییرات اضطراری، خطای انسانی، نبود فرآیند مناسب برای Change Management، استفاده از Templateهای نامناسب، انتقال تنظیمات از محیط‌های قدیمی یا تفاوت بین محیط‌های Development و Production نیز ایجاد شوند.

برای مثال، ممکن است یک Rule برای رفع یک مشکل فوری ایجاد شود، اما Owner مشخصی برای آن تعیین نشود و بعد از رفع مشکل نیز کسی مسئول حذف یا بازبینی آن نباشد.

به همین دلیل، جلوگیری از پیکربندی نادرست امنیتی فقط به دانش فنی افراد وابسته نیست؛ بلکه به فرآیندهای مناسب برای ثبت، تأیید، بازبینی و کنترل تغییرات نیز نیاز دارد.

 

پس کدام‌یک خطرناک‌تر است؟

پاسخ مطلقی وجود ندارد. یک Vulnerability بحرانی در سیستمی که از شبکه غیرقابل اعتماد قابل دسترسی است، می‌تواند ریسک بسیار بالایی داشته باشد. از طرف دیگر، یک Misconfiguration ساده مانند Public شدن یک Storage یا باز شدن یک Management Interface نیز می‌تواند بدون وجود هیچ Vulnerability جدیدی، پیامد جدی ایجاد کند.

بنابراین در ارزیابی ریسک نباید فقط به Severity یک Vulnerability نگاه کرد. باید Exposure، احتمال سوءاستفاده، سطح دسترسی، حساسیت دارایی و Impact احتمالی را نیز در نظر گرفت.