نمونه قرارداد تست نفوذ: ۱۲ بند ضروری

چرا این بندها اهمیت دارند — توضیح عملی

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

دامنه و فهرست دارایی: مرزی که باید کشیده شود

«تست نفوذ سایت شرکت» تعریف دامنه نیست. دامنه یعنی فهرستی ردیف‌به‌ردیف از دارایی‌ها با شناسه‌ی دقیق: دامنه و زیردامنه‌ها، بازه‌های IP، نام بسته‌ی اپلیکیشن، مسیر پایه‌ی API و نسخه‌اش. کنار هر ردیف باید سه چیز مشخص باشد: محیط (عملیاتی یا هم‌ارز تست)، نقش‌های کاربری که در اختیار مجری قرار می‌گیرد، و سطح حساسیت.

نکته‌ای که اغلب فراموش می‌شود، تکلیف زیردامنه‌های کشف‌شده در حین کار است. اگر در مرحله‌ی شناسایی زیردامنه‌ای پیدا شد که در پیوست نیست، پیش‌فرض باید «خارج از دامنه» باشد و افزودنش نیازمند تأیید کتبی. همچنین تکلیف دارایی‌های شخص ثالث را روشن کنید: میزبانی اشتراکی، سرویس ابری و سرویس‌های SaaS اغلب قواعد و مجوز جداگانه‌ی خودشان را می‌خواهند و کارفرما لزوماً اختیار صدور مجوز آزمون روی آن‌ها را ندارد. تفصیل انواع دامنه را در اسکوپ تست نفوذ نوشته‌ایم.

مجوز کتبی: چیزی که هیچ بند دیگری جایش را نمی‌گیرد

مجوز تست، برگه‌ای جدا از قرارداد است که در طول پروژه در دسترس هر دو طرف می‌ماند. باید امضاکننده‌ای داشته باشد که واقعاً اختیار آن دارایی را دارد — نه صرفاً کسی که پروژه را سفارش داده — و باید بازه‌ی زمانی و فهرست دارایی را تکرار کند. توصیه‌ی عملی: نام و راه تماس فوری هر دو طرف را در همان برگه بنویسید، تا اگر تیم پایش کارفرما ترافیک آزمون را دید، در چند دقیقه روشن شود که این یک آزمون مجاز است و نه یک حادثه.

قواعد تعامل (Rules of Engagement)

این بخش تعیین می‌کند مجری «چه کاری» و «چطور» انجام دهد. حداقل‌هایی که باید تصریح شود: آیا آزمون اختلال سرویس مجاز است (پیش‌فرض حرفه‌ای: خیر)، آیا مهندسی اجتماعی روی کارکنان در دامنه است (پیش‌فرض: خیر)، آیا تغییر یا حذف داده‌ی واقعی مجاز است (پیش‌فرض: خیر؛ اثبات با کمترین اثر ممکن انجام می‌شود)، حداکثر نرخ درخواست، و اینکه اگر مجری به دسترسی سطح بالا رسید تا کجا اجازه‌ی پیش‌روی دارد. یک بند «توقف اضطراری» هم لازم است: چه کسی، از چه راهی و در چه زمانی می‌تواند آزمون را متوقف کند.

بند دیگری که معمولاً جا می‌ماند: تکلیف کشف داده‌ی حساس واقعی. اگر مجری در حین آزمون به داده‌ی مشتریان یا اطلاعات هویتی رسید، باید از پیش مشخص باشد که چه مقدار از آن به‌عنوان شاهد نگه داشته می‌شود (پاسخ درست: حداقل ممکن، و ترجیحاً فقط نمونه‌ی پوشانده‌شده) و چطور امحا می‌شود.

پنجره‌ی زمانی

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

داده، محرمانگی و امحا

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

مسئولیت، جبران خسارت و پیش‌شرط‌های کارفرما

