موتور نقش

1) مدل های مجوز

RBAC (کنترل دسترسی مبتنی بر نقش): موضوع نقش ها را دریافت می کند، نقش ها با مجوز ها مرتبط هستند. فقط مدیریت، خوب برای وظایف معمولی.
ABAC (کنترل دسترسی مبتنی بر ویژگی) - راه حل بستگی به ویژگی های موضوع، منابع، عمل و محیط (زمان، IP، منطقه، خطر) دارد. انعطاف پذیر و مقیاس پذیر به قوانین پیچیده.
RBAC + ABAC ترکیبی: نقشها توانایی «اساسی» را به دست میآورند، ویژگیها آن را محدود میکنند (شرایط).
(اختیاری) ReBAC/Relationship-based: گراف رابطه (مالک، عضو تیم، نماینده)، مفید برای اسناد و orgs.

2) معماری: PDP/PEP و جریان

PEP (Policy Enforcement Point): جایی که راه حل اعمال می شود (دروازه API، روش backend، لایه SQL، UI).
PDP (Policy Decision Point): سرویس/کتابخانه ای که «ALLOW/DENY» را با سیاست ها و ویژگی ها محاسبه می کند.
PIP (Policy Information Point): منابع ویژگی (IdP/profile، ابرداده منابع، میزان ریسک، جغرافیایی).
PAP (Policy Administration Point) - رابط اداری/مخزن سیاست (نسخه ها، پیش نویس ها، انتشار).

جریان: درخواست PEP → یک زمینه را تشکیل می دهد → PDP ویژگی های گم شده (از طریق PIP) → تصمیم را محاسبه می کند → PEP اعمال می شود (زمینه های فعال/غیرفعال/قطع) → حسابرسی.

3) مدل داده

• 'subject' (کاربر/سرویس) с атрибутами: 'tenant _ id', 'نقش ها', 'بخش ها', 'سطح ریسک', 'mfa _ verified', 'حوزه', 'ادعا'.
• 'resource' with type and attributes: 'type', 'owner _ id', 'tenant _ id', 'classification' (public/confidential), 'region', 'tags'.
• «عمل»: «خواندن»، «نوشتن»، «حذف»، «صادرات»، «تایید»، «جعل هویت» и т. п.
• 'environment': 'زمان'، 'ip'، 'دستگاه'، 'geo'، 'auth _ strength'، 'business _ context' (канал، тариф).

• 'roles (id, tenant_id, name, inherits []) - سلسله مراتب و الگوهای پشتیبانی.
• 'permissions (id, resource_type, action, constraint?)'.
• 'role _ permissions (role_id, permission_id)'.
• 'assignments (subject_id, role_id, scope)' - دامنه: global/by project/by object.

• 'policy (id, effect = allow' deny, target: {subject, resource, action}, condition: expr, priority, version, status) '.

4) اصول تصمیم گیری

انکار لغو: ممنوعیت های صریح اولویت بندی مجوز.
حداقل امتیاز (PoLP): حداقل دسترسی مورد نیاز را صادر کنید، از طریق شرایط گسترش دهید.
تفکیک وظایف (SoD): ممنوعیت ترکیبی از نقش ها/اقدامات (به عنوان مثال، «پرداخت ایجاد شده» ≠ «دستگیر شده»).
زمینه آگاه: تقویت الزامات در معرض خطر بالاتر (بدون MFA، IP مشکوک).
جبرگرایی: همان زمینه → همان پاسخ ؛ نسخه سیاست را وارد کنید.

5) الگوهای پیاده سازی

5. 1 RBAC ترکیبی → ABAC (تهویه مطبوع)

yaml
Declarative Policy Example
- id: doc_read_own effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","owner"] }
condition: resource. owner_id == subject. id

- id: doc_read_team effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","viewer"] }
condition: subject. team_id in resource. shared_team_ids

- id: doc_read_confidential_external effect: deny target: { action: read, resource. type: document }
condition: resource. classification == "confidential" and subject. tenant_id!= resource. tenant_id priority: 100 # deny high priority

5. 2 ردیف/امنیت در سطح میدان

در سطح پایگاه داده: سیاست های RLS (توسط 'tenant _ id'، 'owner _ id').
در سطح API: filter collections and mask fields if there is no 'allow: read_sensitive_fields'.

5. 3 راه حل های گام به گام

allow if action == "export" and subject. mfa_verified == true else deny

5. 4 تحمل موقت

کمک های مالی با TTL: "تخصیص. expires_at'، دسترسی به «پنجره» (در طول ساعات کار منطقه منبع).

6) عملکرد و ذخیره سازی

کش تصمیم گیری توسط کلید '(subject_hash, resource_key, عمل, policy_version)' با TTL کوتاه.
کش لبه از ویژگی های موضوع (ادعا در نشانه) + ویژگی های منابع تنبل واکشی.
بی اعتبار سازی افزایشی: ناتوانی در حوادث (تغییر نقش، تغییر سیاست، انتقال منابع به «محرمانه»).
چک های دسته ای: برای لیست ها - با یک «فیلتر» (پیش بینی فشار سیاست) ارزیابی کنید تا خط PDP را با خط بکشید.

7) چند مستاجر

در هر میز - 'tenant _ id'; سیاست های پیش فرض دسترسی به اجاره نامه را محدود می کند.
مدیران اجاره فقط نقش/حقوق اجاره نامه خود را مدیریت می کنند.
دسترسی متقابل اجاره - به طور انحصاری از طریق دعوت صریح/به اشتراک گذاری با لغو صریح.

