سطوح دسترسی در نرمافزار سازمانی
در هر پروژهٔ سازمانی، جلسهای هست که در آن کارفرما میگوید «سطوح دسترسی میخواهیم» و همه سر تکان میدهند، انگار یک قلم مشخص است.
نیست. زیر آن جمله دستکم سه سؤال متفاوت پنهان است و هر کدام هزینه و پیچیدگی خودش را دارد.
سه چیزی که یکی نیستند
نقش یعنی این کاربر که است — «کارشناس فروش»، «مدیر انبار». برچسبی روی آدم.
مجوز یعنی چه کاری قابل انجام است — «ثبت سفارش»، «حذف مشتری»، «دیدن گزارش سود». برچسبی روی عملیات.
محدودهٔ داده یعنی روی کدام رکوردها — «سفارشهای شعبهٔ اصفهان»، «مشتریان خودم»، «فقط دورهٔ مالی جاری».
مدل نقشمحور یا همان RBAC دو مورد اول را به هم وصل میکند: نقش مجموعهای از مجوزها را میگیرد، کاربر یک یا چند نقش میگیرد. این تا اینجا درست و کافی است.
مورد سوم چیزی است که تقریباً هیچکس در جلسهٔ اول نمیگوید و تقریباً همیشه لازم میشود.
جایی که نقش کم میآورد
فرض کنید سامانهٔ فروش دارید و نقش «کارشناس فروش» میتواند سفارش ببیند.
سؤال بعدی همیشه این است: کدام سفارشها؟ کارشناس منطقهٔ شمال نباید سفارشهای منطقهٔ جنوب را ببیند، هرچند نقشش دقیقاً همان است. مدیر شعبه باید همهٔ شعبهٔ خودش را ببیند و نه شعبهٔ دیگر. مدیرعامل همه را میبیند.
اگر بخواهید این را با نقش حل کنید، به «کارشناس فروش شمال»، «کارشناس فروش جنوب»، «کارشناس فروش شرق» میرسید و با اضافهشدن هر منطقه و هر واحد، تعداد نقشها ضرب میشود. سازمانی با پنج نقش و ده شعبه، پنجاه نقش پیدا میکند که نگهداریشان از خود سامانه سختتر است.
جواب درست این است که محدودهٔ داده را از نقش جدا کنید: کاربر یک نقش دارد («کارشناس فروش») و یک یا چند محدوده («منطقهٔ شمال»). مجوز از نقش میآید، فیلتر از محدوده.
این تصمیم را باید از ابتدا گرفت. افزودن محدودهٔ داده به سامانهای که سالهاست بدون آن کار میکند یعنی بازبینی تکتک پرسوجوها، چون هر کوئریای که شرط محدوده را جا بیندازد یک نشت داده است — و از بیرون هیچ فرقی با کوئری درست ندارد.
بررسی مجوز کجا انجام میشود
جواب کوتاه: در سرور، در هر درخواست، و بهازای رکورد.
پنهانکردن دکمه در رابط کاربری، تجربهٔ کاربری است، نه امنیت. کاربری که آدرس را مستقیم صدا بزند، دکمهای لازم ندارد. شایعترین رخنهای که در امنیت نرمافزار گفتیم دقیقاً همین است: کاربر وارد شده، پس فرض شده مجاز است.
و بررسی «آیا این کاربر میتواند فاکتور ببیند؟» کافی نیست. سؤال درست «آیا این کاربر میتواند این فاکتور را ببیند؟» است. اولی در میانافزار قابل انجام است؛ دومی نه — چون تا رکورد را نخوانده باشید، نمیدانید مال کیست.
الگویی که در پروژههایمان جواب داده این است: فیلتر محدوده در لایهٔ دسترسی به داده اعمال شود، نه در هر سرویس. یعنی هیچ کوئریای بدون شرط محدوده از آن لایه عبور نکند. اگر این را به عهدهٔ نظم برنامهنویس بگذارید، روزی که تیم عوض شود شرط جا میماند.
مجوز را ریز کنیم یا درشت؟
وسوسهای هست که برای هر عملیات یک مجوز جدا تعریف کنید — «مشاهدهٔ مشتری»، «ویرایش مشتری»، «حذف مشتری»، ضربدر هر موجودیت. سامانهٔ متوسط به سیصد مجوز میرسد و صفحهٔ تعریف نقش، جدولی میشود که هیچکس نمیتواند بخواندش.
نتیجهٔ عملیاش این است که مدیر سامانه از ترس، به همه دسترسی «مدیر» میدهد. یعنی سیستم مجوزی که ساختید نتیجهٔ معکوس داد.
توصیهٔ ما: مجوز را حول کارِ کاربر تعریف کنید، نه حول جدولهای پایگاه داده. «مدیریت سفارش» یک مجوز است که ثبت و ویرایش و لغو را با هم میآورد، چون کسی که سفارش ثبت میکند عملاً باید بتواند اصلاحش هم بکند. جدا کردن آنها فقط زمانی ارزش دارد که سازمان واقعاً این دو کار را به دو نفر داده باشد.
استثنای مهم: عملیات پرخطر جدا بماند. حذف، تغییر قیمت، تخفیف بیش از حد، تأیید پرداخت. اینها را جدا نگه دارید چون همانهایی هستند که روزی باید بگویید چه کسی انجامش داده.
چیزهایی که در سازمان واقعی لازم میشود
جانشینی. مدیر به مرخصی میرود و کسی باید تأییدهایش را انجام دهد. اگر راهحلی برایش نگذارید، رمز عبورش را به همکارش میدهد — و از آن لحظه هر لاگی که دارید بیمعنی است. جانشینی موقت و تاریخدار را در طراحی ببینید.
گردش تأیید. «کارشناس ثبت میکند، مدیر تأیید میکند» یک مجوز نیست، یک فرایند است. اینها را با مدل دسترسی قاطی نکنید؛ وضعیت سند جای درستش است.
دسترسی موقت. پیمانکار، حسابرس، کارآموز. دسترسیای که تاریخ انقضا ندارد، همیشه میماند. اگر میشود، تاریخ پایان را اجباری کنید.
قطع دسترسی هنگام خروج. این را در ورود یکپارچه گفتیم و اینجا هم مهمترین بند است: بدون یک نقطهٔ مرکزی، همیشه یکی از سامانهها فراموش میشود.
لاگ تغییرات دسترسی
سه رویداد را باید ثبت کنید، حتی اگر هیچ لاگ دیگری نداشته باشید:
- چه کسی به چه کسی چه دسترسیای داد، و کی.
- ورودهای ناموفق پیاپی.
- دسترسی به دادههای حساس — گزارش مالی، فهرست مشتریان، اطلاعات پرسنلی.
دلیلش ساده است: وقتی اتفاقی میافتد، اولین سؤال «چه کسی دسترسی داشت؟» است و دومی «از کی؟». سامانهای که این را ثبت نکرده، فقط میتواند حدس بزند.
در آرا پورتال این لاگ بخشی از خود سکو است، نه چیزی که هر پروژه دوباره بسازد — چون تجربه نشان داده اگر اختیاری باشد، در فشار تحویل اولین چیزی است که حذف میشود.
از کجا شروع کنیم
اگر پروژهای نو دارید:
۱. نقشها را کم و واقعی تعریف کنید — پنج تا شش نقش برای شروع کافی است. ۲. مجوزها را حول کار کاربر ببندید، نه حول جدولها. ۳. محدودهٔ داده را در مدل پیشبینی کنید، حتی اگر امروز همه همهچیز را میبینند. ۴. بررسی را در سرور و در لایهٔ داده بگذارید. ۵. تغییر دسترسی را لاگ کنید.
مورد سوم آن است که اگر جا بماند، سال بعد یک پروژهٔ مستقل میشود. بقیه را میشود بعداً هم اضافه کرد.
اگر سامانهای دارید که همین حالا این مشکل را نشان میدهد — نقشهایی که ضرب شدهاند یا دسترسیهایی که کسی جرئت نمیکند کمشان کند — بازطراحی مدل دسترسی معمولاً کوچکتر از چیزی است که به نظر میرسد، به شرطی که قبل از بزرگترشدن سامانه انجام شود. این یکی از کارهایی است که در نرمافزار سفارشی مرتب انجام میدهیم.