هیچ‌کس نمی‌تواند پیش از دیدن سامانه‌ی شما بگوید امنسازی و ارزیابی آن چقدر هزینه دارد — و هر کس عددی بدون پرسیدن سؤال بدهد، در واقع دارد یک بسته‌ی ثابت می‌فروشد، نه ارزیابی سامانه‌ی شما. این مقاله عدد نمی‌دهد؛ چیزی می‌دهد که مفیدتر است: ساختار هزینه. یعنی دقیقاً کدام ویژگی‌های سامانه‌ی شما قیمت را بالا و پایین می‌برد، مدل‌های رایج قیمت‌گذاری چه تفاوتی دارند، و چگونه دو پیشنهاد را طوری مقایسه کنید که سیب با سیب مقایسه شود.
در یک نگاه
- هزینه تابع حجم کار آزمون است، نه اندازهی شرکت شما: تعداد دارایی، تعداد نقشهای کاربری، حجم منطق کسبوکار و سطح API.
- دو بودجهی متفاوت را از هم جدا کنید: هزینه‌ی امنسازی (کار مهندسی) و هزینه‌ی ارزیابی (تست نفوذ).
- بسته‌های ارزان «امنیت سایت» در بازار غالباً یک اسکن خودکار با گزارش برندشده هستند — که کار مفیدی است، اما نامش تست نفوذ نیست.
- دو قلم را در هر پیشنهاد صریحاً بپرسید: آزمون مجدد پس از رفع و آزمون با حساب‌های احراز هویتشده. بی این دو، بخش اصلی ارزش غایب است.
- کم‌هزینه‌ترین کارها — MFA، به‌روزرسانی، بستن فایلهای افشاشده — باید پیش از سفارش ارزیابی انجام شوند تا بودجه صرف یافتههای بدیهی نشود.
چرا «قیمت امنیت سایت» یک عدد ندارد
مقایسه‌ی مفید این است: هزینه‌ی ارزیابی امنیتی مثل هزینه‌ی حسابرسی است، نه مثل قیمت یک لایسنس نرم‌افزار. کار انسانی است و واحد سنجش آن زمان متخصص است. پس هر چیزی که زمان لازم را زیاد کند، قیمت را بالا می‌برد.
سه سؤال ساده تفاوت را نشان می‌دهد. یک سایت معرفی شرکت با ده صفحه‌ی ثابت و بدون ورود کاربر، در برابر یک فروشگاه با سه نقش کاربری، درگاه پرداخت، پنل فروشندگان، اپلیکیشن موبایل و چهل اندپوینت API. هر دو «یک سایت» هستند. اما حجم کار آزمون در دومی چند برابر است، چون:
- تعداد مسیرهایی که باید آزموده شود چند برابر است.
- آزمون کنترل دسترسی باید برای هر جفت نقش انجام شود، نه یک بار.
- منطق کسبوکار — سبد، تخفیف، بازگشت وجه، تسویه‌ی فروشنده — هر کدام مجموعه‌ی آزمون خودش را می‌خواهد و هیچ ابزاری آن را خودکار نمی‌کند.
این تفاوت را می‌توان با کمترین ابهام توضیح داد، به‌شرط اینکه به‌جای پرسیدن «قیمت چقدر است؟» بپرسید «قیمت چه چیزی چقدر است؟». به همین دلیل هر ارزیابی حرفهای با یک مرحله‌ی تعیین دامنه شروع می‌شود و پیش از آن، هیچ عددی معنا ندارد.
نکته‌ی دیگری که باید صریح گفته شود: بازار امنیت در ایران نرخ ثابت و شفاف ندارد و ارقام به‌سرعت تغییر میکند. به همین دلیل در این مقاله هیچ عدد ریالی نمی‌آید — عددی که امروز نوشته شود، تا چند ماه بعد گمراه‌کننده است. آنچه ثابت می‌ماند، ساختار هزینه است.
محرک‌های واقعی هزینه
اگر می‌خواهید بدانید پیشنهاد قیمتی که دریافت کرده‌اید منطقی است یا نه، این جدول را با پیشنهادتان مقایسه کنید. هر ردیف یک متغیر واقعی است که در تعیین دامنه پرسیده می‌شود.
| محرک هزینه | چرا هزینه را تغییر می‌دهد | اثر بر قیمت |
|---|---|---|
| تعداد دارایی (دامنه، زیردامنه، محیط) | هر دارایی مرحله‌ی شناسایی و پوشش آزمون مستقل می‌خواهد | خطی به بالا |
| پیچیدگی برنامه (تعداد قابلیت و گردش کار) | حجم منطقی که باید دستی آزموده شود | بالا |
| تعداد نقشهای احراز هویتشده | آزمون کنترل دسترسی برای هر جفت نقش تکرار می‌شود | بسیار بالا |
| سطح API (تعداد اندپوینت، GraphQL، وب‌هوک) | API اغلب منطق بیشتری از رابط وب دارد و مستندسازی‌اش ناقص است | بالا |
| وجود پرداخت و دادهی حساس | عمق آزمون منطق و الزام‌های انطباقی بیشتر | متوسط تا بالا |
| دسترسی به کد منبع | پوشش را بالا می‌برد اما زمان بازبینی اضافه میکند | بستگی به تصمیم دارد |
| محیط آزمون یا آزمون روی عملیاتی | آزمون روی محیط عملیاتی احتیاط و هماهنگی بیشتری می‌طلبد | متوسط |
| دامنه‌ی آزمون مجدد | راستی‌آزمایی رفع، یک دور کار مستقل است | متوسط |
| عمق گزارش و مخاطب آن | گزارش فنی، خلاصه‌ی مدیریتی، ارائه‌ی حضوری و پاسخ به ممیز | کم تا متوسط |
| محدودیت زمانی | تحویل فشرده یا کار در بازه‌های خاص | افزایش |
محرک شماره‌ی سه — تعداد نقش‌ها — بیشترین اثر را دارد و کمتر از همه فهمیده می‌شود. دلیلش این است که کنترل دسترسی شکسته رتبه‌ی یک OWASP Top 10:2025 است و OWASP گزارش میکند در دادهی این نسخه ۱۰۰٪ برنامه‌های آزموده‌شده نوعی نقص کنترل دسترسی داشته‌اند. آزمون این دسته هیچ راه خودکاری ندارد: آزمونگر باید با هر نقش وارد شود، مجموعه‌ی کامل درخواست‌ها را ثبت کند، و هر درخواست را با نشست نقش دیگر بازپخش کند. با سه نقش، این کار سه‌برابر یک نقش نیست — بیشتر است.
مدل‌های قیمت‌گذاری و تفاوت واقعی آن‌ها
سه مدل رایج وجود دارد و هر کدام برای وضعیت متفاوتی مناسب است.
۱. مبتنی بر روزـنفر
پیمانکار تعداد روز کار متخصص را برآورد میکند و قیمت روی همان بسته می‌شود. شفاف‌ترین مدل است، چون رابطه‌ی عمق آزمون و قیمت را مستقیم میکند. اگر بودجه محدود است، می‌توانید دامنه را کوچک کنید (مثلاً فقط ماژول پرداخت) به‌جای اینکه عمق آزمون روی کل سامانه رقیق شود — که تصمیم درست‌تری است. پرسش کلیدی: «این چند روز چطور بین شناسایی، آزمون دستی، گزارش و آزمون مجدد تقسیم می‌شود؟»
۲. بسته‌ی ثابت
قیمت مقطوع برای یک دامنه‌ی از پیش تعریف‌شده. مزیتش پیش‌بینی‌پذیری است و برای سامانه‌های کوچک و استاندارد منطقی است. ریسکش این است که اگر تعریف دامنه دقیق نباشد، هر چیزی بیرون آن می‌افتد. اگر بسته‌ی ثابت می‌خرید، فهرست مستثنیات را بخواهید — این مهم‌تر از فهرست شمول است.
۳. اشتراکی و پیوسته
اسکن دوره‌ای خودکار به‌همراه بازبینی انسانی در فواصل معین. برای سامانه‌هایی با چرخه‌ی انتشار سریع منطقی است، چون تست سنگین سالانه در چنین محیطی تا سه ماه بعد کهنه می‌شود. اما توجه کنید که اشتراک اسکن، جانشین آزمون دستی دوره‌ای نیست؛ مکمل آن است. ترکیب سالم: اسکن پیوسته برای مسائل شناخته‌شده و رگرسیون، به‌علاوه‌ی آزمون دستی برای کنترل دسترسی و منطق در نقاط عطف محصول.
در هر سه مدل، ساختار هزینه‌ی تست نفوذ به تفصیل بیشتری در هزینه‌ی تست نفوذ بررسی شده است.
بسته‌های ارزان «امنیت سایت» واقعاً چه هستند؟
اگر پیشنهادی دریافت کرده‌اید که قیمتش به‌طور محسوسی از بقیه پایین‌تر است و بدون پرسیدن هیچ سؤالی از سامانه‌ی شما داده شده، به‌احتمال زیاد محتوای واقعی‌اش این است: یک یا چند اسکنر خودکار روی دامنه اجرا می‌شود، خروجی به یک قالب گزارش با لوگو منتقل می‌شود، و فایل PDF تحویل داده می‌شود.
نکته‌ی مهم: این کار بی‌ارزش نیست. اسکن خودکار در محدودهی خودش واقعاً مفید است — پیکربندی نادرست، هدرهای غایب، نسخه‌های آسیب‌پذیر شناخته‌شده، فایلهای افشاشده و اعتبارنامه‌ی پیش‌فرض را خوب پیدا میکند. مشکل، نام‌گذاری است: وقتی این خروجی «تست نفوذ» نامیده می‌شود، شما تصور میکنید ارزیابی کامل شده در حالی که کل دسته‌ی رتبه‌یک فهرست OWASP آزموده نشده است.
«گزارش امنیتی گرفتیم و مشکل بحرانی نداشت، پس سامانه امن است.» پیش از این نتیجه‌گیری، سه چیز را در گزارش بررسی کنید. اول: آیا آزمون با حساب‌های احراز هویتشده و بیش از یک نقش انجام شده؟ اگر گزارش فقط شامل بخش عمومی سایت است، بخش اصلی برنامه آزموده نشده. دوم: آیا یافته‌ای در دسته‌های کنترل دسترسی، منطق کسبوکار یا شرایط مسابقه وجود دارد یا حتی صریحاً گفته شده که آزموده شده و مشکلی نداشته؟ اگر این دستهها در گزارش کاملاً غایب‌اند، احتمالاً آزموده نشدهاند. سوم: آیا هر یافته دارای مراحل بازتولید، شاهد و راهکار رفع مشخص است، یا فقط متن عمومی خروجی ابزار است؟ گزارشی که «نصب WAF» را به‌عنوان راهکار رفع یک آسیب‌پذیری کد پیشنهاد می‌دهد، نشانه‌ی روشنی است که یافته واقعاً تحلیل نشده.
سنجه‌ی سریع و منصفانه برای تشخیص: آیا پیش از دادن قیمت، از شما سؤال پرسیدند؟ پیمانکاری که ارزیابی واقعی انجام می‌دهد ناچار است بپرسد چند نقش کاربری دارید، API دارید یا نه، چند دارایی در دامنه است، آزمون روی عملیاتی است یا محیط آزمون، و حساب‌های آزمون چطور تأمین می‌شود. بدون این پاسخ‌ها، برآورد حجم کار ممکن نیست. برای دیدن اینکه یک گزارش حرفهای چه ساختاری دارد، گزارش تست نفوذ را ببینید.
دو بودجهی متفاوت: ارزیابی و امنسازی
یک اشتباه پرهزینه‌ی رایج این است که همه‌ی بودجهی امنیت صرف ارزیابی شود و هیچ چیز برای رفع نماند. نتیجه‌اش گزارشی است که در پوشه می‌ماند.
این دو قلم را جدا برنامه‌ریزی کنید:
- هزینه‌ی امنسازی: کار مهندسی روی سامانه‌ی خودتان. شامل زمان تیم توسعه و DevOps، احتمالاً ارتقای زیرساخت (مثلاً انتقال از هاست اشتراکی به VPS)، سرویس پشتیبان‌گیری بیرونی، و ابزارهای پایش. بخش قابل توجهی از این‌ها هزینه‌ی نقدی ندارد و فقط زمان می‌برد — فهرست اولویت‌دار در افزایش امنیت سایت آمده است.
- هزینه‌ی ارزیابی: پرداخت به طرف بیرونی برای اینکه بگوید چه چیزی از قلم افتاده. این کار را نمی‌توان به‌درستی داخلی انجام داد، چون کسی که سامانه را ساخته، همان مفروضات را دارد که در طراحی داشت.
نسبت منطقی برای شروع، اختصاص بخش عمده‌ی بودجهی اولیه به امنسازی پایه است. دلیلش ساده است: اگر پنل مدیریت شما MFA ندارد، فایل پشتیبان در ریشه‌ی وب است و افزونه‌ها دو سال بهروز نشدهاند، ارزیابی حرفهای فقط همینها را به شما می‌گوید — و شما برای شنیدن چیزی پول داده‌اید که با خودارزیابی رایگان هم میدانستید. پس از انجام پایهها، ارزیابی به سراغ چیزهایی میرود که خودتان نمی‌توانستید پیدا کنید.
قلم فراموش‌شده: هزینه‌ی رفع
هر گزارش، کار ایجاد میکند. برای بودجه‌ریزی واقع‌بینانه، پیش از سفارش ارزیابی از تیم بپرسید ظرفیت انجام اصلاحات را در چه بازه‌ای دارند. یافتههای پیکربندی معمولاً سریع بسته می‌شوند؛ اما یافته‌ای مثل «کنترل دسترسی در لایه‌ی داده اعمال نمی‌شود» می‌تواند یک پروژه‌ی چند هفته‌ای باشد. این را از قبل بدانید تا گزارش به یک فهرست بلاتکلیف تبدیل نشود.
چگونه یک پیشنهاد قیمت را ارزیابی کنیم
این ده پرسش را از هر پیمانکار بپرسید. پاسخ‌ها، دو پیشنهاد با قیمت متفاوت را قابل مقایسه میکند:
- دامنه‌ی دقیق چیست و چه چیزی مستثنا است؟ فهرست مکتوب دارایی‌ها، زیردامنه‌ها و اندپوینت‌ها.
- آزمون با حساب احراز هویتشده انجام می‌شود؟ با چند نقش؟ اگر پاسخ «نه» یا «یک نقش» است، بخش اصلی برنامه آزموده نمی‌شود.
- سهم آزمون دستی در برابر اسکن خودکار چقدر است؟ پاسخ باید مشخص و قابل دفاع باشد.
- پوشش آزمون بر پایه‌ی چه چارچوبی گزارش می‌شود؟ پاسخ حرفهای: پوشش بر پایه‌ی WSTG و رده‌بندی ریسک بر پایه‌ی OWASP Top 10:2025 و CWE.
- شدت یافته‌ها با چه چیزی امتیازدهی می‌شود؟ پاسخ درست: CVSS، با ذکر صریح نسخه (نسخه‌ی جاری استاندارد ۴٫۰ است، اما نسخه‌ی ۳٫۱ در دادهی واقعی همچنان غالب است و استفاده از هر دو قابل دفاع است — مهم این است که گفته شود کدام).
- آزمون مجدد پس از رفع در قیمت هست؟ اگر نیست، هزینه و شرایطش چیست؟ ارزیابی بدون آزمون مجدد نیمه‌کاره است.
- گزارش چه چیزی دارد؟ مراحل بازتولید، شاهد، امتیاز شدت، راهکار رفع قابل اجرا برای تیم توسعه، و خلاصه‌ی مدیریتی.
- قرارداد و مجوز کتبی چطور تنظیم می‌شود؟ قواعد تعامل، بازه‌ی زمانی مجاز، محدودیت‌های آزمون تخریبی، و محرمانگی داده.
- دادهی من در جریان آزمون چطور مدیریت و در پایان چطور حذف می‌شود؟
- چه کسی کار را انجام می‌دهد؟ نام و سابقه‌ی آزمونگر، نه فقط نام شرکت.
یک هشدار درباره‌ی ادعاهای انطباق: عباراتی مثل «گواهی OWASP»، «انطباق با OWASP» یا «OSSTMM Certified» وجود خارجی ندارند — OWASP نهاد صدور گواهی نیست و چنین گواهی‌هایی صادر نمی‌شود. ادعای قابل دفاع این شکل است: «پوشش آزمون بر پایه‌ی WSTG، رده‌بندی ریسک بر پایه‌ی OWASP Top 10:2025 و CWE، امتیازدهی شدت با CVSS، و ساختار پروژه بر پایه‌ی فازهای شناخته‌شده‌ی تست نفوذ». اگر پیشنهادی گواهی‌هایی را ادعا میکند که وجود ندارند، این خودش یک داده درباره‌ی کیفیت کار است.
ترتیبی که بیشترین بازده را از بودجه می‌گیرد
اگر بودجهی محدودی دارید و می‌خواهید بیشترین کاهش ریسک را بگیرید، این ترتیب را رعایت کنید:
- کارهای بدون هزینه‌ی نقدی. MFA روی همه‌ی حساب‌های مدیریتی، حذف حساب‌های بی‌استفاده، به‌روزرسانی اجزا و حذف افزونه‌های بی‌استفاده، بستن فایلهای افشاشده، خاموش کردن پیام خطای پرجزئیات، و محدودسازی نرخ ورود. این‌ها فقط زمان می‌برند و پرتکرارترین مسیرهای نفوذ را می‌بندند.
- پشتیبان بیرونی با آزمون بازیابی. کم‌هزینه‌ترین بیمه‌ی موجود. پشتیبانی که بازیابی‌اش آزمون نشده، پشتیبان نیست.
- خودارزیابی ساختاریافته. با چک‌لیست امنیتی و گام‌های بررسی امنیت سایت، یافتههای ارزان را خودتان پیدا و رفع کنید.
- ارزیابی حرفهای با دامنه‌ی هدفمند. اگر بودجه برای کل سامانه کافی نیست، دامنه را به بخش پرارزش محدود کنید — مثلاً جریان پرداخت و ماژول احراز هویت — به‌جای آنکه عمق آزمون روی همه‌جا رقیق شود.
- رفع، و سپس آزمون مجدد.
- آموزش تیم توسعه. برای سازمانی که تیم داخلی دارد، این تنها هزینه‌ای است که نرخ تولید آسیب‌پذیری را کم میکند، نه فقط موجودی فعلی را. دوره‌ی سازمانی توسعه‌ی امن برای همین نقطه طراحی شده است.
و در نهایت، مسیر گرفتن یک برآورد واقعی: دامنه را روی کاغذ بیاورید — فهرست دارایی‌ها، نقشهای کاربری، وجود یا نبود API، و اینکه آزمون روی محیط عملیاتی است یا آزمایشی. با همین یک صفحه، هر پیمانکار حرفهای می‌تواند برآورد بدهد و شما می‌توانید پیشنهادها را واقعاً مقایسه کنید. برای دریافت برآورد با دامنه‌ی مشخص، فرم مشاوره و تعیین دامنه نقطه‌ی شروع است؛ و برای دیدن شمول خدمات، صفحه‌ی تست نفوذ وب.
پرسش‌های متداول
هزینه امنیت سایت چقدر است؟
عدد ثابتی وجود ندارد، چون هزینه تابع حجم کار است نه اندازهی کسبوکار. متغیرهای اصلی: تعداد دارایی و زیردامنه، پیچیدگی برنامه، تعداد نقشهای کاربری احراز هویتشده (پرتأثیرترین عامل)، وسعت سطح API، وجود پرداخت و دادهی حساس، و اینکه آزمون مجدد پس از رفع در دامنه هست یا نه. برآورد واقعی فقط پس از تعیین دامنه ممکن است.
چرا بعضی شرکت‌ها قیمت خیلی پایین‌تری می‌دهند؟
معمولاً چون محتوای کار متفاوت است. پیشنهاد ارزان اغلب یک اسکن خودکار با گزارش برندشده است — کار مفیدی که پیکربندی نادرست و نسخه‌های آسیب‌پذیر را پیدا میکند، اما آزمون احراز هویتشده با چند نقش، آزمون کنترل دسترسی و آزمون منطق کسبوکار ندارد. سنجه‌ی تشخیص ساده است: آیا پیش از دادن قیمت از شما سؤال پرسیدند؟
آیا تست نفوذ ارزان بهتر از هیچ است؟
در محدودهی خودش بله — اسکن خودکار یافتههای ارزان را پیدا میکند و همین ارزش دارد. خطر واقعی، اطمینان کاذب است: اگر گزارشی که فقط اسکن بوده «تست نفوذ» نامیده شود، شما تصور میکنید ارزیابی کامل شده در حالی که کنترل دسترسی و منطق کسبوکار — پرتأثیرترین دستهها — آزموده نشدهاند. پس بخرید، اما با نام درست و انتظار درست.
آزمون مجدد باید در قیمت باشد؟
بله، و اگر نیست باید صریحاً پرسیده شود. بدون آزمون مجدد، شما فهرست مشکلات را دارید اما تأیید نشده که اصلاحاتتان واقعاً مؤثر بوده — و رفع ناقص در عمل شایع است. در الزام‌های حوزه‌ی پرداخت، آزمون مجدد پس از رفع صریحاً اجباری است.
برای کاهش هزینه، دامنه‌ی تست را کوچک کنم یا عمق را؟
دامنه را کوچک کنید، نه عمق را. آزمون عمیق روی ماژول پرداخت و احراز هویت، ارزش بیشتری دارد از آزمون سطحی روی کل سامانه — چون یافتههای پرتأثیر در همان بخش‌های حساس متمرکزند و آزمون سطحی همان چیزهایی را پیدا میکند که یک اسکن رایگان هم می‌یافت.
چه بخشی از بودجهی امنیت باید صرف امنسازی شود و چه بخشی صرف ارزیابی؟
در شروع، بخش عمده به امنسازی پایه. اگر MFA فعال نیست، اجزا بهروز نشدهاند و فایلهای افشاشده باز ماندهاند، ارزیابی حرفهای فقط همینها را برمیگرداند — چیزی که با خودارزیابی رایگان هم میدانستید. پس از انجام پایهها، ارزیابی به سراغ دستههایی میرود که خودتان قادر به یافتنشان نیستید و ارزش پول در همانجاست.
منابع
مهدی مرادلو
محقق امنیتی با تمرکز روی منطق کسبوکار و زنجیره‌های حمله‌ی پیچیده. اسکوپ‌بندی پروژه‌ها و تضمین کیفیت گزارش‌ها با اوست.