ניהול גישה לזהות

תקציר

IAM הוא אוסף של תהליכים, מדיניות וכלים שמספקים מי מקבל גישה למה, באילו תנאים וכיצד הוא נשלט. מטרות: מזעור זכויות מיותרות, צמצום משטח התקפה, האצה של עלייה למטוס וביקורת, ציות (PCI DSS, GDPR וכו ') ואמינות גישה מדידה.

מושגים בסיסיים

זהות: אדם (עובד, קבלן), שירות/יישום, התקן.
אימות (AuthN): מי בודק (sammord # MFA = = סכימות FIDO2/passkeys ללא סיסמה).
אישור (AuthZ): החלטה ”מה מותר” (RBAC/ABAC/REBAC, מדיניות).
אישורים: סיסמאות, מפתחות, אסימונים, תעודות (mTLS).
ניהול סודי: KMS/HSM/Vault, סיבובים, TTL קצר, סודות דינמיים.
מחזור חיים: Joiner-Mover-Lever (JML) - ליצור, לשנות תפקידים, להיזכר.

Target IAM ארכיטקטורה

מטוסים ותפקידים:

IDP (ספק זהות): SSO, MFA, ספרייה, פדרציה (OIDC/SAML), מדיניות סיכון.
PDP/PEP: החלטה/אכיפה - מנוע מדיניות (OPA/Cedar) + נקודות יישום (API gateways, proxies, service mesh).
קטלוגים/מערכת משאבי אנוש: מקור האמת באמצעות עובד ותפקידו
מעורר: SCIM/Automation ליצירת/שינוי/ביטול נגישות.
ביקורת: יומנים מרכזיים, UEBA, דוחות תפקידים וגישה.

Access Flow (אפליקציית משתמש):

SSO (+ MFA) ac token project (OIDC/JWT/SAML) * PEP בודק את הסימן/הקשר * PDP מחליט על מדיניות (תפקיד/מאפיינים/סיכון).

אימות: מסיסמאות לסיסמאות

סיסמאות: רק עם מנהלי סיסמאות, לפחות 12-14 תווים, ללא סיבוב ”לפי לוח השנה”, אלא עם חובה במקרה של תקרית.
ברירת מחדל MFA: TOTP/WebWarThn/Push; הימנע מ-SMS כגורם מרכזי.
כניסה ללא סיסמה: FIDO2/passkeys לתחומים קריטיים.
AuthN אדפטיבי: שקול אות סיכון (Geo, ASN, התקן, חריגות).

אישור: RBAC, ABAC, ReBAC

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

המנהגים הטובים ביותר:

שילוב RBAC (רשת בסיס) + ABAC/REBAC (הקשר/גבולות).
JIT (Just-in-Time): הוצאה של הרשאות זמניות באמצעות בקשה/אפליקציה, ביטול אוטומטי.
(JEA (רק-מספיק גישה: מינימום זכויות למבצע.
PAM: גישה ”חזקה” מבודדת (DB/ענן מנהל) עם ברוקר הפעלה, הקלטה/פקודת מסך והנפקת קרדיטים קצרי ימים.

פדרציה ו SSO

פרוטוקולים: OIDC (JWT אסימונים), SAML 2. 0 (טענות XML) - לספקים/שותפים חיצוניים.
SSO: נקודת כניסה אחת עם MFA, צמצום דייג, החזרה מרכזית.
B2B/B2C: פדרציה עם שותפים, הגבלת תחום, מדיניות מבוססת תחום.
mTLS/m2m: לשירותים, שימוש קצר ימים x.509 (SPIFFE/SVID) או OAuth2 תעודות לקוח.

מחזור חיים (JML) ו provisioning

ג 'וינר: SCIM אוטומטי מספק חשבונות ותפקידים בסיסיים ממשאבי אנוש/ספרייה.
מובר: התפקידים משתנים אוטומטית על ידי תכונות (מחלקה, פרויקט, מיקום).
ליבר: החזרה מיידית של גישות SSO, מפתחות, אסימונים, מאגר/ענן/CI/CD.
תהליכים: בקשות גישה (ITSM), מטריצת SoD (חלוקת החובות), סקירת גישה מחזורית.

סודות, מפתחות וסיבובים

KMS/HSM: לאחסן מפתחות שורש/קריטיים, לאפשר ביקורת פעולה.
מנהלי כספת/סודות: קרדיטים דינמיים (DB, עננים), הפעלה אוטומטית בהשלמת TTL.
סיבובים: OAuth אסימונים, JWT חתימת מפתחות, סיסמאות שירות - על לוח זמנים ובמקרה של תקריות.
תעודות קצרות ימים (שעות/ימים), החזרה אוטומטית.

מדיניות ומנוע פתרון

הצהרות: מדיניות אחסון בגיט; בדוק במצ "ח (בדיקות מדיניות).
הקשר: זמן/מיקום/ASN/רמת סיכון/מצב התקן (MDM/EDR).

דוגמה (Rego, מפושט):

rego package authz. payments default allow = false

allow {
input. user. role == "finance"
input. device. compliant == true input. action == "read"
input. resource. type == "report"
time. now_hh >= 8 time. now_hh <= 20
}

ניטור, SLO וביקורת

מדדים:

הצלחה של AuthN/AuthZ (%), p95 login/decision time, שיתוף של MFA/Sessword-floots.
מספר הסלמת JIT/PAM, משך זכות ממוצע.
כיסוי של מכשירים תואמים, נתח של סודות קצרי ימים.

SLO (דוגמאות):

זמינות של SSO/IDP-99. 95% לחודש.
החלטת P95 AuthZ רשומה 50 דולר.
השבתה של 100% של החשבון רישום 15 דקות לאחר העלייה.
יומנים בלתי ניתנים לריכוז (נגישות, שינויי תפקידים, כניסות כושלות, פתרונות PDP), אנליטיקה התנהגותית ואזעקות חריגות.

תגובת-תקרית ב-IAM

פשרה של אסימונים/מפתחות: שלילה מיידית, רישום כפוי, סיבוב מפתחות חתימה, הוצאה מחודשת של סודות קצרי ימים.
ניצול זכויות: להשהות את החשבון, לחסום את JIT/JEA, לערוך סקירת גישה של ישויות שכנות.
IDP אינו זמין: מצבים לא מקוונים (אימות מטמון זמני של אסימונים עם TTL קצר), הליכי שחזור עדיפות.
פישינג: MFA חובה, בדיקות סיכון של מפגשים, הודעות למשתמשים, אימונים.

עננים וקוברנטות (תבניות)

Public Cloud IAM: השתמש בתפקידי ילידים עם זכות מינימלית; במקום מפתחות ”נצחיים” - עומס עבודה עם פדרציית OIDC לענן (IRSA/Workload Identity).
קוברנטס: RBAC על ידי נימספייס/תפקידים, להגביל 'אשכול-ניהול'; סודות - באמצעות מנהלים חיצוניים; שירות רשת + אופ "א למדיניות L7; בקרי כניסה (תמונות חתומות, איסור ”עדכני”).
שער API: בדיקת JWT/mTLS, מגבלות קצב, חתימות בקשה (HMAC) לנקודות קצה רגישות.

תרגול עבור iGaming/fintech

תחומי גישה: תשלומים, אנטי-הונאה, מח "ש, ספקי תוכן - לבודד עם תפקידים ומקטעי רשת.
SoD: לא לשלב תפקידים סותרים (למשל. ליצור פרומו + לאשר תשלומים).
PAM ו-JIT: לגישה לבנקים PSP/Prod-DB - רק באמצעות מתווך הפעלה, עם הקלטה והחזרה אוטומטית.
ציות: PCI DSS - MFA, מינימום הרשאות, מקטע אזור CHD; GDPR - העיקרון של מזעור נתונים ויומנים נקודתיים של גישה ל-PII.
שותפים וספקי תוכן: פדרציה ומדיניות לכל דייר; אסימונים קצרי ימים ורשימת הרשאות IP/ASN.

שגיאות נפוצות

מפתחות ואסימונים ”נצחיים”: אין סיבובים ו TTL = סיכון גבוה לדליפות.
הפעלה ידנית: עיכובים בשלילת זכויות = ”רוח רפאים” גישה.
תפקידי מונולית ': תפקיד על במקום קומפוזיציה ותכונות.
MFA רק בלוח המנהלים: MFA צריך להיות לכל הקלט ופעולות קריטיות.
יומנים ”לשום מקום”: אין ריכוז ו-UEBA = איתור מאוחר יותר של אירועים.

IAM מימוש מפת דרכים

1. מלאי של משתמשים/שירותים/משאבים; מפת נתונים ורגישות.
2. SSO + MFA לכולם, כולל גורמים העמידים בפני פישינג.
3. מודל לחיקוי: מאפיינים בסיסיים של RBAC + (ABAC) להקשר; מטריצת סיד.
4. SCIM מתגרה: יצירה אוטומטית/שינוי/שלילת זכויות מ-HR/קטלוג; יישומים ועדכונים ב-ITSM.
5. פאם ו-JIT/JEA: עבור גישה חסויה; פגישות הקלטה, טי-טי-אל קצרים.
6. ניהול סודי: דחיית מפתחות סטטיים; סודות דינמיים, סיבובים, אם-טי-אל-אס עם תעודות קצרות.
7. מדיניות Git + CI: בדיקות חוק, בקרת שינוי, פריסת מדיניות קנרית.
8. תצפית ו-SLO: לוחות מחוונים של AuthN/AuthZ, התראות, סקירת גישה רגילה.

דוגמאות של חפצים

AWS IAM מדיניות (מינימום לקריאת דוחות S3)

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "ReadOnlyReports",
"Effect": "Allow",
"Action": ["s3:GetObject","s3:ListBucket"],
"Resource": [
"arn:aws:s3:::reports-bucket",
"arn:aws:s3:::reports-bucket/"
],
"Condition": {
"IpAddress": { "aws:SourceIp": "203. 0. 113. 0/24" }
}
}]
}

קוברנטס RBAC (מפתח צפצוף-שם)

yaml apiVersion: rbac. authorization. k8s. io/v1 kind: Role metadata:
name: dev-read-write namespace: app-prod rules:
- apiGroups: ["","apps"]
resources: ["pods","deployments","services","configmaps"]
verbs: ["get","list","watch","create","update","patch","delete"]
apiVersion: rbac. authorization. k8s. io/v1 kind: RoleBinding metadata:
name: dev-bind namespace: app-prod subjects:
- kind: User name: alice@example. com roleRef:
kind: Role name: dev-read-write apiGroup: rbac. authorization. k8s. io

OIDC: אישורים עבור ABAC (דוגמה)

json
{
"sub": "d81f0b5c-...",
"email": "bob@example. com",
"dept": "finance",
"role": "analyst",
"device_compliant": true,
"tenant": "casino-eu"
}

המדיניות עשויה לדרוש ”התקן _ ציות = אמת” ו ”דייר” כדי להתאים את המשאב.

לבדוק-רשימה

[ ] SSO מתאפשר לכל היישומים; MFA כברירת מחדל, סיסמאות בעדיפות ראשונה.

[ ] RBAC; ABAC/REBAC להוסיף הקשר; מיושם על ידי JIT/JEA.

[ ] PAM מגן על גישה חסויה; הפגישות מוקלטות.

[ ] SCIM מתגרה ממשאבי אנוש; העלאה היא אוטומטית לחלוטין.

[ סודות ] הם דינמיים, עם TTL קצר; סיבובים הם אוטומטיים.

[ מדיניות ] מבוססות בגיט, נבחנות במצ "ח; יש חישובים קנריים.

[ ] Dashbards ו-SLO לפי AuthN/AuthZ; יומנים מרכזיים ו-UEBA.

[ סקירת גישה תקופתית ] ובדיקות SoD; דוחות לציות.

FAQ

האם ReBAC צריך את כולם?
לא, זה לא RBAC + ABAC מספיק לסביבות פשוטות. RBAC שימושי בהיררכיה מורכבת של בעלות על משאבים ורב-שכבתיים.

אני יכול להשאיר חשבונות מקומיים?
רק לתרחישי פריצה ולא מקוונים, עם הגבלות מחמירות ואימות תקופתי.

איך להפחית את ”פיצוץ התפקידים”?
הגדלת גרנולריות משאבים, שימוש בתבניות ABAC/ABC, ביקורות אוטומטיות והשלכת תפקידים שלא היו בשימוש.

סך הכל

ארכיטקטורת IAM בוגרת היא SSO + MFA, מינימום זכויות הכרחיות, JML אוטומטי, מדיניות מרכזית ויכולת תצפית. על ידי שילוב RBAC עם מאפיינים ומודלים יחסיים, יישום JIT/JEA ו-PAM, ואוטומציה של סיבובים סודיים, אתה מקבל גישה מנוהלת, ראוותנית ומספקת שעומדת בדרישות האבטחה והעסקים.