تشخیص و تصدیق هویت | امنیت در BPMS فراگستر

زمان تقریبی مطالعه: 3 دقیقه

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

تشخیص و تصدیق هویت در برنامه‌ی کاربردی یک فرآیند ۲ مرحله‌ایست که در طی آن هویت کاربر و یا فرایندی که از جانب کاربر عمل می‌کند، شناسایی شده و سپس هویت او تایید می‌شود. (آیا کاربر همان کسی است که ادعا می‌کند؟)

فرایند تشخیص و تصدیق هویت چگونه انجام میگیرد؟

فرآیند تشخیص توسط شناسه‌ی یکتای کاربر در سطح برنامه‌ی کاربردی انجام می‌گیرد. در مرحله‌ی تصدیق هویت، هویت ادعایی کاربر توسط اطلاعات هویتی ارائه شده توسط کاربر، نظیر کلمه‌های عبور، گواهینامه‌های دیجیتال و یا مشخصه‌های بیومتریک (اثر انگشت، شبکیه، صدا، DNA و..) تایید و یا رد می‌شود. تشخیص و تصدیق هویت پایه‌ایست برای سایر راهکارهای امنیتی چرا که در این مرحله زنجیره‌ی اطمینانی بین کاربر و برنامه‌ی کاربردی برقرار می‌شود.

BPMS فراگستر در این حوزه شاخصهای اصلی زیر را بطور موفق پاس نموده است:

تصدیق هویت کاربران: برنامه‌ی کاربردی باید قبل از اعطای حق دسترسی به منابع و نقش‌ها، هویت کاربران را تصدیق کند
تصدیق هویت فرایندها: برنامه‌ی کاربردی باید هویت تمامی فرایندها، برنامه‌ها و دیگر موجودیت‌ها و اشیای فعال را که از طرف کاربر عملی را انجام می‌دهند، بررسی و تصدیق کند.
زنجیره‌ی عامل‌های تصدیق هویت شده: برای هر تراکنشی برنامه‌ی کاربردی باید مطمئن شود که زنجیره‌ای از عامل‌های تصدیق هویت شده بین مروگر، کارگزار وب، کارگزار برنامه‌ی کاربردی و سیستم‌های پشت صحنه مثل DBMS ایجاد شده باشد.
ذخیره‌سازی اطلاعات هویتی کاربران بصورت امن شده: تمامی اطلاعات تصدیق هویت کاربران باید در رسانه‌های ذخیره‌سازی بصورت رمزنگاری شده ذخیره گردد.
اعمال قاعده‌ی دفاع در عمق برای تصدیق هویت: تصدیق هویت برنامه‌ی کاربردی نباید به عنوان راهکار جایگزین تصدیق هویت سیستم‌های پشتیبان نظیر DBMSها در نظر گرفته شود.
عدم وجود نقش‌هایی در سیستم بدون اطلاعات تصدیق هویتی: هیچ نقشی در سیستم نباید بدون اطلاعات تصدیق هویتی باشد
تصدیق هویت در سطح نقش‌های موجود: برنامه‌ی کاربردی ابتدا باید هویت کاربر را بصورت جداگانه تصدیق کند و سپس صحت ادعای عضویت یک کاربر را برای عضویت او در یک گروه/نقش خاص بررسی کند.
عدم استفاده از اطلاعات تشخیص هویتی در کد: برنامه‌ی‌ کاربردی نباید از اطلاعات تصدیق هویتی نظیر کلمه‌های عبور، کلید‌های رمزنگاری و… در کد استفاده کند.
استفاده از کلمه‌های عبور قوی: برای جلوگیری از انجام حملات brute-force و Dictionary Attack باید کلمه‌های عبور براساس خط مشی انتخاب کلمه‌های عبور انجام شود.
شناسه‌های کاربری یکتا: برنامه‌ی کاربردی نباید اجازه دهد یک شناسه‌ی کاربر با چند کلمه‌ی عبور انتخاب شده و یا با یک شناسه کاری یکسان امکان ورود چندین کاربر وجود داشته باشد.
عدم ذخیره‌ی اطلاعات تصدیق هویت کاربر بطور نامناسب: برنامه‌ی کاربردی نباید اطلاعات تصدیق هویت کاربر را در کوکی ها، اسکریپت های سمت کارگزار و یا مشتری ویا دیگر فایل‌هائی که این اطلاعات بتواند از آن بدست آید، ذخیره کند.
شناسه‌ی کاربری بدون هویت: برنامه‌ی کاربردی نباید شامل شناسه‌ی کاربری بدون هویت برای ورود باشد.
طبقه ‌بندی نواحی برنامه‌ی کاربردی: نواحی عمومی برنامه‌ی کاربردی که برای دسترسی به آنها نیازی به راهکارهای تصدیق هویت نیست باید شناسائی شده و از نواحی خصوصی که برای دسترسی به آنها نیاز به تشخیص و تصدیق هویت است تفکیک گردد.
قاعده‌ی کمترین حق دسترسی: برنامه‌ی کاربردی باید بطور پیش فرض کمترین حق دسترسی را برای شناسه‌ی کاربری در نظر بگیرد.
عدم ارائه‌ی جزئیات به کاربر در صورت ورود ناموفق: برنامه‌ی کاربردی نباید مشخص کند که علت شکست ورود کلمه‌ی عبور نادرست بوده است.
عدم نمایش شناسه کاربری بعد از ورود ناموفق: برنامه کاربردی باید شناسه کاربری را بعد از ورود ناموفق مجددا از کاربر بخواهد.
وجود خصیصه LockOut: اگر کاربر وارد سیستم گردید و سپس برای یک مدت زمان از سیستم استفاده ننمود، جهت استفاده مجدد باید احراز هویت شود.
احراز هویت مجدد برای صفحات حساس: جهت انجام هرگونه فعالیت حساس در سیستم احراز هویت مجدد از کاربر صورت گیرد.