«افتا» در ادبیات سازمانی ایران به مجموعه‌ی الزامات امنیت فضای تولید و تبادل اطلاعات اشاره میکند و معمولاً وقتی مطرح میشود که یک سازمان دولتی یا زیرساختی از پیمانکار خود گزارش ارزیابی امنیتی می‌خواهد. این مقاله شکل کلی ماجرا را توضیح می‌دهد و بیشتر روی چیزی تمرکز میکند که در اختیار شماست: اینکه یک گزارش ارزیابی امنیتی چه ساختاری داشته باشد تا واقعاً قابل استناد و قابل پیگیری باشد. برای الزامات دقیق و جاری، مرجع تنها و معتبر، خودِ نهاد متولی است.
در یک نگاه
- این صفحه مرجع حقوقی نیست. هیچ بند، سند، بازهی زمانی یا مهلت مشخصی در آن ذکر نشده و نباید بشود؛ الزامات جاری را باید از نهاد متولی گرفت.
- شکل کلی رایج: سازمانهای بخش دولتی و زیرساختهای حیاتی مشمول الزامات امنیتی مرجع مربوطه‌اند و معمولاً گزارش ارزیابی و شواهد رفع از آنها خواسته میشود.
- آنچه یک گزارش را قابل استناد میکند: دامنهی صریح، متدولوژی نامبرده، گامهای بازتولید، امتیازدهی شفاف و آزمون مجدد.
- خروجی اسکنر خودکار، گزارش ارزیابی نیست. تفاوت در راستیآزمایی دستی یافتهها و حذف مثبت‌های کاذب است.
افتا در یک نگاه — و مرز آنچه اینجا می‌گوییم
در بسیاری از کشورها، سازمانهای بخش دولتی و متولیان زیرساختهای حیاتی مشمول الزامات امنیتی یک نهاد مرجعاند. ایران هم از این قاعده مستثنا نیست و اصطلاح رایج برای این حوزه «افتا» است. شکل کلی این الزامات در تجربهی عملی معمولاً چند مؤلفه‌ی مشترک دارد:
- تعیین یک ساختار مسئول امنیت در سازمان و مشخص‌بودن مالک ریسک؛
- ارزیابی دوره‌ای وضعیت امنیتی سامانه‌ها، به‌ویژه سامانه‌های در معرض اینترنت؛
- ارائه‌ی گزارش ارزیابی و سپس شواهد رفع یافتهها؛
- الزاماتی درباره‌ی صلاحیت ارزیاب و محرمانگی داده‌های ارزیابی.
هرآنچه در این صفحه آمده، توصیف شکل کلی است، نه نقل الزام. جزئیات — از جمله اینکه چه سازمانهایی مشمول‌اند، چه سندی مبنا است، هر چند وقت یک‌بار ارزیابی لازم است و ارزیاب باید چه صلاحیتی داشته باشد — باید مستقیماً از نهاد متولی راستیآزمایی شود. این الزامات به‌مرور تغییر میکنند و هیچ مقاله‌ای، از جمله همین صفحه، جای مرجع رسمی را نمی‌گیرد.
آنچه از این صفحه به‌درستی می‌توانید بردارید، بخش فنی ماجرا است: صرف‌نظر از اینکه کدام نهاد گزارش را می‌خواهد، یک گزارش ارزیابی خوب ویژگی‌های مشخصی دارد که در ادامه می‌آید.
چرا کیفیت گزارش، تعیین‌کننده است
در عمل، بیشتر اصطکاک‌های میان سازمان و ارزیاب سر «کیفیت گزارش» رخ می‌دهد، نه سر خودِ آزمون. سه الگوی تکراری:
گزارشی که قابل بازتولید نیست
یافته‌ای که فقط عنوان و توضیح عمومی دارد، در تیم توسعه به بحث تبدیل میشود، نه به تیکت. هر یافته باید درخواست دقیق، پاسخ مشاهده‌شده و گامهای بازتولید داشته باشد.
گزارشی که اولویت ندارد
فهرست ۱۲۰ موردی که همه «مهم» علامت خورده‌اند، عملاً بی‌اولویت است. امتیازدهی باید شفاف باشد: CVSS نسخه‌ی v4.0 یا v3.1 — و مهم‌تر از انتخاب نسخه، این است که در گزارش نوشته شود کدام نسخه استفاده شده.
گزارشی که پایان کار تلقی میشود
گزارش، نقطهی شروع رفع است. بدون آزمون مجدد پس از اصلاح، هیچ شاهدی وجود ندارد که مشکل واقعاً حل شده باشد. در چارچوبهای بینالمللی این نکته صریح است؛ برای نمونه PCI DSS v4.0.1 در بند ۱۱٫۴٫۴ تکرار آزمون برای راستیآزمایی اصلاحات را الزامی میکند.
ساختار متعارف و بخش‌های لازم یک گزارش حرفهای در گزارش تست نفوذ با جزئیات بیشتری آمده است.
یک گزارش ارزیابی قابل استناد چه دارد؟
| بخش | چه چیزی باید در آن باشد | چرا لازم است |
|---|---|---|
| دامنه | فهرست دقیق دامنه‌ها، زیردامنه‌ها، APIها، نقش‌های کاربری آزموده‌شده و آنچه صریحاً خارج از دامنه بوده | بدون آن، هیچ‌کس نمی‌داند گزارش چه چیزی را نگفته است |
| متدولوژی | مرجع پوشش فنی (راهنمای آزمون OWASP) و مرجع فرایند (SP 800-115 یا فازهای PTES) | قابلیت ممیزی و مقایسه با ارزیابی‌های بعدی |
| خلاصه‌ی مدیریتی | وضعیت کلی، چند یافته‌ی تعیین‌کننده، و تصمیم‌هایی که مدیریت باید بگیرد — بدون اصطلاح فنی | مخاطب این بخش، تصمیم‌گیر است نه توسعه‌دهنده |
| یافتهها | شرح، اثر، گامهای بازتولید، شواهد غیرتخریبی، امتیاز و نگاشت به OWASP Top 10:2025 و CWE | ترجمه‌ی یافته به کار قابل انجام |
| اقدام اصلاحی | راهکار مشخص در سطح کد یا پیکربندی، مرتب‌شده بر اساس اثربخشی | «WAF بگذارید» راهکار یک نقص کد نیست |
| آزمون مجدد | وضعیت هر یافته پس از اصلاح: رفع‌شده، جزئی، رفع‌نشده | تنها شاهد قابل ارائه‌ی «رفع» |
| محرمانگی | نحوه‌ی نگه‌داری و امحای داده‌های حساس کشف‌شده در جریان آزمون | در ارزیابی سازمانهای حساس، بند تعیین‌کننده است |
ستون سوم را جدی بگیرید. گزارشی که این هفت بخش را دارد، صرف‌نظر از اینکه کدام نهاد آن را می‌خواند، قابل دفاع است. چارچوب قراردادی این تعهدها هم در قرارداد تست نفوذ تعیین میشود.
مسیر عملی: از ارزیابی تا شواهد رفع
ترتیبی که در سازمانهای ایرانی کمترین دوباره‌کاری را ایجاد میکند:
- موجودی دارایی. پیش از هر آزمونی، فهرست واقعی سرویس‌های در معرض اینترنت را بسازید. تقریباً همیشه از فهرست رسمی سازمان بلندتر است.
- تعیین دامنه و قواعد تعامل. پنجره‌ی زمانی، محیط هدف (ترجیحاً محیطی هم‌ارز تولید)، حساب‌های آزمون برای هر نقش، و مسیر تماس اضطراری. جزئیات در دامنهی تست نفوذ.
- اجرای ارزیابی. پوشش فنی بر مبنای راهنمای آزمون OWASP و راستیآزمایی دستی هر یافته. فرایند تست نفوذ این مرحله را گام‌به‌گام توضیح می‌دهد.
- گزارش و اولویت‌بندی. اولویت بر پایه‌ی ترکیب شدت فنی و ارزش دارایی، نه فقط امتیاز عددی.
- رفع. در سطح ریشه‌ای. اگر یک الگوی نادرست در چند سرویس تکرار شده، رفع موردی یعنی بازگشت همان یافته در ارزیابی بعدی.
- آزمون مجدد و مستندسازی. خروجی این مرحله همان «شاهد رفع» است که معمولاً درخواست میشود.
برای سازمانهایی که چند سامانه دارند، این چرخه باید تبدیل به فرایند مستمر شود، نه پروژه‌ی یک‌باره؛ چارچوب آن در مدیریت آسیبپذیری آمده است.
اشتباهات رایج در تدارک ارزیابی
«خروجی اسکنر خودکار را تحویل می‌دهیم، همان گزارش ارزیابی است.» اسکنر یک نقطهی شروع است، نه محصول نهایی. ابزارهای خودکار ذاتاً مثبت کاذب تولید میکنند و — مهم‌تر — نسبت به دسته‌هایی که بیشترین اثر را دارند تقریباً نابینا هستند: کنترل دسترسی شکسته، نقص منطق کسبوکار، IDOR و شرایط رقابتی. گزارشی که هر یافته‌اش دستی راستیآزمایی نشده باشد، در نخستین بازبینی فنی زیر سؤال می‌رود.
سه اشتباه دیگر که تکرار می‌شوند:
- ارزیابی روی محیطی که با تولید یکی نیست. اگر پیکربندی، داده و نسخه‌ها متفاوت باشند، نتیجه قابل تعمیم نیست. اگر آزمون روی محیط تولید ممکن نیست، دست‌کم یک محیط هم‌ارز لازم است.
- ندادن حساب کاربری برای هر نقش. بخش بزرگی از یافته‌های پرارزش — ارتقای سطح دسترسی افقی و عمودی — بدون حساب‌های چندنقشی اصلاً قابل کشف نیست.
- نگاه‌کردن به ارزیابی به‌عنوان تشریفات. هدف، تولید کاغذ نیست؛ کاهش ریسک واقعی است. اگر ریشه‌ی یافتهها در الگوی کدنویسی است، آموزش سازمانی توسعه‌ی امن اثر پایدارتری از هر دور ارزیابی دارد.
اگر مطمئن نیستید سازمان شما به کدام سطح از ارزیابی نیاز دارد و از کجا باید شروع کند، مشاوره‌ی اولیه نقطهی شروع کم‌هزینه‌تری از سفارش مستقیم یک پروژه‌ی بزرگ است. جزئیات خدمت اصلی هم در تست نفوذ وب آمده است.
پرسش‌های متداول
افتا برای چه سازمانهایی الزامی است؟
شکل کلی رایج این است که سازمانهای بخش دولتی و متولیان زیرساختهای حیاتی مشمول الزامات امنیتی نهاد مرجعاند. اما تعیین دقیق مشمولیت، سند مبنا و جزئیات آن فقط از خود نهاد متولی قابل استعلام است و در این صفحه هیچ ادعای مشخصی در این باره مطرح نشده است.
برای ارزیابی امنیتی چه مدارکی معمولاً خواسته میشود؟
در تجربهی متعارف، گزارش ارزیابی امنیتی و پس از آن شواهد رفع یافتهها. برای اینکه این دو قابل استناد باشند، گزارش باید دامنهی صریح، متدولوژی نامبرده، گامهای بازتولید هر یافته، امتیازدهی شفاف و نتیجهی آزمون مجدد داشته باشد. فهرست دقیق مدارک را از نهاد درخواستکننده بگیرید.
تفاوت اسکن آسیبپذیری با تست نفوذ در این زمینه چیست؟
اسکن، تطبیق خودکار امضا با پاسخ سرور است و برای یافتن نسخههای آسیبپذیر و پیکربندیهای شناختهشده خوب کار میکند. تست نفوذ شامل راستیآزمایی دستی، زنجیرهکردن یافتهها و آزمون منطق کسبوکار است — همان جایی که پرخطرترین یافتهها زندگی میکنند و اسکنر آنها را نمیبیند.
گزارش ارزیابی چقدر اعتبار دارد؟
هر گزارش، عکسی از یک نقطهی زمانی مشخص از یک دامنهی مشخص است. با هر تغییر مهم در برنامه یا زیرساخت، اعتبار آن کاهش مییابد. بازهی اعتبار مورد پذیرش را باید از نهاد درخواستکننده پرسید؛ در چارچوبهای بینالمللی مانند PCI DSS بازهی ۱۲ ماهه بهعلاوهی آزمون پس از هر تغییر مهم متعارف است.
آیا آزمون مجدد پس از رفع، هزینهی جداگانه دارد؟
بستگی به قرارداد دارد و باید از ابتدا روشن شود. رویهی حرفهای این است که یک دور آزمون مجدد در بازهی زمانی مشخص پس از تحویل گزارش، بخشی از خود پروژه باشد. این نکته را پیش از شروع در قرارداد مکتوب کنید تا در مرحلهی تحویل شواهد رفع، به مذاکرهی تازه تبدیل نشود.
منابع
مهدی مرادلو
محقق امنیتی با تمرکز روی منطق کسبوکار و زنجیره‌های حمله‌ی پیچیده. اسکوپ‌بندی پروژه‌ها و تضمین کیفیت گزارش‌ها با اوست.