گزارش امنیتی سایت؛ چه چیزهایی باید مستند و تحویل داده شود؟

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

صفحه مشخصات گزارش: دامنه، تاریخ، نسخه و معیارها

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

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

نام پروژه/دامنه‌ها و زیردامنه‌های پوشش داده شده (مثلاً www و پنل‌ها)
محیط‌ها: Production / Staging و اینکه کدام بررسی شده است
تاریخ تهیه گزارش، نسخه گزارش، نام تهیه کننده/تیم مسئول
دامنه بررسی: اپلیکیشن، سرور، CDN، ایمیل، پنل‌های ادمین، درگاه پرداخت و…
سطح بررسی: بررسی پیکربندی و مستندسازی (نه الزاماً Penetration Test)

اگر پروژه شما از ابتدا با نگاه ساختاری و استاندارد پیش برود، تعریف دامنه و تحویل مستندات بخشی از «مهندسی تحویل» است؛ نه یک فایل اضافی در پایان کار.

وضعیت دسترسی‌ها و نقش‌ها: چه کسی به چه چیزی دسترسی دارد؟

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

اقلام پیشنهادی برای مستندسازی دسترسی‌ها

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

نکته کلیدی این است که «مالکیت» باید قابل انتقال باشد؛ یعنی اگر پیمانکار تغییر کرد، پروژه گروگان دسترسی‌ها نشود. برای سایت‌های شخصی هم همین مسئله حیاتی است، چون معمولاً همه چیز به یک نفر متکی است و با گم شدن دسترسی‌ها، هزینه بازیابی بالا می‌رود. در پروژه‌های طراحی وب‌سایت شخصی پیشنهاد می‌شود از ابتدا یک مدل ساده اما شفاف برای مالکیت و دسترسی تعریف شود.

تنظیمات سرور و SSL/TLS: امنیت زیرساخت چگونه قابل سنجش می‌شود؟

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

در این بخش معمولاً موارد زیر مستند می‌شوند:

نوع میزبانی و معماری کلی (Shared/VPS/Dedicated، استفاده از CDN یا WAF)
نسخه‌های کلیدی: سیستم عامل، وب سرور (Nginx/Apache)، PHP/Node، دیتابیس
پورت‌های باز و سرویس‌های فعال (به صورت خلاصه و غیرحساس)
وضعیت SSL/TLS: صادرکننده گواهی، تاریخ انقضا، روش تمدید، ریدایرکت HTTP به HTTPS
هدرهای امنیتی مهم در صورت استفاده (مثل HSTS، X-Content-Type-Options، CSP به شکل سطح بالا)

برای شفافیت بیشتر، می‌توانید یک جدول «چک لیست زیرساخت در زمان تحویل» داشته باشید:

آیتم	وضعیت در زمان تحویل	توضیح/مسئول نگهداری
HTTPS و ریدایرکت	فعال	مسئول تمدید گواهی و زمان‌بندی
نسخه PHP/Runtime	ثبت شده	سیاست ارتقا و سازگاری افزونه‌ها/کد
CDN/WAF	در صورت وجود ثبت شود	مالک اکانت و تنظیمات سطح بالا

سیاست بکاپ و بازیابی: فقط بکاپ داشتن کافی نیست

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

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

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

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

لاگ‌ها و مانیتورینگ: بعد از تحویل چگونه اتفاقات قابل ردیابی می‌شوند؟

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

حداقل موارد پیشنهادی برای این بخش:

نوع لاگ‌ها: وب سرور، اپلیکیشن، لاگ ورود/خروج پنل، لاگ خطاهای سیستم
محل ذخیره و دسترسی‌ها (چه کسی می‌تواند ببیند/دانلود کند)
Retention لاگ‌ها (مثلاً ۱۴ روز، ۳۰ روز، ۹۰ روز)
مانیتورینگ آپتایم و هشدارها (کانال اطلاع رسانی، مسئول پاسخ)
نقطه تماس incident: چه کسی در رخداد امنیتی تصمیم گیر است

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

افزونه‌ها و وابستگی‌ها: موجودی نرم‌افزار (SBOM) در مقیاس عملی

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

