طراحی نقش و دسترسی امن برای کارکنان

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

از پنل وارد «تیم و دسترسی» شوید. صفحه فعلی چهار میانبر دارد: نقش‌های شغلی، مجوزهای دقیق، انتساب نقش، و ردپای دسترسی. پایین‌تر «شبیه‌ساز دسترسی» قرار دارد. این صفحه ابزار تعریف و بررسی دسترسی است؛ خودش فرم دعوت نیروی جدید ندارد. برای ساخت یا دعوت حساب کارمند از گردش عضویت فضای کاری استفاده کنید و سپس او را در انتساب نقش‌ها انتخاب کنید.

مدل دسترسی به زبان عملی

در آناما چهار لایه را از هم جدا کنید:

1. ماژول حوزه محصول را مشخص می‌کند؛ مثل فروش، کاتالوگ یا موجودی. فهرست شبیه‌ساز فقط ماژول‌های فعال را نشان می‌دهد.
2. منبع نوع داده یا صفحه را مشخص می‌کند؛ مثل سفارش، پرداخت، محصول یا انبار. * در شبیه‌ساز یعنی کل منبع‌های همان ماژول.
3. عملیات می‌گوید کاربر چه می‌تواند بکند. گزینه‌های موجود شامل مشاهده، ایجاد، ویرایش، حذف، تأیید، ثبت قطعی و خروجی است. اگر فرآیند خاصی مجوز عملیاتی دیگری تعریف کند، آن را از فهرست منبع و backend همان گردش بررسی کنید؛ این هفت گزینه را تمام عملیات‌های احتمالی فرض نکنید.
4. محدوده مشخص می‌کند اجازه روی چه رکوردهایی معتبر است. مدل فعلی از کل مجموعه، شخصیت حقوقی، واحد سازمانی، انبار و فقط رکوردهای خود کاربر پشتیبانی می‌کند. scope_ids برای محدوده‌های انتخابی نگهداری می‌شود. اجازه مشاهده در محدوده یک انبار به معنی اجازه مشاهده همه انبارها نیست.

مجوز هر نقش، ماژول، resource key، آرایه عملیات، effect اجازه/ممانعت، محدوده و اولویت دارد. نقش‌ها و مجوزها داخل tenant ذخیره می‌شوند؛ کد نقش در همان فضای کاری باید یکتا باشد. یک کارمند می‌تواند چند نقش فعال داشته باشد و هر انتساب تاریخ شروع، تاریخ پایان اختیاری، محدوده و وضعیت فعال خود را دارد. این یعنی برای نیروی موقت می‌توان زمان پایان گذاشت، نه اینکه بعداً به یادآوری دستی تکیه کنید.

گردش تنظیم دسترسی

۱. فهرست شغل‌ها را به وظیفه بشکنید

قبل از ایجاد role، کارهای روزمره شغل را بنویسید: چه داده‌ای باید ببیند؟ چه تغییری باید ایجاد کند؟ چه چیزی نیاز به تأیید دارد؟ آیا رکورد باید محدود به انبار یا شخصیت حقوقی باشد؟ یک انباردار ممکن است مشاهده کالا و ثبت اصلاح موجودی را نیاز داشته باشد، اما خروجی تمام داده مشتریان را نه. «همه چیز لازم است تا کارش راه بیفتد» نقش قابل بازبینی نیست.

۲. نقش را تعریف کنید

در «نقش‌های شغلی» یک کد پایدار و نام واضح بسازید و توضیح کوتاه بنویسید. کد باید در همان فضای کاری یکتا باشد؛ آن را با کد دیگری هم‌معنی نسازید. نقش سیستمی در صفحه read-only است و backend اجازه حذف نقش‌ها را نمی‌دهد. برای کار سفارشی یک role عادی بسازید تا معنا و انتسابش قابل نگهداری باشد.

۳. مجوزها را دقیق اضافه کنید

