אימות ואישור

לולאת AuthN/AuthZ אמינה היא נקודת אמת אחת לגבי מי אתה (אימות) ומה מותר לך לעשות (אישור). בפלטפורמה עם הרבה מותגים, אזורים, אינטגרציות ודרישות רגולטוריות גבוהות, קונטור זה צריך להיות מודולרי, נצפה ונוהל על ידי פוליטיקאים, ולא ”פיזור של if-s על ידי שירותים”.

1) מונחים ותפקידים בסיסיים

זיהוי (ID): זיהוי (משתמש, שירות, ספק).
אימות (AuthN): הוכחה לזהות (סיסמה, MFA, תעודה).
אישור (AuthZ) - פוליסי ומבוסס הקשר יכול/לא יכול להחליט.
PDP/PEP: Policy Decision Point/Policy Appication Point.
IDP: ספק זהות (OIDC).
נושא/משאב/פעולה/הקשר: מי/מה/מה עושה/באילו תנאים.

2) ארכיטקטורת לולאה כללית

[ IdP (OIDC) ]
│ OIDC/OAuth 2. 1 (PKCE, JAR/JARM)

[ Token Service / JWKS / KMS ]
│klyuchi (rotate)
│ JWT/Access/Refresh, mTLS

[API Gateway (PEP)] Solution/Policy ──kesh
│ authN/CSRF/CORS/rate-limit

[ Microservices (PEP)]──PDP (OPA/cedar) ──Policy Store (GitOps)
│audit/metriki

[ Data/Providers ]── service-to-service (mTLS+JWT/Spiffe)

עקרונות: ריכוז דור האסימונים והמדיניות, יישום מקומי; ”זכויות מינימליות” ומשלחות מפורשות.

3) אימות משתמש (OIDC/OAuth 2. 1)

• קוד הרשאה + PKCE (תמיד עבור SPA/Mobile).
• SSO: תמיכה חיצונית של IDP (SAML/OIDC) עבור b2b/operators.
• MFA: TOTP/WebAuthone/SMS; SMS - נסיגה).
• עבור פעולות רגישות (משיכת כספים, שינוי פרטים) נדרש MFA/pe-Auth.

• רענן סיבוב טוקן + רישום RT עם חיטוי שימוש חוזר.
• Nonce/State + PKCE, COURS/CSRF קפדני לזרמי דפדפן.
• אסימוני גישה קצרי ימים (5-15 דקות) + רענון שקט/RT.
• קשירת התקן (DPoP/mtls-bound tokens) לפעולות קריטיות.

json
{
"iss": "https://auth. example. com",
"sub": "user_9f12",
"aud": ["wallet","catalog"],
"exp": 1730385600,
"iat": 1730384700,
"tenant": "brand_eu",
"region": "EE",
"amr": ["pwd, ""webauthn"] ,//authentication methods
"scp": ["wallet:read","bets:place","kyc:status. read"],
"sid": "sess_a1b2c3",      // session id
"acr": "urn: mfa: strong "//warranty level
}

4) אימות שירות-שירות (MTLS, SPIFFE, JWT)

MTLS בין שירותים + SPIFE/SPIRE עבור מזהים עומס עבודה יציב.
שירות JWT עם זמן קצר (5 דקות), חתום על ידי HSM/KMS; ביקורת של הוצאה.
קהל: JWT מתאים רק לשירות/תחום מסוים.
אזורי אמון: שירותים מאזור אחר/דייר - PKIs נפרדים ומדיניות.

5) מודלי הרשאה: RBAC, ABAC, ReBAC

RBAC (תפקידים = הרשאות): פשוט ושקוף (מתאים ללוחות קבלה, אופרטורים).

ABAC (נושא/משאב/תכונות הקשר): ואזור =... kyc_tier≥2." ‏

RBAC (מערכות יחסים): שימושי לאחזקות מורכבות (”למי יש מותג/תיקייה/קמפיין”).

המלצה: היברידי - קשר RBAC + בסיסי עם ABAC + point ReBAC.

6) מדיניות ואכיפה (PDP/PEP)