چه چیزهایی را در موجودی وابستگی‌ها ثبت کنیم؟

CMS و نسخه (مثلاً WordPress و نسخه)
فهرست افزونه‌ها/تم‌ها: نام، نسخه، منبع (رسمی/سفارشی)، وضعیت فعال/غیرفعال
وابستگی‌های سمت سرور/کلاینت در صورت سفارشی بودن پروژه
سرویس‌های ثالث: نقشه، پیامک، درگاه پرداخت، فرم سازها، چت آنلاین

برای تیم‌های غیر فنی، یک جدول خلاصه کمک می‌کند:

گروه	آیتم	ریسک عملیاتی	سیاست مدیریت
افزونه	نام/نسخه ثبت شده	آسیب پذیری‌های احتمالی	به روزرسانی دوره‌ای + حذف موارد بلااستفاده
سرویس ثالث	درگاه/پیامک/چت	وابستگی به ارائه دهنده	ثبت مالکیت اکانت و کلیدها، محدودسازی دسترسی

سیاست به روزرسانی و ریسک‌های باقی مانده: امنیت یعنی مدیریت ریسک، نه حذف کامل آن

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

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

ریسک: عدم فعال سازی 2FA برای همه ادمین‌ها
اثر: افزایش احتمال دسترسی غیرمجاز در صورت نشت رمز
راه حل: الزام 2FA و آموزش تیم
وضعیت: پیشنهادی/در انتظار تصمیم کارفرما
ریسک: وابستگی به یک افزونه کلیدی با سابقه آپدیت نامنظم
اثر: احتمال آسیب پذیری آینده
راه حل: جایگزین معتبر یا توسعه سفارشی
وضعیت: پذیرفته شده/زمان بندی شده

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

جمع بندی: گزارش امنیتی سایت، سند تحویل است نه ضمیمه اختیاری

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

فهرست Deliverableهای امنیتی در زمان تحویل پروژه

در زمان تحویل، این موارد را به عنوان خروجی‌های مستند و قابل ارائه درخواست کنید (ترجیحاً به صورت PDF + فایل‌های ضمیمه در یک پوشه تحویل):

شناسنامه گزارش: دامنه/محیط، تاریخ، نسخه، دامنه بررسی، مسئول تهیه
نقشه مالکیت اکانت‌ها: دامنه، هاست/سرور، CDN/WAF (در صورت وجود)، ایمیل، سرویس‌های ثالث
فهرست نقش‌ها و کاربران پنل مدیریتی (بدون رمز) + سیاست مدیریت دسترسی
سیاست رمز عبور و وضعیت ورود دومرحله‌ای (در صورت استفاده)
خلاصه پیکربندی زیرساخت: نوع میزبانی، وب سرور، نسخه‌های کلیدی، سرویس‌های فعال (سطح بالا)
گزارش SSL/TLS: صادرکننده، تاریخ انقضا، روش تمدید، ریدایرکت HTTP→HTTPS
چک لیست هدرهای امنیتی/تنظیمات محافظتی (سطح بالا و قابل فهم)
سیاست بکاپ: دامنه بکاپ، تناوب، retention، محل نگهداری، دسترسی‌ها، رمزنگاری (در صورت استفاده)
راهنمای بازیابی (Restore Runbook): مراحل، پیش نیازها، زمان تقریبی، مسئول
ثبت آخرین تست بازیابی (اگر انجام شده): تاریخ، نتیجه، مشکلات و اصلاحات
سیاست لاگ: چه لاگ‌هایی فعال است، کجا ذخیره می‌شود، retention، سطح دسترسی
مانیتورینگ و هشدارها: ابزار/روش، کانال هشدار، مسئول پاسخ و escalation
فهرست افزونه‌ها/تم‌ها/وابستگی‌ها با نسخه‌ها (موجودی نرم افزار/SBOM در مقیاس عملی)
سیاست به روزرسانی: بازه بررسی، مسئول، نحوه تست روی staging، رویه rollback
لیست ریسک‌های باقی مانده + وضعیت تصمیم (پذیرفته شده/در حال اقدام/خارج از دامنه)
ثبت تغییرات کلیدی امنیتی انجام شده در پروژه (Changelog سطح بالا)