در «مجوزهای دقیق» برای هر role، ماژول و منبع درست را انتخاب کنید. resource_key دقیق‌تر از نام منو است؛ برای نمونه مشاهده سفارش و تأیید بازپرداخت دو کار جدا هستند. عملیات لازم را محدود کنید. effect می‌تواند allow یا deny باشد؛ deny را فقط با دانستن نحوه اولویت‌گذاری و برخورد با مجوزهای دیگر بسازید، چون یک مجوز عمومی و یک استثنای deny ممکن است روی نتیجه نهایی اثر داشته باشند.

محدوده را به داده‌ای محدود کنید که وظیفه پوشش می‌دهد: همه tenant، یک شخصیت حقوقی، واحد سازمانی، انبار یا فقط رکوردهای خود کاربر. scope_ids باید شناسه محدوده‌های مجاز را داشته باشد. تنظیم scope_type=warehouse بدون انتخاب درست انبار، دسترسی مورد انتظار را تضمین نمی‌کند. شرط‌ها و اولویت فقط در صورت نیاز مشخص کار استفاده شوند؛ اگر معنای یک condition در فهرست پنل یا تعریف backend روشن نیست، آن را حدس نزنید.

۴. نقش را با بازه معتبر به کارمند نسبت دهید

در «انتساب نقش» کاربر، نقش، scope و بازه valid_from / valid_until را انتخاب کنید. حساب موردنظر را با نام یا شماره‌ای که در فهرست سازمانی می‌بینید تطبیق دهید؛ یک فرد می‌تواند چند role هم‌زمان داشته باشد، پس انتساب تکراری یا متداخل را قبل از ذخیره مرور کنید. برای کار موقت تاریخ پایان تعیین کنید. وقتی مسئولیت تغییر می‌کند، انتساب غیرلازم را غیرفعال یا به روش پشتیبانی‌شده سازمان اصلاح کنید؛ role را فقط برای پنهان‌کردن یک صفحه حذف نکنید.

۵. نتیجه را در شبیه‌ساز بسنجید

شبیه‌ساز فهرست کارکنان، ماژول فعال، منبع همان ماژول و عملیات را می‌گیرد. پس از «ارزیابی دسترسی»، نتیجه مجاز/ردشده، دلیل و scopeها نمایش داده می‌شود. چند ترکیب مهم را امتحان کنید: مشاهده و ویرایش یک منبع، یک منبع از دو انبار، و کارمند دارای چند role. شبیه‌سازی قبل از تحویل کار به همکار کمک می‌کند تصمیم فعلی policy را ببینید؛ آن را جای آزمون گردش واقعی با حساب کارمند نگیرید، چون کنترل‌های صفحه، API و داده هدف نیز باید درست باشند.

مثال: انباردار یک شعبه

فرض کنید سارا برای ثبت دریافت و اصلاح موجودی انبار «مرکزی» استخدام شده است. مدیر یک role مانند «اپراتور انبار» می‌سازد، مجوز مشاهده محصول و انبار را برای ماژول‌های لازم اضافه می‌کند، و عملیات ثبت/اصلاح موجودی را در منبع انبار با scope همان warehouse می‌دهد. عملیات حذف کالا، مشاهده حقوق و گزارش‌های کامل مشتری به این role اضافه نمی‌شود مگر شغل واقعاً به آن نیاز داشته باشد. سپس role با تاریخ شروع به حساب سارا اختصاص می‌یابد. مدیر در simulator کاربر سارا، ماژول inventory، منبع مرتبط و عملیات update/post را می‌سنجد و یک انبار دیگر را برای اطمینان از محدودیت scope بررسی می‌کند. در پایان سارا با حساب خودش وارد می‌شود تا دسترسی واقعی و منوی قابل مشاهده سنجیده شود.

صفحه «تیم و دسترسی» و شبیه‌ساز

بالای صفحه چهار کارت سریع مسیرهای مدیریت را نشان می‌دهند. «نقش‌های شغلی» قالب قابل تخصیص است؛ «مجوزهای دقیق» درباره resource و action است؛ «انتساب نقش» اتصال کاربر به نقش و scope است؛ «ردپای دسترسی» گزارش عملیات حساس و نتیجه تصمیم را می‌دهد. این‌ها جدول‌های مرتبط‌اند، نه چهار نسخه از یک تنظیم.

