היררכיה של חשבונות ותתי משתמשים

(סעיף: מבצעים וניהול)

1) משימה ועקרונות

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

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

2) מודל התייחסות היררכית

Tenant
├─ Account - legally/operationally significant unit
│ ├─ Sub-account - Product/Region/Team/Project
│ │ ├─ Spaces/Projects/Environments: prod/stage/dev
│ │ └─ Roles and Groups (RBAC/ABAC) for People and Services
│ └─ Shares (limits, budgets, keys, integrations)
└─ Marketplace/Integrations/Affiliates (Outer Loops)

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

3) מודלי הרשאה

RBAC: Operator/Operator/Viewer/Billing/Complication.
ABAC: ”אזור”, ”דייר”, ”חשבון”, ”סביבה”, ”סיכון _ ציון”, ”התקן _ יציבה”.
RBAC: ”בעלים/משתתף/סקירות” מערכות יחסים לפרויקטים וסודות.

פרקטיקה: Hybrid - RBAC כבסיס קריא, ABAC לאילוצי הקשר (אזור/זמן/התקן), ReBAC לבעלות על משאבים.

4) משלחת וירושה

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

5) מכסות, תקציבים, חיובים

מכסות: בקשות/שניות, אירועים/יום, יציאה, אחסון, מפתחות/קובצי אינטרנט.
תקציבים: פקקים חודשיים והתראות (80/90/100%), משנק/השעיה אוטומטית.
חיוב: חשבוניות ברמת הדייר/חשבון; תת-חשבון ומרכזי עלויות.
תמחור העברה: מטענים פנימיים בין איי-בי-אס/אזורים.
שימוש הוגן: מגבלות ציבוריות, מגבלות תעריף, הגנה מפני ”התפרצויות”.

6) זהויות ו ־ SSO/SCIM

SSO (SAML/OIDC): כניסה מרכזית ברמת Tenant.
SCIM: יצירת/ביטול אוטומטי של המשתמשים/קבוצות ומחייב לתפקידים.
JML (Joiner/Mover/Lever): הוצאה אוטומטית של תפקידי התחלה, שינוי במהלך התרגום, החזרה מיידית לאחר הפיטורים.
MFA/FIDO2: חובה על ניהול, מימון וגישה למח "ש.
תנוחת התקן: עמידות במצב התקן (הצפנה, EDR).

7) חשבונות שירות ומפתחות

חשבון שירות לכל חשבון משנה + סביבה, אין סודות משותפים.
זהות עומס עבודה: אסימונים קצרי ימים, קשירה לתחתית/פונקציה.
KMS/Vault: סיבוב סודי, גישת תפקידים, חתימות DSSE.
חוברות אינטרנט: HMAC/EDDSA, ”nonce + timestamp”, חלון TTL.

8) מודל נתונים (מפושט)

דייר, שם, סו, billing_profile, מדיניות [ ]

"tenant_id, אזור, legal_entity, מכסות, תקציבים, risk_tier}',

, מוצר, סביבה, מפתחות , קורות אינטרנט , גבולות

Role 'id', היקף: דייר' accub '_ חשבון, הרשאות [ ]'

'mbership' _ id, role_id, scope_ref, tl, הצדקה '

Pollicy 'l' [סוג: rbac' abac 'sod' soula, גרסה, כללים, חתימה'

”audit _ event” ”.מי, מה, איפה, מתי, trace_id, חתימה”

"מצטט a _ usage" [היקף] ref, מטרי, חלון, בשימוש, cap "

9) חוזי API

• 'פוסט/דיירים/& id//חשבונות' - ליצור חשבון (פוליסות/מכסות/חיוב).
• 'פוסט/חשבונות/& id//תת חשבונות' - ליצור תת חשבון (מפתחות, קורות אינטרנט).
• ”שים/תפקידים/”” מדיניות לחיקוי; ” פוסט/חברים - להקצות תפקיד.
• 'פוסט/גישה/להעלות' - JIT להגביר עם TTL והצדקה.
• 'קבל/מכסות/שימוש' - שימוש/קאפ; " פוסט/מכסות/לעקוף '.

• 'קבל/ביקורת/אירועים? היקף =... יומנים חתומים.
• 'קבל/מצב/גישה' - תפקידי משחק/TTL/מפתחות.
• ”Qu Caprected”, ”Exporting”, ”KeyRO Date”, ”Policyched Changed”.