هر آزمون واقعی احتمال کوچکی از اختلال ناخواسته دارد و قرارداد باید صادقانه به آن بپردازد، نه اینکه وانمود کند صفر است. دو تعهد متقابل معمول است: مجری متعهد می‌شود در چارچوب قواعد تعامل بماند و در صورت مشاهده‌ی نشانه‌ی اختلال بلافاصله متوقف کند و اطلاع دهد؛ کارفرما متعهد می‌شود پیش از شروع پشتیبان معتبر و آزمایش‌شده داشته باشد و مسیر بازگردانی را بداند. سقف مسئولیت، استثنائات و نحوه‌ی جبران، دقیقاً همان بخشی است که باید با مشاور حقوقی نوشته شود.

مالکیت یافته‌ها و عدم افشا

تفکیک متعارف این است: گزارش و یافته‌های اختصاصی متعلق به کارفرماست؛ روش‌ها، ابزارهای عمومی و دانش فنی مجری نزد او می‌ماند. اما دو نکته را صریح کنید. اول، تکلیف انتشار: مجری بدون اجازه‌ی کتبی نباید یافته‌ها را منتشر کند و اگر قرار است در آینده مطالعه‌ی موردی بی‌نام منتشر شود، شرایطش از همین‌جا توافق شود. دوم، تکلیف آسیب‌پذیری‌هایی که در محصول شخص ثالث پیدا می‌شود؛ مسیر درست در این حالت افشای مسئولانه به سازنده است و قرارداد باید اجازه‌ی آن را بدهد.

تست مجدد: بندی که پروژه را کامل می‌کند

بدون تست مجدد، خروجی پروژه فقط یک سند است. بند خوب سه چیز را مشخص می‌کند: مهلت کارفرما برای رفع، پنجره‌ی تست مجدد پس از آن، و اینکه تست مجدد فقط یافته‌های قبلی را می‌سنجد یا شامل بررسی رگرسیون هم می‌شود. توجه کنید که «رفع شد» با «تأیید شد» یکی نیست؛ خروجی تست مجدد باید برای هر یافته یکی از سه وضعیت رفع‌شده، رفع جزئی یا پذیرفته‌شده به‌عنوان ریسک را ثبت کند. ساختار گزارش نهایی را در گزارش تست نفوذ شرح داده‌ایم.

چارچوب قانونی: صریح و بدون ادعا

یک اصل در تقریباً همه‌ی نظام‌های حقوقی مشترک است و ما فقط همان را می‌گوییم: آنچه آزمون امنیتی مجاز را از دسترسی غیرمجاز جدا می‌کند، مهارت یا نیت نیست — مجوز مکتوب مالک دارایی است. به همین دلیل بند مجوز را یک تشریفات اداری نمی‌دانیم و بدون آن پروژه‌ای شروع نمی‌کنیم.

فراتر از این اصل، در این صفحه به مواد و شماره‌ی قوانین ارجاع نمی‌دهیم و نظر حقوقی نمی‌دهیم. این کار تخصص ما نیست و اطلاعات نادرست در این حوزه می‌تواند هزینه‌ی واقعی داشته باشد. متن نهایی قرارداد — به‌ویژه بندهای مسئولیت، جبران خسارت، داده‌ی شخصی و حل اختلاف — باید توسط مشاور حقوقی سازمان شما بازبینی و تأیید شود. اگر سازمان شما در حوزه‌ی تحت مقررات فعالیت می‌کند، الزامات آن مقررات هم باید در همان بازبینی لحاظ شود.

در انتخاب طرف قرارداد هم چند سیگنال عملی وجود دارد: آیا پیش از امضا نمونه‌ی گزارش نشان می‌دهد؟ آیا متدولوژی را با نام و نسخه ذکر می‌کند یا فقط «استانداردهای جهانی» می‌گوید؟ آیا تست مجدد را در قرارداد آورده یا آن را خدمات جداگانه می‌فروشد؟ و آیا ادعاهای بی‌معنایی مثل «دارای گواهی OWASP» دارد — عنوانی که اصلاً وجود خارجی ندارد؟ معیارهای بیشتر را در انتخاب متخصص تست نفوذ آورده‌ایم و شرح خود خدمت در صفحه‌ی تست نفوذ وب است.