شبیه‌ساز، کارمندهای staff/admin را از فهرست کاربران می‌خواند، فقط ماژول‌های enabled را نمایش می‌دهد و با تغییر ماژول فهرست resourceها را محدود می‌کند. نتیجه پاسخ permission simulator شامل allowed، reason، user و scopes است. اگر کارمند در گزینه‌ها نیست، ابتدا مطمئن شوید حساب در فضای کاری درست وجود دارد و role سیستمی آن نوع پشتیبانی‌شده است. اگر ماژول در فهرست نیست، خاموش‌بودن ماژول را در کاتالوگ یا مجوز فعال‌سازی بررسی کنید؛ انتخاب دستی نامی که در فهرست نیست روش دورزدن entitlement نیست.

ردپای دسترسی و بازبینی

گزارش «ردپای دسترسی» برای بررسی actor، ماژول، منبع، عملیات، outcome، شناسه رکورد و زمان است و خود منبع به‌صورت read-only تعریف شده است. پس از تغییر دسترسی حساس، نتیجه‌های allow/deny و تغییرهای ثبت‌شده را با بازه زمانی و resource مربوط تطبیق دهید. ردپا برای بررسی بعدی است، نه برای اصلاح مجوز؛ policy را در role یا capability تغییر دهید.

دسترسی را هنگام تغییر وظیفه بازبینی کنید: roleهای اضافی، تاریخ پایان‌های گذشته، کارمند غیرفعال، scope سازمانی و عملیات write/export را مرور کنید. دسترسی‌های صادراتی، حذف، تأیید یا ثبت قطعی اثر بیشتری دارند و باید به مسئول آن workflow داده شوند. از تقسیم حساب یک کارمند بین چند نفر خودداری کنید؛ انتساب جداگانه باعث می‌شود audit بتواند تغییر را به actor واقعی نسبت دهد.

چرا همکار صفحه یا عملیات را ندارد؟

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

1. کاربر وارد tenant یا فضای کاری درست شده است؟
2. ماژول مربوط فعال است و اشتراک/entitlement آن اجازه استفاده می‌دهد؟
3. یک assignment فعال و در بازه تاریخ معتبر به کاربر وصل است؟
4. در role، module key و resource key دقیق مطابق صفحه است؟
5. action مورد نیاز مجاز است یا deny با اولویت مؤثر وجود دارد؟
6. scope و scope_ids رکورد موردنظر را پوشش می‌دهند؟
7. simulator همان کاربر، همان منبع و همان عملیات را مجاز نشان می‌دهد؟
8. اگر simulator مجاز است اما صفحه همچنان بسته است، session کارمند را تازه کنید و بررسی کنید endpoint همان action را با resource/action مشابه ارزیابی می‌کند؛ موضوع را با زمان، resource، action و شناسه درخواست به مدیر سامانه بدهید.

اگر صفحه نمایش داده می‌شود اما ذخیره رد می‌شود، مجوز مشاهده را با create/update/post یکی نگیرید. اگر scope روی یک انبار است، رکورد متعلق به انبار دیگری را آزمایش نکنید. در تنظیم role از افزایش دسترسی تا * برای حل یک خطا خودداری کنید؛ این کار مشکل موضعی را به دسترسی همه منابع گسترش می‌دهد.

مجوز و ماژول دو شرط جدا هستند

ماژول می‌گوید قابلیت در فضای کاری فعال است؛ role می‌گوید همین کارمند چه عملیات و چه محدوده‌ای دارد. هر دو شرط را بررسی کنید. فعال‌بودن ماژول لزوماً تمام کاربرها را مجاز نمی‌کند و داشتن capability هم ماژول غیرفعال را فعال نمی‌کند. اگر مدیر به فعال‌سازی یا طرح نیاز دارد، آن تصمیم جدا از تغییر role است و باید از تنظیم workspace یا مالک حساب پیگیری شود.

گام بعدی

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