امنیت نرم افزار اختصاصی؛ ۱۴ اصل برای ساخت یک سیستم امن

امنیت نرم افزار اختصاصی باید از اولین روز طراحی محصول در نظر گرفته شود، نه اینکه پس از پایان برنامه‌نویسی به‌عنوان یک قابلیت اضافی به سیستم اضافه شود.

یک نرم افزار ممکن است از نظر ظاهری بسیار حرفه‌ای باشد و تمام قابلیت‌های مورد نیاز کسب‌وکار را نیز داشته باشد، اما اگر دسترسی کاربران، APIها، دیتابیس، فایل‌ها، نشست‌ها یا نسخه پشتیبان آن به‌درستی مدیریت نشوند، کل سیستم می‌تواند به نقطه‌ای پرریسک تبدیل شود.

اهمیت این موضوع زمانی بیشتر می‌شود که نرم افزار اطلاعاتی مانند:

• مشخصات مشتریان
• شماره تماس
• قراردادها
• اطلاعات مالی
• فایل‌های محرمانه
• سوابق فعالیت کاربران
• اطلاعات کارکنان
• داده‌های تجاری

را نگهداری کند. در این راهنما مهم‌ترین اصول امنیت نرم افزار اختصاصی را از معماری اولیه تا استقرار و نگهداری بررسی می‌کنیم.

امنیت نرم افزار اختصاصی یعنی چه؟

امنیت نرم افزار فقط به این معنی نیست که کاربر یک رمز عبور قوی داشته باشد. یک سیستم امن باید در چند لایه محافظت شود. برای مثال:

• چه کسی می‌تواند وارد سیستم شود؟
• بعد از ورود چه اطلاعاتی می‌تواند مشاهده کند؟
• آیا APIها سطح دسترسی را کنترل می‌کنند؟
• اطلاعات حساس چگونه ذخیره می‌شوند؟
• فایل‌های خصوصی چه کسانی قابل مشاهده‌اند؟
• فعالیت‌های مهم کاربران ثبت می‌شوند؟
• اگر سرور از دسترس خارج شود، نسخه پشتیبان وجود دارد؟
• در صورت خطا چگونه متوجه مشکل می‌شویم؟

امنیت واقعی حاصل مجموعه‌ای از تصمیم‌های معماری، توسعه و عملیاتی است.

چرا امنیت باید از مرحله طراحی شروع شود؟

یکی از اشتباهات رایج این است که تیم ابتدا تمام قابلیت‌ها را توسعه دهد و در پایان پروژه به امنیت فکر کند. این رویکرد می‌تواند باعث شود بعضی مشکلات در ساختار اصلی سیستم قرار گرفته باشند و اصلاح آن‌ها نیازمند تغییرات گسترده شود. در یک فرایند حرفه‌ای طراحی نرم افزار اختصاصی، امنیت باید هم‌زمان با:

• طراحی معماری
• طراحی دیتابیس
• طراحی مجوز دسترسی
• API
• مدیریت فایل
• زیرساخت

در نظر گرفته شود. این رویکرد معمولاً با مفهوم Security by Design شناخته می‌شود.

۱. احراز هویت امن

احراز هویت مشخص می‌کند کاربر واقعاً همان فردی است که ادعا می‌کند. سیستم‌های اختصاصی ممکن است از روش‌های مختلف استفاده کنند:

• نام کاربری و رمز عبور
• ایمیل و رمز عبور
• شماره موبایل و OTP
• ورود سازمانی
• احراز هویت چندمرحله‌ای

روش مناسب به نوع پروژه بستگی دارد. برای سامانه‌ای داخلی با اطلاعات کم‌حساسیت ممکن است یک مدل ساده کافی باشد، اما یک سیستم مالی یا مدیریتی حساس به کنترل‌های بیشتری نیاز دارد.

رمز عبور نباید به‌صورت خام ذخیره شود

یکی از اصول پایه این است که Password کاربران نباید به شکل قابل خواندن داخل دیتابیس ذخیره شود. سیستم باید از روش‌های استاندارد Hashing مناسب برای رمز عبور استفاده کند. این موضوع باعث می‌شود حتی در صورت دسترسی غیرمجاز به دیتابیس، رمزهای اصلی کاربران مستقیماً قابل مشاهده نباشند.

۲. مدیریت صحیح نشست

بعد از ورود، سیستم باید نشست کاربر را به‌صورت امن مدیریت کند. مواردی که باید بررسی شوند شامل:

• مدت اعتبار نشست
• Logout
• انقضای نشست
• نشست‌های فعال
• دستگاه‌های مختلف
• Cookie Security
• رفتار سیستم بعد از تغییر رمز

