בקרת גישה ו ־ RBAC ב ־ API

1) מדוע API גישה לבקרת

האישור הוא התשובה לשאלה "האם השחקן הזה יכול לבצע את הפעולה הזו על המשאב הזה עכשיו? ». שגיאות מובילות להדלפות בולה/IDOR, הסלמת זכויות והפרת דרישות הרגולציה. המטרה היא לבנות מודל רב-דרגתי: perymetre service mash # access rules, עם מדיניות מפורשת ובדיקות ברמת האובייקט.

2) מודלי הרשאה: מתי לבחור מה

RBAC (בקרת גישה מבוססת תפקידים) - תפקידים להרשאות. פשוט, יציב, אבל נוטה ל ”פיצוץ תפקידים”.
החלטה על מאפייני הנושא/אובייקט/הקשר (מדינה, רמת KYC, בעל משאבים, סיכון).
REBAC (מערכת יחסים מבוססת) - גרף יחסים (בעלים, חבר צוות, ”מנהל פרויקטים”); פותר היררכיות מורכבות.
Scopes (OAuth) - חוזה בין הלקוח לבין שרת המשאבים אודות ”אזור הגישה” (לדוגמה, ”תשלומים: לכתוב”).
תרגול: RBAC עבור מטריצות בסיסיות, ABAC עבור הקשר ואילוצים, REBAC עבור היררכיות מורכבות (תיקיות, ארגונים, מגבלות ואילוצים).

3) טקסונומיה של משאבים ומעשים

Hierarchies: 'org ac project accession'. ירושה של זכויות מלמעלה למטה עם ”מגבלות אפשריות”.
פעולות: CROD + domain-specific (”לאשר”, ”להחזיר”, ”ליישב”).
מאפייני משאבים: בעלים, אזור, סטטוס, תגי סיכון (AML/KYC), גבולות.
Multi-terency: כל הפתרונות מכילים "דייר _ id'; מכחיש על ידי ברירת מחדל.

4) ארכיטקטורה: היכן מתקבלת ההחלטה

PEP (נקודת אכיפת מדיניות) - אתר אימות: שער/API-שער, מחית סירה, שירות עצמו.
PDP (Policy Decision Point) - מנוע מדיניות: מרוכז (OPA-service, Cedar-engine) או ספרייה מובנית.
PIP (Policy Information Point) - מקורות ייחוס: תיקיית משתמש/תפקיד, פרופיל דייר, CCP/סיכון, מפת בעלות על משאבים.
PAP (נקודת מינהל מדיניות) - ניהול מדיניות, הוצאה לאור, ביקורת.

המלצה: PDP + מטמון תמיסות מקומי מרוכז ב PEP; אובייקט מורכב בודק בשירות בנוכחות אינווריאנטים תחום.

5) אסימונים, בולים וזהות

OIDC/OAuth2: "sub" (מזהה נושא), "aud' (שירות יעד)," scope "/" תפקידים "," דייר "," kyc _ level "," סיכון _ tier ".
JWT: חתימת RS/ES, קיצור ”exp”, שחרור מחדש על ידי רענון. אל תשים מח "ש; השתמש 'jti' לשלילת/ביקורת מסלול.
MTLS/HMAC: שירות לשירות ושותפים; בולים נשלפים מהספרייה על ידי 'client _ id'.
התקן/הקשר: IP/ASN, geo, time of day - התחברות לפתרון ABAC (למשל, איסור על כתיבה מחוץ לשעות העבודה).

6) אישור ברמת אובייקט (בולה-ראשון)

כל פעולה חייבת להגיב ל "האם הנושא הוא הבעלים/בעל הזכות ל-" resource _ id'? ".

בדיקת בעלות: "משאב. owner_id = = נושא. זיהוי או חברות ב ”אורג” עם תפקיד.
דגימות סינון: תמיד לכסות 'איפה משאב. tenant_id =: דייר ו... '(אבטחה ברמה שורה).
עבור פעולות ייחוס (זיהוי בנתיב/גוף) - לנרמל ולאמת ללוגיקה עסקית.

7) עיצוב RBAC: תפקידים, הרשאות, סטים

הרשאות - זכויות אטומיות: "ארנק. לקרוא ”, ארנק”. לכתוב ',' תשלום. החזר כספי.
תפקידים - שמות הרשאה סטים: 'הערצה', תמיכה. לקרוא, ”קופאי”, הונאה. אנליסט ".

Scopes - חוזה חיצוני ללקוחות (מיפוי הרשאות להיקף)

• תפקידי בסיס + חבילות הרשאה,
• הגבלות ABAC (מדינה/אזור/דייר),
• ”גישה בדיוק בזמן”.

8) אילוצי ABAC/הקשר

Geo/שיפוט: איסור כתיבה ממדינות אסורות (סנקציות/רגולציה).
זמן/סיכון: ”סיכון _ ציון <סף” עבור פעולות גדולות.
ACC/limits: ”kyc _ level> = 2” עבור סיכות> X; שליטה על ”התקררות” בין עסקאות.
”מכשירים מהימנים”: דורשים mTLS לשותפים במסלולים מסוכנים.

9) REBAC וגרף זכויות

שימושי למבנים עסקיים מורכבים (קבוצות, קבוצות, מותגים, סניפים).

מערכות יחסים: ”חבר”, ”הערצה”, ”בעלים”, ”צופה”.
זכויות נגזרות: ”הצופה” של המשאב עובר בירושה מ ”חבר” של הפרויקט ששייך ל ”org”.
אחסון גרף: מסד נתונים עם מטריצת יחסים, שירות מיוחד (ברוח גישת זנזיבר). מטמון 'צ' ק (נושא, יחס, אובייקט) 'תגובות.

