بیشتر چک‌لیست‌های امنیت سازمانی فارسی، فهرستی از عنوان‌های کلی‌اند که هیچ‌کس نمی‌داند چطور باید تیک بخورند. این چکلیست متفاوت ساخته شده: هر ردیف سه ستون دارد — کنترل، معیار پذیرش، و روش اثبات. کنترلی که راهی برای اثباتش وجود ندارد در عمل وجود ندارد. وزن این فهرست عمداً به سمت امنیت برنامه‌های وب سنگین است، چون در بیشتر سازمان‌ها سطح حمله‌ی واقعی و در معرض اینترنت همان‌جاست.
در یک نگاه
- هر کنترل باید سه چیز داشته باشد: مالک، معیار پذیرش و روش اثبات. بدون ستون سوم، چکلیست تبدیل به آرزو می‌شود.
- بدون موجودی دارایی، هیچ کنترلی قابل ارزیابی نیست. نقطه‌ی شروع همیشه فهرست سرویس‌های در معرض اینترنت است.
- بیشترین بازده در سازمانهای متوسط: مجوزدهی سمت سرور، MFA، مدیریت وابستگی و ثبت رخداد قابل هشدار.
- این فهرست، جایگزین آزمون مستقل نیست؛ ورودی آن است.
چطور از این چکلیست استفاده کنیم؟
سه قاعده پیش از شروع:
- همه‌چیز را هم‌زمان شروع نکنید. در یک چرخه‌ی سه‌ماهه، پنج تا هفت کنترل را کامل ببندید — بهتر از سی کنترل نیمه‌کاره.
- برای هر ردیف یک نام بنویسید. کنترل بدون مالک، کنترل بدون پیشرفت است.
- ستون «اثبات» را قبل از شروع پر کنید. اگر نمی‌توانید بنویسید چطور اثباتش می‌کنید، هنوز کنترل را دقیق تعریف نکرده‌اید.
این چکلیست، لایه‌ی سازمانی است. برای لایه‌ی فنی وب‌سایت، چکلیست امنیت سایت و برای پوشش آزمون، چکلیست تست نفوذ مکمل مستقیم آن‌اند و در ادامه به هر دو ارجاع می‌دهیم.
حاکمیت و موجودی دارایی
| کنترل | معیار پذیرش | روش اثبات |
|---|---|---|
| سیاست امنیت مکتوب | ابلاغ‌شده، دارای نسخه و تاریخ بازبینی | سند امضاشده + شواهد بازبینی سالانه |
| مالک ریسک برای هر سامانه | یک نام مشخص، نه یک واحد | جدول سامانه‌ها با ستون مالک |
| موجودی سرویس‌های در معرض اینترنت | شامل زیردامنه‌ها، APIها و محیط‌های آزمایشی | خروجی کشف دارایی + مقایسه با فهرست رسمی |
| طبقه‌بندی داده | حداقل سه سطح با مثال مشخص | نگاشت هر پایگاه‌داده به یک سطح |
| مدیریت ریسک تأمین‌کننده | ارزیابی امنیتی پیمانکاران دارای دسترسی | پرسش‌نامه + بند امنیتی در قرارداد |
| آستانه‌ی پذیرش ریسک | مشخص‌بودن این‌که چه سطحی نیاز به تصمیم مدیریتی دارد | مصوبه‌ی مکتوب کمیته |
ردیف سوم پرارزش‌ترین ردیف این جدول است. در تقریباً هر ارزیابی، فهرست واقعی دارایی‌های در معرض اینترنت از فهرست رسمی سازمان بلندتر است — و آسیب‌پذیرترین مورد معمولاً همان سرویسی است که در فهرست نبود. چارچوب چرخه‌ای این کار در مدیریت آسیبپذیری توضیح داده شده.
امنیت برنامه‌های وب — سنگین‌ترین بخش فهرست
این بخش عمداً مفصل‌تر است. در داده‌ی OWASP برای Top 10:2025، دسته‌ی A01:2025 با عنوان کنترل دسترسی شکسته در ۱۰۰٪ برنامه‌های آزمودهشده به‌شکلی دیده شده است — و همین دسته چیزی است که هیچ ابزار محیطی جلوی آن را نمی‌گیرد.
| کنترل | معیار پذیرش | روش اثبات |
|---|---|---|
| مجوزدهی سمت سرور | هر درخواست، مالکیت رکورد را در لایه‌ی داده بررسی کند | آزمون ماتریس نقش‌ها؛ بازپخش درخواست با حساب دیگر |
| پرهیز از کنترل صرفاً سمت کاربر | پنهان‌کردن منو، کنترل شمرده نشود | فراخوانی مستقیم نقطه‌ی انتهایی بدون رابط کاربری |
| کوئری پارامتری | هیچ الحاق رشته‌ای در ساخت کوئری | بازبینی کد + قاعده‌ی SAST؛ تزریق SQL |
| کدگذاری خروجی بر اساس زمینه | خروجی HTML، صفت و JS جداگانه کدگذاری شود | آزمون XSS در همهی نقاط ورود |
| مدیریت وابستگی و SBOM | موجودی به‌روز + رصد CVE | خروجی ابزار موجودی + گزارش وصله (A03:2025) |
| راستی‌آزمایی امضای بسته‌ها | دریافت فقط از منبع رسمی با بررسی امضا | پیکربندی مخزن داخلی + لاگ ساخت |
| مدیریت نشست امن | شناسه‌ی تصادفی، ابطال سمت سرور، کوکی امن | بررسی صفات کوکی؛ آزمون خروج و انقضا |
| محافظت CSRF | توکن سمت سرور برای هر عمل تغییردهنده | حذف توکن و مشاهده‌ی رد شدن درخواست |
| پیکربندی امن | بدون فهرست‌کردن دایرکتوری، بدون خطای پرجزئیات | اسکن پیکربندی؛ A02:2025 |
| بازبینی طراحی ویژگی‌های حساس | مدل‌سازی تهدید پیش از پیاده‌سازی | مستند بازبینی در هر انتشار |
«WAF داریم، پس OWASP Top 10 پوشش داده شده است.» فایروال برنامه‌ی وب ساختاراً نسبت به کنترل دسترسی شکسته (A01:2025)، نقص منطق کسبوکار، شرایط رقابتی و بیشتر موارد XSS مبتنی بر DOM نابینا است — در مورد آخر، بخش تکه‌ی آدرس اصلاً به سرور نمی‌رسد. WAF یک لایه‌ی کاهش ریسک برای خرید زمان است؛ هرگز نباید در ستون «راهکار» یک نقص کد نوشته شود. شرح دقیق مرزهای آن در WAF آمده است.
هویت، دسترسی و زیرساخت
| کنترل | معیار پذیرش | روش اثبات |
|---|---|---|
| احراز هویت چندعاملی | برای همهی دسترسیهای اداری و از راه دور | گزارش پوشش MFA از سامانه‌ی هویت |
| حذف اعتبارنامهی پیشفرض | هیچ سرویسی با گذرواژه‌ی کارخانه در تولید نباشد | اسکن اعتبارنامهی پیشفرض |
| اعتبارنامهی سختکدشده | هیچ کلید یا گذرواژه‌ای در مخزن کد | اسکن مخزن + بررسی تاریخچه‌ی گیت |
| حداقل دسترسی | بازبینی دوره‌ای دسترسی‌ها و حذف حساب‌های بی‌استفاده | گزارش بازبینی دسترسی |
| جداسازی محیط‌ها | تولید، آزمایش و توسعه اعتبارنامه و شبکه‌ی مشترک نداشته باشند | نمودار شبکه + بررسی متغیرهای محیطی |
| رمزنگاری انتقال | TLS با نسخه و مجموعه‌رمزهای به‌روز، همراه HSTS | اسکن پیکربندی TLS |
| هش گذرواژه | الگوریتم مناسب و نمک‌دار، مانند Argon2 | بازبینی کد و اسکیمای پایگاه‌داده |
| مدیریت کلید | کلیدها در سرویس مدیریت کلید، نه در فایل پیکربندی | بررسی محل نگه‌داری و چرخش کلید |
ردیف اول و سوم بیشترین اثر را با کمترین هزینه دارند. دسته‌ی A07:2025 در OWASP دقیقاً همین حوزه است و توصیه‌ی صریحش، پیاده‌سازی MFA، پرهیز از اعتبارنامهی پیشفرض و همسویی سیاست گذرواژه با NIST SP 800-63B است — نه اجبار به تعویض دوره‌ای گذرواژه که در عمل به بازاستفاده منجر می‌شود.
ثبت رخداد، پشتیبان و پاسخ
| کنترل | معیار پذیرش | روش اثبات |
|---|---|---|
| ثبت رخدادهای امنیتی | ورود، تغییر دسترسی، عملیات حساس، شکست مجوزدهی | نمونه‌گیری از لاگ در سناریوی واقعی |
| هشدار قابل اقدام | هر هشدار یک راهنمای اجرایی متناظر داشته باشد | تمرین: آیا حمله‌ی تیم آزمون هشدار تولید کرد؟ |
| کدگذاری خروجی لاگ | جلوگیری از تزریق به لاگ (CWE-117) | بازبینی کد نویسنده‌ی لاگ |
| عدم ثبت داده‌ی حساس | توکن، گذرواژه و شماره‌ی کارت در لاگ نباشد | جست‌وجوی الگو در لاگ‌های موجود |
| مسیر ممیزی فقط‌افزودنی | حفاظت یکپارچگی لاگ‌های حساس | بررسی مجوزهای نوشتن |
| پشتیبان آزمودهشده | بازیابی واقعی در بازه‌ی هدف انجام شده باشد | گزارش تمرین بازیابی، نه صرفاً وجود نسخه |
| راهنمای پاسخ به رخداد | نقش‌ها، مسیر ارتباط و گام‌های مهار مشخص | تمرین رومیزی سالانه |
ردیف دوم بیشترین شکاف را نشان می‌دهد. دسته‌ی A09:2025 — نقص در ثبت رخداد و هشداردهی — دقیقاً برای همین وجود دارد و OWASP نمونه‌ای واقعی نقل میکند: رخنه‌ای در یک ارائه‌دهنده‌ی طرح سلامت کودکان که ۳٫۵ میلیون کودک را تحت تأثیر قرار داد و از سال ۲۰۱۳ کشف نشده بود، چون نه ثبت رخداد کافی وجود داشت و نه پایش. کشف نهایی هم از بیرون سازمان اطلاع داده شد. اگر می‌خواهید بدانید نشانه‌های عملی چنین وضعیتی چیست، نشانه‌های هک شدن سایت فهرست ملموسی می‌دهد.
اولویت‌بندی: با کدام ردیف شروع کنیم؟
اگر منابع محدود است و باید انتخاب کنید، این ترتیب در سازمانهای متوسط بیشترین کاهش ریسک را به‌ازای هزینه داده است:
- موجودی دارایی‌های در معرض اینترنت. ارزان، سریع، و پیش‌نیاز هر کار دیگری.
- MFA روی دسترسیهای اداری و از راه دور. بیشترین اثر بازدارنده به‌ازای کمترین هزینه.
- مجوزدهی سمت سرور در سامانه‌های اصلی. کاری کد-محور، اما ریشه‌ی پرخطرترین دسته‌ی یافته‌ها.
- مدیریت وابستگی و راستی‌آزمایی منبع. مستقیماً به
A03:2025پاسخ می‌دهد. - ثبت رخداد و هشدار برای مسیرهای حساس.
- ارزیابی مستقل. برای برنامه‌های وب، تست نفوذ وب سازوکار اثبات ردیف‌های بالا است.
یک هشدار پایانی: چکلیست، ورودی ارزیابی است نه جایگزین آن. سازمانی که هر سی ردیف را تیک زده باشد هم ممکن است یک نقص منطق کسبوکار داشته باشد که هیچ ردیفی آن را پوشش نمی‌دهد — و دقیقاً برای همین، ارزیابی امنیتی مستقل جای خود را دارد.
پرسش‌های متداول
چکلیست امنیت سازمانی را از کجا شروع کنیم؟
از موجودی دارایی. تا ندانید چه سرویسهایی در معرض اینترنت دارید، چه دادهای در آنها هست و مالک هرکدام کیست، هیچ کنترل دیگری قابل ارزیابی نیست. این مرحله معمولاً ارزانترین و پربازدهترین گام است.
چکلیست امنیت سازمانی با چکلیست تست نفوذ چه فرقی دارد؟
چکلیست سازمانی، فهرست کنترلهایی است که سازمان باید داشته باشد؛ چکلیست تست نفوذ، فهرست آزمونهایی است که ارزیاب باید انجام دهد. اولی نگاه مدیریتی و دومی نگاه فنی است و هر دو لازماند.
آیا تیکخوردن همهی ردیفها یعنی امن هستیم؟
نه. چکلیست وجود کنترلهای شناختهشده را تضمین میکند، نه نبود آسیبپذیری. نقصهای منطق کسبوکار، ترکیب چند یافتهی کمخطر و خطاهای طراحی معمولاً در هیچ چکلیستی نمیگنجند و فقط با آزمون دستی پیدا میشوند.
برای یک سازمان کوچک، کدام ردیفها واقعاً ضروریاند؟
موجودی دارایی، MFA روی دسترسیهای اداری، حذف اعتبارنامهی پیشفرض و سختکدشده، مجوزدهی سمت سرور، بهروزنگهداشتن وابستگیها و پشتیبان آزمودهشده. این شش مورد بخش عمدهی رخدادهای واقعی سازمانهای کوچک را پوشش میدهند.
هر چند وقت یک‌بار باید این چکلیست را بازبینی کرد؟
بازبینی سبک فصلی برای وضعیت پیشرفت و بازبینی کامل سالانه یا پس از هر تغییر مهم معماری. آنچه بیشتر اهمیت دارد این است که هر تغییر معماری — سرویس جدید، ادغام تازه، مهاجرت به ابر — موجودی دارایی را به‌روز کند.
منابع
امیر پیامنی
شکارچی ضعف‌های زیرساخت؛ از نقشه‌برداری سطح حمله تا بهره‌برداری از سرویس‌های شبکه و حرکت جانبی داخل دامنه.