هستند. در بعضی نرم افزارهای حساس می‌توان امکان مشاهده و خروج از نشست‌های فعال را نیز به کاربر ارائه کرد.

۳. کنترل مجوز دسترسی و سطح دسترسی

احراز هویت فقط مشخص می‌کند چه کسی وارد سیستم شده است. کنترل مجوز دسترسی مشخص می‌کند آن کاربر چه کاری اجازه دارد انجام دهد. فرض کنید سیستم این نقش‌ها را دارد:

• مدیر کل
• مدیر شعبه
• کارشناس فروش
• حسابدار
• پشتیبان
• مشتری

نباید فقط منوی رابط سمت کاربر برای هر کاربر مخفی شود. بخش سرور نیز باید بررسی کند کاربر واقعاً اجازه انجام عملیات را دارد یا خیر. برای مثال اگر کارشناس فروش فقط باید مشتریان خودش را ببیند، API نیز باید همین محدودیت را اعمال کند.

اصل حداقل دسترسی

یکی از اصول مهم در امنیت نرم افزار این است:

هر کاربر فقط به اطلاعات و قابلیت‌هایی دسترسی داشته باشد که برای انجام وظیفه خود نیاز دارد.

این مفهوم با عنوان Least Privilege شناخته می‌شود. برای مثال کارشناس پشتیبانی الزاماً نباید به اطلاعات مالی یا تنظیمات مدیریتی دسترسی داشته باشد.

۴. Role-Based Access Control: در بسیاری از پروژه‌ها می‌توان مجوزهای دسترسی را بر اساس نقش کاربری مدیریت کرد. مثلاً:

مدیر کل: دسترسی کامل

مدیر فروش: مشتریان، فروش و گزارش‌ها

کارشناس: فقط اطلاعات مرتبط با خودش

حسابدار

اطلاعات مالی و فاکتورها

اما پروژه‌های بزرگ‌تر ممکن است به مجوزهای دسترسیی دقیق‌تری نیاز داشته باشند. مثلاً یک مدیر بتواند اطلاعات را مشاهده و ویرایش کند اما اجازه حذف نداشته باشد. به همین دلیل طراحی سیستم دسترسی یکی از مراحل مهم مراحل طراحی نرم افزار اختصاصی است.

۵. امنیت API

بخش بزرگی از نرم افزارهای مدرن از طریق API با رابط سمت کاربر، اپلیکیشن موبایل یا سرویس‌های خارجی ارتباط برقرار می‌کنند. بنابراین امنیت API اهمیت بسیار بالایی دارد. API باید برای هر درخواست بررسی کند:

• کاربر احراز هویت شده است؟
• اجازه این عملیات را دارد؟
• اطلاعات ورودی معتبر هستند؟
• تعداد درخواست‌ها غیرعادی نیست؟
• داده‌ای بیش از نیاز برگردانده نمی‌شود؟

نباید فرض کرد چون Endpoint داخل رابط سمت کاربر مخفی است، کسی نمی‌تواند مستقیماً آن را فراخوانی کند.

۶. اعتبارسنجی اطلاعات ورودی

تمام اطلاعاتی که از سمت کاربر، API یا سرویس دیگر وارد سیستم می‌شوند باید اعتبارسنجی شوند. برای مثال:

• نوع داده
• طول متن
• فرمت ایمیل
• شماره تلفن
• فایل
• مقدار عددی
• شناسه رکورد

باید بررسی شوند. اعتبارسنجی صحیح علاوه بر امنیت، باعث کاهش خطای نرم‌افزار و داده‌های خراب داخل سیستم نیز می‌شود.

۷. محدودیت تعداد درخواست

بعضی Endpointها نباید بدون محدودیت فراخوانی شوند. برای مثال:

• ورود
• OTP
• Reset Password
• جست‌وجوهای سنگین
• APIهای عمومی

می‌توانند نیازمند محدودیت تعداد درخواست باشند. این کنترل علاوه بر امنیت، از مصرف بی‌رویه منابع سرور نیز جلوگیری می‌کند.

۸. امنیت دیتابیس

دیتابیس معمولاً یکی از ارزشمندترین بخش‌های نرم افزار است. اطلاعات مشتریان، کاربران، قراردادها و سوابق فعالیت در آن ذخیره می‌شوند. چند اصل مهم عبارت‌اند از:

• دیتابیس مستقیماً در دسترس عمومی نباشد.
• Credentialها داخل سورس کد Hardcode نشوند.
• دسترسی سرویس‌ها محدود باشد.
• نسخه پشتیبان منظم وجود داشته باشد.
• پرس‌وجو‌ها به شکل امن اجرا شوند.
• اطلاعات حساس فقط در صورت نیاز نگهداری شوند.

