RBAC، Default Deny و Least Privilege

نام یک Role به‌تنهایی مدرک authorization نیست. ممکن است کاربر درست احراز هویت شده باشد و حتی رابط کاربری یک عمل را پنهان کند، اما اگر policy در مرز محافظت‌شده ناقص باشد تصمیم سمت سرور همچنان می‌تواند اشتباه باشد. این درس یک مدل authorization محدود، قابل بازرسی و کاملاً synthetic می‌سازد و فقط در fixture محلی آن را آزمایش می‌کند.

1. مسئله قبل از نام Roleها

سناریو یک project workspace مصنوعی است. سه Role داریم: Viewer، Editor و WorkspaceAdmin. Resourceها به یک workspace تعلق دارند. Actionهای محافظت‌شده شامل خواندن project، خواندن یا نوشتن file و مدیریت memberها هستند. سؤال امنیتی این نیست که «Editor معمولاً چه کارهایی می‌کند؟» سؤال دقیق این است: آیا این subject مجاز است این action را روی این resource و در این context انجام دهد؟

2. خروجی محدود درس

خروجی شما Authorization Decision Matrix v1 است. هر ردیف تعیین‌کننده باید Subject/Role، Resource Scope، Action، Explicit Allow Rule، Default Decision، Enforcement Point، Positive Probe، Negative Probe، Evidence مشاهده‌شده و Residual Policy Question را مشخص کند.

3. این درس چه چیزی را ثابت نمی‌کند

Fixture محلی ثابت نمی‌کند production امن است. موفقیت authentication به‌معنای authorization نیست. پنهان بودن گزینه در UI کنترل authorization محسوب نمی‌شود. فرض نمی‌کنیم RBAC برای همه policyها بهترین مدل است. یک Role ادمین همه‌کاره نیز میان‌بر قابل قبول Least Privilege نیست.

4. Authorization به‌صورت decision tuple

درخواست authorization را به شکل (subject, action, resource, context) ببینید. Role فقط یکی از ورودی‌های تصمیم است. Workspace membership یا رابطه با resource هم می‌تواند بخشی از context باشد. تصمیم باید بر اساس policy صریح و در enforcement point معتبر گرفته شود.

5. Subject و Role

Subject همان caller واقعی است. Role مجموعه‌ای از permissionهای مربوط به یک وظیفه را گروه‌بندی می‌کند. در fixture، Viewer محتوای workspace را می‌خواند، Editor علاوه بر آن file را تغییر می‌دهد و WorkspaceAdmin memberها را مدیریت می‌کند. Role نباید context خود subject، مثل workspace او، را حذف کند.

6. Resource و Action

Permission زمانی دقیق است که به action و resource مشخص وصل باشد. file.read با file.write یکی نیست. member.manage نیز حوزه اختیار دیگری است. Permissionهای مبهم، بررسی Least Privilege را ضعیف می‌کنند.

7. Explicit Allow Rule

Allow rule باید قابل مشاهده و بررسی باشد. Evaluator محلی یک map صریح Role به permission و یک workspace-scope check دارد. اگر allow condition در policy وجود ندارد، نباید آن را از menu، نام Role یا login موفق نتیجه گرفت.

8. Default Deny

اگر هیچ allow rule صریح match نشود، نتیجه deny است. بنابراین Action جدید یا فراموش‌شده در مدل محدود به‌صورت fail-closed رفتار می‌کند. Lab یک unknown-action probe دارد تا نشان دهد نبود rule به permission تصادفی تبدیل نمی‌شود.

9. Least Privilege

Least Privilege یعنی هر Role فقط permissionهای لازم برای وظیفه خودش را داشته باشد. هدف صرفاً «کم بودن permissionها» نیست. Evidence باید permissionها را به task ownership وصل کند و privilege اضافیِ مجاور را آشکار سازد.

10. مرز عمودی

Vertical privilege boundary بین سطح‌های مختلف اختیار قرار دارد. در fixture، Editor می‌تواند file را بنویسد اما memberها را مدیریت نمی‌کند. افزودن member.manage به Editor گسترش عمودی اختیار است و باید در audit دیده شود.

11. مرز افقی

Horizontal boundary بین resourceهای هم‌نوع اما متعلق به scopeهای متفاوت است. یک Viewer در workspace w1 نباید فقط به‌دلیل داشتن file.read بتواند file متعلق به w2 را بخواند. هم permission Role و هم resource scope باید برقرار باشند.

12. Enforcement Point

Enforcement point معتبر در این درس policy evaluator سمت سرورِ synthetic است. UI می‌تواند Action را نشان ندهد، اما پنهان کردن button کنترل امنیتی نیست. Direct synthetic request نیز باید از همان policy عبور کند.

13. مدل ذهنی

