در بسیاری از نرم‌افزارهای سازمانی، دسترسی کاربران به‌صورت وصله‌ای رشد می‌کند: یک کاربر جدید می‌آید، سریع‌ترین راه این است که دسترسی‌های یک همکار مشابه را برایش کپی کنیم؛ یک نیاز استثنایی پیش می‌آید، یک استثنای موقت برای یک نفر ثبت می‌شود که هیچ‌وقت حذف نمی‌شود. بعد از یک یا دو سال، هیچ‌کس دقیق نمی‌داند چرا فلان کاربر به فلان بخش مالی دسترسی نوشتن دارد.
این راهنما برای مدیر فناوری، مدیر عملیات و مسئول امنیت اطلاعاتی نوشته شده که می‌خواهند مدل نقش و سطح دسترسی (RBAC) را از ابتدا یا در بازطراحی یک سامانه موجود درست تعریف کنند. بحث درباره پیاده‌سازی فنی یک کتابخانه خاص نیست؛ درباره مدل داده نقش، مالکیت تصمیم و قابلیت ممیزی است.
پاسخ کوتاه: چه زمانی به مدل نقش رسمی نیاز دارید؟
اگر سامانه فقط چند کاربر با اختیارات تقریباً یکسان دارد، یک پرچم ساده «مدیر/کاربر عادی» کافی است. اما وقتی واحدهای مختلف (فروش، انبار، مالی، پشتیبانی) هرکدام باید فقط بخشی از داده را ببینند یا تغییر دهند، وقتی مشتری بیرونی هم باید به بخشی از سامانه دسترسی محدود داشته باشد، یا وقتی الزام قانونی یا قرارداد شما را موظف به نشان‌دادن «چه کسی به چه داده‌ای دسترسی دارد» می‌کند، مدل نقش رسمی و قابل ممیزی ضروری است.
معیار تصمیم ساده است: اگر همین امروز از شما بخواهند فهرست کامل کسانی که به داده حقوق و دستمزد دسترسی دارند را نشان دهید و پاسخ فوری و قابل استناد ندارید، مشکل دیگر کوچک نیست.
تفاوت با ثبت تاریخچه تغییرات و با طراحی پورتال مشتری
مدل دسترسی با دو موضوع نزدیک اشتباه گرفته می‌شود. ثبت تاریخچه تغییرات (Audit Trail) به شما می‌گوید بعد از وقوع یک تغییر، چه کسی چه کاری کرد؛ مدل نقش و دسترسی، پیش از هر اقدام، مشخص می‌کند اصلاً چه کسی اجازه انجام آن کار را دارد. این دو مکمل‌اند: بدون مدل دسترسی درست، تاریخچه فقط ثبت می‌کند که یک نفر بدون اجازه کاری کرده، بدون آنکه از قبل جلوی آن را بگیرد.
طراحی پورتال مشتری هم موضوع دیگری است؛ آن مقاله دربارهٔ تجربه کاربری و امکانات یک پورتال خودخدمت برای مشتریان بیرونی است. مدل دسترسی زیرساخت مشترکی است که هم پورتال مشتری، هم پنل داخلی کارمندان از آن استفاده می‌کنند، اما خودش دربارهٔ ظاهر یا امکانات یک پورتال خاص نیست.
نقش، اجازه و منبع؛ سه لایه‌ای که باید از هم جدا بمانند
اشتباه رایج، تعریف دسترسی مستقیم برای هر کاربر است، نه برای یک نقش. این کار در آغاز ساده به نظر می‌رسد اما با رشد سازمان غیرقابل نگهداری می‌شود. مدل درست سه لایه دارد که باید از هم جدا تعریف شوند:
- **نقش (Role)**: یک عنوان کاری یا مسئولیتی، مثل «کارشناس فروش»، «مدیر انبار» یا «حسابدار ارشد».
- **اجازه (Permission)**: یک عمل مشخص روی یک نوع داده، مثل «ایجاد فاکتور»، «مشاهده گزارش حقوق» یا «تأیید مرجوعی».
- **منبع (Resource / Scope)**: محدودهٔ داده‌ای که اجازه روی آن اعمال می‌شود، مثل «فقط سفارش‌های شعبه خودش» یا «فقط مشتریان تخصیص‌یافته به خودش».
کاربر به یک یا چند نقش متصل می‌شود؛ هر نقش مجموعه‌ای از اجازه‌ها را روی منابع مشخص دارد. وقتی مسئولیت فردی تغییر می‌کند، فقط نقش او تغییر می‌کند، نه ده‌ها تیک پراکنده در تنظیمات.
سلسله‌مراتب نقش‌ها و خطر «ابرنقش»
نقش‌ها معمولاً سلسله‌مراتبی‌اند: یک «مدیر فروش منطقه» باید همه اجازه‌های «کارشناس فروش» را هم داشته باشد، به‌اضافه چند اجازه مدیریتی. تعریف این وراثت باعث می‌شود اضافه‌کردن یک اجازه جدید به سطح پایه، خودکار به همه سطوح بالاتر هم برسد.
خطر اصلی، ساختن یک یا چند «ابرنقش» است که برای راحتی به همه چیز دسترسی دارد و به افراد بیشتری نسبت به نیاز واقعی داده می‌شود، معمولاً چون تعریف نقش دقیق‌تر «وقت‌گیر» به نظر می‌رسد. هر ابرنقش، سطح آسیب یک حساب کاربری هک‌شده یا یک اشتباه انسانی را چند برابر می‌کند. قانون حداقل دسترسی لازم (Least Privilege) یعنی هر نقش فقط اجازه‌هایی دارد که برای انجام کارش لازم است، نه چیزی که «ممکن است یک روز لازم شود».
دسترسی موقت و استثنای پروژه‌محور
بعضی نیازها واقعاً موقت‌اند: یک کارشناس برای یک پروژه خاص باید چند هفته به گزارش یک واحد دیگر دسترسی داشته باشد. اگر سامانه امکان دسترسی موقت با تاریخ انقضای خودکار نداشته باشد، این استثناها به‌صورت دستی اضافه می‌شوند و تقریباً هیچ‌وقت به‌موقع حذف نمی‌شوند. یک مدل دسترسی سالم باید از ابتدا فیلد تاریخ انقضا برای هر تخصیص استثنایی داشته باشد و پیش از انقضا به مسئول مربوطه یادآوری بفرستد تا تصمیم تمدید یا لغو با آگاهی گرفته شود.
بازبینی دوره‌ای دسترسی‌ها
حتی با بهترین طراحی اولیه، با گذشت زمان نقش افراد تغییر می‌کند، پروژه‌ها تمام می‌شوند و دسترسی‌های اضافه باقی می‌مانند. یک چرخه بازبینی دوره‌ای (مثلاً هر سه یا شش ماه) که در آن مدیر هر واحد فهرست دسترسی‌های زیرمجموعه خودش را تأیید یا اصلاح می‌کند، تنها راه عملی جلوگیری از انباشت دسترسی‌های فراموش‌شده است. این بازبینی باید در خود سامانه ثبت شود، نه در یک ایمیل جداگانه که ردی از آن باقی نمی‌ماند.
چه زمانی تغییر دسترسی باید تأیید مدیر بگیرد
انتساب یک نقش سطح پایین به یک کاربر جدید در همان واحد، ریسک کمی دارد و می‌تواند مستقیم توسط مدیر همان واحد انجام شود. اما دادن هر دسترسی‌ای که مرز واحد را رد می‌کند، سطح مدیریتی بالاتر می‌گیرد یا به داده مالی/حقوقی می‌رسد، باید یک مرحله تأیید صریح و ثبت‌شده داشته باشد. جدا کردن این دو مسیر (سبک برای درون‌واحد، تأییدشده برای فراواحدی) هم سرعت کار روزمره را حفظ می‌کند و هم دسترسی‌های حساس را زیر نظر نگه می‌دارد.
آنچه نسخه اول باید داشته باشد
نسخه اول یک مدل دسترسی قابل اتکا باید شامل این‌ها باشد: تعریف نقش با فهرست صریح اجازه‌ها، اتصال هر کاربر به یک یا چند نقش، محدودهٔ داده (Scope) حداقل در سطح واحد سازمانی، تاریخ انقضا برای هر دسترسی استثنایی، و یک گزارش ساده «کدام کاربر به کدام اجازه دسترسی دارد» که مدیر بتواند در چند ثانیه آن را بخواند.
قابلیت‌های زیر می‌توانند در انتشارهای بعدی اضافه شوند: دسترسی مبتنی بر ویژگی (Attribute-Based) برای قواعد پیچیده‌تر، تفویض موقت نقش هنگام مرخصی، ورود با احراز هویت چندعامله برای نقش‌های حساس، و داشبورد تحلیلی از الگوی استفاده واقعی هر نقش. اضافه‌کردن این‌ها پیش از تثبیت مدل پایه، معمولاً پروژه را پیچیده‌تر از نیاز واقعی می‌کند.
اشتباهاتی که مدل دسترسی را از کار می‌اندازند
رایج‌ترین اشتباه، دادن دسترسی مستقیم به کاربر به‌جای نقش است؛ این کار در ابتدا سریع‌تر به نظر می‌رسد اما هر تغییر بعدی را به یک عملیات دستی و پرخطا تبدیل می‌کند. اشتباه دوم، نداشتن تاریخ انقضا برای دسترسی‌های موقت است؛ بدون آن، «موقت» در عمل به «همیشگی» تبدیل می‌شود. اشتباه سوم، تعریف نقش‌ها بر اساس نام فرد به‌جای مسئولیت شغلی است، که باعث می‌شود با هر تغییر پرسنلی، مدل از نو بازتعریف شود. اشتباه چهارم، حذف‌نشدن دسترسی هنگام خروج یا تغییر سمت کارمند است؛ فرایند خروج باید همان‌قدر رسمی باشد که فرایند ورود.
چگونه بسنجید مدل دسترسی واقعاً کار می‌کند
بعد از استقرار، چند شاخص ساده نشان می‌دهد مدل روی کاغذ مانده یا واقعاً اجرا می‌شود: تعداد کاربرانی که هنوز نقش «ابرنقش» یا دسترسی کامل دارند، درصد دسترسی‌های استثنایی که تاریخ انقضای فعال دارند، زمان لازم برای پاسخ به این سؤال که «چه کسی به این داده دسترسی دارد»، و نتیجه آخرین چرخه بازبینی دوره‌ای (چند دسترسی اصلاح یا لغو شد).
جمع‌بندی
مدل نقش و سطح دسترسی، جایگزین ثبت تاریخچه تغییرات نیست و طراحی یک پورتال خاص هم نیست؛ زیرساختی است که پیش از هر اقدام تعیین می‌کند چه کسی اجازه دارد و روی چه داده‌ای. جداسازی نقش از اجازه و از منبع، پرهیز از ابرنقش، تاریخ انقضا برای استثناها و بازبینی دوره‌ای، ستون‌های اصلی یک مدل قابل اعتماد هستند.
اگر می‌خواهید نقش‌ها، سطوح دسترسی و فرایند تأیید سامانه خودتان را قبل از شروع پیاده‌سازی روشن کنید، از چک‌لیست RFP نرم‌افزار سفارشی برای مقایسه پیشنهادها استفاده کنید یا مستقیم با تیم طراحی نرم‌افزار سفارشی ایزی‌ساز گفتگو کنید. برای شروع یک بررسی اولیه رایگان، از صفحه تماس ایزی‌ساز پیام بفرستید.
پرسش‌های پرتکرار
**آیا این همان ثبت تاریخچه تغییرات (Audit Trail) است؟** خیر. مدل دسترسی پیش از اقدام تعیین می‌کند چه کسی اجازه دارد؛ تاریخچه تغییرات بعد از اقدام ثبت می‌کند چه کسی چه کاری کرد. یک سامانه سالم به هر دو نیاز دارد، اما این دو یک چیز نیستند.
**آیا برای شروع باید همه استثناها را از بین ببریم؟** نه لزوماً، اما هر استثنا باید تاریخ انقضا و یک دلیل ثبت‌شده داشته باشد. حذف کامل استثنا هدف نیست؛ هدف قابل‌ردیابی‌بودن آن است.
**نقش‌ها را بر چه اساسی تعریف کنیم، سمت شغلی یا فرد؟** همیشه بر اساس مسئولیت شغلی، نه نام فرد. وقتی نقش به فرد گره بخورد، هر تغییر پرسنلی به یک پروژه دوباره‌تعریف تبدیل می‌شود.
**چرخه بازبینی دسترسی هر چند وقت باید انجام شود؟** بسته به حساسیت داده، معمولاً هر سه تا شش ماه برای دسترسی‌های عادی و کوتاه‌تر (مثلاً ماهانه) برای دسترسی‌های مالی یا حقوقی حساس.