مجوزدهی یک مدل دامنه است، نه جدول دسترسی
چرا معماری مجوزدهی باید هویت، نقش، دامنه سازمانی، زمینه منبع، سیاست و اعمال تصمیم را در تمام لایه‌های نرم‌افزار به هم متصل کند.
در این مقاله
بسیاری از پروژه‌های مجوزدهی با یک فایل اکسل شروع می‌شوند. نقش‌ها در یک محور، مجوزها در محور دیگر و مجموعه‌ای از علامت‌ها ظاهراً به این پرسش پاسخ می‌دهند که «چه کسی چه کاری می‌تواند انجام دهد؟»
ماتریس مفید است، اما مدل مجوزدهی نیست.
این جدول درباره زمینه اعتبار یک مجوز، نحوه دریافت نقش، سازمان یا منبع تحت پوشش، زمان فعال شدن دسترسی، مسیر رسیدن سیاست به API و شواهد باقی‌مانده از تصمیم توضیح چندانی نمی‌دهد. چند مفهوم متفاوت نیز معمولاً پشت واژه راحت و آشنای «نقش» پنهان می‌شوند.
با رشد سیستم، این تمایزهای فراموش‌شده به کنترل‌های تکراری، توکن‌های بزرگ، رابط‌های ناسازگار، استثناهای پشتیبانی و تصمیم‌های سیاستی پنهان در کد تبدیل می‌شوند.
مجوزدهی زمانی بهتر عمل می‌کند که آن را یک دامنه بدانیم: مدلی مرتبط از سوژه‌ها، مسئولیت‌ها، دامنه‌ها، منابع، سیاست‌ها، تصمیم‌ها و نقاط اعمال.
یک مجوز به‌تنهایی پاسخ نمی‌دهد «آیا این شخص می‌تواند این عمل را انجام دهد؟» سیستم باید بداند شخص نماینده چه زمینه‌ای است، عمل کجا معتبر است، کدام منبع درگیر است و چه سیاستی اکنون اعتبار دارد.
احراز هویت یک سوژه می‌دهد، نه یک تصمیم
احراز هویت، هویت را ایجاد یا تأیید می‌کند. مجوزدهی ارزیابی می‌کند که آیا سوژه احرازشده می‌تواند عملی مشخص را در زمینه‌ای مشخص انجام دهد.
این تفاوت ساده به نظر می‌رسد، اما طراحی‌ها مرتب آن را محو می‌کنند. توکن نام نقش دارد و هر سرویس همان نام را تصمیم کامل دسترسی می‌داند. کاربر عضو یک واحد است و رابط فرض می‌کند همه رکوردهای آن واحد قابل مشاهده‌اند. پرچم administrator اضافه می‌شود و سیاست به یک میان‌بر دائمی تبدیل می‌گردد.
این میان‌برها پرسش‌های واقعی مجوزدهی را مدل نمی‌کنند:
- سوژه: چه شخص یا سیستمی عمل را درخواست کرده است؟
- عمل: چه عملیاتی در حال انجام است؟
- منبع: کدام شیء، رکورد، قابلیت یا مرز تحت تأثیر قرار می‌گیرد؟
- زمینه: درخواست از کدام سازمان، تخصیص، کانال، زمان یا وضعیت فرایند آمده است؟
- سیاست: کدام نسخه از کدام قاعده معتبر است؟
- تصمیم: نتیجه اجازه، منع، مشروط یا نامشخص است؟
- شواهد: برای توضیح نتیجه در آینده چه چیزی باید ثبت شود؟
هویت می‌تواند معتبر باشد، در حالی که عمل درخواستی مجاز نیست. معماری خوب این تمایز را در همه لایه‌ها حفظ می‌کند.
یک واژه «نقش» اغلب سه مدل را پنهان می‌کند
سازمان از نقش برای توصیف مسئولیت استفاده می‌کند: مدیر شعبه، کنترل‌کننده مالی یا کارشناس پشتیبانی. نرم‌افزار از نقش برای بسته‌بندی قابلیت‌ها بهره می‌برد: PaymentApprover، IdentityReviewer یا ReportReader. شخص همچنین از طریق یک تخصیص عمل می‌کند: مدیر شعبه الف در یک بازه زمانی مشخص.
این مفاهیم مرتبط‌اند، اما یکسان نیستند.
نقش سازمانی
جایگاه یا مسئولیت شخص را در سازمان توصیف می‌کند. ممکن است از سامانه منابع انسانی یا ساختار سازمانی بیاید و بر شرایط دریافت دسترسی اثر بگذارد.
نقش سیستمی
مفهومی نرم‌افزاری است که مجوزها یا مسئولیت‌های سیاستی را گروه‌بندی می‌کند. باید بازتاب چیزی باشد که سیستم لازم است اعمال کند، نه نسخه‌ای مستقیم از چارت سازمانی.
تخصیص زمینه‌مند
سوژه و نقش را به یک دامنه، زمان، نمایندگی، محصول، بخش مشتری یا مجموعه منبع متصل می‌کند. یک شخص می‌تواند در یک شعبه همان نقش سیستمی را داشته باشد و در شعبه‌ای دیگر هیچ اختیاری نداشته باشد.
فشرده کردن هر سه مفهوم در یک رشته نقش، پیاده‌سازی اولیه را آسان و رفتار آینده را دشوار می‌کند. صریح نگه داشتن آن‌ها، مدیریت چرخه عمر، دسترسی تفویضی، تفکیک وظایف و تصمیم‌های قابل ممیزی را ممکن می‌سازد.
دامنه، مجوز را واقعی می‌کند
مجوز بدون دامنه معمولاً بیش از اندازه گسترده است.
«مشاهده حساب» می‌تواند به معنای مشاهده همه حساب‌ها، حساب‌های یک مشتری، حساب‌های تحت خدمت یک شعبه، حساب‌های تخصیص‌یافته به یک پرونده یا فقط حساب انتخاب‌شده در یک فرایند تأییدشده باشد. فعل و نام منبع یکسان‌اند، اما مرز امنیتی کاملاً متفاوت است.
دامنه می‌تواند از منابع گوناگونی بیاید:
| منبع دامنه | نمونه | پرسش طراحی |
|---|---|---|
| سازمان | شرکت، منطقه، شعبه، تیم | دسترسی شامل زیرمجموعه‌هاست یا فقط همان واحد؟ |
| رابطه منبع | مالک، مسئول، بازبین | رابطه چگونه ایجاد و پایان داده می‌شود؟ |
| تراکنش | درخواست یا گردش کار جاری | دسترسی پس از پایان فرایند باقی می‌ماند؟ |
| تفویض | مسئولیت موقت | چه کسی آن را تأیید کرده و چه زمانی منقضی می‌شود؟ |
| ویژگی | سطح ریسک، محصول، کانال | مقدار مرجع در کجا نگهداری می‌شود؟ |
قواعد دامنه به مدل کسب‌وکار تعلق دارند. تبدیل آن‌ها به فیلترهای پراکنده query، مشاهده و اثبات کامل بودنشان را تقریباً ناممکن می‌کند.
چرخه عمر مجوز را مدل کنید
دسترسی یک‌بار ایجاد و برای همیشه رها نمی‌شود؛ چرخه عمر دارد:
- واجد شرایط بودن: سوژه شرایط سازمانی یا سیاستی دریافت نقش را دارد.
- تخصیص: نقش و دامنه درخواست یا اختصاص داده می‌شوند.
- تأیید: تصمیم‌های نظارتی یا تفکیک وظایف انجام می‌شوند.
- فعال‌سازی: تخصیص مؤثر و در دسترس سامانه تصمیم‌گیری قرار می‌گیرد.
- استفاده: سرویس‌ها عمل را در برابر سیاست و زمینه فعال ارزیابی می‌کنند.
- بازبینی: ضرورت ادامه تخصیص و شیوه استفاده بررسی می‌شود.
- تعلیق یا لغو: دسترسی به دلیل تغییر شرایط غیرفعال می‌شود.
- انقضا: دسترسی زمان‌دار بدون وابستگی به پاک‌سازی دستی پایان می‌یابد.
هر انتقال به بازیگر، قاعده، زمان و منبع حقیقت نیاز دارد. بدون وضعیت‌های چرخه عمر، «ثبت‌شده در پایگاه داده» به‌اشتباه معادل «در همه‌جا مؤثر» گرفته می‌شود؛ به‌ویژه وقتی توکن، cache و سرویس توزیع‌شده وجود دارد.
توکن را آگاه‌کننده نگه دارید، نه تصمیم‌گیر نهایی
توکن حامل مناسبی برای هویت و ادعاهای نسبتاً پایدار است، اما ظرف مناسبی برای تمام تصمیم‌های ممکن دسترسی نیست.
اگر همه مجوزها و روابط سازمانی در توکن کپی شوند، توکن بزرگ می‌شود، لغو با تأخیر اثر می‌کند، تغییر سیاست تا refresh منتظر می‌ماند و سرویس‌ها ادعاها را متفاوت تفسیر می‌کنند. اگر اطلاعات بیش از اندازه کم باشد، هر درخواست می‌تواند وابستگی پرهزینه‌ای به سرویس مرکزی ایجاد کند.
تعادل مناسب وابسته به سیستم است، اما اطلاعات باید آگاهانه دسته‌بندی شوند:
- ادعاهای شناسایی سوژه و نشست
- زمینه پایداری که می‌تواند همراه درخواست حرکت کند
- روابط پویایی که به ارزیابی تازه نیاز دارند
- ویژگی‌های منبع که متعلق به دامنه مقصدند
- تصمیم‌هایی که باید متمرکز یا به شکل سازگار توزیع شوند
توکن ورودی تصمیم است، نه خود تصمیم.
اعمال سیاست را میان سرویس و رابط هماهنگ کنید
مجوز باید جایی اعمال شود که رفتار حفاظت‌شده رخ می‌دهد؛ معمولاً در مرز سرویس یا دامنه. رفتار رابط نیز مهم است، اما دلیل متفاوتی دارد.
رابط نباید عملی را نشان دهد که کاربر قادر به تکمیل آن نیست. در جای مناسب باید کمبود اختیار را توضیح دهد و وقتی کاربر در چند دامنه عمل می‌کند، زمینه را صریح دریافت کند. این انتخاب‌ها تجربه کاربری را بهتر و درخواست ناموفق را کمتر می‌کنند، اما جایگزین اعمال در سمت سرور نیستند.
یک مسیر منسجم چنین است:
هویت ← تخصیص فعال ← زمینه درخواست ← ارزیابی سیاست ← اعمال در سرویس ← نمایش در رابط ← شواهد ممیزی
همه لایه‌ها باید واژگان و شناسه تصمیم یکسان داشته باشند؛ وگرنه رابط عملی را پنهان می‌کند که سرویس مجاز می‌داند یا سرویسی عملی را رد می‌کند که رابط با اطمینان پیشنهاد داده است.
در مطالعه موردی مدیریت دسترسی و مجوزدهی توضیح داده‌ام که چگونه نقش سازمانی، دامنه زمینه‌ای، توکن، رفتار سرویس و نمایش رابط در یک مدل مرحله‌بندی‌شده به هم متصل می‌شوند.
منع دسترسی نیز یک نتیجه طراحی‌شده است
درخواست ردشده الزاماً خطا نیست؛ ممکن است نتیجه درست سیاست باشد. سیستم باید میان این حالت‌ها تفاوت بگذارد:
- احرازنشده و احرازشده اما غیرمجاز؛
- زمینه ناقص و عمل ممنوع؛
- تخصیص غیرفعال و رابطه نامعتبر با منبع؛
- منع سیاست و در دسترس نبودن زیرساخت تصمیم.
این تفاوت‌ها بر امنیت، راهنمایی کاربر، تشخیص پشتیبانی، رفتار تکرار و ممیزی اثر دارند. ارتباط نیز باید حساب‌شده باشد: پاسخ باید به کاربر مجاز برای بازیابی کمک کند، بدون آنکه اطلاعات حفاظت‌شده را برای فرد غیرمجاز افشا کند.
پرسش‌هایی که مدل ضعیف را آشکار می‌کنند
پیش از تأیید طراحی بپرسید:
- آیا یک شخص می‌تواند در چند زمینه سازمانی عمل کند؟
- آیا دو نقش سازمانی می‌توانند به یک مسئولیت سیستمی برسند؟
- آیا یک نقش فقط بر بخشی از منابع اعمال می‌شود؟
- کدام تغییرها باید فوراً مؤثر شوند؟
- پس از لغو، نشست فعال چه می‌شود؟
- چه کسی دسترسی را تخصیص، تأیید، تفویض، بازبینی و لغو می‌کند؟
- کدام روابط مرجع‌اند و چقدر باید تازه باشند؟
- آیا سرویس می‌تواند دلیل اجازه یا منع را توضیح دهد؟
- آیا jobها و هویت سرویس‌ها کنار کاربران انسانی مدل شده‌اند؟
- آیا هر تصمیم رابط در یک مرز قابل اعتماد اعمال می‌شود؟
اگر پاسخ‌ها میان تیم‌ها و کدها پراکنده‌اند، سیستم کنترل مجوز دارد، اما هنوز معماری مجوزدهی ندارد.
از علامت‌های جدول تا یک سیستم سیاست منسجم
ماتریس نقش و مجوز همچنان مفید است؛ یک نمای مهم از مدل و ابزاری عملی برای بازبینی است. اشتباه، برابر دانستن آن با کل مدل است.
معماری ماندگار، معنای سازمانی را به مسئولیت نرم‌افزاری، مسئولیت را به تخصیص زمینه‌ای، تخصیص را به سیاست، سیاست را به اعمال سرویس و اعمال را به شواهد قابل فهم متصل می‌کند.
این همان طراحی دامنه است. وقتی صریح شود، پیاده‌سازی مجوزها روشن‌تر، تغییرشان امن‌تر و توضیح رفتارشان بسیار آسان‌تر خواهد بود.