PEP על השער ובשירותים: משיג את ההקשר (JWT, כרטיסים, IP/ASN, זמן, אזור, שכבת KYC), יוצר בקשה ל-PDP.

json
{
"subject": { "sub":"user_9f12", "roles":["support"], "kyc":2, "tenant":"brand_eu" },
"action": "bets. place",
"resource": { "game_id":"g_42", "provider":"pr_x" },
"context": { "region":"EE", "ip_asn":"AS12345", "time":"2025-10-31T12:34:56Z" }
}

ומחזירה 'LOW/DETRY' + הסבר.

מטמון התמיסה של PEP (TTL 30-120 C) מפחית את האחיזה; נכות על ידי ”שינוי תפקיד/מדיניות” אירועים.

rego package bets

default allow = false

allow {
input. action == "bets. place"
input. subject. kyc >= 2 input. subject. tenant == input. context. tenant not blocked_region within_limits
}

blocked_region { input. context. region == "NL" }
within_limits { input. context. bet_amount <= data. limits. max_bet[input. subject. tenant] }

7) סקופים והחלטות

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

העיקרון של מינימום הרשאות: אנחנו מקצים רק את הסקופים הדרושים; ”הסלמה” (הרחבות זמניות של זכויות) על ידי כרטיס ועם TTL.

8) רב-דיירים ואזורים (תושבות)

אסימונים מכילים ”דייר”, ”אזור”, ”רישיון”; ה ־ PDP בודק את ההתכתבות עם המשאב.
תפקידים/מדיניות - שמות לכל דייר ("תפקיד: brand _ eu/support').
הפרדת מפתחות חתימה ורשימות שלילת מיקום לפי אזור; בקשות חוצות-אזוריות - רק דרך שערים אמינים.

9) הפעלה וניהול התקנים

Server-side session store for web (קשירת התקן/דפדפן, זיהוי סיבוב).
פסק זמן סרק/מוחלט (למשל: 30 min/24 h); פעולות רגישות - מחדש Auth/MFA.
רישום של התקנים פעילים, ”יציאה מכל”.
חריגות: קלט סימולטני מאזורים שונים, טבילות MFA תכופות - אותות סיכון.

10) משלחת והסכמה (הסכמה)

מטעם (OBO): השירות פועל בשם המשתמש (אסימון proxy עם 'sub '/' act' נפרד).
הסכמה: מסך מפורש לגישה לשותף למידע, יומן הסכמה עם החזרה.
גישה זמנית למנדטים: זכויות לשעות וימים פג תוקפו באופן אוטומטי.

11) מפתחות, חתימות וסבב

JWKS עם 'ילד', סיבוב אוטומטי, אחסון מפתחות פרטיים ב-KMS/HSM.
אלגוריתמים: ES256/EdDSA עבור JWT; TLS 1. 2 +/mTLS.
תקופת מפתח כפולה: קבל את שני 'קידס' לפני שדרוג הלקוח הושלם.
RT ו-Token Introspection נזכרים בתקריות קריטיות.

12) אבטחת יישום לקוח

קוד אישור + PKCE, ללא ”מרומז”, COURS/Content-Security-Policy.
מובייל: App Attestation/Device Check, secure RT, Root/Sailbreak protection.
Desktop: דפדפן מערכת להתחברות (ללא תצוגות רשת משובצות), PKCE.

13) חוזי SDK נוחים

http
POST /authz/evaluate
Authorization: Bearer <access_jwt>
Body: { "action":"bets. place", "resource":{"game_id":"g_42"}, "context":{"bet_amount":5. 0} }
→ 200 { "decision":"ALLOW", "ttlMs":60000, "explain":"kyc>=2, limit ok" }

http
POST /oauth/token grant_type=urn:ietf:params:oauth:grant-type:token-exchange subject_token=<user_jwt>&actor_token=<service_jwt>&audience=wallet

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

• 'authn _ succle _ cate '/' mfa _ challenge _ cate '/' mfa _ fall _ ratefost
• 'authz _ p95 _ ms',' autz _ נדחה _ rate 'i סיבה'
• 'invalid _ token _ rate', 'jwks _ skew _ ms',' rt _ reuse _ detected &pos
• חריגות של כניסות (מכשיר חדש, גיאו-מהירות), סקופים חשודים.

