مدت زمان تقریبی مطالعه: 2
17 آبان 1405
الزامات امنیتی افتا در نرم‌افزارهای دولتی؛ چک‌لیست فنی آزمون نفوذ و پایداری
چند ماه پس از برگزاری مناقصه و صرف صدها ساعت جلسه‌ی تحلیل، سامانه‌ی جدید آماده‌ی استقرار در دیتاسنتر سازمان می‌شود؛ اما درست در نقطه‌ی تحویل، سد محکمی به نام «مجوز امنیتی افتا» پروژه را متوقف می‌کند. کارشناسان حراست فناوری اطلاعات و پدافند غیرعامل، به دلیل وجود آسیب‌پذیری‌های پایه در معماری کد یا اتکای سامانه به سرویس‌های ناشناخته‌ی خارجی، اجازه‌ی اتصال سامانه به شبکه‌ی داخلی را نمی‌دهند. این سناریو، کابوس مشترک ده‌ها سازمان دولتی و نهاد زیرساختی در سال‌های اخیر است.
مجوز امنیتی افتا (امنیت فضای تبادل اطلاعات) که زیر نظر مرکز مدیریت راهبردی افتای ریاست جمهوری صادر می‌شود، مدت‌هاست از یک توصیه‌ی فنی به یک «خط قرمز قانونی» تبدیل شده است. طبق اسناد بالادستی، هیچ ارگان دولتی، وزارتخانه یا زیرساخت حیاتی کشور اجازه‌ی بهره‌برداری از سامانه‌ای را ندارد که فرایند ارزیابی امنیتی افتا را با موفقیت پشت سر نگذاشته باشد. با وجود این، بسیاری از اسناد مناقصه و پروژه‌ها هنوز بدون در نظر گرفتن این الزامات بسته می‌شوند و نتیجه، اتلاف میلیاردها تومان بودجه و پروژه‌های ناتمامی است که هرگز رنگ افتتاح به خود نمی‌بینند.
چرا آزمون‌های نفوذ سنتی برای دریافت تأییدیه افتا کافی نیستند؟
یک تصور اشتباه رایج میان کارفرمایان این است که اسکن خودکار سامانه با چند ابزار مشهور مانند OWASP ZAP یا Acunetix و ارائه‌ی گزارش سبز آن‌ها، به معنای امنیت نرم‌افزار است. ارزیابان مرکز افتا، تست نفوذ را در لایه‌هایی بسیار عمیق‌تر از اسکنرهای خودکار اجرا می‌کنند:
- تحلیل ایستای کد (SAST): بررسی سطر به سطر سورس‌کد برای کشف خطاهای منطقی، متغیرهای سخت‌کدشده (Hardcoded Secrets)، توابع منسوخ و شیوه‌ی مدیریت حافظه.
- بررسی پکیج‌ها و وابستگی‌ها (Software Bill of Materials – SBOM): رصد دقیق تک‌تک کتابخانه‌ها و پکیج‌های متن‌باز مورد استفاده در پروژه برای اطمینان از نبود درهای پشتی (Backdoors) و آسیب‌پذیری‌های ثبت‌شده در پایگاه داده‌ی ملی و بین‌المللی CVE.
- آزمون پویای نفوذ (DAST): شبیه‌سازی حملات هدفمند سناریومحور علیه منطق تجاری (Business Logic Flaws) سامانه؛ خطاهایی که هیچ اسکنر ماشینی قادر به درک آن‌ها نیست.
چک‌لیست ۱۰ گانه‌ی الزامات امنیتی افتا پیش از استقرار سامانه
اگر مدیریت یا نظارت بر پروژه‌ی یک سامانه‌ی دولتی یا زیرساختی را بر عهده دارید، پیش از رسیدن به مرحله‌ی ممیزی نهایی، رعایت این ۱۰ اصل در معماری فنی را از پیمانکار مطالبه کنید:
| ردیف | حوزه ارزیابی | الزام فنی مشخص بر اساس استانداردهای افتا |
|---|---|---|
| ۱ | احراز هویت و دسترسی | اجبار احراز هویت دومرحله‌ای (2FA/MFA)، اتصال به سامانه‌های دایرکتوری سازمانی (LDAP/AD) و تعریف دسترسی بر پایه نقش (RBAC). |
| ۲ | رمزنگاری داده‌ها در سکون | رمزنگاری فیلدهای حساس دیتابیس (اسناد شناسایی، کلمات عبور، شماره حساب‌ها) با الگوریتم‌های استاندارد نظیر AES-256. |
| ۳ | رمزنگاری ترافیک در حال تبادل | برقراری ارتباطات بر بستر TLS 1.3 با Cipher Suiteهای ایمن و غیرفعال‌سازی پروتکل‌های قدیمی SSL و TLS 1.0/1.1. |
| ۴ | مدیریت نشست‌های کاربری (Session) | انقضای خودکار نشست‌ها در زمان عدم فعالیت، تولید شناسه‌های غیرقابل حدس و محافظت کوکی‌ها با پرچم‌های Secure، HttpOnly و SameSite. |
| ۵ | ثبت و ممیزی لاگ‌ها (Audit Trail) | ثبت وقایع حیاتی سیستم (ورود ناموفق، ویرایش داده، تغییر سطح دسترسی) همراه با زمان دقیق، IP، شناسه‌ی کاربر و تضمین عدم دستکاری لاگ‌ها. |
| ۶ | اعتبارسنجی ورودی‌ها (Sanitization) | فیلتر دقیق کاراکترهای مخرب در لایه‌ی سرور برای خنثی‌سازی حملات تزریق SQL (SQLi) و اسکریپت‌نویسی بین‌سایتی (XSS). |
| ۷ | امنیت رابط‌های برنامه‌نویسی (API) | پیاده‌سازی محدودیت نرخ درخواست (Rate Limiting) برای جلوگیری از حملات DoS/DDoS و اعتبارسنجی تمام توکن‌ها (JWT) در هر فراخوانی. |
| ۸ | مدیریت فایل‌های بارگذاری‌شده | ذخیره‌سازی فایل‌های آپلودی بیرون از مسیر اجرای وب‌سرور، اسکن ضدبدافزار فایل‌ها و بررسی فرمت فایل از طریق Magic Bytes (نه صرفاً پسوند). |
| ۹ | استقرار ۱۰۰٪ درون‌سازمانی (On-Premises) | عدم اتصال سامانه به سرورها یا اسکریپت‌های CDN خارجی (نظیر کتابخانه‌های فونت یا اسکریپت‌های تحلیلی گوگل). |
| ۱۰ | عدم وابستگی به لایسنس خارجی | هسته‌ی سامانه نباید به سرورهای فعال‌سازی لایسنس در خارج از کشور وابسته باشد که با بروز تحریم از کار بیفتد. |
استقرار درون‌سازمانی (On-Premises)؛ ستون فقرات امنیت داده‌های ملی
در سال‌های اخیر، موج حرکت به سمت زیرساخت‌های ابری (Cloud) در جهان سرعت گرفته است؛ اما برای صنایع مادر، شرکت‌های انرژی و سازمان‌های دولتی ایران، استقرار درون‌سازمانی یک ضرورت پدافندی اجتناب‌ناپذیر است.
هنگامی که سامانه‌ای در بستر شبکه‌ی محلی و دیتاسنتر اختصاصی سازمان مستقر می‌شود، حتی در شرایط قطع سراسری اینترنت بین‌الملل، چرخه‌ی فرآیندهای عملیاتی سازمان متوقف نخواهد شد. نرم‌افزاری که با استاندارد افتا تولید می‌شود، نیازمند معماری ایزوله‌ای است که تمام وابستگی‌ها، کش‌ها، موتورهای جستجو و پایگاه‌های داده را بدون تبادل بسته با خارج از مرزهای شبکه مدیریت کند.
چگونه الزامات افتا را در اسناد مناقصه (RFP) بگنجانیم؟
بزرگ‌ترین خطای کارفرما این است که در اسناد مناقصه صرفاً می‌نویسد: «پیمانکار موظف به رعایت استانداردهای امنیتی است». این عبارت کلی هیچ ضمانت اجرایی برای شما خلق نمی‌کند. به جای آن، بندهای زیر را مستقیماً در قرارداد بیاورید:
- شرط پرداخت حسن انجام کار: آزادسازی آخرین مرحله‌ی پرداخت قرارداد (حداقل ۲۰ تا ۳۰ درصد مبلغ کل)، منوط به اخذ تأییدیه‌ی رسمی افتا از مرجع ذی‌صلاح توسط پیمانکار خواهد بود.
- هزینه‌ی رفع آسیب‌پذیری‌ها: در صورتی که مرکز افتا در گزارش ممیزی خود آسیب‌پذیری‌هایی را ثبت کند، کلیه‌ی هزینه‌های اصلاح معماری و بازتولید بخش‌های ناامن تا تأیید نهایی بر عهده‌ی پیمانکار است.
- ارائه‌ی گواهی محصول: اولویت در مناقصه باید به شرکت‌های نرم‌افزاری داده شود که خود پیش از این گواهینامه‌ی رسمی افتا را برای محصولات سازمانی یا خدمات نرم‌افزاری خود دریافت کرده‌اند.
همراهی نادین‌سافت در پیاده‌سازی سامانه‌های سازمانی منطبق بر افتا
شرکت دانش‌بنیان نادین‌سافت با برخورداری از گواهینامه رسمی امنیتی افتا از مرکز مدیریت راهبردی افتای ریاست جمهوری و کارنامه‌ی پیاده‌سازی سامانه‌های پرتراکنش در نهادهای زیرساختی، کلیه‌ی سامانه‌های نرم‌افزاری سفارشی و پلتفرم‌های BPMS خود را منطبق بر سخت‌گیرانه‌ترین چک‌لیست‌های امنیتی ملی مستقر می‌کند.