اطلاعاتی را که نیاز ندارید ذخیره نکنید: یکی از بهترین روش‌های کاهش ریسک این است که اطلاعات غیرضروری اصلاً جمع‌آوری نشوند. اگر یک سیستم برای عملکرد خود به داده‌ای نیاز ندارد، نگهداری آن می‌تواند فقط ریسک و مسئولیت بیشتری ایجاد کند.

۹. حفاظت از فایل‌های خصوصی

بعضی نرم افزارها شامل فایل‌هایی مانند:

• قرارداد
• فاکتور
• تصویر مدارک
• فایل پزشکی
• سند داخلی
• گزارش محرمانه

هستند. این فایل‌ها نباید فقط با داشتن URL قابل مشاهده باشند. سیستم باید مشخص کند چه کسی اجازه مشاهده یا دانلود هر فایل را دارد. در پروژه‌های حساس ممکن است نیاز باشد فایل‌ها در ذخیره‌سازی خصوصی نگهداری شوند و دسترسی آن‌ها محدود و زمان‌دار باشد.

۱۰. رمزنگاری ارتباطات

اطلاعاتی که بین مرورگر و سرور منتقل می‌شوند باید از ارتباط امن استفاده کنند. HTTPS یکی از الزامات پایه برای نرم افزارهای تحت وب است. این موضوع برای اطلاعاتی مانند:

• رمز عبور
• Token
• مشخصات کاربران
• اطلاعات مالی

اهمیت زیادی دارد.

۱۱. مدیریت Secretها

پروژه ممکن است Secretهای مختلفی داشته باشد:

• Database Password
• API Key
• SMS Key
• Payment Secret
• JWT Secret
• Storage Credential

این اطلاعات نباید داخل مخزن عمومی یا رابط سمت کاربر قرار بگیرند. مدیریت صحیح Environment Variables و Secretها یکی از بخش‌های مهم فرایند استقرار است.

۱۲. سابقه اقدام‌ها

در نرم افزارهای سازمانی، فقط ذخیره اطلاعات کافی نیست. گاهی باید بدانیم:

چه کسی، چه چیزی را، چه زمانی تغییر داده است؟

برای مثال:

• چه کسی قرارداد را حذف کرد؟
• چه کسی مبلغ فاکتور را تغییر داد؟
• چه کسی مجوز دسترسی کاربر را تغییر داد؟
• چه کسی یک مشتری را منتقل کرد؟

سابقه اقدام‌ها می‌تواند برای عملیات حساس بسیار ارزشمند باشد. این قابلیت هم در امنیت و هم در بررسی خطاهای عملیاتی کاربرد دارد.

ثبت سوابق با سابقه اقدام‌ها متفاوت است

Application Log بیشتر برای بررسی عملکرد فنی سیستم استفاده می‌شود. مثلاً:

• خطا
• Timeout
• Failed Request
• Service Failure

اما سابقه اقدام‌ها روی فعالیت کاربران و تغییرات مهم کسب‌وکار تمرکز دارد. هر دو می‌توانند برای یک سیستم حرفه‌ای ضروری باشند.

۱۳. نسخه پشتیبان؛ آخرین خط دفاع

حتی امن‌ترین نرم افزار نیز باید نسخه پشتیبان داشته باشد. مشکلات فقط ناشی از حمله نیستند. ممکن است:

• خطای انسانی رخ دهد.
• رکورد مهمی حذف شود.
• سرور مشکل پیدا کند.
• ذخیره‌سازی آسیب ببیند.
• استقرار اشتباه انجام شود.

نسخه پشتیبان کمک می‌کند سیستم از چنین اتفاقاتی بازیابی شود.

یک برنامه نسخه پشتیبان باید مشخص کند:

• هر چند وقت نسخه پشتیبان گرفته می‌شود؟
• چه اطلاعاتی نسخه پشتیبان می‌شوند؟
• نسخه پشتیبان کجا نگهداری می‌شود؟
• چند نسخه قبلی نگهداری می‌شود؟
• چه کسی دسترسی دارد؟
• Restore چگونه انجام می‌شود؟

نسخه پشتیبان بدون تست Restore کافی نیست: داشتن فایل نسخه پشتیبان به‌تنهایی تضمین نمی‌کند که در روز بحران قابل استفاده باشد. در پروژه‌های مهم، فرایند بازیابی نیز باید در بازه‌های مناسب بررسی شود.

۱۴. پایش و تشخیص سریع خطا

