فهرست چالش‌های امنیت سایبری سازمانها در بیشتر مقاله‌ها به «افزایش تهدیدات» و «پیچیدگی حملات» ختم می‌شود؛ هیچ‌کدام قابل اقدام نیست. موانع واقعی که پروژه‌های امنیت را متوقف می‌کنند جنس دیگری دارند: سامانه‌ای که مالکش دیگر در شرکت نیست، سرویسی که هیچ‌کس نمی‌داند چه کسی راه انداخته، تیم امنیتی که سه نفر است و باید پاسخ‌گوی چهل توسعه‌دهنده باشد. این مقاله شش مانع تکرارشونده را با نشانه، هزینهی واقعی و پاسخ عملی بررسی می‌کند.
در یک نگاه
- شش مانع تکرارشونده: سامانهی قدیمی، شدو آیتی، کمبود نیرو، قاب‌بندی بودجه، اصطکاک توسعه و امنیت، و ریسک شخص ثالث.
- ریسک زنجیرهی تأمین در OWASP Top 10:2025 به دسته‌ی مستقل
A03:2025ارتقا یافت و دیگر فقط «کتابخانه‌ی آسیب‌پذیر» نیست. - بیشتر شکست‌ها سازمانی‌اند نه فنی: نبود مالک، نبود زمان رسمی، نبود مسیر تصمیم.
- پاسخ پایدار به کمبود نیرو، توزیع مسئولیت است نه استخدام بیشتر.
سامانه‌های قدیمی که کسی جرئت دست‌زدن به آنها را ندارد
الگو آشناست: یک سامانهی حیاتی که ده سال پیش نوشته شده، روی نسخه‌ای از چارچوب اجرا می‌شود که دیگر پشتیبانی نمیشود، توسعه‌دهنده‌ی اصلی‌اش رفته و هیچ‌کس نمی‌داند اگر وابستگی‌ها به‌روز شوند چه چیزی می‌شکند.
هزینهی واقعی این وضعیت فقط آسیب‌پذیری‌های شناخته‌شده نیست؛ ترس از تغییر است. سازمانی که نمی‌تواند وصله کند، عملاً کل چرخه‌ی مدیریت آسیب‌پذیری‌اش را از دست می‌دهد.
پاسخ عملی
- مرزبندی بهجای بازنویسی. بازنویسی کامل معمولاً هرگز اتفاق نمی‌افتد. سامانه را پشت یک لایهی احراز هویت و مجوزدهی مدرن قرار دهید و سطح تماس مستقیمش با اینترنت را کم کنید.
- آزمون رگرسیون قبل از وصله. نبود آزمون خودکار، ریشه‌ی ترس است. کمترین سرمایه‌گذاری مؤثر، نوشتن آزمون برای مسیرهای حیاتی است.
- وصله‌ی مرحلهای. OWASP در
A03:2025صریحاً انتشار مرحلهای بهجای همزمان را توصیه می‌کند — دقیقاً برای همین ریسک.
نکته‌ی مهم: سامانهی قدیمی الزاماً پرخطرترین دارایی نیست. اولویت را باید بر پایه‌ی دادهای که نگه می‌دارد و میزان در معرض بودنش تعیین کرد، نه بر پایه‌ی سن کد. مدیریت آسیب‌پذیری چارچوب این اولویت‌گذاری را می‌دهد.
شدو آیتی و موجودی ناقص
شدو آیتی (Shadow IT) یعنی سرویس‌هایی که خارج از فرایند رسمی راه‌اندازی شده‌اند: زیردامنه‌ای برای یک کمپین بازاریابی، پنل مدیریتی یک ابزار داخلی، محیط استیجینگ روی یک سرور ابری شخصی، یا فرم‌ساز شخص ثالثی که تیم پشتیبانی خودش راه انداخته.
این‌ها به دو دلیل خطرناک‌اند: در فهرست دارایی نیستند پس هیچ کنترلی روی‌شان اعمال نمیشود، و معمولاً بدون احراز هویت یا با اعتبارنامه‌ی پیش‌فرض بالا میآیند — همان چیزی که A02:2025 با عنوان پیکربندی نادرست توصیف می‌کند و در Top 10:2025 از رتبه‌ی پنجم به رتبه‌ی دوم صعود کرده است.
پاسخ عملی
سرکوب جواب نمی‌دهد؛ شدو آیتی معمولاً به این دلیل به وجود می‌آید که مسیر رسمی کند است. دو اقدام مکمل:
- کشف مستمر دارایی از بیرون. شمارش زیردامنه‌ها و بررسی سرویس‌های زنده باید فرایند دوره‌ای باشد، نه کار یک‌باره‌ی پیش از ارزیابی.
- مسیر رسمی سریع. اگر راه‌اندازی یک زیردامنه‌ی جدید از مسیر رسمی سه روز طول بکشد، تیم‌ها از آن استفاده می‌کنند؛ اگر سه هفته طول بکشد، دورش می‌زنند.
«سرویس داخلی است و از اینترنت در دسترس نیست، پس ریسکی ندارد.» دو فرض پنهان در این جمله وجود دارد که هر دو مرتب نقض میشوند: این‌که واقعاً از بیرون در دسترس نیست (پنل‌های «داخلی» به‌طور مرتب روی اینترنت پیدا میشوند)، و این‌که مهاجم هرگز به شبکه‌ی داخلی نمی‌رسد. یک نقص SSRF در یک برنامه‌ی بیرونی کافی است تا سرویس‌های داخلی از دید همان برنامه قابل دسترسی شوند.
کمبود نیروی متخصص و نگه‌داشت
این چالش واقعی است، اما پاسخ رایج به آن — «استخدام بیشتر» — معمولاً شدنی نیست. سه راهکاری که در عمل بازده دارند:
- توزیع مسئولیت بهجای تمرکز. مدل قهرمان امنیت، بار تیم کوچک امنیت را در تیم‌های توسعه پخش می‌کند. شرح آن در امنیت سایبری سازمانی آمده است.
- خودکارسازی کارهای تکراری. اسکن وابستگی، بررسی پیکربندی و آزمون‌های امنیتی پایه باید در خط لوله اجرا شوند تا وقت انسان صرف کاری شود که فقط انسان انجام می‌دهد: منطق کسب‌وکار و کنترل دسترسی.
- برون‌سپاری هدفمند تخصص کمیاب. نگه‌داشتن یک متخصص تست نفوذ تمام‌وقت در سازمانی که سالی دو ارزیابی نیاز دارد، اقتصادی نیست. تحلیل این تصمیم در تیم تست نفوذ آمده است.
در مورد نگه‌داشت: خروج نیروی امنیت معمولاً به دلیل حقوق تنها نیست. نبود مسیر رشد فنی، نبود اختیار تصمیم‌گیری و کار مداوم روی هشدارهای بی‌ارزش، سه دلیل تکرارشونده‌ای‌اند که در گفت‌وگوهای خروج بیشتر از حقوق تکرار میشوند. مسیرهای شغلی این حوزه در مشاغل امنیت سایبری بررسی شده است.
قاب‌بندی بودجه: چرا درخواست‌ها رد میشوند
درخواست بودجه‌ی امنیت معمولاً به این شکل رد می‌شود که هیچ‌وقت رسماً رد نمیشود؛ فقط به سال بعد موکول می‌شود. علتش تقریباً همیشه قاب‌بندی است:
| قاب‌بندی ناکارآمد | قاب‌بندی مؤثر |
|---|---|
| «حملات سایبری در حال افزایش است» | «این سه سامانه داده‌ی پرداخت مشتری را نگه می‌دارند و در ۱۸ ماه گذشته ارزیابی نشده‌اند» |
| «به ابزار X نیاز داریم» | «این تصمیم مشخص را نمی‌توانیم بگیریم چون این داده را نداریم» |
| «ریسک بالاست» | «اگر این سرویس یک روز از دسترس خارج شود، این مقدار سفارش متوقف می‌شود» |
| «باید امن باشیم» | «مشتری سازمانی جدید، گزارش ارزیابی امنیتی می‌خواهد و بدون آن قرارداد بسته نمیشود» |
ستون دوم یک ویژگی مشترک دارد: به تصمیم و پیامد قابل اندازهگیری متصل است، نه به ترس. استدلال‌های بیشتر برای این گفت‌وگو در اهمیت امنیت سایبری و ساختار هزینه در هزینهی تست نفوذ آمده است.
اصطکاک میان توسعه و امنیت
الگوی رایج: تیم امنیت گزارشی با ۸۰ یافته تحویل می‌دهد، تیم توسعه آن را وسط یک چرخه‌ی انتشار دریافت می‌کند، و نتیجه‌اش بی‌اعتمادی دوطرفه است. ریشه‌ی این اصطکاک معمولاً سه چیز است:
- زمان‌بندی. یافته‌ای که در مرحلهی طراحی هزینهی یک جلسه دارد، پس از انتشار هزینهی چند اسپرینت پیدا می‌کند.
- کیفیت یافته. گزارشی که گام بازتولید ندارد یا مثبت کاذب دارد، اعتبار کل گزارش را از بین می‌برد. یک یافته‌ی نادرست، ده یافته‌ی درست را بی‌اثر می‌کند.
- راهکار غیرعملی. نوشتن «ورودی را اعتبارسنجی کنید» راهکار نیست. راهکار، نام تابع، الگوی جایگزین و نمونه‌ی کد است.
پاسخ عملی
یافتهها را با اولویت و بهصورت تدریجی تحویل دهید، نه یک‌جا در پایان. هر یافته باید مستقیماً به تیکت تبدیل شود: عنوان، گام بازتولید، اثر، راهکار مشخص. ساختاری که این کار را ممکن می‌کند در گزارش تست نفوذ توضیح داده شده. و مؤثرترین اقدام بلندمدت، جابه‌جاکردن نقطه‌ی ورود امنیت به مرحلهی طراحی است — همان چیزی که مدلسازی تهدید انجام می‌دهد.
ریسک شخص ثالث و زنجیرهی تأمین
در OWASP Top 10:2025، دسته‌ی A03:2025 با عنوان نقص‌های زنجیرهی تأمین نرمافزار جانشین دسته‌ی «مؤلفه‌های آسیب‌پذیر و منسوخ» شد و دامنه‌اش گسترده‌تر است: نه فقط کتابخانه‌های دارای آسیب‌پذیری شناخته‌شده، بلکه کل فرایند ساخت، توزیع و بهروزرسانی نرمافزار — از ابزار ساخت و خط لولهی CI/CD تا کانال توزیع. این دسته اکنون در رتبه‌ی سوم قرار دارد.
OWASP در همین دسته به رخدادهای واقعی نام‌برده استناد می‌کند: بهروزرسانی آلوده‌ی یک تأمین‌کننده‌ی مورد اعتماد در سال ۲۰۱۹ که حدود ۱۸٬۰۰۰ سازمان را آلوده کرد، و کرم خودانتشار npm در سال ۲۰۲۵ که بیش از ۵۰۰ نسخه‌ی بسته را آلوده کرد و با سرقت توکن‌ها گسترش یافت.
پاسخ عملی
- موجودی متمرکز و SBOM برای همهی مؤلفهها، همراه با رصد پیوسته‌ی CVE؛
- دریافت فقط از منابع رسمی با راستی‌آزمایی امضا — و ترجیحاً از یک مخزن داخلی کنترل‌شده؛
- تفکیک وظایف در خط لولهی CI/CD و بازبینی تغییرات پیکربندی خط لوله؛
- MFA روی همهی زیرساخت توسعه — مخزن کد، رجیستری بسته، سرویس ساخت؛
- انتشار مرحلهای بهجای استقرار همزمان روی همهی محیط‌ها.
برای پیمانکاران دارای دسترسی هم همین منطق برقرار است: بند امنیتی در قرارداد، حداقل دسترسی، و امکان قطع سریع. اگر می‌خواهید بدانید این ریسک در برنامه‌های وب شما چطور بروز می‌کند، تست نفوذ وب نقطه‌ای است که وابستگی‌های در معرض اینترنت و پیکربندی واقعی محیط تولید بررسی می‌شود.
پرسش‌های متداول
بزرگترین چالش امنیت سایبری سازمانها چیست؟
در تجربهی عملی، نبود موجودی دقیق دارایی و نبود مالک مشخص برای ریسک. تقریباً همهی موانع دیگر — سامانهی قدیمی، شدو آیتی، بودجه — از دل همین دو مشکل بیرون میآیند یا با آنها تشدید میشوند.
با سیستم قدیمی که نمیشود بهروزرسانی کرد چه کنیم؟
بهجای بازنویسی کامل که معمولاً هرگز انجام نمیشود، سطح در معرض بودنش را کم کنید: پشت لایهی احراز هویت و مجوزدهی مدرن ببرید، دسترسی شبکهایاش را محدود کنید، برای مسیرهای حیاتی آزمون رگرسیون بنویسید و وصله را مرحلهای اعمال کنید.
چطور برای امنیت بودجه بگیریم؟
درخواست را به یک تصمیم و پیامد قابل اندازهگیری متصل کنید، نه به ترس. مثلاً: کدام سامانه چه دادهای دارد، آخرین ارزیابی کی بوده، و توقف آن چه هزینهی عملیاتی دارد. الزام مشتری سازمانی برای دریافت گزارش ارزیابی هم استدلال بسیار مؤثری است.
ریسک زنجیرهی تأمین نرمافزار را چطور کم کنیم؟
موجودی متمرکز مؤلفهها و SBOM، دریافت بسته فقط از منابع رسمی با بررسی امضا، تفکیک وظایف در خط لولهی CI/CD، احراز هویت چندعاملی روی زیرساخت توسعه، و انتشار مرحلهای بهجای استقرار همزمان.
چطور اصطکاک بین تیم توسعه و امنیت را کم کنیم؟
یافتهها را زودتر و بهصورت اولویتدار تحویل دهید، هر یافته را با گام بازتولید و راهکار مشخص در سطح کد ارائه کنید، و از مثبت کاذب پرهیز کنید. مؤثرترین اقدام بلندمدت، ورود امنیت در مرحلهی طراحی از طریق مدلسازی تهدید است.
منابع
مهدی مرادلو
محقق امنیتی با تمرکز روی منطق کسب‌وکار و زنجیره‌های حمله‌ی پیچیده. اسکوپ‌بندی پروژه‌ها و تضمین کیفیت گزارش‌ها با اوست.