۱. اصول معماری امنیتی
- کمترین سطح دسترسی: هر کاربر و کلید فقط به قابلیتهای لازم دسترسی دارد.
- عدم اعتماد پیشفرض: درخواستها، ورودیها و مقصدهای خروجی باید اعتبارسنجی شوند.
- تفکیک وظایف: تحلیل، بازبینی، تأیید و اقدام میتوانند میان نقشهای متفاوت تقسیم شوند.
- قابلیت ممیزی: عملیات مهم باید با زمان، عامل، سازمان و شناسه درخواست قابل پیگیری باشند.
- شکست ایمن: در نبود پیششرط امنیتی، عملیات حساس متوقف شود؛ نه اینکه از مسیر ناامن ادامه یابد.
۲. کنترلهای اصلی
هویت و نشست
MFA مبتنی بر TOTP، کوکی HttpOnly، کنترل CSRF، ابطال نشست و محدودسازی تلاش ورود.
دسترسی نقشبنیان
نقشهای سازمانی، مجوزهای سفارشی، اصل حداقل دسترسی و کنترل عملیات حساس.
حفاظت از اسرار
رمزنگاری توکنها و کلیدهای اتصال، عدم نمایش دوباره کلیدهای حساس و جداسازی پیکربندی محرمانه.
پایش و ممیزی
Audit Log، Request ID، ثبت رویدادهای امنیتی و امکان بررسی تغییرات و اقدامات مدیریتی.
کنترل خروجی شبکه
Gateway مدیریتشده، حالت Fail-Closed و محدودکردن ارتباطات رسمی به مقصدهای موردنیاز.
داده و مهاجرت
تفکیک سازمانی در سطح برنامه، مهاجرت کنترلشده دیتابیس و پشتیبانگیری متناسب با استقرار.
۳. هویت، نشست و مجوزها
گذرواژهها با الگوریتم مقاوم در برابر حمله آفلاین ذخیره میشوند و ورود میتواند با MFA تکمیل شود. نشستها قابل مشاهده و ابطالاند. کوکی نشست باید با ویژگیهای HttpOnly، Secure و SameSite مناسب منتشر شود. عملیات مدیریتی و تغییرات حساس تنها برای نقش یا مجوز صریح در دسترساند.
۴. حفاظت از داده و اسرار
توکنهای OAuth، کلیدهای سرویس و مقادیر محرمانه نباید بهصورت متن آشکار در خروجی API یا رابط کاربری نمایش داده شوند. رمزنگاری در حالت ذخیره، TLS در مسیر انتقال، محدودیت دسترسی دیتابیس و مدیریت امن نسخه پشتیبان باید همزمان اجرا شوند. کلید رمزنگاری اصلی باید پایدار، خارج از کد و با دسترسی محدود نگهداری شود.
۵. شبکه، Webhook و خروجی Fail-Closed
برای ارتباط با سرویسهای رسمی میتوان Gateway مشخص و کنترلشده تعریف کرد. در حالت Fail-Closed، نبود Gateway معتبر باعث توقف درخواست میشود و سامانه به خروج مستقیم از IP سرور بازنمیگردد. امضای Webhook، دامنه مقصد، پروتکل و پاسخ سرویس خارجی باید بررسی شوند تا ریسک جعل درخواست و SSRF کاهش یابد.
۶. امنیت برنامه و مرورگر
- اعتبارسنجی نوع، طول و ساختار ورودیها و محدودکردن اندازه درخواست.
- هدرهای امنیتی مانند CSP، HSTS، X-Content-Type-Options و Referrer-Policy.
- محافظت CSRF برای درخواستهای دارای نشست و محدودسازی نرخ برای ورود و API عمومی.
- بهروزرسانی وابستگیها، بازبینی تغییرات و اجرای مهاجرتهای دیتابیس بهصورت کنترلشده.
۷. عملیات امن، پایش و پاسخ به رخداد
امنیت بدون پایش مداوم ناقص است. لاگهای برنامه، وبسرور، دیتابیس و WAF باید با زمان هماهنگ، سطح دسترسی محدود و دوره نگهداری مشخص ثبت شوند. برنامه پاسخ به رخداد باید شامل تشخیص، مهار، ابطال اعتبارنامه، بازیابی، اطلاعرسانی و تحلیل علت ریشهای باشد.
لاگ نباید شامل گذرواژه، توکن کامل، کد بازیابی یا محتوای محرمانه غیرضروری باشد. برای عیبیابی، شناسه درخواست و اطلاعات حداقلی کافی ثبت شود.
۸. مدل مسئولیت مشترک
۹. محدودیت و ادعای امنیت
هیچ کنترل فنی بهتنهایی «امنیت کامل» ایجاد نمیکند و این صفحه گواهی نفوذناپذیری نیست. سطح واقعی امنیت به نسخه نرمافزار، تنظیمات استقرار، کیفیت کلیدها، رفتار کاربران و سرویسهای متصل وابسته است. آزمون نفوذ رسمی، بازبینی کد و ارزیابی انطباق باید متناسب با ریسک هر سازمان انجام شود.
۱۰. گزارش مسئولانه آسیبپذیری
گزارش امنیتی باید بهصورت خصوصی و شامل نسخه، مؤلفه درگیر، مراحل بازتولید، اثر احتمالی و شواهد حداقلی باشد. از دسترسی به داده واقعی دیگران، تخریب، ایجاد اختلال، مهندسی اجتماعی و انتشار عمومی پیش از هماهنگی خودداری کنید. گزارشهای معتبر پس از دریافت، اولویتبندی و برای اصلاح برنامهریزی میشوند.