• 'who/what/when/when/why', 'החלטה', 'policy _ version', 'token _ bid',' client _ id'.
• ייצוא לציות (רגולטור/ספק-ביקורת).

15) היקפי והגנה על לקוח

שער PEP: הגבלת קצב, בדיקת בוט/חתימה, הגנת CSRF, CORS קפדנית, HSTS.
תנועה פנימית: mTLS + שירות JWT + רשתות מוגבלות.
HMAC/JWS), חלונות זמן, אנטי-שידור חוזר.

16) שגיאות אופייניות

אסימוני גישה ארוכים פי דליפות.
זרימת OAuth מרומזת בספא.
אין סבב מפתח ותקופת מפתח זוגי.
תפקידי הארדקור במקום מדיניות (אי אפשר לבקר או להסביר החלטות).
ערבוב דיירים/אזורים באחד 'role' או 'key'.
אין שלב למעלה MFA על פעולות רגישות.
מטמון פתרונות AuthZ ללא נכות שינוי תפקיד.

17) ספרי משחק (ספרי הפעלה)

1. פשרת מפתח חתימת JWT

ביטול מיידי 'ילד', פרסום חדש של JWKS, נכות RT/מפגשים כפויה, דו "ח ביקורת.

2. Bulk 'invalid _ oken&fost

בדוק אם השעון לא מתאים לכל החיים, רלוונטיות של JWKS, קריסות מטמון.

3. חריגות קלט

אפשר ניקוד סיכון מוגבר, דורש עליית מדרגה, להודיע למשתמש, להגביל באופן זמני את התשלומים.

4. IDP נכשל

עבור למטמון ההפעלה/התקן התפקידים, הגבל את ההתחברות החדשה, שמור על הפעלות פעילות TTL.

18) רשימת בדיקות לפני המכירה

[ ] OIDC/OAuth 2. 1 עם PKCE, קיצור AT, סיבוב RT, התקן מחייב לפעולות קריטיות.

[ ] MFA (WebAuthn/TOTP) ועליית מדרגה עבור פלט/שינוי פרטים/הסלמת תפקידים.

שירות לשירות: MTLS + SPIFFE, שירות קצר ימים JWTs.
מדיניות [ ] AuthZ (ראשי תיבות של RBAC + ABAC/REBAC; PEP בשער ובשירותים.

[ ] מטמון פתרונות נכות; שביל ביקורת בלתי ניתן לשינוי.

[ ] רב-דיירים/אזורים: מפתח/מדיניות/בידוד רישום, חשבונאות רישוי.

[ ] JWKS/מפתחות ב KMS/HSM, סיבוב דו-מפתח, ניטור 'kid'.

[ ] מסנני CSRF/CORS/HSTS/Rate-Limit/Bot על המתחם.

[ ] ספרי משחקים, ביטול/סיבוב/נעילה להפעיל כפתורים.

סוויטת ניסוי : יחידה (מדיניות), חוזה (SDK/זורם), כאוס (IDP, JWKS), e2e (קפיצת מדרגה, OBO, ביטול).

19) תבניות הגדרות מיני

yaml scopes:
wallet: read: {desc: "Reading balance"}
wallet: transfer: {desc: "Transfer of funds," sensitive: true, step_up: true}
bets: place: {desc: "Bet"}
kyc:status. read: {desc: "KYC status"}
roles:
support:
allow: [wallet:read, kyc:status. read]
finance:
allow: [wallet:read, wallet:transfer]
player:
allow: [bets:place]

yaml deny:
- when: { region: ["NL","BE"] }
actions: ["bets."]

סיכום

לולאת האימות וההרשאה אינה ספרייה, אלא יכולת פלטפורמה: אסימונים קצרי ימים ומפתחות מנוהלים, מדיניות מרכזית ויישומם המקומי, רב-פקטים, בידוד קפדני של דיירים/אזורים, ביקורת חשבונות וטלמטריה. תכנון זה הופך את השינויים לבטוחים, ניתנים להסבר לווסת ושקופים למוצר - והיקפי השוק והפקודה הופכים לפעולה שגרתית, לא להישג.