10) מטמון וביצועים

מטמון PDP ברמת PEP (לדוגמה, בשער) עם המפתח: 'sub' terenant' resource 'action' policy _ version '.
TTL קצר (שניות-דקות) + נכות על ידי אירוע: תפקיד/מערכת יחסים/שינוי דייר.
צ 'קים (batch authorz) עבור רשימות: הפחתת מטעני 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 אופ "א/רגו (ABAC + בולה)

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”) וקנרית לשינויים מסוכנים.
"יבש-run' (יבש-run/shadow החלטות) - רישום" let/dember "ללא השפעה.
מדריך מדיניות ונדידה: מי השתנה מתי ולמה; מיפוי לתקריות.
בדיקות לתרחישים שליליים (מקרים אסורים) - נדרש במצ "ח.

13) יכולת תצפית וביקורת

רישומי החלטות: ”trace _ id',” subject', ”terant',” action ”,” resource _ id', ”surve”, ”policy _ version”, סיבה לכישלון.
Metrics: 'authz _ decision _ latency', 'authz _ ended _ total _ action', נתח של ניסיונות בולה, cache hit-rate.
לוחות מחוונים: כישלונות עליונים על ידי פעולות/דיירים, מגמות לאחר שחרורי מדיניות.

14) בטיחות וקיימות

מכחיש כברירת מחדל: אין אישור מפורש = להכחיש.
כשל סגור: כאשר ה-PDP אינו זמין, כתיבה ביקורתית = = אסורה (או מושפלת ל ”קבוצה המינימלית” של תפקידים מאומתים לחלוטין).
"שמירה-checks' מקומית בתוך שירותים לאינווריאנטים קריטיים (לדוגמה," דייר "/" בעלים ").
מזעור סימני היכר ב-JWT; טען תכונות רגישות באמצעות PIP מעל ערוץ מאובטח.

15) פרטים של iGaming/Finance

תפקידים: ”קופאית”, ”קיק”. סוכן ',' aml. אדוני השוטר, הונאה. אנליסט, אח "מים. מנהל ”,” סיכון. מעריץ.
הגבלות: העברות תשלום תלויות ב ”kyc _ level”, גבולות של תשלומים אחראיים, מצב/סנקציות AML.
נעילה: ”org/brang/pace/payment _ instrument” - מסנני ABAC בכתיבה.
רישומי ביקורת ללא שינוי לפעולות KYC/AML/pin; אחסון לפי מועדים רגולטוריים.
API שותף: mTLS + חוזה ”סקופים” במסלולים, מסנני GEO/ASN בהיקף.

16) בדיקה ואימות

מטריצה שלילית: לרשום מקרים ”אסורים” מפורשים ולתקן עם בדיקות.
אישור FUZ: החלפה של ”terenant _ id',” בעלים _ id', עקיפה של מסננים בעת התאמה/מיון.
בדיקת עומס PDP: בדוק את האיחור וההתנהגות של המטמונים ב- p95/p99.
שחרור מדיניות: run-run + canary + auto-test עם מכחיש/מאפשר צפוי.
תקריות: שידור חוזר של בקשות על דוכן העדים עם גירסה מדויקת של מדיניות.

17) תרופות אנטי ־ פטריות

להסתמך רק על ”היקף” ללא בדיקת אובייקטים (בולה).
לערבב היגיון עסקי ובדיקות זכויות בכל מפעיל ללא מודל ריכוזי.
תפקידי הארדקוד ב UI ואמון פתרונות לקוח.
היעדר מסנני ”דייר ”/” בעלים” בבקשות לבסיס הנתונים (קריאה דולפת).
אין פתרון מטמון נכות בעת שינוי תפקידים/יחסים.
ג 'יי-וי-טי ארוך ימים ללא זיכרון/סיבוב.

18) רשימת מוכנות למומחים

[ ] משאבים/פעילויות, היררכיות וריבוי דירות מוגדרות.

[ ] מטריצות RBAC בסיסיות + מגבלות ABAC,

[ ] PDP/PEP מתוכננים; יש מטמון פתרון מקומי והנכות שלו.

[ מדיניות ] ממצה, בדיקות תרחיש שליליות במודיעה.

[ ] בולה בודקת כל כתיבה/קריאה ל "משאב _ id' ספציפי.

[ ] JWT עם בולים מינימליים, 'exp קצר'; ביקורת חשבונות/זכרון על 'jti'.

[ ] מטריצות/רישומי החלטות, לוחות מחוונים, התראות על ידי הכחשה/איחור.

[ ] אל-כשל לכתיבה ביקורתית; מצב הגיבוי מתועד.

[ תיעוד לקוח ]: ”סקופים”, קודי שגיאה (401/403/404/409), דוגמאות.

19) TL; DR

לבנות אישור בולה-ראשון: מטמון PDP + מרכזי, RBAC כבסיס, ABAC עבור הקשר, ReBAC עבור מערכות יחסים. כל הבקשות נמצאות בהקשר של "דייר" ו "משאב _ id' ספציפי; מכחיש כברירת מחדל, קצר JWT, מסנני אובייקטים בבסיס הנתונים. מדיניות גירסה ובדיקה, מדידת איחור/הכחשה, שידור חוזר של תקריות. עבור iGaming - תפקידים בודדים (KYC/AML/cash register), הגבלת ABAC קשה וביקורת בלתי ניתנת לשינוי.