هرچه سریع‌تر متوجه یک مشکل شویم، احتمال آسیب کمتر می‌شود. پایش می‌تواند مواردی مانند:

• Availability
• Error Rate
• CPU
• حافظه
• پایگاه داده
• Response Time
• ذخیره‌سازی

را بررسی کند. برای نرم افزارهای حیاتی بهتر است خطاهای مهم بدون نیاز به گزارش کاربر به تیم فنی اعلام شوند.

امنیت رابط سمت کاربر

اگرچه بخش اصلی مجوز دسترسی باید روی بخش سرور اعمال شود، رابط سمت کاربر نیز باید اصول امنیتی را رعایت کند. برای مثال:

• اطلاعات حساس در Browser ذخیره نشوند مگر در صورت نیاز.
• Tokenها به شکل مناسب مدیریت شوند.
• خطاها اطلاعات داخلی سیستم را افشا نکنند.
• داده‌های کاربر قبل از نمایش صحیح مدیریت شوند.

رابط سمت کاربر امن جای بخش سرور امن را نمی‌گیرد؛ هر دو باید با هم طراحی شوند.

امنیت اتصال به سیستم‌های دیگر

یک نرم افزار اختصاصی ممکن است به سرویس‌هایی مانند:

• پیامک
• پرداخت
• حسابداری
• CRM
• هوش مصنوعی
• نقشه
• سرویس‌های سازمانی

متصل باشد. هر اتصال به سیستم‌های دیگر یک مرز جدید در معماری ایجاد می‌کند. باید بررسی شود:

• چه اطلاعاتی ارسال می‌شود؟
• Credentialها کجا نگهداری می‌شوند؟
• در صورت قطع سرویس چه اتفاقی می‌افتد؟
• Timeout چگونه مدیریت می‌شود؟
• پاسخ سرویس اعتبارسنجی می‌شود؟

امنیت در اتوماسیون کسب‌وکار

وقتی نرم افزار عملیات را خودکار می‌کند، مجوز دسترسی اهمیت بیشتری پیدا می‌کند. برای مثال یک خودکارسازی ممکن است:

• فاکتور بسازد.
• وضعیت سفارش را تغییر دهد.
• پیامک ارسال کند.
• فایل تولید کند.
• اطلاعات را به سیستم دیگر منتقل کند.

هر گردش کار باید دقیقاً مشخص کند با چه رویداد آغازگر و تحت چه سطح دسترسی اجرا می‌شود.

امنیت نرم افزار اختصاصی و هوش مصنوعی

در پروژه‌هایی که از هوش مصنوعی استفاده می‌کنند، مسئله حاکمیت داده اهمیت بیشتری پیدا می‌کند. باید مشخص شود:

• چه اطلاعاتی برای سرویس هوش مصنوعی ارسال می‌شود؟
• آیا اطلاعات مشتریان ارسال می‌شوند؟
• چه داده‌هایی سابقه می‌شوند؟
• پاسخ هوش مصنوعی چه سطح دسترسی دارد؟
• آیا خروجی قبل از عملیات حساس بررسی می‌شود؟

هوش مصنوعی نیز باید داخل همان معماری مجوز دسترسی و امنیت کلی سیستم قرار بگیرد.

Dependencyها و به‌روزرسانی‌ها

نرم افزارهای مدرن از چارچوب توسعه‌ها و Libraryهای مختلف استفاده می‌کنند. این Dependencyها در طول زمان به‌روزرسانی می‌شوند و ممکن است آسیب‌پذیری‌های شناخته‌شده برای نسخه‌های قدیمی منتشر شود. بنابراین نگهداری امنیتی نرم افزار باید شامل بررسی و به‌روزرسانی کنترل‌شده Dependencyها نیز باشد.

چرا پشتیبانی امنیتی بعد از تحویل مهم است؟

امنیت یک فعالیت یک‌باره نیست. سیستمی که امروز امن است ممکن است دو سال بعد به دلیل:

• Dependency قدیمی
• تغییر زیرساخت
• قابلیت جدید
• تنظیم اشتباه
• آسیب‌پذیری جدید

به به‌روزرسانی نیاز داشته باشد. به همین دلیل در هنگام انتخاب شرکت طراحی نرم افزار اختصاصی، کیفیت پشتیبانی بعد از تحویل نیز باید بررسی شود.

امنیت چگونه روی هزینه پروژه تأثیر می‌گذارد؟

سطح امنیت مورد نیاز برای هر پروژه متفاوت است. یک ابزار ساده داخلی با ۱۰ کاربر الزاماً نیازمند همان ساختاری نیست که یک پلتفرم مالی با هزاران کاربر نیاز دارد. مواردی مانند:

