کنترل دسترسی و RBAC در API

1) چرا کنترل دسترسی API

مجوز پاسخ به این سوال است: «آیا این بازیگر می تواند این عمل را در این منبع انجام دهد ؟» ». خطاها منجر به نشت BOLA/IDOR، تشدید حقوق و نقض الزامات قانونی می شود. هدف این است که برای ساخت یک مدل چند سطح: محیط → خدمات → قوانین کسب و کار، با سیاست های صریح و چک در سطح شی.

2) مدل های مجوز: زمانی که انتخاب کنید چه

RBAC (کنترل دسترسی مبتنی بر نقش) - مجوزها. ساده، پایدار، اما مستعد «انفجار نقش».
ABAC (Attribute-Based) - تصمیم گیری در مورد ویژگی های موضوع/شیء/زمینه (کشور، سطح KYC، صاحب منابع، ریسک).
ReBAC (Relationship-Based) - نمودار رابطه (مالک، عضو تیم، «مدیر پروژه») ؛ سلسله مراتب پیچیده را حل می کند.
محدوده (OAuth) - یک قرارداد بین مشتری و سرور منبع در مورد «منطقه دسترسی» (به عنوان مثال، «پرداخت: نوشتن»).
تمرین: RBAC برای ماتریس پایه، ABAC برای زمینه و محدودیت ها، ReBAC برای سلسله مراتب پیچیده (پوشه ها، سازمان ها، محدودیت ها و podaccounts).

3) طبقه بندی منابع و اقدامات

سلسله مراتب: «org → پروژه → کیف پول → معامله». ارث از حقوق از بالا به پایین با ممکن «محدود کننده».
اقدامات: CRUD + دامنه خاص («تایید»، «بازپرداخت»، «حل و فصل»).
ویژگی های منبع: مالک، منطقه، وضعیت، برچسب های خطر (AML/KYC)، محدودیت ها.
چند اجاره: تمام راه حل ها شامل 'tenant _ id' ؛ انکار به طور پیش فرض.

4) معماری: جایی که تصمیم گیری می شود

PEP (نقطه اجرای سیاست) - سایت تأیید: دروازه/API دروازه، mash sidecar، سرویس خود.
PDP (Policy Decision Point) - موتور سیاست گذاری: متمرکز (OPA-service، Cedar-engine) یا کتابخانه داخلی.
PIP (نقطه اطلاعات سیاست) - منابع ویژگی: دایرکتوری کاربر/نقش، مشخصات مستاجر، CCP/خطر، نقشه مالکیت منابع.
PAP (نقطه مدیریت سیاست) - نسخه بندی سیاست، انتشار، حسابرسی.

توصیه: PDP متمرکز + حافظه پنهان راه حل محلی در PEP ؛ چک کردن اشیاء پیچیده در سرویس در حضور ناوردا دامنه.

5) نشانه ها، تمبر و هویت

OIDC/OAuth2: 'sub' (شناسه موضوع)، 'aud' (سرویس هدف)، 'scope '/' roles'، 'tenant'، 'kyc _ level'، 'risk _ tier'.
JWT: امضای RS/ES، کوتاه 'exp'، دوباره منتشر شده توسط تازه کردن. PII را وارد نکنید استفاده از 'jti' برای حسابرسی لغو/پیگیری.
mTLS/HMAC: سرویس به سرویس و شرکا ؛ تمبرها با نام مستعار از کتاب راهنما بیرون کشیده میشوند.
دستگاه/زمینه: IP/ASN، جغرافیایی، زمان روز - ورود به راه حل ABAC (به عنوان مثال، ممنوع کردن نوشتن در خارج از ساعات کاری).

6) مجوز سطح شیء (BOLA-first)

هر عملیات باید به «آیا موضوع مالک است/حق این» resource _ id «را دارد ؟» پاسخ دهد.

بررسی مالکیت: "منابع. owner_id = موضوع id یا عضویت در یک «سازمان» با یک نقش.
نمونه های فیلتر: همیشه 'WHERE منابع را پوشش می دهد. tenant_id =: مستاجر و... (امنیت در سطح ردیف).
برای عملیات مرجع (ID در مسیر/بدن) - عادی سازی و اعتبار به منطق کسب و کار.

7) طراحی RBAC: نقش ها، مجوز ها، مجموعه ها