جریان را این‌طور ببینید: authenticated subject → policy input → authorization decision → protected action. مسیر deny یک branch درجه‌اول است. Audit evidence فقط آنچه دیده شده را ثبت می‌کند و observation محلی را به claim کلی امنیتی تبدیل نمی‌کند.

14. Baseline Matrix

با کوچک‌ترین policy لازم شروع کنید. Viewer فقط read دارد. Editor علاوه بر آن file.write دارد. WorkspaceAdmin permissionهای member management را اضافه می‌کند. همه Roleها در fixture به workspace خود محدود هستند. Permission را برای «شاید بعداً لازم شود» اضافه نکنید.

15. Positive Evidence

Positive probe نشان می‌دهد task مجاز همچنان کار می‌کند. مثل خواندن file همان workspace توسط Viewer یا نوشتن file همان workspace توسط Editor. این evidence لازم است چون policyای که همه‌چیز را deny کند کاربردی نیست.

16. Negative Evidence

Negative probe به همان اندازه مهم است. Lab unknown action، دسترسی cross-workspace و تلاش Editor برای member management را بررسی می‌کند. نتیجه باید classification دقیق deny را نشان دهد، نه فقط یک test failure کلی؛ token مربوط به vertical deny برابر VERTICAL_PRIVILEGE_DENIED است.

17. Mutation: Action جدید بدون Rule

یک Action مصنوعی مثل project.archive اضافه کنید، بدون اینکه allow rule بسازید. خروجی مورد انتظار DEFAULT_DENY است. این رفتار policy را با evidence نشان می‌دهد و به default فرضی framework تکیه نمی‌کند.

18. Mutation: Over-Grant عمودی

به‌صورت موقت member.manage را به Editor بدهید. Evaluator ممکن است آن Action را مجاز کند، اما least-privilege audit باید Role را over-granted تشخیص دهد. Authorization فقط بررسی «آنچه policy اجازه می‌دهد» نیست؛ باید «آنچه policy باید اجازه دهد» هم بازبینی شود.

19. Mutation: پنهان کردن UI کنترل نیست

member.manage را در UI مصنوعی برای Editor پنهان کنید و سپس direct local request اجرا کنید. Policy سمت سرور همچنان آن را deny می‌کند. این آزمایش presentation را از enforcement جدا می‌کند.

20. Authorization Decision Matrix v1

برای هر ردیف مهم این فیلدها را ثبت کنید: Subject/Role، Resource Scope، Action، Explicit Allow Rule، Default Decision، Enforcement Point، Positive Probe، Negative Probe، Evidence و Residual Policy Question. خالی بودن یک فیلد تعیین‌کننده یعنی تصمیم نهایی هنوز evidence کافی ندارد.

21. Observation در برابر Inference

این جمله observation است: «در fixture محلی، درخواست X با HORIZONTAL_SCOPE_DENIED رد شد.» این جمله inference اثبات‌نشده است: «production در برابر horizontal privilege escalation امن است.» این دو را در artifact جدا نگه دارید.

22. Model Fit: جایی که RBAC کافی نیست

وقتی policy شدیداً به رابطه resource، tenant ownership، attribute، زمان یا workflow state وابسته باشد، Role به‌تنهایی ممکن است کافی نباشد. این درس ABAC یا ReBAC کامل آموزش نمی‌دهد. Residual Policy Question را ثبت کنید و به‌جای role explosion دامنه را بی‌دلیل گسترش ندهید.

23. Transfer Case

در یک support system مصنوعی Roleهای Agent، Supervisor و Billing روی ticketهای tenant-scoped وجود دارند. یک matrix حداقلی جدید بسازید. حداقل یک تصمیم را مشخص کنید که Role به‌تنهایی کافی نیست، چون tenant، assignment یا رابطه دیگری با resource اهمیت دارد.

24. Checkpointهای ارزیابی

باید بتوانید authorization decision tuple را توضیح دهید، Default Deny را توجیه کنید، حداقل permission set را دفاع کنید، horizontal و vertical denial را تفکیک کنید، enforcement point معتبر را مشخص کنید و transfer را بدون کپی کردن matrix اولیه حل کنید.

25. Freshness و Source Boundary

Guidance جاری authorization در این درس به frozen snapshot منبع OWASP-AUTHORIZATION با تاریخ retrieval برابر 2026-09-02 محدود است. Review due آن 2026-10-02 است. Query 1 قبل از این تاریخ اجرا می‌شود؛ بنابراین re-search یا source-scope expansion انجام نمی‌شود.

26. معیار تکمیل

درس زمانی کامل است که positive و negative probe هر دو حفظ شوند، deny path قابل مشاهده باشد، least-privilege drift قابل تشخیص باشد، observation از inference جدا شود، matrix کامل باشد و transfer به‌صورت مستقل تصمیم‌گیری شود. پذیرش policy در production خارج از دامنه این درس است.