• سابقه اقدام‌ها
• MFA
• پایش پیشرفته
• نسخه پشتیبان چندلایه
• Security Testing
• Infrastructure Redundancy

می‌توانند محدوده پروژه را افزایش دهند. به همین دلیل هنگام بررسی هزینه ساخت نرم افزار اختصاصی، سطح امنیت مورد انتظار نیز باید مشخص شود.

قبل از تحویل نرم افزار چه موارد امنیتی بررسی شوند؟

یک Checklist عمومی می‌تواند شامل موارد زیر باشد:

• احراز هویت
• مجوزهای دسترسی
• نشست‌ها
• APIها
• اعتبارسنجی
• محدودیت تعداد درخواست
• Upload
• Database Access
• Secrets
• نسخه پشتیبان
• ثبت سوابق
• سابقه اقدام‌ها
• HTTPS
• Error Handling
• پایش

باشد. البته Checklist واقعی باید بر اساس نوع پروژه طراحی شود.

امنیت و قرارداد پروژه

مسئولیت امنیت باید در قرارداد نیز تا حد ممکن شفاف باشد. برای مثال:

• نسخه پشتیبان با چه کسی است؟
• Hosting با چه کسی است؟
• به‌روزرسانی امنیتی تا چه مدت انجام می‌شود؟
• رخداد چگونه گزارش می‌شود؟
• Credentialهای سرویس‌ها متعلق به چه کسی هستند؟

این موارد در مقاله قرارداد طراحی نرم افزار اختصاصی با جزئیات بیشتری بررسی شده‌اند.

رویکرد آرکوتک به امنیت نرم افزار اختصاصی

در آرکوتک، امنیت باید متناسب با نوع پروژه و حساسیت اطلاعات طراحی شود. برای یک سیستم حرفه‌ای، موضوعاتی مانند:

• احراز هویت
• کنترل مجوز دسترسی
• مجوز دسترسی
• اعتبارسنجی
• API Security
• Secure File Access
• ثبت سوابق
• نسخه پشتیبان
• پایش

باید از مرحله معماری در نظر گرفته شوند. هدف فقط جلوگیری از یک سناریوی خاص نیست؛ بلکه ساخت سیستمی است که کنترل دسترسی، قابلیت بازیابی و امکان مانیتورینگ مناسبی داشته باشد.

جمع‌بندی

امنیت نرم افزار اختصاصی یک قابلیت جداگانه نیست؛ بخشی از معماری کل محصول است.

یک نرم افزار امن باید در چند لایه شامل:

• احراز هویت
• دسترسی
• API
• دیتابیس
• فایل
• نشست
• Secret
• سابقه
• نسخه پشتیبان
• زیرساخت

محافظت شود. هرچه اطلاعات و عملیات سیستم حساس‌تر باشند، طراحی امنیت نیز باید جدی‌تر و دقیق‌تر انجام شود.

اگر قصد توسعه سیستمی را دارید که قرار است اطلاعات مهم کسب‌وکار یا مشتریان شما را مدیریت کند، امنیت باید از اولین مرحله طراحی نرم افزار اختصاصی وارد معماری پروژه شود؛ نه پس از پایان توسعه.

پرسش‌های متداول

امنیت نرم افزار اختصاصی از چه مرحله‌ای باید شروع شود؟

از مرحله تحلیل و معماری. تصمیم‌های مربوط به کاربران، دسترسی، دیتابیس، API و زیرساخت بهتر است قبل از توسعه اصلی مشخص شوند.

آیا HTTPS برای امنیت نرم افزار کافی است؟

خیر. HTTPS فقط بخشی از امنیت ارتباط است و مواردی مانند احراز هویت، مجوز دسترسی، API Security، نسخه پشتیبان و ثبت سوابق نیز اهمیت دارند.

آیا نسخه پشتیبان بخشی از امنیت نرم افزار است؟

بله. امنیت فقط جلوگیری از دسترسی غیرمجاز نیست؛ قابلیت بازیابی اطلاعات بعد از خطا یا حادثه نیز بخشی مهم از امنیت عملیاتی است.

سابقه اقدام‌ها چیست؟

سابقه اقدام‌ها سابقه فعالیت‌های حساس کاربران را ثبت می‌کند تا مشخص باشد چه فردی، در چه زمانی، چه تغییری در سیستم انجام داده است.

آیا امنیت بعد از تحویل نرم افزار تمام می‌شود؟

خیر. Dependencyها، زیرساخت و قابلیت‌های نرم افزار در طول زمان تغییر می‌کنند و به نگهداری و به‌روزرسانی امنیتی نیاز دارند.