مجوزها - حقوق اتمی: "کیف پول. خواندن، کیف پول. نوشتن، پرداخت. بازپرداخت ".
نقشها - مجموعه مجوزهای نامگذاری شده: "admin", "support. خواندن، صندوقدار، تقلب. تحلیلگر ".

دامنه - قرارداد خارجی برای مشتریان (محدوده → نقشه برداری مجوز)

• نقش های پایه + بسته های اجازه،
• محدودیت های ABAC (کشور/منطقه/مستاجر)،
• «دسترسی به موقع»

8) محدودیت های ABAC/زمینه

جغرافیایی/قضایی: ممنوعیت نوشتن از کشورهای ممنوع (تحریم/نظارتی).
زمان/ریسک: «risk _ score <threshold» برای عملیات بزرگ.
ACC/limits: 'kyc _ level> = 2' برای پین> X; کنترل «خنک کردن» بین معاملات.
«دستگاه های قابل اعتماد»: نیاز به mTLS برای همکاران در مسیرهای خطرناک.

9) ReBAC و نمودار حقوق

مفید برای ساختارهای کسب و کار پیچیده (گروه ها، تیم ها، مارک ها، شاخه ها).

روابط: «عضو»، «مدیر»، «مالک»، «بیننده».
حقوق مشتق شده: «بیننده» منبع از «عضو» پروژه متعلق به «org» به ارث برده می شود.
ذخیره سازی نمودار: یک پایگاه داده با ماتریس ارتباط، یک سرویس تخصصی (در روح رویکرد زنگبار). پاسخهای Cache 'check (موضوع، رابطه، شیء).

10) حافظه پنهان و عملکرد راه حل

کش PDP در سطح PEP (به عنوان مثال، در یک دروازه) با کلید: 'زیر' منابع مستاجر 'عمل' سیاست _ نسخه '.
TTL کوتاه (ثانیه دقیقه) + ناتوانی توسط رویداد: تغییر نقش/رابطه/مستاجر.
چک های دسته ای (authz فله) برای لیست: کاهش هزینه های PDP.
اندازه گیری راه حل های تاخیر ؛ در طول تخریب - تخریب برازنده فقط برای خواندن (هرگز برای نوشتن/پولی).

11) نمونه های سیاست

11. تمبرهای 1 JWT → PEP خشن (شبه دروازه)

yaml
- match: { prefix: "/api/v1/wallets" }
authz:
require:
- claim: "aud"
equals: "wallet-service"
- claim: "scope"
includes_any: ["wallet. read", "wallet. write"]
context:
tenant_from: "claim:tenant"

11. 2 OPA/Rego (ABAC + BOLA)

rego package authz

default allow = false

allow {
input. action == "wallet. read"
input. subject. tenant == input. resource. tenant some role role:= input. subject. roles[_]
role == "support. read"
}

allow {
input. action == "payment. refund"
input. subject. tenant == input. resource. tenant input. subject. kyc_level >= 2 input. subject. risk_tier <= 2 input. subject. id == input. resource. owner_id # BOLA
}

11. 3 محدودیت صلاحیت (سیاست انکار لیست)

rego deny[msg] {
input. action == "withdraw. create"
input. context. country in {"IR","KP","SY"}
msg:= "Jurisdiction not allowed"
}

11. 4 سیاست ReBAC (شبه)

allow(subject, "wallet. write", wallet) --
related(subject, "member", wallet. project) ∧ related(subject, "admin", wallet. org)   ∧ wallet. tenant == subject. tenant.

12) سیاست و مدیریت نسخه

نسخه بندی خط مشی ('policy _ version') و canary برای تغییرات خطرناک.
«خشک اجرا» (خشک اجرا/سایه تصمیم گیری) - ورود «اجازه/انکار» بدون تاثیر.

دایرکتوری سیاست و مهاجرت: چه کسی چه زمانی و چرا تغییر کرد نقشه برداری به حوادث

تست برای سناریوهای منفی (موارد ممنوع) - مورد نیاز در CI.

13) قابلیت مشاهده و حسابرسی

سیاهههای مربوط به تصمیم: «ردیابی _ id»، «موضوع»، «مستاجر»، «عمل»، «منبع _ id»، «نتیجه»، «سیاست _ نسخه»، دلیل شکست.
معیارها: «authz _ decision _ latency»، «authz _ denied _ total {action}»، سهم تلاشهای BOLA، نرخ ضربه کش.
داشبورد: شکست های بالا توسط اقدامات/مستاجران، روند پس از انتشار سیاست.

