نیازمندی امنیت باید سیستم و خطر آن را تشریح کند
عبارت «نرمافزار باید امن باشد» قابل طراحی، قیمتگذاری یا پذیرش عینی نیست. هدف تجارتی، نوع معلومات، کاربران، فعالیت ممتاز، موقعیت، ادغام، دسترسی انترنتی، وابستگی خدمت، uptime و انتظار بازیابی را مشخص کنید.
هیچ چکلیست یا تست ثابت نمیکند نرمافزار هیچ آسیبپذیری ندارد. هدف، تعیین روش متناسب، ارزیابی کنترول توافقشده، رسیدگی یافته و عملیات مسئولانه است.
۱. مسئولیت امنیت و معلومات را تعیین کنید
- مالک تجارتی و معلومات
- مرجع تأیید دسترسی و ادمین ممتاز
- مسئول توسعه، review و release
- مالک میزبانی، patch، monitoring و بکاپ
- تماس incident، ارتباط و escalation
- مالک خدمت بیرونی و ادغام
ارائهکننده cloud، عرضهکننده نرمافزار و مشتری میتواند لایههای متفاوت را کنترول کند؛ قرارداد باید مرز را واضح سازد.
۲. هویت، دسترسی و فعالیت حساس را تعریف کنید
هویت کاربر، authentication، بازیابی حساب، نقش، صلاحیت، حد تأیید، تفکیک وظیفه، session و دسترسی ممتاز را مشخص کنید. فعالیت پرخطر میتواند مطابق خطر به احراز دوباره، کنترول دوگانه، اطلاع یا log اضافی نیاز داشته باشد.
۳. حفاظت و چرخه عمر معلومات را مستند کنید
استفاده مجاز، طبقهبندی، محل ذخیره، انتقال، export، نگهداری، حذف، بکاپ و خروج را ثبت کنید. محل encryption و مسئول key یا credential را تعیین کنید. encryption بهتنهایی صلاحیت زیاد یا export ناامن را حل نمیکند.
۴. روش امن توسعه و release بخواهید
- source repository کنترولشده و contributor مجاز
- review تغییر مهم code، config و infrastructure
- جدایی محیط توسعه، تست و اصلی
- مدیریت secret، dependency و build artifact
- تست امنیت متناسب با سیستم و خطر
- release، منظوری، rollback و رسیدگی defect ثبتشده
گزارش scanner یک شواهد است؛ اثبات آزمایش تمام خطرهای منطق تجارتی، دسترسی و عملیات نیست.
۵. ارزیابی و پذیرش را تعیین کنید
نیازمندی را به نتیجه قابل تست برای authentication، authorization، validation، session، معامله حساس، فایل، API، log، config، بکاپ و restoration تبدیل کنید. عمق تست، محیط، معلومات تست، شدت یافته، اصلاح، retest و مرجع پذیرش را مشخص سازید.
۶. میزبانی، بازیابی و تداوم را یکجا طراحی کنید
cloud، private hosting، on-premise یا hybrid را بر حساسیت، اتصال، ظرفیت داخلی، امنیت فزیکی، patch، monitoring، بکاپ، recovery، رشد و هزینه مقایسه کنید. بکاپ باید محدوده، تکرار، نگهداری، حفاظت، مالک و تست restoration داشته باشد.
۷. log، monitoring و incident را آماده کنید
رویداد مهم، دسترسی log، هماهنگی زمان، نگهداری، مالک alert و escalation را تعیین کنید. پلان incident باید triage، مهار، شواهد، restoration، ارتباط، اطلاع لازم، بررسی علت و اقدام بعدی را پوشش دهد.
زمان پاسخ تنها وقتی تعهد است که ساعت خدمت، شدت، وابستگی و روش سنجش در SLA تأییدشده باشد.
۸. ادغام و dependency را بررسی کنید
برای هر API، identity provider، payment service، دستگاه یا پلتفرم بیرونی، authentication، معلومات مجاز، validation، حجم، خطا، retry، reconciliation، monitoring، تغییر نسخه و مالک پشتیبانی را ثبت کنید.
۹. نگهداری، تغییر و خروج را پلان کنید
امنیت پس از نشر ادامه دارد. نسخه قابل پشتیبانی، patch، dependency، گزارش vulnerability، تأیید تغییر، regression، بررسی دسترسی، تست restoration و گزارش خدمت را تعیین کنید. خروج باید export، حذف، credential، domain، infrastructure، source یا licence، اسناد و یافته باز را پوشش دهد.
شواهد قابل درخواست
- ماتریس مسئولیت و نمای معماری یا data flow
- قابلیت پیگیری نیازمندی و verification
- ثبت release و change control
- مدل دسترسی و نقش ممتاز
- شواهد بکاپ و تست restoration
- فهرست یافته با مالک و treatment
- روش incident و escalation پشتیبانی
شواهد باید فعلی، مرتبط و با محرمیت مناسب شریک شود. عنوان سند بهتنهایی اثبات اجرای روش نیست.
منابع اصلی این راهنما
چکلیست با NIST SP 800-218 SSDF، راهنمای Secure by Demand اداره CISA و معیار ASVS بنیاد OWASP مقایسه شده است. اینها منابع مرجع است و تصدیق یا مطابقت عرضهکننده یا محصول را ثابت نمیکند.