نویسنده: WKFGo Editorial · ·
دسترسی مبتنی بر نقش چیست؟
در دسترسی مبتنی بر نقش (RBAC)، مجوزها مستقیماً و پراکنده به هر کاربر داده نمی‌شوند؛ ابتدا به نقش‌هایی مثل مدیر پروژه، عضو تیم، مالی و مهمان متصل می‌شوند و سپس کاربر در محدوده سازمان یا پروژه آن نقش را می‌گیرد. نتیجه باید دو هدف را هم‌زمان برآورده کند: کمترین دسترسی لازم و کمترین اصطکاک برای انجام کار.
نقش با عنوان شغلی یکی نیست
یک نفر ممکن است در سازمان «توسعه‌دهنده ارشد» باشد، در پروژه آلفا مدیر فنی و در پروژه بتا فقط مشاهده‌گر. پس نقش باید محدوده داشته باشد:
- نقش سازمانی برای تنظیمات مشترک و مدیریت اعضا؛
- نقش پروژه برای تسک، سند و گزارش همان پروژه؛
- نقش موقت برای پیمانکار، حسابرس یا جانشین؛
- مجوز استثنایی فقط وقتی نقش استاندارد پاسخ نمی‌دهد.
استثناهای زیاد علامت طراحی ضعیف نقش‌هاست و باید دوره‌ای پاک‌سازی شود.
ماتریس دسترسی نمونه
| عملیات | مدیر پروژه | عضو تیم | مالی | مهمان |
|---|---|---|---|---|
| دیدن تسک پروژه | ✓ | ✓ | در صورت نیاز | محدود |
| ساخت و ویرایش تسک | ✓ | ✓ | — | — |
| تأیید تحویل | ✓ | در صورت نقش بازبین | — | — |
| دیدن هزینه و بودجه | در صورت سیاست | — | ✓ | — |
| مدیریت اعضا و نقش‌ها | ✓ | — | — | — |
| دیدن سند عمومی پروژه | ✓ | ✓ | ✓ | انتخابی |
| دیدن سند محرمانه | بر اساس طبقه‌بندی | بر اساس طبقه‌بندی | بر اساس طبقه‌بندی | — |
این جدول نسخه نهایی نیست؛ نقطه شروع گفت‌وگوست. هر مجوز باید به یک مسئولیت واقعی و یک سناریوی کاری وصل باشد.
۱. عملیات را فهرست کنید
به‌جای شروع از نام نقش‌ها، کارهای حساس را بنویسید: مشاهده مالی، حذف تسک، دعوت عضو، تغییر گردش کار، تأیید تحویل، امضای سند و خروجی داده.
۲. نقش‌های کم و قابل توضیح بسازید
اگر توضیح یک نقش بیش از چند جمله است یا فقط برای یک نفر ساخته شده، احتمالاً نقش نیست؛ مجموعه‌ای از استثناهاست. نقش پایه + محدوده پروژه معمولاً از ده‌ها نقش ترکیبی نگه‌داری‌پذیرتر است.
۳. اصل حداقل دسترسی را اجرا کنید
دسترسی پیش‌فرض بسته باشد و فقط نیاز اثبات‌شده باز شود. اما «حداقل» نباید آن‌قدر محدود باشد که کاربر برای هر اقدام معمول تیکت بزند؛ چنین سیستمی افراد را به حساب مشترک و دورزدن کنترل سوق می‌دهد.
۴. جداسازی وظایف را مشخص کنید
در عملیات پرریسک، سازنده و تأییدکننده یک نفر نباشند. نمونه: ثبت هزینه و تأیید پرداخت، یا آماده‌سازی قرارداد و امضای نهایی. برای تیم کوچک، مسیر اضطراری با ثبت دلیل تعریف کنید.
۵. با سناریو آزمایش کنید
برای هر نقش چند آزمون «مجاز/غیرمجاز» بنویسید. فقط رابط را تست نکنید؛ API، جستجو، خروجی و دستیار AI نیز باید همان محدودیت را رعایت کنند. پنهان‌کردن دکمه بدون کنترل سمت سرور مجوز نیست.
۶. دسترسی را بازبینی و منقضی کنید
دسترسی پیمانکار و پروژه تمام‌شده باید تاریخ انقضا داشته باشد. هر فصل، نقش‌های بدون استفاده، استثناهای فردی و حساب‌های غیرفعال را مرور کنید. تغییر نقش باید در لاگ ممیزی ثبت شود.
سناریوهای مهم
پیمانکار: فقط پروژه مشخص، تسک‌های لازم و اسناد انتخابی؛ بدون فهرست کل مشتریان یا مالی.
مدیر مالی: گزارش هزینه و بودجه در همه پروژه‌های مجاز؛ بدون امکان تغییر تسک فنی مگر مسئولیت جداگانه داشته باشد.
مهمان مشتری: مشاهده خروجی و نقاط عطف تأییدشده؛ نه بحث داخلی، برآورد افراد یا سند پیش‌نویس.
جانشینی موقت: دسترسی مدیر در مرخصی با تاریخ شروع و پایان، دلیل و ثبت ممیزی؛ نه انتقال دائمی و فراموش‌شده.
RBAC و هوش مصنوعی
دستیار متصل به پروژه نباید با یک توکن فراگیر کار کند. جستجو و ابزار MCP باید هویت همان کاربر را حمل کنند، نتایج غیرمجاز را پیش از بازیابی حذف کنند و عملیات نوشتن پرریسک را برای تأیید نگه دارند. حتی افشای عنوان یک سند محرمانه می‌تواند نشت اطلاعات باشد.
شاخص‌های سلامت دسترسی
- تعداد مجوزهای مستقیم خارج از نقش؛
- حساب غیرفعال با دسترسی فعال؛
- دسترسی موقتِ منقضی‌نشده؛
- زمان متوسط پاسخ به درخواست مشروع؛
- تعداد عملیات ردشده‌ای که کار روزانه را مختل کرده‌اند؛
- پوشش آزمون مجوز برای API و رابط.
هدف صفرکردن درخواست دسترسی نیست؛ هدف این است که درخواست‌ها استثنا باشند و ریسک بالا بدون کنترل نماند.
RBAC با دسترسی مبتنی بر ویژگی چه فرقی دارد؟
RBAC تصمیم را بر نقش می‌گذارد. کنترل مبتنی بر ویژگی می‌تواند پروژه، مالکیت، طبقه‌بندی سند یا زمان را نیز لحاظ کند. برای بیشتر تیم‌ها نقش پایه و چند قاعده محدود زمینه‌ای ترکیب قابل فهمی است.
چند نقش بسازیم؟
کمترین تعداد که مسئولیت‌های واقعاً متفاوت را پوشش دهد. اگر ماتریس نقش‌ها قابل مرور در یک صفحه نیست، پیش از افزودن نقش جدید ساختار را ساده کنید.
حساب مدیرکل مشترک قابل قبول است؟
خیر. انتساب و ردپای ممیزی را از بین می‌برد. هر فرد حساب خودش را داشته باشد و دسترسی اضطراری زمان‌دار و ثبت‌شده باشد.
شروع در WKFGo
از چهار نقش پایه شروع کنید، ماتریس مجوز را با سناریوهای واقعی بسنجید و بعد از یک ماه استثناها را مرور کنید. برای طراحی تأییدهای حساس، راهنمای دروازه کیفیت تسک را ببینید.
منابع دست‌اول و روش راستی‌آزمایی
این فهرست برای بررسی بیشتر است؛ لینک‌های داخل متن، منبع ادعای مشخص همان بخش‌اند.