14) ایمنی و پایداری

انکار پیشفرض: بدون اجازه صریح = انکار.
Fail-closed: هنگامی که PDP در دسترس نیست، نوشتن → بحرانی ممنوع است (یا به «حداقل مجموعه» نقشهای کاملاً تأیید شده تنزل می یابد).
«بررسی گارد» محلی در خدمات برای ناورداهای بحرانی (به عنوان مثال، «مستاجر »/« مالک»).
به حداقل رساندن علائم در JWT ؛ بارگذاری ویژگی های حساس از طریق PIP بر روی یک کانال امن.

15) ویژگی های iGaming/امور مالی

نقشها: 'صندوقدار'، 'kyc. مامور آ می. مأمور کلاه برداری. تحلیلگر، ویپ. مدیر «،» خطر. مدیر '.
محدودیت ها: معاملات پرداخت به «kyc _ level»، محدودیت های پرداخت مسئول، وضعیت/تحریم های AML بستگی دارد.
ثباتهای قفل: 'org/brand/device/payment _ instrument' - فیلترهای ABAC هنگام نوشتن.
گزارش های حسابرسی بدون تغییر برای اقدامات KYC/AML/pin ؛ ذخیره سازی با توجه به مهلت قانونی.
APIهای همکار: mTLS + «محدوده» قرارداد در مسیرها، فیلترهای geo/ASN در محیط.

16) تست و تایید

ماتریس منفی: لیست موارد صریح «ممنوع» و رفع با آزمون.
مجوز Fuzz: جایگزینی «tenant _ id»، «owner _ id»، دور زدن فیلترها هنگام صفحه بندی/مرتب سازی.
آزمون بار PDP: بررسی زمان تاخیر و رفتار کش در p95/p99.
انتشار سیاست: خشک اجرا + قناری + تست خودکار با انتظار می رود انکار/اجازه.
حوادث: درخواست ها را در جایگاه با یک نسخه دقیق از سیاست ها پخش کنید.

17) ضد گلوله

فقط به «محدوده» بدون چک کردن شیء (BOLA) تکیه کنید.
منطق کسب و کار و حقوق را در هر کنترل کننده بدون یک مدل متمرکز ترکیب کنید.
نقش هاردکد در UI و راه حل های اعتماد مشتری.
عدم وجود پالایههای «tenant »/« owner» در درخواستها برای دادگان) خوانشهای نشتی (.
ناتوانی در راه حل کش در هنگام تغییر نقش ها/روابط وجود ندارد.
JWT های طولانی مدت بدون یادآوری/چرخش.

18) تولید لیست آمادگی

• منابع/فعالیت ها، سلسله مراتب و چند اجاره تعریف شده است.
• ماتریس پایه RBAC + محدود کننده های ABAC، در صورت نیاز - ReBAC.
• PDP/PEP طراحی شده اند ؛ یک کش راه حل محلی و ناتوانی آن وجود دارد.
• سیاست ها نسخه، آزمون سناریو منفی در CI است.
• BOLA چک در هر نوشتن/خواندن به 'resource _ id' خاص.
• JWT با حداقل تمبر، کوتاه 'exp' ؛ حسابرسی/یادآوری در «jti».
• متریک/تصمیم سیاهههای مربوط، داشبورد، هشدار توسط انکار/تاخیر.
• Fail-closed برای نوشتن انتقادی ؛ حالت عقب نشینی مستند شده است.
• مستندات مشتری: «حوزه»، کدهای خطا (401/403/404/409)، نمونه.

19) TL ؛ دکتر متخصص

ساخت مجوز BOLA-اول: مرکزی PDP + حافظه پنهان راه حل، RBAC به عنوان پایه، ABAC برای زمینه، ReBAC برای روابط. تمام درخواست ها در زمینه «مستاجر» و «resource _ id» خاص هستند ؛ انکار به طور پیش فرض، کوتاه JWT، فیلتر شی در پایگاه داده. نسخه و سیاست های تست، اندازه گیری تاخیر/انکار، پخش حوادث. برای iGaming - نقش های فردی (KYC/AML/ثبت نام نقدی)، محدود کننده های ABAC سخت و حسابرسی غیر قابل تغییر.