8) مدیریت سیاست و چرخه عمر

نسخه: "سیاست. نسخه 'در پاسخ PDP، فروشگاه در ممیزی.
Environments: draft → canary (بخشهایی از حالت ترافیک/سایه) → prod.
ماتریس تست: جداول حقیقت با نقش ها/ویژگی های کلیدی (آزمون های قرارداد).
مدیریت تغییر: درخواست های مربوط به سیاست ها را با بررسی های امنیتی/انطباق ادغام کنید.

9) حسابرسی و مشاهده پذیری

Журнал решений: «decision _ id»، «subject»، «action»، «resource _ ref»، «result»، «matched _ policies»، «policy _ version»، «attributes _ digest».
معیارهای: QPS PDP، تاخیر P95، نرخ کش، انکار سهم، نرخ گام به گام، حوادث SoD.

ردیابی: فاصله در هر تماس PDP ؛ ارتباط با درخواست API

تکرار: توانایی «پخش» تصمیمات تاریخی در نسخه جدید سیاست (بررسی ایمنی).

10) ادغام با احراز هویت و نشانه

هویت - از IdP (OIDC/SAML). توکن ها حداقل ویژگی ها را دارند: «sub»، «tenant»، «role»، «auth _ time»، «amr»، «scopes».
برای ABAC، نشانه های «سنگین» را از طرف سرور (PIP) بکشید تا نشانه را باد نکنید.
نشانه منابع امضا (قابلیت/دعوت نامه) - برای نمایندگی به شدت محدود است.

11) کد شبه PDP (ساده شده)

python def decide(subject, resource, action, env, policies):
matched = []
effect = "deny"
Explicit DENYs with priority for p in sorted (policies, key = lambda x: x.priority, reverse = True):
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
if p. effect == "deny":
return Decision("deny", matched, p. version)
Looking for ALLOW for p in policies:
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
effect = "allow"
break return Decision(effect, matched, max_version(matched, policies))

12) ضد الگوهای

«نقش = صفحه» (صدها نقش کوچک بدون یک مدل دامنه).
سیاست های ذخیره فقط در کد بدون نسخه/ممیزی.
عدم انکار لغو و SoD → افزایش خطر تقلب.
قوانین user _ id 'in لیستهای سخت (به جای ویژگیها/روابط).
بدون فیلتر کردن لایه داده (RLS) فقط با فیلتر UI.
هماهنگ سازی نقش ها از طریق اسکریپت های دستی بدون حوادث و ناتوانی حافظه پنهان.

13) موارد و دستور العمل

13. 1 پوشش سطح:

allow read invoice when subject. roles includes "support"
mask fields ["card_last4", "billing_email"] unless subject. role == "finance"

13. 2 صادرات داده ها فقط با MFA:

allow export if subject. mfa_verified and env. ip in cidr("203. 0. 113. 0/24")

13. 3 بنابراین:

deny approve_payment if subject. performed_actions includes ("create_payment" within last 24h)

13. 4 نمایندگی (توکن محدود):

توکن قابلیت شامل "resource _ id"، "actions = [" خواندن "]،" expires _ at "،" aud "است. PEP تایید امضا و مهلت.

14) تست

تست واحد سیاست ها: جداول حقیقت با ترکیب های اصلی

Property-based: تولید ویژگی های تصادفی برای پیدا کردن «سوراخ».
تستهای طلایی: تعیین مجموعهای از راهحلها برای نقاط پایانی بحرانی.
Canary/Shadow: ارزیابی موازی نسخه های قدیمی و جدید سیاست ها با ورود به سیستم اختلافات.

15) قابلیت های مرتبط بخش «معماری و پروتکل ها»

احراز هویت و مجوز (OIDC/OAuth2)

مدیریت رضایت نامه

نشانه گذاری و مدیریت کلید

قابلیت مشاهده: گزارش ها، معیارها، ردیابی ها

مسیریابی جغرافیایی و محلی سازی

در حالت استراحت/در رمزگذاری حمل و نقل

16) چک لیست معمار

1. آیا نقش های موضوعی و سلسله مراتب آنها تعریف شده است ؟

2. آیا یک مدل ترکیبی وجود دارد: نقش ها + شرایط ویژگی ها ؟

3. پیاده سازی PDP با انکار لغو، SoD و گام به بالا ؟

4. PEP کجاست ؟ (دروازه، باطن، پایگاه داده، UI) - آیا در همه جا یکنواخت است ؟

5. آیا حافظههای نهان راه حل و ناتوانی رویداد پیکربندی?
6. آیا سیاست های نسخه, تست شده, نورد توسط فرایند?

7. آیا تصمیمات حسابرسی، معیارها و ردیابی ها فعال هستند ؟

8. چند اجاره نامه و RLS/زمینه پوشش پشتیبانی می شود ؟

9. يه دفتر ثبت حوادث و رگرسيون سياسي داري ؟

نتیجه گیری

RBAC کنترل پذیری را فراهم می کند، ABAC زمینه و دقت را فراهم می کند. با ترکیب نقش ها با شرایط ویژگی، به اشتراک گذاری PDP/PEP، اجرای ذخیره سازی، حسابرسی و آزمایش سیاست، مجوز را به عنوان یک قابلیت پلت فرم ایجاد می کنید: قابل پیش بینی، قابل اثبات و مقیاس پذیر برای الزامات محصول و قانونی.