افتا چیست؟
افتا مخفف امنیت فضای تولید و تبادل اطلاعات است. گواهینامه افتا تاییدیه امنیتی است که توسط مرکز مدیریت راهبردی افتای ریاست جمهوری صادر شده و سلامت فنی و امنیتی نرمافزارها را برای استفاده در زیرساختهای حیاتی تضمین میکند.در واقع، نرمافزاری که گواهینامه افتا دارد، از فیلتر تستهای نفوذ، و ارزیابیهای فنی عبور کرده تا امنیت زیرساختهای حیاتی کشور دچار تهدید نشود.
آشنایی با مرکز مدیریت راهبردی افتای ریاست جمهوری
مرکز مدیریت راهبردی افتا، بازوی حاکمیتی ایران در حوزه امنیت فضای تولید و تبادل اطلاعات است که با هدف صیانت از زیرساختهای حیاتی کشور در برابر تهدیدات سایبری فعالیت میکند. این مرکز وظیفه دارد با تدوین استانداردهای دقیق، نظارت بر اجرای سیاستهای امنیتی و ارزیابی فنی محصولات، از داراییهای اطلاعاتی سازمانهای دولتی و نهادهای حساس محافظت کند.
در سالهای اخیر، مرکز افتا به عنوان تنها مرجع تایید صلاحیت برای نرمافزارهای سازمانی شناخته میشود. دریافت گواهینامه از این مرکز به معنای آن است که محصول مورد نظر مانند راهکار دانا 360 تمامی آزمونهای سختگیرانه تست نفوذ و بازبینی کد را با موفقیت پشت سر گذاشته و برای استفاده در لایههای حساس مدیریتی و خدماتی کشور کاملاً امن است.
چرا گواهینامه افتا برای نرمافزارها اینقدر مهم است و سازمانها روی داشتن آن حساسیت دارند؟
مرکز افتا عملاً تبدیل به مرجع رسمیِ ارزیابی و استعلام مجوزهای امنیتی در کشور شده و برای بسیاری از سازمانها خصوصاً سازمانهای دولتی، حاکمیتی و حساس یک شرط کلیدیِ انتخاب و پذیرش محصول است.
دلایل اصلی اهمیت افتا:
- اعتبار رسمی و قابل استعلام: نشان میدهد محصول از یک فرآیند ارزیابی مشخص عبور کرده و ادعای امنیت صرفاً تبلیغاتی نیست.
- پذیرش سازمانی و تسهیل خرید: در خیلی از سازمانها، داشتن افتا باعث میشود فرآیند تأیید امنیتی، خرید و استقرار سریعتر و کمحاشیهتر جلو برود.
- کاهش ریسک و افزایش اعتماد: برای مدیران، وجود یک استاندارد/مرجع ارزیابی به معنای کاهش ریسکهای حقوقی، امنیتی و عملیاتی است.
- مزیت رقابتی در بازار سازمانی: محصولی که افتا دارد معمولاً در رقابت با گزینههای فاقد گواهی، شانس بالاتری برای انتخاب شدن دارد.
- نقطه شروع جدی برای امنیت: داشتن افتا یعنی «حداقلهای مهم امنیتی» رعایت شده، اما هنوز نیاز به استقرار امن و نگهداری درست وجود دارد.
در سال 1405 کدام دسته از نرم افزارها به گواهینامه افتا نیاز دارند؟
بهطور کلی، افتا وقتی مهم میشود که یک نرمافزار یا خدمت مستقیماً روی امنیت اطلاعات سازمان اثر بگذارد یا در محیطهایی مثل دولت، زیرساختهای حیاتی و سازمانهای حساس به کار گرفته شود. هر سامانهای که با دادههای حساس کاربران، کنترل دسترسی کاربران ، دادههای محرمانه، گزارشها و رویدادهای امنیتی یا زیرساختهای فناوری اطلاعات درگیر باشد، معمولاً در مناقصهها و ممیزیها با درخواست افتا مواجه میشود. برای نمونه:
- سامانههای مدیریت خدمات فناوری اطلاعات (ITSM / Service Desk)
- درگاهها و سامانههای خدمات آنلاین سازمانی
- سامانههای مالی و عملیاتی حساس
- سامانههای آموزشی و مدیریت یادگیری
- سامانههای اداری و سرمایه انسانی
- سامانههای بهداشت و درمان و پروندههای سلامت
- راهکارهای امنیت و ارتباط امن
امنیت در لایههای مختلف محصولات مدیریت سازمانی (ITSM, ESM, CRM)
در سال ۱۴۰۵، دسته نرمافزارهای ITSM (مدیریت خدمات فناوری اطلاعات)، ESM (مدیریت خدمات سازمانی) و CRM (مدیریت ارتباط با مشتری) عملاً به ستون فقرات عملیاتی و اطلاعاتی سازمان تبدیل شدهاند. این سامانهها نه تنها حجم عظیمی از دادههای حساس را تجمیع میکنند، بلکه به دلیل گره خوردن با هویت و سطح دسترسی کاربران و همچنین یکپارچگی با دهها سامانه حیاتی دیگر، به هدف اصلی حملات سایبری تبدیل شدهاند.
چرا امنیت در ITSM مهم است؟
ITSM معمولاً با عملیات IT و کنترلهای اجرایی سرویسها گره میخورد و اگر دسترسیها یا ثبت رخدادها درست مدیریت نشود، میتواند به مسیر سوءاستفاده از اختیارات و ایجاد اختلال عملیاتی تبدیل شود. امنیت ITSM یعنی کنترل دقیق نقشها، شفافیت اقدامات و جلوگیری از تبدیل شدن سیستم به نقطه نفوذ.
چرا امنیت در ESM مهم است؟
ESM فرآیندهای خدماتی را به کل سازمان تعمیم میدهد و روی جریان تصمیمگیری و گردش کار بین واحدها اثر میگذارد. اینجا امنیت فقط حفاظت از داده نیست؛ حفاظت از صحت اجرای فرآیندها و جلوگیری از دستکاری یا دور زدن کنترلهای داخلی سازمان است.
چرا امنیت در CRM مهم است؟
CRM معمولاً «منبع حقیقت» درباره مشتریان و تعاملات بیرونی است و مستقیم به اعتبار برند و ریسکهای حقوقی/تجاری وصل میشود. امنیت CRM یعنی جلوگیری از دسترسی غیرمجاز و خروج اطلاعات، و تضمین اینکه دادههای حساس مشتریان فقط در اختیار افراد مجاز و در مسیرهای کنترلشده قرار میگیرد.
افتا دقیقاً چه چیزی را میسنجد؟
گواهینامه افتا صرفاً یک فرآیند اداری نیست و برای بسیاری از سازمانهای حساس، یک چارچوب ارزیابی و اعتبارسنجی است که نشان میدهد محصول، از منظر امنیتی مستندسازی شده، راستیآزمایی شده و آزمونهای لازم را پشت سر گذاشته است.
- تست نفوذ (Penetration Testing) و ارزیابی عملیاتی
محصول در برابر سناریوهای حمله و سوءاستفادههای رایج بررسی میشود تا نقاط ضعف اجرایی، سطح تابآوری و میزان مواجههپذیری آن مشخص شود.
- بررسی مستندات و الزامات فنی + راستیآزمایی شواهد
مواردی مثل مدل کنترل دسترسی، ثبت رخدادها و ممیزی، حفاظت از دادهها، نحوه بهروزرسانی و مدیریت آسیبپذیریها باید مستند باشد و تا حد امکان با شواهد قابل بررسی تأیید شود؛ یعنی نتیجهگیری بر پایه «مدرک» است نه صرفاً ادعا.
- توجه به ریسکهای مرجع در امنیت نرمافزار مانند چارچوب OWASP
- برای این نوع سامانههای سازمانی، پوشش ریسکهای رایج امنیت نرمافزارهای کاربردی خصوصاً در حوزههای وب و API اهمیت ویژهای دارد. چارچوب OWASP بهعنوان یکی از منابع مرجع، کمک میکند حداقلهای امنیتی و اولویتهای ریسک با زبان مشترک و قابل سنجش تعریف شود.
- انطباق با الزامات حاکمیتی و چارچوبهای ابلاغی
محصول باید با الزامات امنیتی تعریفشده برای محیطهای حساس همراستا باشد؛ موضوعی که در پروژههای دولتی و زیرساختی، معمولاً یک معیار کلیدی برای پذیرش و خرید محسوب میشود.
زمانبندی اخذ گواهینامه افتا: چرا باید حداقل ۴ ماه زودتر اقدام کنید
فرآیند اخذ افتا معمولاً زمانبر است؛ در حالت خوشبینانه حداقل حدود ۳ ماه طول میکشد، اما با توجه به شرایط محصول و رفتوبرگشتهای اصلاحی، ممکن است بیشتر هم شود. برای اخذ گواهی جدید یا تمدید، بهتر است حداقل ۴ ماه زودتر شروع کنید.
| مرحله | چرا زمان میبرد؟ | زمان تقریبی | نکته مهم |
|---|---|---|---|
| مرحله ۱ ثبت درخواست |
آمادهسازی اطلاعات اولیه و تکمیل مراحل شروع | ۳–۷ روز | هر نقص اطلاعاتی باعث رفتوبرگشت میشود |
| مرحله ۲ انتخاب آزمایشگاه |
هماهنگیها، توافق مالی و برنامهریزی ارزیابی | ۱–۳ هفته | هر آزمایشگاه صف متفاوتی دارد |
| مرحله ۳ تکمیل مستندات |
جمعآوری شواهد فنی و الزامات امنیتی | ۲–۶ هفته | معمولاً طولانیترین مرحله است |
| مرحله ۴ نسخه ارزیابی |
پیکربندی محیط و آمادهسازی بسته تحویل | ۱–۲ هفته | تنظیمات امنیتی حیاتی هستند |
| مرحله ۵ اجرای آزمونها |
اجرای تستها و تهیه گزارش | ۴–۸ هفته | اغلب بیش از یک ماه طول میکشد |
| مرحله ۶ اصلاحات |
رفع عدم انطباقها و آزمون مجدد | ۲–۶ هفته | تقریباً همیشه رخ میدهد |
| مرحله ۷ نظر نهایی |
جمعبندی پرونده و صدور نتیجه | ≈۴ هفته | ممکن است طولانیتر شود |
اگر همهچیز خوب پیش برود، ممکن است حوالی ۳ ماه جمع شود؛ اما در سناریوی معمول، بازه ۴ تا ۶ ماه واقعبینانهتر است پس برنامهریزی را زودتر شروع کنید.
خطای رایج در سازمانها: تکیه کامل به گواهینامه افتا
گواهینامه افتا یک الزام مهم و یک نشانه مثبت از رعایت الزامات امنیتی است، اما بهتنهایی تضمینکننده امنیت عملیاتی نرمافزار نیست. امنیت واقعی در محیط اجرا شکل میگیرد و به عوامل متعددی وابسته است بهخصوص به نحوه استقرار و مدیریت توسط ادمین.
عوامل کلیدی موثر بر امنیت (در محیط عملیاتی):
- پیکربندی امن خود نرمافزار (Hardening): تنظیم نقشها و دسترسیها، سیاستهای رمز عبور، MFA/2FA، محدودیت IP، تنظیمات نشستها (Session)، لاگبرداری و هشدارها، غیرفعالسازی قابلیتهای غیرضروری.
- پیکربندی امن سیستمعامل و سرور/محیط اجرایی: بهروزرسانی منظم (Patch Management)، بستن پورتهای اضافی، محدود کردن سرویسهای غیرضروری، تنظیمات امن IIS/Apache/Nginx، مجوزهای فایلها و سرویسها.
- امنیت شبکه و معماری استقرار: تفکیک شبکه (Segmentation)، DMZ، محدودسازی دسترسی به دیتابیس، اصل حداقل دسترسی بین سرویسها، دسترسی امن راه دور (VPN/Zero Trust).
- استفاده از تجهیزات و لایههای امنیتی تکمیلی:
- Firewall برای کنترل ترافیک و سیاستهای دسترسی
- WAF برای مقابله با حملات لایه وب (مثل SQLi/XSS و …)
- IDS/IPS یا سامانههای تشخیص/جلوگیری نفوذ
- SIEM/Log Management برای تجمیع لاگها و کشف رفتار مشکوک
- مدیریت هویت و دسترسیها (IAM): تعریف نقشها، حذف دسترسیهای اضافی، کنترل دسترسی ادمینها، مدیریت حسابهای مشترک، MFA برای حسابهای حساس.
- امنیت داده و دیتابیس: رمزنگاری در انتقال (TLS) و در صورت نیاز در حالت ذخیره، مدیریت کلیدها، کنترل سطح دسترسی DB، جلوگیری از دسترسی مستقیم از اینترنت، مانیتورینگ Queryهای مشکوک.
- فرآیندهای عملیاتی و نگهداری: مدیریت وصلهها، کنترل تغییرات (Change Management)، تهیه بکاپ امن و تست بازیابی (DR)، اسکنهای دورهای آسیبپذیری، تست نفوذ دورهای.
- امنیت سمت کاربر و سیاستهای سازمانی: آموزش کاربران، جلوگیری از فیشینگ، سیاست دستگاههای مجاز، کنترل افزونهها/مرورگرها، مدیریت رخداد و پاسخگویی به حادثه.
تجربه مدیرعامل دانا پرداز برای شما که میخواهید برای گواهینامه افتا اقدام کنید
اگر بخواهم خیلی صادقانه بگویم، گرفتن گواهینامه افتا برای یک محصول نرمافزاری کار سادهای نیست بهخصوص اگر بار اولتان باشد.
من بهعنوان مدیرعامل شرکت دانا پرداز، این مسیر را چند بار تجربه کردهام؛ محصول «دانا» از اولین نرمافزارهایی بود که در سال ۱۳۹۸ گواهینامه افتا گرفت و بعد از آن هم چند دوره بهصورت متوالی تمدید شد. اگر شما هم میخواهید وارد این مسیر شوید، این چند نکته را جدی بگیرید:
- مستندسازی، مخصوصاً سند الزامات امنیتی، معمولاً زمانبرترین بخش کار است.
اگر قبلاً این کار را انجام نداده باشید، خیلی احتمال دارد برای تکمیل درست سندها به یک مشاور امنیت (ترجیحاً کسی که تجربه افتا داشته باشد) نیاز پیدا کنید. - هر چیزی که در سند الزامات امنیتی مینویسید باید قابل آزمون و راستیآزمایی باشد.
یعنی صرفاً «نوشتن» کافی نیست؛ باید بتوانید نشان بدهید آن ادعا در محصول واقعاً اجرا شده و قابل بررسی است. پس نوشتن این سند را سرسری نگیرید. - آزمایشگاهها هم از نظر هزینه متفاوتاند و هم معمولاً شلوغ.
چون تعداد آزمایشگاههای مجاز محدود است، ممکن است در صف ارزیابی بمانید. قبل از قرارداد، روی هزینه، زمانبندی و شرایط رفتوبرگشتها شفاف مذاکره کنید تا وسط راه غافلگیر نشوید. - واقعبین باشید: معمولاً با یک بار آزمون کار تمام نمیشود.
من بعید میدانم محصولی بدون اصلاح و آزمون مجدد، در همان نوبت اول همه موارد را پاس کند. پس از همان ابتدا در برنامه زمان و هزینه، روی حداقل یک دور تستِ مجدد حساب کنید جدی میگویم. - سختگیریها در سالهای اخیر بیشتر شده و پروفایلهای امنیتی پیچیدهتر شدهاند.
پیشنهاد من این است که افتا را یک «پروژه مهم» ببینید، نه یک کار حاشیهای کنار اسپرینتهای جاری توسعه. اگر منابع کافی (زمان، نفر، تمرکز) نگذارید، هم فرسایشی میشود هم هزینهاش بالا میرود.
چکلیست کامل امنیت عملیاتی برای ادمینها (۱۴۰۵)
حتی اگر نرمافزار گواهی «افتا» داشته باشد، امنیت واقعی در محیط اجرا به پیکربندی، شبکه، مانیتورینگ و عملیات درست وابسته است. این چکلیست کمک میکند قبل از شروع کار و در طول بهرهبرداری، ریسک نفوذ، نشت داده و اختلال سرویس را به حداقل برسانید.
قبل از راهاندازی نهایی (Go-Live) و آمادهسازی زیرساخت
☐ معماری استقرار را درست طراحی کنید: اپلیکیشن و دیتابیس در شبکههای جدا (Segmentation) باشند.
☐ دیتابیس مستقیم از اینترنت قابل دسترس نباشد (هیچ Port عمومی برای DB).
☐ اگر سرویس اینترنتی است، DMZ برای لایه وب در نظر بگیرید و مسیرهای ارتباطی بین لایهها را محدود کنید.
☐ ارتباط بین سرویسها بر اساس اصل حداقل دسترسی باشد (فقط پورت لازم، فقط IP لازم).
☐ اکانتهای سرویس (Service Account) جدا، با حداقل سطح دسترسی و بدون Interactive Logon باشند.
☐ ارتباطات را رمزنگاری کنید: TLS فعال و اجباری (فقط HTTPS).
☐ گواهی SSL معتبر داشته باشید و پروتکلها/Cipherهای ضعیف را طبق سیاست سازمان حذف کنید.
☐ وبسرور را سختسازی (Hardening) کنید (IIS/NGINX/Apache): ماژولهای اضافی خاموش، Headerهای افشاگر محدود، محدودیت اندازه درخواستها، کنترل Upload.
☐ Patch Management: سیستمعامل، وبسرور، دیتابیس، Runtime و کتابخانهها همگی بهروز باشند.
☐ ساعت سرورها NTP یکسان داشته باشد (برای تحلیل لاگ و رخداد حیاتی است).
پیکربندی امن داخل نرمافزار (Hardening در خود سیستم)
☐ برای ادمینها و نقشهای حساس، MFA/2FA را اجباری کنید (اختیاری نباشد).
☐ سیاست رمز عبور (Password Policy): طول مناسب، پیچیدگی، جلوگیری از رمز تکراری، انقضا (طبق سیاست سازمان).
☐ حسابهای پیشفرض را حذف/غیرفعال کنید یا نامشان را تغییر دهید و دسترسیشان را شدیداً محدود کنید.
☐ مدیریت نقشها (RBAC): تعداد «ادمین کل» را حداقل کنید.
☐ تفکیک وظایف (SoD): مدیر سیستم ≠ مدیر امنیت ≠ مدیر داده (تا جای ممکن).
☐ پنل ادمین را فقط از مسیرهای امن باز کنید: IP مشخص / VPN / شبکه داخلی.
☐ امنیت نشستها (Session Security): Timeout، محدودسازی نشست همزمان، خروج خودکار، Secure/HttpOnly Cookie.
☐ کنترل فایلها و ضمیمهها: محدودیت نوع/حجم، اسکن بدافزار، ذخیرهسازی امن، جلوگیری از اجرای مستقیم.
☐ ثبت رخداد و ممیزی (Audit Trail): ورود/خروج، تغییر نقشها، تغییر تنظیمات، حذف داده، خروجی گرفتن (Export) ثبت شود.
☐ اعلانهای امنیتی: هشدار برای ورود مشکوک، تلاش ناموفق زیاد، تغییر سطح دسترسی، عملیات حجیم/غیرعادی.
امنیت لبه اینترنت و شبکه (Perimeter)
☐ فایروال: فقط پورتهای ضروری باز باشد + قوانین دقیق Inbound/Outbound.
☐ برای سرویسهای وب/API (بهخصوص اینترنتی)، WAF فعال کنید.
☐ ضد حمله Brute-Force: Rate Limiting، قفل موقت حساب بعد از تلاش ناموفق، محدودسازی درخواستها.
☐ در صورت نیاز، IP Reputation / Geo-Blocking برای کاهش سطح حمله اعمال کنید.
☐ دسترسی ادمینها و تیم پشتیبانی از طریق VPN یا Zero-Trust Access باشد.
امنیت دیتابیس و حفاظت از دادهها
☐ دسترسی به دیتابیس فقط از لایه اپلیکیشن باشد (نه از کل شبکه).
☐ کاربر دیتابیس (DB User) با حداقل دسترسی لازم تعریف شود (از sa/sysadmin برای اپلیکیشن استفاده نشود).
☐ رمزنگاری داده در انتقال: TLS بین App و DB (در صورت امکان/سیاست سازمان).
☐ رمزنگاری داده در حالت ذخیره (در صورت نیاز): TDE/Encryption + مدیریت امن کلیدها.
☐ پایش رخدادهای حساس DB: Failed Login، تغییر سطح دسترسی، عملیات حجیم/مشکوک.
☐ سیاست نگهداری داده (Retention) و حذف امن (پاکسازی اصولی) مشخص باشد.
لاگ، مانیتورینگ و کشف رخداد (Detection)
☐ لاگها را متمرکز کنید (Log Management / SIEM اگر دارید).
☐ داشبورد امنیتی بسازید: ورود ناموفق، جهش خطاها، جهش ترافیک، تغییر نقشها، Exportهای زیاد.
☐ هشداردهی واقعی (Alerting): پیام/ایمیل/تیکت برای رخدادهای بحرانی (نه فقط ذخیرهسازی).
☐ یکپارچگی لاگها: جلوگیری از دستکاری آسان، دسترسی محدود، نگهداری مناسب.
بکاپ، بازیابی و تداوم کسبوکار (Backup & DR)
☐ بکاپ دورهای دیتابیس + تست بازیابی (Restore Test) طبق برنامه.
☐ بکاپ فایلها/ضمیمهها (File Repository) + کنترل نسخه و دسترسی.
☐ قانون 3-2-1: سه نسخه، دو رسانه متفاوت، یک نسخه خارج از سایت.
☐ سناریوی DR/Failover مشخص باشد و RPO/RTO تعریف شود.
☐ بکاپها رمزنگاری و ایزوله باشند (بکاپِ در دسترس باجافزار، بکاپ واقعی نیست).
عملیات امن و مدیریت تغییر (Run & Change)
☐ فرآیند Change Management: هر تغییر با تیکت، تایید، زمانبندی، برنامه Rollback.
☐ محیط Stage/Test قبل از Production داشته باشید.
☐ مدیریت آسیبپذیریها: اسکن دورهای، اولویتبندی، زمانبندی رفع.
☐ بهروزرسانی امن نرمافزار: منبع معتبر، کنترل checksum/امضا (در حد امکانات).
☐ دسترسی تیمها با اصل حداقل دسترسی: دسترسی مستقیم به سرور/DB فقط برای افراد ضروری و زماندار (Just-in-Time).
نقش ادمین و حاکمیت امنیت (Governance)
☐ مالک امنیت (Security Owner) مشخص باشد + مسئول پاسخگویی رخداد.
☐ اکانت ادمین جدا از اکانت روزمره باشد.
☐ MFA برای اکانتهای ادمین اجباری باشد.
☐ دسترسیهای ادمین ثبت و ممیزی شود (چه کسی، چرا، چه مدت).
☐ آموزش کوتاه کاربران: فیشینگ، رمز عبور، فایل مشکوک، گزارش رخداد.
☐ برنامه واکنش به رخداد (Incident Response Plan) آماده باشد: نقشها، قدمهای عملی، شماره تماسها + چکلیست اجرایی.
سوالات متداول
برای صدور و استعلام مجوزهای افتا در سال 1405 باید از کدام مرجع اقدام کنیم؟
بر اساس اطلاعیه رسمی منتشر شده در پنجشنبه ۸ آبان ۱۴۰۴، مرکز مدیریت راهبردی افتای ریاست جمهوری تنها مرجع صدور و استعلام مجوزهای افتا است و همچنین تمامی فرآیندهای ارزیابی امنیتی و اعتباربخشی محصولات و خدمات مؤثر بر امنیت فضای مجازی را انجام میدهد.
چگونه اعتبار و اصالت گواهی افتا را استعلام کنیم؟
از آبان ۱۴۰۴ و با تعیین «مرکز مدیریت راهبردی افتای ریاستجمهوری» بهعنوان مرجع رسمی صدور و استعلام مجوزهای افتا، بهترین روش برای بررسی اصالت و اعتبار یک گواهینامه افتا این است که وارد صفحه جستجو و استعلام گواهینامهها در وبسایت همین مرکز شوید و نام شرکت یا نام محصول را جستجو کنید.
اگر محصول مورد نظر در نتایج نمایش داده شد، میتوانید سطح ارزیابی و وضعیت گواهی را مشاهده کنید. در این بخش، وضعیت فعلی گواهی (مانند فعال، منقضی، تعلیق یا ابطال) بههمراه تاریخ دقیق اعتبار درج میشود و به شما کمک میکند با اطمینان، اعتبار گواهی را ارزیابی کنید.
در موارد خاص یا برای اطمینان نهایی در پروژههای حساس دولتی، سازمانها میتوانند به صورت کتبی از مرکز مدیریت راهبردی افتای ریاست جمهوری استعلام بگیرند.
نکته مهم: همیشه به تاریخ انقضا و دامنه کاربرد (Scope) گواهی دقت کنید. ممکن است یک محصول برای نسخه ۱.۰ گواهی داشته باشد اما نسخه مورد استفاده شما ۵.۰ باشد که در این صورت گواهی قبلی لزوماً تضمینکننده امنیت نسخه جدید نیست.
گواهینامه افتا برای محصولات نرمافزاری چه مدت اعتبار دارد؟
مدت اعتبار گواهینامه افتا معمولاً ۲ سال است؛ با این حال، بسته به نوع محصول و پروفایل/سطح ارزیابی ممکن است این مدت متفاوت باشد. برای اطلاع دقیق از تاریخ صدور و تاریخ انقضا، کافی است نام محصول یا شرکت را در بخش جستجو و استعلام وبسایت رسمی افتا جستجو کنید تا وضعیت گواهی و تاریخهای اعتبار بهصورت دقیق نمایش داده شود.
هزینه اخذ گواهینامه امنیتی افتا برای یک محصول نرمافزاری در سال ۱۴۰۵ چقدر است؟
متاسفانه در حال حاضر هیچ تعرفه و مرجع قیمت گذاری مشخصی برای این موضوع وجود ندارد. هزینهها معمولاً پروندهمحور هستند و به عواملی مثل نوع گواهی، پروفایل ارزیابی، دامنه و پیچیدگی محصول، سطح آزمونها (از جمله تست نفوذ)، و میزان اصلاحات و بازآزمایی بستگی دارد. در عمل هزینهها معمولاً از دو بخش تشکیل میشود:
- هزینههای ارزیابی و آزمون (آزمایشگاه/ارزیاب)
- هزینههای آمادهسازی، مستندسازی و رفع نواقص/بازآزمون
باید توجه داشته باشید که هزینه ارزیابی و آزمون دو آزمایشگاه مختلف ممکن است متفاوت باشد، و این شامل آزمون اولیه و یا آزمون های بعدی در صورت رد شدن در آزمون است! پس پیشنهاد می کنیم قبل از انتخاب آزمایشگاه حتما استعلام قیمت بگیرید.
چطور برای اخذ مجوز افتا درخواست دهیم و از کجا باید شروع کنیم؟
برای شروع فرآیند اخذ مجوز، ابتدا باید به وبسایت مرکز مدیریت راهبردی افتا مراجعه کنید و از بخش حوزه ارزیابی و اعتباربخشی، ابزار ثبت درخواست را دانلود نمایید. پس از استخراج فایل، باید برنامه را در یک رایانه ویندوزی متصل به اینترنت اجرا کرده و اطلاعات دقیقی شامل مشخصات شرکت، مدیرعامل، هیئتمدیره، سهامداران، کارشناسان و سوابق فعالیت را در بخشهای مربوطه تکمیل کنید. در نهایت، با کلیک بر روی دکمه ثبت درخواست، فرم نهایی را ارسال کرده و کد رهگیری نمایش داده شده را دریافت نمایید.
در گام آخر، برای رسمیسازی و شروع فرآیند ارزیابی فنی، لازم است کد رهگیری خود را طی یک نامه رسمی به دبیرخانه مرکز مدیریت راهبردی افتای ریاست جمهوری ارسال کنید. این نامه باید خطاب به «اداره صدور مجوزهای افتا» بوده و موضوع آن «درخواست اخذ مجوز افتا» قید شود