1- معرفی محصول 1) ماژول اطلاعات جامع اعضای هیات علمی(سجاه) o امکان تعریف دانشکده ها و گروه های آموزشی و اساتید در گروهای آموزشی o امکان ثبت فعالیت های آموزشی o امکان ثبت فعالیت های پژوهشی o امکان ثبت فعالیت های فرهنگی o امکان ثبت فعالیت های اجرایی o امکان دریافت گزارش رزومه اساتید 2) ماژول ارتقا اعضای هیات علمی o امکان ثبت فعالیت های آموزشی در چهار سال گذشته o امکان ثبت فعالیت های پژوهشی در چهار سال گذشته o امکان ثبت فعالیت های فرهنگی در چهار سال گذشته o امکان ثبت فعالیت های اجرایی در چهار سال گذشته o امکان ارسال درخواست بررسی پرونده توسط عضو هیات علمی o امکان مشاهده فعالیت های ثبت شده توسط عضو هیات علمی در اکانت هیات ممیزه 3) ماژول خدمات رفاهی و پشتیبانی o امکان ثبت قراردادهای بیمه تکمیلی با شرکت های طرف قرارداد o امکان درخواست بیمه تکمیلی توسط متقاضیان o امکان ثبت درخواست کمک هزینه وام o امکان ثبت درخواست کمک هزینه دانش آموز ممتازی 4) ماژول مدیریت قراردادها o امکان ثبت پیمانکاران o امکان ثبت قراردادها o امکان ثبت متمم و ضمائم o امکان ثبت مناقصه ها و مزایده ها 5) ماژول مدیریت رویدادها و گواهینامه ها o امکان ثبت و اطلاع رسانی رویدادها o امکان ثبت نام در رویدادها o امکان ثبت گواهینامه رویدادها برای شرکت کنندگان 6) ماژول مدیریت جلسات - امکان ثبت جلسه - امکان دعوت از شرکت کنندگان در جلسه - امکان ثبت دستورجلسه - امکان ثبت صورتجلسه 1-1- مشخصات فنی محصول نسخه‌ی نرم‌افزار/میان‌افزار نسخه 2 مدل و نسخه سیستم‌عامل ویندوز سرور 2019 مدل و نسخه وب‌سرور IIS 10 مدل و نسخه پایگاه داده Microsoft SQL Server 19 زبان برنامه‌نویسی ASP.Net C# 1-2- معماری محصول این محصول از معماری چندلایه مشابه با معماری MVC پشتیبانی می نماید و به ترتیب از پایین به بالا (رابط کاربر) از 5 سطح اصلی پایگاه داده (Database)، لایه اشیاء (Objects Layer)، لایه دسترسی به داده ها (Data Access Layer)، لایه منطق تجاری (Busuiness Layer) و لایه رابط کاربری (User Interface Layer) تشکیل شده است. هر لایه با استفاده از لایه های پایینی خود سطحی از امکانات را در اختیار لایه بالاسری قرار می دهد و ضمن رعایت اصول امنیتی و طراحی ماژولار، در لایه نهائی امکانات مورد نیاز را در اختیار کاربر سیستم قرار می دهد. هر یک از لایه ها تنها امکان دسترسی مستقیم به لایه پایین خود را دارد و امکان دسترسی مستقیم به لایه های پایین تر برای آن وجود نخواهد داشت. در زمان فراخوانی وب سرویس های موجود در لایه رابط کاربری، با توجه به وب سرویس صدا زده شده، متغیرهای مورد نیاز برای آن ارسال می شوند. سپس وب سرویس به دلیل ارتباطی که با لایه منطق تجاری دارد، تابع مورد نظر از این لایه را فراخوانی نموده و داده های مورد نظر را به عنوان ورودی آن ارسال می نماید. در لایه منطق تجاری بر اساس ورودی های داده شده در صورت نیاز یک سری عملیات برنامه نویسی انجام شده و با توجه به حالات مختلف به وجود آمده، تابع مربوطه به همراه متغیرهای مورد نیاز آن از لایه دسترسی به داده ها فراخوانی می گردد. در نهایت در این لایه با استفاده از روش های مناسب عملیات فراخوانی توابع لایه پایگاه داده انجام شده و سامانه طراحی شده در انتظار دریافت داده های ذخیره شده در پایگاه داده می ماند و یا در مواردی متغیرهای ارسال شده را در پایگاه داده ذخیره می نماید. پس از اتمام عملیات تابع سطح پایگاه داده، نتیجه عملیات و داده های مورد نیاز مجددا به لایه دسترسی به داده ها تحویل داده می شوند. سپس داده های ارسال شده به لایه منطق تجاری بازگردانده می شوند و این لایه با توجه به نتیجه عملیات و داده های برگردانده شده تصمیمات مناسب را اتخاذ می نماید. با توجه به تصمیمات گرفته شده، نتیجه کلی فراخوانی تابع و گزارشات لازمه به لایه وب سرویس ارسال می شود. در نهایت لایه وب سرویس که در رابط کاربری قرار دارد، اطلاعات نهائی را دریافت نموده و با استفاده از ابزارهای نمایشی موجود در UI همچون فایلهای HTML و اسکریپت های JS نتایج را به کاربر نهائی نشان می دهد. 2- الزامات امنیتی الزامات امنیتی این سند بر اساس نسخه 1.1 پروفایل حفاظتی «برنامه‌های كاربردی تحت شبكه» تهیه شده است. ساختار این سند بدین صورت است كه برای هر رده در پروفایل حفاظتی مربوطه، یك دسته الزام بیان شده است. 2-1- ممیزی امنیت (لاگ) در این رده توانایی‌های محصول از نظر امكان تولید داده ممیزی (لاگ) مناسب برای فعالیت‌های مختلفی كه در محصول صورت می‌گیرد، در شرایط مختلف سنجیده می‌شود. شماره الزام رده ممیزی امنیت (لاگ) توضیحات 1 محصول باید برای موارد مشخص‌شده كه در ذیل آمده است، ثبت‌نشان تولید كند (Log ثبت نماید).  رویدادهایی که برای آنها لاگ ثبت می‌شود را مشخص نمایید. شروع و اتمام توابع  تلاش‌های ناموفق برای خواندن اطلاعات از ثبت‌نشان‌ها  خواندن اطلاعات از ثبت‌نشان‌ها  تمامی تغییرات در پیكربندی ثبت‌نشان‌ها  عدم وجود امکان تغییر در پیکربندی ثبت‌نشان‌ها عملیات انجام‌شده به دلیل سرریز حافظه ثبت‌نشان‌ها از حد آستانه  ثبت ثبت نشان اخطار به دلیل حذف بخشی از ثبت نشان های قدیمی ناشی از عبور از محدودیت عددی و یا محدودیت زمانی تعیین شده در تنظیمات سیستم عملیات انجام‌شده به دلیل شكست در ذخیره‌سازی ثبت‌نشان‌ها  تلاش‌های موفقیت‌آمیز برای بررسی صحت داده‌ی کاربری، شامل نتایج بررسی.  تمام كاربردهای سازوكار احراز هویت  نتایج نهایی عملیات احراز هویت  تلاش موفق و ناموفق هر گذرواژه تست‌شده توسط محصول  شکست و موفقیت انقیاد ویژگی‌های امنیتی کاربر به موجودیت فعال (مانند شکست و موفقیت ایجاد موجودیت فعال)  تمامی تغییرات بر روی مقادیر ویژگی‌های امنیتی  تمامی درخواست‌های (موفق و ناموفق) برای اجرای عملیات بر روی یك موجودیت غیرفعال محصول  تمامی تلاش‌ها برای وارد کردن داده‌های کاربری (شامل هرگونه ویژگی‌های امنیتی)  همه تلاش‌ها برای خارج كردن اطلاعات از محصول  تمامی تغییرات در رفتارهای توابع كاركردی محصول  امکان کشف و ثبت تغییر رفتار توابع وجود ندارد. استفاده از كاركردهای مدیریتی  تغییرات در گروه كاربران  شكست در كاركردهای امنیتی محصول  تمامی قابلیت‌هایی از محصول كه به دلیل شكست، نمی‌توانند عملیات مورد نظر را انجام دهند.  تلاش موفق یا ناموفق برای برقراری نشست.  عدم ایجاد نشست به دلیل محدودیت نشست‌های همزمان (حداقل)  خاتمه دادن به یك نشست غیرفعال توسط سازوكار قفل نشست  خاتمه به نشست غیرفعال توسط مدیر سیستم  سایر موارد  شروع و پایان تمامی توابع سیستم و نتیجه حاصل از فراخوانی آن ها و اطلاعات مربوط به فراخواننده در آن ها ثبت می گردد. 2 محصول باید برای هر ثبت‌نشان تولیدشده، مشخصاتی كه در ذیل آمده است را ثبت نماید.  مشخصاتی که در ثبت‌نشان‌ها وجود دارد مشخص شود. تاریخ و زمان رویداد  نوع رویداد  هویت ایجادكننده رویداد  نتیجه رویداد  آدرس IP ایجادكننده رویداد  سایر موارد  3 محصول باید ثبت‌نشان‌ها را در برابر دسترسی غیرمجاز محافظت نماید.  4 ثبت‌نشان‌هایی كه محصول تولید می‌نماید باید برای كاربر ساده و قابل فهم باشند.  مواردی كه در ثبت‌نشان‌ها وجود دارند، مشخص شوند. نبود داده نامفهوم در ركوردها  نبود فیلدهای نامرتبط  وجود داده معتبر و مناسب در هر فیلد  5 محصول باید امكان انتخاب و مرتب‌سازی برای ثبت‌نشان‌های تولیدشده را بر اساس فیلدها و پارامترهای مختلف، برای كاربر مجاز فراهم نماید.  مواردی كه بر اساس آنها مرتب‌سازی وجود دارد، مشخص شود. هویت موجودیت فعال  نوع حساب كاربری  تاریخ/زمان  روش اتصال كاربر  نوع رخداد  مكان رویداد  سایر موارد  6 محصول باید هرگونه حذف و تغییر غیرمجاز در ثبت‌نشان‌ها را تشخیص دهد و در صورت امكان جلوگیری نماید.  روش‌های تشخیص مشخص شود. (وجـود یـك مورد لازم و كـافی است) استفاده از درهم‌سازی (Hash) برای تشخیص تغییرات  پیكربندی امن پایگاه داده (كنترل دسترسی و رویدادنگاری)  فقط خواندنی كردن ثبت‌نشان‌ها در محصول  سایر موارد  7 محصول باید وقتی كه حجم ثبت‌نشان‌ها، به حد آستانه تعریف شده برای ذخیره‌سازی می‌رسد، كاربر مجاز را مطلع نماید.  روش‌های اطلاع‌رسانی مشخص شود (وجود یـك مـورد لازم و كافی است) استفاده از یك كانال ارتباطی  ارسال پیام  از طریق واسط كاربر مجاز  سایر موارد  ثبت ثبت نشان اخطار به دلیل حذف بخشی از ثبت نشان های قدیمی ناشی از عبور از محدودیت عددی و یا محدودیت زمانی تعیین شده در تنظیمات سیستم 8 محصول باید توانایی تولید ثبت‌نشان (ثبت Log) هنگام از كار افتادن محصول و/یا پر شدن حافظه ثبت‌نشان‌ها را داشته باشد و برای این كار از رویكردهای بیان‌شده استفاده نماید.  رویكردهای مـورد استفاده در محصول مشخص گردد (وجود یـك مورد لازم و کافی است) نادیده گرفتن ثبت‌نشان‌ها  ذخیره‌سازی محدود ثبت‌نشان‌ها، (آنهایی كه توسط كاربر مجاز و تحت حقوق خاصی رخ می‌دهند)  بازنویسی روی قدیمی‌ترین ثبت‌نشان‌های ذخیره‌شده  سایر موارد    2-2- رمزنگاری در این رده، توانایی محصول در پیاده‌سازی یا به‌كارگیری ماژولهای رمزنگاری، بررسی می‌گردد. برای حفظ محرمانگی داده از رمزنگاری استفاده می‌گردد و این رمزنگاری‌ها می‌تواند به صورت متقارن و نامتقارن صورت گیرد. در رمزنگاری متقارن از یك كلید مشترك برای رمزگذاری و رمزگشایی، استفاده می‌شود ولی در رمزنگاری نامتقارن این كار با استفاده از یك زوج كلید (كلید عمومی و كلید خصوصی) صورت می‌گیرد. الگوریتمها میتوانند با طول كلیدهای مختلف و به روشهای مختلفی (مد عملیاتی) به رمزگذاری و رمزگشایی داده بپردازند كه در این رده، توانایی محصول از این حیث مورد بررسی قرار گرفته است. در رده رمزنگاری همچنین از الگوریتمهای درهم‌سازی (هش) برای برقراری جامعیت داده استفاده می‌گردد. شماره الزام رده رمزنگاری توضیحات 1 محصول باید قابلیت رمزنگاری یا ماژول رمزنگاری داشته باشد، بنابراین باید رمزگذاری و رمزگشایی را بر اساس الگوریتم AES (تعریف‌شده ISO 18033-3) با توجه به موارد زیر انجام دهد.  مد عملیاتی كه الگوریتم از آن استفاده می‌كند را انتخاب نمایید. (وجود یك مورد لازم و كافی است.) مد عملیاتی CBC و طول کلید 128 یا 192 یا 256 بیتی (تعریف‌شده در NIST SP 800-38A)  مد عملیاتی GCM و طول کلید 128 یا 192 یا 256 بیتی (تعریف‌شده در NIST SP 800-38D)  AES 256 GCM مد عملیاتی CTR و طول کلید 128 یا 192 یا 256 بیتی (تعریف‌شده در ISO10116)  2 محصول باید بر اساس الگوریتم رمزنگاری و طول كلیدی كه انتخاب می‌نماید، توانایی تولید داده درهم‌سازی شده (Hash) را داشته باشد؛ بنابراین باید برای تولید درهم‌سازی از موارد زیر بر اساس ISO/IEC 10118-3:2004 استفاده نماید.  الگوریتم و اندازه خلاصه پیام مورد استفاده را انتخاب نمایید. (وجود یك مورد لازم و كافی است.) الگوریتم SHA-1 با اندازه خلاصه پیام 160 بیت  الگوریتم SHA-256 با اندازه خلاصه پیام 256 بیت  الگوریتم SHA-384 با اندازه خلاصه پیام 384 بیت  الگوریتم SHA-512 با اندازه خلاصه پیام 512 بیت  3 در صورتی كه تولید كلید رمزنگاری در محصول وجود دارد، نیاز است كه تخریب كلید رمزنگاری نیز بر اساس موارد زیر صورت پذیرد. (اختیاری)  روش نابودی کلید مشخص گردد. (وجود یک مورد لازم و کافی است) نابودی با استفاده از بازنویسی ساده (بازنویسی با صفرها، یكها، مقدار تصادفی، مقدار جدیدی از كلید)  نابودی با استفاده از یك واسط مشخص  از طریق توابع امنیتی محصول  سایر موارد  در این سیستم از زوج کلیدهای عمومی و خصوصی استفاده شده است و کلید عمومی همیشه در سیستم باقی می ماند. البته ما کلید را رمزنگاری کرده ایم تا به راحتی در دسترس نباشد. 4 در صورتی كه امضاء دیجیتال در محصول پشتیبانی می‌شود، نیاز است كه سرویس‌های امضاء رمزنگاری (تولید و تأیید) بر اساس الگوریتم‌های رمزنگاری زیر انجام گیرد. (اختیاری)  الگوریتم و اندازه کلیدهای مورد استفاده را انتخاب نمایید. (وجود یک مورد لازم و کافی است) الگوریتم‌های امضاء دیجیتال RSA با کلیدهای رمزنگاری 2048 بیت و بزرگتر (بر اساس FIPS PUB 186-4، استاندارد امضاء دیجیتال (DSS) بخش 5.5، الگوی امضای RSASSA-PSS نسخه PKCS #1 v2.1 و/یا RSASSA-PKCS1v_5؛ ISO/IEC 9796-2، الگوی امضای دیجیتال 2 و یا الگوی امضای دیجیتال 3)  الگوریتم‌های امضاء دیجیتال ECDSA با کلیدهای رمزنگاری 256 بیت یا بزرگتر (بر اساس ISO/IEC 14888-3 بخش 6.4، استاندارد امضای دیجیتال (DSS) بخش 6 و پیوست D، با استفاده از منحنی P-256 یا P-384 یا P-521)    2-3- شناسایی و احراز هویت در این رده توانایی‌های محصول از نظر امكان شناسایی و احراز هویت كاربر در حالت‌های مختلف و اقدامات متقابل در راستای عدم برقراری آنها، بررسی می‌گردد. شماره الزام رده شناسایی و احراز هویت توضیحات 1 محصول باید بتواند تعداد تلاش‌های ناموفقی را كه برای احراز هویت شدن صورت گرفته است (در هر بخش یا قسمتی كه نیاز به احراز هویت وجود دارد)، بر اساس موارد زیر مشخص نماید.  مقدار یا یازه‌ی مورد استفاده در هریک باید مشخص گردد. (وجود یک مورد لازم و کافی است) یك عدد مثبت ثابت  یك عدد مثبت قابل تنظیم توسط مدیر  یك بازه‌ی قابل قبولی از مقادیر  2 محصول باید زمانی كه تعداد تلاش‌های ناموفق صورت گرفته برای احراز هویت به حد تعیین‌شده رسید، برای پیچیده‌تر كردن احراز هویت از موارد زیر استفاده نماید.  روش استفاده شده برای پیچیده‌تر کردن احراز هویت را انتخاب نمایید. (وجود یک مورد لازم و کافی است.) لازم به ذکر است روش‌های فوق با توجه به نوع کاربرد می‌تواند از حالت انتخابی به حالت الزامی تغییر یابد. برای مثال غیرفعال کردن حساب کاربری در تمامی کاربردها مفید نیست. غیرفعال كردن حساب كاربری (فعال كردن به صورت دستی توسط مدیر صورت می‌گیرد)  غیرفعال كردن حساب كاربری بر اساس مدت زمان معین (فعال كردن پس از زمان مذكور به صورت خودكار صورت می‌گیرد)  استفاده از سازوكارهایی مانند كدهای CAPTCHA، گرفتن ایمیل و ... (در قسمت توضیحات بیان شود)  سایر موارد  3 محصول باید برای هر كاربر، ویژگی‌های امنیتی كه شامل حداقل اطلاعات كاربری لازم برای شناسایی و احراز هویت باشند را نگهداری نماید.  ویژگی‌های امنیتی مورد نیاز كه باید برای هر كاربر نگهداری شوند. شناسه كاربر  روش احراز هویت مورد استفاده  داده احراز هویت  وضعیت حساب كاربری (فعال، غیرفعال، مسدود شده و غیره)  نقش كاربر  سایر موارد  4 محصول باید قابلیت مدیریت گذرواژه را فراهم آورد.  موارد نیاز كه باید در تعریف گذرواژه استفاده شوند. استفاده از حروف كوچك  استفاده از حروف بزرگ  استفاده از اعداد  استفاده از كاراكترهای خاص ("@"، "#"، "$"، "٪"، "^"، "!" "&"، "*"، "(" , ")" و ...)  حداقل طول 8 یا بیشتر (قابل تنظیم)  سایر موارد  5 محصول باید پیش از احراز هویت موفق یك كاربر، تنها اجازه انجام اقدامات محدودی را فراهم نماید.  اقدامات عمومی كه كاربر می‌تواند قبل از احراز هویت انجام دهد، انتخاب شود. مشاهده راهنمای نحوه ورود به سیستم  بازیابی گذرواژه  هیچ اقدامی  سایر موارد  صفحات لاگین سایر سامانه ها و ثبت نام در سامانه رفاهی و جلسات 6 محصول باید از سازوكار احراز هویت پشتیبانی نماید (برای احراز هویت كاربران راه‌دور، باید بیش از یك سازوكار احراز هویت در محصول به كار رفته باشد).  سـازوكارهـای احراز هویت موجود در محصول مشخص شوند. نام كاربری و گذرواژه  امضاء دیجیتال  Active Directory  OTP یا توكن  احراز هویت دو فاكتوری  سایر موارد  7 محصول باید برای هر كاربر فعال، ویژگی‌های امنیتی نگهداری نماید.  ویژگی‌هایی امنیتی كه محصول برای هر كاربر نگهداری می‌كند، مشخص گردد (در صورتی كه محصول قوانین بیشتری هنگام برقراری نشسـت اعمال می‌نماید، ایـن قوانین در «سایر موارد» بیان می‌شوند). شناسه كاربر  نقش‌ها و یا مجموعه دسترسی‌های كاربر به قسمتهای مختلف برنامه  جزئیات واسط كلاینت  پیشینه احراز هویت (جزئیات تلاش برای احراز هویت موفق و ناموفق)  سایر موارد  8 محصول باید در زمان اتصال اولیه كاربر یا همان زمان برقراری نشست توسط كاربر، موارد زیر را اجرا نماید.  در صورتی كه محصول قوانین بیشـتری هنگام برقراری نشسـت اعمال می‌نماید، ایـن قوانین در «سایر موارد» بیان می‌شوند). از بین رفتن اعتبار نشستهای قبلی هنگام برقراری یك نشست جدید (به جزء مواردی كه فعال بودن همزمان چندین نشست مورد نیاز كاركردی برنامه باشد. در این موارد، هنگام فعال شدن نشست‌های جدید، باید به صفحه كاربر اصلی (نشست اول) اطلاع داده شود.)  بروزرسانی اطلاعات پیشینه احراز هویت  سایر موارد  9 محصول باید بر روی تغییرات ویژگی‌های امنیتی كاربر فعال قوانینی را اعمال نماید.  قوانینی كه در صورت تغییر ویژگی‌های امنیتی كاربر فعال، اعمال می‌شود، مشخص گردد. غیرمجاز بودن هرگونه تغییر در طول نشست فعال  سایر موارد    2-4- حفاظت از داده‌ی کاربری داده كاربری در واقع هر نوع داده‌ای است كه كاربر تولید می‌كند یا مالك آن است. توضیح كامل داده كاربری در سند «راهنمای سند الزامات امنیتی برنامه‌های کاربردی تحت شبکه» در قسمت اصطلاحات بیان گردیده است. در این رده، توانایی محصول در حفاظت از این داده‌ها مورد بررسی قرار می‌گیرد. شماره الزام رده حفاظت از داده‌ی کاربری توضیحات 1 محصول باید برای موجودیت‌ها و عملیات، خط‌مشی‌های كنترل دسترسی اعمال نماید.  موجودیت‌های فعالی كه خطمشی‌های كنترل دسترسی در مورد آنها اعمال می‌شوند، مشخص گردد. مدیر سیستم  کاربر عادی  سایر موارد  موجودیت‌های غیرفعالی كه خط‌مشی‌های كنترل دسترسی در مورد آنها اعمال می‌شوند، مشخص گردد. ركوردها، مستندات و فراداده  داده متعلق به كاربران  داده احراز هویت  سایر موارد  عملیاتی كه خط‌مشی‌های كنترل دسترسی در رابطه با آنها اعمال می‌شوند، مشخص گردد. ایجاد موجودیت غیرفعال جدید  حذف موجودیت غیرفعال  تغییر دسترسی‌ها به موجودیت غیرفعال  عملیات بر روی فراداده وابسته به موجودیت غیرفعال  سایر موارد  2 محصول باید بر اساس ویژگی‌های زیر، برای موجودیت‌های غیرفعال خط‌مشی‌های كنترل دسترسی اعمال نماید.  ویژگی‌هایی كه بر اساس آن خط‌مشی‌ها تعریف می‌شوند، انتخاب گردد. نقش‌ها و مجوزهای كاربر مجاز  اطلاعات نشست كاربر و پارامترهایی كه با درخواست فرستاده می‌شوند.  سایر موارد  3 محصول باید بر اساس قاعده‌ای عملیات بین موجودیت فعال تحت كنترل و موجودیت غیرفعال كنترل‌شده را مجاز نماید (این قاعده می‌تواند بدین شكل باشد كه در لیست كنترل دسترسی، ركوردی وجود داشته باشد كه به كاربر با شناسه كاربری یا شناسه گروه مربوطه یا نقش كاربری تعریف‌شده حق دسترسی به موجودیت غیرفعال را بدهد.)  4 محصول باید بر اساس قوانینی، از دسترسی موجودیت فعال به موجودیت غیرفعال جلوگیری نماید.  قوانین ممانعت از دسترسی مشخص شوند (در صورت اعمال قوانین بیشتر توسط محصول، در «سایر موارد» بیان شود). عبور تعداد نشست آغاز شده با نام كاربری مشابه از مقدار آستانه از پیش تعریف‌شده  سایر موارد  بر اساس تعداد فراخوانی توابع امکان فراخوانی تا مدتی ممنوع می گردد 5 محصول باید تضمین نماید تمام اطلاعات قبلی منابع یا در هنگام تخصیص و یا در هنگام آزادسازی آنها، غیرقابل دسترس می‌گردد و یا سازوكاری امن برای دسترسی به منابع قبلی وجود دارد.  تخصیص و آزادسازی منابع توسط سیستمعامل انجام میشود. 6 محصول باید هنگام دریافت داده كاربری خط‌مشی كنترل دسترسی را اعمال نماید و برای این كار از ویژگی‌های امنیتی مرتبط با داده كاربری استفاده كند.  ویژگی‌های امنیتی مرتبط با داده كاربری كه در هنگام ورود آن به محصول استفاده می‌شوند، مشخص شود (در صورتی كه كنترل دسترسی برای موارد دیگری نیز صورت می‌گیرد، در قسمت «سایر موارد» بیان گردد). نوع داده  متنی، داده، صوتی، ویدئویی، تصویری و صفحه گسترده حجم و اندازه  حداکثر 50 مگابایت (امکان تعیین حداکثر حجم توسط طراح و امکان تعیین حجم برای فرمت های مختلف در منوی تعاریف اولیه -> انواع پسوندهای فایل توسط ادمین) فرمت  هر فرمتی غیر از فرمت های مخرب توسط ادمین قابل تعریف است. لیست فرمت های مخرب ممنوعه: exe,dll,lnk,ink,sys,swf,jar,scr,gzquar,js,com,zix,bat,ocx,vbs,bin,class,ws,drv,ozd,wmf,aru,shs,dev,chm,pgm,xnxx,pif,vxd,xlm,vbe,tps,pcx,vba,0_full_0_tgod_signed,dxz,boo,sop,386,hlp,tsa,vb,exe1,bkd,exe_renamed,rhk,vbx,lik,osa,.9,cih,mjz,dlb,dyz,php3,wsc,hlw,dom,s7p,classmjg,spam,mfu,dyv,kcd,bup,xir,mcq,rsc_tmp,bxz,wsh,upa,cxq,bhx,dli,txs,fnr,xdu,xlv,ska,wlpginstall,cfxxe,dllx,tti,smtmp,vexe,qrn,xtbl,fag,oar,ceo,tko,uzy,bll,dbd,plc,smm,ssy,blf,zvz,cc,ce0,nls,ctbl,iws,hsq,lkh,crypt1,vzr,ezt,atm,hts,rna,let,aepl,aut,fuj,delf,fjl,buk,capxml,bmw,cyw,iva,bps,pid,lpaq5,dxz,qit,bqf,pr,lok,xnt تعداد دفعات Import  تنها یک بار با توجه به نام و حجم فایل و شخص ارسال کننده سایر موارد  7 محصول باید از یك پروتكل امن برای انتقال داده استفاده نماید. این پروتكل ارتباط و همبستگی شفافی را بین داده كاربری دریافت‌شده و ویژگی‌های امنیتی آن فراهم می‌كند و همچنین از شنود و گم‌شدن داده حین انتقال جلوگیری می‌كند.  ما از ssl و به عبارتی https استفاده می کنیم 8 محصول باید هنگام انتقال داده به بیرون از محصول، خط‌مشی كنترل دسترسی اعمال نماید و برای این كار از ویژگی‌های امنیتی مرتبط با داده كاربری استفاده كند.  ویژگی‌های امنیتی مرتبط با داده كاربری كه در هنگام خروج آن از محصول استفاده می‌شوند، مشخص شوند نوع داده  متنی، داده، صوتی، ویدئویی، تصویری و صفحه گسترده حجم و اندازه  حداکثر 50 مگابایت (قابل تغییر به مقادیر کمتر برای فرمت های خاص در منوهای خاص توسط ادمین) فرمت  هر فرمتی غیر از فرمت های مخرب توسط ادمین قابل تعریف است. لیست فرمت های مخرب ممنوعه: exe,dll,lnk,ink,sys,swf,jar,scr,gzquar,js,com,zix,bat,ocx,vbs,bin,class,ws,drv,ozd,wmf,aru,shs,dev,chm,pgm,xnxx,pif,vxd,xlm,vbe,tps,pcx,vba,0_full_0_tgod_signed,dxz,boo,sop,386,hlp,tsa,vb,exe1,bkd,exe_renamed,rhk,vbx,lik,osa,.9,cih,mjz,dlb,dyz,php3,wsc,hlw,dom,s7p,classmjg,spam,mfu,dyv,kcd,bup,xir,mcq,rsc_tmp,bxz,wsh,upa,cxq,bhx,dli,txs,fnr,xdu,xlv,ska,wlpginstall,cfxxe,dllx,tti,smtmp,vexe,qrn,xtbl,fag,oar,ceo,tko,uzy,bll,dbd,plc,smm,ssy,blf,zvz,cc,ce0,nls,ctbl,iws,hsq,lkh,crypt1,vzr,ezt,atm,hts,rna,let,aepl,aut,fuj,delf,fjl,buk,capxml,bmw,cyw,iva,bps,pid,lpaq5,dxz,qit,bqf,pr,lok,xnt سایر موارد  9 محصول باید هنگام خروج داده كاربری به خارج از محصول، قوانینی را اعمال نماید.  قوانینی كه در هنگام خروج داده از محصول اعمال می‌شوند، مشخص شوند مدیر سیستم باید خروج داده‌ها را محدود نماید، به طوریكه كاربران محصول، قادر به خروج بدون هدف داده به خارج از محصول نباشند.  بیشینه تعداد دریافت هر فایل در یک بازه زمانی قابل تعیین توسط مدیر، قابل تنظیم می باشد. سایر موارد  10 محصول باید تغییر غیرمجاز را در داده كاربری حساس ذخیره‌شده در محصول تشخیص دهد.  چگونگی تشخیص تغییر در داده‌های كاربری حساس، مشخص شود. مقدار درهم‌سازی‌شده داده‌های كاربری ذخیره‌شده، نگهداری می‌شود.  سایر موارد  11 محصول باید در صورت تشخیص خطای صحت در داده‌ها، اقدامات مقابله‌ای زیر را انجام دهد.  اقدام مقابله‌ای در صورت تشخیص خطا، مشخص شود (وجود یك مورد لازم و كافی است) ایجاد هشدار/اخطار برای نقش‌های مجاز  در زمان مشاهده لیست موجودیت های حساس تعیین شده برای تشخیص صحت داده. برای مثال در صفحه اطلاعات کاربران (جدول کاربران حاوی اطلاعات حساس و مقدار درهم سازی است) و در زمان مشاهده لیست آن ها، عنوان یکی از ستون های جدول برابر است با "صحت دارد" که مقدار آن برای هر رکورد بیانگر صحت داده های آن رکورد یا کاربر است. در زمان ورود به این صفحات لیست داده های فاقد صحت به صورت اخطار به کاربر نمایش داده می شود. در ضمن امکان مشاهده یک جا همه خطاهای صحت داده (منظور خطاهای ایجاد شده در صفحات و جداول مختلف) در یک صفحه برای ادمین فراهم شده است. تصحیح داده بر اساس مقادیر قبل  سایر موارد    2-5- مدیریت امنیت در این رده توانایی‌های محصول در مدیریت (حذف، تغییر، فعال كردن و ...) كاركردهای امنیتی (جمع‌آوری داده‌های سیستم، پیكربندی‌ها و ...) مورد بررسی قرار می‌گیرد. همچنین توانایی محصول در مدیریت نقش‌ها و دسترسی آنها برای اعمال مدیریت بر روی كاركردهای امنیتی سنجیده می‌شود. شماره الزام رده مدیریت امنیت توضیحات 1 محصول باید برای مدیر سیستم و هر كاربری كه مجوز لازم را دارد، امكان فعالیت‌های مدیریتی زیر را بر روی توابع و تمام كاركردهای مربوط به مدیریت محصول فراهم آورد.  فعالیت‌های مدیریتی که محصول پشتیبانی می‌کند، مشخص شوند. تعیین و تغییر رفتار  غیرفعال نمودن  فعال نمودن  سایر موارد  2 محصول باید با اعمال خط‌مشی كنترل دسترسی؛ امكان تغییر پیش‌فرض و عملیات زیر را بر روی ویژگی‌های امنیتی الزام 7 از رده شناسایی و احراز هویت، به مدیر سیستم و هر كاربری كه مجوز لازم را دارد، محدود نماید.  عملیات بر روی ویژگی‌های امنیتی که در محصول پشتیبانی می‌شوند، مشخص گردد. پرس‌وجو  تغییر  حذف  تنها در صورتی می توان یک ویژگی امنیتی را از سیستم حذف نمود که در سایر بخش های سیستم از مقدار آن ویژگی استفاده نشده باشد و ارتباط محدود کننده ای برای آن وجود نداشته باشد. تغییر پیش‌فرض  سایر موارد  3 محصول باید برای داده‌های محصول، امكان كاركردهای زیر را به مدیر سیستم و هر كاربری كه مجوز لازم را دارد، محدود نماید.  عملیات بر روی داده‌های محصول كه در محصول پشتیبانی می‌شوند، مشخص شود. تغییر پیش‌فرض  حذف نمودن  پرس‌وجو  مقداردهی  ایجاد  مشاهده  سایر موارد  در برخی صفحات مربوط به هر موجودیت (کاربران، نقش ها، نقش های کاربران و موجودیتهای متعدد دیگر) ممکن است موارد دیگری هم وجود داشته باشد. از جمله این موارد می توان به فعال سازی و غیر فعال سازی، تایید صحت برخی اطلاعات و فایل های بارگذاری شده، مشاهده جزئیات بیشتر برای موجودیت، ویرایش موجودیت و اعمال برخی محدودیت ها برای سایر کاربران اشاره نمود. این موجودیت ها بخشی از داده های محصول به حساب می آیند. 4 محصول باید توانایی انجام كاركردهای زیر را داشته باشد.  در صورتی که هرکدام از موارد مطرح‌شده، توسط محصول قابل اجرا نیست، در قسمت توضیحات باید دلایل مطرح گردد. پشتیبانی از (حذف، ویرایش، اضافه) گروهی از كاربران با مجوز دسترسی برای خواندن اطلاعات ثبت‌نشان‌ها  پشتیبانی از مجوزهای مشاهده/ویرایش ثبت‌نشان‌ها  امکان ویرایش ثبت نشان ها در سیستم وجود ندارد. پشتیبانی از حد آستانه و عملیات (حذف، ویرایش، اضافه) در زمان خرابی ذخیره‌سازی ثبت‌نشان‌ها  مدیریت معیارها/پارامترهای مورد استفاده برای ایجاد و یا منع دسترسی به محصول  انتخاب زمان اجرای حفاظت از اطلاعات باقیمانده كه می‌تواند در محصول قابل پیكربندی باشد. (برای مثال، زمان تخصیص و یا زمان آزادسازی منابع)  تخصیص اطلاعات در سیستم ما توسط سامانه انجام نمی شود. در موارد لازم این عملیات توسط سیستم عامل آن انجام می گردد ویرایش قوانین كنترلی بیشتر برای وارد كردن داده به داخل محصول  در نظر گرفتن یك عملیات از پیش تعیین‌شده پس از تشخیص یك خطای صحت داده كه می‌تواند قابل پیكربندی نیز باشد.  1. مدیریت حد آستانه برای تلاش‌های ناموفق 2. مدیریت عملیاتی كه هنگام شكست احراز هویت باید صورت گیرد.  مدیریت معیارها برای تنظیم گذرواژه‌ها  1. مدیریت داده‌های احراز هویت توسط مدیر یا كاربر مربوطه 2. مدیریت یك‌سری عملیاتی كه قبل از احراز شدن هویت كاربر انجام می‌شوند.  1. مدیریت سازوكارهای احراز هویت 2. مدیریت قوانین مرتبط با احراز هویت  مدیریت تغییرات و فر‌آیندهایی مانند (اختصاص آدرس IP برای عملیات شناسایی كاربر خاص و از این قبیل موارد) كه مدیر مجاز می‌تواند قبل از شناسایی كاربر انجام دهد.  مدیر مجاز می‌تواند ویژگی‌های امنیتی موجودیت‌های فعال پیش‌فرض را تعریف كند و تغییر دهد.  مدیریت مقادیر پیش‌فرض برای كنترل دسترسی محصول  مدیریت نقش‌ها در محصول  مدیریت حداكثر تعداد مجاز نشست‌های همزمان كاربران توسط مدیر  مدیریت شرایط آغاز نشست توسط مدیر مجاز  1. تعیین زمان غیرفعال بودن برای یك كاربر مشخص كه پس از آن، نشست آن كاربر خاتمه یابد. 2. تعیین زمان پیش‌فرض غیرفعال بودن كاربران كه پس از آن، نشست خاتمه یابد.  5 محصول باید توانایی تعریف نقش‌های مختلف را داشته باشد.  نقش‌هایی که در محصول پشتیبانی می‌شوند، مشخص گردد. مدیر سیستم  كاربر پیشرفته  كاربر عادی  سایر موارد  امکان اضافه کردن هر نقشی وجود دارد 6 محصول باید قادر باشد كاربران را به نقش‌های تعریف‌شده یا قابل تعریف مرتبط نماید، همچنین لازم است هر حساب كاربری تنها به یك نقش مرتبط شده باشد، اما ممكن است نقش‌ها تنها به یك كاربر محدود نشوند و چندین كاربر نقش مشابهی داشته باشند.    2-6- حفاظت از توابع امنیتی محصول در این رده، توانایی محصول در حفظ وضعیت امن در زمان رخ دادن شكست و همچنین حفاظت از داده‌ها هنگام تبادل بین اجزای محصول یا تبادل با موجودیت‌های دیگر، مورد بررسی قرار گرفته است. شماره الزام رده حفاظت از توابع امنیتی محصول توضیحات 1 محصول باید هنگام رخ دادن هرگونه خرابی، اشکال یا شكست مانند از كار افتادن محصول، قطع شدن ارتباط محصول با پایگاه داده و یا اختلال در كاركردهای محصول، در وضعیت امنی قرار گرفته، صحت داده‌ها و خط‌مشی كنترل دسترسی را حفظ نماید.  تمامی خطاهای رخ داده، در صورت عدم توقف کامل نرم افزار (منظور Application در حال اجرا در IIS)، توسط Log4net و در فایل های متنی ذخیره می شوند. هر یكی از مواردی كه در صورت رخداد آن، وضعیت امن محصول حفظ می‌شود، مشخص گردد. خرابی‌های نرم‌افزاری  خرابی‌های سخت‌افزاری  2 محصول باید از طریق فراهم نمودن بستر و زیرساخت امن، توانایی محافظت از افشاء یا تغییر داده، هنگام انتقال بین بخش‌های مجزای خود را داشته باشد.  3 در صورتی كه محصول از محصولات امن IT استفاده می‌كند، باید تفسیر سازگار و یكسانی را از داده امنیتی در زمان اشتراك‌گذاری آن بین خود و دیگر محصولات امن IT، فراهم آورد.  داده امنیتی قابل اشتراك‌گذاری كه در محصول پشتیبانی مـی‌شوند، مشخص گردد. داده‌های احراز هویت  كلید  امضای دیجیتال  ثبت‌نشان‌ها (داده‌های ممیزی)  سایر موارد  4 محصول باید زمان و تاریخ معتبری داشته باشد، بنابراین باید مهرهای زمانی معتبر، تولید یا استفاده نماید.  روش‌های ایجاد مهرهای زمانی معتبر انتخاب شود. (دیگـر روشهای موجـود در محصول، در قسـمت «سایر مـوارد» بیـان شود). گرفتن مهرهای زمانی از سرور NTP  تنظیم مهرهای زمانی از طریق اینترنت  تنظیم مهرهای زمانی به صورت پیش‌فرض (معتبر و عدم امكان دستكاری غیرمجاز)  سایر موارد  5 محصول باید امكان بروزرسانی نرم‌افزار و میان‌افزار محصول را برای مدیر سیستم فراهم نماید.  روش بروزرسانی مورد استفاده در محصول، مشخص گردد (حـداقل یك مورد لازم و كافی است). بروزرسانی دستی  تغییرات کلی و اساسی سامانه توسط نیروهای شرکت طراح بر روی سرور اصلی انجام می گردد. جستجوی خودكار بروزرسانی‌ها  بروزرسانی‌های خودكار  بروزرسانی دستی بعد از اطمینان از امنیت وصله و یا فایل بروزرسانی  6 در صورت استفاده از بروزرسانی به روش خودكار، محصول باید پیش از نصب بروزرسانی‌های نرم‌افزاری و میان‌افزاری، امكان احراز اصالت میان‌افزار یا نرم‌افزار را فراهم نماید.  سازوكار مورد استفاده برای صحت‌سنجی (اصالت سنجی) به‌روزرسانی‌ها انتخاب گردد. امضاء دیجیتال  درهم‌ساز منتشرشده  2-7- تخصیص منابع در این رده، به بررسی وضعیت عملكردهای محصول و منابع مورد استفاده توسط آن در زمانهای مختلف از جمله زمان شكست پرداخته می‌شود. شماره الزام رده تخصیص منابع توضیحات 1 محصول باید در زمان رخداد هرگونه خرابی (شكست) نرم‌افزاری، از عملكرد كاركردهای اصلی محصول اطمینان حاصل نماید.    2-8- دسترسی به محصول در این رده توانایی محصول در مدیریت نشست‌های صورت گرفته شده توسط كاربر، ارزیابی می‌شود. شماره الزام رده دسترسی به محصول توضیحات 1 محصول باید حداكثر تعداد نشست‌های همزمان متعلق به یك كاربر را محدود نماید.  2 محصول باید كلیه نشست‌های تعاملی راه‌دور را پس از مدت زمانی كه غیرفعال هستند (و می‌بایست توسط مدیر قابل تنظیم باشد)، خاتمه دهد.  3 محصول باید به كاربری كه خود آغازگر نشست بوده است اجازه‌ی خاتمه نشست را بدهد.  4 در صورت برقراری نشست به طور موفقیت‌آمیز، محصول باید قادر به نمایش آخرین تلاش موفق برای ایجاد نشست بر اساس موارد زیر باشد.  انتخاب یك مورد لازم و كافی است. روز  زمان  سایر موارد  IP 5 در صورت برقراری نشست به طور موفقیت آمیز، محصول باید قادر به نمایش آخرین تلاش ناموفق برای ایجاد نشست بر اساس موارد زیر و تعداد تلاش‌های ناموفق تا آخرین ایجاد نشست موفقیت‌آمیز باشد.  انتخاب یك مورد لازم و كافی است. روز  زمان  سایر موارد  IP 6 محصول نباید اطلاعات سوابق دسترسی را بدون بازدید كاربر، از واسط كاربری پاك نماید.  7 محصول باید توانایی ممانعت از ایجاد نشست بر اساس پارامترهایی را داشته باشد.  پارامترهای موجود برای جلوگیری از نشسـت، مشخص شوند (وجود یـك مورد لازم و كافی است). مكان  شماره پورت  روز  زمان  سایر موارد    2-9- کانال‌ها/مسیرهای مورد اعتماد در این رده به بررسی پروتكل‌های امنی كه برای برقراری كانال/مسیر مورد اعتماد، بین محصول و موجودیت‌های IT خارجی، یا بین اجزای محصول، استفاده می‌شوند، پرداخته می‌شود. شماره الزام رده کانال‌ها/مسیرهای مورد اعتماد توضیحات 1 محصول باید قادر باشد مسیر ارتباطی امنی بین خود، كاربران و دیگر محصولات IT فراهم نماید كه به طور منطقی از دیگر كانال‌ها متمایز باشد. سپس از طریق این كانال احراز هویت را انجام داده و از تغییر و افشاء داده تبادلی حفاظت نموده و تغییرات را تشخیص دهد. در صورت انتخاب مورد HTTPS، رعایت الزام ‏3-1- و ‏3-3- و در صورت انتخاب TLS، رعایت الزامات ‏3-2- تا ‏3-4- كه در بخش ‏3- بیان گردیده است، الزامی است.  پروتكل مورد استفاده برای ایجاد كانال امن انتخاب گردد. HTTPS  TLS  2 محصول باید به كاربر/دیگر محصول IT معتبر اجازه دهد كه ارتباطات راه‌دور را از طریق كانال امن آغاز كنند.  ارتباط با ماژول ارسال پیامک به صورت امن انجام می شود. 3 محصول باید استفاده از كانال امن را برای احراز هویت اولیه كاربر الزامی نماید.    3- الزامات امنیتی مبتنی بر انتخاب این بخش به بیان الزاماتی می‌پردازد كه رعایت آنها وابسته به برخی از الزاماتی است كه در بخش‌های پیشین بیان شده است. برای مثال اگر در الزامات مربوط به رده كانال امن، پروتكل HTTPS انتخاب شود، آنگاه رعایت الزامات HTTPS كه در این بخش بیان شده است، اجباری می‌گردد. 3-1- پروتكل HTTPS شماره الزام پروتکل HTTPS توضیحات 1 محصول باید پروتكل HTTPS را مطابق با RFC 2818 اجرا كند.  2 محصول باید پروتكل HTTPS را با استفاده از TLS اجرا كند.  3 در صورتی كه گواهی‌نامه ارائه شده از سمت دیگر محصولات IT (درهنگام برقراری ارتباط) نامعتبر باشد، محصول باید بر اساس موارد زیر عمل نماید. اعتبارسنجی گواهی‌نامه بر اساس الزامات بخش ‏3-5- انجام می‌شود كه در این صورت الزامات بخش ‏3-5- الزامی است.  محصول تنها از موارد بیان‌شده می‌تواند استفاده نماید. اتصال را برقرار نكند.  برای برقراری اتصال درخواست مجوز كند.    3-2- پروتكل TLS Client شماره الزام پروتکل TLS Client توضیحات 1 محصول باید TLS 1.2 (RFC 5246) و/یا TLS 1.1 (RFC 4346) را پیاده‌سازی و دیگر نسخه‌های TLS و SSL را رد كند. همچنین محصول باید TLS را با پشتیبانی از مجموعه‌های رمز زیر پیاده‌سازی نماید.  ﻣﺠﻤﻮﻋﻪ رﻣﺰ ﻣﻮرد اﺳﺘﻔﺎده و ﭘﻴﺎده‌ﺳﺎزی‌شده ﻣﺤﺼﻮل، اﻧﺘﺨﺎب ﮔﺮدد. TLS_RSA_WITH_AES_128_CBC_SHA مطابق با RFC 3268  TLS_RSA_WITH_AES_192_CBC_SHA مطابق با RFC 3268  TLS_RSA_WITH_AES_256_CBC_SHA مطابق با RFC 3268  TLS_DHE_RSA_WITH_AES_128_CBC_SHA مطابق با RFC 3268  TLS_DHE_RSA_WITH_AES_192_CBC_SHA مطابق با RFC 3268  TLS_DHE_RSA_WITH_AES_256_CBC_SHA مطابق با RFC 3268  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA مطابق با RFC 4492  TLS_ECDHE_RSA_WITH_AES_192_CBC_SHA مطابق با RFC 4492  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA مطابق با RFC 4492  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA مطابق با RFC 4492  TLS_ECDHE_ECDSA_WITH_AES_192_CBC_SHA مطابق با RFC 4492  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA مطابق با RFC 4492  TLS_RSA_WITH_AES_128_CBC_SHA256 مطابق با RFC 5246  TLS_RSA_WITH_AES_192_CBC_SHA256 مطابق با RFC 5246  TLS_RSA_WITH_AES_256_CBC_SHA256 مطابق با RFC 5246  TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 مطابق با RFC 5246  TLS_DHE_RSA_WITH_AES_192_CBC_SHA256 مطابق با RFC 5246  TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 مطابق با RFC 5246  TLS_RSA_WITH_AES_128_GCM_SHA256 مطابق با RFC 5288  TLS_RSA_WITH_AES_192_GCM_SHA256 مطابق با RFC 5288  TLS_RSA_WITH_AES_256_GCM_SHA384 مطابق با RFC 5288  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 مطابق با RFC 5289  TLS_ECDHE_ECDSA_WITH_AES_192_CBC_SHA256 مطابق با RFC 5289  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA384 مطابق با RFC 5289  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 مطابق با RFC 5289  TLS_ECDHE_ECDSA_WITH_AES_192_GCM_SHA256 مطابق با RFC 5289  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 مطابق با RFC 5289  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 مطابق با RFC 5289  TLS_ECDHE_RSA_WITH_AES_192_GCM_SHA256 مطابق با RFC 5289  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 مطابق با RFC 5289  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 مطابق با RFC 5289  TLS_ECDHE_RSA_WITH_AES_192_CBC_SHA256 مطابق با RFC 5289  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 مطابق با RFC 5289  2 محصول باید مطابقت شناسه ارائه‌شده با شناسه مرجع را با توجه به بخش 6 از RFC 6125، تأیید نماید.  3 محصول باید كانال امن را فقط در صورت معتبر بودن گواهی‌نامه سرور برقرار سازد؛ بنابراین اگر گواهی‌نامه سرور غیرمعتبر به نظر رسید، محصول باید بر اساس موارد زیر رفتار نماید.  در صورت پشتیبانی از اقدامات دیگر، در «سایر موارد» بیان گردد. ارتباط را برقرار نكند  برای برقراری ارتباط درخواست مجوز كند  سایر موارد  4 محصول باید در پیام ClientHello برای استفاده از خم‌های بیضوی، بر اساس موارد زیر عمل نماید.  استفاده از خم های secp256r1 و secp384r1 وx25519 در صورت كه محصول از منحنی استفاده می‌نماید، طول كلید باید مشخص گردد. Supported Elliptic Curves Extension را ارائه نکند  Supported Elliptic Curves Extension را به همراه NIST Curveهای secp256r1 یا secp384r1 یا secp521r1 ارائه نماید  هیچ منحنی دیگری    3-3- پروتکل TLS Server شماره الزام پروتکل TLS Server توضیحات 1 محصول باید TLS 1.2 (RFC 5246) را پیاده‌سازی كند. همچنین محصول باید TLS را با پشتیبانی از مجموعه‌های رمز زیر پیاده‌سازی نماید.  در سیستم طراحی شده از رمز " TLS_ RSA_WITH_AES_256_GCM_SHA384 " نیز استفاده می گردد ﻣﺠﻤﻮﻋﻪ رﻣﺰ ﻣﻮرد اﺳﺘﻔﺎده و پیاده‌سازی ﺷﺪه ﻣﺤﺼﻮل، اﻧﺘﺨﺎب ﮔﺮدد. TLS_RSA_WITH_AES_256_CBC_SHA مطابق با RFC 3268  TLS_DHE_RSA_WITH_AES_128_CBC_SHA مطابق با RFC 3268  TLS_DHE_RSA_WITH_AES_256_CBC_SHA مطابق با RFC 3268  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA مطابق با RFC 4492  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA مطابق با RFC 4492  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA مطابق با RFC 4492  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA مطابق با RFC 4492  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA مطابق با RFC 4492  TLS_RSA_WITH_AES_128_CBC_SHA256 مطابق با RFC 5246  TLS_RSA_WITH_AES_256_CBC_SHA256 مطابق با RFC 5246  TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 مطابق با RFC 5246  TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 مطابق با RFC 5246  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 مطابق با RFC 5289  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 مطابق با RFC 5289  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 مطابق با RFC 5289  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 مطابق با RFC 5289  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 مطابق با RFC 5289  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 مطابق با RFC 5289  2 محصول باید اتصال‌های كاربرانی كه درخواست SSL1.0، SSL2.0، SSL3.0، TLS1.0 و TLS1.1 دارند را رد نماید.  3 محصول باید پارامترهای ساخت كلید را بر اساس موارد زیر ایجاد نماید.  ساخت کلید با استفاده RSA با طول کلید 2048 انجام می گردد و پارامترهای ECDH با استفاده از NIST Curve هایprime256v1 و secp384r1 و x25519 تعیین می گردند در صورت پشتیبانی از اقدامات دیگر، در «سایر موارد» بیان گردد. استفاده از RSA با اندازه کلید 2048 یا 3072 یا 4096 بیت  پارامترهای ECDH با استفاده را NIST Curveهای secp256r1 یا secp384r1 یا secp521r1 و هیچ مورد دیگری  پارامترهای دیفی-هلمن با اندازه کلید 2048 یا 3072 بیت    3-4- پروتکل TLS مشترک کلاینت و سرور لازم به ذكر است كه الزاماتی كه با عنوان پروتكل‌های TLS Server و TLS Client مطرح شده است، برای مباحث مرتبط به احراز هویت TLS Server و TLS Client نیز مطرح می‌گردد. در این بخش چند الزام كه برای احراز هویت این پروتكل‌ها مطرح می‌گردد و برای هر دوی كلاینت و سرور نیز یكسان است و باید برای هر كدام مورد بررسی قرار گیرد، آورده شده است. شماره الزام پروتکل TLS مشترک کلاینت و سرور توضیحات 1 محصول باید احراز هویت دوطرفه كلاینت‌ها/سرورهای TLS را با استفاده از گواهی‌نامه‌های X509v3 پشتیبانی نماید.  2 محصول در صورت مطابقت نداشتن نام متمایز یا نام دیگر فاعل موجود در گواهی‌نامه، با آنچه از شناساننده كلاینت مورد انتظار بوده است، نباید كانال امن را برقرار سازد.    3-5- اعتبارسنجی گواهی‌نامه شماره الزام اعتبارسنجی گواهی‌نامه توضیحات 1 محصول باید گواهی‌نامه‌ها را بر اساس قوانین زیر تأیید كند.  تأیید گواهی‌نامه RFC 5280 و تأیید مسیر گواهی‌نامه که از حداقل طول مسیر دو گواهی‌نامه پشتیبانی می‌کند.  مسیر گواهی‌نامه باید با یک گواهی‌نامه CA امن پایان یابد.  محصول باید برای تأیید مسیر یک گواهی‌نامه، اطمینان حاصل نماید که افزونه basicConstraints وجود دارد و پرچم CA برای تمام گواهی‌نامه‌های CA به حالت «TRUE» تنظیم شده است.  روش‌های تأیید وضعیت فسخ گواهی‌نامه پروتکل وضعیت گواهی‌نامه آنلاین (OCSP) مشخص‌شده در RFC 696  لیست فسخ گواهی‌نامه (CRL) مشخص شده در RFC 5280 بخش 6.3  لیست فسخ گواهی‌نامه (CRL) مشخص شده در RFC 5759 بخش 5  هیچ روش فسخ دیگری  قوانین تأیید فیلد extendedKeyUsage گواهی‌نامه‌های مورد استفاده برای تأیید بروزرسانی‌های امن و اعتبارسنجی صحت کدهای اجرایی باید هدف «Code Signing» (id-kp3 با OID 1.3.6.1.5.5.7.3.1) را در فیلد extendedKeyUsage خود داشته باشند.  گواهی‌نامه‌های سرور ارائه شده برای TLS باید هدف «Server Authentication» (id-kp1 با OID 1.3.6.1.5.5.7.3.1) را در فیلد extendedKeyUsage خود داشته باشند.  گواهی‌نامه‌های کلاینت ارائه شده برای TLS باید هدف «Client Authentication» (id-kp1 با OID 1.3.6.1.5.5.7.3.2) را در فیلد extendedKeyUsage خود داشته باشند.  گواهی‌نامه‌های OCSP مورد استفاده برای پاسخ OCSP باید «OCSP Signing» (id-pk9 با OID 1.3.6.1.5.5.7.3.9) را در فیلد extendedKeyUsage خود داشته باشند.  2 محصول باید تنها در صورتی که افزونه مربوط به basicConstraints از پیش تنظیم شده باشد و همچنین، پرچم CA به حالت «TRUE» تنظیم شده باشد، یک گواهی‌نامه را به عنوان گواهی‌نامه CA بپذیرد.  3 محصول باید جهت پشتیبانی احراز هویت برای موارد زیر از گواهی‌نامه‌های X509v3 تعریف‌شده در RFC 5280 استفاده کند.  در صورت پشتیبانی از كاركردهای دیگر، در «سایر موارد» بیان گردد. HTTPS  TLS  امضای كد برای بروزرسانی‌های نرم‌افزار سیستم  امضای كد برای تأیید یكپارچگی  سایر موارد    3-6- پروتکل SSH شماره الزام پروتکل SSH توضیحات 1 محصول باید پروتكل SSH را مطابق با RFCهای 4251، 4252، 4253، 4254، 5656 و 6668 پیاده‌سازی نماید.  2 محصول باید در پیاده‌سازی پروتکل SSH مطابق RFC 4252، از روش‌های احراز هویت زیر پشتیبانی نماید.  احراز هویت مبتنی بر کلید عمومی  احراز هویت مبتنی بر گذرواژه  3 محصول باید در پیاده‌سازی پروتکل SSH مطابق RFC 4253، بسته‌های بزرگتر از مقدار مشخصی (در بخش «توضیحات» ذکر شود) را کنار بگذارد.  4 محصول باید در پیاده‌سازی پروتکل SSH تنها از الگوریتم‌های رمزنگاری زیر استفاده نماید.  AES128-CBC  AES192-CBC  AES256-CBC  AES128-CTR  AES192-CTR  AES256-CTR  AEAD_AES_128_GCM  AEAD_AES_256_GCM  5 محصول باید در پیاده‌سازی پروتکل انتقال SSH تنها از الگوریتم‌های کلید عمومی زیر استفاده نماید.  ssh-rsa  ssh-ed25519  ssh-ed448  rsa-sha2-512  rsa-sha2-256  ecdsa-sha2-nistp521  ecdsa-sha2-nistp384  ecdsa-sha2-nistp256  x509v3-ecdsa-sha2-nistp521  x509v3-ecdsa-sha2-nistp384  x509v3-ecdsa-sha2-nistp256  x509v3-rsa2048-sha256  x509v3-ssh-rsa  6 محصول باید در پیاده‌سازی پروتکل انتقال SSH تنها از الگوریتم‌های MAC صحت داده‌های زیر استفاده نماید.  AEAD_AES_256_GCM  AEAD_AES_128_GCM  hmac-sha2-512  hmac-sha2-256  hmac-sha1-96  7 محصول باید در پیاده‌سازی پروتکل SSH تنها از الگوریتم‌های تبادل کلید زیر استفاده نماید.  curve25519-sha256  curve448-sha512  diffie-hellman-group-exchange-sha256  diffie-hellman-group-exchange-sha1  diffie-hellman-group18-sha512  diffie-hellman-group17-sha512  diffie-hellman-group16-sha512  diffie-hellman-group15-sha512  ecdh-sha2-nistp521  ecdh-sha2-nistp384  ecdh-sha2-nistp256  rsa2048-sha256  diffie-hellman-group14-sha256  8 محصول باید اطمینان پیدا کند که در یک ارتباط SSH،کلیدهای نشست یکسانی برای حد آستانه؛ طول نشست بیشتر از یک ساعت نباشد و حجم داده مخابره شده بیشتر از 1 گیگابایت نباشد، استفاده می‌گردد. در صورت پر شدن حد آستانه هر کدام از موارد ذکر شده، مجددسازی کلید باید صورت بگیرد.  9 محصول باید اطمینان حاصل نماید که کلاینت SSH، سرور SSH را احراز هویت می‌کند. سرور SSH از یک پایگاه داده محلی که نام هر میزبان را با کلید عمومی متناظر آن (تشریح‌شده در RFC 4251 بخش ۷.1) همراه می‌کند، استفاده می‌نماید. 