10) RACI (אזורי מפתח)

11) מדדים ו ־ SLO

TTG (זמן-אל-גרנט): גיליון תקן ממוצע של 4 שעות

כיסוי JIT: 80% מהעסקאות חסויות בתפקידים זמניים.
הפרות SoD: 0 Prod; חיסול טי-אר ב-24 אייץ.
גישה יתומה: נתח של זכויות ”נשכחות” 0. 1%.
מכסה דיוק: התאמת טקסים/שימוש 99. 99%.
ביקורת השלמות: 100% חתימה קריטית/פעילות קבלה.

12) לוחות מחוונים

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

13) מעדן נתונים ופרטיות

דומיין נתונים: PII/Finance - רמת חשבון בלבד; חשבון משנה - אגרגטים/אסימונים.
Regionality: localization of data and keys per-region (אזורי אמון).
בקשות מח "ש: באמצעות דקירות מאושרות בלבד; אסימונים ומיסוך.

14) סיכונים ואנטי דפוסים

מודל שטוח: כל - ”מנהל” תקריות ודליפות.
סודות משותפים: אי-משיכה ואי-אפשרות של ביקורות.
אדם אחד יוצר ומאשר תשלומים/הגבלות.
סביבות לא מוצבות: מפתחות dev בפרוד; מבחן ערבוב ונתונים אמיתיים.
תפקידים ”אינסופיים”: אין TTL/respontication # הצטברות סיכונים.
מכסות חלשות: חשבון משנה אחד ”אוכל” את היכולת של כולם.

15) חוברות משחק תקריות

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

16) עלייה למטוס ומחזור חיים

1. אתחול דייר: SSO/SCIM, פרופיל חיוב, מדיניות גלובלית.

2. צור חשבון - אזורים, מכסות, תקציבים, אזורי נתונים, תפקידי בסיס

3. חשבון משנה: מפתחות/קורות אינטרנט, תפקידי צוות, אינטגרציה.
4. JML/Resertification: סקירה רבעונית של זכויות, הסרה אוטומטית של ”Sleepers”.
5. ארכיון, החזרת מפתח, העברת בעלות, סגירת חיוב.

17) רשימת מימושים

[ ] ליישב את הדייר * חשבון # עץ וחשבון משנה וחוקי ירושה.

[ ] תאר תפקידים (RBAC) ומדיניות הקשר (ABAC), מטריצת SOD.

[ ] התחל SSO/SCIM, תהליכי JML והגברת JIT.

[ ] הזן מכסות/תקציבים/כללים וכוננות.

[ ] לפרוס KMS/Vault, סיבובים, וסודות משותפים.

[ ] לכלול מדיניות כקוד, שחרור חתום, ויומני תולעת.

[ ] הגדרות API ניהול/webhooks, נקודות קצה סטטוס, וביקורת.

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

[ ] GameDay: דליפת מפתח, מכסת סערה, כשל IDP, הפרת SoD.

[ ] מחדשת באופן קבוע תפקידים וסוקרת גבולות.

18) FAQ

איפה לשמור על הגבול בין חשבון לחשבון משנה?
שבו כספים/ציות/רגולציה (חשבון) משתנים, וחשבון משנה - על צוות/מוצר/סביבה.

האם זה אפשרי ”להדביק” מכסות של כמה חשבונות משנה?
כן, דרך בריכות וסדרי עדיפויות, אבל עם יכולת ”לשרוף” נתיכים.

איך להוציא במהירות גישה זמנית?
יישום JIT עם MFA ו-TTL, אוטולוגיה ולאחר המוות עבור מפגשים חסויים.

אני צריך מפתחות שונים בימי רביעי?
נדרש: הפרדת חשבונות שירות/מפתחות עבור dev/stage/pod עם בידוד של רשתות וזכויות.

סיכום: היררכיית החשבונות ותת-המשתמשים היא מסגרת של יכולת ניהול: מבנה קריא של ישויות, מדיניות תורשתית, מכסות מחמירות וחיוב, זהות בטוחה וביקורת מספקת. על ידי יישום RBAC/ABAC/REBAC, JIT/SoD ו-Policy-as-code hybrid, תזכה לעלייה מהירה, עלויות צפויות וביטחון בר קיימא כאשר תוגדר על ידי מוצר, צוות ואזור.